[Fedora-directory-users] Replication agreement trouble
by Juan Asensio Sánchez
Hi
Since yesterday I am having troubles with replication between two
servers. The replica is in multimaster mode in both servers, and
everything is configured OK (database, suffixes, changelog, replica,
agreements; until yesterday everything worked OK).
[21/Apr/2009:11:04:57 +0200] NSMMReplicationPlugin - Replication
agreement for agmt="cn=GRS_back-GRS_ppal" (grsgscvalp0101:636) could not
be updated. For replication to take place, please enable the suffix and
restart the server
The only thing to mention are replication problems with other databases
and replicas, but not for the replica of the agreement in the message.
They were fixed re-initializing the consumers of those replicas. Any
idea?
Regards and thanks in advance.
14 years, 12 months
Re: [Fedora-directory-users] fedora ds problem with updating centos
by Eric
>
> Thanks Rich. My problem was fixed with your suggestion too. I had upgraded
> OS without updating fedora ds.Is it the reson of problem?
>
>
> Message: 3
> Date: Mon, 20 Apr 2009 07:53:05 -0600
> From: Rich Megginson <rmeggins(a)redhat.com>
> Subject: Re: [Fedora-directory-users] fedora ds problem with updating
> centos
> To: "General discussion list for the Fedora Directory server project."
> <fedora-directory-users(a)redhat.com>
> Message-ID: <49EC7E41.9010505(a)redhat.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Eric wrote:
> > Hi all,
> > I had fedora-ds-1.1.3-1.fc6 installed on centos 5. I have updated
> > centos to 5.3. now fedora ds cann't be start. when I use: service
> > dirsrv start there is this error:
> > ldap...[19/Apr/2009:06:46:14 -0400] - Unable to access nsslapd-rundir:
> > Bad address
> > [19/Apr/2009:06:46:14 -0400] - Ensure that user "ldap" has read and
> > write permissions on (null)
> > [19/Apr/2009:06:46:14 -0400] - Shutting down.
> > [FAILED]
> You upgraded fedora ds first, then upgraded CentOS to 5.3? ls -al
> /var/run/dirsrv
> >
> > ------------------------------------------------------------------------
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)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: 3258 bytes
> Desc: S/MIME Cryptographic Signature
> Url :
> https://www.redhat.com/archives/fedora-directory-users/attachments/200904...
>
>
14 years, 12 months
RE: [Fedora-directory-users] LDAP proxy
by Michal Rejda
> Michal Rejda wrote:
> >> Michal Rejda wrote:
> >>
> >>>> Michal Rejda wrote:
> >>>>
> >>>>
> >>>>>> Michal Rejda wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> -----Original Message-----
> >>>>>>>> From: fedora-directory-users-bounces(a)redhat.com
> [mailto:fedora-
> >>>>>>>> directory-users-bounces(a)redhat.com] On Behalf Of Rich
> Megginson
> >>>>>>>> Sent: Tuesday, April 14, 2009 4:25 PM
> >>>>>>>> To: General discussion list for the Fedora Directory server
> >>>>>>>>
> >>>>>>>>
> >>>> project.
> >>>>
> >>>>
> >>>>>>>> Subject: Re: [Fedora-directory-users] LDAP proxy
> >>>>>>>>
> >>>>>>>> Michal Rejda wrote:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> I tried to use http://tinyurl.com/culeft. But the database
> >>>>>>>>> link
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> doesn't work. I setup the database link to the Active
> Directory
> >>>>>>>>
> >>>>>>>>
> >>>> (and
> >>>>
> >>>>
> >>>>>>>> OpenLDAP). When I looked into Wireshark log, FDS send search
> >>>>>>>>
> >>>>>>>>
> >>>> request
> >>>>
> >>>>
> >>>>>>>> with controls:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> 2.16.840.1.113730.3.4.2
> >>>>>>>>> 2.16.840.1.113730.3.4.12
> >>>>>>>>> And the AD server responded: Unavailable Critical Extension.
> >>>>>>>>>
> >>>>>>>>> I tried to remove this two controls from Database Link
> >>>>>>>>> Settings
> >>>>>>>>>
> >>>>>>>>>
> >>>> (in
> >>>>
> >>>>
> >>>>>>>> administration console) but it didn't help. The server didn't
> >>>>>>>>
> >>>>>>>>
> >>>> return
> >>>>
> >>>>
> >>>>>>>> the message above, but the administrative console show error
> >>>>>>>>
> >>>>>>>>
> >>>> dialog.
> >>>>
> >>>>
> >>>>>>>> What error?
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>> I tried it again and the error message is exactly:
> >>>>>>>
> >>>>>>> Error fading object 'dn: dc=example, dc=com'.
> >>>>>>> The error send by the server was:
> >>>>>>> ".
> >>>>>>>
> >>>>>>> In the Whireshark log was still the search request witch
> control:
> >>>>>>> 2.16.840.1.113730.3.4.2
> >>>>>>>
> >>>>>>> Why is this control needed by the server when I removed it from
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>> Database link settings?
> >>>>>>
> >>>>>> I'm not sure - maybe the console is not working correctly. Try
> >>>>>>
> >> this:
> >>
> >>>>>> 1) Shutdown the server
> >>>>>> 2) cd /etc/dirsrv/slapd-yourinstance
> >>>>>> 3) edit dse.ldif - look for the entry
> >>>>>> dn: cn=config,cn=chaining database,cn=plugins,cn=config
> >>>>>> 4) edit the nsTransmittedControls attribute - remove
> >>>>>> 2.16.840.1.113730.3.4.2
> >>>>>> 5) save and restart the server
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>> I looked into dse.ldif for a nsTransmittedControls attribute.
> >>>>> There
> >>>>>
> >>>>>
> >>>> is only the 1.3.6.1.4.1.1466.29539.12. , not the problematic
> >>>> 2.16.840.1.113730.3.4.2.
> >>>>
> >>>>
> >>>>> Isn't the 2.16.840.1.113730.3.4.2 hardcoded?
> >>>>>
> >>>>>
> >>>> If it is, I don't see it. There is no mention of managedsa or
> >>>> 2.16.840.1.113730.3.4.2 anywhere in the chaining backend code. The
> >>>> only place it is mentioned is in the default list of
> >>>> nsTransmittedControls in the template-dse.ldif used during new
> >>>> instance creation.
> >>>>
> >>>>
> >>>>> Why is this so necessary?
> >>>>>
> >>>>>
> >>>>>
> >>>> It's not necessary, and I'm not sure where it is coming from. Once
> >>>> place might be an internal operation, but I'm not sure what
> >>>> internal operation would be doing this. You might also try to
> >>>> remove nsActiveChainingComponents and nsPossibleChainingComponents
> >>>> to see
> >>>>
> >> if
> >>
> >>>> one of those components is doing an internal operation with
> >>>> managedsait set.
> >>>>
> >>>>
> >>> I removed nsActiveChainingComponents and
> >>> nsPossibleChainingComponents
> >>>
> >> and it didn't help.
> >>
> >> Then I'm not sure where it's coming from. I suppose you could enable
> >> tracing in the directory server and see if there is anything
> >> interesting in the error log - see
> >> http://directory.fedoraproject.org/wiki/FAQ#Troubleshooting
> >>
> >
> > In the attachment is the part of the server error log. I removed all
> > messages before I click on the exclamation mark before the DN in the
> > Fedora administration console -> Directory folder tab. I don't
> > understand this log. It is helpful for you?
> >
> >
> Ah, I see. You are using the console to try to browse the AD tree? And
> you are using the console admin user "admin"? Try ldapsearch from the
> command line, and attempt to authenticate as an AD user (e.g.
> cn=administrator,cn=users,dc=example,dc=com).
Yes, you are right. I use the console to browse AD tree. But I do this because there is attention marker before the root suffix (lib-w2k3r2) in the Directory tab and I just double click on it.
I tried ldapsearch using AD user (Administrator). I'm able to login but the ldapsearch don't show any results (I use Apache Directory Studio). When I looked into Whireshark log, I now see that another critical extension is missing: 2.16.840.1.113730.3.4.12. The log is in the attachment.
> >>>>>>>>>> Michal Rejda wrote:
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> Hi all,
> >>>>>>>>>>>
> >>>>>>>>>>> Im trying to setup proxy on FDS to another LDAP server
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> (OpenLDAP
> >>>>
> >>>>
> >>>>>>>>>>> and Active Directory). I tried two ways, but none of these
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> works:
> >>>>
> >>>>
> >>>>>>>>>>> 1) New database link to LDAP server.
> >>>>>>>>>>>
> >>>>>>>>>>> - The remote LDAP server (OpenLDAP) returns: null.
> >>>>>>>>>>>
> >> manageDSAit
> >>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> control
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> value not found
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> You might have to tweak the controls used by chaining - see
> >>>>>>>>>> http://tinyurl.com/culeft
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> 2) Create multiple-master replication and setup other
> server
> >>>>>>>>>>> as
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> consumer.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> - But this show error: 255 Replication error acquiring
> >>>>>>>>>>>
> >> replica:
> >>
> >>>>>>>>>>> unknown error.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> Replication will only work to a SunDS, not to any other
> >>>>>>>>>>
> >> vendor.
> >>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> My question is: Is there way how to setup proxy to access
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> another
> >>>>
> >>>>
> >>>>>>>>>>>
> >>>>>>>>>> LDAP
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> server from Fedora DS? I know that is possible to use AD
> >>>>>>>>>>>
> >> sync,
> >>
> >>>>>>>>>>>
> >>>>>> but
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> I
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> cannot install anything on the AD server. The second reason
> >>>>>>>>>>> why
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>> I
> >>>>
> >>>>
> >>>>>>>>>>>
> >>>>>>>>>> need
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> to setup proxy is to use data stored in LDAP server
> >>>>>>>>>>>
> >> (OpenLDAP,
> >>
> >>>>>>>>>>> Open Direcoty Server and Active Directory) in one place. I
> >>>>>>>>>>> need
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>> to
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>>> update
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>>> them too. It is not necessary to synchronize passwords.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>> See also
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>> http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
> >>>>
> >>>>
> >>>>>>>>>>
> >>>>>>>>>>> Thank you for reply.
> >>>>>>>>>>>
> >>>>>>>>>>> Regards,
> >>>>>>>>>>>
> >>>>>>>>>>> Michal
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>> --
> >>>>> Fedora-directory-users mailing list
> >>>>> Fedora-directory-users(a)redhat.com
> >>>>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>> --
> >>> Fedora-directory-users mailing list
> >>> Fedora-directory-users(a)redhat.com
> >>> https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >>>
> >>>
> >
> >
> > ---------------------------------------------------------------------
> -
> > --
> >
> > --
> > Fedora-directory-users mailing list
> > Fedora-directory-users(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-directory-users
> >
>
14 years, 12 months
[Fedora-directory-users] Configure LDAP clients
by Rusch Philipp pru09
Hello all,
my last try to move on with the SSL certificates. I have installed fedora-ds 1.0.4 and have used the setupssl.sh script to generate the certificates on my both servers. After that I jumped tot he „configure ldap clients“ section and there it says: „If you have more than 1 CA cert, you will have to concatenate them into a single file.“
Can anyone tell me how I have to concatenate the two cacert.asc files? I have tried several things without any result (e.g cat cacert1.asc cacert2.asc > cacert.asc). Only the first certificate is used to establish a new tls connection.
I woul appreciate any help about this problem!
Thank you in advance.
Rgds
Philipp
P
Im Sinne unserer Umwelt: Bitte bedenken Sie, dass ein Ausdruck dieser Nachricht wertvolle Ressourcen verbraucht.
For the sake of our environment: Please be aware of the fact that printing this message consumes valuable resources.
14 years, 12 months
[Fedora-directory-users] logconv showing unindexed searches on indexed attributes.
by James Chavez
Hello List,
I have a directory with 20,000 plus users.
The output from logconv is showing me that I have unindexed searches with a
search filter of '(uidNumber=*)'.
However my uidNumber attribute is indeed indexed.
The documentation states the following
" In Directory Server, when examining an index, if more than a certain
number of entries are found, the server stops reading the index and marks
the search as unindexed for that particular index."
I believe this is what is going on because if i increase the
idlistscanlimit the searches no longer show as unindexed.
So a few questions.
Is this a serious warning or error and does it effect performance? It seems
to me that it renders the indexes useless for directories with more than
4,000 entries unless the idlistscanlimit is increased.
Can I increase it only for the uidNumber or chosen attributes attributes? I
am assuming the answer to this is no since it seems to be set globally.
Is there a tool similar to OpenLDAP's slapindex utility to maintain index
integrity in FDS or is it not necessary?
Thank you
14 years, 12 months
[Fedora-directory-users] Windows sync woes
by John A. Sullivan III
Hello, all. I'm having grief trying to get DS 8.0 to synchronize with
Active Directory on Windows 2003 Server R2.
I first tried to synchronize an existing branch of DS with ntuser ids to
a fresh AD. That kept failing with sync total update aborted LDAP error
operations error code 1 and messages about failing to replay creation in
the errors log.
I then deleted the agreement, created a new empty branch in DS, and set
up a windows synchronization agreement. All the errors went away. I
also verified communication with
/usr/lib64/mozldap/ldapsearch -Z -P ./cert8.db -h <hostname> -p 636 -D
"cn=Synch Manager,cn=users,dc=some,dc=domain" -w - -s sub -b
"cn=Users,dc=some,dc=domain" "cn=*"
However, when I create a new user in DS, it does not propagate to AD. I
create the user, add the NT user option and set the uid as well as check
the create new account and delete account boxes.
The DS is set up as a single master. We do not want entries from AD
propagating to DS, just from DS to AD. We initially created the
synchronization user in AD as a member of domain admins. We also tried
making it a member of enterprise and schema admins. Nothing seems to
work.
We see nothing in the AD logs to indicate where the failure is. We see
very little on DS:
[20/Apr/2009:21:41:21 -0400] NSMMReplicationPlugin - Beginning total update of replica "agmt="cn=TestWinSync" (timberline:636)".
[20/Apr/2009:21:41:22 -0400] - Entry "uid=Guest,o=a0000-0012,o=Internal, dc=ssiservices, dc=biz" missing attribute "sn" required by object class "person"
[20/Apr/2009:21:41:22 -0400] - Entry "uid=SUPPORT_388945a0,o=a0000-0012,o=Internal, dc=ssiservices, dc=biz" missing attribute "sn" required by object clas
[20/Apr/2009:21:41:22 -0400] - Entry "uid=Administrator,o=a0000-0012,o=Internal, dc=ssiservices, dc=biz" missing attribute "sn" required by object class "
[20/Apr/2009:21:41:22 -0400] - Entry "uid=krbtgt,o=a0000-0012,o=Internal, dc=ssiservices, dc=biz" missing attribute "sn" required by object class "person"
[20/Apr/2009:21:41:22 -0400] NSMMReplicationPlugin - Finished total update of replica "agmt="cn=TestWinSync" (timberline:636)". Sent 18 entries.
[20/Apr/2009:21:43:07 -0400] NSMMReplicationPlugin - agmt="cn=TestWinSync" (timberline:636): windows_replay_update: Cannot replay add operation.
[20/Apr/2009:21:43:07 -0400] NSMMReplicationPlugin - agmt="cn=TestWinSync" (timberline:636): Simple bind resumed
[20/Apr/2009:21:48:06 -0400] NSMMReplicationPlugin - agmt="cn=TestWinSync" (timberline:636): Simple bind resumed
[20/Apr/2009:21:55:58 -0400] NSMMReplicationPlugin - agmt="cn=TestWinSync" (timberline:636): windows_replay_update: Cannot replay add operation.
[20/Apr/2009:21:55:58 -0400] NSMMReplicationPlugin - agmt="cn=TestWinSync" (timberline:636): Simple bind resumed
[20/Apr/2009:22:00:59 -0400] NSMMReplicationPlugin - agmt="cn=TestWinSync" (timberline:636): Simple bind resumed
I was surprised to see the entries for the Windows based users
propagating. They do not show up in DS. I'm assuming the replay add
operation failures are the attempts to add the user defined in DS. The
user was most minimal with only SN, givenname, cn, uid, password and the
above mentioned nt attributes set.
Not being very versed in AD, I'm sure I must be making some dumb mistake
but I don't see what it is. Any suggestions on where to look? Thanks -
John
--
John A. Sullivan III
Open Source Development Corporation
+1 207-985-7880
jsullivan(a)opensourcedevel.com
http://www.spiritualoutreach.com
Making Christianity intelligible to secular society
14 years, 12 months
[Fedora-directory-users] Am I on the right list?
by Juan Pablo Lorier
Hi guys, I posted about samba + fds a few days ago but didn't get any
reply. Maybe it's because this is not the right list?.
I just need a had because I can get openldap + samba working, but not
with fds.
regards
--
Este mensaje ha sido analizado por MailScanner
en busca de virus y otros contenidos peligrosos,
y se considera que está limpio.
14 years, 12 months
Re: [Fedora-directory-users] Re: fedora ds problem with updating centos
by Andy Schofield
> Andy Schofield wrote:
> I have exactly the same error:
> > ldap...[19/Apr/2009:06:46:14 -0400] - Unable to access
> > nsslapd-rundir: Bad address
Thanks Rich - it was fixed by your suggestion:
> mkdir -p /var/run/dirsrv/slapd-yourinstancename - chown to your
server > user id - chmod to make it rwx by the server user ID
> shutdown the directory server - Edit dse.ldif, the cn=config entry -
> add nsslapd-rundir: /var/run/dirsrv/slapd-yourinstancename
(SELinux was already running in permissive mode - sorry I should have
mentioned that in my initial post).
All seems to be working fine with 1.2.0 now.
15 years
