Adam Megacz <[EMAIL PROTECTED]> wrote: > FB <[EMAIL PROTECTED]> 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 >> threading-expert. > > 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 sshd configs. > 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 > "username:shell.bash"? > > pts cg adam:shell.bash You can set the PTS groups so that they allow anyone to add themselves: http://www.openafs.org/pages/doc/AdminReference/auarf225.htm#HDRPTS_SETFIELDS 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 shell:zsh group. 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 permissions. 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.) <<CDC _______________________________________________ OpenAFS-info mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-info
