CS SysAdmin

A while ago, we got a note from Lyn saying that he had detected some inconsistencies in the groups on Puma and Tempest, and he claimed responsibility for some of them:

On tempest, the last few entries of /etc/group are:
efusco:x:5450:
stapsys:x:157:
events:x:5451:
cs110s12:x:5452:
mensam:x:5453:
mokeefe2:x:5454:
xlu2:x:5455:
cs304s11:x:5456:
mseger:x:5457:
cs342pri:x:5458:cs342,fturbak
cs342stu:x:5459:cs342,fturbak,gdome
cs342web:x:5460:cs342,apache,fturbak

On puma they're
efusco:x:5450:
efusco:x:5450:
events:x:5451:
appinv-stats:x:5452:
cs117:x:5125:
cs110s12:x:5452:
mensam:x:5453:
mokeefe2:x:5454:
xlu2:x:5455:
cs304s11:x:5456:
mseger:x:5457:

I'm at fault for some of these. I added appinv-stats on puma near the end of 
July (didn't know it was supposed to be added on tempest).

Today, I added the new cs342 groups to tempest, but they didn't propagate to puma. 
The fact that appinv-stats and cs110s12 share the same group ID is gonna cause problems. 
Sorry, my bad. 

Okay, we have several issues here, so let’s see what they are:

• The /etc/group files on Puma and Tempest are going to differ in some of their system entries, at least until we get these more in sync.
• Update LDAP as well
• We need to renumber the group for cs110s12, but that won’t be too hard
• We should take this opportunity to clean things up a bit.

I used the “grpck” command on Tempest to clean the /etc/group file up a bit.  It detected some duplicate lines and some missing accounts (e.g. cwhitetake is not a valid account, but she was listed in the accounts for cs235stu:

cs235stu:x:4012:adaigle,atang,choover,clui,cs235,cvaldes,cwhitetake,fturbak,gdome,gwunnava,kneugent,mmiranda,rshull,sfinn,shamilto,skim17,ustutsma,aahiable,cboes,dbullist,kchadha,lchoe,tfeng,mferreir,ggoodwin,cgrote,jhan,lhelm,dkim5,mligon,lrigge,lristovs,asandu,mvasek,evuksani,hwang2,swu

Before letting grpck removed duplicate lines, I wanted to see what they were, so I used the following command:

[root@puma ~] cut -d: -f1 /etc/group | sort | uniq -d
bin
disk
efusco
news
quaggavty
slocate
tomcat

Is there any disagreement or are these perfect duplicates?

[root@puma ~] sort /etc/group | uniq -d
bin:x:1:daemon,root
disk:x:6:root,
efusco:x:5450:
news:x:13:
quaggavty:x:103:
slocate:x:21:
tomcat:x:102:

Having satified myself that it’s okay, I run “grpck:”

[root@puma ~] grpck 
duplicate group entry
delete line 'bin:x:1:daemon,root'? y
duplicate group entry
delete line 'bin:x:1:daemon,root'? y
duplicate group entry
delete line 'disk:x:6:root'? y
duplicate group entry
delete line 'disk:x:6:root,'? y
duplicate group entry
delete line 'news:x:13:'? y
duplicate group entry
delete line 'slocate:x:21:'? y
duplicate group entry
delete line 'tomcat:x:102:'? y
duplicate group entry
delete line 'quaggavty:x:103:'? y
group faculty: no user emustafa
delete member 'emustafa'? y
group cs235stu: no user cwhitetake
delete member 'cwhitetake'? y
duplicate group entry
delete line 'efusco:x:5450:'? y
invalid group file entry
delete line ''? y
grpck: the files have been updated
[root@puma ~]

Now, let’s compare the /etc/group on the two machines.

[root@puma ~] sort -n -t: -k3 /etc/group > /etc/group.sorted
[root@puma ~] sort -n -t: -k3 /etc/group.tempest > /etc/group.sorted.tempest
[root@puma ~] diff /etc/group.sorted /etc/group.sorted.tempest 
2c2
< bin:x:1:daemon,root
---
> bin:x:1:root,bin,daemon
7c7
< disk:x:6:root,
---
> disk:x:6:root
12c12,13
< mail:x:12:mail
---
> cdrom:x:11:
> mail:x:12:mail,postfix
16a18
> dialout:x:18:
21d22
< squid:x:23:
26a28
> tape:x:33:
28c30
< rpm:x:37:
---
> kvm:x:36:qemu
29a32
> video:x:39:
32d34
< xfs:x:43:
39,41c41,42
< audio:x:63:gdm
< webalizer:x:67:
< haldaemon:x:68:
---
> audio:x:63:
> haldaemon:x:68:haldaemon
43a45
> tcpdump:x:72:
45c47,48
< pcap:x:77:
---
> radvd:x:75:
> saslauth:x:76:
47,48c50,52
< sabayon:x:86:
< distcache:x:94:
---
> postfix:x:89:
> postdrop:x:90:
> hsqldb:x:96:
53,55c57,58
< stapdev:x:104:
< stapusr:x:105:
< avahi-autoipd:x:106:
---
> qemu:x:107:
> usbmuxd:x:113:
57c60,74
< nagios:x:399:
---
> stapsys:x:157:
> avahi-autoipd:x:170:
> abrt:x:173:
> mongod:x:489:
> fuse:x:490:
> stapusr:x:491:
> stapdev:x:492:
> pulse-access:x:493:
> pulse:x:494:
> cgred:x:495:
> qpidd:x:496:
> rtkit:x:497:
> desktop_user_r:x:498:
> desktop_admin_r:x:499:
> admin:x:500:
1686d1702
< appinv-stats:x:5452:
1692a1709,1711
> cs342pri:x:5458:cs342,fturbak
> cs342stu:x:5459:cs342,fturbak,gdome
> cs342web:x:5460:cs342,apache,fturbak
[root@puma ~]

For now, I’m going to ignore the minor differences, though it would be nice for them to be entirely eliminated. But what happened to cs110s12?

root@puma ~] grep cs110s12 /etc/group.sorted 
cs110s12:x:5452:
[root@puma ~] grep cs110s12 /etc/group.sorted.tempest 
cs110s12:x:5452:
[root@puma ~]

Oh, since it’s in both, it doesn’t show up in the diff.  the appinv-stats group is *extra*. We could re-number it, but we’d have to worry about files whose GID needs to be changed, and I don’t know where all those files are.  We could find them like this:

[root@tempest ~]# find / -gid 5452 -ls

But that will take *forever*.  In this case, we’re lucky that we know the cs110s12 group is only in /home/cs110s12, so we can renumber those files and folders.  I have a script for this in /root/ldapscripts/user-renumber

In the future, I think we need a wrapper of groupadd on Tempest to migrate the new groups to LDAP and to puma.  For now, I think we’ll use the /root/ldapscripts/ldap-resolve-differences.pl

Sigh. Still lots of differences, many of which are spurious.  We might replace the original files with numerically sorted ones.

Note: this blogpost contains notes on several scripts, and is for reference for current or future student sysadmins so that Prof. Anderson won’t have to reexplain these scripts.

“useradd fbaggins” will add files to /etc/passwd and /etc/group, which are “flat” files, but will not update LDAP. The issue we have is that build-in tools for account management, such as useradd, passwd, chsh, etc. will update flat files, but not LDAP files. We want to update LDAP files, too!

A while ago, if an ordinary user changed their password with passwd, their password would have been changed on LDAP. But this is no longer the case.

Here are our scripts:

• password-change
• useradd-students
• ldapaddpasswordentries

For CS classes, after a user fills out the form, a line is added to /tmp/cs110-fall-2012. For example, if Sam Smith fills out the CS form, the following line may be added to /tmp/…:

domain_name   passwd   full name      usage agreement
sam                     123ok     Sam Smith   yes                          scponly
*If “sam” is not the user’s domain name, there will be problems later in the script.
** Backups of student passwords are located in /root/acctmp/all.

Next, an admin runs the useradd-students script. This creates an account in /etc/accounts/[coursename].  The script chooses a GID and UID for the new account, creates a home directory fo the user and populates it with files (a recursive copy of /etc/skul). The flat files are also updated. (Note that a “snapshot” is taken before updating the flat files so that the program knows which new user entries to add to the database, etc.)

Old users are also processed through useradd-students, which is useful for cases such as when former CS110 students take CS111, etc.

The useradd-students script sets quotas for new users, checks what course a user is in and creates the appropriate drop folders, and eventually emails the user that her account is ready. After looping through all users, the program compares “snapshots” and migrates the new users over to LDAP, putting skipped entries in a skipped file.

We used to only move things to LDAP; flat files used to be removed. Now, however, files are kept in both places.

Now let’s talk about the script (create-course-drop-folders-1) to create drop folders for one user, for instance a user who didn’t sign up and get processed with everyone else (create-coursename-drop-folders is the script for that, and the one that should be used in general). The ownership of the folder is changed to the owner and the course; set-gid ensures that files added to this folder are put in the course group too. This script should not be used much since normally drop folders are created in batches for a class of students.

Next week we’ll be talking about renaming accounts, which is easy to do in flat files but hard in LDAP. We’re talking about this in the first place because of recent problems with passwd-change. Flat and LDAP files are changing on tempest, but not on puma.

I’m again trying to get LDAP to work, instead of having to copy around flat files.  Today I used

authconfig –savebackup=name

which writes out a directory in /var/lib/authconfig/name of all the files involved with authentication.  I did that on both Sampras (F14 client that successfully uses LDAP) and thrush (CentOS client that doesn’t successfully use LDAP).  When I discovered today that Sampras has an /etc/nss_ldap.conf file that Thrush lacks, I felt like I was onto something.

I found this post: https://www.centos.org/modules/newbb/viewtopic.php?topic_id=32402 it mentioned that there have been some renaming of files even in different versions of CentOS.  *sigh*. I did

[root@sampras] rpm -qf /etc/nss_ldap.conf 
nss_ldap-265-6.fc14.i686

but no such package exists for CentOS.  Much discouragement.  However, that site mentioned files such as /etc/pam_ldap.conf, which Thrush also lacks.  So I did

[root@thrush ~] yum whatprovides /etc/pam_ldap.conf
Loaded plugins: fastestmirror, refresh-packagekit, security
Loading mirror speeds from cached hostfile
pam_ldap-185-11.el6.i686 : PAM module for LDAP
Repo        : base
Matched from:
Filename    : /etc/pam_ldap.conf

[root@thrush ~] rpm -q pam_ldap
package pam_ldap is not installed
[root@thrush ~] yum -y install pam_ldap
Running Transaction
Warning: RPMDB altered outside of yum.
  Installing : pam_ldap-185-11.el6.i686                                                                           1/1 
  Verifying  : pam_ldap-185-11.el6.i686                                                                           1/1 

Installed:
  pam_ldap.i686 0:185-11.el6                                                                                          

Complete!
[root@thrush ~]

Okay, that’s interesting.  The guy in the post said he just made his /etc/pam_ldap.conf file be a symlink to /etc/openldap/ldap.conf, so I’ll try that:

root@thrush etc] mv pam_ldap.conf pam_ldap.conf.orig
[root@thrush etc] ln -s /etc/openldap/ldap.conf pam_ldap.conf
[root@thrush etc] ls -l pam_ldap.conf
lrwxrwxrwx 1 root root 23 Sep  3 21:51 pam_ldap.conf -> /etc/openldap/ldap.conf
[root@thrush etc]

Okay, let’s try undoing the account files and rebooting (‘cuz I don’t know what services need to be restarted for ldap/pam/etc):

[root@thrush etc] /usr/network/fixes/account-files-undo
[root@thrush etc] w
 21:54:55 up 4 days, 12:12,  1 user,  load average: 0.00, 0.00, 0.00
USER     TTY      FROM              LOGIN@   IDLE   JCPU   PCPU WHAT
root     pts/2    tempest.wellesle 21:45    0.00s  0.03s  0.00s w
[root@thrush etc] reboot
Broadcast message from root@thrush.wellesley.edu
    (/dev/pts/2) at 21:55 ...

The system is going down for reboot NOW!
[root@thrush etc] Connection to thrush closed by remote host.
Connection to thrush closed.
[root@tempest tmp]#

Okay, let’s try:

[root@tempest tmp]# ssh thrush
Last login: Mon Sep  3 21:45:41 2012 from tempest.wellesley.edu
[root@thrush ~] getent passwd anderson
anderson:*:716:501:Scott D. Anderson,E114:/home/anderson:/bin/bash
[root@thrush ~] logout
Connection to thrush closed.
[root@tempest tmp]# ssh anderson@thrush
anderson@thrush's password: 
Permission denied, please try again.
anderson@thrush's password: 
Permission denied, please try again.
anderson@thrush's password:

Nope.  Still no luck.

root@thrush ~] authconfig --savebackup=thrush2
[root@thrush ~] diff -qr /var/lib/authconfig/backup-thrush2 /usr/network/tmp/backup-sampras/
Files /var/lib/authconfig/backup-thrush2/authconfig and /usr/network/tmp/backup-sampras/authconfig differ
Files /var/lib/authconfig/backup-thrush2/fingerprint-auth-ac and /usr/network/tmp/backup-sampras/fingerprint-auth-ac differ
Files /var/lib/authconfig/backup-thrush2/login.defs and /usr/network/tmp/backup-sampras/login.defs differ
Files /var/lib/authconfig/backup-thrush2/network and /usr/network/tmp/backup-sampras/network differ
Only in /usr/network/tmp/backup-sampras/: nss_ldap.conf
Files /var/lib/authconfig/backup-thrush2/nsswitch.conf and /usr/network/tmp/backup-sampras/nsswitch.conf differ
Files /var/lib/authconfig/backup-thrush2/openldap.conf and /usr/network/tmp/backup-sampras/openldap.conf differ
Files /var/lib/authconfig/backup-thrush2/pam_ldap.conf and /usr/network/tmp/backup-sampras/pam_ldap.conf differ
Only in /usr/network/tmp/backup-sampras/: pam_pkcs11.conf
Files /var/lib/authconfig/backup-thrush2/password-auth-ac and /usr/network/tmp/backup-sampras/password-auth-ac differ
Files /var/lib/authconfig/backup-thrush2/smartcard-auth-ac and /usr/network/tmp/backup-sampras/smartcard-auth-ac differ
Files /var/lib/authconfig/backup-thrush2/smb.conf and /usr/network/tmp/backup-sampras/smb.conf differ
Files /var/lib/authconfig/backup-thrush2/system-auth-ac and /usr/network/tmp/backup-sampras/system-auth-ac differ
[root@thrush ~]

Okay, I’ve looked at all these differences and haven’t seen anything that seem significant.  One possibility is that password-auth-ac has pam_ldap.so on sampras, while thrush has pam_sss.so.  But I thought that CentOS is using sssd instead of ldap.  Heck, it’s worth a try.

[root@thrush pam.d] cd /etc/pam.d
[root@thrush pam.d] cp password-auth-ac password-auth-ac.orig
[root@thrush pam.d] cp /usr/network/tmp/backup-sampras/password-auth-ac .
cp: overwrite `./password-auth-ac'? y
[root@thrush pam.d] diff password-auth-ac password-auth-ac.orig 
7c7
< auth        sufficient    pam_ldap.so use_first_pass
---
> auth        sufficient    pam_sss.so use_first_pass
13c13
< account     [default=bad success=ok user_unknown=ignore] pam_ldap.so
---
> account     [default=bad success=ok user_unknown=ignore] pam_sss.so
18c18
< password    sufficient    pam_ldap.so use_authtok
---
> password    sufficient    pam_sss.so use_authtok
23d22
< -session     optional      pam_systemd.so
26c25
< session     optional      pam_ldap.so
---
> session     optional      pam_sss.so
[root@thrush pam.d]

Here go ‘nuthin.  I rebooted and:

[root@thrush ~] getent passwd anderson
anderson:*:716:501:Scott D. Anderson,E114:/home/anderson:/bin/bash
[root@thrush ~] logout
Connection to thrush closed.
[root@tempest tmp]# ssh anderson@thrush
anderson@thrush's password: 
Last login: Tue Aug 28 16:17:10 2012 from localhost
[anderson@thrush ~] grep anderson /etc/passwd
[anderson@thrush ~]

Holy moly!  It *worked*!

Okay, now I’m trying to replicate that on Robin.  I saved the authconfig to /usr/network/scripts/authconfig-CentOS-client/  and wrote /usr/network/scripts/authconfig-CentOS.sh

On Robin, I ran

/usr/network/fixes/account-files-undo
/usr/network/scripts/authconfig-CentOS.sh
reboot

That didn’t work. Turns out sssd wasn’t running.  So, start that.  Nope.  Oh, it complains that the perms on /etc/sssd/sssd.conf aren’t right.  Need to be 660.  Compared the /etc/pam.d/password-auth-ac files; made sure they were the same. Nope.  In fact, I can find no differences in the authconfig files.

Compared the list of rpms. There are a lot of differences!  How does this happen?  Noticed that Thrush (working) had pam_ldap installed but Robin (not working) doesn’t.  That’s interesting!

Ah ha!  That’s it!  I can now run

ssh bird "/usr/network/fixes/account-files-undo ; /usr/network/scripts/authconfig-CentOS.sh yes"

I didn’t want to use all-centos-hosts because I wanted to keep thrush working, just in case.

When a student signs up for 230, she may already have a server account (if she took cs111) or not (if she placed out of cs111).  Thus, they fill out a form that asks whether the account exists or not.

If it exists, it will have been created with the shell as /usr/local/bin/scponly, and that needs to be changed to /bin/bash

The existing useradd_ldap script does change the shell, but only in LDAP, since it calls ldapchsh.pl.  Since we’re using the flat files, we need to *also* change it in /etc/passwd using the built-in chsh command.

Towards that end, I wrote ldapscripts/chsh-both, which just calls both commands.

I tested to see if it was necessary, using incantations like this:

[root@tempest tmp]# for acct in `cat cs230-2012-fall-saved-version* | cut -f1`; do echo $acct; done
mfeldman
egrandje
vbrown
glanza
vlin
choef
...

To see what their login shell is on Tempest:

[root@tempest tmp]# for acct in `cat cs230-2012-fall-saved-version* | cut -f1`; do getent passwd $acct; done
mfeldman:x:5159:5163:Monica Starr Feldman class of Class of 2014:/students/mfeldman:/usr/local/bin/scponly
egrandje:x:5276:5280:Emily Grandjean class of 2015:/students/egrandje:/usr/local/bin/scponly
vbrown:x:5277:5281:Victoria Brown class of 2015:/students/vbrown:/usr/local/bin/scponly
glanza:x:5217:5221:Gabriela Alicia Lanza Class of 2014:/students/glanza:/usr/local/bin/scponly
vlin:x:5178:5182:Veronica Lin class of 2015:/students/vlin:/bin/bash
mokeefe2:x:5454:5454:Margaret O'Keefe class of 2016:/students/mokeefe2:/bin/bash
xlu2:x:5455:5
...

Some are /bash, but most, as expected, are scponly.  The bash ones are probably new accounts.  Here are the LDAP entries:

[root@tempest tmp]# for acct in `cat cs230-2012-fall-saved-version* | cut -f1`; do ldapsearch -x "uid=$acct" | grep loginShell ; done
loginShell: /bin/bash
loginShell: /bin/bash
loginShell: /usr/local/bin/scponly
loginShell: /bin/bash
loginShell: /bin/bash
loginShell: /usr/local/bin/scponly
loginShell: /bin/bash
loginShell: /bin/bash
...

Hmm. I wonder which are scponly?

for acct in `cat cs230-2012-fall-saved-version* | cut -f1`; do echo -n $acct; ldapsearch -x "uid=$acct" | grep loginShell ; done | grep scponly
ckeungloginShell: /usr/local/bin/scponly
elinloginShell: /usr/local/bin/scponly
[root@tempest tmp]#

Ah, right.  These two didn’t get their shells changed because I removed them from the list of accounts (bad passwords).  That was actually an error, since the password is ignored if the account exists.  (We need to modify the form to clarify that.)

Instead of looking at those files, I should look at /etc/accounts/cs230-2012-fall:

[root@tempest tmp]# for acct in `cut -f1 /etc/accounts/cs230-2012-fall `; do ldapsearch -x "uid=$acct" | grep loginShell; done
loginShell: /bin/bash
loginShell: /bin/bash
loginShell: /bin/bash
loginShell: /bin/bash
loginShell: /bin/bash
...

Much better.  Okay, let’s change their shells:

[root@tempest tmp]# for acct in `cut -f1 /etc/accounts/cs230-2012-fall `; do echo chsh -s /bin/bash $acct; donechsh -s /bin/bash mfeldman
chsh -s /bin/bash egrandje
chsh -s /bin/bash vbrown
chsh -s /bin/bash glanza
chsh -s /bin/bash vlin

That was just double-checking before I do anything that modifies the system.  Now:

[root@tempest tmp]# for acct in `cut -f1 /etc/accounts/cs230-2012-fall `; do chsh -s /bin/bash $acct; done
Changing shell for mfeldman.
Shell changed.
Changing shell for egrandje.
Shell changed.
Changing shell for vbrown.
Shell changed.
Changing shell for glanza.
Shell changed.
Changing shell for vlin.
...

Good!  That should take care of the problem.  I’ve modified useradd_students to use the new script, which is:

[root@tempest tmp]# cat /root/ldapscripts/chsh-both 
#!/bin/bash

# Change the shell in both the flat files and in LDAP

if [ $# -eq 0 ]; then
   echo "Usage: $0 shell username(s)"
   exit
fi

shell=$1
shift

grep $shell /etc/shells > /dev/null
if [ $? -ne 0 ]; then
    echo "$shell not found in /etc/shells. Please check your syntax. First arg is a shell"
    exit
fi

# First change the LDAP shell, since we will consume our args in the for loop

/root/ldapscripts/ldapchsh.pl $shell $*

# Now, iterate over the list and change the shell in /etc/passwd

for username in $*; do
    /usr/bin/chsh -s $shell $username
done

The goal here is to get our PHP scripts from Puma working on Tempest.  We want the PHP modules on Tempest to duplicate those on Puma, so that all the PHP scripts will run correctly.  We also need to check on the php.ini file and any other configuration info.

I intended to copy the /etc/php.ini file from puma, but that one is for an older version of PHP, so I think it will make more sense to edit the copy on Tempest. As with httpd.conf and such, I’m going to put our master copy in /home/sysadmin/etc/php.ini and use the new update-etc-file to maintain the one on Tempest.

I made two modifications to /etc/php.ini:

[root@tempest conf.d]# diff /etc/php.ini /etc/php.ini.orig 
530,533c530
< ; Wellesley modification
< ; display_errors = Off
< display_errors = On
< 
---
> display_errors = Off
685,687c682
< ; Wellesley Mod.  I think this means cookies override GET and POST, not vice versa
< ; request_order = "GP"
< request_order = "GPC"
---
> request_order = "GP"

Okay, now I had installed MDB2, but when I run, for example, http://tempest.wellesley.edu/~sysadmin/sysadmin/machines-dump.php I’m getting:

Error while connecting : MDB2 Error: not found

I’m not sure what’s causing that.  If I run PHP and the script from the command line, what do I get?

[root@tempest conf.d]# cd /home/sysadmin/public_html/sysadmin/
[root@tempest sysadmin]# php machines-dump.php 
<html>
<head>
<title>CS Department Machines</title>
</head>

<body bgcolor="white">

<p><strong>Failed on query 
<q>SELECT name,location,status,repl,sn,hwaddr,model,ip,misc FROM machines 
WHERE status <> 'dead' ORDER BY name,name ASC</q> 
with error message: MDB2 Error: connect failed</strong>
[root@tempest sysadmin]#

Okay, so it’s not that the MDB2 module is missing; it’s not able to connect to the database.  The MDB2-functions and sysadmin-dsn.inc files are there.  Let’s try connecting by hand:

[root@tempest sysadmin]# mysql -u sysadmin
ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (111)
[root@tempest sysadmin]# service mysqld status
mysqld is stopped
[root@tempest sysadmin]# chkconfig mysqld --list
mysqld             0:off    1:off    2:off    3:off    4:off    5:off    6:off
[root@tempest sysadmin]#

Oh, well, that’ll do it.  Let’s start it, and ensure that it always starts at boot time:

[root@tempest sysadmin]# chkconfig mysqld on
[root@tempest sysadmin]# service mysqld start
Starting mysqld:                                           [  OK  ]
[root@tempest sysadmin]# mysql -u sysadmin -p
Enter password: 
ERROR 1045 (28000): Access denied for user 'sysadmin'@'localhost' (using password: YES)

Okay, what’s up with the sysadmin account:

[root@tempest sysadmin]# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
mysql> select user from mysql.user;
+------+
| user |
+------+
| root |
| root |
+------+
2 rows in set (0.00 sec)

mysql>

Okay, so I didn’t copy any of the users over from Puma.  That’s okay.  We should probably archive the old users and their accounts.  Ideally, I think we should put the mysqldump of someone’s account in their home directory, so that they stay together, say in backups and such.  But then we have to deal with quota issues and such.  Right now, the mysqldumps are being put in /usr/network/sysadmin/mysqldumps, which is convenient for copying it over to Tempest, but not ideal for security/privacy.

I wrote a script migrate-mysql-user which dumps out the grants to a file and copies that file to /root/tmp on tempest.  I tried that, but it failed because the sysadmin database, which we are granting access to, doesn’t exist.  So, I created that database very easily:

[root@tempest sysadmin]# mysql <  /usr/network/sysadmin/mysqldumps/sysadmin.sql

(To be honest, I went back to revise the mysql-backup-multi script, which is run nightly by cron, to add the CREATE DATABASE statement at the top of the dump.  That facilitates rebuilding a broken database and also for migrating, as in this case.

Then, create the user:

[root@tempest tmp]# more sysadmin-user.sql 
GRANT USAGE ON *.* TO 'sysadmin'@'localhost' IDENTIFIED BY PASSWORD '*B83F1E63F975825B10548FC4243FAB842E204B4B'
GRANT ALL PRIVILEGES ON `sysadmin`.* TO 'sysadmin'@'localhost'

[root@tempest tmp]# mysql < /root/tmp/sysadmin-user.sql 
ERROR 1064 (42000) at line 1: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'GRANT ALL PRIVILEGES ON `sysadmin`.* TO 'sysadmin'@'localhost'' at line 2
[root@tempest tmp]#

Darn!  This is exactly the syntax that mysql on Puma generated.  Is there a version difference?

[root@tempest tmp]# mysql -V
mysql  Ver 14.14 Distrib 5.1.61, for redhat-linux-gnu (x86_64) using readline 5.1
[root@tempest tmp]# ssh puma mysql -V
mysql  Ver 14.12 Distrib 5.0.95, for redhat-linux-gnu (x86_64) using readline 5.1
[root@tempest tmp]#

Not much of a difference, so that seems unlikely.

Hang on, the error message indicates that the syntax error is noticed at the very first word, namely “grant all …”  Ah, and I notice that the previous statement doesn’t end in a semi-colon.  Could it be as simple and obvious as that?  I’ll add the semi-colons and try again:

[root@tempest tmp]# cat sysadmin-user.sql
GRANT USAGE ON *.* TO 'sysadmin'@'localhost' IDENTIFIED BY PASSWORD '*B83F1E63F975825B10548FC4243FAB842E204B4B';
GRANT ALL PRIVILEGES ON `sysadmin`.* TO 'sysadmin'@'localhost';
[root@tempest tmp]# mysql < /root/tmp/sysadmin-user.sql

Success!  Still, that’s annoying.  We’ll have to try to figure out a programmatic way to add those semi-colons.  Ah, we can do that with sed:

[root@tempest tmp]# cat sysadmin-user.sql~ | sed 's/$/;/'
GRANT USAGE ON *.* TO 'sysadmin'@'localhost' IDENTIFIED BY PASSWORD '*B83F1E63F975825B10548FC4243FAB842E204B4B';
GRANT ALL PRIVILEGES ON `sysadmin`.* TO 'sysadmin'@'localhost';
;

Let’s migrate the “radmin” mysql user (which is actually the correct user for the script) and go back and try our PHP script:

root@tempest sysadmin]# mysql < /root/tmp/radmin-user.sql 
[root@tempest sysadmin]# php machines-dump.php 
<html>
<head>
<title>CS Department Machines</title>
</head>

<!-- Written by Scott D. Anderson, Summer 2004.  Rewritten to use PEAR, summer 2008.  scott.anderson@acm.org -->

<body bgcolor="white">

<table border='1' cellpadding='10'>
<tr>
<th><a href="machines-dump.php?sortkey=name">name</a></th><th><a href="machines-dump.php?sortkey=location">location</a></th><th><a href="machines-dump.php?sortkey=status">status</a></th><th><a href="machines-dump.php?sortkey=repl">repl</a></th><th><a href="machines-dump.php?sortkey=sn">sn</a></th><th><a href="machines-dump.php?sortkey=hwaddr">hwaddr</a></th><th><a href="machines-dump.php?sortkey=model">model</a></th><th><a href="machines-dump.php?sortkey=ip">ip</a></th><th><a href="machines-dump.php?sortkey=misc">misc</a></th></tr>
<tr bgcolor="CCCCCC"><td>baboon</td><td>E125</td><td>ok</td><td>2011-02</td><td><a href="machine-update.php?sn=MJFNLZ9
...

Okay, success!  Woo hoo!

As we transition from Puma being the department’s web server to Tempest, I think it makes sense to put content in /home, since that’s mounted on both machines, rather than in /var/www/, which is local to each machine.

I copied the following from puma:/var/www/html/ to ~sysadmin/public_html:

accounts 
user-info
sysadmin

I also modified the /etc/httpd/conf.d/wellesley.conf file to set up redirects so that references to the original files would find the new location:

[root@tempest ~]# cd /home/sysadmin/etc/httpd/conf.d/
[root@tempest conf.d]# grep Redirect wellesley.conf
# Redirects to the files in the SysAdmin account, which is mounted on both servers.
Redirect permanent /accounts/ http://tempest.wellesley.edu/~sysadmin/accounts/
Redirect permanent /user-info/ http://tempest.wellesley.edu/~sysadmin/user-info/
Redirect permanent /sysadmin/ http://tempest.wellesley.edu/~sysadmin/sysadmin/

To make updating this file (and both copies in the real /etc on the two servers), I created a script called /home/sysadmin/bin/update-etc-file.

I did not delete the original directories, but I did put README files in there saying they were obsolete.  Eventually, we should delete them.  Or check to make sure they’re in the backups and then delete them.

Our main servers are running older versions of Python, which is good and stable for the server, but may not be what users want.  In this post, I’m installing another version of Python, specifically 2.7.  Since it’s not the standard version, I can’t use yum.

Following the advice from this StackOverflow post on multiple versions of Python, I went to http://www.python.org/getit/releases/2.7/, and got the URL of a tgz file and did:

[root@puma tmp] curl http://www.python.org/ftp/python/2.7/Python-2.7.tgz > Python-2.7.tgz
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 13.3M  100 13.3M    0     0   633k      0  0:00:21  0:00:21 --:--:-- 1174k
[root@puma tmp] tar xzf Python-2.7.tgz 
[root@puma tmp] cd Python-2.7
[root@puma Python-2.7] ./configure 
checking for --enable-universalsdk... no
checking for --with-universal-archs... 32-bit
checking MACHDEP... linux2
checking EXTRAPLATDIR... 
checking machine type as reported by uname -m... x86_64
checking for --without-gcc... no
checking for gcc... gcc
... // many lines omitted
checking for build directories... done
configure: creating ./config.status
config.status: creating Makefile.pre
config.status: creating Modules/Setup.config
config.status: creating Misc/python.pc
config.status: creating pyconfig.h
creating Modules/Setup
creating Modules/Setup.local
creating Makefile
[root@puma Python-2.7]

Now, reading the README file says that in order to build the sqlite3 package, I’ll need to have those libraries and headers installed on my system.  Let’s check:

[root@puma Python-2.7] grep sqlite3 /var/log/rpmpkgs
[root@puma Python-2.7] grep sqlite /var/log/rpmpkgs
python-sqlite-1.1.7-1.2.1.x86_64.rpm
sqlite-3.3.6-5.i386.rpm
sqlite-3.3.6-5.x86_64.rpm
sqlite-devel-3.3.6-5.x86_64.rpm
[root@puma Python-2.7] yum search sqlite
================================================================================ Matched: sqlite =================================================================================
mono-data-sqlite.x86_64 : sqlite database connectivity for Mono
pdns-backend-sqlite.x86_64 : SQLite backend for pdns
php-pear-Log.noarch : Abstracted logging facility for PHP
python-sqlite.x86_64 : Python bindings for sqlite.
qt4-sqlite.x86_64 : SQLite drivers for Qt's SQL classes
sqlite.i386 : Library that implements an embeddable SQL database engine
sqlite.x86_64 : Library that implements an embeddable SQL database engine
sqlite-devel.i386 : Development tools for the sqlite3 embeddable SQL database engine.
sqlite-devel.x86_64 : Development tools for the sqlite3 embeddable SQL database engine.
[root@puma Python-2.7] yum search sqlite3
================================================================================ Matched: sqlite3 ================================================================================
sqlite-devel.i386 : Development tools for the sqlite3 embeddable SQL database engine.
sqlite-devel.x86_64 : Development tools for the sqlite3 embeddable SQL database engine.
[root@puma Python-2.7] yum -y install sqlite3
No package sqlite3 available.
Nothing to do
[root@puma Python-2.7]

Okay, now make the binaries:

[root@puma Python-2.7] make
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Modules/python.o ./Modules/python.c
gcc -pthread -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes  -I. -IInclude -I./Include   -DPy_BUILD_CORE -o Parser/acceler.o Parser/acceler.c
gcopying and adjusting /var/tmp/Python-2.7/Lib/smtpd.py -> build/scripts-2.7
... many lines omitted
changing mode of build/scripts-2.7/pydoc from 660 to 775
changing mode of build/scripts-2.7/idle from 660 to 775
changing mode of build/scripts-2.7/2to3 from 660 to 775
changing mode of build/scripts-2.7/smtpd.py from 660 to 775
/usr/bin/install -c -m 644 ./Tools/gdb/libpython.py python-gdb.py
[root@puma Python-2.7]

Now, usually we would then to “make install,” but that would overwrite the default python.  To make it live side-by-side, just use make “altinstall.”  Here are the relevant lines of the README;

Installing multiple versions
----------------------------

On Unix and Mac systems if you intend to install multiple versions of Python
using the same installation prefix (--prefix argument to the configure
script) you must take care that your primary python executable is not
overwritten by the installation of a different version.  All files and
directories installed using "make altinstall" contain the major and minor
version and can thus live side-by-side.  "make install" also creates
${prefix}/bin/python which refers to ${prefix}/bin/pythonX.Y.  If you intend
to install multiple versions using the same prefix you must decide which
version (if any) is your "primary" version.  Install that version using
"make install".  Install all other versions using "make altinstall".

For example, if you want to install Python 2.5, 2.6 and 3.0 with 2.6 being
the primary version, you would execute "make install" in your 2.6 build
directory and "make altinstall" in the others.

So, let’s do that:

[root@puma Python-2.7] make altinstall
/usr/bin/install -c python /usr/local/bin/python2.7
if test -f libpython2.7.a; then \
        if test -n "" ; then \
            /usr/bin/install -c -m 555  /usr/local/bin; \
        else \
            /usr/bin/install -c -m 555 libpython2.7.a /usr/local/lib/libpython2.7.a; \
            if test libpython2.7.a != libpython2.7.a; then \
                (cd /usr/local/lib; ln -sf libpython2.7.a libpython2.7.a) \
            fi \
        fi; \
    else    true; \
    fi
running build
running build_ext
building dbm using gdbm

Python build finished, but the necessary bits to build these modules were not found:
bsddb185           dl                 imageop         
sunaudiodev                                           
To find the necessary bits, look in setup.py in detect_modules() for the module's name.

running build_scripts
Creating directory /usr/local/lib/python2.7
Creating directory /usr/local/lib/python2.7/lib-tk
Creating directory /usr/local/lib/python2.7/lib-tk/test
Creating directory /usr/local/lib/python2.7/lib-tk/test/test_tkinter
Creating directory /usr/local/lib/python2.7/lib-tk/test/test_ttk
Creating directory /usr/local/lib/python2.7/site-packages
Creating directory /usr/local/lib/python2.7/test
....thousands of additional lines omitted
/usr/bin/install -c -m 644 ./Lib/_abcoll.py /usr/local/lib/python2.7
/usr/bin/install -c -m 644 ./Lib/abc.py /usr/local/lib/python2.7
/usr/bin/install -c -m 644 ./Lib/aifc.py /usr/local/lib/python2.7
/usr/bin/install -c -m 644 ./Lib/antigravity.py /usr/local/lib/python2.7
/usr/bin/install -c -m 644 ./Lib/anydbm.py /usr/local/lib/python2.7
/usr/bin/install -c -m 644 ./Lib/argparse.py /usr/local/lib/python2.7
/usr/bin/install -c -m 644 ./Lib/ast.py /usr/local/lib/python2.7
/usr/bin/install -c -m 644 ./Lib/asynchat.py /usr/local/lib/python2.7
...thousands of additional lines omitted
changing mode of /usr/local/bin/2to3 to 775
running install_egg_info
Writing /usr/local/lib/python2.7/lib-dynload/Python-2.7-py2.7.egg-info
[root@puma Python-2.7]

Whew!  That took *forever*.  Let’s see what it did:

[root@puma Python-2.7] ls -l /usr/local/bin/python2.7*
-rwxr-xr-x 1 root root 6053555 Aug 29 15:35 /usr/local/bin/python2.7
-rwxr-xr-x 1 root root    1624 Aug 29 15:42 /usr/local/bin/python2.7-config
[root@puma Python-2.7] ls -l /usr/local/bin/easy_install*
-rwxr-xr-x 1 root root 292 Nov 19  2010 /usr/local/bin/easy_install
-rwxr-xr-x 1 root root 300 Nov 19  2010 /usr/local/bin/easy_install-2.6
[root@puma Python-2.7] which python
/usr/bin/python
[root@puma Python-2.7] python -V
Python 2.4.3
[root@puma Python-2.7] python2.7 -V
Python 2.7

Hmm.  I like that the basic Python hasn’t changed and we have python2.7.  I had hoped there would also be easy_install-2.7, as there is for -2.6.  We’ll have to look into that.  Still, this is a good start.

Ah, found the solution for easy_install and pip from http://mythinkpond.wordpress.com/2011/12/28/how-to-upgrade-to-python-2-7-on-centos/.  I’ve followed those directions to install easy_install-2.7 and pip-2.7 on Puma and Tempest.  There are just two modifications of the linked directions. Since we don’t want to replace the default python on either server, we will do:

make altinstall   # instead of make install
cd pip-1.0
python2.7 setup.py install   # instead of python setup.py install

Seems to be working well!

I think it makes sense to set up a local mirror/repository for CentOS packages, at least for our workstations.  I’m following the directions here, which seem to be quite clear:  http://wiki.centos.org/HowTos/CreateLocalMirror.

We can later investigate the option of doing a network install, like  http://wiki.centos.org/TipsAndTricks/VncHeadlessInstall.  More at http://wiki.centos.org/TipsAndTricks.

First, we need some space.  We’re not using Puma’s disks, and this seems like a good use of that non-backed-up space, so I’m going to delete the files in /students-puma, unmount that (modifying fstab) and create a /share volume that will be exported on-campus:

[root@puma ~] umount /students-puma/
[root@puma ~] emacs -nw /etc/fstab
[root@puma ~] mount /dev/mapper/vg0-lvstud /share
[root@puma ~] mkdir -p /share/CentOS/6.3
[root@puma ~] cd /share/CentOS/
[root@puma CentOS] ln -s 6.3 6
[root@puma CentOS] emacs -nw /etc/exports
[root@puma CentOS] grep share /etc/exports
/share 149.130.0.0/16(ro)
[root@puma CentOS] service nfs restart

I set up the desired directory structure.  I think only the first three are necessary for our purposes, and frankly, I don’t know what the others are, but it can’t hurt, to have them, I think.

[root@puma CentOS] mkdir -p 6.3/isos/i386
[root@puma CentOS] mkdir -p 6.3/os/i386
[root@puma CentOS] mkdir -p 6.3/updates/i386
[root@puma CentOS] mkdir -p 6.3/extras/i386
[root@puma CentOS] mkdir -p 6.3/fastrack/i386
[root@puma CentOS] mkdir -p 6.3/cr/i386
[root@puma CentOS] mkdir -p 6.3/contrib/i386
[root@puma CentOS] mkdir -p 6.3/centosplus/i386
[root@puma CentOS] mkdir -p 6.3/addons/i386

I copied the .iso files to the isos/i386 directory and then did:

[root@puma CentOS] mkdir /tmp/mnt
[root@puma CentOS] mount -ro loop /share/CentOS/6.3/isos/i386/CentOS-6.3-i386-bin-DVD1.iso /tmp/mnt
[root@puma CentOS] rsync -aHS /tmp/mnt/ /share/CentOS/6.3/os/i386/
[root@puma CentOS] umount /tmp/mnt
[root@puma CentOS] mount -ro loop /share/CentOS/6.3/isos/i386/CentOS-6.3-i386-bin-DVD2.iso /tmp/mnt
[root@puma CentOS] rsync -aHS /tmp/mnt/ /share/CentOS/6.3/os/i386/

That looks like:

[root@puma i386] pwd
/share/CentOS/6.3/os/i386
[root@puma i386] ls
CentOS_BuildTag  images    RELEASE-NOTES-en-US.html  RPM-GPG-KEY-CentOS-Debug-6     TRANS.TBL
EULA             isolinux  repodata                  RPM-GPG-KEY-CentOS-Security-6
GPL              Packages  RPM-GPG-KEY-CentOS-6      RPM-GPG-KEY-CentOS-Testing-6
[root@puma i386]

I wrote the following script, based on their example.  I chose gigenet as the mirror site because Illinois isn’t too far, and they support rsync.

[root@puma i386] emacs -nw /home/sysadmin/bin/rsync-update-CentOS
[root@puma i386] chmod a+rx !$
chmod a+rx /home/sysadmin/bin/rsync-update-CentOS
[root@puma bin] cat /home/sysadmin/bin/rsync-update-CentOS
#!/bin/bash

# Script to run regularly to mirror all the updates to the CentOS distribution
# Almost identical to model at http://wiki.centos.org/HowTos/CreateLocalMirror

# bail out on errors
set -e

progname=`basename $0`

lockfile=/var/lock/subsys/$progname
if [ -f $lockfile ]; then
    echo "$progname is already running"
    exit 0
fi

mirror=rsync://mirrors.gigenet.com:/centos
release=6.3
target=/share/CentOS/$release

if [ -d $target ] ; then
    touch $lockfile
    # omit -v and -P since we're running unattended
    # be careful with the trailing slashes
    rsync -aSH --delete --exclude "local*" --exclude "isos" $mirror/$release/ $target/
    rm $lockfile
else
    echo "Target directory $target not present"
fi

Okay, let’s give it a try:

[root@puma bin] update-root-dirs 
[root@puma bin] rsync-update-CentOS 
Linux mirrors.gigenet.com 2.6.32-5-amd64 #1 SMP Mon Oct 3 03:59:20 UTC 2011 x86_64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

[root@puma bin]

Several hours and 29GB later, we have a mirror!

Next, we have to set up a repo file.  Ah, they recommend using either ProtectBase or Priorities. These seem like really good idea, though we can’t use it with RHEL, since there isn’t a .repo file (very strange).

I think I will copy a .repo file from one of the new CentOS clients and edit it to use the local repository.  We’ll also have to mount the /share volume from Puma to the client.  I don’t know yet whether to keep that volume mounted all the time or only when doing updates.  Probably only when necessary.  We can write a little yum-update script that mounts /share, does the update, and un-mounts it.

Since the CS department website is migrating to Drupal, we have to set up a bunch of re-directs.  Why?  Because people may have bookmarked pages or otherwise recorded the obsolete URLs to our old site, and we want them to get the new, up-to-date content instead.  This can easily be done with a redirect.  (See http://www.yolinux.com/TUTORIALS/ApacheRedirect.html for a variety of options.)

A redirect, particularly one that is read when Apache starts, has a speed advantage over most of the alternatives.  No files need to be accessed, and Apache just quickly returns the new URL to the browser and the browser accesses that new URL instead.

At first, I thought that the redirect had to be with a Directory container, like this:

<Directory /home/cs/public_html/Resources/>
    Redirect permanent quota.html http://new.wellesley.edu/cs/resources/quota
</Directory>

but that was an abysmal failure.  Instead, you give the complete URL at the top level in your Apache configuration file, like this:

[root@tempest ~]# cd /etc/httpd/conf.d
[root@tempest conf.d]# grep linux wellesley.conf
Redirect permanent /~cs/Resources/linux.html http://new.wellesley.edu/cs/resources/linux

Note that I’m putting these entries in a separate wellesley.conf file that I put in the /etc/httpd/conf.d directory.  All the .conf files in that directory are automatically loaded when Apache starts up, so that makes a nice way to keep our customizations separate from the basic /etc/httpd/conf/httpd.conf file.

There are a few things that can’t be overridden in a separate .conf file, and have to be done by editing the httpd.conf file.  These are noted in the file in the usual way, with the “Wellesley mod” comment:

[root@tempest conf.d]# cd ../conf
[root@tempest conf]# ls
httpd.conf  httpd.conf.orig  magic
[root@tempest conf]# diff httpd.conf httpd.conf.orig 
366,368c366
<     # Wellesley mod:  allow UserDir
<     #UserDir disabled
<     UserDir public_html
---
>     UserDir disabled

I’m going to do the same thing (a separate wellesley.conf) file on Puma:

[root@puma ~] cd /etc/httpd/conf.d/
[root@puma conf.d] cp /home/sysadmin/etc/httpd/conf.d/wellesley.conf .
[root@puma conf.d] ls -l w*.conf
-rw-r--r-- 1 root root   352 Jul 12  2006 webalizer.conf
-rw-r--r-- 1 root root   299 Jun  6 10:04 welcome.conf
-rw-rw---- 1 root root 25625 Aug 23 15:07 wellesley.conf
[root@puma conf.d] chmod 644 wellesley.conf 
[root@puma conf.d] ls -lZ w*.conf
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 webalizer.conf
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 welcome.conf
-rw-r--r--  root root user_u:object_r:httpd_config_t:s0 wellesley.conf
[root@puma conf.d] chcon --reference=welcome.conf wellesley.conf 
[root@puma conf.d] ls -lZ w*.conf
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 webalizer.conf
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 welcome.conf
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 wellesley.conf
[root@puma conf.d] apachectl -t
[Thu Aug 23 15:08:32 2012] [warn] module unique_id_module is already loaded, skipping
[Thu Aug 23 15:08:32 2012] [warn] The Alias directive in /etc/httpd/conf/httpd.conf at line 1257 will probably never match because it overlaps an earlier Alias.
[Thu Aug 23 15:08:32 2012] [warn] The Alias directive in /etc/httpd/conf/httpd.conf at line 1310 will probably never match because it overlaps an earlier Alias.
[Thu Aug 23 15:08:32 2012] [warn] The Alias directive in /etc/httpd/conf/httpd.conf at line 1311 will probably never match because it overlaps an earlier Alias.
[Thu Aug 23 15:08:32 2012] [warn] The Alias directive in /etc/httpd/conf/httpd.conf at line 1312 will probably never match because it overlaps an earlier Alias.
Syntax OK
[root@puma conf.d] apachectl graceful
[root@puma conf.d]

The “apachectl -t” command checks the Apache configuration files for syntax errors.  The “apachectl graceful” command restarts Apache, gracefully, basically waiting until the current requests are satisfied before restarting, so no browser gets an “interruption” response.

We should fix those Alias errors.  However, let’s first determine whether they’re caused by the overlap between the wellesley.conf file and the stuff I haven’t yet taken out of httpd.conf:

[root@puma conf.d] mv wellesley.conf wellesley.conf-disabled
[root@puma conf.d] apachectl -t
Syntax OK

Yup.  Ok, so let’s remove all the redundant stuff from httpd.conf and try again.  Most of the edits were pretty straightforward, but I removed the ExecCGI on /var/www/html; I’m not sure why it was ever there.  I also restored the entire directory configuration for /var/www/cgi-bin, trying to minimize unnecessary differences with the .orig file.  I also removed the VirtualHost configuration.  We can always restore these from /etc/httpd/conf/httpd.conf.with_wellesley_mods

[root@puma conf.d] cd ../conf
[root@puma conf] diff httpd.conf httpd.conf.orig 
266d265
< ServerName cs.wellesley.edu:80
356,357c355
<     # Wellesley mod: don't disable
<     #UserDir disable
---
>     UserDir disable
364,365c362
<     #Wellesley: allow this(sda and sjk)
<     UserDir public_html
---
>     #UserDir public_html
580d576
< 
[root@puma conf]

Let’s check the selinux context, even though we’re not using selinux on Puma:

[root@puma conf] ls -lZ httpd.conf httpd.conf.orig 
-rw-r--r--  root root user_u:object_r:httpd_config_t:s0 httpd.conf
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 httpd.conf.orig
[root@puma conf] chcon --reference=httpd.conf.orig httpd.conf
[root@puma conf] ls -lZ httpd.conf httpd.conf.orig 
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 httpd.conf
-rw-r--r--  root root system_u:object_r:httpd_config_t:s0 httpd.conf.orig
[root@puma conf]

Okay, let’s recheck the syntax:

[root@puma conf] apachectl -t
Syntax OK
[root@puma conf] cd ../conf.d
[root@puma conf.d] mv wellesley.conf-disabled wellesley.conf
[root@puma conf.d] apachectl -t
Syntax OK
[root@puma conf.d] apachectl graceful

Great.  Now, the redirects should work for Puma:

[root@puma conf.d] grep Redirect wellesley.conf | head 
# Redirects to Drupal site.
Redirect permanent /index.html http://new.wellesley.edu/cs
# Use RedirectMatch with trailing $ so that /~cs/foo doesn't map to new.wellesley.edu/csfoo
RedirectMatch permanent /$ http://new.wellesley.edu/cs
Redirect permanent /index.html http://new.wellesley.edu/cs
Redirect permanent /~cs/Curriculum/curriculum.html        http://new.wellesley.edu/cs/curriculum
Redirect permanent /~cs/Curriculum/majorminor.html        http://new.wellesley.edu/cs/curriculum/major
Redirect permanent /~cs/Curriculum/intro.html             http://new.wellesley.edu/cs/curriculum/introductory
Redirect permanent /~cs/Curriculum/mit.html               http://new.wellesley.edu/cs/curriculum/mit
Redirect permanent /~cs/Curriculum/olin.html              http://new.wellesley.edu/cs/curriculum/olin
[root@puma conf.d]

Here is a nice way to test that the redirects work:

[root@puma conf.d] GET -Sd http://tempest.wellesley.edu/
GET http://tempest.wellesley.edu/ --> 301 Moved Permanently
GET http://new.wellesley.edu/cs --> 200 OK
[root@puma conf.d] GET -Sd http://tempest.wellesley.edu/~cs/Curriculum/curriculum.html
GET http://tempest.wellesley.edu/~cs/Curriculum/curriculum.html --> 301 Moved Permanently
GET http://new.wellesley.edu/cs/curriculum --> 200 OK
[root@puma conf.d] GET -Sd http://puma.wellesley.edu/~cs/Curriculum/curriculum.html
GET http://puma.wellesley.edu/~cs/Curriculum/curriculum.html --> 301 Moved Permanently
GET http://new.wellesley.edu/cs/curriculum --> 200 OK
[root@puma conf.d]

This shows the sequence of URLs returned from the server and re-fetched by the browser (in this case, the GET command is substituting for the browser).

Note that, one case, we used the more powerful RedirectMatch directive, since that allowed us to put the trailing $ to avoid overmatching.  These redirects match all URLs that start with the path shown, so:

[root@puma conf.d] GET -Sd http://tempest.wellesley.edu/~cs/index.html
GET http://tempest.wellesley.edu/~cs/index.html --> 301 Moved Permanently
GET http://new.wellesley.edu/cs --> 200 OK
[root@puma conf.d] GET -Sd http://tempest.wellesley.edu/~cs/index.htmlfoo
GET http://tempest.wellesley.edu/~cs/index.htmlfoo --> 404 Not Found
[root@puma conf.d] GET -Sd http://tempest.wellesley.edu/~cs/index.html/foo
GET http://tempest.wellesley.edu/~cs/index.html/foo --> 301 Moved Permanently
GET http://new.wellesley.edu/cs/foo --> 404 Not Found
[root@puma conf.d]

Did you see how the “foo” got tacked onto the end of the re-written URL?  That won’t typically be a problem for normal filename URLs, but for a directory URL like ~cs/, we can’t just tack the rest of the URL onto the end of the re-write.  So, we only rewrite if the pattern matches, and it’ll only match if the URL matches exactly.  That’s how we can still get to stuff served out of ~cs/public_html.

Now, we should do some cleaning up of public_html, since most of it is now old.  I created the following.  It’s a new public_html, with a handful of the files we still need, plus a pointer to the old stuff (should probably be made read-only) and a README file:

[root@puma conf.d] pushd ~cs
/home/cs /etc/httpd/conf.d
[root@puma cs] ls -ld pub*
lrwxrwxrwx 1 cs   faculty   22 Aug 22 12:29 public_html -> archive/cs_07-08/cs_v3
drwxrwxr-x 4 cs   faculty 4096 Aug 23 16:45 public_html.new
lrwxrwxrwx 1 root root      28 Nov 12  2006 public_html.old -> archive/cs_02-03/csweb-2002/
[root@puma cs] ls -lR public_html.new/
public_html.new/:
total 48
drwxrwxr-x 2 cs faculty  4096 Aug 23 13:41 Curriculum
-rw-rw-r-- 1 cs faculty 31065 Aug 23 16:44 facultyInfo.html
-rw-rw-r-- 1 cs faculty   858 Aug 23 16:44 facultyInfo-style.css
lrwxrwxrwx 1 cs faculty    26 Aug 23 13:26 old -> ../archive/cs_07-08/cs_v3/
drwxrwxr-x 3 cs faculty  4096 Aug 23 13:49 People
-rw-rw-r-- 1 cs faculty   698 Aug 23 16:45 README

public_html.new/Curriculum:
total 148
-rw-r--r-- 1 cs faculty  9712 Aug 23 13:33 course-graph-f08.js
-rw-r--r-- 1 cs faculty 12510 Aug 23 13:33 course-graph-f12.js
-rw-r--r-- 1 cs faculty 16727 Aug 23 13:33 dependencies-f08.html
-rw-r--r-- 1 cs faculty 40803 Aug 23 13:39 dependencies-f12.html
-rw-r--r-- 1 cs faculty 40672 Aug 23 13:33 dependencies-f12.html~
lrwxrwxrwx 1 cs faculty    21 Aug 23 13:35 dependencies.html -> dependencies-f12.html
-rw-rw-r-- 1 cs faculty  8889 Aug 23 13:33 graph.js
-rw-rw-r-- 1 cs faculty  3124 Aug 23 13:33 tooltip.js
-rw-rw-r-- 1 cs faculty  1312 Aug 23 13:33 utils.js

public_html.new/People:
total 4
drwxrwxr-x 2 cs faculty 4096 Aug 23 13:49 wellesley-only

public_html.new/People/wellesley-only:
total 8
-rw-rw-r-- 1 cs faculty 5840 Aug 23 13:49 students.html
[root@puma cs]

Now, all we have to do to switch to this is the following:

[root@puma cs] rm public_html ; mv public_html.new public_html

All the redirects will now work, and we can get to the old content:

[root@puma cs] GET -Sd http://puma.wellesley.edu/~cs/index.html
GET http://puma.wellesley.edu/~cs/index.html --> 301 Moved Permanently
GET http://new.wellesley.edu/cs --> 200 OK
[root@puma cs] GET -Sd http://puma.wellesley.edu/~cs/Curriculum/curriculum.html
GET http://puma.wellesley.edu/~cs/Curriculum/curriculum.html --> 301 Moved Permanently
GET http://new.wellesley.edu/cs/curriculum --> 200 OK
[root@puma cs] GET -Sd http://puma.wellesley.edu/~cs/old/index.html
GET http://puma.wellesley.edu/~cs/old/index.html --> 200 OK
[root@puma cs]

Okay, I think we’re good to go.  I’m sure there will be some small errors, things that should be moved over from “old” or migrated to Drupal, but the bulk is in shape, I think.