Re: [Freeipa-users] hesitate to deploy freeipa
Am 25.06.2015 um 17:47 schrieb Simo Sorce: Yes, the whole project is complex, but not because we like complexity, it is complex because the problem space is complex and we are bound to use existing protocols, which sometimes add in complexity, and we want to offer useful features to admins, so they can think about managing stuff and not about the plumbing all the time. Sure, the problem space is a lot more complex than say ls. But I think there is room for improvement, by making the individual tools somewhat more resilient to unexpected behaviour in other components. For example, if there's any nsuniqueid group present in a users entry, login authentication via sssd breaks with a cryptic error message. It would be nice, IMO, if it didn't break or if it at least issued a better error message. Furthermore, a good graphical generic LDAP editor would make the admin's life significantly easier, IMO. I so far haven't found one. There's gq, which works, mostly, but crashes relatively frequently. I'm mostly using ldapvi now, which works quite well but only after studying its manual. Thomas -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
On 06/04/2015 04:33 PM, Rob Crittenden wrote:
Thomas Sailer wrote:
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.
This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0x...
An entry with nsuniqueid is a replication conflict entry. You want to
resolve this.
See
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html
Yes I know, and I have already fixed that.
The question is is it justified if the presence of such a group breaks
login. If yes, shouldn't there be a more obvious error message than ssh
telling you that login failed for UNKNOWN reasons...
If login would still work, it would buy you time for fixing the problem.
The way it is now, you have people filling your office complaining login
doesn't work anymore while you frantically try to figure out why.
My biggest wish for IPA is for it to become more robust. It consists of
many software components with complex interdependencies, so some
fragility is to be expected. But still, it would be nice if it was as
robust as possible and if it fails that it fails in more obvious ways...
2) I cannot change ssh keys, neither in the web gui nor on the cli.
# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xserver.x.com/ipa/json
ipa: INFO: Request: {
id: 0,
method: ping,
params: [
[],
{}
]
}
ipa: INFO: Response: {
error: null,
id: 0,
principal: ad...@x.com,
result: {
messages: [
{
code: 13001,
message: API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114,
name: VersionMissing,
type: warning
}
],
summary: IPA server version 4.1.4. API version 2.114
},
version: 4.1.4
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xserver.x.com/ipa/json'
ipa: INFO: Request: {
id: 0,
method: user_mod,
params: [
[
t.sailer
],
{
all: true,
ipasshpubkey: null,
no_members: false,
random: false,
raw: false,
rights: false,
version: 2.114
}
]
}
ipa: INFO: Response: {
error: {
code: 4203,
message: Type or value exists: ,
name: DatabaseError
},
id: 0,
principal: ad...@x.com,
result: null,
version: 4.1.4
}
ipa: ERROR: Type or value exists:
I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...
Hmm, curious. What is the current state of the entry? The 389-ds
access log might have more details (though I'm stretching here).
[04/Jun/2015:17:43:21 +0200] conn=3391 fd=70 slot=70 connection from
a.b.c.d to a.b.c.d
[04/Jun/2015:17:43:21 +0200] conn=3391 op=0 BIND dn= method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=1 BIND dn= method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=0 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[04/Jun/2015:17:43:21 +0200] conn=3391 op=1 RESULT err=14 tag=97
nentries=0 etime=0, SASL bind in progress
[04/Jun/2015:17:43:21 +0200] conn=3391 op=2 BIND dn= method=sasl
version=3 mech=GSSAPI
[04/Jun/2015:17:43:21 +0200] conn=3391 op=2 RESULT err=0 tag=97
nentries=0 etime=0 dn=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com
[04/Jun/2015:17:43:21 +0200] conn=3391 op=3 SRCH
base=cn=ipaconfig,cn=etc,dc=x,dc=com scope=0
filter=(objectClass=*) attrs=ALL
[04/Jun/2015:17:43:21 +0200] conn=3391 op=3 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=4 SRCH
base=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com scope=0
filter=(objectClass=*) attrs=objectClass
[04/Jun/2015:17:43:21 +0200] conn=3391 op=4 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=5 SRCH
base=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com scope=0
filter=(objectClass=*) attrs=objectClass ipaSshPubKey
[04/Jun/2015:17:43:21 +0200] conn=3391 op=5 RESULT err=0 tag=101
nentries=1 etime=0
[04/Jun/2015:17:43:21 +0200] conn=3391 op=6 MOD
dn=uid=t.sailer,cn=users,cn=accounts,dc=x,dc=com
[04/Jun/2015:17:43:22 +0200] conn=3391 op=6 RESULT err=20 tag=103
nentries=0 etime=1 csn
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
I have now managed to upgrade the replica as well.
I stumbled over a few additional problems:
1) whenever a user becomes member of a group with +nsuniqueid= in its
name, the user can no longer login. The reason is that ldb_dn_validate
doesn't like the + character, thus returns false, which causes
get_ipa_groupname to return EINVAL, which causes the loop in
hbac_eval_user_element to abort and return an error.
This seems to be quite draconian. Does it have to be like this? If so it
would be nice if a clearer error message would be left somewhere more
obvious than sssd -d 0x...
2) I cannot change ssh keys, neither in the web gui nor on the cli.
# ipa -vv user-mod myuserid --sshpubkey= --all
ipa: INFO: trying https://xserver.x.com/ipa/json
ipa: INFO: Request: {
id: 0,
method: ping,
params: [
[],
{}
]
}
ipa: INFO: Response: {
error: null,
id: 0,
principal: ad...@x.com,
result: {
messages: [
{
code: 13001,
message: API Version number was not sent, forward
compatibility not guaranteed. Assuming server's API version, 2.114,
name: VersionMissing,
type: warning
}
],
summary: IPA server version 4.1.4. API version 2.114
},
version: 4.1.4
}
ipa: INFO: Forwarding 'user_mod' to json server
'https://xserver.x.com/ipa/json'
ipa: INFO: Request: {
id: 0,
method: user_mod,
params: [
[
t.sailer
],
{
all: true,
ipasshpubkey: null,
no_members: false,
random: false,
raw: false,
rights: false,
version: 2.114
}
]
}
ipa: INFO: Response: {
error: {
code: 4203,
message: Type or value exists: ,
name: DatabaseError
},
id: 0,
principal: ad...@x.com,
result: null,
version: 4.1.4
}
ipa: ERROR: Type or value exists:
I cannot find any more information in /var/log/httpd/error_log. But I
can change the SSH keys directly talking to slapd...
3) Is
[global]
debug=True
in /etc/ipa/ipa.conf supposed to change /var/log/httpd/error_log output?
I cannot see any change...
Thomas
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
Martin, Rob, thanks for your answers! On 06/01/2015 09:52 AM, Martin Basti wrote: Could DS in chroot, cause the ipa-ldap-updater --upgrade cannot locate the DS socket? 2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request. I used fedup for the distro upgrade, so yes initially it ran in a chroot. However, the log excerpts were from a second run I manually initiated, after the machine rebooted after the update. I am pretty sure I ensured that enough of freeipa ran to successfully run ipa user-status and kinit. 2) Allow weak ciphers. can you check objectclass definitions in /etc/dirsrv/slapd-X-COM/schema # grep 'allowWeakCipher' * If you find more than on objectclass definition, please remove the old from the ldif files and restart DS. (Probably there will be old in 99user.ldif) I indeed had a file named 99user.ldif with a date from yesterday (even newer than 01core389.ldif). I removed this. Now ipa-ldap-updater --upgrade completes successfully, on one machine. On the other replica, /usr/sbin/ipa-upgradeconfig fails. There's something wrong with pki-tomcatd: access_log: a.b.c.d - - [01/Jun/2015:18:22:35 +0200] GET /ca/admin/ca/getStatus HTTP/1.1 500 2108 Jun 01 18:47:03 server2.x.com server[9651]: Jun 01, 2015 6:47:03 PM org.apache.catalina.core.ContainerBase backgroundProcess Jun 01 18:47:03 server2.x.com server[9651]: WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm@548d946f background process Jun 01 18:47:03 server2.x.com server[9651]: java.lang.NullPointerException Jun 01 18:47:03 server2.x.com server[9651]: at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:108) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1360) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1546) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1556) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1556) Jun 01 18:47:03 server2.x.com server[9651]: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1524) Jun 01 18:47:03 server2.x.com server[9651]: at java.lang.Thread.run(Thread.java:745) Apparently, I'm not the only one :) http://pastebin.com/CtsW0GAt -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches
Hello everyone. I upgraded a freeipa server from fedora 20 to fedora 22. It mostly worked ok, but there are a few issues: - pki-tomcat didn't start after the upgrade, and that in turn made ipa-upgradeconfig fail, because /var/lib/pki/pki-tomcat/conf/ca/CS.cfg had the wrong owner (root). - ipa-ldap-updater stumbles over two problems: - Pre schema upgrade failed - when trying to modify cn=encryption,cn=config, it stumbles over allowWeakCipher not allowed Does anyone know how to fix this? Is the pre schema upgrade failure spurious? what bits am I missing about the allowWeakCipher issue? Thomas 2015-05-28T13:04:55Z DEBUG [4/10]: starting directory server 2015-05-28T13:04:55Z DEBUG Starting external process 2015-05-28T13:04:55Z DEBUG args='/bin/systemctl' 'start' 'dirsrv@X-COM.service' 2015-05-28T13:04:55Z DEBUG Process finished, return code=0 2015-05-28T13:04:55Z DEBUG stdout= 2015-05-28T13:04:55Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:04:55Z DEBUG duration: 0 seconds 2015-05-28T13:04:55Z DEBUG [5/10]: preparing server upgrade 2015-05-28T13:05:36Z ERROR Pre schema upgrade failed with [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 128, in __pre_schema_upgrade ld = ldapupdate.LDAPUpdate(dm_password='', ldapi=True, live_run=self.live_run, plugins=True) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 220, in __init__ self.create_connection() File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 783, in create_connection dm_password=self.dm_password, pw_name=self.pw_name) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:36Z DEBUG duration: 40 seconds 2015-05-28T13:05:36Z DEBUG [6/10]: updating schema 2015-05-28T13:05:46Z DEBUG Traceback (most recent call last): File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 388, in start_creation run_step(full_msg, method) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 378, in run_step method() File /usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py, line 145, in __update_schema dm_password='', ldapi=True, live_run=self.live_run) or self.modified File /usr/lib/python2.7/site-packages/ipaserver/install/schemaupdate.py, line 112, in update_schema fqdn=installutils.get_fqdn()) File /usr/lib/python2.7/site-packages/ipaserver/install/ldapupdate.py, line 65, in connect conn.do_external_bind(pw_name) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1761, in do_external_bind self.conn.sasl_interactive_bind_s, timeout, None, auth_tokens) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1747, in __bind_with_wait self.__wait_for_connection(timeout) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1733, in __wait_for_connection wait_for_open_socket(lurl.hostport, timeout) File /usr/lib/python2.7/site-packages/ipapython/ipautil.py, line 1183, in wait_for_open_socket raise e error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [error] error: [Errno 2] No such file or directory 2015-05-28T13:05:46Z DEBUG [cleanup]: stopping directory server 2015-05-28T13:05:46Z DEBUG Starting external process 2015-05-28T13:05:46Z DEBUG args='/bin/systemctl' 'stop' 'dirsrv@X-COM.service' 2015-05-28T13:05:46Z DEBUG Process finished, return code=0 2015-05-28T13:05:46Z DEBUG stdout= 2015-05-28T13:05:46Z DEBUG stderr=Running in chroot, ignoring request. 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG [cleanup]: restoring configuration 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-05-28T13:05:46Z DEBUG duration: 0 seconds 2015-05-28T13:05:46Z DEBUG File /usr/lib/python2.7/site-packages/ipapython/admintool.py, line 171, in execute return_value = self.run() File /usr/lib/python2.7/site-packages/ipaserver/install/ipa_ldap_updater.py, line 144, in run
[Freeipa-users] replica installation issue
After being unable to rescue my old freeipa installation, I installed a new machine from scratch and imported the user data from the old installation (so I could get rid of the separate PKI dirserv, too). That worked fine. Then I prepared a replica, and installed the replica on the old machine (after first running ipa-server-install --uninstall). The installation completed without error message. The replica however has a few issues: - GSSAPI authentication to the directory service doesn't work: # ldapsearch -D cn=Directory Manager -W \* returns a few hundred records, however # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: ad...@.com Valid starting Expires Service principal 01/16/2014 14:14:51 01/17/2014 14:14:47 krbtgt/@.com 01/16/2014 14:14:54 01/17/2014 14:14:47 HTTP/replica.@.com 01/16/2014 14:15:22 01/17/2014 14:14:47 ldap/replica.@.com # ldapsearch -Y GSSAPI \* SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/localdom...@.com not found in Kerberos database) The localdomain apparently comes from /etc/hosts: 127.0.0.1 localhost.localdomain localhost localhost4 ::1 localhost6.localdomain6 localhost6 192.168.1.2 replica..com replica 192.168.1.3 master..com master I tried to comment out the first two entries, which made it want to use ldap/localh...@.com, which failed too. krb5.keytab looks the same on both the master and the replica, with the exception that the replica lacks the host key for the camellia*-cts-cmac cypher. - When I use the web server of the replica and click on Identity-Certificates, I get: IPA Error 4301: Certificate operation cannot be completed: Unable to communicate with CMS ([Errno 113] No route to host) This same operation on the master works. Is this supposed to be like this? - Is there a more up to date description of how to make a replica a master? The fedora15 documentation seems to have gathered some dust... Thanks, Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] replica installation issue
On 01/17/2014 01:12 PM, Petr Spacek wrote: On 17.1.2014 12:44, Thomas Sailer wrote: # ldapsearch -Y GSSAPI \* SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server krbtgt/localdom...@.com not found in Kerberos database) The LOCALDOMAIN part should equal to the REALM (after @). Is it the same and the difference came from your obfuscation or not? No it's not my obfuscation, it's really LOCALDOMAIN. It turned out that: /etc/openldap/ldap.conf contained: URI ldap://localhost instead of URI ldaps://replica..com See http://adam.younglogic.com/2013/03/iptables-rules-for-freeipa/ Urgh embarassing. Indeed, it turned out that I need to open port 8080 on the master (it is connected by the replica). Port 8080 doesn't feature on the list in the above blog post, so I posted a comment... Replicas will be equal if you install CA to all servers. Great to hear! Have a nice day! Thank you, and same to you! ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading freeipa server from f18 to f20
Here's the corresponding log (from another attempt, thus the differing timestamps) of the server slapd: [09/Jan/2014:12:19:35 +0100] conn=375 fd=73 slot=73 connection from a.b.c.d to e.f.g.h [09/Jan/2014:12:19:35 +0100] conn=375 op=0 EXT oid=1.3.6.1.4.1.1466.20037 name=startTLS [09/Jan/2014:12:19:35 +0100] conn=375 op=0 RESULT err=0 tag=120 nentries=0 etime=0 [09/Jan/2014:12:19:35 +0100] conn=375 SSL 256-bit AES [09/Jan/2014:12:19:35 +0100] conn=375 op=1 BIND dn=cn=Directory Manager method=128 version=3 [09/Jan/2014:12:19:35 +0100] conn=375 op=1 RESULT err=0 tag=97 nentries=0 etime=0 dn=cn=directory manager [09/Jan/2014:12:19:35 +0100] conn=375 op=2 SRCH base=cn=config,cn=ldbm database,cn=plugins,cn=config scope=0 filter=(objectClass=*) attrs=nsslapd-directory [09/Jan/2014:12:19:35 +0100] conn=375 op=2 RESULT err=0 tag=101 nentries=1 etime=0 [09/Jan/2014:12:19:35 +0100] conn=375 op=3 SRCH base=cn=schema scope=0 filter=(objectClass=*) attrs=attributeTypes objectClasses [09/Jan/2014:12:19:36 +0100] conn=375 op=3 RESULT err=0 tag=101 nentries=1 etime=1 [09/Jan/2014:12:19:36 +0100] conn=375 op=4 SRCH base=cn=replication,cn=etc,dc=axsem,dc=com scope=0 filter=(objectClass=*) attrs=ALL [09/Jan/2014:12:19:36 +0100] conn=375 op=4 RESULT err=0 tag=101 nentries=1 etime=0 [09/Jan/2014:12:19:36 +0100] conn=375 op=5 MOD dn=cn=replication,cn=etc,dc=,dc=com [09/Jan/2014:12:19:36 +0100] conn=375 op=5 RESULT err=0 tag=103 nentries=0 etime=0 csn=52ce86170004 [09/Jan/2014:12:19:36 +0100] conn=375 op=6 SRCH base=cn=replica,cn=dc\3D\2Cdc\3Dcom,cn=mapping tree,cn=config scope=0 filter=(objectClass=*) attrs=ALL [09/Jan/2014:12:19:36 +0100] conn=375 op=6 RESULT err=0 tag=101 nentries=1 etime=0 [09/Jan/2014:12:19:36 +0100] conn=375 op=7 ADD dn=cn=replication manager,cn=config [09/Jan/2014:12:19:36 +0100] conn=375 op=7 RESULT err=19 tag=105 nentries=0 etime=0 [09/Jan/2014:12:19:36 +0100] conn=375 op=8 UNBIND [09/Jan/2014:12:19:36 +0100] conn=375 op=8 fd=73 closed - U1 I don't have cn=replication manager,cn=config, should I? When I manually try to create this entry like this (ldapvi syntax), I get: add cn=replication manager,cn=config objectClass: inetorgperson objectClass: person objectClass: top cn: replication manager sn: RM userPassword: password passwordExpirationTime: 20380119031407Z ldap_add: Constraint violation (19) additional info: pre-hashed passwords are not valid Why is that? ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading freeipa server from f18 to f20
Hi Martin,
ipa config-mod --enable-migration=1
Thanks! I'm getting farther now.
It seems to manage setting up the main directory server, but fails
configuring the ca system.
Done configuring directory server (dirsrv).
Configuring certificate server (pki-tomcatd): Estimated time 3 minutes
30 seconds
[1/17]: creating certificate server user
[2/17]: configuring certificate server instance
ipa : CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpqX0Uul' returned non-zero exit status 1
2014-01-09T14:53:42Z DEBUG Starting external process
2014-01-09T14:53:42Z DEBUG args=/usr/sbin/pkispawn -s CA -f /tmp/tmpqX0Uul
2014-01-09T14:53:55Z DEBUG Process finished, return code=1
2014-01-09T14:53:55Z DEBUG stdout=Loading deployment configuration from
/tmp/tmp
qX0Uul.
Installing CA into /var/lib/pki/pki-tomcat.
Storing deployment configuration into
/etc/sysconfig/pki/tomcat/pki-tomcat/ca/de
ployment.cfg.
Installation failed.
2014-01-09T14:53:55Z DEBUG stderr=pkispawn: WARNING ... unable
to valid
ate security domain user/password through REST interface. Interface not
availabl
e
mmap: Invalid argument
mmap: Invalid argument
mmap: Invalid argument
pkispawn: ERROR... Exception from Java Configuration
Servlet: Failed
to obtain installation token from security domain:
java.lang.NullPointerException
2014-01-09T14:53:55Z CRITICAL failed to configure ca instance Command
'/usr/sbin/pkispawn -s CA -f /tmp/tmpqX0Uul' returned non-zero exit status 1
2014-01-09T14:53:55Z INFO File
/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py,
line 619, in run_script
return_value = main_function()
File /usr/sbin/ipa-replica-install, line 652, in main
(CA, cs) = cainstance.install_replica_ca(config, dogtag_master_ds_port)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
1809, in install_replica_ca
subject_base=config.subject_base)
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
625, in configure_instance
self.start_creation(runtime=210)
File /usr/lib/python2.7/site-packages/ipaserver/install/service.py,
line 358, in start_creation
method()
File
/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py, line
744, in __spawn_instance
raise RuntimeError('Configuration of CA failed')
2014-01-09T14:53:55Z INFO The ipa-replica-install command failed,
exception: RuntimeError: Configuration of CA failed
/var/log/pki/pki-tomcat/ca/system:
17875.localhost-startStop-1 - [09/Jan/2014:15:53:52 CET] [3] [3] Cannot
build CA chain. Error java.security.cert.CertificateException:
Certificate is not a PKCS #11 certificate
17875.localhost-startStop-1 - [09/Jan/2014:15:53:52 CET] [13] [3] authz
instance DirAclAuthz initialization failed and skipped, error=Property
internaldb.ldapconn.port missing value
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading freeipa server from f18 to f20
Trying to install the replica on a Fedora 18 machine gives me a slightly
more verbose error message:
Unexpected error - see /var/log/ipareplica-install.log for details:
DatabaseError: Constraint violation: pre-hashed passwords are not valid
arguments: entry=cn=replication manager,cn=config: [('objectclass',
['top', 'person']), ('userpassword', ['']), (u'cn', ['replication
manager']), ('sn', ['replication manager pseudo user'])]
This entry doesn't look wrong to me, the slapd log below seems to
indicate that adding this entry worked. Could someone give me a hint how
to fix this or where to look at?
Thanks,
Thomas
[08/Jan/2014:17:51:01 +0100] conn=2 op=0 BIND dn=cn=directory manager
method=128 version=3
[08/Jan/2014:17:51:01 +0100] conn=2 op=1 SRCH base=cn=config,cn=ldbm
database,cn=plugins,cn=config scope=0 filter=(objectClass=*)
attrs=nsslapd-directory
[08/Jan/2014:17:51:01 +0100] conn=2 op=1 RESULT err=0 tag=101 nentries=1
etime=0
[08/Jan/2014:17:51:01 +0100] conn=2 op=2 SRCH base=cn=schema scope=0
filter=(objectClass=*) attrs=attributeTypes objectClasses
[08/Jan/2014:17:51:01 +0100] conn=2 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn=cn=directory manager
[08/Jan/2014:17:51:01 +0100] conn=2 op=2 RESULT err=0 tag=101 nentries=1
etime=0
[08/Jan/2014:17:51:01 +0100] conn=2 op=3 SRCH
base=cn=replica,cn=dc\3D\2Cdc\3Dcom,cn=mapping tree,cn=config
scope=0 filter=(objectClass=*) attrs=ALL
[08/Jan/2014:17:51:01 +0100] conn=2 op=3 RESULT err=32 tag=101
nentries=0 etime=0
[08/Jan/2014:17:51:01 +0100] conn=2 op=4 ADD dn=cn=replication
manager,cn=config
[08/Jan/2014:17:51:01 +0100] conn=2 op=4 RESULT err=0 tag=105 nentries=0
etime=0
[08/Jan/2014:17:51:01 +0100] conn=2 op=5 SRCH
base=cn=replica,cn=dc\3D\2Cdc\3Dcom,cn=mapping tree,cn=config
scope=0 filter=(objectClass=*) attrs=ALL
[08/Jan/2014:17:51:01 +0100] conn=2 op=5 RESULT err=32 tag=101
nentries=0 etime=0
[08/Jan/2014:17:51:01 +0100] conn=2 op=6 ADD
dn=cn=replica,cn=dc\3D\2Cdc\3Dcom,cn=mapping tree,cn=config
[08/Jan/2014:17:51:02 +0100] conn=2 op=7 ADD dn=cn=changelog5,cn=config
[08/Jan/2014:17:51:02 +0100] conn=2 op=7 RESULT err=0 tag=105 nentries=0
etime=0
[08/Jan/2014:17:51:02 +0100] conn=2 op=6 RESULT err=0 tag=105 nentries=0
etime=1
[08/Jan/2014:17:51:02 +0100] conn=2 op=8 UNBIND
[08/Jan/2014:17:51:02 +0100] conn=2 op=8 fd=64 closed - U1
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrading freeipa server from f18 to f20
On 12/29/2013 03:49 PM, Simo Sorce wrote: Unfortunately you should have created the replica *before* the upgrade. Too bad fedup didn't refuse to update and created this mess... Have you tried downgrading all dogtag and tomcat packages to the fc18 ones ? After some trial and error, I downgraded the following RPMs: freeipa-admintools-3.1.5-1.fc18.x86_64 freeipa-client-3.1.5-1.fc18.x86_64 freeipa-python-3.1.5-1.fc18.x86_64 freeipa-server-3.1.5-1.fc18.x86_64 jss-4.2.6-28.fc18.x86_64 pki-ca-10.0.6-1.fc18.noarch pki-server-10.0.6-1.fc18.noarch pki-symkey-10.0.6-1.fc18.x86_64 pki-tools-10.0.6-1.fc18.x86_64 tomcatjss-7.0.0-5.fc18.noarch krb5-workstation-1.10.3-17.fc18 krb5-libs-1.10.3-17.fc18 krb5-server-ldap-1.10.3-17.fc18 krb5-pkinit-1.10.3-17.fc18 krb5-server-1.10.3-17.fc18 A file needed an ownership fix: chown pkiuser.pkiuser /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg Now I can prepare the replica without error. However, installing the replica fails: Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/34]: creating directory server user [2/34]: creating directory server instance [3/34]: adding default schema [4/34]: enabling memberof plugin [5/34]: enabling winsync plugin [6/34]: configuring replication version plugin [7/34]: enabling IPA enrollment plugin [8/34]: enabling ldapi [9/34]: configuring uniqueness plugin [10/34]: configuring uuid plugin [11/34]: configuring modrdn plugin [12/34]: configuring DNS plugin [13/34]: enabling entryUSN plugin [14/34]: configuring lockout plugin [15/34]: creating indices [16/34]: enabling referential integrity plugin [17/34]: configuring ssl for ds instance [18/34]: configuring certmap.conf [19/34]: configure autobind for root [20/34]: configure new location for managed entries [21/34]: configure dirsrv ccache [22/34]: enable SASL mapping fallback [23/34]: restarting directory server [24/34]: setting up initial replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Unexpected error - see /var/log/ipareplica-install.log for details: DatabaseError: Constraint violation: pre-hashed passwords are not valid The last few lines from the install log look like: 2014-01-07T13:48:06Z DEBUG wait_for_open_ports: localhost [389] timeout 120 2014-01-07T13:48:07Z DEBUG flushing ldap://server..com:389 from SchemaCache 2014-01-07T13:48:07Z DEBUG retrieving schema for SchemaCache url=ldap://server..com:389 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x3445560 2014-01-07T13:48:08Z DEBUG flushing ldaps://replica..com:636 from SchemaCache 2014-01-07T13:48:08Z DEBUG retrieving schema for SchemaCache url=ldaps://replica..com:636 conn=ldap.ldapobject.SimpleLDAPObject instance at 0x35c22d8 2014-01-07T13:48:09Z DEBUG File /usr/lib/python2.7/site-packages/ipaserver/install/installutils.py, line 622, in run_script return_value = main_function() File /sbin/ipa-replica-install, line 669, in main ds = install_replica_ds(config) File /sbin/ipa-replica-install, line 188, in install_replica_ds ca_file=config.dir + /ca.crt, File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line 360, in create_replica self.start_creation(runtime=60) File /usr/lib/python2.7/site-packages/ipaserver/install/service.py, line 364, in start_creation method() File /usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py, line 373, in __setup_replica r_bindpw=self.dm_password) File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py, line 938, in setup_replication self.repl_man_dn, self.repl_man_passwd) File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py, line 909, in basic_replication_setup self.add_replication_manager(conn, repldn, replpw) File /usr/lib/python2.7/site-packages/ipaserver/install/replication.py, line 362, in add_replication_manager conn.add_entry(ent) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 1527, in add_entry self.conn.add_s(dn, attrs.items()) File /usr/lib64/python2.7/contextlib.py, line 35, in __exit__ self.gen.throw(type, value, traceback) File /usr/lib/python2.7/site-packages/ipapython/ipaldap.py, line 928, in error_handler raise errors.DatabaseError(desc=desc, info=info) 2014-01-07T13:48:09Z DEBUG The ipa-replica-install command failed, exception: DatabaseError: Constraint violation: pre-hashed passwords are not valid Any hint on how to fix this? Thanks, Thomas ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Upgrading freeipa server from f18 to f20
I've updated the machine running freeipa from f18 to f20. Now I still have the old pki-base package (pki-base-10.0.6-1.fc18.noarch). Trying to upgrade it results in the following message: error: lua script failed: [string %pretrans(pki-base-10.1.0-1.fc20.noarch)]:22: Unable to upgrade to Fedora 20. There are Dogtag 9 instances that will no longer work since they require Tomcat 6, and Tomcat 6 is no longer available in Fedora 20. Please follow these instructions to migrate the instances to Dogtag 10: http://pki.fedoraproject.org/wiki/Migrating_Dogtag_9_Instances_to_Dogtag_10 Error in PRETRANS scriptlet in rpm package pki-base-10.1.0-1.fc20.noarch The above mentioned wiki page suggests that the easiest way to upgrade dogtag is by creating a replica. However, ipa-replica-prepare fails with: [Errno 2] No such file or directory: '/etc/pki/pki-tomcat/password.conf' There isn't even a directory named /etc/pki/pki-tomcat This server has separate dirserv instances for PKI and the rest. Does anyone have an idea how to do the dogtag upgrade? Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Certificates not renewed
I have a few certificates that fail to be updated, for example the ldap and http certificates. If I read the error message from getcert list (see below) correctly, then the contents of the pinfiles are incorrect. How do I fix this? Thanks, Tom Number of certificates and requests being tracked: 8. Request ID '2016140151': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)). stuck: yes key pair storage: type=NSSDB,location='/etc/dirsrv/slapd--COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd--COM//pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd--COM',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=.COM subject: CN=server..com,O=.COM expires: 2013-11-16 14:01:50 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2016140217': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)). stuck: yes 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=.COM subject: CN=server..com,O=.COM expires: 2013-11-16 14:02:17 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '2016140238': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: EXCEPTION (Invalid Credential.)). stuck: yes 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=.COM subject: CN=server..com,O=.COM expires: 2013-11-16 14:02:38 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130424090625': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='399557979284' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=.COM subject: CN=CA Audit,O=.COM expires: 2015-09-29 09:22:17 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert auditSigningCert cert-pki-ca track: yes auto-renew: yes Request ID '20130424090626': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='399557979284' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=.COM subject: CN=OCSP Subsystem,O=.COM expires: 2015-09-29 09:21:17 UTC eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert ocspSigningCert cert-pki-ca track: yes auto-renew: yes Request ID '20130424090627': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='399557979284' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=.COM subject: CN=CA Subsystem,O=.COM expires: 2015-09-29 09:21:17 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command:
Re: [Freeipa-users] Certificates not renewed
Hi Rob, thanks for the quick answer! Does this work? # ipa cert-show 1 I'm geussing it doesn't. You're correct, it doesn't. You are correct, the serial numbers didn't match. I've fixed this, now I get the following error: Request ID '2016140151': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Profile caIPAserviceCert Not Found)). Thanks, Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificates not renewed
I seem to be a victim of BZ 675742 I've fixed this, now I get the following error: Request ID '2016140151': status: CA_UNREACHABLE ca-error: Server failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: FAILURE (Profile caIPAserviceCert Not Found)). chown pkiuser.pkiuser /var/lib/pki-ca/profiles/ca/caIPAserviceCert.cfg and systemctl restart pki-cad@pki-ca.service has fixed it, all tracked certs are now in MONITORING state Thanks Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Certificates not renewed [SOLVED]
Great, thanks for the follow-up. I was a bit too soon. After sending the mail, I saw that the freeipa web GUI no longer worked. It turned out that I ended up with two certificates with the name Server-Cert in both the httpd and slapd certificate databases. It doesn't seem to be possible using certutil to selectively delete one of the two certificates, so I exported both, deleted both, and used an ASCII editor to extract the correct one and reimport it. After restarting httpd, the web gui now works again. Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Upgrade to 3.1.2: web UI no longer works
Hi, I've just upgraded from F16 to F18 and thus freeipa v3.1.2. It basically works, on the command line. ipa user-show xxx works. The Web UI however no longer works. I get the login window with Your session has expired. Please re-login., no matter whether I use kerberos or password login. The httpd logs don't seem to be very informative. /var/cache/ipa/sessions/ is empty. Could someone point me to where I could find more information to debug this problem? Thanks, Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works
Thanks, John! See the log below. The only thing that looks strange to me is expiration_timestamp=1970-01-01T01:00:00. Where does this time come from? Tom [Tue Feb 05 16:16:53.798117 2013] [:error] [pid 6843] ipa: INFO: *** PROCESS START *** [Tue Feb 05 16:16:53.914486 2013] [:error] [pid 6844] ipa: INFO: *** PROCESS START *** [Tue Feb 05 18:09:25.829937 2013] [:error] [pid 6843] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 18:09:25.830261 2013] [:error] [pid 6843] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Feb 05 18:09:25.830910 2013] [:error] [pid 6843] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 18:09:25.831823 2013] [:error] [pid 6843] ipa: DEBUG: no session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8, generating empty session data [Tue Feb 05 18:09:25.832551 2013] [:error] [pid 6843] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:25 access_timestamp=2013-02-05T18:09:25 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:25.833104 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:25 access_timestamp=2013-02-05T18:09:25 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:25.833325 2013] [:error] [pid 6843] ipa: DEBUG: no ccache, need login [Tue Feb 05 18:09:25.833472 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session: 401 Unauthorized need login [Tue Feb 05 18:09:26.265310 2013] [:error] [pid 6844] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 18:09:26.265601 2013] [:error] [pid 6844] ipa: DEBUG: WSGI login_kerberos.__call__: [Tue Feb 05 18:09:26.266719 2013] [:error] [pid 6844] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 18:09:26.268036 2013] [:error] [pid 6844] ipa: DEBUG: no session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8, generating empty session data [Tue Feb 05 18:09:26.268517 2013] [:error] [pid 6844] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:26.269176 2013] [:error] [pid 6844] ipa: DEBUG: finalize_kerberos_acquisition: login_kerberos ccache_name=FILE:/run/httpd/krbcache/krb5cc_apache_MxFRBf session_id=bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 18:09:26.269420 2013] [:error] [pid 6844] ipa: DEBUG: reading ccache data from file /run/httpd/krbcache/krb5cc_apache_MxFRBf [Tue Feb 05 18:09:26.271728 2013] [:error] [pid 6844] ipa: DEBUG: get_credential_times: principal=krbtgt/@.com, authtime=02/05/13 14:28:55, starttime=02/05/13 18:09:26, endtime=02/06/13 14:25:28, renew_till=01/01/70 01:00:00 [Tue Feb 05 18:09:26.272044 2013] [:error] [pid 6844] ipa: DEBUG: KRB5_CCache FILE:/run/httpd/krbcache/krb5cc_apache_MxFRBf endtime=1360157128 (02/06/13 14:25:28) [Tue Feb 05 18:09:26.272554 2013] [:error] [pid 6844] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1360156828 expiration=1360085366.27 (2013-02-05T18:29:26) [Tue Feb 05 18:09:26.272877 2013] [:error] [pid 6844] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=2013-02-05T18:29:26 [Tue Feb 05 18:09:26.273477 2013] [:error] [pid 6844] ipa: DEBUG: release_ipa_ccache: KRB5CCNAME environment variable not set [Tue Feb 05 18:09:26.296615 2013] [:error] [pid 6843] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Tue Feb 05 18:09:26.297201 2013] [:error] [pid 6843] ipa: DEBUG: WSGI jsonserver_session.__call__: [Tue Feb 05 18:09:26.298296 2013] [:error] [pid 6843] ipa: DEBUG: found session cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8 [Tue Feb 05 18:09:26.298995 2013] [:error] [pid 6843] ipa: DEBUG: no session data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8, generating empty session data [Tue Feb 05 18:09:26.299561 2013] [:error] [pid 6843] ipa: DEBUG: store session: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:26.300515 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8 start_timestamp=2013-02-05T18:09:26 access_timestamp=2013-02-05T18:09:26 expiration_timestamp=1970-01-01T01:00:00 [Tue Feb 05 18:09:26.300903 2013] [:error] [pid 6843] ipa: DEBUG: no ccache, need login [Tue Feb 05 18:09:26.301258 2013] [:error] [pid 6843] ipa: DEBUG: jsonserver_session: 401 Unauthorized need login ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works
On 02/05/2013 06:32 PM, John Dennis wrote:
% ipactl status
# ipactl status
Directory Service: RUNNING
krb5kdc Service: RUNNING
kadmin Service: RUNNING
named Service: RUNNING
httpd Service: RUNNING
pki-cad Service: RUNNING
ipa: INFO: The ipactl command was successful
Apparently, it isn't...
I've started it using:
# systemctl restart ipa_memcached.service
# systemctl enable ipa_memcached.service
But still, it's not listed with ipactl status (systemctl says it started
successfully)
Now I'm getting IPA Error 903.
Thanks,
Tom
[Tue Feb 05 19:38:27.394919 2013] [:error] [pid 7520] ipa: INFO: *** PROCESS
START ***
[Tue Feb 05 19:38:27.410930 2013] [:error] [pid 7519] ipa: INFO: *** PROCESS
START ***
[Tue Feb 05 19:38:55.828540 2013] [:error] [pid 7520] ipa: DEBUG: WSGI
wsgi_dispatch.__call__:
[Tue Feb 05 19:38:55.829826 2013] [:error] [pid 7520] ipa: DEBUG: WSGI
jsonserver_session.__call__:
[Tue Feb 05 19:38:55.831338 2013] [:error] [pid 7520] ipa: DEBUG: found session
cookie_id = bcc81ee57dd1b0dc068a6b049618dfa8
[Tue Feb 05 19:38:55.832468 2013] [:error] [pid 7520] ipa: DEBUG: found session
data in cache with id=bcc81ee57dd1b0dc068a6b049618dfa8
[Tue Feb 05 19:38:55.852098 2013] [:error] [pid 7520] ipa: DEBUG:
jsonserver_session.__call__: session_id=bcc81ee57dd1b0dc068a6b049618dfa8
start_timestamp=2013-02-05T19:34:48 access_timestamp=2013-02-05T19:38:55
expiration_timestamp=2013-02-05T19:57:31
[Tue Feb 05 19:38:55.853918 2013] [:error] [pid 7520] ipa: DEBUG: storing
ccache data into file /var/run/ipa_memcached/krbcc_7520
[Tue Feb 05 19:38:55.857797 2013] [:error] [pid 7520] ipa: DEBUG:
get_credential_times: principal=krbtgt/@.com, authtime=02/05/13
14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28,
renew_till=01/01/70 01:00:00
[Tue Feb 05 19:38:55.858643 2013] [:error] [pid 7520] ipa: DEBUG:
get_credential_times: principal=krbtgt/@.com, authtime=02/05/13
14:28:55, starttime=02/05/13 19:34:48, endtime=02/06/13 14:25:28,
renew_till=01/01/70 01:00:00
[Tue Feb 05 19:38:55.863192 2013] [:error] [pid 7520] ipa: DEBUG: KRB5_CCache
FILE:/var/run/ipa_memcached/krbcc_7520 endtime=1360157128 (02/06/13 14:25:28)
[Tue Feb 05 19:38:55.864570 2013] [:error] [pid 7520] ipa: DEBUG:
set_session_expiration_time: duration_type=inactivity_timeout duration=1200
max_age=1360156828 expiration=1360090735.86 (2013-02-05T19:58:55)
[Tue Feb 05 19:38:56.67 2013] [:error] [pid 7520] ipa: DEBUG: Created
connection context.ldap2
[Tue Feb 05 19:38:56.000523 2013] [:error] [pid 7520] ipa: DEBUG: WSGI
jsonserver.__call__:
[Tue Feb 05 19:38:56.000831 2013] [:error] [pid 7520] ipa: DEBUG: WSGI
WSGIExecutioner.__call__:
[Tue Feb 05 19:38:56.001809 2013] [:error] [pid 7520] ipa: DEBUG: raw:
batch(({u'params': [[], {}], u'method': u'i18n_messages'}, {u'params': [[],
{}], u'method': u'config_show'}, {u'params': [[], {u'all': True, u'whoami':
True}], u'method': u'user_find'}, {u'params': [[], {}], u'method': u'env'},
{u'params': [[], {}], u'method': u'dns_is_enabled'}))
[Tue Feb 05 19:38:56.002558 2013] [:error] [pid 7520] ipa: DEBUG:
batch(({u'params': [[], {}], u'method': u'i18n_messages'}, {u'params': [[],
{}], u'method': u'config_show'}, {u'params': [[], {u'all': True, u'whoami':
True}], u'method': u'user_find'}, {u'params': [[], {}], u'method': u'env'},
{u'params': [[], {}], u'method': u'dns_is_enabled'}))
[Tue Feb 05 19:38:56.003219 2013] [:error] [pid 7520] ipa: DEBUG: raw:
i18n_messages()
[Tue Feb 05 19:38:56.003633 2013] [:error] [pid 7520] ipa: DEBUG:
i18n_messages()
[Tue Feb 05 19:38:56.011433 2013] [:error] [pid 7520] ipa: INFO: u...@.com:
batch: i18n_messages(): SUCCESS
[Tue Feb 05 19:38:56.011971 2013] [:error] [pid 7520] ipa: DEBUG: raw:
config_show()
[Tue Feb 05 19:38:56.012526 2013] [:error] [pid 7520] ipa: DEBUG:
config_show(rights=False, all=False, raw=False)
[Tue Feb 05 19:38:56.016416 2013] [:error] [pid 7520] ipa: DEBUG: retrieving
schema for SchemaCache url=ldapi://%2fvar%2frun%2fslapd--COM.socket
conn=ldap.ldapobject.SimpleLDAPObject instance at 0x7f1d487dad40
[Tue Feb 05 19:38:56.322078 2013] [:error] [pid 7520] ipa: INFO: u...@.com:
batch: config_show(): SUCCESS
[Tue Feb 05 19:38:56.322640 2013] [:error] [pid 7520] ipa: DEBUG: raw:
user_find(None, whoami=True, all=True)
[Tue Feb 05 19:38:56.323390 2013] [:error] [pid 7520] ipa: DEBUG:
user_find(None, whoami=True, all=True, raw=False, pkey_only=False)
[Tue Feb 05 19:38:56.335920 2013] [:error] [pid 7520] ipa: DEBUG: get_memberof:
entry_dn=uid=user,cn=users,cn=accounts,dc=,dc=com
memberof=[ipapython.dn.DN('cn=admins,cn=groups,cn=accounts,dc=,dc=com'),
ipapython.dn.DN('cn=Replication
Administrators,cn=privileges,cn=pbac,dc=,dc=com'), ipapython.dn.DN('cn=Add
Replication Agreements,cn=permissions,cn=pbac,dc=,dc=com'),
ipapython.dn.DN('cn=Modify Replication
Agreements,cn=permissions,cn=pbac,dc=,dc=com'), ipapython.dn.DN('cn=Remove
Replication
Re: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works
On 02/05/2013 06:47 PM, Petr Vobornik wrote: Open Web Console in browser (in FF: 'Tools/Web Developer/Web Console', in Chrome hit F12). I'm using firefox. I'm getting a javascript warning about getAttributeNode being deprecated, and some css complaints. The first post just gets one's own principal (which is correct), and i18 messages, the second post returns the Error 903... Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] Upgrade to 3.1.2: web UI no longer works
On 02/05/2013 08:02 PM, Rob Crittenden wrote: Can you see if you have 60basev3.ldif in /etc/dirsrv/slapd-YOUR-REALM/schema ? That was indeed not there (only 60basev2.ldif). I've copied it, restarted dirsrv. ipa user-show admin works (it did work before though). You'll want to look at /var/log/ipaupgrade.log as well (it may be huge). I reran ipa-upgradeconfig, there are a few errors; see the attachment. Seems to be mostly ldap errors; I don't know why named and pki-cad didn't restart, when I do that manually, they start fine. Thanks, Tom 2012-02-24 14:48:01,062 ERROR Update failed: Type or value exists: 2012-02-24 14:48:01,240 ERROR Add failure Object class violation: missing required attribute objectclass 2012-02-24 14:48:01,382 ERROR Add failure cn=anonymous-limits,cn=etc,dc=,dc=com 2012-02-24 14:48:01,392 ERROR Add failure cn=Managed Entries,cn=etc,dc=,dc=com 2012-02-24 14:48:01,447 ERROR Add failure Object class violation: missing required attribute objectclass 2012-02-24 14:48:01,510 ERROR Add failure cn=replication,cn=etc,dc=,dc=com 2012-02-24 14:48:01,515 ERROR Add failure cn=automember,cn=etc,dc=,dc=com 2012-02-24 14:48:01,544 ERROR Add failure cn=Templates,cn=Managed Entries,cn=etc,dc=,dc=com 2012-02-24 14:48:01,550 ERROR Add failure cn=Definitions,cn=Managed Entries,cn=etc,dc=,dc=com 2012-02-24 14:48:01,555 ERROR Add failure cn=replicas,cn=ipa,cn=etc,dc=,dc=com 2012-02-24 14:48:01,561 ERROR Add failure cn=Hostgroup,cn=automember,cn=etc,dc=,dc=com 2012-02-24 14:48:01,566 ERROR Add failure cn=Group,cn=automember,cn=etc,dc=,dc=com 2012-02-24 14:48:01,571 ERROR Add failure cn=Write IPA Configuration,cn=privileges,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,577 ERROR Add failure cn=Write IPA Configuration,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,582 ERROR Add failure cn=Add HBAC rule,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,586 ERROR Add failure cn=Delete HBAC rule,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,592 ERROR Add failure cn=Modify HBAC rule,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,597 ERROR Add failure cn=Manage HBAC rule membership,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,602 ERROR Add failure cn=Add HBAC services,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,607 ERROR Add failure cn=Delete HBAC services,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,613 ERROR Add failure cn=Add HBAC service groups,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,618 ERROR Add failure cn=Delete HBAC service groups,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,623 ERROR Add failure cn=Manage HBAC service group membership,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,628 ERROR Add failure cn=HBAC Administrator,cn=privileges,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,634 ERROR Add failure cn=Add Sudo rule,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,638 ERROR Add failure cn=Delete Sudo rule,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,643 ERROR Add failure cn=Modify Sudo rule,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,648 ERROR Add failure cn=Add Sudo command,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,654 ERROR Add failure cn=Delete Sudo command,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,659 ERROR Add failure cn=Modify Sudo command,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,664 ERROR Add failure cn=Add Sudo command group,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,669 ERROR Add failure cn=Delete Sudo command group,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,674 ERROR Add failure cn=Manage Sudo command group membership,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,679 ERROR Add failure cn=Sudo Administrator,cn=privileges,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,684 ERROR Add failure cn=Add Group Password Policy costemplate,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,689 ERROR Add failure cn=Delete Group Password Policy costemplate,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,694 ERROR Add failure cn=Modify Group Password Policy costemplate,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,699 ERROR Add failure cn=Add Group Password Policy,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,704 ERROR Add failure cn=Delete Group Password Policy,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,710 ERROR Add failure cn=Modify Group Password Policy,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,715 ERROR Add failure cn=Password Policy Administrator,cn=privileges,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,721 ERROR Add failure cn=Add krbPrincipalName to a host,cn=permissions,cn=pbac,dc=,dc=com 2012-02-24 14:48:01,813 ERROR Add failure Object class violation: missing required attribute objectclass
[Freeipa-users] installing freeipa v2 server fails at configuring certificate server instance
Hi, Installing a v2 freeipa server failed for me at the stage configuring certificate server instance The machine is an updated (and now fully up2date) fedora16 x64 machine. Here's the command line output: Configuring certificate server: Estimated time 3 minutes 30 seconds [1/17]: creating certificate server user [2/17]: creating pki-ca instance [3/17]: configuring certificate server instance root: CRITICAL failed to configure ca instance Command '/usr/bin/perl /usr/bin/pkisilent 'ConfigureCA' '-cs_hostname' 'server.x.com' '-cs_port' '9445' '-client_certdb_dir' '/tmp/tmp-HxuF_T' '-client_certdb_pwd' '-preop_pin' 'rgN1Coi9yfnvOUlxsUUw' '-domain_name' 'IPA' '-admin_user' 'admin' '-admin_email' 'root@localhost' '-admin_password' '-agent_name' 'ipa-ca-agent' '-agent_key_size' '2048' '-agent_key_type' 'rsa' '-agent_cert_subject' 'CN=ipa-ca-agent,O=AXSEM.COM' '-ldap_host' server.x.com' '-ldap_port' '7389' '-bind_dn' 'cn=Directory Manager' '-bind_password' '-base_dn' 'o=ipaca' '-db_name' 'ipaca' '-key_size' '2048' '-key_type' 'rsa' '-key_algorithm' 'SHA256withRSA' '-save_p12' 'true' '-backup_pwd' '-subsystem_name' 'pki-cad' '-token_name' 'internal' '-ca_subsystem_cert_subject_name' 'CN=CA Subsystem,O=X.COM' '-ca_ocsp_cert_subject_name' 'CN=OCSP Subsystem,O=X.COM' '-ca_server_cert_subject_name' 'CN=axextserver1.hq.axsem.com,O=X.COM' '-ca_audit_signing_cert_subject_name' 'CN=CA Audit,O=X.COM' '-ca_sign_cert_subject_name' 'CN=Certificate Authority,O=X.COM' '-external' 'false' '-clone' 'false'' returned non-zero exit status 255 Unexpected error - see ipaserver-install.log for details: Configuration of CA failed I got it working once I removed the (link local IMO) IPv6 address from the ethernet interface. Otherwise, the pki ports (such as 9445) were only bound to IPv6 addresses. Strange. Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] installing freeipa v2 server fails at configuring certificate server instance
On 11/16/2011 03:14 PM, Alexander Bokovoy wrote: maybe that's because server..com resolves to IPv6 address? We pass FQDN of the server to pkisilent, and then it tries to set up and start CA. It doesn't: # dig server..com ; DiG 9.8.1-RedHat-9.8.1-2.fc16 server..com ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 21488 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;server..com. IN A ;; ANSWER SECTION: server..com. 86400 IN A 192.168.1.2 ;; AUTHORITY SECTION: x.com. 86400 IN NS x.com. ;; ADDITIONAL SECTION: x.com. 86400 IN A 192.168.1.2 ;; Query time: 0 msec ;; SERVER: 192.168.1.2#53(192.168.1.2) ;; WHEN: Wed Nov 16 15:21:35 2011 ;; MSG SIZE rcvd: 89 ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] secure NFSv4 failure after IPA server upgrade
After upgrading FreeIPA from FC14/FreeIPAv1 to FC16/FreeIPAv2, secure NFSv4 mounts do not work anymore. V2 is basically a reinstalled FreeIPA server with user data migrated from v1, and host keys etc. recreated. I get the following when trying to mount: # mount -t nfs4 -o soft,intr,rsize=8192,wsize=8192,rw,sec=krb5p server.x.com:/y z mount.nfs4: access denied by server while mounting server.x.com:/y On the client, rpc.gssd reports: Warning: rpcsec_gss library does not support setting debug level beginning poll dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 dir_notify_handler: sig 37 si 0x7fff5f5f1570 data 0x7fff5f5f1440 dir_notify_handler: sig 37 si 0x7fff5f5f0df0 data 0x7fff5f5f0cc0 handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt3a) handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt3a) process_krb5_upcall: service is 'null' Full hostname for 'server.x.com' is 'server.x.com' Full hostname for 'client.x.com' is 'client.x.com' No key table entry found for CLIENT.X.COM$@X.COM while getting keytab entry for 'CLIENT.X.COM$@X.COM' No key table entry found for root/client.x@x.com while getting keytab entry for 'root/client.x@x.com' Success getting keytab entry for 'nfs/client.x@x.com' Successfully obtained machine credentials for principal 'nfs/client.x@x.com' stored in ccache 'FILE:/tmp/krb5cc_machine_X.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_X.COM' are good until 1321556514 using FILE:/tmp/krb5cc_machine_X.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_X.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server server.x.com DEBUG: port already set to 2049 creating context with server n...@server.x.com WARNING: Failed to create krb5 context for user with uid 0 for server server.x.com WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_X.COM for server server.x.com WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server server.x.com Full hostname for 'server.x.com' is 'server.x.com' Full hostname for 'client.x.com' is 'client.x.com' No key table entry found for CLIENT.X.COM$@X.COM while getting keytab entry for 'CLIENT.X.COM$@X.COM' No key table entry found for root/client.x@x.com while getting keytab entry for 'root/client.x@x.com' Success getting keytab entry for 'nfs/client.x@x.com' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_X.COM' are good until 1321556514 INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_X.COM' are good until 1321556514 using FILE:/tmp/krb5cc_machine_X.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_X.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server server.x.com DEBUG: port already set to 2049 creating context with server n...@server.x.com WARNING: Failed to create krb5 context for user with uid 0 for server server.x.com WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_X.COM for server server.x.com WARNING: Failed to create machine krb5 context with any credentials cache for server server.x.com doing error downcall dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 dir_notify_handler: sig 37 si 0x7fff5f5f5d30 data 0x7fff5f5f5c00 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt3b destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt3a And on the server, rpc.svcgssd reports: leaving poll handling null request svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 enctypes from defaults sname = nfs/client.x@x.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc4121_buffer: protocol 1 prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 doing downcall mech: krb5, hndl len: 4, ctx len 52, timeout: 1321556514 (86400 from now), clnt: n...@client.x.com, uid: -1, gid: -1, num aux grps: 0: sending null reply writing message: \x \x6082\x6081 entering poll leaving poll handling null request svcgssd_limit_krb5_enctypes: Calling gss_set_allowable_enctypes with 7 enctypes from defaults sname = nfs/client.x@x.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc4121_buffer:
Re: [Freeipa-users] secure NFSv4 failure after IPA server upgrade
On 11/16/2011 08:40 PM, Simo Sorce wrote: Are you using DES keys ? In that case you probably need to allow weak crypto on both server and client. Note that if all your server/clients are FC16 and you have no old ones FC14 or RHEL 6 then you do not need to force the creation of the nfs/ principal to use only DES keys. Simo. No. I did not use any -e parameter to ipa-getkeytab, so I got aes256-cts-hmac-sha1-96, aes128-cts-hmac-sha1-96, des3-cbc-sha1 and arcfour-hmac. Also, enctype 18 is AFAIK not weak. I also tried enabling weak crypto, and to use only des keys, but that didn't help either. Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] secure NFSv4 failure after IPA server upgrade
On 11/16/2011 08:27 PM, Rob Crittenden wrote: Looks like https://bugzilla.redhat.com/show_bug.cgi?id=652273 Yes. For some reasons I always seem to end up with NFS problems... The fix I used at that time IMO is no longer applicable... mozldap isn't even installed anymore Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] secure NFSv4 failure after IPA server upgrade
On 11/16/2011 08:48 PM, Simo Sorce wrote: If you did this on both server and client, then it looks like it is a nfsd bug, and not a freeipa one. So I filed a bug report against nfs-utils: https://bugzilla.redhat.com/show_bug.cgi?id=754552 I hope Steve Dickson has some ideas... Thanks, Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] secure NFSv4 failure after IPA server upgrade
On 11/16/2011 08:59 PM, Thomas Sailer wrote: On 11/16/2011 08:48 PM, Simo Sorce wrote: If you did this on both server and client, then it looks like it is a nfsd bug, and not a freeipa one. So I filed a bug report against nfs-utils: https://bugzilla.redhat.com/show_bug.cgi?id=754552 Or maybe even a kernel bug. It can be cured by modprobe rpcsec_gss_krb5 on the server. Now there is code in the kernel to autoload that module, but that does not seem to work. Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] krb5 nfs failure between F14 freeipa server and F14 client
On Wed, 2010-12-08 at 11:00 -0500, Simo Sorce wrote: On Tue, 07 Dec 2010 10:51:55 +0100 Thomas Sailer sai...@sailer.dynip.lugs.ch wrote: On Mon, 2010-12-06 at 13:53 -0500, Simo Sorce wrote: However krb5nfs still does not work, it hangs now (instead of giving me an instantaneous error). Will investigate further. Let us know if you solve this problem. It wasn't really a hang, it terminated after many minutes. I can now mount the nfs4 exports on all clients with krb5p. However, access to the nfs4 exports is quite unreliable, much too unreliable to have home directories on nfs4. When I start gnome, gnome-settings-daemon and many other daemons get stuck in D state, usually somewhere within nfs4_delay. With KDE, a simple sed with destination file in the home directory gets stuck in fchown. So I'm back to nfs3 at the moment. Thanks, Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] krb5 nfs failure between F14 freeipa server and F14 client
On Mon, 2010-12-06 at 13:53 -0500, Simo Sorce wrote: Hi Simo, I pushed the patch in git just today :) Your patch indeed helps :) I've adapted it to the fc14 srpm, compiled it, and at least the extop plugin now uses the openldap libraries: http://sailer.fedorapeople.org/ipa-1.2.2-5.fc14.jnx.src.rpm The unreliability of ipa-getkeytab seems now gone, and the krb5 kdc now issues nfs tickets (the ASN.1 parse error is now gone). However krb5nfs still does not work, it hangs now (instead of giving me an instantaneous error). Will investigate further. V2 will need a migration, upgrades are not really possible as we have added/changed a ton of schema and other things in the LDAP tree. That indeed seems like a bigger project... Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] krb5 nfs failure between F14 freeipa server and F14 client
On Mon, 2010-12-06 at 10:55 -0500, Simo Sorce wrote: Hi Simo, thanks for your response! We are seeing an issue with F14 DS where it has been built against opneldap libraries while we still have plugins built against mozldap. Where would that help? just for the ipa-getkeytab reliability issue? Because after the kerberos keys are in the client's keytab, how is ldap even involved in the nfs issues? Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] krb5 nfs failure between F14 freeipa server and F14 client
On Mon, 2010-12-06 at 13:35 -0500, Simo Sorce wrote: Keys are stored in ldap and asn.1 encoding is generated using ldap libraries before storing it. If that operation fails it may generate malformed entries that the KDC later can't properly decode. Which patch are you talking about? Is it included in the current alpha (binaries)? Upgrade to the current alpha might be a better idea than trying to downgrade, or am I overlooking something? Thanks, Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] krb5 nfs failure between F14 freeipa server and F14 client
Hi,
after upgrading a F12 freeipa server to F14, krb5 nfs no longer works.
1) ipa-getkeytab works only very unreliably. I get the following about 4
out of 5 times:
# ipa-getkeytab -s 192.168.1.2 -p nfs/client..xxx -k /etc/krb5.keytab
Operation failed! Unable to set key
ipa-delservice, ipa-addservice and other ipa- commands seem to work
fine, though.
2) I get the following log from rpc.gssd on the client:
# rpc.gssd -f -v -v -v -v -v beginning poll
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1c)
handle_gssd_upcall: 'mech=krb5 uid=0 '
handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt1c)
process_krb5_upcall: service is 'null'
Full hostname for 'server..xxx' is 'server..xxx'
Full hostname for 'client..xxx' is 'client..xxx'
Key table entry not found while getting keytab entry for
'root/client.@.xxx'
Success getting keytab entry for 'nfs/client.@.xxx'
WARNING: Generic error (see e-text) while getting initial ticket for principal
'nfs/client.@.xxx' using keytab 'WRFILE:/etc/krb5.keytab'
ERROR: No credentials found for connection to server server..xxx
doing error downcall
dir_notify_handler: sig 37 si 0x7d2a1170 data 0x7d2a1040
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
dir_notify_handler: sig 37 si 0x7d2a16b0 data 0x7d2a1580
destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt1c
3) In the server's kdc log, I find the following:
Dec 04 02:09:08 server..xxx krb5kdc[6933](info): AS_REQ (7 etypes {18 17 16
23 1 3 2}) 192.168.1.220: LOOKING_UP_CLIENT: nfs/client.@.xxx for
krbtgt/@.xxx, unable to decode stored principal key data (ASN.1
structure is missing a required field)
Does anybody have an idea how I could get krb5 nfs working again?
Thanks,
Tom
___
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users
[Freeipa-users] Secure nfs4 and Fedora 14
Since I upgraded about two days ago from a fully up-to-date and working Fedora13 system to Fedora14, I am unable to mount the krb5p nfs4 shares of the freeipa server (which is itself running a fully up-to-date Fedora12). rpc.gssd on the client reports the following: beginning poll dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si 0x7fff99e7f930 data 0x7fff99e7f800 dir_notify_handler: sig 37 si 0x7fff99e82ef0 data 0x7fff99e82dc0 handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) handle_gssd_upcall: 'mech=krb5 uid=0 enctypes=18,17,16,23,3,1,2 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt38) process_krb5_upcall: service is 'null' Full hostname for 'server..xxx' is 'server..xxx' Full hostname for 'clnt..xxx' is 'clnt..xxx' Key table entry not found while getting keytab entry for 'root/clnt.@.xxx' Success getting keytab entry for 'nfs/clnt.@.xxx' Successfully obtained machine credentials for principal 'nfs/clnt.@.xxx' stored in ccache 'FILE:/tmp/krb5cc_machine_.XXX' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_.XXX' are good until 1289651734 using FILE:/tmp/krb5cc_machine_.XXX as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_.XXX creating context using fsuid 0 (save_uid 0) creating tcp client for server server..xxx DEBUG: port already set to 2049 creating context with server n...@server..xxx WARNING: Failed to create krb5 context for user with uid 0 for server server..xxx WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_.XXX for server server..xxx WARNING: Machine cache is prematurely expired or corrupted trying to recreate cache for server server..xxx Full hostname for 'server..xxx' is 'server..xxx' Full hostname for 'clnt..xxx' is 'clnt..xxx' Key table entry not found while getting keytab entry for 'root/clnt.@.xxx' Success getting keytab entry for 'nfs/clnt.@.xxx' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_.XXX' are good until 1289651734 INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_.XXX' are good until 1289651734 using FILE:/tmp/krb5cc_machine_.XXX as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_.XXX creating context using fsuid 0 (save_uid 0) creating tcp client for server server..xxx DEBUG: port already set to 2049 creating context with server n...@server..xxx WARNING: Failed to create krb5 context for user with uid 0 for server server..xxx WARNING: Failed to create machine krb5 context with credentials cache FILE:/tmp/krb5cc_machine_.XXX for server server..xxx WARNING: Failed to create machine krb5 context with any credentials cache for server server..xxx doing error downcall dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si 0x7fff99e83030 data 0x7fff99e82f00 dir_notify_handler: sig 37 si 0x7fff99e82f30 data 0x7fff99e82e00 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 dir_notify_handler: sig 37 si 0x7fff99e7dfb0 data 0x7fff99e7de80 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt39 destroying client /var/lib/nfs/rpc_pipefs/nfs/clnt38 I need to downgrade the kernel and krb5* to the Fedora13 version to get nfs4 working again. Does anybody have an idea why it no longer works? What is the current party line with respect to nfs4 encryption types? The admin guide on the freeipa web page still requires des-cbc-crc. But MIT Kerberos seems to become increasingly hostile against des. And yes, I do have allow_weak_crypto = true in krb5.conf/libdefaults Thanks, Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NFS4 after client upgrade to Fedora 13
On Thu, 2010-05-27 at 09:09 -0400, Rob Crittenden wrote: I assume the keytab is still valid since the mount succeeds and root works. Kerberos otherwise works ok on this machine, you can kinit, etc? Hm, the server didn't change, and on the client klist -k /etc/krb5.keytab -e does not suggest anything changed, so yes the keytab seems to be ok. Kerberos works as well. You might want to check the kdc log on and the 389-ds log, you might see some querying to find the user for authentication. Neither /var/log/krb5kdc.log nor /var/log/dirsrv/slapd-XXX-COM/errors lists anything related to that client. Do things like 'getent passwd someuser' still work? Yes. I don't think it's anything related to the server, or krb5 on the client going wrong. At the time the non-root user does ls /tmp/z, there is no network traffic, so the server cannot even know that some user tries to ls the mount directory. Also, I've monitored the network traffic with wireshark, the whole NFSv4 exchange seems to work as expected (unfortunately wireshark does not seem to have a dissector for V4 composite RPC calls, so I don't know in detail what server and client are talking about), I have not seen any GSS related failures in the protocol exchange. I've tried selective downgrade of the client. I've downgraded kernel, nfs-utils*, cyrus-sasl*, libtirpc*, krb5*, so far without success. I've also tried the opposite, i.e. selectively upgrading a working fc12 client, so far without any insight, it is still working. I've upgraded the following packages: grubby-7.0.13-1.fc13.x86_64 kernel-2.6.33.4-95.fc13.x86_64 krb5-devel-1.7.1-10.fc13.x86_64 krb5-libs-1.7.1-10.fc13.i686 krb5-libs-1.7.1-10.fc13.x86_64 krb5-workstation-1.7.1-10.fc13.x86_64 linux-firmware-20100106-4.fc13.noarch nfs-utils-1.2.2-2.fc13.x86_64 nfs-utils-lib-1.1.5-1.fc13.x86_64 I'm a bit at a loss... Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NFS4 after client upgrade to Fedora 13
On Thu, 2010-05-27 at 12:27 -0400, Simo Sorce wrote: Try adding allow_weak_crypto = true to your krb5.conf or alternatively rekey your NFS credentials to add RC4/AES keys (rekeying works only if both client and server kernels supporting anything but DES, I think F13's kernels should have those patches now, but old kernels support only DES). Thanks for the hint! Unfortunately, it does not help. I've put allow_weak_crypto=true in the libdefaults section, but I still get permission denied when trying to access the mount directory as non-root. However, I got my rawhide machine connecting to the IPA server that way :) I think allow_weak_crypto is only necessary for krb5 1.8 and later, while F13 still has 1.7. Tom ___ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
Re: [Freeipa-users] NFS4 after client upgrade to Fedora 13
On Thu, 2010-05-27 at 14:30 -0400, Simo Sorce wrote: Oh right, then I guess you need to look into syslog to see if you can find any other hint. does the gssd daemon log anything ? It can be made to talk, like this: rpc.gssd -f -vv -rr Messages at startup: Warning: rpcsec_gss library does not support setting debug level beginning poll At mount time: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) handle_gssd_upcall: 'mech=krb5 uid=0 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) process_krb5_upcall: service is 'null' Full hostname for 'server.xxx.com' is 'server.xxx.com' Full hostname for 'client.xxx.com' is 'client.xxx.com' Key table entry not found while getting keytab entry for 'root/client.xxx@xxx.com' Success getting keytab entry for 'nfs/client.xxx@xxx.com' Successfully obtained machine credentials for principal 'nfs/client.xxx@xxx.com' stored in ccache 'FILE:/tmp/krb5cc_machine_XXX.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_XXX.COM' are good until 1275168019 using FILE:/tmp/krb5cc_machine_XXX.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_XXX.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server server.xxx.com DEBUG: port already set to 2049 creating context with server n...@server.xxx.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) handle_gssd_upcall: 'mech=krb5 uid=1591 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt35) process_krb5_upcall: service is 'null' getting credentials for client with uid 1591 for server server.xxx.com CC file '/tmp/krb5cc_1591' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1591'(u...@xxx.com) passed all checks and has mtime of 1274978851 CC file '/tmp/krb5cc_1_lxXOef' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1_lxXOef' owned by 1, not 1591 CC file '/tmp/krb5cc_machine_XXX.COM' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_machine_XXX.COM' owned by 0, not 1591 CC file '/tmp/krb5cc_1_CG6m2Y' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1_CG6m2Y' owned by 1, not 1591 using FILE:/tmp/krb5cc_1591 as credentials cache for client with uid 1591 for server server.xxx.com using environment variable to select krb5 ccache FILE:/tmp/krb5cc_1591 creating context using fsuid 1591 (save_uid 0) creating tcp client for server server.xxx.com DEBUG: port already set to 2049 creating context with server n...@server.xxx.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall Now interestingly, the access works if rpc.gssd is started from the console! When I start it using service rpc.gssd restart, it fails again, now with this in the log: beginning poll handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) handle_gssd_upcall: 'mech=krb5 uid=0 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) process_krb5_upcall: service is 'null' Full hostname for 'server.xxx.com' is 'server.xxx.com' Full hostname for 'client.xxx.com' is 'client.xxx.com' Key table entry not found while getting keytab entry for 'root/client.xxx@xxx.com' Success getting keytab entry for 'nfs/client.xxx@xxx.com' Successfully obtained machine credentials for principal 'nfs/client.xxx@xxx.com' stored in ccache 'FILE:/tmp/krb5cc_machine_XXX.COM' INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_XXX.COM' are good until 1275169699 using FILE:/tmp/krb5cc_machine_XXX.COM as credentials cache for machine creds using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_XXX.COM creating context using fsuid 0 (save_uid 0) creating tcp client for server server.xxx.com DEBUG: port already set to 2049 creating context with server n...@server.xxx.com DEBUG: serialize_krb5_ctx: lucid version! prepare_krb5_rfc1964_buffer: serializing keys with enctype 4 and length 8 doing downcall handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) handle_gssd_upcall: 'mech=krb5 uid=1591 ' handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt47) process_krb5_upcall: service is 'null' getting credentials for client with uid 1591 for server server.xxx.com CC file '/tmp/krb5cc_1591' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1591' is expired or corrupt CC file '/tmp/krb5cc_1_lxXOef' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1_lxXOef' owned by 1, not 1591 CC file '/tmp/krb5cc_machine_XXX.COM' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_machine_XXX.COM' owned by 0, not 1591 CC file '/tmp/krb5cc_1_CG6m2Y' being considered, with preferred realm 'XXX.COM' CC file '/tmp/krb5cc_1_CG6m2Y' owned by
