From nlf482n at med.usyd.edu.au Thu Aug 13 06:28:54 2009 From: nlf482n at med.usyd.edu.au (Nik Lam) Date: Thu, 13 Aug 2009 16:28:54 +1000 Subject: excluding multipath devices using a pre script during kickstart Message-ID: <1250144934.11245.13.camel@chipolata.med.usyd.edu.au> Hi, I'm having trouble using kickstart to install onto an HP BL 465c G1 blade that has 2 LUNs presented to it from fibre-channel SAN. The first one is where I want to install the system to, the second one is for use later on. A manual install from media works fine with no modifications to the system, however the kickstart fails unless we remove all but one of the LUNs presented to the system. This appears to be some kind of bug with kickstart. Unfortunately we don't have administrative control over the SAN, so it's inconvenient to modify what LUNs are presented to a host for an install (and in an emergency rebuild, we'd have to wait for them). Can anyone here provide me with clues on how to mask or filter the unneeded multipath devices during the install? I think a pre-script must be the way, but I'm not sure where to start. Regards, Nik From Andy.Q.Wu at seagate.com Thu Aug 13 07:03:28 2009 From: Andy.Q.Wu at seagate.com (Andy.Q.Wu at seagate.com) Date: Thu, 13 Aug 2009 15:03:28 +0800 Subject: Andy Q Wu/Seagate is out of the office. Message-ID: I will be out of the office starting 08/06/2009 and will not return until 08/16/2009. I am on leave Aug 6-14. Please contact Xinxu, Zongzhao, Xuecheng for ESG test development issue. Contact Carlo, Meherzad, Jing Ning for field tools issue. Contact Salmiah or my boss David S Wong for admin issue. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Thomas.vonSteiger at swisscom.com Thu Aug 13 10:18:12 2009 From: Thomas.vonSteiger at swisscom.com (Thomas.vonSteiger at swisscom.com) Date: Thu, 13 Aug 2009 12:18:12 +0200 Subject: excluding multipath devices using a pre script during kickstart In-Reply-To: <1250144934.11245.13.camel@chipolata.med.usyd.edu.au> References: <1250144934.11245.13.camel@chipolata.med.usyd.edu.au> Message-ID: <1FC8A0BAFBBD9749BB1F06010D23C8A59B1899AB@sg000035.corproot.net> Hi, Filter for storage devices can be defined in /etc/lvm/lvm.conf. We are install systems only on san storage always on mpath devices. Root filesystem are located on mpath devices for boot. For this we use this filter: filter = [ "a|/dev/mapper/mpath|", "r|.*|" ] regards, Thomas -----Original Message----- From: redhat-install-list-bounces at redhat.com [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Nik Lam Sent: Thursday, August 13, 2009 8:29 AM To: Redhat-install-list at redhat.com Subject: excluding multipath devices using a pre script during kickstart Hi, I'm having trouble using kickstart to install onto an HP BL 465c G1 blade that has 2 LUNs presented to it from fibre-channel SAN. The first one is where I want to install the system to, the second one is for use later on. A manual install from media works fine with no modifications to the system, however the kickstart fails unless we remove all but one of the LUNs presented to the system. This appears to be some kind of bug with kickstart. Unfortunately we don't have administrative control over the SAN, so it's inconvenient to modify what LUNs are presented to a host for an install (and in an emergency rebuild, we'd have to wait for them). Can anyone here provide me with clues on how to mask or filter the unneeded multipath devices during the install? I think a pre-script must be the way, but I'm not sure where to start. Regards, Nik _______________________________________________ Redhat-install-list mailing list Redhat-install-list at redhat.com https://www.redhat.com/mailman/listinfo/redhat-install-list To Unsubscribe Go To ABOVE URL or send a message to: redhat-install-list-request at redhat.com Subject: unsubscribe From nileshnjoshi at gmail.com Fri Aug 14 00:33:31 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Thu, 13 Aug 2009 17:33:31 -0700 Subject: open ldap configuration on rhel3-u4 Message-ID: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> Hi, I have installed openldap-2.0.27-23 on my server. I have configured certificate and path is mentioned in slapd.conf file. I am able to create root DN and also able to add user to it. When I search using cn=manager,dc=test,dc=com, it gives me correct answers. Howere, whenever I search using user id, I see error 49. ldapsearch -x -b "ou=people,dc=test,dc=com" -D "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' In logs, I see: conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 conn=11 op=0 RESULT tag=97 err=49 text= conn=11 fd=10 closed (connection lost) I would like to have openldap running without sasl. How should I configure the same? How can I fix this issue? Thanks and Regards, -Nilesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Fri Aug 14 01:16:33 2009 From: ricks at nerd.com (Rick Stevens) Date: Thu, 13 Aug 2009 18:16:33 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> Message-ID: <4A84BAF1.30507@nerd.com> Nilesh Joshi wrote: > Hi, > > I have installed openldap-2.0.27-23 on my server. > > I have configured certificate and path is mentioned in slapd.conf file. > > I am able to create root DN and also able to add user to it. > > When I search using cn=manager,dc=test,dc=com, it gives me correct answers. > Howere, whenever I search using user id, I see error 49. > > ldapsearch -x -b "ou=people,dc=test,dc=com" -D > "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' > > In logs, I see: > conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) > conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 > conn=11 op=0 RESULT tag=97 err=49 text= > conn=11 fd=10 closed (connection lost) > > I would like to have openldap running without sasl. > > How should I configure the same? How can I fix this issue? Error 49 is "invalid credentials," meaning that you didn't hand the ldapsearch the right password for the user you're trying to bind as. Try it again, but rather than using the "-W" (interactive) flag, try: -w 'your-password-here' If the password has shell metacharacters in it, they may be being interpreted by the shell before being handed to the ldapsearch command. Using the -w and the password enclosed in single quotes prevents that. You also have to make sure that the user you're trying to bind as has access to the userPassword attribute in the slapd.conf file: access to attrs=userPassword by anonymous auth by self write by * none ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - I never drink water because of the disgusting things that fish do - - in it. - - -- WC. Fields - ---------------------------------------------------------------------- From nileshnjoshi at gmail.com Fri Aug 14 01:36:55 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Thu, 13 Aug 2009 18:36:55 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <4A84BAF1.30507@nerd.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> Message-ID: <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> Thanks Rick. I have checked using -w password. The exact command I tried was: ldapsearch -x -b "ou=people,dc=test,dc=com" -D "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' Also added: access to attrs=userPassword by anonymous auth by self write by * none However the result was same. I have confirmed that password is password for now. I think, I am missing something in configuration. Can I use LDAP without sasl and if yes, what I need to do? Thanks and Regards, -Nilesh On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: > Nilesh Joshi wrote: > >> Hi, >> >> I have installed openldap-2.0.27-23 on my server. >> >> I have configured certificate and path is mentioned in slapd.conf file. >> >> I am able to create root DN and also able to add user to it. >> >> When I search using cn=manager,dc=test,dc=com, it gives me correct >> answers. >> Howere, whenever I search using user id, I see error 49. >> >> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >> >> In logs, I see: >> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >> conn=11 op=0 RESULT tag=97 err=49 text= >> conn=11 fd=10 closed (connection lost) >> >> I would like to have openldap running without sasl. >> >> How should I configure the same? How can I fix this issue? >> > > Error 49 is "invalid credentials," meaning that you didn't hand the > ldapsearch the right password for the user you're trying to bind as. > Try it again, but rather than using the "-W" (interactive) flag, try: > > -w 'your-password-here' > > If the password has shell metacharacters in it, they may be being > interpreted by the shell before being handed to the ldapsearch command. > Using the -w and the password enclosed in single quotes prevents that. > > You also have to make sure that the user you're trying to bind as has > access to the userPassword attribute in the slapd.conf file: > > access to attrs=userPassword > by anonymous auth > by self write > by * none > > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - I never drink water because of the disgusting things that fish do - > - in it. - > - -- WC. Fields - > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nlf482n at med.usyd.edu.au Fri Aug 14 06:22:15 2009 From: nlf482n at med.usyd.edu.au (Nik Lam) Date: Fri, 14 Aug 2009 16:22:15 +1000 Subject: excluding multipath devices using a pre script during kickstart In-Reply-To: <1FC8A0BAFBBD9749BB1F06010D23C8A59B1899AB@sg000035.corproot.net> References: <1250144934.11245.13.camel@chipolata.med.usyd.edu.au> <1FC8A0BAFBBD9749BB1F06010D23C8A59B1899AB@sg000035.corproot.net> Message-ID: <1250230935.18960.46.camel@chipolata.med.usyd.edu.au> Thanks Thomas - that looks promising. Do you ever use this LVM-based filtering with a kickstart installation? I'm unsure of what point the lvm.conf file would be read during the installation process. I might try some experiments, but I'm not too hopeful. I've noticed there is a multipath option in kickstart, which includes a --rule= parameter, but I can't find any documentation of how it's used. Regards, Nik On Thu, 2009-08-13 at 12:18 +0200, Thomas.vonSteiger at swisscom.com wrote: > Hi, > > Filter for storage devices can be defined in /etc/lvm/lvm.conf. > We are install systems only on san storage always on mpath devices. Root filesystem are located on mpath devices for boot. > For this we use this filter: > > filter = [ "a|/dev/mapper/mpath|", "r|.*|" ] > > regards, > Thomas > > -----Original Message----- > From: redhat-install-list-bounces at redhat.com [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Nik Lam > Sent: Thursday, August 13, 2009 8:29 AM > To: Redhat-install-list at redhat.com > Subject: excluding multipath devices using a pre script during kickstart > > Hi, > > I'm having trouble using kickstart to install onto an HP BL 465c G1 > blade that has 2 LUNs presented to it from fibre-channel SAN. The first > one is where I want to install the system to, the second one is for use > later on. > > A manual install from media works fine with no modifications to the > system, however the kickstart fails unless we remove all but one of the > LUNs presented to the system. This appears to be some kind of bug with > kickstart. > > Unfortunately we don't have administrative control over the SAN, so it's > inconvenient to modify what LUNs are presented to a host for an install > (and in an emergency rebuild, we'd have to wait for them). > > Can anyone here provide me with clues on how to mask or filter the > unneeded multipath devices during the install? I think a pre-script must > be the way, but I'm not sure where to start. > > Regards, > > Nik > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe From alok.rhct at gmail.com Fri Aug 14 06:29:35 2009 From: alok.rhct at gmail.com (alok pandey) Date: Fri, 14 Aug 2009 11:59:35 +0530 Subject: Is there any way to proxy/redirect SSL-connection to remote host Message-ID: Gurus, Is there any way to proxy/redirect SSL-connections. The scenario is : [Browser]---HTTPS-->[Proxy-pass-WITHPUBLIC-IP (Apache)]---HTTPS-->[Back-end(tomcat)] (Private Network) I want to setup Apache proxy-pass or redirection for all HTTPS/HTTP requests, as we have number of sit running behind one public ip. My setup is working fine for HTTP request but not for HTTPS request. BTW, I am aware of that SSL-connection does not allow man-in-middle attack and the proxy-pass(Apache) [in above scenario] is behaving same for it. I want to know that : --Is there any way to do it (by redirect) by iptables rules DNAT? --Is it possible to write a iptables rule based on URL-request, If yes, can you provide me some good example or any pointer ! --Have any one done this before ? --What are the alternate option for it ? After lots of Gooogling I found one trick which sense as : Browser--HTTPS-->Proxy-Pass----AJP---->back-end(tomcate) So , will the above work ? what points need to be consider while going for this setup. Hope I am clear enough with my problem. I will love to provide more details , if needed for better understanding. -- Thanks ALOK PANDEY -------------- next part -------------- An HTML attachment was scrubbed... URL: From nileshnjoshi at gmail.com Fri Aug 14 14:44:30 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Fri, 14 Aug 2009 07:44:30 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> Message-ID: <7f9821b0908140744j62060858sb644d2784a212a2b@mail.gmail.com> Any idea what's wrong in setup? Regards, -Nilesh On Thu, Aug 13, 2009 at 6:36 PM, Nilesh Joshi wrote: > Thanks Rick. > > I have checked using -w password. The exact command I tried was: > > ldapsearch -x -b "ou=people,dc=test,dc=com" -D > "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' > > Also added: > access to attrs=userPassword > by anonymous auth > by self write > by * none > > However the result was same. I have confirmed that password is password for > now. > > I think, I am missing something in configuration. Can I use LDAP without > sasl and if yes, what I need to do? > > Thanks and Regards, > -Nilesh > > > > On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: > >> Nilesh Joshi wrote: >> >>> Hi, >>> >>> I have installed openldap-2.0.27-23 on my server. >>> >>> I have configured certificate and path is mentioned in slapd.conf file. >>> >>> I am able to create root DN and also able to add user to it. >>> >>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>> answers. >>> Howere, whenever I search using user id, I see error 49. >>> >>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>> >>> In logs, I see: >>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>> conn=11 op=0 RESULT tag=97 err=49 text= >>> conn=11 fd=10 closed (connection lost) >>> >>> I would like to have openldap running without sasl. >>> >>> How should I configure the same? How can I fix this issue? >>> >> >> Error 49 is "invalid credentials," meaning that you didn't hand the >> ldapsearch the right password for the user you're trying to bind as. >> Try it again, but rather than using the "-W" (interactive) flag, try: >> >> -w 'your-password-here' >> >> If the password has shell metacharacters in it, they may be being >> interpreted by the shell before being handed to the ldapsearch command. >> Using the -w and the password enclosed in single quotes prevents that. >> >> You also have to make sure that the user you're trying to bind as has >> access to the userPassword attribute in the slapd.conf file: >> >> access to attrs=userPassword >> by anonymous auth >> by self write >> by * none >> >> ---------------------------------------------------------------------- >> - Rick Stevens, Systems Engineer ricks at nerd.com - >> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >> - - >> - I never drink water because of the disgusting things that fish do - >> - in it. - >> - -- WC. Fields - >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Fri Aug 14 17:04:15 2009 From: ricks at nerd.com (Rick Stevens) Date: Fri, 14 Aug 2009 10:04:15 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> Message-ID: <4A85990F.5080806@nerd.com> Nilesh Joshi wrote: > Thanks Rick. > > I have checked using -w password. The exact command I tried was: > > ldapsearch -x -b "ou=people,dc=test,dc=com" -D > "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' Did you enclose the password in single quotes to mask its value? > Also added: > access to attrs=userPassword > by anonymous auth > by self write > by * none That may not be adequate. That simply allows a user to authenticate against the LDAP database. It does NOT allow a regular user to search the entire database. Let's get rid of the error 49 first, then we'll worry about the rest. > However the result was same. I have confirmed that password is password for > now. If you're using SASL, remember that all the passwords must be stored in cleartext. If the password you're going to use is in the LDAP database, it must be stored in cleartext--NOT some excrypted format such as {MD5} cypherstring {SSHA} cypherstring If the password is in the Cyrus SASL database, it too has to be in cleartext. This is one of the weaknesses of SASL. If you're going to use encrypted passwords in the database, you'll need to use SSL or KRB5 as the transport mechanism. > I think, I am missing something in configuration. Can I use LDAP without > sasl and if yes, what I need to do? You can, but it's not recommended. Try putting this line in slapd.conf: allow bind_v2 bind_anon_cred bind_anon_dn Oh, and by the way, we prefer bottom posting on the list. > On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: > >> Nilesh Joshi wrote: >> >>> Hi, >>> >>> I have installed openldap-2.0.27-23 on my server. >>> >>> I have configured certificate and path is mentioned in slapd.conf file. >>> >>> I am able to create root DN and also able to add user to it. >>> >>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>> answers. >>> Howere, whenever I search using user id, I see error 49. >>> >>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>> >>> In logs, I see: >>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>> conn=11 op=0 RESULT tag=97 err=49 text= >>> conn=11 fd=10 closed (connection lost) >>> >>> I would like to have openldap running without sasl. >>> >>> How should I configure the same? How can I fix this issue? >>> >> Error 49 is "invalid credentials," meaning that you didn't hand the >> ldapsearch the right password for the user you're trying to bind as. >> Try it again, but rather than using the "-W" (interactive) flag, try: >> >> -w 'your-password-here' >> >> If the password has shell metacharacters in it, they may be being >> interpreted by the shell before being handed to the ldapsearch command. >> Using the -w and the password enclosed in single quotes prevents that. >> >> You also have to make sure that the user you're trying to bind as has >> access to the userPassword attribute in the slapd.conf file: >> >> access to attrs=userPassword >> by anonymous auth >> by self write >> by * none >> >> ---------------------------------------------------------------------- >> - Rick Stevens, Systems Engineer ricks at nerd.com - >> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >> - - >> - I never drink water because of the disgusting things that fish do - >> - in it. - >> - -- WC. Fields - >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe -- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Never test for an error condition you don't know how to handle. - ---------------------------------------------------------------------- From nileshnjoshi at gmail.com Fri Aug 14 22:03:49 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Fri, 14 Aug 2009 15:03:49 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <4A85990F.5080806@nerd.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> Message-ID: <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> Hi Rick, I have generated cert again and started slapd. Now I see following in logs: conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 It's same for below 2 commands: 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and restarted openldap, the result is same. It looks like error 49 is gone. What else I need to do to fix this issue. Thanks and Regards, -Nilesh On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens wrote: > Nilesh Joshi wrote: > >> Thanks Rick. >> >> I have checked using -w password. The exact command I tried was: >> >> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >> > > Did you enclose the password in single quotes to mask its value? > > Also added: >> access to attrs=userPassword >> by anonymous auth >> by self write >> by * none >> > > That may not be adequate. That simply allows a user to authenticate > against the LDAP database. It does NOT allow a regular user to search > the entire database. Let's get rid of the error 49 first, then we'll > worry about the rest. > > However the result was same. I have confirmed that password is password for >> now. >> > > If you're using SASL, remember that all the passwords must be stored in > cleartext. If the password you're going to use is in the LDAP database, > it must be stored in cleartext--NOT some excrypted format such as > > {MD5} cypherstring > {SSHA} cypherstring > > If the password is in the Cyrus SASL database, it too has to be in > cleartext. This is one of the weaknesses of SASL. > > If you're going to use encrypted passwords in the database, you'll need > to use SSL or KRB5 as the transport mechanism. > > I think, I am missing something in configuration. Can I use LDAP without >> sasl and if yes, what I need to do? >> > > You can, but it's not recommended. Try putting this line in slapd.conf: > > allow bind_v2 bind_anon_cred bind_anon_dn > > Oh, and by the way, we prefer bottom posting on the list. > > On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: >> >> Nilesh Joshi wrote: >>> >>> Hi, >>>> >>>> I have installed openldap-2.0.27-23 on my server. >>>> >>>> I have configured certificate and path is mentioned in slapd.conf file. >>>> >>>> I am able to create root DN and also able to add user to it. >>>> >>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>> answers. >>>> Howere, whenever I search using user id, I see error 49. >>>> >>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>> >>>> In logs, I see: >>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>> conn=11 fd=10 closed (connection lost) >>>> >>>> I would like to have openldap running without sasl. >>>> >>>> How should I configure the same? How can I fix this issue? >>>> >>>> Error 49 is "invalid credentials," meaning that you didn't hand the >>> ldapsearch the right password for the user you're trying to bind as. >>> Try it again, but rather than using the "-W" (interactive) flag, try: >>> >>> -w 'your-password-here' >>> >>> If the password has shell metacharacters in it, they may be being >>> interpreted by the shell before being handed to the ldapsearch command. >>> Using the -w and the password enclosed in single quotes prevents that. >>> >>> You also have to make sure that the user you're trying to bind as has >>> access to the userPassword attribute in the slapd.conf file: >>> >>> access to attrs=userPassword >>> by anonymous auth >>> by self write >>> by * none >>> >>> ---------------------------------------------------------------------- >>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>> - - >>> - I never drink water because of the disgusting things that fish do - >>> - in it. - >>> - -- WC. Fields - >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > -- > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Never test for an error condition you don't know how to handle. - > > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Fri Aug 14 22:25:33 2009 From: ricks at nerd.com (Rick Stevens) Date: Fri, 14 Aug 2009 15:25:33 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> Message-ID: <4A85E45D.7010506@nerd.com> Nilesh Joshi wrote: > Hi Rick, > > I have generated cert again and started slapd. > > Now I see following in logs: > conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) > conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 > It's same for below 2 commands: > 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D > "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" > 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D > "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" > > I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and restarted > openldap, the result is same. > > It looks like error 49 is gone. Ok, if error 49 is gone, but you're not getting any data back, then user "nilesh" probably doesn't have read access to the database. If you have your slapd manual handy, read up on the "access" directives. If you want a user to see any and all of their info, then you need a directive such as: access to * by self read by * none in slapd.conf. That permits someone to read their own data. If you want to let them modify their data: access to * by self write by * none (note that "write" permission also includes all lower permissions such as auth, read, search, etc.) > What else I need to do to fix this issue. Looks like you're authenticating fine now, but you have to set up access rules to allow users to see things. Here's a good on-line reference book on how to manage an LDAP server: http://www.zytrax.dom/books/ldap Also, the OpenLDAP System Admin Guide should have been placed in /usr/share/doc/openldap-servers-version/guide.html (replace "version" with the appropriate version number) when you installed the OpenLDAP server RPM. You can view it by opening a browser and going to file:///usr/share/doc/opeenldap-servers-version/guide.html > > Thanks and Regards, > -Nilesh > > On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens wrote: > >> Nilesh Joshi wrote: >> >>> Thanks Rick. >>> >>> I have checked using -w password. The exact command I tried was: >>> >>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>> >> Did you enclose the password in single quotes to mask its value? >> >> Also added: >>> access to attrs=userPassword >>> by anonymous auth >>> by self write >>> by * none >>> >> That may not be adequate. That simply allows a user to authenticate >> against the LDAP database. It does NOT allow a regular user to search >> the entire database. Let's get rid of the error 49 first, then we'll >> worry about the rest. >> >> However the result was same. I have confirmed that password is password for >>> now. >>> >> If you're using SASL, remember that all the passwords must be stored in >> cleartext. If the password you're going to use is in the LDAP database, >> it must be stored in cleartext--NOT some excrypted format such as >> >> {MD5} cypherstring >> {SSHA} cypherstring >> >> If the password is in the Cyrus SASL database, it too has to be in >> cleartext. This is one of the weaknesses of SASL. >> >> If you're going to use encrypted passwords in the database, you'll need >> to use SSL or KRB5 as the transport mechanism. >> >> I think, I am missing something in configuration. Can I use LDAP without >>> sasl and if yes, what I need to do? >>> >> You can, but it's not recommended. Try putting this line in slapd.conf: >> >> allow bind_v2 bind_anon_cred bind_anon_dn >> >> Oh, and by the way, we prefer bottom posting on the list. >> >> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: >>> Nilesh Joshi wrote: >>>> Hi, >>>>> I have installed openldap-2.0.27-23 on my server. >>>>> >>>>> I have configured certificate and path is mentioned in slapd.conf file. >>>>> >>>>> I am able to create root DN and also able to add user to it. >>>>> >>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>>> answers. >>>>> Howere, whenever I search using user id, I see error 49. >>>>> >>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>> >>>>> In logs, I see: >>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>> conn=11 fd=10 closed (connection lost) >>>>> >>>>> I would like to have openldap running without sasl. >>>>> >>>>> How should I configure the same? How can I fix this issue? >>>>> >>>>> Error 49 is "invalid credentials," meaning that you didn't hand the >>>> ldapsearch the right password for the user you're trying to bind as. >>>> Try it again, but rather than using the "-W" (interactive) flag, try: >>>> >>>> -w 'your-password-here' >>>> >>>> If the password has shell metacharacters in it, they may be being >>>> interpreted by the shell before being handed to the ldapsearch command. >>>> Using the -w and the password enclosed in single quotes prevents that. >>>> >>>> You also have to make sure that the user you're trying to bind as has >>>> access to the userPassword attribute in the slapd.conf file: >>>> >>>> access to attrs=userPassword >>>> by anonymous auth >>>> by self write >>>> by * none >>>> >>>> ---------------------------------------------------------------------- >>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>> - - >>>> - I never drink water because of the disgusting things that fish do - >>>> - in it. - >>>> - -- WC. Fields - >>>> ---------------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >> >> -- >> ---------------------------------------------------------------------- >> - Rick Stevens, Systems Engineer ricks at nerd.com - >> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >> - - >> - Never test for an error condition you don't know how to handle. - >> >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe -- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Brain: The organ with which we think that we think. - ---------------------------------------------------------------------- From nileshnjoshi at gmail.com Fri Aug 14 22:37:48 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Fri, 14 Aug 2009 15:37:48 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <4A85E45D.7010506@nerd.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> Message-ID: <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> Hi, I htink error 49 is not gone till now. It was not showing any output. I restarted openladp and started getting same error: My slapd.conf looks like below (removed commented lines): ------------------------------------------------------------------------- include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema pidfile /usr/var/run/slapd.pid argsfile /usr/var/run/slapd.args access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth access to attrs=userPassword by anonymous auth by self write by * none TLSCACertificateFile /usr/var/openldap-data/cacert.pem TLSCertificateFile /usr/var/openldap-data/servercrt.pem TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem database bdb suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" rootpw XXXX directory /usr/var/openldap-data/test.com index objectClass eq ----------------------------------------------------------------------------- I think need to concentrate on error=49 only. What you say? Regards, -Nilesh On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens wrote: > Nilesh Joshi wrote: > >> Hi Rick, >> >> I have generated cert again and started slapd. >> >> Now I see following in logs: >> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) >> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >> It's same for below 2 commands: >> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" >> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" >> >> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and restarted >> openldap, the result is same. >> >> It looks like error 49 is gone. >> > > Ok, if error 49 is gone, but you're not getting any data back, then > user "nilesh" probably doesn't have read access to the database. If > you have your slapd manual handy, read up on the "access" directives. > > If you want a user to see any and all of their info, then you need a > directive such as: > > access to * > by self read > by * none > > in slapd.conf. That permits someone to read their own data. If you > want to let them modify their data: > > access to * > by self write > by * none > > (note that "write" permission also includes all lower permissions such > as auth, read, search, etc.) > > What else I need to do to fix this issue. >> > > Looks like you're authenticating fine now, but you have to set up access > rules to allow users to see things. Here's a good on-line reference > book on how to manage an LDAP server: > > http://www.zytrax.dom/books/ldap > > Also, the OpenLDAP System Admin Guide should have been placed in > > /usr/share/doc/openldap-servers-version/guide.html > > (replace "version" with the appropriate version number) when you > installed the OpenLDAP server RPM. You can view it by opening a browser > and going to > > file:///usr/share/doc/opeenldap-servers-version/guide.html > > > >> Thanks and Regards, >> -Nilesh >> >> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens wrote: >> >> Nilesh Joshi wrote: >>> >>> Thanks Rick. >>>> >>>> I have checked using -w password. The exact command I tried was: >>>> >>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>>> >>>> Did you enclose the password in single quotes to mask its value? >>> >>> Also added: >>> >>>> access to attrs=userPassword >>>> by anonymous auth >>>> by self write >>>> by * none >>>> >>>> That may not be adequate. That simply allows a user to authenticate >>> against the LDAP database. It does NOT allow a regular user to search >>> the entire database. Let's get rid of the error 49 first, then we'll >>> worry about the rest. >>> >>> However the result was same. I have confirmed that password is password >>> for >>> >>>> now. >>>> >>>> If you're using SASL, remember that all the passwords must be stored in >>> cleartext. If the password you're going to use is in the LDAP database, >>> it must be stored in cleartext--NOT some excrypted format such as >>> >>> {MD5} cypherstring >>> {SSHA} cypherstring >>> >>> If the password is in the Cyrus SASL database, it too has to be in >>> cleartext. This is one of the weaknesses of SASL. >>> >>> If you're going to use encrypted passwords in the database, you'll need >>> to use SSL or KRB5 as the transport mechanism. >>> >>> I think, I am missing something in configuration. Can I use LDAP without >>> >>>> sasl and if yes, what I need to do? >>>> >>>> You can, but it's not recommended. Try putting this line in slapd.conf: >>> >>> allow bind_v2 bind_anon_cred bind_anon_dn >>> >>> Oh, and by the way, we prefer bottom posting on the list. >>> >>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: >>> >>>> Nilesh Joshi wrote: >>>> >>>>> Hi, >>>>> >>>>>> I have installed openldap-2.0.27-23 on my server. >>>>>> >>>>>> I have configured certificate and path is mentioned in slapd.conf >>>>>> file. >>>>>> >>>>>> I am able to create root DN and also able to add user to it. >>>>>> >>>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>>>> answers. >>>>>> Howere, whenever I search using user id, I see error 49. >>>>>> >>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>>> >>>>>> In logs, I see: >>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>>> conn=11 fd=10 closed (connection lost) >>>>>> >>>>>> I would like to have openldap running without sasl. >>>>>> >>>>>> How should I configure the same? How can I fix this issue? >>>>>> >>>>>> Error 49 is "invalid credentials," meaning that you didn't hand the >>>>>> >>>>> ldapsearch the right password for the user you're trying to bind as. >>>>> Try it again, but rather than using the "-W" (interactive) flag, try: >>>>> >>>>> -w 'your-password-here' >>>>> >>>>> If the password has shell metacharacters in it, they may be being >>>>> interpreted by the shell before being handed to the ldapsearch command. >>>>> Using the -w and the password enclosed in single quotes prevents that. >>>>> >>>>> You also have to make sure that the user you're trying to bind as has >>>>> access to the userPassword attribute in the slapd.conf file: >>>>> >>>>> access to attrs=userPassword >>>>> by anonymous auth >>>>> by self write >>>>> by * none >>>>> >>>>> ---------------------------------------------------------------------- >>>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>>> - - >>>>> - I never drink water because of the disgusting things that fish do - >>>>> - in it. - >>>>> - -- WC. Fields - >>>>> ---------------------------------------------------------------------- >>>>> >>>>> _______________________________________________ >>>>> Redhat-install-list mailing list >>>>> Redhat-install-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>> redhat-install-list-request at redhat.com >>>>> Subject: unsubscribe >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> -- >>> ---------------------------------------------------------------------- >>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>> - - >>> - Never test for an error condition you don't know how to handle. - >>> >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > -- > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Brain: The organ with which we think that we think. - > > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Fri Aug 14 23:37:26 2009 From: ricks at nerd.com (Rick Stevens) Date: Fri, 14 Aug 2009 16:37:26 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> Message-ID: <4A85F536.7030805@nerd.com> Nilesh Joshi wrote: > Hi, > > I htink error 49 is not gone till now. It was not showing any output. I > restarted openladp and started getting same error: > My slapd.conf looks like below (removed commented lines): > ------------------------------------------------------------------------- > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > pidfile /usr/var/run/slapd.pid > argsfile /usr/var/run/slapd.args > access to dn.base="" by * read > access to dn.base="cn=Subschema" by * read > access to * > by self write > by users read > by anonymous auth > access to attrs=userPassword > by anonymous auth > by self write > by * none > > TLSCACertificateFile /usr/var/openldap-data/cacert.pem > TLSCertificateFile /usr/var/openldap-data/servercrt.pem > TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem > > database bdb > suffix "dc=test,dc=com" > rootdn "cn=Manager,dc=test,dc=com" > rootpw XXXX > directory /usr/var/openldap-data/test.com > index objectClass eq > ----------------------------------------------------------------------------- > > I think need to concentrate on error=49 only. You have to be very careful about formatting. If this is an exact cut and paste, you still have authentication issues. A leading space in slapd.conf lines can be used to continue previous directives if they can take multiple values such as the "access" directive can. In the above, you have "access to attrs=userPassword" as a subdirective of the previous "access" directive. Re-edit your config file and make it look like this: include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema pidfile /usr/var/run/slapd.pid argsfile /usr/var/run/slapd.args access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth access to attrs=userPassword by anonymous auth by self write by * none TLSCACertificateFile /usr/var/openldap-data/cacert.pem TLSCertificateFile /usr/var/openldap-data/servercrt.pem TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem database bdb suffix "dc=test,dc=com" rootdn "cn=Manager,dc=test,dc=com" rootpw XXXX directory /usr/var/openldap-data/test.com index objectClass eq I suspect that's where things are getting weird. Personally, I prefer to indent my access directives, so the above bit would look like: --------------------------------------- access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth access to attrs=userPassword by anonymous auth by self write by * none --------------------------------------- But that's just me. Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not being used, so you're using simple SASL authentication...and again the passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. Most Linux systems will use an MD5 encryption and that won't work with SASL. You might also want to try adding "-d 255" to the ldapsearch command. That will spit out lots of debug info that may help you sort out just exactly where the thing's dying. > > What you say? > > Regards, > -Nilesh > On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens wrote: > >> Nilesh Joshi wrote: >> >>> Hi Rick, >>> >>> I have generated cert again and started slapd. >>> >>> Now I see following in logs: >>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) >>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>> It's same for below 2 commands: >>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" >>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" >>> >>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and restarted >>> openldap, the result is same. >>> >>> It looks like error 49 is gone. >>> >> Ok, if error 49 is gone, but you're not getting any data back, then >> user "nilesh" probably doesn't have read access to the database. If >> you have your slapd manual handy, read up on the "access" directives. >> >> If you want a user to see any and all of their info, then you need a >> directive such as: >> >> access to * >> by self read >> by * none >> >> in slapd.conf. That permits someone to read their own data. If you >> want to let them modify their data: >> >> access to * >> by self write >> by * none >> >> (note that "write" permission also includes all lower permissions such >> as auth, read, search, etc.) >> >> What else I need to do to fix this issue. >> Looks like you're authenticating fine now, but you have to set up access >> rules to allow users to see things. Here's a good on-line reference >> book on how to manage an LDAP server: >> >> http://www.zytrax.dom/books/ldap >> >> Also, the OpenLDAP System Admin Guide should have been placed in >> >> /usr/share/doc/openldap-servers-version/guide.html >> >> (replace "version" with the appropriate version number) when you >> installed the OpenLDAP server RPM. You can view it by opening a browser >> and going to >> >> file:///usr/share/doc/opeenldap-servers-version/guide.html >> >> >> >>> Thanks and Regards, >>> -Nilesh >>> >>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens wrote: >>> >>> Nilesh Joshi wrote: >>>> Thanks Rick. >>>>> I have checked using -w password. The exact command I tried was: >>>>> >>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>>>> >>>>> Did you enclose the password in single quotes to mask its value? >>>> Also added: >>>> >>>>> access to attrs=userPassword >>>>> by anonymous auth >>>>> by self write >>>>> by * none >>>>> >>>>> That may not be adequate. That simply allows a user to authenticate >>>> against the LDAP database. It does NOT allow a regular user to search >>>> the entire database. Let's get rid of the error 49 first, then we'll >>>> worry about the rest. >>>> >>>> However the result was same. I have confirmed that password is password >>>> for >>>> >>>>> now. >>>>> >>>>> If you're using SASL, remember that all the passwords must be stored in >>>> cleartext. If the password you're going to use is in the LDAP database, >>>> it must be stored in cleartext--NOT some excrypted format such as >>>> >>>> {MD5} cypherstring >>>> {SSHA} cypherstring >>>> >>>> If the password is in the Cyrus SASL database, it too has to be in >>>> cleartext. This is one of the weaknesses of SASL. >>>> >>>> If you're going to use encrypted passwords in the database, you'll need >>>> to use SSL or KRB5 as the transport mechanism. >>>> >>>> I think, I am missing something in configuration. Can I use LDAP without >>>> >>>>> sasl and if yes, what I need to do? >>>>> >>>>> You can, but it's not recommended. Try putting this line in slapd.conf: >>>> allow bind_v2 bind_anon_cred bind_anon_dn >>>> >>>> Oh, and by the way, we prefer bottom posting on the list. >>>> >>>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: >>>> >>>>> Nilesh Joshi wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>>> I have installed openldap-2.0.27-23 on my server. >>>>>>> >>>>>>> I have configured certificate and path is mentioned in slapd.conf >>>>>>> file. >>>>>>> >>>>>>> I am able to create root DN and also able to add user to it. >>>>>>> >>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>>>>> answers. >>>>>>> Howere, whenever I search using user id, I see error 49. >>>>>>> >>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>>>> >>>>>>> In logs, I see: >>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>>>> conn=11 fd=10 closed (connection lost) >>>>>>> >>>>>>> I would like to have openldap running without sasl. >>>>>>> >>>>>>> How should I configure the same? How can I fix this issue? >>>>>>> >>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand the >>>>>>> >>>>>> ldapsearch the right password for the user you're trying to bind as. >>>>>> Try it again, but rather than using the "-W" (interactive) flag, try: >>>>>> >>>>>> -w 'your-password-here' >>>>>> >>>>>> If the password has shell metacharacters in it, they may be being >>>>>> interpreted by the shell before being handed to the ldapsearch command. >>>>>> Using the -w and the password enclosed in single quotes prevents that. >>>>>> >>>>>> You also have to make sure that the user you're trying to bind as has >>>>>> access to the userPassword attribute in the slapd.conf file: >>>>>> >>>>>> access to attrs=userPassword >>>>>> by anonymous auth >>>>>> by self write >>>>>> by * none >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>>>> - - >>>>>> - I never drink water because of the disgusting things that fish do - >>>>>> - in it. - >>>>>> - -- WC. Fields - >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> _______________________________________________ >>>>>> Redhat-install-list mailing list >>>>>> Redhat-install-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>> redhat-install-list-request at redhat.com >>>>>> Subject: unsubscribe >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Redhat-install-list mailing list >>>>> Redhat-install-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>> redhat-install-list-request at redhat.com >>>>> Subject: unsubscribe >>>>> >>>>> >>>> -- >>>> ---------------------------------------------------------------------- >>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>> - - >>>> - Never test for an error condition you don't know how to handle. - >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >> >> -- >> ---------------------------------------------------------------------- >> - Rick Stevens, Systems Engineer ricks at nerd.com - >> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >> - - >> - Brain: The organ with which we think that we think. - >> >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe -- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Do you know where _your_ towel is? - ---------------------------------------------------------------------- From ricks at nerd.com Sat Aug 15 00:07:03 2009 From: ricks at nerd.com (Rick Stevens) Date: Fri, 14 Aug 2009 17:07:03 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> Message-ID: <4A85FC27.4040804@nerd.com> This is really aimed at Nilesh, but the rest of the list may be interested. I attach a full-up TLS/SSL slapd.conf file. This is taken from the servers we use here, cleaned up and sanitized. Our servers are OpenLDAP 2.4.16, but the same basic stuff should work. I include comments about some things so that, with a bit of tweaking regarding the "authz-regexp" stuff, turning off "starttls=yes" in the syncrepl items, using a cleartext password hash and such, it can be used for both TLS/SSL or SASL systems. I hope this helps folk in the future. #----------------- CUT HERE ------------------------------------------- # # slapd.conf file for TLS/SSL configurations. Easily modified for use # with SASL configurations. # Author: Rick Stevens, HCI/C2, Inc. # Last Edit: 1 August 2009 # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /usr/local/etc/openldap/schema/nis.schema include /usr/local/etc/openldap/schema/misc.schema # Include stuff for the ppolicy mechanism... include /usr/local/etc/openldap/schema/ppolicy.schema # Include stuff for LDAP control of sudo... include /usr/local/etc/openldap/schema/sudo.schema # Include stuff for LDAP-based SSH public keys (requires a hack to sshd) #include /usr/local/etc/openldap/schema/openssh-lpk_openldap.schema # DEBUGGING LOG LEVELS #loglevel 256 128 32 4 1 loglevel 128 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /usr/var/run/slapd.pid #argsfile /usr/var/run/slapd.args # Load dynamic backend modules: modulepath /usr/lib64/openldap moduleload accesslog.la moduleload auditlog.la moduleload dyngroup.la moduleload pcache.la moduleload ppolicy.la moduleload refint.la moduleload retcode.la moduleload rwm.la moduleload syncprov.la moduleload translucent.la moduleload unique.la moduleload valsort.la # Password Requirements # For SASL, this MUST be in cleartext... #password-hash {CLEARTEXT} # Note that our specifications in both the ppolicy overlay and password # checking library can only check the bits of the password after the # cipher encryption. This makes SSHA unusable as it doesn't # necessarily generate any "special" (punctuation) characters, so we # have to use MD5 encryption. Ain't that a kick in the head? password-hash {MD5} # Authentication # SASL will look up DIGEST-MD5 stuff in the LDAP database using these # regex mappings. Note that under SSL, we do NOT use these! # First, handle people who use a DN of "uid="... #authz-regexp # uid=([^,]*),cn=[^,]*,cn=auth # uid=$1,ou=people,dc=ourcompany,dc=com # Also handle people who use a DN of "cn="... #authz-regexp # cn=([^,]*),cn=[^,]*,cn=auth # uid=sysman,ou=People,dc=ourcompany,dc=com # Security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 128-bit (SSL) encryption for simple bind security ssf=1 update_ssf=112 simple_bind=128 ####################################################################### # ACL specifications for pam_ldap and syncrepl... ####################################################################### # Replication and God-like user ACL # These users get full write access, primarily because a) gods must # be able to do anything; and b) we use mirror mode meaning that # other servers have to be able to update our database. access to * by dn="uid=sysman,ou=People,dc=ourcompany,dc=com" tls_ssf=128 write by dn="cn=manager,dc=ourcompany,dc=com" tls_ssf=128 write by * break # Authentication ACL # Anonymous users can authenticate only # Authenticated users can modify their userPassword and # shadowLastChange. No other access permitted. access to attrs=userPassword,shadowLastChange by anonymous auth by self write by * none ####################################################################### # TLS/SSL Configuration ####################################################################### TLSCACertificateFile /etc/openldap/cacerts/ourcompany-cacert.pem TLSCertificateFile /etc/openldap/cacerts/thisserver-cert.pem TLSCertificateKeyFile /etc/openldap/cacerts/thisserver-key.pem ####################################################################### # BDB database definitions ####################################################################### database bdb suffix "dc=ourcompany,dc=com" rootdn "cn=Manager,dc=ourcompany,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # # NOTE: See note above the "password-hash" option for the reason we use # MD5 instead of something harder to crack (like SSHA). #rootpw Th1sis0urP@$$w0rD! rootpw {MD5}OhIMKkO7reCpMM3ZPwcvqQ== # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /usr/var/openldap-data # Indices to maintain for this database... # NOTE: the entryUUID index is to speed up syncrepl index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index entryUUID eq # syncrepl replicas of this database... # We will set up ldap1 and ldap2 as "mirror-mirror" or a hot-standby # configuration. # # The basic replication is via the "syncprov" overlay using these # criteria: # 1) Checkpoint every 10 write operations or 1 minute, whichever is # first. # 2) Checkpoint the session log every 100 operations overlay syncprov syncprov-checkpoint 10 1 syncprov-sessionlog 100 # Here are the syncrepl configs. "rid 001" pulls from the main # server, "rid 002" pulls from the secondary server, "rid 003" pulls # from the remote server. Note that it's OK to use cleartext # credentials here as everything's encrypted by SSL first (the # "starttls=yes" option). syncrepl rid=001 provider=ldap://192.168.1.53 type=refreshAndPersist retry="60 +" searchbase="dc=ourcompany,dc=com" scope=sub schemachecking=on starttls=yes bindmethod=simple binddn="uid=sysman,ou=People,dc=ourcompany,dc=com" credentials=Th1sis0urP@$$w0rD! syncrepl rid=002 provider=ldap://192.168.1.10 type=refreshAndPersist retry="60 +" searchbase="dc=ourcompany,dc=com" scope=sub schemachecking=on starttls=yes bindmethod=simple binddn="uid=sysman,ou=People,dc=ourcompany,dc=com" credentials=Th1sis0urP@$$w0rD! syncrepl rid=003 provider=ldap://192.168.1.11 type=refreshAndPersist retry="60 +" searchbase="dc=ourcompany,dc=com" scope=sub schemachecking=on starttls=yes bindmethod=simple binddn="uid=sysman,ou=People,dc=ourcompany,dc=com" credentials=Th1sis0urP@$$w0rD! # Turn on mirror mode and set the server ID (we're the primary # server)... mirrormode on serverID 1 # Password policy enforcement... # Set up password policies via the "ppolicy" overlay. # Unless otherwise specified by a "pwdPolicySubentry" attribute # in a user's entry, they will use the policy defined in the # "ppolicy_default" entry here. # We force "Invalid Credentials" errors on locked accounts and # we store the passwords in LDAP in MD5 hashes. Note that the # "ppolicy_hash_cleartext" does NOT mean "save passwords in # cleartext". It means "hash any cleartext passwords BEFORE sending # them to the clients. overlay ppolicy ppolicy_default "cn=DefaultPassword,ou=Policies,dc=ourcompany,dc=com" ppolicy_use_lockout ppolicy_hash_cleartext ####################################################################### # Monitoring and configuration database definitions ####################################################################### # Monitor database... database monitor rootdn "cn=Manager,cn=Monitor" rootpw Th1sis0urP@$$w0rD! # Config database... database config rootdn "cn=Manager,cn=Config" rootpw Th1sis0urP@$$w0rD! #----------------- CUT HERE ------------------------------------------- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Time: Nature's way of keeping everything from happening at once. - ---------------------------------------------------------------------- From nileshnjoshi at gmail.com Sat Aug 15 04:10:18 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Fri, 14 Aug 2009 21:10:18 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <4A85FC27.4040804@nerd.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> <4A85FC27.4040804@nerd.com> Message-ID: <7f9821b0908142110r6939f5b1j8a37e93f45a8f2ce@mail.gmail.com> Thanks Rick. I do not have access to systems now. I will do the suggested changes on monday once I have access. Regards, -Nilesh On Fri, Aug 14, 2009 at 5:07 PM, Rick Stevens wrote: > This is really aimed at Nilesh, but the rest of the list may be > interested. > > I attach a full-up TLS/SSL slapd.conf file. This is taken from the > servers we use here, cleaned up and sanitized. Our servers are OpenLDAP > 2.4.16, but the same basic stuff should work. I include comments about > some things so that, with a bit of tweaking regarding the "authz-regexp" > stuff, turning off "starttls=yes" in the syncrepl items, using a > cleartext password hash and such, it can be used for both TLS/SSL or > SASL systems. > > I hope this helps folk in the future. > > #----------------- CUT HERE ------------------------------------------- > # > # slapd.conf file for TLS/SSL configurations. Easily modified for use > # with SASL configurations. > # Author: Rick Stevens, HCI/C2, Inc. > # Last Edit: 1 August 2009 > # > # See slapd.conf(5) for details on configuration options. > # This file should NOT be world readable. > # > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /usr/local/etc/openldap/schema/nis.schema > include /usr/local/etc/openldap/schema/misc.schema > # Include stuff for the ppolicy mechanism... > include /usr/local/etc/openldap/schema/ppolicy.schema > # Include stuff for LDAP control of sudo... > include /usr/local/etc/openldap/schema/sudo.schema > # Include stuff for LDAP-based SSH public keys (requires a hack to sshd) > #include > /usr/local/etc/openldap/schema/openssh-lpk_openldap.schema > > # DEBUGGING LOG LEVELS > #loglevel 256 128 32 4 1 > loglevel 128 > > # Do not enable referrals until AFTER you have a working directory > # service AND an understanding of referrals. > #referral ldap://root.openldap.org > > pidfile /usr/var/run/slapd.pid > #argsfile /usr/var/run/slapd.args > > # Load dynamic backend modules: > modulepath /usr/lib64/openldap > moduleload accesslog.la > moduleload auditlog.la > moduleload dyngroup.la > moduleload pcache.la > moduleload ppolicy.la > moduleload refint.la > moduleload retcode.la > moduleload rwm.la > moduleload syncprov.la > moduleload translucent.la > moduleload unique.la > moduleload valsort.la > > # Password Requirements > # For SASL, this MUST be in cleartext... > #password-hash {CLEARTEXT} > # Note that our specifications in both the ppolicy overlay and password > # checking library can only check the bits of the password after the > # cipher encryption. This makes SSHA unusable as it doesn't > # necessarily generate any "special" (punctuation) characters, so we > # have to use MD5 encryption. Ain't that a kick in the head? > password-hash {MD5} > > # Authentication > # SASL will look up DIGEST-MD5 stuff in the LDAP database using these > # regex mappings. Note that under SSL, we do NOT use these! > # First, handle people who use a DN of "uid="... > #authz-regexp > # uid=([^,]*),cn=[^,]*,cn=auth > # uid=$1,ou=people,dc=ourcompany,dc=com > > # Also handle people who use a DN of "cn="... > #authz-regexp > # cn=([^,]*),cn=[^,]*,cn=auth > # uid=sysman,ou=People,dc=ourcompany,dc=com > > # Security restrictions > # Require integrity protection (prevent hijacking) > # Require 112-bit (3DES or better) encryption for updates > # Require 128-bit (SSL) encryption for simple bind > security ssf=1 update_ssf=112 simple_bind=128 > > ####################################################################### > # ACL specifications for pam_ldap and syncrepl... > ####################################################################### > # Replication and God-like user ACL > # These users get full write access, primarily because a) gods must > # be able to do anything; and b) we use mirror mode meaning that > # other servers have to be able to update our database. > access to * > by dn="uid=sysman,ou=People,dc=ourcompany,dc=com" tls_ssf=128 write > by dn="cn=manager,dc=ourcompany,dc=com" tls_ssf=128 write > by * break > > # Authentication ACL > # Anonymous users can authenticate only > # Authenticated users can modify their userPassword and > # shadowLastChange. No other access permitted. > access to attrs=userPassword,shadowLastChange > by anonymous auth > by self write > by * none > > ####################################################################### > # TLS/SSL Configuration > ####################################################################### > TLSCACertificateFile /etc/openldap/cacerts/ourcompany-cacert.pem > TLSCertificateFile /etc/openldap/cacerts/thisserver-cert.pem > TLSCertificateKeyFile /etc/openldap/cacerts/thisserver-key.pem > > ####################################################################### > # BDB database definitions > ####################################################################### > database bdb > suffix "dc=ourcompany,dc=com" > rootdn "cn=Manager,dc=ourcompany,dc=com" > # Cleartext passwords, especially for the rootdn, should > # be avoided. See slappasswd(8) and slapd.conf(5) for details. > # Use of strong authentication encouraged. > # > # NOTE: See note above the "password-hash" option for the reason we use > # MD5 instead of something harder to crack (like SSHA). > #rootpw Th1sis0urP@$$w0rD! > rootpw {MD5}OhIMKkO7reCpMM3ZPwcvqQ== > > # The database directory MUST exist prior to running slapd AND > # should only be accessible by the slapd and slap tools. > # Mode 700 recommended. > directory /usr/var/openldap-data > > # Indices to maintain for this database... > # NOTE: the entryUUID index is to speed up syncrepl > index objectClass eq,pres > index ou,cn,mail,surname,givenname eq,pres,sub > index uidNumber,gidNumber,loginShell eq,pres > index uid,memberUid eq,pres,sub > index nisMapName,nisMapEntry eq,pres,sub > index entryUUID eq > > # syncrepl replicas of this database... > # We will set up ldap1 and ldap2 as "mirror-mirror" or a hot-standby > # configuration. > # > # The basic replication is via the "syncprov" overlay using these > # criteria: > # 1) Checkpoint every 10 write operations or 1 minute, whichever is > # first. > # 2) Checkpoint the session log every 100 operations > overlay syncprov > syncprov-checkpoint 10 1 > syncprov-sessionlog 100 > > # Here are the syncrepl configs. "rid 001" pulls from the main > # server, "rid 002" pulls from the secondary server, "rid 003" pulls > # from the remote server. Note that it's OK to use cleartext > # credentials here as everything's encrypted by SSL first (the > # "starttls=yes" option). > syncrepl rid=001 > provider=ldap://192.168.1.53 > type=refreshAndPersist > retry="60 +" > searchbase="dc=ourcompany,dc=com" > scope=sub > schemachecking=on > starttls=yes > bindmethod=simple > binddn="uid=sysman,ou=People,dc=ourcompany,dc=com" > credentials=Th1sis0urP@$$w0rD! > > syncrepl rid=002 > provider=ldap://192.168.1.10 > type=refreshAndPersist > retry="60 +" > searchbase="dc=ourcompany,dc=com" > scope=sub > schemachecking=on > starttls=yes > bindmethod=simple > binddn="uid=sysman,ou=People,dc=ourcompany,dc=com" > credentials=Th1sis0urP@$$w0rD! > > syncrepl rid=003 > provider=ldap://192.168.1.11 > type=refreshAndPersist > retry="60 +" > searchbase="dc=ourcompany,dc=com" > scope=sub > schemachecking=on > starttls=yes > bindmethod=simple > binddn="uid=sysman,ou=People,dc=ourcompany,dc=com" > credentials=Th1sis0urP@$$w0rD! > > # Turn on mirror mode and set the server ID (we're the primary > # server)... > mirrormode on > serverID 1 > > # Password policy enforcement... > # Set up password policies via the "ppolicy" overlay. > # Unless otherwise specified by a "pwdPolicySubentry" attribute > # in a user's entry, they will use the policy defined in the > # "ppolicy_default" entry here. > # We force "Invalid Credentials" errors on locked accounts and > # we store the passwords in LDAP in MD5 hashes. Note that the > # "ppolicy_hash_cleartext" does NOT mean "save passwords in > # cleartext". It means "hash any cleartext passwords BEFORE sending > # them to the clients. > overlay ppolicy > ppolicy_default "cn=DefaultPassword,ou=Policies,dc=ourcompany,dc=com" > ppolicy_use_lockout > ppolicy_hash_cleartext > > ####################################################################### > # Monitoring and configuration database definitions > ####################################################################### > # Monitor database... > database monitor > rootdn "cn=Manager,cn=Monitor" > rootpw Th1sis0urP@$$w0rD! > > # Config database... > database config > rootdn "cn=Manager,cn=Config" > rootpw Th1sis0urP@$$w0rD! > #----------------- CUT HERE ------------------------------------------- > > > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Time: Nature's way of keeping everything from happening at once. - > > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nileshnjoshi at gmail.com Mon Aug 17 18:40:33 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Mon, 17 Aug 2009 11:40:33 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <4A85F536.7030805@nerd.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> <4A85F536.7030805@nerd.com> Message-ID: <7f9821b0908171140m4c922b6cy9495d373caf8f5ce@mail.gmail.com> Hi, I have done suggested changes in my slapd.com file. Still I see same issue. When I execute command with -Z option, i see: [$ ldapsearch -x -b "ou=people,dc=test,dc=com" -D "cn=nilesh,ou=people,dc=test,dc=com" -Z -w password "uid=nilesh" ldap_start_tls: Protocol error (2) additional info: unsupported extended operation ldap_bind: Invalid credentials (49) $ conn=77 fd=10 ACCEPT from IP=127.0.0.1:58823 (IP=0.0.0.0:389) conn=77 op=0 EXT oid=1.3.6.1.4.1.1466.20037 do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" conn=77 op=0 RESULT tag=120 err=2 text=unsupported extended operation conn=77 op=1 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 conn=77 op=1 RESULT tag=97 err=49 text= conn=77 fd=10 closed (connection lost Rick Said=>and again the passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. How can I verify? Thanks and Regards, -Nilesh On Fri, Aug 14, 2009 at 4:37 PM, Rick Stevens wrote: > Nilesh Joshi wrote: > >> Hi, >> >> I htink error 49 is not gone till now. It was not showing any output. I >> restarted openladp and started getting same error: >> My slapd.conf looks like below (removed commented lines): >> ------------------------------------------------------------------------- >> include /etc/openldap/schema/core.schema >> include /etc/openldap/schema/cosine.schema >> include /etc/openldap/schema/inetorgperson.schema >> pidfile /usr/var/run/slapd.pid >> argsfile /usr/var/run/slapd.args >> access to dn.base="" by * read >> access to dn.base="cn=Subschema" by * read >> access to * >> by self write >> by users read >> by anonymous auth >> access to attrs=userPassword >> by anonymous auth >> by self write >> by * none >> >> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >> >> database bdb >> suffix "dc=test,dc=com" >> rootdn "cn=Manager,dc=test,dc=com" >> rootpw XXXX >> directory /usr/var/openldap-data/test.com >> index objectClass eq >> >> ----------------------------------------------------------------------------- >> >> I think need to concentrate on error=49 only. >> > > You have to be very careful about formatting. If this is an exact cut > and paste, you still have authentication issues. > > A leading space in slapd.conf lines can be used to continue previous > directives if they can take multiple values such as the "access" directive > can. In the above, you have "access to attrs=userPassword" > as a subdirective of the previous "access" directive. > > Re-edit your config file and make it look like this: > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > pidfile /usr/var/run/slapd.pid > argsfile /usr/var/run/slapd.args > > access to dn.base="" by * read > > access to dn.base="cn=Subschema" by * read > > access to * > by self write > by users read > by anonymous auth > access to attrs=userPassword > by anonymous auth > by self write > by * none > > TLSCACertificateFile /usr/var/openldap-data/cacert.pem > TLSCertificateFile /usr/var/openldap-data/servercrt.pem > TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem > > database bdb > suffix "dc=test,dc=com" > rootdn "cn=Manager,dc=test,dc=com" > rootpw XXXX > directory /usr/var/openldap-data/test.com > index objectClass eq > > I suspect that's where things are getting weird. Personally, I prefer > to indent my access directives, so the above bit would look like: > --------------------------------------- > access to dn.base="" > by * read > > access to dn.base="cn=Subschema" > by * read > > access to * > by self write > by users read > by anonymous auth > > access to attrs=userPassword > by anonymous auth > by self write > by * none > --------------------------------------- > But that's just me. > > Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not being > used, so you're using simple SASL authentication...and again the > passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. Most > Linux systems will use an MD5 encryption and that won't work with SASL. > > You might also want to try adding "-d 255" to the ldapsearch command. > That will spit out lots of debug info that may help you sort out just > exactly where the thing's dying. > > > >> What you say? >> >> Regards, >> -Nilesh >> On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens wrote: >> >> Nilesh Joshi wrote: >>> >>> Hi Rick, >>>> >>>> I have generated cert again and started slapd. >>>> >>>> Now I see following in logs: >>>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) >>>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>> It's same for below 2 commands: >>>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" >>>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" >>>> >>>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and restarted >>>> openldap, the result is same. >>>> >>>> It looks like error 49 is gone. >>>> >>>> Ok, if error 49 is gone, but you're not getting any data back, then >>> user "nilesh" probably doesn't have read access to the database. If >>> you have your slapd manual handy, read up on the "access" directives. >>> >>> If you want a user to see any and all of their info, then you need a >>> directive such as: >>> >>> access to * >>> by self read >>> by * none >>> >>> in slapd.conf. That permits someone to read their own data. If you >>> want to let them modify their data: >>> >>> access to * >>> by self write >>> by * none >>> >>> (note that "write" permission also includes all lower permissions such >>> as auth, read, search, etc.) >>> >>> What else I need to do to fix this issue. >>> Looks like you're authenticating fine now, but you have to set up access >>> rules to allow users to see things. Here's a good on-line reference >>> book on how to manage an LDAP server: >>> >>> http://www.zytrax.dom/books/ldap >>> >>> Also, the OpenLDAP System Admin Guide should have been placed in >>> >>> /usr/share/doc/openldap-servers-version/guide.html >>> >>> (replace "version" with the appropriate version number) when you >>> installed the OpenLDAP server RPM. You can view it by opening a browser >>> and going to >>> >>> file:///usr/share/doc/opeenldap-servers-version/guide.html >>> >>> >>> >>> Thanks and Regards, >>>> -Nilesh >>>> >>>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens wrote: >>>> >>>> Nilesh Joshi wrote: >>>> >>>>> Thanks Rick. >>>>> >>>>>> I have checked using -w password. The exact command I tried was: >>>>>> >>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>>>>> >>>>>> Did you enclose the password in single quotes to mask its value? >>>>>> >>>>> Also added: >>>>> >>>>> access to attrs=userPassword >>>>>> by anonymous auth >>>>>> by self write >>>>>> by * none >>>>>> >>>>>> That may not be adequate. That simply allows a user to authenticate >>>>>> >>>>> against the LDAP database. It does NOT allow a regular user to search >>>>> the entire database. Let's get rid of the error 49 first, then we'll >>>>> worry about the rest. >>>>> >>>>> However the result was same. I have confirmed that password is password >>>>> for >>>>> >>>>> now. >>>>>> >>>>>> If you're using SASL, remember that all the passwords must be stored >>>>>> in >>>>>> >>>>> cleartext. If the password you're going to use is in the LDAP >>>>> database, >>>>> it must be stored in cleartext--NOT some excrypted format such as >>>>> >>>>> {MD5} cypherstring >>>>> {SSHA} cypherstring >>>>> >>>>> If the password is in the Cyrus SASL database, it too has to be in >>>>> cleartext. This is one of the weaknesses of SASL. >>>>> >>>>> If you're going to use encrypted passwords in the database, you'll need >>>>> to use SSL or KRB5 as the transport mechanism. >>>>> >>>>> I think, I am missing something in configuration. Can I use LDAP >>>>> without >>>>> >>>>> sasl and if yes, what I need to do? >>>>>> >>>>>> You can, but it's not recommended. Try putting this line in >>>>>> slapd.conf: >>>>>> >>>>> allow bind_v2 bind_anon_cred bind_anon_dn >>>>> >>>>> Oh, and by the way, we prefer bottom posting on the list. >>>>> >>>>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: >>>>> >>>>> Nilesh Joshi wrote: >>>>>> >>>>>> Hi, >>>>>>> >>>>>>> I have installed openldap-2.0.27-23 on my server. >>>>>>>> >>>>>>>> I have configured certificate and path is mentioned in slapd.conf >>>>>>>> file. >>>>>>>> >>>>>>>> I am able to create root DN and also able to add user to it. >>>>>>>> >>>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>>>>>> answers. >>>>>>>> Howere, whenever I search using user id, I see error 49. >>>>>>>> >>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>>>>> >>>>>>>> In logs, I see: >>>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>>>>> conn=11 fd=10 closed (connection lost) >>>>>>>> >>>>>>>> I would like to have openldap running without sasl. >>>>>>>> >>>>>>>> How should I configure the same? How can I fix this issue? >>>>>>>> >>>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand the >>>>>>>> >>>>>>>> ldapsearch the right password for the user you're trying to bind as. >>>>>>> Try it again, but rather than using the "-W" (interactive) flag, try: >>>>>>> >>>>>>> -w 'your-password-here' >>>>>>> >>>>>>> If the password has shell metacharacters in it, they may be being >>>>>>> interpreted by the shell before being handed to the ldapsearch >>>>>>> command. >>>>>>> Using the -w and the password enclosed in single quotes prevents >>>>>>> that. >>>>>>> >>>>>>> You also have to make sure that the user you're trying to bind as has >>>>>>> access to the userPassword attribute in the slapd.conf file: >>>>>>> >>>>>>> access to attrs=userPassword >>>>>>> by anonymous auth >>>>>>> by self write >>>>>>> by * none >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com- >>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 >>>>>>> - >>>>>>> - >>>>>>> - >>>>>>> - I never drink water because of the disgusting things that fish do >>>>>>> - >>>>>>> - in it. >>>>>>> - >>>>>>> - -- WC. Fields >>>>>>> - >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Redhat-install-list mailing list >>>>>>> Redhat-install-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>> redhat-install-list-request at redhat.com >>>>>>> Subject: unsubscribe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Redhat-install-list mailing list >>>>>> Redhat-install-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>> redhat-install-list-request at redhat.com >>>>>> Subject: unsubscribe >>>>>> >>>>>> >>>>>> -- >>>>> ---------------------------------------------------------------------- >>>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>>> - - >>>>> - Never test for an error condition you don't know how to handle. - >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> _______________________________________________ >>>>> Redhat-install-list mailing list >>>>> Redhat-install-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>> redhat-install-list-request at redhat.com >>>>> Subject: unsubscribe >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> -- >>> ---------------------------------------------------------------------- >>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>> - - >>> - Brain: The organ with which we think that we think. - >>> >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > -- > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - Do you know where _your_ towel is? - > > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Mon Aug 17 19:35:34 2009 From: ricks at nerd.com (Rick Stevens) Date: Mon, 17 Aug 2009 12:35:34 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908171140m4c922b6cy9495d373caf8f5ce@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> <4A85F536.7030805@nerd.com> <7f9821b0908171140m4c922b6cy9495d373caf8f5ce@mail.gmail.com> Message-ID: <4A89B106.2050005@nerd.com> Nilesh Joshi wrote: > Hi, > > I have done suggested changes in my slapd.com file. Still I see same issue. > > When I execute command with -Z option, i see: > > [$ ldapsearch -x -b "ou=people,dc=test,dc=com" -D > "cn=nilesh,ou=people,dc=test,dc=com" -Z -w password "uid=nilesh" > ldap_start_tls: Protocol error (2) > additional info: unsupported extended operation > ldap_bind: Invalid credentials (49) > $ As you can see, the "-Z" forces a TLS startup which we weren't seeing before. My first guess is that your LDAP server or your ldapsearch is not linked to the OpenSSL libraries or they're using the GnuTLS libraries. Try running ldd against your LDAP server and ldapsearch commands: ldd `which slapd` ldd `which ldapsearch` Verify that "libssl.so*" is listed before any "libgnutls*" files. If you see the libgnutls stuff first AND you use a TLS_CACERTFILE in your ldap.conf, then the order of the certificates in that file has to be reversed (the CA cert must be the last one in the file). If you're using the "TLS_CACERTDIR" option, you may need to rearrange things in that directory using the "c_rehash" command that's part of the OpenSSL packages. > conn=77 fd=10 ACCEPT from IP=127.0.0.1:58823 (IP=0.0.0.0:389) > conn=77 op=0 EXT oid=1.3.6.1.4.1.1466.20037 > do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" > conn=77 op=0 RESULT tag=120 err=2 text=unsupported extended operation > conn=77 op=1 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 > conn=77 op=1 RESULT tag=97 err=49 text= > conn=77 fd=10 closed (connection lost > > Rick Said=>and again the passwords in the database MUST BE IN CLEARTEXT IF > YOU USE SASL. > How can I verify? Verify that you're using SASL? If you don't use the -Z (or -ZZ) and -x options to ldapsearch you're using SASL by default. Note that -x alone tries to do a simple bind to the server. That's not allowed by default unless you allow V2 anonymous binds to the LDAP server by adding a line such as allow bind_v2 bind_anon_cred bind_anon_dn to your slapd.conf. You should also comment out the "security" line in slapd.conf. This unsecures your server. You should then be able to access it using the root DN. I'd recommend you get an LDAP client such as GQ or ldapvi to look at the entries in the database. They'll tell you if the password is encrypted or not. If you use ldapvi and you don't see anything in curly braces such as "{MD5}" or "{SSHA}" in the userPassword attribute's value, then the password is in cleartext and the data you see is the password. >>> Hi, >>> >>> I htink error 49 is not gone till now. It was not showing any output. I >>> restarted openladp and started getting same error: >>> My slapd.conf looks like below (removed commented lines): >>> ------------------------------------------------------------------------- >>> include /etc/openldap/schema/core.schema >>> include /etc/openldap/schema/cosine.schema >>> include /etc/openldap/schema/inetorgperson.schema >>> pidfile /usr/var/run/slapd.pid >>> argsfile /usr/var/run/slapd.args >>> access to dn.base="" by * read >>> access to dn.base="cn=Subschema" by * read >>> access to * >>> by self write >>> by users read >>> by anonymous auth >>> access to attrs=userPassword >>> by anonymous auth >>> by self write >>> by * none >>> >>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >>> >>> database bdb >>> suffix "dc=test,dc=com" >>> rootdn "cn=Manager,dc=test,dc=com" >>> rootpw XXXX >>> directory /usr/var/openldap-data/test.com >>> index objectClass eq >>> >>> ----------------------------------------------------------------------------- >>> >>> I think need to concentrate on error=49 only. >>> >> You have to be very careful about formatting. If this is an exact cut >> and paste, you still have authentication issues. >> >> A leading space in slapd.conf lines can be used to continue previous >> directives if they can take multiple values such as the "access" directive >> can. In the above, you have "access to attrs=userPassword" >> as a subdirective of the previous "access" directive. >> >> Re-edit your config file and make it look like this: >> >> include /etc/openldap/schema/core.schema >> include /etc/openldap/schema/cosine.schema >> include /etc/openldap/schema/inetorgperson.schema >> pidfile /usr/var/run/slapd.pid >> argsfile /usr/var/run/slapd.args >> >> access to dn.base="" by * read >> >> access to dn.base="cn=Subschema" by * read >> >> access to * >> by self write >> by users read >> by anonymous auth >> access to attrs=userPassword >> by anonymous auth >> by self write >> by * none >> >> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >> >> database bdb >> suffix "dc=test,dc=com" >> rootdn "cn=Manager,dc=test,dc=com" >> rootpw XXXX >> directory /usr/var/openldap-data/test.com >> index objectClass eq >> >> I suspect that's where things are getting weird. Personally, I prefer >> to indent my access directives, so the above bit would look like: >> --------------------------------------- >> access to dn.base="" >> by * read >> >> access to dn.base="cn=Subschema" >> by * read >> >> access to * >> by self write >> by users read >> by anonymous auth >> >> access to attrs=userPassword >> by anonymous auth >> by self write >> by * none >> --------------------------------------- >> But that's just me. >> >> Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not being >> used, so you're using simple SASL authentication...and again the >> passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. Most >> Linux systems will use an MD5 encryption and that won't work with SASL. >> >> You might also want to try adding "-d 255" to the ldapsearch command. >> That will spit out lots of debug info that may help you sort out just >> exactly where the thing's dying. >> >> >> >>> What you say? >>> >>> Regards, >>> -Nilesh >>> On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens wrote: >>> >>> Nilesh Joshi wrote: >>>> Hi Rick, >>>>> I have generated cert again and started slapd. >>>>> >>>>> Now I see following in logs: >>>>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) >>>>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>> It's same for below 2 commands: >>>>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" >>>>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" >>>>> >>>>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and restarted >>>>> openldap, the result is same. >>>>> >>>>> It looks like error 49 is gone. >>>>> >>>>> Ok, if error 49 is gone, but you're not getting any data back, then >>>> user "nilesh" probably doesn't have read access to the database. If >>>> you have your slapd manual handy, read up on the "access" directives. >>>> >>>> If you want a user to see any and all of their info, then you need a >>>> directive such as: >>>> >>>> access to * >>>> by self read >>>> by * none >>>> >>>> in slapd.conf. That permits someone to read their own data. If you >>>> want to let them modify their data: >>>> >>>> access to * >>>> by self write >>>> by * none >>>> >>>> (note that "write" permission also includes all lower permissions such >>>> as auth, read, search, etc.) >>>> >>>> What else I need to do to fix this issue. >>>> Looks like you're authenticating fine now, but you have to set up access >>>> rules to allow users to see things. Here's a good on-line reference >>>> book on how to manage an LDAP server: >>>> >>>> http://www.zytrax.dom/books/ldap >>>> >>>> Also, the OpenLDAP System Admin Guide should have been placed in >>>> >>>> /usr/share/doc/openldap-servers-version/guide.html >>>> >>>> (replace "version" with the appropriate version number) when you >>>> installed the OpenLDAP server RPM. You can view it by opening a browser >>>> and going to >>>> >>>> file:///usr/share/doc/opeenldap-servers-version/guide.html >>>> >>>> >>>> >>>> Thanks and Regards, >>>>> -Nilesh >>>>> >>>>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens wrote: >>>>> >>>>> Nilesh Joshi wrote: >>>>> >>>>>> Thanks Rick. >>>>>> >>>>>>> I have checked using -w password. The exact command I tried was: >>>>>>> >>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>>>>>> >>>>>>> Did you enclose the password in single quotes to mask its value? >>>>>>> >>>>>> Also added: >>>>>> >>>>>> access to attrs=userPassword >>>>>>> by anonymous auth >>>>>>> by self write >>>>>>> by * none >>>>>>> >>>>>>> That may not be adequate. That simply allows a user to authenticate >>>>>>> >>>>>> against the LDAP database. It does NOT allow a regular user to search >>>>>> the entire database. Let's get rid of the error 49 first, then we'll >>>>>> worry about the rest. >>>>>> >>>>>> However the result was same. I have confirmed that password is password >>>>>> for >>>>>> >>>>>> now. >>>>>>> If you're using SASL, remember that all the passwords must be stored >>>>>>> in >>>>>>> >>>>>> cleartext. If the password you're going to use is in the LDAP >>>>>> database, >>>>>> it must be stored in cleartext--NOT some excrypted format such as >>>>>> >>>>>> {MD5} cypherstring >>>>>> {SSHA} cypherstring >>>>>> >>>>>> If the password is in the Cyrus SASL database, it too has to be in >>>>>> cleartext. This is one of the weaknesses of SASL. >>>>>> >>>>>> If you're going to use encrypted passwords in the database, you'll need >>>>>> to use SSL or KRB5 as the transport mechanism. >>>>>> >>>>>> I think, I am missing something in configuration. Can I use LDAP >>>>>> without >>>>>> >>>>>> sasl and if yes, what I need to do? >>>>>>> You can, but it's not recommended. Try putting this line in >>>>>>> slapd.conf: >>>>>>> >>>>>> allow bind_v2 bind_anon_cred bind_anon_dn >>>>>> >>>>>> Oh, and by the way, we prefer bottom posting on the list. >>>>>> >>>>>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens wrote: >>>>>> >>>>>> Nilesh Joshi wrote: >>>>>>> Hi, >>>>>>>> I have installed openldap-2.0.27-23 on my server. >>>>>>>>> I have configured certificate and path is mentioned in slapd.conf >>>>>>>>> file. >>>>>>>>> >>>>>>>>> I am able to create root DN and also able to add user to it. >>>>>>>>> >>>>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>>>>>>> answers. >>>>>>>>> Howere, whenever I search using user id, I see error 49. >>>>>>>>> >>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>>>>>> >>>>>>>>> In logs, I see: >>>>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>>>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>>>>>> conn=11 fd=10 closed (connection lost) >>>>>>>>> >>>>>>>>> I would like to have openldap running without sasl. >>>>>>>>> >>>>>>>>> How should I configure the same? How can I fix this issue? >>>>>>>>> >>>>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand the >>>>>>>>> >>>>>>>>> ldapsearch the right password for the user you're trying to bind as. >>>>>>>> Try it again, but rather than using the "-W" (interactive) flag, try: >>>>>>>> >>>>>>>> -w 'your-password-here' >>>>>>>> >>>>>>>> If the password has shell metacharacters in it, they may be being >>>>>>>> interpreted by the shell before being handed to the ldapsearch >>>>>>>> command. >>>>>>>> Using the -w and the password enclosed in single quotes prevents >>>>>>>> that. >>>>>>>> >>>>>>>> You also have to make sure that the user you're trying to bind as has >>>>>>>> access to the userPassword attribute in the slapd.conf file: >>>>>>>> >>>>>>>> access to attrs=userPassword >>>>>>>> by anonymous auth >>>>>>>> by self write >>>>>>>> by * none >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com- >>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 >>>>>>>> - >>>>>>>> - >>>>>>>> - >>>>>>>> - I never drink water because of the disgusting things that fish do >>>>>>>> - >>>>>>>> - in it. >>>>>>>> - >>>>>>>> - -- WC. Fields >>>>>>>> - >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Redhat-install-list mailing list >>>>>>>> Redhat-install-list at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>> redhat-install-list-request at redhat.com >>>>>>>> Subject: unsubscribe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Redhat-install-list mailing list >>>>>>> Redhat-install-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>> redhat-install-list-request at redhat.com >>>>>>> Subject: unsubscribe >>>>>>> >>>>>>> >>>>>>> -- >>>>>> ---------------------------------------------------------------------- >>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>>>> - - >>>>>> - Never test for an error condition you don't know how to handle. - >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> _______________________________________________ >>>>>> Redhat-install-list mailing list >>>>>> Redhat-install-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>> redhat-install-list-request at redhat.com >>>>>> Subject: unsubscribe >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Redhat-install-list mailing list >>>>> Redhat-install-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>> redhat-install-list-request at redhat.com >>>>> Subject: unsubscribe >>>>> >>>>> >>>> -- >>>> ---------------------------------------------------------------------- >>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>> - - >>>> - Brain: The organ with which we think that we think. - >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >> >> -- >> ---------------------------------------------------------------------- >> - Rick Stevens, Systems Engineer ricks at nerd.com - >> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >> - - >> - Do you know where _your_ towel is? - >> >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe -- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - What is a "free" gift? Aren't all gifts free? - ---------------------------------------------------------------------- From nileshnjoshi at gmail.com Tue Aug 18 21:37:40 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Tue, 18 Aug 2009 14:37:40 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <4A89B106.2050005@nerd.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> <4A85F536.7030805@nerd.com> <7f9821b0908171140m4c922b6cy9495d373caf8f5ce@mail.gmail.com> <4A89B106.2050005@nerd.com> Message-ID: <7f9821b0908181437t44aa291foe1d7d473c8a8c33@mail.gmail.com> Hi, I think problem got fixed after reediting the slapd.com file. I am able to do search now. Thanks and Regards, -Nilesh On Mon, Aug 17, 2009 at 12:35 PM, Rick Stevens wrote: > Nilesh Joshi wrote: > >> Hi, >> >> I have done suggested changes in my slapd.com file. Still I see same >> issue. >> >> When I execute command with -Z option, i see: >> >> [$ ldapsearch -x -b "ou=people,dc=test,dc=com" -D >> "cn=nilesh,ou=people,dc=test,dc=com" -Z -w password "uid=nilesh" >> ldap_start_tls: Protocol error (2) >> additional info: unsupported extended operation >> ldap_bind: Invalid credentials (49) >> $ >> > > As you can see, the "-Z" forces a TLS startup which we weren't seeing > before. > > My first guess is that your LDAP server or your ldapsearch is not linked > to the OpenSSL libraries or they're using the GnuTLS libraries. Try > running ldd against your LDAP server and ldapsearch commands: > > ldd `which slapd` > ldd `which ldapsearch` > > Verify that "libssl.so*" is listed before any "libgnutls*" files. If > you see the libgnutls stuff first AND you use a TLS_CACERTFILE in your > ldap.conf, then the order of the certificates in that file has to be > reversed (the CA cert must be the last one in the file). If you're > using the "TLS_CACERTDIR" option, you may need to rearrange things in > that directory using the "c_rehash" command that's part of the OpenSSL > packages. > > conn=77 fd=10 ACCEPT from IP=127.0.0.1:58823 (IP=0.0.0.0:389) >> conn=77 op=0 EXT oid=1.3.6.1.4.1.1466.20037 >> do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" >> conn=77 op=0 RESULT tag=120 err=2 text=unsupported extended operation >> conn=77 op=1 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >> conn=77 op=1 RESULT tag=97 err=49 text= >> conn=77 fd=10 closed (connection lost >> >> Rick Said=>and again the passwords in the database MUST BE IN CLEARTEXT IF >> YOU USE SASL. >> How can I verify? >> > > Verify that you're using SASL? If you don't use the -Z (or -ZZ) and -x > options to ldapsearch you're using SASL by default. Note that -x alone > tries to do a simple bind to the server. That's not allowed by default > unless you allow V2 anonymous binds to the LDAP server by adding a line > such as > > allow bind_v2 bind_anon_cred bind_anon_dn > > to your slapd.conf. You should also comment out the "security" line in > slapd.conf. This unsecures your server. You should then be able to > access it using the root DN. > > I'd recommend you get an LDAP client such as GQ or ldapvi to look at > the entries in the database. They'll tell you if the password is > encrypted or not. If you use ldapvi and you don't see anything in curly > braces such as "{MD5}" or "{SSHA}" in the userPassword attribute's > value, then the password is in cleartext and the data you see is the > password. > > > Hi, >>>> >>>> I htink error 49 is not gone till now. It was not showing any output. I >>>> restarted openladp and started getting same error: >>>> My slapd.conf looks like below (removed commented lines): >>>> >>>> ------------------------------------------------------------------------- >>>> include /etc/openldap/schema/core.schema >>>> include /etc/openldap/schema/cosine.schema >>>> include /etc/openldap/schema/inetorgperson.schema >>>> pidfile /usr/var/run/slapd.pid >>>> argsfile /usr/var/run/slapd.args >>>> access to dn.base="" by * read >>>> access to dn.base="cn=Subschema" by * read >>>> access to * >>>> by self write >>>> by users read >>>> by anonymous auth >>>> access to attrs=userPassword >>>> by anonymous auth >>>> by self write >>>> by * none >>>> >>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >>>> >>>> database bdb >>>> suffix "dc=test,dc=com" >>>> rootdn "cn=Manager,dc=test,dc=com" >>>> rootpw XXXX >>>> directory /usr/var/openldap-data/test.com >>>> index objectClass eq >>>> >>>> >>>> ----------------------------------------------------------------------------- >>>> >>>> I think need to concentrate on error=49 only. >>>> >>>> You have to be very careful about formatting. If this is an exact cut >>> and paste, you still have authentication issues. >>> >>> A leading space in slapd.conf lines can be used to continue previous >>> directives if they can take multiple values such as the "access" >>> directive >>> can. In the above, you have "access to attrs=userPassword" >>> as a subdirective of the previous "access" directive. >>> >>> Re-edit your config file and make it look like this: >>> >>> include /etc/openldap/schema/core.schema >>> include /etc/openldap/schema/cosine.schema >>> include /etc/openldap/schema/inetorgperson.schema >>> pidfile /usr/var/run/slapd.pid >>> argsfile /usr/var/run/slapd.args >>> >>> access to dn.base="" by * read >>> >>> access to dn.base="cn=Subschema" by * read >>> >>> access to * >>> by self write >>> by users read >>> by anonymous auth >>> access to attrs=userPassword >>> by anonymous auth >>> by self write >>> by * none >>> >>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >>> >>> database bdb >>> suffix "dc=test,dc=com" >>> rootdn "cn=Manager,dc=test,dc=com" >>> rootpw XXXX >>> directory /usr/var/openldap-data/test.com >>> index objectClass eq >>> >>> I suspect that's where things are getting weird. Personally, I prefer >>> to indent my access directives, so the above bit would look like: >>> --------------------------------------- >>> access to dn.base="" >>> by * read >>> >>> access to dn.base="cn=Subschema" >>> by * read >>> >>> access to * >>> by self write >>> by users read >>> by anonymous auth >>> >>> access to attrs=userPassword >>> by anonymous auth >>> by self write >>> by * none >>> --------------------------------------- >>> But that's just me. >>> >>> Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not being >>> used, so you're using simple SASL authentication...and again the >>> passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. Most >>> Linux systems will use an MD5 encryption and that won't work with SASL. >>> >>> You might also want to try adding "-d 255" to the ldapsearch command. >>> That will spit out lots of debug info that may help you sort out just >>> exactly where the thing's dying. >>> >>> >>> >>> What you say? >>>> >>>> Regards, >>>> -Nilesh >>>> On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens wrote: >>>> >>>> Nilesh Joshi wrote: >>>> >>>>> Hi Rick, >>>>> >>>>>> I have generated cert again and started slapd. >>>>>> >>>>>> Now I see following in logs: >>>>>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) >>>>>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>>> It's same for below 2 commands: >>>>>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" >>>>>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" >>>>>> >>>>>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and >>>>>> restarted >>>>>> openldap, the result is same. >>>>>> >>>>>> It looks like error 49 is gone. >>>>>> >>>>>> Ok, if error 49 is gone, but you're not getting any data back, then >>>>>> >>>>> user "nilesh" probably doesn't have read access to the database. If >>>>> you have your slapd manual handy, read up on the "access" directives. >>>>> >>>>> If you want a user to see any and all of their info, then you need a >>>>> directive such as: >>>>> >>>>> access to * >>>>> by self read >>>>> by * none >>>>> >>>>> in slapd.conf. That permits someone to read their own data. If you >>>>> want to let them modify their data: >>>>> >>>>> access to * >>>>> by self write >>>>> by * none >>>>> >>>>> (note that "write" permission also includes all lower permissions such >>>>> as auth, read, search, etc.) >>>>> >>>>> What else I need to do to fix this issue. >>>>> Looks like you're authenticating fine now, but you have to set up >>>>> access >>>>> rules to allow users to see things. Here's a good on-line reference >>>>> book on how to manage an LDAP server: >>>>> >>>>> http://www.zytrax.dom/books/ldap >>>>> >>>>> Also, the OpenLDAP System Admin Guide should have been placed in >>>>> >>>>> /usr/share/doc/openldap-servers-version/guide.html >>>>> >>>>> (replace "version" with the appropriate version number) when you >>>>> installed the OpenLDAP server RPM. You can view it by opening a >>>>> browser >>>>> and going to >>>>> >>>>> file:///usr/share/doc/opeenldap-servers-version/guide.html >>>>> >>>>> >>>>> >>>>> Thanks and Regards, >>>>> >>>>>> -Nilesh >>>>>> >>>>>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens >>>>>> wrote: >>>>>> >>>>>> Nilesh Joshi wrote: >>>>>> >>>>>> Thanks Rick. >>>>>>> >>>>>>> I have checked using -w password. The exact command I tried was: >>>>>>>> >>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>>>>>>> >>>>>>>> Did you enclose the password in single quotes to mask its value? >>>>>>>> >>>>>>>> Also added: >>>>>>> >>>>>>> access to attrs=userPassword >>>>>>> >>>>>>>> by anonymous auth >>>>>>>> by self write >>>>>>>> by * none >>>>>>>> >>>>>>>> That may not be adequate. That simply allows a user to authenticate >>>>>>>> >>>>>>>> against the LDAP database. It does NOT allow a regular user to >>>>>>> search >>>>>>> the entire database. Let's get rid of the error 49 first, then we'll >>>>>>> worry about the rest. >>>>>>> >>>>>>> However the result was same. I have confirmed that password is >>>>>>> password >>>>>>> for >>>>>>> >>>>>>> now. >>>>>>> >>>>>>>> If you're using SASL, remember that all the passwords must be stored >>>>>>>> in >>>>>>>> >>>>>>>> cleartext. If the password you're going to use is in the LDAP >>>>>>> database, >>>>>>> it must be stored in cleartext--NOT some excrypted format such as >>>>>>> >>>>>>> {MD5} cypherstring >>>>>>> {SSHA} cypherstring >>>>>>> >>>>>>> If the password is in the Cyrus SASL database, it too has to be in >>>>>>> cleartext. This is one of the weaknesses of SASL. >>>>>>> >>>>>>> If you're going to use encrypted passwords in the database, you'll >>>>>>> need >>>>>>> to use SSL or KRB5 as the transport mechanism. >>>>>>> >>>>>>> I think, I am missing something in configuration. Can I use LDAP >>>>>>> without >>>>>>> >>>>>>> sasl and if yes, what I need to do? >>>>>>> >>>>>>>> You can, but it's not recommended. Try putting this line in >>>>>>>> slapd.conf: >>>>>>>> >>>>>>>> allow bind_v2 bind_anon_cred bind_anon_dn >>>>>>> >>>>>>> Oh, and by the way, we prefer bottom posting on the list. >>>>>>> >>>>>>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens >>>>>>> wrote: >>>>>>> >>>>>>> Nilesh Joshi wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>>> I have installed openldap-2.0.27-23 on my server. >>>>>>>>> >>>>>>>>>> I have configured certificate and path is mentioned in slapd.conf >>>>>>>>>> file. >>>>>>>>>> >>>>>>>>>> I am able to create root DN and also able to add user to it. >>>>>>>>>> >>>>>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>>>>>>>> answers. >>>>>>>>>> Howere, whenever I search using user id, I see error 49. >>>>>>>>>> >>>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>>>>>>> >>>>>>>>>> In logs, I see: >>>>>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" >>>>>>>>>> method=128 >>>>>>>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>>>>>>> conn=11 fd=10 closed (connection lost) >>>>>>>>>> >>>>>>>>>> I would like to have openldap running without sasl. >>>>>>>>>> >>>>>>>>>> How should I configure the same? How can I fix this issue? >>>>>>>>>> >>>>>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand >>>>>>>>>> the >>>>>>>>>> >>>>>>>>>> ldapsearch the right password for the user you're trying to bind >>>>>>>>>> as. >>>>>>>>>> >>>>>>>>> Try it again, but rather than using the "-W" (interactive) flag, >>>>>>>>> try: >>>>>>>>> >>>>>>>>> -w 'your-password-here' >>>>>>>>> >>>>>>>>> If the password has shell metacharacters in it, they may be being >>>>>>>>> interpreted by the shell before being handed to the ldapsearch >>>>>>>>> command. >>>>>>>>> Using the -w and the password enclosed in single quotes prevents >>>>>>>>> that. >>>>>>>>> >>>>>>>>> You also have to make sure that the user you're trying to bind as >>>>>>>>> has >>>>>>>>> access to the userPassword attribute in the slapd.conf file: >>>>>>>>> >>>>>>>>> access to attrs=userPassword >>>>>>>>> by anonymous auth >>>>>>>>> by self write >>>>>>>>> by * none >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> - Rick Stevens, Systems Engineer >>>>>>>>> ricks at nerd.com- >>>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: >>>>>>>>> origrps2 >>>>>>>>> - >>>>>>>>> - >>>>>>>>> - >>>>>>>>> - I never drink water because of the disgusting things that fish do >>>>>>>>> - >>>>>>>>> - in it. >>>>>>>>> - >>>>>>>>> - -- WC. >>>>>>>>> Fields >>>>>>>>> - >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Redhat-install-list mailing list >>>>>>>>> Redhat-install-list at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>>> redhat-install-list-request at redhat.com >>>>>>>>> Subject: unsubscribe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Redhat-install-list mailing list >>>>>>>> Redhat-install-list at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>> redhat-install-list-request at redhat.com >>>>>>>> Subject: unsubscribe >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com- >>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 >>>>>>> - >>>>>>> - >>>>>>> - >>>>>>> - Never test for an error condition you don't know how to handle. >>>>>>> - >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Redhat-install-list mailing list >>>>>>> Redhat-install-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>> redhat-install-list-request at redhat.com >>>>>>> Subject: unsubscribe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Redhat-install-list mailing list >>>>>> Redhat-install-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>> redhat-install-list-request at redhat.com >>>>>> Subject: unsubscribe >>>>>> >>>>>> >>>>>> -- >>>>> ---------------------------------------------------------------------- >>>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>>> - - >>>>> - Brain: The organ with which we think that we think. - >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> _______________________________________________ >>>>> Redhat-install-list mailing list >>>>> Redhat-install-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>> redhat-install-list-request at redhat.com >>>>> Subject: unsubscribe >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> -- >>> ---------------------------------------------------------------------- >>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>> - - >>> - Do you know where _your_ towel is? - >>> >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > -- > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - What is a "free" gift? Aren't all gifts free? - > > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Tue Aug 18 21:59:40 2009 From: ricks at nerd.com (Rick Stevens) Date: Tue, 18 Aug 2009 14:59:40 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908181437t44aa291foe1d7d473c8a8c33@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A84BAF1.30507@nerd.com> <7f9821b0908131836o1bb2c4d9g73f2ad8942b5f133@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> <4A85F536.7030805@nerd.com> <7f9821b0908171140m4c922b6cy9495d373caf8f5ce@mail.gmail.com> <4A89B106.2050005@nerd.com> <7f9821b0908181437t44aa291foe1d7d473c8a8c33@mail.gmail.com> Message-ID: <4A8B244C.1040002@nerd.com> Nilesh Joshi wrote: > Hi, > > I think problem got fixed after reediting the slapd.com file. Did you use my slapd.conf or your own and what did you find that was screwey? Just curious. > I am able to do search now. As the normal user or only as the root DN? > On Mon, Aug 17, 2009 at 12:35 PM, Rick Stevens wrote: > >> Nilesh Joshi wrote: >> >>> Hi, >>> >>> I have done suggested changes in my slapd.com file. Still I see same >>> issue. >>> >>> When I execute command with -Z option, i see: >>> >>> [$ ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>> "cn=nilesh,ou=people,dc=test,dc=com" -Z -w password "uid=nilesh" >>> ldap_start_tls: Protocol error (2) >>> additional info: unsupported extended operation >>> ldap_bind: Invalid credentials (49) >>> $ >>> >> As you can see, the "-Z" forces a TLS startup which we weren't seeing >> before. >> >> My first guess is that your LDAP server or your ldapsearch is not linked >> to the OpenSSL libraries or they're using the GnuTLS libraries. Try >> running ldd against your LDAP server and ldapsearch commands: >> >> ldd `which slapd` >> ldd `which ldapsearch` >> >> Verify that "libssl.so*" is listed before any "libgnutls*" files. If >> you see the libgnutls stuff first AND you use a TLS_CACERTFILE in your >> ldap.conf, then the order of the certificates in that file has to be >> reversed (the CA cert must be the last one in the file). If you're >> using the "TLS_CACERTDIR" option, you may need to rearrange things in >> that directory using the "c_rehash" command that's part of the OpenSSL >> packages. >> >> conn=77 fd=10 ACCEPT from IP=127.0.0.1:58823 (IP=0.0.0.0:389) >>> conn=77 op=0 EXT oid=1.3.6.1.4.1.1466.20037 >>> do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" >>> conn=77 op=0 RESULT tag=120 err=2 text=unsupported extended operation >>> conn=77 op=1 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>> conn=77 op=1 RESULT tag=97 err=49 text= >>> conn=77 fd=10 closed (connection lost >>> >>> Rick Said=>and again the passwords in the database MUST BE IN CLEARTEXT IF >>> YOU USE SASL. >>> How can I verify? >>> >> Verify that you're using SASL? If you don't use the -Z (or -ZZ) and -x >> options to ldapsearch you're using SASL by default. Note that -x alone >> tries to do a simple bind to the server. That's not allowed by default >> unless you allow V2 anonymous binds to the LDAP server by adding a line >> such as >> >> allow bind_v2 bind_anon_cred bind_anon_dn >> >> to your slapd.conf. You should also comment out the "security" line in >> slapd.conf. This unsecures your server. You should then be able to >> access it using the root DN. >> >> I'd recommend you get an LDAP client such as GQ or ldapvi to look at >> the entries in the database. They'll tell you if the password is >> encrypted or not. If you use ldapvi and you don't see anything in curly >> braces such as "{MD5}" or "{SSHA}" in the userPassword attribute's >> value, then the password is in cleartext and the data you see is the >> password. >> >> >> Hi, >>>>> I htink error 49 is not gone till now. It was not showing any output. I >>>>> restarted openladp and started getting same error: >>>>> My slapd.conf looks like below (removed commented lines): >>>>> >>>>> ------------------------------------------------------------------------- >>>>> include /etc/openldap/schema/core.schema >>>>> include /etc/openldap/schema/cosine.schema >>>>> include /etc/openldap/schema/inetorgperson.schema >>>>> pidfile /usr/var/run/slapd.pid >>>>> argsfile /usr/var/run/slapd.args >>>>> access to dn.base="" by * read >>>>> access to dn.base="cn=Subschema" by * read >>>>> access to * >>>>> by self write >>>>> by users read >>>>> by anonymous auth >>>>> access to attrs=userPassword >>>>> by anonymous auth >>>>> by self write >>>>> by * none >>>>> >>>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >>>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >>>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >>>>> >>>>> database bdb >>>>> suffix "dc=test,dc=com" >>>>> rootdn "cn=Manager,dc=test,dc=com" >>>>> rootpw XXXX >>>>> directory /usr/var/openldap-data/test.com >>>>> index objectClass eq >>>>> >>>>> >>>>> ----------------------------------------------------------------------------- >>>>> >>>>> I think need to concentrate on error=49 only. >>>>> >>>>> You have to be very careful about formatting. If this is an exact cut >>>> and paste, you still have authentication issues. >>>> >>>> A leading space in slapd.conf lines can be used to continue previous >>>> directives if they can take multiple values such as the "access" >>>> directive >>>> can. In the above, you have "access to attrs=userPassword" >>>> as a subdirective of the previous "access" directive. >>>> >>>> Re-edit your config file and make it look like this: >>>> >>>> include /etc/openldap/schema/core.schema >>>> include /etc/openldap/schema/cosine.schema >>>> include /etc/openldap/schema/inetorgperson.schema >>>> pidfile /usr/var/run/slapd.pid >>>> argsfile /usr/var/run/slapd.args >>>> >>>> access to dn.base="" by * read >>>> >>>> access to dn.base="cn=Subschema" by * read >>>> >>>> access to * >>>> by self write >>>> by users read >>>> by anonymous auth >>>> access to attrs=userPassword >>>> by anonymous auth >>>> by self write >>>> by * none >>>> >>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >>>> >>>> database bdb >>>> suffix "dc=test,dc=com" >>>> rootdn "cn=Manager,dc=test,dc=com" >>>> rootpw XXXX >>>> directory /usr/var/openldap-data/test.com >>>> index objectClass eq >>>> >>>> I suspect that's where things are getting weird. Personally, I prefer >>>> to indent my access directives, so the above bit would look like: >>>> --------------------------------------- >>>> access to dn.base="" >>>> by * read >>>> >>>> access to dn.base="cn=Subschema" >>>> by * read >>>> >>>> access to * >>>> by self write >>>> by users read >>>> by anonymous auth >>>> >>>> access to attrs=userPassword >>>> by anonymous auth >>>> by self write >>>> by * none >>>> --------------------------------------- >>>> But that's just me. >>>> >>>> Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not being >>>> used, so you're using simple SASL authentication...and again the >>>> passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. Most >>>> Linux systems will use an MD5 encryption and that won't work with SASL. >>>> >>>> You might also want to try adding "-d 255" to the ldapsearch command. >>>> That will spit out lots of debug info that may help you sort out just >>>> exactly where the thing's dying. >>>> >>>> >>>> >>>> What you say? >>>>> Regards, >>>>> -Nilesh >>>>> On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens wrote: >>>>> >>>>> Nilesh Joshi wrote: >>>>> >>>>>> Hi Rick, >>>>>> >>>>>>> I have generated cert again and started slapd. >>>>>>> >>>>>>> Now I see following in logs: >>>>>>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) >>>>>>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>>>> It's same for below 2 commands: >>>>>>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" >>>>>>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" >>>>>>> >>>>>>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and >>>>>>> restarted >>>>>>> openldap, the result is same. >>>>>>> >>>>>>> It looks like error 49 is gone. >>>>>>> >>>>>>> Ok, if error 49 is gone, but you're not getting any data back, then >>>>>>> >>>>>> user "nilesh" probably doesn't have read access to the database. If >>>>>> you have your slapd manual handy, read up on the "access" directives. >>>>>> >>>>>> If you want a user to see any and all of their info, then you need a >>>>>> directive such as: >>>>>> >>>>>> access to * >>>>>> by self read >>>>>> by * none >>>>>> >>>>>> in slapd.conf. That permits someone to read their own data. If you >>>>>> want to let them modify their data: >>>>>> >>>>>> access to * >>>>>> by self write >>>>>> by * none >>>>>> >>>>>> (note that "write" permission also includes all lower permissions such >>>>>> as auth, read, search, etc.) >>>>>> >>>>>> What else I need to do to fix this issue. >>>>>> Looks like you're authenticating fine now, but you have to set up >>>>>> access >>>>>> rules to allow users to see things. Here's a good on-line reference >>>>>> book on how to manage an LDAP server: >>>>>> >>>>>> http://www.zytrax.dom/books/ldap >>>>>> >>>>>> Also, the OpenLDAP System Admin Guide should have been placed in >>>>>> >>>>>> /usr/share/doc/openldap-servers-version/guide.html >>>>>> >>>>>> (replace "version" with the appropriate version number) when you >>>>>> installed the OpenLDAP server RPM. You can view it by opening a >>>>>> browser >>>>>> and going to >>>>>> >>>>>> file:///usr/share/doc/opeenldap-servers-version/guide.html >>>>>> >>>>>> >>>>>> >>>>>> Thanks and Regards, >>>>>> >>>>>>> -Nilesh >>>>>>> >>>>>>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens >>>>>>> wrote: >>>>>>> >>>>>>> Nilesh Joshi wrote: >>>>>>> >>>>>>> Thanks Rick. >>>>>>>> I have checked using -w password. The exact command I tried was: >>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>>>>>>>> >>>>>>>>> Did you enclose the password in single quotes to mask its value? >>>>>>>>> >>>>>>>>> Also added: >>>>>>>> access to attrs=userPassword >>>>>>>> >>>>>>>>> by anonymous auth >>>>>>>>> by self write >>>>>>>>> by * none >>>>>>>>> >>>>>>>>> That may not be adequate. That simply allows a user to authenticate >>>>>>>>> >>>>>>>>> against the LDAP database. It does NOT allow a regular user to >>>>>>>> search >>>>>>>> the entire database. Let's get rid of the error 49 first, then we'll >>>>>>>> worry about the rest. >>>>>>>> >>>>>>>> However the result was same. I have confirmed that password is >>>>>>>> password >>>>>>>> for >>>>>>>> >>>>>>>> now. >>>>>>>> >>>>>>>>> If you're using SASL, remember that all the passwords must be stored >>>>>>>>> in >>>>>>>>> >>>>>>>>> cleartext. If the password you're going to use is in the LDAP >>>>>>>> database, >>>>>>>> it must be stored in cleartext--NOT some excrypted format such as >>>>>>>> >>>>>>>> {MD5} cypherstring >>>>>>>> {SSHA} cypherstring >>>>>>>> >>>>>>>> If the password is in the Cyrus SASL database, it too has to be in >>>>>>>> cleartext. This is one of the weaknesses of SASL. >>>>>>>> >>>>>>>> If you're going to use encrypted passwords in the database, you'll >>>>>>>> need >>>>>>>> to use SSL or KRB5 as the transport mechanism. >>>>>>>> >>>>>>>> I think, I am missing something in configuration. Can I use LDAP >>>>>>>> without >>>>>>>> >>>>>>>> sasl and if yes, what I need to do? >>>>>>>> >>>>>>>>> You can, but it's not recommended. Try putting this line in >>>>>>>>> slapd.conf: >>>>>>>>> >>>>>>>>> allow bind_v2 bind_anon_cred bind_anon_dn >>>>>>>> Oh, and by the way, we prefer bottom posting on the list. >>>>>>>> >>>>>>>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens >>>>>>>> wrote: >>>>>>>> >>>>>>>> Nilesh Joshi wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>>> I have installed openldap-2.0.27-23 on my server. >>>>>>>>>> >>>>>>>>>>> I have configured certificate and path is mentioned in slapd.conf >>>>>>>>>>> file. >>>>>>>>>>> >>>>>>>>>>> I am able to create root DN and also able to add user to it. >>>>>>>>>>> >>>>>>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me correct >>>>>>>>>>> answers. >>>>>>>>>>> Howere, whenever I search using user id, I see error 49. >>>>>>>>>>> >>>>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>>>>>>>> >>>>>>>>>>> In logs, I see: >>>>>>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>>>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" >>>>>>>>>>> method=128 >>>>>>>>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>>>>>>>> conn=11 fd=10 closed (connection lost) >>>>>>>>>>> >>>>>>>>>>> I would like to have openldap running without sasl. >>>>>>>>>>> >>>>>>>>>>> How should I configure the same? How can I fix this issue? >>>>>>>>>>> >>>>>>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand >>>>>>>>>>> the >>>>>>>>>>> >>>>>>>>>>> ldapsearch the right password for the user you're trying to bind >>>>>>>>>>> as. >>>>>>>>>>> >>>>>>>>>> Try it again, but rather than using the "-W" (interactive) flag, >>>>>>>>>> try: >>>>>>>>>> >>>>>>>>>> -w 'your-password-here' >>>>>>>>>> >>>>>>>>>> If the password has shell metacharacters in it, they may be being >>>>>>>>>> interpreted by the shell before being handed to the ldapsearch >>>>>>>>>> command. >>>>>>>>>> Using the -w and the password enclosed in single quotes prevents >>>>>>>>>> that. >>>>>>>>>> >>>>>>>>>> You also have to make sure that the user you're trying to bind as >>>>>>>>>> has >>>>>>>>>> access to the userPassword attribute in the slapd.conf file: >>>>>>>>>> >>>>>>>>>> access to attrs=userPassword >>>>>>>>>> by anonymous auth >>>>>>>>>> by self write >>>>>>>>>> by * none >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> - Rick Stevens, Systems Engineer >>>>>>>>>> ricks at nerd.com- >>>>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: >>>>>>>>>> origrps2 >>>>>>>>>> - >>>>>>>>>> - >>>>>>>>>> - >>>>>>>>>> - I never drink water because of the disgusting things that fish do >>>>>>>>>> - >>>>>>>>>> - in it. >>>>>>>>>> - >>>>>>>>>> - -- WC. >>>>>>>>>> Fields >>>>>>>>>> - >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Redhat-install-list mailing list >>>>>>>>>> Redhat-install-list at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>>>> redhat-install-list-request at redhat.com >>>>>>>>>> Subject: unsubscribe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Redhat-install-list mailing list >>>>>>>>> Redhat-install-list at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>>> redhat-install-list-request at redhat.com >>>>>>>>> Subject: unsubscribe >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com- >>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 >>>>>>>> - >>>>>>>> - >>>>>>>> - >>>>>>>> - Never test for an error condition you don't know how to handle. >>>>>>>> - >>>>>>>> >>>>>>>> >>>>>>>> ---------------------------------------------------------------------- >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Redhat-install-list mailing list >>>>>>>> Redhat-install-list at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>> redhat-install-list-request at redhat.com >>>>>>>> Subject: unsubscribe >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> ------------------------------------------------------------------------ >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Redhat-install-list mailing list >>>>>>> Redhat-install-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>> redhat-install-list-request at redhat.com >>>>>>> Subject: unsubscribe >>>>>>> >>>>>>> >>>>>>> -- >>>>>> ---------------------------------------------------------------------- >>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>>>> - - >>>>>> - Brain: The organ with which we think that we think. - >>>>>> >>>>>> ---------------------------------------------------------------------- >>>>>> >>>>>> _______________________________________________ >>>>>> Redhat-install-list mailing list >>>>>> Redhat-install-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>> redhat-install-list-request at redhat.com >>>>>> Subject: unsubscribe >>>>>> >>>>>> >>>>>> >>>>> ------------------------------------------------------------------------ >>>>> >>>>> _______________________________________________ >>>>> Redhat-install-list mailing list >>>>> Redhat-install-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>> redhat-install-list-request at redhat.com >>>>> Subject: unsubscribe >>>>> >>>>> >>>> -- >>>> ---------------------------------------------------------------------- >>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>> - - >>>> - Do you know where _your_ towel is? - >>>> >>>> ---------------------------------------------------------------------- >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >> >> -- >> ---------------------------------------------------------------------- >> - Rick Stevens, Systems Engineer ricks at nerd.com - >> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >> - - >> - What is a "free" gift? Aren't all gifts free? - >> >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > ------------------------------------------------------------------------ > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe -- ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - "Daddy, why doesn't this magnet pick up this floppy disk?" - ---------------------------------------------------------------------- From nileshnjoshi at gmail.com Thu Aug 20 02:14:15 2009 From: nileshnjoshi at gmail.com (Nilesh Joshi) Date: Wed, 19 Aug 2009 19:14:15 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <4A8B244C.1040002@nerd.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> <4A85F536.7030805@nerd.com> <7f9821b0908171140m4c922b6cy9495d373caf8f5ce@mail.gmail.com> <4A89B106.2050005@nerd.com> <7f9821b0908181437t44aa291foe1d7d473c8a8c33@mail.gmail.com> <4A8B244C.1040002@nerd.com> Message-ID: <7f9821b0908191914u52a83937nbc5d5d7d0f062820@mail.gmail.com> Hi, Sorry for late reply. I have copied the file you suggested for me. It's working for both. I mean for manager and users. Thanks a lot for the help. Regards, -Nilesh On Tue, Aug 18, 2009 at 2:59 PM, Rick Stevens wrote: > Nilesh Joshi wrote: > >> Hi, >> >> I think problem got fixed after reediting the slapd.com file. >> > > Did you use my slapd.conf or your own and what did you find that was > screwey? Just curious. > > I am able to do search now. >> > > As the normal user or only as the root DN? > > > On Mon, Aug 17, 2009 at 12:35 PM, Rick Stevens wrote: >> >> Nilesh Joshi wrote: >>> >>> Hi, >>>> >>>> I have done suggested changes in my slapd.com file. Still I see same >>>> issue. >>>> >>>> When I execute command with -Z option, i see: >>>> >>>> [$ ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>> "cn=nilesh,ou=people,dc=test,dc=com" -Z -w password "uid=nilesh" >>>> ldap_start_tls: Protocol error (2) >>>> additional info: unsupported extended operation >>>> ldap_bind: Invalid credentials (49) >>>> $ >>>> >>>> As you can see, the "-Z" forces a TLS startup which we weren't seeing >>> before. >>> >>> My first guess is that your LDAP server or your ldapsearch is not linked >>> to the OpenSSL libraries or they're using the GnuTLS libraries. Try >>> running ldd against your LDAP server and ldapsearch commands: >>> >>> ldd `which slapd` >>> ldd `which ldapsearch` >>> >>> Verify that "libssl.so*" is listed before any "libgnutls*" files. If >>> you see the libgnutls stuff first AND you use a TLS_CACERTFILE in your >>> ldap.conf, then the order of the certificates in that file has to be >>> reversed (the CA cert must be the last one in the file). If you're >>> using the "TLS_CACERTDIR" option, you may need to rearrange things in >>> that directory using the "c_rehash" command that's part of the OpenSSL >>> packages. >>> >>> conn=77 fd=10 ACCEPT from IP=127.0.0.1:58823 (IP=0.0.0.0:389) >>> >>>> conn=77 op=0 EXT oid=1.3.6.1.4.1.1466.20037 >>>> do_extended: unsupported operation "1.3.6.1.4.1.1466.20037" >>>> conn=77 op=0 RESULT tag=120 err=2 text=unsupported extended operation >>>> conn=77 op=1 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>> conn=77 op=1 RESULT tag=97 err=49 text= >>>> conn=77 fd=10 closed (connection lost >>>> >>>> Rick Said=>and again the passwords in the database MUST BE IN CLEARTEXT >>>> IF >>>> YOU USE SASL. >>>> How can I verify? >>>> >>>> Verify that you're using SASL? If you don't use the -Z (or -ZZ) and -x >>> options to ldapsearch you're using SASL by default. Note that -x alone >>> tries to do a simple bind to the server. That's not allowed by default >>> unless you allow V2 anonymous binds to the LDAP server by adding a line >>> such as >>> >>> allow bind_v2 bind_anon_cred bind_anon_dn >>> >>> to your slapd.conf. You should also comment out the "security" line in >>> slapd.conf. This unsecures your server. You should then be able to >>> access it using the root DN. >>> >>> I'd recommend you get an LDAP client such as GQ or ldapvi to look at >>> the entries in the database. They'll tell you if the password is >>> encrypted or not. If you use ldapvi and you don't see anything in curly >>> braces such as "{MD5}" or "{SSHA}" in the userPassword attribute's >>> value, then the password is in cleartext and the data you see is the >>> password. >>> >>> >>> Hi, >>> >>>> I htink error 49 is not gone till now. It was not showing any output. >>>>>> I >>>>>> restarted openladp and started getting same error: >>>>>> My slapd.conf looks like below (removed commented lines): >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> include /etc/openldap/schema/core.schema >>>>>> include /etc/openldap/schema/cosine.schema >>>>>> include /etc/openldap/schema/inetorgperson.schema >>>>>> pidfile /usr/var/run/slapd.pid >>>>>> argsfile /usr/var/run/slapd.args >>>>>> access to dn.base="" by * read >>>>>> access to dn.base="cn=Subschema" by * read >>>>>> access to * >>>>>> by self write >>>>>> by users read >>>>>> by anonymous auth >>>>>> access to attrs=userPassword >>>>>> by anonymous auth >>>>>> by self write >>>>>> by * none >>>>>> >>>>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >>>>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >>>>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >>>>>> >>>>>> database bdb >>>>>> suffix "dc=test,dc=com" >>>>>> rootdn "cn=Manager,dc=test,dc=com" >>>>>> rootpw XXXX >>>>>> directory /usr/var/openldap-data/test.com >>>>>> index objectClass eq >>>>>> >>>>>> >>>>>> >>>>>> ----------------------------------------------------------------------------- >>>>>> >>>>>> I think need to concentrate on error=49 only. >>>>>> >>>>>> You have to be very careful about formatting. If this is an exact cut >>>>>> >>>>> and paste, you still have authentication issues. >>>>> >>>>> A leading space in slapd.conf lines can be used to continue previous >>>>> directives if they can take multiple values such as the "access" >>>>> directive >>>>> can. In the above, you have "access to attrs=userPassword" >>>>> as a subdirective of the previous "access" directive. >>>>> >>>>> Re-edit your config file and make it look like this: >>>>> >>>>> include /etc/openldap/schema/core.schema >>>>> include /etc/openldap/schema/cosine.schema >>>>> include /etc/openldap/schema/inetorgperson.schema >>>>> pidfile /usr/var/run/slapd.pid >>>>> argsfile /usr/var/run/slapd.args >>>>> >>>>> access to dn.base="" by * read >>>>> >>>>> access to dn.base="cn=Subschema" by * read >>>>> >>>>> access to * >>>>> by self write >>>>> by users read >>>>> by anonymous auth >>>>> access to attrs=userPassword >>>>> by anonymous auth >>>>> by self write >>>>> by * none >>>>> >>>>> TLSCACertificateFile /usr/var/openldap-data/cacert.pem >>>>> TLSCertificateFile /usr/var/openldap-data/servercrt.pem >>>>> TLSCertificateKeyFile /usr/var/openldap-data/serverkey.pem >>>>> >>>>> database bdb >>>>> suffix "dc=test,dc=com" >>>>> rootdn "cn=Manager,dc=test,dc=com" >>>>> rootpw XXXX >>>>> directory /usr/var/openldap-data/test.com >>>>> index objectClass eq >>>>> >>>>> I suspect that's where things are getting weird. Personally, I prefer >>>>> to indent my access directives, so the above bit would look like: >>>>> --------------------------------------- >>>>> access to dn.base="" >>>>> by * read >>>>> >>>>> access to dn.base="cn=Subschema" >>>>> by * read >>>>> >>>>> access to * >>>>> by self write >>>>> by users read >>>>> by anonymous auth >>>>> >>>>> access to attrs=userPassword >>>>> by anonymous auth >>>>> by self write >>>>> by * none >>>>> --------------------------------------- >>>>> But that's just me. >>>>> >>>>> Unless you specify "-Z" to your ldapsearch command, TLS/SSL is not >>>>> being >>>>> used, so you're using simple SASL authentication...and again the >>>>> passwords in the database MUST BE IN CLEARTEXT IF YOU USE SASL. Most >>>>> Linux systems will use an MD5 encryption and that won't work with SASL. >>>>> >>>>> You might also want to try adding "-d 255" to the ldapsearch command. >>>>> That will spit out lots of debug info that may help you sort out just >>>>> exactly where the thing's dying. >>>>> >>>>> >>>>> >>>>> What you say? >>>>> >>>>>> Regards, >>>>>> -Nilesh >>>>>> On Fri, Aug 14, 2009 at 3:25 PM, Rick Stevens wrote: >>>>>> >>>>>> Nilesh Joshi wrote: >>>>>> >>>>>> Hi Rick, >>>>>>> >>>>>>> I have generated cert again and started slapd. >>>>>>>> >>>>>>>> Now I see following in logs: >>>>>>>> conn=0 fd=9 ACCEPT from IP=127.0.0.1:36272 (IP=0.0.0.0:389) >>>>>>>> conn=0 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" method=128 >>>>>>>> It's same for below 2 commands: >>>>>>>> 1. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w 'password' "uid=nilesh" >>>>>>>> 2. ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password "uid=nilesh" >>>>>>>> >>>>>>>> I tried adding 'allow bind_v2 bind_anon_cred bind_anon_dn' and >>>>>>>> restarted >>>>>>>> openldap, the result is same. >>>>>>>> >>>>>>>> It looks like error 49 is gone. >>>>>>>> >>>>>>>> Ok, if error 49 is gone, but you're not getting any data back, then >>>>>>>> >>>>>>>> user "nilesh" probably doesn't have read access to the database. If >>>>>>> you have your slapd manual handy, read up on the "access" directives. >>>>>>> >>>>>>> If you want a user to see any and all of their info, then you need a >>>>>>> directive such as: >>>>>>> >>>>>>> access to * >>>>>>> by self read >>>>>>> by * none >>>>>>> >>>>>>> in slapd.conf. That permits someone to read their own data. If you >>>>>>> want to let them modify their data: >>>>>>> >>>>>>> access to * >>>>>>> by self write >>>>>>> by * none >>>>>>> >>>>>>> (note that "write" permission also includes all lower permissions >>>>>>> such >>>>>>> as auth, read, search, etc.) >>>>>>> >>>>>>> What else I need to do to fix this issue. >>>>>>> Looks like you're authenticating fine now, but you have to set up >>>>>>> access >>>>>>> rules to allow users to see things. Here's a good on-line reference >>>>>>> book on how to manage an LDAP server: >>>>>>> >>>>>>> http://www.zytrax.dom/books/ldap >>>>>>> >>>>>>> Also, the OpenLDAP System Admin Guide should have been placed in >>>>>>> >>>>>>> /usr/share/doc/openldap-servers-version/guide.html >>>>>>> >>>>>>> (replace "version" with the appropriate version number) when you >>>>>>> installed the OpenLDAP server RPM. You can view it by opening a >>>>>>> browser >>>>>>> and going to >>>>>>> >>>>>>> file:///usr/share/doc/opeenldap-servers-version/guide.html >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks and Regards, >>>>>>> >>>>>>> -Nilesh >>>>>>>> >>>>>>>> On Fri, Aug 14, 2009 at 10:04 AM, Rick Stevens >>>>>>>> wrote: >>>>>>>> >>>>>>>> Nilesh Joshi wrote: >>>>>>>> >>>>>>>> Thanks Rick. >>>>>>>> >>>>>>>>> I have checked using -w password. The exact command I tried was: >>>>>>>>> >>>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -w password '(uid=nilesh)' >>>>>>>>>> >>>>>>>>>> Did you enclose the password in single quotes to mask its value? >>>>>>>>>> >>>>>>>>>> Also added: >>>>>>>>>> >>>>>>>>> access to attrs=userPassword >>>>>>>>> >>>>>>>>> by anonymous auth >>>>>>>>>> by self write >>>>>>>>>> by * none >>>>>>>>>> >>>>>>>>>> That may not be adequate. That simply allows a user to >>>>>>>>>> authenticate >>>>>>>>>> >>>>>>>>>> against the LDAP database. It does NOT allow a regular user to >>>>>>>>>> >>>>>>>>> search >>>>>>>>> the entire database. Let's get rid of the error 49 first, then >>>>>>>>> we'll >>>>>>>>> worry about the rest. >>>>>>>>> >>>>>>>>> However the result was same. I have confirmed that password is >>>>>>>>> password >>>>>>>>> for >>>>>>>>> >>>>>>>>> now. >>>>>>>>> >>>>>>>>> If you're using SASL, remember that all the passwords must be >>>>>>>>>> stored >>>>>>>>>> in >>>>>>>>>> >>>>>>>>>> cleartext. If the password you're going to use is in the LDAP >>>>>>>>>> >>>>>>>>> database, >>>>>>>>> it must be stored in cleartext--NOT some excrypted format such as >>>>>>>>> >>>>>>>>> {MD5} cypherstring >>>>>>>>> {SSHA} cypherstring >>>>>>>>> >>>>>>>>> If the password is in the Cyrus SASL database, it too has to be in >>>>>>>>> cleartext. This is one of the weaknesses of SASL. >>>>>>>>> >>>>>>>>> If you're going to use encrypted passwords in the database, you'll >>>>>>>>> need >>>>>>>>> to use SSL or KRB5 as the transport mechanism. >>>>>>>>> >>>>>>>>> I think, I am missing something in configuration. Can I use LDAP >>>>>>>>> without >>>>>>>>> >>>>>>>>> sasl and if yes, what I need to do? >>>>>>>>> >>>>>>>>> You can, but it's not recommended. Try putting this line in >>>>>>>>>> slapd.conf: >>>>>>>>>> >>>>>>>>>> allow bind_v2 bind_anon_cred bind_anon_dn >>>>>>>>>> >>>>>>>>> Oh, and by the way, we prefer bottom posting on the list. >>>>>>>>> >>>>>>>>> On Thu, Aug 13, 2009 at 6:16 PM, Rick Stevens >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> Nilesh Joshi wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I have installed openldap-2.0.27-23 on my server. >>>>>>>>>>> >>>>>>>>>>> I have configured certificate and path is mentioned in slapd.conf >>>>>>>>>>>> file. >>>>>>>>>>>> >>>>>>>>>>>> I am able to create root DN and also able to add user to it. >>>>>>>>>>>> >>>>>>>>>>>> When I search using cn=manager,dc=test,dc=com, it gives me >>>>>>>>>>>> correct >>>>>>>>>>>> answers. >>>>>>>>>>>> Howere, whenever I search using user id, I see error 49. >>>>>>>>>>>> >>>>>>>>>>>> ldapsearch -x -b "ou=people,dc=test,dc=com" -D >>>>>>>>>>>> "cn=nilesh,ou=people,dc=test,dc=com" -W '(uid=nilesh)' >>>>>>>>>>>> >>>>>>>>>>>> In logs, I see: >>>>>>>>>>>> conn=11 fd=10 ACCEPT from IP=192.168.1.2:53115 (IP=0.0.0.0:389) >>>>>>>>>>>> conn=11 op=0 BIND dn="cn=nilesh,ou=people,dc=test,dc=com" >>>>>>>>>>>> method=128 >>>>>>>>>>>> conn=11 op=0 RESULT tag=97 err=49 text= >>>>>>>>>>>> conn=11 fd=10 closed (connection lost) >>>>>>>>>>>> >>>>>>>>>>>> I would like to have openldap running without sasl. >>>>>>>>>>>> >>>>>>>>>>>> How should I configure the same? How can I fix this issue? >>>>>>>>>>>> >>>>>>>>>>>> Error 49 is "invalid credentials," meaning that you didn't hand >>>>>>>>>>>> the >>>>>>>>>>>> >>>>>>>>>>>> ldapsearch the right password for the user you're trying to bind >>>>>>>>>>>> as. >>>>>>>>>>>> >>>>>>>>>>>> Try it again, but rather than using the "-W" (interactive) flag, >>>>>>>>>>> try: >>>>>>>>>>> >>>>>>>>>>> -w 'your-password-here' >>>>>>>>>>> >>>>>>>>>>> If the password has shell metacharacters in it, they may be being >>>>>>>>>>> interpreted by the shell before being handed to the ldapsearch >>>>>>>>>>> command. >>>>>>>>>>> Using the -w and the password enclosed in single quotes prevents >>>>>>>>>>> that. >>>>>>>>>>> >>>>>>>>>>> You also have to make sure that the user you're trying to bind as >>>>>>>>>>> has >>>>>>>>>>> access to the userPassword attribute in the slapd.conf file: >>>>>>>>>>> >>>>>>>>>>> access to attrs=userPassword >>>>>>>>>>> by anonymous auth >>>>>>>>>>> by self write >>>>>>>>>>> by * none >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> - Rick Stevens, Systems Engineer >>>>>>>>>>> ricks at nerd.com- >>>>>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: >>>>>>>>>>> origrps2 >>>>>>>>>>> - >>>>>>>>>>> - >>>>>>>>>>> - >>>>>>>>>>> - I never drink water because of the disgusting things that fish >>>>>>>>>>> do >>>>>>>>>>> - >>>>>>>>>>> - in it. >>>>>>>>>>> - >>>>>>>>>>> - -- WC. >>>>>>>>>>> Fields >>>>>>>>>>> - >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Redhat-install-list mailing list >>>>>>>>>>> Redhat-install-list at redhat.com >>>>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>>>>> redhat-install-list-request at redhat.com >>>>>>>>>>> Subject: unsubscribe >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> ------------------------------------------------------------------------ >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Redhat-install-list mailing list >>>>>>>>>> Redhat-install-list at redhat.com >>>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>>>> redhat-install-list-request at redhat.com >>>>>>>>>> Subject: unsubscribe >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> - Rick Stevens, Systems Engineer >>>>>>>>> ricks at nerd.com- >>>>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: >>>>>>>>> origrps2 >>>>>>>>> - >>>>>>>>> - >>>>>>>>> - >>>>>>>>> - Never test for an error condition you don't know how to handle. >>>>>>>>> - >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> Redhat-install-list mailing list >>>>>>>>> Redhat-install-list at redhat.com >>>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>>> redhat-install-list-request at redhat.com >>>>>>>>> Subject: unsubscribe >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> ------------------------------------------------------------------------ >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Redhat-install-list mailing list >>>>>>>> Redhat-install-list at redhat.com >>>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>>> redhat-install-list-request at redhat.com >>>>>>>> Subject: unsubscribe >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> - Rick Stevens, Systems Engineer ricks at nerd.com- >>>>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 >>>>>>> - >>>>>>> - >>>>>>> - >>>>>>> - Brain: The organ with which we think that we think. >>>>>>> - >>>>>>> >>>>>>> >>>>>>> ---------------------------------------------------------------------- >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Redhat-install-list mailing list >>>>>>> Redhat-install-list at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>>> redhat-install-list-request at redhat.com >>>>>>> Subject: unsubscribe >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> _______________________________________________ >>>>>> Redhat-install-list mailing list >>>>>> Redhat-install-list at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>>> redhat-install-list-request at redhat.com >>>>>> Subject: unsubscribe >>>>>> >>>>>> >>>>>> -- >>>>> ---------------------------------------------------------------------- >>>>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>>>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>>>> - - >>>>> - Do you know where _your_ towel is? - >>>>> >>>>> ---------------------------------------------------------------------- >>>>> >>>>> _______________________________________________ >>>>> Redhat-install-list mailing list >>>>> Redhat-install-list at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>>> redhat-install-list-request at redhat.com >>>>> Subject: unsubscribe >>>>> >>>>> >>>>> >>>> ------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Redhat-install-list mailing list >>>> Redhat-install-list at redhat.com >>>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>>> To Unsubscribe Go To ABOVE URL or send a message to: >>>> redhat-install-list-request at redhat.com >>>> Subject: unsubscribe >>>> >>>> >>> -- >>> ---------------------------------------------------------------------- >>> - Rick Stevens, Systems Engineer ricks at nerd.com - >>> - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - >>> - - >>> - What is a "free" gift? Aren't all gifts free? - >>> >>> ---------------------------------------------------------------------- >>> >>> _______________________________________________ >>> Redhat-install-list mailing list >>> Redhat-install-list at redhat.com >>> https://www.redhat.com/mailman/listinfo/redhat-install-list >>> To Unsubscribe Go To ABOVE URL or send a message to: >>> redhat-install-list-request at redhat.com >>> Subject: unsubscribe >>> >>> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Redhat-install-list mailing list >> Redhat-install-list at redhat.com >> https://www.redhat.com/mailman/listinfo/redhat-install-list >> To Unsubscribe Go To ABOVE URL or send a message to: >> redhat-install-list-request at redhat.com >> Subject: unsubscribe >> > > > -- > ---------------------------------------------------------------------- > - Rick Stevens, Systems Engineer ricks at nerd.com - > - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - > - - > - "Daddy, why doesn't this magnet pick up this floppy disk?" - > > ---------------------------------------------------------------------- > > _______________________________________________ > Redhat-install-list mailing list > Redhat-install-list at redhat.com > https://www.redhat.com/mailman/listinfo/redhat-install-list > To Unsubscribe Go To ABOVE URL or send a message to: > redhat-install-list-request at redhat.com > Subject: unsubscribe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ricks at nerd.com Thu Aug 20 16:54:22 2009 From: ricks at nerd.com (Rick Stevens) Date: Thu, 20 Aug 2009 09:54:22 -0700 Subject: open ldap configuration on rhel3-u4 In-Reply-To: <7f9821b0908191914u52a83937nbc5d5d7d0f062820@mail.gmail.com> References: <7f9821b0908131733q1ac70d0dr4dde46d2ac18dd23@mail.gmail.com> <4A85990F.5080806@nerd.com> <7f9821b0908141503o52a8576csf8583aedb55506ab@mail.gmail.com> <4A85E45D.7010506@nerd.com> <7f9821b0908141537sdb5eb61g52b724fa97cc57ee@mail.gmail.com> <4A85F536.7030805@nerd.com> <7f9821b0908171140m4c922b6cy9495d373caf8f5ce@mail.gmail.com> <4A89B106.2050005@nerd.com> <7f9821b0908181437t44aa291foe1d7d473c8a8c33@mail.gmail.com> <4A8B244C.1040002@nerd.com> <7f9821b0908191914u52a83937nbc5d5d7d0f062820@mail.gmail.com> Message-ID: <4A8D7FBE.8030806@nerd.com> Nilesh Joshi wrote: > Hi, > > Sorry for late reply. I have copied the file you suggested for me. > > It's working for both. I mean for manager and users. > > Thanks a lot for the help. No problem. Hopefully, now that you have a working LDAP, the config file makes sense. If not, I'll try to explain anything that you're confused about. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Real Time, adj.: Here and now, as opposed to fake time, which only - - occurs there and then - ---------------------------------------------------------------------- From nlf482n at med.usyd.edu.au Sat Aug 22 14:59:15 2009 From: nlf482n at med.usyd.edu.au (Nik Lam) Date: Sun, 23 Aug 2009 00:59:15 +1000 Subject: excluding multipath devices using a pre script during kickstart In-Reply-To: <1250230935.18960.46.camel@chipolata.med.usyd.edu.au> References: <1250144934.11245.13.camel@chipolata.med.usyd.edu.au> <1FC8A0BAFBBD9749BB1F06010D23C8A59B1899AB@sg000035.corproot.net> <1250230935.18960.46.camel@chipolata.med.usyd.edu.au> Message-ID: <1250953155.5284.13.camel@localhost.localdomain> Just a follow-up on this issue, having received support directly from Red Hat. The solution is to make the following modifications to your kickstart file. 1) If using the "clearpart" directive, append --drives=mapper/mpath0 to it, e.g. clearpart --all --drives=mapper/mpath0 2) For any "part" directives, append --ondisk=mapper/mpath0 to it, e.g. part /boot --fstype ext3 --size=100 --ondisk=mapper/mpath0 part pv.01 --size=10000 --grow --ondisk=mapper/mapth0 On Fri, 2009-08-14 at 16:22 +1000, Nik Lam wrote: > Thanks Thomas - that looks promising. > > Do you ever use this LVM-based filtering with a kickstart installation? > > I'm unsure of what point the lvm.conf file would be read during the > installation process. I might try some experiments, but I'm not too > hopeful. > > I've noticed there is a multipath option in kickstart, which includes a > --rule= parameter, but I can't find any documentation of how it's used. > > Regards, > > Nik > > > > On Thu, 2009-08-13 at 12:18 +0200, Thomas.vonSteiger at swisscom.com wrote: > > Hi, > > > > Filter for storage devices can be defined in /etc/lvm/lvm.conf. > > We are install systems only on san storage always on mpath devices. Root filesystem are located on mpath devices for boot. > > For this we use this filter: > > > > filter = [ "a|/dev/mapper/mpath|", "r|.*|" ] > > > > regards, > > Thomas > > > > -----Original Message----- > > From: redhat-install-list-bounces at redhat.com [mailto:redhat-install-list-bounces at redhat.com] On Behalf Of Nik Lam > > Sent: Thursday, August 13, 2009 8:29 AM > > To: Redhat-install-list at redhat.com > > Subject: excluding multipath devices using a pre script during kickstart > > > > Hi, > > > > I'm having trouble using kickstart to install onto an HP BL 465c G1 > > blade that has 2 LUNs presented to it from fibre-channel SAN. The first > > one is where I want to install the system to, the second one is for use > > later on. > > > > A manual install from media works fine with no modifications to the > > system, however the kickstart fails unless we remove all but one of the > > LUNs presented to the system. This appears to be some kind of bug with > > kickstart. > > > > Unfortunately we don't have administrative control over the SAN, so it's > > inconvenient to modify what LUNs are presented to a host for an install > > (and in an emergency rebuild, we'd have to wait for them). > > > > Can anyone here provide me with clues on how to mask or filter the > > unneeded multipath devices during the install? I think a pre-script must > > be the way, but I'm not sure where to start. > > > > Regards, > > > > Nik > > > > From buzdavis at earthlink.net Mon Aug 24 23:11:18 2009 From: buzdavis at earthlink.net (Buz Davis) Date: Mon, 24 Aug 2009 19:11:18 -0400 Subject: problem installing Fedora 8 Message-ID: <4A931E16.8040904@earthlink.net> For some years I have been running a couple of Red Hat 9 systems on a home network. For the most part they got done what I needed done so I have tended to ignore their being out-of-date. It recently became apparent to me that the Internet was moving away from me, so I began searching for an update. First I tried a set of disks that came with a book from a used/surplus book store. These were Fedora disks, but without a stated version number so I suspect very early Fedora. With these the install (and I was trying to update) seemed to do well until the second or third disk failed with an invalid media message. Surprisingly the system still runs. Grub offers to boot Fedora but I suspect much of what I am running comes from the earlier RH9. I just purchased a set of Fedora 8 cds (my boxes don't have dvd capability) and night before last put them successfully through a media check. But when I attempted to install I got a nearly immediate termination. The messages read (as best as I can decipher my handwriting): === Running anaconda 11.3.0.50, the Fedora system installer - please wait ... install exited abnormally [1/1]. Sending termination signals ... done Sending kill signals ... done disabling swap unmounting filesystems /mnt/runtime done disabling /dev/loop0 /proc done /dev/pys done /sys done /tmp/ranfs done /mnt/source done /src/???? done (here, I can't read my own scribblings ) you may now safely reboot your system === The system consists of an AMD K6 at 500 Mhz, 320 meg ram, and plenty of disk space. I have tried installing in text mode with nousb, but still encounter the problem. Last night I let the memtest supplied on the installation cd run overnight and it completed 8 passes without error, so I think the ram is OK. Any suggestions would be welcome. From micros50 at verizon.net Mon Aug 24 23:30:44 2009 From: micros50 at verizon.net (Micros50) Date: Mon, 24 Aug 2009 19:30:44 -0400 Subject: Fedora 11 + KDE+ Sound Problem Message-ID: <1251156644.5215.14.camel@manhattan.ruffe.edu> I recently installed Fedora 11 to replace fedora 6 which I had been running until recently. Thus far everything looks great. Except for a few minor issues everything more or less worked fine. My preferred desktop is KDE which also seemed to work well. The transition from KDE 3 to KDE4 went smoothly. However, I did run into a problem with regards to KDE sound apps. At first they were running fine. Any apps that needed to access the KDE sound system i.e. "k-notify", "juk", "Amarok", etc. were working fine via the "phoneon-backend-xine" backend. Then all of a sudden something changed and all kde apps that needed to access the sound system started crashing and giving a Signal 6 (SIGABRT). I didn't recall making any changes or updates that would have accounted for this problem. Here is a copy of the backtrace that I was getting each time an application crashed. Application: JuK (juk), signal SIGABRT [Current thread is 1 (Thread 0xb7f3b780 (LWP 3121))] Thread 6 (Thread 0x9940b70 (LWP 3122)): #0 0x00843416 in __kernel_vsyscall () #1 0x008162d2 in pthread_cond_timedwait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #2 0x05c4674d in ?? () from /usr/lib/libxine.so.1 #3 0x00811935 in start_thread () from /lib/libpthread.so.0 #4 0x0074693e in clone () from /lib/libc.so.6 Thread 5 (Thread 0xb66b1b70 (LWP 3123)): [KCrash Handler] #6 0x00843416 in __kernel_vsyscall () #7 0x006937c1 in raise () from /lib/libc.so.6 #8 0x00695092 in abort () from /lib/libc.so.6 #9 0x057fc84c in qt_message_output(QtMsgType, char const*) () from /usr/lib/libQtCore.so.4 #10 0x057fc92e in qFatal(char const*, ...) () from /usr/lib/libQtCore.so.4 #11 0x057fca25 in qt_assert(char const*, char const*, int) () from /usr/lib/libQtCore.so.4 #12 0x02c5b87f in Phonon::MediaSource::type() const () from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so #13 0x02c5e255 in Phonon::MediaSource::type() const () from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so #14 0x02c642a0 in Phonon::MediaSource::type() const () from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so #15 0x0609a884 in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 #16 0x060a1f0e in QApplication::notify(QObject*, QEvent*) () from /usr/lib/libQtGui.so.4 : Any ideas ? It seems to be an issue with the "phoneon-backend-xine" plugin so I switched from the xine backend to gstreamer and all of a sudden everything started working again. I had to install some additional gstreamer plugins but, at least now everything seems to be working again with respect to the KDE sound system. I guess we can say the problem is solved in as far as getting sound out of my KDE apps but I am still puzzled as to what might have caused the xine backend to start giving me problems. Wondering if I might need to send a formal bug report. Any suggestions or insignts into this problem are appreciated. Thanks. John From ricks at nerd.com Mon Aug 24 23:56:47 2009 From: ricks at nerd.com (Rick Stevens) Date: Mon, 24 Aug 2009 16:56:47 -0700 Subject: problem installing Fedora 8 In-Reply-To: <4A931E16.8040904@earthlink.net> References: <4A931E16.8040904@earthlink.net> Message-ID: <4A9328BF.8050202@nerd.com> Buz Davis wrote: > For some years I have been running a couple of Red Hat 9 systems > on a home network. For the most part they got done what I needed > done so I have tended to ignore their being out-of-date. It recently > became apparent to me that the Internet was moving away from me, so I > began searching for an update. > > First I tried a set of disks that came with a book from a used/surplus > book store. These were Fedora disks, but without a stated version > number so I suspect very early Fedora. With these the install (and I > was trying to update) seemed to do well until the second or third disk > failed with an invalid media message. Surprisingly the system still > runs. Grub offers to boot Fedora but I suspect much of what I am > running comes from the earlier RH9. > > I just purchased a set of Fedora 8 cds (my boxes don't have dvd capability) > and night before last put them successfully through a media check. But > when I attempted to install I got a nearly immediate termination. The > messages read (as best as I can decipher my handwriting): > > === > Running anaconda 11.3.0.50, the Fedora system installer - please wait ... > install exited abnormally [1/1]. > Sending termination signals ... done > Sending kill signals ... done > disabling swap > unmounting filesystems > /mnt/runtime done > disabling /dev/loop0 > /proc done > /dev/pys done > /sys done > /tmp/ranfs done > /mnt/source done > /src/???? done (here, I can't read my own scribblings ) > you may now safely reboot your system > === > > The system consists of an AMD K6 at 500 Mhz, 320 meg ram, and plenty of > disk space. I have tried installing in text mode with nousb, but still > encounter the problem. Last night I let the memtest supplied on the > installation cd run overnight and it completed 8 passes without error, > so I think the ram is OK. > > Any suggestions would be welcome. That sounds like the classic "I can't find enough disk" anaconda error. Unless you do an "update existing system" (NOT recommended when making as big a jump as you are) or "replace existing system" install (where anaconda blows the old Linux partitions away and starts over), anaconda wants "unused" disk space (space not in any used partition). Fedora 8 is also quite long in the tooth (current release is Fedora 11). The normal release cycle for Fedora is about 6 months, and support for old versions ends with the second version released after it: New Release Support Ends For ----------- ---------------- Fedora 10 Fedora 8 Fedora 11 Fedora 9 Fedora 12 Fedora 10 This may be a bit quick for you (the lifespan is about a year). If that's the case, you might want to consider something like CentOS 5.x. CentOS tracks the Red Hat Enterprise system pretty faithfully and has similar lifespans (5 years or so). CentOS 5.x/RHEL 5.x is based on Fedora 6, I believe. If you want to live on the bleeding edge (and there has been some blood loss, believe me), I might suggest you try one of the Fedora 11 Live CDs. F11 is pretty robust, although it may not support really old graphics cards (you have to make the change sometime!) The Live CD images are are burnable to a CD (thus taking care of the fact you don't have a DVD drive). You boot from the CD and the system runs normally off it. You can use this mode to see how well it works with your hardware and you can get a good feel for the system. Should you decide you like it, the CD contains tools that allow you to install Fedora via the Internet. It takes longer to install, but if you don't have a DVD drive it's your best option. Note that you can use some tools to put the DVD image on a USB Flash key and use that for installation, but it can be tricky and a lot of old hardware won't boot from a USB key. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - The trouble with troubleshooting is that trouble sometimes - - shoots back. - ---------------------------------------------------------------------- From ricks at nerd.com Tue Aug 25 00:04:46 2009 From: ricks at nerd.com (Rick Stevens) Date: Mon, 24 Aug 2009 17:04:46 -0700 Subject: Fedora 11 + KDE+ Sound Problem In-Reply-To: <1251156644.5215.14.camel@manhattan.ruffe.edu> References: <1251156644.5215.14.camel@manhattan.ruffe.edu> Message-ID: <4A932A9E.9090300@nerd.com> Micros50 wrote: > I recently installed Fedora 11 to replace fedora 6 which I had been > running until recently. Thus far everything looks great. Except for a > few minor issues everything more or less worked fine. > > My preferred desktop is KDE which also seemed to work well. The > transition from KDE 3 to KDE4 went smoothly. > > However, I did run into a problem with regards to KDE sound apps. At > first they were running fine. Any apps that needed to access the KDE > sound system i.e. "k-notify", "juk", "Amarok", etc. were working fine > via the "phoneon-backend-xine" backend. > > Then all of a sudden something changed and all kde apps that needed to > access the sound system started crashing and giving a Signal 6 > (SIGABRT). I didn't recall making any changes or updates that would have > accounted for this problem. Here is a copy of the backtrace that I was > getting each time an application crashed. > > Application: JuK (juk), signal SIGABRT > [Current thread is 1 (Thread 0xb7f3b780 (LWP 3121))] > > Thread 6 (Thread 0x9940b70 (LWP 3122)): > #0 0x00843416 in __kernel_vsyscall () > #1 0x008162d2 in pthread_cond_timedwait@@GLIBC_2.3.2 () > from /lib/libpthread.so.0 > #2 0x05c4674d in ?? () from /usr/lib/libxine.so.1 > #3 0x00811935 in start_thread () from /lib/libpthread.so.0 > #4 0x0074693e in clone () from /lib/libc.so.6 > > Thread 5 (Thread 0xb66b1b70 (LWP 3123)): > [KCrash Handler] > #6 0x00843416 in __kernel_vsyscall () > #7 0x006937c1 in raise () from /lib/libc.so.6 > #8 0x00695092 in abort () from /lib/libc.so.6 > #9 0x057fc84c in qt_message_output(QtMsgType, char const*) () > from /usr/lib/libQtCore.so.4 > #10 0x057fc92e in qFatal(char const*, ...) () > from /usr/lib/libQtCore.so.4 > #11 0x057fca25 in qt_assert(char const*, char const*, int) () > from /usr/lib/libQtCore.so.4 > #12 0x02c5b87f in Phonon::MediaSource::type() const () > from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so > #13 0x02c5e255 in Phonon::MediaSource::type() const () > from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so > #14 0x02c642a0 in Phonon::MediaSource::type() const () > from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so > #15 0x0609a884 in QApplicationPrivate::notify_helper(QObject*, QEvent*) > () from /usr/lib/libQtGui.so.4 > #16 0x060a1f0e in QApplication::notify(QObject*, QEvent*) () > from /usr/lib/libQtGui.so.4 > : > > Any ideas ? It seems to be an issue with the "phoneon-backend-xine" > plugin so I switched from the xine backend to gstreamer and all of a > sudden everything started working again. I had to install some > additional gstreamer plugins but, at least now everything seems to be > working again with respect to the KDE sound system. > > I guess we can say the problem is solved in as far as getting sound out > of my KDE apps but I am still puzzled as to what might have caused the > xine backend to start giving me problems. Wondering if I might need to > send a formal bug report. Any suggestions or insignts into this problem > are appreciated. There were a number of updates to the sound system (PulseAudio, Alsa) and a number of the media players that caused problems recently. I don't use KDE myself, so I don't recall the details very well as they didn't bite me (or a later update fixed them and I didn't notice). I will say that this question is perfect fodder for and can be answered far more completely on the "fedora-list" than here. I'd suggest you search the archives of that list for the last couple of weeks and you should see how to fix it. If not, post a message on that list and you'll get all the help you could possibly want. The people on that list are very helpful and a lot of them are heavy-duty KDE users and mavens. I'm there, too, if you want to take a few swings at me! :-) ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Admitting you have a problem is the first step toward getting - - medicated for it. -- Jim Evarts (http://www.TopFive.com) - ---------------------------------------------------------------------- From buzdavis at earthlink.net Tue Aug 25 00:24:47 2009 From: buzdavis at earthlink.net (Buz Davis) Date: Mon, 24 Aug 2009 20:24:47 -0400 Subject: problem installing Fedora 8 Message-ID: <4A932F4F.3000406@earthlink.net> >That sounds like the classic "I can't find enough disk" anaconda error. >Unless you do an "update existing system" (NOT recommended when making >as big a jump as you are) or "replace existing system" install (where >anaconda blows the old Linux partitions away and starts over), anaconda >wants "unused" disk space (space not in any used partition). Thanks, Rick. As I recall I do have extra space available on the disk that hasn't been assigned to any partition. Would it help to make another partition of it ? If so, would I have to also make a filesystem or would anaconda prefer it unformatted ? From ricks at nerd.com Tue Aug 25 00:44:27 2009 From: ricks at nerd.com (Rick Stevens) Date: Mon, 24 Aug 2009 17:44:27 -0700 Subject: problem installing Fedora 8 In-Reply-To: <4A932F4F.3000406@earthlink.net> References: <4A932F4F.3000406@earthlink.net> Message-ID: <4A9333EB.2060609@nerd.com> Buz Davis wrote: > > >That sounds like the classic "I can't find enough disk" anaconda error. > >Unless you do an "update existing system" (NOT recommended when making > >as big a jump as you are) or "replace existing system" install (where > >anaconda blows the old Linux partitions away and starts over), anaconda > >wants "unused" disk space (space not in any used partition). > > Thanks, Rick. > > As I recall I do have extra space available on the disk that hasn't been > assigned to any partition. Would it help to make another partition of > it ? If so, would I have to also make a filesystem or would anaconda > prefer it unformatted ? You have to make sure that "unassigned" space is big enough to hold the system and you'll have to have at least two partitions available in the table--one for "boot" and one for the root of the OS (you can only have 16 partitions). I can't recall how big the space needed is offhand, but it's in the F11 (Fedora 11) release notes available online. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - To err is human, to moo bovine. - ---------------------------------------------------------------------- From micros50 at verizon.net Tue Aug 25 03:26:37 2009 From: micros50 at verizon.net (Micros50) Date: Mon, 24 Aug 2009 23:26:37 -0400 Subject: Fedora 11 + KDE+ Sound Problem In-Reply-To: <4A932A9E.9090300@nerd.com> References: <1251156644.5215.14.camel@manhattan.ruffe.edu> <4A932A9E.9090300@nerd.com> Message-ID: <1251170798.3006.11.camel@manhattan.ruffe.edu> On Mon, 2009-08-24 at 17:04 -0700, Rick Stevens wrote: > Micros50 wrote: > > I recently installed Fedora 11 to replace fedora 6 which I had been > > running until recently. Thus far everything looks great. Except for a > > few minor issues everything more or less worked fine. > > > > My preferred desktop is KDE which also seemed to work well. The > > transition from KDE 3 to KDE4 went smoothly. > > > > However, I did run into a problem with regards to KDE sound apps. At > > first they were running fine. Any apps that needed to access the KDE > > sound system i.e. "k-notify", "juk", "Amarok", etc. were working fine > > via the "phoneon-backend-xine" backend. > > > > Then all of a sudden something changed and all kde apps that needed to > > access the sound system started crashing and giving a Signal 6 > > (SIGABRT). I didn't recall making any changes or updates that would have > > accounted for this problem. Here is a copy of the backtrace that I was > > getting each time an application crashed. > > > > Application: JuK (juk), signal SIGABRT > > [Current thread is 1 (Thread 0xb7f3b780 (LWP 3121))] > > > > Thread 6 (Thread 0x9940b70 (LWP 3122)): > > #0 0x00843416 in __kernel_vsyscall () > > #1 0x008162d2 in pthread_cond_timedwait@@GLIBC_2.3.2 () > > from /lib/libpthread.so.0 > > #2 0x05c4674d in ?? () from /usr/lib/libxine.so.1 > > #3 0x00811935 in start_thread () from /lib/libpthread.so.0 > > #4 0x0074693e in clone () from /lib/libc.so.6 > > > > Thread 5 (Thread 0xb66b1b70 (LWP 3123)): > > [KCrash Handler] > > #6 0x00843416 in __kernel_vsyscall () > > #7 0x006937c1 in raise () from /lib/libc.so.6 > > #8 0x00695092 in abort () from /lib/libc.so.6 > > #9 0x057fc84c in qt_message_output(QtMsgType, char const*) () > > from /usr/lib/libQtCore.so.4 > > #10 0x057fc92e in qFatal(char const*, ...) () > > from /usr/lib/libQtCore.so.4 > > #11 0x057fca25 in qt_assert(char const*, char const*, int) () > > from /usr/lib/libQtCore.so.4 > > #12 0x02c5b87f in Phonon::MediaSource::type() const () > > from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so > > #13 0x02c5e255 in Phonon::MediaSource::type() const () > > from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so > > #14 0x02c642a0 in Phonon::MediaSource::type() const () > > from /usr/lib/kde4/plugins/phonon_backend/phonon_xine.so > > #15 0x0609a884 in QApplicationPrivate::notify_helper(QObject*, QEvent*) > > () from /usr/lib/libQtGui.so.4 > > #16 0x060a1f0e in QApplication::notify(QObject*, QEvent*) () > > from /usr/lib/libQtGui.so.4 > > : > > > > Any ideas ? It seems to be an issue with the "phoneon-backend-xine" > > plugin so I switched from the xine backend to gstreamer and all of a > > sudden everything started working again. I had to install some > > additional gstreamer plugins but, at least now everything seems to be > > working again with respect to the KDE sound system. > > > > I guess we can say the problem is solved in as far as getting sound out > > of my KDE apps but I am still puzzled as to what might have caused the > > xine backend to start giving me problems. Wondering if I might need to > > send a formal bug report. Any suggestions or insignts into this problem > > are appreciated. > > There were a number of updates to the sound system (PulseAudio, Alsa) > and a number of the media players that caused problems recently. I > don't use KDE myself, so I don't recall the details very well as they > didn't bite me (or a later update fixed them and I didn't notice). > > I will say that this question is perfect fodder for and can be answered > far more completely on the "fedora-list" than here. I'd suggest you > search the archives of that list for the last couple of weeks and you > should see how to fix it. If not, post a message on that list and > you'll get all the help you could possibly want. The people on that > list are very helpful and a lot of them are heavy-duty KDE users and > mavens. I'm there, too, if you want to take a few swings at me! :-) Thanks Rick.. I think I'll sign up for that list and see what they have to say about this. Even though it's "working" now (more or less) it's still doing weird things now and then. Sound apps occasionally freeze or hang and configurations occasionally seem to change by themselves when I restart KDE, almost like there was a poltergeist inside. Case in point, I just got a message from KDE saying that the pulseaudio server is not working even though it was just working a few moments ago. But now a new "Default" device appeared and seems to work but the old "default" doesn't work. It's all but got me banging my head on the wall at this point. In any event I'll drop a line of that "fedora-list" before I lose it completely. Apparently they made a lot of changes that I'm not yet familiar with in the way sound is handled from the old KDE to the new KDE. Ciao John From micros50 at verizon.net Tue Aug 25 03:35:39 2009 From: micros50 at verizon.net (Micros50) Date: Mon, 24 Aug 2009 23:35:39 -0400 Subject: ext3 or ext4 ? Encrypt ? Message-ID: <1251171339.3006.18.camel@manhattan.ruffe.edu> When doing a fresh install and making new partitions I was greeted with some new options that I had never seen before. namely the option to use the newer ext4 file system and, the option to encrypt a file system. In my case I decided to go with ext4 except for the/boot partition in which they recommended sticking with ext3. So far so good, no issues with using ext4. I also decided to encrypt two partitions. So far so good. Wonder if anyone else feels it's best to go with these new options or stick with the old options ? Whatever the choice I just want to make sure my system sticks together... :) Hah. Ciao John From ricks at nerd.com Tue Aug 25 16:59:59 2009 From: ricks at nerd.com (Rick Stevens) Date: Tue, 25 Aug 2009 09:59:59 -0700 Subject: ext3 or ext4 ? Encrypt ? In-Reply-To: <1251171339.3006.18.camel@manhattan.ruffe.edu> References: <1251171339.3006.18.camel@manhattan.ruffe.edu> Message-ID: <4A94188F.2030205@nerd.com> Micros50 wrote: > When doing a fresh install and making new partitions I was greeted with > some new options that I had never seen before. namely the option to use > the newer ext4 file system and, the option to encrypt a file system. > > In my case I decided to go with ext4 except for the/boot partition in > which they recommended sticking with ext3. So far so good, no issues > with using ext4. I also decided to encrypt two partitions. So far so > good. > > Wonder if anyone else feels it's best to go with these new options or > stick with the old options ? > > Whatever the choice I just want to make sure my system sticks > together... :) Hah. ext4 does give you some performance enhancements. It does have the same caveat that ext3 has though, in that it's not built into the kernel by default so it has to be in your initrd image when booting. Also, grub does not grok ext4, though, which is why the /boot partition must be ext2 or ext3. Encryption has been around quite a while. The only thing different here is that it's offered as part of Anaconda's setup. It is purely optional and IMHO rather useless except on removable media. It introduces a performance hit (albeit minor) that will slow down access to encrypted filesystems and puts a bit more load on the CPU. For those reasons, I wouldn't use it on filesystems that are used for high I/O (e.g. a database or the destination of a video encoder). The fact you have to enter the passphrase for it when mounting makes it difficult to use for remotely managed machines (e.g. servers in a data center somewhere) and it really doesn't offer much security. If someone cracks into your system while it's mounted, it's a moot point. If you want to encrypt a filesystem on removable media (e.g. a FLASH drive, USB or firewire drive), then it can make some sense, but not otherwise. That's just my opinion. I could be wrong. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - The gene pool could use a little chlorine. - ---------------------------------------------------------------------- From micros50 at verizon.net Wed Aug 26 19:34:00 2009 From: micros50 at verizon.net (Micros50) Date: Wed, 26 Aug 2009 15:34:00 -0400 Subject: ext3 or ext4 ? Encrypt ? In-Reply-To: <4A94188F.2030205@nerd.com> References: <1251171339.3006.18.camel@manhattan.ruffe.edu> <4A94188F.2030205@nerd.com> Message-ID: <1251315240.5976.27.camel@manhattan.ruffe.edu> On Tue, 2009-08-25 at 09:59 -0700, Rick Stevens wrote: > Micros50 wrote: > > When doing a fresh install and making new partitions I was greeted with > > some new options that I had never seen before. namely the option to use > > the newer ext4 file system and, the option to encrypt a file system. > > > > In my case I decided to go with ext4 except for the/boot partition in > > which they recommended sticking with ext3. So far so good, no issues > > with using ext4. I also decided to encrypt two partitions. So far so > > good. > > > > Wonder if anyone else feels it's best to go with these new options or > > stick with the old options ? > > > > Whatever the choice I just want to make sure my system sticks > > together... :) Hah. > > ext4 does give you some performance enhancements. It does have the same > caveat that ext3 has though, in that it's not built into the kernel by > default so it has to be in your initrd image when booting. Also, grub > does not grok ext4, though, which is why the /boot partition must be > ext2 or ext3. > > Encryption has been around quite a while. The only thing different here > is that it's offered as part of Anaconda's setup. It is purely > optional and IMHO rather useless except on removable media. > > It introduces a performance hit (albeit minor) that will slow down > access to encrypted filesystems and puts a bit more load on the CPU. > For those reasons, I wouldn't use it on filesystems that are used for > high I/O (e.g. a database or the destination of a video encoder). > > The fact you have to enter the passphrase for it when mounting makes > it difficult to use for remotely managed machines (e.g. servers in a > data center somewhere) and it really doesn't offer much security. If > someone cracks into your system while it's mounted, it's a moot point. > > If you want to encrypt a filesystem on removable media (e.g. a FLASH > drive, USB or firewire drive), then it can make some sense, but not > otherwise. > > That's just my opinion. I could be wrong. So, in other words on a hard disk that is installed in the system itself encrypting the disc accomplishes little, unless of course someone were to physically steal the computer or, steal the drive itself. Nonetheless, I did, perhaps foolishly, encrypt a couple of my partitions just to see if it does work and/or if there are any bizarre issues. Thus far, other than having to answer a password, the encryption is more or less transparent, i.e. everything works as normal. However, on my next install/upgrade, I might just opt to go without the encryption. Of course it depends on whether or not I'm in a cryptic mood. Hah hah. :) Ciao John From ricks at nerd.com Wed Aug 26 20:15:11 2009 From: ricks at nerd.com (Rick Stevens) Date: Wed, 26 Aug 2009 13:15:11 -0700 Subject: ext3 or ext4 ? Encrypt ? In-Reply-To: <1251315240.5976.27.camel@manhattan.ruffe.edu> References: <1251171339.3006.18.camel@manhattan.ruffe.edu> <4A94188F.2030205@nerd.com> <1251315240.5976.27.camel@manhattan.ruffe.edu> Message-ID: <4A9597CF.7040407@nerd.com> Micros50 wrote: > On Tue, 2009-08-25 at 09:59 -0700, Rick Stevens wrote: >> Micros50 wrote: >>> When doing a fresh install and making new partitions I was greeted with >>> some new options that I had never seen before. namely the option to use >>> the newer ext4 file system and, the option to encrypt a file system. >>> >>> In my case I decided to go with ext4 except for the/boot partition in >>> which they recommended sticking with ext3. So far so good, no issues >>> with using ext4. I also decided to encrypt two partitions. So far so >>> good. >>> >>> Wonder if anyone else feels it's best to go with these new options or >>> stick with the old options ? >>> >>> Whatever the choice I just want to make sure my system sticks >>> together... :) Hah. >> ext4 does give you some performance enhancements. It does have the same >> caveat that ext3 has though, in that it's not built into the kernel by >> default so it has to be in your initrd image when booting. Also, grub >> does not grok ext4, though, which is why the /boot partition must be >> ext2 or ext3. >> >> Encryption has been around quite a while. The only thing different here >> is that it's offered as part of Anaconda's setup. It is purely >> optional and IMHO rather useless except on removable media. >> >> It introduces a performance hit (albeit minor) that will slow down >> access to encrypted filesystems and puts a bit more load on the CPU. >> For those reasons, I wouldn't use it on filesystems that are used for >> high I/O (e.g. a database or the destination of a video encoder). >> >> The fact you have to enter the passphrase for it when mounting makes >> it difficult to use for remotely managed machines (e.g. servers in a >> data center somewhere) and it really doesn't offer much security. If >> someone cracks into your system while it's mounted, it's a moot point. >> >> If you want to encrypt a filesystem on removable media (e.g. a FLASH >> drive, USB or firewire drive), then it can make some sense, but not >> otherwise. >> >> That's just my opinion. I could be wrong. > > So, in other words on a hard disk that is installed in the system itself > encrypting the disc accomplishes little, unless of course someone were > to physically steal the computer or, steal the drive itself. Yes, that's my take on it. As you say below, once it's mounted the encryption is transparent. If someone cracks into your system, the data is no more protected than if it were unencrypted. And if someone can physically steal the system or open it and take the drive, you have other security issues you should address first! :-) Now, if you keep personal data (passwords, account numbers, etc.) on a FLASH key as I do, yes, I have it encrypted. In fact, my passwords and such are in a KeyPassX database on that encrypted FLASH key and the database itself requires a passphrase, so essentially it's double- encrypted! Welcome to the Department of Redundancy Department. > Nonetheless, I did, perhaps foolishly, encrypt a couple of my partitions > just to see if it does work and/or if there are any bizarre issues. Thus > far, other than having to answer a password, the encryption is more or > less transparent, i.e. everything works as normal. However, on my next > install/upgrade, I might just opt to go without the encryption. Of > course it depends on whether or not I'm in a cryptic mood. Hah hah. :) Heheheh! There's nothing foolish about it. If you don't know just what the encryption stuff is, nothing's better than experimentation. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Huked on foniks reely wurked for me! - ---------------------------------------------------------------------- From micros50 at verizon.net Thu Aug 27 16:48:04 2009 From: micros50 at verizon.net (Micros50) Date: Thu, 27 Aug 2009 12:48:04 -0400 Subject: ext3 or ext4 ? Encrypt ? In-Reply-To: <4A9597CF.7040407@nerd.com> References: <1251171339.3006.18.camel@manhattan.ruffe.edu> <4A94188F.2030205@nerd.com> <1251315240.5976.27.camel@manhattan.ruffe.edu> <4A9597CF.7040407@nerd.com> Message-ID: <1251391685.4253.138.camel@manhattan.ruffe.edu> On Wed, 2009-08-26 at 13:15 -0700, Rick Stevens wrote: > > > Nonetheless, I did, perhaps foolishly, encrypt a couple of my partitions > > just to see if it does work and/or if there are any bizarre issues. Thus > > far, other than having to answer a password, the encryption is more or > > less transparent, i.e. everything works as normal. However, on my next > > install/upgrade, I might just opt to go without the encryption. Of > > course it depends on whether or not I'm in a cryptic mood. Hah hah. :) > > Heheheh! There's nothing foolish about it. If you don't know just what > the encryption stuff is, nothing's better than experimentation. I have a pretty good understanding of the theory and application of encryption but, it's that ol' "gotta try it out" syndrome. I see a new option come up when I do an install and right away i gotta try it. :) yes I agree, experimentation is usually a good thing. Ciao John. From buzdavis at earthlink.net Thu Aug 27 22:13:25 2009 From: buzdavis at earthlink.net (Buz Davis) Date: Thu, 27 Aug 2009 18:13:25 -0400 Subject: problem installing Fedora 8 Message-ID: <4A970505.6000907@earthlink.net> I switched hard disks so that my attempts to install were to a 137 gig disk that had a small msdos partition and a 30 g linux partition. This should have allowed plenty of space for an install, but I still got the [1/1] abnormal termination of Anaconda. I played around with some of the options and found that if I specified 'noprobe' I would get further into the process. After selecting English and a US keyboard Anaconda asked where the files to install were. When I selected 'Local CD/DVD' it informed me that it couldn't find a driver for it. (This seems odd, as it was RUNNING from the CD at the time). It offered a list of drivers from which to select but there was no obvious choice, and every choice that I tried resulted in a dump. The CD in question is a generic IDE 52x. I do have an identical CD on another linux box. Is there any utility by which I can find the driver that device is using ? If so, can I prepare a floppy with this driver to give to Anaconda ? Should this be in a standard ext3 filesystem or do I have to do something else to prepare a driver ? Any suggestions would be appreciated. Buz Davis From ricks at nerd.com Thu Aug 27 23:07:33 2009 From: ricks at nerd.com (Rick Stevens) Date: Thu, 27 Aug 2009 16:07:33 -0700 Subject: problem installing Fedora 8 In-Reply-To: <4A970505.6000907@earthlink.net> References: <4A970505.6000907@earthlink.net> Message-ID: <4A9711B5.7060202@nerd.com> Buz Davis wrote: > I switched hard disks so that my attempts to install were to a 137 gig > disk that had a small msdos partition and a 30 g linux partition. This > should have allowed plenty of space for an install, but I still got the > [1/1] abnormal termination of Anaconda. > > I played around with some of the options and found that if I specified > 'noprobe' I would get further into the process. After selecting English > and a US keyboard Anaconda asked where the files to install were. > When I selected 'Local CD/DVD' it informed me that it couldn't find a > driver for it. (This seems odd, as it was RUNNING from the CD at the > time). It offered a list of drivers from which to select but there was > no obvious choice, and every choice that I tried resulted in a dump. > The CD in question is a generic IDE 52x. > > I do have an identical CD on another linux box. Is there any utility by > which I can find the driver that device is using ? If so, can I prepare > a floppy with this driver to give to Anaconda ? Should this be in a > standard ext3 filesystem or do I have to do something else to prepare a > driver ? > > Any suggestions would be appreciated. Now that I rack my brain...is this an SMP (multi processor) or AMD-based (Athlon, Opteron) machine? Older Fedoras had issues with that stuff. You might try using "noapic" instead of "noprobe". "noprobe" blocks the recognition of some devices on some busses (which is why it couldn't find your CD). "noapic" gets around an APIC programming glitch on AMD and SMP machines. We used to hit that one a TON on SuperMicro AMD and AMD SMP boxes. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - LOOK OUT!!! BEHIND YOU!!! - ---------------------------------------------------------------------- From buzdavis at earthlink.net Fri Aug 28 02:47:39 2009 From: buzdavis at earthlink.net (Buz Davis) Date: Thu, 27 Aug 2009 22:47:39 -0400 Subject: problem installing Fedora 8 Message-ID: <4A97454B.5090403@earthlink.net> Thanks, Rick, it is an AMD system (a K6) but the noapic didn't work. However I will google "fedora and AMD" and see what I can turn up. From ricks at nerd.com Fri Aug 28 15:21:24 2009 From: ricks at nerd.com (Rick Stevens) Date: Fri, 28 Aug 2009 08:21:24 -0700 Subject: problem installing Fedora 8 In-Reply-To: <4A97454B.5090403@earthlink.net> References: <4A97454B.5090403@earthlink.net> Message-ID: <4A97F5F4.9080903@nerd.com> Buz Davis wrote: > Thanks, Rick, it is an AMD system (a K6) but the noapic didn't work. > However I will google "fedora and AMD" and see what I can turn up. Have you tried looking at the other consoles (ALT-F2, ALT-F3, ALT-F4) to see if there's some specific error when it croaks? ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer ricks at nerd.com - - AIM/Skype: therps2 ICQ: 22643734 Yahoo: origrps2 - - - - Any sufficiently advanced technology is indistinguishable from a - - rigged demo. - ----------------------------------------------------------------------