Automating Fog 0.33b SVN updates in Ubuntu 14.04 with cron (Easily adapted to other linux distros)
-
So I had asked in a different forum post (But the conversation had become irrelevant to the original topic so I made a new one) about making the 0.33b updates smoother in Ubuntu 14.04, since there were so many little things that needed to be changed every time.
I managed to solve the problem myself with a script, and since there are updates everyday, I wrote it with running it in cron on a daily basis. I figured I’m probably not the only one that might want something like this and I didn’t see it anywhere else.
The script backs up and restores a few files that are overwritten by a update and moves ones put in the wrong place, it also downloads and runs the most recent update as well as some other little maintenance tasks.
I attached the script and the content of it is below. I tried to be as detailed as possible with my comments and show other options. You have to put your sudo/user password in the script and the cron entry as cleartext, which could be a security risk if your fog server’s files are exposed to the outside world in someway, but it’s the easiest way I found to use sudo commands unattended.
Note: If you were using an older ubuntu with the /var/www webroot you could probably just take out the bit about moving the fog folder to the proper webroot. I hope this helps somebody out[I]Edits:[/I] I found there were a few things I missed and just added such as
- Making the mysql database check run without opening the browser (Thanks to Tom Elliot)
- changing the permissions of the /images folder so that the fog can rename/move the image from the dev folder
- Adding the symlink for the undionly so that ipxe still works.
- Updated the attached script with this
- Note: You may need to run dos2unix on the script before running it
- Edited some formatting in the script comments in the forum post
- Note: This script will still work with Fog 1.0.x because the svn address is still the same and it does work for upgrading from 0.33b to 1.0.x
This script is designed to run an automated update
of the latest FOG server SVN trunk release-amajig through a cron entry
(crontab -e to edit cron entries) on ubuntu 14.04
the cron entry to run this everyday at 3 am for example would be
0 3 * * *
echo "sudoPassword" | sudo -S /home/fog/UpdateFog33bCronJob.sh
Once a week at 3 am on sunday would be
0 3 * * sun
echo "sudoPassword" | sudo -S /home/fog/UpdateFog33bCronJob.sh
-------------------------------------------
[U][B]# Some prereqs for this script[/B][/U]
Already have an existing working install/configuration of FOG 0.33
svn is installed, can be done with “sudo apt-get install subversion”
A folder for the installs in your home folder, for example it can be created with
mkdir /home/fog/fogInstalls
dos2unix is installed, can be installed with “sudo apt-get install dos2unix”
-------------------------------------------
Now to start installing
First, run ubuntu updates and enter sudo mode
echo “[I]yourSudoPassword[/I]” | sudo -S apt-get update -y
sudo apt-get upgrade -y-------------------------------------------
Copy the latest versions of any files you’ve changed that will be overwritten by the update.
For example
the necessary ones are the config.php files with your corrected webroot and stored credentials (i.e mysql)
If you’ve updated the kernel, the bzimage for that kernel and any extra custom kernels you may have
If you have a custom background for the pxe menu, the bg.png file
It’s a good policy to also have backups of these outside of your server via ftp, in case the config file somehow
gets reset to the default and starts copying that as the backup.
sudo cp /opt/fog/service/etc/config.php /home/fog/fogInstalls
sudo mv /home/fog/fogInstalls/config.php /home/fog/fogInstalls/optConfig.php
sudo cp /var/www/html/fog/commons/config.php /home/fog/fogInstalls
sudo mv /home/fog/fogInstalls/config.php /home/fog/fogInstalls/commonsConfig.php
sudo cp /var/www/html/fog/service/ipxe/bzImage /home/fog/fogInstalls
sudo cp /var/www/html/fog/service/ipxe/bg.png /home/fog/fogInstalls-------------------------------------------
If you want to have a folder for each installer follow my example below
Otherwise, if you want to save harddrive space and not have to delete folders all the time,
skip that part and just use rm -rf on the last installer folder
And make a new one and download it there, I just like having backups.
if you wanted to make a cron job to delete the old folders automatically it would look like this
for deleting any folders 2 weeks old at 4:44 am every sunday
44 4 * * sun
echo "yourSudoPassword" | sudo -S find /home/fog/fogInstalls -type d -mtime 14 -exec rm -rf # {} \
This would find all directories that have been modified at least 14 days ago and execute the command rm -rf
If you want to see what folders it will delete for testing take out everything from -exec on -------------------------------------------
Single Folder Method (You can uncomment this next section to reuse the same folder)
cd /home/fog/fogInstalls
rm -rf /home/fog/fogInstalls/currentInstaller
mkdir currentInstaller
cd currentInstaller
-------------------------------------------
New folders with time and date method (Comment out this section if you use the above method)
cd /home/fog/fogInstalls
time_stamp=$(date +%Y_%m_%d_%H_%M_%S)
mkdir ${time_stamp}
cd ${time_stamp}-------------------------------------------
Download latest fog with svn to that folder
Also change the permissions of the fogInstalls folder
So that you have permission to run the install script and move the
backup files later
sudo svn checkout [url]https://svn.code.sf.net/p/freeghost/code/trunk[/url]
sudo chown -R fog /home/fog/fogInstalls
sudo chgrp -R fog /home/fog/fogInstalls
sudo chmod -R 777 /home/fog/fogInstalls-------------------------------------------
Navigate to the new bin folder and run the installer with auto yes prompt
cd ${PWD}/trunk/bin
sudo yes | ${PWD}/installfog.sh-------------------------------------------
remove the old fog webroot folder and move the new one to the html webroot folder
sudo rm -rf /var/www/html/fog
sudo mv /var/www/fog /var/www/html/fog-------------------------------------------
copy the backed up files to their proper places and make sure they’re formatted correct
also recreate the ipxe undionly.0 symlink
sudo dos2unix /home/fog/fogInstalls/.
sudo rm /opt/fog/service/etc/config.php
sudo cp /home/fog/fogInstalls/optConfig.php /opt/fog/service/etc
sudo mv /opt/fog/service/etc/optConfig.php /opt/fog/service/etc/config.php
sudo rm /var/www/html/fog/commons/config.php
sudo cp /home/fog/fogInstalls/commonsConfig.php /var/www/html/fog/commons
sudo mv /var/www/html/fog/commons/commonsConfig.php /var/www/html/fog/commons/config.php
sudo cp /home/fog/fogInstalls/bzImage /var/www/html/fog/service/ipxe
sudo cp /home/fog/fogInstalls/bg.png /var/www/html/fog/service/ipxe
sudo ln -s /var/www/html/fog/service/ipxe/undionly.kpxe /var/www/html/fog/service/ipxe/undionly.0-------------------------------------------
Then change the permissions of the webroot so it can be accessed from the browser
sudo chown -R fog /var/www/html/fog
sudo chgrp -R fog /var/www/html/fog
sudo chmod -R 775 /var/www/html/fog-------------------------------------------
change permissions of images folder
sudo chown -R fog /images
sudo chgrp -R fog /images
sudo chmod -R 775 /images
#--------------------------------------------I find I have to restart apache2 and mysql to get it to finish the job
Alternatively, you could also have it restart the server at this point with
shutdown -r now
sudo /etc/init.d/apache2 restart
sudo service mysql restartRun the database schema check without having to open the browser
wget -O - --post-data=“confirm=yes” “[url]http://${FOGWEBIP}/commons/schemaupdater/index.php[/url]” 2>/dev/null
[url=“/_imported_xf_attachments/0/720_UpdateFog33bCronJob.zip?:”]UpdateFog33bCronJob.zip[/url]
-
The only thing I haven’t yet figured out (not that I’ve tried very hard to just yet) how to automate in this script is the schema update php script that pops up the first time you open the web interface after the update. Every time it checks and then sees that you don’t need the update. If someone else knows a way to do this by maybe using that php file as a quick check without opening the browser, or opening a terminal based browser and automate clicking the two buttons, or just run the mysql command the php script uses in the sh script. Once that is figured out then our journey to the automated side would be complete (Dark side, automated side, same thing right?).
Thanks,
-JJ -
you could, simply, add
[code]wget -O - --post-data=“confirm=yes” “http://${FOGWEBIP}/commons/schemaupdater/index.php” 2>/dev/null[/code]You may want to add checking if the current schemaversion in the database is less than the schema version in the commons/system.php file so you’re not trying to update the database.
Hopfeully this helps!
-
Adding that line worked beautifully!
I didn’t try adding the schema comparison though. But even if it did try to update the database, wouldn’t it just report back something like 0 rows affected and not be a problem?Also I just noticed that it now shows FOG 1.0 as the version, I don’t know if I just missed that for the past week, but either way that’s awesome. Should I start putting FOG 1.0rc as my version in these posts?
-
[quote=“mecsr, post: 26550, member: 23886”]Adding that line worked beautifully!
I didn’t try adding the schema comparison though. But even if it did try to update the database, wouldn’t it just report back something like 0 rows affected and not be a problem?Also I just noticed that it now shows FOG 1.0 as the version, I don’t know if I just missed that for the past week, but either way that’s awesome. Should I start putting FOG 1.0rc as my version in these posts?[/quote]
Technically, it’s actually Version 1.0.0, but it’s currently in RC. So I suppose appending 1.0.0-rc wouldn’t hurt anything for the time being.
-
This command
wget -O - --post-data=“confirm=yes” “[url]http://${FOGWEBIP}/commons/schemaupdater/index.php[/url]” 2>/dev/null
Seems to have stopped working after the recent updates. -
I’m not aware of any changes, other than adding a schema change, so my guess is this could be the cause?