On 11/17/2016 11:22 AM, Rob Crittenden wrote:
Noriko Hosoi wrote:
On 11/17/2016 06:36 AM, Rob Crittenden wrote:
William Brown wrote:
https://fedorahosted.org/389/ticket/49041
https://fedorahosted.org/389/attachment/ticket/49041/0001-Ticket-49041-SSL-fails-to-start-due-to-NSS-db-versio.patch
I think this should be reviewed urgently and backported. This can cause
SSL to fail to start on F24 and higher without explanation.
key4.db and cert9.db are the sqlite databases. Does 389-ds support
specifying sql:/path/to/database/dir?
rob
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
We have a plan to switch [1] but when we discussed in the team, we
concluded it was not urgent. I don't think NSS stops supporting the old
BDB format very soon?
Hi Rob,
I'm also not sure if we should migrate to sqlite format or not. And if
we do when we should... When I worked on it 8 months ago, it was
deferred since it was not urgent. :)
My question revolves around how likely this is to happen to make it
urgent. If 389-ds doesn't support sqlite databases then how are
key4/cert9 files going to end up being created?
The current version does not support sqlite format (as William
reported). Once we apply the patch in [1], it generates sqlite format
cert db's. (Test case is also attached.)
Or is sqlite now the
default format for the NSS utilities so merely using certutil would
generate them?
In terms of the upgrade, NSS provides the method, doesn't it? Like once
opening the old format by, e.g., certutil with some option, it
automatically updates the format? Then, we could rename the files to
the new names? I guess we should prepare an upgrade script to do the
task which is executed in the rpm -U?
Any advice would be greatly appreciated...
Thanks!
--noriko
rob
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
389-devel mailing list -- 389-devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to 389-devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
