find centralized location for NIST PKITS/PDVAL files

Status

P2
normal
11 years ago
4 years ago

People

(Reporter: alvolkov.bgs, Assigned: slavomir.katuscak+mozilla)

Tracking

(Depends on: 1 bug)

trunk
3.12.4
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: PKIXTEST)

(Reporter)

Description

11 years ago
There is a way to make extended test coverage, besides the basic unit tests that are run by default. The extended test coverage can be enabled by setting two environment variables to point to extra certs and crls. These variables are:  

NIST_FILES_DIR=/home/volkov/pkix-tests/certs_and_crl
PDVAL=/home/volkov/pkix-tests/nist_pdval

Currently they point to archived certs/crls tests in my home directory, that may not be available on all the test machines.

The goal of this bug is to find a centralized location for those certstores and use the in every all.sh run.
(Reporter)

Updated

11 years ago
Blocks: 396598
Priority: -- → P1
Whiteboard: PKIXTEST
Whiteboard: PKIXTEST → PKIXTEST NSS312B2
Version: 3.12 → trunk
(Assignee)

Updated

11 years ago
Depends on: 232894

Updated

11 years ago
Priority: P1 → P2

Comment 1

11 years ago
This is more of an internal environment issue. There is probably nothing to check in to mozilla CVS.
Priority: P2 → P1
Summary: enable libpkix tests to use NIST certificates. → find centralized location for NIST PKITS/PDVAL files

Updated

11 years ago
Priority: P1 → P2
(Assignee)

Comment 2

11 years ago
Suggested steps:
1. Copy PKITS data to /share/builds/mccrel3/security/PKITS_DATA.
2. Modify scripts to use PKITS_DATA variable instead of NIST_FILES_DIR and PDVAL (only one variable, the same one as in pkits.sh).
3. Change nightly testing scripts and Tinderbox to use PKITS=/share/builds/mccrel3/security/PKITS_DATA if available.

Alexei, please let me know if this is OK with you or if you have some better suggestion what to do.
(Reporter)

Comment 3

11 years ago
I'm fine with the name and location.

As far as I know, we didn't use nfs shared files in our testing so far. I'm wondering about testing slowdown and reliability: sometimes we have problems with nfs.

Tinderbox script/test scripts may be updated to have a functionality that will copy the directory once and use local location for tests until we have an update. There are numbers of ways how you can effectively identify that directory has been changed without assessing all files in the remote directory.

Lets try to see with your change and work the problem out if we have it.
Testing should rely on NFS as little as possible. 
I suggest doing something like this pseudo-code:
  if (files are not locally available)
      copy test files to local directory.
      If that does not succeed, fail this test.
  Run test with local copy of test files.

It would be best to do the copy using a single compressed archive (e.g. tgz 
or zip) and some non-NFS copy program such as ftp or rcp, then unpack the 
files from the compressed archive locally.  
(Assignee)

Comment 5

11 years ago
For nightly testing it doesn't make much sense to have local copy - build directories (builds are shared) and results directories are all on network drive (jesbuild.red.iplanet.com:/export/builds/mccrel3), having there also PKITS data will not make difference. 

For Tinderboxes it's not a problem to have PKITS data in /export/tinderbox/PKITS_DATA and have PKITS_DATA variable set to this path.
(Assignee)

Comment 6

11 years ago
(In reply to comment #4)
> Testing should rely on NFS as little as possible. 
> I suggest doing something like this pseudo-code:
>   if (files are not locally available)
>       copy test files to local directory.
>       If that does not succeed, fail this test.
>   Run test with local copy of test files.

Nelson, current situation is that all nightly testing runs over NFS (build directories + working/results directories) - there are more reasons for this - build for different OS version (like Solaris 8-10) are built on one machine only and are shared, we don't have to copy builds/results after testing,... There is no much sense for us to copy PKITS to local drive, when everything else is using NFS. There is always some risk of network problems, but when NFS fails, not only PKITS will be affected, we will not be able to run nightly tests at all (this happens once per time, but we still have Tinderboxes).
(Assignee)

Updated

11 years ago
Depends on: 426510
(Reporter)

Updated

11 years ago
Whiteboard: PKIXTEST NSS312B2 → PKIXTEST
Target Milestone: 3.12 → 3.12.1
(Assignee)

Updated

10 years ago
Target Milestone: 3.12.1 → 3.12.4
You need to log in before you can comment on or make changes to this bug.