389DS architecture
by alexandre
Hello everybody,
I try to put 389DS in my compagny but we have already 4 Windows Domain
Controller and we want have 2 389DS server.
I know, I need a multi-master replication, but I ear about 4 multi-master
replication limitation. This one inclued Windows Domain controller ?
My architecture is possible ?
Sorry for my English, I'm from France.
Thanks in advance.
Best regards,
Alex
10 years
Re: [389-users] SSH public keys and 389?
by s.oreilly
On redhat/centos like systems you can install the openssh-ldap package so no
patching involved.
Regards
Sean O'Reilly
On Mon 25/03/13 1:20 PM , Vesa Alho listat(a)alho.fi sent:
> I think 389 side is "easy", but how about openssh-server and/or
> clients? Wondering do I need to patch openssh-server to get it working or is
> there an easier way.
>
> PS. thanks for responding!
>
> -Vesa
>
>
> On 03/25/2013 03:09 PM, s.oreilly wrote:
> > I have just done this. I will see if I can find
> the docs.>
> > You need to add an objectclass (ldappublickey)
> and an attribute (sshpublickey) to> the schema.
> >
> > Regards
> >
> >
> > Sean O'Reilly
> >
> > On Mon 25/03/13 1:02 PM , Vesa Alho listat(a)alho.fi
> sent:>> Hi,
> >>
> >> What would it take to store SSH public keys
> in 389?>>
> >> I found this old thread in archives, but
> mentioned link doesn't work:>>
http://www.mail-archive.com/389-users@lists.fedoraproject.org/msg02389.html>>
Other googling revealed guides which seem to
> require patched version of>> openssh-server and openldap
> guides.>>
> >> I guess freeipa would support this, but any
> chance with only 389?>>
> >> -Mr. Vesa Alho
> >> --
> >> 389 users mailing list
> >>
> >
389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users>>
> >
> > --
> > 389 users mailing list
> > 389-users(a)lists.fedoraproject.org>
https://admin.fedoraproject.org/mailman/listinfo/389-users>
>
> --
> 389 users mailing list
>
389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
10 years
Distributed Numeric Assignment plugin fails with indexing
by Scott Crooks
Greetings,
We're using 389-ds on CentOS 6.4 with 3 master LDAP servers in different
locations. All three master servers have a problem adding new users in
our organization database using the DNA plugin.
We receive the following (unhelpful) error message in the log files:
/[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD begin//
//[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD parameter untagged: uid//
//[22/Mar/2013:09:54:37 +0800] NSUniqueAttr - ADD
target=cn=testuser01,ou=Organizations,dc=test,dc=net//
//*[22/Mar/2013:09:54:37 +0800] dna-plugin - dna_pre_op: failed to
allocate a new ID!!*//*
*//*[22/Mar/2013:09:54:37 +0800] dna-plugin - dna_pre_op: operation
failure [1]*//*
*//[22/Mar/2013:09:54:37 +0800] roles-plugin - --> roles_post_op//
//[22/Mar/2013:09:54:37 +0800] roles-plugin - -->
roles_cache_change_notify//
//[22/Mar/2013:09:54:37 +0800] roles-plugin - <-- roles_post_op/
We've tried indexing the uidNumber and employeeNumber attributes as
described here:
*http://www.spinics.net/linux/fedora/389-users/msg10796.html*
One curious fact: there are exactly 1000 users in our database for
ou=Organizations,dc=test,dc=net. When following the instructions for the
above link, the log outputs the following
/*organizations: Indexing attribute: employeenumber*//*
*//*organizations: Indexed 1000 entries (97%).*//*
*//*organizations: Finished indexing.*//
/
Our organization uses employeenumber rather than uidNumber, but they're
the same in the end. We find it strange that the user creation fails at
*exactly* 1000 entries.
Any ideas on where the configuration is wrong? We assume it's a
configuration problem.
Untitled Document
Best Regards
Scott Crooks
Systems Engineer
scott.crooks(a)mcon.net <mailto:scott.crooks@mcon.net>
Phone: +86 10 8587 7441
Mobile: +86 138 1089 8314
http://www.mcon.net
Logo MCON China Ltd.
Suite 1202, e-Tower
12C Guanghua Road
Chaoyang District
Beijing 100020 *??????**?**? ??**?**(**? ?**)**????**
*?? ??????????12?
??01??1202?
??:100020
Member of mcon group: Australia . Austria . China . Czech Republic .
Germany . India . Japan . Malaysia . Russia . South Korea . Switzerland
. USA
10 years
Re: [389-users] SSH public keys and 389?
by s.oreilly
I have just done this. I will see if I can find the docs.
You need to add an objectclass (ldappublickey) and an attribute (sshpublickey) to
the schema.
Regards
Sean O'Reilly
On Mon 25/03/13 1:02 PM , Vesa Alho listat(a)alho.fi sent:
> Hi,
>
> What would it take to store SSH public keys in 389?
>
> I found this old thread in archives, but mentioned link doesn't work:
> http://www.mail-archive.com/389-users@lists.fedoraproject.org/msg02389.html
> Other googling revealed guides which seem to require patched version of
> openssh-server and openldap guides.
>
> I guess freeipa would support this, but any chance with only 389?
>
> -Mr. Vesa Alho
> --
> 389 users mailing list
>
389-users@lists.fedoraproject.orghttps://admin.fedoraproject.org/mailman/listinfo/389-users
>
10 years
centOS vs Redhat vs 389 and partial replication problems
by Morgan Jones
Hello everyone,
We've standardized on CentOS Directory our ~30,000 user directory environment. It's a 6 servers total: two multi-master, two read-only consumers with a full replication agreement and two read-only consumers with a partial replication.
We have a specific problem that we were *sure* was fixed in CentOS directory 8.2.8. It was not and now we're wondering if we'd be better off on 389 or Redhat Directory since we'd at least have reliable changelogs with the former and support to call for the latter.
Here's the problem, in the master error logs:
[19/Mar/2013:17:59:49 -0400] NSMMReplicationPlugin - agmt="cn=ldapm01-mgmt to ds01-mgmt" (ds01-mgmt:636): Failed to send update operation to consumer (uniqueid c3230b03-18e411e2-af56b819-045c296a, CSN 5148b7cd000100010000): Bad parameter to an ldap routine. Will retry later.
[19/Mar/2013:17:59:49 -0400] NSMMReplicationPlugin - agmt="cn=ldapm01-mgmt to ds02-mgmt" (ds02-mgmt:636): Failed to send update operation to consumer (uniqueid c3230b03-18e411e2-af56b819-045c296a, CSN 5148b7cd000100010000): Bad parameter to an ldap routine. Will retry later.
It repeats once every few seconds. Reinitializing replication solves it for a while, maybe an hour and then it re-occurs.
Recently we've started seeing this:
[21/Mar/2013:15:00:01 -0400] NSMMReplicationPlugin - agmt="cn=ldapm01-mgmt to ds01-mgmt" (ds01-mgmt:636): Unable to acquire replica: there is no replicated area "dc=philasd,dc=org" on the consumer server. Replication is aborting.
deleting the host as a replica and re-adding it solves it but it shouldn't be happening.
They were Sun Directory customers going to back to 5.2 so this product is comfortable for them but with the pain we've been feeling as we roll it into production we're trying to decide if we should consider alternatives.
Does anyone have insight on the problem above or on whether it's best to stick with CentOS, switch to Redhat or 389?
They're heavy users of open source and happy to self support. If Redhat support for directory is good they'd be happy to go that direction.
thanks,
-morgan
10 years
Possible to block large multivalued updates
by Jeffrey Dunham
I have run into a bug that is still open several times now causing large
problems in our LDAP Service. https://fedorahosted.org/389/ticket/346
We have group updates that are very large in size (20k+ records) and while
we're specifically targeting the engineering group responsible, there is
nothing to stop another group to write bad code and abuse our service.
When the large update occurs during replication of the group from our
master to our search fleet we often miss SLAs on replication and search
latency because the boxes go under such heavy load.
Is there a way on our master servers we can block people from preforming
such updates? Either to discard and error on the write or just drop that
traffic all together. I'm open to any sort of suggestion this list might
have to offer.
-Jeff
10 years
Replication Between 8.2 Master and 9.0 Master
by Paul Whitney
Hi everyone,
Not sure if this is the right forum to ask about RHDS vs 389DS, but....
I am currently using RHDS 8.2 and am looking to deploy 9.0 (master, hub, and consumer). Will I be able to replication between an 8.2 master and a 9.0 master?
I have looked in the Administration Guide on Rhed hat Customer Portal and only see references to RHDS 4.x (scratching my head why am I seeing references to 4.x and not anything related to 8.x.).
Paul M. Whitney
paul.whitney(a)icloud.com
Paul M. Whitney
paul.whitney(a)icloud.com
10 years
How to Managed Entries Plugin for Linux Users?
by Chandan Kumar
Hello,
I am deploying the 389 server (On CentOS 6) to manage the Linux
Users/Password. So as part of Linux User management, I was trying to get
the Managed Entries work for Posix user creation.
I am following the standard Redhat documentation.
https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9...
So I created the templates, exactly the way explained in the doc, but when
I create the users it is not creating corresponding Groups.
I am using following ldap commands to add entries. I could see the this
plugin created in from the console server -> data -> Plugins -> Managed
Entries -> <My plugin>
User creation statements
dn: uid=pappu1,ou=People,dc=ma,dc=net
objectclass: person
objectclass: inetorgperson
objectclass: posixAccount
cn: Pappu
sn: Papa
givenName: pappu1
uid:pappu1
uidNumber:9003
gidNumber:9003
objectclass: mepOriginEntry
mepManagedEntry: cn=Pappu Group
homeDirectory: /home/pappu1
The plugin
dn: cn=Posix User-Group,cn=Managed Entries,cn=plugins,cn=config
objectclass: extensibleObject
cn: Posix User-Group
originScope: ou=people,dc=ma,dc=ma
originFilter: objectclass=posixAccount
managedBase: ou=groups,dc=ma,dc=net
managedTemplate: cn=Posix User-Group Template,ou=Templates,dc=ma,dc=net
The template
dn: cn=Posix User-Group Template, ou=Templates,dc=ma,dc=net
objectclass: mepTemplateEntry
cn: Posix User-Group Template
mepRDNAttr: cn
mepStaticAttr: objectclass: posixGroup
mepMappedAttr: cn: $cn Group Entry
mepMappedAttr: gidNumber: $gidNumber
mepMappedAttr: memberUid: $uid
--
http://about.me/chandank
10 years
Windows Sync
by s.oreilly
Hi,
Am I correct in my understanding that I cannot sync OU's from Active Directory to
389-DS?
I am trying to sync users fro an AD server that I do not control and most of the
users are separated in to different OU's
Is there any way of making this work?
Regards
Sean O'Reilly
10 years
