Here we will walk through setting up a new server and explain what is going on along the way


The goals of this document will be to set up date and time, hostname, dhcp server, dns server (with DDNS), and mail server.

  1. Date and time is very important to set up: date.html
  2. Hostname is equally important to set up properly: hostname.html
  3. DHCP server instructions are here: dhcpd.html
  4. DNS (named / bind) instructions are here: named.html
  5. sendmail should already be set up, see below for more notes on setting up sendmail
  6. enable remote mail access – ipop3 and/or imap — see below for more notes
  7. then add a user in linux
  8. then configure the workstations mail client
  9. Okay, let’s
    Let’s add a new user:
    useradd j1

    He can’t log in until he has a password:
    passwd j1

    Now lets make sure we can send him mail (should be set up already by default):
    echo Hello | mail -s “Welcome Aboard” j1

    Now have that user check his mail:
    CTRL+ALT+F2 (switch to another console)
    login as j1
    mail (running “mail” by itself will start checking your mail)
    h – gives you the headers (subject lines)
    1 – pressing a number then enter will bring up that specific message
    enter – pressing enter will move you forward through the mail program
    q – pressing q will “quit” mail and save your messages in ~/mbox
    x – pressing x will “exit” mail and will leave your messages in the mail spooler
    Okay, mail looks good. j1 was able to receive the message from root, so now we know that the mail is working good. Now we need to check a few other things like sendmail, pop3, and imap services.

    Let’s do a chkconfig –list sendmail to make sure that it is turned on for levels 2 through 5.

    sendmail       	0:off	1:off	2:on	3:on	4:on	5:on	6:off
    

    If sendmail is not on for levels 2, 3, 4, and 5, then let’s turn it on:

    chkconfig --level 2345 sendmail on
    

    For an explanation of why we care about runlevels 2 through 5 please see the table in /etc/inittab: sysinit.html#inittab. The short summary is that runlevel: 0 is halt, 6 is reboot, 1 is single user (no networking), 3 is normal bootup (no GUI), and 5 is normal bootup with GUI, 2 and 4 are unused (you can modify this to do your own “special” things). Also of importance in /etc/inittab is the line just below the table that reads: “id:5:initdefault:”, that is how you choose your default init level on bootup. And lastly 2 tools you have to mess with runlevels is “runlevel” and “init”. “runlevel” will show you your previous and current runlevels, and “init” will change your current runlevel.

    Okay, now j1 wants to be able to check his mail from is workstation, rather than logging into the server to check his mail. We need to enable either pop3 or imap so he can set up his mail client. pop3 and imap are both controlled by xinetd and are not configured in /etc/rc.d/init.d/.

    cd /etc/xinetd.d/
    ls (take note of ipop3 and imap in this directory)
    vi ipop3
    change the line that says "disable = yes" to "disable = no"
    Do the same thing for imap if you want imap enabled
    service xinetd reload (After modifying any of the services xinetd is responsible for
                           you must notify xinetd that you made a change.  Running the
                           service xinetd restart command will allow xinetd to re-read
                           each of those config files in /etc/xinetd.d/ )
    

    There are two primary ways that “services” get started on a Linux box:

    1. /etc/rc.d/init.d/ – services started here are always running.
    2. /etc/xinetd.d/ – services controlled by xinetd are only started as needed.

    See sysinit.html#inittab for more details.

    As shown above, the difference between /etc/rc.d/init.d/ and /etc/xinetd/ is the fact that the one runs its services all the time and the other only starts those services as needed. Xinetd notices all the services it is responsible for and remembers the port numbers for each service. These services do not run yet. You can investigate this by using “ps ax”. Then when a message comes in requesting to speak to some service that xinetd knows about (based on which port number it came in on) it then wakes up that service and the service receives the incoming message. Once the service finishes its work with the incoming message, that service is then stopped once again.

    Use “ps ax” to look for sendmail and ssh, notice that they are called in /etc/rc.d/init.d/, you will find that they are always running, even though no one is currently using sendmail nor ssh.

    Use “ps ax” to look for ftp, pop3, and imap. Notice that these services are not running because no one is currently using those services. Try starting ftp and have it talk to this server, you will then be able to find wu-ftp or vsftp in “ps ax”. The same goes for pop3 and imap, you will see them in “ps ax” when you actually have a client request those services — then when the client is through with those services, those services will then stop once again.

    More info about network ports can be found here: network-ports.html

    It turns out that sendmail wasn’t listening to our ethernet card, it was only listening to the internal loopback network interface. So we edited /etc/mail/sendmail.cf and commented out the line: “O DaemonPortOptions=Port=smtp,Addr=127.0.0.1, Name=MTA”, then we restarted sendmail (service sendmail restart) and then it would listen to the network card. We tested this out because of the following telnet commands: “telnet 127.0.0.1 25” and “telnet 10.0.0.1 25” (where 10.0.0.1 was the ip address of this sendmail server).

    After configuring dhcp and dns, we then configured the client to get dynamic ip address and to “obtain dns address automatically”.

    We then configured the mail client on the workstation for pop3 or imap access

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.