[Freeipa-users] Fedora 17 FreeIPA Replica not starting up
After installing a replica on a fresh up to date install of FC17, everything seems fine until a reboot. FreeIPA is running on the new machine, etc. But after the reboot ldap doesn't start on it's own and can't be made to start manually. The origional FreeIPA instance, same software versions, is runny just fine. Release: 1.fc17 Arch: x86_64 FreeIPA Version: 2.2.0 here is the short error. I can post more if this symptom isn't enough. (I've replaced the names of my actual machines and domain) # ipactl start Starting Directory Service Failed to read data from Directory Service: Unknown error when retrieving list of services from LDAP: [Errno 2] No such file or directory Shutting down # tail -20 /var/log/messages Aug 8 23:56:04 replica systemd[1]: dirsrv@PKI-IPA.service: control process exited, code=exited status=1 Aug 8 23:56:04 replica systemd[1]: Unit dirsrv@PKI-IPA.service entered failed state. Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system] Activating service name='net.reactivated.Fprint' (using servicehelper) Aug 9 00:00:16 replica dbus[610]: [system] Activating service name='net.reactivated.Fprint' (using servicehelper) Aug 9 00:00:16 replica dbus-daemon[610]: Launching FprintObject Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system] Successfully activated service 'net.reactivated.Fprint' Aug 9 00:00:16 replica dbus[610]: [system] Successfully activated service 'net.reactivated.Fprint' Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: D-Bus service launched with name: net.reactivated.Fprint Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: entering main loop Aug 9 00:00:46 replica dbus-daemon[610]: ** Message: No devices in use, exit Aug 9 00:05:01 replica ns-slapd[2265]: [09/Aug/2012:00:05:01 -0600] startup - The default password storage scheme SSHA could not be read or was not found in the file /etc/dirsrv/slapd-PIVOTVFX-NET/dse.ldif. It is mandatory. Aug 9 00:05:01 replica systemd[1]: dirsrv@EXAMPLE-COM.service: control process exited, code=exited status=1 Aug 9 00:05:01 replica systemd[1]: Unit dirsrv@EXAMPLE-COM.service entered failed state. Aug 9 00:05:01 replica ns-slapd[2266]: [09/Aug/2012:00:05:01 -0600] startup - The default password storage scheme SSHA could not be read or was not found in the file /etc/dirsrv/slapd-PKI-IPA/dse.ldif. It is mandatory. Aug 9 00:05:01 replica systemd[1]: dirsrv@PKI-IPA.service: control process exited, code=exited status=1 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 17 FreeIPA Replica not starting up
I think I've narrowed it down to the tombstone problem.
But now I'm at a loss for what to do. The only advice I can find
involves using direct ldap code an that is way over my head. (I'd
prefer to not completely destroy my database in the process of trying
to clean out the zombies)
Is there any kind of wrapper script I can use to kill the zombie
{replicageneration} and nsds5replica?
Thanks for any help!
-Aaron
On Thu, Aug 9, 2012 at 12:13 AM, bin.e...@gmail.com wrote:
After installing a replica on a fresh up to date install of FC17,
everything seems fine until a reboot. FreeIPA is running on the new
machine, etc.
But after the reboot ldap doesn't start on it's own and can't be made
to start manually. The origional FreeIPA instance, same software
versions, is runny just fine.
Release: 1.fc17 Arch: x86_64 FreeIPA Version: 2.2.0
here is the short error. I can post more if this symptom isn't enough.
(I've replaced the names of my actual machines and domain)
# ipactl start
Starting Directory Service
Failed to read data from Directory Service: Unknown error when
retrieving list of services from LDAP: [Errno 2] No such file or
directory
Shutting down
# tail -20 /var/log/messages
Aug 8 23:56:04 replica systemd[1]: dirsrv@PKI-IPA.service: control
process exited, code=exited status=1
Aug 8 23:56:04 replica systemd[1]: Unit dirsrv@PKI-IPA.service
entered failed state.
Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system]
Activating service name='net.reactivated.Fprint' (using servicehelper)
Aug 9 00:00:16 replica dbus[610]: [system] Activating service
name='net.reactivated.Fprint' (using servicehelper)
Aug 9 00:00:16 replica dbus-daemon[610]: Launching FprintObject
Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system]
Successfully activated service 'net.reactivated.Fprint'
Aug 9 00:00:16 replica dbus[610]: [system] Successfully activated
service 'net.reactivated.Fprint'
Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: D-Bus service
launched with name: net.reactivated.Fprint
Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: entering main loop
Aug 9 00:00:46 replica dbus-daemon[610]: ** Message: No devices in use, exit
Aug 9 00:05:01 replica ns-slapd[2265]: [09/Aug/2012:00:05:01 -0600]
startup - The default password storage scheme SSHA could not be read
or was not found in the file /etc/dirsrv/slapd-PIVOTVFX-NET/dse.ldif.
It is mandatory.
Aug 9 00:05:01 replica systemd[1]: dirsrv@EXAMPLE-COM.service:
control process exited, code=exited status=1
Aug 9 00:05:01 replica systemd[1]: Unit dirsrv@EXAMPLE-COM.service
entered failed state.
Aug 9 00:05:01 replica ns-slapd[2266]: [09/Aug/2012:00:05:01 -0600]
startup - The default password storage scheme SSHA could not be read
or was not found in the file /etc/dirsrv/slapd-PKI-IPA/dse.ldif. It is
mandatory.
Aug 9 00:05:01 replica systemd[1]: dirsrv@PKI-IPA.service: control
process exited, code=exited status=1
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] cannot find name for user ID
On 08/08/2012 01:11 PM, Jakub Hrozek wrote: On Wed, Aug 08, 2012 at 10:45:47AM -0800, Erinn Looney-Triggs wrote: An interesting problem has popped up and I am not sure where the issue lies. Users logging in are presented with cannot find name for user ID etc. etc. for all groups they are a member of id returns nothing but the numbers, and a getent passwd username returns nothing, when running as the user. However, as root a getent passwd username works. I am taking a look through logs and haven't found much so far, another user experienced a similar issue and a ipa-client-install --uninstall and reinstall (this is starting to feel like windows :) did the trick for them, however it has not solved the issue for me. I have also cleared the sssd cache, and given that process a kick to no avail. Firewall rules have not changed, and I assume the ipa-client-install process would have failed if a firewall issue was present. After increasing sssd logging levels I see a lot of requests for the user in the sssd logs, but no returns, not that I know if the logging is supposed to log the return. This is on a RHEL 5.8 client: ipa-client-2.1.3-2.el5_8 sssd-1.5.1-49.el5_8.1 Connecting to a RHEL 6.3 IPA server. Any ideas? -Erinn Hi Erinn, The requests for the user you saw were only in the sssd_nss log or did they make it to the sssd_$domain.log as well? Can you paste sanitized contents of both, please? I can't think of a reason to make lookups work only as root, that's really strange. Can you check for AVC denials? Can you also check the permissions on /var/lib/sss/pipes/nss ? It should be 0666. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Ok I figured out what was happening, or at least a portion of it, it looks like the sudo package update that was pushed out from red hat to rhel5 c86_64 systems (at least) modified the permissions of the /etc/nsswitch.conf to 600, thus blocking everyone but root from reading it and causing this weird issue where root could pull user info but no one else. At this point I only assume it was the sudo package as that is the package that was updated on 10 or so RHEL 5 hosts at the exact same time as the nsswitch file was updated and the permissions changed. I have to go dig through the rpm scripts to see what could cause this, then work with support to get it fixed overall. Thanks for the help, this was a really odd problem. -Erinn 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] cannot find name for user ID
On 08/08/2012 01:11 PM, Jakub Hrozek wrote: On Wed, Aug 08, 2012 at 10:45:47AM -0800, Erinn Looney-Triggs wrote: An interesting problem has popped up and I am not sure where the issue lies. Users logging in are presented with cannot find name for user ID etc. etc. for all groups they are a member of id returns nothing but the numbers, and a getent passwd username returns nothing, when running as the user. However, as root a getent passwd username works. I am taking a look through logs and haven't found much so far, another user experienced a similar issue and a ipa-client-install --uninstall and reinstall (this is starting to feel like windows :) did the trick for them, however it has not solved the issue for me. I have also cleared the sssd cache, and given that process a kick to no avail. Firewall rules have not changed, and I assume the ipa-client-install process would have failed if a firewall issue was present. After increasing sssd logging levels I see a lot of requests for the user in the sssd logs, but no returns, not that I know if the logging is supposed to log the return. This is on a RHEL 5.8 client: ipa-client-2.1.3-2.el5_8 sssd-1.5.1-49.el5_8.1 Connecting to a RHEL 6.3 IPA server. Any ideas? -Erinn Hi Erinn, The requests for the user you saw were only in the sssd_nss log or did they make it to the sssd_$domain.log as well? Can you paste sanitized contents of both, please? I can't think of a reason to make lookups work only as root, that's really strange. Can you check for AVC denials? Can you also check the permissions on /var/lib/sss/pipes/nss ? It should be 0666. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Yeah I can confirm this for certain now, take a look below: erinn@numbersix ~ $ ls -l /etc/nsswitch.conf -rw-r--r-- 1 root root 1726 Dec 27 2011 /etc/nsswitch.conf erinn@numbersix ~ $ sudo yum -y update sudo Loaded plugins: rhnplugin, security Skipping security plugin, no data Setting up Update Process Resolving Dependencies Skipping security plugin, no data -- Running transaction check --- Package sudo.x86_64 0:1.7.2p1-14.el5_8.2 set to be updated -- Finished Dependency Resolution Dependencies Resolved Package ArchVersion Repository Size Updating: sudo x86_64 1.7.2p1-14.el5_8.2 rhel-x86_64-server-5 359 k Transaction Summary Install 0 Package(s) Upgrade 1 Package(s) Total size: 359 k Downloading Packages: Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : sudo 1/2 Cleanup: sudo 2/2 Updated: sudo.x86_64 0:1.7.2p1-14.el5_8.2 Complete! erinn@numbersix ~ $ ls -l /etc/nsswitch.conf -rw--- 1 root root 1727 Aug 9 08:43 /etc/nsswitch.conf So it appears the latest sudo update is causing this issue, I am uncertain whether this is intentional or not at this point (probably not), but it is the cause, and it sure does make things messy for IPA. I have filed a support case. -Erinn 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] Simple question about replication promotion
Yeah, that probably wasn't very clear... Original - IPA instance w/ DNS, and no Dogtag Replica - IPA instance w/ DNS, and no Dogtag On 8/8/12 3:34 PM, Rob Crittenden wrote: Rolf Brusletto wrote: We had a rather severe issue last night on our primary IPA server(ver 2.2.0), but the replica is still happily plugging along, which very nice. My question is, there is very, very little I can do with the 'master'. From what I've read, there ins't any replicaton, and I just want to verify that a replica is just another master, assuming you're not using the CA option. If so, when I rebuild the primary server, do I just configure it to be a replica to what was the secondary? Just to be clear, you installed the original server with a dogtag CA installed? And then you created a replica but didn't configure a CA on it? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Simple question about replication promotion
Rolf Brusletto wrote: Yeah, that probably wasn't very clear... Original - IPA instance w/ DNS, and no Dogtag Replica - IPA instance w/ DNS, and no Dogtag The devil is always in the details. For user data yes, there is no difference between the initially installed master and any others. It is the CA where things get problematic. In your case, where you used --selfsign when installing, your CA is only on the initial master. You might want to take a look at section 18.8.2 here: http://docs.fedoraproject.org/en-US/Fedora/16/html/FreeIPA_Guide/promoting-replica.html If you try to run ipa-replica-prepare on your second master it will refuse to do so because it lacks a CA. You need to fetch it from the current master, or restore the PKCS#12 file you were warned to back up after the initial installation. In your case you a lso need to create a serial number file (if you don't have this you can always pick a new starting value). rob On 8/8/12 3:34 PM, Rob Crittenden wrote: Rolf Brusletto wrote: We had a rather severe issue last night on our primary IPA server(ver 2.2.0), but the replica is still happily plugging along, which very nice. My question is, there is very, very little I can do with the 'master'. From what I've read, there ins't any replicaton, and I just want to verify that a replica is just another master, assuming you're not using the CA option. If so, when I rebuild the primary server, do I just configure it to be a replica to what was the secondary? Just to be clear, you installed the original server with a dogtag CA installed? And then you created a replica but didn't configure a CA on it? rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Fedora 17 FreeIPA Replica not starting up
On 08/09/2012 01:14 AM, bin.e...@gmail.com wrote:
I think I've narrowed it down to the tombstone problem.
What tombstone problem?
ls -al /etc/dirsrv/slapd-*
Also, please post a sanitized errors log from
/var/log/dirsrv/slapd-YOUR-DOMAIN/errors
But now I'm at a loss for what to do. The only advice I can find
involves using direct ldap code an that is way over my head. (I'd
prefer to not completely destroy my database in the process of trying
to clean out the zombies)
Is there any kind of wrapper script I can use to kill the zombie
{replicageneration} and nsds5replica?
Thanks for any help!
-Aaron
On Thu, Aug 9, 2012 at 12:13 AM,bin.e...@gmail.com wrote:
After installing a replica on a fresh up to date install of FC17,
everything seems fine until a reboot. FreeIPA is running on the new
machine, etc.
But after the reboot ldap doesn't start on it's own and can't be made
to start manually. The origional FreeIPA instance, same software
versions, is runny just fine.
Release: 1.fc17 Arch: x86_64 FreeIPA Version: 2.2.0
here is the short error. I can post more if this symptom isn't enough.
(I've replaced the names of my actual machines and domain)
# ipactl start
Starting Directory Service
Failed to read data from Directory Service: Unknown error when
retrieving list of services from LDAP: [Errno 2] No such file or
directory
Shutting down
# tail -20 /var/log/messages
Aug 8 23:56:04 replica systemd[1]: dirsrv@PKI-IPA.service: control
process exited, code=exited status=1
Aug 8 23:56:04 replica systemd[1]: Unit dirsrv@PKI-IPA.service
entered failed state.
Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system]
Activating service name='net.reactivated.Fprint' (using servicehelper)
Aug 9 00:00:16 replica dbus[610]: [system] Activating service
name='net.reactivated.Fprint' (using servicehelper)
Aug 9 00:00:16 replica dbus-daemon[610]: Launching FprintObject
Aug 9 00:00:16 replica dbus-daemon[610]: dbus[610]: [system]
Successfully activated service 'net.reactivated.Fprint'
Aug 9 00:00:16 replica dbus[610]: [system] Successfully activated
service 'net.reactivated.Fprint'
Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: D-Bus service
launched with name: net.reactivated.Fprint
Aug 9 00:00:16 replica dbus-daemon[610]: ** Message: entering main loop
Aug 9 00:00:46 replica dbus-daemon[610]: ** Message: No devices in use, exit
Aug 9 00:05:01 replica ns-slapd[2265]: [09/Aug/2012:00:05:01 -0600]
startup - The default password storage scheme SSHA could not be read
or was not found in the file /etc/dirsrv/slapd-PIVOTVFX-NET/dse.ldif.
It is mandatory.
Aug 9 00:05:01 replica systemd[1]: dirsrv@EXAMPLE-COM.service:
control process exited, code=exited status=1
Aug 9 00:05:01 replica systemd[1]: Unit dirsrv@EXAMPLE-COM.service
entered failed state.
Aug 9 00:05:01 replica ns-slapd[2266]: [09/Aug/2012:00:05:01 -0600]
startup - The default password storage scheme SSHA could not be read
or was not found in the file /etc/dirsrv/slapd-PKI-IPA/dse.ldif. It is
mandatory.
Aug 9 00:05:01 replica systemd[1]: dirsrv@PKI-IPA.service: control
process exited, code=exited status=1
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] cannot find name for user ID
On Thu, Aug 09, 2012 at 12:52:47AM -0800, Erinn Looney-Triggs wrote: On 08/08/2012 01:11 PM, Jakub Hrozek wrote: On Wed, Aug 08, 2012 at 10:45:47AM -0800, Erinn Looney-Triggs wrote: An interesting problem has popped up and I am not sure where the issue lies. Users logging in are presented with cannot find name for user ID etc. etc. for all groups they are a member of id returns nothing but the numbers, and a getent passwd username returns nothing, when running as the user. However, as root a getent passwd username works. I am taking a look through logs and haven't found much so far, another user experienced a similar issue and a ipa-client-install --uninstall and reinstall (this is starting to feel like windows :) did the trick for them, however it has not solved the issue for me. I have also cleared the sssd cache, and given that process a kick to no avail. Firewall rules have not changed, and I assume the ipa-client-install process would have failed if a firewall issue was present. After increasing sssd logging levels I see a lot of requests for the user in the sssd logs, but no returns, not that I know if the logging is supposed to log the return. This is on a RHEL 5.8 client: ipa-client-2.1.3-2.el5_8 sssd-1.5.1-49.el5_8.1 Connecting to a RHEL 6.3 IPA server. Any ideas? -Erinn Hi Erinn, The requests for the user you saw were only in the sssd_nss log or did they make it to the sssd_$domain.log as well? Can you paste sanitized contents of both, please? I can't think of a reason to make lookups work only as root, that's really strange. Can you check for AVC denials? Can you also check the permissions on /var/lib/sss/pipes/nss ? It should be 0666. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users Yeah I can confirm this for certain now, take a look below: erinn@numbersix ~ $ ls -l /etc/nsswitch.conf -rw-r--r-- 1 root root 1726 Dec 27 2011 /etc/nsswitch.conf erinn@numbersix ~ $ sudo yum -y update sudo Loaded plugins: rhnplugin, security Skipping security plugin, no data Setting up Update Process Resolving Dependencies Skipping security plugin, no data -- Running transaction check --- Package sudo.x86_64 0:1.7.2p1-14.el5_8.2 set to be updated -- Finished Dependency Resolution Dependencies Resolved Package ArchVersion Repository Size Updating: sudo x86_64 1.7.2p1-14.el5_8.2 rhel-x86_64-server-5 359 k Transaction Summary Install 0 Package(s) Upgrade 1 Package(s) Total size: 359 k Downloading Packages: Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : sudo 1/2 Cleanup: sudo 2/2 Updated: sudo.x86_64 0:1.7.2p1-14.el5_8.2 Complete! erinn@numbersix ~ $ ls -l /etc/nsswitch.conf -rw--- 1 root root 1727 Aug 9 08:43 /etc/nsswitch.conf So it appears the latest sudo update is causing this issue, I am uncertain whether this is intentional or not at this point (probably not), but it is the cause, and it sure does make things messy for IPA. I have filed a support case. -Erinn You were a victim of https://bugzilla.redhat.com/show_bug.cgi?id=846631 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Prompting for expired passwords on AIX
I've kerberized a bunch of AIX machines, and I noticed when I was starting out that AIX allows people to connect that have expired passwords, and does not prompt for changes. 1) does anyone know what I need to do on AIX to make this happen (I don't hold out much hope for this.) 2) alternately, does anyone know what I'd have to do on Linux to change this behavior (maybe from that I can find something on AIX.) I plan on opening a ticket with IBM too, but I wanted to see if anyone has run into this before. Thanks! -- The government is going to read our mail anyway, might as well make it tough for them. GPG Public key ID: B6A1A7C6 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
