5:58 a.m.
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
8:22 p.m.
On 28 Jan 2021, at 21:58, Marco Favero <m.faverof(a)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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
2:46 a.m.
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
3:54 a.m.
[...]
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
7:55 p.m.
On 29 Jan 2021, at 19:54, Marco Favero <m.faverof(a)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:
https://spichugi.fedorapeople.org/html/plugin.html
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(a)lists.fedoraproject.org
To unsubscribe send an email to 389-users-leave(a)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.fedoraproje...
—
Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server
SUSE Labs, Australia
1173
days inactive
1177
days old
389-users@lists.fedoraproject.org
4 comments
2 participants
participants (2)
-
Marco Favero -
William Brown