Fedora directory users - Jan 2006 - Samba PDC using FDS backend

Hi Folks,

I had a crack at setting up a Samba PDC using a fresh installation of 
FDS 1.0.1 as the backend on one of our RHEL 3 servers per the Wiki 
Howto:Samba but ran into a few issues.

In the section ''Populating FDS with PDC Entry'', it instructs
the user to
run ''net getlocalsid''. This results in the following:

[root@mybox logs]# net getlocalsid
[2006/01/03 14:32:58, 0] lib/smbldap.c:smbldap_search_domain_info(1392)
  Adding domain info for CMOMA failed with NT_STATUS_UNSUCCESSFUL
SID for domain mybox is: S-1-5-21-4207250186-2406131440-3849861866

Thinking that I might just have a Samba configuration problem, I 
continued by attempting to add the following ldif:

dn: sambaDomainName=CMOMA,dc=cmoma,dc=mycompany,dc=com
objectclass: sambaDomain
objectclass: sambaUnixIDPool
objectclass: top
sambaDomainName: CMOMA
sambaSID: S-1-5-21-4207250186-2406131440-3849861866
uidNumber: 550
gidNumber: 550

which resulted in the following error:

adding new entry sambaDomainName=CMOMA,dc=cmoma,dc=mycompany,dc=com
ldap_add: Object class violation
ldap_add: additional info: unknown object class "sambaUnixIDPool"

I double checked 
/opt/fedora-ds/slapd-<server>/config/schema/61samba.ldif created in the 
initial setup steps and was unable to find a sambaUnixIDPool 
objectclass, but did see a sambaUnixIdPool. However, after I edited 
/tmp/sambaDomainName.ldif to reflect this objectclass name, ldif2ldap 
still complains about an ''unknown object class''.

Any idea of what might be happening here?

Brian Rudy wrote:
>
> I double checked 
> /opt/fedora-ds/slapd-<server>/config/schema/61samba.ldif created in 
> the initial setup steps and was unable to find a sambaUnixIDPool 
> objectclass, but did see a sambaUnixIdPool.
These two values /should/ be equivalent.
> Any idea of what might be happening here?
Did you restart the server after you initially added the new schema files?

-- 
Pete

Pete Rowley wrote:
> Brian Rudy wrote:
>
>>
>> I double checked 
>> /opt/fedora-ds/slapd-<server>/config/schema/61samba.ldif created
in
>> the initial setup steps and was unable to find a sambaUnixIDPool 
>> objectclass, but did see a sambaUnixIdPool.
>
>
> These two values /should/ be equivalent.
>
>> Any idea of what might be happening here?
>
>
> Did you restart the server after you initially added the new schema 
> files?
I did indeed. It almost looks like 61samba.ldif isn''t being used for 
some reason...

I did some additional digging and realized that somehow I did something 
incorrectly while converting the samba.schema file to 61samba.ldif. My 
61samba.ldif was over 176kb (the latter part being filled with binary 
gibberish), but should have been ~13k if things had completed properly 
:P Strangely enough, I didn''t see any errors in the slapd logs about 
being unable to load the schema file...


Brian Rudy wrote:
> Pete Rowley wrote:
>
>> Brian Rudy wrote:
>>
>>>
>>> I double checked 
>>> /opt/fedora-ds/slapd-<server>/config/schema/61samba.ldif
created in
>>> the initial setup steps and was unable to find a sambaUnixIDPool 
>>> objectclass, but did see a sambaUnixIdPool.
>>
>>
>>
>> These two values /should/ be equivalent.
>>
>>> Any idea of what might be happening here?
>>
>>
>>
>> Did you restart the server after you initially added the new schema 
>> files?
>
>
> I did indeed. It almost looks like 61samba.ldif isn''t being used
for
> some reason...
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users

Please create a bug and attach your (zipped) gibberish file.  Bad schema 
should be logged (at least) - assuming the gibberish didn''t actually 
form a valid schema component some how.

Brian Rudy wrote:
> I did some additional digging and realized that somehow I did 
> something incorrectly while converting the samba.schema file to 
> 61samba.ldif. My 61samba.ldif was over 176kb (the latter part being 
> filled with binary gibberish), but should have been ~13k if things had 
> completed properly :P Strangely enough, I didn''t see any errors in
the
> slapd logs about being unable to load the schema file...
>
>
> Brian Rudy wrote:
>
>> Pete Rowley wrote:
>>
>>> Brian Rudy wrote:
>>>
>>>>
>>>> I double checked 
>>>> /opt/fedora-ds/slapd-<server>/config/schema/61samba.ldif
created in
>>>> the initial setup steps and was unable to find a
sambaUnixIDPool
>>>> objectclass, but did see a sambaUnixIdPool.
>>>
>>>
>>>
>>>
>>> These two values /should/ be equivalent.
>>>
>>>> Any idea of what might be happening here?
>>>
>>>
>>>
>>>
>>> Did you restart the server after you initially added the new schema
>>> files?
>>
>>
>>
>> I did indeed. It almost looks like 61samba.ldif isn''t being
used for
>> some reason...
>>
>>
>>
>> -- 
>> Fedora-directory-users mailing list
>> Fedora-directory-users@redhat.com
>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
>
>
> -- 
> Fedora-directory-users mailing list
> Fedora-directory-users@redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users


-- 
Pete

Bug 177473 has been created.

Pete Rowley wrote:
> Please create a bug and attach your (zipped) gibberish file.  Bad 
> schema should be logged (at least) - assuming the gibberish didn''t
> actually form a valid schema component some how.
>
> Brian Rudy wrote:
>
>> I did some additional digging and realized that somehow I did 
>> something incorrectly while converting the samba.schema file to 
>> 61samba.ldif. My 61samba.ldif was over 176kb (the latter part being 
>> filled with binary gibberish), but should have been ~13k if things 
>> had completed properly :P Strangely enough, I didn''t see any
errors
>> in the slapd logs about being unable to load the schema file...
>

Brian Rudy wrote:
> Bug 177473 has been created.
> 
> Pete Rowley wrote:
> 
>> Please create a bug and attach your (zipped) gibberish file.  Bad 
>> schema should be logged (at least) - assuming the gibberish
didn''t
>> actually form a valid schema component some how.
>>
Hi,
  I am the author of that tool.

  There is no bug in the script which could cause this problem you have 
described. This problem is likely caused by bad memory on your machine 
or a kernel or filesystem bug.

  Are you able to reproduce this multiple times and provide multiple 
corrupted output files? And are they all identical (checked with openssl 
sha)?

Example:

openssl sha README.txt
SHA(README.txt)= d9f24b5f0a2b26e8c498a3b4b9d3b34361c41e56

  What about reproducing it on more than one machine?

BR,
--
mike

Mike Jackson wrote:
> Brian Rudy wrote:
>> Bug 177473 has been created.
>>
>> Pete Rowley wrote:
>>
>>> Please create a bug and attach your (zipped) gibberish file.  Bad 
>>> schema should be logged (at least) - assuming the gibberish
didn''t
>>> actually form a valid schema component some how.
>>>
>
> Hi,
>  I am the author of that tool.
>
>  There is no bug in the script which could cause this problem you have 
> described. This problem is likely caused by bad memory on your machine 
> or a kernel or filesystem bug.
>
>  Are you able to reproduce this multiple times and provide multiple 
> corrupted output files? And are they all identical (checked with 
> openssl sha)?
>
> Example:
>
> openssl sha README.txt
> SHA(README.txt)= d9f24b5f0a2b26e8c498a3b4b9d3b34361c41e56
>
>  What about reproducing it on more than one machine?
>
> BR,
> -- 
> mike
Hi Mike,

This far I have only seen this happen one time. I tried multiple times 
with the same machine and a few other development boxes with no success. 
Its certainly possible that I mistyped something during the initial 
schema conversion step, but I don''t see how it would have produced this
file either.

Brian Rudy wrote:
> This far I have only seen this happen one time. I tried multiple times 
> with the same machine and a few other development boxes with no success. 
> Its certainly possible that I mistyped something during the initial 
> schema conversion step, but I don''t see how it would have produced
this
> file either.
OK, I would consider this case closed, but I don''t have those type of 
rights in the bugzilla. Maybe Rich or one of the others can close it.

BR,
Mike

Mike Jackson wrote:
> Brian Rudy wrote:
>
>> This far I have only seen this happen one time. I tried multiple 
>> times with the same machine and a few other development boxes with no 
>> success. Its certainly possible that I mistyped something during the 
>> initial schema conversion step, but I don''t see how it would
have
>> produced this file either.
>
>
> OK, I would consider this case closed, but I don''t have those type
of
> rights in the bugzilla. Maybe Rich or one of the others can close it.
>
> BR,
> Mike

There are two problems listed in the bug:

1) OpenLDAP schema file conversion produces invalid LDIF.
2) slapd does not complain that it is unable to read said LDIF.

For the moment, we can assume PEBKAC for #1, but #2 warrants further 
scrutiny.



-- 
Brian Rudy  (brudyNO@SPAMpraecogito.com)
Funky Monkey

Praecogito=>Thinking Ahead...
--

Tweaking your inner geek.