[[PageOutline]] = 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, [wiki:squeeze-wheezy-mosh-upgrade], and [wiki: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 * 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: `apt-get purge deborphan * 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 [http://php.net/archive/2013.php#id2013-07-11-1 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 [DebianPackage:phpmyadmin] reconfiguration.