[389-users] dirsrv won't start

Fri Jan 11 20:31:05 UTC 2013

Sorry I did not see the last time that error is in schema. I don't know how
you did it but you break it. You don't need to panic. Because when you
install a dirsrv instance the setup script copies the schema from
somewhere... I don't remember from where... it was somewhere in /var or
/usr... here are some ideas to get the good copy:
- Red Hat docs will have this info also you can use find command to find
this file.
- Installing other dirsrv instance for a moment will create a good copy of
this file in its directory. There can be many dirsrv servers on the system.
You need to specify diferent port and DN.
- you can read setup-ds and find from where it copies schema files.

I'm traweling at the moment and I cannot give you more details at the
moment. I am writing from my phone. I hope this will help.

Greg.
11 sty 2013 21:06, "Doug Tucker" <tuckerd at lyle.smu.edu> napisał(a):

> I was excited to see this reply, thanks so much.  Unfortunately, I copied
> that to the dse.ldif and the results are the same.  It won't start and with
> the same error.
>
> Sincerely,
>
> Doug Tucker
>
> On 01/11/2013 11:14 AM, Grzegorz Dwornicki wrote:
>
>>
>> For the record dirsrv creates file in its directory with the last good
>> configuration. I believe it was called dse.ldif.startok
>>
>> Greg.
>>
>> 11 sty 2013 18:06, "Chandan Kumar" <chandank.kumar at gmail.com <mailto:
>> chandank.kumar at gmail.**com <chandank.kumar at gmail.com>>> napisał(a):
>>
>>     You may not need to re-install it. If you could just replace the
>>     file that you changed, I hope you took a backup before
>>     experimenting with the file. Same thing happened with me too, I
>>     restored the directory server from the bakcup files.
>>
>>     On Friday, January 11, 2013, Doug Tucker wrote:
>>
>>         Well, I give up.  I can find nothing in the docs or on google
>>         to get me around this.  I'm see no way other than to uninstall
>>         389 and reinstall from scatch so no need to respond to this.
>>
>>         Sincerely,
>>
>>         Doug Tucker
>>
>>         On 01/10/2013 11:19 AM, Doug Tucker wrote:
>>
>>             So I've gone from bad to worse.  Googling and googling and
>>             no response on my auth issue from the list yesterday, I
>>             coudn't stand doing nothing.  The only thing I saw that
>>             made me curious was some thread where a guy could not auth
>>             and he changed the password hash to something else and it
>>             worked.  I looked at our current password hash in openldap
>>             and it was ssha.  For the life of me I could not find how
>>             to see what the current one was in 389.  The only thing I
>>             could find in the docs was how to set a password policy
>>             which allowed you to set the hash.  So I did so according
>>             to the documentation on the Users cn.  The only thing I
>>             did was turn it on, and make sure password hash was set to
>>             ssha. I left the rest default which was no expiration,
>>             etc.  I saved, and tried to restart according to the docs,
>>             it woudn't restart.  I shut down with the init script
>>             instead, and tried to start, and now I get this:
>>
>>             [root at lyleauth1 schema]# /etc/init.d/dirsrv start
>>             Starting dirsrv:
>>                 lyleauth1...[09/Jan/2013:16:**23:05 -0600]
>>             dse_read_one_file - The entry cn=schema in file
>>             /etc/dirsrv/slapd-lyleauth1/**schema/99user.ldif (lineno: 1)
>>             is invalid, error code 21 (Invalid syntax) - attribute
>>             type olcOverlay: Missing parent attribute syntax OID
>>             [09/Jan/2013:16:23:05 -0600] dse - Please edit the file to
>>             correct the reported problems and then restart the server.
>>             [FAILED]
>>               *** Warning: 1 instance(s) failed to start
>>
>>             Looking at the time stamp on that file, it is: Dec 20
>>             16:36 99user.ldif .  So what I did yesterday did not touch
>>             it.  Anyone have any idea how to fix this?
>>
>>
>>         --
>>         389 users mailing list
>>         389-users at lists.fedoraproject.**org<389-users at lists.fedoraproject.org>
>>         https://admin.fedoraproject.**org/mailman/listinfo/389-users<https://admin.fedoraproject.org/mailman/listinfo/389-users>
>>
>>
>>
>>     --
>>     --
>>     http://about.me/chandank
>>
>>
>>     --
>>     389 users mailing list
>>     389-users at lists.fedoraproject.**org<389-users at lists.fedoraproject.org>
>>     <mailto:389-users at lists.**fedoraproject.org<389-users at lists.fedoraproject.org>
>> >
>>     https://admin.fedoraproject.**org/mailman/listinfo/389-users<https://admin.fedoraproject.org/mailman/listinfo/389-users>
>>
>>
>>
>> --
>> 389 users mailing list
>> 389-users at lists.fedoraproject.**org <389-users at lists.fedoraproject.org>
>> https://admin.fedoraproject.**org/mailman/listinfo/389-users<https://admin.fedoraproject.org/mailman/listinfo/389-users>
>>
>
> --
> 389 users mailing list
> 389-users at lists.fedoraproject.**org <389-users at lists.fedoraproject.org>
> https://admin.fedoraproject.**org/mailman/listinfo/389-users<https://admin.fedoraproject.org/mailman/listinfo/389-users>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20130111/bd1a4a5b/attachment.html>