1. Edit /etc/inetd.conf to add the «cvs» service:
   cvspserver stream tcp nowait cvs /usr/libexec/tcpd /usr/bin/cvs -f --allow-root=/home/cvs pserver
2. Edit /etc/services to add the cvspserver protocol:
   cvspserver 2401/tcp
3. Edit /etc/hosts.allow to allow connections from certain hosts to the «cvs» service:
   cvs: 192.168.0. botte-coders.example.org .aars.it
4. Add the «cvs» user mentioned in /etc/inetd.conf to /etc/master.passwd:
   cvs:*:80:80::0:0:CVS:/home/cvs:/usr/local/bin/bash
   Run pwd_mkdb -p /etc/master.passwd to regenerate /etc/passwd.

   Create the group «cvs»:
   /etc/group:
cvs:*:80:

   Create the home directory for user «cvs»:
   mkdir /home/cvs
chmod 700 /home/cvs


5. Init the CVSROOT directory in /home/cvs:
   su -l cvs
cvs -d /home/cvs init

6. Create and/or edit the file /home/cvs/CVSROOT/passwd. This file will list the users able to connect to the «cvs» service:
   su -l cvs
cd /home/cvs/CVSROOT
touch passwd
chmod 600 passwd
vi passwd

   The file will look something like this:
   harry:ZrLzRsjAPL7iQ:cvs
klaas:Rf0DZbqhHM.Z.:cvs
sjaak:kLruwLTHOsOXT2:cvs
cvsusers:ORA7SfF0sRkD.:cvs

   «harry», «klaas» and «sjaak» are the cvs users. «cvsusers» is the common user account for the developers working on a certain website project. It is mainly meant for doing cvs checkouts in the production environment.
7. Finally, create the common user account «cvsusers» to keep your developers happy. You know how to do that, don’t you? (-:
8. Now all developers should set their CVSROOT environment and execute a cvs login:
   export CVSROOT=":pserver:<username>@yourserver.com:/home/cvs"
cvs login
cd ~public_html/
cvs -q checkout PROJECTNAME

Follow these pointers:

1. Edit /etc/rc.conf.local to start the DHCP server automatically:

   dhcpd_flags="-q" # for normal use: "-q"


2. Create/edit the file /etc/dhcpd.conf to configure dhcpd:

   # $OpenBSD: dhcpd.conf,v 1.1 1998/08/19 04:25:45 form Exp $
#
# DHCP server options.
# See dhcpd.conf(5) and dhcpd(8) for more information.

   shared-network LOCAL-NET {
   option routers 10.0.0.3;
   option domain-name "intranet.atomicvoid.net";
   option domain-name-servers 10.0.0.3;

   subnet 10.0.0.0 netmask 255.255.255.0 {
   range 10.0.0.100 10.0.0.200;
   }

   host miranda {
   hardware ethernet 00:00:39:3b:68:0d;
   fixed-address miranda.intranet.atomicvoid.net;
   }

   host andromeda {
hardware ethernet 00:50:fc:0c:3e:32;
fixed-address andromeda.intranet.atomicvoid.net;
}
}

   For a more detailed working example, see my dhcpd.conf file.

   The «host» directives inform the DHCP server to allocate a «fixed-address» to requests with a MAC address equal to the one listed by «hardware ethernet».
   The «subnet» directive informs the DHCP server that all DHCP requests result in a allocation of an IP address in the range of [10.0.0.100 - 10.0.0.200] if a client’s MAC address is not listed by one of the «host» directives.

3. Create/edit the file /etc/dhcpd.interfaces to list the interfaces dhcpd should listen on for DHCP requests:

   # $OpenBSD: dhcpd.interfaces,v 1.1 1998/08/19 04:25:45 form Exp $
#
# List of network interfaces served by dhcpd(8).
#
# ep0
# ed0 le0
# de1
xl0

   In this case, only DHCP request entering via the interface xl0 will be seen and handled by the DHCP daemon.

4. Reboot the system to have the changes take effect. Alternately, you can execute

   /usr/sbin/dhcpd -q xl0

   to start the DHCP server. Option «-q» quiets the chatter of the DHCP server and «xl0″ is the interface on which the DHCP server should listen for requests.

5. Check /var/log/daemon if the DHCP server was started succesfully.