Re: [Freeipa-users] No result when trying to integrate a FreeBSD client with the FreeIPA server
Further to my earlier email, I have written a blog post about all these matters, with a particular focus on the custom package repo. I will update it tomorrow with a bit more about the package flavours topic. For now, all the details for enabling and using the custom repo are in the post. Check it out and let me know if you spot any issues. http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ Cheers, Fraser On Wed, Oct 22, 2014 at 09:13:11AM +0500, Orkhan Gasimov wrote: Great news! If I understand correctly, a package can be equivalent to several ports? If this is correct, then could a composite package be built to include all necessary ports? * _security/sssd_ http://www.freshports.org/security/sssd * _security/sudo_ http://www.freshports.org/security/sudo(with SSSD backend) * _net/openldap24-client-sasl_ http://www.freshports.org/net/openldap24-client-sasl * security/cyrus-sasl2 * security/cyrus-sasl2-gssapi That package could be called something like ipa-client, and make FreeBSD - FreeIPA integration one step closer. If not possible, even a pkg equivalent to /security/sssd would eliminate existing possibilities for misconfiguration. 22-Oct-14 07:06, Fraser Tweedale пишет: I have prepared a custom pkg(8) repo with the packages built with the required options/make.conf variables. Hang tight, I'll send all the info soon. -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On 22.10.2014 09:10, Fraser Tweedale wrote: Further to my earlier email, I have written a blog post about all these matters, with a particular focus on the custom package repo. I will update it tomorrow with a bit more about the package flavours topic. For now, all the details for enabling and using the custom repo are in the post. Check it out and let me know if you spot any issues. http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ Hello Fraser and others, it would be great if you could add links to your FreeIPA-related blog posts to http://www.freeipa.org/page/HowTos . We are trying to build kind of 'documentation hub' with links to relevant posts stored elsewhere. It is even fine to add links to mailing list archives if the particular post is useful to broad audience. Have a nice day! Petr^2 Spacek Cheers, Fraser On Wed, Oct 22, 2014 at 09:13:11AM +0500, Orkhan Gasimov wrote: Great news! If I understand correctly, a package can be equivalent to several ports? If this is correct, then could a composite package be built to include all necessary ports? * _security/sssd_ http://www.freshports.org/security/sssd * _security/sudo_ http://www.freshports.org/security/sudo(with SSSD backend) * _net/openldap24-client-sasl_ http://www.freshports.org/net/openldap24-client-sasl * security/cyrus-sasl2 * security/cyrus-sasl2-gssapi That package could be called something like ipa-client, and make FreeBSD - FreeIPA integration one step closer. If not possible, even a pkg equivalent to /security/sssd would eliminate existing possibilities for misconfiguration. 22-Oct-14 07:06, Fraser Tweedale пишет: I have prepared a custom pkg(8) repo with the packages built with the required options/make.conf variables. Hang tight, I'll send all the info soon. -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On (22/10/14 17:10), Fraser Tweedale wrote:
Further to my earlier email, I have written a blog post about all
these matters, with a particular focus on the custom package repo.
I will update it tomorrow with a bit more about the package
flavours topic. For now, all the details for enabling and using
the custom repo are in the post. Check it out and let me know if
you spot any issues.
http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/
The disadvantage of this approach is that users need to rely on updating
of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA
In my opinion, it's better to write howto (script) which will configure all
necessary ports/files and portmaster will take care of updating ports.
https://www.freebsd.org/doc/handbook/ports-using.html#portmaster
LS
--
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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On Thu, Oct 23, 2014 at 12:23 AM, Lukas Slebodnik lsleb...@redhat.com
wrote:
On (22/10/14 17:10), Fraser Tweedale wrote:
Further to my earlier email, I have written a blog post about all
these matters, with a particular focus on the custom package repo.
I will update it tomorrow with a bit more about the package
flavours topic. For now, all the details for enabling and using
the custom repo are in the post. Check it out and let me know if
you spot any issues.
http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/
The disadvantage of this approach is that users need to rely on updating
of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA
In my opinion, it's better to write howto (script) which will configure all
necessary ports/files and portmaster will take care of updating ports.
https://www.freebsd.org/doc/handbook/ports-using.html#portmaster
LS
As an avid BSD user, with FreeIPA cloud deployed, ill fire up some FreeBSD
VMs and see if i can get a running system,
using the thread here, and the doc thats been written to sanity check
things and possibly help out with the packaging
if I can. I only need to consider, that I run Launchd on my FreeBSD
systems, so ill need to go deeper, with modified start
scripts. Ill do a few rc based stock installs of 10.1 See how we go.
--
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
--
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] mastercrl.bin very old
Natxo Asenjo wrote: On Mon, Oct 13, 2014 at 9:39 PM, Natxo Asenjo natxo.ase...@gmail.com wrote: But if I get it from the crl generator using /ipa/crl/MasterCRL.bin I still get the old crl dated june 28th last year. Should I modify ipa-pki-proxy.conf as well on the CRL generator host to point to the /ca/ee/ca/getCRL?op=getCRLcrlIssuingPoint=MasterCRL as well? This morning the /ipa/crl dir still had the lists of 28th June 2013 in the crl generator host. In my test environment running centos 7 the files get updated, so I think a process is nut running. But which one? Going to the /ca/ee/ca/getCRL?op=getCRL crlIssuingPoint=MasterCRL gives me the up to date CRL. -- Groeten, natxo To enable CRL generation you need these set: ca.crl.MasterCRL.enableCRLCache=false ca.crl.MasterCRL.enableCRLUpdates=false Given that the CA seems to be generating a new CRL that you can fetch directly I'll assume those are set. The CA also needs configuration on how/where to publish a file-based CRL. The configuration should look like: ca.publish.publisher.instance.FileBaseCRLPublisher.crlLinkExt=bin ca.publish.publisher.instance.FileBaseCRLPublisher.directory=/var/lib/ipa/pki-ca/publish ca.publish.publisher.instance.FileBaseCRLPublisher.latestCrlLink=true ca.publish.publisher.instance.FileBaseCRLPublisher.pluginName=FileBasedPublisher ca.publish.publisher.instance.FileBaseCRLPublisher.timeStamp=LocalTime ca.publish.publisher.instance.FileBaseCRLPublisher.zipCRLs=false ca.publish.publisher.instance.FileBaseCRLPublisher.zipLevel=9 ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.b64=false ca.publish.publisher.instance.FileBaseCRLPublisher.Filename.der=true ca.publish.rule.instance.FileCrlRule.publisher=FileBaseCRLPublisher rob -- 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] Attempting to re-provision previous replica
Hello all,
First and foremost, a big thank you! to the FreeIPA developers for a
great product!
Now, to the point!
We're trying to re-provision a previous replica using the standard
documentation via the Red Hat site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html
However, we're running into errors during the import process. The
errors are varied and fail at random steps; there was an issue with
NTP or HTTP or LDAP, etc. This did not happen when we promoted a
separate node to become a replica.
We had previously removed the replica via `ipa-replica-manage del` and
ensured that no trace of it being a replica existed: removed DNS
records and verified that the host enrollment was not present. I did
not use the --force and --cleanup options.
When I check RUV's against the host in question, there are several. I
also queried the tombstones against the host and found two entries
which have valid hex time stamps; coincidentally, out of the 9
tombstone entries, 2 have nsds50ruv time stamps. I'll paste
sanitized output below:
# ldapsaerch -x -W -LLL -D cn=directory manager -b
dc=our,dc=personal,dc=domain '(objectclass=nsTombstone)'
Enter LDAP Password:
dn: nsuniqueid=---,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50ef13ae0004
nsds50ruv: {replica 4 ldap://master.our.personal.domain:389}
5164d1470004 5447bda 800010004
nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389}
54107f9f0016 54436b 250016
nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389}
51b734de0015 51b7 34ef00020015
nsds50ruv: {replica 19
ldap://host-in-question.our.personal.domain:389} 510d56c900010013
510d82 be00020013
nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 23
ldap://host-in-question.our.personal.domain:389} 5418770200020017
541878 9a0017
dc: our
nsruvReplicaLastModified: {replica 4
ldap://master.our.personal.domain:389} 5447bce8
nsruvReplicaLastModified: {replica 22
ldap://separatenode.our.personal.domain:389} 54436a5e
nsruvReplicaLastModified: {replica 21
ldap://iparepbackup.our.personal.domain:389}
nsruvReplicaLastModified: {replica 19
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 18
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 17
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 16
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 15
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 14
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 13
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 12
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 23
ldap://host-in-question.our.personal.domain:389}
dn:
nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn: host-in-question.our.personal.domain
nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0
dn:
nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn: host-in-question.our.personal.domain
nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0
As you can see, the host-in-question has many RUV's and of which two
appear to be active and two entries which I believe (pardon my
ignorance) possibly correlate with the active entries of the
host-in-question.
Do these two tombstone entries need to be deleted with ldapdelete
before we can re-provision host-in-question and add it back as a
replica?
Thank you,
John DeSantis
--
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] Attempting to re-provision previous replica
On 10/22/2014 09:42 AM, John Desantis wrote:
Hello all,
First and foremost, a big thank you! to the FreeIPA developers for a
great product!
Now, to the point!
We're trying to re-provision a previous replica using the standard
documentation via the Red Hat site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html
However, we're running into errors during the import process. The
errors are varied and fail at random steps; there was an issue with
NTP or HTTP or LDAP, etc. This did not happen when we promoted a
separate node to become a replica.
We had previously removed the replica via `ipa-replica-manage del` and
ensured that no trace of it being a replica existed: removed DNS
records and verified that the host enrollment was not present. I did
not use the --force and --cleanup options.
What version of 389 are you using?
rpm -q 389-ds-base
When I check RUV's against the host in question, there are several. I
also queried the tombstones against the host and found two entries
which have valid hex time stamps; coincidentally, out of the 9
tombstone entries, 2 have nsds50ruv time stamps. I'll paste
sanitized output below:
# ldapsaerch -x -W -LLL -D cn=directory manager -b
dc=our,dc=personal,dc=domain '(objectclass=nsTombstone)'
Enter LDAP Password:
dn: nsuniqueid=---,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50ef13ae0004
nsds50ruv: {replica 4 ldap://master.our.personal.domain:389}
5164d1470004 5447bda 800010004
nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389}
54107f9f0016 54436b 250016
nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389}
51b734de0015 51b7 34ef00020015
nsds50ruv: {replica 19
ldap://host-in-question.our.personal.domain:389} 510d56c900010013
510d82 be00020013
nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 23
ldap://host-in-question.our.personal.domain:389} 5418770200020017
541878 9a0017
dc: our
nsruvReplicaLastModified: {replica 4
ldap://master.our.personal.domain:389} 5447bce8
nsruvReplicaLastModified: {replica 22
ldap://separatenode.our.personal.domain:389} 54436a5e
nsruvReplicaLastModified: {replica 21
ldap://iparepbackup.our.personal.domain:389}
nsruvReplicaLastModified: {replica 19
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 18
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 17
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 16
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 15
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 14
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 13
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 12
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 23
ldap://host-in-question.our.personal.domain:389}
dn:
nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn: host-in-question.our.personal.domain
nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0
dn:
nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn: host-in-question.our.personal.domain
nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0
As you can see, the host-in-question has many RUV's and of which two
appear to be active and two entries which I believe (pardon my
ignorance) possibly correlate with the active entries of the
host-in-question.
Do these two tombstone entries need to be deleted with ldapdelete
before we can re-provision host-in-question and add it back as a
replica?
Thank you,
John DeSantis
--
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] Attempting to re-provision previous replica
Richard,
You helped me before in #freeipa, so I appreciate the assistance again.
What version of 389 are you using?
rpm -q 389-ds-base
389-ds-base-1.2.11.15-34.el6_5
Thanks,
John DeSantis
2014-10-22 12:09 GMT-04:00 Rich Megginson rmegg...@redhat.com:
On 10/22/2014 09:42 AM, John Desantis wrote:
Hello all,
First and foremost, a big thank you! to the FreeIPA developers for a
great product!
Now, to the point!
We're trying to re-provision a previous replica using the standard
documentation via the Red Hat site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html
However, we're running into errors during the import process. The
errors are varied and fail at random steps; there was an issue with
NTP or HTTP or LDAP, etc. This did not happen when we promoted a
separate node to become a replica.
We had previously removed the replica via `ipa-replica-manage del` and
ensured that no trace of it being a replica existed: removed DNS
records and verified that the host enrollment was not present. I did
not use the --force and --cleanup options.
What version of 389 are you using?
rpm -q 389-ds-base
When I check RUV's against the host in question, there are several. I
also queried the tombstones against the host and found two entries
which have valid hex time stamps; coincidentally, out of the 9
tombstone entries, 2 have nsds50ruv time stamps. I'll paste
sanitized output below:
# ldapsaerch -x -W -LLL -D cn=directory manager -b
dc=our,dc=personal,dc=domain '(objectclass=nsTombstone)'
Enter LDAP Password:
dn:
nsuniqueid=---,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50ef13ae0004
nsds50ruv: {replica 4 ldap://master.our.personal.domain:389}
5164d1470004 5447bda 800010004
nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389}
54107f9f0016 54436b 250016
nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389}
51b734de0015 51b7 34ef00020015
nsds50ruv: {replica 19
ldap://host-in-question.our.personal.domain:389} 510d56c900010013
510d82 be00020013
nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 23
ldap://host-in-question.our.personal.domain:389} 5418770200020017
541878 9a0017
dc: our
nsruvReplicaLastModified: {replica 4
ldap://master.our.personal.domain:389} 5447bce8
nsruvReplicaLastModified: {replica 22
ldap://separatenode.our.personal.domain:389} 54436a5e
nsruvReplicaLastModified: {replica 21
ldap://iparepbackup.our.personal.domain:389}
nsruvReplicaLastModified: {replica 19
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 18
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 17
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 16
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 15
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 14
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 13
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 12
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 23
ldap://host-in-question.our.personal.domain:389}
dn:
nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn: host-in-question.our.personal.domain
nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0
dn:
nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn: host-in-question.our.personal.domain
nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0
As you can see, the host-in-question has many RUV's and of which two
appear to be active and two entries which I believe (pardon my
ignorance) possibly correlate with the active entries of the
host-in-question.
Do these two tombstone entries need to
Re: [Freeipa-users] Attempting to re-provision previous replica
On 10/22/2014 10:31 AM, John Desantis wrote:
Richard,
You helped me before in #freeipa, so I appreciate the assistance again.
What version of 389 are you using?
rpm -q 389-ds-base
389-ds-base-1.2.11.15-34.el6_5
Thanks,
John DeSantis
2014-10-22 12:09 GMT-04:00 Rich Megginson rmegg...@redhat.com:
On 10/22/2014 09:42 AM, John Desantis wrote:
Hello all,
First and foremost, a big thank you! to the FreeIPA developers for a
great product!
Now, to the point!
We're trying to re-provision a previous replica using the standard
documentation via the Red Hat site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html
However, we're running into errors during the import process. The
errors are varied and fail at random steps; there was an issue with
NTP or HTTP or LDAP, etc. This did not happen when we promoted a
separate node to become a replica.
We had previously removed the replica via `ipa-replica-manage del` and
ensured that no trace of it being a replica existed: removed DNS
records and verified that the host enrollment was not present. I did
not use the --force and --cleanup options.
What version of 389 are you using?
rpm -q 389-ds-base
You should remove the unused ruv elements. I'm not sure why they were
not cleaned. You may have to use cleanallruv manually.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv
note - use the cleanallruv procedure, not cleanruv.
When I check RUV's against the host in question, there are several. I
also queried the tombstones against the host and found two entries
which have valid hex time stamps; coincidentally, out of the 9
tombstone entries, 2 have nsds50ruv time stamps. I'll paste
sanitized output below:
# ldapsaerch -x -W -LLL -D cn=directory manager -b
dc=our,dc=personal,dc=domain '(objectclass=nsTombstone)'
Enter LDAP Password:
dn:
nsuniqueid=---,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50ef13ae0004
nsds50ruv: {replica 4 ldap://master.our.personal.domain:389}
5164d1470004 5447bda 800010004
nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389}
54107f9f0016 54436b 250016
nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389}
51b734de0015 51b7 34ef00020015
nsds50ruv: {replica 19
ldap://host-in-question.our.personal.domain:389} 510d56c900010013
510d82 be00020013
nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 12 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 23
ldap://host-in-question.our.personal.domain:389} 5418770200020017
541878 9a0017
dc: our
nsruvReplicaLastModified: {replica 4
ldap://master.our.personal.domain:389} 5447bce8
nsruvReplicaLastModified: {replica 22
ldap://separatenode.our.personal.domain:389} 54436a5e
nsruvReplicaLastModified: {replica 21
ldap://iparepbackup.our.personal.domain:389}
nsruvReplicaLastModified: {replica 19
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 18
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 17
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 16
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 15
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 14
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 13
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 12
ldap://host-in-question.our.personal.domain:389}
nsruvReplicaLastModified: {replica 23
ldap://host-in-question.our.personal.domain:389}
dn:
nsuniqueid=c08a2803-5b5a11e2-a527ce8b-8fa47d35,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn: host-in-question.our.personal.domain
nsParentUniqueId: e6fa9418-5b5711e2-a1a9825b-daf5b5b0
dn:
nsuniqueid=664c4383-6d6311e2-8db6e946-de27dd8d,cn=host-in-question.our.personal.domain,cn=maste
rs,cn=ipa,cn=etc,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsContainer
objectClass: nsTombstone
cn:
Re: [Freeipa-users] Attempting to re-provision previous replica
On 10/22/2014 12:55 PM, John Desantis wrote:
Richard,
You should remove the unused ruv elements. I'm not sure why they were not
cleaned. You may have to use cleanallruv manually.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv
note - use the cleanallruv procedure, not cleanruv.
I'll try that, thanks for the guidance.
What is the real problem you have? Did replication stop working? Are you
getting error messages?
I cannot get the host to be a replica. Each time I run
`ipa-replica-install
replica-info-host-in-question.our.personal.domain.gpg' it fails. I
had assumed it was due to the fact that the host was already a
replica, but had to be taken offline due to a hard disk failing. The
machine was re-provisioned after the new hard drive was installed.
Ok. I don't know if we have a documented procedure for that case. I
assumed that if you first ran ipa-replica-manage del, then
ipa-replica-prepare, then ipa-replica-install, that would take care of that.
When I enabled extra debugging during the installation process, the
initial error was that the dirsrv instance couldn't be started. I
checked into this and found that there were missing files in
/etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv
after copying some schema files from another replica. The install did
move forward but then failed with Apache and its IPA configuration.
I performed several uninstalls and re-installs, and at one point I got
error code 3 from ipa-replica-install, which is why I was thinking
that the old RUV's and tombstones were to blame.
It could be. I'm really not sure what the problem is at this point.
Thanks,
John DeSantis
2014-10-22 12:51 GMT-04:00 Rich Megginson rmegg...@redhat.com:
On 10/22/2014 10:31 AM, John Desantis wrote:
Richard,
You helped me before in #freeipa, so I appreciate the assistance again.
What version of 389 are you using?
rpm -q 389-ds-base
389-ds-base-1.2.11.15-34.el6_5
Thanks,
John DeSantis
2014-10-22 12:09 GMT-04:00 Rich Megginson rmegg...@redhat.com:
On 10/22/2014 09:42 AM, John Desantis wrote:
Hello all,
First and foremost, a big thank you! to the FreeIPA developers for a
great product!
Now, to the point!
We're trying to re-provision a previous replica using the standard
documentation via the Red Hat site:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html
However, we're running into errors during the import process. The
errors are varied and fail at random steps; there was an issue with
NTP or HTTP or LDAP, etc. This did not happen when we promoted a
separate node to become a replica.
We had previously removed the replica via `ipa-replica-manage del` and
ensured that no trace of it being a replica existed: removed DNS
records and verified that the host enrollment was not present. I did
not use the --force and --cleanup options.
What version of 389 are you using?
rpm -q 389-ds-base
You should remove the unused ruv elements. I'm not sure why they were not
cleaned. You may have to use cleanallruv manually.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv
note - use the cleanallruv procedure, not cleanruv.
When I check RUV's against the host in question, there are several. I
also queried the tombstones against the host and found two entries
which have valid hex time stamps; coincidentally, out of the 9
tombstone entries, 2 have nsds50ruv time stamps. I'll paste
sanitized output below:
# ldapsaerch -x -W -LLL -D cn=directory manager -b
dc=our,dc=personal,dc=domain '(objectclass=nsTombstone)'
Enter LDAP Password:
dn:
nsuniqueid=---,dc=our,dc=personal,dc=domain
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 50ef13ae0004
nsds50ruv: {replica 4 ldap://master.our.personal.domain:389}
5164d1470004 5447bda 800010004
nsds50ruv: {replica 22 ldap://separatenode.our.personal.domain:389}
54107f9f0016 54436b 250016
nsds50ruv: {replica 21 ldap://iparepbackup.our.personal.domain:389}
51b734de0015 51b7 34ef00020015
nsds50ruv: {replica 19
ldap://host-in-question.our.personal.domain:389} 510d56c900010013
510d82 be00020013
nsds50ruv: {replica 18 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 17 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 16 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 15 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 14 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 13 ldap://host-in-question.our.personal.domain:389}
nsds50ruv: {replica 12
Re: [Freeipa-users] Attempting to re-provision previous replica
Rob and Rich, ipa-replica-manage del should have cleaned things up. You can clear out old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. I remember having previously tried this task, but it had failed on older RUV's which were not even active (the KDC was under some strain so ipa queries were timing out). However, I ran it again and have been able to delete all but 1 (it's still running) RUV referencing the previous replica. I'll report back once the tasks finishes or fails. Thanks, John DeSantis 2014-10-22 15:49 GMT-04:00 Rob Crittenden rcrit...@redhat.com: Rich Megginson wrote: On 10/22/2014 12:55 PM, John Desantis wrote: Richard, You should remove the unused ruv elements. I'm not sure why they were not cleaned. You may have to use cleanallruv manually. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv note - use the cleanallruv procedure, not cleanruv. I'll try that, thanks for the guidance. What is the real problem you have? Did replication stop working? Are you getting error messages? I cannot get the host to be a replica. Each time I run `ipa-replica-install replica-info-host-in-question.our.personal.domain.gpg' it fails. I had assumed it was due to the fact that the host was already a replica, but had to be taken offline due to a hard disk failing. The machine was re-provisioned after the new hard drive was installed. Ok. I don't know if we have a documented procedure for that case. I assumed that if you first ran ipa-replica-manage del, then ipa-replica-prepare, then ipa-replica-install, that would take care of that. ipa-replica-manage del should have cleaned things up. You can clear out old RUVs with ipa-replica-manage too via list-ruv and clean-ruv. You use list-ruv to get the id# to clean and clean-ruv to do the actual cleaning. When I enabled extra debugging during the installation process, the initial error was that the dirsrv instance couldn't be started. I checked into this and found that there were missing files in /etc/dirsrv/slapd-BLAH directory. I was then able to start dirsrv after copying some schema files from another replica. The install did move forward but then failed with Apache and its IPA configuration. I performed several uninstalls and re-installs, and at one point I got error code 3 from ipa-replica-install, which is why I was thinking that the old RUV's and tombstones were to blame. It could be. I'm really not sure what the problem is at this point. I think we'd need to see ipareplica-install.log to know for sure. It could be the sort of thing where it fails early but doesn't kill the install, so the last error is a red herring. rob Thanks, John DeSantis 2014-10-22 12:51 GMT-04:00 Rich Megginson rmegg...@redhat.com: On 10/22/2014 10:31 AM, John Desantis wrote: Richard, You helped me before in #freeipa, so I appreciate the assistance again. What version of 389 are you using? rpm -q 389-ds-base 389-ds-base-1.2.11.15-34.el6_5 Thanks, John DeSantis 2014-10-22 12:09 GMT-04:00 Rich Megginson rmegg...@redhat.com: On 10/22/2014 09:42 AM, John Desantis wrote: Hello all, First and foremost, a big thank you! to the FreeIPA developers for a great product! Now, to the point! We're trying to re-provision a previous replica using the standard documentation via the Red Hat site: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Identity_Management_Guide/Setting_up_IPA_Replicas.html However, we're running into errors during the import process. The errors are varied and fail at random steps; there was an issue with NTP or HTTP or LDAP, etc. This did not happen when we promoted a separate node to become a replica. We had previously removed the replica via `ipa-replica-manage del` and ensured that no trace of it being a replica existed: removed DNS records and verified that the host enrollment was not present. I did not use the --force and --cleanup options. What version of 389 are you using? rpm -q 389-ds-base You should remove the unused ruv elements. I'm not sure why they were not cleaned. You may have to use cleanallruv manually. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html#cleanruv note - use the cleanallruv procedure, not cleanruv. When I check RUV's against the host in question, there are several. I also queried the tombstones against the host and found two entries which have valid hex time stamps; coincidentally, out of the 9 tombstone entries, 2 have nsds50ruv time stamps. I'll paste sanitized output below: # ldapsaerch -x -W -LLL -D cn=directory manager -b
[Freeipa-users] A crazy idea maybe, migration to Free-IPA 4.1.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello List, So the whole not being able to change the CA easily is becoming a regular point of contention in meetings. If I have read the e-mails on this list correctly this issue is fixed in 4.1. After spending a large amount of time thinking about this, I believe I have come to a solution that will appease management, my coworkers, and myself. Here is what I am thinking of doing. I am thinking I will install FC21 VM with free-IPA (which should be 4.1) then migrating my current install over there, followed by changing the CA to that of my contracted CA and third party issuer. The questions that come to mind are: 1) how does one migrate the information over to a new install, in this case 3.3 to 4.1 on separate servers? 2) is there any documentation on the process of changing the CA in 4.1? 3) am I insane for wanting to introduce FC21 into my environment? 4) has anyone done this, and what was your experience with doing so? Thanks, Bill -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUSA5LAAoJEJFMz73A1+zrVu4P/3rcjvj5Vlcf3M1mAFLIyRWS NMf5Qu+gRK9wR4MQkp3QJ46NC88TwZmwtYy6z31tMqwbRKzLR4/IUOGq89K/mjIl CuzGc5S0dW5ctfJPv+5E+shfytYtHeUsTSmMTFwazEGKq8bMEo0Lr7prZera2t8t NPeYSpECwPMU46g8ufS2oPSOQACmkIhAPfKAr5BATpM1g5JAJJ89oidd9ob7tu7n UKcTjqtEhXxbLVXi0+H65O9sZzgpDTk1Gfl52DOii/XVEgBsL8ybmk5902zAJsOg W2eamMVivFJD8SVas97DvRar0GMRNXilNZS6Q316N9mjOoVJJHONUb/VZ0t10BLc FRbc6hMRQJ3TQCdp37DYcaTblVnRanQJ9HBbih4hcErWG42mWEPzaQJljDO/If5f DfzTGai3Fd+1TIhOsX81XKH/8NCK+qpoaEJlsOJd2iScxv8f9AqMGKv1TAhZiJGY WXXma39WdoLy/p1DMDM6kg+gAnmxBxGU+5RxjXl+HkOkvK8nn3nUJa3GHD3a4Iep L6FLiRjZ8UuJbKsXPPIpKAioil8Lt1JbcFykCKFuEM6wQ5ehpOPRMYeZEqedvXPD Is3yEqtyXX+B/wEcCljL4kD9Wmntfkfh59ondcnlHZTkiQM/Fs6eY0FqEKIvcgj1 jbyjtbGUn5KRsXdGjBde =WagT -END PGP SIGNATURE- -- 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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On Thu, Oct 23, 2014 at 11:20 AM, Fraser Tweedale ftwee...@redhat.com
wrote:
On Wed, Oct 22, 2014 at 03:23:56PM +0200, Lukas Slebodnik wrote:
On (22/10/14 17:10), Fraser Tweedale wrote:
Further to my earlier email, I have written a blog post about all
these matters, with a particular focus on the custom package repo.
I will update it tomorrow with a bit more about the package
flavours topic. For now, all the details for enabling and using
the custom repo are in the post. Check it out and let me know if
you spot any issues.
http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/
The disadvantage of this approach is that users need to rely on updating
of non standard repo. https://frase.id.au/pkg/${ABI}_FreeIPA
In my opinion, it's better to write howto (script) which will configure
all
necessary ports/files and portmaster will take care of updating ports.
https://www.freebsd.org/doc/handbook/ports-using.html#portmaster
LS
Each has its advantages and disadvantages; people can choose what
works for them. Hopefully - not too far in the future - people
won't have to choose, when binary package flavours are
implemented. When that happens, a small effort will be needed to
define the FreeIPA flavour and ensure it gets included in the
official package repos.
Actually I would be inclined to assist with a ports build, so it could be
done correctly from the ports tree
and work towards having it adopted into mainline.
Fraser
--
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
--
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] No result when trying to integrate a FreeBSD client with the FreeIPA server
On Wed, Oct 22, 2014 at 01:26:42PM +0200, Petr Spacek wrote: On 22.10.2014 09:10, Fraser Tweedale wrote: Further to my earlier email, I have written a blog post about all these matters, with a particular focus on the custom package repo. I will update it tomorrow with a bit more about the package flavours topic. For now, all the details for enabling and using the custom repo are in the post. Check it out and let me know if you spot any issues. http://blog-ftweedal.rhcloud.com/2014/10/configuring-freebsd-as-a-freeipa-client/ Hello Fraser and others, it would be great if you could add links to your FreeIPA-related blog posts to http://www.freeipa.org/page/HowTos . I updated the HowTos page. Cheers, Fraser. We are trying to build kind of 'documentation hub' with links to relevant posts stored elsewhere. It is even fine to add links to mailing list archives if the particular post is useful to broad audience. Have a nice day! Petr^2 Spacek Cheers, Fraser On Wed, Oct 22, 2014 at 09:13:11AM +0500, Orkhan Gasimov wrote: Great news! If I understand correctly, a package can be equivalent to several ports? If this is correct, then could a composite package be built to include all necessary ports? * _security/sssd_ http://www.freshports.org/security/sssd * _security/sudo_ http://www.freshports.org/security/sudo(with SSSD backend) * _net/openldap24-client-sasl_ http://www.freshports.org/net/openldap24-client-sasl * security/cyrus-sasl2 * security/cyrus-sasl2-gssapi That package could be called something like ipa-client, and make FreeBSD - FreeIPA integration one step closer. If not possible, even a pkg equivalent to /security/sssd would eliminate existing possibilities for misconfiguration. 22-Oct-14 07:06, Fraser Tweedale пишет: I have prepared a custom pkg(8) repo with the packages built with the required options/make.conf variables. Hang tight, I'll send all the info soon. -- 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 -- 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
