Comment: LHL (ENTHUSIAST) Post Date 04/12/02 06:48 AM Hypothesis: CvsRoot User: cvsroot Home = / Home2 / CVSROOT / CVSROOT CVS Group: CVS 1: Secure #groupadd CVS #mkdir / Home2 / CvsRoot # Note: / home2 / cvsroot is all # ustraddd -g cvs -g cvs -d / home2 / cvsroot / cvsroot cvsroot / *** unlucked ** / #mv / usr / bin / cvs / usr / bin / cvs .real #cat> / usr / bin / cvs #! / bin / sh umask 2 # or whatever Your Site Standard Is. EXEC /USR/BIN/CVS.REAL $ {1 "$ @"} ^ D / ** ********** / 2: Multi-warehouse Note, we use cvsroot just used to manage, so don't create any warehouses below it. In addition, the initial environment of the cvsroot user should not contain non-empty $ Cvsroot. Any management work that uses cvsroot indicates that cvsRoot is a good habit. OK, start to build a warehouse to a single project to assume two items, Project1, Project2, hope to be stored separately, easy to manage #mkdir / home2 / cvsroot / pro1 #mkdir / home2 / cvsroot / pro2 #chown cvsroot.cvs / home2 / cvsroot / pro1 #chown cvsroot.cvs / home2 / cvsroot / pro2 #chmod 2775 / home2 / cvsroot / pro1 #chmod 2775 / home2 / cvsroot / Pro2 (higher security requirements $ chmod 2770 / home2 / cvsroot / cvsroot / pro1) OK, start building a warehouse #SU - CVSROOT $ cvs -d / home2 / cvsroot / pro1init $ cvs -d / home2 / cvsroot / pro2 INIT $ chmod 2775 / home2 / cvsroot / pro1 $ chmod 2775 / home2 / cvsroot / pro2 modified startup file service CVSP Server {disable = no flags = reuse socket_type = stream wait = no user = root bind = 192.168.0.1 online = 192.168.0.0/24 server = / usr / bin / cvs server_args = -f - allow-root = / home2 / Cvsroot / pro1 --allow-root = / home2 / cvsroot / pro2 PServer log_on_failure = userid} / **************** Due to XINETD's Server_Args length Limit, when you want to run a lot of single warehouse, you can do this, #vi /etc/xinetd.d/cvspserver service cvspserver {Disable = no flags = reuse socket_type = stream wait = no user = root bind = 192.168.0.1 ONLY_FROM = 192.168.0.1.0 / 24 Server = /Home2/cvsroot/cvs.run log_on_failure =
Userid}: wq then write scripts /Home2/cvsroot/cvs.run #vi /home2/cvsroot/cvs.run #! / Bin / bash / usr / bin / cvs -f / - allow-root = / home2 / cvsroot / pro1 / - allalow-root = / home2 / cvsroot / pro2 / - allow-root = / home2 / cvsroot / pro3 / --allow-root = / home2 / cvsroot / pro4 / --allow-root = / home2 / cvsroot / pro5 / --allow-root = / home2 / cvsroot / pro6 / pserver: wq #chmod x /home2/cvsroot/cvs.run #service xinetd Restart OK! / ********* ************** / Modify the strategy of different warehouses #SU - CVSROOT $ export cvsroot = / home2 / cvsroot / pro1 $ CVS CO CVSROOT $ CD CVSROOT $ VI Config # set this to " no "if pserver should not check system users / passwords SystemAuth = no # Put CVS lock files in this directory rather than directly in the repository. LockDir = / var / cache / cvs / pro1 # Set` TopLevelAdmin 'to `yes' to create a CVS directory at the top # level of the new working directory when using the `cvs checkout '# command. # TopLevelAdmin = no # Set` LogHistory' to `all 'or` TOFEWGCMAR' to log all transactions to the # history file , or a subset as needed (IE `TMAR 'LOGS ALL WRITE Operations) LOGHISTORY = TofEwgcmar: WQ $ VI LOGINFO All (Echo% {svv}; cat) | /usr/local/viewcvs-0.9.2/loginfo-handler#sql checkin: WQ $ cvs commit -m "Auth change, log "" Change "
OK, since we don't use the system user verification, then let's create a user / *********** / do not use the system account reason is to fully guarantee the security, avoid the system account directly to delete the files in the warehouse. Though Trouble, but it is necessary, because each programmer is very experienced. In this case, an equivalent system user is built for each project, this user should be a member of the CVS group. Do not have to be There is shell. (You can also build an equivalent user for all items, private CVS Server can do this, even cvsroot directly, huh, it is more dangerous) #adduser -g cvs -g cvs -s / bin / false -d / home2 / cvsroot / pro1 -m cvspro1 / *********** / Create a LockDir (select / var / cache is because some systems are placed under / var / lock ) #mkdir / var / cache / cvs #chown cvsroot.cvs / var / cache / cvs #chmod 2775 / var / cache / cvs #mkdir / var / cache / cvs / pro1 #Chown cvspro1.cvs / var / cache / cvs / pro1 #CHMOD 2775 / VAR / CACHE / CVS / PRO1 Create User Creating User Clear Environment $ EXPORT CVSROOT = $ CD ~ CVSROOT $ RM -RF CVSROOT Direct Switch to Pro1 Warehouse $ CD / Home2 / CvsRoot / Pro1 $ CD CVSROOT Create User HLEIL $ HTPASSWD -C Passwd HLEIL Modify Passwd into CVS Format $ VI Passwd HLEIL: SVCSDasdcvjn: Cvspro1: WQ Add to Writers Group $ Echo HLEIL >> Writers / ************************ *** / If User HLEIL needs Writers permissions, he will definitely not appear in the Readers group. Writers, readers, passwd's file tail downs are necessary. If there is no existence, it will cause Access Failed. The CVS account is try to have no corresponding system account. If there is, make sure they passWD different. / **************************** / OK! Project Pro2 is the same. 3: Construction of modular works about modularization, everyone hangs in the mouth is not a day two days, referring to the modularity of the project, does not refer to specific procedures. Before the normal project begins, it must be customized before the implementation is implemented. Analysis and structural design, of course, "project" like printing "Hello World!" May not use systematic analysis: P, so don't have to have a hard build CVS. After the software design is complete, each module should come out. Before implementation, we need to consider using CVS to implement design results. The module of CVS does not have to be refined to the extent of crazy, and will be based on functional division and take into account the working group. The same module must only have a single working group to be responsible. Determine the module Let us build modules. #Su - hleil $ export cvsroot =: pserver: hleil@192.168.0.1: / home2 / cvsroot / pro1 $ cvs login $ cvs co covsroot assumptions have such a directory structure, PRO01 LIBS LIBS / 01 LIBS / 02 Each directory has an initialization file init (convenient import) we can define modules, $ VI CVSROOT / MODULES PRO01PRO01 & LIBS LIBS-01-D 01LIBS / 01 LIBS-02 -D 02LIBS / 02 LIBS-A LIBS- 01 LIBS-02: WQ $ cvs commit -m "init modules" poured into the directory structure, $ cvs import -m "init checkin"
