Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
On Fri, Apr 13, 2012 at 17:44, Rich Megginson rmegg...@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? 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
Re: [Freeipa-users] General status of my FreeIPA servers - is there a method for cleaning them?
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 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?
On Tue, Apr 17, 2012 at 09:26, Rich Megginson rmegg...@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?
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?
- Original Message -
On Tue, Apr 17, 2012 at 09:26, Rich Megginson rmegg...@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.
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
[Freeipa-users] Fwd: Problem creating replica file
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
Re: [Freeipa-users] client without certmonger/dbus
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_ http://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
Re: [Freeipa-users] Screensaver unlock with expired password
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] DNS zone delegation
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] General status of my FreeIPA servers - is there a method for cleaning them?
On Tue, Apr 17, 2012 at 10:29, Richard Megginson rmegg...@redhat.com wrote:
- Original Message -
On Tue, Apr 17, 2012 at 09:26, Rich Megginson rmegg...@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]
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] General status of my FreeIPA servers - is there a method for cleaning them?
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.
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] client without certmonger/dbus
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] client without certmonger/dbus
On Mon, Apr 16, 2012 at 11:09 PM, Christoph Kaminski christoph.kamin...@biotronik.com 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
On Tue, Apr 17, 2012 at 10:28 PM, Christoph Kaminski christoph.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 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
[Freeipa-users] Antwort: Re: client without certmonger/dbus
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 sbing...@gmail.com schrieb: -An: Christoph Kaminski christoph.kamin...@biotronik.comVon: Stephen Ingram sbing...@gmail.comDatum: 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 Kaminskichristoph.kamin...@biotronik.com 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 defaults0 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
