My overall goal is still getting this EMC to work so I don't have to take it apart and send it back. I think I am getting real close (to not sending it back). Richard M. graciously helped me through some problems, probably self-induced, with loading of the NIS/Solaris schema mentioned in the FDS Solaris How-To. After following the steps in the How-To, I purged and redid the client profile with a defined TTL of 5 minutes and then I erased the EMC's client/bind/profile config and started over. Many more things now work. When, on the EMC, I issue "server_ldap servername -info -verbose" I see that it now has the profile's TTL and timestamp and it actual has a correct mapping of group to ou=Groups. Progress! However, as an example pasted below shows, it was still only resolving users by numeric uid. No attempt as resolving group name/id worked. No problem binding that I immediately saw. This *seemed* like some sort of an attribute mapping issue, but then I saw that group queries worked maybe 1 time in 4. When I started looking more closely at LDAP logs, I realized the NAS' queries weren't making it to the LDAP server/daemon. Name resolution. The EMC NS350 is functionally divided into a "control station" and a "data mover". These each have their own /etc/hosts and nsswitch.conf. DNS lookup for LDAP server apparently wasn't fast enough for the EMC, so I have temporarily changed LDAP server spec in the iPlanet client profile to the LDAP server's IP. Now I am seeing consistent results for group/user queries. I'll add an updated hosts file to the data mover. So the initial NIS schema and profile simply hid another problem. It is looking like I might be able to keep this thing. Jim [nasadmin]$ server_ldap server_2 -lookup -group staff server_2 : Unable to get information for group staff [nasadmin]$ server_ldap server_2 -lookup -group 2611 server_2 : Unable to get information for group 2600 [nasadmin]$ server_ldap server_2 -lookup -gid 2611 server_2 : Unable to get information for gid 2600 [nasadmin]$ server_ldap server_2 -lookup -user jimh server_2 : Unable to get information for user jimh [nasadmin]$ server_ldap server_2 -lookup -uid jim server_2 : Unable to get information for uid 0 [nasadmin]$ server_ldap server_2 -lookup -uid 1111 server_2 : user: jim, uid: 1111, gid: 2611 Jim Hogan wrote: > I am trialing an EMC NS350 as a candidate NAS to serve CIFS and NFS > clients (XP, OSX, and Linux). I have set up a working Samba 3.x > domain with FDS 1.01 back end and I have an older, borrowed NetApp > Filer (DataOnTap 6.5) working fine as a temporary NFS/CIFS server > authing against LDAP/Samba. > > With the EMC, official support is limited to AD and Sun iPlanet LDAP. > The latter limitation of support is turning out to be less theoretical > than I might have hoped. It seems like the EMC wants to behave like > an "official" iPlanet/Sun client. > > I am thinking that the solution to this problem could be to config FDS > as laid out in the Solaris Client How-To here: > > http://directory.fedora.redhat.com/wiki/Howto:SolarisClient > > I have a couple of questions. First, has anybody done this > (integrated an EMC) who has a cut-and-dried report on doing it? > Second, the second schema for NIS domain seems relevant only if the > client is also binding to a NIS domain. I'm not. Or hope not to be :) > Then, is the following step -- adding nisdomain attribute -- also > optional? Seems like it should be. > I am going to try the EMC with the stock set of > serviceSearchDescriptor listed in the How-To's example profile. If > anybody else has improved on that for an EMC, I would be interested in > your comments. > > There were both pros and cons when comparing NetApp and EMC offerings > this time. It is a bit ironic that NetApp isn't nearly as Linux-y as > EMCs Celerra product, yet LDAP was a breeze to set up on the Filer > itself. In contrast, very little client-side non-iPlanet > configuration is possible on the EMC, so I don't see much alternative > to going through this server-side Solaris-style config change (and > hope that it works!) > > Thanks, > > Jim > > > -- > Fedora-directory-users mailing list > Fedora-directory-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users >
