Kicking and screaming…

I remember looking at LiveUpgrade at my old job and it not working very well because I was trying to be all tricksy with it and make it do things beyond the most basic “clone this and apply these patches” — I was trying to use it to convert Solaris 8+VxVM to Solaris 10+SVM, and while it should have worked, it didn’t, and it felt like the failure to work was down to arbitrary limits and hard-coded inanity in LU.

So I’ve never really seen it working in any useful fashion.

This week, while thinking about how best to set up the new shinies (an X4600 to play the role of database server, and a pair of X4100s to be its minions) LU somehow popped into my mind. As I have a little time to play with for a change, figured it couldn’t hurt to fiddle.

So we now have a new default configuration for all new Solaris systems. Single filesystem for the OS at ~50GB, a spare slice of the same size for the alternate BE, with the rest going to swap. This is assuming 136GB spindles.

And it works quite nicely. There’s some risk of actually being able to patch things in future, thanks to the easy back-out route and the much less-insane downtime requirements.

I’d like to think that we’ll migrate existing systems to a similar configuration, it’s certainly technically possible to do, but I’m not going to count on having the time to do it. Shall have to settle for a very gradual process of conversion by replacement.

Popularity: 20% [?]

Small pleasures

I may perhaps be taking too much enjoyment from:


# zfs snapshot tank0/sybase/home@copy
# zfs send tank0/sybase/home@copy | ssh root@db2 'zfs receive tank0/sybase/home'
# zfs destroy tank0/sybase/home@copy
# ssh root@db2 'zfs destroy tank0/sybase/home@copy'

But I’m not sure I care. Is good.

Except for the bit where I repeatedly typo it as ‘destory’.

Popularity: 23% [?]

Solaris, LDAP, and you (part 1)

I’ve been fighting this for ages, and finally got something to start working today. Here’s what I did.

First, I gave up on Sun’s LDAP server. It’s a huge thing, quite possibly great for large-scale implementations, but we just want to authenticate ~100 users across ~100 hosts.

So I installed OpenLDAP, followed the stuff in the Quick Start guide to get a basic top-level thing going, and then created appropriate OUs for users and groups, e.g.:


dn: ou=People,dc=example,dc=com
objectclass: organizationalUnit
ou: People

You need to load the cosine, inetorgperson, and nis schemas if you want to do account-fu. Here’s an example account:


dn: uid=someuser,ou=People,dc=example,dc=com
objectClass: person
objectClass: posixAccount
objectClass: shadowAccount
uid: someuser
uidNumber: 5226
gecos: Some User
homeDirectory: /home/someuser
loginShell: /bin/bash
cn: Some User
sn: User
userPassword:: crypted-password
gidNumber: 603

It’s helpful to have at least one user in the thing before you start fiddling with clients, as then you can tell it’s working.

Finally, you need a user for Solaris to authenticate as:


dn: ou=LDAPusers,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: LDAPUsers

And:

dn: cn=solaris,ou=LDAPusers,dc=example,dc=com
objectClass: top
objectClass: person
cn: solaris
sn: LDAP User
userPassword:: somecrypt

Now it’s time to fiddle with the client.

First, ignore Sun’s documentation. The absolute dead-easiest way to make this work is to ensure that the LDAP cache manager is off and then frob the config files by hand. They should look a bit like this:


# /var/ldap/ldap_client_file
NS_LDAP_FILE_VERSION= 1.0
NS_LDAP_SERVERS= 10.132.3.149:389
NS_LDAP_SEARCH_BASEDN= dc=example,dc=com
NS_LDAP_AUTH= NS_LDAP_AUTH_SIMPLE
NS_LDAP_SEARCH_REF= NS_LDAP_FOLLOWREF
NS_LDAP_DOMAIN= example.com
NS_LDAP_SEARCH_DN= passwd:(ou=People,dc=example,dc=com)
NS_LDAP_SEARCH_DN= shadow:(ou=People,dc=example,dc=com)
NS_LDAP_SEARCH_SCOPE= NS_LDAP_SCOPE_SUBTREE
NS_LDAP_SEARCH_TIME= 30 NS_LDAP_CACHETTL= 3600


# /var/ldap/ldap_client_cred
NS_LDAP_BINDDN= cn=solaris,ou=ldapusers,dc=example,dc=com
NS_LDAP_BINDPASSWD= {NS1}somecrypt

Now you can change nsswitch.conf’s passwd line to look like this:

passwd: files ldap

Kick nscd (svcadm restart name-service-cache) and you should start seeing LDAP content show up, e.g.:


# listusers
someuser Some User
...

If things are working this far, you can try making the accounts active for login. Edit pam.conf and where you see a line with required pam_unix_auth.so.1 change it to binding pam_unix_auth.so.1 server_policy and add a line of the form required pam_ldap.so.1 immediately after.

This got me to the point of being able to log in to the host with LDAP-based accounts, though it is far from being a complete picture. You should also be able to use ldapaddent to inject data, though if you try anything but the passwd or group map you’ll find you need to create the top-level container in the directory first.

Popularity: 96% [?]