Christopher D. Clausen
Sun, 1 Apr 2007 13:10:54 -0500
Adam Megacz <email@example.com> wrote:
> FB <firstname.lastname@example.org> writes:
>> * Some multithreaded applications (i don't remember exactly which
>> ones) just didn't work with the thread model of Todd's module.
>> AFAIK it had something to do with pthread v.s lwp but I'm not a
> Ok, I'm going to look into this.
>> * One of my cells contains a DB-Server which is off-by-default.
>> Moving the PTDB-Code to a daemon prevents timeouts while
>> marking DB-servers offline. This way I timeouts in any program
>> accessing the uid-name-resolution are replace by a single
>> timeout at daemon-start. -> A seriously wish, I had such a
>> daemon for host-lookups, too...
> I see. I think nscd would achieve the same effect...
> Also, while I'm hacking on this, two more questions:
> 1. Does it make sense to map AFS group ids (with the sign reversed)
> onto GIDs?
Probably, yes. That way the local group can be used to protect
resources, like cdrom or sound or whatever or you could use groups in
> 2. Previous suggestions about shells involved putting users into
> groups named after shells, such as
> pts add adam shell:bash
> But it seems that this wouldn't allow users to manage their own
> shells since shell:bash would belong to some administrative user.
> What about an alternative, where users would create a group
> pts cg adam:shell.bash
You can set the PTS groups so that they allow anyone to add themselves:
you want -access SOMAx
Not sure if that would allow them to change other users shells or not
though, but thats easy to test for those so inclined.
You'd need a periodic cleanup process (run via cron on a trusted host)
to remove the user from the old group when they are in two of them. And
it would probably be best to have a default shell (say bash) with no
group and default users to this shell. Most users I know only change
shell once and it would be easy for them to add themselves to the
Or, have a web interface that actually runs with "shell" tokens to allow
users to change their shells and don't mess with the PTS group
Bascially, even if it requires system administrator intervention to
change shells, it would still be superior to running NIS or LDAP just
for shell and home directory information.
In fact, it might be simpler to have a PTS DB extention that emulates an
NIS server and run it on the AFS DB servers. That way you wouldn't need
to port the nss module to various OSes. (I suspect it would be painful
to port to AIX.)