Log in

No account? Create an account

Previous Entry | Next Entry

Work todos

  • move database services to the new cluster machine, in a VM
  • rebuild the database to passwd-file converter, to be triggerable whenever a user is added to the database
  • set up passwd-file replication (rdist?)
  • finish user management in the control panel system
  • Start clustered web services finally

There's some fun stuff.


( 5 comments — Leave a comment )
Nov. 28th, 2007 07:00 pm (UTC)
You're rolling out new systems with passwd-replication-over-rdist? Seriously? C'mon, setting up an OpenLDAP server and configuring PAM isn't that hard, and will save you serious headaches in the future. You can even still make the LDAP data a replica of your RDBMS account info, if you want -- that's how we manage our 2-3K (soon to be 5-6K) user accounts around here.
Nov. 28th, 2007 09:30 pm (UTC)
LDAP is what I'm moving away FROM.

pam_ldap works okay, nss_ldap has really serious flaws, lockups and more.

Also, network outage hoses so much when that happens. nss has no API for something that has network failure modes.
Nov. 28th, 2007 09:32 pm (UTC)
(Error in network = User not found) = Bad.
Nov. 28th, 2007 09:46 pm (UTC)
Ouch. I cringe at the thought of having to go back to local password stores...heck, I cringe at the idea of having to give up single-sign-on (we use Kerberos).

I've certainly seen issues trying to log in to boxen that have LDAP PAM and NSS compat turned on...but that's why god gave us serial consoles and local root passwords, right?
Nov. 28th, 2007 09:56 pm (UTC)
Kerberos ++ -- I'd be using it if I could find a sane migration strategy. I think they exist, I'm just not there yet.

LDAP, well, anything networked with NSS is just ugly. We've had a handful of DoS attacks against the servers, and it managed to disrupt traffic to the LDAP server enough so that NSS was returning 'Error', which getpwent returns as 'not found'. So. Ugly. Since we're running a rather mixed set of servers, NSS is the only common API (though more than 50% of the services we run support LDAP, that's not nearly enough)

I've written some simple password-file synching scripts -- just keep system users from /etc/passwd, anything uid<1000; anything uid >= 1000 gets replaced with the copy from the database. Still finishing shadow support, but it's a start. Master-slave replication for UID>=1000, and local users are < 1000. Easy policy so far.

Serial consoles and local root are good in a pinch, yes, but it's more things like users sending each other messages and getting "no such user" that really chafed.
( 5 comments — Leave a comment )