Warren Toomey
Email: wkt@cs.adfa.edu.au
Printed June 24, 2000
We are allowed to completely destroy the Windows installation, so follow the description in the notes on how to do this. You will need to use DHCP to get your network settings, as the lab machines have dynamic IP addresses.
The download media to choose is FTP Passive, because ANU has a firewall. The name of your computer is on the sticker on the monitor, e.g g26pc11. DHCP will fill in the other details.
If you choose to install X Windows, install the 100dpi and Speedo fonts, and the Mach64 (Ma64) X server.
The mouse is a PS/2 mouse and lives on port /dev/psm0.
When you configure X Windows, choose the `ATI Mach 64' video card. Also set your mouse to `Emulate 3 Buttons'.
After you have booted FreeBSD from the hard disk, anonymous FTP to minnie.cs.adfa.edu.au and get the binary file workshop.tar. Then do:
# cd /tmp
# tar vxf workshop.tar
This will bring in many of the configuration files described in the notes.
You might like to do a
tar vtf workshop.tar beforehand to see the contents.
In preparation for the compilation of ssh later, bring in the m4 and autoconf packages when you are downloading the FreeBSD packages.
If you are using X Windows, don't set the kern_securelevel, but leave it at -1 by not adding a line to /etc/rc.conf.
We may not be able to CVSup the new kernel sources, probably due to the ANU firewall. You will still be able to configure and make a kernel from sources, though. You will need to mkdir -p /usr/local/etc/cvsup, something I forgot to put in the original notes.
If you downloaded workshop.tar, you will find a kernel configuration file called WORKSHOP where you extracted the tarball.
If you were able to successfully CVSup the kernel source, you will need to install a few changed application binaries. The reason is that the FreeBSD kernel changed its symbol table handling slightly since 4.0-RELEASE, and so programs like ps, top and w don't work correctly.
If you have downloaded and extracted workshop.tar, you will find replacements in /tmp. Do these commands to install the new versions:
# cat /tmp/ps > /bin/ps # cat /tmp/w > /usr/bin/w # cat /tmp/top > /usr/bin/top # cat /tmp/libkvm.a > /usr/lib/libkvm.a # cat /tmp/libkvm.so.2 > /usr/lib/libkvm.so.2
If you have downloaded and extracted workshop.tar, you will find a sample smb.conf configuration file where you extracted the tarball. You will need to modify it slightly to match the setup at ANU.
I'm sure someone will ask about this.
If you would like to deploy Internet mail clients (e.g Netscape, Eudora etc.) on your LAN clients, then you will need an SMTP mail server and a POP server on the LAN. FreeBSD comes with the Sendmail SMTP, but no POP server. However, there is a FreeBSD port of the Qpopper POP server from Qualcomm Inc.
I am assuming that we have extracted the FreeBSD ports during the installation. All we need to do to build and install the Qpopper program is:
# cd /usr/ports/mail/popper # make install This will take some time
Once the binary is installed, we must make one more change: we need to configure the inetd service to allow network connections to the new POP service. We edit the file /etc/inetd.conf and change the pop3 line to:
# example entry for the optional pop3 server pop3 stream tcp nowait root /usr/local/libexec/popper popper
We then find the process-id of the inetd server and send it a HUP signal to get it to re-read its configuration file:
# ps ax | grep inetd root 130 0.0 0.7 856 412 ?? Is 10:19AM 0:00.02 inetd # kill -HUP 130
The POP service is now enabled, and will be enabled after reboot. POP clients on the LAN can now access their mailboxes, and as Sendmail is already running, they can send mail as well.
You now need to configure your mail clients to use your FreeBSD box as their POP3 server and as their SMTP server. You might want to refuse external connections to the POP service by modifying /etc/hosts.allow.
I'm sure someone will ask about this.
Network address translation, or NAT, makes a FreeBSD server act as an IP proxy. As packets from the client machines pass through the server to the Internet, the source IP address is changed from the client to the FreeBSD box. Reply packets come back to the FreeBSD box, which changes the destination IP address back to the original client machine.
The effect is to make the FreeBSD box seem to be the source of all IP traffic emanating from the LAN, as viewed by the Internet. The LAN computers remain hidden, although they are communicating in an unrestricted fashion with the Internet.
Enabling NAT on FreeBSD is relatively easy. You need to first compile a kernel with the following lines in the config file:
options IPFIREWALL # Required for natd options IPDIVERT # Required for natd
With the kernel recompiled and installed, you now need to add the following lines to your /etc/rc.conf and reboot the system:
############################################################## ### Network configuration sub-section ###################### ############################################################## gateway_enable="YES" # Set to YES if this host will be a gateway. firewall_enable="YES" # Set to YES to enable firewall functionality firewall_type="open" # Firewall type (see /etc/rc.firewall) firewall_quiet="NO" # Set to YES to suppress rule display natd_enable="YES" # Enable natd (if firewall_enable == YES). natd_interface="ppp0" # Public interface to use with natd. natd_flags="-log -dynamic" # Additional flags for natd.
NAT is performed by the natd server, which runs in combination with the FreeBSD firewall functionality. We need to identify the network interface on which translations are going to be done: I have used ppp0 in the example above. For now, the firewall type is `open': no Internet packet filtering will be done. It would be worth investigating ipfw(8) to help increase your network security.
The -log flag makes natd log its operations into /var/log/alias.log. Because the ppp0 interface is not permanently up, I added the -dynamic flag to make natd watch for any changes in the IP address of ppp0 (e.g during PPP establishment).
You can now set your internal machines to use the FreeBSD box as their default gateway. I would also recommend that you choose an `internal' set of IP addresses for your internal network, such as 10.10.X.X netmask 255.255.0.0. This aids security, because the Internet will refuse to route packets with these addresses.
References