wiki:support-team/wheezy-upgrade-tech-notes

Version 19 (modified by Jamie McClelland, 5 years ago) (diff)

--

Technical notes on upgrading from squeeze to wheezy

This page details some of the issues we've encountered regarding the squeeze to wheezy upgrades, additional information can be found on #7425, squeeze-wheezy-mosh-upgrade, and support-team/server-upgrade-status.

Steps to take

  • Check /etc/network/interfaces make sure no interface names are longer than 15 characters. If they are, shorten them.
    • example -- eth0:thisismylonginterface must be shortened or else the interface will fail to come up after the upgrade.
  • Ensure current distribution is up to date:
    apt-get update
    apt-get dist-upgrade
    
  • Delete all files in /etc/apt/sources.list.d and /etc/apt/preferences.d (these are controlled by puppet and will be replaced when we next run puppet)
  • Edit /etc/apt/sources.list and change squeeze to wheezy
  • check (or update) /etc/security/limits.d/$(hostname).conf, as described below.
  • Run: apt-get update to update to the current distribution
  • Run: apt-get install dpkg apt to update the package install tools
  • Run: apt-get upgrade to upgrade packages that don't have any new dependencies
  • Run: apt-get dist-upgrade to upgrade all packages
  • Run: freepuppet-run to update our configuration files
  • Run: apt-get update to refresh the package list
  • Run: apt-get dist-upgrade to pull in new packages based on puppet changes
  • Run: apt-get autoremove to remove any packages we no longer need
  • Run: apt-get install deborphan
  • Run: deborphan look at additional unneeded packages
  • Run: apt-get purge $(deborphan) remove those unneeded packages.
  • Run: mf-turn-off-auto-fscks to ensure we don't have to wait for fsck's on reboot
  • Run: shutdown -h now to reboot the system (yes, we say "-h" which means halt, but our virtualization engine will detect that it is off and restart it for us)

major changes

please add more as we discover them:

PHP
we move from PHP 5.3 (which is approaching end of life) to PHP 5.4

configuration files to keep

Almost all configuration files will use the package maintainers version. Here is the short list of things not to modify or that need special attention:

/etc/mysql/my.cnf

Be sure to use the package maintainer version but hit "D" to see the differences and add any changes that we have added to /etc/mysql/conf.d/hostname.cnf

/etc/cron.d/awstats

Keep the currently installed version, we do not actually want awstats to install a cronjob since we manage this cronjob separately.

/var/log/sysstat

The newer version of sysstat asks that you delete the current files, do it

/etc/default/grub

You will be given the following options for grub:

  1. install the package maintainer's version
  2. keep the local version currently installed
  3. show the differences between the versions
  4. show a side-by-side difference between the versions
  5. show a 3-way difference between available versions
  6. do a 3-way merge between available versions (experimental)
  7. start a new shell to examine the situation

You can safely just choose to keep the local version as there are no meaningful changes to the package maintainers version.

mysql-5.5 open files

It's not yet clear if this particular issue will be chronic across servers. However, according to ticket #8040, it appears that mysql file limits might need to be increased just to be safe. The current recommendation judging from rose is to add...

/etc/security/limits.d/hostname.conf

mysql   soft    nofile  4096
mysql   hard    nofile  32768

root    soft    nofile  4096
root    hard    nofile  32768

rebooting

Upon rebooting rose using shutdown -h now the service on rose's host failed to start the kvm process. This required the following commands from root@florence.mayfirst.org:

sv down rose
sv up /etc/sv/kvm/rose

phpmyadmin and php5_cgi

We encountered weirdness with phpmyadmin during the upgrade to rose.

After the upgrade phpmyadmin failed to load with the error:

navigation.php< not found on the server.

Apparently the apache module php5_cgi created this problem as dis-enabling it fixed the error. However, we're not sure why the module got loaded. We'll need to pay attention to this issue on future upgrades, though that module does not seem to be loaded on other moshes.

We also needed to rebuild the phpmyadmin control database. This was done using the info from /etc/phpmyadmin/config-db.php. It's not clear why, but the old phpmyadmin control database did not transfer to the upgraded version of the system. Likely due to choices made during the phpmyadmin reconfiguration.