Description of problem: Running import-server-key-cert results in error message: Error: 'NoneType' object has no attribute 'get' Version-Release number of selected component (if applicable): 389-ds-base-2.0.10-1.fc34.x86_64 How reproducible: Always Steps to Reproduce: 1. dnf install 389-ds-base cockpit-389-ds 2. create instance.inf, e.g. [general] full_machine_name = ldap.yourdomain.net start = False strict_host_checking = False [slapd] instance_name = localhost root_dn = cn=manager root_password = secret port = 389 secure_port = 636 self_sign_cert = False [backend-userroot] sample_entries = no suffix = dc=yourdomain,dc=net create_suffix_entry = True 3. dscreate from-file instance.inf 4. dsctl localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem ; echo $? Actual results: Error: 'NoneType' object has no attribute 'get' 1 Expected results: 0 Additional info: After downgrading to 2.0.7 the above mentioned command (dsctl localhost tls import-server-key-cert ...) works again as expected: dnf install https://kojipkgs.fedoraproject.org//packages/389-ds-base/2.0.7/1.fc34/noarch/cockpit-389-ds-2.0.7-1.fc34.noarch.rpm https://kojipkgs.fedoraproject.org//packages/389-ds-base/2.0.7/1.fc34/x86_64/389-ds-base-2.0.7-1.fc34.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/389-ds-base/2.0.7/1.fc34/x86_64/389-ds-base-libs-2.0.7-1.fc34.x86_64.rpm https://kojipkgs.fedoraproject.org//packages/389-ds-base/2.0.7/1.fc34/noarch/python3-lib389-2.0.7-1.fc34.noarch.rpm
Hi, thank you for your report. Unfortunately, I can't reproduce your issue. Could you please run dsctl with --verbose and paste full output + traceback? Thanks.
Hi Viktor, Thanks for looking into this. Here's the traceback: # dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='/etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem', key_path='/etc/pki/tls/private/ldap.yourdomain.net/privkey.pem', func=<function import_key_cert_pair at 0x7fa82d2e6280>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: no ip address for b'ldap.yourdomain.net' DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Instance allocated DEBUG: 'NoneType' object has no attribute 'get' Traceback (most recent call last): File "/usr/sbin/dsctl", line 142, in <module> result = args.func(inst, log, args) File "/usr/lib/python3.9/site-packages/lib389/cli_ctl/tls.py", line 47, in import_key_cert_pair tls = NssSsl(dirsrv=inst) File "/usr/lib/python3.9/site-packages/lib389/nss_ssl.py", line 58, in __init__ self._certdb = self.dirsrv.get_cert_dir() File "/usr/lib/python3.9/site-packages/lib389/__init__.py", line 1629, in get_cert_dir return self.ds_paths.cert_dir File "/usr/lib/python3.9/site-packages/lib389/paths.py", line 221, in __getattr__ return ensure_str(self._config.get(SECTION, name).format(instance_name=self._serverid)) AttributeError: 'NoneType' object has no attribute 'get' ERROR: Error: 'NoneType' object has no attribute 'get' Please note that I've changed ldap.yourdomain.net but it's resolvable (there's a valid AAAA record for it, no A record though).
Here's the same command with version 2.0.7: # dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='/etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem', key_path='/etc/pki/tls/private/ldap.yourdomain.net/privkey.pem', func=<function import_key_cert_pair at 0x7f8615d1f700>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Instance allocated DEBUG: Importing key and cert -> /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem, /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem DEBUG: nss cmd: openssl pkcs12 -export -in /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem -inkey /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem -out /etc/dirsrv/slapd-localhost/temp_server_key_cert.p12 -name Server-Cert -passout pass: -aes128 DEBUG: del_cert cmd: /usr/bin/certutil -D -d /etc/dirsrv/slapd-localhost -n Server-Cert -f /etc/dirsrv/slapd-localhost/pwdfile.txt DEBUG: nss cmd: pk12util -v -i /etc/dirsrv/slapd-localhost/temp_server_key_cert.p12 -d /etc/dirsrv/slapd-localhost -k /etc/dirsrv/slapd-localhost/pwdfile.txt -W ''
Must have missed that there's a build of version 2.0.9 on koji yesterday, but I can report that I get the exact same erroneous behaviour with version 2.0.9 as with version 2.0.10. Unfortunately I cannot test version 2.0.9 since that's been deleted: https://koji.fedoraproject.org/koji/buildinfo?buildID=1822845 So the error crept in somewhere between 2.0.7 (good) and 2.0.9 (bad). Maybe this helps narrowing it down.
(In reply to Spike from comment #4) > Unfortunately I cannot test version 2.0.9 > since that's been deleted: > https://koji.fedoraproject.org/koji/buildinfo?buildID=1822845 This of course should read 2.0.8. Sorry, my bad.
Thank you for the additional information, I was able to reproduce it and found the PR that introduced this regression: https://github.com/389ds/389-ds-base/pull/4850 After this PR the detection of local instance is different. When we run dsctl, it is always a local instance, but lib389 thinks differently: [root@server ds]# dsctl -v localhost tls import-server-key-cert ./fullchain.pem ./privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='./fullchain.pem', key_path='./privkey.pem', func=<function import_key_cert_pair at 0x7f1817aaf280>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: no ip address for b'ldap.yourdomain.net' DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Instance allocated > /usr/lib/python3.9/site-packages/lib389/nss_ssl.py(57)__init__() -> self._certdb = dbpath (Pdb) n > /usr/lib/python3.9/site-packages/lib389/nss_ssl.py(58)__init__() -> if self._certdb is None: (Pdb) n > /usr/lib/python3.9/site-packages/lib389/nss_ssl.py(59)__init__() -> self._certdb = self.dirsrv.get_cert_dir() (Pdb) s --Call-- > /usr/lib/python3.9/site-packages/lib389/__init__.py(1628)get_cert_dir() -> def get_cert_dir(self): (Pdb) s > /usr/lib/python3.9/site-packages/lib389/__init__.py(1629)get_cert_dir() -> return self.ds_paths.cert_dir (Pdb) s --Call-- > /usr/lib/python3.9/site-packages/lib389/paths.py(200)__getattr__() -> def __getattr__(self, name): (Pdb) name 'cert_dir' (Pdb) n > /usr/lib/python3.9/site-packages/lib389/paths.py(201)__getattr__() -> from lib389.utils import ensure_str (Pdb) n > /usr/lib/python3.9/site-packages/lib389/paths.py(202)__getattr__() -> if self._defaults_cached is False and self._islocal: (Pdb) self._islocal False For comparison on 2.0.3: [root@server ds]# dsctl -v localhost tls import-server-key-cert ./fullchain.pem ./privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='./fullchain.pem', key_path='./privkey.pem', func=<function import_key_cert_pair at 0x7f3cbced2f70>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Instance allocated > /usr/lib/python3.9/site-packages/lib389/nss_ssl.py(57)__init__() -> self._certdb = dbpath (Pdb) n > /usr/lib/python3.9/site-packages/lib389/nss_ssl.py(58)__init__() -> if self._certdb is None: (Pdb) n > /usr/lib/python3.9/site-packages/lib389/nss_ssl.py(59)__init__() -> self._certdb = self.dirsrv.get_cert_dir() (Pdb) s --Call-- > /usr/lib/python3.9/site-packages/lib389/__init__.py(1617)get_cert_dir() -> def get_cert_dir(self): (Pdb) n > /usr/lib/python3.9/site-packages/lib389/__init__.py(1618)get_cert_dir() -> return self.ds_paths.cert_dir (Pdb) s --Call-- > /usr/lib/python3.9/site-packages/lib389/paths.py(153)__getattr__() -> def __getattr__(self, name): (Pdb) n > /usr/lib/python3.9/site-packages/lib389/paths.py(154)__getattr__() -> from lib389.utils import ensure_str (Pdb) n > /usr/lib/python3.9/site-packages/lib389/paths.py(155)__getattr__() -> if self._defaults_cached is False and self._islocal: (Pdb) self._islocal True Simon, could you please look into this?
Please, fix me if I miss some steps, but I can't reproduce the issue: # rpm -qe 389-ds-base 389-ds-base-2.0.10-1.fc34.x86_64 1. # hostnamectl set-hostname www.example.com 2. Edit /etc/hosts with the hostname and IP address of the local machine 3. Setup 389-ds-base instance for 'www.example.com' (with the instance.inf provided in the first message) 4. # dsctl -v localhost tls import-server-key-cert ./fullchain.pem ./privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='./fullchain.pem', key_path='./privkey.pem', func=<function import_key_cert_pair at 0x7fa09f07bc10>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: Allocate <class 'lib389.DirSrv'> with b'www.example.com':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'www.example.com':636 DEBUG: Instance allocated > /usr/local/lib/python3.9/site-packages/lib389/nss_ssl.py(57)__init__() -> self._certdb = dbpath (Pdb) n > /usr/local/lib/python3.9/site-packages/lib389/nss_ssl.py(58)__init__() -> if self._certdb is None: (Pdb) n > /usr/local/lib/python3.9/site-packages/lib389/nss_ssl.py(59)__init__() -> self._certdb = self.dirsrv.get_cert_dir() (Pdb) s --Call-- > /usr/local/lib/python3.9/site-packages/lib389/__init__.py(1647)get_cert_dir() -> def get_cert_dir(self): (Pdb) s > /usr/local/lib/python3.9/site-packages/lib389/__init__.py(1648)get_cert_dir() -> return self.ds_paths.cert_dir (Pdb) s --Call-- > /usr/local/lib/python3.9/site-packages/lib389/paths.py(200)__getattr__() -> def __getattr__(self, name): (Pdb) name 'cert_dir' (Pdb) n > /usr/local/lib/python3.9/site-packages/lib389/paths.py(201)__getattr__() -> from lib389.utils import ensure_str (Pdb) n > /usr/local/lib/python3.9/site-packages/lib389/paths.py(202)__getattr__() -> if self._defaults_cached is False and self._islocal: (Pdb) self._islocal True
If you leave out (In reply to Simon Pichugin from comment #7) > Please, fix me if I miss some steps, but I can't reproduce the issue: > 1. # hostnamectl set-hostname www.example.com or run hostnamectl set-hostname x with 'x' being anything else but the fqdn (e.g. just the host 'ldap') or reboot with an empty (default) /etc/hostname file (e.g. because the hostname is set through dhcp), you'll run into the error described above: [root@ldap ~]# hostnamectl set-hostname example [root@ldap ~]# dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='/etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem', key_path='/etc/pki/tls/private/ldap.yourdomain.net/privkey.pem', func=<function import_key_cert_pair at 0x7f6a8b331280>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: no ip address for b'ldap.yourdomain.net' DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Instance allocated DEBUG: 'NoneType' object has no attribute 'get' Traceback (most recent call last): File "/usr/sbin/dsctl", line 142, in <module> result = args.func(inst, log, args) File "/usr/lib/python3.9/site-packages/lib389/cli_ctl/tls.py", line 47, in import_key_cert_pair tls = NssSsl(dirsrv=inst) File "/usr/lib/python3.9/site-packages/lib389/nss_ssl.py", line 58, in __init__ self._certdb = self.dirsrv.get_cert_dir() File "/usr/lib/python3.9/site-packages/lib389/__init__.py", line 1629, in get_cert_dir return self.ds_paths.cert_dir File "/usr/lib/python3.9/site-packages/lib389/paths.py", line 221, in __getattr__ return ensure_str(self._config.get(SECTION, name).format(instance_name=self._serverid)) AttributeError: 'NoneType' object has no attribute 'get' ERROR: Error: 'NoneType' object has no attribute 'get' [root@ldap ~]# hostnamectl set-hostname ldap [root@ldap ~]# dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.youdomain.net/fullchain.pem /etc/pki/tls/private/ldap.youdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='/etc/pki/tls/certs/ldap.youdomain.net/fullchain.pem', key_path='/etc/pki/tls/private/ldap.youdomain.net/privkey.pem', func=<function import_key_cert_pair at 0x7f7a5feb3280>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: no ip address for b'ldap.youdomain.net' DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.youdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.youdomain.net':636 DEBUG: Instance allocated DEBUG: 'NoneType' object has no attribute 'get' Traceback (most recent call last): File "/usr/sbin/dsctl", line 142, in <module> result = args.func(inst, log, args) File "/usr/lib/python3.9/site-packages/lib389/cli_ctl/tls.py", line 47, in import_key_cert_pair tls = NssSsl(dirsrv=inst) File "/usr/lib/python3.9/site-packages/lib389/nss_ssl.py", line 58, in __init__ self._certdb = self.dirsrv.get_cert_dir() File "/usr/lib/python3.9/site-packages/lib389/__init__.py", line 1629, in get_cert_dir return self.ds_paths.cert_dir File "/usr/lib/python3.9/site-packages/lib389/paths.py", line 221, in __getattr__ return ensure_str(self._config.get(SECTION, name).format(instance_name=self._serverid)) AttributeError: 'NoneType' object has no attribute 'get' ERROR: Error: 'NoneType' object has no attribute 'get' [root@ldap ~]# hostnamectl set-hostname ldap.possiblelossofprecision.net [root@ldap ~]# dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.youdomain.net/fullchain.pem /etc/pki/tls/private/ldap.youdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='/etc/pki/tls/certs/ldap.youdomain.net/fullchain.pem', key_path='/etc/pki/tls/private/ldap.youdomain.net/privkey.pem', func=<function import_key_cert_pair at 0x7f486bc06280>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.youdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.youdomain.net':636 DEBUG: Instance allocated DEBUG: Importing key and cert -> /etc/pki/tls/private/ldap.youdomain.net/privkey.pem, /etc/pki/tls/certs/ldap.youdomain.net/fullchain.pem DEBUG: nss cmd: openssl pkcs12 -export -in /etc/pki/tls/certs/ldap.youdomain.net/fullchain.pem -inkey /etc/pki/tls/private/ldap.youdomain.net/privkey.pem -out /etc/dirsrv/slapd-localhost/temp_server_key_cert.p12 -name Server-Cert -passout pass: -aes128 DEBUG: del_cert cmd: /usr/bin/certutil -D -d /etc/dirsrv/slapd-localhost -n Server-Cert -f /etc/dirsrv/slapd-localhost/pwdfile.txt DEBUG: nss cmd: pk12util -v -i /etc/dirsrv/slapd-localhost/temp_server_key_cert.p12 -d /etc/dirsrv/slapd-localhost -k /etc/dirsrv/slapd-localhost/pwdfile.txt -W '' This used to not be the case with versions <= 2.0.7 (potentially also 2.0.8, see above)
Copy and paste is hard. Of course, the last command (In reply to Spike from comment #8) > [root@ldap ~]# hostnamectl set-hostname ldap.possiblelossofprecision.net > [root@ldap ~]# dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.youdomain.net/fullchain.pem /etc/pki/tls/private/ldap.youdomain.net/privkey.pem > DEBUG: The 389 Directory Server Administration Tool > DEBUG: Inspired by works of: ITS, The University of Adelaide ... needs to read: [root@ldap ~]# hostnamectl set-hostname ldap.yourdomain.net [root@ldap ~]# dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide Othewise the comment above makes no sense. Sorry about that.
Simon, to reproduce use ldap.youdomain.net exactly, as it doesn't resolve to an IP address: > DEBUG: no ip address for b'ldap.yourdomain.net' I just found that this was fixed in https://github.com/389ds/389-ds-base/issues/4959 https://github.com/389ds/389-ds-base/pull/4960 Now it also prints a message about incorrect configuration: # dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='/etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem', key_path='/etc/pki/tls/private/ldap.yourdomain.net/privkey.pem', func=<function import_key_cert_pair at 0x7fefee9ac280>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: no ip address for b'ldap.yourdomain.net' DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Instance allocated DEBUG: Invalid state No paths config (defaults.inf) could be found. This may be because the remote instance is offline, or your /etc/hosts is misconfigured for a local instance Traceback (most recent call last): File "/usr/sbin/dsctl", line 142, in <module> result = args.func(inst, log, args) File "/usr/lib/python3.9/site-packages/lib389/cli_ctl/tls.py", line 47, in import_key_cert_pair tls = NssSsl(dirsrv=inst) File "/usr/lib/python3.9/site-packages/lib389/nss_ssl.py", line 58, in __init__ self._certdb = self.dirsrv.get_cert_dir() File "/usr/lib/python3.9/site-packages/lib389/__init__.py", line 1629, in get_cert_dir return self.ds_paths.cert_dir File "/usr/lib/python3.9/site-packages/lib389/paths.py", line 226, in __getattr__ raise LookupError("""Invalid state LookupError: Invalid state No paths config (defaults.inf) could be found. This may be because the remote instance is offline, or your /etc/hosts is misconfigured for a local instance ERROR: Error: Invalid state No paths config (defaults.inf) could be found. This may be because the remote instance is offline, or your /etc/hosts is misconfigured for a local instance So if I add 127.0.0.1 ldap.yourdomain.net to /etc/hosts, dsctl works as expected. # dsctl -v localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem DEBUG: The 389 Directory Server Administration Tool DEBUG: Inspired by works of: ITS, The University of Adelaide DEBUG: Called with: Namespace(verbose=True, instance='localhost', json=False, list=False, remove_all=False, cert_path='/etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem', key_path='/etc/pki/tls/private/ldap.yourdomain.net/privkey.pem', func=<function import_key_cert_pair at 0x7feb29927280>) DEBUG: Allocate <class 'lib389.DirSrv'> with None DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Allocate <class 'lib389.DirSrv'> with b'ldap.yourdomain.net':636 DEBUG: Instance allocated DEBUG: Importing key and cert -> /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem, /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem DEBUG: nss cmd: openssl pkcs12 -export -in /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem -inkey /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem -out /etc/dirsrv/slapd-localhost/temp_server_key_cert.p12 -name Server-Cert -passout pass: -aes128 DEBUG: del_cert cmd: /usr/bin/certutil -D -d /etc/dirsrv/slapd-localhost -n Server-Cert -f /etc/dirsrv/slapd-localhost/pwdfile.txt DEBUG: nss cmd: pk12util -v -i /etc/dirsrv/slapd-localhost/temp_server_key_cert.p12 -d /etc/dirsrv/slapd-localhost -k /etc/dirsrv/slapd-localhost/pwdfile.txt -W '' Spike, could you please check if adding an entry in /etc/hosts solves your issue? Thanks.
(In reply to Viktor Ashirov from comment #10) > could you please check if adding an entry in /etc/hosts solves your issue? It does. However, that shouldn't be necessary since ldap.yourdomain.net has a vaild AAAA record (no IPv4 tough) and the host I'm running 389ds on has that exact IP: # dig ldap.yourdomain.net -t AAAA +short 2003:somethingsomething:9a52 # ip a | grep 2003 inet6 2003:somethingsomething:9a52/64 scope global dynamic noprefixroute Adding "127.0.0.1 ldap.yourdomain.net" messes with all sorts of stuff (e.g. dig does not return the AAAA record any more). I'd prefer not to resort to those types of hacks.
Thank you for clarification. Indeed, we're only checking for IPv4 address: https://github.com/389ds/389-ds-base/blob/0552081fe736b5c86d3c7e3d640f8a8b170d1dc6/src/lib389/lib389/utils.py#L673-L681 # first lookup ip addr try: ip_addr = socket.gethostbyname(host_name) if ip_addr.startswith("127."): # log.debug("this ip is on loopback, retain only the first octet") ip_addr = '127.' except socket.gaierror: log.debug("no ip address for %r" % host_name) return False gethostbyname() does not support IPv6 name resolution, and getaddrinfo() should be used instead.
So what's the recommended way forward? There's no mention of '/etc/hosts' in the documentation https://access.redhat.com/documentation/en-us/red_hat_directory_server/11/html-single/administration_guide/index. The defaults in '/usr/share/dirsrv/inf/defaults.inf' that are shipped with 389-ds-base seem to be correct. All of the paths seem to match (e.g. the config dir of my instance is at '/etc/dirsrv/slapd-{instance_name}' in accordance with '/usr/share/dirsrv/inf/defaults.inf'). I've tried the patch from https://github.com/389ds/389-ds-base/pull/4960 and indeed now I get the error message: ERROR: Error: Invalid state No paths config (defaults.inf) could be found. This may be because the remote instance is offline, or your /etc/hosts is misconfigured for a local instance
There's no fundamental difference in https://github.com/389ds/389-ds-base/blob/0552081fe736b5c86d3c7e3d640f8a8b170d1dc6/src/lib389/lib389/utils.py#L673-L681 and how the state of 'isLocal' was determined before. However, 'allocate' in src/lib389/lib389/__init__.py assumed 'isLocal' to be True up to and including 2.0.7 https://github.com/389ds/389-ds-base/commit/434d680338755bbd91b5fc1c9f96b14572a68976#diff-10fad34fdcb9556b5901c8f5a1532a4caea0f316546d292ecd30da9b9a6593afL530 and 'isLocal' to be False starting with 2.0.8 https://github.com/389ds/389-ds-base/commit/434d680338755bbd91b5fc1c9f96b14572a68976#diff-10fad34fdcb9556b5901c8f5a1532a4caea0f316546d292ecd30da9b9a6593afR552 That ties in directly to what Viktor said earlier: (In reply to Viktor Ashirov from comment #6) > Thank you for the additional information, I was able to reproduce it and > found the PR that introduced this regression: > https://github.com/389ds/389-ds-base/pull/4850 > > After this PR the detection of local instance is different. > When we run dsctl, it is always a local instance, but lib389 thinks > differently: And indeed if I apply this (very much unsound patch): --- /usr/lib/python3.9/site-packages/lib389/__init__.py.bak 2021-11-05 12:45:41.127587471 +0100 +++ /usr/lib/python3.9/site-packages/lib389/__init__.py 2021-11-05 12:45:55.705377774 +0100 @@ -549,7 +549,7 @@ self.inst_scripts = args.get(SER_INST_SCRIPTS_ENABLED, None) - self.isLocal = False + self.isLocal = True # Or do we have tcp / ip settings? if self.ldapi_enabled == 'on' and self.ldapi_socket is not None: self.ldapi_autobind = args.get(SER_LDAPI_AUTOBIND, 'off') dsctl localhost tls import-server-key-cert /etc/pki/tls/certs/ldap.yourdomain.net/fullchain.pem /etc/pki/tls/private/ldap.yourdomain.net/privkey.pem; echo $? 0 I imagine it's quite tricky to fix https://github.com/389ds/389-ds-base/blob/0552081fe736b5c86d3c7e3d640f8a8b170d1dc6/src/lib389/lib389/utils.py#L673-L681 to work properly in all IPv6 environments where there might only be a publicly routable and/or a link local address. Maybe one should continue to assume 'isLocal' to be true in lib389/__init__.py until detected otherwise (as it seemed to be the case up to 2.0.7)?
(In reply to Spike from comment #14) > I imagine it's quite tricky to fix > https://github.com/389ds/389-ds-base/blob/ > 0552081fe736b5c86d3c7e3d640f8a8b170d1dc6/src/lib389/lib389/utils.py#L673- > L681 to work properly in all IPv6 environments where there might only be a > publicly routable and/or a link local address. Maybe one should continue to > assume 'isLocal' to be true in lib389/__init__.py until detected otherwise > (as it seemed to be the case up to 2.0.7)? Just food for thought: Up to and including 2.0.7 there didn't need to be a valid DNS record for the 389ds instance when running `dsctl localhost tls import-server-key-cert...' (I've just tried it out). It'd work without any '/etc/hosts' hacks and any DNS record (A or AAAA) because it just assumed 'isLocal' to be True when running dsctl. This is particularly useful when dynamically provisioning 389-ds instances (think ansible, puppet, salt) since the DNS record might take a while to appear. As a user I very much prefer this behaviour.
(In reply to Spike from comment #13) > So what's the recommended way forward? We should fix local instance detection (in IPv6 case and with strict_host_checking = False). I've reopened upstream issue: https://github.com/389ds/389-ds-base/issues/4959 Feel free to add your comments there as well. Thanks!
Hmm... Isn't 'dsctl' always local anyway? Why not do inst.local_simple_allocate(insts[0]['server-id']) here https://github.com/389ds/389-ds-base/blob/ef93bea49ff395855e9d7665b6a3fa55f46a1f3b/src/lib389/cli/dsctl#L140
This was fixed upstream with https://github.com/389ds/389-ds-base/commit/55fb438a41789ae4daa35d18a65be2c918e75b24 An update is available for Fedora 36+: https://bodhi.fedoraproject.org/updates/?search=389-ds-base
This message is a reminder that Fedora Linux 34 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 34 on 2022-06-07. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '34'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 34 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
Fedora Linux 34 entered end-of-life (EOL) status on 2022-06-07. Fedora Linux 34 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. Thank you for reporting this bug and we are sorry it could not be fixed.