*** NameError: name 'ds_is_older' is not defined
by Anuj Borah
Hi all,
Issue: https://pagure.io/389-ds-base/issue/50446
from lib389.utils import (ds_is_older) is missing in
https://pagure.io/389-ds-base/blob/master/f/src/lib389/lib389/idm/account.py
users = UserAccounts(standalone, DEFAULT_SUFFIX)
for i in users.list(): i.dn
'uid=testuser,ou=People,dc=example,dc=com'
'uid=test_user_1000,ou=People,dc=example,dc=com'
'uid=test_user1,ou=People,dc=example,dc=com'
UserAccount(standalone,'uid=test_user1,ou=People,dc=example,dc=com').enroll_certificate('/etc/dirsrv/slapd-standalone1/user-test_user1.der')
*** NameError: name 'ds_is_older' is not defined
Regards
Anuj Borah
5 years
Extra schema from SUSE 12/openldap
by William Brown
Hi all,
During my packaging work I have noticed that suse is shipping extra schema for compatability with openldap and some legacy applications. I have attached the tar.gz to check.
What would we think about shipping this in the upstream to help ensure compatibility between RH/SUSE/Others in migrations from OpenLDAP -> 389, and between 389 on distros?
I think it may also be worth our time to investigate an openldap -> 389 conversion tool, because both RH and SUSE are dropping OpenLDAP so we should help support our users to make the migration as seemless as possible.
Thoughts?
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs
5 years
Replication agreement status messages: JSON or text?
by Mark Reynolds
I am currently working on a revision of replication agreement status
messages. Previously we logged the status like so:
Error (%d) - message (sub-message) ...
If Error was set to 0 it meant success, but this caused confusion
because of the word "Error". So I am working on changing this.
There are two options here: change the static "Error" text to be
dynamic: "Info", "Warning", or "Error" depending on the state. Or, move
away from a human friendly text string to a machine friendly simple JSON
object. There are pro's and con's to both. I think moving towards a
JSON object is the correct way - easier to maintain, and easier to be
consumed by other applications. The cons are that it is a disruptive
change to the previous behavior, and it could be confusing to an Admin
who might not understand JSON.
This is the basic JSON object I was thinking of
{"status": "Good|Warning|Bad", "status code": NUMBER(aka error
code), "date": "2019117485748745Z", "message": "Message text"}
or maybe multiple messages (list):
{"status": "Good|Warning|Bad", "status code": NUMBER(aka error
code), "date": "2019117485748745Z", "message": ["the replication status
is...", "Connection error 91", "Server Down"]}
The JSON object can easily be extended without breaking clients, but
it's not easy to read for a human.
Thoughts?
Thanks,
Mark
5 years
