G'day Frank.
On 23/04/13 23:42, Frank Ch. Eigler wrote:
> ...
>> Note that $NSS_DEFAULT_DB_TYPE is not an option as this apparently
>> intended for compatibility support in the other direction,
>> as "sql" appears to be the only well-defined value for this
>> environment variable to enable the "new" method.
>
> Can you elaborate please? The model of this variable is that even if
> it is set to "sql" (with certificate file names unadorned by the sql:
> prefix), older versions of NSS such as on RHEL5 will ignore it, and
> use plain berkeleydb data files. Current versions of NSS will use it
> as an implicit prefix. What's not suitable about this?
I don't see evidence of NSS_DEFAULT_DB_TYPE helping at all in my situation.
Here's a typical session ...
kenj@vm04:~$ env | egrep 'PCP|NSS'
kenj@vm04:~$ ls -l ~/.pki
ls: /home/kenj/.pki: No such file or directory
kenj@vm04:~$ pmprobe sample.long.one
[Wed Apr 24 06:59:03] pmprobe(32133) Warning: __pmConnectPMCD: certificate
database exists, but failed initialization
sample.long.one 1
This warning is the problem that is breaking QA and is a regression over
previous behaviour.
I believe it is because this empty directory structure is created (I still
believe this creation is bogus, but that is another discussion I'm apparently
not winning ...)
kenj@vm04:~$ ls -lR ~/.pki
/home/kenj/.pki:
total 4
drwx------ 2 kenj kenj 4096 Apr 24 06:59 nssdb
/home/kenj/.pki/nssdb:
total 0
And further I believe it is because our code is using the sql: prefix when it
tries to (again bogusly IMHO) load certificates even though the client has no
interest in secure sockets (and indeed there is no certificate for pmcd in this
installation).
This produces the same result (as expected)
kenj@vm04:~$ export NSS_DEFAULT_DB_TYPE=sql
kenj@vm04:~$ pmprobe sample.long.one
[Wed Apr 24 07:00:10] pmprobe(32140) Warning: __pmConnectPMCD: certificate
database exists, but failed initialization
sample.long.one 1
And this does not help (also as expected, since 'sql' seems to be the only
acceptable value for $NSS_DEFAULT_DB_TYPE)
kenj@vm04:~$ export NSS_DEFAULT_DB_TYPE=
kenj@vm04:~$ pmprobe sample.long.one
[Wed Apr 24 07:05:54] pmprobe(32163) Warning: __pmConnectPMCD: certificate
database exists, but failed initialization
sample.long.one 1
But this does fix the regression.
kenj@vm04:~$ unset NSS_DEFAULT_DB_TYPE
kenj@vm04:~$ export PCP_SECURE_DB_METHOD=
kenj@vm04:~$ pmprobe sample.long.one
sample.long.one 1
> (I believe nathans was going to test modern NSS's behavior about its
> run-time searching behavior, in case sql: or non-sql: databases are
> found in its target directory. It may turn out that this
> $NSS_DEFAULT_DB_TYPE-or-equivalent need only be specified
> once: at certificate db creation time.)
Maybe, but my evidence suggests it is load certificate time that is the problem.
Now having said all this, my "fix" addresses the regression ... I still have
not had any success in making secure sockets actually work on this platform,
although I can clearly create berkeley-style databases.
|