From yersinia.spiros at gmail.com Sun Aug 2 14:09:10 2009 From: yersinia.spiros at gmail.com (yersinia) Date: Sun, 2 Aug 2009 16:09:10 +0200 Subject: [389-users] Samba integration with FDS and Heartbeat for HA Samba In-Reply-To: <4A734D6E.8000403@viveli.com> References: <4A734D6E.8000403@viveli.com> Message-ID: On Fri, Jul 31, 2009 at 10:00 PM, David Christensen < David.Christensen at viveli.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I successfully setup heartbeat and glusterfs (instead of DRBD) to > provide an HA Samba configuration. I tested that fail over worked fine > all the existing computers were able to get to their shares and re > authenticate users. > > However I discovered that I was not able to join computers to the domain > after the configuration was setup. The netbios name was changed to > accommodate the new heartbeat VIP and the new VIP is the only address I > have samba bound to. > > When I go to add the computer to the domain, type to the domain in and > hit enter, I am presented with a login dialog box. When I enter the > admin and password and hit enter, after a few seconds I get the warning > that a controller for the domain could not be foumd. > So samba is the PDC, if not clear to me from the mail. If this is the case the netbios name of the samba - or windows prewindows 2000 - domain PDC is domainname#1B The samba - or windows prewindos 200 - domain DC - so also the BC - is domain#1C (e.g. the domain master browser in windows term ) Now, how your samba PDC/BDC registrar their name ? If you use wins in smb.conf - let me call the wins server with the ip address x.y.z.w - try to lookup the domain name nmblookup -R -U x.y.z.w domainame#1C (e similar for #1B) If not - your PDC is into the same broadcast address (e.g subnet) of your client - nmblookup domainname#1B (#1C also) In reality the client was finding domainname#1C for update the machine account onto the PDC. If the one of the preceding command fail well it is only a wins or other namespace registration problem : not a local samba problem. Or, perhaps you have not tell in more depth the different configuration on samba you have done, so it is possible i am wrong. Regard > I suspect that there is some caching going on and (maybe) winbind is > using the old info for the PDC and not the new? > > Are there any caches I could clear that may fix this? Am I on the right > track or is there somethign else I should be looking at? > > When I compare the ldap access logs with and without heartbeat, there is > a difference in the query. As I previously mentioned, without > heartbeat, adding is successful, with heartbeat it is not. I found that > the search base is different: > > With heartbeat - SRCH base="cn=groups,cn=accounts,dc=example,dc=com" > scope=2 filter="(&(objectClass=sambaGroupMapping)(gidNumber=99))" > attrs="gidNumber sambaSID sambaGroupType sambaSIDList description > displayName cn objectClass" > > W/heartbeat - SRCH > > base="sambaDomainName=exampleHQ,sambaDomainName=exampleHQ,dc=example,dc=com" > scope=2 > > filter="(&(objectClass=sambaTrustedDomainPassword)(sambaDomainName=exampleHQ))" > attrs=ALL > > When I compared the logs when executing pdbedit -Lv with both setups, > the queries are the same. > > Why would samba do a different query to the same instance of ldap when > configured with heartbeat and without heartbeat? > > The address that samba is binding to/from for access to ldap is not the > VIP provided by heartbeat. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org > > iEYEARECAAYFAkpzTW4ACgkQ5B+8XEnAvqub1ACdGFBhVRaePH0fuTD0mORGIMgB > V48AnR0znBY9KD3nhYYdPtR2dQXUWxBO > =jrTm > -----END PGP SIGNATURE----- > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From psundaram at wgen.net Tue Aug 4 15:53:17 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Tue, 04 Aug 2009 11:53:17 -0400 Subject: [389-users] Enable SSL in console issue Message-ID: Dear folks, I configured the FDS and as trying to setup the encryption and I ran into this. When I enabled ?Use SSL in console? and restarted the server. I was able to get into console and see that Admin server is fine, but the Directory server shows ?Stopped? and port is 636. Now it prompts me for password. Menubar: Log in to Directory Distinguished Name: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot. Password: ******* Here I entered the admin password that I setup during the ?setup-ds-admin.pl? phase. It is not accepting that. :( I also tried changing the DN to CN=Directory Manager, Dc=, dc=. It still doesn?t let me in. I went back to check the dse.ldif and tried editing the entry cn=encryption, cn=config....... nsSSLClientAuth: off nsSSL2: off nsSSL3=on Is there anything that can be done to turn the SSL off the console? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpolli at babel.it Tue Aug 4 16:51:33 2009 From: rpolli at babel.it (Roberto Polli) Date: Tue, 4 Aug 2009 18:51:33 +0200 Subject: [389-users] can't modify userPassword with proxy user: after code debugging... Message-ID: <200908041851.34124.rpolli@babel.it> Following http://www.mail-archive.com/fedora-directory- users at redhat.com/msg09799.html As of now, no solution but give to proxy user write access on entries.. if you succeeded in another way you're welcome to post. I looked+gdb the code of modify.c: when I try to change userPassword another flow is done. modify.c: ... if (has_password_mod): PasswordFlow return StandardFlow return in PasswordFlow, the function op_shared_allow_pw_change() change the password ignoring controls and evaluating proxy user access permissions as a local user in StandardFlow, all the controls are evaluated and the proxy_dn is set To make a specific request using only the interesting controls, avoiding evaluation of unneeded ones (), I used the following options to ldapmodify| passwd * -g -R -J 2.16.840.1.113730.3.4.18 Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altres? a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali." From msauton at redhat.com Tue Aug 4 17:25:11 2009 From: msauton at redhat.com (Marc Sauton) Date: Tue, 04 Aug 2009 10:25:11 -0700 Subject: [389-users] Enable SSL in console issue In-Reply-To: References: Message-ID: <4A786EF7.60303@redhat.com> This is expected, see online documentation: The prompt is a password to unlock the NSS DB key file used for SSL on an RHDS instance. http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_SSL-Starting_the_Server_with_SSL_Enabled.html#Starting_the_Server_with_SSL_Enabled-Creating_a_Password_File And about admin and directory manager users: http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Introduction_to_RHDS-Configuring_the_Directory_Manager.html http://www.redhat.com/docs/manuals/dir-server/8.1/admin/console.html#Introduction_to_RHDS-Binding_to_the_Directory_from_RHI_Console M. Prashanth Sundaram wrote: > Dear folks, > > I configured the FDS and as trying to setup the encryption and I ran > into this. > > When I enabled ?Use SSL in console? and restarted the server. I was > able to get into console and see that Admin server is fine, but the > Directory server shows ?Stopped? and port is 636. Now it prompts me > for password. > > Menubar: Log in to Directory > Distinguished Name: > uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot. > Password: ******* > > Here I entered the admin password that I setup during the > ?setup-ds-admin.pl? phase. It is not accepting that. :( > I also tried changing the DN to CN=Directory Manager, Dc=, dc=. It > still doesn?t let me in. > > I went back to check the dse.ldif and tried editing the entry > cn=encryption, cn=config....... nsSSLClientAuth: off nsSSL2: off > *nsSSL3=on > *Is there anything that can be done to turn the SSL off the console? > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From andrey.ivanov at polytechnique.fr Tue Aug 4 19:23:59 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Tue, 4 Aug 2009 21:23:59 +0200 Subject: [389-users] Supported Extension In-Reply-To: References: <4A719F20.3050306@redhat.com> Message-ID: <1601b8650908041223s14a1f0bap7260191029e71f47@mail.gmail.com> 2009/7/30 Techie : > On Thu, Jul 30, 2009 at 6:24 AM, Rich Megginson wrote: >> Techie wrote: >>> >>> Greetings all, >>> Is it possible to add the supportedExtension: 1.3.6.1.4.1.4203.1.11.1 >>> to the 389 Directory server? >>> >> >> It's not there? ?It should already be listed: >> ldapsearch -x -s base -b "" >> dn: >> ... >> supportedExtension: 2.16.840.1.113730.3.5.9 >> supportedExtension: 2.16.840.1.113730.3.5.4 >> supportedExtension: 1.3.6.1.4.1.4203.1.11.1 <---- >> supportedControl: 2.16.840.1.113730.3.4.2 >> supportedControl: 2.16.840.1.113730.3.4.3 > > My Mistake... The extension I am looking for is. > > 1.3.6.1.4.1.4203.1.11.3 > > 1.3.6.1.4.1.4203.1.11.1 is definitely there. There is already an enhancement request filed in bugzilla for this extension : https://bugzilla.redhat.com/show_bug.cgi?id=437632 From andrey.ivanov at polytechnique.fr Tue Aug 4 19:43:27 2009 From: andrey.ivanov at polytechnique.fr (Andrey Ivanov) Date: Tue, 4 Aug 2009 21:43:27 +0200 Subject: [389-users] OpenLDAP as a slave of Fedora Directory Server? In-Reply-To: <4A721F7C.2020905@itasoftware.com> References: <4A721864.9000902@itasoftware.com> <4A721EAA.7040600@broadcom.com> <4A721F7C.2020905@itasoftware.com> Message-ID: <1601b8650908041243u54aef521if0d7887b1e57d585@mail.gmail.com> Hi, You can also use the LDAP persistent search control an then convert the 389 attributes to openLDAP ones and send them immediately in real time, and then, once a day, just to be sure that everything is ok you can push the whole LDIF dump. Here is an example of a simple persistent search script in perl : my $ldap = Net::LDAP -> new ("ldap-test.example.com", port => 389, version => 3 ) or die $!; my $result = $ldap -> bind( "cn=Directory Manager", password => "mypassword"); my $persist = Net::LDAP::Control::PersistentSearch -> new ( changeTypes => 15, changesOnly => 1, returnECs => 1 ); my $ldap_filter = "(objectClass=*)"; my $result_search = $ldap -> search ( base => $COMPLETE_BASE, scope => "sub", filter => $ldap_filter, control => [ $persist ], callback=> \&process_entry ); exit; sub process_entry { my $message = shift; my $entry = shift; print $entry -> dn()."\n"; #output entry DN my $ldif = Net::LDAP::LDIF -> new( "", "w", onerror => 'undef'); $ldif -> write_entry ($entry); #output entry in LDIF $ldif -> done ( ); } You may also be interested in digging a little bit the ldofsort.pl and ldifdiff.pl utilities from perl-LDAP rpm package (they are in /usr/share/doc/perl-LDAP-0.33/contrib/ in CentOS/RHEL 5.3). These are an excellent solution if you need to generate the difference between two ldifs and then push this delta to openldap, for example... 2009/7/31 Anne Cross : > Rats. ?That's pretty much the conclusion I'd reached, but I'd hoped I was > wrong, based on the wiki page. ?Unfortunately, for account terminations, we > need more than just the ldif export/import, and Security is kind of cranky > about the lack. > > Thanks for the answer. ?I guess I'll cross my fingers that somebody takes it > off of the wishlist soon. > > ? -- juniper > > George Holbert wrote: >> >> Currently, OpenLDAP and 389 have totally different replication mechanisms, >> so you can't really replicate between the two. >> You can of course export / import filtered LDIF in either direction, >> which, depending on the need, is occasionally good enough. >> >> Anne Cross wrote: >>> >>> I've been through the FDS/389 website, and the best I've come up with is >>> this: http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration >>> >>> Unfortunately, that gives me the sync in the wrong direction. ?We have >>> pre-existing OpenLDAP servers that belong to a different group. ?We're >>> supposed to be their ultimate source of data - once we get set up - but they >>> won't change their servers from OpenLDAP because, as they say, they know how >>> they work and why should they do more work. >>> >>> I don't need data synced back from OpenLDAP, but syncrepl doesn't appear >>> to do the right thing when pointed at an FDS directory server, so what's the >>> secret, undocumented method? ?Even a hint would help. ?Google just keeps >>> turning up pages where people have named their box "Fedora" and it's all >>> openldap to openldap. >>> >>> >> >> >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > -- > ,___, > {o,o} ?Anne "Juniper" Cross > (___) ?Senior Linux Systems Engineer and Extropic Crusader > -"-"-- Information Technology, ITA Software > /^^^ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From jeff_clowser at fanniemae.com Tue Aug 4 20:09:50 2009 From: jeff_clowser at fanniemae.com (Clowser, Jeff) Date: Tue, 4 Aug 2009 16:09:50 -0400 Subject: [389-users] OpenLDAP as a slave of Fedora Directory Server? In-Reply-To: <1601b8650908041243u54aef521if0d7887b1e57d585@mail.gmail.com> References: <4A721864.9000902@itasoftware.com> <4A721EAA.7040600@broadcom.com><4A721F7C.2020905@itasoftware.com> <1601b8650908041243u54aef521if0d7887b1e57d585@mail.gmail.com> Message-ID: Using a persistent search will work, but if the script stops running for any reason (crash, reboot, etc), you might miss some changes. A more reliable, and probably more efficient approach is to use the retro changelog (http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication-Using_the_Retro_Changelog_Plug_in.html). As each change is made, it's logged there, with a sequential changenumber id. Using the changenumber ID, you can always record where you left off, so if you have to restart your sync script, you can pick up exactly where you left off. You can probably even use a persistent search on the retro changelog to process changes as they happen near realtime, while still having the benefit of tracking what the last change made was. - Jeff > -----Original Message----- > From: fedora-directory-users-bounces at redhat.com > [mailto:fedora-directory-users-bounces at redhat.com] On Behalf > Of Andrey Ivanov > Sent: Tuesday, August 04, 2009 3:43 PM > To: General discussion list for the 389 Directory server project. > Subject: Re: [389-users] OpenLDAP as a slave of Fedora > Directory Server? > > Hi, > > You can also use the LDAP persistent search control an then convert > the 389 attributes to openLDAP ones and send them immediately in real > time, and then, once a day, just to be sure that everything is ok you > can push the whole LDIF dump. Here is an example of a simple > persistent search script in perl : > > > my $ldap = Net::LDAP -> new ("ldap-test.example.com", port => 389, > version => 3 ) or die $!; > my $result = $ldap -> bind( "cn=Directory Manager", password > => "mypassword"); > > my $persist = Net::LDAP::Control::PersistentSearch -> new ( > > changeTypes => 15, > > changesOnly => 1, > returnECs => 1 > ); > > > > my $ldap_filter = "(objectClass=*)"; > my $result_search = $ldap -> search ( > base => $COMPLETE_BASE, > scope => "sub", > filter => $ldap_filter, > control => [ $persist ], > callback=> \&process_entry > ); > exit; > > sub process_entry > { > my $message = shift; > my $entry = shift; > print $entry -> dn()."\n"; #output entry DN > my $ldif = Net::LDAP::LDIF -> new( "", "w", onerror > => 'undef'); > $ldif -> write_entry ($entry); #output entry in LDIF > $ldif -> done ( ); > } > > > > You may also be interested in digging a little bit the ldofsort.pl and > ldifdiff.pl utilities from perl-LDAP rpm package (they are in > /usr/share/doc/perl-LDAP-0.33/contrib/ in CentOS/RHEL 5.3). These are > an excellent solution if you need to generate the difference between > two ldifs and then push this delta to openldap, for example... > > > 2009/7/31 Anne Cross : > > Rats. ?That's pretty much the conclusion I'd reached, but > I'd hoped I was > > wrong, based on the wiki page. ?Unfortunately, for account > terminations, we > > need more than just the ldif export/import, and Security is > kind of cranky > > about the lack. > > > > Thanks for the answer. ?I guess I'll cross my fingers that > somebody takes it > > off of the wishlist soon. > > > > ? -- juniper > > > > George Holbert wrote: > >> > >> Currently, OpenLDAP and 389 have totally different > replication mechanisms, > >> so you can't really replicate between the two. > >> You can of course export / import filtered LDIF in either > direction, > >> which, depending on the need, is occasionally good enough. > >> > >> Anne Cross wrote: > >>> > >>> I've been through the FDS/389 website, and the best I've > come up with is > >>> this: > http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration > >>> > >>> Unfortunately, that gives me the sync in the wrong > direction. ?We have > >>> pre-existing OpenLDAP servers that belong to a different > group. ?We're > >>> supposed to be their ultimate source of data - once we > get set up - but they > >>> won't change their servers from OpenLDAP because, as they > say, they know how > >>> they work and why should they do more work. > >>> > >>> I don't need data synced back from OpenLDAP, but syncrepl > doesn't appear > >>> to do the right thing when pointed at an FDS directory > server, so what's the > >>> secret, undocumented method? ?Even a hint would help. ? Google just keeps > >>> turning up pages where people have named their box > "Fedora" and it's all > >>> openldap to openldap. > >>> > >>> > >> > >> > >> > >> -- > >> 389 users mailing list > >> 389-users at redhat.com > >> https://www.redhat.com/mailman/listinfo/fedora-directory-users > >> > > > > > > -- > > ,___, > > {o,o} ?Anne "Juniper" Cross > > (___) ?Senior Linux Systems Engineer and Extropic Crusader > > -"-"-- Information Technology, ITA Software > > /^^^ > > > > -- > > 389 users mailing list > > 389-users at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From psundaram at wgen.net Tue Aug 4 21:32:00 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Tue, 04 Aug 2009 17:32:00 -0400 Subject: [389-users] Enable SSL in console issue Message-ID: Marc, I created the password files same as the RedHat guide, pin.txt and password.conf and they both worked good until I enabled ?Use SSL in console?. I used tried all the passwords that I used in FDS, but none works. :( I was able to restart and stop dirsrv and dirsrv-admin from terminal. Can you tell me if the DN is correct? Distinguished Name: uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot. Prashanth ------------------------ This is expected, see online documentation: The prompt is a password to unlock the NSS DB key file used for SSL on an RHDS instance. http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_SSL-Startin g_the_Server_with_SSL_Enabled.html#Starting_the_Server_with_SSL_Enabled-Crea ting_a_Password_File And about admin and directory manager users: http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Introduction_to_RHDS -Configuring_the_Directory_Manager.html http://www.redhat.com/docs/manuals/dir-server/8.1/admin/console.html#Introdu ction_to_RHDS-Binding_to_the_Directory_from_RHI_Console M. ------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From msauton at redhat.com Wed Aug 5 01:35:08 2009 From: msauton at redhat.com (Marc Sauton) Date: Tue, 04 Aug 2009 18:35:08 -0700 Subject: [389-users] Enable SSL in console issue In-Reply-To: References: Message-ID: <4A78E1CC.7000804@redhat.com> Prashanth Sundaram wrote: > Marc, > > I created the password files same as the RedHat guide, pin.txt and > password.conf and they both worked good until I enabled ?Use SSL in > console?. I used tried all the passwords that I used in FDS, but none > works. :( I was able to restart and stop dirsrv and dirsrv-admin from > terminal. > > Can you tell me if the DN is correct? Distinguished Name: > uid=admin,ou=Administrators,ou=TopologyManagement,o=NetscapeRoot. > This dn looks ok. M. > Prashanth > ------------------------ > This is expected, see online documentation: > The prompt is a password to unlock the NSS DB key file used for SSL on > an RHDS instance. > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_SSL-Starting_the_Server_with_SSL_Enabled.html#Starting_the_Server_with_SSL_Enabled-Creating_a_Password_File > > And about admin and directory manager users: > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Introduction_to_RHDS-Configuring_the_Directory_Manager.html > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/console.html#Introduction_to_RHDS-Binding_to_the_Directory_from_RHI_Console > M. > > ------------------ > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From Dharmin.Mandalia at TangaNet.net Wed Aug 5 09:34:04 2009 From: Dharmin.Mandalia at TangaNet.net (Dharmin Mandalia) Date: Wed, 5 Aug 2009 10:34:04 +0100 (BST) Subject: [389-users] no modifiable attributes specified Message-ID: <53055.199.46.244.228.1249464844.squirrel@mail.tanganet.net> Hello On my dir server, I am seeing lots of similar to below messages, how this can be resolve so I don't see below error msg.. appreciate your help. on dvfnds01 , is the supplier # tail -f /var/log/dirsrv/slap-*/access [05/Aug/2009:09:07:19 +0000] NSMMReplicationPlugin - agmt="cn=dvfnds02" (dvfnds02:636): Consumer failed to replay change (uniqueid 059b5581-0d2511dd-ae03d7e3-3dfce5fc, CSN 4a794bc8000000010000): DSA is unwilling to perform. Will retry later. on dvfnds02 , is the consumer # tail -f /var/log/dirsrv/slap-*/access [05/Aug/2009:09:07:19 +0000] conn=3561655 SSL 256-bit AES [05/Aug/2009:09:07:19 +0000] conn=3561655 op=0 BIND dn="cn=Replication Manager,cn=config" method=128 version=3 [05/Aug/2009:09:07:19 +0000] conn=3561655 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=replication manager,cn=config" [05/Aug/2009:09:07:19 +0000] conn=3561655 op=1 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [05/Aug/2009:09:07:19 +0000] conn=3561655 op=1 RESULT err=0 tag=101 nentries=1 etime=0 [05/Aug/2009:09:07:19 +0000] conn=3561655 op=2 SRCH base="" scope=0 filter="(objectClass=*)" attrs="supportedControl supportedExtension" [05/Aug/2009:09:07:19 +0000] conn=3561655 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [05/Aug/2009:09:07:19 +0000] conn=3561655 op=3 EXT oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" [05/Aug/2009:09:07:19 +0000] conn=3561655 op=3 RESULT err=0 tag=120 nentries=0 etime=0 [05/Aug/2009:09:07:19 +0000] conn=3561655 op=4 SRCH base="cn=replica,cn=\22dc=TB,dc=be\22,cn=mapping tree,cn=config" scope=0 filter="(objectClass=*)" attrs="nsDS5ReplicaId" [05/Aug/2009:09:07:19 +0000] conn=3561655 op=4 RESULT err=32 tag=101 nentries=0 etime=0 [05/Aug/2009:09:07:19 +0000] conn=3561655 op=5 MOD dn="uid=john.elle,ou=people,ou=EB,dc=TB,dc=be", no modifiable attributes specified [05/Aug/2009:09:07:19 +0000] conn=3561655 op=5 RESULT err=53 tag=103 nentries=0 etime=0 [05/Aug/2009:09:07:19 +0000] conn=3561656 fd=186 slot=186 SSL connection from 192.168.3.12 to 192.168.3.134 [05/Aug/2009:09:07:19 +0000] conn=3561656 op=-1 fd=186 closed - Encountered end of file. Does anyone have a list of what error code 53 is or error code 32 is.. Thanks... Regards Dharmin From nkinder at redhat.com Wed Aug 5 15:39:39 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Wed, 05 Aug 2009 08:39:39 -0700 Subject: [389-users] no modifiable attributes specified In-Reply-To: <53055.199.46.244.228.1249464844.squirrel@mail.tanganet.net> References: <53055.199.46.244.228.1249464844.squirrel@mail.tanganet.net> Message-ID: <4A79A7BB.90401@redhat.com> On 08/05/2009 02:34 AM, Dharmin Mandalia wrote: > Hello > > On my dir server, I am seeing lots of similar to below messages, how this > can be resolve so I don't see below error msg.. appreciate your help. > > > on dvfnds01 , is the supplier > # tail -f /var/log/dirsrv/slap-*/access > [05/Aug/2009:09:07:19 +0000] NSMMReplicationPlugin - agmt="cn=dvfnds02" > (dvfnds02:636): Consumer failed to replay change (uniqueid > 059b5581-0d2511dd-ae03d7e3-3dfce5fc, CSN 4a794bc8000000010000): DSA is > unwilling to perform. Will retry later. > > > > on dvfnds02 , is the consumer > # tail -f /var/log/dirsrv/slap-*/access > [05/Aug/2009:09:07:19 +0000] conn=3561655 SSL 256-bit AES > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=0 BIND dn="cn=Replication > Manager,cn=config" method=128 version=3 > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="cn=replication manager,cn=config" > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=1 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=1 RESULT err=0 tag=101 > nentries=1 etime=0 > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=2 SRCH base="" scope=0 > filter="(objectClass=*)" attrs="supportedControl supportedExtension" > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=2 RESULT err=0 tag=101 > nentries=1 etime=0 > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=3 EXT > oid="2.16.840.1.113730.3.5.3" name="Netscape Replication Start Session" > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=3 RESULT err=0 tag=120 > nentries=0 etime=0 > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=4 SRCH > base="cn=replica,cn=\22dc=TB,dc=be\22,cn=mapping tree,cn=config" scope=0 > filter="(objectClass=*)" attrs="nsDS5ReplicaId" > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=4 RESULT err=32 tag=101 > nentries=0 etime=0 > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=5 MOD > dn="uid=john.elle,ou=people,ou=EB,dc=TB,dc=be", no modifiable attributes > specified > [05/Aug/2009:09:07:19 +0000] conn=3561655 op=5 RESULT err=53 tag=103 > nentries=0 etime=0 > [05/Aug/2009:09:07:19 +0000] conn=3561656 fd=186 slot=186 SSL connection > from 192.168.3.12 to 192.168.3.134 > [05/Aug/2009:09:07:19 +0000] conn=3561656 op=-1 fd=186 closed - > Encountered end of file. > > Does anyone have a list of what error code 53 is or error code 32 is.. > http://www.redhat.com/docs/manuals/dir-server/8.1/cli/Configuration_Command_File_Reference-Access_Log_and_Connection_Code_Reference-LDAP_Result_Codes.html > Thanks... > > Regards > Dharmin > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From psundaram at wgen.net Fri Aug 7 18:45:19 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Fri, 07 Aug 2009 14:45:19 -0400 Subject: [389-users] Command line to request certificate Message-ID: All, I know I am being a bummer here, but I am running into problems now and then. The reason is I am trying to script out the FDS deployment. Here are my questions: 1. What is the command line equivalent of requesting a server certificate for Admin Server and Directory server? The console works fine. I am using openssl to generate certificates in x509 format. 2. In order to setup subsequent FDS servers, I should copy /etc/dirsrv ; /usr/lib/dirsrv / ; /var/lib/dirsrv to the other hosts. Is this correct? And Run register-ds-admin.pl 3.If I do as in 2. Not sure if the certificates will cause issue. Also I am using ldap.domain.com as server identifier and mapping a virtual IP for load balancing purpose. I read that server name should be same as hostname, but I am using a DNS record if ldap.domain.com. Will it cause any issues? Thanks, Prashanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From edlinuxguru at gmail.com Mon Aug 10 02:02:44 2009 From: edlinuxguru at gmail.com (Edward Capriolo) Date: Sun, 9 Aug 2009 22:02:44 -0400 Subject: [389-users] OpenLDAP as a slave of Fedora Directory Server? In-Reply-To: References: <4A721864.9000902@itasoftware.com> <4A721EAA.7040600@broadcom.com> <4A721F7C.2020905@itasoftware.com> <1601b8650908041243u54aef521if0d7887b1e57d585@mail.gmail.com> Message-ID: If you have your main database as openldap and 389 is your secondary the old slurp replication should be able to push LDAP updates at FDS. On Tue, Aug 4, 2009 at 4:09 PM, Clowser, Jeff wrote: > Using a persistent search will work, but if the script stops running for any reason (crash, reboot, etc), you might miss some changes. ?A more reliable, and probably more efficient approach is to use the retro changelog (http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Managing_Replication-Using_the_Retro_Changelog_Plug_in.html). ?As each change is made, it's logged there, with a sequential changenumber id. ?Using the changenumber ID, you can always record where you left off, so if you have to restart your sync script, you can pick up exactly where you left off. ?You can probably even use a persistent search on the retro changelog to process changes as they happen near realtime, while still having the benefit of tracking what the last change made was. > > ?- Jeff > > >> -----Original Message----- >> From: fedora-directory-users-bounces at redhat.com >> [mailto:fedora-directory-users-bounces at redhat.com] On Behalf >> Of Andrey Ivanov >> Sent: Tuesday, August 04, 2009 3:43 PM >> To: General discussion list for the 389 Directory server project. >> Subject: Re: [389-users] OpenLDAP as a slave of Fedora >> Directory Server? >> >> Hi, >> >> You can also use the LDAP persistent search control an then convert >> the 389 attributes to openLDAP ones and send them immediately in real >> time, and then, once a day, just ?to be sure that everything is ok you >> can push the whole LDIF dump. Here is an example of a simple >> persistent search script in perl : >> >> >> my $ldap = Net::LDAP -> new ("ldap-test.example.com", port => 389, >> version => 3 ) or die $!; >> my $result = $ldap -> bind( "cn=Directory Manager", ?password >> => "mypassword"); >> >> my $persist = Net::LDAP::Control::PersistentSearch -> new ? ? ? ( >> >> changeTypes => 15, >> >> changesOnly => 1, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? returnECs => 1 >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ); >> >> >> >> my $ldap_filter = "(objectClass=*)"; >> my $result_search = $ldap -> search ( >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? base ? ?=> $COMPLETE_BASE, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? scope ? => "sub", >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? filter ?=> $ldap_filter, >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? control => [ $persist ], >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? callback=> \&process_entry >> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ); >> exit; >> >> sub process_entry >> { >> ? ? ? ? my $message = shift; >> ? ? ? ? my $entry = shift; >> ? ? ? ? print $entry -> dn()."\n"; ?#output entry DN >> ? ? ? ? my $ldif = Net::LDAP::LDIF -> new( "", "w", onerror >> => 'undef'); >> ? ? ? ? $ldif -> write_entry ($entry); #output entry in LDIF >> ? ? ? ? $ldif -> done ( ); >> } >> >> >> >> You may also be interested in digging a little bit the ldofsort.pl and >> ldifdiff.pl utilities from perl-LDAP rpm package (they are in >> /usr/share/doc/perl-LDAP-0.33/contrib/ in CentOS/RHEL 5.3). These are >> an excellent solution if you need to generate the difference between >> two ldifs and then push this delta to openldap, for example... >> >> >> 2009/7/31 Anne Cross : >> > Rats. ?That's pretty much the conclusion I'd reached, but >> I'd hoped I was >> > wrong, based on the wiki page. ?Unfortunately, for account >> terminations, we >> > need more than just the ldif export/import, and Security is >> kind of cranky >> > about the lack. >> > >> > Thanks for the answer. ?I guess I'll cross my fingers that >> somebody takes it >> > off of the wishlist soon. >> > >> > ? -- juniper >> > >> > George Holbert wrote: >> >> >> >> Currently, OpenLDAP and 389 have totally different >> replication mechanisms, >> >> so you can't really replicate between the two. >> >> You can of course export / import filtered LDIF in either >> direction, >> >> which, depending on the need, is occasionally good enough. >> >> >> >> Anne Cross wrote: >> >>> >> >>> I've been through the FDS/389 website, and the best I've >> come up with is >> >>> this: >> http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration >> >>> >> >>> Unfortunately, that gives me the sync in the wrong >> direction. ?We have >> >>> pre-existing OpenLDAP servers that belong to a different >> group. ?We're >> >>> supposed to be their ultimate source of data - once we >> get set up - but they >> >>> won't change their servers from OpenLDAP because, as they >> say, they know how >> >>> they work and why should they do more work. >> >>> >> >>> I don't need data synced back from OpenLDAP, but syncrepl >> doesn't appear >> >>> to do the right thing when pointed at an FDS directory >> server, so what's the >> >>> secret, undocumented method? ?Even a hint would help. > Google just keeps >> >>> turning up pages where people have named their box >> "Fedora" and it's all >> >>> openldap to openldap. >> >>> >> >>> >> >> >> >> >> >> >> >> -- >> >> 389 users mailing list >> >> 389-users at redhat.com >> >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> >> > >> > >> > -- >> > ,___, >> > {o,o} ?Anne "Juniper" Cross >> > (___) ?Senior Linux Systems Engineer and Extropic Crusader >> > -"-"-- Information Technology, ITA Software >> > /^^^ >> > >> > -- >> > 389 users mailing list >> > 389-users at redhat.com >> > https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From rmeggins at redhat.com Mon Aug 10 17:55:39 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 10 Aug 2009 11:55:39 -0600 Subject: [389-users] Re: can't modify userPassword with proxy user: after code debugging... In-Reply-To: <200908041851.34124.rpolli@babel.it> References: <200908041851.34124.rpolli@babel.it> Message-ID: <4A805F1B.1050008@redhat.com> Roberto Polli wrote: > Following http://www.mail-archive.com/fedora-directory- > users at redhat.com/msg09799.html > > As of now, no solution but give to proxy user write access on entries.. > if you succeeded in another way you're welcome to post. > > > I looked+gdb the code of modify.c: when I try to change userPassword another > flow is done. > > modify.c: > ... > if (has_password_mod): > PasswordFlow > return > > StandardFlow > return > > > > in PasswordFlow, the function > op_shared_allow_pw_change() > change the password ignoring controls and evaluating proxy user access > permissions as a local user > Thanks for debugging this. So the problem is that slapi_acl_check_mods() at line 945 is failing? > in StandardFlow, all the controls are evaluated and the proxy_dn is set > > To make a specific request using only the interesting controls, avoiding > evaluation of unneeded ones (), I used the following options to ldapmodify| > passwd > * -g -R -J 2.16.840.1.113730.3.4.18 > > > Peace, > R. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Aug 10 18:00:49 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 10 Aug 2009 12:00:49 -0600 Subject: [389-users] Command line to request certificate In-Reply-To: References: Message-ID: <4A806051.5020509@redhat.com> Prashanth Sundaram wrote: > All, > > I know I am being a bummer here, but I am running into problems now > and then. The reason is I am trying to script out the FDS deployment. > > Here are my questions: > > 1. What is the command line equivalent of requesting a server > certificate for Admin Server and Directory server? The console > works fine. > > I am using openssl to generate certificates in x509 format. There is a script which creates a self signed CA cert, then uses that CA to create server certs, using the certutil and pk12util command line tools. Have you seen this - http://directory.fedoraproject.org/wiki/Howto:SSL#Script > > 2. In order to setup subsequent FDS servers, I should copy > /etc/dirsrv ; /usr/lib/dirsrv / ; /var/lib/dirsrv to the other > hosts. Is this correct? No. > And Run register-ds-admin.pl No. You should not copy anything. You should simply run setup-ds-admin.pl on each machine. If you want to use a centralized console, that is, if you want to be able to see all of your servers no matter where you run the console, then you should select the option to use an existing configuration directory server on each server (other than the first one, of course). Have you read the Install Guide - http://www.redhat.com/docs/manuals/dir-server/8.1/install/index.html > > 3.If I do as in 2. Not sure if the certificates will cause > issue. Also I am using ldap.domain.com as server identifier and > mapping a virtual IP for load balancing purpose. I read that server > name should be same as hostname, but I am using a DNS record if > ldap.domain.com. Will it cause any issues? Yes. You will probably want to use subjectAltName in your directory server certificates. See http://directory.fedoraproject.org/wiki/Howto:SSL#Using_Subject_Alt_Name > > Thanks, > Prashanth > > > > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From marco.strullato at gmail.com Tue Aug 11 09:19:03 2009 From: marco.strullato at gmail.com (Marco Strullato) Date: Tue, 11 Aug 2009 11:19:03 +0200 Subject: [389-users] security problems Message-ID: Hi all, years ago I set up a ldap fedora directory server that is the used for pki authentication by many servers. In that period I didn't care much about security but now I would like to close security holes. I see that the directory manager password is stored in ldap.conf and rebuild sshd.conf (for pki) I see also that if I restrict access (600) to these files the authentication process does not end correctly because the uid and gid are not taken by ldap. Probabily during the user logon these files must be readable. By my point of view the solution could be to encrypt the directory manager password or to create a read only user. What do you suggest me? and how to implement? Regards, Marco Strullato -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.adams at cypressinteractive.com Tue Aug 11 09:19:28 2009 From: matt.adams at cypressinteractive.com (matt.adams at cypressinteractive.com) Date: 11 Aug 2009 04:19:28 -0500 Subject: =?utf-8?Q?Re:_[389=2Dusers]_security_problems?= Message-ID: <20090811091928.28148.qmail@s68278.CypressInteractive.com> Thank you for your message. I am out of the office until August 17th and will respond after I return. Thank you! From jsullivan at opensourcedevel.com Tue Aug 11 09:24:44 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Tue, 11 Aug 2009 05:24:44 -0400 Subject: [389-users] security problems In-Reply-To: References: Message-ID: <1249982684.22650.122.camel@jaspav.missionsit.net.missionsit.net> On Tue, 2009-08-11 at 11:19 +0200, Marco Strullato wrote: > Hi all, > years ago I set up a ldap fedora directory server that is the used for > pki authentication by many servers. In that period I didn't care much > about security but now I would like to close security holes. > > I see that the directory manager password is stored in ldap.conf and > rebuild sshd.conf (for pki) > > I see also that if I restrict access (600) to these files the > authentication process does not end correctly because the uid and gid > are not taken by ldap. Probabily during the user logon these files > must be readable. > > By my point of view the solution could be to encrypt the directory > manager password or to create a read only user. What do you suggest > me? and how to implement? > Hmm . . . been a while since I looked at this. If I recall correctly, in our environment, if the server needing ldap access did not need to write to the directory, e.g., password updates, we did not enter the directory manager password at all. On those systems that do, I thought it was stored in a separate file - something like ldap.secrets - and that file we could set as 600. Beyond that, we also disable anonymous access, create various read only browsing users (for different parts of our multi-client tree) with minimal access and use those as the binddn and bindpw users in ldap.conf. I hope this is what you are looking for. Good luck - John -- John A. Sullivan III Open Source Development Corporation +1 207-985-7880 jsullivan at opensourcedevel.com http://www.spiritualoutreach.com Making Christianity intelligible to secular society From psundaram at wgen.net Wed Aug 12 21:10:59 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Wed, 12 Aug 2009 17:10:59 -0400 Subject: [389-users] Command line to request certificate Message-ID: Rich, The script that you directed me to, it installs the CA cert in the server cert tab when I check in console. I tried manually adding it but it would still end up along with Directory server-cert. Also the admin server-cert shows up here as well. How do I troubleshoot that? The certs are fine in Admin server, but not in Directory instance. http://directory.fedoraproject.org/wiki/Howto:SSL#Script Another question: Since I am going to have two ldap servers and VIPs, can I just specify the DNS host names with the certificate like add certutil ?S.... ?8 ldap.foo1.com.ldap.foo2.com within the script, saving extra work? Thanks for your help!! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Aug 12 21:31:40 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 12 Aug 2009 15:31:40 -0600 Subject: [389-users] Command line to request certificate In-Reply-To: References: Message-ID: <4A8334BC.1060005@redhat.com> Prashanth Sundaram wrote: > Rich, > > The script that you directed me to, it installs the CA cert in the > server cert tab when I check in console. There is a bug in the script - it doesn't add all of the flags to the CA cert to make it show up as a CA cert in the console. But it really is a CA cert and you can use it as a CA cert. > I tried manually adding it but it would still end up along with > Directory server-cert. That's annoying, but it should still work for TLS/SSL just fine. > Also the admin server-cert shows up here as well. Right. The script generates the admin server cert in the directory server cert database, then exports it for use in the admin server cert database. > > How do I troubleshoot that? The certs are fine in Admin server, but > not in Directory instance. > > http://directory.fedoraproject.org/wiki/Howto:SSL#Script > > Another question: Since I am going to have two ldap servers and VIPs, > can I just specify the DNS host names with the certificate like add > certutil ?S.... ?8 ldap.foo1.com.ldap.foo2.com within the script, > saving extra work? Sure - feel free to hack the script as you need to. > > Thanks for your help!! > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From psundaram at wgen.net Thu Aug 13 15:51:05 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Thu, 13 Aug 2009 11:51:05 -0400 Subject: [389-users] Command line to request certificate Message-ID: Rich, I went forward with manual SSL install. I still see the console showing ldap.foo.com:389 on the top tree level. The ?User DS? field in Admin server points to ldap.foo.com:636. I have set all the encryption via console. Am I missing something? When I issue ldapsearch ?p 389, it returns ldap_sasl_interactive_bind_s: Unknown authentication method (-6) additional info: SASL(-4): no mechanism available: When I issue, ldapsearch ?p 636 is asks for pass but hangs thereafter. I have imported 500 entries. Also my indexes don?t seem to work, when searched on console. I used proper ldapsearch with all possible switches -x , -Z, -ZZ. After I enabled indexing on the directory level and ou levels, when I click on search with nothing on search bar, it retuns the ou levels and not users. So I manually indexed individual users, they don;t show up anyway. Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Thu Aug 13 15:58:25 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 13 Aug 2009 09:58:25 -0600 Subject: [389-users] Command line to request certificate In-Reply-To: References: Message-ID: <4A843821.3070104@redhat.com> Prashanth Sundaram wrote: > Rich, > > I went forward with manual SSL install. I still see the console > showing ldap.foo.com:389 on the top tree level. That's just for labeling. If you have restarted the directory server after configuring it to use TLS, you should see in the error log a message that it is listening on the TLS/SSL port. You should also be able to use netstat to see that it is listening to both the LDAP port (389) and the LDAPS port (636) (or whatever other port numbers you may have configured). > The ?User DS? field in Admin server points to ldap.foo.com:636. I have > set all the encryption via console. Am I missing something? When I > issue ldapsearch ?p 389, it returns ldap_sasl_interactive_bind_s: > Unknown authentication method (-6) additional info: SASL(-4): no > mechanism available: /usr/bin/ldapsearch by default will attempt a SASL bind. You must use the -x argument to use simple bind. > > When I issue, ldapsearch ?p 636 is asks for pass but hangs thereafter. > I have imported 500 entries. Also my indexes don?t seem to work, when > searched on console. Why do you think your indexes are not working? > I used proper ldapsearch with all possible switches -x , -Z, -ZZ. Note that -Z will require you to configure your ldapsearch client to use a CA cert - see man ldap.conf - search for TLS - you can also create/use ~/.ldaprc > After I enabled indexing on the directory level and ou levels, when I > click on search with nothing on search bar, it retuns the ou levels > and not users. So I manually indexed individual users, they don;t show > up anyway. I'm not sure what you mean by "index" in this context. > > Thanks, > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ryan.braun at ec.gc.ca Thu Aug 13 18:23:35 2009 From: ryan.braun at ec.gc.ca (Ryan Braun [ADS]) Date: Thu, 13 Aug 2009 18:23:35 +0000 Subject: [389-users] Specifying failover configuration servers Message-ID: <200908131823.35639.ryan.braun@ec.gc.ca> In my testing lab, I have setup 2 servers using MMR replicating both userroot and netscaperoot. All replication is working between the 2 servers. My 3rd server, a consumer read-only replica of userroot, I registered to the first of the 2 MMR servers. My question, is how do I configure the slave server to be able to contact the second (or any other) MMR server to get is admin server configs automatically if the first server ever goes boom? Eventually we will have 4 MMR servers, 2 groups of 2 with ip takeover style HA, for example westldap.example.com (virtual ip) westldap0.example.com westldap1.example.com eastldap.example.com (virtual ip) eastldap0.example.com eastldap1.example.com On the slave server, adm.conf looks like so (with host specific details replaced). Would I just add another ldapurl option? And would the server be smart enough to fail over to the next server listed? AdminDomain: example.com sysuser: nobody isie: cn=389 Administration Server, cn=Server Group, cn=ywgsrvr4.example.com, ou=example.com, o=NetscapeRoot SuiteSpotGroup: nogroup sysgroup: nogroup userdn: uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot ldapurl: ldap://srvr0.example.com:389/o=NetscapeRoot SuiteSpotUserID: nobody sie: cn=admin-serv-srvr4, cn=389 Administration Server, cn=Server Group, cn=srvr4.example.com, ou=example.com, o=NetscapeRoot Also, on the slave server I found this in dse.ldif dn: cn=Pass Through Authentication,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: Pass Through Authentication nsslapd-pluginPath: libpassthru-plugin nsslapd-pluginInitfunc: passthruauth_init nsslapd-pluginType: preoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database nsslapd-pluginarg0: ldap://srvr0.example.com:389/o=NetscapeRoot nsslapd-pluginId: passthruauth nsslapd-pluginVersion: 1.2.1 nsslapd-pluginVendor: Fedora Project nsslapd-pluginDescription: pass through authentication plugin I am guessing this pass thru allows me to login to the admin server on srvr0.example.com, and then allow me access to the slave server. If so, I would assume I would need an entry like this for each MMR server? Would I need a whole entry? or just stack the nsslapd-pluginarg0 attribute with all the servers ie dn: cn=Pass Through Authentication,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: Pass Through Authentication nsslapd-pluginPath: libpassthru-plugin nsslapd-pluginInitfunc: passthruauth_init nsslapd-pluginType: preoperation nsslapd-pluginEnabled: on nsslapd-plugin-depends-on-type: database nsslapd-pluginarg0: ldap://srvr0.example.com:389/o=NetscapeRoot nsslapd-pluginarg0: ldap://srvr1.example.com:389/o=NetscapeRoot nsslapd-pluginarg0: ldap://srvr.example.com:389/o=NetscapeRoot nsslapd-pluginId: passthruauth nsslapd-pluginVersion: 1.2.1 nsslapd-pluginVendor: Fedora Project nsslapd-pluginDescription: pass through authentication plugin All servers are running debian etch|lenny with the following versions ii port389-admin 1.1.8 Fedora Administration Server (admin) ii port389-adminutil 1.1.8 Utility library for directory server adminis ii port389-base 1.2.1 Fedora Directory Server (base) Thanks Ryan From rmeggins at redhat.com Thu Aug 13 19:03:29 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 13 Aug 2009 13:03:29 -0600 Subject: [389-users] Specifying failover configuration servers In-Reply-To: <200908131823.35639.ryan.braun@ec.gc.ca> References: <200908131823.35639.ryan.braun@ec.gc.ca> Message-ID: <4A846381.5040509@redhat.com> Ryan Braun [ADS] wrote: > In my testing lab, I have setup 2 servers using MMR replicating both userroot > and netscaperoot. All replication is working between the 2 servers. My 3rd > server, a consumer read-only replica of userroot, I registered to the first > of the 2 MMR servers. My question, is how do I configure the slave server > to be able to contact the second (or any other) MMR server to get is admin > server configs automatically if the first server ever goes boom? Eventually > we will have 4 MMR servers, 2 groups of 2 with ip takeover style HA, for > example > > westldap.example.com (virtual ip) > westldap0.example.com > westldap1.example.com > eastldap.example.com (virtual ip) > eastldap0.example.com > eastldap1.example.com > > On the slave server, adm.conf looks like so (with host specific details > replaced). Would I just add another ldapurl option? No, unfortunately it's not that smart. Unfortunately, failover is manual. Please file a bugzilla to request failover. > And would the server be > smart enough to fail over to the next server listed? > > AdminDomain: example.com > sysuser: nobody > isie: cn=389 Administration Server, cn=Server Group, cn=ywgsrvr4.example.com, > ou=example.com, o=NetscapeRoot > SuiteSpotGroup: nogroup > sysgroup: nogroup > userdn: uid=admin, ou=Administrators, ou=TopologyManagement, o=NetscapeRoot > ldapurl: ldap://srvr0.example.com:389/o=NetscapeRoot > SuiteSpotUserID: nobody > sie: cn=admin-serv-srvr4, cn=389 Administration Server, cn=Server Group, > cn=srvr4.example.com, ou=example.com, o=NetscapeRoot > > > Also, on the slave server I found this in dse.ldif > > dn: cn=Pass Through Authentication,cn=plugins,cn=config > objectClass: top > objectClass: nsSlapdPlugin > objectClass: extensibleObject > cn: Pass Through Authentication > nsslapd-pluginPath: libpassthru-plugin > nsslapd-pluginInitfunc: passthruauth_init > nsslapd-pluginType: preoperation > nsslapd-pluginEnabled: on > nsslapd-plugin-depends-on-type: database > nsslapd-pluginarg0: ldap://srvr0.example.com:389/o=NetscapeRoot > nsslapd-pluginId: passthruauth > nsslapd-pluginVersion: 1.2.1 > nsslapd-pluginVendor: Fedora Project > nsslapd-pluginDescription: pass through authentication plugin > > I am guessing this pass thru allows me to login to the admin server on > srvr0.example.com, and then allow me access to the slave server. Not exactly. This allows the uid=admin,....,o=NetscapeRoot user to login to servers that do not have o=NetscapeRoot, by passing through the credentials to the configuration DS (the server that has o=NetscapeRoot). > If so, I > would assume I would need an entry like this for each MMR server? Would I > need a whole entry? or just stack the nsslapd-pluginarg0 attribute with all > the servers ie > > dn: cn=Pass Through Authentication,cn=plugins,cn=config > objectClass: top > objectClass: nsSlapdPlugin > objectClass: extensibleObject > cn: Pass Through Authentication > nsslapd-pluginPath: libpassthru-plugin > nsslapd-pluginInitfunc: passthruauth_init > nsslapd-pluginType: preoperation > nsslapd-pluginEnabled: on > nsslapd-plugin-depends-on-type: database > nsslapd-pluginarg0: ldap://srvr0.example.com:389/o=NetscapeRoot > nsslapd-pluginarg0: ldap://srvr1.example.com:389/o=NetscapeRoot > nsslapd-pluginarg0: ldap://srvr.example.com:389/o=NetscapeRoot > The attribute is not multi-valued like that. There is a different syntax for specifying multiple host:port in an LDAP URL: ldap://srvr0.example.com:389 srvr1.example.com:389 srvr.example.com:389/o=NetscapeRoot > nsslapd-pluginId: passthruauth > nsslapd-pluginVersion: 1.2.1 > nsslapd-pluginVendor: Fedora Project > nsslapd-pluginDescription: pass through authentication plugin > > All servers are running debian etch|lenny with the following versions > ii port389-admin 1.1.8 > Fedora Administration Server (admin) > ii port389-adminutil 1.1.8 > Utility library for directory server adminis > ii port389-base 1.2.1 > Fedora Directory Server (base) > > > Thanks > > Ryan > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From ryan.braun at ec.gc.ca Thu Aug 13 20:34:00 2009 From: ryan.braun at ec.gc.ca (Ryan Braun [ADS]) Date: Thu, 13 Aug 2009 20:34:00 +0000 Subject: [389-users] Specifying failover configuration servers In-Reply-To: <4A846381.5040509@redhat.com> References: <200908131823.35639.ryan.braun@ec.gc.ca> <4A846381.5040509@redhat.com> Message-ID: <200908132034.00407.ryan.braun@ec.gc.ca> On August 13, 2009 07:03:29 pm Rich Megginson wrote: > Ryan Braun [ADS] wrote: > > In my testing lab, I have setup 2 servers using MMR replicating both > > userroot and netscaperoot. All replication is working between the 2 > > servers. My 3rd server, a consumer read-only replica of userroot, I > > registered to the first of the 2 MMR servers. My question, is how do I > > configure the slave server to be able to contact the second (or any > > other) MMR server to get is admin server configs automatically if the > > first server ever goes boom? Eventually we will have 4 MMR servers, 2 > > groups of 2 with ip takeover style HA, for example > > > > westldap.example.com (virtual ip) > > westldap0.example.com > > westldap1.example.com > > eastldap.example.com (virtual ip) > > eastldap0.example.com > > eastldap1.example.com > > > > On the slave server, adm.conf looks like so (with host specific details > > replaced). Would I just add another ldapurl option? > > No, unfortunately it's not that smart. Unfortunately, failover is > manual. Please file a bugzilla to request failover. filed. https://bugzilla.redhat.com/show_bug.cgi?id=517413 > > > And would the server be > > smart enough to fail over to the next server listed? > > > > AdminDomain: example.com > > sysuser: nobody > > isie: cn=389 Administration Server, cn=Server Group, > > cn=ywgsrvr4.example.com, ou=example.com, o=NetscapeRoot > > SuiteSpotGroup: nogroup > > sysgroup: nogroup > > userdn: uid=admin, ou=Administrators, ou=TopologyManagement, > > o=NetscapeRoot ldapurl: ldap://srvr0.example.com:389/o=NetscapeRoot > > SuiteSpotUserID: nobody > > sie: cn=admin-serv-srvr4, cn=389 Administration Server, cn=Server Group, > > cn=srvr4.example.com, ou=example.com, o=NetscapeRoot > > > > > > Also, on the slave server I found this in dse.ldif > > > > dn: cn=Pass Through Authentication,cn=plugins,cn=config > > objectClass: top > > objectClass: nsSlapdPlugin > > objectClass: extensibleObject > > cn: Pass Through Authentication > > nsslapd-pluginPath: libpassthru-plugin > > nsslapd-pluginInitfunc: passthruauth_init > > nsslapd-pluginType: preoperation > > nsslapd-pluginEnabled: on > > nsslapd-plugin-depends-on-type: database > > nsslapd-pluginarg0: ldap://srvr0.example.com:389/o=NetscapeRoot > > nsslapd-pluginId: passthruauth > > nsslapd-pluginVersion: 1.2.1 > > nsslapd-pluginVendor: Fedora Project > > nsslapd-pluginDescription: pass through authentication plugin > > > > I am guessing this pass thru allows me to login to the admin server on > > srvr0.example.com, and then allow me access to the slave server. > > Not exactly. This allows the uid=admin,....,o=NetscapeRoot user to > login to servers that do not have o=NetscapeRoot, by passing through the > credentials to the configuration DS (the server that has o=NetscapeRoot). I'm guilty of a bad habit here, whenever I connect to the console (not very often), I use cn=directory manager. Does the above pass whichever user was authenticated by the console, or just the uid=admin user? For example, I created another admin user uid=TAdmin,ou=Administrators, ou=TopologyManagement, o=netscapeRoot I login to the console on srvr0 with uid=TAdmin, and I can open up the ds-console for the slave. When I click on the configuration tab, I get an error saying the user doesn't have permission to perform this operation. Only I don't see anything in either servers access logs about it failing, or the admin server logs. Here is a snippet from srvr0, it binds successfully, then when I click on the config tab, it says no permission, asks for the password again, and does appear to bind successfully but again tells me I don't have permission. [13/Aug/2009:20:08:11 +0000] conn=3 fd=64 slot=64 connection from x.x.x.x to x.x.x.x [13/Aug/2009:20:08:11 +0000] conn=3 op=0 BIND dn="uid=tadmin,ou=Administrators, ou=TopologyManagement, o=netscapeRoot" method=128 version=3 [13/Aug/2009:20:08:11 +0000] conn=3 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=tadmin,ou=administrators,ou=topologymanagement,o=netscaperoot" [13/Aug/2009:20:09:09 +0000] conn=3 op=1 BIND dn="uid=tadmin,ou=Administrators, ou=TopologyManagement, o=netscapeRoot" method=128 version=3 [13/Aug/2009:20:09:09 +0000] conn=3 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=tadmin,ou=administrators,ou=topologymanagement,o=netscaperoot" [13/Aug/2009:20:09:29 +0000] conn=3 op=3 SRCH base="cn=config" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsslapd-security" [13/Aug/2009:20:09:29 +0000] conn=3 op=3 RESULT err=0 tag=101 nentries=0 etime=0 [13/Aug/2009:20:09:29 +0000] conn=3 op=4 SRCH base="cn=config" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsslapd-port nsslapd-secureport nsslapd-lastmod nsslapd-readonly nsslapd-schemacheck nsslapd-referral" [13/Aug/2009:20:09:29 +0000] conn=3 op=4 RESULT err=0 tag=101 nentries=0 etime=0 [13/Aug/2009:20:10:13 +0000] conn=3 op=6 BIND dn="uid=tadmin,ou=Administrators, ou=TopologyManagement, o=netscapeRoot" method=128 version=3 [13/Aug/2009:20:10:13 +0000] conn=3 op=6 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=tadmin,ou=administrators,ou=topologymanagement,o=netscaperoot" [13/Aug/2009:20:10:13 +0000] conn=3 op=7 SRCH base="cn=config" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs="nsslapd-port nsslapd-secureport nsslapd-lastmod nsslapd-readonly nsslapd-schemacheck nsslapd-referral" [13/Aug/2009:20:10:14 +0000] conn=3 op=7 RESULT err=0 tag=101 nentries=0 etime=1 When I login to the console with the initial uid=Admin,ou=Administrators, ou=TopologyManagement, o=netscapeRoot and fire up the ds-console for the slave, it does work fine. I can browse whatever I need, create items in cn=config etc. > > If so, I > > would assume I would need an entry like this for each MMR server? Would > > I need a whole entry? or just stack the nsslapd-pluginarg0 attribute > > with all the servers ie > > > > dn: cn=Pass Through Authentication,cn=plugins,cn=config > > objectClass: top > > objectClass: nsSlapdPlugin > > objectClass: extensibleObject > > cn: Pass Through Authentication > > nsslapd-pluginPath: libpassthru-plugin > > nsslapd-pluginInitfunc: passthruauth_init > > nsslapd-pluginType: preoperation > > nsslapd-pluginEnabled: on > > nsslapd-plugin-depends-on-type: database > > nsslapd-pluginarg0: ldap://srvr0.example.com:389/o=NetscapeRoot > > nsslapd-pluginarg0: ldap://srvr1.example.com:389/o=NetscapeRoot > > nsslapd-pluginarg0: ldap://srvr.example.com:389/o=NetscapeRoot > > The attribute is not multi-valued like that. There is a different > syntax for specifying multiple host:port in an LDAP URL: > ldap://srvr0.example.com:389 srvr1.example.com:389 > srvr.example.com:389/o=NetscapeRoot > Ok I'll give it a shot with the url, once I get the above sorted out. Ryan From konetzed at quixoticagony.com Fri Aug 14 00:12:54 2009 From: konetzed at quixoticagony.com (Edward "Koko" Konetzko) Date: Thu, 13 Aug 2009 19:12:54 -0500 Subject: [389-users] RHDS 8.1 and SNMP Message-ID: <4A84AC06.3050309@quixoticagony.com> I am wonder if SNMP monitoring works in RHDS 8.1 if so I need some help getting it working. The docs I have been using are linked below http://directory.fedoraproject.org/wiki/Howto:SNMPMonitoring http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Monitoring_DS_Using_SNMP.html The /etc/snmp/snmp.conf file com2sec notConfigUser default public group notConfigGroup v1 notConfigUser group notConfigGroup v2c notConfigUser view systemview included .1.3.6.1.2.1.1 view systemview included .1.3.6.1.2.1.25.1.1 access notConfigGroup "" any noauth exact systemview none none com2sec local localhost ldap group MyROGroup any local view all included .1 access MyROGroup "" any noauth 0 all none none syslocation Unknown (edit /etc/snmp/snmpd.conf) syscontact Root (configure /etc/snmp/snmp.local.conf) pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat master agentx The /etc/dirsrv/config/ldap-agent.conf # Config file for AgentX access so FDS can pass snmp variables to net-snmp # This is the agent config file. # # Start the agent with /opt/fedora-ds/bin/slapd/server/ldap-agent /opt/fedora-ds/ldap-agent.conf # # ## AgentX Master ## # # Where the agent communicates with the AgentX Master (net-snmp). # If not specified uses the net-snmp default of a UNIX socket # at /var/agentx/master. RTFM if you decide to use a differing location... # agentx-master /var/agentx/master ## AgentX Logdir ## # # Where the agent logs its logfile... # agent-logdir /var/log/dirsrv/agent/ # ## Server ## # # Which FDS instance you wish to monitor. # This should be the absolute path to the log dir of the FDS instance. # server slapd-ldap-master-n01 When I run "snmpwalk -v 1 -c ldap localhost .1.3.6.1.4.1.2312.6.1.1.3.389" I get nothing back but when I run "snmpwalk -v 1 -c ldap localhost .1.3.6.1.4.1.2312" the following is returned. SNMPv2-SMI::enterprises.2312.6.5.1.1.389 = STRING: "ldap master server" SNMPv2-SMI::enterprises.2312.6.5.1.2.389 = STRING: "Red Hat-Directory/8.1.0" SNMPv2-SMI::enterprises.2312.6.5.1.3.389 = STRING: "Rackspace Cloud" SNMPv2-SMI::enterprises.2312.6.5.1.4.389 = STRING: "Lab" SNMPv2-SMI::enterprises.2312.6.5.1.5.389 = STRING: "not made yet" SNMPv2-SMI::enterprises.2312.6.5.1.6.389 = STRING: "ldap-master-n01" All of that is correct with what is set in the Directory server. If I run "strings /var/run/dirsrv/slapd-ldap-master-n01.stats" I get the following back and I am wondering if there is supposed to be something where it says "Not Available"? Red Hat-Directory/8.1.0 ldap-master-n01 ldap master server Rackspace Cloud not made yet Not Available Not Available Not Available Not Available Not Available Not Available Not Available Not Available Not Available Not Available /usr/bin/ldap-agent-bin -D /etc/dirsrv/config/ldap-agent.conf just outputs the following over and over again in its log file. 2009-08-13 18:51:57 Reloading stats. 2009-08-13 18:51:57 Opening stats file (/var/run/dirsrv/slapd-ldap-master-n01.stats) for server: 389 Thanks in advance. Edward From amessina at messinet.com Fri Aug 14 00:21:26 2009 From: amessina at messinet.com (Anthony Messina) Date: Thu, 13 Aug 2009 19:21:26 -0500 Subject: [389-users] RHDS 8.1 and SNMP In-Reply-To: <4A84AC06.3050309@quixoticagony.com> References: <4A84AC06.3050309@quixoticagony.com> Message-ID: <200908131921.26971.amessina@messinet.com> On Thursday 13 August 2009 07:12:54 pm Edward "Koko" Konetzko wrote: > When I run "snmpwalk -v 1 -c ldap localhost > .1.3.6.1.4.1.2312.6.1.1.3.389" I get nothing back but when I run > "snmpwalk -v 1 -c ldap localhost .1.3.6.1.4.1.2312" the following is > returned. I just integrated with Cacti on this yesterday! I found that I needed to use SNMP version 2c to get the rest of the information. -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From nkinder at redhat.com Fri Aug 14 02:50:24 2009 From: nkinder at redhat.com (Nathan Kinder) Date: Thu, 13 Aug 2009 19:50:24 -0700 Subject: [389-users] RHDS 8.1 and SNMP In-Reply-To: <4A84AC06.3050309@quixoticagony.com> References: <4A84AC06.3050309@quixoticagony.com> Message-ID: <4A84D0F0.5010009@redhat.com> On 08/13/2009 05:12 PM, Edward "Koko" Konetzko wrote: > I am wonder if SNMP monitoring works in RHDS 8.1 if so I need some > help getting it working. > > The docs I have been using are linked below > http://directory.fedoraproject.org/wiki/Howto:SNMPMonitoring > http://www.redhat.com/docs/manuals/dir-server/8.1/admin/Monitoring_DS_Using_SNMP.html > > > > The /etc/snmp/snmp.conf file > > com2sec notConfigUser default public > group notConfigGroup v1 notConfigUser > group notConfigGroup v2c notConfigUser > view systemview included .1.3.6.1.2.1.1 > view systemview included .1.3.6.1.2.1.25.1.1 > access notConfigGroup "" any noauth exact systemview > none none > com2sec local localhost ldap > group MyROGroup any local > view all included .1 access MyROGroup > "" any noauth 0 all none none > syslocation Unknown (edit /etc/snmp/snmpd.conf) > syscontact Root (configure /etc/snmp/snmp.local.conf) > pass .1.3.6.1.4.1.4413.4.1 /usr/bin/ucd5820stat > master agentx > > The /etc/dirsrv/config/ldap-agent.conf > > # Config file for AgentX access so FDS can pass snmp variables to > net-snmp > # This is the agent config file. > # > # Start the agent with /opt/fedora-ds/bin/slapd/server/ldap-agent > /opt/fedora-ds/ldap-agent.conf > # > # > ## AgentX Master ## > # > # Where the agent communicates with the AgentX Master (net-snmp). > # If not specified uses the net-snmp default of a UNIX socket > # at /var/agentx/master. RTFM if you decide to use a differing > location... > # > agentx-master /var/agentx/master > > ## AgentX Logdir ## > # > # Where the agent logs its logfile... > # > agent-logdir /var/log/dirsrv/agent/ > # > ## Server ## > # > # Which FDS instance you wish to monitor. > # This should be the absolute path to the log dir of the FDS instance. > # > server slapd-ldap-master-n01 > > When I run "snmpwalk -v 1 -c ldap localhost > .1.3.6.1.4.1.2312.6.1.1.3.389" I get nothing back but when I run > "snmpwalk -v 1 -c ldap localhost .1.3.6.1.4.1.2312" the following is > returned. > > SNMPv2-SMI::enterprises.2312.6.5.1.1.389 = STRING: "ldap master server" > SNMPv2-SMI::enterprises.2312.6.5.1.2.389 = STRING: "Red > Hat-Directory/8.1.0" > SNMPv2-SMI::enterprises.2312.6.5.1.3.389 = STRING: "Rackspace Cloud" > SNMPv2-SMI::enterprises.2312.6.5.1.4.389 = STRING: "Lab" > SNMPv2-SMI::enterprises.2312.6.5.1.5.389 = STRING: "not made yet" > SNMPv2-SMI::enterprises.2312.6.5.1.6.389 = STRING: "ldap-master-n01" > > All of that is correct with what is set in the Directory server. > > If I run "strings /var/run/dirsrv/slapd-ldap-master-n01.stats" I get > the following back and I am wondering if there is supposed to be > something where it says "Not Available"? > > Red Hat-Directory/8.1.0 > ldap-master-n01 > ldap master server > Rackspace Cloud > not made yet > Not Available > Not Available > Not Available > Not Available > Not Available > Not Available > Not Available > Not Available > Not Available > Not Available The "Not Available" strings are from the unimplemented interactions table. This table is supposed to list the last 10 clients that the server has interacted with IIRC, but it's not implemented, so we just report "Not Available". The bulk of the stats are not strings, so what you see is everything I would expect. > > > /usr/bin/ldap-agent-bin -D /etc/dirsrv/config/ldap-agent.conf just > outputs the following over and over again in its log file. > > 2009-08-13 18:51:57 Reloading stats. > 2009-08-13 18:51:57 Opening stats file > (/var/run/dirsrv/slapd-ldap-master-n01.stats) for server: 389 > > > Thanks in advance. > Edward > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users From okelet at gmail.com Fri Aug 14 07:48:50 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Fri, 14 Aug 2009 09:48:50 +0200 Subject: [389-users] nsDirectoryServerTask objectClass Message-ID: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> Hi I am trying to create a task to update the index database, according to the instructions described here: - http://www.redhat.com/docs/manuals/dir-server/8.1/admin/applying-indexes.html - http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP_Design But when I create the task from a Perl script, i get an error about unknown object class: my $entry = Net::LDAP::Entry->new(); $tmp_index_name = 'cn'; my $cn = "$tmp_index_name index task"; $entry->dn("cn=$cn, cn=index, cn=tasks, cn=config"); $entry->add('objectClass' => ['nsDirectoryServerTask']); $entry->add('cn' => $cn); $entry->add('nsindexattribute' => "\"eq:pres\""); my $res = $entry->update($ldap_conn); The error is 'unknown object class "nsDirectoryServerTask"'. Where is that objectClass defined? # rpm -qa | grep -i fedora fedora-ds-admin-1.1.1-1.fc6 fedora-ds-1.1.0-3.fc6 fedora-ds-base-1.1.0-3.fc6 fedora-admin-console-1.1.0-4.fc6 fedora-idm-console-1.1.0-5.fc6 fedora-ds-console-1.1.0-5.fc6 # uname -a Linux grsgscbulp0301.sacyl.es 2.6.18-128.1.10.el5.centos.plusPAE #1 SMP Mon May 11 07:51:33 EDT 2009 i686 i686 i386 GNU/Linux Regards and thanks in advance. From siedler at hrd-asia.com Fri Aug 14 08:49:53 2009 From: siedler at hrd-asia.com (Wolf Siedler) Date: Fri, 14 Aug 2009 15:49:53 +0700 Subject: [389-users] Disable SSL in Administration server from command line? Message-ID: <4A852531.1040804@hrd-asia.com> Hi, I probably caused a major hiccup in my system - I can't log onto anymore by the Java console to the Administration Server. Unfortunately, my direcory server knowledge is not yet very deep so I got lost now. Last action I had done before that the attempted removal of SSL encryption from the Administration Server. Originally, I had connected with SSL encryption to the Admin Server. I then went to Configuration - Encryption, unchecked "Enable SSL for this server" saved everything and restarted dirsrv-admin on the command line. The outcome was as desired: Originally I connected the console by "https://admin.example.com:20126". After this change, connecting via "http://admin.example.com":20126" worked. In both cases, I connected from a remote PC. But then I goofed by rechecking "Enable SSL for this server" and saving the settings (nothing else was changed, in particular not the previously working certificate settings). After I few distractions I had forgotten about this and restarted the dirsrv-admin. Since then I can't log on via fedora-idm-console anymore. Neither "https://admin.example.com:20126" nor "http://admin.example.com":20126" works anymore. For https://admin.example.com:20216, I get the error: Cannot connect to the Admin Server "https://admin.example.com:20126" The URL is not correct or the server is not working. For http://admin.example.com:20216, I get this error: Cannot log on because of an incorrect User ID, Incorrect password or Directory problem. java.io.EOFException: Connection lost OK, the second failure I expected, but not the first one. I ca not believe that it is a typing error in URL, user name or password as all this information comes from a script and except for https/http, there were no modifications at all to this script. For both attempts, /var/log/dirsrv/admin-serv/error shows > [Fri Aug 14 16:19:05 2009] [error] SSL Library Error: -12268 Cannot > connect: SSL is disabled > [Fri Aug 14 16:19:25 2009] [error] SSL Library Error: -12268 Cannot > connect: SSL is disabled > [Fri Aug 14 16:32:39 2009] [error] SSL Library Error: -12268 Cannot > connect: SSL is disabled > [Fri Aug 14 16:35:26 2009] [error] SSL Library Error: -12268 Cannot > connect: SSL is disabled So it seems to me as if during the attempted reenabling of SSL on the Admin Server, something went really wrong. Hence my question: Is it possible to force SSL usage from the Admin Server by command line? I saw http://directory.fedoraproject.org/wiki/Howto:SSL#Starting_the_Server_with_SSL_enabled and hoped that something similar is possible in reverse direction? Is there any way to overcome this problem? It would be most appreciated is a complete reinstallation could be avoided. I was on the way to a full backup (I do have an LDIF export) when I encountered problems and messed up things while trying to get the backup done. Any advice would be highly appreciated! Regards, Wolf PS: Installed versions are: fedora-ds-1.1.2-1.fc6 fedora-idm-console-1.1.1-1.fc6 fedora-ds-dsgw-1.1.1-1.fc6 fedora-ds-admin-console-1.1.2-1.fc6 fedora-ds-base-1.1.3-2.fc6 fedora-ds-console-1.1.2-1.fc6 fedora-ds-admin-1.1.6-1.fc6 From siedler at hrd-asia.com Fri Aug 14 09:08:17 2009 From: siedler at hrd-asia.com (Wolf Siedler) Date: Fri, 14 Aug 2009 16:08:17 +0700 Subject: [389-users] Disable SSL in Administration server from command line? Message-ID: <4A852981.9070408@hrd-asia.com> As a follow-up: The console also doesn't work (same errors) locally on the machine where the directory server is installed. I would also consider most helpful any advice on how to properly enable SSL from command line (again) for the Admin Server. Either way - as long as I can get the console operational again... Many thanks for any advice! Regards, Wolf From jsullivan at opensourcedevel.com Fri Aug 14 12:20:34 2009 From: jsullivan at opensourcedevel.com (John A. Sullivan III) Date: Fri, 14 Aug 2009 08:20:34 -0400 Subject: [389-users] Disable SSL in Administration server from command line? In-Reply-To: <4A852531.1040804@hrd-asia.com> References: <4A852531.1040804@hrd-asia.com> Message-ID: <1250252434.6595.4.camel@jaspav.missionsit.net.missionsit.net> On Fri, 2009-08-14 at 15:49 +0700, Wolf Siedler wrote: > Hi, > > I probably caused a major hiccup in my system - I can't log onto anymore > by the Java console to the Administration Server. Unfortunately, my > direcory server knowledge is not yet very deep so I got lost now. > > Last action I had done before that the attempted removal of SSL > encryption from the Administration Server. > Originally, I had connected with SSL encryption to the Admin Server. > I then went to Configuration - Encryption, unchecked "Enable SSL for > this server" saved everything and restarted dirsrv-admin on the command > line. > The outcome was as desired: Originally I connected the console by > "https://admin.example.com:20126". After this change, connecting via > "http://admin.example.com":20126" worked. In both cases, I connected > from a remote PC. > > But then I goofed by rechecking "Enable SSL for this server" and saving > the settings (nothing else was changed, in particular not the previously > working certificate settings). After I few distractions I had forgotten > about this and restarted the dirsrv-admin. > > Since then I can't log on via fedora-idm-console anymore. Neither > "https://admin.example.com:20126" nor "http://admin.example.com":20126" > works anymore. > > For https://admin.example.com:20216, I get the error: > Cannot connect to the Admin Server "https://admin.example.com:20126" > The URL is not correct or the server is not working. > > For http://admin.example.com:20216, I get this error: > Cannot log on because of an incorrect User ID, Incorrect password or > Directory problem. > java.io.EOFException: Connection lost > > OK, the second failure I expected, but not the first one. > I ca not believe that it is a typing error in URL, user name or password > as all this information comes from a script and except for https/http, > there were no modifications at all to this script. > > For both attempts, /var/log/dirsrv/admin-serv/error shows > > [Fri Aug 14 16:19:05 2009] [error] SSL Library Error: -12268 Cannot > > connect: SSL is disabled > > [Fri Aug 14 16:19:25 2009] [error] SSL Library Error: -12268 Cannot > > connect: SSL is disabled > > [Fri Aug 14 16:32:39 2009] [error] SSL Library Error: -12268 Cannot > > connect: SSL is disabled > > [Fri Aug 14 16:35:26 2009] [error] SSL Library Error: -12268 Cannot > > connect: SSL is disabled > So it seems to me as if during the attempted reenabling of SSL on the > Admin Server, something went really wrong. > > Hence my question: > Is it possible to force SSL usage from the Admin Server by command line? > > I saw > http://directory.fedoraproject.org/wiki/Howto:SSL#Starting_the_Server_with_SSL_enabled > and hoped that something similar is possible in reverse direction? > > Is there any way to overcome this problem? It would be most appreciated > is a complete reinstallation could be avoided. I was on the way to a > full backup (I do have an LDIF export) when I encountered problems and > messed up things while trying to get the backup done. Quick dislcaimer - I haven't read this carefully because I am literally racing out the door and will be gone most of the day but I understand this pain because I have been here before. I don't know if this applies but, when we needed to manually disable SSL for similar reasons, this is how we did it. From our internal documentation and very quickly cleansed of sensitive data (so some of it might be mangled!): This next procedure is to disable HTTPS access in case something goes wrong with it and one is unable to connect to the administration console. This shows the admin config and the security setting: ./ldapsearch -x -b o=netscaperoot -D "cn=Directory Manager" -w - -h 172.c.c.48 "objectclass=nsAdminConfig" dn: cn=configuration,cn=admin-serv-ldap,cn=CentOS Administration Server,cn=S erver Group,cn=ldap.mycompany.biz,ou=mycompany.biz,o=NetscapeRoot nsServerPort: 9830 objectClass: nsConfig objectClass: nsAdminConfig objectClass: nsAdminObject objectClass: nsDirectoryInfo objectClass: top nsClassname: com.netscape.management.admserv.AdminServer at centos-admin-8.0.jar@ cn=admin-serv-ldap, cn=CentOS Administration Server, cn=Server Group, cn=l dap.mycompany.biz, ou=mycompany.biz, o=NetscapeRoot cn: Configuration nsDirectoryInfoRef: cn=Server Group, cn=ldap.mycompany.biz, ou=mycompany .biz, o=NetscapeRoot nsAdminAccessAddresses: * nsSuiteSpotUser: ldap nsAdminEnableDSGW: on nsAdminAccessHosts: *.mycompany.biz nsAdminCacheLifetime: 600 nsDefaultAcceptLanguage: en nsServerAddress: nsAdminOneACLDir: adminacl nsErrorLog: /var/log/dirsrv/admin-serv/error nsAdminUsers: /etc/dirsrv/admin-serv/admpw nsPidLog: admin-serv.pid nsAccessLog: /var/log/dirsrv/admin-serv/access nsAdminEnableEnduser: on nsServerSecurity: on We disable the SSL security with the following modifications: [root at ldap01 mozldap]# ./ldapmodify -D "cn=Directory Manager" -w - -h 172.c.c.48 Enter bind password: dn: cn=configuration,cn=admin-serv-ldap,cn=CentOS Administration Server,cn=Server Group,cn=ldap.mycompany.biz,ou=mycompany.biz,o=NetscapeRoot changetype: modify replace: nsServerSecurity nsServerSecurity: off dn: cn=configuration,cn=admin-serv-ldap,cn=CentOS Administration Server,cn=Server Group,cn=ldap.mycompany.biz,ou=mycompany.biz,o=NetscapeRoot changetype: modify replace: nsServerAddress nsServerAddress: 172.c.c.48 twice to exit Sorry I can't be more helpful. Hope this helps - John -- John A. Sullivan III Open Source Development Corporation Street Preacher: Are you SAVED?????!!!!!! Educated Skeptic: Saved from WHAT?????!!!!!! Educated Believer: From our selfishness that hurts the ones we love and condemns us to an eternity of hurting each other. http://www.spiritualoutreach.com Christianity that makes sense From rmeggins at redhat.com Fri Aug 14 14:16:00 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 14 Aug 2009 08:16:00 -0600 Subject: [389-users] nsDirectoryServerTask objectClass In-Reply-To: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> References: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> Message-ID: <4A8571A0.3010000@redhat.com> Juan Asensio S?nchez wrote: > Hi > > I am trying to create a task to update the index database, according > to the instructions described here: > > - http://www.redhat.com/docs/manuals/dir-server/8.1/admin/applying-indexes.html > - http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP_Design > > But when I create the task from a Perl script, i get an error about > unknown object class: > > my $entry = Net::LDAP::Entry->new(); > $tmp_index_name = 'cn'; > my $cn = "$tmp_index_name index task"; > $entry->dn("cn=$cn, cn=index, cn=tasks, cn=config"); > $entry->add('objectClass' => ['nsDirectoryServerTask']); > $entry->add('cn' => $cn); > $entry->add('nsindexattribute' => "\"eq:pres\""); > my $res = $entry->update($ldap_conn); > > The error is 'unknown object class "nsDirectoryServerTask"'. Where is > that objectClass defined? > It is not defined. The documentation is wrong. Just use extensibleObject as the objectclass. For more information and examples, see the various perl scripts created for each instance in /usr/lib/dirsrv/slapd-instance - db2ldif.pl, ldif2db.pl, db2index.pl, etc. And please file a bug to correct that documentation. > # rpm -qa | grep -i fedora > fedora-ds-admin-1.1.1-1.fc6 > fedora-ds-1.1.0-3.fc6 > fedora-ds-base-1.1.0-3.fc6 > fedora-admin-console-1.1.0-4.fc6 > fedora-idm-console-1.1.0-5.fc6 > fedora-ds-console-1.1.0-5.fc6 > # uname -a > Linux grsgscbulp0301.sacyl.es 2.6.18-128.1.10.el5.centos.plusPAE #1 > SMP Mon May 11 07:51:33 EDT 2009 i686 i686 i386 GNU/Linux > > Regards and thanks in advance. > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From amessina at messinet.com Sat Aug 15 18:37:18 2009 From: amessina at messinet.com (Anthony Messina) Date: Sat, 15 Aug 2009 13:37:18 -0500 Subject: [389-users] Console error after upgrading to renamed389 packages Message-ID: <200908151337.18351.amessina@messinet.com> When I attempt to connect using the 389-console, I get the following errors in the admin-serv/errors log as if the 389-console is still looking for the wrong files: [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not exist: /usr/share/dirsrv/html/java/jars [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not exist: /usr/share/dirsrv/html/java/fedora-admin-1.1.jar [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not exist: /usr/share/dirsrv/html/fedora-admin-1.1.jar Is anyone else having this problem? Any ideas on how to fix it? -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From msauton at redhat.com Sat Aug 15 18:59:21 2009 From: msauton at redhat.com (Marc Sauton) Date: Sat, 15 Aug 2009 11:59:21 -0700 Subject: [389-users] Console error after upgrading to renamed389 packages In-Reply-To: <200908151337.18351.amessina@messinet.com> References: <200908151337.18351.amessina@messinet.com> Message-ID: <4A870589.4050005@redhat.com> On 08/15/2009 11:37 AM, Anthony Messina wrote: > When I attempt to connect using the 389-console, I get the following errors in > the admin-serv/errors log as if the 389-console is still looking for the wrong > files: > > [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not exist: > /usr/share/dirsrv/html/java/jars > [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not exist: > /usr/share/dirsrv/html/java/fedora-admin-1.1.jar > [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not exist: > /usr/share/dirsrv/html/fedora-admin-1.1.jar > > Is anyone else having this problem? Any ideas on how to fix it? > > See /usr/share/dirsrv/html/java/ contains and what version of console is used. M. > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From zreoxx at gmail.com Sat Aug 15 19:28:56 2009 From: zreoxx at gmail.com (Andreas Andersson) Date: Sat, 15 Aug 2009 21:28:56 +0200 Subject: [389-users] LDAP Monitoring CN=Monitor Message-ID: <95F1C884-CCA1-46DC-BFB5-F4DDAD57445B@gmail.com> Hi! My name is Andreas and I want to inform you about a little project I've been working with the last couple of months called CN=Monitor. It's about monitoring and verifiying directory servers with focus on 389/RHDS. From single installed servers to large scaled deployments. Its a webbased application where you can: * Verify availability, compare load and performance between servers * Collect historical events for long term analysis (and get weekly reports by mail) * Verify cluster and load balancing functionality * Query several directories at the same time for data consistancy verification ... and a lot more. Project page: http://cnmonitor.sourceforge.net Freshmeat: http://freshmeat.net/projects/cnmonitor Tell me what you think! I'm right now working on version 1.1 so if you have any feature requests let me know! Best regards - Andreas Andersson From amessina at messinet.com Sat Aug 15 21:31:51 2009 From: amessina at messinet.com (Anthony Messina) Date: Sat, 15 Aug 2009 16:31:51 -0500 Subject: [389-users] Console error after upgrading to renamed389 packages In-Reply-To: <4A870589.4050005@redhat.com> References: <200908151337.18351.amessina@messinet.com> <4A870589.4050005@redhat.com> Message-ID: <200908151631.55318.amessina@messinet.com> On Saturday 15 August 2009 01:59:21 pm Marc Sauton wrote: > On 08/15/2009 11:37 AM, Anthony Messina wrote: > > When I attempt to connect using the 389-console, I get the following > > errors in the admin-serv/errors log as if the 389-console is still > > looking for the wrong files: > > > > [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not > > exist: /usr/share/dirsrv/html/java/jars > > [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not > > exist: /usr/share/dirsrv/html/java/fedora-admin-1.1.jar > > [Sat Aug 15 12:54:49 2009] [error] [client 192.168.1.11] File does not > > exist: /usr/share/dirsrv/html/fedora-admin-1.1.jar > > > > Is anyone else having this problem? Any ideas on how to fix it? > > > > > > See /usr/share/dirsrv/html/java/ contains and what version of console is > used. rpm -q --filesbypkg 389-admin-console-1.1.4-1.fc11.noarch 389-admin-console /usr/share/dirsrv/html/java/389-admin-1.1.4.jar 389-admin-console /usr/share/dirsrv/html/java/389-admin-1.1.4_en.jar 389-admin-console /usr/share/dirsrv/html/java/389-admin-1.1.jar 389-admin-console /usr/share/dirsrv/html/java/389-admin-1.1_en.jar 389-admin-console /usr/share/dirsrv/html/java/389-admin.jar 389-admin-console /usr/share/dirsrv/html/java/389-admin_en.jar 389-admin-console /usr/share/doc/389-admin-console-1.1.4 389-admin-console /usr/share/doc/389-admin-console-1.1.4/LICENSE they are all there! but the 389-console binary still seems to be looking for the fedora-admin-*-jar files -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From amessina at messinet.com Sat Aug 15 21:42:52 2009 From: amessina at messinet.com (Anthony Messina) Date: Sat, 15 Aug 2009 16:42:52 -0500 Subject: [389-users] Console error after upgrading to renamed389 packages In-Reply-To: <200908151631.55318.amessina@messinet.com> References: <200908151337.18351.amessina@messinet.com> <4A870589.4050005@redhat.com> <200908151631.55318.amessina@messinet.com> Message-ID: <200908151642.52605.amessina@messinet.com> On Saturday 15 August 2009 04:31:51 pm Anthony Messina wrote: > > See /usr/share/dirsrv/html/java/ contains and what version of console is > > used. sorry, i forgot the versions... 389-admin-1.1.8-3.fc11.x86_64 389-admin-console-1.1.4-1.fc11.noarch 389-admin-console-doc-1.1.4-1.fc11.noarch 389-adminutil-1.1.8-3.fc11.x86_64 389-console-1.1.3-3.fc11.noarch 389-ds-1.1.3-4.fc11.noarch 389-ds-base-1.2.1-1.fc11.x86_64 389-ds-console-1.2.0-4.fc11.noarch 389-ds-console-doc-1.2.0-4.fc11.noarch 389-dsgw-1.1.4-1.fc11.x86_64 idm-console-framework-1.1.3-1.fc11.noarch -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From amessina at messinet.com Sun Aug 16 22:51:35 2009 From: amessina at messinet.com (Anthony Messina) Date: Sun, 16 Aug 2009 17:51:35 -0500 Subject: [SEMI-SOLVED]: Re: [389-users] Console error after upgrading to renamed389 packages In-Reply-To: <200908151642.52605.amessina@messinet.com> References: <200908151337.18351.amessina@messinet.com> <200908151631.55318.amessina@messinet.com> <200908151642.52605.amessina@messinet.com> Message-ID: <200908161751.39288.amessina@messinet.com> On Saturday 15 August 2009 04:42:52 pm Anthony Messina wrote: > On Saturday 15 August 2009 04:31:51 pm Anthony Messina wrote: > > > See /usr/share/dirsrv/html/java/ contains and what version of console > > > is used. > > sorry, i forgot the versions... > 389-admin-1.1.8-3.fc11.x86_64 > 389-admin-console-1.1.4-1.fc11.noarch > 389-admin-console-doc-1.1.4-1.fc11.noarch > 389-adminutil-1.1.8-3.fc11.x86_64 > 389-console-1.1.3-3.fc11.noarch > 389-ds-1.1.3-4.fc11.noarch > 389-ds-base-1.2.1-1.fc11.x86_64 > 389-ds-console-1.2.0-4.fc11.noarch > 389-ds-console-doc-1.2.0-4.fc11.noarch > 389-dsgw-1.1.4-1.fc11.x86_64 > > idm-console-framework-1.1.3-1.fc11.noarch I have reinstalled 389 DS on my master and slaver servers, from scratch and do not experience any issues. Unfortunately, I'm not so sure about what setup- ds-admin.pl -u should be doing, as it did not properly update eithe rof my machines and it left the old instances of fedor-ds in the console. -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From okelet at gmail.com Mon Aug 17 07:59:07 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Mon, 17 Aug 2009 09:59:07 +0200 Subject: [389-users] nsDirectoryServerTask objectClass In-Reply-To: <4A8571A0.3010000@redhat.com> References: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> <4A8571A0.3010000@redhat.com> Message-ID: <52a9d2e30908170059u44f94ea1l85be5624cb082fb0@mail.gmail.com> Hi I can't get this to work. Even with the script db2index.pl, i get an error: =============================================================================== [root at server11 slapd-center1]# ./db2index.pl -D "cn=Directory Manager" -w - -v -n center1 -t cn:eq Bind Password: ldapmodify: started Mon Aug 17 11:49:52 2009 ldap_init( server11.center1.xxxxxxxx.local, 389 ) add objectclass: top extensibleObject add cn: db2index_2009_8_17_11_49_52 add nsInstance: center1 add nsIndexAttribute: cn:eq adding new entry cn=db2index_2009_8_17_11_49_52, cn=index, cn=tasks, cn=config ldap_add: No such object =============================================================================== With an LDIF file: =============================================================================== [root at server11 ~]# cat index_cn.ldif dn : cn=cn_index_task, cn=index, cn=tasks, cn=config objectClass: top objectClass: extensibleObject cn: cn_index_task nsIndexAttribute: eq:pres [root at server11 ~]# ldapadd -H ldap://localhost -D "cn=Directory Manager" -W -x -f index_cn.ldif Enter LDAP Password: adding new entry "cn=cn_index_task, cn=index, cn=tasks, cn=config" ldapadd: Object class violation (65) =============================================================================== Any idea? Thanks in advance. 2009/8/14 Rich Megginson : > Juan Asensio S?nchez wrote: >> >> Hi >> >> I am trying to create a task to update the index database, according >> to the instructions described here: >> >> - >> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/applying-indexes.html >> - http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP_Design >> >> But when I create the task from a Perl script, i get an error about >> unknown object class: >> >> my $entry = Net::LDAP::Entry->new(); >> $tmp_index_name = 'cn'; >> my $cn = "$tmp_index_name index task"; >> $entry->dn("cn=$cn, cn=index, cn=tasks, cn=config"); >> $entry->add('objectClass' => ['nsDirectoryServerTask']); >> $entry->add('cn' => $cn); >> $entry->add('nsindexattribute' => "\"eq:pres\""); >> my $res = $entry->update($ldap_conn); >> >> The error is 'unknown object class "nsDirectoryServerTask"'. Where is >> that objectClass defined? >> > > It is not defined. ?The documentation is wrong. ?Just use extensibleObject > as the objectclass. ?For more information and examples, see the various perl > scripts created for each instance in /usr/lib/dirsrv/slapd-instance - > db2ldif.pl, ldif2db.pl, db2index.pl, etc. > > And please file a bug to correct that documentation. >> >> # rpm -qa | grep -i fedora >> fedora-ds-admin-1.1.1-1.fc6 >> fedora-ds-1.1.0-3.fc6 >> fedora-ds-base-1.1.0-3.fc6 >> fedora-admin-console-1.1.0-4.fc6 >> fedora-idm-console-1.1.0-5.fc6 >> fedora-ds-console-1.1.0-5.fc6 >> # uname -a >> Linux grsgscbulp0301.sacyl.es 2.6.18-128.1.10.el5.centos.plusPAE #1 >> SMP Mon May 11 07:51:33 EDT 2009 i686 i686 i386 GNU/Linux >> >> Regards and thanks in advance. >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > From okelet at gmail.com Mon Aug 17 08:00:46 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Mon, 17 Aug 2009 10:00:46 +0200 Subject: [389-users] LDAP Monitoring CN=Monitor In-Reply-To: <95F1C884-CCA1-46DC-BFB5-F4DDAD57445B@gmail.com> References: <95F1C884-CCA1-46DC-BFB5-F4DDAD57445B@gmail.com> Message-ID: <52a9d2e30908170100m54bc259elcc06193eade4006a@mail.gmail.com> Hi We are using this tool. Although there are some issues, this is great. Where can we send you some bugs and/or suggestions? Regards. 2009/8/15 Andreas Andersson : > Hi! > > My name is Andreas and I want to inform you about a little project I've been > working with the last couple of months called CN=Monitor. > It's about monitoring and verifiying directory servers with focus on > 389/RHDS. From single installed servers to large scaled deployments. > > Its a webbased application where you can: > * Verify availability, compare load and performance between servers > * Collect historical events for long term analysis (and get weekly reports > by mail) > * Verify cluster and load balancing functionality > * Query several directories at the same time for data consistancy > verification > ... and a lot more. > > Project page: > http://cnmonitor.sourceforge.net > > Freshmeat: > http://freshmeat.net/projects/cnmonitor > > Tell me what you think! I'm right now working on version 1.1 so if you have > any feature requests let me know! > > Best regards - Andreas Andersson > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > From amessina at messinet.com Sun Aug 16 01:54:12 2009 From: amessina at messinet.com (Anthony Messina) Date: Sat, 15 Aug 2009 20:54:12 -0500 Subject: [389-users] Post upgrade to 389-ds* from fedora-ds* Message-ID: <200908152054.16593.amessina@messinet.com> The upgrade has beem quite rough as seen by my previous email today. I am now able to use the 389-console to access my upgraded 389ds server and admin server. Most of the issues seem to relate to the fact that I had SSL enabled on my admin server which is a problem if you attempt to upgrade via the instructions here: http://www.redhat.com/docs/manuals/dir-server/8.1/install/upgrade.html the setup-ds-admin.pl -u command wants you to enter a new CA cert, even though I already had one in there. Also, once I finally got around that, I now am not able to use the "Manage Certificates" task/utility as it appears that I don't have the netscape pkcs#11 internal security module installed, though I can access the server just fine with TLS/SSL. I also cannot configure the admin server via the console with a message: "no protocol: asmin-serv/tasks/Configuration/ServerSetup" See the attached screenshots. Any help is appreciated. I had done a lot of reading about updating before I did this and it turned out to be a disaster anyway. -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: 389ds.png Type: image/png Size: 85483 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 389ds-admin.png Type: image/png Size: 72670 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From psundaram at wgen.net Mon Aug 17 14:37:28 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Mon, 17 Aug 2009 10:37:28 -0400 Subject: [389-users] SSH config with FDS Message-ID: All, I am having trouble configured SSH access using FDS. I am trying to configure using the host attribute in the directory schema to verify the accesss. I enabled pam_check_host_attr, pam_lookup_policy, pam_login_attribute=uid, pam_password_clear_remove_old and respective uri in ldap.conf. Please note I have not enabled ssl in my DS, I am trying to do this one-step at a time. Is there any extra parameters need to be configured? Since my db is imported from openldap and AD, I have stripped it to basic schema and here it is. Just to see if this has to do anything. dn: uid=username,ou=People,dc=fedorads,dc=net cn: Firstname Lastname gecos: Firstname Lastname gidNumber: 2005 homeDirectory: /home/username loginShell: /bin/bash objectClass: top objectClass: account objectClass: posixAccount uid: amolinaro uidNumber: 2105 userPassword: {MD5}/42DQx3FHKdMlGHAspWv1lFg -------------- next part -------------- An HTML attachment was scrubbed... URL: From zreoxx at gmail.com Mon Aug 17 17:25:38 2009 From: zreoxx at gmail.com (Andreas Andersson) Date: Mon, 17 Aug 2009 19:25:38 +0200 Subject: [389-users] LDAP Monitoring CN=Monitor In-Reply-To: <52a9d2e30908170100m54bc259elcc06193eade4006a@mail.gmail.com> References: <95F1C884-CCA1-46DC-BFB5-F4DDAD57445B@gmail.com> <52a9d2e30908170100m54bc259elcc06193eade4006a@mail.gmail.com> Message-ID: <86A114F0-1F5C-46D1-9873-F057C995C92D@gmail.com> Hi Asensio! The best way to report bugs and request features is sending an email to monitorldap at gmail.com. You can also use my zreoxx at gmail.com address. I will work on adding an open bugtracker. Regards Andreas On Aug 17, 2009, at 10:00, Juan Asensio S?nchez wrote: > Hi > > We are using this tool. Although there are some issues, this is great. > Where can we send you some bugs and/or suggestions? > > Regards. > > > 2009/8/15 Andreas Andersson : >> Hi! >> >> My name is Andreas and I want to inform you about a little project >> I've been >> working with the last couple of months called CN=Monitor. >> It's about monitoring and verifiying directory servers with focus on >> 389/RHDS. From single installed servers to large scaled deployments. >> >> Its a webbased application where you can: >> * Verify availability, compare load and performance between servers >> * Collect historical events for long term analysis (and get weekly >> reports >> by mail) >> * Verify cluster and load balancing functionality >> * Query several directories at the same time for data consistancy >> verification >> ... and a lot more. >> >> Project page: >> http://cnmonitor.sourceforge.net >> >> Freshmeat: >> http://freshmeat.net/projects/cnmonitor >> >> Tell me what you think! I'm right now working on version 1.1 so if >> you have >> any feature requests let me know! >> >> Best regards - Andreas Andersson >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users From zreoxx at gmail.com Mon Aug 17 17:25:38 2009 From: zreoxx at gmail.com (Andreas Andersson) Date: Mon, 17 Aug 2009 19:25:38 +0200 Subject: [389-users] LDAP Monitoring CN=Monitor In-Reply-To: <52a9d2e30908170100m54bc259elcc06193eade4006a@mail.gmail.com> References: <95F1C884-CCA1-46DC-BFB5-F4DDAD57445B@gmail.com> <52a9d2e30908170100m54bc259elcc06193eade4006a@mail.gmail.com> Message-ID: <86A114F0-1F5C-46D1-9873-F057C995C92D@gmail.com> Hi Asensio! The best way to report bugs and request features is sending an email to monitorldap at gmail.com. You can also use my zreoxx at gmail.com address. I will work on adding an open bugtracker. Regards Andreas On Aug 17, 2009, at 10:00, Juan Asensio S?nchez wrote: > Hi > > We are using this tool. Although there are some issues, this is great. > Where can we send you some bugs and/or suggestions? > > Regards. > > > 2009/8/15 Andreas Andersson : >> Hi! >> >> My name is Andreas and I want to inform you about a little project >> I've been >> working with the last couple of months called CN=Monitor. >> It's about monitoring and verifiying directory servers with focus on >> 389/RHDS. From single installed servers to large scaled deployments. >> >> Its a webbased application where you can: >> * Verify availability, compare load and performance between servers >> * Collect historical events for long term analysis (and get weekly >> reports >> by mail) >> * Verify cluster and load balancing functionality >> * Query several directories at the same time for data consistancy >> verification >> ... and a lot more. >> >> Project page: >> http://cnmonitor.sourceforge.net >> >> Freshmeat: >> http://freshmeat.net/projects/cnmonitor >> >> Tell me what you think! I'm right now working on version 1.1 so if >> you have >> any feature requests let me know! >> >> Best regards - Andreas Andersson >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users From rmeggins at redhat.com Mon Aug 17 17:41:28 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 17 Aug 2009 11:41:28 -0600 Subject: [389-users] nsDirectoryServerTask objectClass In-Reply-To: <52a9d2e30908170059u44f94ea1l85be5624cb082fb0@mail.gmail.com> References: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> <4A8571A0.3010000@redhat.com> <52a9d2e30908170059u44f94ea1l85be5624cb082fb0@mail.gmail.com> Message-ID: <4A899648.1080405@redhat.com> Juan Asensio S?nchez wrote: > Hi > > I can't get this to work. Even with the script db2index.pl, i get an error: > > =============================================================================== > [root at server11 slapd-center1]# ./db2index.pl -D "cn=Directory > Manager" -w - -v -n center1 -t cn:eq > Bind Password: > > ldapmodify: started Mon Aug 17 11:49:52 2009 > > ldap_init( server11.center1.xxxxxxxx.local, 389 ) > add objectclass: > top > extensibleObject > add cn: > db2index_2009_8_17_11_49_52 > add nsInstance: > center1 > add nsIndexAttribute: > cn:eq > adding new entry cn=db2index_2009_8_17_11_49_52, cn=index, cn=tasks, cn=config > ldap_add: No such object > look in /var/log/dirsrv/slapd-instance/access - find the ADD operation corresponding to this - which > =============================================================================== > > > With an LDIF file: > > =============================================================================== > [root at server11 ~]# cat index_cn.ldif > dn : cn=cn_index_task, cn=index, cn=tasks, cn=config > objectClass: top > objectClass: extensibleObject > cn: cn_index_task > nsIndexAttribute: eq:pres > [root at server11 ~]# ldapadd -H ldap://localhost -D "cn=Directory > Manager" -W -x -f index_cn.ldif > Enter LDAP Password: > adding new entry "cn=cn_index_task, cn=index, cn=tasks, cn=config" > ldapadd: Object class violation (65) > You are missing nsInstance: center1 > =============================================================================== > > Any idea? > > Thanks in advance. > > > 2009/8/14 Rich Megginson : > >> Juan Asensio S?nchez wrote: >> >>> Hi >>> >>> I am trying to create a task to update the index database, according >>> to the instructions described here: >>> >>> - >>> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/applying-indexes.html >>> - http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP_Design >>> >>> But when I create the task from a Perl script, i get an error about >>> unknown object class: >>> >>> my $entry = Net::LDAP::Entry->new(); >>> $tmp_index_name = 'cn'; >>> my $cn = "$tmp_index_name index task"; >>> $entry->dn("cn=$cn, cn=index, cn=tasks, cn=config"); >>> $entry->add('objectClass' => ['nsDirectoryServerTask']); >>> $entry->add('cn' => $cn); >>> $entry->add('nsindexattribute' => "\"eq:pres\""); >>> my $res = $entry->update($ldap_conn); >>> >>> The error is 'unknown object class "nsDirectoryServerTask"'. Where is >>> that objectClass defined? >>> >>> >> It is not defined. The documentation is wrong. Just use extensibleObject >> as the objectclass. For more information and examples, see the various perl >> scripts created for each instance in /usr/lib/dirsrv/slapd-instance - >> db2ldif.pl, ldif2db.pl, db2index.pl, etc. >> >> And please file a bug to correct that documentation. >> >>> # rpm -qa | grep -i fedora >>> fedora-ds-admin-1.1.1-1.fc6 >>> fedora-ds-1.1.0-3.fc6 >>> fedora-ds-base-1.1.0-3.fc6 >>> fedora-admin-console-1.1.0-4.fc6 >>> fedora-idm-console-1.1.0-5.fc6 >>> fedora-ds-console-1.1.0-5.fc6 >>> # uname -a >>> Linux grsgscbulp0301.sacyl.es 2.6.18-128.1.10.el5.centos.plusPAE #1 >>> SMP Mon May 11 07:51:33 EDT 2009 i686 i686 i386 GNU/Linux >>> >>> Regards and thanks in advance. >>> >>> -- >>> 389 users mailing list >>> 389-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Aug 17 17:41:48 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 17 Aug 2009 11:41:48 -0600 Subject: [389-users] nsDirectoryServerTask objectClass In-Reply-To: <52a9d2e30908170059u44f94ea1l85be5624cb082fb0@mail.gmail.com> References: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> <4A8571A0.3010000@redhat.com> <52a9d2e30908170059u44f94ea1l85be5624cb082fb0@mail.gmail.com> Message-ID: <4A89965C.1080203@redhat.com> Juan Asensio S?nchez wrote: > Hi > > I can't get this to work. Even with the script db2index.pl, i get an error: > > =============================================================================== > [root at server11 slapd-center1]# ./db2index.pl -D "cn=Directory > Manager" -w - -v -n center1 -t cn:eq > Bind Password: > > ldapmodify: started Mon Aug 17 11:49:52 2009 > > ldap_init( server11.center1.xxxxxxxx.local, 389 ) > add objectclass: > top > extensibleObject > add cn: > db2index_2009_8_17_11_49_52 > add nsInstance: > center1 > add nsIndexAttribute: > cn:eq > adding new entry cn=db2index_2009_8_17_11_49_52, cn=index, cn=tasks, cn=config > ldap_add: No such object > look in /var/log/dirsrv/slapd-instance/access - find the ADD operation corresponding to this - which entry does it complain about? > =============================================================================== > > > With an LDIF file: > > =============================================================================== > [root at server11 ~]# cat index_cn.ldif > dn : cn=cn_index_task, cn=index, cn=tasks, cn=config > objectClass: top > objectClass: extensibleObject > cn: cn_index_task > nsIndexAttribute: eq:pres > [root at server11 ~]# ldapadd -H ldap://localhost -D "cn=Directory > Manager" -W -x -f index_cn.ldif > Enter LDAP Password: > adding new entry "cn=cn_index_task, cn=index, cn=tasks, cn=config" > ldapadd: Object class violation (65) > You are missing nsInstance: center1 > =============================================================================== > > Any idea? > > Thanks in advance. > > > 2009/8/14 Rich Megginson : > >> Juan Asensio S?nchez wrote: >> >>> Hi >>> >>> I am trying to create a task to update the index database, according >>> to the instructions described here: >>> >>> - >>> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/applying-indexes.html >>> - http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP_Design >>> >>> But when I create the task from a Perl script, i get an error about >>> unknown object class: >>> >>> my $entry = Net::LDAP::Entry->new(); >>> $tmp_index_name = 'cn'; >>> my $cn = "$tmp_index_name index task"; >>> $entry->dn("cn=$cn, cn=index, cn=tasks, cn=config"); >>> $entry->add('objectClass' => ['nsDirectoryServerTask']); >>> $entry->add('cn' => $cn); >>> $entry->add('nsindexattribute' => "\"eq:pres\""); >>> my $res = $entry->update($ldap_conn); >>> >>> The error is 'unknown object class "nsDirectoryServerTask"'. Where is >>> that objectClass defined? >>> >>> >> It is not defined. The documentation is wrong. Just use extensibleObject >> as the objectclass. For more information and examples, see the various perl >> scripts created for each instance in /usr/lib/dirsrv/slapd-instance - >> db2ldif.pl, ldif2db.pl, db2index.pl, etc. >> >> And please file a bug to correct that documentation. >> >>> # rpm -qa | grep -i fedora >>> fedora-ds-admin-1.1.1-1.fc6 >>> fedora-ds-1.1.0-3.fc6 >>> fedora-ds-base-1.1.0-3.fc6 >>> fedora-admin-console-1.1.0-4.fc6 >>> fedora-idm-console-1.1.0-5.fc6 >>> fedora-ds-console-1.1.0-5.fc6 >>> # uname -a >>> Linux grsgscbulp0301.sacyl.es 2.6.18-128.1.10.el5.centos.plusPAE #1 >>> SMP Mon May 11 07:51:33 EDT 2009 i686 i686 i386 GNU/Linux >>> >>> Regards and thanks in advance. >>> >>> -- >>> 389 users mailing list >>> 389-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Mon Aug 17 17:42:34 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 17 Aug 2009 11:42:34 -0600 Subject: [SEMI-SOLVED]: Re: [389-users] Console error after upgrading to renamed389 packages In-Reply-To: <200908161751.39288.amessina@messinet.com> References: <200908151337.18351.amessina@messinet.com> <200908151631.55318.amessina@messinet.com> <200908151642.52605.amessina@messinet.com> <200908161751.39288.amessina@messinet.com> Message-ID: <4A89968A.5060407@redhat.com> Anthony Messina wrote: > On Saturday 15 August 2009 04:42:52 pm Anthony Messina wrote: > >> On Saturday 15 August 2009 04:31:51 pm Anthony Messina wrote: >> >>>> See /usr/share/dirsrv/html/java/ contains and what version of console >>>> is used. >>>> >> sorry, i forgot the versions... >> 389-admin-1.1.8-3.fc11.x86_64 >> 389-admin-console-1.1.4-1.fc11.noarch >> 389-admin-console-doc-1.1.4-1.fc11.noarch >> 389-adminutil-1.1.8-3.fc11.x86_64 >> 389-console-1.1.3-3.fc11.noarch >> 389-ds-1.1.3-4.fc11.noarch >> 389-ds-base-1.2.1-1.fc11.x86_64 >> 389-ds-console-1.2.0-4.fc11.noarch >> 389-ds-console-doc-1.2.0-4.fc11.noarch >> 389-dsgw-1.1.4-1.fc11.x86_64 >> >> idm-console-framework-1.1.3-1.fc11.noarch >> > > I have reinstalled 389 DS on my master and slaver servers, from scratch and do > not experience any issues. Unfortunately, I'm not so sure about what setup- > ds-admin.pl -u should be doing, as it did not properly update eithe rof my > machines and it left the old instances of fedor-ds in the console. > There is a bug in setup-ds-admin.pl -u - it does not delete the old fedora ds instances when upgrading to 389. You can ignore those old instances. > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rafiee.nima at gmail.com Tue Aug 18 07:09:43 2009 From: rafiee.nima at gmail.com (nima rafiee) Date: Tue, 18 Aug 2009 11:39:43 +0430 Subject: [389-users] my email Message-ID: <34b295dc0908180009o41faaefawc7149c17b12c13c@mail.gmail.com> rafiee.nima at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafiee.nima at gmail.com Tue Aug 18 07:15:55 2009 From: rafiee.nima at gmail.com (nima rafiee) Date: Tue, 18 Aug 2009 11:45:55 +0430 Subject: [389-users] question Message-ID: <34b295dc0908180015if189866v387c8e0a7f3e3d06@mail.gmail.com> hi I installed fedra-directory server . It worked till I install perl -ol-schema.pl and aldo stupssh.12 to use samba but after I did I couldnt login to fedora-ds console the error is bad : usr and password for directory manager of directoy problem but Im sure that my userid is cn=directory manger and my pass is correct too what should i do I dont know this erro is because of those file that i installed or somthing else -------------- next part -------------- An HTML attachment was scrubbed... URL: From okelet at gmail.com Tue Aug 18 10:42:18 2009 From: okelet at gmail.com (=?UTF-8?Q?Juan_Asensio_S=C3=A1nchez?=) Date: Tue, 18 Aug 2009 12:42:18 +0200 Subject: [389-users] nsDirectoryServerTask objectClass In-Reply-To: <4A89965C.1080203@redhat.com> References: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> <4A8571A0.3010000@redhat.com> <52a9d2e30908170059u44f94ea1l85be5624cb082fb0@mail.gmail.com> <4A89965C.1080203@redhat.com> Message-ID: <52a9d2e30908180342p704b39eet16b9bd3bd6f682b5@mail.gmail.com> Well I have found the errors. When I execute the script db2index.pl, i was using the server instance instead the database instance for the -n parameter.With the LDAP file i forgot to include the nsInstance attribue, as Rich said. Now the tasks for reindexing are created OK, but i use a script that creates lots of tasks to update the indexes of the database, so the first task for the database runs ok, but the others don't run because of this error. The attributes of the tasks are for nstasklog and nstaskstatus "Index failed (error -1)", and in the error log i get "ldbm: 'userRoot' is already in the middle of another task and cannot be disturbed.". Is there any way to run the tasks in order, starting one when other finishes? Regards. 2009/8/17 Rich Megginson : > Juan Asensio S?nchez wrote: >> >> Hi >> >> I can't get this to work. Even with the script db2index.pl, i get an >> error: >> >> >> =============================================================================== >> [root at server11 slapd-center1]# ./db2index.pl ?-D "cn=Directory >> Manager" -w - -v -n center1 -t cn:eq >> Bind Password: >> >> ldapmodify: started Mon Aug 17 11:49:52 2009 >> >> ldap_init( server11.center1.xxxxxxxx.local, 389 ) >> add objectclass: >> ? ? ? ?top >> ? ? ? ?extensibleObject >> add cn: >> ? ? ? ?db2index_2009_8_17_11_49_52 >> add nsInstance: >> ? ? ? ?center1 >> add nsIndexAttribute: >> ? ? ? ?cn:eq >> adding new entry cn=db2index_2009_8_17_11_49_52, cn=index, cn=tasks, >> cn=config >> ldap_add: No such object >> > > look in /var/log/dirsrv/slapd-instance/access - find the ADD operation > corresponding to this - which entry does it complain about? >> >> >> =============================================================================== >> >> >> With an LDIF file: >> >> >> =============================================================================== >> [root at server11 ~]# cat index_cn.ldif >> dn : cn=cn_index_task, cn=index, cn=tasks, cn=config >> objectClass: top >> objectClass: extensibleObject >> cn: cn_index_task >> nsIndexAttribute: eq:pres >> [root at server11 ~]# ldapadd -H ldap://localhost -D "cn=Directory >> Manager" -W -x -f index_cn.ldif >> Enter LDAP Password: >> adding new entry "cn=cn_index_task, cn=index, cn=tasks, cn=config" >> ldapadd: Object class violation (65) >> > > You are missing > nsInstance: center1 >> >> >> =============================================================================== >> >> Any idea? >> >> Thanks in advance. >> >> >> 2009/8/14 Rich Megginson : >> >>> >>> Juan Asensio S?nchez wrote: >>> >>>> >>>> Hi >>>> >>>> I am trying to create a task to update the index database, according >>>> to the instructions described here: >>>> >>>> - >>>> >>>> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/applying-indexes.html >>>> - >>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP_Design >>>> >>>> But when I create the task from a Perl script, i get an error about >>>> unknown object class: >>>> >>>> my $entry = Net::LDAP::Entry->new(); >>>> $tmp_index_name = 'cn'; >>>> my $cn = "$tmp_index_name index task"; >>>> $entry->dn("cn=$cn, cn=index, cn=tasks, cn=config"); >>>> $entry->add('objectClass' => ['nsDirectoryServerTask']); >>>> $entry->add('cn' => $cn); >>>> $entry->add('nsindexattribute' => "\"eq:pres\""); >>>> my $res = $entry->update($ldap_conn); >>>> >>>> The error is 'unknown object class "nsDirectoryServerTask"'. Where is >>>> that objectClass defined? >>>> >>>> >>> >>> It is not defined. ?The documentation is wrong. ?Just use >>> extensibleObject >>> as the objectclass. ?For more information and examples, see the various >>> perl >>> scripts created for each instance in /usr/lib/dirsrv/slapd-instance - >>> db2ldif.pl, ldif2db.pl, db2index.pl, etc. >>> >>> And please file a bug to correct that documentation. >>> >>>> >>>> # rpm -qa | grep -i fedora >>>> fedora-ds-admin-1.1.1-1.fc6 >>>> fedora-ds-1.1.0-3.fc6 >>>> fedora-ds-base-1.1.0-3.fc6 >>>> fedora-admin-console-1.1.0-4.fc6 >>>> fedora-idm-console-1.1.0-5.fc6 >>>> fedora-ds-console-1.1.0-5.fc6 >>>> # uname -a >>>> Linux grsgscbulp0301.sacyl.es 2.6.18-128.1.10.el5.centos.plusPAE #1 >>>> SMP Mon May 11 07:51:33 EDT 2009 i686 i686 i386 GNU/Linux >>>> >>>> Regards and thanks in advance. >>>> >>>> -- >>>> 389 users mailing list >>>> 389-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> >>>> >>> >>> -- >>> 389 users mailing list >>> 389-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> >>> >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > > From info at silkwise.com Tue Aug 18 09:34:39 2009 From: info at silkwise.com (info at silkwise.com) Date: Tue, 18 Aug 2009 02:34:39 -0700 (MST) Subject: [389-users] What is Password Synchronization? Message-ID: <28991606.340.1250588079495.JavaMail.root@ip-97-74-127-145.ip.secureserver.net> Dear Sir/Madam, SilkWise.com is a popular question answer website. Some of our users asked the above question, and we think you are the domain expert who can provide a great answer to it. Can you help to answer the question or improve the current answer at the following link? http://www.silkwise.com/content/viewthread_thread,8025 Everyone has unique expertise. SilkWise is the place to share your wisdom, build your networks, and market yourself! SilkWise Team To stop future messages from me, visit http://silkwise.com/unsubscribe contact PO BOX 36092 Milpitas,CA From rmeggins at redhat.com Tue Aug 18 14:00:36 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 18 Aug 2009 08:00:36 -0600 Subject: [389-users] nsDirectoryServerTask objectClass In-Reply-To: <52a9d2e30908180342p704b39eet16b9bd3bd6f682b5@mail.gmail.com> References: <52a9d2e30908140048x18f2377fvd9a29e8529b05aae@mail.gmail.com> <4A8571A0.3010000@redhat.com> <52a9d2e30908170059u44f94ea1l85be5624cb082fb0@mail.gmail.com> <4A89965C.1080203@redhat.com> <52a9d2e30908180342p704b39eet16b9bd3bd6f682b5@mail.gmail.com> Message-ID: <4A8AB404.6020502@redhat.com> Juan Asensio S?nchez wrote: > Well > > I have found the errors. When I execute the script db2index.pl, i was > using the server instance instead the database instance for the -n > parameter.With the LDAP file i forgot to include the nsInstance > attribue, as Rich said. > > Now the tasks for reindexing are created OK, but i use a script that > creates lots of tasks to update the indexes of the database, so the > first task for the database runs ok, but the others don't run because > of this error. The attributes of the tasks are for nstasklog and > nstaskstatus "Index failed (error -1)", and in the error log i get > "ldbm: 'userRoot' is already in the middle of another task and cannot > be disturbed.". Is there any way to run the tasks in order, starting > one when other finishes? > Yes. Using the task interface, you simply do a search of the index task entry. When the entry has the nsTaskExitCode, the task is completed. The value of that attribute will be 0 if the task was successful, or some error code if not. The server will remove the entry automatically after a certain period of time, so if the entry does not exist (err=32) then the task is completed, but you will not be able to get the exit code. > Regards. > > 2009/8/17 Rich Megginson : > >> Juan Asensio S?nchez wrote: >> >>> Hi >>> >>> I can't get this to work. Even with the script db2index.pl, i get an >>> error: >>> >>> >>> =============================================================================== >>> [root at server11 slapd-center1]# ./db2index.pl -D "cn=Directory >>> Manager" -w - -v -n center1 -t cn:eq >>> Bind Password: >>> >>> ldapmodify: started Mon Aug 17 11:49:52 2009 >>> >>> ldap_init( server11.center1.xxxxxxxx.local, 389 ) >>> add objectclass: >>> top >>> extensibleObject >>> add cn: >>> db2index_2009_8_17_11_49_52 >>> add nsInstance: >>> center1 >>> add nsIndexAttribute: >>> cn:eq >>> adding new entry cn=db2index_2009_8_17_11_49_52, cn=index, cn=tasks, >>> cn=config >>> ldap_add: No such object >>> >>> >> look in /var/log/dirsrv/slapd-instance/access - find the ADD operation >> corresponding to this - which entry does it complain about? >> >>> =============================================================================== >>> >>> >>> With an LDIF file: >>> >>> >>> =============================================================================== >>> [root at server11 ~]# cat index_cn.ldif >>> dn : cn=cn_index_task, cn=index, cn=tasks, cn=config >>> objectClass: top >>> objectClass: extensibleObject >>> cn: cn_index_task >>> nsIndexAttribute: eq:pres >>> [root at server11 ~]# ldapadd -H ldap://localhost -D "cn=Directory >>> Manager" -W -x -f index_cn.ldif >>> Enter LDAP Password: >>> adding new entry "cn=cn_index_task, cn=index, cn=tasks, cn=config" >>> ldapadd: Object class violation (65) >>> >>> >> You are missing >> nsInstance: center1 >> >>> =============================================================================== >>> >>> Any idea? >>> >>> Thanks in advance. >>> >>> >>> 2009/8/14 Rich Megginson : >>> >>> >>>> Juan Asensio S?nchez wrote: >>>> >>>> >>>>> Hi >>>>> >>>>> I am trying to create a task to update the index database, according >>>>> to the instructions described here: >>>>> >>>>> - >>>>> >>>>> http://www.redhat.com/docs/manuals/dir-server/8.1/admin/applying-indexes.html >>>>> - >>>>> http://directory.fedoraproject.org/wiki/Task_Invocation_Via_LDAP_Design >>>>> >>>>> But when I create the task from a Perl script, i get an error about >>>>> unknown object class: >>>>> >>>>> my $entry = Net::LDAP::Entry->new(); >>>>> $tmp_index_name = 'cn'; >>>>> my $cn = "$tmp_index_name index task"; >>>>> $entry->dn("cn=$cn, cn=index, cn=tasks, cn=config"); >>>>> $entry->add('objectClass' => ['nsDirectoryServerTask']); >>>>> $entry->add('cn' => $cn); >>>>> $entry->add('nsindexattribute' => "\"eq:pres\""); >>>>> my $res = $entry->update($ldap_conn); >>>>> >>>>> The error is 'unknown object class "nsDirectoryServerTask"'. Where is >>>>> that objectClass defined? >>>>> >>>>> >>>>> >>>> It is not defined. The documentation is wrong. Just use >>>> extensibleObject >>>> as the objectclass. For more information and examples, see the various >>>> perl >>>> scripts created for each instance in /usr/lib/dirsrv/slapd-instance - >>>> db2ldif.pl, ldif2db.pl, db2index.pl, etc. >>>> >>>> And please file a bug to correct that documentation. >>>> >>>> >>>>> # rpm -qa | grep -i fedora >>>>> fedora-ds-admin-1.1.1-1.fc6 >>>>> fedora-ds-1.1.0-3.fc6 >>>>> fedora-ds-base-1.1.0-3.fc6 >>>>> fedora-admin-console-1.1.0-4.fc6 >>>>> fedora-idm-console-1.1.0-5.fc6 >>>>> fedora-ds-console-1.1.0-5.fc6 >>>>> # uname -a >>>>> Linux grsgscbulp0301.sacyl.es 2.6.18-128.1.10.el5.centos.plusPAE #1 >>>>> SMP Mon May 11 07:51:33 EDT 2009 i686 i686 i386 GNU/Linux >>>>> >>>>> Regards and thanks in advance. >>>>> >>>>> -- >>>>> 389 users mailing list >>>>> 389-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>>> >>>>> >>>>> >>>> -- >>>> 389 users mailing list >>>> 389-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> >>>> >>>> >>>> >>> -- >>> 389 users mailing list >>> 389-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>> >>> >> >> -- >> 389 users mailing list >> 389-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> >> >> > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Tue Aug 18 14:02:00 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Tue, 18 Aug 2009 08:02:00 -0600 Subject: [389-users] question In-Reply-To: <34b295dc0908180015if189866v387c8e0a7f3e3d06@mail.gmail.com> References: <34b295dc0908180015if189866v387c8e0a7f3e3d06@mail.gmail.com> Message-ID: <4A8AB458.2040402@redhat.com> nima rafiee wrote: > hi > I installed fedra-directory server . > It worked till I install perl -ol-schema.pl and aldo stupssh.12 to use > samba but after I did I couldnt login to fedora-ds console the error > is bad : usr and password for directory manager of directoy problem > but Im sure that my userid is cn=directory manger and my pass is > correct too > what should i do fedora-idm-console -D 9 -f console.log (or 389-console if you have upgraded) Then paste the console.log to fpaste.org (be careful to obscure any sensitive information first) then email the link to the paste to the list. > I dont know this erro is because of those file that i installed or > somthing else > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From dumboq at yahoo.com Tue Aug 18 21:01:36 2009 From: dumboq at yahoo.com (Dumbo Q) Date: Tue, 18 Aug 2009 14:01:36 -0700 (PDT) Subject: [389-users] Broken bash environment with ldap users. Message-ID: <20718.1954.qm@web111902.mail.gq1.yahoo.com> I setup central authentication using centos ds. On a test box I got it working just the way i wanted, but then when I went to deploy the config files to some other servers, things went screwy. Hopefully someone else has seen this happen when deploying ldap..?? Heres what I did. 1. Copied my config files from the working server to a new one. Here is a listing of the files that have been copied: /etc/authconfig /etc/auto.home /etc/auto.master /etc/ldap.conf /etc/libuser.conf /etc/login.defs /etc/nsswitch.conf /etc/openldap/ldap.conf /etc/pam.d/system-auth /etc/pam.d/system-auth-ac /etc/security/access.conf 2. Once the files are in place, I tried to ssh as username "dumbo" uid=1000 in ldap. I can login successfully, but the bash environment is all screwed up. Here is what i mean by that. example 1. echo hello |grep hello returns no output. No pipes seem to work. grep alone on a file works. example 2. See the attached zip file. I saved the output of bash --login -vx from both a local user and an ldap user. It appears that when the ldap user logs in, it is unable to parse backticks. Note the output is just 50 lines, which shows what happens when the user runs /etc/bashrc on login. Some other steps i've taken. 1. wiped out the home directory for the ldap user (although it still worked fine on my first test box). 2. diffed and confirmed that all of the files i copied as well as /etc/profile.d are identical on both servers. 3. I set the first line in /etc/bashrc to "set > /tmp/test1", and compared output of the environment variables from a local and ldap user. The output is is the same other the of course the UID's and PID numbers. I am at a complete loss as to what the problem is. any help would be appreciated. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: out.zip Type: application/x-zip-compressed Size: 1256 bytes Desc: not available URL: From dumboq at yahoo.com Tue Aug 18 22:28:30 2009 From: dumboq at yahoo.com (Dumbo Q) Date: Tue, 18 Aug 2009 15:28:30 -0700 (PDT) Subject: [389-users] Broken bash environment with ldap users. In-Reply-To: <20718.1954.qm@web111902.mail.gq1.yahoo.com> References: <20718.1954.qm@web111902.mail.gq1.yahoo.com> Message-ID: <627706.92803.qm@web111910.mail.gq1.yahoo.com> I promise, I spent a good 8 hours on this. In the end, here is what got it working. yum -y update [659 updates] I guess, sometimes you gotta think simple. ________________________________ From: Dumbo Q To: fedora-directory-users at redhat.com Sent: Tuesday, August 18, 2009 5:01:36 PM Subject: [389-users] Broken bash environment with ldap users. I setup central authentication using centos ds. On a test box I got it working just the way i wanted, but then when I went to deploy the config files to some other servers, things went screwy. Hopefully someone else has seen this happen when deploying ldap..?? Heres what I did. 1. Copied my config files from the working server to a new one. Here is a listing of the files that have been copied: /etc/authconfig /etc/auto.home /etc/auto.master /etc/ldap.conf /etc/libuser.conf /etc/login.defs /etc/nsswitch.conf /etc/openldap/ldap.conf /etc/pam.d/system-auth /etc/pam.d/system-auth-ac /etc/security/access.conf 2. Once the files are in place, I tried to ssh as username "dumbo" uid=1000 in ldap. I can login successfully, but the bash environment is all screwed up. Here is what i mean by that. example 1. echo hello |grep hello returns no output. No pipes seem to work. grep alone on a file works. example 2. See the attached zip file. I saved the output of bash --login -vx from both a local user and an ldap user. It appears that when the ldap user logs in, it is unable to parse backticks. Note the output is just 50 lines, which shows what happens when the user runs /etc/bashrc on login. Some other steps i've taken. 1. wiped out the home directory for the ldap user (although it still worked fine on my first test box). 2. diffed and confirmed that all of the files i copied as well as /etc/profile.d are identical on both servers. 3. I set the first line in /etc/bashrc to "set > /tmp/test1", and compared output of the environment variables from a local and ldap user. The output is is the same other the of course the UID's and PID numbers. I am at a complete loss as to what the problem is. any help would be appreciated. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From theunis at pier29.co.za Wed Aug 19 20:22:08 2009 From: theunis at pier29.co.za (Theunis De Klerk) Date: Wed, 19 Aug 2009 22:22:08 +0200 Subject: [389-users] Data corruption after upgrade. Message-ID: <009901ca210a$bcad3d20$3607b760$@co.za> Hi All, I am having an issue with 389DS after an upgrade and I was hoping someone could help me out. According to people on the 389 IRC Channel, someone has had this before. Firstly, please understand I am a little out of my league, so please be patient. So this afternoon, our RHEL5 box did a yum update which included 389DS. But after the upgrade, user's can't login using profiles in ldap. All the data is there, but it seems that the password fields are messed. As an example, our apache websites use Directory Server for Authentication. If I take any of the usernames and passwords that exist and try login, I get a "password mismatch" in apache. I.e. wrong password. This worked before the upgrade. But .. If I, using Apache Directory Studio, edit the password on one of those profiles, and commit. That person can login. Its as if the password attributes data is corrupted, and has to be manually reset to work again. Users can't even reset their own passwords, as the Perl module (Net::LDAP) can modify the password value, but it still won't let them login. I can even use Directory studio to verify the password, and its correct. Seems the only way I can use a password is if I use Directory Studio to change it. Has anyone has this? Or know where I can start looking, or how to fix it? Not sure what other information I need to give. Thanks, Theunis -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Wed Aug 19 20:50:46 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 19 Aug 2009 14:50:46 -0600 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <009901ca210a$bcad3d20$3607b760$@co.za> References: <009901ca210a$bcad3d20$3607b760$@co.za> Message-ID: <4A8C65A6.4050901@redhat.com> Theunis De Klerk wrote: > > Hi All, > > I am having an issue with 389DS after an upgrade and I was hoping > someone could help me out. According to people on the 389 IRC Channel, > someone has had this before. > > Firstly, please understand I am a little out of my league, so please > be patient. > > So this afternoon, our RHEL5 box did a yum update which included 389DS. > 32-bit or 64-bit? > > But after the upgrade, user?s can?t login using profiles in ldap. > I'm not sure what you mean by "using profiles in ldap". Does ldapsearch work? Can you try /usr/bin/ldapsearch -x -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword -s base -b "" ? > > All the data is there, but it seems that the password fields are messed. > > As an example, our apache websites use Directory Server for > Authentication. If I take any of the usernames and passwords that > exist and try login, I get a ?password mismatch? in apache. I.e. wrong > password. This worked before the upgrade. > > But ?. If I, using Apache Directory Studio, edit the password on one > of those profiles, and commit. That person can login. > > Its as if the password attributes data is corrupted, and has to be > manually reset to work again. Users can?t even reset their own > passwords, as the Perl module (Net::LDAP) can modify the password > value, but it still won?t let them login. I can even use Directory > studio to verify the password, and its correct. Seems the only way I > can use a password is if I use Directory Studio to change it. > > Has anyone has this? Or know where I can start looking, or how to fix it? > > Not sure what other information I need to give. > > Thanks, > > Theunis > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From theunis at pier29.co.za Wed Aug 19 21:12:21 2009 From: theunis at pier29.co.za (Theunis De Klerk) Date: Wed, 19 Aug 2009 23:12:21 +0200 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <4A8C65A6.4050901@redhat.com> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> Message-ID: <00b201ca2111$c0a12f70$41e38e50$@co.za> > 32-bit or 64-bit? 64-bit. > I'm not sure what you mean by "using profiles in ldap". A person is technically just an entry with attributes. > Does ldapsearch work? Can you try > /usr/bin/ldapsearch -x -D "uid=username,ou=people,dc=yoursuffix,dc=com" > -w thepassword -s base -b "" > ? Yes that works fine. That's what I don't get. All the data is there! I can even search for a user and all their information is there. Even the password. From rmeggins at redhat.com Wed Aug 19 21:46:29 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 19 Aug 2009 15:46:29 -0600 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <00b201ca2111$c0a12f70$41e38e50$@co.za> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> Message-ID: <4A8C72B5.3080605@redhat.com> Theunis De Klerk wrote: >> 32-bit or 64-bit? >> > > 64-bit. > > >> I'm not sure what you mean by "using profiles in ldap". >> > > A person is technically just an entry with attributes. > > >> Does ldapsearch work? Can you try >> /usr/bin/ldapsearch -x -D "uid=username,ou=people,dc=yoursuffix,dc=com" >> -w thepassword -s base -b "" >> ? >> > > Yes that works fine. Wait - you mean ldapsearch -D "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword works? So the user is able to successfully authenticate using the password after upgrade using ldapsearch? Just not with some other tool? * ldapsearch works * OS login fails * Apache mod_ldap fails * other apps? I'm trying to figure out what the common thread is here. For the apps that fail - can you take a look at the directory server access log in /var/log/dirsrv/slapd-instance/access and see what the sequence of operations is? I just want to see if those apps are attempting to retrieve the userPassword attribute and doing the password comparison themselves, or using the LDAP Compare operation, rather than just doing an LDAP BIND operation with the clear text password (which is what ldapsearch -x -D "dn" -w cleartextpw does > That's what I don't get. All the data is there! I can > even search for a user and all their information is there. Even the > password. > > > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From theunis at pier29.co.za Wed Aug 19 22:15:02 2009 From: theunis at pier29.co.za (Theunis De Klerk) Date: Thu, 20 Aug 2009 00:15:02 +0200 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <4A8C72B5.3080605@redhat.com> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> <4A8C72B5.3080605@redhat.com> Message-ID: <00ce01ca211a$827b37a0$8771a6e0$@co.za> > Wait - you mean ldapsearch -D > "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword works? So > the user is able to successfully authenticate using the password after > upgrade using ldapsearch? Just not with some other tool? > * ldapsearch works > * OS login fails > * Apache mod_ldap fails > * other apps? Yes, if I do an ldapsearch for a specific user, I get all their details just fine. If I use Apache Directory Studio, also fine. Those are the only to that I can test with to get information out of the directory server. Apache is set to authenticate certain website from the Directory Server. And that's where it fails. Apache is the only one that uses the directory server for authentication. Postfix does as well, but none of the users have email accounts. > I'm trying to figure out what the common thread is here. > > For the apps that fail - can you take a look at the directory server > access log in /var/log/dirsrv/slapd-instance/access and see what the > sequence of operations is? I just want to see if those apps are > attempting to retrieve the userPassword attribute and doing the > password comparison themselves, or using the LDAP Compare operation, > rather than just doing an LDAP BIND operation with the clear text > password (which is what ldapsearch -x -D "dn" -w cleartextpw does There is nothing in the dirsrv access log. But there is this in the apache logs: auth_ldap authenticate: user user at domain.com authentication failed; URI /profile/ [ldap_simple_bind_s() to check user credentials failed][Invalid credentials], referer: https://www.domain.com/profile/ mod_auth_form: user 'user at domain.com': authentication failure for "/profile/": password Mismatch, referer: https://www.domain.co.za/profile/ Does that help? And here is a curve ball that makes no sense, might be useless information, but anyway. If do a search on uid=username,ou=people,dc=yoursuffix,dc=com. All their correct information is there. So the data itself looks perfect. But if I take their uid and password and try login via apache, I get the above error. Makes sense, the password could be wrong or data corruption. Apache Directory Studio has a feature where you can verify a password field. So I put in the password that I just tried to login with and it verifies! i.e. Apache Directory Studio tells me the password for that user is correct. Then just to make it interesting, if copy and paste, that exact password (that wouldn't let me login via apache, but verified on Apache Directory Studio) and create a new password via Apache Directory Studio for that same user, apache then lets me login. Which is exactly why I think its data corruption, cause as soon as Apache Directory Studio writes to the password field, it 'repairs' the field. From rmeggins at redhat.com Wed Aug 19 22:29:22 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 19 Aug 2009 16:29:22 -0600 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <00ce01ca211a$827b37a0$8771a6e0$@co.za> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> <4A8C72B5.3080605@redhat.com> <00ce01ca211a$827b37a0$8771a6e0$@co.za> Message-ID: <4A8C7CC2.3010906@redhat.com> Theunis De Klerk wrote: >> Wait - you mean ldapsearch -D >> "uid=username,ou=people,dc=yoursuffix,dc=com" -w thepassword works? So >> the user is able to successfully authenticate using the password after >> upgrade using ldapsearch? Just not with some other tool? >> * ldapsearch works >> * OS login fails >> * Apache mod_ldap fails >> * other apps? >> > > Yes, if I do an ldapsearch for a specific user, I get all their details just > fine. > I don't mean ldapsearch _for_ a specific user - I mean ldapsearch _as_ a specific user - ldapsearch -x -D "uid=username,..." -w cleartextpassword This will send the LDAP BIND operation with the user's DN and clear text password i.e. will test the internal directory server password comparison code. > If I use Apache Directory Studio, also fine. > Those are the only to that I can test with to get information out of the > directory server. > Apache is set to authenticate certain website from the Directory Server. And > that's where it fails. > Apache is the only one that uses the directory server for authentication. > Postfix does as well, but none of the users have email accounts. > > >> I'm trying to figure out what the common thread is here. >> >> For the apps that fail - can you take a look at the directory server >> access log in /var/log/dirsrv/slapd-instance/access and see what the >> sequence of operations is? I just want to see if those apps are >> attempting to retrieve the userPassword attribute and doing the >> password comparison themselves, or using the LDAP Compare operation, >> rather than just doing an LDAP BIND operation with the clear text >> password (which is what ldapsearch -x -D "dn" -w cleartextpw does >> > > There is nothing in the dirsrv access log. But there is this in the apache > logs: > auth_ldap authenticate: user user at domain.com authentication failed; URI > /profile/ [ldap_simple_bind_s() to check user credentials failed][Invalid > credentials], referer: https://www.domain.com/profile/ > mod_auth_form: user 'user at domain.com': authentication failure for > "/profile/": password Mismatch, referer: https://www.domain.co.za/profile/ > > Does that help? > Yes. It means apache is using the LDAP BIND operation to authenticate the user, which is what ldapsearch does. > And here is a curve ball that makes no sense, might be useless information, > but anyway. If do a search on uid=username,ou=people,dc=yoursuffix,dc=com. > All their correct information is there. So the data itself looks perfect. > But if I take their uid and password and try login via apache, I get the > above error. Makes sense, the password could be wrong or data corruption. > Apache Directory Studio has a feature where you can verify a password field. > So I put in the password that I just tried to login with and it verifies! > i.e. Apache Directory Studio tells me the password for that user is correct. > Then just to make it interesting, if copy and paste, that exact password > (that wouldn't let me login via apache, but verified on Apache Directory > Studio) and create a new password via Apache Directory Studio for that same > user, apache then lets me login. > Which is exactly why I think its data corruption, cause as soon as Apache > Directory Studio writes to the password field, it 'repairs' the field. > I'm still trying to reproduce this problem. el5 i386 does not have the problem - now trying el5 x86_64 > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From theunis at pier29.co.za Wed Aug 19 22:41:20 2009 From: theunis at pier29.co.za (Theunis De Klerk) Date: Thu, 20 Aug 2009 00:41:20 +0200 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <4A8C7CC2.3010906@redhat.com> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> <4A8C72B5.3080605@redhat.com> <00ce01ca211a$827b37a0$8771a6e0$@co.za> <4A8C7CC2.3010906@redhat.com> Message-ID: <00d701ca211e$2e700830$8b501890$@co.za> > I'm still trying to reproduce this problem. el5 i386 does not have the > problem - now trying el5 x86_64 Well, I got 1 step closer. Along with users not being able to login, when they reset their passwords (done via a perl module; which worked before the upgrade), it would update ldap, but they still couldn't login. Then taking a shot in the dark in the code that updated/created the password instead of passing an SSHA'd password to ldap update command, I now pass a plaintext password and it works. Is it possible that in the latest 389 version, that the values for the userPassword attributes are being stored/read differently? From rmeggins at redhat.com Wed Aug 19 22:59:13 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 19 Aug 2009 16:59:13 -0600 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <00d701ca211e$2e700830$8b501890$@co.za> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> <4A8C72B5.3080605@redhat.com> <00ce01ca211a$827b37a0$8771a6e0$@co.za> <4A8C7CC2.3010906@redhat.com> <00d701ca211e$2e700830$8b501890$@co.za> Message-ID: <4A8C83C1.4010707@redhat.com> Theunis De Klerk wrote: >> I'm still trying to reproduce this problem. el5 i386 does not have the >> problem - now trying el5 x86_64 >> > > Well, I got 1 step closer. Along with users not being able to login, when > they reset their passwords (done via a perl module; which worked before the > upgrade), it would update ldap, but they still couldn't login. Then taking a > shot in the dark in the code that updated/created the password instead of > passing an SSHA'd password to ldap update command, I now pass a plaintext > password and it works. > > Is it possible that in the latest 389 version, that the values for the > userPassword attributes are being stored/read differently? > Yes. The upgrade doesn't touch the actual data, but 1.2.1 may have slightly altered the way password comparisons are done. In general, you should always pass the clear text password to the directory server, and let it hash it and compare it. This also allows you to use the password policy features of the directory server (e.g. password syntax checking does not work with pre-hashed passwords). Were these applications that pre-hashed the SSHA passwords, then sent the pre-hashed SSHA password to the server, when adding a user or modifying the password? If so, then it could be that the legacy SSHA handling was broken. > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From theunis at pier29.co.za Wed Aug 19 23:03:27 2009 From: theunis at pier29.co.za (Theunis De Klerk) Date: Thu, 20 Aug 2009 01:03:27 +0200 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <4A8C83C1.4010707@redhat.com> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> <4A8C72B5.3080605@redhat.com> <00ce01ca211a$827b37a0$8771a6e0$@co.za> <4A8C7CC2.3010906@redhat.com> <00d701ca211e$2e700830$8b501890$@co.za> <4A8C83C1.4010707@redhat.com> Message-ID: <00f001ca2121$45728190$d05784b0$@co.za> > In general, you should always pass the clear text password to the > directory server, and let it hash it and compare it. This also allows > you to use the password policy features of the directory server (e.g. > password syntax checking does not work with pre-hashed passwords). Oh. > Were these applications that pre-hashed the SSHA passwords, then sent > the pre-hashed SSHA password to the server, when adding a user or > modifying the password? If so, then it could be that the legacy SSHA > handling was broken. They were pre-hashed, and sent in the pre-hash format to the add and modify commands. From theunis at pier29.co.za Wed Aug 19 23:12:17 2009 From: theunis at pier29.co.za (Theunis De Klerk) Date: Thu, 20 Aug 2009 01:12:17 +0200 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <4A8C83C1.4010707@redhat.com> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> <4A8C72B5.3080605@redhat.com> <00ce01ca211a$827b37a0$8771a6e0$@co.za> <4A8C7CC2.3010906@redhat.com> <00d701ca211e$2e700830$8b501890$@co.za> <4A8C83C1.4010707@redhat.com> Message-ID: <00f301ca2122$81dab840$859028c0$@co.za> > Were these applications that pre-hashed the SSHA passwords, then sent > the pre-hashed SSHA password to the server, when adding a user or > modifying the password? If so, then it could be that the legacy SSHA > handling was broken. Here is an example of the perl code I used to create the password. my $password = 'thepassword'; use Digest::SHA1; use MIME::Base64; my $ctx = Digest::SHA1->new; $ctx->add($password); $ctx->add('salt'); my $hashedPasswd = '{SSHA}' . encode_base64($ctx->digest . 'salt' ,''); i.e: the way not to do it. From mrugeshkarnik at gmail.com Thu Aug 20 07:40:42 2009 From: mrugeshkarnik at gmail.com (Mrugesh Karnik) Date: Thu, 20 Aug 2009 13:10:42 +0530 Subject: [389-users] Chain on Update: Proxy Auth Fails Message-ID: <200908201310.42199.mrugeshkarnik@gmail.com> Hi all, I've been trying to set up Chain on Update on CentOS DS 8.1. The master-slave replication works. Search queries return data from the replicated database on the slave perfectly. When I send an update request, the slave binds with the master with the proper credentials but the ACI evaluation fails on the master. From the ACI logs on the master, it seems to me that the master evaluates the ACIs for the multiplexor bind dn rather than for the original user identity. This leads me to believe that somehow, proxy authentication is not happening. How do I solve this problem? In my setup, Following is the suffix and db configuration on the slave: # Suffix dn: cn="ou=Roster,dc=example,dc=com",cn=mapping tree,cn=config cn: "ou=Roster,dc=example,dc=com" objectClass: top objectClass: extensibleObject objectClass: nsMappingTree nsslapd-state: backend nsslapd-backend: RosterData nsslapd-backend: RosterDataChain nsslapd-distribution-plugin: /usr/lib/dirsrv/plugins/libreplication-plugin.so nsslapd-distribution-funct: repl_chain_on_update nsslapd-parent-suffix: "dc=example,dc=com" # Database dn: cn=RosterData,cn=ldbm database,cn=plugins,cn=config objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance nsslapd-suffix: ou=Roster,dc=example,dc=com # Replica dn: cn=replica,cn="ou=Roster,dc=example,dc=com",cn=mapping tree,cn=config cn: replica objectClass: top objectClass: nsds5replica objectClass: extensibleObject nsds5replicaroot: ou=Roster,dc=example,dc=com nsds5replicaid: 21 nsds5replicatype: 2 nsds5flags: 0 nsds5ReplicaBindDN: cn=dirhost1.example.net,ou=Replication Managers,cn=config nsds5ReplicaBindDN: cn=dirhost2.example.net,ou=Replication Managers,cn=config # Chaining Database dn: cn=RosterDataChain,cn=chaining database,cn=plugins,cn=config changetype: add objectClass: top objectClass: extensibleObject objectClass: nsBackendInstance cn: RosterDataChain nsslapd-suffix: ou=Roster,dc=example,dc=com nsFarmServerUrl: ldap://dirhost1.example.net ldap://dirhost2.example.net nsCheckLocalACI: on nsUseStartTls: on nsBindMethod: nsMultiplexorBindDn: cn=dirslave1.example.net,ou=Replication Managers,cn=config nsMultiplexorCredentials: secret I've tried with the following ACI combinations on ou=Roster,dc=example,dc=com on dirhost1 and dirhost2 1> aci: (targetattr="*") (version 3.0; acl "Proxy access for chain-on-update"; allow (proxy) userdn="ldap:///cn=dirslave1.example.net,ou=replication managers,cn=config";) 2> aci: (target=ldap:///uid=*,ou=Users,ou=Roster,dc=example,dc=com)(targetattr=*) (version 3.0; acl "Proxy access for chain-on-update as normal users"; allow (proxy) userdn="ldap:///cn=dirslave1.example.net,ou=Replication Managers,cn=config";) I see the following error in the ACI logs: [20/Aug/2009:12:57:24 +051800] NSACLPlugin - conn=201 op=2 (main): Deny write on entry(uid=mrugesh.karnik,ou=users,ou=roster,dc=example,dc=com).attr(userPassword) to cn=dirslave1.example.net,ou=replication managers,cn=config: no aci matched the subject by aci(70): aciname= "Write access to personal info", acidn="ou=users,ou=roster,dc=example,dc=com" Thanks, Mrugesh P.S. The users can modify their own userpassword attribute properly. From rmeggins at redhat.com Thu Aug 20 17:35:02 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 20 Aug 2009 11:35:02 -0600 Subject: [389-users] Data corruption after upgrade. In-Reply-To: <00f301ca2122$81dab840$859028c0$@co.za> References: <009901ca210a$bcad3d20$3607b760$@co.za> <4A8C65A6.4050901@redhat.com> <00b201ca2111$c0a12f70$41e38e50$@co.za> <4A8C72B5.3080605@redhat.com> <00ce01ca211a$827b37a0$8771a6e0$@co.za> <4A8C7CC2.3010906@redhat.com> <00d701ca211e$2e700830$8b501890$@co.za> <4A8C83C1.4010707@redhat.com> <00f301ca2122$81dab840$859028c0$@co.za> Message-ID: <4A8D8946.8030706@redhat.com> Theunis De Klerk wrote: >> Were these applications that pre-hashed the SSHA passwords, then sent >> the pre-hashed SSHA password to the server, when adding a user or >> modifying the password? If so, then it could be that the legacy SSHA >> handling was broken. >> > > Here is an example of the perl code I used to create the password. > > > my $password = 'thepassword'; > use Digest::SHA1; > use MIME::Base64; > my $ctx = Digest::SHA1->new; > $ctx->add($password); > $ctx->add('salt'); > my $hashedPasswd = '{SSHA}' . encode_base64($ctx->digest . 'salt' ,''); > > > i.e: the way not to do it. > thanks - https://bugzilla.redhat.com/show_bug.cgi?id=518520 > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Aug 20 20:41:01 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 20 Aug 2009 14:41:01 -0600 Subject: [389-users] URGENT: some problems with 389 1.2.1 Message-ID: <4A8DB4DD.6020905@redhat.com> Do not upgrade to 389 1.2.1 until you have read this message. Bug 518418 - Package rename shuts down server, results in unconfigured package This was caused by renaming the packages from fedora-ds to 389. This causes RPM to first remove the fedora-ds-base and fedora-ds-admin packages which triggers this %preun scriptlet in the spec: %preun if [ $1 = 0 ]; then /sbin/service %{pkgname} stop >/dev/null 2>&1 || : /sbin/chkconfig --del %{pkgname} fi So not only does it shutdown your directory and admin servers, it removes the chkconfig settings, including your run level settings. This was an unforeseen consequence of the package rename, and we compounded the problem by pushing the package out to stable instead of testing (where it would have likely been caught). If you intend to upgrade despite this problem, please first save your run level configuration by using chkconfig --list dirsrv, and schedule the upgrade when you can tolerate a service interruption. Is there any other way around this problem? Bug 518520 - pre hashed salted passwords do not work If you use an external mechanism to generate salted SSHA passwords, authentication will fail, because the server does not take into account the salt length. We have a patch for this ready to go for 1.2.2. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From matt.adams at cypressinteractive.com Fri Aug 21 18:06:52 2009 From: matt.adams at cypressinteractive.com (Matt Adams) Date: Fri, 21 Aug 2009 12:06:52 -0600 Subject: [389-users] Trouble building 389-admin-1.1.8 Message-ID: <4A8EE23C.9080704@cypressinteractive.com> Folks, I'm having some trouble building 389-admin-1.1.8 from the source archive. The error I'm getting is configure: checking for LDAPSDK... checking for --with-ldapsdk... no checking for --with-ldapsdk-inc... using ../mozldap-6.0.6/mozilla/dist/public/ldap checking for --with-ldapsdk-lib... using /usr/local/lib checking for pkg-config... (cached) /usr/bin/pkg-config checking for mozldap with pkg-config... configure: error: LDAPSDK not found, specify with --with-ldapsdk-inc|-lib. Which is very odd since I had no problems using the same options to build 389-ds-base. Nothing else has changed. The configure line I'm using is ./configure \ --prefix=/usr/local/dirsrv \ --with-ldapsdk-lib=/usr/local/lib \ --with-ldapsdk-bin=/usr/local/bin \ --with-ldapsdk-inc=../mozldap-6.0.6/mozilla/dist/public/ldap Does anyone have any ideas as to why configure refuses to find LDAPSDK? I've tried several different combinations and nothing seems to work. Thanks in advance, Matt -- Matt Adams Development & Network Services, Cypress Interactive http://cypressinteractive.com, http://edsuite.com From mrugeshkarnik at gmail.com Mon Aug 24 07:54:13 2009 From: mrugeshkarnik at gmail.com (Mrugesh Karnik) Date: Mon, 24 Aug 2009 13:24:13 +0530 Subject: [389-users] Re: Chain on Update: Proxy Auth Fails In-Reply-To: <200908201310.42199.mrugeshkarnik@gmail.com> References: <200908201310.42199.mrugeshkarnik@gmail.com> Message-ID: <200908241324.13855.mrugeshkarnik@gmail.com> On Thursday 20 Aug 2009 13:10:42 Mrugesh Karnik wrote: > When I send an update request, the slave binds with the master with the > proper credentials but the ACI evaluation fails on the master. From the ACI > logs on the master, it seems to me that the master evaluates the ACIs for > the multiplexor bind dn rather than for the original user identity. This > leads me to believe that somehow, proxy authentication is not happening. > How do I solve this problem? Upon further investigation, it turns out that chain on update works perfectly for attributes other than userPassword. For userPassword, the nsmultiplexorbinddn is directly considered for aci evaluation rather than the proxy bind dn. Any takers? Thanks, Mrugesh From rpolli at babel.it Tue Aug 25 10:51:58 2009 From: rpolli at babel.it (Roberto Polli) Date: Tue, 25 Aug 2009 12:51:58 +0200 Subject: [389-users] Re: can't modify userPassword with proxy user: after code debugging... In-Reply-To: <4A805F1B.1050008@redhat.com> References: <200908041851.34124.rpolli@babel.it> <4A805F1B.1050008@redhat.com> Message-ID: <200908251251.58638.rpolli@babel.it> On Monday 10 August 2009 19:55:39 Rich Megginson wrote: > > in PasswordFlow, the function > > op_shared_allow_pw_change() > > change the password ignoring controls and evaluating proxy user access > > permissions as a local user > > Thanks for debugging this. So the problem is that > slapi_acl_check_mods() at line 945 is failing? I got slapi_acl_check_mods() on line 934 fds release is fedora-ds-base-1.1.2 the difference is that > > in StandardFlow, all the controls are evaluated and the proxy_dn is set in PasswordFlow the controls are not evaluated Peace, R. -- Roberto Polli Babel S.r.l. - http://www.babel.it Tel. +39.06.91801075 - fax +39.06.91612446 Tel. cel +39.340.6522736 P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma) "Il seguente messaggio contiene informazioni riservate. Qualora questo messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene notizia a mezzo e-mail. Vi sollecitiamo altres? a distruggere il messaggio erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto della legge in materia di protezione dei dati personali." From rmeggins at redhat.com Wed Aug 26 16:30:06 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Aug 2009 10:30:06 -0600 Subject: [389-users] Re: can't modify userPassword with proxy user: after code debugging... In-Reply-To: <200908251251.58638.rpolli@babel.it> References: <200908041851.34124.rpolli@babel.it> <4A805F1B.1050008@redhat.com> <200908251251.58638.rpolli@babel.it> Message-ID: <4A95630E.4060704@redhat.com> Roberto Polli wrote: > On Monday 10 August 2009 19:55:39 Rich Megginson wrote: > >>> in PasswordFlow, the function >>> op_shared_allow_pw_change() >>> change the password ignoring controls and evaluating proxy user access >>> permissions as a local user >>> >> Thanks for debugging this. So the problem is that >> slapi_acl_check_mods() at line 945 is failing? >> > I got slapi_acl_check_mods() on line 934 > fds release is fedora-ds-base-1.1.2 > > the difference is that > >>> in StandardFlow, all the controls are evaluated and the proxy_dn is set >>> > in PasswordFlow the controls are not evaluated > > Peace, > R. > Thanks - I think this is a bug - please file a bug about this issue. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Thu Aug 27 02:43:22 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 26 Aug 2009 20:43:22 -0600 Subject: [389-users] 389 Directory Server 1.2.2 has been released Message-ID: <4A95F2CA.50905@redhat.com> The 389 Directory Server team is pleased to announce the release of version 1.2.2. There are two updated packages: 389-ds-base-1.2.2-1 and 389-admin-1.1.8-4 This release fixes several critical bugs that were in 1.2.1. We apologize for any inconvenience caused by those bugs. * Full bug list - https://bugzilla.redhat.com/showdependencytree.cgi?id=389_1.2.2&hide_resolved=0 * https://bugzilla.redhat.com/show_bug.cgi?id=487425 slapd crashes after changelog is moved * https://bugzilla.redhat.com/show_bug.cgi?id=504651 Need to store additional attributes in Retro Changelog * https://bugzilla.redhat.com/show_bug.cgi?id=509472 db2index (all) does not reindex all the db backends correctly * https://bugzilla.redhat.com/show_bug.cgi?id=518418 Package rename shuts down server, results in unconfigured package * https://bugzilla.redhat.com/show_bug.cgi?id=518520 pre hashed salted passwords do not work * https://bugzilla.redhat.com/show_bug.cgi?id=518544 large entries cause server SASL responses to fail * https://bugzilla.redhat.com/show_bug.cgi?id=519065 Fails to start if attrcrypt can't unwrap keys The Fedora 10, 11, and 12 (rawhide) packages should be showing up in the mirrors shortly. The FC6 packages are available for download. * Release Notes - http://directory.fedoraproject.org/wiki/Release_Notes * Download - http://directory.fedoraproject.org/wiki/Download -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From psundaram at wgen.net Thu Aug 27 21:27:34 2009 From: psundaram at wgen.net (Prashanth Sundaram) Date: Thu, 27 Aug 2009 17:27:34 -0400 Subject: [389-users] Kerberos SASL GSSAPI ssh error Message-ID: Hello, I am having some trouble with the FDS PAM PTA. I am trying to authenticate against AD I was trying to verify the password authentication to AD. The only time it does is kinit . To test this, I was trying to setup ssh on a client box and configure it to bind to the FDS directory. Then I tried ssh user at localhost on client box, it will not accept any password and return below error. debug1: Authentications that can continue: publickey,gssapi-with-mic,password debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No credentials cache found debug1: Next authentication method: publickey Here are my questions. 1. Do I have to make any changes in ldap.conf file like below entries? # RFC 2307 (AD) mappings # pam_login_attribute uid (enable) # pam_lookup_policy (enable) # pam_password crypt (enable) # pam_password ad (update ad passwd from unix) 2. Edit the following files for kerberos. I was trying to follow this link for documentation. http://aput.net/~jheiss/krbldap/howto.html * krb5.conf * kadm5.acl * kdc.conf 3. Edit /etc/pam.d/system-auth and ldapserver. 4. Do I need to have CA cert installed on Admin and Directory servers for ssh? I mean, I do not have any certificates installed to 389-ds currently. Is there any other steps missing here? Thanks, Prashanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From amessina at messinet.com Fri Aug 28 15:03:14 2009 From: amessina at messinet.com (Anthony Joseph Messina) Date: Fri, 28 Aug 2009 10:03:14 -0500 Subject: [389-users] Proper upgrading procedure and the use of setup-ds-admin.pl -u Message-ID: <200908281003.18534.amessina@messinet.com> I am currently running the following: 389-admin-1.1.8-3.fc11.x86_64 389-admin-console-1.1.4-1.fc11.noarch 389-admin-console-doc-1.1.4-1.fc11.noarch 389-adminutil-1.1.8-3.fc11.x86_64 389-console-1.1.3-3.fc11.noarch 389-ds-1.1.3-4.fc11.noarch 389-ds-base-1.2.1-1.fc11.x86_64 389-ds-base-debuginfo-1.2.1-1.fc11.x86_64 389-ds-console-1.2.0-4.fc11.noarch 389-ds-console-doc-1.2.0-4.fc11.noarch 389-dsgw-1.1.4-1.fc11.x86_64 Those are the packages that were the initial group that supported the renaming of Fedora DS to 389 DS. I plan to upgrade with "yum upgrade" today as some bugs have been fixed. What is the proper upgrading procedure for 389 DS? Can I simply do a "yum update" and expect everything to work or do I always need to merge rpmnew files and run setup-ds-admin.pl after each "yum update"? I ask for two reasons: 1) I was hit by https://bugzilla.redhat.com/show_bug.cgi?id=518418 and have since recreated my servers with the above packages 2) I noticed that while using SSL, the setup-ds-admin.pl requires me to delete the CA cert that was previously installed and re-import it (crazy). I'd like to make sure don't have these servers crap out again. Thanks a lot. -A -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rmeggins at redhat.com Fri Aug 28 15:25:20 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 28 Aug 2009 09:25:20 -0600 Subject: [389-users] Proper upgrading procedure and the use of setup-ds-admin.pl -u In-Reply-To: <200908281003.18534.amessina@messinet.com> References: <200908281003.18534.amessina@messinet.com> Message-ID: <4A97F6E0.3050800@redhat.com> Anthony Joseph Messina wrote: > I am currently running the following: > 389-admin-1.1.8-3.fc11.x86_64 > the new version is 389-admin-1.1.8-4 > 389-admin-console-1.1.4-1.fc11.noarch > 389-admin-console-doc-1.1.4-1.fc11.noarch > 389-adminutil-1.1.8-3.fc11.x86_64 > 389-console-1.1.3-3.fc11.noarch > 389-ds-1.1.3-4.fc11.noarch > 389-ds-base-1.2.1-1.fc11.x86_64 > the new version is 389-ds-base-1.2.2-1 > 389-ds-base-debuginfo-1.2.1-1.fc11.x86_64 > 389-ds-console-1.2.0-4.fc11.noarch > 389-ds-console-doc-1.2.0-4.fc11.noarch > 389-dsgw-1.1.4-1.fc11.x86_64 > > Those are the packages that were the initial group that supported the renaming > of Fedora DS to 389 DS. I plan to upgrade with "yum upgrade" today as some > bugs have been fixed. > Ok. Do not upgrade until the new versions specified above are available from your repo. > What is the proper upgrading procedure for 389 DS? > > Can I simply do a "yum update" and expect everything to work or do I always > need to merge rpmnew files and run setup-ds-admin.pl after each "yum update"? > You should do a yum upgrade instead of update so that obsoletes will be processed correctly. Then do setup-ds-admin.pl -u I don't think there is any merging that needs to be done, but it wouldn't hurt just to check the diff between file and file.rpmnew to see if anything has changed (that you didn't set in your configuration). > I ask for two reasons: > > 1) I was hit by https://bugzilla.redhat.com/show_bug.cgi?id=518418 and have > since recreated my servers with the above packages > > 2) I noticed that while using SSL, the setup-ds-admin.pl requires me to delete > the CA cert that was previously installed and re-import it (crazy). > Yes, this is a bug. https://bugzilla.redhat.com/show_bug.cgi?id=501846 > I'd like to make sure don't have these servers crap out again. > Due to the rename issue, your servers will be stopped and restarted, but you should not lose your run level configuration. In what other way(s) did they "crap out"? > Thanks a lot. > > -A > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From amessina at messinet.com Fri Aug 28 15:56:36 2009 From: amessina at messinet.com (Anthony Joseph Messina) Date: Fri, 28 Aug 2009 10:56:36 -0500 Subject: [389-users] Proper upgrading procedure and the use =?iso-8859-15?q?of=09setup-ds-admin=2Epl?= -u In-Reply-To: <4A97F6E0.3050800@redhat.com> References: <200908281003.18534.amessina@messinet.com> <4A97F6E0.3050800@redhat.com> Message-ID: <200908281056.36453.amessina@messinet.com> On Friday 28 August 2009 10:25:20 Rich Megginson wrote: > > 2) I noticed that while using SSL, the setup-ds-admin.pl requires me to > > delete the CA cert that was previously installed and re-import it > > (crazy). > > Yes, this is a bug. https://bugzilla.redhat.com/show_bug.cgi?id=501846 > > > I'd like to make sure don't have these servers crap out again. > > > > Due to the rename issue, your servers will be stopped and restarted, but > you should not lose your run level configuration. In what other way(s) > did they "crap out"? well, since i had SSL in the server, the admin server and the console communication between both, and when the servers were stopped, the setup-ds- admin.pl couldn't connect to anything to do the upgrade and once i manually re-added (chkconfig --add dirsrv...) and restarted, the SSL issue with setup- ds-admin.pl became a problem as i had to then uninstall certs just to reinstall them... yuk! but i'm not worried about the change between fedora-ds* and 389-ds* now as i removed all of fedora-ds* and installed fresh 389-ds* rpms and just simply started over. -- i had just moved from OpenLDAP so that wasn't a big deal. i also noticed last time that the setup-ds-admin.pl created duplicate instances of my servers in the console -- and i wasn't sure how to get rid of those which is also part of why i just "started over." since i'm already using the renamed packages (the first round of them), i want to be sure i'm ok with a yum upgrade and that the proper procedure is to always run a setup-ds-admin.pl -u due to https://bugzilla.redhat.com/show_bug.cgi?id=501846, i now have standard ldap:// (instead of ldaps://) between the admin server and the ds so i should be able to avoid that issue. i'm still learning this 389-ds, coming from OpenLDAP where i simply did an yum update and didn't need to do anything else :) i guess, basically... what does one do if the server stops and they are not able to run setup-ds-admin.pl? is it safe to restart the server services and then try it again? -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From amessina at messinet.com Fri Aug 28 16:10:51 2009 From: amessina at messinet.com (Anthony Joseph Messina) Date: Fri, 28 Aug 2009 11:10:51 -0500 Subject: [389-users] Proper upgrading procedure and the use =?iso-8859-15?q?of=09setup-ds-admin=2Epl?= -u In-Reply-To: <4A97F6E0.3050800@redhat.com> References: <200908281003.18534.amessina@messinet.com> <4A97F6E0.3050800@redhat.com> Message-ID: <200908281110.51658.amessina@messinet.com> On Friday 28 August 2009 10:25:20 Rich Megginson wrote: > Anthony Joseph Messina wrote: > > I am currently running the following: > > 389-admin-1.1.8-3.fc11.x86_64 > > > > the new version is 389-admin-1.1.8-4 i got that. > > 389-admin-console-1.1.4-1.fc11.noarch > > 389-admin-console-doc-1.1.4-1.fc11.noarch > > 389-adminutil-1.1.8-3.fc11.x86_64 > > 389-console-1.1.3-3.fc11.noarch > > 389-ds-1.1.3-4.fc11.noarch > > 389-ds-base-1.2.1-1.fc11.x86_64 > > > > the new version is 389-ds-base-1.2.2-1 i got that. > > 389-ds-base-debuginfo-1.2.1-1.fc11.x86_64 > > 389-ds-console-1.2.0-4.fc11.noarch > > 389-ds-console-doc-1.2.0-4.fc11.noarch > > 389-dsgw-1.1.4-1.fc11.x86_64 > > > > Those are the packages that were the initial group that supported the > > renaming of Fedora DS to 389 DS. I plan to upgrade with "yum upgrade" > > today as some bugs have been fixed. > > > > Ok. Do not upgrade until the new versions specified above are available > from your repo. ok, i can confirm that the following works now: 1) running "yum upgrade" from the original package set that i specified earlier which retrieves the new 389-admin and 389-ds-base packages. (no rpmnew files created) 2) running setup-ds-admin.pl -u (without ldaps://... as the connection string between the admin server and the ds) 3) now i have: [27/Aug/2009:20:39:13 -0500] - 389-Directory/1.2.1 B2009.224.1954 starting up [27/Aug/2009:20:39:14 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [27/Aug/2009:20:39:14 -0500] - Listening on All Interfaces port 636 for LDAPS requests [28/Aug/2009:11:01:47 -0500] - slapd shutting down - signaling operation threads [28/Aug/2009:11:01:47 -0500] - slapd shutting down - waiting for 29 threads to terminate [28/Aug/2009:11:01:47 -0500] - slapd shutting down - closing down internal subsystems and plugins [28/Aug/2009:11:01:49 -0500] - Waiting for 4 database threads to stop [28/Aug/2009:11:01:49 -0500] - All database threads now stopped [28/Aug/2009:11:01:49 -0500] - slapd stopped. 389-Directory/1.2.2 B2009.237.206 ds.messinet.com:636 (/etc/dirsrv/slapd-ds) [28/Aug/2009:11:01:50 -0500] - 389-Directory/1.2.2 B2009.237.206 starting up [28/Aug/2009:11:01:50 -0500] - slapd started. Listening on All Interfaces port 389 for LDAP requests [28/Aug/2009:11:01:50 -0500] - Listening on All Interfaces port 636 for LDAPS requests so it worked. thank you. i just want to keep in my brain the proper way to upgrade these servers. if for example, there were *.rpmnew files created, at what point during this process should they be merged? 1) before running setup-ds-admin.pl -u? 2) after, but before restarting dirsrv? thanks again. -a -- Anthony - http://messinet.com - http://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From rmeggins at redhat.com Fri Aug 28 16:56:21 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 28 Aug 2009 10:56:21 -0600 Subject: [389-users] Proper upgrading procedure and the use of setup-ds-admin.pl -u In-Reply-To: <200908281110.51658.amessina@messinet.com> References: <200908281003.18534.amessina@messinet.com> <4A97F6E0.3050800@redhat.com> <200908281110.51658.amessina@messinet.com> Message-ID: <4A980C35.3090109@redhat.com> Anthony Joseph Messina wrote: > On Friday 28 August 2009 10:25:20 Rich Megginson wrote: > >> Anthony Joseph Messina wrote: >> >>> I am currently running the following: >>> 389-admin-1.1.8-3.fc11.x86_64 >>> >>> >> the new version is 389-admin-1.1.8-4 >> > > i got that. > > >>> 389-admin-console-1.1.4-1.fc11.noarch >>> 389-admin-console-doc-1.1.4-1.fc11.noarch >>> 389-adminutil-1.1.8-3.fc11.x86_64 >>> 389-console-1.1.3-3.fc11.noarch >>> 389-ds-1.1.3-4.fc11.noarch >>> 389-ds-base-1.2.1-1.fc11.x86_64 >>> >>> >> the new version is 389-ds-base-1.2.2-1 >> > > i got that. > > >>> 389-ds-base-debuginfo-1.2.1-1.fc11.x86_64 >>> 389-ds-console-1.2.0-4.fc11.noarch >>> 389-ds-console-doc-1.2.0-4.fc11.noarch >>> 389-dsgw-1.1.4-1.fc11.x86_64 >>> >>> Those are the packages that were the initial group that supported the >>> renaming of Fedora DS to 389 DS. I plan to upgrade with "yum upgrade" >>> today as some bugs have been fixed. >>> >>> >> Ok. Do not upgrade until the new versions specified above are available >> from your repo. >> > > ok, i can confirm that the following works now: > 1) running "yum upgrade" from the original package set that i specified earlier > which retrieves the new 389-admin and 389-ds-base packages. (no rpmnew files > created) > > 2) running setup-ds-admin.pl -u (without ldaps://... as the connection string > between the admin server and the ds) > > 3) now i have: > > [27/Aug/2009:20:39:13 -0500] - 389-Directory/1.2.1 B2009.224.1954 starting up > [27/Aug/2009:20:39:14 -0500] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [27/Aug/2009:20:39:14 -0500] - Listening on All Interfaces port 636 for LDAPS > requests > [28/Aug/2009:11:01:47 -0500] - slapd shutting down - signaling operation > threads > [28/Aug/2009:11:01:47 -0500] - slapd shutting down - waiting for 29 threads to > terminate > [28/Aug/2009:11:01:47 -0500] - slapd shutting down - closing down internal > subsystems and plugins > [28/Aug/2009:11:01:49 -0500] - Waiting for 4 database threads to stop > [28/Aug/2009:11:01:49 -0500] - All database threads now stopped > [28/Aug/2009:11:01:49 -0500] - slapd stopped. > 389-Directory/1.2.2 B2009.237.206 > ds.messinet.com:636 (/etc/dirsrv/slapd-ds) > > [28/Aug/2009:11:01:50 -0500] - 389-Directory/1.2.2 B2009.237.206 starting up > [28/Aug/2009:11:01:50 -0500] - slapd started. Listening on All Interfaces > port 389 for LDAP requests > [28/Aug/2009:11:01:50 -0500] - Listening on All Interfaces port 636 for LDAPS > requests > > so it worked. thank you. i just want to keep in my brain the proper way to > upgrade these servers. > > if for example, there were *.rpmnew files created, at what point during this > process should they be merged? > 1) before running setup-ds-admin.pl -u? > Yes. setup-ds-admin.pl uses the files in /etc/dirsrv/admin-serv/ > 2) after, but before restarting dirsrv? > > thanks again. -a > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: From rmeggins at redhat.com Fri Aug 28 17:01:37 2009 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 28 Aug 2009 11:01:37 -0600 Subject: [389-users] Proper upgrading procedure and the use of setup-ds-admin.pl -u In-Reply-To: <200908281056.36453.amessina@messinet.com> References: <200908281003.18534.amessina@messinet.com> <4A97F6E0.3050800@redhat.com> <200908281056.36453.amessina@messinet.com> Message-ID: <4A980D71.30105@redhat.com> Anthony Joseph Messina wrote: > On Friday 28 August 2009 10:25:20 Rich Megginson wrote: > >>> 2) I noticed that while using SSL, the setup-ds-admin.pl requires me to >>> delete the CA cert that was previously installed and re-import it >>> (crazy). >>> >> Yes, this is a bug. https://bugzilla.redhat.com/show_bug.cgi?id=501846 >> >> >>> I'd like to make sure don't have these servers crap out again. >>> >>> >> Due to the rename issue, your servers will be stopped and restarted, but >> you should not lose your run level configuration. In what other way(s) >> did they "crap out"? >> > > well, since i had SSL in the server, the admin server and the console > communication between both, and when the servers were stopped, the setup-ds- > admin.pl couldn't connect to anything to do the upgrade and once i manually > re-added (chkconfig --add dirsrv...) and restarted, the SSL issue with setup- > ds-admin.pl became a problem as i had to then uninstall certs just to > reinstall them... yuk! > > but i'm not worried about the change between fedora-ds* and 389-ds* now as i > removed all of fedora-ds* and installed fresh 389-ds* rpms and just simply > started over. -- i had just moved from OpenLDAP so that wasn't a big deal. > > i also noticed last time that the setup-ds-admin.pl created duplicate > instances of my servers in the console -- and i wasn't sure how to get rid of > those which is also part of why i just "started over." > They can be removed using the console directory browser, to remove their entries from under o=NetscapeRoot > since i'm already using the renamed packages (the first round of them), i want > to be sure i'm ok with a yum upgrade and that the proper procedure is to > always run a setup-ds-admin.pl -u > Yes. In the future (unless we obsolete some packages again) you can just use yum update. And you must always run setup-ds-admin.pl -u after doing an upgrade - this will make sure the console shows the correct information, and in the future will do things like schema upgrade, adding new configuration, removing old/obsolete configuration/files, etc. > due to https://bugzilla.redhat.com/show_bug.cgi?id=501846, i now have standard > ldap:// (instead of ldaps://) between the admin server and the ds so i should > be able to avoid that issue. > > i'm still learning this 389-ds, coming from OpenLDAP where i simply did an yum > update and didn't need to do anything else :) > Unfortunately, there is no way to change the information that the console uses without asking for some sort of password or credential - you can't do that with yum upgrade or rpm -U. I'm not sure how a yum upgrade of openldap would deal with schema changes, config changes, etc. - perhaps it doesn't do any of that, and just expects you to do that. > i guess, basically... what does one do if the server stops and they are not > able to run setup-ds-admin.pl? is it safe to restart the server services and > then try it again? > Yes. > > ------------------------------------------------------------------------ > > -- > 389 users mailing list > 389-users at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-directory-users > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3258 bytes Desc: S/MIME Cryptographic Signature URL: