Hello, I'm new in this list, thank you for developing 389ds!
I would like some hints about lib389.
dscreate allows to set some parameters only when you create an instance. So it' very difficult to maintain all configuration parameters among db and instances and replicated instances.
I'm writing my tool to manage all configuration parameters in one place (a yaml file). Just a wrapper for dsconf. See at
https://github.com/falon/ds-easyconf
I would like to call dsconf from an external host only, different from hosts where the 389ds run. So I have installed the python3-lib389 rpm in that different host.
Let suppose I have
tst1.example.com tst2.example.com tst3.example.com
where 389ds Directory Server run after dscreate process.
I have another host:
manage.example.com
where I have installed lib389 rpm only, and from that remote host I configure the tst*.example.com servers through dsconf.
The problem is that dsconf exit with the error "defaults.inf not found in any well known location!".
So I have taken the defaults.inf from a 389ds host (one of tst*.example.com) and I have placed it in the new path /usr/share/dirsrv/inf of manage.example.com.
Now dsconf works fine.
I would like to know if there are some reason to avoid to do that. Or, if simply the python3-lib389 forgot to install the defaults.inf in the proper path.
Thank you very much Warm Regards Marco
On 28 Jan 2021, at 21:58, Marco Favero m.faverof@gmail.com wrote:
Hello, I'm new in this list, thank you for developing 389ds!
Thanks for using it!
I would like some hints about lib389.
dscreate allows to set some parameters only when you create an instance.
I think the only parameter that *can not* change after an install is "instance_name". Everything else is possible to alter later.
So it' very difficult to maintain all configuration parameters among db and instances and replicated instances.
I'm writing my tool to manage all configuration parameters in one place (a yaml file). Just a wrapper for dsconf. See at
https://github.com/falon/ds-easyconf
I would like to call dsconf from an external host only, different from hosts where the 389ds run. So I have installed the python3-lib389 rpm in that different host.
Let suppose I have
tst1.example.com tst2.example.com tst3.example.com
where 389ds Directory Server run after dscreate process.
I have another host:
manage.example.com
where I have installed lib389 rpm only, and from that remote host I configure the tst*.example.com servers through dsconf.
The problem is that dsconf exit with the error "defaults.inf not found in any well known location!".
Can you re-run with 'dsconf -v <other options>"? dsconf should be able to work remotely.
What version of 389-ds are you using as well? And on what distro?
So I have taken the defaults.inf from a 389ds host (one of tst*.example.com) and I have placed it in the new path /usr/share/dirsrv/inf of manage.example.com.
Now dsconf works fine.
I would like to know if there are some reason to avoid to do that. Or, if simply the python3-lib389 forgot to install the defaults.inf in the proper path.
I'd like to check your version, but it should work, so this sounds like either a bug in lib389 (requesting paths when not available) or a packaging issues.
Since you are already using python, you could more easily just use lib389 directly rather than subprocess to dsconf btw:
from lib389 import DirSrv import logging
log = logging.getLogger() log.setLevel(logging.DEBUG)
ds = DirSrv(verbose=True, external_log=log) ds.remote_simple_allocate(ldapuri="ldaps://ldapuri", binddn="", password="") ds.open()
from there you can pass the ds instance into things to configure them:
from lib389.config import Config dsconfig = Config(ds) dsconfig.set('nsslapd-port', '389')
There is a lot more you can do too, but this seems much more preferrable to shelling out.
Hope that helps,
Thank you very much Warm Regards Marco _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs, Australia
Hello William,
Can you re-run with 'dsconf -v <other options>"? dsconf should be able to work remotely.
This is the output on "manage" host:
[root@manage ~]# dsconf -v -D "cn=Directory Manager" -w password ldap://tst3.example.com:389 backend config get DEBUG: The 389 Directory Server Configuration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: dsrc path: /root/.dsrc DEBUG: dsrc container path: /data/config/container.inf DEBUG: dsrc instances: [] DEBUG: dsrc no such section: slapd-ldap://tst3.example.com:389 DEBUG: Called with: Namespace(basedn=None, binddn='cn=Directory Manager', bindpw='password', func=<function db_config_get at 0x7f5342b921e0>, instance='ldap://tst3.example.com:389', json=False, prompt=False, pwdfile=None, starttls=False, verbose=True) DEBUG: Instance details: {'uri': 'ldap://tst3.example.com:389', 'basedn': None, 'binddn': 'cn=Directory Manager', 'bindpw': None, 'saslmech': None, 'tls_cacertdir': None, 'tls_cert': None, 'tls_key': None, 'tls_reqcert': 1, 'starttls': False, 'prompt': False, 'pwdfile': None, 'args': {'ldapurl': 'ldap://tst3.example.com:389', 'root-dn': 'cn=Directory Manager'}} DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance DEBUG: Allocate <class 'lib389.DirSrv'> with ldap://tst3.example.com:389 DEBUG: Allocate <class 'lib389.DirSrv'> with manage.example.com:389 DEBUG: Allocate <class 'lib389.DirSrv'> with manage.example.com:389 DEBUG: SER_SERVERID_PROP not provided, assuming non-local instance DEBUG: Allocate <class 'lib389.DirSrv'> with ldap://tst3.example.com:389 DEBUG: Allocate <class 'lib389.DirSrv'> with manage.example.com:389 DEBUG: Allocate <class 'lib389.DirSrv'> with manage.example.com:389 DEBUG: open(): Connecting to uri ldap://tst3.example.com:389 DEBUG: defaults.inf not found in any well known location! Traceback (most recent call last): File "/usr/sbin/dsconf", line 133, in <module> inst = connect_instance(dsrc_inst=dsrc_inst, verbose=args.verbose, args=args) File "/usr/lib/python3.6/site-packages/lib389/cli_base/__init__.py", line 152, in connect_instance starttls=dsrc_inst['starttls'], connOnly=True) File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 998, in open certdir = self.get_cert_dir() File "/usr/lib/python3.6/site-packages/lib389/__init__.py", line 1677, in get_cert_dir return self.ds_paths.cert_dir File "/usr/lib/python3.6/site-packages/lib389/paths.py", line 156, in __getattr__ self._read_defaults() File "/usr/lib/python3.6/site-packages/lib389/paths.py", line 136, in _read_defaults spath = self._get_defaults_loc(DEFAULTS_PATH) File "/usr/lib/python3.6/site-packages/lib389/paths.py", line 133, in _get_defaults_loc raise IOError('defaults.inf not found in any well known location!') OSError: defaults.inf not found in any well known location! ERROR: Error: defaults.inf not found in any well known location!
If I add /usr/share/dirsrv/inf/defaults.inf myself, then dsconf works remotely very fine.
What version of 389-ds are you using as well? And on what distro?
On manage machine I installed 1.4.3.8-6. On remote hosts where run 389ds too, the version is 1.4.3.13-1
I'd like to check your version, but it should work, so this sounds like either a bug in lib389 (requesting paths when not available) or a packaging issues.
Since you are already using python, you could more easily just use lib389 directly rather than subprocess to dsconf btw:
from lib389 import DirSrv import logging
[...]
dsconfig.set('nsslapd-port', '389')
There is a lot more you can do too, but this seems much more preferrable to shelling out.
Wow, thank you very much for this example!! I found official lib389 docs, but I missed a complete example. I don't use the subprocess "shell" yet, but calling the api directly is of course better! I will try. Thank you very much for these hints!
Kind Regards Marco
[...]
Since you are already using python, you could more easily just use lib389 directly rather than subprocess to dsconf btw:
from lib389 import DirSrv import logging
[...]
I leave just a note on this...
Really at the moment I prefer trust on dsconf. I see that the lib389 documentation is still work in progress.
Or it's not clear for me where to find the full documentation. For instance, here
https://lib389.readthedocs.io/en/latest/plugin.html
it's not clear how to configure all uniqueness plugin parameters.
A more complete documentation seems the following:
https://spichugi.fedorapeople.org/html/plugin.html
but for example it still lacks on some configurations about AttributeUniquenessPlugin, such as "--subtree-entries-oc" which dsconf manages fine.
Another way to proceed is to manage all attributes and dn directly with LDAP modify operations, but this would bypass lib389...
Thank you again for all the hints Kind Regards Marco
On 29 Jan 2021, at 19:54, Marco Favero m.faverof@gmail.com wrote:
[...]
Since you are already using python, you could more easily just use lib389 directly rather than subprocess to dsconf btw:
from lib389 import DirSrv import logging
[...]
I leave just a note on this...
Really at the moment I prefer trust on dsconf. I see that the lib389 documentation is still work in progress.
Or it's not clear for me where to find the full documentation. For instance, here
https://lib389.readthedocs.io/en/latest/plugin.html
it's not clear how to configure all uniqueness plugin parameters.
A more complete documentation seems the following:
I think simon has the most up to date documentation. Remember, dsconf itself relies on lib389 so it can be trusted.
but for example it still lacks on some configurations about AttributeUniquenessPlugin, such as "--subtree-entries-oc" which dsconf manages fine.
Another way to proceed is to manage all attributes and dn directly with LDAP modify operations, but this would bypass lib389...
That's also a good approach, since cn=config is not subject to large amounts of change.
Thank you again for all the hints Kind Regards Marco _______________________________________________ 389-users mailing list -- 389-users@lists.fedoraproject.org To unsubscribe send an email to 389-users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-users@lists.fedoraproject....
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs, Australia
389-users@lists.fedoraproject.org
-
Marco Favero -
William Brown