[389-devel] Re: Ticket 48798 - CI and lib389 tests fail

On Thu, 2016-06-09 at 22:11 +0200, Simon Pichugin wrote:
> Hi William,
>
> On Thu, Jun 09, 2016 at 10:12:29AM +1000, William Brown wrote:
> >
> > On Wed, 2016-06-08 at 17:52 +0200, Simon Pichugin wrote:
> > >
> > > Hi William,
> > >
> > > I troubleshoot failures at the tickets.
> > > And both tickets/ticket48798_test.py and lib389/tests/nss_ssl_test.py
> > > fail because of the same problem. 
> > > As I understand this is because of class design issue (lib389/nss_ssl.py).
> > >
> > > Can you please take a look? May be you've already faced that issue and
> > > can help me with the problem, so it would resolve faster. :)
> > >
> > > Please, find the log output in the attachment.
> > >
> > > Thanks,
> > > Simon
> > I haven't seen this issue before. "works for me" right, so it's not a bug? ;) 
> Did you test it on clean environment?

Always yes.

>
> >
> >
> > Joking aside, looking at that trace, the assert failing is that the CA failed to validate post create. 
> >
> >         # Check if ca exists. Should be false.
> >         assert(topology.standalone.nss_ssl._rsa_ca_exists() is False)
> >         # Create it. Should work.
> >         assert(topology.standalone.nss_ssl.create_rsa_ca() is True)
> >         # Check if ca exists. Should be true
> > >
> > >        assert(topology.standalone.nss_ssl._rsa_ca_exists() is True)
> > E       assert <bound method NssSsl._rsa_ca_exists of <lib389.nss_ssl.NssSsl object at 0x7f13b4de3ed0>>() is True
> > E        +  where <bound method NssSsl._rsa_ca_exists of <lib389.nss_ssl.NssSsl object at 0x7f13b4de3ed0>> =
> > <lib389.nss_ssl.NssSsl object at 0x7f13b4de3ed0>._rsa_ca_exists
> > E        +    where <lib389.nss_ssl.NssSsl object at 0x7f13b4de3ed0> = <lib389.DirSrv instance at 0x7f13b553dbd8>.nss_ssl
> > E        +      where <lib389.DirSrv instance at 0x7f13b553dbd8> = <lib389.tests.nss_ssl_test.TopologyStandalone object at
> > 0x7f13b4df8210>.standalone
> >
> > lib389/tests/nss_ssl_test.py:71: AssertionError
> >
> >
> > I would think the error is occuring in:
> >
> >         assert(topology.standalone.nss_ssl.create_rsa_ca() is True)
> >
> > This may erroneously be returning True.
> >
> > It would be worth preventing the instance from being removed, and checking the output of the ssl directory.
> >
> > Have a look at say (depending on your install prefix ...):
> >
> > cd [/opt/dirsrv]/etc/dirsrv/slapd-standalone
> > certutil -L -d .
> >
> > You could also dump the result of the check call, or even the command line string it uses and run it by hand. Look at line
> > 147 of nss_ssl.py. Maybe we could add some better logging in / around these parts for future if we have this error again?
> >
> > The reason I think the error is in create_rsa_ca, is because in _rsa_ca_exists(), there is basically no error checking. It's
> > designed to "fail fast", in the cast there is no CA or DB. Because it's returning a "False", which triggers the assert, it
> > means the CA check is probably working, and telling the truth.
> >
> >
> > Does that help? If you need anything else, let me know,
> So I am in the process of investigation, but today I am already drained out,
> so I will share what I've found and go to sleep.
>
> Certutil shows that CA cert was successfully added.

Can you paste me the output?

>
> If I comment only "#assert(topology.standalone.nss_ssl._rsa_ca_exists() is False)",
> then "assert(topology.standalone.nss_ssl._rsa_ca_exists() is True)" is passed.

The whole test passes? Hmmm, maybe there is a fault in the CA detection code like you suspected .... 

>
> If I additionally comment "#assert(topology.standalone.nss_ssl._rsa_key_and_cert_exists() is False)",
> then "assert(topology.standalone.nss_ssl._rsa_ca_exists() is True)" is failed again.

I don't quite understand this sorry, I'll need to look :) 

>
> And it is pretty weird. I think all of this happens because of
> not proper created NssSsl class (something was messed out with "bound",
> "nonbound" and "static" methods AND/OR something wrong with nss_init
> opened every function and not closed). But I am still not sure where is the
> problem can be, it is only suggestions. :)

The python NSS types are pretty gnarly. It's basically a thin wrapper to the C api. So it gets messy *fast*. 

>
> Additionaly, I have the next error:
>
> self = <lib389.config.Config object at 0x7f418cdf50d0>, secport = 636, secargs = {'nsSSL3Ciphers': '+all'}
>
>     def enable_ssl(self, secport=636, secargs=None):
>         """Configure SSL support into cn=encryption,cn=config.
>
>                 secargs is a dict like {
>                     'nsSSLPersonalitySSL': 'Server-Cert'
>                 }
>             """
> >
> >       if self.deprecation_strict:
> E       AttributeError: 'Config' object has no attribute 'deprecation_strict'

Ahhhhhh that's my mistake there on that one as a result of 48820. Just remove the "if self.deprecation_strict:" and related
lines.

>
> But I didn't look into this still. If you want I'll do it tomorrow.
>

We really need a shared VM we can work on some of these issues together I think sometimes :) I might setup something for this
purpose. 


--
Sincerely,

William Brown
Software Engineer
Red Hat, Brisbane