This site is now 100% read-only, and retired.

XML Logo

Posted by daemon on Thu 10 Apr 2008 at 22:11
Tags: ,

Since we're talking about work, it seems that Google are also on the hunt for sys-admins and tech engineers. What caught me out about the whole deal so far, is that I was contacted directly, out of the blue, which came as a bit of a surprise.

I'm not sure how my name managed to crop up in their list of contacts, but I guess, they are Google after all, if anyone's going to find something in a search of the web, they're as likely as anyone...

Either way, I'm very flattered, and very interested too. Especially if it'll get me comfortably back to the UK (international relocation costs a bomb, so it's always better if someone else picks up the tab ;-)

Cheers,
:wq

 

Posted by daemon on Thu 22 Mar 2007 at 12:26
Tags: , ,

I recently had to set up some user accounts on a server that should auth from a central LDAP server (running Novell eDirectory). It was supposed to be simple, users only needed sftp access, so I'm using scponly as their shell, and it was all straight forward enough.

User entries were added to /etc/passwd, with no corresponding entry in /ets/shadow, and they all had one locally defined group as their primary group. While this may look non-standard, it works perfectly for two test accounts that are setup in the exact same manner -- the test acconts have no issues.

However, oddly enough, the non test accounts have odd behaviour. When using getent, some reply, correctly, with the locally defined information, while others reply with the LDAP defined information. This plays havoc with normal use, because the uid, gid, home and shell information is different in each source (e.g. they should have a shell of /usr/bin/scponly, but the LDAP definition uses /bin/bash, the locally defined $HOME is /home/cs1/[user], but the LDAP definition uses /home/[user]).

While all that is strange enough, what's really odd is that even though they can log in, browse happily, and that they have rwx owner permissions on their $HOME, they can't write unless they have group write permissions too (and seeing as they're all members of the same group, that's not very good in this situation).

I've disabled, re-enabled, and re-configured nscd (removing the group caching entry), which initially solved the getent reply issue, but not any more, I've tinkered with libnss-ldap.conf (which is symlinked to pam_ldap.conf), and culled LDAP from the "group" entry in nsswitch.conf.

If anyone else here come across anything like this before, did you managed to find out what was going on? Any hints and tips?

All help gratefully received ;-)