How to configure and use SSH authentication system server CVS

ssh-with-cvs

How to configure and use SSH authentication system server CVS

cvs (Concurrent Version System) is a very popular version control tool. Although its function as Perforce, Subversion and other powerful, but because of its easy configuration, simple to use and the introduction of longer, so in all a kind of software project widely used.

first is to install FreeBSD, and application security patches. This step is very simple, download a FreeBSD (the upcoming 5.2-RELEASE is a good choice, in this article was published, this version may have been able to download a) of the mini iso burning CD-ROM, then you can install the (choose “Minimum” installation). Note that, in order to be able to use ssh authentication, be sure to install the crypto. Configure the network for this machine, so after the restart just fine.

then install the necessary package. FreeBSD 4.x built-in perl, but in 5.x in, perl be deleted from the basic system. In order to better use, including ACL, commit mail, and a number feature, you must install perl.

I personally recommend using the ports in the 5.8.x version of perl. Before installing, first of all convinced that the system does not perl 5.6.x installed, the new system, they can safely execute the following command:

This will remove the existing any package. In general, the majority of FreeBSD users use cvsup to update the system, but the release of the CD, cvsup-without-gui is not included, while the ordinary cvsup package requires a series of X11 libraries. To avoid trouble, consider the following two different ways to complete the first code update:

1, using the FreeBSD’s cvs to synchronize code:

cvs-d: pserver: anoncvs@anoncvs.jp.FreeBSD.org: / home / ncvs login

enter “anoncvs”, Enter

cd / usr

cvs-R-d: pserver: anoncvs@anoncvs.jp.FreeBSD.org: / home / ncvs export-r RELENG_5_2 src ports

Note: If you are not using 5.2-RELEASE, please make appropriate amendments to RELENG_5_2 (for example ,4-STABLE is RELENG_4, – CURRENT is the HEAD, etc.)

2, install cvsup-without-gui:

pkg_add-r cvsup-without-gui

then use cvsup to synchronize code, space is limited, I will not repeat them

I recommend the first method, of course, the second method should be faster, and does not require manually compiling cvsup. Subsequently, the installation of Perl 5.8.x:

cd / usr / ports / lang / perl5.8 & & make all install clean & & rehash

Then we will face a very serious problem: ports inside use.perl script does not know the system had not installed perl, so the time to be wrong in the implementation – this time, just make a symbolic link to perl on it. Well, the implementation:

use.perl port

This script will help you complete use.perl modify configuration files (such as / etc / make.conf) and a series of work. Here is not the table, a little profile about OpenSSH (sshd) configuration, in general, add the following two lines:

Protocol 2

PasswordAuthentication no

the benefits of doing so: ( 1) only allow ssh2 protocol log, which can provide better security (2) does not allow password login, which no doubt will increase security.

1, create a cvs repository

Well, pre-configuration is basically over. Do not forget to create a user for the cvs group, for example, ncvs, as well as a cvs repository for the management of users, such as the repoman (which of course is ncvs that group), and then create a directory to save the cvs repository, in this case , we put it into / home / ncvs in:

rm-rf / home / ncvs

mkdir-p / home / ncvs

chown-R repoman: ncvs / home / ncvs

chmod-R 775 / home / ncvs

next step is to initialize the repository, and simple to implement:

su-l repoman

cvs-d / home / ncvs init

on it.

present, all the FreeBSD version of cvs are included in the safety of the existence of a small vulnerability, although this flaw only in local use, but we recommend that you put it back on is to find / usr / src / contrib / cvs / src / expand_path.c in

return current_parsed_root-> original;

line, turning it into a

return current_parsed_root-> directory;

Of course, the next step is to re-make world kernel of. Need to note is that if you are using a 5-CURRENT, also need to modify some code for it to reach 5.2-RELEASE as performance (-CURRENT in a large number of debugging options turned on), specific methods will not go into here.

2, the configuration commitmail and ACL

then configure cvs commitmail and ACL. I personally think that commitmail the team software development a very important thing to cvs, it is especially important because cvs is not atomic submit function, but commitmail just enough to make up for this.

FreeBSD development team used a very good perl script to complete commitmail function, while the hook they use cvs to achieve a simple access control function (ACL). I use the cvs repository based on FreeBSD’s CVSROOT, and made a few changes.

use the CVSROOT cover your CVSROOT, and you also need to freebsd directory mailsend.c which compiled the results into the / usr / local / bin (the script assumes that the CVSROOT in this matter). In addition, the CVSROOT need some modifications before it is put into use (for example, machine name, etc.). These settings can be found in the cfg_local.pm inside:

$ MAILADDRS = ‘cvs- all@example.org ‘;

commitmail this is the place to be sent to.

$ MAIL_BRANCH_HDR = “X-Phantasm-CVS-Branch”;

this is to be added to the commitmail head of information, if you use the mailing list, then it can help mailing list automatically sorted.

$ MAILBANNER = “The Phantasm Studio repository”;

this soon in commitmail said that they commit to which a repository.

if ($ hostname = ~ / ^ cvs \. Example \. Org $ / i)

commit to this is to determine the host name

$ CVSWEB_URL = “http://cvsweb.example.org/cgi-bin/cvsweb.cgi”;

This is cvsweb services at

a brief CVSROOT in the other documents

avail: the file used to control access to user group.

access: This file is used to control who can perform cvs operations.

exclude: This file is used to control those files do not need to check the cvs tag

options: this file used to control the commencement of cvs tag, for example, can define $ Phantasm $, etc.

3, configuration of users and restrict ssh permissions

ssh authentication using a more vexing question is, ssh means that users have a system account, and that they be able to log in.. If configured properly, they can get a shell, it is natural to be a potential security risk.

must therefore be very careful in handling the ssh cvs authentication issue. The underlying principle is: any action against the user, unless we allow them to do so.

create a user in accordance with the following rules:

user’s” primary “group is ncvs (This will not only restrict the user’s permission, so we can more easily control the other users in the cvs repository which can not be free to commit)

users do not use password authentication, which will ease because they do not properly set up ftp and other safety hazards caused by

still give the user a shell, the “shell” can be a perl script, it only allow the implementation of the beginning of the command cvs

then allow users to use openssh’s ssh-keygen to generate your own key pair. OpenSSH in most * BSD and Linux distributions can be found in, if the user uses the Windows Desktop, you need to install cygwin (in particular, the installation of net in OpenSSH), of course, the implementation of the command is the same:

ssh-keygen-t dsa-b 2048

for the paranoid security enthusiasts, can consider later in 2048 will be replaced by-b 4096. Of course, under the barrel theory, if you are a paranoid, then obviously you should be forced to use all the partners are also at least as long as your key:)

, the administrator should be user (committer) the key into the server, the user corresponding to the authorized_keys file in the folder inside. For example, one of my public key as follows:

ssh-dss AAAAB3NzaC1kc3MAAAEBAL +1 jinOw +86 RcTEaSM5/Hz4Lr9tIS0IQsX8ebo

TwLzWnqpOHRh2KBCGn/e0xGCIAai7PGz7c + SZCvrLiRvG9mCsMMMue8ZIL + QF4OAmMd

Cz8Qoyg0cc4YXImOd + UEpdOX29PC4aMAz28v/GO2yf58/Qa49Clfq1kHa/8q3IAgs9o

W95 / ArG + IWFOsN1Tv9nh4XJb5AQjpa5uMlB5SEmvKGTXQ2oYiRVIxL8vzHL6MtO/8×1

j8 + RioSH6FCpEXS7UJbYxE7vF3m5Fa5o6g2dIZewphsleOeHkvYJ442Hqvsly3p4 +4 N

dvim4bY2HMDha5r5zeTV8tTlOz4wQVgKyWoEAAAAVAINGzX7uU0vR8l63qhBhUeWGZt

C9AAABADWiO +9 bvV7DApsn08LR1eoEnMjJFQgEfGlbV + EvZHkO0bkHZAdRIKtVmgNUw

G6uufykkt2Tb + q5SbVNZkzeaFVv4ZMtnjSvEPIZrEXcQFFguGk1it5v5EYcmq4G8 + j1

BFTVHef4b1wMTSt11WtEz0LUYncuZ6LA48/WGTuZiSm8JkchgVm8HhR9NqjdeFJH8sO

RUhUBoxyWjo/hv7zFg7HqoJGzeNfrEhFg36psR2RDaRvSP0vN1W2q4j5OZy3gB6ZyVt

nsEPl1HELhlaCFifmdz1LVxDx + FyPy6wMsPQLTmB1g6N1J6PWy3qCTJ0NyQgarSt3 / A

TQ0InF1BOdJn8QAAAEAPb1OgswuMHdEsHk2ETZVmOKOkI9Rjf72vjZ3xG45iEbCH/7p

aTP8OQmJMW9FD4MHjdmtktPVYXDIa9Hj/IM44zhfMHEdKs9LlFUK5dBgNUps + yPj2Ns

Mr2rl771ODR0mB52FwrXm1FCmNTM7WQpFOEy/QhtZRpHK +7 / YZp7PBggt17Fw7rbjP2

zhWnZluoSKLgvfkhxhJuOMm/ElNJx2c + XHdxPqI3eR5UxzLNjDUNh59I8 + h + E69bFB3

b2uhKqziziHOQcqoH5r0Kud / DBBE79lU3mRUF8FQNygCRh/V3yFzed40rc0nF0PQpNZ

6zodDTJByrm6vX5wr2lI4RgA9w == bitripper@grimreaper.delphij.net

Description: public key is not allowed off-line, here is convenient for typesetting. We have just opened to the user shell, which is still potential pitfalls, so we tighten security in this regard, the public key by adding the following text before the project:

command = “/ usr / bin / cvs – allow-root = / home / ncvs server”

So, the whole line should look like this:

command =” / usr / bin / cvs – allow-root = / home / ncvs server “ssh-dss AAAAB

…… …………………..

X5wr2lI4RgA9w == bitripper@grimreaper.delphij.net

ssh this command means that up on the implementation of / usr / bin / cvs – allow-root = / home / ncvs server this command, and can only perform this command. Thus, unless there are loopholes in the cvs itself, otherwise, can not really cut out through ssh shell. – Allow-root limits the ability to use the repository, so users can not easily specify the other repository, thus trying to undermine the security will become more difficult. If you need multiple repository, you can specify the number of allow-root parameter.

be noted is that if users have multiple public key, you need to specify each public key before the command.

4, configuration cvsweb

configuration cvsweb is quite simple. First install the apache (I tried 1.3.x and 2.0.x), configure the ready, from the port which install cvsweb on it:

cd / usr / ports / devel / cvsweb & & make all installl clean

and then to modify it configuration file:

cd / usr / local / etc / cvsweb

vi cvsweb.conf

find

;

@ CVSrepositories = (

line, follow the example of an increase in following their own repository, For example:

‘ncvs’ => [‘ New CVS Repository ‘,’ / home / ncvs’],

write the number of how many, of course, @ CVSrepositories the first to directly access cvsweb.cgi when the repository.

in FreeBSD 5.1-CURRENT development process carried out by some of the changes caused by the ports in the cvsweb not normally call the cvs and rcs tools, which will cause it to not work properly. To solve this problem, can be found from the following web site the latest version of cvsweb:

http://www.freebsd.org/projects/cvsweb.html

the author of this writing, the latest cvsweb version is 2.9.1 beta. Before the installation, need to install the other two port:

cd / usr/ports/devel/p5-IPC-Run & & make all install clean

cd / usr/ports/net/p5-URI & & make all install clean

then downloaded tbz file unpack, copy to the appropriate location (cgi-bin and related images directory) can be used.

Tagged : / / / / / / / / / / / / / / /

Running MSBuild 4.0 and MSBuild 3.5 on Continuous Integration

msbuild-40-and-msbuild-35

With Visual Studio 2010 RC released recently, we jumped on the release and began to code with VS2010.  One issue that popped up was that now all builds were targeting MSBuild 4.0.

That doesn’t seem to be a big problem until our CruiseControl CI server kicked in, downloaded our updated code and failed building the upgraded projects.

Fortunately there is a very quick solution to this little problem.  There are a couple of requirements.

1. You need to have VS2010 RC installed somewhere
2. You need to download the .Net Framework 4.0 (I recommend the full version and not just the Client Profile, it ensures you don’t miss anything)

To fix, do the following:

1. download and install the .Net Framework 4.0 on the CI server (then restart the server)
2. on the computer where VS2010 RC is installed go to the following path:
%programfiles%\MSBuild\Microsoft\VisualStudio
3. copy the v10.0 folder located in that directory into the CI server at the same path (or wherever our MSbuild path is on the CI server)
4. Once that is done, edit the ccnet.config file at the tag and change it to the new .Net 4.0 Framework installed (you should only need to change the section “\v3.5\” to “\v4.0.xxxxx\”

Hope this helps

Tagged : / / / / / / / / / / / / / / /

How CVS will help to Realtime Developers ?

how-cvs-will-help-to-realtime-developers

CVS Tips & Tricks

The CVS commands here assume that you are using the command line version of CVS. Tips and tricks for a specific CVS GUI are specific to each GUI and do not really belong here.

Viewing the commit log of a file.

$ cvs log filename

Show current status of a file.

The status command will show you the latest version, the version in your working directory and if your local copy has been modified.

$ cvs status filename

Performing a CVS diff

After developers have checked in updates to the code it may be beneficial to see what has changed, either to help solve bugs or to track changes. There are several option to do this.

  1. Perform a diff between complete branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2
  1. Perform a diff between a single file in two branches:
$ cvs -q diff -u -r BRANCH1 -r BRANCH2 filename
  1. Perform a diff between different versions of a file:
$ cvs -q diff -u -r version1 -r version2 filename
  1. Perform a diff between working version and most up to date file in database:
$ cvs -q diff -u filename
  1. Perform a diff between working version and a specific database version:
$ cvs -q diff -u -r version filename

Retrieving CVS Information on Files

To retrieve the current version and other relevant information about a file run:

$ cvs status filename

To retrieve the entire change log pertaining to a file run:

$ cvs log filename

Retrieving CVS Files Based Upon Revision

To retrieve a file from CVS based upon a revision number perform the following:

$ cvs -q up -Pd -r revision filename
  • To get the revision number use the log command above

Tag file in CVS as a Release

To tag files in CVS as a release perform the following:

$ cvs tag
  • Run the command from within the release source dir.

Creating a Branch

I like to do the following before creating a branch:

See what tags are available and pick one.

$ cvs -q log filename

Revert to a tagged version of HEAD.

$ cvs -q up -r TAG_Version

To create a branch in CVS perform the following:

$ cvs tag -b

Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_36_BUG_.

cvs -q up -r
$ cvs -q status <– confirm that the branch has specified as the tag
$ cvs tag _mm_day_year <– eg: BRANCH_12_BUG_12345_07_17_2009

Reverting to a Branch

To revert to a branch in CVS perform the following:

$ cvs -q up –r
  • Run the command from within the release source dir. This should be done in the top level directory of the project. The chosen_branch is something like BRANCH_BUG_.

Verifying you are in a branch

To verify you are in a branch

$ cvs -q status

You will see that the branch is a sticky tag.

Merge Current Branch with HEAD

Ensure that you are in the branch by reverting to the branch and Verifying that you are in the branch.

$ cvs update -j

This will ensure that you are your branch is getting merged properly with HEAD so the only differences you see between your branch and the are changes that you made. You can verify this from your branch with:

$ cvs -q diff -u -r | less

You will eventually have to commit your changes you should always do a tag on the branch after your commit.

$ cvs tag

Merge HEAD into Current Branch Multiple Times (with tags) and without -kk option

$ cvs update -j -j

This command will unfortunenately result in a lot of your ID tags getting changed at the top. Using the –kk option will avoid this problem. But then you won’t see which files have changed and You won’t know who last modified a file easily. After you run this command I recommend:

$ vim `cvs up -d | grep '^C' | sed -e 's/^C //'`

You may find the following page interesting as well: http://kb.wisc.edu/middleware/page.php?id=4087

This will grab all of the conflicting files. You can save them with :w. And step through them with :bn. You can easily close them all with :wq!.

Merge HEAD into Current Branch Multiple Times (with tags)

To merge current HEAD into a branch that has already had HEAD merged into it once, the differences between that last merge and current HEAD need to be gathered and applied to the branch. This is done by finding out when the last time HEAD was merged with the branch. Hopefully you tagged your branch. Repeat steps 1 and 2 from the previous section to create a tag for HEAD and to create a tag for your branch so you can have a backup/reference point. Then, perform the following if you have tagged the branch when merging the last time:

$ cvs update -kk -j -j
  • Run the command from within the branched version. is the old tag in HEAD from the last time you merged (the tag that you created in Step one from the previous section). If you in this case, the format will likely be the following:
$ cvs update -kk -j UPDATE_HEAD_36_BUG__06_16_2008 -j UPDATE_HEAD_36_BUG__07_23_2008

The first tag is the one created the last time HEAD was merged into the branch. The second tag is one that should have been just created. This will take all the differences between the two tags, and bring them into the branch. The next time a merge from HEAD into the branch occurs, this latest tag will be the “old” tag, and the new tag will be created at the time of the merge.

The reason for tagging the branch before a join/merge like this is to create a reference point to revert to if the need ever arises. The -kk option removes rcsid tags so that the cvs tag at the top doesn’t get flagged as a conflict on every merge/join.

Merge HEAD into Current Branch Multiple Times (without tags)

If no tags have been created for the branch when HEAD was merged into a branch at a previous time, an alternative is to use the daily build tag. Find the commit message of the last time HEAD was merged into the branch and was committed and select the daily build tag the day BEFORE that one (but only if the commit was before the daily build that day, i.e. before lunch time for GMT -06:00). An example is provided below on how to merge without tagging:

$ cvs update -kk -j Tag_Branch -j HEAD>

Run the command from within the branched version.

———————————-
To Avoide network confusion :-

use :- alias cvs=`cvs -z9`

causes cvs to use compression level 6.

Good links for it:-

  • http://datagrams.blogspot.com/2009/01/how-to-deploy-cvs-concurrent-versions.html
  • http://kb.wisc.edu/middleware/page.php?id=4087
  • http://ximbiot.com/cvs/manual/cvs-1.11.21/cvs_10.html#SEC85
  • http://ximbiot.com/cvs/wiki/Special/Index
  • More Help!!

Refer for more on This:-

          Click Me!!

Thanks,

-Amaresh Das

Tagged : / / / / / / / / / / / /