> Hello there, > > I'm trying to install a long awaited (by myself, because I only have 3 > boxes) full ldap based authentification, with smb as network filesystem > for both Linux and Windows worstation (I want to throw away nfs and > anyway I have to use samba for my windows box, stupid ?).
Be aware that NFS is currently the best generic (ie exlucing AFS and Coda) unix-to-unix file sharing system available, and NFSv4 should probably provide for the only reasons you would want to use smb over NFS. At present it is not possible to run GNOME or KDE on a SMB/CIFS-mounted home directory, even with a samba server running on a unix machine with unix extensions available (or at least it was last time I tested which was just before cifs went into the Mandrake kernel). > The ldap based authentification and samba-ldap are fine working. Last > step is therefore using pam_mount for home directory (+ few other > shares). Are you using group mapping? If so, is it working (I have problems using the Windows User Manager for Domains under certain circumstances, but I have a bug open on it ...). > > Here is what I faced, could you please tell me if I'm wrong .... > > pam_mount is able to pass password to the stack, but not to keep it back > from the stack -> pam_mount must be stacked first in the auth section. No, this is not necessary. > I don't know why, but if I stack pam_mount after pam_ldap in the session > section, mount operation will abort with the following message : > > pam_mount: unable to open /var/run/pam_mount/foo > pam_mount: received order to close things > (...) > su: unbind.c:40: ldap_unbind_ext: Assertion `( > (ld)->ld_options.ldo_valid == 0x2 )' failed. > (...) Maybe you need the "use_first_pass" option in your pam_mount line if it's after a real authenticating module. > If I toggle pam_ldap & pam_mount, things are ok, but I still have the > following warning message (last line, /var/run/pam_mount is root owned): > > pam_mount: -------- > pam_mount: checking to see if //192.168.1.12/foo is already mounted at > /home/foo > pam_mount: creating mount /home/foo > pam_mount: checking for encrypted filesystem key configuration > pam_mount: about to start building mount command > pam_mount: mount type is SMBMOUNT > pam_mount: waiting for homedir mount > pam_mount: command: /bin/mount mount -t smbfs //192.168.1.12/foo > /home/foo -o username=foo,uid=foo,gid=foo,dmask=0700 Note taht you will have no chance at all to run KDE or GNOME on smbfs, with cifs you may get a bit further (relative symlinks actually work in some circumstances on cifs, but not at all on smbfs). Most of the other WMs work OK (I have tested at least fluxbox and WindowMaker). > pam_mount: unable to open /var/run/pam_mount/toto Never seen that. The current cooker package works fine for me. > [EMAIL PROTECTED] /]$ > > > Does anyone has yet faced (and understood) the above errors/warnings > (I've found nothing on it googling) ? > > Thanks in advance, > Sébastien. > > > PS : > It's on an up to date 9.2 : > pam_mount-0.9.2-3mdk > pam_ldap-164-2mdk > samba3-common-3.0.0-2mdk > samba3-client-3.0.0-2mdk > samba3-server-3.0.0-2mdk > > The last pam_mount version is the 9.4, I'll compile it and see if things > are going to another way. > I don't think that's the problem. > > The pam.d/system-auth used was > ---------- > auth required /lib/security/pam_env.so > auth required /lib/security/pam_mount.so > auth sufficient /lib/security/pam_unix.so nullok > use_first_pass auth sufficient /lib/security/pam_ldap.so > use_first_pass auth required /lib/security/pam_deny.so > > account required /lib/security/pam_unix.so > account sufficient /lib/security/pam_ldap.so > > password required /lib/security/pam_cracklib.so retry=3 minlen=2 > dcredit=0 ucredit=0 > password sufficient /lib/security/pam_unix.so nullok use_authtok > md5 shadow > password sufficient /lib/security/pam_ldap.so use_authtok > password required /lib/security/pam_deny.so > > session required /lib/security/pam_limits.so > session required /lib/security/pam_unix.so > session optional /lib/security/pam_mount.so > session optional /lib/security/pam_ldap.so > ---------- Some comments: 1)I don't think it is useful putting pam_mount in system-auth, since I don't see any value having your smb share mounted when you read your mail via an IMAP on such a machine, or when you connect to a samba printer (if you use 'obey pam restrictions = yes') etc. Also, I have had some problems using pam_mount in system-auth (maybe it doesn't work too well with pam_stack) in the past. 2)I don't know if you want to make the pam_mount entry required or requisite, since it may make it impossible to do certain things if your samba server is unavailable (although I guess there could be scenarios where you don't want users to be able to log in in such a case). I use pam_mount by adding the two required lines to /etc/pam.d/login (at the end of each section), so I have something like this: auth required /lib/security/pam_securetty.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so auth optional /lib/security/pam_mount.so use_first_pass account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session optional /lib/security/pam_console.so session optional /lib/security/pam_mount.so use_first_pass You should do this for each service you have that you want to automatically mount shares for users (maybe login, kde3, gdm, xdm). My system-auth is basically as set up by drakauth (or the LDAP option during installation). > and I've commented out the pam_rootok.so line in pam.d/su to only use > the service=system methode in auth section (I 'll se this point later > ... ;-) ) I don't know why you would want that ... it's better to just ensure users can't get to the root account on any machine. BTW, IMHO there is only (currently) one scenario where smbfs/cifs would be a good idea for sharing home directories (if symlinks worked correctly), and that would be as a unix fileserver in a Windows-only network, to provide home directories to clients running winbind. But, since winbind can store it's idmap in LDAP (I must still try this), this is probably no longer the best method. IMHO, the best method (currently) to manage file sharing between unix machines in a network is with autofs (specifically automount maps in LDAP). You basically don't have to touch a thing on any clients (besides make the directory the autofs mounts in, ie if you have /nfs/users auto-mounted, you need to make /nfs). If autofs supported direct mounts life would be even better ... Regards, Buchan
