Completed in August 2007

• Can add users with luseradd and lgroupadd, and those programs refuse duplicate entries, but doing an ldapsearch does not return added users/groups. Groups and users added via something like Luma or JXplorer show up in ldapsearch, but not groups/users added by l*add! Are they using different databases? /etc/libuser.conf controls how libuser (the 'l' in luseradd, etc.) does its thing.
• The LDAP password was stored in a plain text file on einstein, so I deleted it. Only root had permissions, but still… This "might" be needed by something, so let's not forget about it having existed Yes, it was needed by PAM, at least
• Get the old public keys for pauli2 and 4 from einstein or whatever and replace the new ones on pauli2 and 4 with the old ones
• Got rid of the "wheel" entry in /etc/sudoers since we don't have a wheel group.
• Standardized the /etc/ssh/ssh_known_hosts file. Made one host per line, with all possible ways to get to the host (lone hostname, unh address, unh ip, farm ip, farm address, etc.). WAY cleaner and easier to read and blocked into obvious sections.
• Pepper's been running two instances of cortex for a REALLY long time with 100% cpu usage. Sent a message to Covrig to ask if he's actually doing something of if it's out of control. Turns out they were runaways, he killed them.
• tomato: trying to figure out how to configure and set up some fake users for testing[1] before copying einstein's setup Need to figure out TLS certificates, too. User passwords are stored encrypted in the LDAP database. We need the key that einstein uses or it won't work for authentication when we transfer the db to tomato. There are several keys and certificates in /usr/share/ssl/certs, but what each of them is for is not totally obvious. The LDAP-related ones are referenced in slapd.conf/ldap.conf We need to figure out how to deal with transferring the LDAP database to tomato and have the passwords work. Turns out to be not a big deal with salted hashing. The client requests the salt from the server, hashes the password, and then sends the hashed version to the server for authentication. So no external keys are used for that. Certs and stuff are still needed for encryption over the network.
• rsync didn't backup tomato last night. Did we change a key? Maybe not, since tomato was in some weird state where root couldn't log in… Tomato was having serious ssl-related ldap issues, preventing it from starting ldap and authenticating anything far enough to log in, including root, strangely enough.
• Put jalapeno back on an SMP kernel. GRUB doesn't have it as the default, so the last time jalapeno froze up, the single got loaded. However, the most recent SMP kernel led to a panic on initialization, so we're using a slightly older one.
• Price server hardware and see if we can beat the microway quote. Not worth our time to build it from scratch, especially considering the fact that the school year is approaching.
• Slapdcat'd einstein, slapadd'd tomato, works! A benefit of BerkleyDB is that slapcat can be safely run while slapd is running. Handy SSL Stuff Specifics for OpenLdap Setting up with TLS. Roentgen is NPG's Certificate Authority. Remember to concatenate einstein and tomato's unh_physics_ca.crt files, and distribute that to clients before the switch?
• Updated up2date on pepper, taro, symanzik, and parity via the old up2date. Worked without errors, and used the new up2date to fetch updates.
• Figure out how to change log levels for snmpd on jalapeno. It's logging every time okra makes a connection. /etc/sysconfig/snmpd.options ? Changing it to be like einstein's didn't work. Looks to me like it did work. Check with ps auwwx, will show options are set properly. Those options don't seem to be all there is to it, because splunk still shows ~550 logs per hour. Well, the issue seems to have gone away as of thursday
• Bohr, improv, and who knows how many others lost connection to /net/home at the same time. Turns out that the DNS servers running on both einstein and tomato died. Restarting named and rebooting affected workstations solved the problem. Why did this happen in the first place??
• After a reinstall, the errors went away. Copied all of einstein's /etc/postfix over to tomato, edited to say tomato instead of einstein. Postfix still won't start, maillog shows fatal: bind 10.0.0.248 port 587: Cannot assign requested address 10.0.0.248 is einstein's farm address. /var/log/maillog is showing einstein as a relay. What files other than the stuff in /etc/postfix were copied? Nevermind, had the wrong value for $myorigin. Starting from scratch seemed to be the best solution.
• (Possibly helpful site) All mail needs replicated/master-slaved Reinstalled postfix, cleaned out the old config files. We should try to first get it set up to send mail locally, at least, then go for the whole Internet. Local mail is now working! Sending/receiving(Need to modify DNS so that it doesn't get grabbed by einstein) mail across the subnet now works! Sending mail outside of the subnet works, too, but receiving foreign mail is disabled (same as for receiving over subnet?). Mail from my gmail account doesn't even result in any sort of entry in maillog… It all works just fine and dandy!
• tomato: Maps are synched in the LDAP database, script is referenced by adduser-npg. Replicated/mounted-elsewhere? rsync'ed einstein's home to a folder on tomato's data drive, we can just keep this copied version up to date via rsync until the switchover, to minimize effort during the switch.
• tomato: Um, yes???? Actually, the amavis/postfix/clamav/spamassassin guide on the spamassassin website is better. Set everything up until amavis' config file, because I can't seem to get amavisd-new installed, thanks to dependencies. Nevermind, I played with repositories a bit and got it all installed.