My suggestions are;
1. You need to set HTTP_PROXY and FTP_PROXY before installing new web based package.
2. Instead of /tmp try /root folder for log redirection. Because most of the time /tmp gets cleanup automatically after reboot.
3. Use apt-get update -q -y 2>&1 /tmp/test1 option (2>&1). So that you can catch the error also.
4. If possible download the updated ISO from internet and use it in VMware Studio. You need to update its md5sum in build profile.
Hi, I've just tried your line with an Ubuntu server 10.04.
At first it didn't work, but I decided to copy the line on the post-script and add an upgrade below.
That has worked for me
the script looks something like this:
#Update Ubuntu 10.04 before deployment
apt-get update -q -y 2>&1 /tmp/update.log
apt-get upgrade -q -y 2>&1 /tmp/upgrade.log
Ok, I have to correct my statement on my last post. It has not worked.
Does anybody know how to update ubuntu server before it gets packed into an OVA file?
El mensaje fue editado por: data101
No, don't do this. The entire philosophy of an appliance is that the author (you) controls what is in the appliance, and has validated that it will work. If you use an external service to update packages (especially if you do something as dramatic as try to upgrade the OS!) you have no idea if your application will work at all. How do you support such a hybrid when a customer calls to ask for help? You have no idea the state of the appliance, so you will have no idea how to fix something when it breaks. You don't have to use the VAMI update feature, but you should use something that depends on *you* putting software into the appliance, as opposed to an external third party that you do not control, and that software has been tested with your application.
Get the updated packages from Ubuntu, put them into another application repository called, say, "OS_updates", and *test* the new Ubuntu packages with your application software. Then, and only then, should you make the update repository (with the new Ubuntu packages) available to your customers' appliances.
thank you very much for your answer. I guess I did not explain what I was trying to do before I posted my answer.
What I want to do is create an appliance with the most up to date packages of Ubuntu server 10.04 (for security reasons). I'm not using ubuntu 12.04 LTS because it has issues with Tomcat at this point in time, and I'm not using 11.10 because it's not a TLS version of the OS.
So the idea as you've pointed out, is not to update the appliance when the user deploys it, or have an update button. But to have VMware Studio update the packages when creating the VM's files so that I can freeze it there and have a safer version of what I want to deploy. Otherwise it would be impossible to determine if clients problems were caused by the OS or the program.
The other option would be to create an ISO image of the OS with the latest software, or even a parallel repository and use that. But I'm not quite sure how to do that.
Any ideas on how to achieve what I'm trying to do?
What you can do is create your appliance with Studio, list all the packages and versions (dpkg -l), update it with Ubuntu's mechanism, see which packages were updated, and then copy those packages from the apt cache into a separate repository in Studio.
Interesting, I'll give that a try.
Ok, I've done what you suggested with "apt-get -d upgrade" and put all the files Studio.
Now the OVA is 150MB bigger. Any way I can lower that down? it's meant to be updates, not new debs...
Well, updates to debs can very well be larger, and new deb packages can certainly be added, if a package that you have had new dependencies added (likely), then the VM can certainly be larger. I'm afraid you'll have to ask Ubuntu why things are bigger.
Hi asharpe, thanks for that. Late night, wasn't thinking properly... makes a lot of sence!
I have detected a problem though with the installation of the downloaded deb files.
All of a suden I have realized that neither my application or MySQL is in the resulting VM. I've had a look at the postinstall.log and found that it actually installs the deb files and at the very end, for some reason that I cannot explain, it removes them:
Found linux image: /boot/vmlinuz-2.6.32-38-generic
Found initrd image: /boot/initrd.img-2.6.32-38-generic
Found memtest86+ image: /memtest86+.bin
Finished: See /opt/vmware/www/build/DIDManager.4/status/cut_files.log in Studio for details.
Reading package lists...
Building dependency tree...
Reading state information...
Note, selecting mysql-client-5.1 instead of mysql-client
The following packages were automatically installed and are no longer required:
libnet-daemon-perl liblcms1 libdbi-perl libdbd-mysql-perl libplrpc-perl
Use 'apt-get autoremove' to remove them.
The following packages will be REMOVED:
certmanager mysql-client-5.1 mysql-server mysql-server-5.1
When I remove the repository that contains the updates I get a working VM with my program "certmanager" and MySQL and everything (except updates).
This is my postinstall script:
# Un-comment the following lines for reducing the space occupied for the
# operating system by deleting potentially unneeded files. The script
# template is located at /opt/vmware/etc/footprint and should be used with
# appropriate verification.
wget_opt="-nH --cut-dirs=2 -nv"
echo Download run_cut_files.sh
wget $wget_opt -P /tmp $cut_files_url 2>$wget_err 1>/dev/null
if [ $? -ne 0 ]; then
echo Abort: $errmsg
echo Execute run_cut_files.sh
chmod +x /tmp/$cut_files_wrapper
rm -f /tmp/$cut_files_wrapper $wget_err
#added by DATA101
mysql -u root < /var/opt/tomcatMySQL/temp/DDBBDigitalID.sql
mysqladmin -u root password xxxx
apt-get -y remove mysql-client
service tomcat6 stop
apt-get -y remove tomcat6
apt-get -y remove tomcat6-common
apt-get -y remove libtomcat6-java
apt-get -y remove libservlet2.5-java
update-rc.d -f tomcat6 remove
Any ideas? Is there any other file I could have a look at?
It looks like your removal of the mysql client also decided to remove the server, or the cut_files script is being over-ambitious. You will probably have to comment out lines until your application and mysql stick around, and then you'll know who's doing it.