Difference between revisions of "Todo - Spring 2013"
(→www) |
(add general notes on proper procedure) |
||
Line 1: | Line 1: | ||
The following list of items should ideally be accomplished during spring break. If you are interested in working on a task below, please add your name in the space provided. Items highlighted in red need downtime notification provided to users at least 24 hours in advance of maintenance. | The following list of items should ideally be accomplished during spring break. If you are interested in working on a task below, please add your name in the space provided. Items highlighted in red need downtime notification provided to users at least 24 hours in advance of maintenance. | ||
+ | |||
+ | =General Notes= | ||
+ | Downtime notifications for items highlighted in Red should be posted via Iodine at least 24 hours in advance (but ideally as soon as possible). They should include both a start time and estimated end time. Be generous when estimating end-times :). | ||
+ | |||
+ | In general, a good pattern to follow when updating systems is: Reboot, Update, Reboot again, Verify. This way you are sure that the system is in working order before beginning work. The Verify step is also very important to make sure that you leave systems in working order :). | ||
+ | |||
+ | You should also make sure you have a current backup (If the system is running [[Guardian Backup System|Guardian]], check /root/scripts/backup.log to make sure the last backup is current and successful). | ||
+ | |||
+ | For paired/redundant systems (eg: casey/smith or ns1/ns2), there should be at least 24 hours between the maintenance windows for the two servers to allow time for any subtle problems to surface. | ||
=Updates= | =Updates= |
Revision as of 00:37, 24 March 2013
The following list of items should ideally be accomplished during spring break. If you are interested in working on a task below, please add your name in the space provided. Items highlighted in red need downtime notification provided to users at least 24 hours in advance of maintenance.
General Notes
Downtime notifications for items highlighted in Red should be posted via Iodine at least 24 hours in advance (but ideally as soon as possible). They should include both a start time and estimated end time. Be generous when estimating end-times :).
In general, a good pattern to follow when updating systems is: Reboot, Update, Reboot again, Verify. This way you are sure that the system is in working order before beginning work. The Verify step is also very important to make sure that you leave systems in working order :).
You should also make sure you have a current backup (If the system is running Guardian, check /root/scripts/backup.log to make sure the last backup is current and successful).
For paired/redundant systems (eg: casey/smith or ns1/ns2), there should be at least 24 hours between the maintenance windows for the two servers to allow time for any subtle problems to surface.
Updates
VM Servers
Antipodes
- update system software
- update system kernel to 3.4.0 (from git)
Galapagos
- update system software
- update system kernel to 3.4.0 (from git)
Vega
- update system software
- update system kernel to 3.4.0 (from git)
Waitaha
- update system software
- downgrade system kernel to 3.4.0 (from git, to match remaining VMs/Servers)
- configure nagios monitoring
- configure backups
Other Servers
Agni
NOTE: After Scylla/Nebula
- update system to OpenBSD 5.2
- configure automatic encrypted backups
Betelgeuse
- Scrub nalgene and bubbles zpools
Dulles
- scrub skillet zpool(s) (See also, Seatac)
Fiordland
- reinstall fiordland as a testing Gentoo Hardened/SELinux Server
Littleblue
- install as a KVM VM Server
- configure nagios monitoring
- configure backups
Nebula
- finish configuring as slave KDC
- configure nagios monitoring
- configure automatic encrypted backups
Rockhopper
- update system software
- reinstall SPL/ZFS via portage (use latest Release Candidate)
- scrub guardian2 zpool
Royal
- scrub fryingpan and dutchoven zpools
Scylla
- update system to OpenBSD 5.2
- configure automatic encrypted backups
Seatac
- scrub skillet zpool(s) (See also, Dulles)
Weather
- update system software
VMs
bugs
- update system software
- update VM Kernel to enable memory ballooning
- update bugzilla software (via webapp)
casey
NOTE: casey should be removed from the mail.tjhsst.edu round-robin while being updated
- update system software
- update VM Kernel to enable memory ballooning
cups2
- update system software
- update VM Kernel to enable memory ballooning
haimageserver
- update system software
- update VM Kernel to enable memory ballooning
Iodine
- update VM Kernel to enable memory ballooning
- migrate VM to local storage on Galapagos</span
iodine-ldap (Andrew Hamilton)
- update system software
- update VM Kernel to enable memory ballooning
license
- update system software
- update VM Kernel to enable memory ballooning
- update mathlm licensing manager for Mathematica 9.0.1
lists
- reinstall system with Gentoo Linux
- migrate mailing lists/configurations to new system
monitor
- update system software
- update VM Kernel to enable memory ballooning
- configure update monitoring
mysql1
- update system software
- update VM Kernel to enable memory ballooning
ns1
- update system software
- update VM Kernel to enable memory ballooning
ns2
- update system software
- update VM Kernel to enable memory ballooning
openldap1
NOTE: openldap2 should hold the ldap-sun service IP while openldap1 is being updated
- update system software
- update VM Kernel to enable memory ballooning
openldap2
NOTE: openldap1 should hold the ldap-sun service IP while openldap2 is being updated
- update system software
- update VM Kernel to enable memory ballooning
openvpn
- update system software
- update VM Kernel to enable memory ballooning
smith
NOTE: smith should be removed from the mail.tjhsst.edu round-robin while being updated
- update system software
- update VM Kernel to enable memory ballooning
stage64
- update system software
- update VM Kernel to enable memory ballooning
www
- update system software
- update VM Kernel to enable memory ballooning
- update Roundcube (via webapp)
Other
Workstations
- update system software
- investigate ways to block user shutdowns
Nagios
- find/write a plugin to monitor physical server status (PSUs, HDDs, etc) via iLO/LOM
- Fix parent/child relationships
- Migrate legacy root diskspace checks to generic diskspace check
- remove retired/testing servers