There is a MySQL database server installed in each box, along with the
necessary clients and libs. Packages like the Apache web server and
the Exim mailer daemon are set up MySQL-ready, where applicable.
Since not everybody needs an SQL database in his box, and it has a
certain memory footprint when it runs, it is disabled by default.
To enable it just activate its start/stop script '100.mysql-server.sh'
under '/usr/local/etc/rc.d'.
Note that we left the preinstalled MySQL pretty much unconfigured to
not interfere with what you want to do with it. We suggest that, in
case you do not have much experience with MySQL, you first read up on
its administration, especially to get the access permissions right.
MySQL is one of the few daemons that does not have SSL encryption built
in. In our setup its IP port is in a range that is firewalled against
Internet access to prevent people from stealing your data. This means,
however, that you cannot directly access the MySQL server from the remote.
For this, we suggest you take a look at '/usr/local/etc/rc.d/900.stunnel.sh'.
There is a solution in it to establish an SSL encrypted link for MySQL
to some remote place. Alternatively, you could use SSH's port forwarding.
The choice is yours.
MySQL is accompanied by 'mytop', a character based
application that shows you the current MySQL sessions in the same way
'top' displays information about running processes.
|
|
|
As an alternative to MySQL, which is more suited
for applications that require a lightweight, resource efficient SQL
database, there is also a PostgreSQL database server installed, for more
heavy duty tasks. It is not as fast as MySQL, but in turn its SQL standard
implementation is more complete.
In order to enable PostgreSQL you first need to
create the actual database on disk. The command (as user 'root')
su -l pgsql -c initdb
creates the necessary files under '/var/db/pgsql'. The database daemon
can then be enabled by activating the start/stop script '110.pgsql.sh'
under '/usr/local/etc/rc.d'. The rest is normal PostgreSQL administration.
You can find the online documentation in your "Server Box Information
Area". Note that PostgreSQL expects its config file 'postgresql.conf'
in the top data directory, that is, in '/var/db/pgsql' by default.
|
|
|
Besides CVS, which is part of the FreeBSD base
distribution, there is Subversion installed, a modern version control
system that is similar to CVS, but without sharing some of its major
disadvantages. The client ('svn') can be used right away to access
remote Subversion servers. However, for hosting a repository in your
own server box some configuration work is required.
First of all, if there is no user 'svn' in your
'/etc/passwd' yet, as user 'root' you have to add the following line
with the 'vipw' command:
svn:*:65527:65527::0:0:Subversion repository user:/nonexistent:/sbin/nologin
Also, with a normal text editor, add the line
svn:*:65527:
to file '/etc/group' if that group does not exist yet. Note that newly
created boxes have that user and group already. Next, you need to
initialize the repository by entering the command:
su -fm svn -c '/usr/local/bin/svnadmin create --fs-type fsfs /var/db/svn'
This creates the necessary structures under
'/var/db/svn' as user 'svn'. Once they exist you can set up access
permissions and authentication data by editing the files under
'/var/db/svn/conf'. Detailed information about how to do this is
available online at "http://svnbook.red-bean.com", chapter "Server
Configuration".
Finally, the start/stop script for the server
process 'svnserve' under '/usr/local/etc/rc.d' needs to be activated by
renaming the file '.420.svnserve.sh' to '420.svnserve.sh'. After
rebooting the box you can start using the repository. Access from
within the box would look like this:
svn list svn://localhost/
From the remote, 'localhost' just needs to be
replaced by a valid domain name pointing to your server box.
Authentication is normally necessary only once because the Subversion
client caches the login data and reuses it automatically with each
subsequent connection.
|
|
|
We included a complete domain name server (DNS) in your box (Bind).
By default it is set up as a resolver, and, for security reasons, can
be queried only from inside the server box it runs in. However,
if you would like to use it as a primary or secondary DNS for
some zones, just do so. But note that it is extremely easy
to break a DNS configuration if you do not know very well what you
are doing, and sometimes even then.
So if in doubt whether you are really up to it, better do not
touch it. Otherwise you might not even be able to log in anymore.
You can find the name server's configuration under '/etc/namedb'.
If you do want to use your box as primary or secondary DNS, note that
due to Internet regulations a zone has to be provided by at least
two independent entities, that is, machines, which also must have
IP addresses from separate networks.
|
|
|
|
The classical UNIX editor is 'vi'. We additionally installed 'vim', a
"VI Improved" which has a lot of additional functionality like
multi-window support etc. Nevertheless, any VI is a pain for less
experienced users. Therefore there are also 'joe' and 'pico'. Pick
the one you like best.
|
|
|
Apart from the software you compile and install yourself
there is the FreeBSD Ports Collection where you can get thousands of precompiled
packages. For almost all software you get for Linux there is a port
for FreeBSD, too. Have a look at
http://www.freebsd.org/ports/
Before you actually install one of those packages,
check with the 'pkg_info' command whether the package is already there,
since it is not that good an idea to install a package over an already
existing one. Instead, we recommend to contact and ask us for an update
of the respective package, if required. We normally comply with these
requests since we are always interested in improving our system, preferably
centrally and therefore for all users.
In order to install a precompiled package you need
to download it from the FreeBSD server (see link above). Please note that
the "Package" links on the FreeBSD Ports pages point to binaries compiled
for FreeBSD 5.x and above while you would need packages for the more
mature FreeBSD 4.x our system is based on. So once you have found out
the package name you would use the command
pkg_fetch <packagename>
Just replace <packagename> with the exact
package name from the FreeBSD Ports pages, including the version number.
Provided a precompiled package is available for the respective port
'pkg_fetch' will then download the file and deploy it under
'/usr/ports/packages/All'. Alternatively, you could also visit the
FreeBSD FTP server directly in order to fetch the required files.
Next you would run the command
pkg_add /usr/ports/packages/All/<filename>
If 'pkg_add' complains about missing prerequisite
packages, check the (optional) 'Requires:' line of the port (on the
FreeBSD Ports pages) and install the required packages first (with
'pkg_add' as well). Note that prerequisite packages can have a
'Requires:' line of their own. The dependency system works hierarchically.
Another way to obtain the dependency list of an already downloaded package
file would be to run
pkg_info -r /usr/ports/packages/All/<filename>
If a prerequisite package is already preinstalled
by us and differs only slightly in its revision number from what 'pkg_add'
requires, you can normally ignore that difference. Use the '-f' option
to force 'pkg_add' to accept the preinstalled package in order to
minimize the number of components you have to install yourself.
Once all necessary packages are installed you
can use the software, after the obligatory 'rehash' in csh/tcsh.
In order to save disk space you may want to delete the files under
'/usr/ports/packages' when you are done with testing.
Note: Please do not use the '-r' option of
'pkg_add', even if that appears to be more convenient. The remote
fetching feature has a tendency to install prerequisite package even
if they differ only slightly in their revision number from what is
already installed. This means that you would end up with a number of
private copies of packages basically identical to those that are
already preinstalled. This would not only allocate additional disk space
in your server box, you would also lose the central management feature
for the affected packages.
In case you would like to get rid of a package
again, use
pkg_delete <packagename>
or if the package was installed over a centrally maintained version
the command
pkg_delpriv <packagename>
would be more appropriate since it automatically restores the original
(shared) files.
Note: For all software you bring you will have to
take care of maintenance and security yourself. We can neither know of
its existance nor are we able to maintain it in the same centralized way we
use for our preinstalled software. Also, by installing binary packages
compiled elsewhere you will not have the built-in stack smash protection
you would get with software compiled directly in your box.
|
|
|
|
