On pe, 03 kesä 2022, Leo O via FreeIPA-users wrote:
So many questions come up when reading your reply. I also done some
troubleshooting.
1. Not a question, but a observation: set debug=true, still not helpful
If you have specific problems, outline them with more details. "still
not helpful" is not a problem statement that I can help with, sorry.
For example, this is how it works for me:
[root@idm ~]# vim /etc/ipa/server.conf
[root@idm ~]# cat /etc/ipa/server.conf
[global]
debug = True
[root@idm ~]# systemctl restart httpd
[root@idm ~]# kinit admin
Password for admin(a)IPA.TEST:
[root@idm ~]# ipa ping
----------------------------------------------------------------
IPA server version 4.10.0.dev202205301426+git. API version 2.248
----------------------------------------------------------------
And in the /var/log/httpd/error_log I can see:
[Sat Jun 04 06:13:05.625413 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Sat Jun 04 06:13:05.625469 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: WSGI jsonserver.__call__:
[Sat Jun 04 06:13:05.625497 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: KerberosWSGIExecutioner.__call__:
[Sat Jun 04 06:13:05.639304 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: Created connection context.ldap2_140315178175936
[Sat Jun 04 06:13:05.639380 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: WSGI WSGIExecutioner.__call__:
[Sat Jun 04 06:13:05.643317 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: raw: schema(known_fingerprints=('73d45d48',),
version='2.170')
[Sat Jun 04 06:13:05.643450 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: schema(known_fingerprints=('73d45d48',),
version='2.170')
[Sat Jun 04 06:13:05.761966 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: WSGI wsgi_execute PublicError: Traceback (most recent call
last):
[Sat Jun 04 06:13:05.761990 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] File
"/usr/lib/python3.10/site-packages/ipaserver/rpcserver.py", line 407, in
wsgi_execute
[Sat Jun 04 06:13:05.761994 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] result = command(*args, **options)
[Sat Jun 04 06:13:05.761997 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] File
"/usr/lib/python3.10/site-packages/ipalib/frontend.py", line 471, in __call__
[Sat Jun 04 06:13:05.762000 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] return self.__do_call(*args, **options)
[Sat Jun 04 06:13:05.762002 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] File
"/usr/lib/python3.10/site-packages/ipalib/frontend.py", line 499, in __do_call
[Sat Jun 04 06:13:05.762005 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ret = self.run(*args, **options)
[Sat Jun 04 06:13:05.762008 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] File
"/usr/lib/python3.10/site-packages/ipalib/frontend.py", line 816, in run
[Sat Jun 04 06:13:05.762011 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] return self.execute(*args, **options)
[Sat Jun 04 06:13:05.762013 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] File
"/usr/lib/python3.10/site-packages/ipaserver/plugins/schema.py", line 855, in
execute
[Sat Jun 04 06:13:05.762016 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] raise errors.SchemaUpToDate(
[Sat Jun 04 06:13:05.762019 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipalib.errors.SchemaUpToDate: Schema is up to date (FP
'73d45d48', TTL 3600 s)
[Sat Jun 04 06:13:05.762021 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858]
[Sat Jun 04 06:13:05.762089 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: INFO: [jsonserver_kerb] admin(a)IPA.TEST:
schema(known_fingerprints=('73d45d48',), version='2.170'): SchemaUpToDate
[Sat Jun 04 06:13:05.762120 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: [jsonserver_kerb] admin(a)IPA.TEST:
schema(known_fingerprints=('73d45d48',), version='2.170'): SchemaUpToDate
etime=122649405
[Sat Jun 04 06:13:05.762674 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: FINAL: Hits 0 Misses 0 Size 0
[Sat Jun 04 06:13:05.762711 2022] [wsgi:error] [pid 25641:tid 25865] [remote
10.0.189.65:40858] ipa: DEBUG: Destroyed connection context.ldap2_140315178175936
[Sat Jun 04 06:13:05.915087 2022] [:warn] [pid 25646:tid 25746] [client 10.0.189.65:40862]
failed to set perms (3140) on file (/run/ipa/ccaches/admin(a)IPA.TEST-GboQvM)!, referer:
https://idm.ipa.test/ipa/xml
[Sat Jun 04 06:13:05.915684 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Sat Jun 04 06:13:05.915729 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: WSGI jsonserver_session.__call__:
[Sat Jun 04 06:13:05.926136 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: Created connection context.ldap2_140315178176560
[Sat Jun 04 06:13:05.926198 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: WSGI jsonserver.__call__:
[Sat Jun 04 06:13:05.926237 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: WSGI WSGIExecutioner.__call__:
[Sat Jun 04 06:13:05.930928 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: raw: ping(version='2.248')
[Sat Jun 04 06:13:05.931037 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: ping(version='2.248')
[Sat Jun 04 06:13:05.931142 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: INFO: [jsonserver_session] admin(a)IPA.TEST:
ping/1(version='2.248'): SUCCESS
[Sat Jun 04 06:13:05.931177 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: [jsonserver_session] admin(a)IPA.TEST:
ping/1(version='2.248'): SUCCESS etime=4850346
[Sat Jun 04 06:13:05.932134 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: FINAL: Hits 0 Misses 0 Size 0
[Sat Jun 04 06:13:05.932180 2022] [wsgi:error] [pid 25642:tid 25868] [remote
10.0.189.65:40862] ipa: DEBUG: Destroyed connection context.ldap2_140315178176560
In non-debug run you'd only see entries with ipa: INFO or ipa: ERROR.
2. Still open question from my last post, do I need the "change
type
modify, add: attributeTypes, add: objectClasses" inside my schema, is
it doing something or should I remove it again?
No. You have to provide a schema file in a format like this in a
schema.d subdirectory:
https://github.com/abbra/freeipa-desktop-profile/blob/master/plugin/schem...
This is enough. IPA upgrade code will pick it up and perform proper
integration of it. The key is to put the LDAP schema files in
/usr/share/ipa/schema.d/. README file in that directory explains what is
required and expected.
Side note: About your reply, I'm not a python dev and I absolutely
don't know the application so best preconditions to probably do every
mistake possible. Nevertheless, according to "instead of that, simply
use add_missing_object_class()", the one you are talking about is a
class, my plugins are not, different structure, so I can't say what's
here important/ needed.
3. you mentioned my "usermod_precallback" function, what about the
"useradd_precallback" above, there is an append too, should this be
refactored as well with "add_missing_object_class"?
Yes.
4. Speaking of "add_missing_object_class(ldap,
u'ipacertmapobject',
dn)" what's the u'... before the objectClass doing, meaning?
This is Python 2 way of saying the string is in Unicode. You can drop it
these days, e.g. just 'ipacertmapobject' instead of u'ipacertmapobject'
as current IPA code is not targetted to Python 2 anymore.
5. And what about the statements after the first useradd and second
usermod callbacks:
"user.user_add.register_pre_callback(useradd_precallback)" and
"user.user_mod.register_pre_callback(usermod_precallback)", do they
stay, after your proposed refactoring or do they have to be removed?
They stay. I have tried to help you with that specific fragment, not
with the whole plugin or plugins.
Another observation:
I've setup a VM where I installed freeIPA, so I don't have to deal with
the read-only container and images. I started to create the files one
by one. So created "postfixbook.js", "mailenabled.js" and
"mailenabled.py", strangely no error, I could create a user, I could
click on the Mail enabled checkbox and save successfully. Ldapsearch
showed even that it was correctly set for that user. The only issue so
far, the checkbox in the UI is always unchecked, so entering a user
with checked mail enabled, when I check it, I can't save, FreeIpa sees
that nothing has changed, then when I uncheck, now I can save. So
simply on entering the details view, this checkbox element isn't set
according to the stored value, it's simply always unchecked. This was
done with the "old" unguarded appends, so it seems, this is working. I
then added the second file pairs "mailalias.js" and "mailalias.py".
Now
I had this weird behaviour, couldn't create user anymore, couldn't save
the mail alias. I then discovered that "mailenabled.py" had
"entry["objectclass"].append("postfixbookmailaccount")"
whereas
"mailalias.py" had
"entry["objectclass"].append("postfixbookMailaccount")" with
a capital
"M". BTW the same typo was in "mailsieverulesource". So how should I
know when to use lowercase or camelCase?
For example in the pdf:
https://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf
"objectclasses" is sometimes written lowercased and sometimes
camelCased "objectClasses". When I look into my schema, the
objectClasses name is even written as "PostfixBookMailAccount". In the
schema one attributeType is written as "mailEnabled", in the
"mailenabled.js" and "mailenabled.py" files everywhere is
"mailenabled"
lowercased. In your (abbra freeIpa user status) repo the same with
"inetuserstatus" in the .py and .js files whereas "inetUserStatus" in
the schema.
So I'm totally confused when to use what, it feels totally wrong, feels like a big
mess.
There are three separate parts here.
LDAP attribute and objectclass names are case-insensitive in LDAP. You
can build an LDAP filter that asks for
(&(objectClass=PostfixBookMailAccount)(mailEnabled=TRUE)) and
(&(objectclass=postfixbookmailaccount)(mailenabled=TRUE)) and get the
same result. Values might have different matching rules, sensitive and
insensitive, but the attribute/class names are insensitive. And
objectclass attribute values are treated case-insensitive in LDAP
schema. So that's why 'postfixbookmailaccount' and
'PostfixBookMailAccount' in the queries above both work.
When you use
entry["objectclass"].append("postfixbookMailaccount")
you are dealing with Python representation of the LDAP entry in IPA
framework. 'entry' is a dictionary. Python dictionary uses
case-sensitive keys, so entry["ObjectClass"] is addressing a different
object than entry["objectclass"]. Objects, stored in the dictionary,
treated elsewhere.
LDAP attribute names in IPA framework Python code often used to search
in various Python dictionaries or Python lists. When that search is
done, in most cases it is case-sensitive, so uniform casing is
important. We choose to use lower case in IPA framework.
There are few exceptions that help developers. For example,
add_missing_object_class() helper in its entirety is here:
def add_missing_object_class(ldap, objectclass, dn, entry_attrs=None, update=True):
"""
Add object class if missing into entry. Fetches entry if not passed. Updates
the entry by default.
Returns the entry
"""
if not entry_attrs:
entry_attrs = ldap.get_entry(dn, ['objectclass'])
if (objectclass.lower() not in (o.lower() for o in
entry_attrs['objectclass'])):
entry_attrs['objectclass'].append(objectclass)
if update:
ldap.update_entry(entry_attrs)
return entry_attrs
You can see that we use .lower() method a lot in comparisons of string
values and address 'objectclass' always in lower case when accessing
entry_attrs dictionary. But this is not the case for all code paths, so
we expect lowcase attribute/objectclass names.
Finally, your issue:
The only issue so far, the checkbox in the UI is always unchecked, so
entering a user with checked mail enabled, when I check it, I can't
save
This is most likely because your 'mailenabled' attribute is not fetched
by default when a corresponding object is retrieved. Do you see
'mailenabled' returned for 'ipa user-show'?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland