Houston, we have lift-off (sort of)
It’s been a while since I’ve written. I’ve had many late nights working with verin (that’s the name of my new file server, BTW) and I think (I’m coming down with|I have a) cold. Not that it’s any excuse for not making an entry since then. In typical fashion, I’ll now write of events completely out of order.
euphorik and I spent an hour or so tonight talking about depressing music. He thinks August and Everything After is a depressing album. After thinking about it, I kind of agreed. Other artists I think we were both able to agree on: Mazzy Star, Portishead (sort of). I can’t think of any of the others. I guess I don’t think of some of these as depressing, necessarily; some of them occur to me, at least at times, as just being thoughtful and different. What do I know about depression or thoughtfulness, though?
I pretty much have the file server situation squared away. I have a
single password for both Windows and Linux, I can access my shared
drive in both, and I have some semblance of security. I’ll try and
take it step-by-step, but unfortunately I did > instead of >>
into a text file that was filled with notes I wanted to write here so
I may miss some steps.
First, in a semi-final act of desperation, I mailed the Samba mailing
list.
Andrew Bartlett was kind enough to reply to
me.
He gave me a little hope, but this came after I was 2/3 of the way
done with the simpler solution of doing Samba 2.2 as a PDC and doing
password synchronization. Anyway, maybe someday I’ll try writing the
code to put the Kerberos key into Samba’s secrets.pdb or whatever
it is, and see how far I get from there.
One thing I realized I had to set up was SSL LDAP, and LDAP Kerberos
authentication. In retrospect I don’t think I’m even using this –
but at the time I’m sure I thought it was an imperative. To do this I
followed the instructions in the LDAPv3
HOWTO. I did “set up a CA”
using the OpenSSL mini-CA stuff. Check out /usr/share/ssl/misc
for the CA.sh script, IIRC. I started from the section titled
“Building OpenLDAP v2″ pretty much. One hazard to watch out for: if
you’re using Red Hat 8.0 and you want to do Kerberos (GSSAPI)
authentication, make sure to install the cyrus-sasl-gssapi
package. Red Hat 8.0’s OpenLDAP is built with the necessary
configure options. I did add in all three SSL certification
options as given in the HOWTO. I have not created any indexes, though
I probably should and quite probably will at some point in the
future. I don’t have many ACLs set up, and certainly not as many as
the example in the HOWTO. You will need the Kerberos principal and
you’ll need to ktadd the key for the principal into
/etc/krb5.keytab as shown. One detail: OpenLDAP from Red Hat 8.0
doesn’t run as root IIRC, so you’ll need to make a group to own
the /etc/krb5.keytab file, then put the ldap user in that
group. Don’t worry if your userPassword attribute doesn’t start
appearing in Base64; mine didn’t. For testing OpenSSL, if you can’t
get supportedSASLMechanisms to return anything over an unencrypted
connection, try going to the next part where you test with an SSL
connection; I think in my case, the SSL connection showed the proper
results whereas the unencrypted connection displayed no results.
YMMV. You can see my
/etc/openldap/slapd.conf.
Next I must have set up Samba 2.2. I don’t really remember, so this
seems like the next logical step. First of all, the RH8 packages for
Samba don’t have pam_smbpass or LDAP support, so you’ll need to
rebuild from the spec files. You can try my samba.spec with LDAP
and pam_smbpass.
Don’t forget to read the Samba 2.2 PDC
HOWTO.
You can also check out my
/etc/samba/smb.conf.
Here’s one tip for you:
DON’T USE UTF-8 IN RED HAT 8.0
You know it’s been fucking you up. You’ve noticed weird shit
happening, like authconfig speaking in half-Chinese when you run
it from a gnome-terminal on your RH7.2 box, or when Kudzu comes up
over serial console, or when you try to read a manual page. You found
setting LANG=C fixes it, and you were content doing that where
absolutely necessary. Well stop. It’s fucked. Go in
/etc/sysconfig/i18n right now and do something like this:
#LANG="en_US.UTF-8" LANG="en_US" LC_COLLATE="C" SUPPORTED="en_US.UTF-8:en_US:en" SYSFONT="latarcyrheb-sun16"
Taking that UTF-8 off the end seems to fix everything. (Thanks
for the tip, dj.) “Why so urgent, darkness?” Well, I’m pretty sure
that when UTF-8 is in there, the import_smbpasswd.pl script
from Samba breaks in a most horrible fashion, locking up before it can
add or modify any accounts. Dissecting some packets with
Ethereal (which I’ve come to love, BTW;
great for debugging LDAP) I saw that it was apparently putting in bad
packet sizes in Convert::ASN1. After trying to troubleshoot this
module for most of a day, I woke up one morning and decided to slap
LANG=C in front of the script before I rand it. Behold, it
worked. Bastards.
On the topic of password synchronization: it doesn’t work from
Windows. Apparently most any SMB client isn’t going to send you the
plain text password when it sends a request to the server to change
the password. If you’re using Kerberos, like I am, pam_krb5 will not
let root change the password for a principal just because ey’s root.
I corrected passwd chat in smb.conf as you can see, but it
doesn’t work because Samba doesn’t have the old password from Windows;
it just sends enter instead. Oops. The only hope here would possibly
be to hack up something that uses kadmin.local, I think, but that
would make a lot of assumptions (the user is in Kerberos, you’re on
the Kerberos server, etc.) This would also bypass PAM. Yick. Better
would be to hack support in to pam_krb5. I don’t care that much,
though, because… we can change passwords in Linux!
Yes, through use of pam_smbpass you can change your password as
usual with the passwd command. In one swoop this will do a
cracklib check, change your password in SMB, and Kerberos (or
/etc/shadow, as it applies). Here’s my
/etc/pam.d/system-auth (text is hand-wrapped):
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth sufficient /lib/security/pam_krb5.so use_first_pass auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/pam_krb5.so password requisite /lib/security/pam_cracklib.so retry=3 type= password [default=die success=ok user_unknown=ignore] /lib/security/pam_smbpass.so nullok use_authtok try_first_pass password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/pam_krb5.so use_authtok password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_krb5.so debug
You’ll notice that most of this is as authconfig would generate
it. However, the pam_smbpass line I added in myself. I’m very
proud of it. It ignores the module if the user isn’t in LDAP as a
sambaAccount, or fails immediately without executing any other
modules if the user is a Samba user but it fails to update their
password. This half-way keeps you from having your password changed
in Kerberos when it failed in Samba. On a side note, I’m not sure why
Red Hat didn’t use requisite instead of required in for
pam_cracklib. The difference between the two is that requisite
fails immediately and doesn’t execute other modules if the module
fails, whereas a required module might fail but the other modules
will be executed before failure is returned to the caller. I think it
works regardless, since I don’t think pam_cracklib will set the
“authtok” without liking the password you’ve supplied, but it still
seems ugly.
I haven’t found any tools that are ready out of the box for me to manage accounts with, so I’ve just been using GQ to edit things by hand. Note that I can’t get the latest GQ beta to enable TLS to my server, for whatever reason.
After all this, Samba is pretty well set up. Next is NFS for the
Linux boxes to get to the shared files. NFS setup was pretty easy.
Here’s my /etc/exports:
/nfs/verin/array0 client.mydomain.com(rw,sync,root_squash)
Simple, eh? Note that, since we have two arrays to be NFS mounted,
and they’re not both on the same box, I’m putting everything under
/nfs/MACHINENAME/MOUNTPOINT so there’s no conflicts when, for
example, verin wants to mount another server’s share. Here’s an
/etc/fstab entry for the client (text is hand-wrapped):
verin.mydomain.com:/nfs/verin/array0 /nfs/verin/array0 nfs nfsvers=3,mountvers=3,hard,intr,rw 0 0
I haven’t decided if I want to use hard or soft yet. So far,
hard hasn’t left me with any “hung” processes. Also, I don’t know
if mountvers=3 is necessary for NFSv3 fun, but I noticed verin
supported it (rpcinfo -p) so I figured, “why not?”
Firewalling NFS is an interesting process. I had to open up 8 ports
and modify /etc/init.d/nfslock and /etc/modules.conf. Here’s
my
/etc/init.d/nfslock
which should properly read ports from /etc/sysconfig/nfs. Here’s
my /etc/sysconfig/nfs:
RQUOTAD=no MOUNTD_PORT=32768 STATD_IN_PORT=32769 STATD_OUT_PORT=32770
I’m not using quotas so I hope it’s OK to stop that daemon from being
run, which is what RQUOTAD=no is. Then, the line you need in
/etc/modules.conf to make the kernel lockd bind specific ports
is:
options lockd nlm_udpport=32771 nlm_tcpport=32772
I don’t know if these numbers need to be different, since one is TCP
and one is UDP. I saw some example that had them different, so I
followed suit. I’m not short on ports (yet). After this, I have the
following ports open on the server: 111/tcp, 32768/tcp, 32769/tcp,
2049/udp, 111/udp, 32768/udp, 32769/udp, 32771/udp. Note that your
client needs to have its nfslock service started, and for that
it’ll need the /etc/modules.conf line above as well as the
modified /etc/init.d/nfslock above, and /etc/sysconfig/nfs
with only the STATD_* lines in it, IIRC. The server apparently
does contact the clients on those ports, though I don’t know if it
only does it in response to something the client sends out first (in
which case -m state --state ESTABLISHED might work). (I kind of
doubt you could use --state ESTABLISHED. Really.)
I think that’s all about the extent of it. After I joined my Windows
box to the domain I had to create a new profile. I couldn’t get the
normal profile copying mechanism to work (from the System control
panel applet, etc.) I ended up creating a new profile, finding how
much shit stores in HKCU, and trying to get my old profile into my new
profile. I copied things like My Documents and Application
Data. (Oh shit, I forgot Application Data.) For my registry I
rebooted, logged in as a local user, loaded my old user’s hive with
regedt32, exported it with regedit, loaded my new user’s hive,
used an editor to do a global search/replace on the key name, then
imported it with regedit. It seems to have worked reasonably
well. It made Half-Life start, at least.
As I’ve been writing this entry I’ve been copying my MP3 CDs to my new RAID array. I’m doing it using the local (loud) CD-RW. I’m on CD 17 so far, and I’ve been real slack on switching CDs. It’ll be nice to have my MP3s all on a disk, but I’m really hoping to use this as a test to prove data reliability. I don’t know how. I guess I’m hoping that if somethings unreliable in this setup it’ll speak up. Or turn my MP3s into white noise. Either way, sounds good to me.
I have this Dinnermints song stuck in my head. I’ll have to rip that CD. All of my CDs. Yes. Soon, soon.