[Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
Hello everyone. I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). - ipa-ldap-updater stumbles over two problems: - Pre schema upgrade failed - when trying to modify cn=encryption,cn=config, it stumbles over allowWeakCipher not allowed Does anyone know how to fix this? Is the pre schema upgrade failure spurious? what bits am I missing about the allowWeakCipher issue? Thomas 2015-05-28T13:04:55Z DEBUG [4/10]: starting directory server 2015-05-28T13:04:55Z DEBUG Starting external process 2015-05-28T13:04:55Z DEBUG args='/bin/systemctl' 'start' 'dirsrv@X-COM.service' 2015-05-28T13:04:55Z DEBUG Process finished, return code=0 2015-05-28T13:04:55Z DEBUG stdout= 2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:04:55Z DEBUG duration: 0 seconds 2015-05-28T13:04:55Z DEBUG [5/10]: preparing server upgrade 2015-05-28T13:05:36Z ERROR Pre schema upgrade failed with [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 220, in __init__ self.create_connection() File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG duration: 40 seconds 2015-05-28T13:05:36Z DEBUG [6/10]: updating schema 2015-05-28T13:05:46Z DEBUG Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 388, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 378, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File "/usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py", line 112, in update_schema fqdn=installutils.get_fqdn()) File "/usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py", line 65, in connect conn.do_external_bind(pw_name) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [error] error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [cleanup]: stopping directory server 2015-05-28T13:05:46Z DEBUG Starting external process 2015-05-28T13:05:46Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv@X-COM.service' 2015-05-28T13:05:46Z DEBUG Process finished, return code=0 2015-05-28T13:05:46Z DEBUG stdout= 2015-05-28T13:05:46Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG [cleanup]: restoring configuration 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 171, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_upda
Re: [Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4
Hm. @Jakub : I cannot upgrade, because I am not the hosting provider managing this VM unfortunately. I need to make it work with RHEL 6.4. @Sam : Selinux is deactivated : cat /etc/selinux/config # This file controls the state of SELinux on the system. # SELINUX=disabled # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted Best regards. Bahan On Fri, May 29, 2015 at 6:39 PM, wrote: > Seem to be a fair few things implicating selinux there. > > Have you got it set to enforcing mode? If so, have you set any particular > policy that may be angered by this? > > Sam > > > May 29 2015 5:37 PM, "bahan w" <%22bahan%20w%22%20%3cbahanw042...@gmail.com%3E>> wrote: > > Hello everyone. > > I send you this mail because I have a problem with the installation of > FreeIPA Server 3.0 on a VM running on RHEL 6.4. > > First, when I performed the yum install ipa-server, I got an error but the > installation finished finally with a complete. > Here it is : > > > > === > Install 4 Package(s) > > Total download size: 1.4 M > Installed size: 4.6 M > Is this ok [y/N]: y > Downloading Packages: > (1/4): ipa-admintools-3.0.0-42.el6.x86_64.rpm | 67 kB 00:00 > (2/4): ipa-client-3.0.0-42.el6.x86_64.rpm | 145 kB 00:00 > (3/4): ipa-server-3.0.0-42.el6.x86_64.rpm | 1.1 MB 00:00 > (4/4): ipa-server-selinux-3.0.0-42.el6.x86_64.rpm | 66 kB 00:00 > > --- > Total 7.3 MB/s | 1.4 MB 00:00 > Total 7.3 MB/s | 1.4 MB 00:00 > Running rpm_check_debug > Running Transaction Test > Transaction Test Succeeded > Running Transaction > Installing : ipa-client-3.0.0-42.el6.x86_64 1/4 > Installing : ipa-admintools-3.0.0-42.el6.x86_64 2/4 > Installing : ipa-server-3.0.0-42.el6.x86_64 3/4 > Installing : ipa-server-selinux-3.0.0-42.el6.x86_64 4/4 > libsepol.print_missing_requirements: ipa_dogtag's global requirements were > not met: type/attribute pki_ca_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > Verifying : ipa-server-3.0.0-42.el6.x86_64 1/4 > Verifying : ipa-server-selinux-3.0.0-42.el6.x86_64 2/4 > Verifying : ipa-client-3.0.0-42.el6.x86_64 3/4 > Verifying : ipa-admintools-3.0.0-42.el6.x86_64 > > Installed: > ipa-server.x86_64 0:3.0.0-42.el6 > > Dependency Installed: > ipa-admintools.x86_64 0:3.0.0-42.el6 ipa-client.x86_64 0:3.0.0-42.el6 > ipa-server-selinux.x86_64 0:3.0.0-42.el6 > > Complete! > > Are these two errors blocking in order to use FreeIPA Server ? Or is it > fine ? > libsepol.print_missing_requirements: ipa_dogtag's global requirements were > not met: type/attribute pki_ca_t (No such file or directory). > libsemanage.semanage_link_sandbox: Link packages failed (No such file or > directory). > semodule: Failed! > > Furthermore, when I try a ipa-server-install, I got also an error message > during step > > > Configuring directory server (dirsrv): Estimated time 1 minute > [1/38]: creating directory server user > [2/38]: creating directory server instance > ipa : CRITICAL failed to create ds instance Command '/usr/sbin/ > setup-ds.pl --silent --logfile - -f /tmp/tmpPamNs8' returned non-zero > exit status 1 > > > And when I checked in the log, here is what I see > > Here is the message I see : > > 2015-05-29T15:56:49Z DEBUG calling setup-ds.pl > 4944 2015-05-29T15:56:49Z DEBUG args=/usr/sbin/setup-ds.pl --silent > --logfile - -f /tmp/tmpkCAtzh > 4945 2015-05-29T15:56:49Z DEBUG stdout=[15/05/29:17:56:49] - [Setup] Info > Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 32256. > Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission > denied > 4946 > 4947 Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: > 32256. Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission > denied > 4948 > 4949 [15/05/29:17:56:49] - [Setup] Fatal Error: Could not create directory > server instance 'MyRealm'. > 4950 Error: Could not create directory server instance 'MyRealm'. > 4951 [15/05/29:17:56:49] - [Setup] Fatal Exiting . . . > > > When I check the perm on the folders, everything is fine : > >
Re: [Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4
On Fri, May 29, 2015 at 06:25:24PM +0200, bahan w wrote: > Hello everyone. > > I send you this mail because I have a problem with the installation of > FreeIPA Server 3.0 on a VM running on RHEL 6.4. This is really old, please upgrade if you can, ideally to RHEL-7. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Problem to install FreeIPA Server 3.0 on a RedHat 6.4
Hello everyone. I send you this mail because I have a problem with the installation of FreeIPA Server 3.0 on a VM running on RHEL 6.4. First, when I performed the yum install ipa-server, I got an error but the installation finished finally with a complete. Here it is : === Install 4 Package(s) Total download size: 1.4 M Installed size: 4.6 M Is this ok [y/N]: y Downloading Packages: (1/4): ipa-admintools-3.0.0-42.el6.x86_64.rpm | 67 kB 00:00 (2/4): ipa-client-3.0.0-42.el6.x86_64.rpm | 145 kB 00:00 (3/4): ipa-server-3.0.0-42.el6.x86_64.rpm | 1.1 MB 00:00 (4/4): ipa-server-selinux-3.0.0-42.el6.x86_64.rpm | 66 kB 00:00 --- Total 7.3 MB/s | 1.4 MB 00:00 Total 7.3 MB/s | 1.4 MB 00:00 Running rpm_check_debug Running Transaction Test Transaction Test Succeeded Running Transaction Installing : ipa-client-3.0.0-42.el6.x86_64 1/4 Installing : ipa-admintools-3.0.0-42.el6.x86_64 2/4 Installing : ipa-server-3.0.0-42.el6.x86_64 3/4 Installing : ipa-server-selinux-3.0.0-42.el6.x86_64 4/4 libsepol.print_missing_requirements: ipa_dogtag's global requirements were not met: type/attribute pki_ca_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! Verifying : ipa-server-3.0.0-42.el6.x86_64 1/4 Verifying : ipa-server-selinux-3.0.0-42.el6.x86_64 2/4 Verifying : ipa-client-3.0.0-42.el6.x86_64 3/4 Verifying : ipa-admintools-3.0.0-42.el6.x86_64 Installed: ipa-server.x86_64 0:3.0.0-42.el6 Dependency Installed: ipa-admintools.x86_64 0:3.0.0-42.el6 ipa-client.x86_64 0:3.0.0-42.el6 ipa-server-selinux.x86_64 0:3.0.0-42.el6 Complete! Are these two errors blocking in order to use FreeIPA Server ? Or is it fine ? libsepol.print_missing_requirements: ipa_dogtag's global requirements were not met: type/attribute pki_ca_t (No such file or directory). libsemanage.semanage_link_sandbox: Link packages failed (No such file or directory). semodule: Failed! Furthermore, when I try a ipa-server-install, I got also an error message during step Configuring directory server (dirsrv): Estimated time 1 minute [1/38]: creating directory server user [2/38]: creating directory server instance ipa : CRITICAL failed to create ds instance Command '/usr/sbin/ setup-ds.pl --silent --logfile - -f /tmp/tmpPamNs8' returned non-zero exit status 1 And when I checked in the log, here is what I see Here is the message I see : 2015-05-29T15:56:49Z DEBUG calling setup-ds.pl 4944 2015-05-29T15:56:49Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmpkCAtzh 4945 2015-05-29T15:56:49Z DEBUG stdout=[15/05/29:17:56:49] - [Setup] Info Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 32256. Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission denied 4946 4947 Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 32256. Output: sh: /var/lib/dirsrv/scripts-MyRealm/ldif2db: Permission denied 4948 4949 [15/05/29:17:56:49] - [Setup] Fatal Error: Could not create directory server instance 'MyRealm'. 4950 Error: Could not create directory server instance 'MyRealm'. 4951 [15/05/29:17:56:49] - [Setup] Fatal Exiting . . . When I check the perm on the folders, everything is fine : ls -ld /var/lib/dirsrv/ drwxrwxr-x 5 root dirsrv 4096 May 29 18:19 /var/lib/dirsrv/ ls -l /var/lib/dirsrv/ drwxrwx--- 2 dirsrv dirsrv 4096 May 29 18:19 scripts-MYREALM drwxrwx--- 5 dirsrv dirsrv 4096 May 29 18:19 slapd-MYREALM drwxrwx--- 5 pkisrv dirsrv 4096 May 29 18:18 slapd-PKI-IPA ls -l /var/lib/dirsrv/scripts-MYREALM/ -r-xr-x--- 1 dirsrv dirsrv 1212 May 29 18:19 bak2db -r-xr-x--- 1 dirsrv dirsrv 5661 May 29 18:19 bak2db.pl -r-xr-x--- 1 dirsrv dirsrv 6018 May 29 18:19 cleanallruv.pl -r-xr-x--- 1 dirsrv dirsrv 1134 May 29 18:19 db2bak -r-xr-x--- 1 dirsrv dirsrv 5397 May 29 18:19 db2bak.pl -r-xr-x--- 1 dirsrv dirsrv 759 May 29 18:19 db2index -r-xr-x--- 1 dirsrv dirsrv 8129 May 29 18:19 db2index.pl -r-xr-x--- 1 dirsrv dirsrv 2053 May 29 18:19 db2ldif -r-xr-x--- 1 dirsrv dirsrv 10093 May 29 18:19 db2ldif.pl -r-xr-x--- 1 dirsrv dirsrv 932 May 29 18:19 dbverify -r-xr-x--- 1 dirsrv dirsrv 499 May 29 18:19 dn2rdn -r-xr-x--- 1 dirsrv dirsrv 5560 May 29 18:19 fixup-linkedattrs.pl -r-xr-x--- 1 dirsrv dirsrv 5896 May 29 18:19 fixup-memberof.pl -r-xr-x--- 1 dirsrv dirsrv 729 May 29 18:19 ldif2db -r-xr-x--- 1 dirsrv dirsrv 8826 May 29 18:19 ldif2
Re: [Freeipa-users] ssh problem with migrated FreeIPA client on EL7.1
On Fri, 29 May 2015, Christopher Lamb wrote: Hi All Some weeks ago I setup a new FreeIPA 4.1.0 on an OEL 7.1 server to replace the existing FreeIPA 3.0.0 running on OEL 6.5, and successfully migrated across the users. We have 50 odd Servers that are FreeIPA clients. Today I started migrating these one-by-one from the old FreeIPA 3.x server to the new FreeIPA 4 server by doing an ipa-client-install --uninstall from the old, and ipa-client-install to register with the new 4.1.0 server. Most of the FreeIPA clients are running OEL 6.5, and for these the migration process above worked perfectly. After migrating the server, I could ssh in with my FreeIPA user. Then I migrated an OEL 7.1 server. The migration itself seemed to work, and getent passwd was successful for my FreeIPA user. However when I try and ssh in, my FreeIPA user / password is not accepted. Before the migration I could ssh into the problem server (though evidently it was using my FreeIPA user from the old FreeIPA server). I can ssh in with a local (non ldap) user, so ssh is running and working. From user root I can successfully su to my FreeIPA user. Further investigation showed that version of ipa-client installed was 3.3.3, so I yum updated this to 4.1.0. However I still cannot ssh into the OEL 7.1 box with my FreeIPA user. The same user continues to work for the 6.5 boxes. A colleague tried to ssh in with his FreeIPA user, and was also rejected, so the problem is not my user, but is probably for all FreeIPA users. A failed ssh login attempt causes the following error in /var/log/messages [sssd[krb5_child[5393]]]: Decrypt integrity check failed It means /etc/krb5.keytab contains keys from older system and SSSD picks them up. Can you show output of 'klist -kKet'? -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ssh problem with migrated FreeIPA client on EL7.1
Hi All Some weeks ago I setup a new FreeIPA 4.1.0 on an OEL 7.1 server to replace the existing FreeIPA 3.0.0 running on OEL 6.5, and successfully migrated across the users. We have 50 odd Servers that are FreeIPA clients. Today I started migrating these one-by-one from the old FreeIPA 3.x server to the new FreeIPA 4 server by doing an ipa-client-install --uninstall from the old, and ipa-client-install to register with the new 4.1.0 server. Most of the FreeIPA clients are running OEL 6.5, and for these the migration process above worked perfectly. After migrating the server, I could ssh in with my FreeIPA user. Then I migrated an OEL 7.1 server. The migration itself seemed to work, and getent passwd was successful for my FreeIPA user. However when I try and ssh in, my FreeIPA user / password is not accepted. Before the migration I could ssh into the problem server (though evidently it was using my FreeIPA user from the old FreeIPA server). I can ssh in with a local (non ldap) user, so ssh is running and working. >From user root I can successfully su to my FreeIPA user. Further investigation showed that version of ipa-client installed was 3.3.3, so I yum updated this to 4.1.0. However I still cannot ssh into the OEL 7.1 box with my FreeIPA user. The same user continues to work for the 6.5 boxes. A colleague tried to ssh in with his FreeIPA user, and was also rejected, so the problem is not my user, but is probably for all FreeIPA users. A failed ssh login attempt causes the following error in /var/log/messages [sssd[krb5_child[5393]]]: Decrypt integrity check failed Any ideas? Cheers Chris -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv keytab revoked
On Fri, 2015-05-29 at 10:06 +0200, Martin Kosek wrote: > On 05/29/2015 07:48 AM, Christoph Kaminski wrote: > > Hi > > > > I have had a defect entries in ldap for a replica and deleted them. But now > > the > > dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The > > replica starts but it cant connect other replicas (but other replicas can > > connect to it). > > > > I have tried: > > kinit -k -t /etc/dirsrv/ds.keytab > > ldap/ipa-1.mgmt.testsystem-homemonitoring.int > > > > and got: > > kinit: Clients credentials have been revoked while getting initial > > credentials > > > > It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab > > (on this replica) doesnt work. > > Running ipa-getkeytab on this replica is tricky - as if replication is down > and > you do this, the old key is revoked and new one is generated - which is not > known for the other master as replication is not working and you get in a > strange situation. > > You can try to log to your active master, do ipa-getkeytab for the broken > replica, copy the keytab there, restart DS and then run re-initialize to > reload > all the data from active master. It may work. No need to login and copy stuff, just point ipa-getkeytab at the other master with the -s switch. Once you've done that, restart the replica, however there are chances it will then try to get a TGT to replicate against the local KDC and it will fail because the local KDC has the old key. One way to help this is to temporarily change krb5.conf to explicitly point to a "good" replica so that KDC operations will be handled by that other replica, restart all IPA components and make sure a round of replication happens. Then restore the krb5.conf file and restart all. > > Or it is better to destroy it and do a new install? > > That may be even faster for the making that particular replica up and running > again, if you do not want to dig too much in this issue. If the play above doesn't help, it will be simpler to reinstall the replica indeed. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Antwort: Re: Haunted servers?
>
> On May 29, 2015, at 00:41, thierry bordaz wrote:
>
>> On 05/29/2015 08:16 AM, Christoph Kaminski wrote:
>> freeipa-users-boun...@redhat.com schrieb am 28.05.2015 13:23:26:
>>
>> > Von: Alexander Frolushkin
>> > An: "'thierry bordaz'"
>> > Kopie: "freeipa-users@redhat.com"
>> > Datum: 28.05.2015 13:24
>> > Betreff: Re: [Freeipa-users] Haunted servers?
>> > Gesendet von: freeipa-users-boun...@redhat.com
>> >
>> > Unfortunately, after a couple of minutes, on two of three servers
>> > error comes back in little changed form:
>> > # ipa-replica-manage list-ruv
>> > unable to decode: {replica 16}
>> >
>> >
>> > Before cleanruv it looked like:
>> > # ipa-replica-manage list-ruv
>> > unable to decode: {replica 16} 548a81260010 548a81260010
>> >
>> >
>> > And one server seems to be fixed completely.
>> >
>> > WBR,
>> > Alexander Frolushkin
>> >
>> >
>>
>> we had the same problem (and some more) and yesterday we have successfully
>> cleaned the gohst rid's
>>
>> our fix:
>
> Hi Christoph,
>
> THanks for sharing this procedure. This bug is difficult to workaround and
> that is a good idea to write it down.
>
>>
>> 1. stop all cleanallruv Tasks, if it works with ipa-replica-manage
>> abort-clean-ruv. It hasnt worked here. We have done it manually on ALL
>> replicas with:
>> a) replica stop
>> b) delete all nsds5ReplicaClean from /etc/dirsrv/slapd-HSO/dse.ldif
>> c) replica start
> Yes the ability to abort clean ruv hits the same retry issue that
> cleanallruv. It has been addressed with
> https://fedorahosted.org/389/ticket/48154
>> 2. prepare on EACH ipa a cleanruv ldif file with ALL ghost rids inside
>> (really ALL from all ipa replicas, we has had some rids only on some
>> replicas...)
>> Example:
>>
>> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
>> changetype: modify
>> replace: nsds5task
>> nsds5task:CLEANRUV11
>>
>> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
>> changetype: modify
>> replace: nsds5task
>> nsds5task:CLEANRUV22
>>
>> dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
>> changetype: modify
>> replace: nsds5task
>> nsds5task:CLEANRUV37
>> ...
>
> It should work but I would prefer to do it in an other order.
> We need to clean a specific RID, on all replica, at the same time. We do not
> need to clean all RIDs at the same time.
> Having several CLEANRUV in parallel for differents RID should work but I do
> not know how much it has been tested that way.
>
> So I would recommend to clean, in parallel on all replicas, RID 11. Then when
> it is completed, RID 22. Then RID 37.
>
>>
>> 3. do a "ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -W -x -f
>> $your-cleanruv-file.ldif" on all replicas AT THE SAME TIME :) we used
>> terminator for it (https://launchpad.net/terminator). You can open multiple
>> shell windows inside one window and send to all at the same time the same
>> commands...
>
> same remark I would split your-cleanruv-file.ldif into three files
> cleanruv-11-file.ldif,...
>>
>> 4. we have done a re-initialize of each IPA from our first master
>
> Do you mean a total init ? I do not see a real need for that.
> If you are ready to reinit all replicas, there is a very simple way to get
> rid of all these ghost RIDs.
> Select the "good" master that is having all the updates
> do a ldif export without the replication data
> do a ldif import of exported file
> do online reinit of the full topology, cascading from the "good" master down
> to the "consumers"
> Most of the time we try to avoid asking a full reinit of the topology because
> DB are large.
>>
>> 5. restart of all replicas
>>
>> we are not sure about the point 3 and 4. Maybe they are not necessary, but
>> we have done it.
>>
>> If something fails look at defect LDAP entries in whole ldap, we have had
>> some entries with 'nsunique-$HASH' after the 'normal' name. We have deleted
>> them.
> do you mean entries with 'nsuniqueid' attribute in the RDN. This could be
> create during replication conflicts when updates are received in parallele on
> different replicas.
>
>
> thanks
> thierry
>>
>> MfG
>> Christoph Kaminski
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
Looks like I'll be giving this a try. So glad someone else is seeing exactly
the same issues. Hopefully soon we can find the cause.
~J--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
[Freeipa-users] vSphere and freeIPA
Afternoon, I'm currently attempting to set up an existing vsphere environment to use freeipa 4.1.0 for authentication, following this guide: http://www.freeipa.org/page/HowTo/vsphere5_integration I've followed it all through, and for the purposes for testing, I've created a user called sam that's a member of a group called samtest: [root@ldap1 ~]# ldapsearch -x -D "uid=ldapauth,cn=users,cn=accounts,dc=example,dc=hostname,dc=co,dc=uk" -w passwordgoeshere -b "cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk" cn=samtest # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=samtest # requesting: ALL # # samtest, groups, compat, example.hostname.co.uk dn: cn=samtest,cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk objectClass: groupOfUniqueNames objectClass: top uniqueMember: uid=sam,cn=users,cn=compat,dc=example,dc=hostname,dc=co,dc= uk cn: samtest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 With only sam in the samtest group, the uniqueMember attribute that vsphere seems to depend on displays fine, and you can log into vsphere as the sam user if samtest has been given the correct permissions. The issue arises when a second user (chris) is added to the samtest group. [root@ldap1 ~]# ldapsearch -x -D "uid=ldapauth,cn=users,cn=accounts,dc=example,dc=hostname,dc=co,dc=uk" -w passwordgoeshere -b "cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk" cn=samtest # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=samtest # requesting: ALL # # samtest, groups, compat, example.hostname.co.uk dn: cn=samtest,cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk objectClass: groupOfUniqueNames objectClass: top cn: samtest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 This causes the uniqueMember attribute to not display for either sam or chris, and neither user can access vsphere. However if sam is removed from samtest, then uniqueMember is once again shown: [root@ldap1 ~]# ldapsearch -x -D "uid=ldapauth,cn=users,cn=accounts,dc=example,dc=hostname,dc=co,dc=uk" -w passwordgoeshere -b "cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk" cn=samtest # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=samtest # requesting: ALL # # samtest, groups, compat, example.hostname.co.uk dn: cn=samtest,cn=groups,cn=compat,dc=example,dc=hostname,dc=co,dc=uk objectClass: groupOfUniqueNames objectClass: top uniqueMember: uid=chris,cn=users,cn=compat,dc=example,dc=hostname,dc=co,d c=uk cn: samtest # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 If anyone could shed any light on this behaviour, or point out any flaws in my logic/understanding, it would be greatly appreciated. Kind regards, Sam -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE
On 05/29/2015 11:18 AM, David Lin wrote: the other hosts do not have certificate set. What IPA version is it? host-find/show should use /etc/httpd/alias dir, as Martin wrote. Could you check if there is anything wrong with this directory, e.g. missing files, missing dir, wrong SELinux context. Do you have selinux error? My default installation has: ls -l -a -Z /etc/httpd/alias/ drwxr-xr-x. root root system_u:object_r:cert_t:s0 . drwxr-xr-x. root root system_u:object_r:httpd_config_t:s0 .. -r--r--r--. root root unconfined_u:object_r:cert_t:s0 cacert.asc -rw-rw. root apache unconfined_u:object_r:cert_t:s0 cert8.db -rw-r-. root apache system_u:object_r:cert_t:s0 cert8.db.orig -rw---. root root system_u:object_r:cert_t:s0 install.log -rw-rw. root apache unconfined_u:object_r:cert_t:s0 key3.db -rw-r-. root apache system_u:object_r:cert_t:s0 key3.db.orig lrwxrwxrwx. root root system_u:object_r:cert_t:s0 libnssckbi.so -> ../../..//usr/lib64/libnssckbi.so -rw-rw. root apache unconfined_u:object_r:cert_t:s0 pwdfile.txt -rw-rw. root apache unconfined_u:object_r:cert_t:s0 secmod.db -rw-r-. root apache system_u:object_r:cert_t:s0 secmod.db.orig ls -l -a -Z /etc/httpd/ drwxr-xr-x. root root system_u:object_r:cert_t:s0 alias Other way could to check if the initialization really uses the /etc/httpd/alias dir. This could be done by inserting print dbdir into def load_certificate function in /usr/lib/python2.7/site-packages/ipalib/x509.py, line ~ 112 ouput will be in /var/log/httpd/error_log Thanks, David On 05/29/2015 02:05 AM, Petr Vobornik wrote: On 05/29/2015 10:45 AM, David Lin wrote: ipa host-find produces this ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. and ipa host-show on only one of the hosts show ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. all the other hosts are fine. Does any other host have certificate set? I want to find out if it fails on a specific certificate and not on other(s) or if it fails for all hosts with certificate set. SEC_ERROR_LEGACY_DATABASE error suggests that it fails on initialization of NSS database which is not dependent on stored certificate. Thanks! David On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: On 05/29/2015 10:02 AM, Martin Kosek wrote: On 05/29/2015 01:27 AM, David Lin wrote: Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, This means that Web UI calls `ipa host-find` and couple of `ipa host-show` commands. Could you try it in CLI find out which command fails? So other web ui tabs work? Does service tab work(services has some common logic with hosts)? I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database directory (for any reason, including non-existent directory) That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was somehow damaged? Although I doubt that, in that case Apache would not be able to serve https even. +1 On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. If you are using FreeIPA 4.1+, this is expected: https://fedorahosted.org/freeipa/ticket/4449 Martin -- Petr Vobornik -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Antwort: Re: dirsrv keytab revoked
Martin Kosek schrieb am 29.05.2015 10:06:45: > > Running ipa-getkeytab on this replica is tricky - as if replication > is down and > you do this, the old key is revoked and new one is generated - which is not > known for the other master as replication is not working and you get in a > strange situation. > > You can try to log to your active master, do ipa-getkeytab for the broken > replica, copy the keytab there, restart DS and then run re- > initialize to reload > all the data from active master. It may work. > > > Or it is better to destroy it and do a new install? > > That may be even faster for the making that particular replica up and running > again, if you do not want to dig too much in this issue. yep done it on other replica and it works, thx! MfG Christoph Kaminski -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE
the other hosts do not have certificate set. Thanks, David On 05/29/2015 02:05 AM, Petr Vobornik wrote: On 05/29/2015 10:45 AM, David Lin wrote: ipa host-find produces this ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. and ipa host-show on only one of the hosts show ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. all the other hosts are fine. Does any other host have certificate set? I want to find out if it fails on a specific certificate and not on other(s) or if it fails for all hosts with certificate set. SEC_ERROR_LEGACY_DATABASE error suggests that it fails on initialization of NSS database which is not dependent on stored certificate. Thanks! David On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: On 05/29/2015 10:02 AM, Martin Kosek wrote: On 05/29/2015 01:27 AM, David Lin wrote: Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, This means that Web UI calls `ipa host-find` and couple of `ipa host-show` commands. Could you try it in CLI find out which command fails? So other web ui tabs work? Does service tab work(services has some common logic with hosts)? I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database directory (for any reason, including non-existent directory) That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was somehow damaged? Although I doubt that, in that case Apache would not be able to serve https even. +1 On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. If you are using FreeIPA 4.1+, this is expected: https://fedorahosted.org/freeipa/ticket/4449 Martin -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE
On 05/29/2015 10:45 AM, David Lin wrote: ipa host-find produces this ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. and ipa host-show on only one of the hosts show ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. all the other hosts are fine. Does any other host have certificate set? I want to find out if it fails on a specific certificate and not on other(s) or if it fails for all hosts with certificate set. SEC_ERROR_LEGACY_DATABASE error suggests that it fails on initialization of NSS database which is not dependent on stored certificate. Thanks! David On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: On 05/29/2015 10:02 AM, Martin Kosek wrote: On 05/29/2015 01:27 AM, David Lin wrote: Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, This means that Web UI calls `ipa host-find` and couple of `ipa host-show` commands. Could you try it in CLI find out which command fails? So other web ui tabs work? Does service tab work(services has some common logic with hosts)? I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database directory (for any reason, including non-existent directory) That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was somehow damaged? Although I doubt that, in that case Apache would not be able to serve https even. +1 On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. If you are using FreeIPA 4.1+, this is expected: https://fedorahosted.org/freeipa/ticket/4449 Martin -- Petr Vobornik -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv keytab revoked
On 29.5.2015 10:06, Martin Kosek wrote: > On 05/29/2015 07:48 AM, Christoph Kaminski wrote: >> Hi >> >> I have had a defect entries in ldap for a replica and deleted them. But now >> the >> dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The >> replica starts but it cant connect other replicas (but other replicas can >> connect to it). >> >> I have tried: >> kinit -k -t /etc/dirsrv/ds.keytab >> ldap/ipa-1.mgmt.testsystem-homemonitoring.int >> >> and got: >> kinit: Clients credentials have been revoked while getting initial >> credentials >> >> It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab >> (on this replica) doesnt work. > > Running ipa-getkeytab on this replica is tricky - as if replication is down > and you do this, the old key is revoked and new one is generated - which is > not known for the other master as replication is not working and you get in a > strange situation. > > You can try to log to your active master, do ipa-getkeytab for the broken > replica, copy the keytab there, restart DS and then run re-initialize to > reload all the data from active master. It may work. > >> Or it is better to destroy it and do a new install? > > That may be even faster for the making that particular replica up and running > again, if you do not want to dig too much in this issue. It might happen that keytab is actually valid but the principal just is locked out. In that case following LDIF should fix the problem: dn: krbprincipalname=ldap/ipa-1.mgmt.testsystem-homemonitoring.int@,cn=services,cn=accounts, changetype: modify delete: krbLoginFailedCount - delete: krbLastFailedAuth - You need to run ldapmodify with Directory manager's credentials. I hope this helps. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE
ipa host-find produces this ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. and ipa host-show on only one of the hosts show ipa: ERROR: Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. all the other hosts are fine. Thanks! David > On May 29, 2015, at 1:35 AM, Petr Vobornik wrote: > > On 05/29/2015 10:02 AM, Martin Kosek wrote: >> On 05/29/2015 01:27 AM, David Lin wrote: >>> Hi, >>> When I try to add multiple hosts, on the web UI, when I go to the host >>> tab, > > This means that Web UI calls `ipa host-find` and couple of `ipa host-show` > commands. Could you try it in CLI find out which command fails? > > So other web ui tabs work? Does service tab work(services has some common > logic with hosts)? > >> I get >>> Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The >>> certificate/key database is in an old, unsupported format. >>> >>> What does this mean? > > NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database > directory (for any reason, including non-existent directory) > >> >> That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was >> somehow damaged? Although I doubt that, in that case Apache would not be >> able to serve https even. > > +1 > >> >>> On one of the hosts, I do notice that when i do >>> >>> ipa host-show >>> >>> there is no certificate listed. >> >> If you are using FreeIPA 4.1+, this is expected: >> >> https://fedorahosted.org/freeipa/ticket/4449 >> >> Martin >> > > -- > Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE
On 05/29/2015 10:02 AM, Martin Kosek wrote: On 05/29/2015 01:27 AM, David Lin wrote: Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, This means that Web UI calls `ipa host-find` and couple of `ipa host-show` commands. Could you try it in CLI find out which command fails? So other web ui tabs work? Does service tab work(services has some common logic with hosts)? I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? NSS returns SEC_ERROR_LEGACY_DATABASE when it can't read the database directory (for any reason, including non-existent directory) That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was somehow damaged? Although I doubt that, in that case Apache would not be able to serve https even. +1 On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. If you are using FreeIPA 4.1+, this is expected: https://fedorahosted.org/freeipa/ticket/4449 Martin -- Petr Vobornik -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] SEC_ERROR_LEGACY_DATABASE
On 05/29/2015 01:27 AM, David Lin wrote: Hi, When I try to add multiple hosts, on the web UI, when I go to the host tab, I get Certificate format error: (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. What does this mean? That's strange. CCIng Petr. Maybe /etc/httpd/alias NSS database was somehow damaged? Although I doubt that, in that case Apache would not be able to serve https even. On one of the hosts, I do notice that when i do ipa host-show there is no certificate listed. If you are using FreeIPA 4.1+, this is expected: https://fedorahosted.org/freeipa/ticket/4449 Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] dirsrv keytab revoked
On 05/29/2015 07:48 AM, Christoph Kaminski wrote: Hi I have had a defect entries in ldap for a replica and deleted them. But now the dirsrv keytab (/etc/dirsrv/ds.keytab) doesnt work anymore (revoked). The replica starts but it cant connect other replicas (but other replicas can connect to it). I have tried: kinit -k -t /etc/dirsrv/ds.keytab ldap/ipa-1.mgmt.testsystem-homemonitoring.int and got: kinit: Clients credentials have been revoked while getting initial credentials It is possible to 'regenerate' this keytab? If yes how? Simple ipa-getkeytab (on this replica) doesnt work. Running ipa-getkeytab on this replica is tricky - as if replication is down and you do this, the old key is revoked and new one is generated - which is not known for the other master as replication is not working and you get in a strange situation. You can try to log to your active master, do ipa-getkeytab for the broken replica, copy the keytab there, restart DS and then run re-initialize to reload all the data from active master. It may work. Or it is better to destroy it and do a new install? That may be even faster for the making that particular replica up and running again, if you do not want to dig too much in this issue. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Single mail deployment i an FreeIPA-WindowsAD scenario.
Only a very basic "fractional replication" - you can remove selected attributes from replicating. It is possible even now and can be configured on each replication agreement: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/managing-fractional-repl.html In FreeIPA 4.2, it should be possible to set that centrally: https://fedorahosted.org/freeipa/ticket/4302 Martin On 05/28/2015 09:02 PM, Carlos Raúl Laguna wrote: Thanks for the clarifications, one more question, does FreeIPA support partial or fractional replications? Regards 2015-05-28 0:25 GMT-04:00 Alexander Bokovoy mailto:aboko...@redhat.com>>: On Wed, 27 May 2015, Carlos Raúl Laguna wrote: Hello Martin, Alexander Seem that the time shift is large between us, If i understand correctly, compat tree will allow me to see all users, regardless they location Windows or FreeIPA, however the kolab-specific attribute must come from FreeIPA and Windows AD where the users entries lays. This means creating custom object classes and attributes for AD schema them update compat plugin to see the custom attribute. The second part where kolab needs to update some value in any of this attribute, for example mailQuota it would be rejected and therefor it must be done from Windows AD or FreeIPA, is this correct? Thanks both of you for your time and input in this matter. Regards Just to make you absolutely clear: using compat tree will not help you at all. Nothing else in FreeIPA could help you in getting Kolab to work with both IPA and AD users at the same time. It would be nice if kolab could grow a capability to connect to multiple LDAP servers at the same time, with non-overlapping user and group trees. I don't think it is there now and I don't see other possibilities here. 2015-05-27 4:46 GMT-04:00 Alexander Bokovoy mailto:aboko...@redhat.com>>: On Wed, 27 May 2015, Martin Kosek wrote: On 05/27/2015 10:08 AM, Alexander Bokovoy wrote: On Wed, 27 May 2015, Martin Kosek wrote: On 05/26/2015 07:36 PM, Carlos Raúl Laguna wrote: Hello Martin, The email deployment it is a groupware in this scenario Kolab, kolab use 389 ad as main backend and it require some kolab ldap specific attribute to work properly, this is not a problem in fact is quite easy to use freeipa as kolab backend, so far so good but the romance only get this far. Since we also use Windows Ad with forest-trust not all user are present in the FreeIPA directory and there it is where my problem lays. Since not all user are in the same box it become difficult to implement one mail system for all users. Regards As I said, we have compat tree that allows LDAP BIND authentication and LDAP identity (not enumeration) for both IPA users and AD users when realm is in place. You can even update the configuration of the compat tree and add the kolab specific fields to be generated there too. There was very similar request on freeipa-users. It was for vSphere, but dealing with very similar use case and the final solution: http://www.freeipa.org/page/HowTo/vsphere5_integration Would that approach work for you? I don't think it will work. compat tree is run-time read-only view of the data coming from somewhere else. You need to have Kolab-specific data available somewhere to be able to inject it in the compat tree. Where would that data be stored for Kolab for AD-specific entries? It would work as long as the attributes are in the "real" user entries in form
Re: [Freeipa-users] Antwort: Re: Haunted servers?
On 05/29/2015 08:16 AM, Christoph Kaminski wrote:
freeipa-users-boun...@redhat.com schrieb am 28.05.2015 13:23:26:
> Von: Alexander Frolushkin
> An: "'thierry bordaz'"
> Kopie: "freeipa-users@redhat.com"
> Datum: 28.05.2015 13:24
> Betreff: Re: [Freeipa-users] Haunted servers?
> Gesendet von: freeipa-users-boun...@redhat.com
>
> Unfortunately, after a couple of minutes, on two of three servers
> error comes back in little changed form:
> # ipa-replica-manage list-ruv
> unable to decode: {replica 16}
>
>
> Before cleanruv it looked like:
> # ipa-replica-manage list-ruv
> unable to decode: {replica 16} 548a81260010 548a81260010
>
>
> And one server seems to be fixed completely.
>
> WBR,
> Alexander Frolushkin
>
>
we had the same problem (and some more) and yesterday we have
successfully cleaned the gohst rid's
our fix:
Hi Christoph,
THanks for sharing this procedure. This bug is difficult to workaround
and that is a good idea to write it down.
1. stop all cleanallruv Tasks, if it works with ipa-replica-manage
abort-clean-ruv. It hasnt worked here. We have done it manually on ALL
replicas with:
a) replica stop
b) delete all nsds5ReplicaClean from
/etc/dirsrv/slapd-HSO/dse.ldif
c) replica start
Yes the ability to abort clean ruv hits the same retry issue that
cleanallruv. It has been addressed with
https://fedorahosted.org/389/ticket/48154
2. prepare on EACH ipa a cleanruv ldif file with ALL ghost rids inside
(really ALL from all ipa replicas, we has had some rids only on some
replicas...)
Example:
dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV11
dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV22
dn: cn=replica,cn=dc\3Dexample,cn=mapping tree,cn=config
changetype: modify
replace: nsds5task
nsds5task:CLEANRUV37
...
It should work but I would prefer to do it in an other order.
We need to clean a specific RID, on all replica, at the same time. We do
not need to clean all RIDs at the same time.
Having several CLEANRUV in parallel for differents RID should work but I
do not know how much it has been tested that way.
So I would recommend to clean, in parallel on all replicas, RID 11. Then
when it is completed, RID 22. Then RID 37.
3. do a "ldapmodify -h 127.0.0.1 -D "cn=Directory Manager" -W -x -f
$your-cleanruv-file.ldif" on all replicas AT THE SAME TIME :) we used
terminator for it (https://launchpad.net/terminator). You can open
multiple shell windows inside one window and send to all at the same
time the same commands...
same remark I would split your-cleanruv-file.ldif into three files
cleanruv-11-file.ldif,...
4. we have done a re-initialize of each IPA from our first master
Do you mean a total init ? I do not see a real need for that.
If you are ready to reinit all replicas, there is a very simple way to
get rid of all these ghost RIDs.
* Select the "good" master that is having all the updates
* do a ldif export without the replication data
* do a ldif import of exported file
* do online reinit of the full topology, cascading from the "good"
master down to the "consumers"
Most of the time we try to avoid asking a full reinit of the topology
because DB are large.
5. restart of all replicas
we are not sure about the point 3 and 4. Maybe they are not necessary,
but we have done it.
If something fails look at defect LDAP entries in whole ldap, we have
had some entries with 'nsunique-$HASH' after the 'normal' name. We
have deleted them.
do you mean entries with 'nsuniqueid' attribute in the RDN. This could
be create during replication conflicts when updates are received in
parallele on different replicas.
thanks
thierry
MfG
Christoph Kaminski
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] inserting users via java
On 05/28/2015 11:00 PM, Timothy Worman wrote: On May 28, 2015, at 12:26 PM, Martin Kosek wrote: On 05/28/2015 07:10 PM, Timothy Worman wrote: On Mar 26, 2015, at 3:08 PM, Dmitri Pal wrote: On 03/26/2015 03:19 PM, Timothy Worman wrote: On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: On 03/26/2015 07:37 PM, Timothy Worman wrote: Thanks everyone for the input. I do agree that I don’t like the sound of option 1. I don’t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there’s an existing/working API there. I’ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you’re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? Hi Dmitri - following up on this to see how progress is going on this project. I am definitely still interested in testing this. In the meantime, I have been pursuing http client calls posting json. And I have some questions I need to pursue on that as well. Should I take this to freeipa-devel? Hello Timothy, I am sorry we did not update this thread, but in the end we decided not to invest in the REST interface ourselves at this moment (read - FreeIPA 4.2), but rather work on stabilizing and documenting current JSON-RPC API we have as we believe the API is easily usable from major languages even though it is not RESTy. To prove our point, we need good documentation of it and examples for the major languages. This is the proposal of what shall be done in FreeIPA 4.2 that I sent to freeipa-devel: http://www.redhat.com/archives/freeipa-devel/2015-April/msg00061.html I hope the way we go for the next release is acceptable for you. In the mean time, if you have specific questions on calling JSON from your programs, both freeipa-users and freeipa-devel may be suitable, depending on how deep you want to go in the code... HTH, Martin Thanks Martin: OK, just to verify - The staging approach (Dmitri spoke about) of inserting records into a staged user schema and having them inserted via a cron job is now off for near releases. I am anxious to see that happen. Ah, looks I misread the thread branches about what was actually promised. The FreeIPA User Life Cycle feature (staging users can be added via LDAP and later activated) *is* going to FreeIPA 4.2 and is actually mostly implemented, it will be part of FreeIPA 4.2 Alpha release, so you can try it out then. This is the upstream tracker: https://fedorahosted.org/freeipa/ticket/3813 But, I am working on a java http client (apache httpclient + jaas/Krb5LoginModule) that posts json to the ipaserver. However, I am having some difficulty with kerberos negotiation and I should probably start a separate thread on that - either here or on freeipa-devel. Ok. Feel free to ask. I do not expect too big problems with JSON&Kerberos. AFAIK, you do not need to even need to use JSON calls and Kerberos at the same time. With FreeIPA, you can simply login to the API via HTTPS+SPNEGO, get a session code and use that for HTTPS JSON API calls (this helps if a JSON library cannot do Kerberos auth out of the box). Martin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
