soup4you2
February 26th, 2003, 11:02
If you have more than 1 BSD box laying around this comes in handy. What we will be doing here is mirroring the cvsup#.freebsd.org site to out local hard drive to distribute sources and ports to our other machines. It doesnt matter if PC1 is running FreeBSD 5 and PC2 is running FreeBSD 3.2 your going to get all the sources. This is extremely easy to do and should take you no more than 5 to 10 minuites to setup and configure.
Installing and Configuring your CVS mirror
Configuring the cvs server by hand can be a bit tricky. Luckely there's a easy way to do it right in your ports tree.
($:~)=> cd /usr/ports/net/cvsup-mirror ; make install clean
The install is going to ask you some questions..
Master site for your updates [cvsup-master.freebsd.org]?
The default, cvsup-master.freebsd.org, is reserved for official FreeBSD mirror use. Access to this system is tightly controlled by authentication keys; not just any dumbass can use it.
How many hours between updates of your files [1]?
The script updates /etc/crontab to run CVSup automatically. This default is intended for public mirrors. you probbibly want to change this to every 12 or 24 hours so you dont end up pissing off your cvsup server.
Do you wish to mirror the main source repository [y]?
Where would you like to put it [/home/ncvs]? /repo
Do you wish to mirror the installed World Wide Web data [y]? n
Do you wish to mirror the GNATS bug tracking database [y]? n
Do you wish to mirror the mailing list archive [y]? n
For the majority of people out there you just need to update the main source repository. But there's nothing stopping you from getting the mailing lists also.. They come in handy for questions.
Unique unprivileged user ID for running the client [cvsupin]?
Unique unprivileged group ID for running the client [cvsupin]?
Unique unprivileged user ID for running the server [cvsup]?
Unique unprivileged group ID for running the server [cvsup]?
You can use the defaults, or use user and group names that fit your local scheme.
Maximum simultaneous client connections [8]?
The maximum simultaneous client connections is easy to change, so don't sweat it. We'll see how in the cvsupd.access file, below.
The make install process adds these usernames, sets the configuration, and generally gets you ready to go.
Pretty simple so far hugh? This is a nice port that pretty much does everything for you..
Updating Your Repository
You should have a cron job scheduled now to update your cvs mirror. you can look at /etc/crontab to be sure. But you probbibly want to hurry up and start updating your sources and ports. but keep in mind the first initial update takes hours to complete. but if you wish to tell your cvs mirror to update there's a script arlready setup for you.
($:~)=> /usr/local/etc/cvsup/update.sh
If you want to watch the process of the update you can just preform a tail on it's logfile
($:~)=> tail -f /var/log/cvsup.log
Now that a few hours have passed and your probbibly extremely drunk.. (if you started drinking in the beginning of this process) But once you've got the sources.. dont think you can just do your buildworlds or whatever at this moment.. we still need to have out box get the sources from our cvs mirror.. First we need to edit or create our cvsup supfile..
($:~)=> vi /usr/local/etc/cvs-supfile
Now here's an example of a standard or basic cvs-supfile
*default host=cvsup.yourserver.com
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_4_7 #CHANGE TO YOUR RELEASE
*default delete use-rel-suffix
*default compress
src-all
Controlling Access and Security
The file /usr/local/etc/cvsup/cvsupd.access controls which hosts may connect. The syntax is simple:
# Means a comment or remark
+ Means that the Host can connect
- Means that the Host cannot connect
* Means that the Host must authenticate it's self
Each rule in cvsupd.access can refer to either a host name or an IP address.
For example, to allow access from the network 192.168.0.0/16 and reject clients accessing from elsewhere, use this.
+192.168.0.0/16
-0.0.0.0/0
You can also use cvsupd.access to restrict the number of connections the system will allow at any one time. This is done by specifying a number after the network number. For example, to restrict the server to 10 connections per second you would use
-0.0.0.0/0 10
As you might guess, you can use this system to throttle connections from blocks of IP addresses. Another good idea is to also place ipf rules to restrice that ip's or hosts can access your cvsupd service.
pass in quick on xl1 proto tcp from 10.0.2.1 to yourserver port = 5999 keep state
If your unfamiliar with IPfilters then start reading up.. But basically here were allowing the ip 10.0.2.1 to the server (yourserver should be changed to your server's address or hostname) You can also utalize the /etc/hosts.allow to get more control over it.
Authentication
The CVSup server uses a challenge-response system for authentication, rather than handing passwords around in clear text. If someone drops a packet sniffer on the network, the cannot grab passwords. What's more, since the challenge-response system incorporates the time, the client IP address, some pseudo-random numbers, and a bunch of other system garbage that changes rapidly, a response cannot be used a second time.
You must use a password file, /usr/local/etc/cvsup/cvsupd.passwd, to use authentication. This file should only be readable by the cvsup user, or anyone could grab user information. (You can do this by running chown cvsup cvsupd.passwd and chmod 600 cvsupd.passwd.)
The first line is the server name and private key, separated by a colon.
servername.yourdomain.com:testkey
The server name is sent back to the client. The private key is used for additional randomness. You don't have to have a private key -- the cvsupd password system is pretty random as is -- but you must have the colon. The private key cannot contain a colon.
After this, you have your legitimate users. Each user appears on a separate line, in the following format.
user ID:shared secret:class:comment
cvsup IDs are email addresses, i.e., "techguru@bsdhound.com." The shared secret is based upon a cryptographic hash of your chosen password. The class is reserved for future use, and should be left blank. Finally, the comment field can be used by the administrator.
The cvpasswd command automates generating cvsupd.passwd entries. You use it like this:
($:~)=> cvpasswd userID servername
For example:
($:~)=> cvpasswd techguru@bsdhound.com cvsupserver.bsdhound.com
Enter password: *************
Enter same password again: *************
Send this line to the server administrator at cvsupserver.bsdhound.com:
-------------------------------------------------------
techguru@bsdhound.com:$md5$bf489b753a0a949a1c63a3f 5da0d61b6::
--------------------------------------------------------
Be sure to send it using a secure channel!
Add this line to your file "$HOME/.cvsup/auth", replacing "XXX"
with the password you typed in:
---------------------------------------------------------
techguru.bsdhound.com:cvsupserver.bsdhound.com:XXX :
---------------------------------------------------------
Make sure the file is readable and writable only by you!
Copy the first line given to /usr/local/etc/cvsup/cvsupd.passwd on the server. On your client system, create a .cvsup directory and put the second line into .cvsup/auth. Make sure that only you can read that file (chmod 600 .cvsup/auth).
Well now was that not easy or what.. I hope you enjoyed this little guide..
References used in this article are: ONLAMP | FreeBSDDiary
Installing and Configuring your CVS mirror
Configuring the cvs server by hand can be a bit tricky. Luckely there's a easy way to do it right in your ports tree.
($:~)=> cd /usr/ports/net/cvsup-mirror ; make install clean
The install is going to ask you some questions..
Master site for your updates [cvsup-master.freebsd.org]?
The default, cvsup-master.freebsd.org, is reserved for official FreeBSD mirror use. Access to this system is tightly controlled by authentication keys; not just any dumbass can use it.
How many hours between updates of your files [1]?
The script updates /etc/crontab to run CVSup automatically. This default is intended for public mirrors. you probbibly want to change this to every 12 or 24 hours so you dont end up pissing off your cvsup server.
Do you wish to mirror the main source repository [y]?
Where would you like to put it [/home/ncvs]? /repo
Do you wish to mirror the installed World Wide Web data [y]? n
Do you wish to mirror the GNATS bug tracking database [y]? n
Do you wish to mirror the mailing list archive [y]? n
For the majority of people out there you just need to update the main source repository. But there's nothing stopping you from getting the mailing lists also.. They come in handy for questions.
Unique unprivileged user ID for running the client [cvsupin]?
Unique unprivileged group ID for running the client [cvsupin]?
Unique unprivileged user ID for running the server [cvsup]?
Unique unprivileged group ID for running the server [cvsup]?
You can use the defaults, or use user and group names that fit your local scheme.
Maximum simultaneous client connections [8]?
The maximum simultaneous client connections is easy to change, so don't sweat it. We'll see how in the cvsupd.access file, below.
The make install process adds these usernames, sets the configuration, and generally gets you ready to go.
Pretty simple so far hugh? This is a nice port that pretty much does everything for you..
Updating Your Repository
You should have a cron job scheduled now to update your cvs mirror. you can look at /etc/crontab to be sure. But you probbibly want to hurry up and start updating your sources and ports. but keep in mind the first initial update takes hours to complete. but if you wish to tell your cvs mirror to update there's a script arlready setup for you.
($:~)=> /usr/local/etc/cvsup/update.sh
If you want to watch the process of the update you can just preform a tail on it's logfile
($:~)=> tail -f /var/log/cvsup.log
Now that a few hours have passed and your probbibly extremely drunk.. (if you started drinking in the beginning of this process) But once you've got the sources.. dont think you can just do your buildworlds or whatever at this moment.. we still need to have out box get the sources from our cvs mirror.. First we need to edit or create our cvsup supfile..
($:~)=> vi /usr/local/etc/cvs-supfile
Now here's an example of a standard or basic cvs-supfile
*default host=cvsup.yourserver.com
*default base=/usr
*default prefix=/usr
*default release=cvs tag=RELENG_4_7 #CHANGE TO YOUR RELEASE
*default delete use-rel-suffix
*default compress
src-all
Controlling Access and Security
The file /usr/local/etc/cvsup/cvsupd.access controls which hosts may connect. The syntax is simple:
# Means a comment or remark
+ Means that the Host can connect
- Means that the Host cannot connect
* Means that the Host must authenticate it's self
Each rule in cvsupd.access can refer to either a host name or an IP address.
For example, to allow access from the network 192.168.0.0/16 and reject clients accessing from elsewhere, use this.
+192.168.0.0/16
-0.0.0.0/0
You can also use cvsupd.access to restrict the number of connections the system will allow at any one time. This is done by specifying a number after the network number. For example, to restrict the server to 10 connections per second you would use
-0.0.0.0/0 10
As you might guess, you can use this system to throttle connections from blocks of IP addresses. Another good idea is to also place ipf rules to restrice that ip's or hosts can access your cvsupd service.
pass in quick on xl1 proto tcp from 10.0.2.1 to yourserver port = 5999 keep state
If your unfamiliar with IPfilters then start reading up.. But basically here were allowing the ip 10.0.2.1 to the server (yourserver should be changed to your server's address or hostname) You can also utalize the /etc/hosts.allow to get more control over it.
Authentication
The CVSup server uses a challenge-response system for authentication, rather than handing passwords around in clear text. If someone drops a packet sniffer on the network, the cannot grab passwords. What's more, since the challenge-response system incorporates the time, the client IP address, some pseudo-random numbers, and a bunch of other system garbage that changes rapidly, a response cannot be used a second time.
You must use a password file, /usr/local/etc/cvsup/cvsupd.passwd, to use authentication. This file should only be readable by the cvsup user, or anyone could grab user information. (You can do this by running chown cvsup cvsupd.passwd and chmod 600 cvsupd.passwd.)
The first line is the server name and private key, separated by a colon.
servername.yourdomain.com:testkey
The server name is sent back to the client. The private key is used for additional randomness. You don't have to have a private key -- the cvsupd password system is pretty random as is -- but you must have the colon. The private key cannot contain a colon.
After this, you have your legitimate users. Each user appears on a separate line, in the following format.
user ID:shared secret:class:comment
cvsup IDs are email addresses, i.e., "techguru@bsdhound.com." The shared secret is based upon a cryptographic hash of your chosen password. The class is reserved for future use, and should be left blank. Finally, the comment field can be used by the administrator.
The cvpasswd command automates generating cvsupd.passwd entries. You use it like this:
($:~)=> cvpasswd userID servername
For example:
($:~)=> cvpasswd techguru@bsdhound.com cvsupserver.bsdhound.com
Enter password: *************
Enter same password again: *************
Send this line to the server administrator at cvsupserver.bsdhound.com:
-------------------------------------------------------
techguru@bsdhound.com:$md5$bf489b753a0a949a1c63a3f 5da0d61b6::
--------------------------------------------------------
Be sure to send it using a secure channel!
Add this line to your file "$HOME/.cvsup/auth", replacing "XXX"
with the password you typed in:
---------------------------------------------------------
techguru.bsdhound.com:cvsupserver.bsdhound.com:XXX :
---------------------------------------------------------
Make sure the file is readable and writable only by you!
Copy the first line given to /usr/local/etc/cvsup/cvsupd.passwd on the server. On your client system, create a .cvsup directory and put the second line into .cvsup/auth. Make sure that only you can read that file (chmod 600 .cvsup/auth).
Well now was that not easy or what.. I hope you enjoyed this little guide..
References used in this article are: ONLAMP | FreeBSDDiary