Can you spot why this is failing? I’m just not seeing it.
Completed appendfile if [ $? -eq 0 ];then
Not seeing anything obvious. Can you post your actionscript? Deleting __appendfile at the start is normal but that should not affect the move unless __appendfile is still in use or locked somehow. Which would be weird.
Here is the entire script. Thanks for looking.
Completed appendfile #! /bin/bashhttp://ROOT:52311/Uploads/3b7a95d1d2cca634ae62ccc338c48806893cc515/jdk-8u141-linux-x64.tar.gz.tmp sha256:88a5e277c5e1f7bc88d60d984fc9d4c8196039229d87fdfe6d9089bb6465b899
What you have posted are the client logs/action results… need the actual actionscript from the fixlet itself.
The copy/move commands will fail if the target already exists. Try deleting /tmp/temp.bash before copying to it.
Here is the full script:
appendfile #! /bin/bash
// replace java versions here
parameter "OLD_JAVA_VERSION" = "jdk1.8.0_121"
parameter "OLD_JAVA_TAR" = "jdk-8u121"
parameter "OLD_JAVA_TAR_FULL" = "jdk-8u121-linux-x64.tar.gz"
parameter "NEW_JAVA_TAR" = "jdk-8u141"
parameter "NEW_JAVA_VERSION" = "jdk1.8.0_141"
//
appendfile if [ -f /etc/init.d/jboss64 ];then
appendfile if [ -x /etc/init.d/jboss64 ];then
appendfile /etc/init.d/jboss64 stop
appendfile fi
appendfile fi
appendfile mkdir /usr/lib/jvm/bkup
appendfile echo "Backing up policy files and cacerts to /usr/lib/jvm/bkup folder" > /usr/lib/jvm/output.txt
appendfile cp -pr /usr/lib/jvm/{parameter "OLD_JAVA_VERSION"}/jre/lib/security/local_policy.jar /usr/lib/jvm/{parameter "OLD_JAVA_VERSION"}/jre/lib/security/US_export_policy.jar /usr/lib/jvm/{parameter "OLD_JAVA_VERSION"}/jre/lib/security/cacerts /usr/lib/jvm/bkup
appendfile if [ $? -eq 0 ];then
appendfile echo "Files copied successfully" >> /usr/lib/jvm/output.txt
appendfile else
appendfile echo "cacerts or policy file copying failed" >> /usr/lib/jvm/output.txt
appendfile fi
if { exists file "/tmp/temp.bash"}
delete "/tmp/temp.bash"
endif
move "__appendfile" "/tmp/temp.bash"
wait chmod 750 "/tmp/temp.bash"
wait "/tmp/temp.bash"
//
if {exists folder "/usr/lib/jvm" whose ( exists folder (parameter "OLD_JAVA_VERSION") of it)}
wait rm -rf /usr/lib/jvm/{parameter "OLD_JAVA_VERSION"}
delete "/usr/lib/jvm/{parameter "OLD_JAVA_TAR_FULL"}"
endif
//
//if {exists folder "/usr/lib/jvm/jdk1.8.0_131"}
//wait rm -rf /usr/lib/jvm/jdk1.8.0_131
//endif
//if {exists file "/usr/lib/jvm/jdk-8u131-linux-x64.tar.gz"}
//delete "/usr/lib/jvm/jdk-8u131-linux-x64.tar.gz"
//endif
prefetch 3b7a95d1d2cca634ae62ccc338c48806893cc515 sha1:3b7a95d1d2cca634ae62ccc338c48806893cc515 size:184933527 http://p3piemc01.rb.win.frb.org:52311/Uploads/3b7a95d1d2cca634ae62ccc338c48806893cc515/jdk-8u141-linux-x64.tar.gz.tmp sha256:88a5e277c5e1f7bc88d60d984fc9d4c8196039229d87fdfe6d9089bb6465b899
extract 3b7a95d1d2cca634ae62ccc338c48806893cc515 /usr/lib/jvm
appendfile #! /bin/bash
appendfile cd /usr/lib/jvm
appendfile tar xvzf /usr/lib/jvm/{parameter "NEW_JAVA_TAR"}-linux-x64.tar.gz
if { exists file "/tmp/java-copy.bash"}
delete "/tmp/java-copy.bash"
endif
move "__appendfile" "/tmp/java-copy.bash"
wait chmod 750 "/tmp/java-copy.bash"
wait "/tmp/java-copy.bash"
wait /usr/sbin/alternatives --install /usr/bin/java java /usr/lib/jvm/{parameter "NEW_JAVA_VERSION"}/bin/java 1
wait /usr/sbin/alternatives --set java /usr/lib/jvm/{parameter "NEW_JAVA_VERSION"}/bin/java
if { exists file "/tmp/start.bash"}
delete "/tmp/start.bash"
endif
wait cp -pr /usr/lib/jvm/bkup/local_policy.jar /usr/lib/jvm/{parameter "NEW_JAVA_VERSION"}/jre/lib/security
wait cp -pr /usr/lib/jvm/bkup/US_export_policy.jar /usr/lib/jvm/{parameter "NEW_JAVA_VERSION"}/jre/lib/security
wait cp -pr /usr/lib/jvm/bkup/cacerts /usr/lib/jvm/{parameter "NEW_JAVA_VERSION"}/jre/lib/security
wait chown -R root:root /usr/lib/jvm/{parameter "NEW_JAVA_VERSION"}
wait chmod -R 755 /usr/lib/jvm/{parameter "NEW_JAVA_VERSION"}
appendfile #! /bin/bash
appendfile if [ -f /etc/init.d/jboss64 ];then
appendfile if [ -x /etc/init.d/jboss64 ];then
appendfile /etc/init.d/jboss64 start
appendfile fi
appendfile fi
move "__appendfile" "/tmp/start.bash"
wait chmod 750 "/tmp/start.bash"
wait "/tmp/start.bash"
1 Like
jmaple
October 21, 2017, 7:54pm
7
Try removing the quotes around __appendfile. ActionScript treats __appendfile as a full path and the move action should move it successfully without the need for it to be quoted.
AlanM
October 23, 2017, 11:54pm
8
The check isn’t required, the delete will handle it if its not there to delete
1 Like
AlanM
October 23, 2017, 11:56pm
9
The copy here has a space where it should be just
#!/bin/bash
AlanM
October 23, 2017, 11:58pm
10
This may also cause a problem as your /tmp volume may not have the ability to add the +x bit
Consider doing the following
wait /bin/sh /tmp/java-copy.bash
1 Like
jgstew
October 23, 2017, 11:59pm
11
I would call bash specifically instead:
wait /bin/bash /tmp/java-copy.bash
This won’t make a difference on the Mac, but on Linux, it will if you intend it to be run as a BASH script. Not all scripts will work interchangeably between bash and sh
AlanM
October 24, 2017, 12:04am
12
True, but the .bash file will be looked at for its start command (the hash first line) and should automatically run the correct processor.
I incorporated all of your suggestions (except wait /bin/sh /tmp/java-copy.bash). It’s still failing at the same place. I just don’t understand this because I simply copied a working script and made some minor changes. This is just not making sense to me. It’s got to be something simple and stupid.
Failed move __appendfile "/tmp/temp.bash"
wait chmod 750 "/tmp/temp.bash"
wait "/tmp/temp.bash"
appendfile #!/bin/bashhttp://p3piemc01.rb.win.frb.org:52311/Uploads/3b7a95d1d2cca634ae62ccc338c48806893cc515/jdk-8u141-linux-x64.tar.gz.tmp sha256:88a5e277c5e1f7bc88d60d984fc9d4c8196039229d87fdfe6d9089bb6465b899
The syntax looks correct. Is there anything that might prevent the root account from writing to /tmp ? Filesystem out-of-space, filesystem not mounted, SELinux rules, anything like that?
JasonWalker:
The syntax looks correct. Is there anything that might prevent the root account from writing to /tmp ? Filesystem out-of-space, filesystem not mounted, SELinux rules, anything like that?
None of that should be in play. The account used has successfully updated another directory (similar script) under the same /opt/Apps folder. Only 3% of the tmp is being used right now.
When BigFix flags a statement and indicates “Failed”, does that mean that particular statement or could it be something further down. This is just not making sense.
Thanks so far for your suggestions and time.
Ken
It’s supposed to mean that particular line failed, but you’d need to review the client-side logs to be sure.
My last reply was slightly incorrect. I’m not updating a directory in /opt/Apps. I am upgrading java in the standard /usr/lib/jvm directory.
That being said I think the issue is 2 different apps are using that Java. I stop one but the other is still running and probably causing contention with removing the old java and replacing with the new one. I need to try this on a test server where this is the only app using that java. This is probably the issue.
Stopping the other app did not help. The /tmp/temp.bash was in the tmp directory from a previous older run similar to this one. I manually deleted it and re-ran. This file did not get written to the directory on the last attempt, failing again at the same point. I’ll just have to keep digging I guess.
trn
October 25, 2017, 7:56am
19
If /tmp/temp.bash was already there from a previous run it implies that the delete of the file failed.
I’d try a stripped out task that just creates the file in /tmp - something along the lines of
delete __appendfile
appendfile "Test file written {now}"
delete "/tmp/temp.bash"
continue if {not exists file "/tmp/temp.bash"}
copy __appendfile "/tmp/temp.bash"
continue if {exists file "/tmp/temp.bash"}
A couple of runs of that should tell you whether you can create your file. The continue statements will trip out where it fails. The timestamp in the file will also tell you whether it is being created afresh each time.
Finally getting back to this, sorry for the delay.
I ran what you suggested and it failed at the end. So what does this tell me, especially in light of a similar script working? If not enough rights to perform this, how do I get it to work?
Completed delete __appendfile
