[Fedora-directory-users] FDS Crashing!

Thu Jan 18 17:37:23 UTC 2007

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://listman.redhat.com/archives/fedora-directory-users/attachments/20070118/940e9bd2/attachment.bin>