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? >>> >>> 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. 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. >>> >>> 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 -------------- 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/940e9bd2/attachment.bin
