Re: [Freeipa-users] client without certmonger/dbus

[Stephen Ingram]

On Tue, Apr 17, 2012 at 11:07 PM, Christoph Kaminski
 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: client without certmonger/dbus

[Christoph Kaminski]

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  schrieb: -An: Christoph Kaminski Von: Stephen Ingram Datum: 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 Kaminski 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

[Freeipa-users] Antwort: Re: client without certmonger/dbus

[Christoph Kaminski]

done it without success :(

[root@xaphon ~]# dbus-daemon --system --nofork
Failed to start message bus: Failed to drop capabilities: Operation not permittedMfGChristoph Kaminski-Stephen Ingram  schrieb: -An: Christoph Kaminski Von: Stephen Ingram Datum: 18.04.2012 00:07Kopie: freeipa-users@redhat.comBetreff: Re: [Freeipa-users] client without certmonger/dbusOn Mon, Apr 16, 2012 at 11:09 PM, Christoph Kaminski wrote:> hi>> It is possible to use the ipa-client without certmonger/dbus? Have an openvz> environemnt where I cant start dbus...Christoph-You can install IPA in OpenVZ container. I was able to install afterdoing the following:1. mkdir -m 1777 /dev/shm2. add this line to fstab: tmp    /dev/shm      tmpfs     defaults       0 03. mkdir /var/run/dbus4. service messagebus startAlso, make sure you give yourself lots of memory to install IPA. Onceit's installed you can reduce back down depending on the size of yourdirectory.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

[Stephen Ingram]

On Tue, Apr 17, 2012 at 10:28 PM, Christoph Kaminski
 wrote:
> done it without success :(
>
> [root@xaphon ~]# dbus-daemon --system --nofork
> Failed to start message bus: Failed to drop capabilities: Operation not
> permitted

What OS and version are you using? I was using Fedora 15 template from OpenVZ.

Steve

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] client without certmonger/dbus

[Stephen Ingram]

On Mon, Apr 16, 2012 at 11:09 PM, Christoph Kaminski
 wrote:
> hi
>
> It is possible to use the ipa-client without certmonger/dbus? Have an openvz
> environemnt where I cant start dbus...

Christoph-

You can install IPA in OpenVZ container. I was able to install after
doing the following:

1. mkdir -m 1777 /dev/shm
2. add this line to fstab: tmp/dev/shm  tmpfs defaults   0 0
3. mkdir /var/run/dbus
4. service messagebus start

Also, make sure you give yourself lots of memory to install IPA. Once
it's installed you can reduce back down depending on the size of your
directory.

Steve

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] client without certmonger/dbus

[Rob Crittenden]

Christoph Kaminski wrote:

hi

It is possible to use the ipa-client without certmonger/dbus? Have an
openvz environemnt where I cant start dbus...



Is it not working for you at all? lack of certmonger should not cause a 
fatal installation problem, just a slew of scary error messages.


There is no option to not configure certmonger.

rob

___
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?

[Rich Megginson]

On 04/17/2012 09:59 AM, Dan Scott wrote:

On Tue, Apr 17, 2012 at 10:29, Richard Megginson  wrote:

- Original Message -

On Tue, Apr 17, 2012 at 09:26, Rich Megginson
wrote:

On 04/17/2012 07:26 AM, Dan Scott wrote:

On Fri, Apr 13, 2012 at 17:44, Rich Megginson
  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.



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




Thanks for all your help. It's looking good now.

Dan


___
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?

[Dan Scott]

On Tue, Apr 17, 2012 at 10:29, Richard Megginson  wrote:
> - Original Message -
>> On Tue, Apr 17, 2012 at 09:26, Rich Megginson 
>> wrote:
>> > On 04/17/2012 07:26 AM, Dan Scott wrote:
>> >>
>> >> On Fri, Apr 13, 2012 at 17:44, Rich Megginson
>> >>  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]
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?

Thanks for all your help. It's looking good now.

Dan

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] DNS zone delegation

[Petr Spacek]

On 02/02/2012 10:23 AM, Adam Tkac wrote:

On 02/01/2012 07:21 PM, Loris Santamaria wrote:

Hi,

I have a dns zone managed by IPA and I'm trying to delegate a zone
managed by Active Directory.

The IPA managed zone is called "corpfbk", and the AD one is
"ad.corpfbk".

I started by adding the proper glue records:

ipa dnsrecord-add corpfbk ns1.ad --a-rec=192.168.3.36
ipa dnsrecord-add corpfbk ns2.ad --a-rec=192.168.3.241

Then I add what I consider should be the zone delegation:

ipa dnsrecord-add corpfbk ad --ns-rec=ns1.ad.corpfbk.,ns2.ad.corpfbk.

Problem is, IPA DNS can't resolve any host in the ad.corpfbk zone,
except ns1 and ns2. Recursion is enabled in named.conf. Dig results:

dig @localhost ad.corpfbk NS +norecurse
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21862
;; flags: qr aa ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 4

;; QUESTION SECTION:
;ad.corpfbk. IN NS

;; ANSWER SECTION:
ad.corpfbk. 86400 IN NS ns1.ad.corpfbk.
ad.corpfbk. 86400 IN NS ns2.ad.corpfbk.

;; AUTHORITY SECTION:
corpfbk. 86400 IN NS ipa01.central.corpfbk.
corpfbk. 86400 IN NS ipa02.central.corpfbk.

;; ADDITIONAL SECTION:
ns1.ad.corpfbk. 86400 IN A 192.168.3.36
ns2.ad.corpfbk. 86400 IN A 192.168.3.241
ipa01.central.corpfbk. 86400 IN A 192.168.3.6
ipa02.central.corpfbk. 86400 IN A 192.168.3.16

It seems to me, and after testing with other non-IPA based DNS servers,
that the response shouldn't have and "Answer section", but it should
have an "authority section" pointing to ad.corpfbk.

I am doing something wrong? Should I file a bug?


You are right, ad.corpfbk. records should be in auth section. This seems
like a bug in the bind-dyndb-ldap plugin. Please fill it with reference
to this thread to bugzilla.redhat.com. Thank you in advance!

Regards, Adam


These problems are fixed in latest bind-dyndb-ldap upstream version 
(commit 9bcd08be60aad4cb55393d494887b97bd31526be).


Petr^2 Spacek

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] Screensaver unlock with expired password

[Sigbjorn Lie]

On Mon, April 16, 2012 23:43, Nalin Dahyabhai wrote:
> On Mon, Apr 16, 2012 at 11:17:35PM +0200, Sigbjorn Lie wrote:
>
>> The clients use nss_ldap+pam_krb5, SSSD was crashing for us on RHEL 5.
>>
>>
>> The server is the IPA server provided in RHEL 6.2.
>>
>>
>> When I check the logs on the client it states that authentication
>> succeeded, and that the password has expired.  And that's where the 
>> screensaver fails. It show an
>> info message that the password has expired, and then an error message 
>> advising that "The
>> password subsystem has failed..."
>>
>>> Best would be if you provide a clear reproduction steps and file a
>>> ticket attaching logs and configuration to it. If it is a bug in SSSD we 
>>> would need to fix it
>>> ASAP though we have not
>>> seen this behavior in SSSD ever.
>>
>> This is not SSSD, I believe it either comes down to lack of support
>> in the KDE screensaver or a requirement for change in the PAM configuration. 
>> The current PAM
>> configuration is set by the system-config-auth script with the" 
>> --enable-ldap --enable-krb5"
>> options.
>>
>> I was hoping for a change in the PAM configuration and that someone
>> had an example that works to advise me about.
>
> Short version: try turning on the "chpw_prompt" option for pam_krb5, by
> setting something like this in /etc/krb5.conf:
>
> [appdefaults]
> pam = { chpw_prompt = kscreensaver gnome-screensaver }
>
>
> Long version: as you've noticed, some applications don't quite do what
> PAM expects of them when the user's password has expired.  When the user
> needs to set a new password, PAM is supposed to succeed in the authentication 
> phase, and then
> return an specific status, indicating that a password change is needed, in 
> the account management
> phase.
>
> Based on that second result, the application can either start a password
> change through PAM (and then allow access only if that change operation 
> succeeds), or reject the
> user if it can't handle a password change (think of FTP servers, where the 
> protocol keeps a server
> from being able to ask for a new password).  Some applications don't know to 
> do either, so the
> password-expired status is treated as a fatal error, and that appears to be 
> what's going on here.
>
> Turning on the "chpw_prompt" option causes pam_krb5 to let libkrb5
> attempt to change the password, during authentication, if a password change 
> is needed.  Depending
> on the application, that might be enough to fix things.  It depends on the 
> application to not just
> reply with the same password without relaying the question to the user, and 
> you don't get the
> chance to add any client-side password quality checking via PAM, but it might 
> work if the
> application can handle multiple prompts correctly.
>
> If that change allows users to log in (or unlock their screens, in this
> case), then you've found a bug in the PAM-enabled application, which is 
> unfortunately not unheard
> of.  The need to provide this option was first reported [1] after we fixed 
> pam_krb5 to do the
> right thing [2].
>
> HTH,
>
>
> Nalin
>
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=509092
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=402721
>


Hi Nalin,

Thank you for your reply.

I have testing this and it works with GNOME! It did not work with KDE, I was 
still advised that
the password had expired, but then there we're not further messages, and I was 
returned to the
unlock prompt.

Unfortunately we are running KDE in our client production environment.

Do you have any other suggestions I could try?

Thanks.


Regards,
Siggi


___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Re: [Freeipa-users] client without certmonger/dbus

[Dmitri Pal]

On 04/17/2012 02:09 AM, Christoph Kaminski wrote:
> hi
>
> It is possible to use the ipa-client without certmonger/dbus? Have an
> openvz environemnt where I cant start dbus...

A quick review of openvz indicates that it supports dbus, so why this is
an issue?
If you feel this is still necessary please file an RFE with your
justification.

>
> -
> MfG
> Christoph Kaminski
>
>
> _
> __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


-- 
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] Fwd: Problem creating replica file

[Jorge Argibay Molina]

Dmitri,

I'm attaching the result of rpm -qa | sort

I tried to follow the installation instructions to the letter, as it was my 
first installation. As I didn't have an existing CA, I asked the installation 
script to install its own CA.

This is the only problem the installation seems to be having, because there are 
several fedora desktops authenticating happily against the IPA instance.

Thanks for your prompt response.



389-ds-base-1.2.10.4-2.fc16.x86_64
389-ds-base-libs-1.2.10.4-2.fc16.x86_64
abattis-cantarell-fonts-0.0.7-1.fc16.noarch
abrt-2.0.7-2.fc16.x86_64
abrt-addon-ccpp-2.0.7-2.fc16.x86_64
abrt-addon-kerneloops-2.0.7-2.fc16.x86_64
abrt-addon-python-2.0.7-2.fc16.x86_64
abrt-addon-vmcore-2.0.7-2.fc16.x86_64
abrt-desktop-2.0.7-2.fc16.x86_64
abrt-gui-2.0.7-2.fc16.x86_64
abrt-libs-2.0.7-2.fc16.x86_64
abrt-retrace-client-2.0.7-2.fc16.x86_64
accountsservice-0.6.15-2.fc16.x86_64
accountsservice-libs-0.6.15-2.fc16.x86_64
acl-2.2.51-2.fc16.x86_64
acpid-2.0.14-1.fc16.x86_64
adwaita-cursor-theme-3.2.1-2.fc16.noarch
adwaita-gtk2-theme-3.2.1-2.fc16.x86_64
adwaita-gtk3-theme-3.2.1-2.fc16.x86_64
aic94xx-firmware-30-2.fc15.noarch
aisleriot-3.2.1-2.fc16.x86_64
alsa-firmware-1.0.25-1.fc16.noarch
alsa-lib-1.0.25-1.fc16.x86_64
alsa-tools-firmware-1.0.25-1.fc16.x86_64
apache-commons-collections-3.2.1-11.fc16.noarch
apache-commons-daemon-1.0.7-1.fc16.1.x86_64
apache-commons-dbcp-1.4-7.fc16.noarch
apache-commons-lang-2.6-4.fc16.noarch
apache-commons-logging-1.1.1-16.fc16.noarch
apache-commons-pool-1.5.6-1.fc16.noarch
apg-2.3.0b-11.fc16.x86_64
apr-1.4.6-1.fc16.x86_64
apr-devel-1.4.6-1.fc16.x86_64
apr-util-1.3.12-1.fc16.x86_64
apr-util-devel-1.3.12-1.fc16.x86_64
apr-util-ldap-1.3.12-1.fc16.x86_64
ar9170-firmware-2009.05.28-3.fc15.noarch
at-3.1.13-5.fc16.x86_64
atk-2.2.0-2.fc16.x86_64
atkmm-2.22.5-1.fc16.x86_64
atmel-firmware-1.3-8.fc15.noarch
at-spi2-atk-2.2.1-2.fc16.x86_64
at-spi2-core-2.2.1-2.fc16.x86_64
attr-2.4.46-2.fc16.x86_64
audit-2.2.1-1.fc16.x86_64
audit-libs-2.2.1-1.fc16.x86_64
audit-libs-python-2.2.1-1.fc16.x86_64
authconfig-6.1.16-2.fc16.x86_64
authconfig-gtk-6.1.16-2.fc16.x86_64
avahi-0.6.30-4.fc16.x86_64
avahi-autoipd-0.6.30-4.fc16.x86_64
avahi-glib-0.6.30-4.fc16.x86_64
avahi-gobject-0.6.30-4.fc16.x86_64
avahi-libs-0.6.30-4.fc16.x86_64
avahi-ui-gtk3-0.6.30-4.fc16.x86_64
b43-fwcutter-015-1.fc16.x86_64
b43-openfwwf-5.2-6.fc15.noarch
basesystem-10.0-5.fc16.noarch
bash-4.2.24-1.fc16.x86_64
bash-completion-1.3-6.fc16.noarch
bc-1.06.95-3.fc15.x86_64
bcel-5.2-9.fc15.noarch
bind-9.8.2-0.4.rc2.fc16.x86_64
bind-dyndb-ldap-1.1.0-0.10.b2.fc16.x86_64
bind-libs-9.8.2-0.4.rc2.fc16.x86_64
bind-libs-lite-9.8.2-0.4.rc2.fc16.x86_64
bind-license-9.8.2-0.4.rc2.fc16.noarch
bind-utils-9.8.2-0.4.rc2.fc16.x86_64
binutils-2.21.53.0.1-6.fc16.x86_64
biosdevname-0.3.11-5.fc16.x86_64
bluez-4.96-3.fc16.x86_64
bluez-libs-4.96-3.fc16.x86_64
brasero-3.2.0-1.fc16.x86_64
brasero-libs-3.2.0-1.fc16.x86_64
brasero-nautilus-3.2.0-1.fc16.x86_64
brlapi-0.5.6-3.fc16.x86_64
brltty-4.3-3.fc16.x86_64
btparser-0.13-1.fc16.x86_64
btrfs-progs-0.19-16.fc16.x86_64
bzip2-1.0.6-3.fc15.x86_64
bzip2-libs-1.0.6-3.fc15.x86_64
ca-certificates-2011.78-1.fc16.noarch
cadaver-0.23.3-2.fc15.x86_64
cairo-1.10.2-4.fc16.x86_64
cairo-gobject-1.10.2-4.fc16.x86_64
cairomm-1.10.0-1.fc16.x86_64
c-ares-1.7.4-3.fc16.x86_64
caribou-0.4.1-3.fc16.x86_64
caribou-antler-0.4.1-3.fc16.x86_64
caribou-gtk2-module-0.4.1-3.fc16.x86_64
caribou-gtk3-module-0.4.1-3.fc16.x86_64
cdparanoia-libs-10.2-10.fc15.x86_64
cdrdao-1.2.3-11.fc16.x86_64
celt-0.11.1-2.fc16.x86_64
celt051-0.5.1.3-3.fc15.x86_64
certmonger-0.56-1.fc16.x86_64
checkpolicy-2.1.6-2.fc16.x86_64
cheese-3.2.2-1.fc16.x86_64
cheese-libs-3.2.2-1.fc16.x86_64
chkconfig-1.3.59-1.fc16.x86_64
chrony-1.26-5.20110831gitb088b7.fc16.x86_64
cifs-utils-5.3-2.fc16.x86_64
clutter-1.8.4-1.fc16.x86_64
clutter-gst-1.4.4-1.fc16.x86_64
clutter-gtk-1.0.4-1.fc16.x86_64
cogl-1.8.2-2.fc16.x86_64
colord-0.1.15-2.fc16.x86_64
color-filesystem-1-8.noarch
compat-readline5-5.2-18.fc15.x86_64
comps-extras-20-2.fc15.noarch
ConsoleKit-0.4.5-1.fc15.x86_64
ConsoleKit-libs-0.4.5-1.fc15.x86_64
ConsoleKit-x11-0.4.5-1.fc15.x86_64
control-center-3.2.2-1.fc16.x86_64
control-center-filesystem-3.2.2-1.fc16.x86_64
coolkey-1.1.0-19.fc15.x86_64
coreutils-8.12-7.fc16.x86_64
coreutils-libs-8.12-7.fc16.x86_64
cpio-2.11-4.fc16.x86_64
cracklib-2.8.18-2.fc15.x86_64
cracklib-dicts-2.8.18-2.fc15.x86_64
cracklib-python-2.8.18-2.fc15.x86_64
crda-1.1.1_2010.11.22-2.fc15.x86_64
cronie-1.4.8-10.fc16.x86_64
cronie-anacron-1.4.8-10.fc16.x86_64
crontabs-1.11-2.20101115git.fc15.noarch
crypto-utils-2.4.1-31.x86_64
cryptsetup-luks-1.3.1-3.fc16.x86_64
cryptsetup-luks-libs-1.3.1-3.fc16.x86_64
cups-libs-1.5.2-8.1.fc16.x86_64
cups-pk-helper-0.1.3-3.fc16.x86_64
curl-7.21.7-7.fc16.x86_64
cyrus-sasl-2.1.23-27.fc16.x86_64
cyrus-sasl-devel-2.1.23-27.fc16.x86_64
cyrus-sasl-gssapi-2.1.23-27.fc16.x86_64
cyrus-sasl-lib-2.1.23-27.fc16.x86_64
cyrus-sasl-md5-2.1.23-27.fc16.x86_64
cyrus-sasl-plain-2.1.23-27.fc16

Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?

[Richard Megginson]

- Original Message -
> On Tue, Apr 17, 2012 at 09:26, Rich Megginson 
> wrote:
> > On 04/17/2012 07:26 AM, Dan Scott wrote:
> >>
> >> On Fri, Apr 13, 2012 at 17:44, Rich Megginson
> >>  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.

> 
> On my PKI-IPA server, the CLEANRUV task doesn't seem to work. It
> keeps
> re-adding entries after I remove them. I have 3 entries for my
> non-existent fileserver4 - They disappear when I remove them, but
> they
> come back after a few minutes.

Right, because they are being replicated from another master.  You will need to 
run the CLEANRUV on all masters at the same time.

> 
> Thanks,
> 
> Dan
> 

___
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?

[Dan Scott]

On Tue, Apr 17, 2012 at 09:26, Rich Megginson  wrote:
> On 04/17/2012 07:26 AM, Dan Scott wrote:
>>
>> On Fri, Apr 13, 2012 at 17:44, Rich Megginson  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?

On my PKI-IPA server, the CLEANRUV task doesn't seem to work. It keeps
re-adding entries after I remove them. I have 3 entries for my
non-existent fileserver4 - They disappear when I remove them, but they
come back after a few minutes.

Thanks,

Dan

___
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?

[Rich Megginson]

On 04/17/2012 07:26 AM, Dan Scott wrote:

On Fri, Apr 13, 2012 at 17:44, Rich Megginson  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



fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of:
[13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send
startTLS request: error -1 (Can't contact LDAP server) errno 107
(Transport endpoint is not connected)


This is a real connection error - could be cert or hostname lookup
related.

How do I find out if it's cert or hostname lookup? Which hostname?
Fileserver3 runs DNS, and it seems to be working fine.


Try ldapsearch - on server3

LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H
ldap://server2.fqdn -D "cn=directory manager" -W -s base -b ""

If that works, check to make sure the replication agreement has the
correct
server2.fqdn

If that doesn't work, use ldapsearch -d 1 -x . to get further
debugging
information.

The replication agreements (according to ipa-replica-manage) all have
the correct host names - I'm not sure what ldapsearch command to run
to check the replication agreements.


ipa-replica-manage --list?  or something like that?

That's what I was using - they are all correct.


Ok.  And the LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch ... is
working?

It returns a load of supportedExtension: and supportedControl: entries
- I guess that means 'working'? :)

Yes.

Then I'm not sure why TLS/SSL connections with replication are not working.


Thanks,

Dan


___
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?

[Dan Scott]

On Fri, Apr 13, 2012 at 17:44, Rich Megginson  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?

 fileserver3's /var/log/dirsrv/slapd-PKI-IPA/errors contains lots of:
 [13/Apr/2012:13:52:50 -0400] slapi_ldap_bind - Error: could not send
 startTLS request: error -1 (Can't contact LDAP server) errno 107
 (Transport endpoint is not connected)
>>>
>>>
>>> This is a real connection error - could be cert or hostname lookup
>>> related.
>>
>> How do I find out if it's cert or hostname lookup? Which hostname?
>> Fileserver3 runs DNS, and it seems to be working fine.
>
>
> Try ldapsearch - on server3
>
> LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch -x -ZZ -H
> ldap://server2.fqdn -D "cn=directory manager" -W -s base -b ""
>
> If that works, check to make sure the replication agreement has the
> correct
> server2.fqdn
>
> If that doesn't work, use ldapsearch -d 1 -x . to get further
> debugging
> information.

 The replication agreements (according to ipa-replica-manage) all have
 the correct host names - I'm not sure what ldapsearch command to run
 to check the replication agreements.
>>>
>>>
>>> ipa-replica-manage --list?  or something like that?
>>
>> That's what I was using - they are all correct.
>
>
> Ok.  And the LDAPTLS_CACERTDIR=/etc/dirsrv/slapd-PKI-IPA ldapsearch ... is
> working?

It returns a load of supportedExtension: and supportedControl: entries
- I guess that means 'working'? :)

Thanks,

Dan

___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users