[Fedora-directory-users] FDS Crashing!

Richard Megginson rmeggins at redhat.com
Thu Jan 18 19:16:39 UTC 2007 

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

More information about the Fedora-directory-users mailing list