[389-devel] Re: Ticket 48798 - CI and lib389 tests fail
On Fri, 2016-06-10 at 19:39 +0200, Simon Pichugin wrote: > Hi William, > unfortunatly, soon I'll leave for a long PTO and now I need to finish a lot > of different running stuff. > > Can you, please, finish with your broken patches? > Here is the fix: https://fedorahosted.org/389/attachment/ticket/48886/0001-Ticket-48886-Fix-NSS-SSL-library-in-lib389.patch -- Sincerely, William Brown Software Engineer Red Hat, Brisbane signature.asc Description: This is a digitally signed message part -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
[389-devel] Re: Ticket 48798 - CI and lib389 tests fail
On Fri, 2016-06-10 at 19:39 +0200, Simon Pichugin wrote: > Hi William, > unfortunatly, soon I'll leave for a long PTO and now I need to finish a lot > of different running stuff. > > Can you, please, finish with your broken patches? > > I am prepared a script for you. With the script you'll be able to set up > an environment on any VM. Just reserve some new clean VM or create your own, > run the script and then run the ticket48798.py. It should fail after this. > > I will available a few of following days, so I answer questions, if you'd > have some. > > It's okay. You have my word that this week, I will investigate this script, and see what happens. Can I ask what distro / platform you are testing on so I can re-create? > On Fri, Jun 10, 2016 at 10:43:44AM +1000, William Brown wrote: > > > > 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 > > > >() is True > > > > E+ where > > > > = > > > > ._rsa_ca_exists > > > > E+where = > > > > > > > 0x7f13b553dbd8>.nss_ssl > > > > E+ where = > > > > > > > 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
[389-devel] Re: Ticket 48798 - CI and lib389 tests fail
Hi William,
unfortunatly, soon I'll leave for a long PTO and now I need to finish a lot
of different running stuff.
Can you, please, finish with your broken patches?
I am prepared a script for you. With the script you'll be able to set up
an environment on any VM. Just reserve some new clean VM or create your own,
run the script and then run the ticket48798.py. It should fail after this.
I will available a few of following days, so I answer questions, if you'd have
some.
Thanks,
Simon
On Fri, Jun 10, 2016 at 10:43:44AM +1000, William Brown wrote:
> 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 > > >() is True
> > > E+ where > > > =
> > > ._rsa_ca_exists
> > > E+where =
> > > .nss_ssl
> > > E+ where =
> > > > > 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 = , secport = 636,
> > secargs = {'nsSSL3Ciphers': '+all'}
> >
> > def enable_ssl(self, secport=636, secargs=None):
> > """Configure SSL support into cn=encryption,cn=config.
> >
> >
[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 > >() is True
> > E+ where > > =
> > ._rsa_ca_exists
> > E+where =
> > .nss_ssl
> > E+ where =
> > > 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 = , 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'
Ahh 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
signature.asc
Description: This is a digitally signed message part
--
389-devel mailing list
389-devel@lists.fedoraproject.org
[389-devel] Re: Ticket 48798 - CI and lib389 tests fail
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?
>
> 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 object at 0x7f13b4de3ed0>>() is True
> E+ where > =
> ._rsa_ca_exists
> E+where =
> .nss_ssl
> E+ where =
> 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.
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.
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.
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. :)
Additionaly, I have the next error:
self = , 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'
But I didn't look into this still. If you want I'll do it tomorrow.
Thanks,
Simon
>
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Brisbane
>
signature.asc
Description: PGP signature
--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
[389-devel] Re: Ticket 48798 - CI and lib389 tests fail
Note: Resent due to earlier technical issues. 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? ;) 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 >() is True E+ where > = ._rsa_ca_exists E+where = .nss_ssl E+ where = .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, -- Sincerely, William Brown Software Engineer Red Hat, Brisbane signature.asc Description: This is a digitally signed message part -- 389-devel mailing list 389-devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/389-devel@lists.fedoraproject.org
