On Mon, 26 Feb 2007, Jan Iven wrote: <snip> >> What is the correct way to fix this? >> >> Should I be adding the /lib64/security into the ld config paths, or creating >> symbolic links in /lib/security to the correct paths, or should proftpd really >> be looking for these libraries in their correction locations? (I can notify >> the author if this is the case). > > Probably the last would be the best. Other service-specific PAM config > file (under /etc/pam.d/) use something like > > /lib/security/$ISA/pam_rootok.so > > and the $ISA part gets expanded differently on 32bit and on 64bit (this > is not a shell variable). > So would suggest to change /etc/pam.d/proftpd to use $ISA for a test and > then file this with the upstream author... Of course $ISA has to expand to something pretty freaky for that path to work -- though indeed it does seem to do the right thing!! Other pam.d/ config files seem to just refer to the module name with no explicit path, and that also seems to work, e.g. the default sshd entry: #%PAM-1.0 auth required pam_stack.so service=system-auth auth required pam_nologin.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth session required pam_stack.so service=system-auth session required pam_loginuid.so In case you think that pam_stack/pam_nologin are somehow special, we add our local pam stuff (again without paths), and that seems to work for us... # DAMTP added part account required pam_simpaccess.so minuid=0 etc etc. At some point the Solaris pam stuff stopped including the equivalent path (/usr/lib/security/$ISA) in the pam.conf too. I can't remember when that happened though (too long ago). Of course what you are supposed to do if the pam modules are installed in a non-standard location is a different matter!! -- Jon Peatfield, Computer Officer, DAMTP, University of Cambridge Mail: [log in to unmask] Web: http://www.damtp.cam.ac.uk/