[Freeipa-users] deploying FreeIPA
hello how is everyone doing? I do have a request, can you help me Deploying FreeIPA? I would apreciate any kind of help thank you for your time Jose Mora ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeIPA replication
Виктор Сергеевич wrote: Hi! Thanks! It works!, but In master-server I'm see users in groups, but in replica I'm see only group, without users. If search users - i'm can find it. And one more: Strange, that shouldn't happen. I'd search for them directly in LDAP to ensure it isn't a problem with the IPA management framework: % ldapsearch -x -b cn=users,cn=accounts,dc=example,dc=com (objectclass=posixuser) uid If I write users (Firsname and/ore lastname)in cyrillic symbols (russian language), save this user and try find it - I'm see 500 - internal server error. An unexpected error occured. Prompt please - as with it it is possible to consult how This is a known problem (https://bugzilla.redhat.com/show_bug.cgi?id=490285). IPA v1 only supports the ASCII character set currently. rob Thanks В Птн, 11/12/2009 в 13:07 -0700, Rich Megginson пишет: James Roman wrote: If I remember correctly, I had to comment out the following entries in the /etc/dirsrv/slapd-/schema/99user.ldif file: # objectClasses: ( 2.16.840.1.113730.3.2.300 NAME 'nsAIMpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY (nsaimid $ nsaimstatusgraphic $ nsaimstatustext ) X-ORIGIN ( 'Netscape Directory Server' 'user defined' ) ) # objectClasses: ( 2.16.840.1.113730.3.2.301 NAME 'nsICQpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY ( nsicqid $ nsicqstatusgraphic $ nsICQStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user defined' ) ) # objectClasses: ( 2.16.840.1.113730.3.2.302 NAME 'nsYIMpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY ( nsyimid $ nsyimstatusgraphic $ nsYIMStatusText ) X-ORIGIN ( 'Netscape Directory Server' 'user defined' ) ) # objectClasses: ( 2.16.840.1.113730.3.2.303 NAME 'nsMSNpresence' DESC 'Netscape defined objectclass' SUP top AUXILIARY MAY nsmsnid X-ORIGIN ( 'Netscape Dir ectory Server' 'user defined' ) ) That should work. The problem is that these schema should never have been in 99user.ldif in the first place. The code has been fixed so that standard schema such as these will not be copied to 99user.ldif, and setup-ds.pl -u in 389-ds-base 1.2.3 and later will clean up 99user.ldif of these and other bogus schema. Rich Megginson wrote: Rob Crittenden wrote: Виктор Сергеевич wrote: On fedora 11: Name: 389-ds-base Relocations: (not relocatable) Version : 1.2.2 Vendor: Fedora Project Release : 1.fc11Build Date: Wed 26 Aug 2009 12:07:44 AM MSD Install Date: Fri 11 Dec 2009 10:46:32 AM MSK Build Host: x86-1.fedora.phx.redhat.com Group : System Environment/DaemonsSource RPM: 389-ds-base-1.2.2-1.fc11.src.rpm Size: 5080205 License: GPLv2 with exceptions Signature : RSA/SHA1, Wed 26 Aug 2009 04:34:33 PM MSD, Key ID 1dc5c758d22e77f2 Packager: Fedora Project URL : http://port389.org/ Summary : 389 Directory Server (base) IIRC in 389-ds 1.2.2 some schema was dropped/modified. If you try to replicate between 1.2.2 and = 1.2.2 you can get this error because the schema isn't defined on one side. I'm not sure the best way to work around this. Options include: - sync up the 389-ds versions between your servers. This would likely require building your own set of rpms on one or the other. - add the missing schema to the F-11 server in /etc/dirsrv/schema. This has the downside that you'll probably end up broken in other very odd some time way into the future. - modify 99user.ldif on the replicated system and remove the offending attributes. At the point in the replica installation where this fails the installer is almost done. The only missing steps are the DNS configuration and configuring the client. There may be other options, and again I'm not sure which is the best at this point. Rich, what do you think? With 389-ds-base 1.2.3 and later (1.2.5.rc2 is currently available from the testing repos) 99user.ldif is fixed to remove the offending schema upon upgrade (yum or rpm), or by doing setup-ds.pl -u. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] deploying FreeIPA
On 12/12/2009 12:50 AM, jose mora wrote: hello how is everyone doing? I do have a request, can you help me Deploying FreeIPA? I would apreciate any kind of help thank you for your time Jose Mora We would like to help you but first you need to tell us what you need help with. -- John Dennis jden...@redhat.com Looking to carve out IT costs? www.redhat.com/carveoutcosts/ ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeIPA replication
Rob Crittenden wrote: Виктор Сергеевич wrote: Hi! Thanks! It works!, but In master-server I'm see users in groups, but in replica I'm see only group, without users. If search users - i'm can find it. And one more: Strange, that shouldn't happen. I'd search for them directly in LDAP to ensure it isn't a problem with the IPA management framework: Are you sure your describing this correctly. When I built my replica, initially, I could see that groups were synchronized (I could search for groups and I could see the members), but the memberof attributes of individual user entries was not available in the replica server. These are not synchronized by default, you must enable the plug-in to generate the entries. # ldapmodify -x -W -D cn=Directory Manager dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on I've also seen the memberof entries disappear after performing an ipa-replica-manage init replicaserver. This was much harder to address. I performed a lookup of the ipausers group members, stripped the entries down to just the uid and then ran then through a script that removed each entry and re-added them to the ipausers group, which forced the plug-in to recreate all memberof entries on all accounts. (Thank god I didn't have to do that on all the groups.) There are two member related plugins now a freeipa one and a 389 plugin. Not sure if they are stepping on each other or not. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] freeIPA replication
James Roman wrote: Rob Crittenden wrote: Виктор Сергеевич wrote: Hi! Thanks! It works!, but In master-server I'm see users in groups, but in replica I'm see only group, without users. If search users - i'm can find it. And one more: Strange, that shouldn't happen. I'd search for them directly in LDAP to ensure it isn't a problem with the IPA management framework: Are you sure your describing this correctly. When I built my replica, initially, I could see that groups were synchronized (I could search for groups and I could see the members), but the memberof attributes of individual user entries was not available in the replica server. These are not synchronized by default, you must enable the plug-in to generate the entries. Yes, I think I misread his statement. I read it as I have groups but no users not I have groups that contain no users. # ldapmodify -x -W -D cn=Directory Manager dn: cn=MemberOf Plugin,cn=plugins,cn=config changetype: modify replace: nsslapd-pluginEnabled nsslapd-pluginEnabled: on I've also seen the memberof entries disappear after performing an ipa-replica-manage init replicaserver. This was much harder to address. I performed a lookup of the ipausers group members, stripped the entries down to just the uid and then ran then through a script that removed each entry and re-added them to the ipausers group, which forced the plug-in to recreate all memberof entries on all accounts. (Thank god I didn't have to do that on all the groups.) There are two member related plugins now a freeipa one and a 389 plugin. Not sure if they are stepping on each other or not. Right, the plugin was developed in IPA and moved into DS. In the next version of IPA we are dropping our plugin in favor of the DS version. You really don't want both enabled at once, who knows what problems that could cause. memberOf isn't a replicated attribute. It is built separately on each IPA server. You can force the attribute to be rebuilt by creating a DS task and using ldapmodify to apply it. Something like: # cp /usr/share/ipa/memberof-task.ldif /tmp/memberof-task.ldif [edit /tmp/memberof-task.ldif anre placed $TIME with some unique number and $SUFFIX with dc=example,ed=com as appropriate] # ldapmodify -x -D cn=directory manager -W /tmp/memberof-task.ldif You'll be prompted for your DM password. This should rebuild all the local memberOf entries. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
