QA » openQA Project » openQA Tests » qe-yam

created PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/9250

I tried to find if we could easily adapt the module, it seems not. It will require more investigation, especially that the bug is not clear and looks like we have a different issue in SLE and TW.
In SLE we have could not find certificate
While in TW we have invalid credentials

PR to disable the module https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/10270

I renewed the key, but that was not the issue - though at least it allowed me to go ahead. It looks like now we have to use "cn=Directory Manager" instead of "cn=root" : https://openqa.opensuse.org/tests/1275011#step/yast2_samba/62. We see this cn here : https://openqa.opensuse.org/tests/1275011#step/yast2_samba/15.
Also now, we have two new bugs. I'll report them on monday.

You probably should be checking that connection with Anonymous, not Directory Manager, or another test account, but yes, we removed the ability to change the admin dn :)

I reported this https://bugzilla.opensuse.org/show_bug.cgi?id=1172084. As for the bug in SLE, I try to understand why we are using a workaround that does not point to a bug report here https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/536d1fb618b99b81b9b63d8816b4f1e242f1f294/tests/console/yast2_samba.pm#L94.

Collection of bugs for reference:
https://bugzilla.suse.com/show_bug.cgi?id=1117643
https://bugzilla.suse.com/show_bug.cgi?id=1083328
https://bugzilla.suse.com/show_bug.cgi?id=1068900#c5

In those bug reports, it appears that yast2-ldap is pretty much abandoned, and yast2-samba is not maintained by yast team. I wonder if it should be supported at all in these conditions.

Reading those issues you linked, I think they somewhat fall into my jurisdiction to enable the schema to make this work.

I think that https://bugzilla.opensuse.org/show_bug.cgi?id=1172084, https://bugzilla.suse.com/show_bug.cgi?id=1083328, and https://bugzilla.suse.com/show_bug.cgi?id=1068900#c5 are all the same issue. I believe when I saw and commented on these in the past, I was still very new to SUSE and did not fully understand the context of the bug report, so for that I'm sorry.

1117643 is not related to this, so I think that needs to be looked at seperately.

So I have taken 1083328, and I'll treat that as the BZ that I need to resolve.

I have also opened the following upstream issue: https://pagure.io/389-ds-base/issue/51115

So leave this up to me, I will resolve it hopefully in the next week, and then pending an upstream patch release we can get it into SLE proper ASAP.

Sounds like a plan. And of course, please stay in contact so we can resolve these tests and get it all working. Thanks so much for your patience in this!

https://pagure.io/389-ds-base/pull-request/51126

Upstream PR made,

I was asked to explain how the new certificates were generated, so here it is. I adapted the way that it had been done last time, see https://bugzilla.suse.com/show_bug.cgi?id=1088152#c8 though as-is it did not work and needed to be adapted.

I adapted this file https://jamielinux.com/docs/openssl-certificate-authority/appendix/root-configuration-file.html

root@~/ca # diff root-config.txt openssl-ca.cnf

13c13
< new_certs_dir     = $dir/newcerts
---
> new_certs_dir     = $dir/certs
19,20c19,20
< private_key       = $dir/private/ca.key.pem
< certificate       = $dir/certs/ca.cert.pem
---
> private_key       = $dir/private/ca_key.pem
> certificate       = $dir/certs/ca_cert.pem
81,86c81,86
< countryName_default             = GB
< stateOrProvinceName_default     = England
< localityName_default            =
< 0.organizationName_default      = Alice Ltd
< organizationalUnitName_default  =
< emailAddress_default            =
---
> countryName_default             = DE
> stateOrProvinceName_default     = Bayern
> localityName_default            = Nuremberg
> 0.organizationName_default      = Suse
> organizationalUnitName_default  = QA
> emailAddress_default            = ca_qa@suse.de

then from my commands history, steps seem to be:

mkdir csr private certs

1. Create a CA
# ca key
openssl genrsa -out private/ca_key.pem
# ca cert
openssl req -config openssl-ca.cnf -key private/ca_key.pem -new -x509 -days 7300 -extensions v3_ca -out certs/ca_cert.pem -nodes

2. Create server key & cert
# server key
 openssl genrsa -out private/server_key.pem 2048
#server cert
openssl req -new -config openssl-ca.cnf -key private/server_key.pem -out csr/server_csr.pem -nodes -days 7300

3. Sign server cert by ca
openssl ca -config openssl-ca.cnf -extensions server_cert -days 7300 -notext -md sha256 -in csr/server_csr.pem -out certs/server_cert.pem

4. Export signed server cert & key to pkcs12 format
openssl pkcs12 -export -nodes -CAfile certs/ca_cert.pem -inkey private/server_key.pem -in certs/server_cert.pem -out server_cert.pfx

... rename server key and p12 files and copied to server.
specified empty passwords when possible.

firstyear wrote:

https://pagure.io/389-ds-base/pull-request/51126

Upstream PR made,

Hello @firstyear, I see that the bsc#1172084 is still happening on Tumbleweed - see here https://openqa.opensuse.org/tests/1345057#step/yast2_samba/70 - I guess the upstream PR never reached the required package in OBS ?

No, 1.4.4.4 is in tumbleweed, so this must be a different error. I'd need to see the content of /var/log/dirsrv, journalctl -b, the yast logs, and probably rpm -qa to know what's going wrong here ... :(

Following this issue here https://bugzilla.opensuse.org/show_bug.cgi?id=1172084, As the source of issue seem to be still [ 441.942193] ns-slapd[2888]: [26/May/2020:03:26:52.650749532 -0400] - ERR - slapi_entry_schema_check_ext - Entry "sambaDomainName=QA-SAMBA,dc=ldaptest,dc=org" has unknown object class "sambaDomain". I can add more logs/info to that report if needed.

JRivrain wrote:

firstyear wrote:

No, 1.4.4.4 is in tumbleweed, so this must be a different error. I'd need to see the content of /var/log/dirsrv, journalctl -b, the yast logs, and probably rpm -qa to know what's going wrong here ... :(

Attached dirsrv logs, and you will find all the rest here https://openqa.opensuse.org/tests/1352957/file/yast2_samba-y2logs.tar.bz2. It may be (again) that we are doing something wrong on our side... I'll also try to see if I see something obvious, though I think you know a lot more about the matter, so your help is greatly appreciated here :)

Sorry I missed this update, I have been quite busy lately. I'll investigate shortly. Next time you make a tar though, can you add a top level directory please :)

I started to review this then I immediately realised the issue:

# rpm -qa | grep -i 389-ds
389-ds-1.4.4.3~git0.7b79b89c1-1.3.x86_64

The 1.4.4.4 update is in the feeder project for tumbleweed:

https://build.opensuse.org/package/show/network:ldap/389-ds

So I guess you need to wait for this update to flow through the magic pipeline to arrive to you. I have no idea where it is or how that works because I really don't understand OBS beyond a superficial level, so maybe someone else can help push it along ....

Hi, thanks for the update, and sorry for the archive !

See for the reason of tracker change: http://mailman.suse.de/mailman/private/qa-sle/2020-October/002722.html

I don't have access to this mailing list I think, so I'm unable to see the reason sorry.

@szarate can you please forward me the information from the mailing list in question? wbrown at suse.de please.

firstyear wrote:

JRivrain wrote:

firstyear wrote:

No, 1.4.4.4 is in tumbleweed, so this must be a different error. I'd need to see the content of /var/log/dirsrv, journalctl -b, the yast logs, and probably rpm -qa to know what's going wrong here ... :(

Attached dirsrv logs, and you will find all the rest here https://openqa.opensuse.org/tests/1352957/file/yast2_samba-y2logs.tar.bz2. It may be (again) that we are doing something wrong on our side... I'll also try to see if I see something obvious, though I think you know a lot more about the matter, so your help is greatly appreciated here :)

Sorry I missed this update, I have been quite busy lately. I'll investigate shortly. Next time you make a tar though, can you add a top level directory please :)

I started to review this then I immediately realised the issue:

# rpm -qa | grep -i 389-ds
389-ds-1.4.4.3~git0.7b79b89c1-1.3.x86_64

The 1.4.4.4 update is in the feeder project for tumbleweed:

https://build.opensuse.org/package/show/network:ldap/389-ds

So I guess you need to wait for this update to flow through the magic pipeline to arrive to you. I have no idea where it is or how that works because I really don't understand OBS beyond a superficial level, so maybe someone else can help push it along ....

I see that 389-ds is now in version 1.4.4.9 in Sle 15 sp3 beta 3 (2.0.1 in Tumbleweed) and yet we still see the same bug happening: https://openqa.opensuse.org/tests/1587572#step/yast2_samba/68. Bugs 1177302 and 1172084 have not been updated yet. The errors in the serial output still look identical as in may, I wonder if the certificate I generated back then were actually proper. To be honest I do not understand those error messages.

Added the test suite in OSD sle15 development jobgroup and re-created needles, the same bug occurs there. Then once it's fixed, we can put the test suite back in production both on OOO and OSD.