7285
Comment:
|
6755
On second thought, call it IpAddresses
|
Deletions are marked like this. | Additions are marked like this. |
Line 3: | Line 3: |
To get the whole picture, also see pages ColocationNextSteps, SystemArchitecturePlans and NewSystemHardware. | [[TableOfContents]] |
Line 5: | Line 5: |
= Global TODO = | = Final preparations = |
Line 7: | Line 7: |
* Make ca@hcoop.net e-mail address working. It's the address that will be used in the certificate files. | See page NewServersSetup/FinalPreparations. = Special topic pages about migration and new set-up = * AndrewFileSystem: Using our new shared filesystem * BackupInfo: Information on how to recover deleted files from our off-site backups. * DaemonAdmin: Daemon-specific pages aimed at admins * DomTool: Administering and using the new domtool * IpAddresses: Listing of IPs that we use (nonpublic). * NewSystemHardware: Information on the new hardware * TaskDistribution: What each sysadmin is responsible for * SoftwareArchitecturePlans: Plans for software installation * SystemArchitecturePlans: Plans regarding our hardware * OnSiteStuff: Checklist for the next on-site visit to the new machines. * OneTimeCosts2007: Costs associated with the new servers through April 2007 * HcoopAddresses: Physical addresses relevant to us The following are outdated: * ColocationNextSteps: Listing of things to do after getting the hardware. = To-do list = These items should probably be in Bugzilla instead now. == During migration == * Unclaimed * Watchdog process to kill resource hogs * Fix resolv.conf on both servers to have multiple good DNS servers for now, set it to use localhost once BIND is running and configured. * Figure out how to use Dell OMSA or other tools to monitor RAID and other hardware. * Migrate ejabberd mnesia db just before the dns switchover. * Set up back-up regime, possibly using [http://rsync.net/ rsync.net]. * Get miscellaneous web stuff ported, like membership application, vmail password change, publicly-viewable statistics on membership, bandwidth usage stats, .... * Do performance testing on the new configuration, by having admins or other users monitor performance on mire (using vmstat, top, mytop, etc) and having one or more (perhaps multi-threaded) scripts requesting web pages from somewhere off of the Peer 1 network. * ntk * Mailman * (Status) The exim side of things has been mostly set up. I think I migrated the non-exim stuff as well, but will need to double-check. --MichaelOlson * Migrate lists. * Reboot mire while on-site to watch for slow boot issues that should be resolved with recent changes * mwolson * Run simple tests on cron to see if it works. * AdamMegacz * Setup Sun Netra ("Krunk") to be secondary KDC+AFS server |
Line 12: | Line 55: |
* To connect to hcoop's ldap server using ''gq'', create a SSH tunnel: ''' ssh -p 2222 -f -N -L 389:localhost:389 USERNAME@69.90.123.51''', and then connect to ''localhost:389'' in ''gq''. | * To connect to hcoop's ldap server using ''gq'', create a SSH tunnel: ''' ssh -f -N -L 389:localhost:389 USERNAME@deleuze.hcoop.net''', and then connect to ''localhost:389'' in ''gq''. * For the description of the actual authentication scheme, see AuthenticationScheme. |
Line 14: | Line 58: |
= Deleuze = | = Tasks done = == Deleuze == |
Line 17: | Line 63: |
== Tasks done == |
|
Line 35: | Line 79: |
* Install MySQL and PostgreSQL (input from AFS step and admin discussion needed to see how to exactly configure this). * Install BIND. * Install and configure Apache, to serve static web content only. --MichaelOlson * Review kernel configuration and install testnet. -- DavorOcelic * Configure exim4. --MichaelOlson * Configure Courier IMAP daemons, reviewing fyodor's config. --MichaelOlson * Migrate squirrelmail configuration settings from fyodor. * Configure Squirrel``Mail to use imapproxyd, which should give speed improvements once we migrate to deleuze. --MichaelOlson * Exim filters * (a method has been set up by MichaelOlson, but it needs testing). * DNS server * Works on deleuze, although I will test once more domains have been migrated for reasonable domain defaults --JustinLeitgeb * nscd process for name caching * Currently this processes is set to do hostname caching on deleuze, so bind will not be set up as a caching name server --JustinLeitgeb * Get exim working on mire --MichaelOlson * Upgrade deleuze to debian etch --MichaelOlson * Install denyhosts on both deleuze and mire, needs debian etch --MichaelOlson * Switch ssh on deleuze to listen to port 22, needs denyhosts --MichaelOlson * Perform testing on procmail and exim filter on deleuze. --MichaelOlson * Make ca@hcoop.net e-mail address working. It's the address that will be used in the certificate files. --MichaelOlson * Make sure somebody is reading mail sent to abuse@hcoop.net so we don't wind up on lame DNSBLs. * Review apache configuration on mire. --MichaelOlson * Make /afs/hcoop.net/common/etc/scripts/apache-sync-logs work. --Megacz |
|
Line 36: | Line 103: |
== TODO == | == Mire == |
Line 38: | Line 105: |
In order of implementation (soonest first): | * Installed new second SCSI hard drive, reinstalled debian, and configured the drives with software RAID-1. --NathanKennedy * Configured Mire to work as a proper krb/ldap/afs client machine. --DavorOcelic |
Line 40: | Line 108: |
* Fix resolv.conf on both servers to have multiple good DNS servers for now, set it to use localhost once BIND is running and configured. * Install MySQL and PostgreSQL (input from AFS step and admin discussion needed to see how to exactly configure this) -- DavorOcelic * Install BIND -- DavorOcelic * Review kernel configuration and install testnet. -- DavorOcelic * Install and configure Apache, to serve static web content only. --MichaelOlson * Get domtool2 working (this to be done concurrent with mire). * Figure out how to use Dell OMSA or other tools to monitor RAID and other hardware. == Problems == * With ''debsums'', once you break md5sum of a config file, the file keeps being reported as mismatching even if you completely regenerate md5sums for a package!! -- DavorOcelic * The logical volume for /dev/sdb is supposed to be a 4-drive raid array, each drive ~73GB. Right now it seems to be configured as RAID1 mirroring the two drives, for a capacity of ~146G (see dmesg, for instance). This would be faster and the volume would be 73G bigger if it was set up as RAID5. I might need to do this from console, and I need to talk to Justin about it, since he set up the logical volumes and I thought he said that sdb was RAID5. --NathanKennedy * Spoke to Justin about this. Nonproblem--it is RAID10 and intended to be so. I will let admins decide the merits of RAID5 vs. RAID10. --NathanKennedy == Authentication scheme explained == Regarding the exact authentication mechanism on HCoop: We have Kerberos and LDAP working. Kerberos holds user "principals" (account names + passwords), while LDAP keeps account names plus everything else (such as UIDs, GIDs, home directories, real names, permissions etc.). General policy is: all users have LDAP accounts and a Kerberos principal. Admins have passwd file account and a Kerberos principal. When needed, admins can also create a pure local-files-based account. The whole authentication work is performed though a series of PAM (Pluggable Authentication Modules) configuration directives. PAM has four "management groups", listed in most-common order of execution: auth, account, session, and password. (The exact order of execution is controlled by the order of lines in /etc/pam.d/* files, with each file corresponding to a particular service). * Auth is concerned with actual username/password verification in the database. In our setup, when users type in the password, it is verified against the Kerberos database. If three attempts are unsuccessful, another prompt is displayed, allowing a user to enter Unix passwd file password. (Only administrators who create a local account would have one). Then, pam_env is invoked, which reads ''/etc/security/pam_env.conf''. That way you can initialize environment variables in the user session. * Account checks things like password aging etc. If the user has an LDAP account, then the Kerberos account module is invoked which checks for the list of allowed principals in ''~/.k5login''. Users with no LDAP account are just checked in the local password files. Then, pam_access is invoked, which reads ''/etc/security/access.conf''. That way you can determine which users (and from where) are allowed to log in. * Session sets up session details. First pam_limits is invoked, imposing limits on users as defined in ''/etc/security/limits.conf''. Then pam_krb5 is invoked which will only succeed if the user has a Kerberos principal. (If it has, it initializes the TGT ticket for them automatically). And then, finally, pam_unix_session is called which just logs session creation (and later session termination) to system log files. At that point, users are logged in. * Password is the management group involved only in changing the password (or whatever the authentication mechanism is). Currently, by default, Kerberos password is changed. Running '''kpasswd''' will change the Kerberos password; running '''passwd''' will change the local-files password, and will only work for people with pure local accounts. |
== Krunk == |
Line 69: | Line 112: |
* DomtoolTwo (Adam, will it be possible to change/modify support requests from the command line? Also, it would be so "candy" if the messages regarding ticket status were sent as followups to the original request email, not as completely separate mails). -- DavorOcelic | * DomtoolTwo |
Line 72: | Line 115: |
* Watchdog process to kill resource hogs These are my responsibility. Right now, I'm waiting for the more traditional stuff to be set up and stable before beginning. --AdamChlipala = Mire = == Tasks done == * Installed new second SCSI hard drive, reinstalled debian, and configured the drives with software RAID-1. --NathanKennedy |
1. Introduction
2. Final preparations
See page NewServersSetup/FinalPreparations.
3. Special topic pages about migration and new set-up
AndrewFileSystem: Using our new shared filesystem
BackupInfo: Information on how to recover deleted files from our off-site backups.
DaemonAdmin: Daemon-specific pages aimed at admins
DomTool: Administering and using the new domtool
IpAddresses: Listing of IPs that we use (nonpublic).
NewSystemHardware: Information on the new hardware
TaskDistribution: What each sysadmin is responsible for
SoftwareArchitecturePlans: Plans for software installation
SystemArchitecturePlans: Plans regarding our hardware
OnSiteStuff: Checklist for the next on-site visit to the new machines.
OneTimeCosts2007: Costs associated with the new servers through April 2007
HcoopAddresses: Physical addresses relevant to us
The following are outdated:
ColocationNextSteps: Listing of things to do after getting the hardware.
4. To-do list
These items should probably be in Bugzilla instead now.
4.1. During migration
- Unclaimed
- Watchdog process to kill resource hogs
- Fix resolv.conf on both servers to have multiple good DNS servers for now, set it to use localhost once BIND is running and configured.
- Figure out how to use Dell OMSA or other tools to monitor RAID and other hardware.
- Migrate ejabberd mnesia db just before the dns switchover.
Set up back-up regime, possibly using [http://rsync.net/ rsync.net].
- Get miscellaneous web stuff ported, like membership application, vmail password change, publicly-viewable statistics on membership, bandwidth usage stats, ....
- Do performance testing on the new configuration, by having admins or other users monitor performance on mire (using vmstat, top, mytop, etc) and having one or more (perhaps multi-threaded) scripts requesting web pages from somewhere off of the Peer 1 network.
- ntk
- Mailman
(Status) The exim side of things has been mostly set up. I think I migrated the non-exim stuff as well, but will need to double-check. --MichaelOlson
- Migrate lists.
- Reboot mire while on-site to watch for slow boot issues that should be resolved with recent changes
- Mailman
- mwolson
- Run simple tests on cron to see if it works.
- Setup Sun Netra ("Krunk") to be secondary KDC+AFS server
5. Global Notes
To edit LDAP database from a GUI tool, use gq program
To connect to hcoop's ldap server using gq, create a SSH tunnel: ssh -f -N -L 389:localhost:389 USERNAME@deleuze.hcoop.net, and then connect to localhost:389 in gq.
For the description of the actual authentication scheme, see AuthenticationScheme.
6. Tasks done
6.1. Deleuze
This machine donated by Justin Leitgeb seems real nice. Buffered disk throughput is about 1.5 GB/s. Raw disk reads are 60 MB/s for the two 36 GB disks and 120 MB/s for the 4-disk array. Not bad at all.
- Removed excessive packages, cleaned up the system
Installed changetrack to monitor all config file changes. The program uses rcs and automatically keeps previous revisions. It is ran from cron on a daily basis.
Installed debsums to monitor file md5sums
- Installed Courier IMAP and IMAP-SSL
Installed LDAP for user authentication. The system is currently configured to use LDAP and fallback to the usual /etc/ files. Admin users will be added locally on all machines and will be able to log in even when LDAP is not operational.
- Installed MIT Kerberos 5
Fixed date/time on the system. Installed ntpd
Installed TLS support for LDAP. Certificate file is /etc/ldap/server.pem, and ldap/ldaps ports are 389/636.
- Installed Linux 2.6.18.3-grsec with 2.6.18-mm3 patches (2) for megaraid.
The patches and source tree installed, along with the .deb generated, is under /usr/src/ntk2. I set up sockets groups as on fyodor (7070-7072). SMP, with hyperthreading enhancements, is enabled. I also installed a bunch of packages that someone were uninstalled while I was gone (e.g., gcc). I also fixed the sudoers, wheel group, and admin home directories. --NathanKennedy
- Kerberos + LDAP works.
Compiled requisite kernel modules, compiled and installed new OpenIPMI package, and installed dellomsa. Dell OMSA is now working. --NathanKennedy
- Install SSH.
- Permit new admins to log in by copying their SSH keys to their newly-created (empty) home directories.
Install AFS (need to repeat the reading on AFS and how it really works. Also it will influence the decision how to format /dev/sdb in the system) -- DavorOcelic
- Install MySQL and PostgreSQL (input from AFS step and admin discussion needed to see how to exactly configure this).
- Install BIND.
Install and configure Apache, to serve static web content only. --MichaelOlson
Review kernel configuration and install testnet. -- DavorOcelic
Configure exim4. --MichaelOlson
Configure Courier IMAP daemons, reviewing fyodor's config. --MichaelOlson
- Migrate squirrelmail configuration settings from fyodor.
Configure SquirrelMail to use imapproxyd, which should give speed improvements once we migrate to deleuze. --MichaelOlson
- Exim filters
(a method has been set up by MichaelOlson, but it needs testing).
- DNS server
Works on deleuze, although I will test once more domains have been migrated for reasonable domain defaults --JustinLeitgeb
- nscd process for name caching
Currently this processes is set to do hostname caching on deleuze, so bind will not be set up as a caching name server --JustinLeitgeb
Get exim working on mire --MichaelOlson
Upgrade deleuze to debian etch --MichaelOlson
Install denyhosts on both deleuze and mire, needs debian etch --MichaelOlson
Switch ssh on deleuze to listen to port 22, needs denyhosts --MichaelOlson
Perform testing on procmail and exim filter on deleuze. --MichaelOlson
Make ca@hcoop.net e-mail address working. It's the address that will be used in the certificate files. --MichaelOlson
Make sure somebody is reading mail sent to abuse@hcoop.net so we don't wind up on lame DNSBLs.
Review apache configuration on mire. --MichaelOlson
- Make /afs/hcoop.net/common/etc/scripts/apache-sync-logs work. --Megacz
6.2. Mire
Installed new second SCSI hard drive, reinstalled debian, and configured the drives with software RAID-1. --NathanKennedy
Configured Mire to work as a proper krb/ldap/afs client machine. --DavorOcelic
6.3. Krunk
7. Custom software
- Vmail tools
- Web portal