CS 470 Grossmont College Rocky Linux plus NFS & FreeBSD plus E mail Service Labs

CS 470: Unix/Linux SysadminSummer 2021 Lab 2
FreeBSD + e-mail service
This lab gets our hands dirty with the far-and-away most prominent free-and-open-source BSD-derived
operating system, FreeBSD. Whereas OpenBSD has always focused on being the most secure operating
system (see http://www.openbsd.org/goals.html), FreeBSD has always been focused, in their own words, “to
provide a stable and fast general purpose operating system that may be used for any purpose without strings
attached.” (https://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/introduction.html#idp44542712)
OpenBSD was quite unabashedly only for power users and hackers … which means the operating systems
mostly get easier from here. Pat yourself on the back, you’re over the proverbial hump.
To this end, FreeBSD’s codebase is much larger by comparison with OpenBSD, and the amount of supported
hardware and third-party software is much greater. There are also a lot more creature comforts all around;
this is because FreeBSD makes less assumptions about its users’ level of skill or threshold for pain, and has a
much larger community of developers and users – notably, FreeBSD is extensively used in the development of
macOS, the Sony PlayStation line of gaming consoles, under the hood of Google’s search engine, and inside
Juniper routers … the latter two obviously because of FreeBSD well-established reputation for having the
fastest TCP/IP stack in it, of any operating system. For many years, the fastest and highest-traffic internet sits
ran FreeBSD, until the time where statistics were no longer feasible.
Once upon a time, Facebook had a program to bring the Linux kernel’s famously bad IP stack up to parity with
FreeBSD’s.
https://www.theregister.com/2014/08/07/facebook_wants_linux_networking_as_good_as_freebsd/
Back up the greater scheme of things, we have plumbed IP and name service for our little private network as
of lab 1; now we need a way to see what all of our systems are telling us on an ongoing basis, as we delve into
system internals. FreeBSD is going to be our mail server, to help us up scoop all this data.
‼ IMPORTANT NOTE: after setting up this lab, you will want to start leaving your VMs on overnight. A lot of
cron jobs run during the late hours, by design, and we want you to see their output!
part one: installing FreeBSD
1. Grab the latest FreeBSD (version 13.0 as of the time of this lab) installation “disc1” ISO from the
following URL. It’s almost a gigabyte, and will take a little while.
https://download.freebsd.org/ftp/releases/ISO-IMAGES/13.0/
Again, we want the amd64 CPU architecture, unless you somehow are using an antique. If so, grab the
“i386” architecture ISO … everything else should be the same. Also note, there’s an x-zipped version
(ending in “.xz”) that’ll save you some time downloading, but xz is the most successful at shrinking files
in part because it’s the most CPU-intensive algorithm. Just know that you pay in wait time after you
download, if you go this route.
Look around FreeBSD’s website at www.FreeBSD.org … in particular, I’d like you to notice …
1
a) The release notes for version 13.0 (https://www.freebsd.org/releases/13.0R/announce.html), and
within that, the “availability” section explains what the various downloads contain, and in some cases,
how to use them. “Release notes” are typical for all software releases … OpenBSD has a very similar
document. I just didn’t ask you to look … but I suggest you do.
b) The security advisories page (https://www.freebsd.org/security/advisories.html) … click on one of
the links. Note how affected versions of each advisory are listed, along with descriptions, directions,
and signed source code for the fix. Again, all base operating system patching in BSD-land was up until
recently was always done manually, by re-compiling affected pieces of the operating system. I’m
tormenting you enough, but wanted to point out how the patches are delivered as source, with
instructions.
OpenBSD also has an errata page, with the same stuff: http://www.openbsd.org/errata69.html
2. Create a new, custom virtual machine in your VMware product, whichever you’re using. On this
system, let’s use the following specifications:
CPU: single virtual core/processor
RAM: 512 MB
Hard disk: 30 GB
guest OS: FreeBSD 12 64-bit
Note that even though it’s under the “other” menu in VMware Fusion here on my laptop, FreeBSD has
enough market share to get its own entry in VMware hypervisors … but VMware hasn’t updated this
list since FreeBSD 13 was released. Choosing the “guest OS” configuration option for FreeBSD 12 will
be just fine.
3. Boot the VM, and notice the menu for the boot loader with the nifty ASCII art. We can already see
with the menu that we’re in for at least a slightly different experience than with OpenBSD … but if we
wanted a command line, we could get it here, with option #3. That said, we just want to “boot multiuser” here … even though we’re not really booting multi-user, since this is the installation media.
2
FreeBSD’s mascot is a daemon … not a demon, but a “daemon,” while Beastie (yes, that’s his name)
looks slightly devilish, he takes his name from service daemons, and has gotten tweaks over time.
When BSD got the “fast” file system (AKA “FFS” or “ffs”), Beastie got sneakers in a lot of the BSD
merchandising and art … and the most popular version was drawn by none other than John Lasseter,
long before John was the creative leader at Pixar, or the head of Disney Animation.
Beastie also has a fork, because Unix daemons fork() processes, as you might know from the operating
systems class (CS570).
4. Once you’re done with the march of text output – this is the kernel enumerating various devices and
which drivers to use with them – you’re presented with this menu. Already a whole lot different from
OpenBSD.
‼ IMPORTANT NOTE: the tab key changes sub-sections or areas within the FreeBSD installer …
generally the arrow keys can be used to move around within areas of an installer “window.”
‼ ALSO IMPORTANT NOTE: if you ever get diagnostic messages printed over the installation interface,
like in the screenshot above, control-L is often honored as a request to re-draw the terminal window.
3
Ah, much better. Let’s choose to install.
5. You’ll see a lot of the options line up decisions we had to make during the OpenBSD installation
process, for instance choosing a keyboard layout (map). The default should here should be fine. If
mess anything up along the way, you probably won’t need to start over; FreeBSD will ask you at the
end if you’d like to change anything before rebooting into your freshly-installed VM.
When asked to set a hostname, use “freebsd” all in lower case.
On the distribution selection page, deselect kernel-dbg, and select src … use the space bar here to
toggle selections, and in screens like this.
At the partitioning dialog, select “Auto (UFS)” and then “entire disk,” and whatever is presented as the
default partitioning scheme … because I was pleasantly surprised to find that the automatic
configuration in FreeBSD now makes use of a single partition for the file namespace, and makes a sane
decision about swap size. It should look like the screenshot below, with the bulk of the disk in a single
4
root filesystem, and roughly 2 to 3 times RAM as a dedicated swap space. If it doesn’t, modify your
layout to make sure it does.
Once upon a time we used to use partitions as the rule rather than the exception; exponentially
cheaper disk space is a huge driver for not partitioning.
If your disk device is da0, this is not a problem … it just means VMware picked you a SCSI device (driver
name da, the first instance of which is zero, of course. ada is the device driver name for disks attached
to ATA or SATA buses.
Notice that unlike OpenBSD, FreeBSD considers its MBR partition a part of the device namespace … the
disk is ada0, the FreeBSD partition is s1 (slice one), and like OpenBSD the root filesystem is a and swap
b. All BSD-derived OSs use letters a through h for their partitions. AT&T-derived OSs use the numbers
0 through 7, as we will see.
Making the slice part of the namespace makes more logical sense if you have multiple partitions on a
single physical or virtual disk, like if you were dual-booting. A Windows partition would show up as
da0s2, or ada0s2. In OpenBSD, DOS/Windows partitions show up as partition letters after h.
After you’re done here, select “finish” and the installer will, as all do, ask you to confirm you’re really
ready to wipe out the prior contents of the drive. You’ll then see the “archive extraction” screen …
… the src tree will take a little while; it is full of lots of small files.
You’ll then be asked for a root password. Choose a good one!
6. Network configuration … you should only have one NIC in your VM. Mine was le0 last time, this time
it’s em0. It doesn’t matter which one you have, so long as the installer detects a network interface.
VMware supports several kinds of emulated NICs, and just like with the disk devices in the prior step,
each set of letters denotes a different driver, in turn for a different set of devices. em is an Intel gigabit
NIC; le is a “Lance” ethernet chip, now put out by AMD.
We want to configure IPv4 for this interface, but not IPv6. We do NOT want to use DHCP.
5
!! IMPORTANT NOTE: if your OpenBSD VM isn’t turned up right now, make sure it is, because we’re
about to be using it as the name server. As a general rule, you will always want ALL your VMs up and
running together during labs. If your laptop starts bogging down, turn down other VMs first, but leave
the two BSD-based VMs up!
You will want to substitute in the first three octets of your private IP network for what you see in the
next screenshot, but everybody’s FreeBSD VM should be .72. Of course, use the same router as in lab
one. The default gateway does not change in between computers on a subnet; it is a fixed value for
the whole network. This screenshot is from Catalina last year, so I got .2 here.
VMware may ask you to provide your password for your “host” (non-virtual) operating system to allow
the guest permission to asset up the network properly. Please provide it.
Finally, you’ll be asked to provide the resolver configuration for DNS. Your search path should be
cs470.local (the DNS namespace we set up in lab 1), and your only name server should be the IP
address of your OpenBSD VM.
6
7. You’ll be asked to set the time zone, then to choose services you want to be started at boot. sshd and
dumpdev should be pre-selected, and we want them running. Add ntpdate to set the clock at boot
time, ntpd to keep track of the time as the VM runs, and powerd, to save you some electrons.
The “system hardening” screen is next. You may leave all these boxes unchecked.
You’ll then be asked if you want to add users to the installed system … take this opportunity, and do so.
‼ TIME AND PAIN-SAVING TIP: Keep using the same username across all your systems, to avoid having
to tell SSH your username. SSH assumes the same username if you just tell it the system name/IP you
want to access.
Use user ID number 1000, same as the OpenBSD installer used for you. You’ll see why we do this later.
The default login group option (a group of your own) is fine.
7
Add yourself to the wheel and operator groups in the next question, separated by a space, so we can
become root with this user, and perform certain privileged operations without becoming root or using
sudo.
After your user is created, don’t create another.
You’ll make it to the “final configuration” menu, where you’ll have the choice of revisiting a lot of the
prior options, if you want to change anything you selected. If you do, great, go! Experiment! If not, or
when done, select “exit.” Then tell it you don’t want a shell, and that you want it to reboot. Your
FreeBSD installation is complete, and your system will reboot into multi-user mode.
8. Log into the console of your FreeBSD system, and make a .ssh directory inside your home folder.
$ mkdir -m 700 ~/.ssh
Now, copy your SSH public key over into the authorized_keys file, as usual, so you can use your key
and agent to log into your FreeBSD VM. Now your setup is truly complete.
9. Now let’s check out where the FreeBSD put most of the options we chose during installation.
$ more /etc/rc.conf
My output looked like this; it should be needless to say at this point that yours will look slightly
different, depending on the first three octets of your VM network and what kind of NIC your VM is
using.
hostname=”freebsd”
ifconfig_em0=”inet 192.168.223.72 netmask 255.255.255.0″
defaultrouter=”192.168.223.1″
sshd_enable=”YES”
ntpdate_enable=”YES”
8
ntpd_enable=”YES”
powerd_enable=”YES”
# Set dumpdev to “AUTO” to enable crash dumps, “NO” to disable
dumpdev=”AUTO”
Note that the network configuration here in rc.conf is mixed with service configurations. Also note,
the file is relatively short for a full system configuration. This is because FreeBSD has a set of
“defaults” configuration files under /etc/defaults that it reads before local configuration to do the
rest. Take a second to look briefly through all the settings and on/off switches for built-in services.
This file, by comparison, is much much larger … with the goal of giving you a smaller rc.conf to look at,
where you made only the changes to set or override whatever boot variables you want.
$ more /etc/defaults/rc.conf
On OpenBSD, /etc/rc.conf.local (with the changes) is parsed after the defaults in /etc/rc.conf.
OpenBSD stores its network interface configuration(s) in /etc/hostname.* files, named by interface
driver and number, and its default gateway in /etc/mygate. FreeBSD stores its default gateway in a
statically-named shell variable (defaultrouter), and stores its network interface configuration(s) in
shell variables, named by device name and number.
10. Remember the login banner? Fear not if you don’t … since the dawn of time it’s been in /etc/motd
like OpenBSD, and will be found in the same place on virtually every OS we play with. Not anymore,
though
$ more /etc/motd
/etc/motd: No such file or directory
Not anymore, apparently, and more than a few have chalked this up as an annoyance with the justreleased FreeBSD 13.
https://forums.freebsd.org/threads/freebsd-13-annoyances.79815/page-4
Many more have complained about this release than previous ones. This change to motd appears to be
driven by jealousy of Ubuntu’s login information, which we’ll see soon. motd will now be generated
dynamically, to presumably be able to add more that isn’t there quite yet … it comes from a template
now …
$ more /etc/motd.template
Welcome to FreeBSD!
Release Notes, Errata: https://www.FreeBSD.org/releases/
Security Advisories:
https://www.FreeBSD.org/security/
FreeBSD Handbook:
https://www.FreeBSD.org/handbook/
FreeBSD FAQ:
https://www.FreeBSD.org/faq/
Questions List: https://lists.FreeBSD.org/mailman/listinfo/freebsd-questions/
FreeBSD Forums:
https://forums.FreeBSD.org/
9
Documents installed with the system are in the /usr/local/share/doc/freebsd/
directory, or can be installed later with: pkg install en-freebsd-doc
For other languages, replace “en” with a language code like de or fr.
Show the version of FreeBSD installed: freebsd-version ; uname -a
Please include that output and any error messages when posting questions.
Introduction to manual pages: man man
FreeBSD directory layout:
man hier
To change this login announcement, see motd(5).
The FreeBSD Handbook is a far more comprehensive walkthrough-style documentation for a nearcomplete set of features of FreeBSD. We’ll be talking shortly about how various operating system file
hierarchies are laid out, but wanted to make a point of showing this off … most other operating
systems don’t have a neat man page with a guided tour through their file tree.
$ man hier
Again, use return to scroll through line-by-line, space to load another page.
11. Finally, let’s add the ports tree. You may have noticed that, like with OpenBSD, there was a copy of the
ports tree that was offered to us during installation. This ports tree is a checkout of the ports tree,
without real capability to update, so we’re going to use a rolling version of the ports tree.
FreeBSD has a command, portsnap, that specifically deals with getting snapshots of the ports tree and
keeping it up to date. Use su to become root (note the pound sign prompt below), and grab and
extract the ports tree with portsnap.
# portsnap fetch extract
Looking up portsnap.FreeBSD.org mirrors… 4 mirrors found.
Fetching public key from ipv4.aws.portsnap.freebsd.org… done.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org… done.
Fetching snapshot metadata… done.
Fetching snapshot generated at Sat Jul 17 17:04:03 PDT 2021:
f1fbad6a1586f38f89ca09159d730c73dd7d2bf64a89f1
91 MB
11 MBps
08s
Extracting snapshot… done.
Verifying snapshot integrity… done.
Fetching snapshot tag from ipv4.aws.portsnap.freebsd.org… done
Fetching snapshot metadata… done.
Updating from Sat Jul 17 17:04:03 PDT 2021 to Sun Jul 18 13:11:12 PDT 2021.
Fetching 5 metadata patches… done.
Applying metadata patches… done.
Fetching 0 metadata files… done.
Fetching 117 patches.
(117/117) 100.00% done.
done.
Applying patches…
10
done.
Fetching 11 new ports or files… done.
/usr/ports/.arcconfig
/usr/ports/.gitignore
…
The above output is provided for context; you will start to see the paths of ports listed, and this whole
process will take a few minutes. Not a really long time, but a few minutes. We’re grabbing a large set
of small files from online sources.
If this command fails, because “host not found” then your DNS server or network setup is messed up.
Did you get your name server working properly and validated on that system?
part two: installing software
Now let’s install some software on your FreeBSD VM.
12. First and foremost, let’s install sudo, so that you don’t have to walk around as root. Run the following
command … again, for the last time I’m going to remind you the pound sign prompt means that you
run su to become root, then type the command above to build sudo … don’t type the “$” or the “#” …
# cd /usr/ports/security/sudo && make install
You will notice FreeBSD building pre-requisites, including pkg, FreeBSD’s package management system.
At a certain point during the installation, you’ll see a menu like this …
… where FreeBSD has selectable features for software in the ports tree, it will present you this screen
to allow you to choose the options. If you have a sense of humor and thick skin, I highly recommend
the “insults” option … it’ll poke fun at you when you fat-finger your password. Some of you may have
already seen this, if you fat-fingered your password using sudo on OpenBSD, which builds sudo in the
11
ports tree with insults enabled by default.
Select “OK” when you’re done here.
You may still be asked to select options for a couple dependencies after that, so don’t walk away for
too long … come back soon. We’ll deal with this during the next build. When sudo is done building,
you should see something like this …
… type exit to quit your root shell (that you started with su). That said and now that we have sudo
installed, you don’t need to be root all the time, just to put sudo in front of command you want to be
run as root.
‼ IMPORTANT NOTE: typos with sudo can be just as painful as typos on a root command line. ALWAYS
double check commands to be run with elevated privileges before hitting the return key.
Next, let’s try to install bash. I’ll explain the differences here in this command shortly.
$ cd /usr/ports/shells/bash && sudo make -DBATCH install
sudo will ask you for your password, and again, this is your user account password, not the root
password you configured at installation. Unless you did something different from me, you’re
presented with the following error message:
peter is not in the sudoers file.
This incident will be reported.
Again, looks like we need to set up sudo first. Become root again, with su, and run …
# vi /usr/local/etc/sudoers
12
Note that FreeBSD puts configuration files that would ordinarily go in /etc into /usr/local/etc for
software built in the ports tree. While you’re editing the sudoers file in vi, uncomment the line
allowing the wheel group to run any command, by removing the pound sign at the beginning … but not
the line allowing them to do so without a password.
Note that the sudoers file is treated with the utmost caution … the permissions on this file cause it to
be opened in read-only mode in vi …
root@freebsd:/usr/ports/shells/bash # ls -l /usr/local/etc/sudoers
X11 forwarding request failed on channel 0
-r–r—– 1 root wheel 3632 Jul 18 07:06 /usr/local/etc/sudoers
… so you will have to use a bang (!) after :wq to tell vi that you REALLY want to write out the file and
bypass its read-only permissions, even as root.
13. Now that we’ve fixed sudo, let’s try to build bash again. This time, however, we don’t want the ports
subsystem to stop us to ask for options, so we’re going to tell the ports tree we want it to run in
“batch” mode. Go into the bash port directory and build bash:
$ cd /usr/ports/shells/bash && sudo make -DBATCH install
-DBATCH is equivalent to setting the shell variable BATCH. We could do this on the command line, in
our shell’s environment like we did for TERM in single-user mode on OpenBSD, but sudo filters
environment variables with good reason … keep in mind that warning that the ports tree gave us about
sudo having security repercussions.
bash has a lot of dependencies, including perl, and this will take a few minutes, but when it’s done,
we’ll finally have bash, and like in OpenBSD, you can use the chsh command to change your shell to
/usr/local/bin/bash. Note that chsh drops you into a vi window where you’re expected to alter a
13
temporary file, which gets parsed and read back into /etc/passwd and /etc/master.passwd, like in
OpenBSD.
When the ports tree installs a shell, it’s added to the file /etc/shells, which contains the list of
acceptable values for a user’s login shell in /etc/passwd.
‼ IMPORTANT TIP: when an error happens while building ports, scroll upward to the first error
message. The last is often the effect of a resulting cause, or a resulting cause of a resulting cause, and
we want to know where the problems began, the “root cause.” This is why we often send output to a
file, and prefer to SSH into our VM and use software-based terminals instead of the console … it makes
it way, way easier to scroll back to find the root cause of a problem.
14. Next, let’s add GnuPG. Again, we need this on every VM for the grading software later in the class.
$ cd /usr/ports/security/gnupg && sudo make -DBATCH install
GnuPG has a lot of dependencies, even more than bash, so once it’s started running, might be a good
time to grab something to drink, stretch, or do whatever you do. After a little while, you should see
output like this …
===>
Registering installation for gnupg-2.3.1
Installing gnupg-2.3.1…
When run on hosts without IPv6 connectivity, GnuPG may fail to connect to
dual-stack hkp servers [1]. As a workaround, add:
disable-ipv6
to:
/usr/local/etc/dirmngr.conf
[1] https://dev.gnupg.org/rGecfc4db3a2f8bc2652ba4ac4de5ca1cd13bfcbec
===> SECURITY REPORT:
This port has installed the following files which may act as network
servers and may therefore pose a remote security risk to the system.
/usr/local/bin/watchgnupg
If there are vulnerabilities in these programs there may be a security
risk to the system. FreeBSD makes no guarantee about the security of
ports included in the Ports Collection. Please type ‘make deinstall’
to deinstall the port if this is a concern.
For more information, and contact details about the security
status of this software, see the following webpage:
https://www.gnupg.org/
14
… which means that GnuPG is successfully installed. We can ignore the warning about systems without
IPv6, as we won’t be using an HKP server to find GPG encryption keys.
15. Now, let’s install some mail server software. A piece of software for getting mail to and in between
mail servers (that is, implementing the SMTP protocol), Sendmail, is already included with FreeBSD.
We just need software to implement mail folders for, and accept delivery of, mail messages. Let’s
install dovecot.
$ cd /usr/ports/mail/dovecot && sudo make -DBATCH install
A couple dependencies this time, but building dovecot is relatively quick, when compared to GnuPG.
===> Staging rc.d startup script(s)
===>
Installing ldconfig configuration file
===> Installing for dovecot-2.3.15
===> Checking if dovecot is already installed
===>
Registering installation for dovecot-2.3.15
Installing dovecot-2.3.15…
===> Creating groups.
Creating group ‘dovecot’ with gid ‘143’.
Creating group ‘dovenull’ with gid ‘144’.
===> Creating users
Creating user ‘dovecot’ with uid ‘143’.
Creating user ‘dovenull’ with uid ‘144’.
You must create the configuration files yourself. Copy them over
to /usr/local/etc/dovecot and edit them as desired:
cp -R /usr/local/etc/dovecot/example-config/* \
/usr/local/etc/dovecot
The default configuration includes IMAP and POP3 services, will
authenticate users agains the system’s passwd file, and will use
the default /var/mail/$USER mbox files.
Next, enable dovecot in /etc/rc.conf:
dovecot_enable=”YES”
To avoid a risk of mailbox corruption, do not set the
security.bsd.see_other_uids or .see_other_gids sysctls to 0
if Dovecot is storing mail for multiple concurrent users (PR 218392).
Similarly, setting sysctls security.bsd.hardlink_check_uid or
security.bsd.hardlink_check_gid to 1 might result in non-working
mailboxes, depending on what mailbox locking mechanism is used
(PR 242223).
If you want to be able to search within attachments using the
15
decode2text plugin, you’ll need to install textproc/catdoc, and
one of graphics/xpdf or graphics/poppler-utils.
There are some potentially breaking changes in Dovecot 2.3. If you
are upgrading from Dovecot 2.2:
* Read https://wiki2.dovecot.org/Upgrading/2.3
* Merge the configuration file changes from
/usr/local/etc/dovecot/examples-config/
===> SECURITY REPORT:
This port has installed the following files which may act as network
servers and may therefore pose a remote security risk to the system.
/usr/local/lib/dovecot/libdovecot.so.0.0.0
/usr/local/lib/dovecot/libdovecot.a(net.o)
If there are vulnerabilities in these programs there may be a security
risk to the system. FreeBSD makes no guarantee about the security of
ports included in the Ports Collection. Please type ‘make deinstall’
to deinstall the port if this is a concern.
For more information, and contact details about the security
status of this software, see the following webpage:

Home

dovecot is installed! From the messages above, see that similar to OpenBSD, we need to add
configuration to /etc/rc.conf … we’ll take care of this in a bit.
part three: configuring sendmail and dovecot
Typically nowadays, most – including myself – prefer a simpler-to-configure SMTP server, notably postfix.
However, FreeBSD is pure, genetic BSD Unix and so is sendmail, the great-granddaddy of all mail servers.
They grew up together, and (sadly) they remain together.
Why do I say “sadly,” you ask? The stock sendmail configuration file is almost 60k in FreeBSD, and barely
human-readable beyond the first 20% of the file. Fortunately, we build it mostly from pre-configured macro
files designed for this purpose.
Within your FreeBSD box, list the contents of /etc/mail … this is where all of sendmail’s configuration lives.
total 1
-rw-r–r–rw-r–r–rw-r–r–rw-r–r–rw-r—-drwxr-xr-x
-rw-r–r–
1
1
1
1
1
2
1
root
root
root
root
root
root
root
wheel
wheel
wheel
wheel
wheel
wheel
wheel
6770
2834
558
1624
131072
512
59467
Apr 8 23:26 Makefile
Apr 8 23:26 README
Apr 8 23:26 access.sample
Apr 8 23:26 aliases
Jul 18 06:19 aliases.db
Jul 18 06:19 certs
Apr 8 23:26 freebsd.cf
16
-rw-r–r–r–r–r–r–r–r–r–r–r–rw-r–r–rw-r–r–rw-r–r–r–r–r–rw-r–r–
1
1
1
1
1
1
1
1
1
root
root
root
root
root
root
root
root
root
wheel
wheel
wheel
wheel
wheel
wheel
wheel
wheel
wheel
4460
41334
826
5659
416
171
59467
41334
498
Apr
Apr
Apr
Apr
Apr
Apr
Apr
Apr
Apr
8
8
8
8
8
8
8
8
8
23:26
23:26
23:26
23:26
23:24
23:26
23:26
23:26
23:26
freebsd.mc
freebsd.submit.cf
freebsd.submit.mc
helpfile
mailer.conf
mailertable.sample
sendmail.cf
submit.cf
virtusertable.sample
freebsd.cf is the configuration for a public-facing mail server able to receive mail, and disabled by default in
FreeBSD. freebsd.submit.cf is the configuration for the on-by-default internal “submission” mail server
that allows you to send mail outbound, provide you link it up properly to an upstream mail server that will
accept your mail. Since over 95% of the e-mail on the internet today is spam, this has become a very
particular process, and one of the first checks is whether or not an e-mail contains a legitimate source DNS
domain name. Our little network does not have one, so we’re not going to be able to get mail outbound … but
we’re going to learn how anyways.
The .mc files in /etc/mail are the macro files used to generate sendmail configuration files, using the macro
processor “m4,” and the process is still sufficiently complicated that we have a Makefile to handle invoking
the macro processor and spitting out the file.
16. Run the following command:
$ netstat -a | grep smtp
The netstat command is used for a variety of purposes; this invocation asks it for the state of all (“-a”)
active network sockets, including those used by server processes, and waiting for connections. You
should get the following output:
tcp4
0
0 localhost.smtp
*.*
LISTEN
This tells you that there is a socket/port waiting for inbound connections on the IP address associated
with the name “localhost,” on the “smtp” service. localhost, of course, is the loopback network
adapter on every system, that allows a system to offer network-based services to itself. SMTP is
“Simple Mail Transfer Protocol,” the language used by mail servers to exchange e-mail messages for
almost 40 years now.
The netstat command will translate IP addresses to host names using the DNS service and the file
/etc/hosts, and translate services using the file /etc/services. We’ve already seen and edited
/etc/hosts to implement static name service for our VMs on our host system, so now let’s check out
/etc/services.
As from the first lecture, TCP and UDP make use of 16-bit port numbers (0 to 65535), but many of
these port numbers at the low end are commonly associated with specific services, some of which
we’re already familiar with, for instance http (web pages), https (encrypted web pages), ssh, and now
smtp.
17
$ egrep “http|https|ssh|smtp” /etc/services
This command should spit out about 30 lines of output from /etc/services, matching the four search
tokens within the quotation marks (in this context, the vertical bar character is a logical or). This file is
where a lot of subsystems will look for the name of a service associated with a particular port. If the
port number doesn’t have a name, you’ll just see the port number. Of course, you might want this in
the first place …
$ netstat -an | grep LISTEN
… in the above command, the n switch to netstat tells it not to resolve host and service names. We
just want the numbers, and we’re piping this through a grep for “LISTEN,” all in caps, to have netstat
tell us all the services that are listening for incoming connections.
tcp4
tcp4
tcp6
0
0
0
0 127.0.0.1.25
0 *.22
0 *.22
*.*
*.*
*.*
LISTEN
LISTEN
LISTEN
This output tells us that we’re running an SSH server on IPv4 and IPv6, on ALL IPs of this system (the
asterisk) on port 22 (from our grep of /etc/services just before it), and that we’re running the
“submission” mail server I told you about above, configured by /etc/mail/freebsd.submit.cf, that
allows processes on your FreeBSD system to submit mail messages. Since it’s not connected to the
mail flows on the rest of the internet at large, it can only send mail messages to other users of the
same system. Since it’s only listening on the loopback adapter, it can also only possibly accept mail
from other users of the same system (you have to be on the system in some fashion to talk to its
loopback adapter).
In fact, you should be able to see that some mail has already been delivered.
$ ls -l /var/mail
total 1
-rw——- 1 _tss
-rw——- 1 dovecot
-rw——- 1 dovenull
-rw——- 1 peter
-rw——- 1 root
_tss
dovecot
dovenull
peter
wheel
0
0
0
0
4938
Jul
Jul
Jul
Jul
Jul
19
19
19
18
19
15:58
16:17
16:17
06:19
03:55
_tss
dovecot
dovenull
peter
root
/var/mail is where simple user mail spool files reside, and programs exist to parse and break up its
input. Notably here, you can see that on my system, the root user has about 1k of mail waiting. If you
also have mail there – that is, if the size of the file is not zero – you can look through this e-mail easily
with the following command …
$ sudo more /var/mail/root
… and you should see a message warning the root user about your unauthorized use of the sudo
command, unless you did something differently. Also, as I told you in lecture, periodic cron jobs also
send their output via e-mail to the root user, and that means they’ll end up in this file.
18
17. Let’s save a copy of the distribution’s default .cf and .mc files for a public-facing mail server.
$ sudo cp -p /etc/mail/freebsd.cf /etc/mail/freebsd.cf.orig
$ sudo cp -p /etc/mail/freebsd.mc /etc/mail/freebsd.mc.orig
The -p switch with the cp (“copy”) command tells it to preserve timestamps, permissions, and
ownership of the things it copies … this information is often pertinent, especially when making archival
copies of things, in case you make a change that breaks stuff. If you make a mistake and need to come
back, of course just reverse the order of the filename arguments in the cp command(s).
18. Let’s edit the sendmail macro file to aim it at dovecot, instead of those mail spool files in /var/mail.
There are client-side mail servers like popper for POP (“post office protocol”), but this is primitive, and
we want to be able to set up an e-mail server that lets our user create and manage folders, and
synchronize multiple mail clients … so we need IMAP.
$ sudo vi /etc/mail/freebsd.mc
In this file, you’ll notice “dnl” all over the place … this denotes a comment in the macro being used.
Now find the line that says …
MAILER(local)
… this is the macro that defines the local mail spool files in /var/mail. Just prior to that line, insert the
following three lines …
FEATURE(`local_procmail’, `/usr/local/libexec/dovecot/deliver’,`deliver -d $u’)
MODIFY_MAILER_FLAGS(`LOCAL’, `-f’)
MAILER(procmail)
… and save the file. We just added dovecot to the macro file that builds the mail server configuration.
19. Now we’re going to build a new sendmail configuration file from the macro file.
$ cd /etc/mail && sudo make freebsd.cf
The make output should show you that it’s invoking the macro processor m4, referring to a pool of
sendmail configuration information in /usr/share/sendmail/cf, processing freebsd.mc, and
sending the output to freebsd.cf. Let’s look at the difference between the default freebsd.cf
(saved in #17 above).
$ diff /etc/mail/freebsd.cf.orig /etc/mail/freebsd.cf
The output of the diff (“difference”) command uses the greater-than and less-than characters to
point “left” and “right” for the two filenames it was handed to compare on the command line above.
You should see some comments at the top of the file (the numbers are line numbers) showing that you
built the file locally, as root, in /etc/mail, and some additional configuration near the end of the file
(it started on line number 1729 for me) to add “procmail” mailer information and dovecot information
19
in the place of /usr/libexec/mail.local, the program that delivers into /var/mail.
20. Install your new sendmail configuration file. (Note: you should still be in /etc/mail.)
$ sudo make install-cf
21. We need to tell sendmail the domain names it must accept and locally deliver e-mail for, on this
FreeBSD VM. We’re going to create the file /etc/mail/local-host-names …
$ sudo vi /etc/mail/local-host-names
… and insert the following into it:
cs470.local
freebsd.cs470.local
22. Time to configure dovecot.
$ cd /usr/local/etc/dovecot && ls -l
Note that there’s a README file here. When you find one, it’s there for a purpose.
$ more README
So … there is a bunch of stuff in example-config, because we can do a preposterous amount of things
with dovecot – and I recommend you use cd and ls to poke around a bit – but we’re just going to take a
subset of it up a directory level to configure dovecot.
$ sudo cp -p example-config/dovecot.conf .
$ more dovecot.conf
Note that pretty much everything in here is commented out, that the comments contain the defaults
for each option, and the file ends with statements including everything in a local.conf file and
conf.d/*.conf. This is fairly common nowadays, to break up the configuration files of services into
files that contain logically separate subsets of the configuration.
First, let’s make a conf.d directory here, in the right place …
$ sudo mkdir conf.d
… and then let’s copy out the pieces of the example configuration that we need, leaving the example
configuration untouched, in case we need to refer to it again, or to grab a clean copy. Note: the
following command will work just fine if you’re using bash, csh, or tcsh, but may barf if you’re using
another shell. I’ve put this command here to introduce you to the syntax in modern shells for
expanding to multiple targets, using curly brackets and commas.
$ sudo cp -p example-config/conf.d/{10-auth.conf,auth-system.conf.ext,10-
20
mail.conf,20-imap.conf} ./conf.d
If you’re using another shell, you’ll almost certainly get a “file not found” error, and will want to
separately copy each of the four config files into conf.d.
Now let’s tweak the files to set up dovecot as we want it for this lab.
First, edit dovecot.conf, and add a “protocols” line (leave the sample protocols line with all the
options intact) just below the sample protocols line, saying that we just want the imap protocol to be
served.
Next, edit conf.d/10-auth.conf. Uncomment the line for disable_plaintext_auth and change it to
“no” … this would be a VERY bad idea without activating encryption, but on our little VM network on
our own laptop, this will be fine … and we’ll save security certificates for another day. Also in 10auth.conf, add login to the line for auth_mechanisms.
Finally, edit conf.d/10-mail.conf. Uncomment the line for the setting mail_location, and set it like
so:
mail_location = maildir:/var/spool/imap/%u
This tells dovecot to create a directory for each user under /var/spool/imap, with the username as
the name of the folder. Since we’ve referred to this directory, let’s create it, associate it with the
dovecot subsystem pseudouser, the group mail, and allow everybody to write there, but nobody to
delete anything that doesn’t belong to them. (Remember the sticky bit from lecture?)
$ sudo mkdir -m 1777 /var/spool/imap
$ sudo chown dovecot:mail /var/spool/imap
23. Now let’s enable both sendmail and dovecot. Edit /etc/rc.conf and add the following three lines:
dovecot_enable=”YES”
sendmail_enable=”YES”
sendmail_flags=”-bd -q30m”
The sendmail flags tell it to become a daemon (a server, -bd), and to run its queue every 30 minutes
(-q30m) to try to redeliver mail that somehow gets stuck there.
Now, let’s start up both services.
$ sudo /etc/rc.d/sendmail restart
$ sudo /usr/local/etc/rc.d/dovecot start
Note that sendmail is started from scripts in /etc/rc.d, because it was bundled with the operating
system. dovecot is started under /usr/local, because it was installed from the ports tree. We are
restarting sendmail, because some of its components were already running (remember the
submission mail server?), but dovecot has never run before. dovecot will complain about a file not
being there …
21
doveconf: Error: t_readlink(/var/run/dovecot/dovecot.conf) failed: readlink()
failed: No such file or directory
… but this is because it’s hoping to find a link to where we made dovecot.conf from
/var/run/dovecot (a directory for running content for dovecot). It will make that link when it
doesn’t find it there this first time.
$ ls -l /var/run/dovecot/dovecot.conf
lrwx—— 1 root wheel 35 Jul 12 00:12 /var/run/dovecot/dovecot.conf ->
/usr/local/etc/dovecot/dovecot.conf
Run netstat -an | grep LISTEN again. Look a little different? How about the output of the
command, without the “n” switch?
24. Test your mail server.
$ echo “test” | mail -s test peter
Naturally, substitute in your username for mine. Now check the mail subsystem log.
$ tail /var/log/maillog
The tail command shows the end of a file, in this case, the log for the mail subsystem. You should see a
line showing the mail being received by the submission sendmail instance, another by the other
sendmail we set up, accepting it for delivery, and finally, dovecot delivering it into your user’s inbox.
Listing the contents of /var/spool/imap should also show that some stuff has been created.
25. Now let’s test mail between your two VMs. On your OpenBSD system, use sudo and vi to create the
file /etc/mail/mailname … this file did not exist on my OpenBSD VM prior to this step … and put
openbsd.cs470.local into it. That’s it, nothing else. Just one line, just your OpenBSD VM’s fullyqualified DNS domain name, then save it out.
Save, and restart smtpd to make sure it notices the change we just made …
$ sudo /etc/rc.d/smtpd restart
… and let’s send a test mail on the command line to
$ echo “test” | mail -s test peter@cs470.local
Since the e-mail address we’re supplying in our test case here is @cs470.local, the SMTP service on
OpenBSD (OpenBSD has its own “smtpd,” and doesn’t use sendmail or postfix) goes out and consults
DNS to find out where to deliver e-mail for the domain “cs470.local.” It is configured to be its own
name server, and if you look back at what we set up in DNS, we configured an MX record (MX is short
for “mail exchanger”) for the domain cs470.local, pointing at our FreeBSD system.
On both VMs, run the following command and see what it says …
22
$ host -t mx cs470.local
It should report that the preferred mail exchanger for cs470.local is your FreeBSD VM. E-mail should
now be flowing properly between our first two VMs. Check mail logs at both sides if it’s not working,
and start from error messages there.
part four: configuring regular maintenance and diagnostic mails
26. First things first, let’s tell this FreeBSD system who its sysadmins are.
$ sudo vi /etc/mail/aliases
The aliases file is a list of mail re-direction rules. You’ll notice that e-mail addressed to pretty much
every subsystem of our FreeBSD VM is routed to root. However, all that mail going to root – it’s not all
that much – but we don’t want it to go to root. We want it to go to the system administrators of our
system, each of us, and NOT to have to log in as root via a mail server to grab it.
There’s a comment about just this, forwarding root’s e-mail, and under that a line that looks like this:
# root: me@my.domain
Uncomment it (remove the leading # and space), and replace me@mydomain with username for your
account on your FreeBSD system @cs470.local (the domain for our private networks). For me, it
looked like this:
root: peter@cs470.local
You now know what the at-sign is for in an e-mail address, and how the whole system behind that
works.
When we edit the aliases database, we need to tell the mail subsystem to parse it and re-generate the
database file that sendmail actually references during regular operation (note that there’s an
aliases.db file in /etc/mail).
$ sudo newaliases
27. Now, do the same alias configuration (all of #26) on your OpenBSD VM. The aliases file is in the same
place, you want to substitute in the same data, and you have to run the newaliases command
afterwards.
28. Back on our FreeBSD VM, let’s set up some cron jobs.
$ sudo crontab -e
Add in the following lines:
0 3 * * * /usr/sbin/portsnap cron update
23
0 4 * * * /usr/sbin/freebsd-update cron
These two lines will automatically update your ports tree at 3 AM, and check for updates to FreeBSD at
4 AM, every day.
‼ REMINDER: I want you to start running your VMs all night, for the duration of the class, so that these
late-night cron jobs turn up some output, and start e-mailing it to you. You will not be graded on
uptime, and if you’d rather save on your electricity bill, feel free to change the cron jobs to run by day.
part five: configuring a hosts file
Changing our host operating system’s resolver configuration back-and-forth to use our OpenBSD VM is going
to be a pain, so let’s just NOT do that moving forward. On every operating system, there’s a “hosts” file that is
consulted before the network-based DNS resolver, and asking name servers … so you can override any name
you like. In fact, prior to developing the DNS protocol, everybody on the early internet just shared this huge
flat “hosts” text file, until it became untenable, and we needed a protocol like DNS, with a hierarchical
namespace and distributed lookups and authority.
‼ IMPORTANT NOTE: be careful here with hosts files! It’s a common mistake to leave stuff in here, forget
about it, and wonder why your computer uniquely among all the others next to it can’t get to that internet site
in particular.
If you’re using macOS or Linux as your host operating system, you want to (sudo) edit the file /etc/hosts. If
you’re using Windows and WSL, you want to edit the file C:\WINDOWS\system32\drivers\etc\hosts. I
recommend you run Wordpad as administrator from the start menu. If you use another editor, it’ll get the
line breaks wrong. If you don’t run it as administrator, you’ll be denied access to the file. WSL updates its own
/etc/hosts file from the file Windows on the Windows side of the house, so if you get the one in Windows,
you get both Windows and WSL covered, and we need both. You’ll have to close all your WSL shells to force a
re-parse of this file. If that doesn’t work, reboot Windows … it’s still the best way to fix a lot of things with
Windows, sadly. J
Either way, you want to add the following entries to your hosts file:
192.168.223.71
192.168.223.72
192.168.223.73
192.168.223.74
192.168.223.75
192.168.223.76
openbsd.cs470.local
freebsd.cs470.local
centos.cs470.local
ubuntu.cs470.local
solaris.cs470.local
cloud.cs470.local
Of course, change the first three octets to match your private IP subnet, and test these new lookups with ping
and ssh on the command line on your host system, and your OpenBSD and FreeBSD VMs as targets. You
should now be able to freely address these systems by name, instead of by IP, without aiming your host
system at the name server on your OpenBSD VM.
24
part six: configure a mail client
Mac users, use Mail.app. Windows and Linux users, I recommend getting Thunderbird … it’s free and it’s way
better than the Windows mail client, if you’re on Windows. Linux users, you probably have Thunderbird
installed along with your operating system. If you don’t, go get it.
No matter which operating system you’re on, set up a mail client to get e-mail from the IMAP server on
freebsd.cs470.local … because we set this up in /etc/hosts, your mail program should be able to aim there
without changing your host operating system’s DNS configuration to aim at your OpenBSD VM.
You will likely have to accept a self-signed certificate from your mail server in your mail client, and may have
to tell your mail client that you’re okay with sending passwords unsafely because of this self-signed certificate.
Just accept the risk and the warnings … it’s between your host and your VM, so take it with a grain of salt. If
you get your earlier test e-mails in your mail client, mission accomplished.
Other problems here? I want you to web search them. I’ve spoon-fed you enough for today. Lab two done!
25
CS 470: Unix/Linux Sysadmin
Summer 2021 Lab 3
Rocky Linux + NFS
This lab gets our hands into our first Linux distribution in the class, Rocky Linux.
It is the primary design goal of Rocky Linux to be 100% binary compatible with Red Hat Enterprise Linux
(“RHEL”), Red Hat’s primary operating system offering. For almost all intents and purposes, if somebody says
they need/want Red Hat, Rocky Linux will do just fine as a development and test platform. Version 8.4 of
Rocky lines up, package-for-package, with version 8.4 of RHEL.
IBM was always a large stakeholder in Red Hat, but in 2018, IBM announced its intent to purchase Red Hat for
$34B, and the purchase closed a year ago this month (July 2019). For all intents and purposes, Red Hat is now
IBM Linux.
We used to always use CentOS for this lab. Since version 6 of both RHEL and CentOS, around which time Red
Hat bought the entity backing CentOS, the latter was the official subscription-free version of Red Hat for use in
testing and development; as such, it’s pretty much the same distribution when compared side-by-side,
version-to-version. You got Red Hat when you need paid-for on-call support for critical production instances
of the operating system. If you don’t feel you need it, or you just don’t want to pay, then CentOS was likely
the distribution for you … but then Red Hat killed it, dead.
In the middle of the timeline for CentOS 8.x, Red Hat announced it was killing of CentOS and turning it into a
rolling “stream” distribution that no longer tracked Red Hat … which is what most of the people using CentOS
were using it for. The response in the community was swift and unforgiving to Red Hat. In response, they
announced a couple of programs where small businesses and individual developers could get RHEL for free,
provided that they register for accounts with Red Hat … but the damage was already done, and they should
have had that announcement ready from the get-go, not after they made everybody mad.
It’s also worth noting here that CERN used to put out a Red Hat-compatible distribution, like CentOS, but
stopped and transitioned everybody to CentOS for version 8 … poor suckers. I was hoping to use Scientific
Linux for this class, with its neat atom and particle-based iconography and graphics, but was unaware of its
death. I briefly considered using either Oracle Linux (which is also 100% Red Hat compatible aside from its
value-add “unbreakable” kernel) or Red Hat Enterprise Linux itself, but both of these options would have
required a free sign-up … no thanks to spam!
Fortunately, the founders of the CentOS project just decided to start a new distribution to mirror RHEL, Rocky
Linux, and we’ll be using that. No sign-ups, no spam, no headaches, thank you very much.
part 0: get it
Go to http://www.rockylinux.org/download/ … the Rocky Linux download is BIG. The “DVD” download is
almost 10 GB. Fortunately, I’m fairly certain we’re not going to need all that, and that you can download the
“minimal” ISO (Rocky-8.4-x86_64-minimal.iso). It’s just under 2 GB.
part 1: install it
1
Create a new custom VM – make sure not to use “easy install” – on your shared VM network, using the
following specifications:
CPU: single virtual core/processor
RAM: 1 GB
hard disk: 40 GB
guest OS: CentOS 8 64-bit
As usual, legacy BIOS is fine for our firmware.
When you start the VM, you’ll be presented with a list of choices from the installation media (the ISO). We
don’t need to check the media – this is for use cases involving burning a physical disc – so go ahead and select
to install.
Choose your language, and you’ll be greeted by the installation screen. All of the options in the following
screen come before installing Rocky Linux. A number of options, as we’ll see, can be selected during or after
the installation.
2
From this screen, however:
1. Select “Network & Host Name” … let’s go there.
You should see a window like this … first, let’s use the switch in the upper right-hand corner to turn our
network on. When you do, you should see it go out and get an address from DHCP on your local
NATwork. If the first three octets of the IP it gets don’t match the rest of your VMs, you’ve set up your
VM’s network incorrectly, and need to check out its settings. Click the “configure …” button.
Click on the “general” tab and make sure that “connect automatically” is selected. Then, click on the
“IPv4 Settings” tab, and change “method” to “manual.”
“Add” an IP address … the IP ending with .73 on your network, as you entered into /etc/hosts on
your host operating system, and into your name server for the Rocky Linux VM instance. The netmask
3
should be “24” – this is the number of bits in a “255.255.255.0” netmask, and enter the default
gateway you’ve been using with your other VMs. Enter the IP of your OpenBSD VM (which should be
up and running!) as your DNS server, and cs470.local as your search domain.
What you have after you’re done with the IPv4 settings pane should look like this:
Click “save.”
Finally, to complete the network setup, set the hostname of your VM to rocky.cs470.local and click
“apply.” You should have something like this, though your IP addresses may differ a little depending
on the network VMware gave you.
Now click “done,” in the upper left hand corner, to go back to the main installer window.
4
2. Select “time and date” and set your timezone. We want “Americas/Los Angeles.” In the upper righthand corner of the screen, you’ll see a widget to turn on network time, and as we’ve seen, timekeeping in VMs is very important. Turn it on, if it’s not already, and hit “done.”
3. The “installation source” should be the “local media” … this is the ISO file you downloaded, pretending
to be an optical disc. Select “software selection.” Since we grabbed the minimal DVD, let’s select the
“minimal install” base environment, like in the screenshot below. Select no “additional software …”
and then click on “done” to go back to the main installer window.
4. Select “installation destination” … you may have noticed that it wants to automatically configure
partitioning … and that we have always viewed this with scrutiny in the past.
5
Select to make a “custom” storage configuration then “done.” You’ll see that this (not very intuitively)
doesn’t take us back to the main installer window … it takes us to the manual partitioning screen.
Change the partitioning scheme from LVM (logical volume manager) to “standard partition.”
‼ NOTE: LVM abstracts filesystems from actual physical disks, and might be helpful with real machines,
but here in a VM, it’s an unnecessary layer of abstraction in a device with already-virtual disks.
Click the plus sign button (“+”) to create a new partition (the installer confusingly says “mount point”
here) with the mount point / and a desired capacity of “38 GiB” and click “add mount point.” Do not
encrypt it, and change it from the default xfs filesystem to ext4.
‼ IMPORTANT NOTE: in case you hadn’t been introduced to this particular law of the universe,
ATTORNEYS RUIN EVERYTHING. Did you notice the lower-case “i” in between “G” and “B?” This means
we’re using gibibytes, not gigabytes. The difference, you ask? Base 10 vs. base 2. See the following
page.
https://en.wikipedia.org/wiki/Gibibyte
If you feel so inclined, remove your root filesystem, and re-create it with “GB” as units and check out
the difference in size. DO, however, use 38 GiB, not 38 GB as the final size of your root partition.
Do the plus sign again to create another partition, and use the drop-down menu to select “swap” …
which is not really a mount point at all, and 2 GiB for the size of our swap space.
6
Your manual partitioning screen should look like the above. Click “done.” You’ll be asked to confirm
your changes; you may “accept changes” quickly and without hesitation, since this is a virtual disk in a
VM and a blank one at that, not a real disk.
5. Back at the main installation window, CentOS and RHEL used to let you click “begin installation”
without setting a root password, but this is no longer an option … so please set your root password.
Please take a moment to set a root password, and create your non-root user account with the same
username as your OpenBSD and FreeBSD VMs. When you create your non-root user, make sure you
check “make this user administrator” to allow this user the ability to become root and use sudo. Then
click the button to “begin installation.”
When the installation is done, you’ll see a button appear at the bottom to “finish configuration.” It’ll
take a couple quick actions and the button will re-appear to prompt you to reboot your VM. Click it.
part 2: configure it and install common packages
Indeed, configuration is over as the exception, rather than a rule. As we go through our lab operating systems
to generally easier and more full-featured OSs, some of these things were set up for us during the installation,
notably static IP addressing and network time. We still have a few things to set up, though.
6. During the reboot, you’ll briefly see the “GRUB” menu (screenshot below). This is the boot loader that
corresponds to the OpenBSD boot prompt and the FreeBSD boot menu. Do nothing here; I’m just
bringing your attention to a familiar feature, in a new OS … we want to fully boot the system anyways.
7
7. I wanted to see if SSH is running, so I used netstat, like in the prior labs … but got an error message
saying “command not found.” We’re getting what we asked for here, with a minimal installation. For
Linux, a 1.7 GB installation footprint is fairly small.
Since netstat wasn’t available, I used the ps command to verify that SSH was running, and the line
with /usr/bin/sshd … that’s it, and it’s running.
8. Create your SSH directory, with 700 permissions …
$ mkdir -m 700 ~/.ssh
‼ IMPORTANT NOTE: the tilde character (~) expands to refer to your home directory, no matter who
you are, in most modern shells. This is taken from the HOME variable in your shell’s environment.
8
… and after you’ve created your .ssh directory, copy over your SSH key into the authorized_keys file
so that you can use SSH and minimize the console window.
9. You’ll probably be happy to know that gpg is already installed, even in the minimal configuration of
Rocky Linux. This is because it is used to sign and verify binary packages, which are the default method
of distributing software in Rocky Linux.
$ which gpg
/usr/bin/gpg
That’s right … breathe a sigh of relief. this also means we’re largely done building things from source.
10. Speaking of, let’s configure the package manager for Rocky Linux, dnf … type sudo dnf update …
$ sudo dnf update
Rocky Linux 8 – AppStream
2.3 MB/s | 8.0 MB
00:03
Rocky Linux 8 – BaseOS
2.9 MB/s | 4.5 MB
00:01
Rocky Linux 8 – Extras
7.6 kB/s | 3.8 kB
00:00
Dependencies resolved.
====================================================================================
Package
Architecture Version
Repository
Size
====================================================================================
================
Installing:
kernel
x86_64
4.18.0-305.10.2.el8_4
baseos
5.9 M
kernel-core
x86_64
4.18.0-305.10.2.el8_4
baseos
36 M
kernel-modules
x86_64
4.18.0-305.10.2.el8_4
baseos
28 M
…
… your results may vary slightly, but the general idea is the same. We’re telling dnf to grab the latest
list of packages, and it will come back and tell us it’s got a few updates from between the time that ISO
we used to install was published,
Transaction Summary
================================================================================
Install
5 Packages
Upgrade 39 Packages
Total download size: 107 M
Is this ok [y/N]:
Type “y” to allow it to upgrade, and it will go out to the Rocky Linux repositories, and download all the
updated packages. You’ll be asked near the end to accept the new official GPG signing key …
warning: /var/cache/dnf/appstream-62ae9a0bbea44fbe/packages/libxkbcommon-0.9.11.el8.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 6d745a60: NOKEY
Rocky Linux 8 – AppStream
1.6 MB/s | 1.6 kB
00:00
Importing GPG key 0x6D745A60:
9
Userid
: “Release Engineering ”
Fingerprint: 7051 C470 A929 F454 CEBE 37B7 15AF 5DAC 6D74 5A60
From
: /etc/pki/rpm-gpg/RPM-GPG-KEY-rockyofficial Is this ok [y/N]:
Again, type “y” to allow it. It will then validate and install all the package updates. After it’s done,
reboot. I’m asking you to do this because mine included a kernel update, and when you get a kernel
update, you need to reboot to run the operating system on top of this new kernel instead.
‼ INTERESTING NOTE: Ubuntu Linux includes a feature called “livepatch” which does away with the
need to reboot to patch your kernel. Of course, however, this is a paid feature … not for free users.
Yes, I know this is the Rocky Linux lab, but thought it cool enough to mention here.
As your VM reboots, you make notice that another kernel has been added to the GRUB menu. If your
new kernel has a problem, this is where you could select to boot (one time) with a different kernel, to
do process-of-elimination troubleshooting.
11. Let’s install some common packages that you might find useful, and I’ll be using later to grade your
work: wget, csh (via tcsh), host (via bind-utils), and ifconfig and netstat (via net-tools) on
Rocky Linux.
$ sudo dnf install wget tcsh net-tools bind-utils
12. In the name of minimalism, Rocky Linux isn’t including a syslog package for system logging as a part of
the minimal install. Let’s fix that; logging is kind of important if we’re going to do any troubleshooting.
$ sudo dnf install rsyslog
$ sudo systemctl enable rsyslog
$ sudo systemctl start rsyslog
13. As with our other VMs, let’s make sure our system can send mail to our mail server on the FreeBSD
VM. You might remember me mentioning postfix, the more modern mail server … that’s what
we’re going to use, and it was left out of our minimalist installation. Let’s install it.
$ sudo dnf install postfix
First, let’s back up the main postfix configuration file.
$ sudo cp -p /etc/postfix/main.cf /etc/postfix/main.cf.orig
Then, let’s edit the configuration file …
$ sudo vi /etc/postfix/main.cf
… and set the following values under the areas for each variable’s sample:
myhostname = rocky.cs470.local
mydomain = cs470.local
10
myorigin = $myhostname
inet_protocols = ipv4
… once you’re done, save out the file, and let’s enable and start up postfix.
$ sudo systemctl enable postfix.service
$ sudo systemctl start postfix.service
14. Let’s fix the aliases database, to make sure we get e-mail intended for the system administrator. In
Rocky Linux (locations can and will vary from Linux distribution to Linux distribution), it’s located at
/etc/aliases.
$ sudo vi /etc/aliases
Find the line aiming root’s e-mail at “marc” (last line in my file) and replace “marc” with your
@cs470.local e-mail address from lab 2. Save the file and …
$ sudo newaliases
… tell the mail subsystem to re-read the alias database.
15. Some of you noticed, also, that because we’re running the “minimal” installation of Rocky Linux here,
it’s not provided us the “mail” command we were using to test e-mail connectivity between our VMs.
dnf has a solution for that …
$ dnf whatprovides mail
yum will go through grabbing some databases the first time you run this command, but if you wanted
to know which package to install to add a particular command, this is one way to do. yum told me:
mailx-12.5-29.el8.x86_64 : Enhanced implementation of the mailx command
Repo
: BaseOS
Matched from:
Filename
: /bin/mail
So I installed it …
$ sudo dnf install mailx
… and was able to use mail to test mail transmission in between systems, like in lab 2.
‼ IMPORTANT NOTE ‼ every Unix and Unix-like OS, just about, will have logging for its mail subsystem
and all its subsystems, somewhere. I recommend perusing the file /etc/syslog.conf or
/etc/rsyslog.conf and their associated manpages.
11
16. As with all our other VMs, let’s set up our Rocky Linux VM to do automatic checking for operating
system updates, and to e-mail us the output.
$ sudo crontab -e
You’ll be creating root’s crontab with the above command … insert the following line …
0 0 * * * /usr/bin/dnf check-update
… and save it. Every night at midnight, your Rocky Linux VM will check the repositories for updates and
patches.
part 3: NFS server
17. dnf is a full-fledged package management system. You may have noticed “.rpm” at the end of the
packages dnf was downloading in the initial update step above. RPM stands for Red Hat Package
Manager, and like all things, and like a lot of software, we figure out something better and don’t throw
away everything we used before … we just build on top of it.
dnf is actually “Dandified YUM,” is the successor to yum, an acronym too, which stands for Yellow Dog
Updater, Modified … because the original Yellow Dog Linux updater was called … you guessed it: yup.
Yellow Dog Linux was a Red Hat-based distribution that was really popular on the PowerPC
architecture, and notable on the PlayStation 3. It’s not much in use anymore, but lives on through
widespread use of yum, which is just the best tool to date … for managing RPM packages, often just
called “RPMs.” An rpm tool is there, underneath yum … but we won’t use it much, because it doesn’t
do much, and it’s why they made yup, yum, and dnf.
Enough story time, though … we’re going to turn this Rocky Linux instance into an NFS server, and
share /home amongst all our VMs, so that we have the same files. Fortunately, the NFS server is
already built into the minimal Rocky Linux distribution. Let’s look for other tools to supplement our
NFS service.
$ dnf search nfs
Note, that like a lot of things, you don’t need to be root unless you’re actually making/writing changes
to disk. You do NOT need to be root in order to search yum’s databases. Look at the output generated
by yum when you search … you’ll notice all packages are tagged with an architecture.
Packages with “x86_64” as a suffix are 64-bit packages. Those with “i686” are 32-bit x86 packages, but
you won’t see them anymore in Rocky Linux 8, aside from in fringe use cases and repositories.
“noarch” are packages made of configuration files, headers, or interpreted scripts for which the
architecture is not important. Let’s install the nfs-tools, because I’m fairly sure we’ll be using them.
$ sudo dnf install nfs-utils
Follow the prompts, and make sure it installs.
12
18. systemctl is the tool for controlling systemd, the subsystem responsive for managing services and
system startup in current versions of Linux, as discussed earlier in lecture. We need to tell systemd
that we want to run an NFS server.
$ sudo systemctl enable nfs-server.service
This last command tells systemctl to enable the NFS service, which starts it at boot time … but not
immediately …
$ sudo systemctl start nfs-server.service
… the above command starts it now.
19. Rocky Linux comes, by default, with a host firewall. Any services we want to get into our Rocky Linux
VM will have to be explicitly allowed through the firewall.
$ systemctl is-active firewalld
The above command asks systemd if firewalld (the firewall daemon) is active, and it should reply
active.
Let’s see what services are allowed to all hosts in the firewalld logical area (“zone”) “public.”
$ sudo firewall-cmd –info-zone=public
My output looked like this:
public (active)
target: default
icmp-block-inversion: no
interfaces: ens33
sources:
services: cockpit dhcpv6-client ssh
ports:
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
Let’s tell firewalld that we also want it to let NFS traffic through. Fortunately, it already knows what
NFS is, and what NFS traffic looks like.
$ sudo firewall-cmd –permanent –zone=public –add-service=nfs
$ sudo firewall-cmd –permanent –zone=public –add-service=mountd
$ sudo firewall-cmd –permanent –zone=public –add-service=rpc-bind
13
mountd is a back-end NFS service, and RPC is an API that NFS is built on top of. firewalld should reply
success for each. Now tell it to re-load its ruleset.
$ sudo firewall-cmd –reload
Again, it should reply success. Our firewall is good, and now our NFS traffic will pass through it.
20. Now let’s set up the NFS service itself.
$ sudo vi /etc/exports
The file /etc/exports is there, but it has a zero size by default, so everything here we’ll be adding in:
/home
192.168.223.0/24(rw,sync)
This tells the NFS server that we want to share /home on the local system (in this case, our Rocky Linux
VM) to all the hosts on our private VM network (remember to swap in your network numbers into the
first three octets of the IP), to allow read/write access (rw), and sychnronous I/O (sync). Note that
there are NO spaces in between the address range and the NFS mount options.
Now, let’s share it!
$ sudo exportfs -a
This tells the NFS service to immediately share everything (-a) declared in /etc/exports. We can
verify this worked with the showmount command, which we installed along with the nfs-utils
package in step #14.
$ showmount -e localhost
This queries the NFS server with a client program (showmount), using the loopback network adapter, as
discussed in lecture. You should see something like the following:
Export list for localhost:
/home 192.168.223.0/24
21. Let’s make a place to test and play with NFS behavior.
$ sudo mkdir -m 1777 /home/tmp
This makes a “tmp” directory under our NFS share (/home) with the sticky bit set. Everybody who can
mount this share should be able to write here.
$ ls -ld /home/tmp
drwxrwxrwt. 2 root root 6 Jul 21 20:57 /home/tmp
Looks just like /tmp … perfect.
14
22. Go to your FreeBSD VM, and look at the contents of your home directory.
$ ls -la $HOME
Then cd to the root of the filesystem.
$ cd /
We can’t mount anything at a point above us in the file namespace. That is, if you’re at /home/peter,
some OSs will flatly refuse to mount something at /home, which is exactly what we’re about to do …
$ sudo mount rocky.cs470.local:/home /home
If you don’t get a command line right back, odds are you screwed up one of the last few steps. You can
now see it in the filesystem mount table. Type mount … my output looked like this.
$ mount
/dev/ada0s1a on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
rocky.cs470.local:/home on /usr/home (nfs)
And type df -h to look at filesystem utilization …
$ df -h
Filesystem
/dev/da0s1a
devfs
rocky.cs470.local:/home
Size
27G
1.0K
37G
Used
8.8G
1.0K
2.0G
Avail Capacity
16G
35%
0B
100%
33G
6%
Mounted on
/
/dev
/usr/home
Note: in FreeBSD, /home is a symlink (also often called a “soft link”) to /usr/home.
$ ls -l /home
lrwxr-xr-x 1 root
wheel
8 Jul 28 20:04 /home -> usr/home
Now check out the contents of your home directory again.
$ ls -la $HOME
Looks kinda different from a few minutes ago, huh?
Back on your Rocky Linux system, run the following command:
$ touch $HOME/testfile
On your FreeBSD system, run the following command:
$ ls -l $HOME/testfile
15
Should be the same.
‼ IMPORTANT NOTE: the output of ls -l *should* be listing your correct username, on both sides …
because the defaults for every operating system so far are (or what I asked you to do was) to use user
ID 1000 for the first non-root user.
23. Where did the files under your home directory on FreeBSD go? The short answer: nowhere. They’re
just sort of hidden, no longer accessible, because they’re hidden “under” a mount point.
$ cd /
$ sudo umount /home
$ ls -la $HOME
Your FreeBSD home directory files are back! They never really went anywhere, and just weren’t visible
because /home (actually /usr/home in a very nostalgic way on FreeBSD) became a mount point, and
when that mount point is crossed, you’ve changed over to the root directory of the filesystem, or
share, mounted “on” that mount point.
In this case, under /usr/home on your FreeBSD VM … you were seeing the contents of /home on your
Rocky Linux VM.
24. Let’s make this permanent, for your FreeBSD VM, but not your OpenBSD VM.
There’s a very simple reason for this: we don’t want a chicken/egg problem here and now, where your
Rocky Linux VM needs your OpenBSD VM for DNS, and your OpenBSD VM needs your Rocky Linux VM
for home directories. Your OpenBSD VM is your DNS server, helps everything find everything else by
name, and we want it to just start, without dependency.
‼ IMPORTANT NOTE: everything you add to /etc/fstab MUST SUCCESSFULLY mount at boot time, or
the operating system will kick you out into single-user mode. After we make this change, you will have
to have your Rocky Linux VM booted up before your FreeBSD VM or your FreeBSD VM will fail to boot!
On your FreeBSD box …
$ sudo vi /etc/fstab
Add the line at the end of the file, using tabs to make the columns line up with prior entries:
rocky:/home
/home
nfs
rw
0
0
… and reboot your FreeBSD VM. When it comes back, log in and run df again. If it doesn’t come back,
you almost certainly made a mistake in /etc/fstab and need to fix it on the VM console to reboot
into multi-user mode.
25. One last thing: with NFS, we don’t want root on one system to be root on another, for security
purposes. In some cases, that would be VERY BAD … one would have to completely trust the system
administrators of all NFS client systems, or they could leverage root powers on their computer …
16
against files on our filesystem. BAD.
On your FreeBSD box, run the following command …
$ sudo touch /home/tmp/test
… and note that, with sudo, we ran that command as root. NFS does something with file access
performed as root called “squashing,” that is, if a user is root on the remote system … we make them
just like everybody else … we make them a nobody.
$ ls -l /home/tmp/test
As you should see, /home/tmp/test is owned by “nobody” and associated with the group “nobody.”
This user and group were created specifically for the purpose of “squashing” root access over NFS
shares, a long time ago.
part four: tuning and reporting
26. Shut down your Rocky Linux VM, and let’s take back half its RAM. My Rocky Linux VM was only using
about 300 MB RAM after the first couple reboots.
The top command is outstanding for analyzing system performance on the spot. Note my top output
below, 4th row, MiB Mem.
top – 21:03:55 up 54 min, 2 users, load average: 0.00, 0.00, 0.04
Tasks: 142 total,
1 running, 141 sleeping,
0 stopped,
0 zombie
%Cpu(s): 0.0 us, 0.0 sy, 0.0 ni, 99.7 id, 0.0 wa, 0.3 hi, 0.0 si, 0.0 st
MiB Mem :
782.4 total,
83.4 free,
249.3 used,
449.6 buff/cache
MiB Swap:
2047.0 total,
2035.6 free,
11.4 used.
398.0 avail Mem
512 MB RAM will be enough for the VM. All done.
‼ IMPORTANT NOTE: After completing this lab, your lab setup now has a dependency-induced
mandatory boot order when bringing up your lab: always first boot your OpenBSD VM to completion,
because it hosts name service, required by a lot of things. Then boot your Rocky Linux VM, because it
will have the home directories for all your other systems. You may then bring up all the other VMs in
any order you like.
When shutting down your VMs, shut down everything but Rocky Linux and OpenBSD first, in any order.
Then shut down Rocky Linux, and finally OpenBSD.
‼ ALSO IMPORTANT NOTE: shutdown on Linux uses -P with a capital “P” for a power-off shutdown, but
it’s also the default, so you don’t need to have it in there.
17