[Fedora-directory-users] FDS Crashing!

[Nicholas Byrne]

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?

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?
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.