Nicholas Byrne wrote: > > > Richard Megginson wrote: >> Nicholas Byrne wrote: >>> >>> >>> Richard Megginson wrote: >>>> Nicholas Byrne wrote: >>>>> >>>>> >>>>> Richard Megginson wrote: >>>>>> Nicholas Byrne wrote: >>>>>>> I'm using 1.0.4-1 release. My configuration fairly basic using >>>>>>> "one way" windows sync (ref: >>>>>>> https://www.redhat.com/archives/fedora-directory-users/2006-December/msg00070.html). >>>>>>> >>>>>>> >>>>>>> It's been working well until this morning for going on a month >>>>>>> (fortunately it's not live yet, but was planning to put it live >>>>>>> this weekend - not anymore!). I'm not sure what occurred >>>>>>> exactly, a few password changes and minor updates to a couple of >>>>>>> attributes but since a few hours ago any attempt to write to >>>>>>> anything in the userRoot database fails and slapd crashes. I've >>>>>>> looked in the error and access logs but it doesn't give much >>>>>>> away - on restart i see: >>>>>>> >>>>>>> [18/Jan/2007:14:48:42 +0000] - Fedora-Directory/1.0.4 >>>>>>> B2006.312.435 starting up >>>>>>> [18/Jan/2007:14:48:42 +0000] - Detected Disorderly Shutdown last >>>>>>> time Directory Server was running, recovering database. >>>>>>> [18/Jan/2007:14:48:43 +0000] - slapd started. Listening on All >>>>>>> Interfaces port 389 for LDAP requests >>>>>>> [18/Jan/2007:14:48:43 +0000] - Listening on All Interfaces port >>>>>>> 636 for LDAPS requests >>>>>>> >>>>>>> What can do to get more info? >>>>>> start-slapd -d 1 >>>>>> or >>>>>> http://directory.fedora.redhat.com/wiki/FAQ#Troubleshooting and >>>>>> use the TRACE debug level. >>>>> thanks, the server takes a long time to fully start and is really >>>>> quite slow with this switch. I suppose thats normal. >>>> Yes. >>>>> Any hints as to what else to look for, there is an enormous amount >>>>> of output. The log ends (when it crashes when i attempt any write >>>>> operation) with a segmentation fault. >>>> So, not just a write of userPassword, but of any attribute? >>> Yep thats correct >>>>>>> >>>>>>> Yesterday i did password change using ldappasswd and i found >>>>>>> this issue >>>>>>> (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=179723) >>>>>>> just now - my directory does have a password policy. Is this >>>>>>> fixed in 1.0.4? >>>>>> Yes, it is supposed to be - but if you reproduced it with 1.0.4, >>>>>> then I guess not :-( >>>>>> >>>>>> So, if I understand correctly - you used ldappasswd to change a >>>>>> user's password, and you have password policy enabled (global or >>>>>> local?), and you can crash the server. >>>>> I have all three requirements it seems to reproduce this bug, 1. >>>>> ssl on, 2. password policy global and local/subtree and i've used >>>>> ldappassword (yesterday) - uh oh! >>>>> >>>>> My issue is slightly different in that the server crashes when any >>>>> update is attempted, not just a modify password. >>>>> >>>>> Is there any way to restore an old database and turn off all >>>>> password policy for the time being without writing to the >>>>> directory / user database? Probably not i suppose, at least not >>>>> easily. So is my best bet to dump the directory to ldif and do a >>>>> reinstall and reconfigure. What do you think? >>>> If the database is corrupted, just a dump to LDIF and a reimport >>>> might do the trick. If not, then I suggest disabling the local >>>> password policy to see if that fixes the problem. >>> i did a dump and ended up having to do a ldif2db (as i couldn't >>> write to the live database without a crash) and i seem to be back up >>> and running except i don't have the default ACI's anymore. How can i >>> recreate them? >> >> Are you sure they're missing? Did you use ldapsearch to look for >> them? Remember that the aci attribute is operational and must be >> specified on the ldapsearch command line. > The process i followed was ("tech" is my top level dn/domain) - > > ldapsearch -x -b "dc=tech" | egrep -v '^pwdpolicysubentry|^ tainer' > > tech.ldif > vi tech.ldif # remove subtree password policy - "dn: > cn=nsPwPolicyContainer,ou=People,dc=tech" > stop-slapd > ldif2db -n userRoot -i tech.ldif &> ~/import.log > > So maybe i missed them out, are aci's stored in the NetscapeRoot or > "userRoot" db? Both. acis are stored with the the regular data in the database. > > I had to add a single generic one to my top level domain (tech) be > able to read it without being "cn=Domain Manager". I 've used the FD > console to look for ACI's but none seem obvious and i'm sure there > were a number of default ACI's (selfwrite, read for all - not sure of > names/dn's etc) but now there appear to be none. > > After adding this generic one on the dc=tech dn, running "ldapsearch > -x" and looking through output, it appears aci's are stored elsewhere. > Where? try this: ldapsearch -x -D "cn=directory manager" -w password -b "dc=tech" "aci=*" aci > Thanks again >> >>> Is there wiki/manual page or a script with the default ones, thats >>> all i need for the time being. >>>> >>>> At any rate, please file a bug http://bugzilla.redhat.com/ and list >>>> OS + version + bitsize, and detailed steps about how to reproduce >>>> the bug. My inclination is that this is a bug which will require a >>>> patch to address. >>> Will do, and help so far the support Richard. >>>>>>> >>>>>>> I have tried a restore from a week old backup (using bak2db) but >>>>>>> that didn't fix the problem so anyone got any idea whats going >>>>>>> on and how i might start fixing this - Help!? >>>>>>> >>>>>>> Thanks >>>>>>> Nick >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> This e-mail is the property of Quadriga Worldwide Ltd, intended >>>>>>> for the addressee only and confidential. Any dissemination, >>>>>>> copying or distribution of this message or any attachments is >>>>>>> strictly prohibited. >>>>>>> >>>>>>> If you have received this message in error, please notify us >>>>>>> immediately by replying to the message and deleting it from your >>>>>>> computer. >>>>>>> >>>>>>> Messages sent to and from Quadriga may be monitored. >>>>>>> >>>>>>> Quadriga cannot guarantee any message delivery method is secure >>>>>>> or error-free. Information could be intercepted, corrupted, >>>>>>> lost, destroyed, arrive late or incomplete, or contain viruses. >>>>>>> >>>>>>> We do not accept responsibility for any errors or omissions in >>>>>>> this message and/or attachment that arise as a result of >>>>>>> transmission. >>>>>>> >>>>>>> You should carry out your own virus checks before opening any >>>>>>> attachment. >>>>>>> >>>>>>> Any views or opinions presented are solely those of the author >>>>>>> and do not necessarily represent those of Quadriga. >>>>>>> >>>>>>> -- >>>>>>> Fedora-directory-users mailing list >>>>>>> Fedora-directory-users at redhat.com >>>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> >>>>>> -- >>>>>> Fedora-directory-users mailing list >>>>>> Fedora-directory-users at redhat.com >>>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>>>> >>>>> >>>>> >>>>> >>>>> This e-mail is the property of Quadriga Worldwide Ltd, intended >>>>> for the addressee only and confidential. Any dissemination, >>>>> copying or distribution of this message or any attachments is >>>>> strictly prohibited. >>>>> >>>>> If you have received this message in error, please notify us >>>>> immediately by replying to the message and deleting it from your >>>>> computer. >>>>> >>>>> Messages sent to and from Quadriga may be monitored. >>>>> >>>>> Quadriga cannot guarantee any message delivery method is secure or >>>>> error-free. Information could be intercepted, corrupted, lost, >>>>> destroyed, arrive late or incomplete, or contain viruses. >>>>> >>>>> We do not accept responsibility for any errors or omissions in >>>>> this message and/or attachment that arise as a result of >>>>> transmission. >>>>> >>>>> You should carry out your own virus checks before opening any >>>>> attachment. >>>>> >>>>> Any views or opinions presented are solely those of the author and >>>>> do not necessarily represent those of Quadriga. >>>>> >>>>> -- >>>>> Fedora-directory-users mailing list >>>>> Fedora-directory-users at redhat.com >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> ------------------------------------------------------------------------ >>>> >>>> >>>> -- >>>> Fedora-directory-users mailing list >>>> Fedora-directory-users at redhat.com >>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >>>> >>> >>> >>> >>> This e-mail is the property of Quadriga Worldwide Ltd, intended for >>> the addressee only and confidential. Any dissemination, copying or >>> distribution of this message or any attachments is strictly prohibited. >>> >>> If you have received this message in error, please notify us >>> immediately by replying to the message and deleting it from your >>> computer. >>> >>> Messages sent to and from Quadriga may be monitored. >>> >>> Quadriga cannot guarantee any message delivery method is secure or >>> error-free. Information could be intercepted, corrupted, lost, >>> destroyed, arrive late or incomplete, or contain viruses. >>> >>> We do not accept responsibility for any errors or omissions in this >>> message and/or attachment that arise as a result of transmission. >>> >>> You should carry out your own virus checks before opening any >>> attachment. >>> >>> Any views or opinions presented are solely those of the author and >>> do not necessarily represent those of Quadriga. >>> >>> -- >>> Fedora-directory-users mailing list >>> Fedora-directory-users at redhat.com >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> ------------------------------------------------------------------------ >> >> -- >> Fedora-directory-users mailing list >> Fedora-directory-users at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-directory-users >> > > > > This e-mail is the property of Quadriga Worldwide Ltd, intended for > the addressee only and confidential. Any dissemination, copying or > distribution of this message or any attachments is strictly prohibited. > > If you have received this message in error, please notify us > immediately by replying to the message and deleting it from your > computer. > > Messages sent to and from Quadriga may be monitored. > > Quadriga cannot guarantee any message delivery method is secure or > error-free. Information could be intercepted, corrupted, lost, > destroyed, arrive late or incomplete, or contain viruses. > > We do not accept responsibility for any errors or omissions in this > message and/or attachment that arise as a result of transmission. > > You should carry out your own virus checks before opening any attachment. > > Any views or opinions presented are solely those of the author and do > not necessarily represent those of Quadriga. > > -- > Fedora-directory-users mailing list > Fedora-directory-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: 3245 bytes Desc: S/MIME Cryptographic Signature Url : http://lists.fedoraproject.org/pipermail/389-users/attachments/20070118/8e97f389/attachment.bin
