SunOne Directory Server automount issue - PLEASE HELP!!!

It worked Gary, but what I had to do was re-jumpstart my sol9 server and remove all the IPLT pkgs, I know you can exclude them when you setup your jumpstart profile, but I was too lazy. I then did a fresh install of ds5.2 on the sol9 server and setup the server in a typical way without using tls and ssl. I then modified your automount ldif file with my own info. It barfed on the solaris automount stuff because I had already added the sol-automount stuff from the sol-client using the ldapaddent command, but the auto.* linux stuff copied right into the directory. I then re-started autofs on the linux client and I could su- user1 and also logout root and log back in as user1. BTW, the only 2 things I need to specify in the /etc/ldap.conf file are the host and the base. I currently have:

ssl no

tls_cacertdir /etc/openldap/cacerts

pam_password md5

but I don't think you really need them. The solaris 9 client could still su - user1, but in order for me to log out as root and log back in as user1 I had to modify my pam.conf file.

Gary, thankyou so much for your very detailed how-to instructions on the web. They are better than anything I could find from Sun. I think Sun wants you to pay for their advice. They are going to have a celebration lunch here in honor of our success at getting this setup, please feel free to join us if you're free this week for lunch.

hardware_man at 2007-7-6 13:54:39 >

I can't solve your problem #2, I can solve your problem #1 by:

On DS5.2 LDAP Server, ldapadd this ldif file:

dn: cn=/projects,ou=auto.master,dc=sprintlabs,dc=com

objectclass: top

objectclass: automount

automountinformation: ldap:ou=auto.projects,dc=sprintlabs,dc=com

automountkey: /projects

cn: /projects

dn: ou=auto.projects,dc=sprintlabs,dc=com

objectclass: top

objectclass: automountMap

automountmapname: auto.projects

ou: auto.projects

dn: cn=/,ou=auto.projects,dc=sprintlabs,dc=com

objectclass: top

objectclass: automount

automountinformation: 199.2.53.226:/projects/&

automountkey: /

cn: /

On RHEL4 LDAP Client

Login as root

# mkdir /projects

unmount all mounted autofs and "service autofs restart"

# cd /projects

# cd ip

# df -k

199.2.53.226::/projects/ip

16158081440864126464 92% /projects/ip

Gary

GaryTay at 2007-7-6 13:54:39 >

Hi Gary,

As I said, the automount mechanism works, but I have discovered a flaw. The filer that's hosting the nfs shares has an older version of ontap and we'll be updating it this Friday, but my Linux client has problems with the nfs shares on that filer. Here's some output:

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> etc]# cd /projects

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> projects]# ls -la

total 8

drwxr-xr-x2 root root0 Dec 14 17:02 .

drwxr-xr-x 26 root root 4096 Dec 14 16:47 ..

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> projects]# su - bills

-bash-3.00$ cd /projects

-bash-3.00$ ls -la

total 8

drwxr-xr-x2 root root0 Dec 14 17:02 .

drwxr-xr-x 26 root root 4096 Dec 14 16:47 ..

-bash-3.00$ cd ip

-bash: cd: ip: Permission denied

-bash-3.00$ ls -la

total 16

drwxr-xr-x3 root root0 Dec 14 17:13 .

drwxr-xr-x 26 root root 4096 Dec 14 16:47 ..

drwxrws 30 root 10001 8192 Aug 1 18:22 ip

-bash-3.00$ cd iog

-bash: cd: iog: Permission denied

-bash-3.00$ ls -la

total 24

drwxr-xr-x4 root root0 Dec 14 17:13 .

drwxr-xr-x 26 root root 4096 Dec 14 16:47 ..

drwxrws 30 root 10001 8192 Aug 1 18:22 iog

drwxrws 30 root 10001 8192 Aug 1 18:22 ip

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> projects]# service autofs status

Configured Mount Points:

/usr/sbin/automount --timeout=60 /homes ldap ou=auto.home,dc=sprintlabs,dc=com

/usr/sbin/automount --timeout=60 /projects ldap ou=auto.projects,dc=sprintlabs,dc=com

Active Mount Points:

--

/usr/sbin/automount --timeout=60 /homes ldap ou=auto.home,dc=sprintlabs,dc=com

/usr/sbin/automount --timeout=60 /projects ldap ou=auto.projects,dc=sprintlabs,dc=com

As you can see, autofs is somehow mounting the shares on the linux machine but they are invisible until the user tries to cd into them, and then they are not the ownership that exists on the filer. BTW on my solaris client the folders iog and ip mount under the local folder /projects and you can see them up front. You can also go into those folders as expected. Now the funny thing is, if I use another newer filer with ldap enabled on it, the linux client is happy and the behaviour for the mounted nfs shares is normal.

What's really weird is that there are no groups that I can find that have that gid 10001 and notice how the sticky bit is set in the inode table. Please help me Gary, thanks.

P.S. Gary, I thought of one more thing, do you know why if I uncomment the line #rootbinddn "cn=Directory Manager" then I cannot bind to the ldap server? I have a file in /etc called ldap.secret with the Directory Manager password, but I just typed it in there plain text. Was I supposed to get the crypted version of that password and put that in there? Thanks Gary.

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> projects]# cat /etc/ldap.conf

host ldap-test.sprintlabs.com

base dc=sprintlabs,dc=com

ldap_version 3

binddn cn=proxyagent,ou=profile,dc=sprintlabs,dc=com

bindpw proxy

#rootbinddn "cn=Directory Manager"

port 389

pam_filter objectclass=posixAccount

pam_login_attribute uid

pam_member_attribute memberUid

pam_password crypt

nss_base_passwd ou=people,dc=sprintlabs,dc=com?one

nss_base_shadow ou=people,dc=sprintlabs,dc=com?one

nss_base_group ou=group,dc=sprintlabs,dc=com?one

nss_base_netgroupou=netgroup,dc=sprintlabs,dc=com?one

#ssl start_tls

#tls_checkpeer yes

#tls_cacertfile /etc/openldap/cert7.pem

#tls_cacertdir /etc/openldap/cacerts

ssl no

P.S.S. Here's some output from /var/log/messages when I'm binding and attempting to mount those folders:

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> etc]# tail -f /var/log/messages

Dec 14 16:44:24 lin-client automount[3672]: lookup(ldap): got answer, but no first entry for (&(objectclass=automount)(cn=ip))

Dec 14 16:44:24 lin-client automount[3672]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=/))

Dec 14 16:49:26 lin-client su(pam_unix)[3738]: session opened for user bills by (uid=0)

Dec 14 16:49:26 lin-client automount[3740]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=bills))

Dec 14 16:49:26 lin-client automount[3740]: lookup(ldap): got answer, but no first entry for (&(objectclass=automount)(cn=bills))

Dec 14 16:49:26 lin-client automount[3740]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=/))

Dec 14 16:49:39 lin-client automount[3768]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=ip))

Dec 14 16:49:39 lin-client automount[3768]: lookup(ldap): got answer, but no first entry for (&(objectclass=automount)(cn=ip))

Dec 14 16:49:39 lin-client automount[3768]: lookup(ldap): got answer, but no first entry for (&(objectclass=nisObject)(cn=/))

Dec 14 16:49:53 lin-client su(pam_unix)[3636]: session closed for user bills

attached is a snoop output taken on lin-client and ldap-test (my linux ldap client and my solaris ldap server). At the time of the snoop I was authenticating and trying to mount ip and iog to /projects.

hardware_man at 2007-7-6 13:54:39 >

You're right Gary, it was a group thing. NIS is running on that older filer and enforcing groups and it didn't know my ldap groups. I had to change the gid of the ldap users to get it to work. What's funny though is that the shares are invisible until you cd into them. Can't figure that one out yet. BTW I was wrong above when I was saying that I had to create a local mount point on the linux machine called /projects/ip and change the automountKey to /projects/ip, I only had to make them both projects and then share /ip from the filer to /projects on the local linux machine to get it to work. Now if I could just make the shares visible on the local machine. BTW I was wrong about there being no group with the gid of 10001, there is one and it's the group on the folder I was trying to mount locally but couldn't. It's a NIS group, maybe I have to turn off NIS on the linux machine?

hardware_man at 2007-7-6 13:54:40 >

Gary,

I opologize. I was wrong again. To solve the "invisible" folder problem when mounting those remote shares to my local linux machine was to go into /etc/profile and add:

cd /projects/ip

cd /projects/iog

cd /projects/otg

cd /projects/videoip

cd /projects/adl

cd

this /etc/profile I see is the standard profile for someone that the admin gives a bash shell to in the ldap passwd file. It's the only work around I can think of for now but it works.

hardware_man at 2007-7-6 13:54:40 >

Gary,

My customer doesn't want to do the wild card solution, i.e...,

automountKey: /projects

and

automountInformation: 199.2.53.226:/tools/&

and then on the filer tools looks like:

lrwxrwxrwx1 root bin6 Dec 19 11:16 iog -> ../iog

lrwxrwxrwx1 root bin5 Dec 19 11:16 ip -> ../ip

lrwxrwxrwx1 root bin6 Dec 19 11:16 otg -> ../otg

lrwxrwxrwx1 root bin10 Dec 19 11:16 videoip -> ../videoip

(This way you don't use the wild card on the root of the filer and end up sharing /etc and stuff like that.)

"&" being the "wild card" I'm speaking of. He wants to directly mount

each and every folder under the filer's root "/" dir (iog, otg, videoip,

ip, and adl) to the automountKey "/projects". I've changed up the

information in the directory a thousand different ways and have had no

luck in accomplishing this.

The reason for my client's insistence on having each folder under the

root directly mounted that way is because those folders are actually

"Q-Trees" which is a NetApp term that means you can set quotas and blah, blah, blah on them. My best solution was to create a folder called

"/tools" and put sim links in it that pointed back to the folders under

the root using relative path names, i.e..., ln -s ../adl adl.

If I directly mounted all the filer shares to the same folder /projects

I ended up going into each of the folders and seeing the same thing that

was in the ip folder. So in other words when you populate the directory

with the auto.master and auto.projects stuff, the first one to grab

the /projects folder reigns supreme.

He said an acceptable solution would be to just mount ip to /projects

and all the others could be mounted to root, i.e..., /adl, /otg, /videoip, etc... That worked to a point, but all the folders ended up being mounted to folders with their own names, i.e..., /adl/adl, and /otg/otg, etc....

He then said that the most important thing is just to directly mount ip

to /projects and I did and it seems to work, but I just discovered this

morning that if you go into /projects on the client and you type "cd

<any folder name>, i.e.., cd /projects/tokyo, you will go into that

folder and the same files that are in ip will be in that new mystery

folder.

Can anybody help me do what my customer really wants, i.e..., directly

mount ip, otg, videoip, etc... to /projects without using a wildcard in

the automountKey?

hardware_man at 2007-7-21 15:00:37 >

Gary, forget the automount stuff. I spent way too much time on that and in the end they decided that linux developers will mount their own remote nfs shares via the fstab file on their linux production machines. Eventually I'd like to create a web page with clear and concise directions on how to do heiarchical mounting with autofs on linux, until this project is over I'll have to accept the fact that there is not enough support currently available out there for me to do what I want.

Gary, if I follow your directions exactly as you've layed them out for using tls and ssl self signed certificates between the sun ds5.2 server and the linux client, it doesn't work. The best I can do is run the showcerts command on the linux client and it'll do a handshake with the server, but if I try to go "id tuser" it doesn't work, so in other words I cannot bind to the ldap server via tls because the cert that I copied over from the server appears to belong to the server and not the local client. Take my word for it, I did everything exactly as you've outlined on your web page. The only difference being that I've got a newer version of ssl installed on my sun ldap server. Here is my configuration:

******Server*******

ssl version openssl0.9.8a

<a href="mailto:root&#64;ldap-test" target="_blank">root@ldap-test</a>:/var/Sun/mps/alias 181% ls -la

total 1178

drwxr-x4 rootother512 Jan 4 10:49 .

drwxr-xr-x 19 rootother512 Dec 30 15:18 ..

-rw-1 rootother65536 Dec 30 15:19 admin-serv-ldap-test-cert8.db

-rw-1 rootother32768 Dec 30 15:19 admin-serv-ldap-test-key3.db

drwxr-xr-x2 rootother512 Jan 3 11:05 backup_Tue

drwxr-xr-x2 rootother512 Jan 4 10:47 backup_Wed

-rwxr-xr-x1 rootother401748 Dec 30 15:17 libnssckbi.so

-rw-1 rootother32768 Dec 30 15:19 secmod.db

-rw-1 rootother65536 Jan 4 10:49 slapd-ldap-test-cert8.db

-rw-1 rootother32768 Jan 4 10:49 slapd-ldap-test-key3.db

-r--1 rootother 36 Jan 3 11:23 slapd-ldap-test-pin.txt

<a href="mailto:root&#64;ldap-test" target="_blank">root@ldap-test</a>:/var/Sun/mps 167% /usr/local/ssl/bin/openssl s_client -connect localhost:636 -showcerts

CONNECTED(00000003)

depth=0/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.sprin tlabs.com

verify error:num=18:self signed certificate

verify return:1

depth=0/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.sprin tlabs.com

verify return:1

Certificate chain

0s:/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.spr intlabs.com

i:/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.spr intlabs.com

--BEGIN CERTIFICATE--

MIICaDCCAdGgAwIBAgIFAIExm0gwDQYJKoZIhvcNAQEEBQAwazELMAkGA1UE BhMC

VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEzARBgNVBAcTCkJ1cmxpbmdhbWUx DzAN

BgNVBAoTBlNwcmludDEhMB8GA1UEAxMYbGRhcC10ZXN0LnNwcmludGxhYnMu Y29t

MB4XDTA2MDEwNDE4NDg0OFoXDTA3MDQwNDE4NDg0OFowazELMAkGA1UEBhMC VVMx

EzARBgNVBAgTCkNhbGlmb3JuaWExEzARBgNVBAcTCkJ1cmxpbmdhbWUxDzAN BgNV

BAoTBlNwcmludDEhMB8GA1UEAxMYbGRhcC10ZXN0LnNwcmludGxhYnMuY29t MIGf

MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWRms6XqWmAqJbNouTD25yVdTW NDRu

kf38rgqyAZApcp7w2wnhNRBBVUtHPebHJZCWr9BlouaawUnEfv8SjGoz4fht A9mV

u3yx+VjDKiZNrUvuUlaz6LevMnTicyycQ7nA1C4734Mw/siZymCye+0ogE2h WFOQ

vDkJ9RbW2+sqXQIDAQABoxgwFjAUBglghkgBhvhCAQEBAf8EBAMCBkAwDQYJ KoZI

hvcNAQEEBQADgYEAZ+SnLHhsZ5Y7v4oG3u1PojYVG7Y/YAHvAKkJ1aUQKPOO bdSo

J3/J4nul2nqMvRXv60K5tScXCCEBHIN0L7mPaG3C9A6ZWjVzljqvgFZ43ZAS PuP4

mj5/XkqZxP2RAoITgGHFR+bRNfXDF4n4ToipSe9VbncRmWD5lCXKoVemt3U=

--END CERTIFICATE--

Server certificate

subject=/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-te st.sprintlabs.com

issuer=/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-tes t.sprintlabs.com

Acceptable client certificate CA names

/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.sprin tlabs.com

SSL handshake has read 876 bytes and written 342 bytes

New, TLSv1/SSLv3, Cipher is RC4-MD5

Server public key is 1024 bit

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol : TLSv1

Cipher: RC4-MD5

Session-ID:15FDD6C6CB13C4E052F7DD6EB6659B7477BDAC570CEE09F212A3913A8EFC D9D2Session-ID-ctx:

Master-Key:7363E25B9D0BF0BD68BF494AA1CEC30766894C7E679F236BD5B7EB27302C 60E0B00C3E4186D88230A2F221D662A8C8C5

Key-Arg: None

Start Time: 1136400789

Timeout: 300 (sec)

Verify return code: 18 (self signed certificate)

closed

******linux client******

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> ~]# openssl s_client -connect ldap-test.sprintlabs.com:636 -showcerts

CONNECTED(00000003)

depth=0/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.sprin tlabs.com

verify error:num=18:self signed certificate

verify return:1

depth=0/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.sprin tlabs.com

verify return:1

Certificate chain

0s:/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.spr intlabs.com

i:/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.spr intlabs.com

--BEGIN CERTIFICATE--

MIICaDCCAdGgAwIBAgIFAIExm0gwDQYJKoZIhvcNAQEEBQAwazELMAkGA1UE BhMC

VVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEzARBgNVBAcTCkJ1cmxpbmdhbWUx DzAN

BgNVBAoTBlNwcmludDEhMB8GA1UEAxMYbGRhcC10ZXN0LnNwcmludGxhYnMu Y29t

MB4XDTA2MDEwNDE4NDg0OFoXDTA3MDQwNDE4NDg0OFowazELMAkGA1UEBhMC VVMx

EzARBgNVBAgTCkNhbGlmb3JuaWExEzARBgNVBAcTCkJ1cmxpbmdhbWUxDzAN BgNV

BAoTBlNwcmludDEhMB8GA1UEAxMYbGRhcC10ZXN0LnNwcmludGxhYnMuY29t MIGf

MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWRms6XqWmAqJbNouTD25yVdTW NDRu

kf38rgqyAZApcp7w2wnhNRBBVUtHPebHJZCWr9BlouaawUnEfv8SjGoz4fht A9mV

u3yx+VjDKiZNrUvuUlaz6LevMnTicyycQ7nA1C4734Mw/siZymCye+0ogE2h WFOQ

vDkJ9RbW2+sqXQIDAQABoxgwFjAUBglghkgBhvhCAQEBAf8EBAMCBkAwDQYJ KoZI

hvcNAQEEBQADgYEAZ+SnLHhsZ5Y7v4oG3u1PojYVG7Y/YAHvAKkJ1aUQKPOO bdSo

J3/J4nul2nqMvRXv60K5tScXCCEBHIN0L7mPaG3C9A6ZWjVzljqvgFZ43ZAS PuP4

mj5/XkqZxP2RAoITgGHFR+bRNfXDF4n4ToipSe9VbncRmWD5lCXKoVemt3U=

--END CERTIFICATE--

Server certificate

subject=/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-te st.sprintlabs.com

issuer=/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-tes t.sprintlabs.com

Acceptable client certificate CA names

/C=US/ST=California/L=Burlingame/O=Sprint/CN=ldap-test.sprin tlabs.com

SSL handshake has read 876 bytes and written 336 bytes

New, TLSv1/SSLv3, Cipher is RC4-MD5

Server public key is 1024 bit

SSL-Session:

Protocol : TLSv1

Cipher: RC4-MD5

Session-ID:15FDB301187B97778C8AA4D3E4FDD3FE28675F71A141802819426BA987CF FD8ASession-ID-ctx:

Master-Key:49DE2C81C7F2BBA39B7C02E3945512FAD862508A119A89B566D85F5E2F50 6C14C5B2CD442A5B0E252E59FAC36746E6AA

Key-Arg: None

Krb5 Principal: None

Start Time: 1136400942

Timeout: 300 (sec)

Verify return code: 18 (self signed certificate)

closed

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> ~]# cat /etc/ldap.conf

host ldap-test.sprintlabs.com

base dc=sprintlabs,dc=com

ldap_version 3

port 389

binddn cn=proxyagent,ou=profile,dc=sprintlabs,dc=com

bindpw proxy

rootbinddn "cn=Directory Manager"

pam_filter objectclass=posixAccount

pam_login_attribute uid

pam_member_attribute memberUid

pam_password md5

nss_base_passwd ou=People,dc=sprintlabs,dc=com?one

nss_base_shadow ou=People,dc=sprintlabs,dc=com?one

nss_base_group ou=group,dc=sprintlabs,dc=com?one

nss_base_netgroupou=netgroup,dc=sprintlabs,dc=com?one

tls_checkpeer yes

#ssl yes

ssl start_tls

tls_cacertdir /etc/openldap/cacerts

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> cacerts]# ls -la

total 20

drwxr-xr-x 2 root root 4096 Jan 4 11:23 .

drwxr-xr-x 3 root root 4096 Dec 29 15:01 ..

-rw-r--r-- 1 root root 1181 Jan 3 10:55 cert7.pem

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> cacerts]# pwd

/etc/openldap/cacerts

<a href="mailto:&#91;root&#64;lin-client" target="_blank">[root@lin-client</a> cacerts]#

Can you see anything I have done wrong Gary, the cert shows up in the ldap gui and I'm using both secure and non-secure ports. I'm using cipher family RSA and I'm using SSHA (my client's request). He doesn't want to send passwords in the clear.

hardware_man at 2007-7-21 15:00:37 >