Site Navigation
|
|
PGTS Humble BlogThread: Tips/Tricks For Programming etc |
|
 |
Gerry Patterson. The world's most humble blogger |
| Edited and endorsed by PGTS, Home of the world's most humble blogger | |
| | |
Upgrading to Ubuntu 14.04 Server |
|
Chronogical Blog Entries: |
|
| | |
Date: Sat, 6 Sep 2014 20:56:58 +1000Upgrading to version 14 Ubuntu is straight forward. If you do it now you will get the LTS version (14.04) ... Soon it will time for 14.10. |
|
I have already upgraded all workstations. However, I usually take a little more time to upgrade servers. On the one hand, upgrading a server is easier than upgrading a workstation because there usually are none of the complications involved with upgrading a GUI ... Unless you make a habit of installing a GUI on all your servers ... I'm inclined to regard a GUI on server as about as useful as a "bull with tits" ... So generally, I won't have problems with video cards, X, or GUI applications trying to be too smart for their own good. On the other hand problems with a server upgrade can have "downstream" consequences ... So it is usually prudent to to approach them with care.
A few of the issues I've encountered about upgrading to Ubuntu 14.04 server are:
-
Samba utils is now CIFS. If the server is older than 13.10, you'll probably discover that any samba shares mounted with samba utils software in /etc/fstab will no longer mount. You will probably have to install cifs-utils and change any file types smbfs in /etc/fstab to cifs ... Apart from the name change everything seems to work as before. But for servers in a complex Windows/Unix environment there could be complications.
-
New version of postgres. This is mentioned briefly during the upgrade --- But it might flick past and escape your attention. The upgrade procedure will retain the old 9.1 cluster and creates an empty 9.3 cluster. You must purge the dummy 9.3 cluster and upgrade the 9.1 cluster to 9.3 ASAP. As the application owner (default is "postgres") ... Run these commands:
pg_dropcluster --stop 9.3 main pg_upgradecluster 9.1 main pg_dropcluster 9.1 main
If you used the default HOME settings for postgres, you'll probably need to clean up the 9.1 folders in the application owner's HOME folder and alter any environment settings in .profile. -
Timezone lost in postgresql. Sometimes the new version of postgres ignores server TZ settings. For any session that does not set it explicitly it reverts to UTC. There might be a good reason for this but I was not able to discover it ... The solution I used was to edit /etc/postgresql/9.3/main/postgresql.conf and replace these two:
#log_timezone = '(defaults to server environment setting)' #timezone = '(defaults to server environment setting)' log_timezone = 'Australia/Melbourne' timezone = 'Australia/Melbourne'
Of course you must substitute the (valid) TZ name for your zone ... Unless you also wish to use the Melbourne/Australia zone. I still haven't worked out the cause of this, because fresh installations of postgres don't seem to have this issue. -
New apache config. As ever you will have to check the config files for apache, and make sure that aliases, mods, etc came across in the new version. Also if your setup comes from a 12.04 server (mostly likely since that was the last LTS) ... Then you have to decide whether to go with the new default application owner of "www-data" or stick with "apache". Certainly if you have a slightly complex setup with mulitple scripts you would want to keep the "apache" user and group and check that they still have access to various components (such as logrotate scripts etc)
-
Bug in python script for xhtml2pdf. This one was a bit obscure. The PDF creation script, xhtml2pdf returned the following error:
**************************************************** IMPORT ERROR! Reportlab Version 2.1+ is needed! **************************************************** ... File "/usr/lib/pymodules/python2.7/sx/pisa3/pisa_util.py", line 44, in <module> raise ImportError("Reportlab Version 2.1+ is needed!") ImportError: Reportlab Version 2.1+ is needed!I tried purging and re-installing all associated packages ... Eventually I found the only way to address this issue was to modify /usr/lib/pymodules/python2.7/sx/pisa3/pisa_util.py :43c43 < if not(reportlab.Version[0] == "2" and reportlab.Version[2] >= "1"): --- > if not(reportlab.Version[0] == "3" and reportlab.Version[2] >= "0"): 46c46 < REPORTLAB22 = (reportlab.Version[0] == "2" and reportlab.Version[2] >= "2") --- > REPORTLAB22 = (reportlab.Version[0] == "3" and reportlab.Version[2] >= "0")
There is already quite a lot of info on the web about this ... But what there is does not really make it clear about how to fix the problem. I found that after hacking the code, it all worked as it did before ... However, YMMV ... Actually it is a bug ... And probably will be modified in a future release. -
Deprecated warning message from Mail::Sender. This depends on how you have installed your perl modules and in particular Mail::Sender. If you encounter this issue you will see something like the following warning:
# Warning message from Mail::Sender: defined(@array) is deprecated at /usr/share/perl5/Mail/Sender.pm line xxx (Maybe you should just omit the defined()?)
Generally I avoid editing code that came from CPAN ... Also I usually take the approach that it is easier to use APT to manage them rather than CPAN ... CPAN doesn't have an uninstall option. In this case I decided to purge the Mail::Sender package with APT and then install it with CPAN ... It's pretty simple:# You can discover the name with "dpkg" apt-get purge libmail-sender-perl # you will need "make" if it's not there -- Might be a good idea to install YAML also apt-get install make # Start up CPAN: install CPAN reload cpan install YAML # Now search for and install the latest version of Mail::Sender
Unfortunately, taking the option of installing packages with CPAN means taking ownership of the managment of perl packages going forward ...