[Freeipa-users] freeipa server upgrade from fedora 20 to fedora 22 glitches

[Thomas Sailer]

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 0xffff...
>
> 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://xxxxxserver.xxxxx.com/ipa/json
>> ipa: INFO: Request: {
>>      "id": 0,
>>      "method": "ping",
>>      "params": [
>>          [],
>>          {}
>>      ]
>> }
>> ipa: INFO: Response: {
>>      "error": null,
>>      "id": 0,
>>      "principal": "admin at XXXXX.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://xxxxxserver.xxxxx.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": "admin at XXXXX.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=xxxxx,dc=com"
[04/Jun/2015:17:43:21 +0200] conn=3391 op=3 SRCH 
base="cn=ipaconfig,cn=etc,dc=xxxxx,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=xxxxx,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=xxxxx,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=xxxxx,dc=com"
[04/Jun/2015:17:43:22 +0200] conn=3391 op=6 RESULT err=20 tag=103 
nentries=0 etime=1 csn=557072af000100040000
[04/Jun/2015:17:43:22 +0200] conn=3391 op=7 UNBIND
[04/Jun/2015:17:43:22 +0200] conn=3391 op=7 fd=70 closed - U1

Thanks!
Thomas