Behold, the The Objective Rack - Mark IV!
This whole rack-rebuild project took most of Saturday. Thankfully everything of mine came up ok afterwards. Unfortunately a friend's server (that I've started hosting as of last weekend) didn't come up so easily. After a whole night of frantic tinkering attempts, I backed up all the data I could salvage and we reinstalled it this morning.
This is but the latest in a continual cycle I go through....
1) Build rack all nice and neat
2) Use new setup for a while
3) Gradually decide to change things over time (add new machines, remove old machines, etc.)
4) Decide that the once-elegant rack has become a mess of tangled wires and ad-hoc mounting
5) Tear it down and repeat from step 1.
As I said, this is the 4th iteration of my attempts at building a rack of computer equipment for my personal use. Here's the history in chronological order:
Mark I - Moved to an apartment in Florida, bought the rack in the process, got everything all setup. Many of my systems weren't rackmount, so I used a lot of rack-mount shelves.
Mark II - Upgraded a lot of equipment, had a lot of new stuff to mount (including an E4000 and a big RAID box), and took the desktops out of the rack. First use of the term "objective rack".
Mark III - Moved from the apartment to a house, finally had the proper mounting kit for the E4000, needed to get everything setup again.
Mark IV - Retired some of the more power-hungry equipment (E4000 and big RAID box), changed a lot of systems around, had some new equipment and cable-guide stuff to integrate.
Prior to the rack, I went through a series of wire-shelf-based setups. These began my sophomore year of college with this setup, and continued with a new iteration every academic year.
Sunday, December 18, 2005
Tuesday, December 06, 2005
Fun with LDAP and Kerberos
Several weeks ago I decided that I want my firewall to no longer be a Solaris machine, and that I wanted a dedicated authentication/utility server. The goal was to decouple my internal utility services (authentication, DNS, NTP, etc.) from my main servers. So I dug up a cheap 1U server, put FreeBSD on it, made it my firewall/internal-router/external-DNS/etc. box, and took my Netra T1 out of production.
Since the Netra T1 was to be the new auth server, I began last week by blowing away its prior installation and giving it a fresh load of Solaris 10. (note: always remember to make the small dedicated partition for the SVM metadb replicas *before* installing Solaris) I then got my internal DNS migrated to it, as well as NTP.
For a while, I was running good 'ole NIS to do my distributed user accounts. Of course its an old protocol, and everyone says to upgrade, but it "just f**ing works", and I can configure it in my sleep on just about any *nix. Of course the whole point of this auth server was to try something new. Originally I knew I wanted to take a shot at LDAP again, as I've tried (and failed) before, going back to NIS. As I approached this past weekend, and did some reading, I decided to take a bigger chunk and try LDAP with Kerberos.
So on Saturday I brought the Netra out to the LEAP Installfest, and started getting OpenLDAP and the Kerberos that comes with Solaris (SEAM) all installed and configured. By Sunday afternoon, I was still tinkering, and things still weren't yet working right. I figured out how to migrate my NIS accounts into LDAP, knew how to make users in Kerberos, but client authentication just wasn't working right. (it sort-of worked to my FreeBSD server, and didn't work with my Solaris one) I spend way too much time staring at PAM debuging output, and continued to be baffled.
So I said f*ck it, pulled out OpenLDAP, and went and installed "Sun Java System Directory Server 5.2". (which used to be called SunONE *something*, which used to be called iPlanet *something*, which used to be Netscape *something*) The name sounds fancy, but it really is just an LDAP server with some graphical (and the usual command-line) admin tools.
After tinkering all night, it was almost working. In the morning I figured out the magic extra LDAP user parameter to finally get authentication working. So by sometime Monday morning, I could do name lookups and authentication against the SJSDS LDAP server from both my Solaris and FreeBSD servers. However, while I had SSL configured on the LDAP server, it wasn't reaching down to the clients.
I spent all of last night attacking the SSL issue... You see, LDAP isn't really a good authentication protocol (which is different from an authorization/lookup protocol, which it is decent at). Without SSL, you have 2 authentication types... simple (your client sends your password IN CLEAR TEXT over the wire to the LDAP server), and CRAM-MD5/DIGEST-MD5 (the password isn't in the clear on the wire, but it is IN CLEAR TEXT in the LDAP database itself. (thus breaking my desire for password-hash compatability with the data I imported from NIS) In any case, but the end of the night, I got simple authentication with SSL working. Thus, no cleartext passwords anywhere.
Then tonight I got brave again... You see, the Sun JSDS docs do have a good writeup on integrating Kerberos. But when I initially tried it, the ns-slapd process (the LDAP server itself) kept core-dumping. Apparently, this was a known issue according to the release notes, and there was even a fix (which worked!). So as of the middle of this evening, I actually succeeded in getting LDAP+Kerberos fully functional across all my remote-access systems. I even figured out how to convince PAM on my Solaris server to use SSL LDAP authentication for users that don't yet have a Kerberos principal. (couldn't figure out how to tweak PAM to do that seemlessly on FreeBSD, though.) Now that Kerberos is working, its only a matter of time before I find myself fully taking advantage of what it has to offer.
In any case, I think I've conquered LDAP+Kerberos. Next step is to eventually get around to figuring out exactly what I did, and producing a detailed technical writeup to help others in the future. (sure, the web is full of such writeups, but they're all partial and I needed to piece together hints from all of them to get things working.)
Since the Netra T1 was to be the new auth server, I began last week by blowing away its prior installation and giving it a fresh load of Solaris 10. (note: always remember to make the small dedicated partition for the SVM metadb replicas *before* installing Solaris) I then got my internal DNS migrated to it, as well as NTP.
For a while, I was running good 'ole NIS to do my distributed user accounts. Of course its an old protocol, and everyone says to upgrade, but it "just f**ing works", and I can configure it in my sleep on just about any *nix. Of course the whole point of this auth server was to try something new. Originally I knew I wanted to take a shot at LDAP again, as I've tried (and failed) before, going back to NIS. As I approached this past weekend, and did some reading, I decided to take a bigger chunk and try LDAP with Kerberos.
So on Saturday I brought the Netra out to the LEAP Installfest, and started getting OpenLDAP and the Kerberos that comes with Solaris (SEAM) all installed and configured. By Sunday afternoon, I was still tinkering, and things still weren't yet working right. I figured out how to migrate my NIS accounts into LDAP, knew how to make users in Kerberos, but client authentication just wasn't working right. (it sort-of worked to my FreeBSD server, and didn't work with my Solaris one) I spend way too much time staring at PAM debuging output, and continued to be baffled.
So I said f*ck it, pulled out OpenLDAP, and went and installed "Sun Java System Directory Server 5.2". (which used to be called SunONE *something*, which used to be called iPlanet *something*, which used to be Netscape *something*) The name sounds fancy, but it really is just an LDAP server with some graphical (and the usual command-line) admin tools.
After tinkering all night, it was almost working. In the morning I figured out the magic extra LDAP user parameter to finally get authentication working. So by sometime Monday morning, I could do name lookups and authentication against the SJSDS LDAP server from both my Solaris and FreeBSD servers. However, while I had SSL configured on the LDAP server, it wasn't reaching down to the clients.
I spent all of last night attacking the SSL issue... You see, LDAP isn't really a good authentication protocol (which is different from an authorization/lookup protocol, which it is decent at). Without SSL, you have 2 authentication types... simple (your client sends your password IN CLEAR TEXT over the wire to the LDAP server), and CRAM-MD5/DIGEST-MD5 (the password isn't in the clear on the wire, but it is IN CLEAR TEXT in the LDAP database itself. (thus breaking my desire for password-hash compatability with the data I imported from NIS) In any case, but the end of the night, I got simple authentication with SSL working. Thus, no cleartext passwords anywhere.
Then tonight I got brave again... You see, the Sun JSDS docs do have a good writeup on integrating Kerberos. But when I initially tried it, the ns-slapd process (the LDAP server itself) kept core-dumping. Apparently, this was a known issue according to the release notes, and there was even a fix (which worked!). So as of the middle of this evening, I actually succeeded in getting LDAP+Kerberos fully functional across all my remote-access systems. I even figured out how to convince PAM on my Solaris server to use SSL LDAP authentication for users that don't yet have a Kerberos principal. (couldn't figure out how to tweak PAM to do that seemlessly on FreeBSD, though.) Now that Kerberos is working, its only a matter of time before I find myself fully taking advantage of what it has to offer.
In any case, I think I've conquered LDAP+Kerberos. Next step is to eventually get around to figuring out exactly what I did, and producing a detailed technical writeup to help others in the future. (sure, the web is full of such writeups, but they're all partial and I needed to piece together hints from all of them to get things working.)
Subscribe to:
Posts (Atom)