admins-discuss

Download

admins-discuss@lists.redbrick.dcu.ie

February 2009

3 participants
2 discussions

[Admin-discuss] Murphy installation (Jan 2009, Volume 2, Issue 1, out now at your local newsagent)
by Andrew Martin 04 Apr '09

04 Apr '09

Hey all, Just a quick update/summary on what's going on with murphy, if ye haven't been reading the details in the other threads. Right now, it's sitting there scratching itself running OpenBSD 4.4. Testing went great, but web services are still on deathray. As soon as we switched apache on when we tried to move it over in production, the kernel started panicing. We suspect it's related to the NFS server (minerva) being too slow to keep up, and murphy not quite knowing what to do. However, as none of us happen to be OpenBSD kernel developers (or well versed in SPARC assembly language), we're really just making guesses based on debug output. We're planning to submit the bug to the OpenBSD project, but all we can really do then is wait. While the NFS server does need to be sped up, it should not cause the web server to fail. It *definitely* shouldn't cause it to kernel panic. This leaves us with the original option of going back to Solaris 10 (sob). With that in mind, I spent a few hours over the last couple of days putting together a test installation of Solaris 10 (x86, but everything I'm doing should be the same for SPARC) in a VM on my desktop. I've gotten it to the point where the OS (and all software *currently* on it) can be easily kept up to date (with patch check advanced). No Sunfreeware packages are installed, and I'd like to keep it like that for the time being. It's connecting to redbrick's LDAP and authing off it using the native ldapclient. I'm just about to start working on a system to compile and install apache packages, and some scripts to keep them up to date at the moment. The aim is to have it at a point where you can update the entire system using at most two tools (pca, and script for checking and updating apache/everything required by www). The next thing I'd like to do is put solaris onto murphy, everything in the instructions (below) up to where it says "VM checkpoint 2". That would make it a login machine with very little userland stuff installed. Compiling apache in a KVM VM seems to be taking forever, it would be less painful on the actual machine. Does anyone have any objections to this? OpenBSD is, as I said, doing nothing right now. I could take a backup of the whole thing if we really want to try it again though. -Andrew Copypasta of setup notes below -------- Solaris 10 setup guide ----------- ***WORK IN PROGRESS, feedback welcome though*** ---- Install ---- * Custom installation * Install locale Western Europe>Ireland * Default: en_IE.UTF-8 * Core software group only * No networked services option ---- Post-install ---- * Mount dvd # mount -F hsfs -o ro /dev/dsk/c1t0d0s0 /mnt * Install SSH: SUNWsshcu SUNWsshdr SUNWsshdu SUNWsshr SUNWsshu # pkgadd -d /mnt/Solaris_10/Product SUNWsshcu SUNWsshdr SUNWsshdu SUNWsshr SUNWsshu * Generate SSH key (rsa) * Install documentation: SUNWdoc SUNWman # pkgadd -d /mnt/Solaris_10/Product SUNWdoc SUNWman * Install bash, zsh and tcsh SUNWbash SUNWzsh SUNWtcsh # pkgadd -d /mnt/Solaris_10/Product SUNWbash SUNWzsh SUNWtcsh > VM Checkpoint 1 < * Install wget and perl for PCA SUNWperl584usr SUNWperl584man SUNWperl584core SUNWperl-xml-parser SUNWgcmn SUNWwgetr SUNWwgetu # pkgadd -d /mnt/Solaris_10/Product SUNWperl584usr SUNWperl584man SUNWperl584core SUNWperl-xml-parser SUNWgcmn SUNWwgetr SUNWwgetu * Install PCA # cd /root # /usr/sfw/bin/wget http://www.par.univie.ac.at/solaris/pca/stable/pca # chmod 755 pca Move it somewhere more appropriate? * Run PCA (simulation). From within DCU, export http_proxy (or set it in .wgetrc) # ./pca --download --pretend -a (wait bloody ages - who'd have thought patching 10u3 over gateway's connection would take a while >.<) * Run PCA # ./pca --download --install -a (reconfiguration reboot, lather, rinse, repeat, until it stops giving you orders. This step will also take a while.) After you're done, don't forget to remount the DVD, you'll need more packages from it later. ---- Authentication (LDAP and local accounts) ---- * Edit nsswitch.ldap to sane settings. For some reason, sun think LDAP should do the work of a DNS server. Everything should just be set to "files" (NOT "files ldap" or "ldap files" or anything in between). The exceptions (and their required settings) are as follows: passwd: files ldap group: files ldap hosts: files dns ipnodes: files dns printers: user files When you edit nsswitch.ldap, the settings will not take effect. They will only be used when you run the ldapclient command (next step), which will copy nsswitch.ldap over nsswitch.conf. * Configure ldapclient to work with an openldap server (replace LDAP_ROOT_PASSWORD and IP.OF.LDAP.SERVER): # ldapclient -v manual \ -a domainName=redbrick.dcu.ie \ -a defaultSearchBase=o=redbrick \ -a serviceSearchDescriptor=passwd:ou=accounts,o=redbrick \ -a serviceSearchDescriptor=group:ou=groups,o=redbrick \ -a attributeMap=group:userpassword=userPassword \ -a attributeMap=group:memberuid=memberUid \ -a attributeMap=group:gidnumber=gidNumber \ -a attributeMap=passwd:gecos=cn \ -a attributeMap=passwd:gidnumber=gidNumber \ -a attributeMap=passwd:uidnumber=uidNumber \ -a attributeMap=passwd:homedirectory=homeDirectory \ -a attributeMap=passwd:loginshell=loginShell \ -a attributeMap=shadow:shadowflag=shadowLastChange \ -a attributeMap=shadow:userpassword=userPassword \ -a objectClassMap=group:posixGroup=posixGroup \ -a objectClassMap=passwd:posixAccount=posixAccount \ -a objectClassMap=shadow:shadowAccount=shadowAccount \ -a searchTimeLimit=60 \ -a authenticationMethod=simple \ -a credentialLevel=proxy \ -a proxyDN=cn=root,ou=ldap,o=redbrick \ -a proxyPassword=LDAP_ROOT_PASSWORD \ IP.OF.LDAP.SERVER * Edit pam.conf: Replace anywhere that says "auth required pam_unix_cred.so.1" with "auth binding pam_unix_cred.so.1". There'll be a few. Replace anywhere that says "auth required pam_unix_auth.so.1" with "auth binding pam_unix_auth.so.1 server_policy". Under the pam_unix_auth lines you just edited (each of them), add the following line: servicename auth required pam_ldap.so.1 Replace anywhere that says "account required pam_unix_account.so.1" with "account binding pam_unix_account.so.1 server_policy". Under the pam_unix_account lines you just edited (each of them), add the following line: servicename account required pam_ldap.so.1 Replace the line "other password required pam_authtok_store.so.1" with "other password sufficient pam_authtok_store.so.1 server_policy". Underneath this line, add: other password required pam_ldap.so.1 You should now be able to id users, su to them, and log in as them. You'll need to create /usr/local/shells and symlink the usual shells there before most people can log in, though. > VM checkpoint 2 < * Configure NFS. Not documented, because it's simple enough and I can't test it from home. The only caveat that jumps to mind is that you have to force NFS version 3 with the mount option nfsvers=3. Mount /storage and /fast-storage at a minimum. * Install dev tools SUNWtoo SUNWsprot SUNWhea SUNWarc SUNWlibmr SUNWlibm SUNWsfwhea SUNWgccruntime SUNWgcc SUNWbzip SUNWggrp # pkgadd -d /mnt/Solaris_10/Product SUNWtoo SUNWsprot SUNWhea SUNWarc SUNWlibmr SUNWlibm SUNWsfwhea SUNWgccruntime SUNWgcc SUNWbzip SUNWggrp * Install OpenSSL SUNWopenssl-commands SUNWopenssl-include SUNWopenssl-libraries SUNWopenssl-man SUNWopensslr # pkgadd -d /mnt/Solaris_10/Product SUNWopenssl-commands SUNWopenssl-include SUNWopenssl-libraries SUNWopenssl-man SUNWopensslr * Create a packaging chroot Easiest way to do this is to use script at (add url here), mirrored at (add url here). ./mkchroot.sh buildapache ---- Routine update procedure ---- * Update PCA # cd (wherever PCA is) # /usr/sfw/bin/wget http://www.par.univie.ac.at/solaris/pca/stable/pca # chmod 755 pca * Check Sun patch list # ./pca -l all * Run simulation patch # ./pca --download --pretend -a * Install Sun patches # ./pca --download --install -a (reconfiguration reboot, lather, rinse, repeat, until it stops giving you orders)

3 5

[Admin-discuss] tunnel.redbrick
by Andrew Harford 09 Mar '09

09 Mar '09

Hey, At the moment tunnel.redbrick is setup with jumpgate to forward tunnel:80 and tunnel:443 to login:22 Just wondering if anyone can remember why it was setup this way, as opposed to just getting minerva to listen for ssh on 80/443? a. -- Andrew Harford System Administrator, DCU Networking Society Equipment Officer, Societies & Publications Committee Hi. I'm Troy McClure, you might remember me from such public service videos as "Designated Drivers, the Lifesaving Nerds" and "Phony Tornado Alarms Reduce Readiness." --Troy McClure

3 6