Re: [Freeipa-users] [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached
On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: Hi guys, I don't know if you already know this, but in my logs I can find this: Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is preventing /usr/bin/memcached from create access on the sock_file ipa_memcached. For complete SELinux messages. run sealert -l 85b51f4e-3f2e-4e7d-819f-1efb04836de3 I'm running: [root@freeipa01 ipa]# rpm -qa|grep freeipa freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 freeipa-client-2.1.90.rc1-0.fc16.x86_64 freeipa-server-2.1.90.rc1-0.fc16.x86_64 freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 freeipa-python-2.1.90.rc1-0.fc16.x86_64 HTH Marco Hello Marco, there is a SELinux policy where this issue is fixed: https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 Its still in updates-testing though. This is an appropriate BZ: https://bugzilla.redhat.com/show_bug.cgi?id=783592 It requires httpd_manage_ipa SELinux boolean to be set, upstream FreeIPA bits already sets it automatically during installation. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] [Freeipa-devel] FreeIPA beta1: SELinux prohibits memcached
On Tue, 2012-03-20 at 13:14 +0100, Marco Pizzoli wrote: Hi Martin, On Tue, Mar 20, 2012 at 1:02 PM, Martin Kosek mko...@redhat.com wrote: On Tue, 2012-03-20 at 12:44 +0100, Marco Pizzoli wrote: Hi guys, I don't know if you already know this, but in my logs I can find this: Mar 20 12:14:47 freeipa01 setroubleshoot: SELinux is preventing /usr/bin/memcached from create access on the sock_file ipa_memcached. For complete SELinux messages. run sealert -l 85b51f4e-3f2e-4e7d-819f-1efb04836de3 I'm running: [root@freeipa01 ipa]# rpm -qa|grep freeipa freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 freeipa-client-2.1.90.rc1-0.fc16.x86_64 freeipa-server-2.1.90.rc1-0.fc16.x86_64 freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 freeipa-python-2.1.90.rc1-0.fc16.x86_64 HTH Marco Hello Marco, there is a SELinux policy where this issue is fixed: https://admin.fedoraproject.org/updates/FEDORA-2012-2733/selinux-policy-3.10.0-80.fc16 Its still in updates-testing though. This is an appropriate BZ: https://bugzilla.redhat.com/show_bug.cgi?id=783592 Thanks for your answer. Just to be aligned, actually it's not still available on the updates-testing channel too. I see on the cli that I cannot update to that release and by looking at the link you posted I see it has still to be pushed - current state: pending. Thanks again Marco You are right, its not there yet. You can just download and install fixed RPM from koji (there is a link on Fedora update file), but it is of course a SElinux policy version without proper community testing. I tried it and it worked for me, no AVC raised. Martin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
On Tue, Mar 20, 2012 at 1:32 PM, Dmitri Pal d...@redhat.com wrote: ** On 03/20/2012 05:19 AM, Marco Pizzoli wrote: On Tue, Mar 20, 2012 at 12:14 AM, Dmitri Pal d...@redhat.com wrote: On 03/19/2012 06:54 PM, Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden rcrit...@redhat.comwrote: Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Dmitri Pal wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=__mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it --user-container=ou=people,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it --user-objectclass=__inetOrgPerson --group-container=ou=groups,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.__it http://mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.__mydomain.it/ipa/xml https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.__mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server *u*'http://freeipa01.unix.__mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Well, I don't think either is a bug. If you have users/groups in multiple places you'll need to migrate them individually for now. It is safe to run migrate-ds multiple times, existing users are not migrated. I just re-executed by specifing a nested ou for my groups. This is what I got: ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.csebo.it/ipa/xml' --- migrate-ds: --- Migrated: Failed user: fw03075_no: Type or value exists: [other users listed] Failed group: pdbac32: Type or value exists: [other groups listed] -- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. I don't understand what it's trying to telling me. On my FreeIPA ldap server I don't see any imported user. What's my fault here? The u is a python-ism for unicode. This is not a bug. Please, could you give a little more detail on this? It's only a hint on what that data represents in a Python variable? Thanks again Marco Type or value exists occurs when one tries to add an attribute value to an entry that already exists. I suspect that the underlying problem is different between users and groups. For groups it is likely adding a duplicate member. For users I'm not really sure. It could be one of the POSIX attributes. What does a failed entry look like? rob The user entry: dn: uid=fw03075_NO,ou=People,dc=mydc1,dc=mydc2.it description: fw03075 cn: fw03075 uidNumber: 11013 gidNumber: 503 homeDirectory: /home/fw03075 loginShell: /bin/sh gecos: fw03075 shadowLastChange: 13059 shadowMax: 9 shadowWarning: 7 objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount objectClass: top objectClass: xxxPeopleAttributes sn: SN_NON_IMPOSTATO givenName: GIVENNAME_NON_IMPOSTATO xxxUfficio: UFFICIO_NON_IMPOSTATO xxxTipoUtente: tecnico uid: fw03075_NO userPassword: secret group entry: --- dn: cn=pdbac32,ou=pdbac32,ou=prod,ou=db2,ou=databases,ou=Groups,dc=mydc1,dc= mydc2.it gidNumber: 10015 member: uid=NESSUNO,ou=People,dc=mydc1,dc=mydc2.it member: uid=aaa415,ou=People,dc=mydc1,dc=mydc2.it member:
Re: [Freeipa-users] Problem in ipa migrate-ds procedure
On 03/20/2012 09:09 AM, Marco Pizzoli wrote: On Tue, Mar 20, 2012 at 1:32 PM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/20/2012 05:19 AM, Marco Pizzoli wrote: On Tue, Mar 20, 2012 at 12:14 AM, Dmitri Pal d...@redhat.com mailto:d...@redhat.com wrote: On 03/19/2012 06:54 PM, Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 8:31 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Marco Pizzoli wrote: On Mon, Mar 19, 2012 at 2:42 PM, Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com wrote: Dmitri Pal wrote: On 03/17/2012 07:36 AM, Marco Pizzoli wrote: Hi guys, I'm trying to migrate my ldap user base to freeipa. I'm using the last Release Candidate. I already changed ipa config-mod --enable-migration=TRUE This is what I have: ipa -v migrate-ds --bind-dn=cn=manager,dc=__mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it --user-container=ou=people,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it --user-objectclass=__inetOrgPerson --group-container=ou=groups,__dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it --group-objectclass=posixGroup --base-dn=dc=mydc1,dc=mydc2.__it http://mydc2.it http://mydc2.it --with-compat ldap://ldap01 ipa: INFO: trying https://freeipa01.unix.__mydomain.it/ipa/xml http://mydomain.it/ipa/xml https://freeipa01.unix.mydomain.it/ipa/xml Password: ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.__mydomain.it/ipa/xml http://mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' ipa: ERROR: Container for group not found at ou=groups,dc=mydc1,dc=mydc2.it http://mydc2.it http://mydc2.it http://mydc2.it I looked at my ldap server logs and I found out that the search executed has scope=1. Actually both for users and groups. This is a problem for me, in having a lot of subtrees (ou) in which my users and groups are. Is there a way to manage this? Thanks in advance Marco P.s. As a side note, I suppose there's a typo in the verbose message I obtain in my output: ipa: INFO: Forwarding 'migrate_ds' to server *u*'http://freeipa01.unix.__mydomain.it/ipa/xml http://mydomain.it/ipa/xml http://freeipa01.unix.mydomain.it/ipa/xml' Please open tickets for both issues. Well, I don't think either is a bug. If you have users/groups in multiple places you'll need to migrate them individually for now. It is safe to run migrate-ds multiple times, existing users are not migrated. I just re-executed by specifing a nested ou for my groups. This is what I got: ipa: INFO: trying https://freeipa01.unix.csebo.it/ipa/xml ipa: INFO: Forwarding 'migrate_ds' to server u'http://freeipa01.unix.csebo.it/ipa/xml' --- migrate-ds: --- Migrated: Failed user: fw03075_no: Type or value exists: [other users listed] Failed group:
Re: [Freeipa-users] (no subject)
When I try to export the db I get this: /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif Exported ldif file: /dbexport/ipaca-output.ldif [03/Mar/2012:17:27:25 +] - ERROR: Could not find backend 'ipaca' When I start IPA as it is now these are the logs I get: debug- http://fpaste.org/ItuZ/ catalina.out- http://fpaste.org/tSyQ/ -Jimmy On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittenden rcrit...@redhat.com wrote: Jimmy wrote: This is all I see in the /var/log/httpd/error_log file. This issue has become critical. The server has been down a week and I have no idea why certmonger broke and don't seem to have any indication of how to fix it. What would be the best route besides chasing down this certmonger issue? Could I export all of my configuration/users/etc, install a completely new IPA and import my config? [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: host/csp-idm.pdh@pdh.csp: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u'ldap/csp-idm.pdh@pdh.csp', add=True): C ertificateOperationError I think your CA is still not up and running. Things to check: /var/log/pki-ca/catalina.out to be see if there are start up errors. The debug log in the same directory may contain information as well. If you are seeing a bunch of error 32's it means your db is still corrupted. The output of ipa-getcert list. This will tell you what certmonger thinks is wrong. Did you repair the ipaca backend in PKI-IPA? It is different than userRoot. rob On Fri, Mar 16, 2012 at 5:30 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: I actually shut down IPA to do the export and restarted after I imported. certutil -L -d /etc/httpd/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert u,u,u ABC.XYZIPA CA CT,C,C ipaCert u,u,u Signing-Cert u,u,u certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt certutil: certificate is valid How's that look? That's what it's supposed to look like. Is Apache logging a failure or maybe that is coming from dogtag through Apache... rob On Fri, Mar 16, 2012 at 4:34 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: ipa-getcert list shows some ugly output - http://fpaste.org/bV2v/ Looks pretty similar to what we've been seeing. The invalid credentials means that dogtag can't validate RA agent cert. This was due to the corrupted database. You'll need to restart the pki-cad process once the LDAP backend is fixed. The trust issues are stranger. To show the certs in those databases: # certutil -L -d /etc/httpd/alias To verify that the cert in there now has all the CA certs it needs: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias -e -f /etc/httpd/alias/pwdfile.txt rob On Fri, Mar 16, 2012 at 4:05 PM, Jimmyg17ji...@gmail.com wrote: I exported/imported the /var/lib/dirsrv/slapd-PKI-IPA/db/userRoot and that went smoothly but now I see this in /var/log/pki-ca/system: 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null response control 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Operation Error - netscape.ldap.LDAPException: error result (32); matchedDN = o=ipaca 10358.CertStatusUpdateThread - [08/Mar/2012:04:36:29 UTC] [5] [3] Null
[Freeipa-users] Error during ipa-replica-install
Hi guys, I'm running this version of FreeIPA: [root@freeipa03 ~]# rpm -qa|grep freeipa freeipa-server-selinux-2.1.90.rc1-0.fc16.x86_64 freeipa-server-2.1.90.rc1-0.fc16.x86_64 freeipa-admintools-2.1.90.rc1-0.fc16.x86_64 freeipa-client-2.1.90.rc1-0.fc16.x86_64 freeipa-python-2.1.90.rc1-0.fc16.x86_64 I'm having this problem: [root@freeipa03 ~]# ipa-replica-install --setup-dns --no-forwarders /var/lib/ipa/replica-info-freeipa03.unix.mydomain.it.gpg Directory Manager (existing master) password: Run connection check to master Check connection from replica to remote master 'freeipa01.unix.mydomain.it': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master ad...@unix.mydomain.it password: Cannot acquire Kerberos ticket: kinit: Invalid message type while getting initial credentials Connection check failed! Please fix your network settings according to error messages above. If the check results are not valid it can be skipped with --skip-conncheck parameter. --- I don't have any firewall between freeipa03 and freeipa01. This is what I have in my /var/log/messages file: Mar 20 12:03:51 freeipa03 sssd: Starting up Mar 20 12:03:51 freeipa03 sssd[be[unix.mydomain.it]]: Starting up Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: 0.fedora.pool.ntp.org Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: 1.fedora.pool.ntp.org Mar 20 12:03:52 freeipa03 ntpd_intres[773]: host name not found: 2.fedora.pool.ntp.org Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully called chroot(). Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Successfully dropped remaining capabilities. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service file /services/ssh.service. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Loading service file /services/udisks.service. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Network interface enumeration completed. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Registering HINFO record with values 'X86_64'/'LINUX'. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Server startup complete. Host name is freeipa03.local. Local service cookie is 3668475942. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service freeipa03 (/services/udisks.service) successfully established. Mar 20 12:03:52 freeipa03 avahi-daemon[734]: Service freeipa03 (/services/ssh.service) successfully established. Mar 20 12:03:52 freeipa03 systemd-logind[764]: New seat seat0. Mar 20 12:03:53 freeipa03 sssd[pam]: Starting up Mar 20 12:03:53 freeipa03 sssd[nss]: Starting up Mar 20 12:03:53 freeipa03 network[765]: Bringing up loopback interface: [ OK ] Mar 20 12:03:54 freeipa03 kernel: [ 25.724015] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None Mar 20 12:03:55 freeipa03 avahi-daemon[734]: Registering new address record for fe80::20c:29ff:fedc:9788 on eth0.*. Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.146.134. Mar 20 12:03:56 freeipa03 avahi-daemon[734]: New relevant interface eth0.IPv4 for mDNS. Mar 20 12:03:56 freeipa03 avahi-daemon[734]: Registering new address record for 192.168.146.134 on eth0.IPv4. Mar 20 12:03:56 freeipa03 network[765]: Bringing up interface eth0: [ OK ] Mar 20 12:03:57 freeipa03 kernel: [ 28.697268] 8021q: 802.1Q VLAN Support v1.8 Mar 20 12:03:57 freeipa03 kernel: [ 28.697283] 8021q: adding VLAN 0 to HW filter on device eth0 Mar 20 12:03:57 freeipa03 rpc.statd[994]: Version 1.2.5 starting Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 4 eth0 192.168.146.134 UDP 123 Mar 20 12:03:57 freeipa03 ntpd[741]: Listen normally on 5 eth0 fe80::20c:29ff:fedc:9788 UDP 123 Mar 20 12:03:57 freeipa03 ntpd[741]: peers refreshed Mar 20 12:03:57 freeipa03 sm-notify[995]: Version 1.2.5 starting Mar 20 12:03:58 freeipa03 systemd[1]: PID file /run/sendmail.pid not readable (yet?) after start. Mar 20 12:04:04 freeipa03 ntpd_intres[773]: host name not found: 0.fedora.pool.ntp.org Mar 20 12:04:07 freeipa03 systemd[1]: PID file /var/run/krb5kdc.pid not readable (yet?) after start. Mar 20 12:04:09 freeipa03 ntpd_intres[773]: host name not found: 1.fedora.pool.ntp.org Mar 20 12:04:10 freeipa03 named[1113]: starting BIND 9.8.2rc2-RedHat-9.8.2-0.4.rc2.fc16 -u named Mar 20 12:04:10 freeipa03 named[1113]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
Re: [Freeipa-users] groups migration problem
Maciej Sawicki wrote: Hi, I haven't manage to migrate ldap groups (in free ipa panel I see that users are migrated) #ipa migrate-ds ldap://192.168.1.125:389 --bind-dn=cn=admin,dc=polidea,dc=pl --group-container='ou=groups,dc=polidea,dc=pl' #ipa: ERROR: Container for group not found My old ldap setup: https://skitch.com/viroos/8miq5/ldap-ou-groups-dc-polidea-dc-pl-lem-apache-directory-studio. The basedn is automatically appended. Try --group-container=ou=groups regards rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
Here are the http logs: http://fpaste.org/j7kN/ On Tue, Mar 20, 2012 at 3:16 PM, Jimmy g17ji...@gmail.com wrote: I was able to do this: /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif /usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db -n ipaca -i /dbexport/ipaca-output.ldif The cert still doesn't seem to be renewing, though. Here is the debug and catalina.out. http://fpaste.org/k0Lz/ http://fpaste.org/UUnE/ ipa-getcert list shows this for a couple certs in question: Request ID '20110913154314': status: MONITORING ca-error: Error setting up ccache for local host service using default keytab. stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ABC.XYZ subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ expires: 2012-03-11 15:43:13 UTC eku: id-kp-serverAuth command: track: yes auto-renew: yes Request ID '20110913154337': status: MONITORING ca-error: Error setting up ccache for local host service using default keytab. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ABC.XYZ subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ expires: 2012-03-11 15:43:37 UTC eku: id-kp-serverAuth command: track: yes auto-renew: yes On Tue, Mar 20, 2012 at 1:41 PM, Rob Crittenden rcrit...@redhat.com wrote: Jimmy wrote: When I try to export the db I get this: /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif Exported ldif file: /dbexport/ipaca-output.ldif [03/Mar/2012:17:27:25 +] - ERROR: Could not find backend 'ipaca'] The CA uses a different instance of 389-ds. You need to run the scripts specific to that instance. dogtag sets things up slightly differently, you want something like: /usr/lib/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif When I start IPA as it is now these are the logs I get: debug- http://fpaste.org/ItuZ/ catalina.out- http://fpaste.org/tSyQ/ Yes, as I suspected it isn't finding any of its data which is why the certificate renewal is failing. rob -Jimmy On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: This is all I see in the /var/log/httpd/error_log file. This issue has become critical. The server has been down a week and I have no idea why certmonger broke and don't seem to have any indication of how to fix it. What would be the best route besides chasing down this certmonger issue? Could I export all of my configuration/users/etc, install a completely new IPA and import my config? [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: host/csp-idm.pdh@pdh.csp: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u'ldap/csp-idm.pdh@pdh.csp', add=True): C ertificateOperationError I think your CA is still not up and running. Things to check: /var/log/pki-ca/catalina.out to be see if there are start up errors. The debug log in the same directory may contain information as well. If you are seeing a bunch of error 32's it means your db is still corrupted. The output of ipa-getcert list.
Re: [Freeipa-users] (no subject)
ipa cert-show 1== Certificate: MIIDhTCCAm2gAwIBAgIBATANBgkqhkiG9w0BAQsFADAyMRAwDgYDVQQKEwdQREgu Q1NQMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTEwOTEzMTU0 MTE4WhcNMTkwOTEzMTU0MTE4WjAyMRAwDgYDVQQKEwdQREguQ1NQMR4wHAYDVQQD ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDRPzyFQbAIgnNLGZQRoMVuHGLIBqANVpJOXiE28PlwVczQ5F14FE5e d2QZ6CYtY/1RpWph/SaUHqRKW2C2NTlx3Rw6q+aaLzFqqSp4cC9vNwfURT32xn64 wSuHsVPakBp6xDF5QfJTgxXEcO/eJt9KiyIDtOEmk3TBzmalNtVejNe33OfwBx6s LmVKjH49wUuUGQBvk6/di5vhQ8soquWMRKdZFsTBfepp4BSvscweY0nNk7+iMOEE ESt0JOhvrQOzEeopqVf7GcDKLEhCC4BRwuGZ6GzWl3w9OiiriH8aLdEGeLuBjYq1 wa/z6pCah4dNmAmV/nf5xocH84DdxRJJAgMBAAGjgaUwgaIwHwYDVR0jBBgwFoAU PiI4ye3VbGZeR6iy37xgdCLgUNcwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E BAMCAcYwHQYDVR0OBBYEFD4iOMnt1WxmXkeost+8YHQi4FDXMD8GCCsGAQUFBwEB BDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NzcC1pZG0ucGRoLmNzcDo5MTgwL2Nh L29jc3AwDQYJKoZIhvcNAQELBQADggEBALsg/ivFOv4VmydSZ2q93TwQUtV49Gp+ AJcrCu8aVpd2q9LX2yNxq2EXSZq4+/Afml6zGCSMZ6w/EV2dpwHo4BrVg5HAIWe9 k6zekjDhVGVYRtO09B8PTWoRvt5lgQf4zMoiaVwS8+uE8CWF3Y24CqnAeW4z9vFr EmCkVEp69xaLfbTBLt1bzyIxIlq4mgb8oE8NDVr2Qo3cdwT4qGNPLEHvb9vCwySN R3BNarw+LB0GB5g5XkEIXPmgKmxoJuQ3nW578bPxXRvUJ19Yg2/WObAyrfoVL/sc iEJDnJKWtV/kcN68LhOIkC77w41RII43YxJFQva9NQVY4uT1CApNcPk= Subject: CN=Certificate Authority,O=ABC.XYZ Issuer: CN=Certificate Authority,O=ABC.XYZ Not Before: Tue Sep 13 15:41:18 2011 UTC Not After: Fri Sep 13 15:41:18 2019 UTC Fingerprint (MD5): 05:d4:89:49:6b:03:0e:9b:06:14:a0:0a:e2:32:dc:e1 Fingerprint (SHA1): c4:b7:9f:07:df:5a:9e:36:a6:c3:f4:18:c7:77:1a:29:86:30:41:4f Serial number: 1 kvno host/xyz-ipa.abc.xyz -k /etc/krb5.keytab host/xyz-ipa.abc@abc.xyz: kvno = 2, keytab entry valid I can do a kinit as the host principal with the keytab /etc/krb5.keytab ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
On 03/20/2012 01:16 PM, Jimmy wrote: I was able to do this: /usr/lib64/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif /usr/lib64/dirsrv/slapd-PKI-IPA/ldif2db -n ipaca -i /dbexport/ipaca-output.ldif ok - let's make sure this step worked - any errors in /var/log/dirsrv/slapd-PKI-IPA/errors? The cert still doesn't seem to be renewing, though. Here is the debug and catalina.out. What about /var/log/dirsrv/slapd-PKI-IPA/access? http://fpaste.org/k0Lz/ http://fpaste.org/UUnE/ ipa-getcert list shows this for a couple certs in question: Request ID '20110913154314': status: MONITORING ca-error: Error setting up ccache for local host service using default keytab. stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PKI-IPA//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-PKI-IPA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ABC.XYZ subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ expires: 2012-03-11 15:43:13 UTC eku: id-kp-serverAuth command: track: yes auto-renew: yes Request ID '20110913154337': status: MONITORING ca-error: Error setting up ccache for local host service using default keytab. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=ABC.XYZ subject: CN=xyz-ipa.abc.xyz,O=ABC.XYZ expires: 2012-03-11 15:43:37 UTC eku: id-kp-serverAuth command: track: yes auto-renew: yes On Tue, Mar 20, 2012 at 1:41 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: When I try to export the db I get this: /var/lib/dirsrv/scripts-ABC-XYZ/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif Exported ldif file: /dbexport/ipaca-output.ldif [03/Mar/2012:17:27:25 +] - ERROR: Could not find backend 'ipaca'] The CA uses a different instance of 389-ds. You need to run the scripts specific to that instance. dogtag sets things up slightly differently, you want something like: /usr/lib/dirsrv/slapd-PKI-IPA/db2ldif -n ipaca -a /dbexport/ipaca-output.ldif When I start IPA as it is now these are the logs I get: debug- http://fpaste.org/ItuZ/ catalina.out- http://fpaste.org/tSyQ/ Yes, as I suspected it isn't finding any of its data which is why the certificate renewal is failing. rob -Jimmy On Mon, Mar 19, 2012 at 4:58 PM, Rob Crittendenrcrit...@redhat.com wrote: Jimmy wrote: This is all I see in the /var/log/httpd/error_log file. This issue has become critical. The server has been down a week and I have no idea why certmonger broke and don't seem to have any indication of how to fix it. What would be the best route besides chasing down this certmonger issue? Could I export all of my configuration/users/etc, install a completely new IPA and import my config? [Sat Mar 03 00:05:27 2012] [error] ipa: INFO: sslget 'https://csp-idm.pdh.csp:443/ca/agent/ca/displayBySerial' [Sat Mar 03 00:05:28 2012] [error] ipa: INFO: host/csp-idm.pdh@pdh.csp: cert_request(u'MIIDQzCCAisCAQAwLDEQMA4GA1UEChMHUERILkNTUDEYMBYGA1 UEAxMPY3NwLWlkbS5wZGguY3NwMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAr0EHCdyTuteryFZ2bdEl+V4OATR/xk8ELthmvlwT/5qubZKwlCWS6yLawgdyCg9Yw737A7q Ge0BPxHv6E+as10NxppEPsn9BOi+TPRIMYNMNNYmO2sce2pvkMkVBqsF7Gn7mF7e5+Bpc7ApnDGP7WLsAjbso8EvLUrqVMTNyiziCSHiNk+/Fi1Om6K5GKzKkqfEDex0RK+kpMswgcaZH hmW3i+y3UxFZsJjOg3R4fJAfC0+My2d1Vx4052+EgWAbSNpSj7zmLGM2+dkmgMo5Li7jjgJe8VsrqOV4L5IgqtGVJ0EOb7EP7gynbVoa74m4XrVwEP8rd/M5RxAnD1JPuwIDAQABoIHRM BoGCSqGSIb3DQEJFDENEwtTZXJ2ZXItQ2VydDCBsgYJKoZIhvcNAQkOMYGkMIGhMA4GA1UdDwEBAAQEAwIE8DB3BgNVHREBAQAEbTBroCwGCisGAQQBgjcUAgOgHgwcbGRhcC9jc3AtaW RtLnBkaC5jc3BAUERILkNTUKA7BgYrBgEFAgKgMTAvoAkbB1BESC5DU1ChIjAgoAMCAQGhGTAXGwRsZGFwGw9jc3AtaWRtLnBkaC5jc3AwFgYDVR0lAQEABAwwCgYIKwYBBQUHAwEwDQY JKoZIhvcNAQELBQADggEBABD/Hwbgf5NJNUYt0+ntMDHiilMFkSaO6ryQ36/pCH1oR+vI+PCeClHewPo0v99h4Z8W8L7CQtDdNBUMl/JVHH5Lz7cBF8A/jXZQ+naV17EEuXncacM8AvYh 5dL2yih+8RpPalEmSgz5rijtbSigfNGrZn0Mh3qOW1kbsz+GDaaT9wLFxvdJyqgdKds2tsp0KzHIMcJuw3cwOfH8zrBRV28XYhMLm0OOhj92uxgax5UPY2VyHP5UOtOnfuduU1ZXa+o8Q IXqX7/HyDSCLGwiPJscAsp9cRzjn4KvqzZDOcdGEjXmCGfrmUiMcuzVyTDR2SdAWrHdbRmXeyVxmiBPzdk=', principal=u'ldap/csp-idm.pdh@pdh.csp', add=True): C ertificateOperationError I think your CA is still not up and running. Things to check: /var/log/pki-ca/catalina.out to be see if there are start up errors. The debug log in the same directory may contain information as well. If you are seeing a bunch of error 32's it means your db is still corrupted. The output of ipa-getcert list.
Re: [Freeipa-users] (no subject)
Jimmy wrote: ipa cert-show 1== Certificate: MIIDhTCCAm2gAwIBAgIBATANBgkqhkiG9w0BAQsFADAyMRAwDgYDVQQKEwdQREgu Q1NQMR4wHAYDVQQDExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwHhcNMTEwOTEzMTU0 MTE4WhcNMTkwOTEzMTU0MTE4WjAyMRAwDgYDVQQKEwdQREguQ1NQMR4wHAYDVQQD ExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDRPzyFQbAIgnNLGZQRoMVuHGLIBqANVpJOXiE28PlwVczQ5F14FE5e d2QZ6CYtY/1RpWph/SaUHqRKW2C2NTlx3Rw6q+aaLzFqqSp4cC9vNwfURT32xn64 wSuHsVPakBp6xDF5QfJTgxXEcO/eJt9KiyIDtOEmk3TBzmalNtVejNe33OfwBx6s LmVKjH49wUuUGQBvk6/di5vhQ8soquWMRKdZFsTBfepp4BSvscweY0nNk7+iMOEE ESt0JOhvrQOzEeopqVf7GcDKLEhCC4BRwuGZ6GzWl3w9OiiriH8aLdEGeLuBjYq1 wa/z6pCah4dNmAmV/nf5xocH84DdxRJJAgMBAAGjgaUwgaIwHwYDVR0jBBgwFoAU PiI4ye3VbGZeR6iy37xgdCLgUNcwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8E BAMCAcYwHQYDVR0OBBYEFD4iOMnt1WxmXkeost+8YHQi4FDXMD8GCCsGAQUFBwEB BDMwMTAvBggrBgEFBQcwAYYjaHR0cDovL2NzcC1pZG0ucGRoLmNzcDo5MTgwL2Nh L29jc3AwDQYJKoZIhvcNAQELBQADggEBALsg/ivFOv4VmydSZ2q93TwQUtV49Gp+ AJcrCu8aVpd2q9LX2yNxq2EXSZq4+/Afml6zGCSMZ6w/EV2dpwHo4BrVg5HAIWe9 k6zekjDhVGVYRtO09B8PTWoRvt5lgQf4zMoiaVwS8+uE8CWF3Y24CqnAeW4z9vFr EmCkVEp69xaLfbTBLt1bzyIxIlq4mgb8oE8NDVr2Qo3cdwT4qGNPLEHvb9vCwySN R3BNarw+LB0GB5g5XkEIXPmgKmxoJuQ3nW578bPxXRvUJ19Yg2/WObAyrfoVL/sc iEJDnJKWtV/kcN68LhOIkC77w41RII43YxJFQva9NQVY4uT1CApNcPk= Subject: CN=Certificate Authority,O=ABC.XYZ Issuer: CN=Certificate Authority,O=ABC.XYZ Not Before: Tue Sep 13 15:41:18 2011 UTC Not After: Fri Sep 13 15:41:18 2019 UTC Fingerprint (MD5): 05:d4:89:49:6b:03:0e:9b:06:14:a0:0a:e2:32:dc:e1 Fingerprint (SHA1): c4:b7:9f:07:df:5a:9e:36:a6:c3:f4:18:c7:77:1a:29:86:30:41:4f Serial number: 1 kvno host/xyz-ipa.abc.xyz -k /etc/krb5.keytab host/xyz-ipa.abc@abc.xyz: kvno = 2, keytab entry valid I can do a kinit as the host principal with the keytab /etc/krb5.keytab Can you make sure the system hostname is right? Check the output of /bin/hostname, /etc/hosts and DNS. You might try restarting the certmonger service. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
I restarted certmonger and it seems to be working. Is there some way to change the renewal interval so we can simulate this in the lab? I'd like to see it go through a number of renewals to make sure we don't keep having this problem. ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
On Tue, Mar 20, 2012 at 04:10:19PM -0400, Jimmy wrote: I restarted certmonger and it seems to be working. Is there some way to change the renewal interval so we can simulate this in the lab? I'd like to see it go through a number of renewals to make sure we don't keep having this problem. Attempts to re-enroll are triggered as the not-valid-after date approaches and you cross a threshold time-left value. The default (2419200, 604800, 259200, 172800, 86400, which works out to 28, 7, 3, 2, and 1 day, when you convert from seconds to days) can be modified by setting the ttls value in the [defaults] section of /etc/certmonger/certmonger.conf. To avoid going nuts, the daemon will actually hold off on certificates with a not-before value that's not at least an hour in the past, so adding a really high ttls value (say, longer than the certificate's entire validity period) should force frequent re-enrollments, though I haven't done this myself. HTH, Nalin ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
Jimmy wrote: I restarted certmonger and it seems to be working. Is there some way to change the renewal interval so we can simulate this in the lab? I'd like to see it go through a number of renewals to make sure we don't keep having this problem. Glad you are up and running again. You can control the interval by tuning knobs in certmonger.conf(5). You want to modify ttls. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] (no subject)
Cool thanks for the awesome help, y'all. On Tue, Mar 20, 2012 at 5:20 PM, Rob Crittenden rcrit...@redhat.com wrote: Jimmy wrote: I restarted certmonger and it seems to be working. Is there some way to change the renewal interval so we can simulate this in the lab? I'd like to see it go through a number of renewals to make sure we don't keep having this problem. Glad you are up and running again. You can control the interval by tuning knobs in certmonger.conf(5). You want to modify ttls. rob ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
