User Tools

Site Tools


build:todo

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
Next revision Both sides next revision
build:todo [2005/09/10 11:25]
206.197.251.65
build:todo [2006/08/25 12:28]
151.145.63.122 Suggest mounting /var with noatime. (CMB)
Line 5: Line 5:
 ===== Commands ===== ===== Commands =====
  
-NOTE: Enter any command-line programs you want to install ​here.+(Enter any command-line programs you want to have installed ​here.)
  
 ===== Operating System ===== ===== Operating System =====
  
-Need to check for security updates regularlyMy thought on this is to run ''​apt-get update && apt-get --simulate upgrade''​ every dayand if it produces any output, send it to SYSADMIN. This way someone ​on the SYSADMIN list will go and run it manually if it needs it.+Need to configure all regular users(Actuallywe need to determine if regular users will have accounts ​on these boxes at all. But the answer ​will probably be yes.) If we do allow normal users, we need to transfer over the same UIDs and (shadow) passwords as the existing boxes (Michelob and Dark) use.
  
-Need to configure all regular users. (Actually, we need to determine if regular users will have accounts on these boxes at all.) If we do allow normal users, we need to transfer over the same UIDs and (shadowpasswords as the existing boxes (Michelob and Dark) use.+Need to fix server not shutting down properly. It hangs before finishing the shutdown process. (I believe this is fixedI rebooted ​the systems on 3/16/2006 using ''​init 6'' ​and they came back up just fine. -- Craig)
  
 +Need to fix the console not coming back up after it blanks out. May be APM power settings. (Our current kernel doesn'​t support APM.)
  
-Need to fix server not shutting down properly. ​It hangs before finishing ​the shutdown process.+It would probably be a good idea to mount the /var partition with the noatime flag.
  
-===== Firewall ​=====+===== Kernel ​=====
  
-I'm not sure if there's anything left to do on the firewall. We may need to open some more ports for new services.+We'd like to upgrade to a 2.6 kernel. We'd also like to compile a custom kernel, to remove ​some stuff we don't need and to get better support ​for some of the features of our systems --- such as APM.
  
-We definitely need to document how we configured the firewall. DONE on new system.+===== Firewall =====
  
 +We may need to open some more ports for new services, if we add any new services.
  
 ===== Email ===== ===== Email =====
  
-Outbound email seems to be working OK.+Outbound email seems to be working OK. Not anymore :( as of November 4, 2005. (CMB)
  
 Inbound SMTP seems to be working OK, but the hand-off to Cyrus seems to be broken. Inbound SMTP seems to be working OK, but the hand-off to Cyrus seems to be broken.
 +
 +Jeff Muse and Craig Buchek think we should switch to Courier IMAP. Cyrus isn't working, and there'​s better documentation for setting up Courier in a configuration similar to ours.
 +
 +We'll need to get mailing lists working on the new systems before we can migrate email.
  
 Lots of testing (via the test.sluug.org domain) will be required before we're ready to send production email to the new system. Lots of testing (via the test.sluug.org domain) will be required before we're ready to send production email to the new system.
Line 50: Line 56:
   * System Admin (like Webmin)   * System Admin (like Webmin)
  
-Before moving www.sluug.org and www.stllinux.org to the new system(s), we need to make sure that we've got all the old content moved over, and pages with all the same names that external sites are pointing at. To make sure, we need to monitor the Apache logs after moving over, to see what non-existant pages people are trying to access.+Before moving www.sluug.org to the new system(s), we need to make sure that we've got all the old content moved over, and pages with all the same names that external sites are pointing at. To make sure, we need to monitor the Apache logs after moving over, to see what non-existant pages people are trying to access.
  
  
Line 64: Line 70:
 ===== Routine Maintanence ===== ===== Routine Maintanence =====
  
-Need to frequently update packages that Debian updates due to security issues. +MySQL and PostgreSQL databases require periodic maintanence. For example, Matthew Porter recently explained how failure to VACUUM a PostgreSQL database will lead to very slow access times after about a month of moderate-heavy use.
- +
-MySQL and PostgreSQL databases require periodic maintanence. For example, Matthew Porter recently explained how failure to VACUUM a PostgreSQL database will lead to very slow access times after bout a month of moderate-heavy use.+
  
  
 ===== Redundancy ===== ===== Redundancy =====
  
-We'd really like to have 2 systems, so that we can fail over to a backup system if the primary fails. Each system ​would be doing its own thing under normal conditions. If one system ​were to fail, we'**manually** switch its functionality over to the other system.+We have 2 identical ​systems, so that we can fail over to a backup system if the primary fails. Each system ​will be doing its own thing under normal conditions. If one system ​happens ​to fail, we'll **manually** switch its functionality over to the other system. Mostly by pointing the DNS records for those services ​to the other system.
  
 ===== Misc ===== ===== Misc =====
  
 +We need to require a password for sudo for those who can run anything through sudo. 
 +For those who can only run a few commands, we can allow them to use sudo without a password.
  
 +We also need to set up restricted users in sudo, who can only run a few commands.
build/todo.txt · Last modified: 2007/06/13 15:26 by 206.197.251.253