Re: [Freeipa-users] FREEIPA REPLICA - ITS USE AND HOW IT SHOULD OPERATE WHEN PRIMARY FAILS
On 04/10/2015 06:54 PM, Martin Chamambo wrote: Good day I have a freeipa primary server working as i wanted , no complex stuff has been setup yet except the basic service and sudo controls which is fine by me. I have also setup a replica from the primary. the dns server is running from a different platform so basically the 2 servers query a DNS server on onother server to resolve their names. my questions is as follows: when primary server fails , does the replica automatically assume the position of the primary [and please note that replication is also working as expected] The replica is no different from the primary master, aside from being responsible for CRL generation. Failover really depends on how your clients are configured. If you are using SSSD, you should look at the 'FAILOVER' section in the 'sssd-ipa' man page for a details on how it works and how it is configured. -- 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] Problems with ntpd when running FreeIPA in a Docker container
On 01/15/2015 08:56 AM, Nathan Kinder wrote: On 01/15/2015 12:01 AM, Jan Pazdziora wrote: ... You need to use --cap-add=SYS_TIME when running the server container or ntpd will fail. Thanks for the tip. This works. It would be handy to add this to the README for your freeipa-server container. Nevermind. I just saw your reply to Lukas on this. If we can keep the client install from hanging forever, then I agree that it's best to have it be noticeable that time sync is not working in the client installer output vs. hiding that it's not working. Even if you do that, SELinux will likely prevent ntpd doing its job but at least it will stay around so that the client can connect to it. What is interesting though is the fact that the client hangs indefinitely instead of reporting that it cannot sync the time and proceeding. I think this is simply a behavior difference between ntpdate and ntpd (which we are using now during the client install on f21). This issue should not be specific to using IPA in a container. Hanging indefinitely is never a good thing, so I think it would be nice to add a timeout in ipa-client-install in case we can't reach the server for ntp. I have filed a ticket for this: https://fedorahosted.org/freeipa/ticket/4842 -NGK -- 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] Problems with ntpd when running FreeIPA in a Docker container
On 01/15/2015 12:01 AM, Jan Pazdziora wrote: On Wed, Jan 14, 2015 at 08:18:02PM -0800, Nathan Kinder wrote: Hi, I'm running into a strange problem related to ntpd when trying to use IPA in a container. I'm using the adelton/freeipa-server:fedora-21 and adelton/freeipa-client:fedora-21 docker images. Basically, the client install hangs when it runs ntpd. This is reproducible on two different docker hosts of mine, so it will probably easily reproduce for others as [...] The /sbin/ipa-server-configure-first entrypoint script for the server image does a 'systemctl start-enabled' to bring up all of the services, which results in this output in /var/log/systemctl.log: [start-enabled] [start ntpd.service] Running [export OPTIONS=-g -x; /usr/sbin/ntpd -u ntp:ntp $OPTIONS] Marked pid [15] for [ntpd.service] Marked process name [/usr/sbin/ntpd] for [ntpd.service] ... This is the same log output that is generated if I manually run 'systemctl start ntpd.service' from within the container, but the ntpd process stays around when I start it this way. It's hard to tell what might be happening to ntpd, as there is no journal in the container. I'm continuing to debug this, but I thought I'd share my findings thus far in case anyone else has seen this or has any ideas for tracking the problem down. Any ideas? You need to use --cap-add=SYS_TIME when running the server container or ntpd will fail. Thanks for the tip. This works. It would be handy to add this to the README for your freeipa-server container. Even if you do that, SELinux will likely prevent ntpd doing its job but at least it will stay around so that the client can connect to it. What is interesting though is the fact that the client hangs indefinitely instead of reporting that it cannot sync the time and proceeding. I think this is simply a behavior difference between ntpdate and ntpd (which we are using now during the client install on f21). This issue should not be specific to using IPA in a container. Hanging indefinitely is never a good thing, so I think it would be nice to add a timeout in ipa-client-install in case we can't reach the server for ntp. I have filed a ticket for this: https://fedorahosted.org/freeipa/ticket/4842 -NGK -- 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] Problems with ntpd when running FreeIPA in a Docker container
On 01/15/2015 09:41 AM, Jan Pazdziora wrote: On Thu, Jan 15, 2015 at 08:56:29AM -0800, Nathan Kinder wrote: Even if you do that, SELinux will likely prevent ntpd doing its job but at least it will stay around so that the client can connect to it. What is interesting though is the fact that the client hangs indefinitely instead of reporting that it cannot sync the time and proceeding. I think this is simply a behavior difference between ntpdate and ntpd (which we are using now during the client install on f21). This issue should not be specific to using IPA in a container. The problem is, on Fedora 21 client which is not container and ntpd not running on the server, I was not able to reproduce the issue. Strange... Does it reproduce for you when using containers for both the server and the client? -- 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] Problems with ntpd when running FreeIPA in a Docker container
Hi, I'm running into a strange problem related to ntpd when trying to use IPA in a container. I'm using the adelton/freeipa-server:fedora-21 and adelton/freeipa-client:fedora-21 docker images. Basically, the client install hangs when it runs ntpd. This is reproducible on two different docker hosts of mine, so it will probably easily reproduce for others as well. Below are the steps I'm using. Install IPA server in F21 container: [root@localhost ~]# docker run --name freeipa-server-container -d -h ipa.example.test -e PASSWORD=Secret123 adelton/freeipa-server:fedora-21 875007ab561ff62ea45dde5e8a5e320a209c63b3c8fc52bd4ca7b22561d1bbf0 [root@localhost ~]# docker logs freeipa-server-container ... FreeIPA server configured. Go loop. Install IPA client in F21 container and link it to the IPA server container. This will hang indefinitely when it tries to run ntpd to sync the time before getting the admin ticket: [root@localhost ~]# docker run --name client -h client.example.test --link freeipa-server-container:ipa -e PASSWORD=Secret123 -e IPA_CLIENT_INSTALL=--debug -it adelton/freeipa-client:fedora-21 ... Synchronizing time with KDC... Search DNS for SRV record of _ntp._udp.example.test DNS record found: 0 100 123 ipa.example.test. Starting external process args='/usr/sbin/ntpd' '-qgc' '/tmp/tmpRhhyCz' If I use nsenter to go into the client container and kill ntpd, the install continues and completes. I also confirmed that the ntpd config file that we create in /tmp is correct. From within the client container (via nsenter), running 'ntpd -qgc' with a conf file that points to the IPA server just loops endlessly. I looked into the IPA server container, and ntpd is not running. The ipaserver-install.log shows that it attempts to start (which returns 0), but the service is not active afterwards: ... 2015-01-14T22:57:02Z DEBUG [4/4]: starting ntpd 2015-01-14T22:57:02Z DEBUG Starting external process 2015-01-14T22:57:02Z DEBUG args='/bin/systemctl' 'start' 'ntpd.service' 2015-01-14T22:57:03Z DEBUG Process finished, return code=0 2015-01-14T22:57:03Z DEBUG stdout= 2015-01-14T22:57:03Z DEBUG stderr= 2015-01-14T22:57:03Z DEBUG Starting external process 2015-01-14T22:57:03Z DEBUG args='/bin/systemctl' 'is-active' 'ntpd.service' 2015-01-14T22:57:04Z DEBUG Process finished, return code=3 2015-01-14T22:57:04Z DEBUG stdout=inactive 2015-01-14T22:57:04Z DEBUG stderr= 2015-01-14T22:57:04Z DEBUG duration: 1 seconds 2015-01-14T22:57:04Z DEBUG Done configuring NTP daemon (ntpd). ... It seems that this causes ntpd on the F21 client to just loop endlessly since it never sees a response. We use ntpdate on F20, which bails out and skips the time update on a F20 client when the server is unavailable: ... 2015-01-15T03:29:11Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v ipa.example.test 2015-01-15T03:29:11Z DEBUG Process finished, return code=1 2015-01-15T03:29:11Z DEBUG stdout= 2015-01-15T03:29:11Z DEBUG stderr= 2015-01-15T03:29:11Z DEBUG Starting external process 2015-01-15T03:29:11Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v ipa.example.test 2015-01-15T03:29:11Z DEBUG Process finished, return code=1 2015-01-15T03:29:11Z DEBUG stdout= 2015-01-15T03:29:11Z DEBUG stderr= 2015-01-15T03:29:11Z WARNING Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. ... I can do a 'systemctl start ntpd.service' on the IPA server container, and it does start up successfully. It never seems to automatically start though, even if I restart the IPA server docker container. I did confirm that ntpd.service is enabled with systemctl, yet it doesn't start automatically. The /sbin/ipa-server-configure-first entrypoint script for the server image does a 'systemctl start-enabled' to bring up all of the services, which results in this output in /var/log/systemctl.log: [start-enabled] [start ntpd.service] Running [export OPTIONS=-g -x; /usr/sbin/ntpd -u ntp:ntp $OPTIONS] Marked pid [15] for [ntpd.service] Marked process name [/usr/sbin/ntpd] for [ntpd.service] ... This is the same log output that is generated if I manually run 'systemctl start ntpd.service' from within the container, but the ntpd process stays around when I start it this way. It's hard to tell what might be happening to ntpd, as
Re: [Freeipa-users] weak and null ciphers detected on ldap ports
On 09/22/2014 05:03 AM, Murty, Ajeet (US - Arlington) wrote: Security scan of FreeIPA server ports uncovered weak, medium and null ciphers on port 389 and 636. We are running ‘ipa-server-3.0.0-37.el6.i686’. How can I disable/remove these ciphers in my existing setup? This has recently been worked on in this 389-ds-base ticket: https://fedorahosted.org/389/ticket/47838 As mentioned in the initial description of that ticket, you can configure the allowed ciphers in the cn=config entry in 389-ds-base. You can edit this over LDAP, or by stopping 389-ds-base and editing /etc/dirsrv/slapd-REALM/dse.ldif. Thanks, -NGK Ciphers Discovered - TLSv1 EXP-RC2-CBC-MD5 Kx=RSA(512)Au=RSA Enc=RC2-CBC(40) Mac=MD5export EXP-RC4-MD5 Kx=RSA(512)Au=RSA Enc=RC4(40) Mac=MD5export TLSv1 EXP1024-DES-CBC-SHA Kx=RSA(1024) Au=RSA Enc=DES-CBC(56) Mac=SHA1 export EXP1024-RC4-SHA Kx=RSA(1024) Au=RSA Enc=RC4(56) Mac=SHA1 export DES-CBC-SHA Kx=RSA Au=RSA Enc=DES-CBC(56) Mac=SHA1 TLSv1 NULL-SHA Kx=RSA Au=RSA Enc=None Mac=SHA1 Thanks, Amb. This message (including any attachments) contains confidential information intended for a specific individual and purpose, and is protected by law. If you are not the intended recipient, you should delete this message and any disclosure, copying, or distribution of this message, or the taking of any action based on it, by you is strictly prohibited. v.E.1 -- 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] ipa sync agreement to AD DC is taking a very long time
On 10/14/2013 08:26 PM, janice.psyop wrote: Hi, I've been setting up an IPA server (centos 6.4) with AD trust (2008R2 domain) following the FC18 freeipa guide. Everything has gone smoothly until I ran the ipa-replica-manage connect command to the AD DC and it seems to be running (no errors on std out and ps says it is still running), but it has been running for six hours! We do have ~2000 user entries, but I didn't think it would take this long to sync up. It's definitely hung up. 2k users should be very quick to sync. The command I ran was this (see below) and the screen now just displays repeating Update in progress. I'm very tempted to kill it in case something is going horribly wrong (with the AD user accounts...) /usr/sbin/ipa-replica-manage connect --winsync --passsync=MySecretPass --binddn=CN=myipasyncuser,CN=Users,DC=domain,DC=com --bindpw=MySecretPass --cacert=/etc/openldap/cacerts/DC-CA.cer -v dc.domain.com http://dc.domain.com Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Update in progress Is there any way to check the progress of this in case it is in fact hung up? The last few entries in the ipa/default.log is from six hours ago: Is there anything of interest in the 389 DS errors log? It's located at /var/log/dirsrv/slapd-realm/errors. Thanks, -NGK 2013-10-14T21:32:45Z2706MainThread ipa INFOAdded new sync agreement, waiting for it to become ready . . . 2013-10-14T21:32:46Z2706MainThread ipa INFO Replication Update in progress: FALSE: status: 0 Replica acquired successfully: Incremental update started: start: 0: end: 0 2013-10-14T21:32:46Z2706MainThread ipa INFOAgreement is ready, starting replication . . . thanks much, -J. ___ 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] Required services are not started after reboot
On 10/10/2013 04:57 PM, Nathan Kinder wrote: On 10/10/2013 04:11 PM, Nathan Kinder wrote: On 10/10/2013 03:50 PM, Nathan Kinder wrote: On 10/10/2013 06:48 AM, Rob Crittenden wrote: Mateusz Marzantowicz wrote: On 08.10.2013 18:43, Tamas Papp wrote: On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: Finally, I've managed to install FreeIPA on Fedora 20 without any errors. I was even able to log in through web UI and make some changes. Sadly after system reboot, non of IPA related services were started and now nothing works as expected. What services need to be enabled (I need to enable manually) to make ipa server operational again? I'd be thankful for any links to official documentation that covers this topic. See: https://bugzilla.redhat.com/show_bug.cgi?id=1008306 t Thanks, It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). How is it possible that same release of freeipa (3.3.2-1) fixes bug 996716 in fc19 and not in fc20? I'm currently testing newest available rpm on fc20 and this bug still occurs. I've found that bug 1008306 [3] is more relevant in this case than one in FreeIPA. I also have newest 389-ds-base (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and nothing has changed as I mentioned above. I'm trying to make sens out of this bug rpm # spaghetti but it's not so easy. [1] https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 [2] https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 I think this is because the fixed 389-ds package hasn't been built yet for F-20. The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 build. Are we sure that the issue that is occuring here is related to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? I just fired up a F20 VM, and there is definitely still a problem here in 389-ds-base. I see the following in my tmpfiles.d config for dirsrv: -- d /var/run/dirsrv 0770 nobody nobody d /var/lock/dirsrv 0770 nobody nobody d /var/lock/dirsrv/slapd-example 0770 nobody nobody -- We'll figure out what's going on and get a respin of 389-ds-base out. This appears to be a simple issue in 389-ds-base. We will get a new builds in Koji on F19 and F20 tomorrow. Here's a new build for F20 that should resolve this: https://admin.fedoraproject.org/updates/389-ds-base-1.3.2.2-1.fc20 Please test it and provide karma. Thanks, -NGK https://fedorahosted.org/389/ticket/47513 Thanks, -NGK I think the difference in bugs fixed in bohdi was an oversight. The F-19 bugs fixed upstream should have been included in the F-20 bohdi (and probably the other way around too). The changes made to IPA for BZ 996716 are basically just cosmetic, to be in compliance with packaging guidelines. rog ___ 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] Required services are not started after reboot
On 10/10/2013 06:48 AM, Rob Crittenden wrote: Mateusz Marzantowicz wrote: On 08.10.2013 18:43, Tamas Papp wrote: On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: Finally, I've managed to install FreeIPA on Fedora 20 without any errors. I was even able to log in through web UI and make some changes. Sadly after system reboot, non of IPA related services were started and now nothing works as expected. What services need to be enabled (I need to enable manually) to make ipa server operational again? I'd be thankful for any links to official documentation that covers this topic. See: https://bugzilla.redhat.com/show_bug.cgi?id=1008306 t Thanks, It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). How is it possible that same release of freeipa (3.3.2-1) fixes bug 996716 in fc19 and not in fc20? I'm currently testing newest available rpm on fc20 and this bug still occurs. I've found that bug 1008306 [3] is more relevant in this case than one in FreeIPA. I also have newest 389-ds-base (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and nothing has changed as I mentioned above. I'm trying to make sens out of this bug rpm # spaghetti but it's not so easy. [1] https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 [2] https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 I think this is because the fixed 389-ds package hasn't been built yet for F-20. The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 build. Are we sure that the issue that is occuring here is related to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? Thanks, -NGK I think the difference in bugs fixed in bohdi was an oversight. The F-19 bugs fixed upstream should have been included in the F-20 bohdi (and probably the other way around too). The changes made to IPA for BZ 996716 are basically just cosmetic, to be in compliance with packaging guidelines. rog ___ 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] Required services are not started after reboot
On 10/10/2013 03:50 PM, Nathan Kinder wrote: On 10/10/2013 06:48 AM, Rob Crittenden wrote: Mateusz Marzantowicz wrote: On 08.10.2013 18:43, Tamas Papp wrote: On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: Finally, I've managed to install FreeIPA on Fedora 20 without any errors. I was even able to log in through web UI and make some changes. Sadly after system reboot, non of IPA related services were started and now nothing works as expected. What services need to be enabled (I need to enable manually) to make ipa server operational again? I'd be thankful for any links to official documentation that covers this topic. See: https://bugzilla.redhat.com/show_bug.cgi?id=1008306 t Thanks, It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). How is it possible that same release of freeipa (3.3.2-1) fixes bug 996716 in fc19 and not in fc20? I'm currently testing newest available rpm on fc20 and this bug still occurs. I've found that bug 1008306 [3] is more relevant in this case than one in FreeIPA. I also have newest 389-ds-base (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and nothing has changed as I mentioned above. I'm trying to make sens out of this bug rpm # spaghetti but it's not so easy. [1] https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 [2] https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 I think this is because the fixed 389-ds package hasn't been built yet for F-20. The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 build. Are we sure that the issue that is occuring here is related to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? I just fired up a F20 VM, and there is definitely still a problem here in 389-ds-base. I see the following in my tmpfiles.d config for dirsrv: -- d /var/run/dirsrv 0770 nobody nobody d /var/lock/dirsrv 0770 nobody nobody d /var/lock/dirsrv/slapd-example 0770 nobody nobody -- We'll figure out what's going on and get a respin of 389-ds-base out. Thanks, -NGK I think the difference in bugs fixed in bohdi was an oversight. The F-19 bugs fixed upstream should have been included in the F-20 bohdi (and probably the other way around too). The changes made to IPA for BZ 996716 are basically just cosmetic, to be in compliance with packaging guidelines. rog ___ 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] Required services are not started after reboot
On 10/10/2013 04:11 PM, Nathan Kinder wrote: On 10/10/2013 03:50 PM, Nathan Kinder wrote: On 10/10/2013 06:48 AM, Rob Crittenden wrote: Mateusz Marzantowicz wrote: On 08.10.2013 18:43, Tamas Papp wrote: On 10/08/2013 06:33 PM, Mateusz Marzantowicz wrote: Finally, I've managed to install FreeIPA on Fedora 20 without any errors. I was even able to log in through web UI and make some changes. Sadly after system reboot, non of IPA related services were started and now nothing works as expected. What services need to be enabled (I need to enable manually) to make ipa server operational again? I'd be thankful for any links to official documentation that covers this topic. See: https://bugzilla.redhat.com/show_bug.cgi?id=1008306 t Thanks, It looks like this bug is fixed in fc19 [1] but it's not in fc20 [2] (please compare 'Bugs Fixed' sections (I haven't tested it on fc19)). How is it possible that same release of freeipa (3.3.2-1) fixes bug 996716 in fc19 and not in fc20? I'm currently testing newest available rpm on fc20 and this bug still occurs. I've found that bug 1008306 [3] is more relevant in this case than one in FreeIPA. I also have newest 389-ds-base (389-ds-base-1.3.2.0-1.fc20.x86_64) package released for fc20 and nothing has changed as I mentioned above. I'm trying to make sens out of this bug rpm # spaghetti but it's not so easy. [1] https://admin.fedoraproject.org/updates/FEDORA-2013-18371/freeipa-3.3.2-1.fc19 [2] https://admin.fedoraproject.org/updates/FEDORA-2013-18542/freeipa-3.3.2-1.fc20 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1008306 I think this is because the fixed 389-ds package hasn't been built yet for F-20. The fix for BZ 1008306 is in the 389-ds-base-1.3.2.0-1.fc20.x86_64 build. Are we sure that the issue that is occuring here is related to tmpfiles.d not creating /var/lock/dirsrv before dirsrv is started? I just fired up a F20 VM, and there is definitely still a problem here in 389-ds-base. I see the following in my tmpfiles.d config for dirsrv: -- d /var/run/dirsrv 0770 nobody nobody d /var/lock/dirsrv 0770 nobody nobody d /var/lock/dirsrv/slapd-example 0770 nobody nobody -- We'll figure out what's going on and get a respin of 389-ds-base out. This appears to be a simple issue in 389-ds-base. We will get a new builds in Koji on F19 and F20 tomorrow. https://fedorahosted.org/389/ticket/47513 Thanks, -NGK I think the difference in bugs fixed in bohdi was an oversight. The F-19 bugs fixed upstream should have been included in the F-20 bohdi (and probably the other way around too). The changes made to IPA for BZ 996716 are basically just cosmetic, to be in compliance with packaging guidelines. rog ___ 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] FreeIPA on Fedora 20: Configuration of CA failed
On 09/11/2013 03:33 PM, Mateusz Marzantowicz wrote:
I'm trying to install FreeIPA Server on Fedora 20 (with all updates
installed) but it fails on ipa-server-install -N command.
Error message:
CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s
CA -f /tmp/tmppTdhYM' returned non-zero exit status 1
which pointed me to [1] and [2]. I've found bug 953488 [3] but
recommended solution does not work for me.
Is there any way I can install and configure FreeIPA server on Fedora 20?
I believe that this is all caused by a recent change to the way Tomcat
startup works in F20, which breaks the Dogtag CA. We hope to have a new
build of Dogtag soon that addresses this.
Thanks,
-NGK
Here are some lines from /var/log/ipaserver-install.log:
2013-09-11T20:13:40Z DEBUG Starting external process
2013-09-11T20:13:40Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmppTdhYM
2013-09-11T20:13:40Z DEBUG Process finished, return code=1
2013-09-11T20:13:40Z DEBUG stdout=Loading deployment configuration from
/tmp/tmppTdhYM.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg.
Installation failed.
2013-09-11T20:13:40Z DEBUG stderr=pkispawn: WARNING ...
Dangling symlink
'/var/lib/pki/pki-tomcat/pki-tomcat'--'/usr/sbin/tomcat-sysd'
2013-09-11T20:13:40Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmppTdhYM' returned non-zero exit status 1
2013-09-11T20:13:40Z DEBUG File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 622, in run_script
return_value = main_function()
File /usr/sbin/ipa-server-install, line 1022, in main
dm_password, subject_base=options.subject)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
478, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 364, in start_creation
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
604, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
2013-09-11T20:13:40Z DEBUG The ipa-server-install command failed,
exception: RuntimeError: Configuration of CA failed
and few more lines from /var/log/pki/pki-ca-spawn.20130911221340.log:
2013-09-11 22:13:40 pkispawn: INFO ... mkdir -p
/var/lib/pki/pki-tomcat/work/Catalina/localhost/ca
2013-09-11 22:13:40 pkispawn: DEBUG... chmod 770
/var/lib/pki/pki-tomcat/work/Catalina/localhost/ca
2013-09-11 22:13:40 pkispawn: DEBUG... chown 995:994
/var/lib/pki/pki-tomcat/work/Catalina/localhost/ca
2013-09-11 22:13:40 pkispawn: INFO ... ln -s
/usr/share/tomcat/bin /var/lib/pki/pki-tomcat/bin
2013-09-11 22:13:40 pkispawn: DEBUG... chown -h 995:994
/var/lib/pki/pki-tomcat/bin
2013-09-11 22:13:40 pkispawn: WARNING ... Dangling symlink
'/var/lib/pki/pki-tomcat/pki-tomcat'--'/usr/sbin/tomcat-sysd'
2013-09-11 22:13:40 pkispawn: DEBUG... Error Type: SystemExit
2013-09-11 22:13:40 pkispawn: DEBUG... Error Message: 1
2013-09-11 22:13:40 pkispawn: DEBUG... File
/usr/sbin/pkispawn, line 374, in main
rv = instance.spawn()
File
/usr/lib/python2.7/site-packages/pki/deployment/instance_layout.py,
line 87, in spawn
uid=0, gid=0)
File /usr/lib/python2.7/site-packages/pki/deployment/pkihelper.py,
line 1774, in create
sys.exit(1)
Mateusz Marzantowicz
[1] https://www.redhat.com/archives/freeipa-users/2013-July/msg00247.html
[2]
https://www.redhat.com/archives/freeipa-users/2012-December/msg00010.html
[3] https://bugzilla.redhat.com/show_bug.cgi?id=953488
___
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] [Freeipa-devel] [SSSD] FreeIPA on Debian
On 09/03/2013 01:50 PM, Timo Aaltonen wrote: On 03.09.2013 23:30, Nathan Kinder wrote: On 09/01/2013 01:35 PM, Timo Aaltonen wrote: On 01.09.2013 21:43, Dmitri Pal wrote: On 09/01/2013 02:20 PM, Timo Aaltonen wrote: On 31.08.2013 00:04, Dmitri Pal wrote: Hello, Sorry for cross posting to 4 different lists but it seems that this is the best way to include most of people who might be interested in this discussion. The question of When FreeIPA will be available on Debian? has been coming up periodically on the list(s) without any resolution. However it is clear that it would be beneficial for the community and the project. Hi, As you know, I've been packaging stuff for the past two years with the goal of eventually having FreeIPA server on Debian/Ubuntu. A lot has been accomplished, but quite a bit is still missing too.. May be it is time to try again? Let us see why it yet has not happened? 1) Some components need to be ported to Debian especially Dogtag and a slew of its new RESTEasy dependencies. This requires time and quite an effort from someone familiar with the domain. Yes, this is the biggest blocker. Dogtag 9 is packaged in git and working, but I'm not going to push that to the distro. It can be used for testing the IPA server though, before we have Dogtag 10. Once the prereqs are in place the Dogtag git should be easy to rebase with 10.x. I did start packaging some of the dependencies, but hit a wall when some maven component needed a different release than another one.. AIUI this is a known issue with maven based projects.. I would like to organize the effort to get Dogtag 10 ported to Debian. I know that there are a lot of dependencies needed for this to happen. I can create and maintain a wiki page to track all of the work that is needed to get this porting done. Do you have a list of Dogtag 10 dependencies that are not currently packaged for Debian that I can use as a starting point? Once we have a clear outline of what is needed, we can start trying to divide up and schedule the work. Alright, nice! This is the list I sent to debian-java a year ago, roughly in dependency order: Great, this will help me get started. It might be a bit out of date, as I know that we worked on reducing the number of dependencies within the last year. I'll start with this and cross-reference with the current dependencies. codehaus-parent keytool-maven-plugin maven-help-plugin maven-idea-plugin maven-jarsigner-plugin maven-jxr maven-source-plugin geronimo-parent-poms geronimo-annotation plexus-mail-sender maven-release plexus-resources maven-checkstyle-plugin maven-pmd-plugin maven-anno-plugin maven-reporting-api maven-changes-plugin maven-deploy-plugin apache-james-project javamail base64coder gdata-java sonatype-oss-parent forge-parent mojo-parent maven-plugin-build-helper relaxngcc xsom glassfish-fastinfoset jvnet-parent glassfish-jaxb-api glassfish-dtd-parser stax-ex istack-commons rngom glassfish-jaxb maven-jaxb2-plugin jboss-parent jandex jboss-specs-parent jboss-annotations jetty-parent jetty-toolchain jetty-version-maven-plugin scannotation snakeyml resteasy There might be errors, now that I know that the fedora package of resteasy doesn't built everything to make the deps a bit easier? Yes, resteasy was trimmed to make things easier. And at least codehaus-parent, mojo-parent and jetty-parent are packaged and pushed to git.debian.org but since I'm not a DD (yet) I can't upload them. The debian java policy means that the actual package names are like 'libmojo-parent-java' etc., in case you try to find a package. Do you have more details on the maven issue you were running up against? if my notes are to be trusted, it was that keytool-maven-plugin wants v16 of mojo-parent, and not v30 that is in git now.. Ok, I'll note it down and we can figure out the details when we try it again. Thanks, -NGK ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] PKI-CAD couldn't start
On 07/12/2013 01:58 PM, Dmitri Pal wrote:
On 07/12/2013 05:18 AM, natxo asenjo wrote:
On 07/12/2013 10:55 AM, Christian Schmitt wrote:
I can't start the IPA Service with service ipa start after an reboot.
It fails on the pki-cad service, that only outputs
'grep --help' gives you more information.
I'm really not sure whats the correct error and how to restart ipa now.
logs? look in /var/log/dirsrv/slapd-PKI-{yourinstancename}/ , the
answer should be in one of the files in there.
This is a DS log, you need to look into the PKI-CA log. Unfortunately I
do not recall its location from top of my head.
We need to see if /var/log/pki-ca/catalina.out gives any clues when the
startup fails.
Thanks,
-NGK
If DS is starting then it might be something with CA itself. It is a new
install or an old one that suddenly stopper working?
If the latter it might be that certs have expired.
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] automember issues
On 04/30/2013 10:48 AM, JR Aquino wrote: On Apr 30, 2013, at 10:43 AM, John Moyer john.mo...@digitalreasoning.com wrote: One thing to add is that this build user only has the following access: Host Administrators Host enrollment Would he need more access to do the membership? My original thought was that technically the user is not doing the addition to the group it's the system technically doing it so there shouldn't be a permissions issue. The user's roles shouldn't really matter to the best of my knowledge (Nathan Kinder may need to refresh my memory), but the 389 plugin, should be catching the insertion of the new object, then match the watched-attribute, and execute the hostgroup assignment based upon the rights of the plugin rather than that of the user. This is correct. The user doesn't matter, as the operation that deals with the group membership is done internally by the AutoMember plug-in. Would it be possible to ask you to do an automember-find --type=hostgroup on the CLI and send it back to the thread? If we are missing something or if we have any bugs in there, we need to get them identified and fixed. Thanks, _ John Moyer On Apr 30, 2013, at 1:21 PM, JR Aquino jr.aqu...@citrix.com wrote: On Apr 30, 2013, at 9:30 AM, John Moyer john.mo...@digitalreasoning.commailto:john.mo...@digitalreasoning.com wrote: Anyone have any suggestions to using the auto member function in IPA? I've tried to set it up so if a server is enrolled by a user called build then it should add it to a specific server group. I put in an inclusive rule and the expression is just build, but it doesn't work. Do I need to specify more than just build in the expression area? That -should- be enough to catch new hosts that are built by the 'build' user. Can you verify that the Attribute you are matching on is: enrolledby ? Keeping your head in the cloud ~ Jr Aquino | Sr. Information Security Specialist GXPN | GIAC Exploit Researcher and Advanced Penetration Tester GCIH | GIAC Certified Incident Handler GWAPT | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors://0/0 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrix.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ Keeping your head in the cloud ~ Jr Aquino | Sr. Information Security Specialist GXPN | GIAC Exploit Researcher and Advanced Penetration Tester GCIH | GIAC Certified Incident Handler GWAPT | GIAC WebApp Penetration Tester Citrix Online | 7408 Hollister Avenue | Goleta, CA 93117x-apple-data-detectors://0/0 T: +1 805.690.3478tel:+1%C2%A0805.690.3478 C: +1 805.717.0365tel:+1%20805.717.0365 jr.aqu...@citrix.commailto:jr.aqu...@citrixonline.com http://www.citrixonline.comhttp://www.citrixonline.com/ Thanks, _ John Moyer ___ Freeipa-users mailing list Freeipa-users@redhat.commailto: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] ipa-replica-install errors
On 04/04/2013 07:14 AM, Joseph, Matthew (EXP) wrote: Hello, I'm trying to setup a replica server with ipa-2.2.0-16 on both the Server and the Replica Server. Here are the steps I ran (From the Red Hat 6.3 IdM Administration Guide); *IPA_Server:* ipa-replica-prepare ipareplica.example.com --ip-address 192.168.1.2 scp /var/lib/ipa/replica-info-ipareplica.example.com.gpg root@ ipareplica:/var/lib/ipa/ *IPA_Replica:* ipa-replica-install --setup-ca --setup-dns /var/lib/ipa/replica-info-ipareplica.exam ple.com.gpg -- Below is the error I am getting when running ipa-replica-install; Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'IPA_Server.domain.ca': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@domain.ca password: Execute check on remote master Check connection from master to remote replica 'IPA_Replica.domain.ca': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK PKI-CA: Directory Service port (7389): OK Connection from master to replica is OK. Connection check OK Configuring ntpd [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd done configuring ntpd. Configuring directory server for the CA: Estimated time 30 seconds [1/3]: creating directory server user [2/3]: creating directory server instance [3/3]: restarting directory server done configuring pkids. Configuring certificate server: Estimated time 3 minutes 30 seconds [1/13]: creating certificate server user [2/13]: creating pki-ca instance [3/13]: configuring certificate server instance [4/13]: disabling nonces [5/13]: creating RA agent certificate database [6/13]: importing CA chain to RA certificate database [7/13]: fixing RA database permissions [8/13]: setting up signing cert profile [9/13]: set up CRL publishing [10/13]: set certificate subject base [11/13]: enabling Subject Key Identifier [12/13]: configuring certificate server to start on boot [13/13]: Configure HTTP to proxy connections done configuring pki-cad. Restarting the directory and certificate servers Configuring directory server: Estimated time 1 minute [1/30]: creating directory server user [2/30]: creating directory server instance [3/30]: adding default schema [4/30]: enabling memberof plugin [5/30]: enabling referential integrity plugin [6/30]: enabling winsync plugin [7/30]: configuring replication version plugin [8/30]: enabling IPA enrollment plugin [9/30]: enabling ldapi [10/30]: configuring uniqueness plugin [11/30]: configuring uuid plugin [12/30]: configuring modrdn plugin [13/30]: enabling entryUSN plugin [14/30]: configuring lockout plugin [15/30]: creating indices [16/30]: configuring ssl for ds instance [17/30]: configuring certmap.conf [18/30]: configure autobind for root [19/30]: configure new location for managed entries [20/30]: restarting directory server [21/30]: setting up initial replication Starting replication, please wait until this has completed. [IPA_Server.domain.ca] reports: Update failed! Status: [-11 - System error] creation of replica failed: Failed to start replication Also in the error log(/var/log/dirsrv/slapd-DOMAIN-CA/errors) is the following error; NSMMReplicationPlugin -- agmt=cn=metoIPA_Server.domain.ca (ipa_server:389): Replica has a different generation ID than the local data. This is probably just fallout from the replica initialization failure. If a replica is never initialized, it will get a generation ID mismatch error when the master contacts it. Any thoughts or ideas on this issue? Searching google I don't see anyone getting the Status:-11 -- System Error. There was a bug in 389-ds-base that was fixed a while back where negative LDAP error codes were all printed as System Error. The -11 is a connection error. Here is how it is defined in /usr/include/ldap.h: #define LDAP_CONNECT_ERROR (-11) It sounds like this connection error is occurring
Re: [Freeipa-users] Resynchronize Samba Passwort
On 10/16/2012 05:21 AM, Simo Sorce wrote: On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? What DNA configuration is used? -NGK ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Resynchronize Samba Passwort
On 10/16/2012 02:40 PM, Simo Sorce wrote: On Tue, 2012-10-16 at 14:22 -0700, Nathan Kinder wrote: On 10/16/2012 05:21 AM, Simo Sorce wrote: On Tue, 2012-10-16 at 10:06 +0200, Marc Grimme wrote: Am 15.10.2012 15:50, schrieb Simo Sorce: On Mon, 2012-10-15 at 14:15 +0200, Marc Grimme wrote: Am 14.10.2012 23:14, schrieb Simo Sorce: On Fri, 2012-10-12 at 16:47 +0200, Marc Grimme wrote: Right I am ok with sambaPwdMustChange not being set. That's all good. What about sambaPwdLastSet ? Not set when a user is created new. It should be set when you give the user a password as long at the sambaSamAccount objectclass is added to the user. When I change the password: sambaPwdLastSet: 0 If this is when you set the password as an admin, it is expected. Ok, understood. But it should change when the user resets his/her password, right? And that is not happening. When the user sets his/her password the sambaPwdLastSet stays untouched. That's odd, how does the user change the password ? Not working with samba! Need to apply my script (see below). Let me ask one thing, are you changing the password as a user ? Or have you tested only setting the password as admin ? I set the initial password as admin. Then the user logs in to a server (sssd, ssh, ipa-member) and is requested to change his/her password. This works but the sambaPwdLastSet stays untouched. Ok this is clearly a bug, can you open a bugzilla against RHEL 6.3 ? If the latter this applies: http://www.freeipa.org/page/NewPasswordsExpired Checked it. But that was my understanding nevertheless. I think it may require: SambaSID=S-1-5-21-xx-xx-xx-assign Simo. # ipa user-add tuser2 --first=Test --last=User2 --shell=/bin/false --setattr=SambaSID=S-1-5-21-xx-xx-xx-assign I think that this needs to be --setattr=assign. The prefix should not be included when specifying the magic value to trigger generation. --- Added user tuser2 --- User login: tuser2 First name: Test Last name: User2 Full name: Test User2 Display name: Test User2 Initials: TU Home directory: /home/tuser2 GECOS field: Test User2 Login shell: /bin/false Kerberos principal: tus...@cl.atix UID: 47378 GID: 47378 Password: False Kerberos keys available: False # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix sambaSID: S-1-5-21-xx-xx-xx-assign The following objectclasses are being set when creating a new user: # ldapsearch -LLL -b uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass SASL/GSSAPI authentication started SASL username: ad...@cl.atix SASL SSF: 56 SASL data security layer installed. dn: uid=tuser2,cn=users,cn=accounts,dc=cl,dc=atix objectClass: top objectClass: person objectClass: organizationalperson objectClass: inetorgperson objectClass: inetuser objectClass: posixaccount objectClass: krbprincipalaux objectClass: krbticketpolicyaux objectClass: ipaobject objectClass: sambaSAMAccount objectClass: ipasshuser objectClass: ipaSshGroupOfPubKeys objectClass: mepOriginEntry Thanks for your help Seem like a DNA bug ... then, Nathan do you have any idea ? What DNA configuration is used? From a previous mail this look to be the config. Marc is this still correct ? Although my configurations looks ok, doesn't it? # ldapsearch -LLL -b cn=SambaSID,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config -D cn=Directory Manager -x -W Enter LDAP Password: dn: cn=SambaSid,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject dnatype: sambaSID dnaprefix: S-1-5-21-1310149461-105972258- dnainterval: 1 dnamagicregen: assign dnafilter: (|(objectclass=sambasamaccount)(objectclass=sambagroupmapping)) dnascope: dc=atix,dc=cl cn: SambaSid dnanextvalue: 15400 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] UID 999, not possible?
On 07/03/2012 12:38 AM, Petr Viktorin wrote: On 07/03/2012 05:55 AM, Nathan Kinder wrote: On 06/29/2012 07:10 AM, Petr Viktorin wrote: On 06/29/2012 03:55 PM, Alexander Bokovoy wrote: On Fri, 29 Jun 2012, Petr Viktorin wrote: On 06/29/2012 03:04 PM, Alexander Bokovoy wrote: On Thu, 28 Jun 2012, sysad...@noboost.org wrote: Hi All, Is there a weird restriction to UID 999 in ipa, as IPA keeps changing the UID when I add a user with that number? (I've already checked the UID isn't in use) We use 999 as a marker for DNA plugin. UID/GID 999 is replaced by an allocated one with the help of the 389-ds plugin http://directory.fedoraproject.org/wiki/DNA_Plugin http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Defining_Dynamic_Atrribute_Values.html#about-dunamically-assigning-attribute-values The documentation mentions that the magic value can be a word (magic), or it doesn't have to exist at all (it's added for objectClass:posixAccount entries). Is there a reason IPA is using 999 here? uidNumber and gidNumber field use integer value syntax: OID value: 1.3.6.1.4.1.1466.115.121.1.27 OID description: Values in this syntax are encoded as the decimal representation of their values, with each decimal digit represented by the its character equivalent. So the number 1321 is represented by the character string 1321. So, you can't have string there that does not evaluate to integer. That's true, but according to the documentation you linked, uidNumber/gidNumber syntax doesn't matter. The dnaMagicRegen field is in fact a DirectoryString. I assume the DNA plugin sees and modifies the value before it's validated as an integer. I wouldn't trust this, as DNA was initially designed/implemented before we added syntax validation to 389. DNA was also written to be able to work with non integer attributes, where values have some sort of prefix followed by an integer (such as user1, user2, etc.). For this reason, dnaMagicRegen was left as Directory String syntax. I personally feel that it is safer to have the magic value be syntactically valid for the attribute that DNA is configured to generate. Best go with a negative number then. The DS docs should be updated if you don't trust what they say, though. I should have been a bit more clear. I believe that the core 389 DS code does handle replacing the magic value before the syntax is checked, but we have encountered issues with client applications trying to enforce syntax before the server receives the operation. An example of this is the 389-console application (which FreeIPA doesn't use). The Console knows that the uidNumber attribute is defined to use the Integer syntax, so the UI field is validated before it can be submitted to the server. Other client applications may do similar things by looking up the schema definitions on the server and trying to do some client-side validation. This sort of behavior prevents the ability to trigger DNA if the magic value does not meet the syntax requirements of the attribute. Again, this may not affect FreeIPA, but I wanted to provide a bit of background. On 06/29/2012 04:23 PM, Alexander Bokovoy wrote: Looks like you are right: http://comments.gmane.org/gmane.linux.redhat.fedora.directory.user/10641 We would have issue on our side when using non-integer value as Int() parameter does not support non-integer values. However, we could select some negative value as default one and use the same value for DNA configuration. The value can be optional, the server can fill in the default if it's not received from the client. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] UID 999, not possible?
On 06/29/2012 07:10 AM, Petr Viktorin wrote: On 06/29/2012 03:55 PM, Alexander Bokovoy wrote: On Fri, 29 Jun 2012, Petr Viktorin wrote: On 06/29/2012 03:04 PM, Alexander Bokovoy wrote: On Thu, 28 Jun 2012, sysad...@noboost.org wrote: Hi All, Is there a weird restriction to UID 999 in ipa, as IPA keeps changing the UID when I add a user with that number? (I've already checked the UID isn't in use) We use 999 as a marker for DNA plugin. UID/GID 999 is replaced by an allocated one with the help of the 389-ds plugin http://directory.fedoraproject.org/wiki/DNA_Plugin http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/9.0/html/Deployment_Guide/Defining_Dynamic_Atrribute_Values.html#about-dunamically-assigning-attribute-values The documentation mentions that the magic value can be a word (magic), or it doesn't have to exist at all (it's added for objectClass:posixAccount entries). Is there a reason IPA is using 999 here? uidNumber and gidNumber field use integer value syntax: OID value: 1.3.6.1.4.1.1466.115.121.1.27 OID description: Values in this syntax are encoded as the decimal representation of their values, with each decimal digit represented by the its character equivalent. So the number 1321 is represented by the character string 1321. So, you can't have string there that does not evaluate to integer. That's true, but according to the documentation you linked, uidNumber/gidNumber syntax doesn't matter. The dnaMagicRegen field is in fact a DirectoryString. I assume the DNA plugin sees and modifies the value before it's validated as an integer. I wouldn't trust this, as DNA was initially designed/implemented before we added syntax validation to 389. DNA was also written to be able to work with non integer attributes, where values have some sort of prefix followed by an integer (such as user1, user2, etc.). For this reason, dnaMagicRegen was left as Directory String syntax. I personally feel that it is safer to have the magic value be syntactically valid for the attribute that DNA is configured to generate. If there is, the command should fail instead of silently assigning a different number than asked for. I'll file a bug for this. DNA_MAGIC in user.py is defined to 999 and it is default value to uidNumber and gidNumber options. We have no way to differentiate between default and entered by user but the same value. Yes, the server would need to verify if the client has been fixed. This means either waiting for the next major API version, or looking at the version/capabilities the client sends us. (See Martin's message from 2012-06-20 in thread [Freeipa-devel] [PATCH] 0062 Don't crash when server returns extra output). [root@sysvm-ipa ~]# ipa user-add administrator --uid=999 --gidnumber=132 --first=administrator --last=administrator -- Added user administrator -- User login: administrator First name: administrator Last name: administrator Full name: administrator administrator Display name: administrator administrator Initials: aa Home directory: /home/administrator GECOS field: administrator administrator Login shell: /bin/bash Kerberos principal: administra...@example.com UID: 72162 GID: 132 Keytab: False Password: False cya Craig ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Petr³ ___ 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] HBAC rule refreshes and read-only slaves
On 06/08/2012 07:26 AM, Dmitri Pal wrote: On 06/07/2012 09:22 PM, Cam McK wrote: Hello 2). We would also like to use FreeIPA in a trusted network but then have perhaps a read-only slave sitting in DMZ with the possibility of not containing the KDC or LDAP password stores on it, is this possible? (Basically authentication being done by a different PAM module, but pam_sss.so still allowing HBAC via the PAM 'account' directive.) Is it possible to have a 'regular' LDAP directory (in the DMZ) just slurping down the required LDAP info? I suggest using an LDAP directory that can do proxy operations or proxy authentications. You might consider 389 and sync in some user accounts and groups while using pam passtrough capabilities. I think recent upstream versions of 389 made this configuration possible but you need to check with them. #389 on freenode is your best bet. Openldap has some capabilities that might be of the value here too. 389 can consult PAM to authenticate a user when performing an LDAP BIND operation. This would probably take care of the authentication piece of the puzzle. You would also need to use fractional replication to avoid replicating things like passwords or Kerberos related attributes to the DMZ LDAP server. Fractional replication can only trim out specific attributes. It does not allow you to select portions of the tree to replicate at the entry level. This would mean that all of your user accounts would need to be replicated out to the DMZ LDAP server, but you could trim sensitive attributes. I am not quite sure what you are trying to accomplish here so a bit more details would be helpful. More details would definitely help. I don't think you can easily accomplish what you want right now. It could be possible with a lot of manual configuration of 389 on both the IPA and DMZ LDAP server sides, but I don't think anyone has set things up in this way with IPA before. -NGK Many Thanks Campbell ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users -- Thank you, Dmitri Pal Sr. Engineering Manager IPA project, Red Hat Inc. --- 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 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Auto membership plugin
On 04/08/2011 09:07 AM, Dmitri Pal wrote: On 04/08/2011 11:49 AM, JR Aquino wrote: Is there any way to capture a description associated with the regex - group mapping? I was thinking that after time, it would be important to look back on rules and know why they were put there. Particularly in the case of regex, since it may not be completely obvious by looking back at alphabet soup. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users The more I think about current design the more I want to normalize things. I would rather instead of: dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberExclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www5\.example\.com autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^www[1-9]+\.example\.com autoMemberInclusiveRegex: cn=webservers,cn=hostgroups,dc=example,dc=com:fqdn=^web[1-9]+\.example\.com autoMemberInclusiveRegex: cn=mailservers,cn=hostgroups,dc=example,dc=com:fqdn=^mail[1-9]+\.example\.com autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com autoMemberGroupingAttr: member:dn Have something like: dn: cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinition objectclass: cnContainer autoMemberScope: dc=example,dc=com autoMemberFilter: objectclass=ipaHost autoMemberRegexRule: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config autoMemberRegexRule: cn=Mailserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config autoMemberRegexRule: cn=Desktop exclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config autoMemberDefaultGroup: cn=orphans,cn=hostgroups,dc=example,dc=com autoMemberGroupingAttr: member:dn dn: cn=Webserver Inclusion Rule,cn=Hostgroups,cn=Auto Membership Plugin,cn=plugins,cn=config objectclass: autoMemberDefinitionRegexRule cn: Webserver Inclusion Rule description: Rule contains regular expression to include webserver hosts into the webserver group. include: yes- include or exclude memberGroup: cn=webservers,cn=hostgroups,dc=example,dc=com arrtibuteToMath: fgdn expressionToMatch: ^www[1-9]+\.example\.com Or something along those lines... It's a nice logical layout, but it would be hard for an administrator to figure out what exactly would happen if they were to add a host with a specific hostname. Since the config is spread over so many entries, one would have to look at the top level config entry to find each rule DN, fetch each rule DN to look at the regexes. All of the information is so spread out that you can't just look in one place to see the rules that will be used. This could make things difficult from a troubleshooting perspective. The description issue is a tough one to deal with if we have the config in the form that is currently described in the design doc. Since we want a description per regex rule, we should need to make the description be a part of the regex rule value instead of a separate description attribute. I don't necessarily like this approach, as the readability of the config will not be nice. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Auto membership plugin
On 03/30/2011 06:32 AM, Rob Crittenden wrote: Dmitri Pal wrote: Hello, Please find the design for the auto membership plugin: https://fedorahosted.org/freeipa/ticket/753 Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design I have some comments and questions: 1) Is the AND functionality for inclusion criteria required? 2) How the attributes are escaped? Do they need to? Probably there will be cases when they should be escaped 3) Parsing pairs in the value as a bit of overhead. I wonder if there is any way to avoid it? 4) I have concerns about the UI and CLI, do you see any good ways to mange such entries? Because the configuration is stored in cn=config we would need to bind as DM to be able to manage it (unless we want to make an exception and allow writing here. Could a bad config could prevent 389-ds from starting). No. Similar to a bad DNA or managed entry setup, an error would be logged and the bad config entry would be skipped. I assume a restart would be needed whenever a configuration change is made? Only enabling the plug-in at the top level, which we could enabled by default. The definition entry changes would be dynamic. What happens if the target in automembertargetgroup gets removed? I still need to fill in the Behavior section in the design doc, but this plug-in is not a referential integrity plug-in. It simply monitors ADD operations and updates the membership accordingly. Nothing is done for MOD, DEL, or MODRDN operations. -NGK rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Auto membership plugin
On 03/30/2011 06:00 AM, Dmitri Pal wrote: Hello, Please find the design for the auto membership plugin: https://fedorahosted.org/freeipa/ticket/753 Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design I have some comments and questions: 1) Is the AND functionality for inclusion criteria required? I'm not sure. Is there a use case for it? 2) How the attributes are escaped? Do they need to? Probably there will be cases when they should be escaped Where exactly are you thinking that they need to be escaped? Why do you think they might need to be escaped? 3) Parsing pairs in the value as a bit of overhead. I wonder if there is any way to avoid it? Do you mean parsing the pair contained in the autoMemberGroupingAttr attribute in the config definition entry? This will only be parsed when the definition entry is loaded at startup or when it is modified. It would be stored in a different form that is more efficient to use when we actually need to perform auto membership operations. -NGK 4) I have concerns about the UI and CLI, do you see any good ways to mange such entries? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Auto membership plugin
On 03/30/2011 08:06 AM, Dmitri Pal wrote: On 03/30/2011 10:43 AM, Nathan Kinder wrote: On 03/30/2011 07:34 AM, Rob Crittenden wrote: Nathan Kinder wrote: On 03/30/2011 06:32 AM, Rob Crittenden wrote: Dmitri Pal wrote: Hello, Please find the design for the auto membership plugin: https://fedorahosted.org/freeipa/ticket/753 Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design I have some comments and questions: 1) Is the AND functionality for inclusion criteria required? 2) How the attributes are escaped? Do they need to? Probably there will be cases when they should be escaped 3) Parsing pairs in the value as a bit of overhead. I wonder if there is any way to avoid it? 4) I have concerns about the UI and CLI, do you see any good ways to mange such entries? Because the configuration is stored in cn=config we would need to bind as DM to be able to manage it (unless we want to make an exception and allow writing here. Could a bad config could prevent 389-ds from starting). No. Similar to a bad DNA or managed entry setup, an error would be logged and the bad config entry would be skipped. Ok, great. But we would still need to carve out an exception for allow people to write in cn=config, right? Yes, someone will need to write the config entry, so that will need to be allowed. But can it be an ordinary user controlled by CLI or it is a DM? I believe this could be done by a normal (admin) user if the ACI allows it. Will newly added rule be respected right away? Yes, changes to the definition entry would be respected right away. You probably want to have an enable/disable flag on the rule to give some staging capability to the admin. Makes sense. I assume a restart would be needed whenever a configuration change is made? Only enabling the plug-in at the top level, which we could enabled by default. The definition entry changes would be dynamic. What happens if the target in automembertargetgroup gets removed? I still need to fill in the Behavior section in the design doc, but this plug-in is not a referential integrity plug-in. It simply monitors ADD operations and updates the membership accordingly. Nothing is done for MOD, DEL, or MODRDN operations. I was thinking more what happens if the targetgroup is deleted and a new user is added? Will this result in a failed modify or would the user get a member pointer to a non-existent entry, or something else? That's an interesting case. It would result in a failed modify, as we would not be able to update the non-existent group entry. This plug-in does not add a pointer to the user entry (that's done by the memberOf plug-in if it is desired). The usre entry would still be consistent, but you would have an error in the errors log about the failed modify. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users All the rest seems fine so far. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Auto membership plugin
On 03/30/2011 08:03 AM, Dmitri Pal wrote: On 03/30/2011 10:39 AM, Nathan Kinder wrote: On 03/30/2011 06:00 AM, Dmitri Pal wrote: Hello, Please find the design for the auto membership plugin: https://fedorahosted.org/freeipa/ticket/753 Here: http://directory.fedoraproject.org/wiki/Auto_Membership_Design I have some comments and questions: 1) Is the AND functionality for inclusion criteria required? I'm not sure. Is there a use case for it? 2) How the attributes are escaped? Do they need to? Probably there will be cases when they should be escaped Where exactly are you thinking that they need to be escaped? Why do you think they might need to be escaped? Wild cards and regular expression might have special symbols like = \ slashes etc. If we decode to support AND it would probably be solved by concatenating multiple attr=regex pairs in one attribute. I am concerned it will be a challenge to parse. We use libpcre elsewhere in 389 to allow regular expressions to be used. We actually have a public regular expression API within SLAPI (the slapi_re_* functions). We would leverage these functions in this plug-in. The SASL mapping code already uses these for something similar, so there is not a new problem to solve here. 3) Parsing pairs in the value as a bit of overhead. I wonder if there is any way to avoid it? Do you mean parsing the pair contained in the autoMemberGroupingAttr attribute in the config definition entry? This will only be parsed when the definition entry is loaded at startup or when it is modified. It would be stored in a different form that is more efficient to use when we actually need to perform auto membership operations. Yes I am concerned about parsing pairs for the purposes of the modify operation in CLI/UI. This is only done when loading the config, so it's a one-time penalty at startup or when the config is modified (which should be fairly rare). I wouldn't worry about this. -NGK 4) I have concerns about the UI and CLI, do you see any good ways to mange such entries? ___ 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] 389 DS server closing connection after upgrade from Fedora 12 to 13
On 02/21/2011 07:10 AM, Simo Sorce wrote: On Mon, 21 Feb 2011 02:07:36 +0100 tomasz.napier...@allegro.pltomasz.napier...@allegro.pl wrote: Feb 20 23:47:19 Updated: 389-ds-base-1.2.7.5-1.fc13.x86_64 Any one have an idea what could be the reason? If I remember correctly, some people reported similar issues with 1.2.7 It doesn't affect everyone but afaik the lock-up bug has been fixed in the 1.2.8 alphas. Yes, I believe that this may be https://bugzilla.redhat.com/show_bug.cgi?id=668619. It will be fixed in 389-ds-base-1.2.8, which has alpha builds with the fix available now. You may want to try to upgrade 389ds with the version in updates-testing and see if that fixes this problem. Simo. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On 10/08/2010 12:08 PM, Dan Scott wrote:
On Fri, Oct 8, 2010 at 14:52, James Romanjames.ro...@ssaihq.com wrote:
On 10/08/2010 01:49 PM, Dan Scott wrote:
On Fri, Oct 8, 2010 at 13:18, Rich Megginsonrmegg...@redhat.comwrote:
Dan Scott wrote:
On Fri, Oct 8, 2010 at 11:39, James Romanjames.ro...@ssaihq.com
wrote:
So does anyone have any more suggestions? Or should I just configure a
new replica with new hostname and IP?
Thanks,
Dan
I've seen the initial problem where the memberof elements stop updating
on
my own FreeIPA v1 replica as well. Normally it happens after I perform
a
full init of the replica. The subsequent errors you are experiencing
have
not occurred on my system. You have not indicated a synchronization
error
anywhere, but they tend to get buried in the error logs. I assume you
are
not short on disk space on the replica. I also assume that the /var has
not
been mounted as read-only. (I've had a few oddities where disk/storage
problems have caused a file-system to be remounted read-only recently)
Out of curiosity, if you modify a user on the replica, do the changes
get
saved to the record? If you add a user to a new group on the replica
does
the memberof attribute get added to the user's record?
Hmm, very strange. Adding my user to another group appears to have
fixed the memberOf attributes for my user on the replica
Presumably, the fixup-memberof.pl script is supposed to do this -
strange that it does not appear to work.
I can create a temporary group, add all users to it and then remove
them again - possibly that would fix the problem?
I'm still a little concerned by log entries such as (on the replica):
NSMMReplicationPlugin - replica_check_for_data_reload: Warning: data
for replica dc=example,dc=com was reloaded and it no longer matches
the data in the changelog (replica datachangelog). Recreating the
changelog file. This could affect replication with replica's consumers
in which case the consumers should be reinitialized.
You should only see this once. This is ok for an initial initialization
or
a reinitialization.
OK, thanks. I also get the following (on both master and replica) on
each alteration of LDAP:
NSMMReplicationPlugin - repl_set_mtn_referrals: could not set
referrals for replica dc=example,dc=com: 20
Is this expected/normal?
Thanks,
Dan
Dan
I was going to suggest reinitializing the sync agreement and running the
fixmemberof script again. Did I miss that you have actually done that
already?
Yes, once I realised that there were difference between the master and
replica I ran:
ipa-replica-manage init ohm.example.com
from curie. To try and get the syncing working.
If not than that error seems pretty out of place. Before you do run
the following script on both servers (replacing dc=example and hostname) and
remove the admin group from any that you find on both servers before doing
your re-init.
ldapsearch -Y GSSAPI -h hostname -b
cn=groups,cn=accounts,dc=example,dc=com
'(member=cn=admins,cn=groups,cn=accounts,dc=example,dc=com)'
I did have a group which contained the admins group as a member. I
removed this yesterday and so there are now no groups containing the
member 'admins'.
The test of adding the user to the group was only to test that the
ipa-memberof plug-in is functioning properly on the replica. It is triggered
by a group change on the server. The fixmemberof script is really a much
more efficient way of updating all accounts.
Yes, but the fixmember script doesn't appear to work. It appeared to
successfully add the entry:
cn=memberOf_fixup_2010_10_8_15_6_11
but the memberOf attributes weren't corrected.
The way that the memberOf fixup task works is that a search is performed
using the specified search base and optional filter that are supplied
when the task is created. Each matching entry has it's memberOf
attribute values removed and the memberOf values are re-computed.
The reason that the task did not work for you is that you set the base
for the fixup task to cn=groups,cn=accounts,dc=example,dc=com. This
search base does not contain any of your user entries, so noe of them
had their memberOf attribute re-computed. The search base needs to
contain your user entries that you want fixed up.
-NGK
One other consideration, are both server time in sync (at least within 5
minutes) but in general, you want them to be pretty close.
Yes, they are both in sync ('Exactly' in sync, 1s apart as far as I can tell).
Thanks for your help.
Dan
___
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] Replica not syncing 'memberOf' attributes
On 10/06/2010 07:03 PM, Rich Megginson wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 19:29, Nathan Kinder nkin...@redhat.com wrote: On 10/06/2010 03:08 PM, Dan Scott wrote: I'm not sure which group this is referring to. Admins only contains 3 users, no nested groups. Do any other groups have a member attribute that points to your cn=admins group's DN? The error message indicates that some other group has your admins group as a member. Yes, I do have another group of which admins is a member. I have removed it temporarily. Would this be a problem normally? I'm not sure how the memberOf plugin is supposed to handle situations like this. The memberOf plug-in leaves it up to the administrator to ensure that the proper objectClasses are present on objects that it wants to add memberOf to. When the plug-in encounters an issue where the memberOf attribute it not allowed on an entry, it simply continues on to the next entry. This one grouping error should not cause any other issues with memberOf working for other groups. From an FreeIPA perspective, should it be allowed to list the cn=admins group as a member of another group? If so, the proper objectClass needs to be added to cn=admins to allow the memberOf attribute. Thanks, Dan -NGK The problem appears to be related to the users, rather than the groups. None of the users on ohm have a 'memberOf'. Curie has the correct memberOf attributes. The groups themselves appear to be correct on both servers. Both ohm and curie have groups which contain the correct 'member' attributes. So the problem appears to be that ohm contains groups with correct 'members', but none of the users have any 'memberOf's. Thanks, Dan On Wed, Oct 6, 2010 at 16:17, Rich Megginsonrmegg...@redhat.com wrote: Dan Scott wrote: Hi, ohm_admins.ldif and curie_admins.ldif attached. I added a '-h $hostname' to the command to ensure that I queried both servers. The results look identical to me, apart from the ordering. Thanks, Dan On Wed, Oct 6, 2010 at 15:34, Rob Crittendenrcrit...@redhat.com wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.com wrote: On Wed, 6 Oct 2010 10:26:48 -0400 Dan Scottdanieljamessc...@gmail.comwrote: Hi, I have master and slave FreeIPA servers. I recently upgraded the slave by wiping, re-installing Fedora 13 and re-creating the replication using ipa-replica-prepare and ipa-replica-install. For some reason, the slave is having difficulty replicating the memberOf attribute. I can attach an LDAP viewer to the replica, and view the schema, but the memberOf attributes are missing. Also, the master server contains the lines: - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com -- attribute memberOf not allowed NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=example,dc=com: 20 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for replica dc=example,dc=com does not match the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account inactivation,cn=accounts,dc=example,dc=com--no templates found The rest of the replication appears to be working correctly (as far as I can tell). I have tried using ipa-replica-manage init and synch to try to fix the replication, but I suspect this has something to do with the schema definition. Does anyone have any pointers/ideas for how I can fix this? Dan, the memberof attribute is explicitly not replicated, and should be simply re-generated on the receiving replica when member attributes are replicated. So does this imply that there is some corruption in the schema on the replica server? Are the IPA versions on the master and the replica the same ? They are both the same version: ipa-server-1.2.2-4.fc13.x86_64 Thanks, Dan Scott It is complaining that memberOf isn't allowed in the admins group which is pretty strange. Can you show us the admins group out of the replica and master? ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins Neither one has the inetUser objectclass which allows the use of memberOf. But why is it attempting to add memberOf to this entry which is itself a group entry? Is this some sort of nested group? thanks 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
Re: [Freeipa-users] Replica not syncing 'memberOf' attributes
On 10/06/2010 03:08 PM, Dan Scott wrote: I'm not sure which group this is referring to. Admins only contains 3 users, no nested groups. Do any other groups have a member attribute that points to your cn=admins group's DN? The error message indicates that some other group has your admins group as a member. -NGK The problem appears to be related to the users, rather than the groups. None of the users on ohm have a 'memberOf'. Curie has the correct memberOf attributes. The groups themselves appear to be correct on both servers. Both ohm and curie have groups which contain the correct 'member' attributes. So the problem appears to be that ohm contains groups with correct 'members', but none of the users have any 'memberOf's. Thanks, Dan On Wed, Oct 6, 2010 at 16:17, Rich Megginsonrmegg...@redhat.com wrote: Dan Scott wrote: Hi, ohm_admins.ldif and curie_admins.ldif attached. I added a '-h $hostname' to the command to ensure that I queried both servers. The results look identical to me, apart from the ordering. Thanks, Dan On Wed, Oct 6, 2010 at 15:34, Rob Crittendenrcrit...@redhat.com wrote: Dan Scott wrote: Hi, On Wed, Oct 6, 2010 at 11:32, Simo Sorcesso...@redhat.comwrote: On Wed, 6 Oct 2010 10:26:48 -0400 Dan Scottdanieljamessc...@gmail.comwrote: Hi, I have master and slave FreeIPA servers. I recently upgraded the slave by wiping, re-installing Fedora 13 and re-creating the replication using ipa-replica-prepare and ipa-replica-install. For some reason, the slave is having difficulty replicating the memberOf attribute. I can attach an LDAP viewer to the replica, and view the schema, but the memberOf attributes are missing. Also, the master server contains the lines: - Entry cn=admins,cn=groups,cn=accounts,dc=example,dc=com -- attribute memberOf not allowed NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica dc=example,dc=com: 20 NSMMReplicationPlugin - replica_reload_ruv: Warning: new data for replica dc=example,dc=com does not match the data in the changelog. Recreating the changelog file. This could affect replication with replica's consumers in which case the consumers should be reinitialized. [06/Oct/2010:09:58:33 -0400] - skipping cos definition cn=account inactivation,cn=accounts,dc=example,dc=com--no templates found The rest of the replication appears to be working correctly (as far as I can tell). I have tried using ipa-replica-manage init and synch to try to fix the replication, but I suspect this has something to do with the schema definition. Does anyone have any pointers/ideas for how I can fix this? Dan, the memberof attribute is explicitly not replicated, and should be simply re-generated on the receiving replica when member attributes are replicated. So does this imply that there is some corruption in the schema on the replica server? Are the IPA versions on the master and the replica the same ? They are both the same version: ipa-server-1.2.2-4.fc13.x86_64 Thanks, Dan Scott It is complaining that memberOf isn't allowed in the admins group which is pretty strange. Can you show us the admins group out of the replica and master? ldapsearch -x -b 'cn=groups,cn=accounts,dc=example,dc=com' cn=admins Neither one has the inetUser objectclass which allows the use of memberOf. But why is it attempting to add memberOf to this entry which is itself a group entry? Is this some sort of nested group? thanks 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
