User Tools

Site Tools


system:vicki_debian_lenny_to_squeeze

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Last revision Both sides next revision
system:vicki_debian_lenny_to_squeeze [2012-03-15T13:16:57+0000]
michael_paoli updated to current status and what's been done, etc.
system:vicki_debian_lenny_to_squeeze [2013-02-17T19:55:50+0000]
michael_paoli syntax correction and a typo fix
Line 543: Line 543:
  
 </​file>​ </​file>​
- 
 ===== vicki host install/"​upgrade"​ procedure outline + select details: ===== ===== vicki host install/"​upgrade"​ procedure outline + select details: =====
 <​file>​ <​file>​
Line 645: Line 644:
       o /boot       o /boot
       o vicki-boot       o vicki-boot
-    o Finish partitioning ​nad write changes to disk+    o Finish partitioning ​and write changes to disk
     (continue without swap)     (continue without swap)
 o Install base system o Install base system
Line 846: Line 845:
 ===== sflug VM upgrade to Debian GNU/Linux 6.0.4 ===== ===== sflug VM upgrade to Debian GNU/Linux 6.0.4 =====
   * sflug VM log bits made available here: [[http://​www.sf-lug.com/​log.txt]]   * sflug VM log bits made available here: [[http://​www.sf-lug.com/​log.txt]]
-  * upgrade to be done [[http://​linuxmafia.com/​pipermail/​sf-lug/​2012q1/​009242.html|soon]] +  * upgrade to be done [[http://​linuxmafia.com/​pipermail/​sf-lug/​2012q1/​009242.html|soon]] ... [[http://​linuxmafia.com/​pipermail/​sf-lug/​2012q1/​009246.html|"​done"​]] 
-  * will be upgrading, mostly per:+  * will be upgrading/was upgraded, mostly per:
     * **backup(s)** - since [www.]sf-lug.com is (generally) "​down"​ when sflug is down, we'll mostly try to minimize the host's downtime. ​ So, for backup, backing up "​everything"​ is good,  but as this is a VM, and its storage on the hosting system is under LVM, we have some nice options for fast live backups - backups from which, state is at least "​recoverable",​ namely:     * **backup(s)** - since [www.]sf-lug.com is (generally) "​down"​ when sflug is down, we'll mostly try to minimize the host's downtime. ​ So, for backup, backing up "​everything"​ is good,  but as this is a VM, and its storage on the hosting system is under LVM, we have some nice options for fast live backups - backups from which, state is at least "​recoverable",​ namely:
       * from host (vicki), sflug'​s storage is an LVM LV,       * from host (vicki), sflug'​s storage is an LVM LV,
Line 1099: Line 1098:
  
 </​file>​ </​file>​
-            * present Debian GNU/Linux 6.0.4 "​Squeeze"​ - Official i386 CD Binary-1 20120128-12:​53 (or latest 6.0.x) from host to sflug guest,\\ we do this as a SCSI "​disk"​ (though SCSI CD-ROM would be even more preferred), as we can't hot remove virtual IDE devices from guest (though we can change virtual media ... but sometimes we want to present multiple ISO images concurrently,​ and it's preferable to be able to remove the devices when they'​re no longer needed or wanted), so we present it from host vicki thusly:\\ # virsh attach-disk sflug /​var/​local/​pub/​mirrored/​cdimage.debian.org/​debian-cd/​6.0.4/​i386/​iso-cd/​debian-6.0.4-i386-CD-1.iso sdc optional ​--mode readonly\\ Note that that sometimes ​cases a slight booboo in the guest'​s configuration,​ which we'd fix via:\\ # virsh edit sflug\\ namely we'd want to change the driver name from file to qemu in the section for our added disk - otherwise the guest will fail to restart once (virtually) powered off.  In our particular case this time around, virsh appeared to not introduce that issue (it used driver name phy) - probably "good enough",​ so didn't bother to "​correct"/​alter that at time of upgrade; we do however, still need to test full (virutal) power down and subsequent reboot of guest+            * present Debian GNU/Linux 6.0.4 "​Squeeze"​ - Official i386 CD Binary-1 20120128-12:​53 (or latest 6.0.x) from host to sflug guest,\\ we do this as a SCSI "​disk"​ (though SCSI CD-ROM would be even more preferred), as we can't hot remove virtual IDE devices from guest (though we can change virtual media ... but sometimes we want to present multiple ISO images concurrently,​ and it's preferable to be able to remove the devices when they'​re no longer needed or wanted), so we present it from host vicki thusly:\\ # virsh attach-disk sflug /​var/​local/​pub/​mirrored/​cdimage.debian.org/​debian-cd/​6.0.4/​i386/​iso-cd/​debian-6.0.4-i386-CD-1.iso sdc --mode readonly\\ Note that that sometimes ​causes ​a slight booboo in the guest'​s configuration,​ which we'd fix via:\\ # virsh edit sflug\\ namely we'd want to change the driver name from file to qemu in the section for our added disk - otherwise the guest will fail to restart once (virtually) powered off.  In our particular case this time around, virsh appeared to not introduce that issue (it used driver name phy) - probably "good enough",​ so didn't bother to "​correct"/​alter that at time of upgrade; we do however, still need to test full (virutal) power down and subsequent reboot of guest
             * on guest, scan SCSI devices, create mount point (if not present), update /etc/fstab, and mount it:             * on guest, scan SCSI devices, create mount point (if not present), update /etc/fstab, and mount it:
               * # (for tmp in /​sys/​class/​scsi_host/​host*/​scan;​ do echo '- - -' > "​$tmp";​ done)               * # (for tmp in /​sys/​class/​scsi_host/​host*/​scan;​ do echo '- - -' > "​$tmp";​ done)
Line 1115: Line 1114:
             * we essentially completed through step 4.6.3, "​skipped"​ (deferred) 4.7 (the part before 4.7.1), and completed step 4.7.1, and then deferred subsequent steps (4.8 and beyond) for later subsequent "​clean-up"​ and the like, having essentially made it through all the particularly critical and important portions of the main sequence of the upgrade proper.             * we essentially completed through step 4.6.3, "​skipped"​ (deferred) 4.7 (the part before 4.7.1), and completed step 4.7.1, and then deferred subsequent steps (4.8 and beyond) for later subsequent "​clean-up"​ and the like, having essentially made it through all the particularly critical and important portions of the main sequence of the upgrade proper.
             * we also both web server and DNS server both on the host and up and running and operational as expected.             * we also both web server and DNS server both on the host and up and running and operational as expected.
-          * **to do**+          * **and done(!)** - these bits were completed later, but not later than 2012-03-17: 
-            * (forgot to do the full virtual power part of this 2012-03-14 - will retest relatively soon including full virtual power down and power up of guest; otherwise this was fully tested on 2013-03-14 within our upgrade maintenance window) test a full (virtual) power down and restart of sflug guest, ensure it properly comes up multiuser without any need for console input. +            * went through and completed ​our various clean-up tasks: 
-            * will, fairly soon, go through and complete ​our various clean-up tasks: +              * reviewed ​configurations - in the interests of time (and uptime), some of the configurations where we had local modifications,​ we just used our "​old"​ configurations,​ and didn't examine or merge/​integrate our earlier changes with the newer default configurations; completed going through those carefully and adjusting and cleaning up as appropriate 
-              * review some of the configurations - in the interests of time (and uptime), some of the configurations where we had local modifications,​ we just used our "​old"​ configurations,​ and didn't examine or merge/​integrate our earlier changes with the newer default configurations +              * init / rc stuff - we didn'​t ​earlier ​get the advantages of the newer faster start-up system - some legacy/​dependency bit prevented that from being activated; ​reviewed ​that and got that all squared away
-              * init / rc stuff - we didn't get the advantages of the newer faster start-up system - some legacy/​dependency bit prevented that from being activated; ​will review ​that (after other clean-up bits) to see if there'​s anything we still need to then do at that point to activate and get the (speed, etc.) advantages of the newer and better/​faster start-up initialization+
               * 4.7 (the part before 4.7.1)               * 4.7 (the part before 4.7.1)
               * steps starting at and beyond step 4.8               * steps starting at and beyond step 4.8
-              * saved script output from most of the upgrade process - review ​that for any potentially security sensitive bits, and if there aren't any significant security issues with public disclosure, ​make that data available +              * saved script output from most of the upgrade process - reviewed ​that for any potentially security sensitive bits, and as there weren't any significant security issues with public disclosure, ​made that data available ​(at least "for a while"​) at: [[http://​www.sf-lug.com/​upgrade-squeeze.tar.bz2]] 
-              * high-level (human written (with some machine assist) and intended for human consumption) log file for the system is available at:\\ [[http://​www.sf-lug.com/​log.txt]] - for this system upgrade bit, look/search for the line that starts with:\\ 2012-03-14\\ (at the time of this writing that's near the end of that file). ​ Will also continue to update ​that file, and likely provide information on where the saved script(1data may be publicly obtained - presuming such is cleared ​for and is made publicly accessible+              * high-level (human written (with some machine assist) and intended for human consumption) log file for the system is available at:\\ [[http://​www.sf-lug.com/​log.txt]] - for this system upgrade bit, look/search for the line that starts with:\\ 2012-03-14\\ (at the time of this writing that's near the end of that file) ... and got that file quite caught up. 
 +            * did full virtual power reboot test (did reboot tests 2012-03-14but not with full virtual power down and back up again with guest), ensured that guest comes up fine with no need for any console input being provided
       * and (documentation bits - didn't really need to refer to or use this particular document with/for our upgrade) also if/​as/​where/​relevant:​ [[http://​www.debian.org/​releases/​stable/​i386/​|Debian GNU/Linux Installation Guide]] (installation instructions for the Debian GNU/Linux 6.0 system (codename “squeeze”),​ for the 32-bit PC (“i386”) architecture)       * and (documentation bits - didn't really need to refer to or use this particular document with/for our upgrade) also if/​as/​where/​relevant:​ [[http://​www.debian.org/​releases/​stable/​i386/​|Debian GNU/Linux Installation Guide]] (installation instructions for the Debian GNU/Linux 6.0 system (codename “squeeze”),​ for the 32-bit PC (“i386”) architecture)
system/vicki_debian_lenny_to_squeeze.txt · Last modified: 2013-02-17T20:00:48+0000 by michael_paoli