Recent Changes - Search:
OSsetup /

HumbabaDebian8Upgrade

Upgrading OS from v7 "Wheezy" to v8 "Jessie"

2018-02-10

Pre-test

Again, as before with the Squeeze to Wheezy update I added a third drive to the RAID array and synced. Then I removed the third disk again with:

# mdadm --manage /dev/md1 --fail /dev/sdd5 --remove /dev/sdd5
# mdadm --manage /dev/md0 --fail /dev/sdd1 --remove /dev/sdd1

I physically removed the third drive and connected to an identical HP t5740 box, to be used as a test rig for the upgrade process before doing the real upgrade.

With the test rig booted, in order to eliminate network conflicts I changed:

hostname to "humtest"
# hostname humtest
# echo humtest > /etc/hostname
changed IP address to "192.168.1.217"
# ifconfig eth0 192.168.1.217
modified /etc/network/interfaces with 192.168.1.217

Then rebooted to confirm changes and get a fresh session

Next, I ran aptitude to see if there were any outstanding actions by typeing 'g' and there were none.

Next, I ran:

  • # dpkg --audit

which returned a list of two packages that were "missing the md5 control file":

  • module-init-tools
  • binutils

It recommened reinstalling these packages and I did so without trouble:

  • # apt-get install --reinstall module-init-tools
  • # apt-get install --reinstall binutils

A rerun on dpkg --audit comes back clean (no output)

I modified /etc/apt/sources.list

  • commented out the Wheezy lines
  • added lines for Jessie

Started the script capture tool:

  • # script -t 2>~/upgrade-jessie1.time -a ~/upgrade-jessie1.script
  • (this can latter be reviewed with: less -R ~/upgrade-jessie1.script)

Updated the package database

  • # apt-get update

Performed the initial minimal upgrade

  • # apt-get upgrade

This showed 349 packages to be upgraded, 239 'held-back' and asked for confirmation. I entered 'Y' to begin. The package download began showing about 16 minutes would be required. A list of important changes to a number of packages appeared:

  • imagemagick
  • ca-certificates (x7)
  • jbig2dec
  • screen
  • coreutils
  • libhtml-tree-perl
  • make-dfsg (x2)

After enter 'q' to quit, the package installation process began. There was one instance of configuration collisions. In this case, I elected to allow the package's new file to be installed, but first I made a copy of the old file, appending "wheezy" ala "xxxxx.wheezy":

  • /etc/fuse.conf

Through the process there were occassional warnings that Teapop was did not have appropriate LSB tags in it's init.d script. These I ignored, since teapop is an old package, but still serves as my POP3 server.

At this point, we are ready for the full upgrade to Jessie:

  • # apt-get dist-upgrade

This showed 238 packages to be upgraded, 237 to be newly installed, 13 to remove, and 1 to be held back (db5.1-util) and asked for confirmation. I entered 'Y' to begin. The package download began showing about 37 minutes required. A list of important changes to a number of packages appeared:

  • samba (x2)
  • cryptsetup
  • cups (x2)
  • exim4
  • gnuplot (x2)
  • initramfs-tools
  • linux-latest
  • openssh
  • php5 (x4)
  • subversion
  • curl (x2)
  • libio-socket-ssl-perl (x2)
  • mutt
  • util-linux

I entered 'q' to continue.

The package installation process began.

I was queried about the new openssl: should I disable root login with password? I answered 'NO'.

I got a WARNING about a configuration problem with apache which wouldn't let the server start. I'll have to check this later.

As the packages were installed I saw a number of file collisions. In all cases a made a copy of the old file (naming it xxxxxx.wheezy), and then allowed the system to install the package's new file:

  • /etc/apache2/mods-available/autoindex.conf
  • /etc/apache2/mods-available/userdir.conf
  • /etc/apache2/ports.conf
  • /etc/samba/smb.conf
  • /etc/subversion/servers
  • /etc/vsftpd.conf

The vsftpd servers was restarted but produced a WARNING and was unable to start. I'll have to check this later. NB: I setup vsftpd to run from inet.d in Wheezy and that may have something to do with it.

Then the upgrade process finished.

As suggested by the Release Notes, a purge of obsolete packages and configuration files is a good idea. I used this command:

  • # aptitude search '~c'
  • # aptitude purge '~c'
  • # apt-get autoremove

Again vsftpd was unable to start via init.d runlevels.

Time to reboot!

  • # reboot

The system boots up fine, it is mostly functional. MySQL is working fine, Apache/PHP5 are working fine, with exceptions given below.

There are some immediate problems:

  • Apache
    • server daemon can't determine it's own name (conf.d is now conf-available/conf-enabled)
    • home-grown virtual domain MailManager (mm) is no longer working
    • user dirs are not served, with "Forbidden"
    • virtual hosts are not served, with "403 Forbidden"
    • perl scripts do not execute, rather they are offered for download
    • icons for etexts (EPUB, PDB) no longer render (/etc/apache2/mods-available/autoexec.conf)
    • configuration files layout has changed
      • /etc/apache2/conf.d is no longer used
      • /etc/apache2/conf-available/* and /etc/apache2/conf-enabled/* are now used
  • Samba
    • home shares are not working... (...again; same as upgrade to wheezy)
  • PmWiki
    • I'm running a very old version, 2.2.15; it is working, but it is generating a lot of log traffic, due to it's use of PHP's preg_replace() /e option. The /e option is deprecated since PHP 5.4 and every use of it generates a log message. There are hundreds of these messages generated for every pmwiki page display. The solution is to upgrade PmWiki to a more recent version. Doing so could possibly break something, so I'll tackle that as a secondary project.

I had to make a few changes to get the system functional again:

Apache
  • /etc/apache2/conf.d
    • copy /etc/apache2/conf.d/httpd.conf to /etc/apache2/conf-available/global.conf
    • create symlink in /etc/apache2/conf-enabled/
    • copy /etc/apache2/conf.d/mm to /etc/apache2/conf-available/mm.conf
    • create symlink in /etc/apache2/conf-enabled/
  • /etc/apache2/mods-available/autoindex.conf
    • add back in the custom icons for etexts
      • AddIcon /icons/epub.gif .epub
      • AddIcon /icons/palm.png .pdb .pdc
  • /etc/apache2/mods-available/userdir.conf
    • change dir to 'www' from 'public_html' (two references)
    • add 'ExecCGI' to the allowed actions
    • ''This got the user dirs (~jared) working again, but virtual hosts are still denied.
  • /etc/apache2/sites-available/*
    • postfix each vdomain config file with ".conf"
    • edit each vdomain config file (in /home/vdomain/xxxx/etc/httpd.conf)
      • add "Require all granted" inside the top-level <Directory /> section
      • add "Require all granted" inside rogerwilco.org :443 section
  • /etc/apache2/sites-enabled/*
    • postfix each vdomain config file with ".conf"
  • interestingly, perl script pages now work without further config changes (i.e., DropZone)
Samba
  • /etc/samba/smb.conf
    • still in [global], immediately after "=== Share Definitions ===" add:
      • browsable = yes
      • comment =
    • in [homes] add:
      • guest ok = yes
      • force user = %S
      • writeable = yes
    • in [homes] comment out (using ';'):
      • ;comment = Home Directories
      • ;read only = yes
      • ;valid users = %S
pmWiki

This was easy! All I needed to do was download the latest from pmwiki.org (2.2.107) and install it:

At this point, I am ready to perform the upgrade on the production server.

Actual Upgrade - 2018-02-11

In preparation for the upgrade on the actual server, I restored the third drive to the RAID array:

I physically mounted the third drive; it became /dev/sdd
# mdadm --misc --zero-superblock /dev/sdd5
# mdadm --misc --zero-superblock /dev/sdd1
# mdadm --manage /dev/md1 --add /dev/sdd5
# mdadm --manage /dev/md0 --add /dev/sdd1

Then, I followed the steps outlined above from my test run-through. I first started by making sure that I had a fully synced RAID with three drives. Once that was complete, I followed step-by-step the actions listed above. I removed the third RAID drive again, keeping it as a snapshot backup, and proceeded with the upgrade with the two remaining drives in the RAID array. All went smoothly and exactly as the test run.

A couple of things that I did this time around, not listed above:

  • I ran the apt-get dist-upgrade command twice. It helped to finalize a few packages that had somehow been held back (probably for dependencies, but the second run solved those problems.

There were still complaints about vsftpd, but I will resolve that later, since ftp is only used by me on my local network.

Then, to make sure that I was bootable from either drive of the RAID array, reinstalled grub:

# grub-install /dev/sda
# grub-install /dev/sdc

Then I was ready to reboot, after which I completed the steps outlined above.

As for PmWiki, I run three instances:

  1. JBwiki
  2. BRBFTwiki
  3. PC80

The first I upgraded right away (again using my notes from the test run). No problems noted.

The second and third have customizations that will require more time than I have at present to confirm or disprove their functionality after the upgrade to 2.2.107, so I'm holding those as projects for another day.

Fixed vsftpd execution for modifying the config file /etc/vsftpd.conf:

change listen_ipv6 = YES to listen_ipv6 = NO
change write_enable = NO to write_enable = YES

2018-02-12

Upgraded the PC80 PmWiki code to version 2.2.107. Since I tap directly into the main pmwiki.php script in order to accomplish the needed page fixups for my antique computer antics pages, I had to restore the hack in function PageBrowse() after the PmWiki upgrade: 

  } else {
    $IsHTMLCached = 0;
###vv### 2017-10-23 JRB - perform whole text manipulation before rendering
      if ( preg_match( '/^\(:NotesFile:/m', $text ) ) {
              $text = AnticsTextPreProcess( $text );
      }
###^^### 2017-10-23 JRB - perform whole text manipulation before rendering

Upgraded the BRBFTwiki to PmWiki 2.2.107. I was concerned that my customization of the slide photo pages would require special fixups, but fortunately it is not necessary. The meta data 'details' of each slide are edited with an out-of-band custom PHP script that is not affected by an upgrade of the PmWiki code.

One last item, sadly, is that Netatalk has been removed as an official package in Jessie. It is back in Stretch, but an old 2.2.xx version. There are some details on the interweb that show how to get Netatalk 3.1.xx installed on Jessie, but I'll probably just wait for my next upgrade to Stretch.