[Freeipa-users] Antwort: Re: Re: client without certmonger/dbus
centos 6.2 inside vserver, but I dont know what OS is the host system. (leased at heckrath.com)MfGChristoph KaminskiHealth Services Network AdministrationPhone: +49 (0) 30 68905-4645Fax: +49 (0) 30 68905-2940Mail: christoph.kamin...@biotronik.de-Stephen Ingram sbing...@gmail.com schrieb: -An: Christoph Kaminski christoph.kamin...@biotronik.comVon: Stephen Ingram sbing...@gmail.comDatum: 18.04.2012 07:33Kopie: freeipa-users@redhat.comBetreff: Re: Re: [Freeipa-users] client without certmonger/dbusOn Tue, Apr 17, 2012 at 10:28 PM, Christoph Kaminskichristoph.kamin...@biotronik.com wrote: done it without success :( [root@xaphon ~]# dbus-daemon --system --nofork Failed to start message bus: Failed to drop capabilities: Operation not permittedWhat OS and version are you using? I was using Fedora 15 template from OpenVZ.Stevewww.biotronik.comBIOTRONIK SE Co. KGWoermannkehre 1, 12359 Berlin, GermanySitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501Vertreten durch ihre Komplementärin:BIOTRONIK MT SESitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 BGeschäftsführende Direktoren: Christoph Böhmer, Dr. Werner Braun, Dr. Lothar Krings, Dr. Torsten WolfBIOTRONIK - A global manufacturer of advanced Cardiac Rhythm Management systems and Vascular Intervention devices. Quality, innovation, and reliability define BIOTRONIK and our growing success. We are innovators of technologies like the first wireless remote monitoring system - Home Monitoring®, Closed Loop Stimulation and coveted lead solutions as well as state-of-the-art stents, balloons and guide wires for coronary and peripheral indications. We highly invest in the development of drug eluting devices and are leading the industry with our drug eluting absorbable metal scaffold program.This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] client without certmonger/dbus
On Tue, Apr 17, 2012 at 11:07 PM, Christoph Kaminski christoph.kamin...@biotronik.com wrote: centos 6.2 inside vserver, but I dont know what OS is the host system. (leased at heckrath.com) You can do a cat /proc/version inside your container to see what version of the kernel they are using. I'm guessing it is pretty old since that problem was solved some time ago as it caused problems with the operation of the container. If it is really old, you might want to see if they can migrate your container to a newer host node with an updated kernel. I haven't tried this on Redhat or CentOS using OpenVZ as I switched to KVM to take advantage of SELinux. Fedora 15 worked great on the 2.6.18-238.9.1.el5.028stab089.1 kernel. I also looked at your provider's Website and saw that the largest container they offer is 512MB. I'll be very surprised if you can get FreeIPA to install inside a container with only 512MB. I had to use around 2GB just to get it to install. Once complete, then I was able to lower the memory to around 1GB. For some reason the install requires an enormous amount of RAM. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Antwort: Re: Re: Re: client without certmonger/dbus
[root@xaphon ~]# cat /proc/version Linux version 2.6.26-2-openvz-amd64 (Debian 2.6.26-26lenny1) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 25 05:14:47 UTC 2010 I have 2GB RAM on my vhost (512MB is only initialy, you can buy additional ram later) But I want to install the client, not ipa server. - MfG Christoph Kaminski Von: Stephen Ingram sbing...@gmail.com An: Christoph Kaminski christoph.kamin...@biotronik.com Kopie: freeipa-users@redhat.com Datum: 18.04.2012 08:34 Betreff: Re: Re: Re: [Freeipa-users] client without certmonger/dbus On Tue, Apr 17, 2012 at 11:07 PM, Christoph Kaminski christoph.kamin...@biotronik.com wrote: centos 6.2 inside vserver, but I dont know what OS is the host system. (leased at heckrath.com) You can do a cat /proc/version inside your container to see what version of the kernel they are using. I'm guessing it is pretty old since that problem was solved some time ago as it caused problems with the operation of the container. If it is really old, you might want to see if they can migrate your container to a newer host node with an updated kernel. I haven't tried this on Redhat or CentOS using OpenVZ as I switched to KVM to take advantage of SELinux. Fedora 15 worked great on the 2.6.18-238.9.1.el5.028stab089.1 kernel. I also looked at your provider's Website and saw that the largest container they offer is 512MB. I'll be very surprised if you can get FreeIPA to install inside a container with only 512MB. I had to use around 2GB just to get it to install. Once complete, then I was able to lower the memory to around 1GB. For some reason the install requires an enormous amount of RAM. Steve www.biotronik.com BIOTRONIK SE Co. KG Woermannkehre 1, 12359 Berlin, Germany Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRA 6501 Vertreten durch ihre Komplementärin: BIOTRONIK MT SE Sitz der Gesellschaft: Berlin, Registergericht: Berlin HRB 118866 B Geschäftsführende Direktoren: Christoph Böhmer, Dr. Werner Braun, Dr. Lothar Krings, Dr. Torsten Wolf BIOTRONIK - A global manufacturer of advanced Cardiac Rhythm Management systems and Vascular Intervention devices. Quality, innovation, and reliability define BIOTRONIK and our growing success. We are innovators of technologies like the first wireless remote monitoring system - Home Monitoring®, Closed Loop Stimulation and coveted lead solutions as well as state-of-the-art stents, balloons and guide wires for coronary and peripheral indications. We highly invest in the development of drug eluting devices and are leading the industry with our drug eluting absorbable metal scaffold program. This e-mail and the information it contains including attachments are confidential and meant only for use by the intended recipient(s); disclosure or copying is strictly prohibited. If you are not addressed, but in the possession of this e-mail, please notify the sender immediately and delete the document. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Tue, Apr 17, 2012 at 15:32, Rich Megginson rmegg...@redhat.com wrote:
On 04/17/2012 09:59 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 10:29, Richard Megginsonrmegg...@redhat.com
wrote:
- Original Message -
On Tue, Apr 17, 2012 at 09:26, Rich Megginsonrmegg...@redhat.com
wrote:
On 04/17/2012 07:26 AM, Dan Scott wrote:
On Fri, Apr 13, 2012 at 17:44, Rich Megginsonrmegg...@redhat.com
wrote:
On 04/13/2012 03:40 PM, Dan Scott wrote:
I cleaned up all the ruv_compare_ruv: RUV [changelog max RUV]
does
not contain element errors in the logs for each of fileservers
1, 2
and 3. The ldapsearch for
'((nsuniqueid=---)(objectclass=nstombstone))'
is still showing entries though. Is that OK?
The entry should exist, but the deleted servers should not be
present in
the
nsds50ruv attribute.
OK, so it's safe to delete replica entries which have
ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a
replica) but not for the other servers?
Yes. Following the CLEANRUV procedure:
http://port389.org/wiki/Howto:CLEANRUV
Thanks. I think I'm getting there - removed the tombstones from the
main directory and the PKI-IPA directory (only one server so far
though). I still have a few strange entries though:
[root@fileserver1 ~]# ldapsearch -xLLL -D cn=directory manager -W
-b
dc=ecg,dc=mit,dc=edu
'((nsuniqueid=---)(objectclass=nstombstone))'
Enter LDAP Password:
dn:
nsuniqueid=---,dc=ecg,dc=mit,dc=edu
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e7b746e0004
nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389}
4f50e685001d0006
4f8d787400020006
nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389}
4f88cf450001002b000
0 4f8d7814002b
nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389}
4f5047ad001d0005
4f8d77c30005
nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389}
nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389}
nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389}
4f7363d2001d0008
4f73640200070008
dc: ecg
nsruvReplicaLastModified: {replica 6
ldap://fileserver1.ecg.mit.edu:389} 4f8d7
806
nsruvReplicaLastModified: {replica 43
ldap://fileserver2.ecg.mit.edu:389} 4f8d
77a6
nsruvReplicaLastModified: {replica 5
ldap://fileserver3.ecg.mit.edu:389} 4f8d7
756
nsruvReplicaLastModified: {replica 4
ldap://fileserver3.ecg.mit.edu:389} 0
000
nsruvReplicaLastModified: {replica 9
ldap://fileserver3.ecg.mit.edu:389} 0
000
nsruvReplicaLastModified: {replica 8
ldap://fileserver3.ecg.mit.edu:389} 0
000
Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with
2
entries for fileserver3. How do I know which one to delete?
Whichever one is the one currently in use.
ldapsearch -xLLL -h fileserver3 -D cn=directory manager -W -b cn=config
cn=replica
What is the replica ID? That is the one that is currently in use. You
should be able to safely delete the others.
Excellent thanks.
Nearly there now.
I think my only remaining problems are:
1. The fileserver5.ecg.mit.edu entry (dn:
cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu)
which I cannot delete due to: [LDAP: error code 66 - Not Allowed On
Non-leaf]
It won't let you delete the tombstones? Or it is not showing any
tombstones?
If this is due to orphan tombstone entries, the only resolution will be to
db2ldif, then ldif2db.
It's not showing any tombstones. Is there any documentation for
db2ldif, then ldif2db? I guess it's the scripts in
/var/lib/dirsrv/scripts-ECG-MIT-EDU/. But I'm not sure if there are
any options I should be using?
2. One inconsistency in my replication agreements:
ipa-csreplica-manage -v list fileserver1.ecg.mit.edu shows only
fileserver2.
ipa-csreplica-manage -v list fileserver3.ecg.mit.edu shows both
fileservers 1 and 2.
So, fileserver3 thinks that it's replicating fine with fileserver1,
but fileserver1 is not replicating with fileserver3.
Any ideas?
Not sure. You can look at the replication agreements directly using
ldapsearch:
ldapsearch -xLLL -D cn=directory manager -W -b cn=config
objectclass=nsds5replicationagreement
The agreements agree with the output of ipa-replica-manage list i.e.
There's an entry on fileserver3 pointing to fileserver1:
dn:
cn=masterAgreement1-fileserver1.ecg.mit.edu-pki-ca,cn=replica,cn=o\3Dipaca,cn=mapping
tree,cn=config
but no equivalent entry on fileserver1. Is there an easy way to fix this?
I think I have also found yet another problem. On fileserver2, the output of:
ldapsearch -xLLL -D cn=directory manager -W -b cn=config
objectclass=nsds5replicationagreement
Shows lots of entries for missing replicas:
nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 0
000
[Freeipa-users] Replica promotion and CA serial testing
Hi, What's the best way to verify _everything will be OK_ after completing the steps in section 16.8 of the Guide? Also, why is it necessary to add the master.ca.* entries when they did not exist in the previous master? The Guide is a little unclear on that. -- - *question everything*learn something*answer nothing* Lucas Yamanishi -- Systems Administrator, ADNET Systems, Inc. 7515 Mission Drive, Suite A100 Lanham, MD 20706 * 301-352-4646 * 0xE23F3D7A signature.asc Description: OpenPGP digital signature ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] client without certmonger/dbus
On Tue, 2012-04-17 at 23:33 -0700, Stephen Ingram wrote: On Tue, Apr 17, 2012 at 11:07 PM, Christoph Kaminski christoph.kamin...@biotronik.com wrote: centos 6.2 inside vserver, but I dont know what OS is the host system. (leased at heckrath.com) You can do a cat /proc/version inside your container to see what version of the kernel they are using. I'm guessing it is pretty old since that problem was solved some time ago as it caused problems with the operation of the container. If it is really old, you might want to see if they can migrate your container to a newer host node with an updated kernel. I haven't tried this on Redhat or CentOS using OpenVZ as I switched to KVM to take advantage of SELinux. Fedora 15 worked great on the 2.6.18-238.9.1.el5.028stab089.1 kernel. I also looked at your provider's Website and saw that the largest container they offer is 512MB. I'll be very surprised if you can get FreeIPA to install inside a container with only 512MB. I had to use around 2GB just to get it to install. Once complete, then I was able to lower the memory to around 1GB. For some reason the install requires an enormous amount of RAM. FWIW I regularly install FreeIPA in a VM with 768MB of ram allocated (and some swap) and it is just fine for an install. Granted there isn't much RAM left once FreeIPa is up and running (esp with the PKI). For production I would recommend to stay around a few G of RAM, as DS will use all the RAM it can for caches, and you also need to run tomcat/java for the CA, which is another process that demands a bit of RAM. Also using a few CPUs is not a bad idea at all. While FreeIPA will work fine with one or 2 CPUs, having more will mean the system will be more responsive when many clients hit it using a mix of protocols (LDAP, KRB, DNS). Simo. -- Simo Sorce * Red Hat, Inc * New York ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Replica promotion and CA serial testing
Lucas Yamanishi wrote: Hi, What's the best way to verify _everything will be OK_ after completing the steps in section 16.8 of the Guide? Also, why is it necessary to add the master.ca.* entries when they did not exist in the previous master? The Guide is a little unclear on that. I'm assuming you're using a dogtag CA? For dogtag only one of the masters generates the CRL. All these modifications do is change the server on which the CRL is generated. To test this you'd just want to add the entries to one, remove from the previous master and restart both. Then watch the promoted master's debug log to ensure that it is regenerating the CRL on schedule. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] client without certmonger/dbus
On Wed, Apr 18, 2012 at 12:06 AM, Christoph Kaminski christoph.kamin...@biotronik.com wrote: [root@xaphon ~]# cat /proc/version Linux version 2.6.26-2-openvz-amd64 (Debian 2.6.26-26lenny1) ( da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 25 05:14:47 UTC 2010 I have 2GB RAM on my vhost (512MB is only initialy, you can buy additional ram later) But I want to install the client, not ipa server. I'm sorry, I thought we were talking about the server here. That's a recent OpenVZ kernel so there shouldn't be any issues there. 2GB of RAM is more than enough for the client. I'm going to setup a container with CentOS 6.2 and see if I can replicate what you are talking about. I'll report back. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] client without certmonger/dbus
On Wed, Apr 18, 2012 at 9:09 AM, Stephen Ingram sbing...@gmail.com wrote: On Wed, Apr 18, 2012 at 12:06 AM, Christoph Kaminski christoph.kamin...@biotronik.com wrote: [root@xaphon ~]# cat /proc/version Linux version 2.6.26-2-openvz-amd64 (Debian 2.6.26-26lenny1) (da...@debian.org) (gcc version 4.1.3 20080704 (prerelease) (Debian 4.1.2-25)) #1 SMP Thu Nov 25 05:14:47 UTC 2010 I have 2GB RAM on my vhost (512MB is only initialy, you can buy additional ram later) But I want to install the client, not ipa server. I'm sorry, I thought we were talking about the server here. That's a recent OpenVZ kernel so there shouldn't be any issues there. 2GB of RAM is more than enough for the client. I'm going to setup a container with CentOS 6.2 and see if I can replicate what you are talking about. I'll report back. I just installed and successfully started dbus on a CentOS 6.2 container. I would ask your provider why you can't run dbus on the container (that bug was fixed over 2 years ago), and, perhaps try another image. Of course, you can always forgo certmonger and manually integrate your system into an IPA realm. You would lose the certificate auto-renew, but everything else should work great. Steve ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On 04/18/2012 07:22 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 15:32, Rich Megginsonrmegg...@redhat.com wrote:
On 04/17/2012 09:59 AM, Dan Scott wrote:
On Tue, Apr 17, 2012 at 10:29, Richard Megginsonrmegg...@redhat.com
wrote:
- Original Message -
On Tue, Apr 17, 2012 at 09:26, Rich Megginsonrmegg...@redhat.com
wrote:
On 04/17/2012 07:26 AM, Dan Scott wrote:
On Fri, Apr 13, 2012 at 17:44, Rich Megginsonrmegg...@redhat.com
wrote:
On 04/13/2012 03:40 PM, Dan Scott wrote:
I cleaned up all the ruv_compare_ruv: RUV [changelog max RUV]
does
not contain element errors in the logs for each of fileservers
1, 2
and 3. The ldapsearch for
'((nsuniqueid=---)(objectclass=nstombstone))'
is still showing entries though. Is that OK?
The entry should exist, but the deleted servers should not be
present in
the
nsds50ruv attribute.
OK, so it's safe to delete replica entries which have
ldap://fileserver4.ecg.mit.edu:389 (fileserver4 is not currently a
replica) but not for the other servers?
Yes. Following the CLEANRUV procedure:
http://port389.org/wiki/Howto:CLEANRUV
Thanks. I think I'm getting there - removed the tombstones from the
main directory and the PKI-IPA directory (only one server so far
though). I still have a few strange entries though:
[root@fileserver1 ~]# ldapsearch -xLLL -D cn=directory manager -W
-b
dc=ecg,dc=mit,dc=edu
'((nsuniqueid=---)(objectclass=nstombstone))'
Enter LDAP Password:
dn:
nsuniqueid=---,dc=ecg,dc=mit,dc=edu
objectClass: top
objectClass: nsTombstone
objectClass: extensibleobject
nsds50ruv: {replicageneration} 4e7b746e0004
nsds50ruv: {replica 6 ldap://fileserver1.ecg.mit.edu:389}
4f50e685001d0006
4f8d787400020006
nsds50ruv: {replica 43 ldap://fileserver2.ecg.mit.edu:389}
4f88cf450001002b000
0 4f8d7814002b
nsds50ruv: {replica 5 ldap://fileserver3.ecg.mit.edu:389}
4f5047ad001d0005
4f8d77c30005
nsds50ruv: {replica 4 ldap://fileserver3.ecg.mit.edu:389}
nsds50ruv: {replica 9 ldap://fileserver3.ecg.mit.edu:389}
nsds50ruv: {replica 8 ldap://fileserver3.ecg.mit.edu:389}
4f7363d2001d0008
4f73640200070008
dc: ecg
nsruvReplicaLastModified: {replica 6
ldap://fileserver1.ecg.mit.edu:389} 4f8d7
806
nsruvReplicaLastModified: {replica 43
ldap://fileserver2.ecg.mit.edu:389} 4f8d
77a6
nsruvReplicaLastModified: {replica 5
ldap://fileserver3.ecg.mit.edu:389} 4f8d7
756
nsruvReplicaLastModified: {replica 4
ldap://fileserver3.ecg.mit.edu:389} 0
000
nsruvReplicaLastModified: {replica 9
ldap://fileserver3.ecg.mit.edu:389} 0
000
nsruvReplicaLastModified: {replica 8
ldap://fileserver3.ecg.mit.edu:389} 0
000
Is it safe to run CLEANRUV on IDs 4 and 9? That still leaves me with
2
entries for fileserver3. How do I know which one to delete?
Whichever one is the one currently in use.
ldapsearch -xLLL -h fileserver3 -D cn=directory manager -W -b cn=config
cn=replica
What is the replica ID? That is the one that is currently in use. You
should be able to safely delete the others.
Excellent thanks.
Nearly there now.
I think my only remaining problems are:
1. The fileserver5.ecg.mit.edu entry (dn:
cn=fileserver5.ecg.mit.edu,cn=masters,cn=ipa,cn=etc,dc=ecg,dc=mit,dc=edu)
which I cannot delete due to: [LDAP: error code 66 - Not Allowed On
Non-leaf]
It won't let you delete the tombstones? Or it is not showing any
tombstones?
If this is due to orphan tombstone entries, the only resolution will be to
db2ldif, then ldif2db.
It's not showing any tombstones. Is there any documentation for
db2ldif, then ldif2db? I guess it's the scripts in
/var/lib/dirsrv/scripts-ECG-MIT-EDU/. But I'm not sure if there are
any options I should be using?
2. One inconsistency in my replication agreements:
ipa-csreplica-manage -v list fileserver1.ecg.mit.edu shows only
fileserver2.
ipa-csreplica-manage -v list fileserver3.ecg.mit.edu shows both
fileservers 1 and 2.
So, fileserver3 thinks that it's replicating fine with fileserver1,
but fileserver1 is not replicating with fileserver3.
Any ideas?
Not sure. You can look at the replication agreements directly using
ldapsearch:
ldapsearch -xLLL -D cn=directory manager -W -b cn=config
objectclass=nsds5replicationagreement
The agreements agree with the output of ipa-replica-manage list i.e.
There's an entry on fileserver3 pointing to fileserver1:
dn:
cn=masterAgreement1-fileserver1.ecg.mit.edu-pki-ca,cn=replica,cn=o\3Dipaca,cn=mapping
tree,cn=config
but no equivalent entry on fileserver1. Is there an easy way to fix this?
Add it using the ipa-csreplica-manage or ipa-replica-manage tool?
I think I have also found yet another problem. On fileserver2, the output of:
ldapsearch -xLLL -D cn=directory manager -W -b cn=config
objectclass=nsds5replicationagreement
Shows lots of entries for missing replicas:
nsruvReplicaLastModified: {replica 5 ldap://fileserver3.ecg.mit.edu:389} 0
