1.0) Getting the OS

First go to http://www.ubuntu.com and get the latest version you're interesting in. They offer server version that they support for 5 years or so. I suggest one of those if you want to run a server. This is an ISO, in generate around 600Mb so be ready to wait a few hours... Even with a really fast connection, because the transfer will be limited by the mirror in most cases.

2.0) Burn the CD

You need a CD burner. Ask a friend if you do not have one, but if you do so, test the CD before coming back home. To do so, boot the CD in your Friends machine and select the 2nd menu entry (after you selected the language if you are forced to do so, it is like that in 8.04, it may have happened before though.)

And if you're lucky as a champ, the first burn will work. I had to do 3 to get it to work!

3.0) Start the Installation

Insert the CD in your computer, and reboot or turn the computer on (whichever works best for you.) Select your language if queried, then select the top entry to install everything. Note that version will use a text installer

4.0) Installation Procedure (Partitioning)

For most of the installation, you should not have much of a problem. Unless you are an expert, forget multi-boot systems. Ubuntu by itself is good enough for you anyway.

If you are installing a server and want to use software RAID, then you will need to do a manual installation of your partitions. First, set the partitions to Physical volume for RAID. Then edit the RAID setup (another menu at the top of the manual setup) and finally, when you are done linking partitions, define what's what.

I strongly suggest RAID1 if you want to use RAID. Others are not as safe for your data (i.e. RAID1, if a drive dies, you still have the other 100% functioning!)

When asked what you want to install, for a the Server, it is safe to install everything unless you know for sure that certain things won't be necessary.

If installing a Desktop version, watch out because installing everything won't usually work correctly. Actually, often you should only install the base system including X11 and when you reboot, use apt-get to install other software. This is my experience of the installer. You may have better luck too. (after all, it has been several years since I tried to install a Desktop Ubuntu!)

5.0) Reboot

At some point, the installation will tell you that you're done. It's not so bad, time wise. It took me only 1h total on a PowerEdge to get the OS installed. And I would think that the installer does not run with both processors.

6.0) Booting...

Let the computer boot. If you installed a weird sendmail system, then it will get stuck for a minute on that one. It looks like they now use postfix which works properly. Otherwise, change the /etc/init.d/sendmail script or remove the S??sendmail from the /etc/rc2.d folder.

Once booted, you should get a Login prompt. Enter the name of the user you created at the time you ran the installation and his password. If you forgot the password, and wrote it really badly on that old enveloppe, then you will be good for a reboot to the rescue system that will let you fix it (good luck) or to re-install.

7.0) Firewall

As I mentioned before, you want to setup your firewall BEFORE you connect your computer to the Internet (and Intranet if you're at work or whatever non-100%-secure network.)

There is probably a way to do that "cleanly". There is a good community description of the iptables command line. However, they tell you to auto-load and auto-save, or use the command line and then save the tables. And they give you a script to do this and that. I prefer my simple solution (he! he!).

What I do is create a file named iptables (and ipv6tables) under /etc/network (seems reasonable.) And in there I type in the command line options that I want to use. This means if you do an error, you don't have to retype and or move the cursor slowly between command line options, you use your prefered editor, like vim for instance (best editor ever, right?!)

A line in that iptables file really simply looks like the command line of the iptable in your console. For instance, to allow nothing else than port 80 connections, do this:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# Allow the local network (totally open)
-A INPUT -i lo -s 192.168.1.1 -j ACCEPT
-A INPUT -i lo -s 192.168.2.1 -j ACCEPT
-A INPUT -i lo -s 192.168.3.1 -j ACCEPT
... (repeat as many times as you have local networks) ...
-A INPUT -i lo -s 127.0.0.1 -j ACCEPT
-A INPUT -i lo -j REJECT

# Allow external connections to Apache
-A INPUT -i eth0 -p tcp -m tcp --dport 80 -d 192.168.1.1 --syn -j ACCEPT
-A INPUT -i eth0 -p tcp -m state --state ESTABLISHED,RELATED -m tcp ! --syn -d 192.168.1.1 -j ACCEPT
-A INPUT -i eth0 -p all -j REJECT

You may find it useful to allow your BIND and email servers too. But this is not part of this documentation. Once you have a "good" setup (one that iptables gobbles), add rules as necessary. In general, it is a very good idea to start with close to no rules and add only what you need so your servers and clients work.

But ping does not work anymore?! Ah! Yes. The Unix tool called ping requires the icmp protocol to be open. I personately like to have it open. This is what you need to add before the REJECT line in the previous example:

-A INPUT -i eth0 -p icmp -j ACCEPT

For good security (at least to my point of view) it is a good idea to stop illegal addresses from connecting. This means all the addresses that are reserved for local networks (Intranet). The following shows what to do:

:bad_tcp_packets - [0:0]

-A INPUT -j bad_tcp_packets
-A FORWARD -j bad_tcp_packets

-A bad_tcp_packets -i eth0 -s 192.168.0.0/16 -j LOG --log-prefix "bad_tcp_packet: " --log-uid
-A bad_tcp_packets -i eth0 -s 192.168.0.0/16 -j DROP
-A bad_tcp_packets -i eth0 -s 10.0.0.0/8 -j DROP
-A bad_tcp_packets -i eth0 -s 172.16.0.0/12 -j DROP

In general, the FORWARD chain should never get such bad packets. But you are never too secure, are you?

Next I setup my OUTPUT rules. These are very similar, just use OUTPUT instead of INPUT and add the few entries you need and at the end of the chain use a LOG and DROP or REJECT. It is important to setup the OUTPUT because you may want to block some internal computers from accessing the outside. Also, that will give you accounting of all the traffic going around. You may see 1,000 hit on your Apache server, and notice 10,000 output packets. This is normal, but you wouldn't know if you hadn't any OUTPUT rules. The accounting also includes how many bytes are being transfered. This grows to Gb pretty quickly on my server.

The FORWARD chain is different. It actually requires a nat entry. And just in case you did not know yet, this allows you to plug X computers on a server and have that server forward the packets from these X computers to the Internet (or whatever network.) It is much better, if you can, to have two NIC in this case. One NIC goes to the Internet and one NIC goes to your Intranet. Otherwise, it is difficult to protect the network as well as I can do it... First you enter rules in the FORWARD chain like for INPUT and OUTPUT. At first, you can leave that all empty as the FORWARD chain, in general, is safer than the other two. Make sure that the FORWARD is working, the protect it.

The nat entry is similar to what we've seen so far. You may have noticed the '*filter' at the very beginning of the descriptions of this chapter. This means you are defining the filters. (Yeah, I know.) Filters will block packets, but they won't actually do anything to allow packet forwarding. That requires the '*nat' entries.

*nat
:POSTROUTING - [0,0]
-A POSTROUTING -o eth0 -s 192.168.2.2  -j SNAT --to-source 192.168.1.1
-A POSTROUTING -o eth0 -s 192.168.2.3  -j SNAT --to-source 192.168.1.1
-A POSTROUTING -o eth0 -s 192.168.2.4  -j SNAT --to-source 192.168.1.1
...

Obviously, you need to change the IP addresses to match your network. Yet, this will tell the server to forward packets from 192.168.2.2 (and .3, .4) to 192.168.1.1 which is the server or gateway in this case.

Alright! Now that you have typed all the firewall rules, you need to COMMIT them. Add the word COMMIT on a line by itself. This means "make all these rules I just added current". If an error occured while installing these rules, then the COMMIT fails and your firewall is not modified. Here the problem is if you reboot and there is an error. NO RULE WILL BE ADDED TO YOUR FIREWALL. So, please, try to remember that each time you change a rule, you MUST run iptables on that file to make sure that, if it ever happen, on next reboot it works.

One last note about security, you should NOT use addresses 1, 2, 3, 4, etc. in order. Instead, choose whatever random number which is still available (i.e. 199, 201, 57, etc.) This makes it much harder for hackers to penetrate any one of these systems, just in case. If the firewall works well anyway, it should not be a problem.

8.0) DHCP (why ping & dig don't find IPs)

Now a day, it is often that your server will be setup for DHCP automatically. I find it annoying since in most cases a server will be on a static address (or am I a weirdo?) In any event, you will have to edit the network interface setup. This is in /etc/network/interfaces. The following is a basic sample that will work in most cases. Obviously, do use 192.168.1.1 if you were assigned another IP. CHange the network and broadcast IPs accordingly too. The definition for a DHCP has only the first line and it says 'dhcp' instead of 'static'.

auto eth0
iface eth0 inet static
	address 192.168.1.1
	netmask 255.255.255.0
	network 192.168.1.0
	broadcast 192.168.1.255
	gateway 192.168.1.254

As a side note, your DHCP may be setup properly, mine never works in regard to giving proper name server information. That means you need to change those IP addresses in /etc/resolv.conf, but do that AFTER you changed your interface from DHCP to static IP. Otherwise the DHCP server will overwrite the file. Also, you need to kill the dhclient by hand. The following should help you on that one:

ifdown eth0
ps -ef | grep dhclient
kill <dhclient process number>
ifup eth0

The routing table won't work too well if you do not first kill the dhclient. It could also be that you should do ifdown eth0 BEFORE editing the /etc/network/interfaces file so it knows it was using a dhcp client... but where is that written in the docs?

9.0) ntpd (get the right time)

By default your server is setup to reset its clock on boot. It will query a server that is assumed to be available (namely, ntp.ubuntu.com which has never been accessible to my servers).

First I install ntpd which for now is not installed by default. Then, what I do is change the /etc/ntpd.conf file to use a few US servers that are much more responsive to me (I'm in California, after all!) Also, I restrict the computers that can access my NTP server to my local network. I prevent ALL computers to change the clock. So only the NTP server has that right.

For instance, UC Davis offers an NTP and I can use it with the following:

restrict ntp.ucdavis.edu mask 255.255.255.255 nomodify notrap noquery
server ntp.ucdavis.edu

Then I restrict just my local network:

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.2.0 mask 255.255.255.0 nomodify notrap
restrict 192.168.3.0 mask 255.255.255.0 nomodify notrap
...

Of course, you could even restrict to specific computers... Note that if you have many computers & networks, you will need to find a way to replicate the clock on different servers to not bog down your main server. Possibly, you'd need to setup a clock server.

10.0) IP Forwarding

Forwarding packets, meaning forwarding network traffic from one computer through your server and back to that computer, requires setting up the net.ipv4.ip_forward variable to 1. You can just do this to do it on the fly:

echo 1 >/proc/sys/net/ipv4/ip_forward
or
sysctl -w net.ipv4.ip_forward=1

To set it at each reboot, edit the file /etc/sysctl.conf and search for that variable and uncomment it and make sure to set it to 1.

If using IPv6, obviously, use 6 instead of 4.

Once that flag is set, you also will need to setup your iptables to include a POSTROUTING otherwise, it is not likely to work properly. The post routing tells the server how to "rename" the different IP addresses. In general, your internal network will be on a different IP address and you need to change that IP to the main server IP so the packets can go outside. The following shows an example:

*nat
:POSTROUTING - [0,0]
-A POSTROUTING -o eth0 -s 192.168.2.2 -j SNAT --to-source 192.168.1.1
-A POSTROUTING -o eth0 -s 192.168.2.3 -j SNAT --to-source 192.168.1.1
...

This last example assumes that the IP addresses of your Intranet network computers match 192.168.2.0/24. The 192.168.1.1 is your main server seeing the outside.

11.0) Samba

# "security = user" is always a good idea. This will require a Unix account
# in this server for every user accessing the server. See
# /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/ServerType.html
# in the samba-doc package for details.
   security = user

smbpasswd -a <username>

Yes. Most of the type, your customers have some sort of Win32 box seating somewhere and you've got to attach that box with your Ubuntu server. In that case, you need to install the samba server. You may want to avoid the winbind server. That can cause problems, especially if you are using a static IP address as I have shown here so far.

If you installed the documentation, then you will find it here: /usr/share/doc/samba-doc/htmldocs/Samba3-HOWTO/index.html

Samba is very difficult to debug, outside of that, it works just fine. First you need to tweak the configuration file. It is under /etc/samba/smb.conf. Just in case you do not feel confident enough, first make a read-only copy of that file so you can always look back (hmmm). I think that a better method is to learn using man smb.conf and reading the definitions of each entry for your samba server.

The big lines... the file looks like a .ini file (it is a .ini file). The [globals] define an array of options for all connections. The other [<name>] entries represent a drive or a printer or some other strange thing as defined by Netbios.

The file include a workgroup, a server name, wins support yet/no, etc. You probably want the name of the workgroup to be different from the name of your computer. This is important if you do not want to have errors in your logs saying that another computer is the master, not you.

The interfaces should be defined with the acceptable interfaces. For instance, if your Intranet is defined on 192.168.111.0/24 running on eth3, then put that in there. It will prevent connections from any other computer if you also set bind interfaces only to true.