Open Bug 396601 Opened 17 years ago Updated 1 year ago

find centralized location for NIST PKITS/PDVAL files

Categories

(NSS :: Test, defect, P2)

Tracking

(Not tracked)

3.12.4

People

(Reporter: alvolkov.bgs, Unassigned)

References

Details

(Whiteboard: PKIXTEST)

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.
Blocks: 396598
Priority: -- → P1
Whiteboard: PKIXTEST
Whiteboard: PKIXTEST → PKIXTEST NSS312B2
Version: 3.12 → trunk
Depends on: 232894
Priority: P1 → P2
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
Priority: P1 → P2
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.
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.  
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.
(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).
Depends on: 426510
Whiteboard: PKIXTEST NSS312B2 → PKIXTEST
Target Milestone: 3.12 → 3.12.1
Target Milestone: 3.12.1 → 3.12.4

The bug assignee is inactive on Bugzilla, and this bug has priority 'P2'.
:beurdouche, could you have a look please?

For more information, please visit auto_nag documentation.

Assignee: slavomir.katuscak+mozilla → nobody
Flags: needinfo?(bbeurdouche)
Severity: normal → S3

We have modified the bot to only consider P1 as high priority, so I'm cancelling the needinfo here.

Flags: needinfo?(bbeurdouche)
You need to log in before you can comment on or make changes to this bug.