A duplicate FreeBSD server, built on chrome, would provide a backup should crimson die. Since chrome was even slower than crimson (100MHz vs. 120MHz), I decided to installed packages (pre-compiled ports) whenever possible.
The FreeBSD version of chrome was built from the FreeBSD 4.9 CD, downloaded from the web. This was the first time I had built FreeBSD with a large amount of disk to play with (60GB). I placed the new disk into chrome as master disk on the primary IDE channel. I wanted to built the disk with one large slice, containing the following partitions (FreeBSD terminology):
/ /var /tmp [swap] /usr /usr/local /home /opt
When I tried to define the last partition, it was given a device
X. I discovered (as I should have known all
along) that FreeBSD only allows eight partitions per slice, one
of which (ad2s1c) is reserved to address the entire slice,
leaving only seven partitions to play with. The partitioning
scheme I wanted was not going to work. I then tried to create
two slices, with /opt on the second slice. The install seemed
to go fine, until I tried to reboot and got "Invalid Partition
Table" as the only message on the screen.
Some googling indicated that sysinstall was a bit flaky in building partition tables. I therefore installed the FreeBSD drive as master on the secondary IDE channel, re-connected the Linux disk, and booted into Linux. The Linux fdisk program was used to define two partitions on the FreeBSD drive. I then re-installed FreeBSD on the freshly created partitions, using the following scheme:
Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad2s1a 120926 46890 64362 42% / /dev/ad2s1h 23834554 402310 21525480 2% /home /dev/ad2s2e 30269782 278534 27569666 1% /opt /dev/ad2s1f 251950 10 231784 0% /tmp /dev/ad2s1g 4129310 1947378 1851588 51% /usr /dev/ad2s1e 251950 5564 226230 2% /var
I choose to install the
All option from the CD, Once
this was complete, I installed the following packages:
Cupsd 1.1.19 out of the ports failed to work properly. It was impossible to define a printer using the web interface (http://localhost:631), as every time a printer was defined, the error message "Request Entity Too Large - The request is too large for this server to process." was issued. Google indicated that was a previously encountered problem, and the recommended solution was to build from ports. I therefore cvsup'd cupsd and built it on chrome. Once this version was installed (some time later), cupsd worked. So much for my idea of minimising the amount of compilation necessary.
In configuring the printer to cups, using the web interface
http://localhost:631), make sure the printer is turned
on. If not, cups will not present an option to set the
connection as the parallel device (
After building the world and kernel, using a customised kernel configuration file, apache refused to start, with the error message: "default_listeners(): getaddrinfo(PASSIVE) for family 28: No address associated with hostname". There was little on this particular error message on the web, but a response from Matthew Seaman to a similar query provided the necessary clue:
Looks like apache is getting mixed up with IP6 addresses --- /usr/include/sys/socket.h has #define AF_INET6 28 /* IPv6 */ I've never seen that happen myself on an IPv6 capable FreeBSD box, so I'm at a loss as to what to suggest. Only thing I can think of is to try using Listen directives in your httpd.conf to force it to bind to your IPv4 addresses only."
This seemed plausible; my custom config omitted IPV6. A quick
look at pkg_info confirmed this assertion; the package version
was actually called apache-ipv6. I therefore deleted this
pkg_delete, and built the version from
Sendmail had to be built from the ports anyway, as I had to turn off IPV6 support (for the reason why, see The Sendmail Saga. One challenge was yet to be faced: how to configure sendmail to deliver to machines in the domain without masquerading the sender address, but to deliver mail to outside domains with the masquerading. Exim on the Debian version of chrome had been configured this way; surely it was possible to set sendmail up the same way? That's a retorical question - I found the solution for sendmail.
The only other major difference between the two systems was the
method of burning CDs. Debian used
burncd. At least
require any messing about with SCSI drivers. As on Debian, an
iso image has to be created first (using mkisofs), then burncd is used
to write the image to a CD. The most frequently used commands
mkisofs -U -o backup.iso directory # create iso image burncd -f /dev/acd0c -s max blank # erase CD-RW disk burncd -f /dev/acd0c -s max data backup.iso fixate # burn backup.iso