[Fusionforge-general] GForge/FusionForge developer access toSVN - WebDAV or ssh/svnserve better?

[Christian BAYLE]

Matt Kleffner a écrit :
>
> OK, I think I understand a little better now. When I take my additions
> out of sshd, the auth.log error is from pam_unix (invalid user as
> well), not pam_pgsql . I assumed that meant that nothing was even
> attempting to connect to the database, but you are saying that
> pam_unix will try with properly-configured nss. Are nss and pam truly
> orthogonal authentication mechanisms, then, or does pam use nss as
> well?
>
>   
Not exactly,  auth is going thru pam that is cascading  various modules
when you have required,  and the return co is false, the
auth/session/passwd fails
when you have sufficient, if ok it doesn't go more far.

See http://www.linuxdocs.org/HOWTOs/User-Authentication-HOWTO/x101.html

pam_unix is usually after the other auth
and is doing std unix auth using the nss library to gets user info and
passwd
you can see this doing
strace getent passwd root 2>&1| grep open

open("/etc/nsswitch.conf", O_RDONLY)    = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/i686/cmov/libnss_compat.so.2", O_RDONLY) = 3
open("/lib/i686/cmov/libnsl.so.1", O_RDONLY) = 3
open("/etc/ld.so.cache", O_RDONLY)      = 3
open("/lib/i686/cmov/libnss_nis.so.2", O_RDONLY) = 3
open("/lib/i686/cmov/libnss_files.so.2", O_RDONLY) = 3
open("/etc/passwd", O_RDONLY|O_CLOEXEC) = 3

you can with strace try to guess where things fail

It means you can have in a first phase of  login a try thru pam_pgsql
and a second thru pam_unix and nss libs
pam has the ability to let you choose the mechanism depending on the 
program ,
sshd is particulary using /etc/pam.d/sshd config file


>>> select * from nss_passwd;
>>>  uid | gid | login | passwd | gecos | shell | homedir | status
>>> -----+-----+-------+--------+-------+-------+---------+--------
>>> (0 rows)
>>>
>>> nss_usergroups, and nss_shadow also have 0 rows like the above.
>>>
>>> Logging into the database with admin rights and running "select * from
>>> users;" shows a few users that obviously aren't showing up in the
>>> nss_* files. Even if PAM+NSS is otherwise properly configured on my
>>> machine, it looks like gforge shell logins still won't work without
>>> the proper database entries.  How are the nss_* tables populated
>>> and/or updated?
>>>
>>>       
>> your problem seems to be that
>> getent shadow don't get the crypted passwd
>>     
>
> From where? I see two problems that can occur - getent can't get to
> the database (is this where the crypted passwd is?), and/or the nss_*
> tables haven't been filled with the necessary information from the
> standard gforge tables. Regarding the table issue, is there a cron job
> that fills these tables? Or are these tables somehow filled by getent?
>
>   
Sure this can't work as far as nss_passwd is not correctly filed
This is done by
gforge/common/include/system/<$sys_account_manager_type>.class.php
sys_account_manager_type is defined in gforge.conf the default being UNIX
it should be pqsql if you use gforge-shell-postgresql
nss_shadow is a view
take care that only users member of a project get unix account


>> For me, it's pam that is used systematically, following the config
>> in /ets/pam.d
>> and if you use pam_unix
>> it uses the getent function that make use of /etc/nsswitch.conf
>> nss then load the proper modules
>>
>>     
>
> Which method is developer-preferred for gforge/fusionforge, or is it
> really admin preference?
>
>   
As far as I know pam-pgsql is not configured, it only uses  nss thru
pam_unix
>> just an extra question, which distro do you use ? because not all are
>> configuring pam in the same way
>> I answered rather with may knowledge of what is done in debian and
>> derivated.
>>
>>     
>
> I am using Debian Lenny with the stable gforge packages. I enabled
> shell access as soon as I installed the gforge-shell-postgresql
> package. I'm wondering if I didn't mess something up somehow, though,
> because this seems like something that might otherwise work right
> after install. Am I better of reinstalling? Installing a version from
> unstable or experimental? Is it expected that gforge-account shell
> access works immediately after installing the shell package? Either
> way, this experience is teaching me quite a bit about various
> authentication mechanisms - which is quite useful.
>
>   
It seems it's a problem in some case because the
connectionstring = hostaddr=127.0.0.1 user=$db_user_nss
password=$db_password dbname=$db_name
desync the passwd
You can just remove host and pass
onnectionstring = user=$db_user_nss dbname=$db_name

I don't know exactly why this happens, maybe some usual problem with
postgresql not listening by default on socket

You may try the lenny install CD in a virtual machine l that should
properly config  a gforge
as far as you have a properly configured dhcp server without doing anything

Cheers

Christian