Index: trunk/server/doc/389-ds-enable-ssl-and-kerberos.diff =================================================================== --- trunk/server/doc/389-ds-enable-ssl-and-kerberos.diff (revision 1687) +++ (revision ) @@ -1,59 +1,0 @@ ---- o-f.config.ldif 2008-07-05 06:24:48.000000000 -0400 -+++ b-m.config.ldif 2008-07-05 06:25:34.000000000 -0400 -@@ -123,7 +123,7 @@ - passwordMaxFailure: 3 - nsslapd-accesslog: /var/log/dirsrv/slapd-scripts/access - nsslapd-lastmod: on --nsslapd-security: off -+nsslapd-security: on - passwordMaxAge: 8640000 - nsslapd-auditlog-logrotationtimeunit: day - passwordResetFailureCount: 600 -@@ -180,7 +180,7 @@ - nsslapd-referralmode: - nsslapd-maxdescriptors: 1024 - nsslapd-conntablesize: 1024 --nsslapd-sslclientauth: off -+nsslapd-sslclientauth: allowed - nsslapd-config: cn=config - nsslapd-instancedir: - nsslapd-schemadir: /etc/dirsrv/slapd-scripts/schema -@@ -217,7 +217,8 @@ - nsSSLSessionTimeout: 0 - nsSSLClientAuth: allowed - nsSSL2: off --nsSSL3: off -+nsSSL3: on -+nsSSL3Ciphers: +rsa_rc4_128_md5 - nsSSLSupportedCiphers: SSL3::rc4::RC4::MD5::128 - nsSSLSupportedCiphers: SSL3::rc4export::RC4::MD5::128 - nsSSLSupportedCiphers: SSL3::rc2::RC2::MD5::128 -@@ -315,6 +316,15 @@ - objectClass: extensibleObject - cn: uniqueid generator - -+# RSA, encryption, config -+dn: cn=RSA,cn=encryption,cn=config -+objectClass: top -+objectClass: nsEncryptionModule -+cn: RSA -+nsSSLPersonalitySSL: ldap/better-mousetrap -+nsSSLToken: internal (software) -+nsSSLActivation: on -+ - # options, features, config - dn: cn=options,cn=features,cn=config - objectClass: top -@@ -1264,3 +1274,12 @@ - nsslapd-pluginVendor: Fedora Project - nsslapd-pluginDescription: Salted Secure Hashing Algorithm (SSHA512) - -+# mapname, mapping, sasl, config -+dn: cn=mapname,cn=mapping,cn=sasl,cn=config -+objectClass: top -+objectClass: nsSaslMapping -+cn: mapname -+nsSaslMapRegexString: \(.*\) -+nsSaslMapBaseDNTemplate: uid=\1,ou=People,dc=scripts,dc=mit,dc=edu -+nsSaslMapFilterTemplate: (objectClass=posixAccount) -+ Index: trunk/server/doc/HOWTO-SETUP-LDAP =================================================================== --- trunk/server/doc/HOWTO-SETUP-LDAP (revision 1687) +++ (revision ) @@ -1,106 +1,0 @@ -To set up a new LDAP server: - -- Install the RPM 389-ds-base with yum -- root# env NSS_NONLOCAL_IGNORE=1 useradd -r -d /var/lib/dirsrv fedora-ds -- root# /usr/sbin/setup-ds.pl - - Choose a typical install - - Tell it to use the fedora-ds user and group - - Directory server identifier: scripts - - Suffix: dc=scripts,dc=mit,dc=edu - - Input directory manager password -- yum install ldapvi -- /sbin/service dirsrv start -- Apply ./fedora-ds-enable-ssl-and-kerberos.diff manually -- Also set nsslapd-ldapifilepath: /var/run/dirsrv/slapd-scripts.socket - and nsslapd-ldapilisten: on, otherwise ldapi won't work. -- /sbin/service dirsrv stop -- Add the scripts schemas to /var/lib/dirsrv/slapd-scripts -- wget http://web.mit.edu/geofft/Public/scripts-ca.pem -- certutil -d /etc/dirsrv/slapd-scripts -A -n "scripts.mit.edu CA" -t CT,, -a -i scripts-ca.pem -- Generate a pkcs12 cert for the server: -- openssl pkcs12 -export -in c-w.pem -inkey c-w.key -name 'ldap/cats-whiskers' -out c-w.pkcs12 -- pk12util -i ldap-server-cert.p12 -d /etc/dirsrv/slapd-scripts -- Put LDAP keytab in /etc/dirsrv/keytab -- Uncomment and modify in /etc/syscnfig/dirsrv: KRB5_KTNAME=/etc/dirsrv/keytab ; export KRB5_KTNAME -- mkdir -p /var/tmp/dirsrv -- chown fedora-ds:fedora-ds /var/tmp/dirsrv -- chmod 755 /var/run/dirsrv -- /sbin/service dirsrv restart -- Use ldapvi -b cn=config to add these indexes: - -add cn=apacheServerName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: apacheServerName -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -add cn=apacheServerAlias, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: apacheServerAlias -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -add cn=scriptsVhostName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: scriptsVhostName -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -add cn=scriptsVhostAlias, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: scriptsVhostAlias -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -add cn=scriptsVhostAccount, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: scriptsVhostAccount -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -add cn=memberuid, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: memberuid -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -add cn=uidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: uidnumber -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -add cn=gidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config -objectClass: top -objectClass: nsIndex -cn: gidnumber -nsSystemIndex: false -nsIndexType: eq -nsIndexType: pres - -- Build the indexes for all the fields: - - /usr/lib64/dirsrv/slapd-scripts/db2index.pl -D "cn=Directory Manager" -j /etc/signup-ldap-pw -n userRoot - -- Watch for the indexing operations to finish with this command: - - ldapsearch -x -y /etc/signup-ldap-pw -D 'cn=Directory Manager' -b cn=tasks,cn=config - -- Set up replication: - (basically, execute - http://directory.fedoraproject.org/sources/contrib/mmr.pl - manually) Index: trunk/server/doc/install-fedora =================================================================== --- trunk/server/doc/install-fedora (revision 1687) +++ trunk/server/doc/install-fedora (revision 1693) @@ -2,143 +2,13 @@ ---------------------------------------- -1. Create the LVS partitions that the Scripts guest will use. +We use Kickstart to to initial Fedora configuration. Installing a new +vanilla machine is as easy as: -Our classic setup is 50GB for the main, root partition (/) and -10GB for our swap. You can consult what things look like -by using `lvdisplay`. Our naming convention is server-name-root -and server-name-swap. + xm create scripts-server machine_name=$MACHINE install=fXX && console $MACHINE -Creating new LVS partitions is done with `lvcreate`: +The only prompt (near the beginning of the install process) should be +for the root password, and at the end, when it asks you to reboot. +Say yes, and the machine will power down, and then restart without +the install parameter: - # Example values: - # SERVERNAME=whole-enchilada - # HOSTNAME=jay-leno - lvcreate -n $SERVERNAME-root $HOSTNAME --size 50.00G - lvcreate -n $SERVERNAME-swap $HOSTNAME --size 10.00G - -2. Acquire the network installation media for Fedora. - -Normally, you would download an ISO and kick off an installation -by burning it to a CD and booting off of that. Since we would like -to make as minimal a Fedora install as possible, we use a different -method. [XXX: Why do we actually do it this way? It seems kind -of convoluted] - -First, we need to create an appropriate installation directory, -which contains the necessary kernel images and bootstrapping code. -Navigate to a Fedora mirrors website, and find the correct release -from the linux/releases directory, then grab the contents of -Fedora/x86_64/os/isolinux. For example, getting the Fedora 13 installer -from mirrors.mit.edu would be: - - mkdir ~/f13-install - cd ~/f13-install - wget -r -nd ftp://mirrors.mit.edu/fedora/linux/releases/13/Fedora/x86_64/os/isolinux/ - -You can then spin up a Xen image for installation with: - - xm create scripts-server machine_name=$HOSTNAME install=f13 - -Note that the -install suffix was dropped. Get a console with `xm -console`. - -3. Tell Fedora where to get the real installer. - -You will now be in a curses installer interface. Since you are doing -a network install, you will need to configure your network and specify -the URL to install. Find the static hostname that you are planning -to install to and get its information with: - - stella $HOSTNAME - -Manually configure its IP, disabling IPv6 for now [XXX I don't know how -to configure that]. The network mask is 16, and you can check -'/etc/resolv.conf' if you don't remember what MIT's DNS servers are. - -It will then ask you for an installation image. Continuing with our -F13 mirrors.mit.edu, the URL will look something like: - - ftp://mirrors.mit.edu/fedora/linux/releases/13/Fedora/x86_64/os - -4. Use VNC - -At this point, Fedora will ask you whether or not you want to use VNC -to continue the installation. Because Scripts has an unusual disk -image setup, you will want to answer yes. [XXX: Unfortunately, this puts -the VNC session on MITnet, so make sure you use a good password, and -we should figure out to make it not do that]. Grab your favorite -VNC client and login to $HOSTNAME:1 - -5. Installation in VNC - -5.1. Disks to use - -We don't have any exotic devices (we did that at the host level, -recall), so you can use normal configuration. The scripts-server Xen -configuration will have automatically selected the LVS partitions you -created in Step 1, and you want both of them. - -5.2. Host - -The default hostname is all caps: we use lower-case, so lower-case the -name before proceeding. - -5.3. Timezone - -Self explanatory - -5.4. Root password - -Use Scripts root password for a real install, and fake password -otherwise. [XXX: Insecure over VNC? Argh!] - -5.5 Formatting the disks - -You can find out what our existing setup looks like by consulting -'/etc/fstab'. - -Select Custom, and select both disks for formatting. Setup the larger -disk as the boot partition. Configure the partitions as follows: - - 50GB - Standard Partition - Mount Point: / - File System Type: ext3 (the default as of F13 is ext4, which - cannot be mounted by the hosts and thus should not be used!) - Additional Size Options: Fill to maximum allowable size (the - Size parameter will not do anything in that case) - Force to be primary partition - 10GB - Standard Partition - File System Type: swap - Additional Size Options: Fill to maximum allowable size - -5.6 Bootloader - -Defaults are fine. - -5.7 Installation - -Do a minimal install (we will proceed to install the packages we care -about), and add the normal F13 repository (testing and updates will be -added when we bring in our /etc configuration). Similarly, we will -install the software we want later, so there is no need to do that now. - -5.8 Reboot - -When the install finishes, it will ask you to reboot. This is fine, but -since we created the VM image with install, upon reboot it will ask us -to install again. Let it reboot, then destroy the virtual machine. - - xm destroy $SERVERNAME - -6. New World Order - -Start up the VM without the install flag: - - xm create scripts-server machine_name=$SERVERNAME - -Use xm console to get a terminal, and proceed with the official install -instructions. - - xm console $SERVERNAME + xm create scripts-server machine_name=$MACHINE && console $MACHINE Index: trunk/server/doc/install-howto.sh =================================================================== --- trunk/server/doc/install-howto.sh (revision 1687) +++ trunk/server/doc/install-howto.sh (revision 1693) @@ -1,86 +1,91 @@ # This document is a how-to for installing a Fedora scripts.mit.edu server. +# It is semi-vaguely in the form of a shell script, but is not really +# runnable as it stands. set -e -x -[ -e /scripts-boot-count ] || echo 0 > /scripts-boot-count - -source_server="old-faithful.mit.edu" - -boot=${1:$(cat /scripts-boot-count)} - -# XXX: let 'branch' be the current svn branch you are on - -doreboot() { - echo $(( $boot + 1 )) > /scripts-boot-count; - shutdown -r now "Rebooting for step $(cat /scripts-boot-count)" -} - -YUM() { - NSS_NONLOCAL_IGNORE=1 yum "$@" -} - -# Helper files for the install are located in server/fedora/config. - -# Start with a normal install of Fedora. - -if [ $boot = 0 ]; then -# When the initial configuration screen comes up, under "Firewall -# configuration", disable the firewall, and under "System services", leave -# enabled (as of Fedora 9) acpid, anacron, atd, cpuspeed, crond, -# firstboot, fuse, haldaemon, ip6tables, iptables, irqbalance, -# kerneloops, mdmonitor, messagebus, microcode_ctl, netfs, network, nscd, ntpd, -# sshd, udev-post, and nothing else. - echo "--disabled" > /etc/sysconfig/system-config-firewall - for i in NetworkManager avahi-daemon bluetooth cups isdn nfslock nfs pcscd restorecond rpcbind rpcgssd rpcidmapd sendmail; do - chkconfig "$i" off - done - -# Turn on network, so we can connect at boot -chkconfig network on - -# Edit /etc/selinux/config so it has SELINUX=disabled and reboot. - sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config - doreboot -fi - -if [ $boot = 1 ]; then -# Create a scripts-build user account, and set up rpm to build in -# $HOME by doing a -# cp config/home/scripts-build/.rpmmacros /home/scripts-build/ -# (If you just use the default setup, it will generate packages -# in /usr/src/redhat.) - adduser scripts-build +# Some commands should be run as the scripts-build user, not root. + +alias asbuild="sudo -u scripts-build" + +# Old versions of this install document advised setting +# NSS_NONLOCAL_IGNORE=1 anytime you're setting up anything, e.g. using +# yum, warning that useradd will query LDAP in a stupid way that makes +# it hang forever. As of Fedora 13, this does not seem to be a problem, +# so it's been removed from the instructions. If an install is hanging, +# though, try adding NSS_NONLOCAL_IGNORE. + +# This is actually just "pick an active scripts server". It can't be +# scripts.mit.edu because our networking config points that domain +# at localhost, and if our server is not setup at that point things +# will break. +source_server="cats-whiskers.mit.edu" + +# 'branch' is the current svn branch you are on. You want to +# use trunk if your just installing a new server, and branches/fcXX-dev +# if your preparing a server on a new Fedora release. +branch="trunk" + +# 'server' is the public hostname of your server, for SCP'ing files +# to and from. +server=YOUR-SERVER-NAME-HERE + +# Start with a Scripts kickstarted install of Fedora (install-fedora) + +# Take updates, reboot if there's a kernel update. + + yum update + +# Get rid of network manager + yum remove NetworkManager # Check out the scripts.mit.edu svn repository. Configure svn not to cache # credentials. - YUM install -y subversion - - cd /srv - svn co svn://$source_server/$branch repository - - sed -i 's/^(# *)*store-passwords.*/store-passwords = no/' /root/.subversion/config - sed -i 's/^(# *)*store-auth-creds.*/store-auth-creds = no/' /root/.subversion/config -# The same tweaks should be made on /home/scripts-build/.subversion/config -# once it exists (do something with svn as scripts-build) - - chown -R scripts-build /srv/repository - -# cd to server/fedora in the svn repository. - cd /srv/repository/server/fedora - -# Run "make install-deps" to install various prereqs. Nonstandard -# deps are in /mit/scripts/rpm. - YUM install -y make - make install-deps - -# Install bind - YUM install -y bind +# Copy over root's dotfiles from one of the other machines. +# Perhaps a useful change is to remove the default aliases + cd /root + ls -l .bashrc + ls -l .ldapvirc + ls -l .screenrc + ls -l .ssh + ls -l .vimrc + ls -l .k5login + # Trying to scp from server to server won't work, as scp + # will attempt to negotiate a server-to-server connection. + # Instead, scp to your trusted machine as a temporary file, + # and then push to the other server +scp -r root@$source_server:~/{.bashrc,.ldapvirc,.screenrc,.ssh,.vimrc,.k5login} . +scp -r {.bashrc,.ldapvirc,.screenrc,.ssh,.vimrc,.k5login} root@$server:~ + +# Install the initial set of credentials (to get Kerberized logins once +# krb5 is installed). Otherwise, SCP'ing things in will be annoying. +# o You probably installed the machine keytab long ago + ls -l /etc/krb5.keytab +# Use ktutil to combine the host/scripts.mit.edu and +# host/scripts-vhosts.mit.edu keys with host/this-server.mit.edu in +# the keytab. Do not use 'k5srvutil change' on the combined keytab +# or you'll break the other servers. (real servers only). Be +# careful about writing out the keytab: if you write it to an +# existing file the keys will just get appended. The correct +# credential list should look like: +# ktutil: l +# slot KVNO Principal +# ---- ---- --------------------------------------------------------------------- +# 1 5 host/old-faithful.mit.edu@ATHENA.MIT.EDU +# 2 3 host/scripts-vhosts.mit.edu@ATHENA.MIT.EDU +# 3 2 host/scripts.mit.edu@ATHENA.MIT.EDU +# o Replace the ssh host keys with the ones common to all scripts servers (real servers only) + ls -l /etc/ssh/*key* +# You can do that with: +scp root@$source_server:/etc/ssh/*key* . +scp *key* root@$server:/etc/ssh/ + service sshd reload # Check out the scripts /etc configuration + # backslash to make us not use the alias cd /root - svn co svn://scripts.mit.edu/$branch/server/fedora/config/etc etc - # backslash to make us not use the alias \cp -a etc / + chmod 0440 /etc/sudoers # NOTE: You will have just lost DNS resolution and the ability @@ -90,121 +95,57 @@ # you have named. - service named start - chkconfig named on - -# In the case of the Kerberos libraries, you'll be told that -# there are conflicting files with the 64-bit versions of the packages, -# which we scriptsify. You'll have to use --force to install those -# rpms despite the conflicts. After doing that, you may want to -# install the corresponding 64-bit scriptsified versions again, just -# to be safe in case the 32-bit versions overwrite files that differ. -# When you try this, it will complain that you already have the same -# version installed; again, you'll need to use --force to do it anyway. - -# We need yumdownloader to force some RPMs - # XXX: This might be wrong. Sanity check what packages ou - # have when done - YUM install -y yum-utils - yumdownloader krb5-libs - # XXX: These version numbers are hardcoded, need some cli-fu to generalize - rpm -i krb5-libs-*.i586.rpm - rpm -U --force krb5-libs-*.scripts.1138.x86_64.rpm - -# env NSS_NONLOCAL_IGNORE=1 yum install scripts-base - YUM install -y scripts-base - -# Remember to set NSS_NONLOCAL_IGNORE=1 anytime you're setting up -# anything, e.g. using yum. Otherwise useradd will query LDAP in a stupid way -# that makes it hang forever. (This is why we're using YUM, not yum) - -# Reload the iptables config to take down the restrictive firewall - service iptables restart - -# Copy over root's dotfiles from one of the other machines. -# Perhaps a useful change is to remove the default aliases - # On 2009-07-01, the dotfiles to transfer where: - # .bashrc .ldapvirc (<- HAS PRIVILEDGED DATA) - # .screenrc .ssh (<- directory) .vimrc - # Trying to scp from server to server won't work, as scp - # will attempt to negotiate a server-to-server connection. - # Instead, scp to your trusted machine as a temporary file, - # and then push to the other server - # You'll need some way to authenticate to the server, and since - # password logins are disabled, you'll need some way of - # temporarily giving yourself credentials. On a test server, - # reenabling password authentication is ok: frob /etc/pam.d/sshd - # and reverse apply r1068. +# NOTE: You can get password SSH back by editing /etc/ssh/sshd_config (allow +# password auth) and /etc/pam.d/sshd (comment out the first three auth +# lines). However, you should have the Kerberos credentials in place +# so as soon as you install the full set of Scripts packages, you'll get +# Kerberized logins. + +# Make sure network is working. If this is a new server name, you'll +# need to add it to /etc/hosts and +# /etc/sysconfig/network-scripts/route-eth1. Kickstart should have +# configured eth0 and eth1 correctly; use service network restart +# to add the new routes in route-eth1. + service network restart + route + ifconfig + cat /etc/hosts + cat /etc/sysconfig/network-scripts/route-eth1 + +# This is the point at which you should start updating scriptsified +# packages for a new Fedora release. Consult 'upgrade-tips' for more +# information. + yum install -y scripts-base + # Some of these packages are naughty and clobber some of our files + cd /etc + svn revert resolv.conf hosts sysconfig/openafs # Replace rsyslog with syslog-ng by doing: rpm -e --nodeps rsyslog - YUM install -y syslog-ng + yum install -y syslog-ng chkconfig syslog-ng on -# Install various dependencies of the scripts system, including -# glibc-devel.i586 (ezyang: already installed for me), -# python-twisted-core (ditto), mod_fcgid, nrpe, nagios-plugins-all. - YUM install -y mod_fcgid - YUM install -y nrpe - YUM install -y nagios-plugins-all - -# Disable NetworkManager with chkconfig NetworkManager off. Configure -# networking on the front end and back end, and the routing table to send -# traffic over the back end. Make sure that chkconfig reports "network" on, so -# that the network will still be configured at next boot. -# ezyang: For me, NetworkManager was not installed at this point, and -# we had already done the basic config for networking front end and -# back end (because I wanted ssh access, and not just conserver access) - -# Fix the openafs /usr/vice/etc <-> /etc/openafs mapping by changing -# /usr/vice/etc/cacheinfo to contain: -# /afs:/usr/vice/cache:10000000 -# Also fix ThisCell to contain athena.mit.edu in both directories -# WARNING: if you're installing a test server, this needs to be much -# smaller; the max filesize on XVM is 10GB. Pick something like -# 500000 +# Fix the openafs /usr/vice/etc <-> /etc/openafs mapping. echo "/afs:/usr/vice/cache:10000000" > /usr/vice/etc/cacheinfo - # ezyang: ThisCell on b-k and c-w don't have anything special - # written here -# If you're making a test server, some of the AFS parameters are -# kind of retarded (and if you're low on disk space, will actually -# exhaust our inodes). -# Edit the parameters in /etc/sysconfig/openafs - -# Figure out why Zephyr isn't working. Most recently, it was because there -# was a 64-bit RPM installed; remove it and install Joe's 32-bit one - YUM erase -y mit-zephyr - # mit-zephyr has a spurious dependency on mit-krb-config - yumdownloader mit-zephyr.i386 - # if deps change, this breaks - YUM install -y libXaw.i586 libXext.i586 libXmu.i586 ncurses-libs.i586 readline.i586 - rpm -i --nodeps mit-zephyr-2.1-6-linux.i386.rpm - # test if it worked by sending an un-authed message - zwrite -d -c scripts -i test - -# Install the athena-base, athena-lprng, and athena-lprng-misc RPMs -# from the Athena 9 build (these are present in our yum repo). Note -# that you will have to use --nodeps for at least one of the lprng -# ones because it thinks it needs the Athena hesiod RPM. It doesn't -# really. Before doing this, run it without --nodeps and arrange to -# install the rest of the things it really does depend on. This will -# include a bunch of 32-bit rpms; go ahead and install the .i586 versions -# of them. - YUM install -y athena-base - YUM install -y athena-lprng - yumdownloader athena-lprng-misc - # ezyang: I couldn't find any deps for this that existed in the repos - # You might get a "find: `/usr/athena/info': No such file or directory" - # error; this is fine - rpm -i --nodeps athena-lprng-misc-9.4-0.i386.rpm + echo "athena.mit.edu" > /usr/vice/etc/ThisCell + +# [TEST SERVER] If you're installing a test server, this needs to be +# much smaller; the max filesize on XVM is 10GB. Pick something like +# 500000. Also, some of the AFS parameters are kind of retarded (and if +# you're low on disk space, will actually exhaust our inodes). Edit +# these parameters in /etc/sysconfig/openafs + +# Test that zephyr is working + chkconfig zhm on + service zhm start + echo 'Test!' | zwrite -d -c scripts -i test # Install the full list of RPMs that users expect to be on the # scripts.mit.edu servers. - -# on another server, run: rpm -qa --queryformat "%{Name}.%{Arch}\n" | sort > packages.txt # arrange for packages.txt to be passed to the server, then run: - # notice that yum is not capitalized - # Also notice skip-broken - cat packages.txt | NSS_NONLOCAL_IGNORE=1 xargs yum install -y --skip-broken +# --skip-broken will (usually) prevent you from having to sit through +# several minutes of dependency resolution until it decides that +# it can't install /one/ package. + yum install -y --skip-broken $(cat packages.txt) # Check which packages are installed on your new server that are not @@ -212,34 +153,30 @@ # on the new machine. Otherwise, aside from bloat, you may end up # with undesirable things for security, like sendmail. - rpm -qa --queryformat "%{Name}.%{Arch}\n" | sort > newpackages.txt - diff -u packages.txt newpackages.txt | less - # if all went well, you'll probably see multiple kernel versions - # as the only diff - # ezyang: I got exim installed as another package + rpm -qa --queryformat "%{Name}.%{Arch}\n" | grep -v kernel | sort > newpackages.txt + diff -u packages.txt newpackages.txt | grep -v kernel | less # here's a cute script that removes all extra packages - diff -u packages.txt newpackages.txt | grep '+' | cut -c2- | grep -v "@" | grep -v "++" | xargs yum erase -y + yum erase -y $(grep -Fxvf packages.txt newpackages.txt) + +# We need an upstream version of cgi which we've packaged ourselves, but +# it doesn't work with the haskell-platform package which expects +# explicit versions. So temporarily rpm -e the package, and then +# install it again after you install haskell-platform. [Note: You +# probably won't need this in Fedora 15 or something, when the Haskell +# Platform gets updated.] + rpm -e ghc-cgi-devel ghc-cgi + yum install -y haskell-platform + yumdownloader ghc-cgi + yumdownloader ghc-cgi-devel + rpm -i ghc-cgi*1.8.1*.rpm # Check out the scripts /usr/vice/etc configuration - cd /root - mkdir vice - cd vice - svn co svn://scripts.mit.edu/trunk/server/fedora/config/usr/vice/etc etc + cd /root/vice \cp -a etc /usr/vice # Install the full list of perl modules that users expect to be on the # scripts.mit.edu servers. -# - export PERL_MM_USE_DEFAULT=1 -# - Run 'cpan', accept the default configuration, and do 'o conf -# prerequisites_policy follow'. -# - Parse the output of perldoc -u perllocal | grep head2 on an existing -# server, and "notest install" them from the cpan prompt. -# TO DO THIS: -# On another server, run: -# perldoc -u perllocal | grep head2 | cut -f 3 -d '<' | cut -f 1 -d '|' | sort -u | perl -ne 'chomp; print "notest install $_\n" if system("rpm -q --whatprovides \"perl($_)\" >/dev/null 2>/dev/null")' > /mit/scripts/config/perl-packages.txt -# Then on the server you're installing, -# cat perl-packages.txt | perl -MCPAN -e shell + cd /root export PERL_MM_USE_DEFAULT=1 - # XXX: Some interactive gobbeldygook - cpan + cpan # this is interactive, enter the next two lines o conf prerequisites_policy follow o conf commit @@ -257,5 +194,5 @@ # /usr/lib64/python2.6/site-packages for Python eggs and modules. # There will be a lot of gunk that was installed from packages; -# easy-install.pth will tell you what was easy_installed. +# easy-install.pth in /usr/lib/ will tell you what was easy_installed. # First use 'yum search' to see if the relevant package is now available # as an RPM, and install that if it is. If not, then use easy_install. @@ -263,44 +200,58 @@ # want to be able to write to ~/.python-eggs. (Also makes sourcediving # easier.) + cat /usr/lib/python2.6/site-packages/easy-install.pth # - Look at `gem list` for Ruby gems. # Again, use 'yum search' and prefer RPMs, but failing that, 'gem install'. # ezyang: rspec-rails depends on rspec, and will override the Yum # package, so... don't use that RPM yet +gem list --no-version > gem.txt + gem install $(gem list --no-version | grep -Fxvf - gem.txt) # - Look at `pear list` for Pear fruits (or whatever they're called). # Yet again, 'yum search' for RPMs before resorting to 'pear install'. Note # that for things in the beta repo, you'll need 'pear install package-beta'. # (you might get complaints about the php_scripts module; ignore them) +pear list | tail -n +4 | cut -f 1 -d " " > pear.txt + pear config-set preferred_state beta + pear channel-update pear.php.net + pear install $(pear list | tail -n +4 | cut -f 1 -d " " | grep -Fxvf - pear.txt) # - Look at `pecl list` for PECL things. 'yum search', and if you must, # 'pecl install' needed items. If it doesn't work, try 'pear install # pecl/foo' or 'pecl install foo-beta' or those two combined. - # Automating this... will require a lot of batonning between - # the servers. Probably best way to do it is to write an actual - # script. +pecl list | tail -n +4 | cut -f 1 -d " " > pecl.txt + pecl install --nodeps $(pecl list | tail -n +4 | cut -f 1 -d " " | grep -Fxvf - pecl.txt) # Setup some Python config echo 'import site, os.path; site.addsitedir(os.path.expanduser("~/lib/python2.6/site-packages"))' > /usr/lib/python2.6/site-packages/00scripts-home.pth -# Install the credentials. There are a lot of things to remember here: -# o This will be different if you're setting up our build/update server. -# o You probably installed the machine keytab long ago - ls -l /etc/krb5.keytab -# o Use ktutil to combine the host/scripts.mit.edu and -# host/scripts-vhosts.mit.edu keys with host/this-server.mit.edu in -# the keytab. Do not use 'k5srvutil change' on the combined keytab -# or you'll break the other servers. (real servers only) -# o The daemon.scripts keytab +# Install the credentials. There are a lot of things to remember here. +# Be sure to make sure the permissions match up (ls -l on an existing +# server!). +scp root@$source_server:{/etc/{sql-mit-edu.cfg.php,daemon.keytab,pki/tls/private/scripts.key,signup-ldap-pw,whoisd-password},/home/logview/.k5login} . +scp daemon.keytab signup-ldap-pw whoisd-password sql-mit-edu.cfg.php root@$server:/etc +scp scripts.key root@$server:/etc/pki/tls/private +scp .k5login root@$server:/home/logview + chown afsagent:afsagent /etc/daemon.keytab +# o The daemon.scripts keytab (will be daemon.scripts-test for test) ls -l /etc/daemon.keytab # o The SSL cert private key (real servers only) + ls -l /etc/pki/tls/private/scripts.key # o The LDAP password for the signup process (real servers only) -# o The SQL password for the signup process (real servers only) + ls -l /etc/signup-ldap-pw # o The whoisd password (real servers only) -# o The LDAP keytab for this server, which will be used later (real servers only) -# o Replace the ssh host keys with the ones common to all scripts servers (real servers only) -# o You'll install an LDAP certificate signed by the scripts CA later (real servers only) -# o Make sure root's .k5login is correct - cat /root/.k5login + ls -l /etc/whoisd-password # o Make sure logview's .k5login is correct (real servers only) - -# If you are setting up a test server, pay attention to + cat /home/logview/.k5login + +# Spin up OpenAFS. This will fail if there's been a new kernel since +# when you last tried. In that case, you can hold on till later to +# start OpenAFS. This will take a little bit of time; + service openafs-client start + +# Check that fs sysname is correct. You should see, among others, +# 'amd64_fedoraX_scripts' (vary X) and 'scripts'. If it's not, you +# probably did a distro upgrade and should update /etc/sysconfig/openafs. + fs sysname + +# [TEST SERVER] If you are setting up a test server, pay attention to # /etc/sysconfig/network-scripts and do not bind scripts' IP address. # You will also need to modify: @@ -322,14 +273,22 @@ # XXX: someone should write sed scripts to do this -# If you are setting up a test server, afsagent's cronjob will attempt -# to be renewing with the wrong credentials (daemon.scripts). Change this: +# [TEST SERVER] If you are setting up a test server, afsagent's cronjob +# will attempt to be renewing with the wrong credentials +# (daemon.scripts). Change this: vim /home/afsagent/renew # replace all mentions of daemon.scripts.mit.edu -# Install 389-ds-base and set up replication (see ./HOWTO-SETUP-LDAP -# and ./389-ds-enable-ssl-and-kerberos.diff). +# Set up replication (see ./install-ldap). +# You'll need the LDAP keytab for this server: be sure to chown it +# fedora-ds after you create the fedora-ds user + ls -l /etc/dirsrv/keytab + cat install-ldap # Make the services dirsrv, nslcd, nscd, postfix, and httpd start at # boot. Run chkconfig to make sure the set of services to be run is # correct. + service nslcd start + service nscd start + service postfix start + service httpd start chkconfig dirsrv on chkconfig nslcd on @@ -341,4 +300,7 @@ chkconfig nrpe on +# Check sql user credentials (needs to be done after LDAP is setup) + chown sql /etc/sql-mit-edu.cfg.php + # Postfix doesn't actually deliver mail; fix this cd /etc/postfix @@ -349,6 +311,6 @@ # Run fmtutil-sys --all, which does something that makes TeX work. +# (Note: this errors on XeTeX which is ok.) fmtutil-sys --all - # ezyang: I got errors on xetex # Ensure that PHP isn't broken: @@ -356,11 +318,12 @@ chmod 01777 /tmp/sessions -# Ensure fcgid isn't broken - chmod 755 /var/run/mod_fcgid # ezyang: I suspect this is no longer necessary +# Ensure fcgid isn't broken (should be 755) + ls -ld /var/run/mod_fcgid # Fix etc by making sure none of our config files got overwritten cd /etc - svn status | grep M - # ezyang: I had to revert krb5.conf (not with latest), nsswitch.conf and sysconfig/openafs + svn status -q + # Some usual candidates for clobbering include nsswitch.conf and + # sysconfig/openafs # ThisCell got clobbered, replace it with athena.mit.edu @@ -368,23 +331,12 @@ # Reboot the machine to restore a consistent state, in case you -# changed anything. - # ezyang: When I rebooted, the following things happened: - # o Starting kdump failed (this is ok) - # o postfix mailbombed us - # o firstboot configuration screen popped up (ignored; manually will do - # chkconfig after the fact) - -# (Optional) Beat your head against a wall. - -# Possibly perform other steps that I've neglected to put in this -# document. -# o For some reason, syslog-ng wasn't turning on automatically, so we weren't -# getting spew - -# Some info about changing hostnames: it appears to be in: +# changed anything. (Note: Starting kdump fails (this is ok)) + +# [OPTIONAL] Your machine's hostname is baked in at install time; +# in the rare case you need to change it: it appears to be in: # o /etc/sysconfig/network # o your lvm thingies; probably don't need to edit -# More stuff for test servers +# [TEST SERVER] More stuff for test servers # - You need a self-signed SSL cert. Generate with: openssl req -new -x509 -keyout /etc/pki/tls/private/scripts.key -out /etc/pki/tls/certs/scripts.cert -nodes @@ -394,2 +346,12 @@ # be an accepted vhost name # - Look at the old test server and see what config changes are floating around + +# XXX: our SVN checkout should be updated to use scripts.mit.edu +# (repository and etc) once serving actually works. + cd /etc + svn switch --relocate svn://$source_server/ svn://scripts.mit.edu/ + cd /usr/vice/etc + svn switch --relocate svn://$source_server/ svn://scripts.mit.edu/ + cd /srv/repository + asbuild svn switch --relocate svn://$source_server/ svn://scripts.mit.edu/ + asbuild svn up # verify scripts.mit.edu works Index: trunk/server/doc/install-ldap =================================================================== --- trunk/server/doc/install-ldap (revision 1693) +++ trunk/server/doc/install-ldap (revision 1693) @@ -0,0 +1,354 @@ +To set up a new LDAP server: + +- Install the RPM 389-ds-base with yum (these are installed by kickstart + these days, so these two steps are probably not necessary) + root# yum install -y 389-ds-base + root# yum install -y policycoreutils-python + root# yum install -y ldapvi +- We want to run the directory server as its own user, so create fedora-ds + root# useradd -r -d /var/lib/dirsrv fedora-ds +- Temporarily move away the existing slapd-scripts folder + root# mv /etc/dirsrv/slapd-scripts{,.bak} +- root# /usr/sbin/setup-ds.pl + - Choose a typical install + - Tell it to use the fedora-ds user and group + - Directory server identifier: scripts + Needed to remove this from the config file first + - Suffix: dc=scripts,dc=mit,dc=edu + - Input directory manager password + (this can be found in ~/.ldapvirc) +- Move the schema back + root# cp -R /etc/dirsrv/slapd-scripts.bak/{.svn,*} /etc/dirsrv/slapd-scripts + root# rm -Rf /etc/dirsrv/slapd-scripts.bak +- Turn dirsrv off: service dirsrv stop +- Apply the following configuration changes. If you're editing + dse.ldif, you don't want dirsrv to be on, otherwise it will + overwrite your changes. [XXX: show how to do these changes with + dsconf, which is the "blessed" method] + +# Inside cn=config. These changes definitely require a restart. +nsslapd-ldapifilepath: /var/run/dirsrv/slapd-scripts.socket +nsslapd-ldapilisten: on + +# Add these blocks + +# mapname, mapping, sasl, config +# This is the most liberal mapping you can have for SASL: you can +# basically add authentication for any given GSSAPI mechanism by +# explicitly creating the UID for that SASL string. +dn: cn=mapname,cn=mapping,cn=sasl,cn=config +objectClass: top +objectClass: nsSaslMapping +cn: mapname +nsSaslMapRegexString: \(.*\) +nsSaslMapBaseDNTemplate: uid=\1,ou=People,dc=scripts,dc=mit,dc=edu +nsSaslMapFilterTemplate: (objectClass=posixAccount) + +- Put LDAP keytab (ldap/hostname.mit.edu) in /etc/dirsrv/keytab. Make + sure you chown/chgrp it to be readable by fedora-ds +- Uncomment and modify in /etc/sysconfig/dirsrv: KRB5_KTNAME=/etc/dirsrv/keytab ; export KRB5_KTNAME +- chown fedora-ds:fedora-ds /var/run/dirsrv +- chmod 755 /var/run/dirsrv +- /sbin/service dirsrv start +- Use ldapvi -b cn=config to add these indexes (8 of them): + +add cn=apacheServerName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: apacheServerName +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +add cn=apacheServerAlias, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: apacheServerAlias +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +add cn=scriptsVhostName, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: scriptsVhostName +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +add cn=scriptsVhostAlias, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: scriptsVhostAlias +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +add cn=scriptsVhostAccount, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: scriptsVhostAccount +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +add cn=memberuid, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: memberuid +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +add cn=uidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: uidnumber +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +add cn=gidnumber, cn=index, cn=userRoot, cn=ldbm database, cn=plugins, cn=config +objectClass: top +objectClass: nsIndex +cn: gidnumber +nsSystemIndex: false +nsIndexType: eq +nsIndexType: pres + +- Build the indexes for all the fields: + + /usr/lib64/dirsrv/slapd-scripts/db2index.pl -D "cn=Directory Manager" -j /etc/signup-ldap-pw -n userRoot + + (/etc/signup-ldap-pw is the LDAP root password, make sure it's + chmodded correctly and chowned to signup. Also, make sure it doesn't + have a trailing newline!) + +- Watch for the indexing operations to finish with this command: + + ldapsearch -x -y /etc/signup-ldap-pw -D 'cn=Directory Manager' -b cn=tasks,cn=config + + (look for nktaskstatus) + +- Set up replication. + + We used to tell people to go execute + http://directory.fedoraproject.org/sources/contrib/mmr.pl manually + (manually because that script assumes only two masters and we have + every one of our servers set up as a master.) However, those + instructions are inaccurate, because we use GSSAPI, not SSL and + because the initializing procedure is actually prone to a race + condition. Here are some better instructions. + + LDAP replication is based around producers and consumers. Producers + push changes in LDAP to consumers: these arrangements are called + "replication agreements" and the producer will hold a + nsDS5ReplicationAgreement object that represents this commitment, + as well as some extra configuration to say who consumers will accept + replication data from (a nsDS5Replica). + + The procedure, at a high level, is this: + + 1. Pick an arbitrary existing master. The current server will + be configured as a slave to that master. Initialize a changelog, + then request a replication to populate our server with + information. + + M1 <---> M2 ---> S + + 2. Configure the new server to be replicated back. + + M1 <---> M2 <---> S + + 3. Set up the rest of the replication agreements at your leisure. + + M1 <---> M2 + ^ ^ + | | + +--> S <--+ + + Here's how you do it. + + 1. Pull open the replication part of the database. It's fairly empty + right now. + + ldapvi -b cn=\"dc=scripts,dc=mit,dc=edu\",cn=mapping\ tree,cn=config + + 2. Configure the server $SLAVE (this server) to accept $MASTER + replications by adding the following LDAP entries: + +add cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config +objectClass: top +objectClass: nsDS5Replica +cn: replica +nsDS5ReplicaId: $REPLICA_ID +nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu +nsDS5Flags: 1 +nsDS5ReplicaBindDN: uid=ldap/bees-knees.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindDN: uid=ldap/busy-beaver.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindDN: uid=ldap/cats-whiskers.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindDN: uid=ldap/pancake-bunny.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindDN: uid=ldap/whole-enchilada.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindDN: uid=ldap/real-mccoy.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindDN: uid=ldap/better-mousetrap.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindDN: uid=ldap/old-faithful.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +# ADD SERVERS HERE AS YOU ADD NEW SERVERS +nsds5ReplicaPurgeDelay: 604800 +nsds5ReplicaLegacyConsumer: off +nsDS5ReplicaType: 3 + + $REPLICA_ID is the scripts$N number (stella $HOSTNAME to find + out.) You might wonder why we are binding to all servers; + weren't we going to replicate from only one server? That is + correct, however, simply binding won't mean we will receive + updates; we have to setup the $MASTER to send data $SLAVE. + + 3. Although we allowed those uids to bind, that user information + doesn't exist on $SLAVE yet. So you'll need to create the entry + for just $MASTER. + +add uid=ldap/$MASTER,ou=People,dc=scripts,dc=mit,dc=edu +uid: ldap/$MASTER +objectClass: account +objectClass: top + + 4. Though our $SLAVE will not be making changes to LDAP, we need to + initialize the changelog because we intend to be able to do this + later. + +add cn=changelog5,cn=config +objectclass: top +objectclass: extensibleObject +cn: changelog5 +nsslapd-changelogdir: /etc/dirsrv/slapd-scripts/changelogdb + + 5. Ok, now go to your $MASTER server that you picked (it should have + been one of the hosts mentioned in nsDS5ReplicaBindDN) and tell + it to replicate to $SLAVE. + + The last line runs the replication. This is perhaps the most + risky step of the process; see below for help debugging problems. + + WARNING: There is a known bug doing full updates from 1.2.6 to + 1.2.6, see https://bugzilla.redhat.com/show_bug.cgi?id=637852 + +add cn="GSSAPI Replication to $SLAVE", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config +objectClass: top +objectClass: nsDS5ReplicationAgreement +cn: "GSSAPI Replication to $SLAVE" +cn: GSSAPI Replication to $SLAVE +nsDS5ReplicaHost: $SLAVE +nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu +nsDS5ReplicaPort: 389 +nsDS5ReplicaTransportInfo: LDAP +nsDS5ReplicaBindDN: uid=ldap/$MASTER,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindMethod: SASL/GSSAPI +nsDS5ReplicaUpdateSchedule: "0000-2359 0123456" +nsDS5ReplicaTimeout: 120 +nsDS5BeginReplicaRefresh: start + + 5. Check that the replication is running; the status will be stored + in the object we've been mucking around with. + + If it fails with LDAP Error 49, check /var/log/dirsrv on $MASTER + for more information. It might be because fedora-ds can't read + /etc/dirsrv/keytab + + 6. Replicate in the other direction. On $MASTER, add $SLAVE + as a nsDS5ReplicaBindDN in cn=replica,cn="dc=scripts,dc=mit,dc=edu",cn=mapping tree,cn=config + Also, add an account for $SLAVE + +add uid=ldap/$SLAVE,ou=People,dc=scripts,dc=mit,dc=edu +uid: ldap/$SLAVE +objectClass: account +objectClass: top + + On $SLAVE, + +add cn="GSSAPI Replication to $MASTER", cn=replica, cn="dc=scripts,dc=mit,dc=edu", cn=mapping tree, cn=config +objectClass: top +objectClass: nsDS5ReplicationAgreement +cn: "GSSAPI Replication to $MASTER" +cn: GSSAPI Replication to $MASTER +nsDS5ReplicaHost: $MASTER +nsDS5ReplicaRoot: dc=scripts,dc=mit,dc=edu +nsDS5ReplicaPort: 389 +nsDS5ReplicaTransportInfo: LDAP +nsDS5ReplicaBindDN: uid=ldap/$SLAVE,ou=People,dc=scripts,dc=mit,dc=edu +nsDS5ReplicaBindMethod: SASL/GSSAPI +nsDS5ReplicaUpdateSchedule: "0000-2359 0123456" +nsDS5ReplicaTimeout: 120 + + If you get a really scary internal server error, that might mean you + forgot to initialize the changelog. Remove the replication + agreement (you'll need to turn off dirsrv), add the changelog, and + then try again. + +Troubleshooting +=============== + +LDAP multimaster replication can fail in a number of colorful ways; +combine that with GSSAPI authentication and it goes exponential. + +If authentication is failing with LDAP error 49, check if: + + * /etc/dirsrv/keytab + * fedora-ds is able to read /etc/dirsrv/keytab + * /etc/hosts has not been modified by Network Manager (you + /did/ uninstall it, right? Right?) + +If the failure is local to a single master, usually you can recover +by asking another master to refresh that master with: + +nsDS5BeginReplicaRefresh: start + +In practice, we've also had problems with this technique. Some of them +include: + +* Something like https://bugzilla.redhat.com/show_bug.cgi?id=547503 + on Fedora 11 ns-slapd, where replication is turned off to do the + replication, but then it wedges and you need to forcibly kill the + process. + +* Failed LDAP authentication because another master attempted to do + an incremental update. + +* Repropagation of the error because the corrupt master thinks it still + should push updates. + +So the extremely safe method to bring up a crashed master is as follows: + +1. Disable all incoming and outgoing replication agreements by editing + /etc/dirsrv/slapd-scripts/dse.ldif. You'll need to munge: + + nsDS5ReplicaBindDN in cn=replica,cn=dc\3Dscripts\2Cdc\3Dmit\2Cdc\3Dedu,cn=mapping tree,cn=config + + and all of the push agreements. Deleting them outright works, but + means you'll have to reconstruct all of the agreements from scratch. + +2. Bring up the server. + +3. Accept incoming replication data from a single server. + +4. Initiate a full update from that server. + +5. Finish setting up replication as described above. + +If your database gets extremely fucked, other servers may not be able +to authenticate because your authentication information has gone missing. +In that case, the minimal set of entries you need is: + +add dc=scripts,dc=mit,dc=edu +objectClass: top +objectClass: domain +dc: scripts + +add ou=People,dc=scripts,dc=mit,dc=edu +objectClass: top +objectClass: organizationalunit +ou: People + +add uid=ldap/whole-enchilada.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu +objectClass: account +objectClass: top +uid: ldap/whole-enchilada.mit.edu Index: trunk/server/doc/install-xen =================================================================== --- trunk/server/doc/install-xen (revision 1687) +++ trunk/server/doc/install-xen (revision 1693) @@ -43,2 +43,6 @@ git clone ssh://scripts@scripts.mit.edu/mit/scripts/git/xen.git /etc/xen +# setup conserver + cat /etc/conserver/console.cf # add the correct entires here + visudo # add conservr to sudoers list with: + conservr ALL=(ALL) NOPASSWD: /usr/sbin/xm console * Index: trunk/server/doc/install-xvm =================================================================== --- trunk/server/doc/install-xvm (revision 1693) +++ trunk/server/doc/install-xvm (revision 1693) @@ -0,0 +1,48 @@ +Installing a test scripts server on XVM +======================================= + +It's useful to have a less secure scripts server for testing +purposes. Here's what you have to do: + +1. Creating the VM +------------------ + +To authenticate to xvm.mit.edu with root tickets, you need +a browser that suppors SPNEGO; Firefox is one such browser and +the following instructions will assume it. Browse to about:config +and modify the key 'network.negotiate-auth.trusted-uris' to be + + https://xvm.mit.edu:442/* + +Then, with active root tickets on your system, navigate to + + https://xvm.mit.edu:442/ + +You should be logged in as root, and if you are on scripts-root +you should be able to assign ownership to scripts. + +[XXX: there should be a way to do this with remctl too] + +2. Spin up +---------- + +These instructions are mostly the same as the latter part of +install-fedora, with the following changes: + +VNC +--- + +You will not need to sketchily forward VNC, because XVM has a built +in VNC console. + +Password +-------- + +Do NOT use the scripts-root password. Pick something else. + +Disks +----- + +The standard Scripts setup has separate LVM partitions for root and +swap, as well as a non-LVM partition for boot. You will not have this +for XVM, so the Fedora defaults mostly work. Don't use ext4 though. Index: trunk/server/doc/kernel-build-howto =================================================================== --- trunk/server/doc/kernel-build-howto (revision 1687) +++ trunk/server/doc/kernel-build-howto (revision 1693) @@ -19,4 +19,7 @@ [root@old-faithful ~]# rpm -ivh kernel-vanilla{,-devel}-2.6.23.8-28.scripts1.fc7.x86_64.rpm +You can build kernel-firmware, which is a bunch of binary blobs for +hardware, by running the mock build with --arch=noarch. + Index: trunk/server/doc/ldap-kerberos-replication.txt =================================================================== --- trunk/server/doc/ldap-kerberos-replication.txt (revision 1693) +++ trunk/server/doc/ldap-kerberos-replication.txt (revision 1693) @@ -0,0 +1,93 @@ +How to migrate from SSL authentication to GSSAPI authentication +=============================================================== + + :author: Edward Z. Yang + :author: Geoffrey Thomas + +NOTE: This document is strictly for HISTORICAL purposes. It may +come in handy if you ever need to migrate from SSL to GSSAPI on +another LDAP setup, though! This assumes that ldap service keytabs +are setup properly on all hosts involved. + +---- + +On $CONSUMER (e.g. real-mccoy.mit.edu) + +To cn=replica,cn="dc=scripts,dc=mit,dc=edu",cn=mapping tree,cn=config: +Add nsDS5ReplicaBindDN: uid=ldap/$PRODUCER,ou=People,dc=scripts,dc=mit,dc=edu + This tells the CONSUMER to accept replication pushes from PRODUCER. + However, PRODUCER is not configured yet, so you should keep + the cn=repman,cn=config entry which is old style. + +Create uid=ldap/$PRODUCER,ou=People,dc=scripts,dc=mit,dc=edu +uid: ldap/$PRODUCER +objectClass: account +objectClass: top + This creates the LDAP user entry for GSSAPI authentication via the + service keytab of LDAP replication. This information /is/ + replicated, so if you felt like it you could create entries for all + PRODUCERS (which, in full multimaster replication, is all servers.) + +---- + +On $PRODUCER (e.g. cats-whiskers.mit.edu) + You will destroy and recreate a replication agreement (well, + actually, ldapvi will attempt to create and then destroy the old + agreement). + +To cn="SSL Replication to $CONSUMER",cn=replica,cn="dc=scripts,dc=mit,dc=edu",cn=mapping tree,cn=config +Replace all instances of "SSL Replication" to "GSSAPI Replication" +Replace the number on the entry with 'add'; to indicate destroy/recreate +Replace nsDS5ReplicaBindDN: uid=ldap/cats-whiskers.mit.edu,ou=People,dc=scripts,dc=mit,dc=edu + (instead of cn=repman,cn=config) +Replace nsDS5ReplicaTransportInfo: LDAP + (instead of SSL) +Replace nsDS5ReplicaPort: 389 + (instead of 636) +Replace nsDS5ReplicaBindMethod: SASL/GSSAPI + (instead of simple) +Remove nsDS5ReplicaCredentials + +Here are some search-replace lines that will probably do what you want, +but be sure to double check how many substitutions were made. '<,'> lines +should exclude the cn=replica section. + + # n = NUMBER OF SERVERS - 1 = 4 + # n*3 substitutions + :%s/SSL Replication/GSSAPI Replication/g + # n substitutions + :'<,'>s/cn=repman,cn=config/uid=ldap\/$HOST,ou=People,dc=scripts,dc=mit,dc=edu/g + :%s/simple/SASL\/GSSAPI/ + :%s/nsDS5ReplicaPort: 636/nsDS5ReplicaPort: 389/ + :%s/SSL/LDAP/g + :%s/^nsDS5ReplicaCredentials.\+\n//g + :'<,'>s/^nsds5replicareapactive: 0\n//g + :%s/^[1-9] /add /g # fix if more than 9 servers + +There is some cleanup that needs to happen after these values change; +I had luck forcibly rebooting the servers and making LDAP cleanup +after an unclean shutdown. You can tell if this cleanup is necessary +if LDAP refuses to start replication sessions. This issue is known to +clear up after several reboots or by destroying and recreating all +replicas. + +---- + +Once everything is on the new replication and you verify it's working +correctly, you should then clean out the SSL configuration (most +notably, turn nsslapd-security off. Despite its ominous name, it only +controls SSL authentication, not GSSAPI authentication.) You will need +to take the server offline to do that; edit +/etc/dirsrv/slapd-scripts/dse.ldif + +When that's gone, there may be some vestigial SSL configuration left. +Scripts specifically had the following sections that needed to be +cleaned up: + + cn=RSA,cn=encryption,cn=config + (whole thing) + cn=encryption,cn=config + nsSSL3: on [change to off] + nsSSL3Ciphers: +rsa_rc4_128_md5 [delete] + cn=config + nsslapd-sslclientauth: on [change to off] Index: trunk/server/doc/package-build-howto =================================================================== --- trunk/server/doc/package-build-howto (revision 1687) +++ trunk/server/doc/package-build-howto (revision 1693) @@ -146,2 +146,7 @@ overwrite any changes you made in place). +Tips +==== + + * Don't try to build a 32-bit package without building the 64-bit + package as well. Index: trunk/server/doc/upgrade-tips =================================================================== --- trunk/server/doc/upgrade-tips (revision 1693) +++ trunk/server/doc/upgrade-tips (revision 1693) @@ -0,0 +1,186 @@ +Upgrading Scripts for a new Fedora distribution +=============================================== + +1. Gather knowledge +------------------- + +You should read the Release Notes for all of the intervening +releases. For example, here are the Fedora 13 release notes: + + http://docs.fedoraproject.org/en-US/Fedora/13/html/Release_Notes/ + +Because we sometimes skip releases, you should read any skipped +release's report notes. + +Example: + + In Fedora 12, i586 was deprecated in favor of i686; this meant + that any parts of Scripts that referenced i586 explicitly had to + changed to i686. + +2. Update the Scripts build environment +--------------------------------------- + +A large amount of the Scripts source repository is Fedora Release +specific, so when you are ramping up the new release, you will want +a new branch to do development on, before merging back upon the +official release. You can do this with: + + svn cp svn://scripts.mit.edu/trunk \ + svn://scripts.mit.edu/branches/fcXX-dev + +On the new branch, there are a number of files you will have to +update: + +2.1 Mock + +Mock needs to be setup for the new environment. The first thing to do +is to update the Makefile by substituting +s/scripts-fcOLD/scripts-fcNEW/g on the /usr/bin/mock invocations. +After that, you need to go to /etc/mock and create the new cfg file +for the new scripts-fcXX-ARCH configurations (where ARCH is x86_64 and +i386). You can base the new cfg off of the older version's, however +you will want to make the following changes: + + * Update all references to the old Fedora release to the new + Fedora release. This includes root, dist, mirrorlist, baseurl + + * Temporarily disabling the web.mit.edu Scripts RPM repository + and the local RPM repository by setting enabled=0 (it's there for + a reason!) However, the local RPM repository is fairly painless + to create and will come in handy when you start attempting to + build packages that have dependencies on other scriptsified + packages: you can set one up as scripts-build with: + + mkdir ~/mock-local + createrepo ~/mock-local + +3. Rebuild Scripts packages +--------------------------- + +In order to support specific extra functionality, we have scriptsified +a variety of Fedora packages. When the base packages get upgrades, +we need to upgrade the scriptsification. Some of the following topics +are covered in 'package-build-howto', but a new Fedora release tends +to also result in somewhat rarer situations. + +As you finish building packages, you'll want to place them somewhere +so they don't get blown away on a successive mock build. ~/mock-local +is a good choice. The Mock RPMs will be created in: + + /var/lib/mock/$MOCK_ENV/result/ + +Here are some of the common troubles you'll have to deal with: + +3.1 Spec patches are no longer necessary + +When a Fedora release gets EOL'ed, we may continue to backport +patches for CVE's manually. When we upgrade to a non-EOL'd release, +those patches will generally become unnecessary and can be dropped. + +You can drop a modified specfile from the repository simply by +`svn rm`ing: + + * The spec patch in server/fedora/specs, + * The source code patch in server/common/patches, and + * The upstream_yum entry in server/fedora/Makefile + +If a specfile merely bumps the version field, there may be no extra +patch (this indicates that the maintainer rebuilt the package simply +by manually dropping the new source tarball in rpmbuild/SOURCES, +which is kind of sketchy but works. See -c 1586 for an example.) + +3.2 Spec patches no longer apply + +Symptom: + + $ make patch-specs + patching file openssh.spec + Hunk #1 succeeded at 74 with fuzz 2 (offset 11 lines). + Hunk #2 failed at 88. + Hunk #3 succeeded at 177 (offset 14 lines). + Hunk #4 succeeded at 270 with fuzz 2 (offset 36 lines). + 1 out of 4 hunks failed--saving rejects to openssh.spec.rej + +Fix: + + The main thing to remember is where the generated files live + they are placed in rpmbuild/SPECS/openssh.spec{.rej,.orig}. + A workflow for fixing them might look like: + + 1. Inspect the rejects file. + 2. As much as possible, manually fix the original diff + file in /srv/repository/server/fedora/specs + 3. If absolutely necessary, edit the rpmbuild/SPECS/openssh.spec + file with any final changes (this is dangerous because + this file is blown away on a successive make) + 4. Generate a new unified diff: + diff -u openssh.spec.orig openssh.spec > \ + /srv/repository/server/fedora/specs\openssh.spec.patch + +3.3 Mock fails with no error message + +Fix: You forgot to add scripts-build to the mock group. See + https://bugzilla.redhat.com/show_bug.cgi?id=630791 + [XXX: remove this entry when this bug is fixed] + +3.4 Source patches no longer apply + +Symptoms: + + Generally, you will see these error messages after Mock starts + building (if they occur before Mock, that means it's a bug in the + spec patch, not a source patch that the spec patch references.) + +Fix: + + The error message will be from within a schroot that Mock is using. + As a result, it's not immediately obvious where the files live. + + The easiest approach is to use rpmbuild to manually reapply the + patches. + + rpmbuild -bp path/to/foo.spec + + If this fails complaining about a dependency, you should install + the dependency and add it to the Makefile. + + Once you've fixed the patch, you can rerun rpmbuild after running + + make setup + + (This is useful if you can't do a full make due to another mock + process running.) + +4. "Officializing" everything +----------------------------- + +web.mit.edu scripts repository (/mit/scripts/rpm-fcXX and +/mit/scripts/rpm-fcXX-testing) needs to be made. It's quite simple; +all you need to do is copy the RPMs from the build server to there +(probably going through a trusted machine, since you don't want to +put your root tickets on a server.) When you're done, run `createrepo` +on the directory. + +Note that if you do a successive rebuild without bumping the Subversion +revision (via a `svn up`), the new package will have the *same* version +and yum will probably insist on using the old cached version. You can +use `yum clean all` to reset your cache and force yum to get the latest +version. + +5. Update fs sysname +-------------------- + +Update /etc/sysconfig/openafs with an extra amd64_fedoraX_scripts and +amd64_fedoraX sysname. The format should be evident from the existing +entries. [XXX There might be other things you want] + +6. Extra stuff +-------------- + +Fedora occasionally updates the architecture name for 32-bit; the last +such update was in Fedora 12, when i586 became i686. Fixing this +usually just involves replacing i586 with i686 in the appropriate places +(Makefile, specfiles, /etc/mock configuration). Note that for +hysterical raisins we still refer to our 32-bit builds as i386. +[XXX: Maybe this should change]