2012-01-25 19:21 AEST by Arthur Barrett - Using 'cvs passwd' with :local: gives audit error.

cvs -d :local:/db_conf/CVS_local_storage/Repos/Repo_1 passwd -r cvsuser -a mdelacru

 gives

Audit trigger initialiasation failed: Couldn't initialise oracle database engine.
cvs passwd: Pre-command check failed

2012-01-25 19:29 AEST by Arthur Barrett - The :local: protocol is not recommended.  Using a 'real' protocol, eg: pserver or sspi solves this.

In the rare case when the server is set to RunAsUser=cvsuser and the 'passwd' and or 'group' file is not 
writable by cvsuser then you cannot use a 'real' protocol.

In this case the recommend workaround is to temporarily disable audit while adding users.

To resolve the file ownership issues, as a linux administrator to:

1. take a snapshot of the server vm (if the server is running on vm)
 
2. change the ownership on /path/to/repos/CVSROOT/group and path/to/repos/CVSROOT/passwd to 
cvsuser:cvsuser

3. change the file access on /path/to/repos/CVSROOT/group and path/to/repos/CVSROOT/passwd to 
to g+rwxs

4. run some tests, eg:
 *regular user checkin/checkout/promote
 *regular user browse using CVS Suite Studio
 *cvsadmin user browse using CVS Suite Studio
* cvsadmin add a user from client PC using :pserver: protocol
 

We recommend you resolve this some time when the pressure is off and you've got plenty of time to run 
some tests and you have a non-admin user who can also run some tests.

2012-03-03 06:36 AEST by Arthur Barrett - To clarify:

The cvsadmin currently follows this procedure using the linux server to add a new user 'mdelacru':

   cvs -d :local:/db_conf/CVS_local_storage/Repos/Repo_1 passwd -r cvsuser -a mdelacru

The correct procedure is instead to use the client windows PC to add the new user:

   cvs -d :sspi:njlcvs01:/estee passwd -r cvsuser -a mdelacru

The customer cannot use the 'correct' procedure, because the permissions on these files are wrong on 
the server (should be cvsuser:cvsuser):

/db_conf/CVS_local_storage/Repos/Repo_1/CVSROOT/group
/db_conf/CVS_local_storage/Repos/Repo_1/CVSROOT/passwd

The procedure to change the permissions/ownership of the files has already been supplied to the 
customer.  However this requires several things which may take up a lot of time, including:
* conduct a security assessment on the impact of this change
* develop a test plan and rollback plan (in case of testing failure)
* perform system changes only possible from root
* test the change, rollback if required (using plan)
* update your written procedures
* re-validate/re-test the system and procedures

Because the customer was not ready to proceed with implementing the fix, we instead provided a 
workaround.

2012-03-03 07:09 AEST by Arthur Barrett - This customer is using :pserver: not :sspi: so the correct procedure example is:

   cvs -d :pserver:cvsadmin@njlcvs01:/estee passwd -r cvsuser -a mdelacru

or

   cvs -d :pserver:cvsadmin@10.1.46.68:/estee passwd -r cvsuser -a mdelacru