Re: lib389 question

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 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
_______________________________________________
389-users mailing list -- 389-users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-users-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx




[Index of Archives]     [Fedora User Discussion]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora News]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora QA]     [Fedora Triage]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Yosemite Photos]     [Linux Apps]     [Maemo Users]     [Gnome Users]     [KDE Users]     [Fedora Tools]     [Fedora Art]     [Fedora Docs]     [Maemo Users]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Fedora ARM]

  Powered by Linux