ubuntu-server-guide

ubuntu server guide changes, errors and bugs this is the current edition for ubuntu 20.04 lts, focal fossa. ubuntu serverguides for previous lts versions: 18.04 (pdf), 16.04 (pdf). if you find any errors or have suggestions for improvements to pages, please use the link at the bottom of each topic titled: “help improve this document in the forum.” this link will take you to the server discourse forum for the specific page you are viewing. there you can share your comments or let us know about bugs with each page. offline download this guide as a pdf support there are a couple of different ways that ubuntu server edition is supported: commercial support and community support. the main commercial support (and development funding) is available from canonical, ltd. they supply reasonably- priced support contracts on a per desktop or per server basis. for more information see the ubuntu advantage page. community support is also provided by dedicated individuals and companies that wish to make ubuntu the best distribution possible. support is provided through multiple mailing lists, irc channels, forums, blogs, wikis, etc. the large amount of information available can be overwhelming, but a good search engine query can usually provide an answer to your questions. see the ubuntu support page for more information. basic installation this chapter provides an overview of installing ubuntu 20.04 server edition. there is more detailed docu- mentation on other installer topics. preparing to install this section explains various aspects to consider before starting the installation. system requirements ubuntu 20.04 server edition provides a common, minimalist base for a variety of server applications, such as file/print services, web hosting, email hosting, etc. this version supports four 64-bit architectures: • amd64 (intel/amd 64-bit) • arm64 (64-bit arm) • ppc64el (power8 and power9) • s390x (ibm z and linuxone) the recommended system requirements are: • cpu: 1 gigahertz or better 1

• ram: 1 gigabyte or more • disk: a minimum of 2.5 gigabytes server and desktop differences the ubuntu server edition and the ubuntu desktop edition use the same apt repositories, making it just as easy to install a server application on the desktop edition as on the server edition. one major difference is that the graphical environment used for the desktop edition is not installed for the server. this includes the graphics server itself, the graphical utilities and applications, and the various user-supporting services needed by desktop users. backing up before installing ubuntu server edition you should make sure all data on the system is backed up. if this is not the first time an operating system has been installed on your computer, it is likely you will need to re-partition your disk to make room for ubuntu. any time you partition your disk, you should be prepared to lose everything on the disk should you make a mistake or something goes wrong during partitioning. the programs used in installation are quite reliable, most have seen years of use, but they also perform destructive actions. preparing install media there are platform specific step-by-step examples for s390x lpar, z/vm and ppc64el installations. for amd64, download the install image from https://releases.ubuntu.com/20.04/. there are many ways to boot the installer but the simplest and commonest way is to create a bootable usb stick to boot the system to be installed with (tutorials for other operating systems are also available). booting the installer plug the usb stick into the system to be installed and start it. most computers will automatically boot from usb or dvd, though in some cases this is disabled to improve boot times. if you don’t see the boot message and the “welcome” screen which should appear after it, you will need to set your computer to boot from the install media. there should be an on-screen message when the computer starts telling you what key to press for settings or a boot menu. depending on the manufacturer, this could be escape, f2,f10 or f12. simply restart your computer and hold down this key until the boot menu appears, then select the drive with the ubuntu install media. if you are still having problems, check out the ubuntu community documentation on booting from cd/dvd. after a few moments, the installer will start in its language selection screen. welcome_c|690x517 2

using the installer the installer is designed to be easy to use and have sensible defaults so for a first install you can mostly just accept the defaults for the most straightforward install: • choose your language • update the installer (if offered) • select your keyboard layout • do not configure networking (the installer attempts to configure wired network interfaces via dhcp, but you can continue without networking if this fails) • do not configure a proxy or custom mirror unless you have to in your network • for storage, leave “use an entire disk” checked, and choose a disk to install to, then select “done” on the configuration screen and confirm the install • enter a username, hostname and password • just select done on the ssh and snap screens • you will now see log messages as the install is completed • select restart when this is complete, and log in using the username and password provided there is more detailed documentation on all these options. advanced installation software raid redundant array of independent disks “raid” is a method of using multiple disks to provide different balances of increasing data reliability and/or increasing input/output performance, depending on the raid level being used. raid is implemented in either software (where the operating system knows about both drives and actively maintains both of them) or hardware (where a special controller makes the os think there’s only one drive and maintains the drives ‘invisibly’). the raid software included with current versions of linux (and ubuntu) is based on the ‘mdadm’ driver and works very well, better even than many so-called ‘hardware’ raid controllers. this section will guide you through installing ubuntu server edition using two raid1 partitions on two physical hard drives, one for / and another for swap. raid configuration follow the installation steps until you get to the guided storage configuration step, then: select custom storage layout. create the /boot partition in a local disk. so select one of the devices listed in available devices and add gpt partition. next, enter the partition size, then choose the desired format (ext4) and /boot as mount point. and finally, select create. now to create the raid device select create software raid (md) under available devices. add the name of the raid disk (the default is md0). for this example, select “1 (mirrored)” in raid level, but if you are using a different setup choose the appropriate type (raid0 raid1 raid5 raid6 raid10). note in order to use raid5, raid6 and raid10 you need more than two drives. using raid0 or raid1 only two drives are required. 3

select the devices that will be used by this raid device. the real devices can be marked as active or spare, by default it becomes active when is selected. select the size of the raid device. select create. the new raid device (md0 if you did not change the default) will show up in the available devices list, with software raid 1 type and the chosen size. repeat steps above for the other raid devices. partitioning select the raid 1 device created (md0) then select “add gpt partition”. next, select the size of the partition. this partition will be the swap partition, and a general rule for swap size is twice that of ram. enter the partition size, then choose swap in format. and finally, select create. note a swap partition size of twice the available ram capacity may not always be desirable, especially on systems with large amounts of ram. calculating the swap partition size for servers is highly dependent on how the system is going to be used. for the / partition once again select the raid 1 device then “add gpt partition”. use the rest of the free space on the device, choose the format (default is ext4) and select / as mount point, then create. repeat steps above for the other partitions. once it is finished select “done”. the installation process will then continue normally. degraded raid at some point in the life of the computer a disk failure event may occur. when this happens, using software raid, the operating system will place the array into what is known as a degraded state. if the array has become degraded, due to the chance of data corruption, by default ubuntu server edition will boot to initramfs after thirty seconds. once the initramfs has booted there is a fifteen second prompt giving you the option to go ahead and boot the system, or attempt manual recover. booting to the initramfs prompt may or may not be the desired behavior, especially if the machine is in a remote location. booting to a degraded array can be configured several ways: • the dpkg-reconfigure utility can be used to configure the default behavior, and during the process you will be queried about additional settings related to the array. such as monitoring, email alerts, etc. to reconfigure mdadm enter the following: sudo dpkg−r e c o n f i g u r e mdadm • the dpkg−reconfigure mdadm process will change the /etc/initramfs−tools/conf.d/mdadm configura- tion file. the file has the advantage of being able to pre-configure the system’s behavior, and can also be manually edited: boot_degraded=true 4

note the configuration file can be overridden by using a kernel argument. • using a kernel argument will allow the system to boot to a degraded array as well: – when the server is booting press shift to open the grub menu. – press e to edit your kernel command options. – press the down arrow to highlight the kernel line. – add “bootdegraded=true” (without the quotes) to the end of the line. – press ctrl+x to boot the system. once the system has booted you can either repair the array see the next section for details, or copy important data to another machine due to major hardware failure. raid maintenance the mdadm utility can be used to view the status of an array, add disks to an array, remove disks, etc: the -d tells mdadm to display detailed information about the /dev/md0 device. replace /dev/md0 with the appropriate raid device. • to view the status of a disk in an array: • to view the status of an array, from a terminal prompt enter: sudo mdadm−d /dev/md0 sudo mdadm−e /dev/sda1 the output if very similar to the mdadm−d command, adjust /dev/sda1 for each disk. sudo mdadm−−remove /dev/md0 /dev/sda1 sudo mdadm−−add /dev/md0 /dev/sda1 change /dev/md0 and /dev/sda1 to the appropriate raid device and disk. • if a disk fails and needs to be removed from an array enter: • similarly, to add a new disk: sometimes a disk can change to a faulty state even though there is nothing physically wrong with the drive. it is usually worthwhile to remove the drive from the array then re-add it. this will cause the drive to re-sync with the array. if the drive will not sync with the array, it is a good indication of hardware failure. the /proc/mdstat file also contains useful information about the system’s raid devices: cat / proc /mdstat p e r s o n a l i t i e s : [ multipath ] [ l i n e a r ] [ raid0 ] [ raid1 ] [ raid5 ] [ raid4 ] [ raid6 ] [ the following command is great for watching the status of a syncing drive: raid10 ] md0 : a c t i v e raid1 sda1 [ 0 ] [ 2 / 2 ] 10016384 blocks sdb1 [ 1 ] [uu] unused devices : <none> watch−n1 cat / proc /mdstat 5

press ctrl+c to stop the watch command. if you do need to replace a faulty drive, after the drive has been replaced and synced, grub will need to be installed. to install grub on the new drive, enter the following: sudo grub−i n s t a l l /dev/md0 replace /dev/md0 with the appropriate array device name. resources the topic of raid arrays is a complex one due to the plethora of ways raid can be configured. please see the following links for more information: • ubuntu wiki articles on raid. • software raid howto • managing raid on linux logical volume manager (lvm) logical volume manger, or lvm, allows administrators to create logical volumes out of one or multiple physical hard disks. lvm volumes can be created on both software raid partitions and standard partitions residing on a single disk. volumes can also be extended, giving greater flexibility to systems as requirements change. overview a side effect of lvm’s power and flexibility is a greater degree of complication. before diving into the lvm installation process, it is best to get familiar with some terms. • physical volume (pv): physical hard disk, disk partition or software raid partition formatted as lvm pv. • volume group (vg): is made from one or more physical volumes. a vg can can be extended by adding more pvs. a vg is like a virtual disk drive, from which one or more logical volumes are carved. • logical volume (lv): is similar to a partition in a non-lvm system. a lv is formatted with the desired file system (ext3, xfs, jfs, etc), it is then available for mounting and data storage. installation as an example this section covers installing ubuntu server edition with /srv mounted on a lvm volume. during the initial install only one physical volume (pv) will be part of the volume group (vg). another pv will be added after install to demonstrate how a vg can be extended. there are several installation options for lvm in guided storage configuration step: • select “use an entire disk”, “set up this disk as an lvm group”, and done. this option will create a /boot partition in the local disk and the rest of the disk space is allocated to the lvm group. • select “use an entire disk”, “set up this disk as an lvm group”, “encrypt the lvm group with luks”, insert the password (and confirm it), and done. the output is the same as described above but the lvm group is encrypted. 6

• select “custom storage layout”, and done. at this time the only way to configure a system with both lvm and standard partitions, during installation, is to use this approach. this is the option used in this example. follow the installation steps until you get to the storage configuration step, then: let’s first create a /boot partition in a local disk. select the hard disk under available devices, and add gpt parition. add the size and format (ext4), then select /boot as mount point. finally, select create. the /boot partition will be listed under file system summary. next, create standard swap, and / partitions with whichever filesystem you prefer following the steps above. now the lvm volume group will be created. select “create volume group (lvm)”. enter a name for the volume group (default is vg0), select the device (lvm physical volume) and the size, and choose “create”. there is an option to encrypt your volume, if you want it encrypted select “create encrypted volume” and enter a password (also confirm it). the brand new lvm group (if the default was not changed it is vg0) will be listed as a device in available devices. to create a lvm logical volume select the created lvm volume group and “create logical volume”. give it a name (default is lv-0), let’s call it lv-srv since this will be used to mount /srv. insert the size of the volume, your preferred filesytem format, and select /srv as mount point. choose “create”. the lvm logical volume mounted at /srv will be listed in the filesystem summary. finally, select “done”. then confirm the changes and continue with the rest of the installation. there are some useful utilities to view information about lvm: • pvdisplay: shows information about physical volumes. • vgdisplay: shows information about volume groups. • lvdisplay: shows information about logical volumes. extending volume groups continuing with srv as an lvm volume example, this section covers adding a second hard disk, creating a physical volume (pv), adding it to the volume group (vg), extending the logical volume srv and finally extending the filesystem. this example assumes a second hard disk has been added to the system. in this example, this hard disk will be named /dev/sdb and we will use the entire disk as a physical volume (you could choose to create partitions and use them as different physical volumes) warning make sure you don’t already have an existing /dev/sdb before issuing the commands below. you could lose some data if you issue those commands on a non-empty disk. first, create the physical volume, in a terminal execute: sudo pvcreate /dev/sdb now extend the volume group (vg): sudo vgextend vg0 /dev/sdb use vgdisplay to find out the free physical extents - free pe / size (the size you can allocate). we will assume a free size of 511 pe (equivalent to 2gb with a pe size of 4mb) and we will use the whole free space available. use your own pe and/or free space. the logical volume (lv) can now be extended by different methods, we will only see how to use the pe to extend the lv: sudo lvextend /dev/vg0/ srv−l +511 7

the -l option allows the lv to be extended using pe. the -l option allows the lv to be extended using meg, gig, tera, etc bytes. even though you are supposed to be able to expand an ext3 or ext4 filesystem without unmounting it first, it may be a good practice to unmount it anyway and check the filesystem, so that you don’t mess up the day you want to reduce a logical volume (in that case unmounting first is compulsory). the following commands are for an ext3 or ext4 filesystem. if you are using another filesystem there may be other utilities available. sudo umount / srv sudo e2fsck−f /dev/vg0/ srv the -f option of e2fsck forces checking even if the system seems clean. finally, resize the filesystem: sudo r e s i z e 2 f s /dev/vg0/ srv now mount the partition and check its size. mount /dev/vg0/ srv / srv && df−h / srv resources • see the ubuntu wiki lvm articles. • see the lvm howto for more information. • for more information on fdisk see the fdisk man page. iscsi the iscsi protocol can be used to install ubuntu on systems with or without hard disks attached, and ibft can be used to automate iscsi setup on installation and boot. installation on a diskless system the first steps of a diskless iscsi installation are identical to the installation using debian-installer section up to “hard drive layout”. the installer will display a warning with the following message: no disk drive was detected . the d r i v e r needed by your i f you know the name of disk drive , you can s e l e c t i t from the l i s t . select the item in the list titled login to iscsi targets. you will be prompted to enter an ip address to scan for iscsi targets with a description of the format for the address. enter the ip address for the location of your iscsi target and navigate to <continue> then hit enter if authentication is required in order to access the iscsi device, provide the username in the next field. otherwise, leave it blank. if your system is able to connect to the iscsi provider, you should see a list of available iscsi targets where the operating system can be installed. the list should be similar to the following : 8

s e l e c t the iscsi t a r g e t s you wish to use . iscsi [ ] t a r g e t s on 1 9 2 . 1 6 8 . 1 . 2 9 : 3 2 6 0 : iqn .2016−03. trustys−i s c s i t a r g e t : storage . sys0 <continue> <go back> select the iscsi target that you want to use with the space bar. use the arrow keys to navigate to the target that you want to select. navigate to <continue> and hit enter. if the connection to the iscsi target is successful, you will be prompted with the [!!] partition disks installation menu. the rest of the procedure is identical to any normal installation on attached disks. once the installation is completed, you will be asked to reboot. installation on a system with disk attached again, the iscsi installation on a normal server with one or many disks attached is identical to the instal- lation using debian-installer section until we reach the disk partitioning menu. instead of using any of the guided selection, we need to perform the following steps : navigate to the manual menu entry select the configure iscsi volumes menu entry choose the log into iscsi targets you will be prompted to enter an ip address to scan for iscsi targets. with a description of the format for the address. enter the ip address and navigate to <continue> then hit enter if authentication is required in order to access the iscsi device, provide the username in the next field or leave it blank. if your system is able to connect to the iscsi provider, you should see a list of available iscsi targets where the operating system can be installed. the list should be similar to the following : s e l e c t t a r g e t s you wish to use . the iscsi iscsi [ ] t a r g e t s on 1 9 2 . 1 6 8 . 1 . 2 9 : 3 2 6 0 : iqn .2016−03. trustys−i s c s i t a r g e t : storage . sys0 <continue> <go back> select the iscsi target that you want to use with the space bar. use the arrow keys to navigate to the target that you want to select navigate to <continue> and hit enter. if successful, you will come back to the menu asking you to log into iscsi targets. navigate to finish and hit enter the newly connected iscsi disk will appear in the overview section as a device prefixed with scsi. this is the disk that you should select as your installation disk. once identified, you can choose any of the partitioning methods. 9

warning depending on your system configuration, there may be other scsi disks attached to the system. be very careful to identify the proper device before proceeding with the installation. otherwise, irreversible data loss may result from performing an installation on the wrong disk. installation with ibft in order to setup iscsi based on the ibft (iscsi boot firmware table) on the installation and boot, append these options at the installer prompt (or to the preseed file): disk−detect / i b f t / enable=true partman−i s c s i / iscsi_auto=true this should probe for ibft information and configure network interface(s) and iscsi target(s) accordingly during the installation, and configure system boot (initramfs) to do that too in order to find the root device. warning the support for ibft is available in the debian-installer on netboot images as of 2019-06-20 and (expected) on iso images for the 18.04.3 point release and later. rebooting to an iscsi target the procedure is specific to your hardware platform. as an example, here is how to reboot to your iscsi target using ipxe ipxe> dhcp configuring ( net0 5 2 : 5 4 : 0 0 : a4 : f2 : a9 ) . . . . . . . ok i s c s i : 1 9 2 . 1 6 8 . 1 . 2 9 : : : : iqn .2016−03. trustys−i s c s i t a r g e t : storage . ipxe> sanboot sys0 if the procedure is successful, you should see the grub menu appear on the screen. package management ubuntu features a comprehensive package management system for installing, upgrading, configuring, and removing software. in addition to providing access to an organized base of over 60,000 software packages for your ubuntu computer, the package management facilities also feature dependency resolution capabilities and software update checking. several tools are available for interacting with ubuntu’s package management system, from simple command- line utilities which may be easily automated by system administrators, to a graphical interface which is easy to use by those new to ubuntu. introduction ubuntu’s package management system is derived from the same system used by the debian gnu/linux distribution. the package files contain all of the necessary files, meta-data, and instructions to implement a particular functionality or software application on your ubuntu computer. debian package files typically have the extension .deb, and usually exist in repositories which are collections of packages found online or on physical media, such as cd-rom discs. packages are normally in a pre- compiled binary format; thus installation is quick and requires no compiling of software. 10

many packages use dependencies. dependencies are additional packages required by the principal package in order to function properly. for example, the speech synthesis package festival depends upon the package alsa−utils, which is a package supplying the alsa sound library tools needed for audio playback. in order for festival to function, it and all of its dependencies must be installed. the software management tools in ubuntu will do this automatically. apt the apt command is a powerful command-line tool, which works with ubuntu’s advanced packaging tool (apt) performing such functions as installation of new software packages, upgrade of existing software packages, updating of the package list index, and even upgrading the entire ubuntu system. some examples of popular uses for the apt utility: • install a package: installation of packages using the apt tool is quite simple. for example, to install the nmap network scanner, type the following: sudo apt i n s t a l l nmap • remove a package: removal of a package (or packages) is also straightforward. to remove the package installed in the previous example, type the following: sudo apt remove nmap tip multiple packages: you may specify multiple packages to be installed or removed, sepa- rated by spaces. notice scripting: while apt is a command-line tool, it is intended to be used interactively, and not to be called from non-interactive scripts. the apt−get command should be used in scripts (perhaps with the−−quiet flag). for basic commands the syntax of the two tools is identical. also, adding the−−purge option to apt remove will remove the package configuration files as well. this may or may not be the desired effect, so use with caution. • update the package index: the apt package index is essentially a database of available packages from the repositories defined in the /etc/apt/sources. list file and in the /etc/apt/sources. list .d di- rectory. to update the local package index with the latest changes made in the repositories, type the following: sudo apt update • upgrade packages: over time, updated versions of packages currently installed on your computer may become available from the package repositories (for example security updates). to upgrade your system, first, update your package index as outlined above, and then type: sudo apt upgrade for information on upgrading to a new ubuntu release see upgrading. actions of the apt command, such as installation and removal of packages, are logged in the /var/log/dpkg.log log file. for further information about the use of apt, read the comprehensive apt user’s guide or type: apt help 11

aptitude launching aptitude with no command-line options will give you a menu-driven, text-based front-end to the advanced packaging tool (apt) system. many of the common package management functions, such as installation, removal, and upgrade, can be performed in aptitude with single-key commands, which are typically lowercase letters. aptitude is best suited for use in a non-graphical terminal environment to ensure proper functioning of the command keys. you may start the menu-driven interface of aptitude as a normal user by typing the following command at a terminal prompt: sudo aptitude when aptitude starts, you will see a menu bar at the top of the screen and two panes below the menu bar. the top pane contains package categories, such as new packages and not installed packages. the bottom pane contains information related to the packages and package categories. using aptitude for package management is relatively straightforward, and the user interface makes common tasks simple to perform. the following are examples of common package management functions as performed in aptitude: • install packages: to install a package, locate the package via the not installed packages package category, by using the keyboard arrow keys and the enter key. highlight the desired package, then press the + key. the package entry should turn green, indicating that it has been marked for installation. now press g to be presented with a summary of package actions. press g again, and downloading and installation of the package will commence. when finished, press enter, to return to the menu. • remove packages: to remove a package, locate the package via the installed packages package category, by using the keyboard arrow keys and the enter key. highlight the desired package you wish to remove, then press the - key. the package entry should turn pink, indicating it has been marked for removal. now press g to be presented with a summary of package actions. press g again, and removal of the package will commence. when finished, press enter, to return to the menu. • update package index: to update the package index, simply press the u key. updating of the package index will commence. • upgrade packages: to upgrade packages, perform the update of the package index as detailed above, and then press the u key to mark all packages with updates. now press g whereby you’ll be presented with a summary of package actions. press g again, and the download and installation will commence. when finished, press enter, to return to the menu. the first column of the information displayed in the package list in the top pane, when actually viewing packages lists the current state of the package, and uses the following key to describe the state of the package: • i: installed package • c: package not installed, but package configuration remains on the system • p: purged from system • v: virtual package • b: broken package • u: unpacked files, but package not yet configured • c: half-configured - configuration failed and requires fix • h: half-installed - removal failed and requires a fix to exit aptitude, simply press the q key and confirm you wish to exit. many other functions are available from the aptitude menu by pressing the f10 key. 12

command line aptitude you can also use aptitude as a command-line tool, similar to apt. to install the nmap package with all necessary dependencies, as in the apt example, you would use the following command: sudo aptitude i n s t a l l nmap to remove the same package, you would use the command: sudo aptitude remove nmap consult the man pages for more details of command-line options for aptitude. dpkg dpkg is a package manager for debian-based systems. it can install, remove, and build packages, but unlike other package management systems, it cannot automatically download and install packages or their dependencies. apt and aptitude are newer, and layer additional features on top of dpkg. this section covers using dpkg to manage locally installed packages: • to list all packages in the system’s package database, including all packages, installed and uninstalled, from a terminal prompt type: • depending on the number of packages on your system, this can generate a large amount of output. pipe the output through grep to see if a specific package is installed: | grep apache2 • to list the files installed by a package, in this case the ufw package, enter: replace apache2 with any package name, part of a package name, or a regular expression. dpkg−l dpkg−l dpkg−l ufw • if you are not sure which package installed a file, dpkg−s may be able to tell you. for example: dpkg−s / etc / host . conf base−f i l e s : / etc / host . conf they are on the filesystem, dpkg−s may not know which package they belong to. sudo dpkg−i zip_3.0−4_amd64 . deb change zip_3.0−4_amd64.deb to the actual file name of the local .deb file you wish to install. sudo dpkg−r zip note many files are automatically generated during the package install process, and even though the output shows that the /etc/host.conf belongs to the base-files package. • uninstalling a package can be accomplished by: • you can install a local .deb file by entering: 13

caution uninstalling packages using dpkg, in most cases, is not recommended. it is better to use a package manager that handles dependencies to ensure that the system is in a consistent state. for example, using dpkg−r zip will remove the zip package, but any packages that depend on it will still be installed and may no longer function correctly. for more dpkg options see the man page: man dpkg. apt configuration configuration of the advanced packaging tool (apt) system repositories is stored in the /etc/apt/sources . list file and the /etc/apt/sources. list .d directory. an example of this file is referenced here, along with information on adding or removing repository references from the file. you may edit the file to enable repositories or disable them. for example, to disable the requirement of inserting the ubuntu cd-rom whenever package operations occur, simply comment out the appropriate line for the cd-rom, which appears at the top of the file: # no more prompting f o r cd−rom please # deb cdrom : [ distro−apt−cd−name− release i386 (20111013.1) ]/ distro−short− codename main r e s t r i c t e d extra repositories in addition to the officially supported package repositories available for ubuntu, there exist additional community-maintained repositories which add thousands more packages for potential installation. two of the most popular are the universe and multiverse repositories. these repositories are not officially supported by ubuntu, but because they are maintained by the community they generally provide packages which are safe for use with your ubuntu computer. note packages in the multiverse repository often have licensing issues that prevent them from being distributed with a free operating system, and they may be illegal in your locality. warning be advised that neither the universe or multiverse repositories contain officially supported pack- ages. in particular, there may not be security updates for these packages. many other package sources are available, sometimes even offering only one package, as in the case of package sources provided by the developer of a single application. you should always be very careful and cautious when using non-standard package sources, however. research the source and packages carefully before performing any installation, as some package sources and their packages could render your system unstable or non-functional in some respects. by default, the universe and multiverse repositories are enabled but if you would like to disable them edit /etc/apt/sources. list and comment the following lines: deb http :// archive . ubuntu . com/ubuntu distro−short−codename universe multiverse deb−s r c http :// archive . ubuntu . com/ubuntu distro−short−codename universe deb http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename universe deb−s r c http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename universe deb http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename−updates multiverse universe 14

universe multiverse deb−s r c http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename−updates deb http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename multiverse deb−s r c http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename multiverse deb http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename−updates deb−s r c http :// us . archive . ubuntu . com/ubuntu/ distro−short−codename−updates deb http :// s e c u r i t y . ubuntu . com/ubuntu distro−short−codename−s e c u r i t y universe deb−s r c http :// s e c u r i t y . ubuntu . com/ubuntu distro−short−codename−s e c u r i t y deb http :// s e c u r i t y . ubuntu . com/ubuntu distro−short−codename−s e c u r i t y deb−s r c http :// s e c u r i t y . ubuntu . com/ubuntu distro−short−codename−s e c u r i t y multiverse universe multiverse multiverse automatic updates ing to fit your needs: the unattended-upgrades package can be used to automatically install updated packages and can be con- figured to update all packages or just install security updates. first, install the package by entering the following in a terminal: sudo apt i n s t a l l unattended−upgrades to configure unattended-upgrades, edit /etc/apt/apt.conf.d/50unattended−upgrades and adjust the follow- unattended−upgrade : : allowed−origins { ”${ distro_id }: ${ distro_codename}−s e c u r i t y ” ; ”${ distro_id }: ${ distro_codename}−updates ” ; ”${ distro_id }: ${ distro_codename}−proposed ” ; ”${ distro_id }: ${ distro_codename}−backports ” ; ”${ distro_id }: ${ distro_codename }”; certain packages can also be blacklisted and therefore will not be automatically updated. to blacklist a package, add it to the list: // // // }; unattended−upgrade : : package−b l a c k l i s t { // // // // }; ”vim ” ; ” l i b c 6 ” ; ” libc6−dev ” ; ” libc6−i686 ” ; figuration options: note the double “//” serve as comments, so whatever follows “//” will not be evaluated. to enable automatic updates, edit /etc/apt/apt.conf.d/20auto−upgrades and set the appropriate apt con- apt: : periodic : : update−package−l i s t s ”1”; apt: : periodic : : download−upgradeable−packages ”1”; 15

apt: : periodic : : autocleaninterval ”7”; the above configuration updates the package list, downloads, and installs available upgrades every day. the local download archive is cleaned every week. on servers upgraded to newer versions of ubuntu, depending on your responses, the file listed above may not be there. in this case, creating a new file of this name should also work. note apt: : periodic : : unattended−upgrade ”1”; you can read more about apt periodic configuration options in the /etc/cron.daily/apt−compat the results of unattended-upgrades will be logged to /var/log/unattended−upgrades. in /etc/apt/apt.conf.d/50unattended−upgrades will configuring unattended−upgrade::mail enable unattended-upgrades to email an administrator detailing any packages that need upgrading or have problems. another useful package is apticron. apticron will configure a cron job to email an administrator information about any packages on the system that have updates available, as well as a summary of changes in each package. to install the apticron package, in a terminal enter: sudo apt i n s t a l l apticron script header. notifications once the package is installed edit /etc/apticron/apticron.conf, to set the email address and other options: email=”root@example . com” references most of the material covered in this chapter is available in man pages, many of which are available online. • the installingsoftware ubuntu wiki page has more information. • for more dpkg details see the dpkg man page. • the apt user’s guide and apt man page contain useful information regarding apt usage. • see the aptitude user’s manual for more aptitude options. • the adding repositories howto (ubuntu wiki) page contains more details on adding repositories. kernel crash dump introduction a kernel crash dump refers to a portion of the contents of volatile memory (ram) that is copied to disk whenever the execution of the kernel is disrupted. the following events can cause a kernel disruption : • kernel panic • non maskable interrupts (nmi) 16

• machine check exceptions (mce) • hardware failure • manual intervention for some of those events (panic, nmi) the kernel will react automatically and trigger the crash dump mechanism through kexec. in other situations a manual intervention is required in order to capture the memory. whenever one of the above events occurs, it is important to find out the root cause in order to prevent it from happening again. the cause can be determined by inspecting the copied memory contents. kernel crash dump mechanism when a kernel panic occurs, the kernel relies on the kexec mechanism to quickly reboot a new instance of the kernel in a pre-reserved section of memory that had been allocated when the system booted (see below). this permits the existing memory area to remain untouched in order to safely copy its contents to storage. installation the kernel crash dump utility is installed with the following command: sudo apt i n s t a l l linux−crashdump loader process . <yes> <no> f u l l system boot ( s y s v i n i t only ) ? t r i g g e r a r e s t a r t into a | | | | kernel | | loaded by kexec instead of going through the i f you choose t h i s option , a system reboot w i l l note starting with 16.04, the kernel crash dump mechanism is enabled by default. during the instal- lation, you will be prompted with the following dialogs. |−−−−−−−−−−−−−−−−−−−−−−−−| configuring kexec−t o o l s |−−−−−−−−−−−−−−−−−−−−−−−−| | should kexec−t o o l s handle reboots |−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−| select yes to hook up kexec−tools for all reboots. |−−−−−−−−−−−−−−−−−−−−−−−−| configuring kdump−t o o l s |−−−−−−−−−−−−−−−−−−−−−−−−| the kdump−t o o l s mechanism w i l l be enabled . a | | should kdump−t o o l s be enabled be d e f a u l t ? |−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−| | | | | i s | parameter . | i f you choose t h i s option , reboot s t i l l required in order to enable the crashkernel kernel <yes> <no> | | | | | | 17 | | | | | | | | | | | | | | | | | | |

( true / f a l s e ) /kexec and set parameters directly: # load a kexec kernel load_kexec=true yes should be selected here as well, to enable kdump−tools. if you ever need to manually enable the functionality, you can use the dpkg−reconfigure kexec−tools and dpkg−reconfigure kdump−tools commands and answer yes to the questions. you can also edit /etc/default as well, edit /etc/default/kdump−tools to enable kdump by including the following line: if a reboot has not been done since installation of the linux−crashdump package, a reboot will be required in order to activate the crashkernel= boot parameter. upon reboot, kdump−tools will be enabled and active. if you enable kdump−tools after a reboot, you will only need to issue the kdump−config load command to you can view the current status of kdump via the command kdump−config show. this will display something activate the kdump mechanism. use_kdump=1 like this: dump_mode: use_kdump: kdump_sysctl: kdump_coredir: crashkernel addr : kdump 1 kernel . panic_on_oops=1 / var / crash / var / l i b /kdump/vmlinuz kdump i n i t r d : / var / l i b /kdump/ i n i t r d . img ready to kdump current s t a t e : kexec command : / sbin / kexec−p−−command−l i n e = ” . . . ”−−i n i t r d = . . . this tells us that we will find core dumps in /var/crash. configuration in addition to local dump, it is now possible to use the remote dump functionality to send the kernel crash dump to a remote server, using either the ssh or nfs protocols. local kernel crash dumps remote kernel crash dumps using the ssh protocol local dumps are configured automatically and will remain in use unless a remote protocol is chosen. many configuration options exist and are thoroughly documented in the /etc/default/kdump−tools file. to enable remote dumps using the ssh protocol, the /etc/default/kdump−tools must be modified in the #−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− # ssh− username and hostname of # remote dump f a c i l i t i e s : the remote s e r v e r r e c e i v e the dump and dmesg f i l e s . following manner : that w i l l # 18

# # # # remote s e r v e r i f hostname of i s the d e f a u l t . to the remote s e r v e r . ip address w i l l be used as a p r e f i x to the the ssh private key to be used to l o g i n to the remote timestamped d i r e c t o r y when sending f i l e s ’ ip ’ propagate command will create a new keypair. the hosttag variable may be used to use the hostname of the system as a prefix to the remote directory to be created instead of the ip address. the only mandatory variable to define is ssh. it must contain the username and hostname of the remote server using the format {username}@{remote server}. s e r v e r . use kdump−c o n f i g propagate to send the public key to the # ssh_key− full path of # hosttag− s e l e c t ssh=”ubuntu@kdump−netcrash ” ssh_key may be used to provide an existing private key to be used. otherwise, the kdump−config the following example shows how kdump−config propagate is used to create and propagate a new keypair sudo kdump−c o n f i g propagate ’kdump−netcrash ( 1 9 2 . 1 6 8 . 1 . 7 4 ) ’ can ’ t be e s t a b l i s h e d . ubuntu@kdump−netcrash ’ s password : propagated ssh key / root /. ssh /kdump_id_rsa to s e r v e r ubuntu@kdump−netcrash the kdump−config show command can be used to confirm that kdump is correctly configured to use the kdump−c o n f i g show need to generate a new ssh key . . . the a u t h e n t i c i t y of host ecdsa key f i n g e r p r i n t are you sure you want to continue connecting ( yes /no ) ? yes the password of the account used on the remote server will be required in order to successfully send the public key to the server i s sha256 : imp+5y28qhbd+tevfcwrexykdd4di3yn4ovlu3cbbq4 . to the remote server : ssh protocol : kdump dump_mode: 1 use_kdump: kernel . panic_on_oops=1 kdump_sysctl: kdump_coredir: / var / crash crashkernel addr : 0 x2c000000 / var / l i b /kdump/vmlinuz : kdump i n i t r d : symbolic l i n k to /boot/vmlinuz−4.4.0−10− g e n e r i c symbolic l i n k to / var / l i b /kdump/ i n i t r d . img / var / l i b /kdump/ i n i t r d . img : −4.4.0−10− g e n e r i c ubuntu@kdump−netcrash / root /. ssh /kdump_id_rsa ip ready to kdump s t a t e : ssh : ssh_key: hosttag: current following manner : remote kernel crash dumps using the nfs protocol to enable remote dumps using the nfs protocol, the /etc/default/kdump−tools must be modified in the # nfs− nfs=”kdump−netcrash :/ var / crash ” hostname and mount point of the crash dump. the syntax must be {hostname}:{mountpoint} ( e . g . the nfs s e r v e r configured to r e c e i v e remote :/ var / crash ) # # # 19

nfs protocol : as with the ssh protocol, the hosttag variable can be used to replace the ip address by the hostname as the prefix of the remote directory. the kdump−config show command can be used to confirm that kdump is correctly configured to use the kdump−c o n f i g show kdump dump_mode: 1 use_kdump: kernel . panic_on_oops=1 kdump_sysctl: kdump_coredir: / var / crash crashkernel addr : 0 x2c000000 symbolic l i n k to /boot/vmlinuz−4.4.0−10− g e n e r i c symbolic l i n k to / var / l i b /kdump/ i n i t r d . img / var / l i b /kdump/ i n i t r d . img : / var / l i b /kdump/vmlinuz : kdump i n i t r d : −4.4.0−10− g e n e r i c s t a t e : kdump−netcrash :/ var / crash hostname ready to kdump nfs: hosttag: current verification to confirm that the kernel dump mechanism is enabled, there are a few things to verify. first, confirm that the crashkernel boot parameter is present (note: the following line has been split into two to fit the format of this document: cat / proc / cmdline root=/dev/mapper/ precises−root ro boot_image=/vmlinuz−3.2.0−17− s e r v e r crashkernel =384m−2g:64m,2g−:128m range=start−[end ] crashkernel =384m−2g:64m,2g−:128m the above value means: ’ start ’ i s the crashkernel parameter has the following syntax: crashkernel=<range1 >:<size1 >[,<range2 >:<size2 > , . . . ] [ @offset ] i n c l u s i v e and ’ end ’ i s e x c l u s i v e . so for the crashkernel parameter found in /proc/cmdline we would have : • if the ram is smaller than 384m, then don’t reserve anything (this is the “rescue” case) • if the ram size is between 386m and 2g (exclusive), then reserve 64m • if the ram size is larger than 2g, then reserve 128m . . . [ second, verify that the kernel has reserved the requested memory area for the kdump kernel by doing: dmesg | grep−i crash finally, as seen previously, the kdump−config show command displays the current status of the kdump-tools 0.000000] reserving 64mb of memory at 800mb f o r ( system ram: configuration : crashkernel 1023mb) 20

kdump−c o n f i g show kdump dump_mode: 1 use_kdump: kernel . panic_on_oops=1 kdump_sysctl: / var / crash kdump_coredir: crashkernel addr : 0 x2c000000 / var / l i b /kdump/vmlinuz : kdump i n i t r d : current kexec command : s t a t e : / var / l i b /kdump/ i n i t r d . img : symbolic l i n k to / var / l i b /kdump/ i n i t r d . img symbolic l i n k to /boot/vmlinuz−4.4.0−10− g e n e r i c −4.4.0−10− g e n e r i c / sbin / kexec−p−−command−l i n e =”boot_image=/vmlinuz−4.4.0−10− g e n e r i c root =/dev/mapper/vivids−−vg−root ,115200 i r q p o l l maxcpus=1 nousb systemd . unit=kdump−t o o l s . s e r v i c e ”−− i n i t r d=/var / l i b /kdump/ i n i t r d . img / var / l i b /kdump/vmlinuz ro debug break=i n i t ready to kdump console=ttys0 testing the crash dump mechanism warning testing the crash dump mechanism will cause a system reboot. in certain situations, this can cause data loss if the system is under heavy load. if you want to test the mechanism, make sure that the system is idle or under very light load. verify that the sysrq mechanism is enabled by looking at the value of the /proc/sys/kernel/sysrq kernel parameter : cat / proc / sys / kernel / sysrq the options and the default value. enable dump then reboot testing with the following command : if a value of 0 is returned the dump and then reboot feature is disabled. a value greater than 1 indicates that once this is done, you must become root, as just using sudo will not be sufficient. as the root user, you will a sub-set of sysrq features is enabled. see /etc/sysctl .d/10−magic−sysrq.conf for a detailed description of sudo s y s c t l−w kernel . sysrq=1 have to issue the command echo c > /proc/sysrq−trigger. if you are using a network connection, you will sudo−s # echo c > / proc / sysrq−t r i g g e r lose contact with the system. this is why it is better to do the test while being connected to the system console. this has the advantage of making the kernel dump process visible. a typical test output should look like the following : 31.659002] sysrq : trigger a crash 31.659749] bug: unable to handle kernel null pointer d e r e f e r e n c e at [ sudo ] password f o r ubuntu : [ [ ( n u l l ) [< f f f f f f f f 8 1 3 9 f 1 6 6 >] sysrq_handle_crash+0x16/0x20 ip : 31.662668] 31.662668] pgd 3 bfb9067 pud 368 a7067 pmd 0 31.662668] oops : 0002 [#1] smp 31.662668] cpu 1 [ [ [ [ . . . . 21

the rest of the output is truncated, but you should see the system rebooting and somewhere in the log, you will see the following line : begin : saving vmcore from kernel crash . . . if the dump does not work due to oom (out of memory) error, then try increasing the amount of reserved once completed, the system will reboot to its normal operational mode. you will then find the kernel crash dump file, and related subdirectories, in the /var/crash directory : l s / var / crash 201809240744 linux−image−4.15.0−34− generic−201809240744. crash memory by editing /etc/default/grub.d/kdump−tools.cfg. for example, to reserve 512 megabytes : grub_cmdline_linux_default=”$grub_cmdline_linux_default crashkernel =384m−:512m run sudo update−grub and then reboot afterwards, and then test again. kexec_cmd ” resources kernel crash dump is a vast topic that requires good knowledge of the linux kernel. you can find more information on the topic here : • kdump kernel documentation. • the crash tool • analyzing linux kernel crash (based on fedora, it still gives a good walkthrough of kernel dump analysis) reporting bugs in ubuntu server the ubuntu project, and thus ubuntu server, uses launchpad as its bug tracker. in order to file a bug, you will need a launchpad account. create one here if necessary. reporting bugs with apport-cli the preferred way to report a bug is with the apport-cli command. it must be invoked on the machine affected by the bug because it collects information from the system on which it is being run and publishes it to the bug report on launchpad. getting that information to launchpad can, therefore, be a challenge if the system is not running a desktop environment in order to use a browser (common with servers) or if it does not have internet access. the steps to take in these situations are described below. note the commands apport-cli and ubuntu-bug should give the same results on a cli server. the latter is actually a symlink to apport-bug which is intelligent enough to know whether a desktop environment is in use and will choose apport-cli if not. since server systems tend to be cli-only apport-cli was chosen from the outset in this guide. bug reports in ubuntu need to be filed against a specific software package, so the name of the package (source package or program name/path) affected by the bug needs to be supplied to apport-cli: apport−c l i packagename 22

once apport-cli has finished gathering information you will be asked what to do with it. for instance, to report a bug in vim: $ apport−c l i vim *** c o l l e c t i n g problem information the c o l l e c t e d information can be sent a p p l i c a t i o n . this might . . . take a few minutes . to the developers to improve the *** send problem report to the developers ? the problem report has been sent , please after automatically opened web browser . f i l l out the form in the what would you l i k e to do? your options are : ( 2 . 8 kb) s : send report v: view report k: keep report i : cancel and ignore future crashes of c: cancel f i l e f o r please choose (s/v/k/ i /c) : sending l a t e r or copying to somewhere e l s e t h i s program version the first three options are described below: • send: submits the collected information to launchpad as part of the process of filing a new bug report. you will be given the opportunity to describe the bug in your own words. *** uploading problem information the c o l l e c t e d information i s being sent this might 94% take a few minutes . to the bug tracking system . *** to continue , you must v i s i t https :// bugs . launchpad . net /ubuntu/+source /vim/+f i l e b u g /09 b2495a−e2ab−11 e3−879b−68b5996a96c8 ? you can launch a browser now , or copy t h i s url into a browser on another the f o l l o w i n g url: computer . choices : 1: launch a browser now c: cancel please choose (1/c) : 1 the browser that will be used when choosing ‘1’ will be the one known on the system as www-browser via the debian alternatives system. examples of text-based browsers to install include links, elinks, lynx, and w3m. you can also manually point an existing browser at the given url. • view: displays the collected information on the screen for review. this can be a lot of information. press ‘enter’ to scroll by a screenful. press ‘q’ to quit and return to the choice menu. 23

report, typically after transferring it to another ubuntu system. what would you l i k e to do? your options are : ( 2 . 8 kb) s : send report v: view report k: keep report i : cancel and ignore future crashes of c: cancel f i l e f o r sending l a t e r or copying to somewhere e l s e t h i s program version • keep: writes the collected information to disk. the resulting file can be later used to file the bug please choose (s/v/k/ i /c) : k problem report f i l e : /tmp/ apport . vim .1 pg92p02 . apport to report the bug, get the file onto an internet-enabled ubuntu system and apply apport-cli to it. this will cause the menu to appear immediately (the information is already collected). you should then press ‘s’ to send: apport−c l i apport . vim .1 pg92p02 . apport apport−c l i vim−−save apport . vim . t e s t . apport to directly save a report to disk (without menus) you can do: report names should end in .apport. note if this internet-enabled system is non-ubuntu/debian, apport-cli is not available so the bug will need to be created manually. an apport report is also not to be included as an attachment to a bug either so it is completely useless in this scenario. reporting application crashes the software package that provides the apport-cli utility, apport, can be configured to automatically capture the state of a crashed application. this is enabled by default (in /etc/default/apport). after an application crashes, if enabled, apport will store a crash report under /var/crash: whoopsie 150k jul 24 16:17 _usr_lib_x86_64−linux− −rw−r−−−−− 1 peter gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . crash apport−c l i use the apport-cli command without arguments to process any pending crash reports. it will offer to report them one by one. *** send problem report to the developers ? the problem report has been sent , please after automatically opened web browser . f i l l out the form in the what would you l i k e to do? your options are : (153.0 kb) s : send report v: view report k: keep report i : cancel and ignore future crashes of c: cancel f i l e f o r please choose (s/v/k/ i /c) : s sending l a t e r or copying to somewhere e l s e t h i s program version 24

if you send the report, as was done above, the prompt will be returned immediately and the /var/crash directory will then contain 2 extra files: −rw−r−−−−− 1 peter gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . crash −rw−rw−r−− 1 peter gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . upload −rw−−−−−−− 1 whoopsie whoopsie gnu_libmenu−cache2_libexec_menu−cached . 1 0 0 0 . uploaded whoopsie 150k jul 24 16:17 _usr_lib_x86_64−linux− 0 jul 24 16:37 _usr_lib_x86_64−linux− 0 jul 24 16:37 _usr_lib_x86_64−linux− sending in a crash report like this will not immediately result in the creation of a new public bug. the report will be made private on launchpad, meaning that it will be visible to only a limited set of bug triagers. these triagers will then scan the report for possible private data before creating a public bug. whoopsie resources • see the reporting bugs ubuntu wiki page. • also, the apport page has some useful information. though some of it pertains to using a gui. upgrading there are several ways to upgrade from one ubuntu release to another. this section gives an overview of the recommended upgrade method. do-release-upgrade the recommended way to upgrade a server edition installation is to use the do-release-upgrade utility. part of the update-manager-core package, it does not have any graphical dependencies and is installed by default. is recommended because it has the ability to handle system configuration changes sometimes needed between releases. to upgrade to a newer release, from a terminal prompt enter: debian based systems can also be upgraded by using apt dist−upgrade. however, using do-release-upgrade do−r e l e a s e−upgrade do−r e l e a s e−upgrade−d it is also possible to use do-release-upgrade to upgrade to a development version of ubuntu. to accomplish this use the -d switch: warning upgrading to a development release is not recommended for production environments. for further stability of an lts release, there is a slight change in behaviour if you are currently running an lts version. lts systems are only automatically considered for an upgrade to the next lts via do-release- upgrade with the first point release. so for example 18.04 will only upgrade once 20.04.1 is released. if you want to update before, e.g. on a subset of machines to evaluate the lts upgrade for your setup the same argument as an upgrade to a dev release has to be used via the -d switch. 25

device mapper multipathing - introduction device mapper multipath will be referred here as multipath only. multipath allows you to configure multiple i/o paths between server nodes and storage arrays into a single device. these i/o paths are physical san connections that can include separate cables, switches, and controllers. multipathing aggregates the i/o paths, creating a new device that consists of the aggregated paths. this chapter provides an introduction and a high-level overview of multipath. overview multipath can be used to provide: • redundancy multipath can provide failover in an active/passive configuration. in an active/passive configuration, only half the paths are used at any time for i/o. if any element of an i/o path (the cable, switch, or controller) fails, multipath switches to an alternate path. • improved performance multipath can be configured in active/active mode, where i/o is spread over the paths in a round-robin fashion. in some configurations, multipath can detect loading on the i/o paths and dynamically re-balance the load. storage array overview it is a very good idea to consult your storage vendor installation guide for the recommended multipath configuration variables for your storage model. the default configuration will probably work but will likely need adjustments based on your storage setup. multipath components | description | | - | - | | dm_multipath kernel module | reroutes | component i/o and supports failover for paths and path groups. | | multipath command | lists and configures multipath devices. normally started up with /etc/rc. sysinit , it can also be started up by a udev program whenever a block device is added or it can be run by the initramfs file system. | | multipathd daemon | monitors paths; as paths fail and come back, it may initiate path group switches. provides for interactive changes to multipath devices. this daemon must be restarted for any changes to the /etc/multipath.conf file to take effect. | | kpartx command | creates device mapper devices for the partitions on a device it is necessary to use this command for dos-based partitions with multipath. the kpartx is provided in its own package, but the multipath-tools package depends on it. | multipath setup overview multipath includes compiled-in default settings that are suitable for common multipath configurations. setting up multipath is often a simple procedure. the basic procedure for configuring your system with multipath is as follows: 1. install the multipath-tools and multipath-tools-boot packages 2. create an empty config file called /etc/multipath.conf 3. edit the multipath.conf file to modify default values and save the updated file. 4. start the multipath daemon 26

5. update initial ramdisk for detailed setup instructions for multipath configuration see dm-multipath configuration and dm- multipath setup. multipath devices without multipath, each path from a server node to a storage controller is treated by the system as a separate device, even when the i/o path connects the same server node to the same storage controller. multipath provides a way of organizing the i/o paths logically, by creating a single device on top of the underlying paths. multipath device identifiers each multipath device has a world wide identifier (wwid), which is guaranteed to be globally unique and unchanging. by default, the name of a multipath device is set to its wwid. alternately, you can set the user_friendly_names option in multipath.conf, which causes multipath to use a node-unique alias of the form mpathn as the name. for example, a node with two hbas attached to a storage controller with two ports via a single unzoned fc switch sees four devices: /dev/sda, /dev/sdb, /dev/sdc, and /dev/sdd. multipath creates a single device with a unique wwid that reroutes i/o to those four underlying devices according to the multipath configuration. when the user_friendly_names configuration option is set to yes, the name of the multipath device is set to mpathn. when new devices are brought under the control of multipath, the new devices may be seen in two different places under the /dev directory: /dev/mapper/mpathn and /dev/dm-n. • the devices in /dev/mapper are created early in the boot process. use these devices to access the multipathed devices. • any devices of the form /dev/dm-n are for internal use only and should never be used directly. you can also set the name of a multipath device to a name of your choosing by using the alias option in the multipaths section of the multipath configuration file. for information on the multipath configuration defaults, including the user_friendly_names and alias configuration options, see dm-multipath configuration. consistent multipath device names in a cluster when the user_friendly_names configuration option is set to yes, the name of the multipath device is unique to a node, but it is not guaranteed to be the same on all nodes using the multipath device. similarly, if you set the alias option for a device in the multipaths section of /etc/multipath.conf, the name is not automatically consistent across all nodes in the cluster. this should not cause any difficulties if you use lvm to create logical devices from the multipath device, but if you require that your multipath device names be consistent in every node it is recommended that you leave the user_friendly_names option set to no and that you not configure aliases for the devices. if you configure an alias for a device that you would like to be consistent across the nodes in the cluster, you should ensure that the /etc/multipath.conf file is the same for each node in the cluster by following the same procedure: 1. configure the aliases for the multipath devices in the in the multipath.conf file on one machine. 27

2. disable all of your multipath devices on your other machines by running the following commands: 3. copy the /etc/multipath.conf file from the first machine to all the other machines in the cluster. 4. re-enable the multipathd daemon on all the other machines in the cluster by running the following # systemctl # multipath−f stop multipath−t o o l s . s e r v i c e s t a r t multipath−t o o l s . s e r v i c e command: # systemctl when you add a new device you will need to repeat this process. multipath device attributes in addition to the user_friendly_names and alias options, a multipath device has numerous attributes. you can modify these attributes for a specific multipath device by creating an entry for that device in the multipaths section of /etc/multipath.conf. for information on the multipaths section of the multipath configuration file, see dm-multipath configu- ration. multipath devices in logical volumes after creating multipath devices, you can use the multipath device names just as you would use a physical device name when creating an lvm physical volume. for example, if /dev/mapper/mpatha is the name of a multipath device, the following command will mark /dev/mapper/mpatha as a physical volume: # pvcreate /dev/mapper/mpatha you can use the resulting lvm physical device when you create an lvm volume group just as you would use any other lvm physical device. note if you attempt to create an lvm physical volume on a whole device on which you have configured partitions, the pvcreate command will fail. when you create an lvm logical volume that uses active/passive multipath arrays as the underlying physical devices, you should include filters in the lvm.conf to exclude the disks that underlie the multipath devices. this is because if the array automatically changes the active path to the passive path when it receives i/o, multipath will failover and failback whenever lvm scans the passive path if these devices are not filtered. for active/passive arrays that require a command to make the passive path active, lvm prints a warning message when this occurs. to filter all scsi devices in the lvm configuration file (lvm.conf), include the following filter in the devices section of the file. f i l t e r = [ ” r / block /” , ” r / disk /” , ” r /sd .*/” , ”a /.*/” ] after updating /etc/lvm.conf, it’s necessary to update the initrd so that this file will be copied there, where the filter matters the most, during boot. perform: update−i n i t r a m f s−u−k a l l 28

note every time either /etc/lvm.conf or /etc/multipath.conf is updated, the initrd should be rebuilt to reflect these changes. this is imperative when blacklists and filters are necessary to maintain a stable storage configuration. device mapper multipathing - configuration device mapper multipath will be referred here as multipath only. before moving on with this session it is recommended that you read: 1. device mapper multi- pathing - introduction multipath is usually able to work out-of-the-box with most common storages. this doesn’t mean the default configuration variables should be used in production: they don’t treat important parameters your storage might need. consult your storage manufacturer’s install guide for the linux multipath configuration options. it is very common that storage vendors provide the most adequate options for linux, including minimal kernel and multipath-tools versions required. default configuration values for dm-multipath can be overridden by editing the /etc/multipath.conf file and restarting the multipathd service. this chapter provides information on parsing and modifying the multipath.conf file and it is split into the following configuration file sections: • configuration file overview • configuration file defaults • configuration file blacklist & exceptions • configuration file multipath section • configuration file devices section configuration file overview the configuration file contains entries of the form: <section > { <attribute > <value> . . . <subsection > { <attribute > <value> . . . } } the following keywords are recognized: • defaults - this section defines default values for attributes which are used whenever no values are given in the appropriate device or multipath sections. • blacklist - this section defines which devices should be excluded from the multipath topology discov- ery. 29

• blacklist_exceptions - this section defines which devices should be included in the multipath topol- ogy discovery, despite being listed in the blacklist section. • multipaths - this section defines the multipath topologies. they are indexed by a world wide identifier(wwid).attributes set in this section take precedence over all others. • devices - this section defines the device-specific settings. devices are identified by vendor, product, and revision. • overrides - this section defines values for attributes that should override the device-specific settings for all devices. configuration file defaults currently, the multipath configuration file only includes a minor defaults section that sets the user_friendly_names parameter to yes: d e f a u l t s { user_friendly_names yes } this overwrites the default value of the user_friendly_names parameter. all the multipath attributes that can set in the defaults section of the multipath.conf file can be found here with an explanation of what they mean. the attributes are: • verbosity • polling_interval • max_polling_interval • reassign_maps • multipath_dir • path_selector • path_grouping_policy • uid_attrs • uid_attribute • getuid_callout • prio • prio_args • features • path_checker • alias_prefix • failback • rr_min_io • rr_min_io_rq • max_fds • rr_weight • no_path_retry • queue_without_daemon • checker_timeout • flush_on_last_del • user_friendly_names • fast_io_fail_tmo • dev_loss_tmo • bindings_file • wwids_file • prkeys_file 30

• log_checker_err • reservation_key • all_tg_pt • retain_attached_hw_handler • detect_prio • detect_checker • force_sync • strict_timing • deferred_remove • partition_delimiter • config_dir • san_path_err_threshold • san_path_err_forget_rate • san_path_err_recovery_time • marginal_path_double_failed_time • marginal_path_err_sample_time • marginal_path_err_rate_threshold • marginal_path_err_recheck_gap_time • delay_watch_checks • delay_wait_checks • marginal_pathgroups • find_multipaths • find_multipaths_timeout • uxsock_timeout • retrigger_tries • retrigger_delay • missing_uev_wait_timeout • skip_kpartx • disable_changed_wwids • remove_retries • max_sectors_kb • ghost_delay • enable_foreign previously the multipath-tools project used to provide a complete configuration file with all the most used options for each of the most used storage devices. currently you can see all those default options by executing sudo multipath−t. this will dump used configuration file including all the embedded default options. configuration file blacklist & exceptions the blacklist section is used to exclude specific devices from the multipath topology. it is most commonly used to exclude local disks, non-multipathed or non-disk devices. 1. blacklist by devnode the default blacklist consists of the regular expressions “ˆ(ram|zram|raw|loop|fd|md|dm-|sr|scd|st|dcssblk)[0- 9]” and “ˆ(td|hd|vd)[a-z]”. this causes virtual devices, non-disk devices, and some other device types to be excluded from multipath handling by default. b l a c k l i s t { devnode ”^(ram | zram | raw | loop | fd |md|dm−| sr | scd | st | dcssblk ) [0−9]” devnode ”^( td | hd | vd ) [ a−z ] ” devnode ”^ c c i s s ! c [0−9]d[0−9]*” } 31

2. blacklist by wwid regular expression for the world wide identifier of a device to be excluded/included 3. blacklist by device subsection for the device description. this subsection recognizes the vendor and product keywords. both are regular expressions. device { vendor ”lenovo” product ” universal xport” } } 4. blacklist by property regular expression for an udev property. all devices that have matching udev properties will be excluded/included. the handling of the property keyword is special, because devices must have at least one whitelisted udev property; otherwise they’re treated as blacklisted, and the message “blacklisted, udev property missing” is displayed in the logs. 5. blacklist by protocol the protocol strings that multipath recognizes are scsi:fcp, scsi:spi, scsi:ssa, scsi:sbp, scsi:srp, scsi:iscsi, scsi:sas, scsi:adt, scsi:ata, scsi:unspec, ccw, cciss, nvme, and undef. the protocol that a path is using can be viewed by running multipathd show paths format “%d %p” 6. blacklist exceptions the blacklist_exceptions section is used to revert the actions of the blacklist section. this allows one to selectively include (“whitelist”) devices which would normally be excluded via the blacklist section. b l a c k l i s t _ e x c e p t i o n s { property ”(scsi_ident_|id_wwn) ” a common usage is to blacklist “everything” using a catch-all regular expression, and create specific blacklist_exceptions entries for those devices that should be handled by multipath-tools. configuration file multipath section the multipaths section allows setting attributes of multipath maps. the attributes that are set via the multipaths section (see list below) take precedence over all other configuration settings, including those from the overrides section. the only recognized attribute for the multipaths section is the multipath subsection. if there are multiple multipath subsections matching a given wwid, the contents of these sections are merged, and settings from later entries take precedence. the multipath subsection recognizes the following attributes: • wwid = (mandatory) world wide identifier. detected multipath maps are matched agains this attribute. note that, unlike the wwid attribute in the blacklist section, this is not a regular expression or a substring; wwids must match exactly inside the multipaths section. • alias = symbolic name for the multipath map. this takes precedence over a an entry for the same wwid in the bindings_file. the following attributes are optional; if not set the default values are taken from the overrides, devices, or defaults section: 32

• path_grouping_policy • path_selector • prio • prio_args • failback • rr_weight • no_path_retry • rr_min_io • rr_min_io_rq • flush_on_last_del • features • reservation_key • user_friendly_names • deferred_remove • san_path_err_threshold • san_path_err_forget_rate • san_path_err_recovery_time • marginal_path_err_sample_time • marginal_path_err_rate_threshold • marginal_path_err_recheck_gap_time • marginal_path_double_failed_time • delay_watch_checks • delay_wait_checks • skip_kpartx • max_sectors_kb • ghost_delay example: multipaths { multipath { wwid a l i a s path_grouping_policy path_selector f a i l b a c k rr_weight no_path_retry } multipath { wwid a l i a s } } 3600508 b4000156d700012000000b0000 yellow multibus ”round−robin 0” manual p r i o r i t i e s 5 1dec_____321816758474 red configuration file devices section multipath-tools have a built-in device table with reasonable defaults for more than 100 known multipath- capable storage devices.the devices section can be used to override these settings. if there are multiple matches for a given device, the attributes of all matching entries are applied to it. if an attribute is specified in several matching device subsections, later entries take precedence. the only recognized attribute for the devices section is the device subsection. devices detected in the system are matched against the device entries using the vendor, product, and revision fields. 33

the vendor, product, and revision fields that multipath or multipathd detect for devices in a system depend on the device type. for scsi devices, they correspond to the respective fields of the scsi inquiry page. in general, the command ‘multipathd show paths format “%d %s” ’ command can be used to see the detected properties for all devices in the system. the device subsection recognizes the following attributes: 1. vendor(mandatory) regular expression to match the vendor name. 2. product(mandatory) regular expression to match the product name. 3. revisionregular expression to match the product revision. 4. product_blacklistproducts with the given vendor matching this string are blacklisted. 5. alias_prefixthe user_friendly_names prefix to use for this device type, instead of the default 6. hardware_handlerthe hardware handler to use for this device type. the following hardware handler “mpath”. are implemented: • 1 emc - (hardware-dependent) hardware handler for dgc class arrays as clariion cx/ax and emc vnx and unity families. • 1 rdac - (hardware-dependent) hardware handler for lsi / engenio / netapp rdac class as netapp santricity e/ef series, and oem arrays from ibm dell sgi stk and sun. • 1 hp_sw - (hardware-dependent) hardware handler for hp/compaq/dec hsg80 and msa/hsv arrays with active/standby mode exclusively. • 1 alua - (hardware-dependent) hardware handler for scsi-3 alua compatible arrays. • 1 ana - (hardware-dependent) hardware handler for nvme ana compatible arrays. the following attributes are optional; if not set the default values are taken from the defaults section: • path_grouping_policy • uid_attribute • getuid_callout • path_selector • path_checker • prio • prio_args • features • failback • rr_weight • no_path_retry • rr_min_io • rr_min_io_rq • fast_io_fail_tmo • dev_loss_tmo • flush_on_last_del • user_friendly_names • retain_attached_hw_handler • detect_prio • detect_checker • deferred_remove • san_path_err_threshold • san_path_err_forget_rate • san_path_err_recovery_time • marginal_path_err_sample_time • marginal_path_err_rate_threshold • marginal_path_err_recheck_gap_time • marginal_path_double_failed_time • delay_watch_checks • delay_wait_checks 34

• skip_kpartx • max_sectors_kb • ghost_delay • all_tg_pt example: devices { device { } } vendor ”3pardata” product ”vv” path_grouping_policy ”group_by_prio” hardware_handler ”1 alua ” prio ” alua ” f a i l b a c k ” immediate ” no_path_retry 18 fast_io_fail_tmo 10 dev_loss_tmo ” i n f i n i t y ” vendor ”dec” product ”hsg80” path_grouping_policy ”group_by_prio” path_checker ”hp_sw” hardware_handler ”1 hp_sw” prio ”hp_sw” no_path_retry ” queue ” } device { device mapper multipathing - setup device mapper multipath will be referred here as multipath only. before moving on with this session it is recommended that you read: 1. device mapper multi- pathing - introduction 2. device mapper multipathing - configuration this section provides step-by-step example procedures for configuring multipath. it includes the following procedures: • basic setup – main defaults & devices attributes. – shows how to ignore disks with blacklists – shows how to rename disks using wwids • configuring active/active paths basic setup before setting up multipath on your system, ensure that your system has been updated and includes the multipath-tools package. if boot from san is desired, then the multipath-tools-boot package is also required. 35

a very simple /etc/multipath.conf file exists, as explained in device mapper multipathing - configuration session. all the non-declared in multipath.conf attributes are taken from multipath-tools internal database and its internal blacklist. the internal attributes database can be acquired by doing: $ sudo multipath -t multipath is usually able to work out-of-the-box with most common storages. this does not mean the default configuration variables should be used in production: they don’t treat important parameters your storage might need. with the internal attributes, described above, and the given example bellow, you will likely be able to create your /etc/multipath.conf file by squashing the code blocks bellow. make sure to read every defaults section attribute comments and change it based on your environment needs. • example of a defaults section: d e f a u l t s { : p o l l i n g _ i n t e r v a l : multipathd : # # name # scope # desc # # # values # d e f a u l t # p o l l i n g _ i n t e r v a l 10 : n > 0 : 5 i n t e r v a l between two path checks properly functioning paths , w i l l gradually i n c r e a s e to (4 * p o l l i n g _ i n t e r v a l ) . in seconds . for the i n t e r v a l between checks : path_selector : multipath & multipathd : sending the same amount of the d e f a u l t path s e l e c t o r algorithm to use these algorithms are o f f e r e d by the kernel multipath target : ”round−robin 0” = loop through every path in the path group , ”queue−length 0” = send the next bunch of ” s e r vi c e−time 0” = choose the path f o r : ” s er v i c e−time 0” path_selector ”round−robin 0” io to each . io down the path with the l e a s t amount of outstanding io . io based on the amount of outstanding io to the path and i t s r e l a t i v e throughput . the next bunch of # # name # scope # desc # # values # # # # # # # d e f a u l t # # # name # scope # desc # # values # # # # # : path_grouping_policy : multipath & multipathd : : the d e f a u l t path grouping p o l i c y to apply to u n s p e c i f i e d multipaths f a i l o v e r multibus group_by_serial = 1 path per p r i o r i t y group = a l l v a l i d paths in 1 p r i o r i t y group = 1 p r i o r i t y group per detected s e r i a l group_by_prio = 1 p r i o r i t y group per path p r i o r i t y number value 36

# # d e f a u l t # path_grouping_policy multibus : group_by_node_name = 1 p r i o r i t y group per f a i l o v e r target node name : uid_attribute : multipath & multipathd : # # name # scope # desc # # d e f a u l t # uid_attribute ”id_serial” i d e n t i f i e r id_serial : should be generated . the d e f a u l t udev a t t r i b u t e from which the path # # name # scope # desc # # # d e f a u l t # : getuid_callout : multipath & multipathd : to obtain a unique superseded by uid_attribute to c a l l o u t i s deprecated , i s deprecated . the d e f a u l t program and args path i d e n t i f i e r . this parameter this parameter : / l i b /udev/ scsi_id−−w h i t e l i s t e d−−device=/dev/%n getuid_callout ”/ l i b /udev/ scsi_id−−w h i t e l i s t e d−−device=/dev/%n” in spc−3 provide an the d e f a u l t function to c a l l p r i o r i t y value . the alua b i t s e x p l o i t a b l e prio value f o r example . : prio : multipath & multipathd : to obtain a path : const # # name # scope # desc # # # d e f a u l t # # prio ” alua ” : prio_args : multipath & multipathd : the arguments # # name # scope # desc # # # d e f a u l t # # prio_args ” timeout=1000 p r e f e r r e d s d s=foo ” datacore p r i o r i t i z e r need one . ( n u l l ) : most prio f u n c t i o n s do not need arguments . the s t r i n g passed to the prio function # # name # scope # desc # # # # values # # f e a t u r e s : : multipath & multipathd : the d e f a u l t extra f e a t u r e s of multipath devices . syntax i s ”num[ number of f e a t u r e s . f e a t u r e s feature_0 feature_1 . . . ] ” , where ‘num’ in the f o l l o w i n g ( p o s s i b l y empty ) i s the l i s t of : queue_if_no_path = queue io i f no path i s a c t i v e ; consider no_partitions using the ‘ no_path_retry ’ keyword instead . = disable automatic p a r t i t i o n s generation via 37

# # d e f a u l t # f e a t u r e s #f e a t u r e s #f e a t u r e s #f e a t u r e s : ”0” kpartx . ”0” ”1 queue_if_no_path” ”1 no_partitions ” ”2 queue_if_no_path no_partitions ” # # name # scope # desc # values # d e f a u l t # path_checker d i r e c t i o : path_checker , checker : multipath & multipathd : : : d i r e c t i o the d e f a u l t method used to determine the paths ’ readsector0 | tur | emc_clariion | hp_sw | d i r e c t i o | rdac | cciss_tur s t a t e rr_min_io : : multipath & multipathd : io to route to a path before switching the number of to the next multipath implementation . this parameter k e r n e l s version up to 2 . 6 . 3 1 ; newer kernel version use the parameter rr_min_io_rq in the same path group f o r the bio−based i s used f o r : 1000 # # name # scope # desc # # # # # d e f a u l t # rr_min_io 100 # # name # scope # desc # # # # d e f a u l t # rr_min_io_rq 1 : 1 rr_min_io_rq : : multipath & multipathd : io to route to a path before switching the number of to the next multipath implementation . this parameter k e r n e l s v e r s i o n s in the same path group f o r than 2 . 6 . 3 1 . l a t e r the request−based i s used f o r flush_on_last_del : : multipathd : # # name # scope # desc # # values # d e f a u l t # flush_on_last_del yes : yes | no : no s e t i f l a s t path to a device has been deleted . to ” yes ” , multipathd w i l l d i s a b l e queueing when the # # name # scope # desc : max_fds : multipathd : sets the maximum number of open f i l e d e s c r i p t o r s f o r the 38

multipathd process . : max | n > 0 : none # # values # d e f a u l t # max_fds 8192 # # name # scope # desc # # values # d e f a u l t # rr_weight p r i o r i t i e s s e t rr_weight : : multipath & multipathd : to p r i o r i t i e s : p r i o r i t i e s | uniform : uniform i f path weights as ” path prio * rr_min_io” the multipath c o n f i g u r a t o r w i l l assign t e l l the daemon to manage path group failback , or not 0 means immediate failback , values >0 means d e f f e r e d f a i l b a c k expressed in seconds . to . : manual | immediate | n > 0 : manual f a i l b a c k : : multipathd : # # name # scope # desc # # # values # d e f a u l t # f a i l b a c k immediate # # name # scope # desc # # # values # d e f a u l t # no_path_retry f a i l : no_path_retry : multipath & multipathd : the number of t e l l ” f a i l ” means immediate f a i l u r e ( no queueing ) , ” queue ” means never stop queueing r e t r i e s u n t i l d i s a b l e queueing , or : queue | f a i l | n (>0) : ( n u l l ) : queue_without_daemon : multipathd : i f devices when i t # # name # scope # desc # # values # d e f a u l t queue_without_daemon no : yes | no : yes s e t i s to ”no ” , multipathd w i l l d i s a b l e queueing f o r a l l shut down . # # name # scope # desc # # # : user_friendly_names : multipath & multipathd : s e t to ” yes ” , using the bindings i f / etc / multipath / bindings unique a l i a s i f to the multipath , to ”no” use the wwid as s e t f i l e to assign a p e r s i s t e n t and in the form of mpath<n>. the a l i a s . in e i t h e r case 39

t h i s be w i l l be overriden by any s p e c i f i c a l i a s e s f i l e . # # # values # d e f a u l t user_friendly_names yes : yes | no : no in t h i s # # name # scope # desc # values # d e f a u l t mode 0644 # # name # scope # desc # # values # d e f a u l t uid 0 # # name # scope # desc # # values # d e f a u l t gid disk : mode : multipath & multipathd : the mode to use f o r : 0000− 0777 : determined by the process the multipath device nodes , in o c t a l . : uid : multipath & multipathd : the user id to use f o r : <user_id> : determined by the process may use e i t h e r the numeric or symbolic uid the multipath device nodes . you : gid : multipath & multipathd : the group id to user : <group_id> : determined by the process may use e i t h e r the numeric or symbolic gid f o r the multipath device nodes . you : checker_timeout : multipath & multipathd : the timeout i s s u e # # name # scope # desc # # # values # d e f a u l t checker_timeout 60 : n > 0 : that seconds . to use f o r path checkers and p r i o r i t i z e r s s c s i commands with an e x p l i c i t in timeout , taken from / sys / block /sd<x>/device / timeout # # name # scope # desc # # # values # d e f a u l t fast_io_fail_tmo 5 fast_io_fail_tmo : : multipath & multipathd : the number of seconds the s c s i l a y e r w i l l wait a f t e r a problem has been detected on a fc remote port before io to devices on that : o f f | n >= 0 ( smaller : determined by the os remote port . than dev_loss_tmo ) f a i l i n g # # name : dev_loss_tmo 40

# scope # desc # # # values # d e f a u l t dev_loss_tmo 120 : multipath & multipathd seconds : the number of the s c s i l a y e r w i l l wait a f t e r a problem has been detected on a fc remote port before removing i t i n f i n i t y | n > 0 from the system . : : determined by the os : b i n d i n g s _ f i l e : multipath : the l o c a t i o n of # # name # scope # desc # : <full_pathname> # values # d e f a u l t : ”/ var / l i b / multipath / bindings ” # b i n d i n g s _ f i l e ”/ etc / multipath / bindings ” the user_friendly_names option . the bindings f i l e that i s used with : wwids_file : multipath : the l o c a t i o n of # # name # scope # desc # # values # d e f a u l t # wwids_file ”/ etc / multipath /wwids” : <full_pathname> : ”/ var / l i b / multipath /wwids” keep track of the wwids f i l e multipath uses the created multipath devices . to reservation_key # # name # scope # desc # values # d e f a u l t # reservation_key ”mpathkey” : : multipath : service action r e s e r v a t i o n key used by mpathpersist . : <key> : ( n u l l ) : force_sync : multipathd : # # name # scope # desc # : yes | no # values # d e f a u l t : no force_sync yes s e t i f sync mode , even i f to yes , multipath w i l l the checker has an async mode . run a l l of the checkers in # # name # scope # desc # # # # values # d e f a u l t # config_dir : : multipath & multipathd : s e t i f not t h i s d i r e c t o r y a l p h a b e t i c a l l y f o r and i t w i l l f i l e s , j u s t as i f : ”” or a f u l l y q u a l i f i e d pathname : ”/ etc / multipath / conf . d” to an empty string , multipath w i l l search f i l e s ending in ” . conf ” read c o n f i g u r a t i o n information from these i t was in / etc / multipath . conf 41

: delay_watch_checks : multipathd : to a value g r e a t e r that have r e c e n t l y become v a l i d f o r i f s e t paths checks . when they next become valid , they have stayed up f o r delay_wait_checks checks . they f a i l again while they are being watched , they w i l l not be used u n t i l than 0 , multipathd w i l l watch t h i s many i f : delay_wait_checks : multipathd : i f to a value g r e a t e r r e c e n t l y come back o nline delay_watch_checks checks , online , i t has passed delay_wait_checks checks . time i t comes back i t w i l l marked and delayed , and not used u n t i l than 0 , when a device that has f a i l s again within the next # name # scope # desc # # # # # values # d e f a u l t delay_watch_checks 12 : no|<n> > 0 : no s e t # # name # scope # desc # # # # # values # d e f a u l t delay_wait_checks 12 : no|<n> > 0 : no • example of a multipaths section. > note: you can obtain the wwids for your luns executing: > > $ multipath -ll > > after the service multipath-tools.service has been restarted. } multipaths { multipath { } multipath { } multipath { } multipath { } multipath { } } wwid 360000000000000000 e00000000030001 a l i a s yellow wwid 360000000000000000 e00000000020001 a l i a s blue wwid 360000000000000000 e00000000010001 a l i a s red wwid 360000000000000000 e00000000040001 a l i a s green wwid 360000000000000000 e00000000050001 a l i a s purple • small example of a devices section: # devices { # # device { vendor ”ibm” 42

product ”2107900” path_grouping_policy group_by_serial # # # # } # } • example of a blacklist section: l i s t of device names to discard as not multipath candidates : sr , scd , fd , hd , md, dm, t h e i r vender and product : b l a c k l i s t : multipath & multipathd : # name # scope # desc # # devices can be i d e n t i f i e d by t h e i r device node name ”devnode ” , # t h e i r wwid ”wwid” , or s t r i n g s ” device ” # d e f a u l t loop , dcssblk # # b l a c k l i s t { # # # # # # # # # } devnode ”^(ram | raw | loop | fd |md|dm−| sr | scd | st ) [0−9]\*” devnode ”^hd [ a−z ] ” devnode ”^ dcssblk [0−9]\*” vendor dec.\* product msa[ 1 5 ] 0 0 wwid 26353900 f02796769 st , ram , raw , device { } • example of a blacklist exception section: i s not p o s s i b l e to b l a c k l i s t devices using the devnode keyword l i s t of device names to be treated as multipath candidates even i f they are on the b l a c k l i s t . exceptions are only v a l i d in the same c l a s s . : b l a c k l i s t _ e x c e p t i o n s : multipath & multipathd : # name # scope # desc # # # note : b l a c k l i s t # i t # and to exclude some devices of them using the wwid keyword . # d e f a u l t # # b l a c k l i s t _ e x c e p t i o n s { # # # # # } :− devnode ”^dasd [ c−d]+[0−9]\*” ”ibm.75000000092461.4 d00 .34” ”ibm.75000000092461.4 d00 .35” ”ibm.75000000092461.4 d00 .36” wwid wwid wwid device mapper multipathing - usage & debug device mapper multipath will be referred here as multipath only. before moving on with this session it is recommended that you read: 1. device mapper mul- tipathing - introduction 2. device mapper multipathing - configuration 3. device mapper multipathing - setup 43

this section provides step-by-step example procedures for configuring multipath. it includes the following procedures: • resizing online multipath devices • moving root file system from a single path device to a multipath device • the multipath daemon • issues with queue_if_no_path • multipath command output • multipath queries with multipath command • determining device mapper entries with dmsetup command • troubleshooting with the multipathd interactive console resizing online multipath devices | first find all the paths to the lun about to be resized: s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw $ sudo multipath− l l mpathb (360014056 eee8ec6e1164fcb959086482 ) dm−0 lio−org, lun01 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=a c t i v e ‘− 7 : 0 : 0 : 1 sde 8:64 a c t i v e ready running ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=enabled ‘− 8 : 0 : 0 : 1 sdf 8:80 a c t i v e ready running mpatha (36001405 e3c2841430ee4bf3871b1998b ) dm−1 lio−org, lun02 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=a c t i v e ‘− 7 : 0 : 0 : 2 sdc 8:32 a c t i v e ready running ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=enabled ‘− 8 : 0 : 0 : 2 sdd 8:48 a c t i v e ready running s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw | now i’ll reconfigure mpathb (with wwid = 360014056eee8ec6e1164fcb959086482) to have 2gb instead of just 1gb and check if has changed: $ echo 1 | 1 $ echo 1 | 1 sudo tee / sys / block / sdf / device / rescan sudo tee / sys / block / sde / device / rescan | s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw $ sudo multipath− l l mpathb (360014056 eee8ec6e1164fcb959086482 ) dm−0 lio−org, lun01 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=a c t i v e ‘− 7 : 0 : 0 : 1 sde 8:64 a c t i v e ready running ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=enabled ‘− 8 : 0 : 0 : 1 sdf 8:80 a c t i v e ready running mpatha (36001405 e3c2841430ee4bf3871b1998b ) dm−1 lio−org, lun02 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=a c t i v e ‘− 7 : 0 : 0 : 2 sdc 8:32 a c t i v e ready running ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=enabled ‘− 8 : 0 : 0 : 2 sdd 8:48 a c t i v e ready running s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw | 44

not yet! we still need to re-scan the multipath map: $ sudo multipathd r e s i z e map mpathb ok and then we are good: s i z e =2.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw $ sudo multipath− l l mpathb (360014056 eee8ec6e1164fcb959086482 ) dm−0 lio−org, lun01 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=a c t i v e ‘− 7 : 0 : 0 : 1 sde 8:64 a c t i v e ready running .‘−+− p o l i c y =’ s e r v ic e−time 0 ’ prio=50 status=enabled ‘− 8 : 0 : 0 : 1 sdf 8:80 a c t i v e ready running mpatha (36001405 e3c2841430ee4bf3871b1998b ) dm−1 lio−org, lun02 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=a c t i v e ‘− 7 : 0 : 0 : 2 sdc 8:32 a c t i v e ready running ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=50 status=enabled ‘− 8 : 0 : 0 : 2 sdd 8:48 a c t i v e ready running make sure to run resize2fs /dev/mapper/mpathb to resize the filesystem. s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw | | moving root file system from a single path device to a multipath device this is dramatically simplified by the use of uuids to identify devices as an intrinsic label. simply install multipath-tools-boot and reboot. this will rebuild the initial ramdisk and afford multipath the opportunity to build it’s paths before the root filesystem is mounted by uuid. note whenever multipath.conf is updated, so should the initrd by executing: update−initramfs−u−k all the reason behind is multipath.conf is copied to the ramdisk and is integral to determining the available devices to map via it’s blacklist and devices sections. the multipath daemon if you find you have trouble implementing a multipath configuration, you should ensure the multipath daemon is running as described in device mapper multipathing - setup. the multipathd daemon must be running in order to use** multipath** devices. multipath command output alias (wwid_if_different_from_alias) dm_device_name_if_known vendor,product when you create, modify, or list a multipath device, you get a printout of the current device setup. the for- mat is as follows. for each multipath device: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ action_if_any: size=size features=‘features’ hwhandler=‘hardware_handler’ wp=write_permission_if_known ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ for each path group: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -+- policy=‘scheduling_policy’ prio=prio_if_known status=path_group_status_if_known ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ for each path: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ − host:channel:id:lun devnode major:minor dm_status_if_known path_status online_status ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ mpathb (360014056eee8ec6e1164fcb959086482)dm−0 lio−org,lun01 size=2.0g features=’0’ hwhandler =’1 alua’ wp=rw |−+− policy=’service−time 0’ prio=50 status=active |- 7:0:0:1 sde 8:64 active ready for example, the output of a multipath command might appear as follows: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 45

running −+− policy=’service−time 0’ prio=50 status=enabled- 8:0:0:1 sdf 8:80 active ready running ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ if the path is up and ready for i/o, the status of the path is ready or ghost. if the path is down, the status is faulty or shaky. the path status is updated periodically by the multipathd daemon based on the polling interval defined in the /etc/multipath.conf file. the dm_status is similar to the path status, but from the kernel’s point of view. the dm_status has two states: failed, which is analogous to faulty, and active, which covers all other path states. occasionally, the path state and the dm state of a device will temporary not agree. the possible values for online_status are running and offline. a status of offline means that the scsi device has been disabled. multipath queries with multipath command you can use the -l and -ll options of the multipath command to display the current multipath configuration. the -l option displays multipath topology gathered from information in sysfs and the device mapper. the -ll option displays the information the -l displays in addition to all other available components of the system. when displaying the multipath configuration, there are three verbosity levels you can specify with the -v option of the multipath command. specifying -v0 yields no output. specifying-v1 outputs the created or updated multipath names only, which you can then feed to other tools such as kpartx. specifying -v2 prints all detected paths, multipaths, and device maps. note the default verbosity level of multipath is 2 and can be globally modified by defining the verbosity attribute in the defaults section of multipath.conf. s i z e =2.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw the following example shows the output of a multipath -l command. $ sudo multipath−l mpathb (360014056 eee8ec6e1164fcb959086482 ) dm−0 lio−org, lun01 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=0 status=a c t i v e ‘− 7 : 0 : 0 : 1 sde 8:64 a c t i v e undef ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=0 status=enabled ‘− 8 : 0 : 0 : 1 sdf 8:80 a c t i v e undef mpatha (36001405 e3c2841430ee4bf3871b1998b ) dm−1 lio−org, lun02 |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=0 status=a c t i v e ‘− 7 : 0 : 0 : 2 sdc 8:32 a c t i v e undef ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=0 status=enabled ‘− 8 : 0 : 0 : 2 sdd 8:48 a c t i v e undef s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler=’1 alua ’ wp=rw determining device mapper entries with dmsetup command running running running running | | you can use the dmsetup command to find out which device mapper entries match the multipathed devices. the following command displays all the device mapper devices and their major and minor numbers. the minor numbers determine the name of the dm device. for example, a minor number of 1 corresponds to the multipathd device /dev/dm-1. $ sudo dmsetup l s mpathb mpatha ( 2 5 3 : 0 ) ( 2 5 3 : 1 ) $ l s−lahd /dev/dm* 46

brw−rw−−−− 1 root disk 253 , 0 apr 27 14:49 /dev/dm−0 brw−rw−−−− 1 root disk 253 , 1 apr 27 14:47 /dev/dm−1 troubleshooting with the multipathd interactive console the multipathd -k command is an interactive interface to the multipathd daemon. entering this command brings up an interactive multipath console. after entering this command, you can enter help to get a list of available commands, you can enter a interactive command, or you can enter ctrl-d to quit. the multipathd interactive console can be used to troubleshoot problems you may be having with your system. for example, the following command sequence displays the multipath configuration, including the defaults, before exiting the console. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ sudo multipathd -k > show config > ctrl-d ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ the following command sequence ensures that multipath has picked up any changes to the multipath.conf, ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ sudo multipathd -k > reconfigure > ctrl-d ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ use the following command sequence to ensure that the path checker is working properly. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ sudo multipathd -k > show paths > ctrl-d ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ commands can also be streamed into multipathd using stdin like so: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ $ echo ‘show config’ | sudo multipathd -k ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ networking networks consist of two or more devices, such as computer systems, printers, and related equipment which are connected by either physical cabling or wireless links for the purpose of sharing and distributing information among the connected devices. this section provides general and specific information pertaining to networking, including an overview of network concepts and detailed discussion of popular network protocols. tcp/ip the transmission control protocol and internet protocol (tcp/ip) is a standard set of protocols developed in the late 1970s by the defense advanced research projects agency (darpa) as a means of communication between different types of computers and computer networks. tcp/ip is the driving force of the internet, and thus it is the most popular set of network protocols on earth. tcp/ip introduction the two protocol components of tcp/ip deal with different aspects of computer networking. internet protocol, the “ip” of tcp/ip is a connectionless protocol which deals only with network packet routing using the ip datagram as the basic unit of networking information. the ip datagram consists of a header followed by a message. the transmission control protocol is the “tcp” of tcp/ip and enables network hosts to establish connections which may be used to exchange data streams. tcp also guarantees that the data between connections is delivered and that it arrives at one network host in the same order as sent from another network host. 47

tcp/ip configuration the tcp/ip protocol configuration consists of several elements which must be set by editing the appropriate configuration files, or deploying solutions such as the dynamic host configuration protocol (dhcp) server which in turn, can be configured to provide the proper tcp/ip configuration settings to network clients automatically. these configuration values must be set correctly in order to facilitate the proper network operation of your ubuntu system. the common configuration elements of tcp/ip and their purposes are as follows: • ip address the ip address is a unique identifying string expressed as four decimal numbers ranging from zero (0) to two-hundred and fifty-five (255), separated by periods, with each of the four numbers representing eight (8) bits of the address for a total length of thirty-two (32) bits for the whole address. this format is called dotted quad notation. • netmask the subnet mask (or simply, netmask) is a local bit mask, or set of flags which separate the portions of an ip address significant to the network from the bits significant to the subnetwork. for example, in a class c network, the standard netmask is 255.255.255.0 which masks the first three bytes of the ip address and allows the last byte of the ip address to remain available for specifying hosts on the subnetwork. • network address the network address represents the bytes comprising the network portion of an ip address. for example, the host 12.128.1.2 in a class a network would use 12.0.0.0 as the network address, where twelve (12) represents the first byte of the ip address, (the network part) and zeroes (0) in all of the remaining three bytes to represent the potential host values. a network host using the private ip address 192.168.1.100 would in turn use a network address of 192.168.1.0, which specifies the first three bytes of the class c 192.168.1 network and a zero (0) for all the possible hosts on the network. • broadcast address the broadcast address is an ip address which allows network data to be sent simultaneously to all hosts on a given subnetwork rather than specifying a particular host. the standard general broadcast address for ip networks is 255.255.255.255, but this broadcast address cannot be used to send a broadcast message to every host on the internet because routers block it. a more appropriate broadcast address is set to match a specific subnetwork. for example, on the private class c ip network, 192.168.1.0, the broadcast address is 192.168.1.255. broadcast messages are typically produced by network protocols such as the address resolution protocol (arp) and the routing information protocol (rip). • gateway address a gateway address is the ip address through which a particular network, or host on a network, may be reached. if one network host wishes to communicate with another network host, and that host is not located on the same network, then a gateway must be used. in many cases, the gateway address will be that of a router on the same network, which will in turn pass traffic on to other networks or hosts, such as internet hosts. the value of the gateway address setting must be correct, or your system will not be able to reach any hosts beyond those on the same network. • nameserver address nameserver addresses represent the ip addresses of domain name service (dns) systems, which resolve network hostnames into ip addresses. there are three levels of name- server addresses, which may be specified in order of precedence: the primary nameserver, the sec- ondary nameserver, and the tertiary nameserver. in order for your system to be able to resolve network hostnames into their corresponding ip addresses, you must specify valid nameserver addresses which you are authorized to use in your system’s tcp/ip configuration. in many cases these addresses can and will be provided by your network service provider, but many free and publicly accessible name- servers are available for use, such as the level3 (verizon) servers with ip addresses from 4.2.2.1 to 4.2.2.6. tip the ip address, netmask, network address, broadcast address, gateway address, and 48

nameserver addresses are typically specified via the appropriate directives in the file /etc/ network/interfaces. for more information, view the system manual page for interfaces , with the following command typed at a terminal prompt: access the system manual page for interfaces with the following command: man i n t e r f a c e s ip routing ip routing is a means of specifying and discovering paths in a tcp/ip network along which network data may be sent. routing uses a set of routing tables to direct the forwarding of network data packets from their source to the destination, often via many intermediary network nodes known as routers. there are two primary forms of ip routing: static routing and dynamic routing. static routing involves manually adding ip routes to the system’s routing table, and this is usually done by manipulating the routing table with the route command. static routing enjoys many advantages over dynamic routing, such as simplicity of implementation on smaller networks, predictability (the routing table is always computed in advance, and thus the route is precisely the same each time it is used), and low overhead on other routers and network links due to the lack of a dynamic routing protocol. however, static routing does present some disadvantages as well. for example, static routing is limited to small networks and does not scale well. static routing also fails completely to adapt to network outages and failures along the route due to the fixed nature of the route. dynamic routing depends on large networks with multiple possible ip routes from a source to a destination and makes use of special routing protocols, such as the router information protocol (rip), which handle the automatic adjustments in routing tables that make dynamic routing possible. dynamic routing has several advantages over static routing, such as superior scalability and the ability to adapt to failures and outages along network routes. additionally, there is less manual configuration of the routing tables, since routers learn from one another about their existence and available routes. this trait also eliminates the possibility of introducing mistakes in the routing tables via human error. dynamic routing is not perfect, however, and presents disadvantages such as heightened complexity and additional network overhead from router communications, which does not immediately benefit the end users, but still consumes network bandwidth. tcp and udp tcp is a connection-based protocol, offering error correction and guaranteed delivery of data via what is known as flow control. flow control determines when the flow of a data stream needs to be stopped, and previously sent data packets should to be re-sent due to problems such as collisions, for example, thus ensuring complete and accurate delivery of the data. tcp is typically used in the exchange of important information such as database transactions. the user datagram protocol (udp), on the other hand, is a connectionless protocol which seldom deals with the transmission of important data because it lacks flow control or any other method to ensure reliable delivery of the data. udp is commonly used in such applications as audio and video streaming, where it is considerably faster than tcp due to the lack of error correction and flow control, and where the loss of a few packets is not generally catastrophic. icmp the internet control messaging protocol (icmp) is an extension to the internet protocol (ip) as defined in the request for comments (rfc) #792 and supports network packets containing control, error, and informational messages. icmp is used by such network applications as the ping utility, which can determine 49

the availability of a network host or device. examples of some error messages returned by icmp which are useful to both network hosts and devices such as routers, include destination unreachable and time exceeded. daemons daemons are special system applications which typically execute continuously in the background and await requests for the functions they provide from other applications. many daemons are network-centric; that is, a large number of daemons executing in the background on an ubuntu system may provide network-related functionality. some examples of such network daemons include the hyper text transport protocol daemon (httpd), which provides web server functionality; the secure shell daemon (sshd), which provides secure remote login shell and file transfer capabilities; and the internet message access protocol daemon (imapd), which provides e-mail services. resources • there are man pages for tcp and ip that contain more useful information. • also, see the tcp/ip tutorial and technical overview ibm redbook. • another resource is o’reilly’s tcp/ip network administration. network configuration ubuntu ships with a number of graphical utilities to configure your network devices. this document is geared toward server administrators and will focus on managing your network on the command line. ethernet interfaces ethernet interfaces are identified by the system using predictable network interface names. these names can appear as eno1 or enp0s25. however, in some cases an interface may still use the kernel eth# style of naming. identify ethernet interfaces to quickly identify all available ethernet interfaces, you can use the ip command as shown below. ip a 1: lo : <loopback,up,lower_up> mtu 65536 qdisc noqueue s t a t e unknown group d e f a u l t qlen 1000 l i n k / loopback 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 brd 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 i n e t 1 2 7 . 0 . 0 . 1 / 8 scope host lo v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t f o r e v e r inet6 : : 1 / 1 2 8 scope host v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t f o r e v e r 2: enp0s25 : <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue s t a t e up group d e f a u l t qlen 1000 l i n k / ether 0 0 : 1 6 : 3 e : e2 : 5 2 : 4 2 brd f f : f f : f f : f f : f f : f f i n e t 10.102.66.200/24 brd 10.102.66.255 scope g lobal dynamic eth0 link−netnsid 0 v a l i d _ l f t 3257 sec p r e f e r r e d _ l f t 3257 sec inet6 fe80 : : 2 1 6 : 3 e f f : f ee2 :5242/64 scope l i n k 50

v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t f o r e v e r another application that can help identify all network interfaces available to your system is the lshw command. this command provides greater details around the hardware capabilities of specific adapters. in the example below, lshw shows a single ethernet interface with the logical name of eth0 along with bus information, driver details and all supported capabilities. sudo lshw−c l a s s network *−network i n t e r f a c e d e s c r i p t i o n : ethernet product : mt26448 [ connectx en 10gige , pcie 2.0 5gt/ s ] vendor : mellanox technologies physical bus l o g i c a l name : eth4 version : b0 s e r i a l : e4 :1 d :2 d : 6 7 : 8 3 : 5 6 i n f o : pci@0004 : 0 1 : 0 0 . 0 id : 0 s i z e : 10 gbit/ s capacity : 10 gbit/ s width : 64 b i t s clock : 33mhz c a p a b i l i t i e s : pm vpd msix p c i e x p r e s s bus_master cap_list ethernet s l o t : u78cb. 0 0 1 .wzs09kb−p1−c6−t1 f i b r e 10000 bt−fd d r i v e r v e r s i o n =4.0−0 duplex=f u l l iomemory:24000−23 f f f f e 2 0 0 0 f f f f f memory:240000000000−240007 f f f f f f i r q :481 memory :3 fe200000000−3 c o n f i g u r a t i o n : autonegotiation=o f f broadcast=yes d r i v e r=mlx4_en latency=0 l i n k=yes multicast=yes port=f i b r e speed=10gbit/ s r e s o u r c e s : physical firmware =2.9.1326 ip =192.168.1.1 ethernet interface logical names interface logical names can also be configured via a netplan configuration. if you would like control which interface receives a particular logical name use the match and set-name keys. the match key is used to find an adapter based on some criteria like mac address, driver, etc. then the set-name key can be used to change the device to the desired logial name. network : version : 2 renderer : networkd ethernets : eth_lan0 : dhcp4 : match : true set−name : eth_lan0 ethernet interface settings macaddress : 0 0 : 1 1 : 2 2 : 3 3 : 4 4 : 5 5 ethtool is a program that displays and changes ethernet card settings such as auto-negotiation, port speed, duplex mode, and wake-on-lan. the following is an example of how to view supported features and con- figured settings of an ethernet interface. 51

[ fibre ] 10000 baset/ full 10000 baset/ full sudo e t h t o o l eth4 f o r eth4 : s e t t i n g s supported ports : supported l i n k modes : supported pause frame use : no supported fec modes : not reported advertised l i n k modes : advertised pause frame use : no supports auto−n e g o t i a t i o n : no advertised auto−n e g o t i a t i o n : no auto−n e g o t i a t i o n : o f f supports wake−on : d wake−on : d advertised fec modes : not reported speed : 10000mb/ s duplex : full port : fibre phyad: 0 transceiver : l i n k ifdown i n t e r n a l link detected : yes current message l e v e l : 0x00000014 (20) ip addressing the following section describes the process of configuring your systems ip address and default gateway needed for communicating on a local area network and the internet. temporary ip address assignment for temporary network configurations, you can use the ip command which is also found on most other gnu/linux operating systems. the ip command allows you to configure settings which take effect immedi- ately, however they are not persistent and will be lost after a reboot. to temporarily configure an ip address, you can use the ip command in the following manner. modify the ip address and subnet mask to match your network requirements. sudo ip addr add 10.102.66.200/24 dev enp0s25 the ip can then be used to set the link up or down. ip l i n k s e t dev enp0s25 up ip l i n k s e t dev enp0s25 down to verify the ip address configuration of enp0s25, you can use the ip command in the following manner. ip address show dev enp0s25 10: enp0s25 : <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue s t a t e up group d e f a u l t qlen 1000 l i n k / ether 0 0 : 1 6 : 3 e : e2 : 5 2 : 4 2 brd f f : f f : f f : f f : f f : f f i n e t 10.102.66.200/24 brd 10.102.66.255 scope g lobal dynamic eth0 link−netnsid 0 v a l i d _ l f t 2857 sec p r e f e r r e d _ l f t 2857 sec inet6 fe80 : : 2 1 6 : 3 e f f : f ee2 :5242/64 scope l i n k f o r e v e r 6 f o r e v e r p r e f e r r e d _ l f t v a l i d _ l f t 52

to configure a default gateway, you can use the ip command in the following manner. modify the default gateway address to match your network requirements. sudo ip route add d e f a u l t via 1 0 . 1 0 2 . 6 6 . 1 to verify your default gateway configuration, you can use the ip command in the following manner. ip route show d e f a u l t via 1 0 . 1 0 2 . 6 6 . 1 dev eth0 proto dhcp s r c 10.102.66.200 metric 100 10.102.66.0/24 dev eth0 proto kernel 1 0 . 1 0 2 . 6 6 . 1 dev eth0 proto dhcp scope l i n k s r c 10.102.66.200 metric 100 scope l i n k s r c 10.102.66.200 if you require dns for your temporary network configuration, you can add dns server ip addresses in the file /etc/resolv .conf. in general, editing /etc/resolv .conf directly is not recommanded, but this is a temporary and non-persistent configuration. the example below shows how to enter two dns servers to /etc/resolv . conf, which should be changed to servers appropriate for your network. a more lengthy description of the proper persistent way to do dns client configuration is in a following section. nameserver 8 . 8 . 8 . 8 nameserver 8 . 8 . 4 . 4 if you no longer need this configuration and wish to purge all ip configuration from an interface, you can use the ip command with the flush option as shown below. ip addr f l u s h eth0 note flushing the ip configuration using the ip command does not clear the contents of /etc/resolv .conf. you must remove or modify those entries manually, or re-boot which should also cause /etc/resolv .conf, which is a symlink to /run/systemd/resolve/stub−resolv.conf, to be re-written. dynamic ip address assignment (dhcp client) to configure your server to use dhcp for dynamic address assignment, create a netplan configuration in the file /etc/netplan/99_config.yaml. the example below assumes you are configuring your first ethernet interface identified as enp3s0. network : version : 2 renderer : networkd ethernets : enp3s0 : dhcp4 : true the configuration can then be applied using the netplan command. sudo netplan apply static ip address assignment to configure your system to use static address assignment, create a netplan configuration in the file /etc /netplan/99_config.yaml. the example below assumes you are configuring your first ethernet interface identified as eth0. change the addresses, gateway4, and nameservers values to meet the requirements of your network. 53

network : version : 2 renderer : networkd ethernets : eth0 : addresses : − 10.10.10.2/24 gateway4 : 1 0 . 1 0 . 1 0 . 1 nameservers : search : addresses : [ mydomain , otherdomain ] [ 1 0 . 1 0 . 1 0 . 1 , 1 . 1 . 1 . 1 ] the configuration can then be applied using the netplan command. sudo netplan apply loopback interface the loopback interface is identified by the system as lo and has a default ip address of 127.0.0.1. it can be viewed using the ip command. ip address show lo 1: lo : <loopback,up,lower_up> mtu 65536 qdisc noqueue s t a t e unknown group d e f a u l t qlen 1000 l i n k / loopback 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 brd 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 i n e t 1 2 7 . 0 . 0 . 1 / 8 scope host lo v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t f o r e v e r inet6 : : 1 / 1 2 8 scope host v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t f o r e v e r name resolution name resolution as it relates to ip networking is the process of mapping ip addresses to hostnames, making it easier to identify resources on a network. the following section will explain how to properly configure your system for name resolution using dns and static hostname records. dns client configuration traditionally, the file /etc/resolv .conf was a static configuration file that rarely needed to be changed or automatically changed via dchp client hooks. systemd-resolved handles name server configuration, and it should be interacted with through the systemd−resolve command. netplan configures systemd-resolved to / etc / r e s o l v . conf−> . . / run/systemd/ r e s o l v e /stub−r e s o l v . conf to configure the resolver, add the ip addresses of the nameservers that are appropriate for your network to the netplan configuration file. you can also add an optional dns suffix search-lists to match your network domain names. the resulting file might look like the following: network : generate a list of nameservers and domains to put in /etc/resolv .conf, which is a symlink: version : 2 renderer : networkd ethernets : enp0s25 : addresses : 54

− 192.168.0.100/24 gateway4 : 1 9 2 . 1 6 8 . 0 . 1 nameservers : search : addresses : [ mydomain , otherdomain ] [ 1 . 1 . 1 . 1 , 8 . 8 . 8 . 8 , 4 . 4 . 4 . 4 ] the search option can also be used with multiple domain names so that dns queries will be appended in the order in which they are entered. for example, your network may have multiple sub-domains to search; a parent domain of example.com, and two sub-domains, sales .example.com and dev.example.com. if you have multiple domains you wish to search, your configuration might look like the following: network : version : 2 renderer : networkd ethernets : enp0s25 : addresses : − 192.168.0.100/24 gateway4 : 1 9 2 . 1 6 8 . 0 . 1 nameservers : search : addresses : [ example . com , s a l e s . example . com , dev . example . com ] [ 1 . 1 . 1 . 1 , 8 . 8 . 8 . 8 , 4 . 4 . 4 . 4 ] if you try to ping a host with the name of server1, your system will automatically query dns for its fully qualified domain name (fqdn) in the following order: 1. server1.example.com 2. server1. sales .example.com 3. server1.dev.example.com if no matches are found, the dns server will provide a result of notfound and the dns query will fail. static hostnames static hostnames are locally defined hostname-to-ip mappings located in the file /etc/hosts. entries in the hosts file will have precedence over dns by default. this means that if your system tries to resolve a hostname and it matches an entry in /etc/hosts, it will not attempt to look up the record in dns. in some configurations, especially when internet access is not required, servers that communicate with a limited number of resources can be conveniently set to use static hostnames instead of dns. the following is an example of a hosts file where a number of local servers have been identified by simple hostnames, aliases and their equivalent fully qualified domain names (fqdn’s). 1 2 7 . 0 . 0 . 1 1 2 7 . 0 . 1 . 1 1 0 . 0 . 0 . 1 1 1 0 . 0 . 0 . 1 2 1 0 . 0 . 0 . 1 3 1 0 . 0 . 0 . 1 4 server1 server1 . example . com vpn server2 server2 . example . com mail server3 server3 . example . com www server4 server4 . example . com f i l e ubuntu−s e r v e r l o c a l h o s t note in the above example, notice that each of the servers have been given aliases in addition to their proper names and fqdn’s. server1 has been mapped to the name vpn, server2 is referred to as mail, server3 as www, and server4 as file. 55

name service switch configuration the order in which your system selects a method of resolving hostnames to ip addresses is controlled by the name service switch (nss) configuration file /etc/nsswitch.conf. as mentioned in the previous section, typically static hostnames defined in the systems /etc/hosts file have precedence over names resolved from dns. the following is an example of the line responsible for this order of hostname lookups in the file /etc/nsswitch.conf. hosts : [notfound=return ] dns mdns4 f i l e s mdns4_minimal • files first tries to resolve static hostnames located in /etc/hosts. • mdns4_minimal attempts to resolve the name using multicast dns. • [notfound=return] means that any response of notfound by the preceding mdns4_minimal process should be treated as authoritative and that the system should not try to continue hunting for an answer. • dns represents a legacy unicast dns query. • mdns4 represents a multicast dns query. to modify the order of the above mentioned name resolution methods, you can simply change the hosts: string to the value of your choosing. for example, if you prefer to use legacy unicast dns versus multicast dns, you can change the string in /etc/nsswitch.conf as shown below. hosts : [notfound=return ] mdns4_minimal mdns4 f i l e s dns bridging bridging multiple interfaces is a more advanced configuration, but is very useful in multiple scenarios. one scenario is setting up a bridge with multiple network interfaces, then using a firewall to filter traffic between two network segments. another scenario is using bridge on a system with one interface to allow virtual machines direct access to the outside network. the following example covers the latter scenario. configure the bridge by editing your netplan configuration found in /etc/netplan/: network : version : 2 renderer : networkd ethernets : enp3s0 : dhcp4 : no bridges : br0 : dhcp4 : yes i n t e r f a c e s : − enp3s0 note enter the appropriate values for your physical interface and network. now apply the configuration to enable the bridge: sudo netplan apply the new bridge interface should now be up and running. the brctl provides useful information about the state of the bridge, controls which interfaces are part of the bridge, etc. see man brctl for more information. 56

resources • the ubuntu wiki network page has links to articles covering more advanced network configuration. • the netplan website has additional examples and documentation. • the netplan man page has more information on netplan. • the systemd-resolve man page has details on systemd-resolve command. • the systemd-resolved man page has more information on systemd-resolved service. • for more information on bridging see the netplan.io examples page and the linux foundation’s networking-bridge page. dynamic host configuration protocol (dhcp) the dynamic host configuration protocol (dhcp) is a network service that enables host computers to be automatically assigned settings from a server as opposed to manually configuring each network host. computers configured to be dhcp clients have no control over the settings they receive from the dhcp server, and the configuration is transparent to the computer’s user. the most common settings provided by a dhcp server to dhcp clients include: • ip address and netmask • ip address of the default-gateway to use • ip adresses of the dns servers to use however, a dhcp server can also supply configuration properties such as: • host name • domain name • time server • print server the advantage of using dhcp is that changes to the network, for example a change in the address of the dns server, need only be changed at the dhcp server, and all network hosts will be reconfigured the next time their dhcp clients poll the dhcp server. as an added advantage, it is also easier to integrate new computers into the network, as there is no need to check for the availability of an ip address. conflicts in ip address allocation are also reduced. a dhcp server can provide configuration settings using the following methods: • manual allocation (mac address) this method entails using dhcp to identify the unique hardware address of each network card con- nected to the network and then continually supplying a constant configuration each time the dhcp client makes a request to the dhcp server using that network device. this ensures that a particular address is assigned automatically to that network card, based on it’s mac address. • dynamic allocation (address pool) in this method, the dhcp server will assign an ip address from a pool of addresses (sometimes also called a range or scope) for a period of time or lease, that is configured on the server or until the client informs the server that it doesn’t need the address anymore. this way, the clients will be receiving their configuration properties dynamically and on a “first come, first served” basis. when a dhcp client is no longer on the network for a specified period, the configuration is expired and released back to the address pool for use by other dhcp clients. this way, an address can be leased or used for a 57

period of time. after this period, the client has to renegociate the lease with the server to maintain use of the address. • automatic allocation using this method, the dhcp automatically assigns an ip address permanently to a device, selecting it from a pool of available addresses. usually dhcp is used to assign a temporary address to a client, but a dhcp server can allow an infinite lease time. the last two methods can be considered “automatic” because in each case the dhcp server assigns an address with no extra intervention needed. the only difference between them is in how long the ip address is leased, in other words whether a client’s address varies over time. the dhcp server ubuntu makes available is dhcpd (dynamic host configuration protocol daemon), which is easy to install and configure and will be automatically started at system boot. installation at a terminal prompt, enter the following command to install dhcpd: sudo apt i n s t a l l isc−dhcp−s e r v e r note: dhcpd’s messages are being sent to syslog. look there for diagnostics messages. configuration subnet 1 9 2 . 1 6 8 . 1 . 0 netmask 255.255.255.0 { range 192.168.1.150 1 9 2 . 1 6 8 . 1 . 2 0 0 ; option ro ut e rs 1 9 2 . 1 6 8 . 1 . 2 5 4 ; you will probably need to change the default configuration by editing /etc/dhcp/dhcpd.conf to suit your needs and particular configuration. most commonly, what you want to do is assign an ip address randomly. this can be done with settings as follows: # minimal sample / etc /dhcp/dhcpd . conf default−lease−time 600; max−lease−time 7200; option domain−name−s e r v e r s 1 9 2 . 1 6 8 . 1 . 1 , 1 9 2 . 1 6 8 . 1 . 2 ; option domain−name ”mydomain . example ” ; you also may need to edit /etc/default/isc−dhcp−server to specify the interfaces dhcpd should listen to. this will result in the dhcp server giving clients an ip address from the range 192.168.1.150-192.168.1.200. it will lease an ip address for 600 seconds if the client doesn’t ask for a specific time frame. otherwise the maximum (allowed) lease will be 7200 seconds. the server will also “advise” the client to use 192.168.1.254 as the default-gateway and 192.168.1.1 and 192.168.1.2 as its dns servers. interfacesv4=”eth4 ” } after changing the config files you have to restart the dhcpd service: sudo systemctl r e s t a r t isc−dhcp−s e r v e r . s e r v i c e 58

references • the dhcp3-server ubuntu wiki page has more information. • for more /etc/dhcp/dhcpd.conf options see the dhcpd.conf man page. • isc dhcp-server time synchronization ntp is a tcp/ip protocol for synchronizing time over a network. basically a client requests the current time from a server, and uses it to set its own clock. behind this simple description, there is a lot of complexity - there are tiers of ntp servers, with the tier one ntp servers connected to atomic clocks, and tier two and three servers spreading the load of actually handling requests across the internet. also the client software is a lot more complex than you might think - it has to factor out communication delays, and adjust the time in a way that does not upset all the other processes that run on the server. but luckily all that complexity is hidden from you! ubuntu by default uses timedatectl / timesyncd to synchronize time and users can optionally use chrony to serve the network time protocol. synchronizing your systems time since ubuntu 16.04 timedatectl / timesyncd (which are part of systemd) replace most of ntpdate / ntp. timesyncd is available by default and replaces not only ntpdate, but also the client portion of chrony (or formerly ntpd). so on top of the one-shot action that ntpdate provided on boot and network activation, now timesyncd by default regularly checks and keeps your local time in sync. it also stores time updates locally, so that after reboots monotonically advances if applicable. if chrony is installed timedatectl steps back to let chrony do the time keeping. that shall ensure that no two time syncing services are fighting. while no more recommended to be used, this still also applies to ntpd being installed to retain any kind of old behavior/config that you had through an upgrade. but it also implies that on an upgrade from a former release ntp/ntpdate might still be installed and therefore renders the new systemd based services disabled. ntpdate is considered deprecated in favor of timedatectl (or chrony) and thereby no more installed by default. timesyncd will generally do the right thing keeping your time in sync, and chrony will help with more complex cases. but if you had one of a few known special ntpdate use cases, consider the following: • if you require a one-shot sync use: chronyd−q • if you require a one-shot time check, without setting the time use: chronyd−q configuring timedatectl and timesyncd the current status of time and time configuration via timedatectl and timesyncd can be checked with timedatectl status. $ timedatectl status local universal time : fr 2018−02−23 08:47:13 utc time : fr 2018−02−23 08:47:13 utc rtc time : fr 2018−02−23 08:47:13 time zone : etc/utc (utc, +0000) system clock synchronized : yes 59

rtc in l o c a l tz: no if chrony is running it will automatically switch to: [ . . . ] via timedatectl an admin can control the timezone, how the system clock should relate to the hwclock and if permanent synronization should be enabled or not. see man timedatectl for more details. timesyncd itself is still a normal service, so you can check its status also more in detail via. $ systemctl systemd−timesyncd . s e r v i c e a c t i v e : yes systemd−timesyncd . s e r v i c e a c t i v e : no systemd−timesyncd systemd−timesyncd . s e r v i c e− network time synchronization loaded (/ l i b /systemd/system/systemd−timesyncd . s e r v i c e ; enabled ; s i n c e fri 2018−02−23 08:55:46 utc; 10 s ago docs : man: systemd−timesyncd . s e r v i c e (8) main pid : 3744 ( systemd−timesyn ) cgroup : /system . s l i c e /systemd−timesyncd . s e r v i c e |−3744 / l i b /systemd/systemd−timesyncd feb 23 08:55:46 bionic−t e s t feb 23 08:55:46 bionic−t e s t feb 23 08:55:46 bionic−t e s t status : ” synchronized to time s e r v e r 9 1 . 1 8 9 . 8 9 . 1 9 8 : 1 2 3 ( ntp . ubuntu . com) . ” tasks : 2 ( l i m i t : 4915) systemd [ 1 ] : starting network time synchronization systemd [ 1 ] : started network time synchronization . systemd−timesyncd [ 3 7 4 4 ] : synchronized to time s e r v e r 9 1 . 1 8 9 . 8 9 . 1 9 8 : 1 2 3 ( ntp . ubuntu . com) . the nameserver to fetch time for timedatectl and timesyncd from can be specified in /etc/systemd/timesyncd .conf and additional config files can be stored in /etc/systemd/timesyncd.conf.d/. the entries for ntp= and fallbackntp= are space separated lists. see man timesyncd.conf for more. status loaded : vendor preset : enabled ) active : a c t i v e ( running ) . . . serve the network time protocol if in addition to synchronizing your system you also want to serve ntp information you need an ntp server. there are several options with chrony, ntpd and open-ntp. the recommended solution is chrony. chrony(d) the ntp daemon chronyd calculates the drift and offset of your system clock and continuously adjusts it, so there are no large corrections that could lead to inconsistent logs for instance. the cost is a little processing power and memory, but for a modern server this is usually negligible. installation to install chrony, from a terminal prompt enter: sudo apt i n s t a l l chrony this will provide two binaries: 60

• chronyd - the actual daemon to sync and serve via the ntp protocol • chronyc - command-line interface for chrony daemon chronyd configuration edit /etc/chrony/chrony.conf to add/remove server lines. by default these servers are configured: # use s e r v e r s # on 2011−02−08 (lp: #104525) . see http ://www. pool . ntp . org / j o i n . html from the ntp pool project . approved by ubuntu technical board f o r # more information . pool 0. ubuntu . pool . ntp . org i b u r s t pool 1. ubuntu . pool . ntp . org i b u r s t pool 2. ubuntu . pool . ntp . org i b u r s t pool 3. ubuntu . pool . ntp . org i b u r s t see man chrony.conf for more details on the configuration options. after changing the any of the config file you have to restart chrony: sudo systemctl r e s t a r t chrony . s e r v i c e of the pool 2.ubuntu.pool.ntp.org as well as ntp.ubuntu.com also support ipv6 if needed. if one needs to force ipv6 there also is ipv6.ntp.ubuntu.com which is not configured by default. view status use chronyc to see query the status of the chrony daemon. for example to get an overview of the currently available and selected time sources. chronyc sources ms name/ip address =============================================================================== stratum poll reach lastrx last sample ms ms ms ms ms ^+ www. kashra . com ^+ gamma. rueckgr . at ^− 2b . ncomputers . org ^+ stratum2−4.ntp. techfak .u> ^− zepto . mcl . gg ^− mirrorhost .pw ^− atto . mcl . gg ^− s t a t i c . 1 4 0 . 1 0 7 . 4 6 . 7 8 . c l i > ^− 4 . 5 3 . 1 6 0 . 7 5 ^− 3 7 . 4 4 . 1 8 5 . 4 2 ms ms ms ms ms 2 2 2 2 2 2 2 2 2 3 377 377 377 377 377 377 377 377 377 377 8 8 8 8 7 7 7 8 8 7 61 18 50 29 19 135 −1048us [−1048 us ] +/− 204 −1141us [−1124 us ] +/− 139 +3483us [+3483 us ] +/− 143 −2090us [−2073 us ] +/− −774us [ −774us ] +/− −660us [ −660us ] +/− −823us [ −823us ] +/− 9 −1503us [−1503 us ] +/− −11ms [ −11ms ] +/− 117 10 −3274us [−3274 us ] +/− 137 78 29 50 53 45 70 9 8

ms ms ms ms ms ^+ 85.199.214.102 ^− bagnikita . com ^− europa . e l l i p s e . net ^− tethys . hot−c h i l l i . net ^− 66−232−97−8. s t a t i c . hvvc.> ^* 46−243−26−34. tangos . nl ^− pugot . canonical . com ^− alphyn . canonical . com ^− golem . canonical . com ^− c h i l i p e p p e r . canonical . com chronyc s o u r c e s t a t s ms ms ms ms ms 2 2 2 2 1 1 2 2 2 2 7 8 8 7 8 8 8 6 7 8 377 377 377 377 377 377 377 377 377 377 10 57 79 12 31 27 59 97 71 21 205 204 141 141 74 +3131us [+3131 us ] +/− −790us [ −773us ] +/− −797us [ −797us ] +/− 206 +1669us [+1686 us ] +/− 133 +175us [ +192us ] +/− −123us [ −106us ] +/− −95us [ −95us ] +/− 23 −1569us [−1569 us ] +/− 92 −1018us [−1018 us ] +/− 21 −1106us [−1106 us ] +/− −878us −0.007 −0.132 0.283 −1169us −0.092 0.130 −2056us −0.018 −683us −591us −0.069 −904us 0.094 −1526us −0.005 −11ms −0.983 0.173 −3718us −0.132 −473us −864us −0.094 −0.116 −0.054 −307us −0.271 −143us 0.360 −1749us −0.087 −988us 0.224 −1116us −0.084 0.217 +3527us 0.553 0.110 0.165 +1561us 0.390 +129us 0.297 0.176 freq skew offset 0.259 +3426us 0.196 0.445 0.199 +0.148 +0.117 +0.129 +0.412 +0.057 0.142 0.370 25 26 25 frequency sources = 20 np nr span stratum2−4.ntp. techfak .u> 25 210 number of name/ip address std dev ============================================================================== 106 us gamma. rueckgr . at 256 us 2b . ncomputers . org 195 us www. kashra . com 96 us 66 us 19 us 103 us 78 us 84 us 122 us 139 us 424 us 88 us 109 us 343 us 198 us 135 us 114 us 229 us 169 us 13 zepto . mcl . gg 6 mirrorhost .pw atto . mcl . gg 21 s t a t i c . 1 4 0 . 1 0 7 . 4 6 . 7 8 . c l i > 25 4 . 5 3 . 1 6 0 . 7 5 25 24 3 7 . 4 4 . 1 8 5 . 4 2 17 bagnikita . com 26 europa . e l l i p s e . net 25 tethys . hot−c h i l l i . net 66−232−97−8. s t a t i c . hvvc.> 20 46−243−26−34. tangos . nl 26 25 25 pugot . canonical . com 17 alphyn . canonical . com golem . canonical . com 23 c h i l i p e p p e r . canonical . com 25 32m 35m 32m 32m 21m 645 25m 34m 32m 30m 31m 35m 32m 35m 35m 32m 34m 1100 30m 34m 15 16 15 14 11 5 13 18 10 12 7 15 11 11 11 16 14 11 12 18 85.199.214.102 +0.038 0.110 certain chronyc commands are privileged and can not be run via the network without explicitly allowing them. see section command and monitoring access in man chrony.conf for more details. a local admin can use sudo as usually as this will grant him access to the local admin socket /var/run/chrony/chronyd.sock. 62

pps support chrony supports various pps types natively. it can use kernel pps api as well as ptp hardware clock. most general gps receivers can be leveraged via gpsd. the latter (and potentially more) can be accessed via shm or via a socket (recommended). all of the above can be used to augment chrony with additional high quality time sources for better accuracy, jitter, drift, longer-or-short term accuracy (usually each kind of clock type is good at one of those, but non-perfect at the others). for more details on configuration see some of the external pps/gpsd resource listed below. note: at the release of 20.04 there was a bug which until fixed you might want to add this content to your /etc/apparmor.d/local/usr.sbin.gpsd. example configuration for gpsd to feed chrony for the setup you need $ sudo apt install gpsd chrony but you will want to test/debug your setup and especially the gps reception, therefore also install $ sudo apt install pps−tools gpsd−clients s t r i n g s : mfr=1, product=2, bcddevice= 4.00 serialnumber=0 idvendor=067b , idproduct =2303, gps devices usually will communicate via serial interfaces, yet the most common type these days are usb gps devices which have a serial converter behind usb. if you want to use this for pps please be aware that the majority does not signal pps via usb. check the gpsd hardware list for details. the examples below were run with a navisys gr701-w. when plugging in such a device (or at boot time) dmesg should report serial connection of some sorts, example: [ [ 52.442199] usb 1−1.1: new f u l l−speed usb device number 3 using xhci_hcd 52.546639] usb 1−1.1: new usb device found , 52.546654] usb 1−1.1: new usb device 52.546665] usb 1−1.1: product : usb−s e r i a l controller d 52.546675] usb 1−1.1: manufacturer : p r o l i f i c technology inc . 52.609564] pl2303 1−1.1:1.0: pl2303 converter detected 52.618366] usb 1−1.1: pl2303 converter now attached to ttyusb0 r e f c l o c k shm 0 r e f i d gps p r e c i s i o n 1e−1 o f f s e t 0.9999 delay 0.2 we see above that it appeared as ttyusb0. to later on have chrony accept being feeded time information by that we have to set it up in /etc/chrony/chrony.conf (please replace usb0 to whatever applies to your setup): 52.602103] usbcore : 52.602244] u s b s e r i a l : usb s e r i a l 52.609471] usbcore : 52.609503] u s b s e r i a l : usb s e r i a l r e f c l o c k sock / var /run/chrony . ttyusb0 . sock r e f i d pps r e g i s t e r e d new i n t e r f a c e d r i v e r u s b s e r i a l _ g e n e r i c then restart chrony to make the socket available and waiting. sudo systemctl restart chrony next one needs to tell gpsd which device to manager, therefore in /etc/default/gpsd we set: devices=”/ dev/ttyusb0” furthermore the default use-case of gpsd is, well for gps position tracking. therefore it will normally not consume any cpu since it is not running the service but waiting on a socket for clients. furthermore the client will then tell gpsd what it requests and gpsd will only do that. for the use case of gpsd as pps-providing- daemon you want to set the option to: support r e g i s t e r e d f o r g e n e r i c r e g i s t e r e d new i n t e r f a c e d r i v e r pl2303 support r e g i s t e r e d f o r pl2303 [ [ [ [ [ [ [ [ [ 63

• immediately start even without a client connected, this can be set in gpsd_options of /etc/default /gpsd: – gpsd_options=”−n” • enable the service itself and not wait for a client to reach the socket in the future: – sudo systemctl enable /lib/systemd/system/gpsd.service restarting gpsd will now initialize the pps from gps and in dmesg you will see pps_ldisc : pps l i n e d i s c i p l i n e pps pps0 : new pps source u s b s e r i a l 0 pps pps0 : source ”/ dev/ttyusb0” added r e g i s t e r e d in case you have multiple pps the tool ppsfind might be useful to identify which pps belongs to which gps. you could check that with: $ sudo ppsfind /dev/ttyusb0 pps0 : name=u s b s e r i a l 0 path=/dev/ttyusb0 to get any further you need your gps to get a lock. tools like cgps or gpsmon need to report a 3d fix for the data being any good. then you’d want to check to really have pps data reported on that with ppstest $ cgps . . . ฀ status : 3d fix (7 s e c s ) . . . next one might want to ensure that the pps device really submits pps data, to do so run ppstest: $ sudo ppstest /dev/pps0 trying pps source ”/ dev/pps0 ” found pps source ”/ dev/pps0 ” ok , found 1 source ( s ) , now s t a r t f e t c h i n g data . . . sequence : 70 1588140739.999663721 , source 0− a s s e r t 1588140739.099526246 , source 0− a s s e r t 1588140740.099661485 , source 0− a s s e r t 1588140740.099661485 , source 0− a s s e r t 1588140741.099792447 , 1588140739.999663721 , 1588140740.999786664 , 1588140740.999786664 , sequence : 71 sequence : 70 sequence : 71 sequence : 69− c l e a r sequence : 70− c l e a r sequence : 70− c l e a r sequence : 71− c l e a r ok, gpsd is now running, the gps reception has found a fix and this is fed into chrony. now lets check that from the point of view of chrony. initially (e.g. before gpsd has started or before it has a lock) those will be new and “untrusted” sources marked with an “?”. if your devices stay in the “?” state and won’t leave it even after quite some time then gpsd seems not to feed any data to chrony and you’d need to debug why. chronyc> sources 210 number of ms name/ip address =============================================================================== stratum poll reach lastrx last sample sources = 10 #? gps ns #? pps ns 0 0 4 4 0 0 − − +0ns [ +0ns [ +0ns ] +/− +0ns ] +/− 0 0 over time chrony will classify them as good or bad. in the example case the raw gps had too much deviation but pps is good. 64

chronyc> sources 210 number of ms name/ip address =============================================================================== stratum poll reach lastrx last sample sources = 10 #x gps 0 4 177 24 −876ms [ −876ms ] +/− 200ms #− pps 0 4 177 21 +916us [ +916us ] +/− 63 us ^− c h i l i p e p p e r . canonical . com 2 6 37 53 +33us [ +33us ] +/− 33ms and finally after a while it used the hardware pps input as it was better: chronyc> sources 210 number of ms name/ip address =============================================================================== stratum poll reach lastrx last sample sources = 10 #x gps ms #* pps us ^− alphyn . canonical . com ms 0 0 2 4 4 6 377 377 377 20 −884ms [ −884ms ] +/− 200 18 +6677ns [ +52us ] +/− 20 −1303us [−1258 us ] +/− 114 58 the pps might also be ok but used in a combined way with e.g. the selected server. see man chronyc for more details about how all these combinations will look like. chronyc> sources 210 number of ms name/ip address =============================================================================== stratum poll reach lastrx last sample sources = 11 and if you wonder if your shm based gps data is any good, you can check for that as well. first of all chrony will not only tell you if it classified it as good or bad. via sourcestats you can also check the details chronyc> s o u r c e s t a t s 210 number of std dev name/ip address ============================================================================== 1208 us gps 41 us pps golem . canonical . com 108 us 11.501 5.009 +3365ns 0.509 freq skew offset +1.993 +0.324 +0.859 np nr span sources = 10 frequency 302 78 783 20 6 15 9 3 10 you can also track the raw data that gpsd or other ntpd compliant refclocks are sending via shared memory by using ntpshmmon: −868ms −750us $ sudo ntpshmmon−o ntpshmmon : version 3.20 # name prc offset clock real l 65 #? gps ns #+ pps us ms ^* c h i l i p e p p e r . canonical . com 0 0 2 4 4 6 0 377 377 − 22 50 0 +0ns [ +0ns ] +/− +154us [ +154us ] +/− 8561 −353us [ −300us ] +/− 44

sample ntp1 sample ntp0 −10 −20 −10 −20 −10 sample ntp1 sample ntp0 sample ntp1 references 0.000223854 1588265805.000223854 1588265805.000000000 0 0.125691783 1588265805.125999851 1588265805.000308068 0 0.000349341 1588265806.000349341 1588265806.000000000 0 0.130326636 1588265806.130634945 1588265806.000308309 0 0.000485216 1588265807.000485216 1588265807.000000000 0 • chrony faq • ntp.org: home of the network time protocol project • pool.ntp.org: project of virtual cluster of timeservers • freedesktop.org info on timedatectl • freedesktop.org info on systemd-timesyncd service • feeding chrony from gpsd • see the ubuntu time wiki page for more information. data plane development kit the dpdk is a set of libraries and drivers for fast packet processing and runs mostly in linux userland. it is a set of libraries that provide the so called “environment abstraction layer” (eal). the eal hides the details of the environment and provides a standard programming interface. common use cases are around special solutions for instance network function virtualization and advanced high-throughput network switching. the dpdk uses a run-to-completion model for fast data plane performance and accesses devices via polling to eliminate the latency of interrupt processing at the tradeoff of higher cpu consumption. it was designed to run on any processors. the first supported cpu was intel x86 and it is now extended to ibm ppc64 and arm64. ubuntu further provides some infrastructure to ease dpdks usability. prerequisites this package is currently compiled for the lowest possible cpu requirements allowed by upstream. starting with dpdk 17.08 that means it requires at least sse4_2 and anything else activated by -march=corei7 (in gcc) to be supported by the cpu. the list of upstream dpdk supported network cards can be found at supported nics. but a lot of those are disabled by default in the upstream project as they are not yet in a stable state. the subset of network cards that dpdk has enabled in the package as available in ubuntu 16.04 is: dpdk has “userspace” drivers for the cards called pmds. the packages for these follow the pattern of librte−pmd−<type>−<version>. therefore the example for an intel e1000 in 18.11 would be librte−pmd −e1000−18.11. 66

the more commonly used, tested and fully supported drivers are installed as dependencies of dpdk. but there are way more in universe that follow the same naming pattern. unassigning the default kernel drivers cards have to be unassigned from their kernel driver and instead be assigned to uio_pci_generic of vfio−pci. uio_pci_generic is older and usually getting to work more easily, but also has less features and isolation. the newer vfio-pci requires that you activate the following kernel parameters to enable iommu. iommu=pt intel_iommu=on or on amd amd_iommu=pt on top for vfio-pci you then have to configure and assign the iommu groups accordingly. that is mostly done in firmware and by hw layout, you can check the group assignment the kernel probed in /sys/kernel /iommu_groups/. note: virtio is special, dpdk can directly work on those devices without vfio_pci/uio_pci_generic. but to avoid issues by kernel and dpdk managing the device you still have to unassign the kernel driver. manual configuration and status checks can be done via sysfs or with the tool dpdk_nic_bind status of a l l known network , crypto , event i t d i s p l a y s print and mempool devices . for each device , along with a text d e s c r i p t i o n of device driver , other * the linux i n t e r f a c e name e . g . i f=eth0 * the d r i v e r being used e . g . drv=igb_uio * any s u i t a b l e d r i v e r s not c u r r e n t l y using that device i s being used by a kernel driver , information w i l l be displayed : relevant the pci domain , bus , s l o t and function , the device . depending upon whether the igb_uio driver , or no the e . g . unused=igb_uio i f t h i s note: status display w i l l always occur a f t e r place . f l a g i s passed along with a bind/unbind option , the the other operations have taken 67 usage: dpdk_nic_bind . py−−help dpdk−devbind . py [ options ] device1 device2 . . . . −−help ,−−usage : −s ,−−status : display usage information and quit the current options : syntax where device1, device2 etc , are s p e c i f i e d via pci ”domain : bus : s l o t . func ” or ”bus : s l o t . func ” syntax . for devices bound to linux kernel drivers , a l s o be r e f e r r e d to by linux i n t e r f a c e name e . g . eth0 , eth1 , em0 , em1 , they may etc .

the status of given device group . supported device groups are : having routes in the routing table− cannot be modified . using the t h i s behavior , allowing a c t i v e to be l i n k s f o r c i b l y unbound . warning: this can lead to l o s s of network connection and should be used with caution . f l a g o v e r r i d e s indicated by s e l e c t examples : the d r i v e r unbind a device ( equivalent to display current device status : to use or ”none” to unbind the device to display current network device status : to ”−b none ”) print ” net ” , ” crypto ” , ” event ” , ”mempool” and ” compress ” −−status−dev : −b driver ,−−bind=d r i v e r : −u ,−−unbind : −−f o r c e : by default , network devices which are used by linux− as −−f o r c e −−−−−−−−− dpdk−devbind . py−−status dpdk−devbind . py−−status−dev net dpdk−devbind . py−−bind=igb_uio eth1 dpdk−devbind . py−u 0 0 0 0 : 0 1 : 0 0 . 0 dpdk−devbind . py−b ixgbe 0 2 : 0 0 . 0 0 2 : 0 0 . 1 with uio_pci_generic and the other one with vfio−pci. linux−image−extra−<version> package . # <bus> # <id> # <driver > # # be aware that to bind eth1 from the current d r i v e r and move to use igb_uio # part of # this package i s not always to unbind 0 0 0 0 : 0 1 : 0 0 . 0 from using any d r i v e r dpdk device configuration are images . # so please i n s t a l l supported to bind against currently only ” pci ” i s device id on the s p e c i f i e d bus driver ( vfio−pci or uio_pci_generic ) the two dpdk compatible d r i v e r s uio_pci_generic and vfio−pci i n s t a l l e d by d e f a u l t− f o r example in cloud− in case you run into missing module i s s u e s . i t 68 to bind 0 0 0 0 : 0 2 : 0 0 . 0 and 0 0 0 0 : 0 2 : 0 0 . 1 to the ixgbe kernel d r i v e r the package dpdk provides init scripts that ease configuration of device assignment and huge pages. it also makes them persistent across reboots. the following is an example of the file /etc/dpdk/interfaces configuring two ports of a network card. one

<driver > # # <bus> <id> pci 0 0 0 0 : 0 4 : 0 0 . 0 uio_pci_generic cards are identified by their pci-id. if you are unsure you might use the tool dpdk_nic_bind.py to show the current available devices and the drivers they are assigned to. pci 0 0 0 0 : 0 4 : 0 0 . 1 vfio−pci dpdk_nic_bind . py−−status network devices using dpdk−compatible d r i v e r 0 0 0 0 : 0 4 : 0 0 . 0 ’ ethernet controller 10−gigabit x540−at2’ drv=uio_pci_generic ============================================ unused=ixgbe network devices using kernel d r i v e r =================================== 0 0 0 0 : 0 2 : 0 0 . 0 ’ netxtreme bcm5719 gigabit ethernet pcie ’ uio_pci_generic * active * 0 0 0 0 : 0 2 : 0 0 . 1 ’ netxtreme bcm5719 gigabit ethernet pcie ’ i f=eth0 drv=tg3 unused= i f=eth1 drv=tg3 unused= i f=eth2 drv=tg3 unused= i f=eth3 drv=tg3 unused= i f=eth5 drv=ixgbe uio_pci_generic uio_pci_generic 0 0 0 0 : 0 2 : 0 0 . 2 ’ netxtreme bcm5719 gigabit ethernet pcie ’ uio_pci_generic 0 0 0 0 : 0 2 : 0 0 . 3 ’ netxtreme bcm5719 gigabit ethernet pcie ’ 0 0 0 0 : 0 4 : 0 0 . 1 ’ ethernet controller 10−gigabit x540−at2’ unused=uio_pci_generic other network devices ===================== <none> dpdk hugepage configuration dpdk makes heavy use of huge pages to eliminate pressure on the tlb. therefore hugepages have to be configured in your system. the dpdk package has a config file and scripts that try to ease hugepage configuration for dpdk in the form of /etc/dpdk/dpdk.conf. if you have more consumers of hugepages than just dpdk in your system or very special requirements how your hugepages are going to be set up you likely want to allocate/control them by yourself. if not this can be a great simplification to get dpdk configured for your needs. here an example configuring 1024 hugepages of 2m each and 4 1g pages. nr_2m_pages=1024 nr_1g_pages=4 as shown this supports configuring 2m and the larger 1g hugepages (or a mix of both). it will make sure there are proper hugetlbfs mountpoints for dpdk to find both sizes no matter what your default huge page size is. the config file itself holds more details on certain corner cases and a few hints if you want to allocate hugepages manually via a kernel parameter. it depends on your needs which size you want - 1g pages are certainly more effective regarding tlb pressure. but there were reports of them fragmenting inside the dpdk memory allocations. also it can be harder to grab enough free space to set up a certain amount of 1g pages later in the life-cycle of a system. 69

compile dpdk applications currently there are not a lot consumers of the dpdk library that are stable and released. openvswitch- dpdk being an exception to that (see below) and more are appearing. but in general it might still happen that you might want to compile an app against the library. you will often find guides that tell you to fetch the dpdk sources, build them to your needs and eventually build your application based on dpdk by setting values rte_* for the build system. since ubuntu provides an already compiled dpdk for you can can skip all that. dpdk provides a valid pkg-config file to simplify setting the proper variables and options. libdpdk )−o testdpdkprog sudo apt−get gcc testdpdkprog . c $ ( pkg−c o n f i g−−l i b s−−c f l a g s sudo apt−get i n s t a l l dpdk−dev libdpdk−dev i n s t a l l build−dep dpdk dpdk in kvm guests an example of a complex (autoconfigure) user of pkg-config of dpdk including fallbacks to older non pkg-config style can be seen in the openvswitch build system. depending on what you build it might be a good addition to install all of dpdk build dependencies before the make, which on ubuntu can be done automatically with. if you have no access to dpdk supported network cards you can still work with dpdk by using its support for virtio. to do so you have to create guests backed by hugepages (see above). on top of that there it is required to have at least sse3. the default cpu model qemu/libvirt uses is only up to sse2. so you will have to define a model that passed the proper feature flags (or use host-passthrough). an example can be found in following snippet to your virsh xml (or the equivalent virsh interface you use). <cpu mode=’host−passthrough ’> also virtio nowadays supports multiqueue which dpdk in turn can exploit for better speed. to modify a normal virtio definition to have multiple queues add the following to your interface definition. this is about enhancing a normal virtio nic to have multiple queues, to later on be consumed e.g. by dpdk in the guest. <d r i v e r name=”vhost ” queues=”4”/> use dpdk since dpdk on its own is only (massive) library you most likely might continue to openvswitch-dpdk as an example to put it to use. resources • dpdk documentation • release notes matching the version packages in ubuntu 16.04 • linux dpdk user getting started • eal command-line options • dpdk api documentation 70

• openvswitch dpdk installation • wikipedias definition of dpdk openvswitch-dpdk # run on core 0 only with dpdk being just a library it doesn’t do a lot on its own, so it depends on emerging projects making use of it. one consumer of the library that already is part of ubuntu is openvswitch with dpdk support in the package openvswitch-switch-dpdk. here an example how to install and configure a basic openvswitch using dpdk for later use via libvirt/qemu- kvm. i n s t a l l openvswitch−switch−dpdk s e t open_vswitch . ” other_config : dpdk−i n i t=true ” s e t open_vswitch . ” other_config : dpdk−lcore−mask=0x1” s e t open_vswitch . ” other_config : dpdk−a l l o c−mem=2048” s e t open_vswitch . ” other_config : dpdk−extra=−−pci−w h i t e l i s t sudo apt−get sudo update−a l t e r n a t i v e s−−s e t ovs−vswitchd / usr / l i b / openvswitch−switch−dpdk/ ovs−vswitchd−dpdk ovs−v s c t l ovs−v s c t l ovs−v s c t l ovs−v s c t l sudo s e r v i c e openvswitch−switch r e s t a r t please remember that you have to assign devices to dpdk compatible drivers see above at network - dpdk before restarting. please note that the section dpdk-alloc-mem=2048 above is the most basic numa setup for a single socket system. if you have multiple sockets you might want to define how to split your memory among them. more details about these options are outlined in openvswitch setup. to one w h i t e l i s t e d device # allocate 2g huge pages ( not numa node aware ) # l i m i t =0000:04:00.0” attaching dpdk ports to openvswitch the openvswitch you now started supports all port types openvswitch usually does, plus dpdk port types. here an example how to create a bridge and - instead of a normal external port - add an external dpdk port to it. when doing so you can specify the device that will be associated. ovs−v s c t l add−br ovsdpdkbr0−− s e t bridge ovsdpdkbr0 datapath_type=netdev ovs−v s c t l add−port ovsdpdkbr0 dpdk0−− s e t : dpdk−devargs=${ovsdev_pciid}” ovs−v s c t l further tuning can be applied by setting options: i n t e r f a c e dpdk0 ” options : n_rxq=2” i n t e r f a c e dpdk0 type=dpdk ” options s e t openvswitch dpdk to kvm guests if you are not building some sort of sdn switch or nfv on top of dpdk it is very likely that you want to forward traffic to kvm guests. the good news is, that with the new qemu/libvirt/dpdk/openvswitch versions in ubuntu this is no more about manually appending commandline string. this chapter covers a basic configuration how to connect a kvm guest to a openvswitch-dpdk instance. 71

the recommended way to get to a kvm guest is using vhost_user_client. this will cause ovs-dpdk to create connect to a socket that qemu created. that way old issues like guest failures on ovs restart are avoided. here an example how to add such a port to the bridge you created above. ovs−v s c t l add−port ovsdpdkbr0 vhost−user−1−− s e t i n t e r f a c e vhost−user−1 type= dpdkvhostuserclient ” options : vhost−server−path=/var /run/ v h o s t u s e r c l i e n t / vhost−user−c l i e n t−1” path=’/ var /run/ openvswitch /vhost−user−c l i e n t−1’ this will connect to the specified path that has to be created by a guest listening on it. to let libvirt/kvm consume this socket and create a guest virtio network device for it add a snippet like this to your guest definition as the network definition. <i n t e r f a c e type=’ vhostuser ’> <source type=’unix ’ mode=’ server ’/> <model type=’ v i r t i o ’/> </i n t e r f a c e > tuning openvswitch-dpdk dpdk has plenty of options - in combination with openvswitch-dpdk the two most commonly used are: ovs−v s c t l ovs−v s c t l s e t open_vswitch . other_config : n−dpdk−rxqs=2 s e t open_vswitch . other_config :pmd−cpu−mask=0x6 the first select how many rx queues are to be used for each dpdk interface, while the second controls how many and where to run pmd threads. the example above will utilize two rx queues and run pmd threads on cpu 1 and 2. see the referred links to “eal command-line options” and “openvswitch dpdk installation” at the end of this document for more. as usual with tunings you have to know your system and workload really well - so please verify any tunings with workloads matching your real use case. support and troubleshooting dpdk is a fast evolving project. in any case of a search for support and further guides it is highly recom- mended to first check if they apply to the current version. check if it is a known issue on: • dpdk mailing lists • for openvswitch-dpdk openstack mailing lists • known issues in dpdk launchpad area • join the irc channels #dpdk or #openvswitch on freenode. issues are often due to missing small details in the general setup. later on, these missing details cause problems which can be hard to track down to their root cause. a common case seems to be the “could not open network device dpdk0 (no such device)” issue. this occurs rather late when setting up a port in open vswitch with dpdk. but the root cause most of the time is very early in the setup and initialization. here an example how a proper initialization of a device looks - this can be found in the syslog/journal when starting open vswitch with dpdk enabled. ovs−c t l [ 3 5 6 0 ] : eal: pci device 0 0 0 0 : 0 4 : 0 0 . 1 on numa socket 0 ovs−c t l [ 3 5 6 0 ] : eal: probe d r i v e r : 8086:1528 rte_ixgbe_pmd 72

pci memory mapped at 0 x7f2140000000 pci memory mapped at 0 x7f2140200000 if this is missing, either by ignored cards, failed initialization or other reasons, later on there will be no dpdk device to refer to. unfortunately the logging is spread across syslog/journal and the openvswitch log. to allow some cross checking here an example what can be found in these logs, relative to the entered command. #note : this log was taken with dpdk 2.2 and openvswitch 2.5 but looks s t i l l s i m i l a r ( a b i t extended ) these days ovs−c t l [ 3 5 6 0 ] : eal: ovs−c t l [ 3 5 6 0 ] : eal: quite captions : cmd: syslog: that you enter on ovs node 0 cpu cores cmd: syslog: sock : connecting . . . ( terminated ) , e x i t i n g ( inlcuding eal and ovs messages ) ( openvswitch messages ) #preparation bind an i n t e r f a c e to dpdk uio drivers , make hugepages available , enable dpdk ovs−log: sudo s e r v i c e openvswitch−switch r e s t a r t 2016−01−22t08 : 5 8 : 3 1 . 3 7 2 z| 0 0 0 0 3 | daemon_unix ( monitor ) |info| pid 3329 died , k i l l e d 2016−01−22t08 : 5 8 : 3 3 . 3 7 7 z| 0 0 0 0 2 | vlog |info| opened log f i l e / var / log / openvswitch / ovs−vswitchd . log 2016−01−22t08 : 5 8 : 3 3 . 3 8 1 z| 0 0 0 0 3 | ovs_numa |info| discovered 12 cpu cores on numa 2016−01−22t08 : 5 8 : 3 3 . 3 8 1 z| 0 0 0 0 4 | ovs_numa |info| discovered 1 numa nodes and 12 2016−01−22t08 : 5 8 : 3 3 . 3 8 1 z| 0 0 0 0 5 | reconnect |info| unix :/ var /run/ openvswitch /db . 2016−01−22t08 : 5 8 : 3 3 . 3 8 3 z| 0 0 0 0 6 | reconnect |info| unix :/ var /run/ openvswitch /db . 2016−01−22t08 : 5 8 : 3 3 . 3 8 6 z| 0 0 0 0 7 | bridge |info| ovs−vswitchd (open vswitch ) 2 . 5 . 0 ovs−log: ovs−c t l [ 3 5 4 1 ] : * k i l l i n g ovs−vswitchd (3329) ovs−c t l [ 3 5 4 1 ] : * k i l l i n g ovsdb−s e r v e r ovs−c t l [ 3 5 6 0 ] : * starting ovsdb−s e r v e r ovs−v s c t l : ovs | 0 0 0 0 1 | v s c t l |info| called as ovs−v s c t l−−no−wait−− i n i t−− s e t open_vswitch . db−version =7.12.1 ovs−v s c t l : ovs | 0 0 0 0 1 | v s c t l |info| called as ovs−v s c t l−−no−wait . ovs−version =2.5.0 ” external−i d s : system−id=\”e7c5ba80−bb14−45c1−b8eb−628 f3ad03903 \”” ”system−type=\”ubuntu\”” ”system−version =\”16.04− x e n i a l \”” ovs−c t l [ 3 5 6 0 ] : * configuring open vswitch system ids ovs−c t l [ 3 5 6 0 ] : 2016−01−22t08 : 5 8 : 3 1 z| 0 0 0 0 1 | dpdk |info| no−vhost_sock_dir provided− d e f a u l t i n g to / var /run/ openvswitch ovs−vswitchd : ovs | 0 0 0 0 1 | dpdk |info| no−vhost_sock_dir provided− d e f a u l t i n g to systemd [ 1 ] : stopping open vswitch . . . systemd [ 1 ] : stopped open vswitch . systemd [ 1 ] : stopping open vswitch i n t e r n a l unit . . . systemd [ 1 ] : stopped open vswitch i n t e r n a l unit . systemd [ 1 ] : starting open vswitch i n t e r n a l unit . . . / var /run/ openvswitch s e t open_vswitch sock : connected (3318) 73

core ( s ) by c o n f i g u r a t i o n . loaded , skip vfio support . . . s i z e 1024mb from socket 0 l c o r e 0 i s ready ( t i d=fc6cbb00 ; cpuset =[0]) ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 0 as core 0 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 1 as core 1 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 2 as core 2 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 3 as core 3 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 4 as core 4 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 5 as core 5 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 6 as core 0 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 7 as core 1 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 8 as core 2 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 9 as core 3 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 10 as core 4 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: detected l c o r e 11 as core 5 on socket 0 ovs−c t l [ 3 5 6 0 ] : eal: support maximum 128 l o g i c a l ovs−c t l [ 3 5 6 0 ] : eal: detected 12 l c o r e ( s ) ovs−c t l [ 3 5 6 0 ] : eal: vfio modules not a l l ovs−c t l [ 3 5 6 0 ] : eal: setting up p h y s i c a l l y contiguous memory . . . ovs−c t l [ 3 5 6 0 ] : eal: ask a v i r t u a l area of 0x100000000 bytes ovs−c t l [ 3 5 6 0 ] : eal: virtual area found at 0 x7f2040000000 ( s i z e = 0x100000000 ) ovs−c t l [ 3 5 6 0 ] : eal: requesting 4 pages of ovs−c t l [ 3 5 6 0 ] : eal: tsc frequency i s ~2397202 khz ovs−vswitchd [ 3 5 9 2 ] : eal: tsc frequency i s ~2397202 khz ovs−vswitchd [ 3 5 9 2 ] : eal: master ovs−vswitchd [ 3 5 9 2 ] : eal: pci device 0 0 0 0 : 0 4 : 0 0 . 0 on numa socket 0 ovs−vswitchd [ 3 5 9 2 ] : eal: ovs−vswitchd [ 3 5 9 2 ] : eal: ovs−vswitchd [ 3 5 9 2 ] : eal: pci device 0 0 0 0 : 0 4 : 0 0 . 1 on numa socket 0 ovs−vswitchd [ 3 5 9 2 ] : eal: ovs−vswitchd [ 3 5 9 2 ] : eal: ovs−vswitchd [ 3 5 9 2 ] : eal: ovs−c t l [ 3 5 6 0 ] : eal: master ovs−c t l [ 3 5 6 0 ] : eal: pci device 0 0 0 0 : 0 4 : 0 0 . 0 on numa socket 0 ovs−c t l [ 3 5 6 0 ] : eal: ovs−c t l [ 3 5 6 0 ] : eal: ovs−c t l [ 3 5 6 0 ] : eal: pci device 0 0 0 0 : 0 4 : 0 0 . 1 on numa socket 0 ovs−c t l [ 3 5 6 0 ] : eal: ovs−c t l [ 3 5 6 0 ] : eal: ovs−c t l [ 3 5 6 0 ] : eal: ovs−vswitchd [ 3 5 9 2 ] : pmd: eth_ixgbe_dev_init () : mac: 4 , phy: 3 ovs−vswitchd [ 3 5 9 2 ] : pmd: eth_ixgbe_dev_init () : port 0 vendorid=0x8086 deviceid ovs−c t l [ 3 5 6 0 ] : pmd: eth_ixgbe_dev_init () : mac: 4 , phy: 3 ovs−c t l [ 3 5 6 0 ] : pmd: eth_ixgbe_dev_init () : port 0 vendorid=0x8086 deviceid=0 ovs−c t l [ 3 5 6 0 ] : zone 0: name:<rg_mp_log_history>, phys :0 x83fffdec0 , ovs−c t l [ 3 5 6 0 ] : zone 1: name:<mp_log_history >, phys :0 x83fd73d40 , ovs−c t l [ 3 5 6 0 ] : zone 2: name:<rte_eth_dev_data >, phys :0 x83fd43380 , ovs−c t l [ 3 5 6 0 ] : * starting ovs−vswitchd ovs−c t l [ 3 5 6 0 ] : * enabling remote ovsdb managers probe d r i v e r : 8086:1528 rte_ixgbe_pmd pci memory mapped at 0 x7f2140000000 pci memory mapped at 0 x7f2140200000 l c o r e 0 i s probe d r i v e r : 8086:1528 rte_ixgbe_pmd pci memory mapped at 0 x7f2140000000 pci memory mapped at 0 x7f2140200000 systemd [ 1 ] : started open vswitch i n t e r n a l unit . systemd [ 1 ] : starting open vswitch . . . systemd [ 1 ] : started open vswitch . probe d r i v e r : 8086:1528 rte_ixgbe_pmd not managed by a supported kernel driver , probe d r i v e r : 8086:1528 rte_ixgbe_pmd not managed by a supported kernel driver , v i r t :0 x7f213fd43380 , socket_id : 0 , v i r t :0 x7f213fd73d40 , socket_id : 0 , f l a g s :0 v i r t :0 x7f213fffdec0 , socket_id : 0 , f l a g s :0 ready ( t i d=fc6cbb00 ; cpuset =[0]) len :0 x2080 , len :0 x28a0c0 , len :0 x2f700 , =0x1528 x1528 skipped skipped f l a g s :0 74

make sure rx burst sw_ring=0x7f211a79ebc0 i n t e r f a c e dpdk0 type=dpdk id 00008 cdcd4b36de9 ’ dpdk0 ’ tx enabled . sw_ring=0x7f211a78a6c0 hw_ring=0x7f211a7a6c00 dma_addr=0x81a7a6c00 hw_ring=0x7f211a7a6c00 dma_addr=0x81a7a6c00 ixgbe_dev_tx_queue_setup () : sw_ring=0x7f211a79ebc0 ixgbe_set_rx_function () : vector rx enabled , please s i z e no l e s s than 4 ( port =0) . ixgbe_dev_tx_queue_setup () : sw_sc_ring=0x7f211a786580 hw_ring=0x7f211a78e800 dma_addr=0x81a78e800 ixgbe_set_tx_function () : using simple tx code path ixgbe_set_tx_function () : vector ixgbe_dev_rx_queue_setup () : 2016−01−22t08 : 5 9 : 3 1 . 5 2 3 z| 0 0 0 0 2 | dpif_netdev (pmd16) |info| core 0 processing port ovs−log: ovs−v s c t l : ovs | 0 0 0 0 1 | v s c t l |info| called as ovs−v s c t l add−port ovsdpdkbr0 dpdk0 −− s e t ovs−vswitchd [ 3 5 9 5 ] : pmd: ovs−vswitchd [ 3 5 9 5 ] : pmd: ovs−vswitchd [ 3 5 9 5 ] : pmd: ovs−vswitchd [ 3 5 9 5 ] : pmd: ovs−vswitchd [ 3 5 9 5 ] : pmd: ovs−vswitchd [ 3 5 9 5 ] : pmd: i n t e r f a c e vhost− sudo ovs−v s c t l add−port ovsdpdkbr0 vhost−user−1−− s e t user−1 type=dpdkvhostuser ovs−log: 2016−01−22t09 : 0 0 : 3 5 . 1 4 5 z| 0 0 0 2 6 | dpdk |info| socket / var /run/ openvswitch /vhost− user−1 created f o r vhost−user port vhost−user−1 2016−01−22t09 : 0 0 : 3 5 . 1 4 5 z| 0 0 0 0 3 | dpif_netdev (pmd16) |info| core 0 processing port 2016−01−22t09 : 0 0 : 3 5 . 1 4 5 z| 0 0 0 0 4 | dpif_netdev (pmd16) |info| core 0 processing port ’ vhost−user−1’ 2016−01−22t09 : 0 0 : 3 5 . 1 4 5 z| 0 0 0 2 7 | bridge |info| bridge ovsdpdkbr0 : added i n t e r f a c e vhost−user−1 on port 2 ovs−v s c t l : ovs | 0 0 0 0 1 | v s c t l |info| called as ovs−v s c t l add−port ovsdpdkbr0 vhost− user−1−− s e t i n t e r f a c e vhost−user−1 type=dpdkvhostuser ovs−vswitchd [ 3 5 9 5 ] : vhost_config: ovs−vswitchd [ 3 5 9 5 ] : vhost_config: bind to / var /run/ openvswitch /vhost−user−1 33:13.56 ovs− 10 −10 4975344 103936 eventually we can see the p o l l virt pr ni shr s %cpu %mem 9916 s 100.0 0.3 pid user 3595 root vswitchd thread in top res time+ command . . . cmd: ’ dpdk0 ’ syslog: socket created , fd :46 resources • dpdk documentation • release notes matching the version packages in ubuntu 16.04 • linux dpdk user getting started • eal command-line options • dpdk api documentation 76

• openvswitch dpdk installation • wikipedias definition of dpdk security security should always be considered when installing, deploying, and using any type of computer system. although a fresh installation of ubuntu is relatively safe for immediate use on the internet, it is important to have a balanced understanding of your system’s security posture based on how it will be used after deployment. this chapter provides an overview of security-related topics as they pertain to ubuntu distro-rev server edition, and outlines simple measures you may use to protect your server and network from any number of potential security threats. user management user management is a critical part of maintaining a secure system. ineffective user and privilege management often lead many systems into being compromised. therefore, it is important that you understand how you can protect your server through simple and effective user account management techniques. where is root? ubuntu developers made a conscientious decision to disable the administrative root account by default in all ubuntu installations. this does not mean that the root account has been deleted or that it may not be accessed. it merely has been given a password hash which matches no possible value, therefore may not log in directly by itself. instead, users are encouraged to make use of a tool by the name of ‘sudo’ to carry out system administrative duties. sudo allows an authorized user to temporarily elevate their privileges using their own password instead of having to know the password belonging to the root account. this simple yet effective methodology provides accountability for all user actions, and gives the administrator granular control over which actions a user can perform with said privileges. • if for some reason you wish to enable the root account, simply give it a password: sudo passwd sudo will prompt you for your password, and then ask you to supply a new password for root as shown below: [ sudo ] password f o r username : enter new unix password : retype new unix password : passwd : password updated s u c c e s s f u l l y ( enter your own password ) root ) root ) ( enter a new password f o r ( repeat new password f o r • to disable the root account password, use the following passwd syntax: sudo passwd−l root • you should read more on sudo by reading the man page: man sudo 77

by default, the initial user created by the ubuntu installer is a member of the group sudo which is added to the file /etc/sudoers as an authorized sudo user. if you wish to give any other account full root access through sudo, simply add them to the sudo group. adding and deleting users the process for managing local users and groups is straightforward and differs very little from most other gnu/linux operating systems. ubuntu and other debian based distributions encourage the use of the ‘adduser’ package for account management. • to add a user account, use the following syntax, and follow the prompts to give the account a password and identifiable characteristics, such as a full name, phone number, etc. sudo adduser username • to delete a user account and its primary group, use the following syntax: sudo d e l u s e r username deleting an account does not remove their respective home folder. it is up to you whether or not you wish to delete the folder manually or keep it according to your desired retention policies. remember, any user added later on with the same uid/gid as the previous owner will now have access to this folder if you have not taken the necessary precautions. you may want to change these uid/gid values to something more appropriate, such as the root account, and perhaps even relocate the folder to avoid future conflicts: • to add or delete a personalized group, use the following syntax, respectively: sudo addgroup groupname sudo delgroup groupname • to add a user to a group, use the following syntax: sudo adduser username groupname user profile security when a new user is created, the adduser utility creates a brand new home directory named /home/username. the default profile is modeled after the contents found in the directory of /etc/skel, which includes all profile basics. if your server will be home to multiple users, you should pay close attention to the user home directory permissions to ensure confidentiality. by default, user home directories in ubuntu are created with world read/execute permissions. this means that all users can browse and access the contents of other users home directories. this may not be suitable for your environment. 78 sudo mkdir /home/ archived_users / sudo mv /home/username /home/ archived_users / sudo chown−r root : root /home/username/ sudo passwd−l username sudo passwd−u username • to temporarily lock or unlock a user password, use the following syntax, respectively:

the following output shows that the directory /home/username has world-readable permissions: • to verify your current user home directory permissions, use the following syntax: l s−ld /home/username drwxr−xr−x 2 username username • you can remove the world readable-permissions using the following syntax: sudo chmod 0750 /home/username 4096 2007−10−02 20:03 username note some people tend to use the recursive option (-r) indiscriminately which modifies all child folders and files, but this is not necessary, and may yield other undesirable results. the parent directory alone is sufficient for preventing unauthorized access to anything below the parent. a much more efficient approach to the matter would be to modify the adduser global default permissions when creating user home folders. simply edit the file /etc/adduser.conf and modify the dir_mode variable to something appropriate, so that all new home directories will receive the correct permissions. dir_mode=0750 • after correcting the directory permissions using any of the previously mentioned techniques, verify the results using the following syntax: l s−ld /home/username drwxr−x−−− 2 username username password policy the results below show that world-readable permissions have been removed: 4096 2007−10−02 20:03 username a strong password policy is one of the most important aspects of your security posture. many successful security breaches involve simple brute force and dictionary attacks against weak passwords. if you intend to offer any form of remote access involving your local password system, make sure you adequately address minimum password complexity requirements, maximum password lifetimes, and frequent audits of your authentication systems. minimum password length password by default, ubuntu requires a minimum password length of 6 characters, as well as some basic entropy checks. these values are controlled in the file /etc/pam.d/common−password, which is outlined below. pam_unix . so obscure sha512 [ s ucce ss=1 d e f a u l t=ignore ] if you would like to adjust the minimum length to 8 characters, change the appropriate variable to min=8. the modification is outlined below. password pam_unix . so obscure sha512 [ s ucce ss=1 d e f a u l t=ignore ] minlen=8 note basic password entropy checks and minimum length rules do not apply to the administrator using sudo level commands to setup a new user. 79

password expiration sudo chage−l username when creating user accounts, you should make it a policy to have a minimum and maximum password age forcing users to change their passwords when they expire. • to easily view the current status of a user account, use the following syntax: the output below shows interesting facts about the user account, namely that there are no policies applied: last password change password e x p i r e s password i n a c t i v e account e x p i r e s minimum number of days between password change maximum number of days between password change number of days of warning before password e x p i r e s : jan 20 , 2015 : never : never : never : 0 : 99999 : 7 • to set any of these values, simply use the following syntax, and follow the interactive prompts: sudo chage username the following is also an example of how you can manually change the explicit expiration date (-e) to 01/31/2015, minimum password age (-m) of 5 days, maximum password age (-m) of 90 days, inactivity period (-i) of 30 days after password expiration, and a warning time period (-w) of 14 days before password expiration: • to verify changes, use the same syntax as mentioned previously: sudo chage−e 01/31/2015−m 5−m 90−i 30−w 14 username sudo chage−l username the output below shows the new policies that have been established for the account: last password change password e x p i r e s password i n a c t i v e account e x p i r e s minimum number of days between password change maximum number of days between password change number of days of warning before password e x p i r e s : jan 20 , 2015 : apr 19 , 2015 : may 19 , 2015 : jan 31 , 2015 : 5 : 90 : 14 other security considerations many applications use alternate authentication mechanisms that can be easily overlooked by even experienced system administrators. therefore, it is important to understand and control how users authenticate and gain access to services and applications on your server. ssh access by disabled users simply disabling/locking a user password will not prevent a user from logging into your server remotely if they have previously set up ssh public key authentication. they will still be able to gain shell access to the 80

server, without the need for any password. remember to check the users home directory for files that will allow for this type of authenticated ssh access, e.g. /home/username/.ssh/authorized_keys. remove or rename the directory .ssh/ in the user’s home folder to prevent further ssh authentication capabilities. be sure to check for any established ssh connections by the disabled user, as it is possible they may have existing inbound or outbound connections. kill any that are found. who | grep username the pts/# terminal ) ( to get restrict ssh access to only user accounts that should have it. for example, you may create a group called “sshlogin” and add the group name as the value associated with the allowgroups variable located in the file /etc/ssh/sshd_config. allowgroups s s h l o g i n sudo p k i l l−f pts/# then add your permitted ssh users to the group “sshlogin”, and restart the ssh service. sudo adduser username s s h l o g i n sudo systemctl sshd . s e r v i c e r e s t a r t external user database authentication most enterprise networks require centralized authentication and access controls for all system resources. if you have configured your server to authenticate users against external databases, be sure to disable the user accounts both externally and locally. this way you ensure that local fallback authentication is not possible. apparmor apparmor is a linux security module implementation of name-based mandatory access controls. apparmor confines individual programs to a set of listed files and posix 1003.1e draft capabilities. apparmor is installed and loaded by default. it uses profiles of an application to determine what files and permissions the application requires. some packages will install their own profiles, and additional profiles can be found in the apparmor-profiles package. to install the apparmor-profiles package from a terminal prompt: sudo apt i n s t a l l apparmor−p r o f i l e s apparmor profiles have two modes of execution: • complaining/learning: profile violations are permitted and logged. useful for testing and developing new profiles. • enforced/confined: enforces profile policy as well as logging the violation. using apparmor the optional apparmor-utils package contains command line utilities that you can use to change the appar- mor execution mode, find the status of a profile, create new profiles, etc. • apparmor_status is used to view the current status of apparmor profiles. sudo apparmor_status 81

• aa-enforce places a profile into enforce mode. • aa-complain places a profile into complain mode. to place all profiles in enforce mode: ulate the mode of all profiles. enter the following to place all profiles into complain mode: sudo aa−complain /path/ to / bin sudo aa−enforce /path/ to / bin sudo aa−complain / etc /apparmor . d/* sudo aa−enforce / etc /apparmor . d/* sudo apparmor_parser−r / etc /apparmor . d/ p r o f i l e . name sudo ln−s / etc /apparmor . d/ p r o f i l e . name / etc /apparmor . d/ d i s a b l e / sudo apparmor_parser−r / etc /apparmor . d/ p r o f i l e . name disable a profile. • systemctl can be used to reload all profiles: sudo systemctl reload apparmor . s e r v i c e • apparmor_parser is used to load a profile into the kernel. it can also be used to reload a currently loaded profile using the -r option after modifying it to have the changes take effect. to reload a profile: • the /etc/apparmor.d directory is where the apparmor profiles are located. it can be used to manip- • the /etc/apparmor.d/disable directory can be used along with the apparmor_parser -r option to to re-enable a disabled profile remove the symbolic link to the profile in /etc/apparmor.d/disable/. then load the profile using the -a option. sudo rm / etc /apparmor . d/ d i s a b l e / p r o f i l e . name cat / etc /apparmor . d/ p r o f i l e . name | sudo apparmor_parser−a • apparmor can be disabled, and the kernel module unloaded by entering the following: sudo systemctl sudo systemctl d i s a b l e apparmor . s e r v i c e stop apparmor . s e r v i c e • to re-enable apparmor enter: sudo systemctl enable apparmor . s e r v i c e s t a r t apparmor . s e r v i c e sudo systemctl note replace profile.name with the name of the profile you want to manipulate. also, replace /path/ to/bin/ with the actual executable file path. for example for the ping command use /bin/ping 82

profiles apparmor profiles are simple text files located in /etc/apparmor.d/. the files are named after the full path to the executable they profile replacing the “/” with “.”. for example /etc/apparmor.d/bin.ping is the apparmor profile for the /bin/ping command. there are two main type of rules used in profiles: • path entries: detail which files an application can access in the file system. • capability entries: determine what privileges a confined process is allowed to use. as an example, take a look at /etc/apparmor.d/bin.ping: #include <tunables / global > / bin / ping f l a g s =(complain ) { #include <a b s t r a c t i o n s /base> #include <a b s t r a c t i o n s / consoles > #include <a b s t r a c t i o n s / nameservice> c a p a b i l i t y net_raw , c a p a b i l i t y setuid , network i n e t raw , / bin / ping mixr , / etc /modules . conf r , } • #include <tunables/global>: include statements from other files. this allows statements pertaining to multiple applications to be placed in a common file. • /bin/ping flags=(complain): path to the profiled program, also setting the mode to complain. • capability net_raw,: allows the application access to the cap_net_raw posix.1e capability. • /bin/ping mixr,: allows the application read and execute access to the file. note after editing a profile file the profile must be reloaded. see above at using apparmor for details. creating a profile • design a test plan: try to think about how the application should be exercised. the test plan should be divided into small test cases. each test case should have a small description and list the steps to follow. some standard test cases are: – starting the program. – stopping the program. – reloading the program. – testing all the commands supported by the init script. • generate the new profile: use aa-genprof to generate a new profile. from a terminal: sudo aa−genprof executable for example: 83

sudo aa−genprof apparmor package: slapd • to get your new profile included in the apparmor-profiles package, file a bug in launchpad against the – include your test plan and test cases. – attach your new profile to the bug. updating profiles further pre-existing profiles when the program is misbehaving, audit messages are sent to the log files. the program aa-logprof can be used to scan log files for apparmor audit messages, review them and update the profiles. from a terminal: sudo aa−l o g p r o f the packages apport−profiles and apparmor−profiles−extra ship some experimental profiles for apparmor some even more experimental profiles carried by the package are placed in/usr/share/doc/apparmor−profiles security policies. do not expect these profiles to work out-of-the-box, but they can give you a head start when trynig to create a new profile by starting off a base that exists. these profiles are not considered mature enough to be shipped in enforce mode by default. therefore they are shipped in complain mode so that users can test them, choose which are desired, and help improve them upstream if needed. /extras/ checking and debugging denies you will see in ‘dmesg’ and any log that collects kernel messages if you have hit a deny. right away it is worth to know that this will cover any access that was denied because it was not allowed, but explicit denies will put no message in your logs at all. examples might look like: [1521056.552037] audit : denied” operation=”open” p r o f i l e =”/usr / sbin /cups−browsed ” name=”/var / l i b / l i b v i r t /dnsmasq/” pid=1128 comm=”cups−browsed ” requested_mask=”r ” type=1400 audit (1571829452.330:24323) : apparmor=” type=1400 audit (1571868402.378:24425) : apparmor=” denied_mask=”r ” f s u i d=0 ouid=0 [1482106.651527] audit : denied” operation=”sendmsg” p r o f i l e =”snap . lxd . lxc ” pid =24115 comm=”lxc ” laddr =10.7.0.69 l p o r t =48796 faddr =10.7.0.231 f p o r t =445 family=”i n e t ” sock_type=”stream ” protocol=6 requested_mask=”send ” denied_mask=”send ” that follows a generic structure starting with a timestamp, an audit tag and the category apparmor=” denied”. from the following fields you can derive what was going on and why it was failing. in the examples above that would be first example: * operation: open (program tried to open a file) * profile: /usr/sbin/cups−browsed (you’ll find /etc/apparmor.d/usr.bin.cups−browsed) * name: /var/lib/ libvirt /dnsmasq (what it wanted to access) * pid/comm: the program that did trigger the access * requested_mask/denied_mask/fsuid/ouid: parameters of that open call 84

second example: * operation: sendmsg (program tried send via network) * profile: snap.lxd.lxc (snaps are special, you’ll find /var/lib/snapd/apparmor/profiles/snap.lxd.lxc) * pid/comm: the program that did trigger the access * laddr/lport/faddr/fport/family/sock_type/protocol: parameters of that sendmsg call that way you know in which profile and at what action you have to start if you consider either debugging or adapting the profiles. profile customization profiles are meant to provide security and thereby can’t be all too open. but quite often a very special setup would work with a profile if it wold just allow this one extra access. to handle that there are three ways. • modify the profile itself • use tunables • modify a local override – always works, but has the drawback that profiles are in /etc and considered conffiles. so after modification on a related package update you might get a conffile prompt. worst case depending on configuration automatic updates might even override it and your custom rule is gone. – those provide variables that can be used in templates, for example if you want a custom dir considered as it would be a home directory you could modify /etc/apparmor.d/tunables/home which defines the base path rules use for home directories – by design those variables will only influence profiles that use them – to mitigate the drawbacks of above approaches local includes got introduced adding the ability to write arbitrary rules that will be used, and not get issues on upgrades that modify the packaged rule. – the files can be found in /etc/apparmor.d/local/ and exist for the packages that are known to sometimes need slight tweaks for special setups references • see the apparmor administration guide for advanced configuration options. • for details using apparmor with other ubuntu releases see the apparmor community wiki page. • the opensuse apparmor page is another introduction to apparmor. • (https://wiki.debian.org/apparmor) is another introduction and basic howto for apparmor. • a great place to ask for apparmor assistance, and get involved with the ubuntu server community, is the #ubuntu-hardened irc channel on freenode. firewall introduction the linux kernel includes the netfilter subsystem, which is used to manipulate or decide the fate of network traffic headed into or through your server. all modern linux firewall solutions use this system for packet filtering. the kernel’s packet filtering system would be of little use to administrators without a userspace interface to manage it. this is the purpose of iptables: when a packet reaches your server, it will be handed off to the netfilter subsystem for acceptance, manipulation, or rejection based on the rules supplied to it from userspace via iptables. thus, iptables is all you need to manage your firewall, if you’re familiar with it, but many frontends are available to simplify the task. 85

ufw - uncomplicated firewall the default firewall configuration tool for ubuntu is ufw. developed to ease iptables firewall configuration, ufw provides a user-friendly way to create an ipv4 or ipv6 host-based firewall. ufw by default is initially disabled. from the ufw man page: “ufw is not intended to provide complete firewall functionality via its command interface, but instead provides an easy way to add or remove simple rules. it is currently mainly used for host-based firewalls.” the following are some examples of how to use ufw: • first, ufw needs to be enabled. from a terminal prompt enter: sudo ufw enable • to open a port (ssh in this example): sudo ufw allow 22 • rules can also be added using a numbered format: sudo ufw i n s e r t 1 allow 80 • similarly, to close an opened port: sudo ufw deny 22 • to remove a rule, use delete followed by the rule: sudo ufw d e l e t e deny 22 • it is also possible to allow access from specific hosts or networks to a port. the following example allows ssh access from host 192.168.0.2 to any ip address on this host: sudo ufw allow proto tcp from 1 9 2 . 1 6 8 . 0 . 2 to any port 22 replace 192.168.0.2 with 192.168.0.0/24 to allow ssh access from the entire subnet. • adding the –dry-run option to a ufw command will output the resulting rules, but not apply them. * f i l t e r ### rules ### ### end rules ### for example, the following is what would be applied if opening the http port: sudo ufw−−dry−run allow http : ufw−user−input− [ 0 : 0 ] : ufw−user−output− [ 0 : 0 ] : ufw−user−forward− [ 0 : 0 ] : ufw−user−l i m i t− [ 0 : 0 ] : ufw−user−limit−accept− [ 0 : 0 ] −a ufw−user−input−p tcp−−dport 80−j accept −a ufw−user−input−j return −a ufw−user−output−j return −a ufw−user−forward−j return −a ufw−user−l i m i t−m l i m i t−−l i m i t 3/ minute−j log−−log−p r e f i x ” [ufw ### tuple ### allow tcp 80 0 . 0 . 0 . 0 / 0 any 0 . 0 . 0 . 0 / 0 limit ] : ” 86

−a ufw−user−l i m i t−j reject −a ufw−user−limit−accept−j accept commit rules updated • ufw can be disabled by: sudo ufw d i s a b l e • to see the firewall status, enter: sudo ufw status • and for more verbose status information use: sudo ufw status verbose • to view the numbered format: sudo ufw status numbered note if the port you want to open or close is defined in /etc/services, you can use the port name instead of the number. in the above examples, replace 22 with ssh. this is a quick introduction to using ufw. please refer to the ufw man page for more information. ufw application integration applications that open ports can include an ufw profile, which details the ports needed for the application to function properly. the profiles are kept in /etc/ufw/applications.d, and can be edited if the default ports have been changed. • to view which applications have installed a profile, enter the following in a terminal: sudo ufw app l i s t • similar to allowing traffic to a port, using an application profile is accomplished by entering: sudo ufw allow samba • an extended syntax is available as well: ufw allow from 192.168.0.0/24 to any app samba replace samba and 192.168.0.0/24 with the application profile you are using and the ip range for your network. note there is no need to specify the protocol for the application, because that information is detailed in the profile. also, note that the app name replaces the port number. • to view details about which ports, protocols, etc., are defined for an application, enter: sudo ufw app i n f o samba not all applications that require opening a network port come with ufw profiles, but if you have profiled an application and want the file to be included with the package, please file a bug against the package in launchpad. ubuntu−bug nameofpackage 87

ip masquerading the purpose of ip masquerading is to allow machines with private, non-routable ip addresses on your network to access the internet through the machine doing the masquerading. traffic from your private network destined for the internet must be manipulated for replies to be routable back to the machine that made the request. to do this, the kernel must modify the source ip address of each packet so that replies will be routed back to it, rather than to the private ip address that made the request, which is impossible over the internet. linux uses connection tracking (conntrack) to keep track of which connections belong to which machines and reroute each return packet accordingly. traffic leaving your private network is thus “masqueraded” as having originated from your ubuntu gateway machine. this process is referred to in microsoft documentation as internet connection sharing. ufw masquerading ip masquerading can be achieved using custom ufw rules. this is possible because the current back-end for ufw is iptables-restore with the rules files located in /etc/ufw/*.rules. these files are a great place to add legacy iptables rules used without ufw, and rules that are more network gateway or bridge related. the rules are split into two different files, rules that should be executed before ufw command line rules, and rules that are executed after ufw command line rules. • first, packet forwarding needs to be enabled in ufw. two configuration files will need to be adjusted, in /etc/default/ufw change the default_forward_policy to “accept”: default_forward_policy=”accept” then edit /etc/ufw/sysctl.conf and uncomment: net / ipv4 / ip_forward=1 similarly, for ipv6 forwarding uncomment: net / ipv6 / conf / d e f a u l t / forwarding=1 • now add rules to the /etc/ufw/before.rules file. the default rules only configure the filter table, and to enable masquerading the nat table will need to be configured. add the following to the top of the file just after the header comments: # nat table r u l e s *nat :postrouting accept [ 0 : 0 ] # forward t r a f f i c from eth1 through eth0 . −a postrouting−s 192.168.0.0/24−o eth0−j masquerade # don ’ t d e l e t e the these nat ’commit’ l i n e or table r u l e s won ’ t be processed commit the comments are not strictly necessary, but it is considered good practice to document your configu- ration. also, when modifying any of the rules files in /etc/ufw, make sure these lines are the last line for each table modified: # don ’ t d e l e t e the commit these r u l e s won ’ t be processed ’commit’ l i n e or for each table a corresponding commit statement is required. in these examples only the nat and filter tables are shown, but you can also add rules for the raw and mangle tables. 88

note in the above example replace eth0, eth1, and 192.168.0.0/24 with the appropriate interfaces and ip range for your network. • finally, disable and re-enable ufw to apply the changes: sudo ufw d i s a b l e && sudo ufw enable ip masquerading should now be enabled. you can also add any additional forward rules to the /etc/ ufw/before.rules. it is recommended that these additional rules be added to the ufw-before-forward chain. iptables masquerading iptables can also be used to enable masquerading. • similar to ufw, the first step is to enable ipv4 packet forwarding by editing /etc/sysctl .conf and uncomment the following line: net . ipv4 . ip_forward=1 if you wish to enable ipv6 forwarding also uncomment: net . ipv6 . conf . d e f a u l t . forwarding=1 • next, execute the sysctl command to enable the new settings in the configuration file: sudo s y s c t l−p sudo i p t a b l e s−t nat−a postrouting−s 192.168.0.0/16−o ppp0−j on your network configuration: masquerade • ip masquerading can now be accomplished with a single iptables rule, which may differ slightly based the above command assumes that your private address space is 192.168.0.0/16 and that your internet- facing device is ppp0. the syntax is broken down as follows: – -t nat – the rule is to go into the nat table – -a postrouting – the rule is to be appended (-a) to the postrouting chain – -s 192.168.0.0/16 – the rule applies to traffic originating from the specified address space – -o ppp0 – the rule applies to traffic scheduled to be routed through the specified network device – -j masquerade – traffic matching this rule is to “jump” (-j) to the masquerade target to be manipulated as described above • also, each chain in the filter table (the default table, and where most or all packet filtering occurs) has a default policy of accept, but if you are creating a firewall in addition to a gateway device, you may have set the policies to drop or reject, in which case your masqueraded traffic needs to be allowed through the forward chain for the above rule to work: sudo i p t a b l e s−a forward−s 192.168.0.0/16−o ppp0−j accept sudo i p t a b l e s−a forward−d 192.168.0.0/16−m s t a t e \ −−s t a t e established,related−i ppp0−j accept the above commands will allow all connections from your local network to the internet and all traffic related to those connections to return to the machine that initiated them. 89

• if you want masquerading to be enabled on reboot, which you probably do, edit /etc/rc. local and add any commands used above. for example add the first command with no filtering: i p t a b l e s−t nat−a postrouting−s 192.168.0.0/16−o ppp0−j masquerade logs firewall logs are essential for recognizing attacks, troubleshooting your firewall rules, and noticing unusual activity on your network. you must include logging rules in your firewall for them to be generated, though, and logging rules must come before any applicable terminating rule (a rule with a target that decides the fate of the packet, such as accept, drop, or reject). if you are using ufw, you can turn on logging by entering the following in a terminal: sudo ufw logging on to turn logging off in ufw, simply replace on with off in the above command. if using iptables instead of ufw, enter: sudo i p t a b l e s−a input−m s t a t e−−s t a t e new−p tcp−−dport 80 \ −j log−−log−p r e f i x ”new_http_conn: ” a request on port 80 from the local machine, then, would generate a log in dmesg that looks like this (single line split into 3 to fit this document): [4304885.870000] new_http_conn: in=lo out= mac = 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 0 : 0 8 : 0 0 src=127.0.0.1 dst=127.0.0.1 len=60 tos=0x00 prec=0x00 ttl=64 id=58288 df proto =tcp spt=53981 dpt=80 window=32767 res=0x00 syn urgp=0 the above log will also appear in /var/log/messages, /var/log/syslog, and /var/log/kern.log. this behavior can be modified by editing /etc/syslog.conf appropriately or by installing and configuring ulogd and using the ulog target instead of log. the ulogd daemon is a userspace server that listens for logging instructions from the kernel specifically for firewalls, and can log to any file you like, or even to a postgresql or mysql database. making sense of your firewall logs can be simplified by using a log analyzing tool such as logwatch, fwanalog, fwlogwatch, or lire. other tools there are many tools available to help you construct a complete firewall without intimate knowledge of iptables. a command-line tool with plain-text configuration files: • shorewall is a very powerful solution to help you configure an advanced firewall for any network. references • the ubuntu firewall wiki page contains information on the development of ufw. • also, the ufw manual page contains some very useful information: man ufw. • see the packet-filtering-howto for more information on using iptables. • the nat-howto contains further details on masquerading. • the iptables howto in the ubuntu wiki is a great resource. 90

certificates one of the most common forms of cryptography today is public-key cryptography. public-key cryptography utilizes a public key and a private key. the system works by encrypting information using the public key. the information can then only be decrypted using the private key. a common use for public-key cryptography is encrypting application traffic using a secure socket layer (ssl) or transport layer security (tls) connection. one example: configuring apache to provide https, the http protocol over ssl/tls. this allows a way to encrypt traffic using a protocol that does not itself provide encryption. a certificate is a method used to distribute a public key and other information about a server and the organization who is responsible for it. certificates can be digitally signed by a certification authority, or ca. a ca is a trusted third party that has confirmed that the information contained in the certificate is accurate. types of certificates to set up a secure server using public-key cryptography, in most cases, you send your certificate request (including your public key), proof of your company’s identity, and payment to a ca. the ca verifies the certificate request and your identity, and then sends back a certificate for your secure server. alternatively, you can create your own self-signed certificate. note note that self-signed certificates should not be used in most production environments. continuing the https example, a ca-signed certificate provides two important capabilities that a self- signed certificate does not: • browsers (usually) automatically recognize the ca signature and allow a secure connection to be made without prompting the user. • when a ca issues a signed certificate, it is guaranteeing the identity of the organization that is providing the web pages to the browser. most of the software supporting ssl/tls have a list of cas whose certificates they automatically accept. if a browser encounters a certificate whose authorizing ca is not in the list, the browser asks the user to either accept or decline the connection. also, other applications may generate an error message when using a self-signed certificate. the process of getting a certificate from a ca is fairly easy. a quick overview is as follows: 1. create a private and public encryption key pair. 2. create a certificate signing request based on the public key. the certificate request contains information about your server and the company hosting it. 3. send the certificate request, along with documents proving your identity, to a ca. we cannot tell you which certificate authority to choose. your decision may be based on your past experiences, or on the experiences of your friends or colleagues, or purely on monetary factors. once you have decided upon a ca, you need to follow the instructions they provide on how to obtain a certificate from them. 4. when the ca is satisfied that you are indeed who you claim to be, they send you a digital certificate. 5. install this certificate on your secure server, and configure the appropriate applications to use the certificate. 91

generating a certificate signing request (csr) whether you are getting a certificate from a ca or generating your own self-signed certificate, the first step is to generate a key. if the certificate will be used by service daemons, such as apache, postfix, dovecot, etc., a key without a passphrase is often appropriate. not having a passphrase allows the services to start without manual intervention, usually the preferred way to start a daemon. this section will cover generating a key with a passphrase, and one without. the non-passphrase key will then be used to generate a certificate that can be used with various service daemons. warning running your secure service without a passphrase is convenient because you will not need to enter the passphrase every time you start your secure service. but it is insecure and a compromise of the key means a compromise of the server as well. to generate the keys for the certificate signing request (csr) run the following command from a terminal prompt: openssl genrsa−des3−out generating rsa private key , 2048 b i t . . . . . . . . . . . . . . . . . . . . . . . . . . + + + + + + .......++++++ e i s 65537 (0 x10001 ) enter pass phrase f o r s e r v e r . key : s e r v e r . key 2048 long modulus you can now enter your passphrase. for best security, it should at least contain eight characters. the minimum length when specifying−des3 is four characters. as a best practice it should include numbers and/or punctuation and not be a word in a dictionary. also remember that your passphrase is case-sensitive. re-type the passphrase to verify. once you have re-typed it correctly, the server key is generated and stored in the server .key file. now create the insecure key, the one without a passphrase, and shuffle the key names: openssl mv s e r v e r . key s e r v e r . key . secure mv s e r v e r . key . i n s e c u r e s e r v e r . key s e r v e r . key . i n s e c u r e the insecure key is now named server .key, and you can use this file to generate the csr without passphrase. to create the csr, run the following command at a terminal prompt: openssl s e r v e r . c s r rsa−in s e r v e r . key−out req−new−key s e r v e r . key−out it will prompt you enter the passphrase. if you enter the correct passphrase, it will prompt you to enter company name, site name, email id, etc. once you enter all these details, your csr will be created and it will be stored in the server . csr file. you can now submit this csr file to a ca for processing. the ca will use this csr file and issue the certificate. on the other hand, you can create self-signed certificate using this csr. creating a self-signed certificate to create the self-signed certificate, run the following command at a terminal prompt: openssl x509−req−days 365−in s e r v e r . c s r−signkey s e r v e r . key−out 92 s e r v e r . c r t

the above command will prompt you to enter the passphrase. once you enter the correct passphrase, your certificate will be created and it will be stored in the server . crt file. warning if your secure server is to be used in a production environment, you probably need a ca-signed certificate. it is not recommended to use self-signed certificate. installing the certificate you can install the key file server .key and certificate file server . crt, or the certificate file issued by your ca, by running following commands at a terminal prompt: sudo cp s e r v e r . c r t / etc / s s l / c e r t s sudo cp s e r v e r . key / etc / s s l / private now simply configure any applications, with the ability to use public-key cryptography, to use the certificate and key files. for example, apache can provide https, dovecot can provide imaps and pop3s, etc. certification authority if the services on your network require more than a few self-signed certificates it may be worth the additional effort to setup your own internal certification authority (ca). using certificates signed by your own ca, allows the various services using the certificates to easily trust other services using certificates issued from the same ca. first, create the directories to hold the ca certificate and related files: sudo mkdir / etc / s s l /ca sudo mkdir / etc / s s l / newcerts the ca needs a few additional files to operate, one to keep track of the last serial number used by the ca, each certificate must have a unique serial number, and another file to record which certificates have been issued: sudo sh−c ” echo ’01 ’ > / etc / s s l /ca/ s e r i a l ” sudo touch / etc / s s l /ca/ index . txt the third file is a ca configuration file. though not strictly necessary, it is very convenient when issuing multiple certificates. edit /etc/ssl/openssl.cnf, and in the [ ca_default ] change: d i r database c e r t i f i c a t e s e r i a l private_key = / etc / s s l = $dir /ca/ index . txt = $dir / c e r t s / cacert . pem # the ca c e r t i f i c a t e = $dir /ca/ s e r i a l = $dir / private / cakey . pem# the private key # where everything i s kept # database index f i l e . # the current s e r i a l number next, create the self-signed root certificate: openssl req−new−x509−extensions v3_ca−keyout cakey . pem−out cacert . pem− days 3650 you will then be asked to enter the details about the certificate. now install the root certificate and key: sudo mv cakey . pem / etc / s s l / private / sudo mv cacert . pem / etc / s s l / c e r t s / 93

you are now ready to start signing certificates. the first item needed is a certificate signing request (csr), see generating a certificate signing request (csr) for details. once you have a csr, enter the following to generate a certificate signed by the ca: sudo openssl ca−in s e r v e r . c s r−c o n f i g / etc / s s l / openssl . cnf after entering the password for the ca key, you will be prompted to sign the certificate, and again to commit the new certificate. you should then see a somewhat large amount of output related to the certificate creation. there should now be a new file, /etc/ssl/newcerts/01.pem, containing the same output. copy and paste everything beginning with the line: —–begin certificate—– and continuing through the line: —- end certificate—– lines to a file named after the hostname of the server where the certificate will be installed. for example mail.example.com.crt, is a nice descriptive name. subsequent certificates will be named 02.pem, 03.pem, etc. note replace mail.example.com.crt with your own descriptive name. finally, copy the new certificate to the host that needs it, and configure the appropriate applications to use it. the default location to install certificates is /etc/ssl/certs. this enables multiple services to use the same certificate without overly complicated file permissions. for applications that can be configured to use a ca certificate, you should also copy the /etc/ssl/certs/ cacert.pem file to the /etc/ssl/certs/ directory on each server. references • the wikipedia https page has more information regarding https. • for more information on openssl see the openssl home page. • also, o’reilly’s network security with openssl is a good in-depth reference. console security as with any other security barrier you put in place to protect your server, it is pretty tough to defend against untold damage caused by someone with physical access to your environment, for example, theft of hard drives, power or service disruption, and so on. therefore, console security should be addressed merely as one component of your overall physical security strategy. a locked “screen door” may deter a casual criminal, or at the very least slow down a determined one, so it is still advisable to perform basic precautions with regard to console security. the following instructions will help defend your server against issues that could otherwise yield very serious consequences. disable ctrl+alt+delete anyone that has physical access to the keyboard can simply use the ctrl+alt+delete key combination to reboot the server without having to log on. while someone could simply unplug the power source, you should still prevent the use of this key combination on a production server. this forces an attacker to take more drastic measures to reboot the server, and will prevent accidental reboots at the same time. to disable the reboot action taken by pressing the ctrl+alt+delete key combination, run the following two commands: 94

sudo systemctl mask c t r l−alt−del . target sudo systemctl daemon−reload ecryptfs is deprecated ecryptfs is deprecated and should not be used, instead the luks setup as defined by the ubuntu installer is recommended. that in turn - for a typical remote server setup will need a remote key store as usually no one is there to enter a key on boot. virtualization is being adopted in many different environments and situations. if you are a developer, virtualization can provide you with a contained environment where you can safely do almost any sort of development safe from messing up your main working environment. if you are a systems administrator, you can use virtualization to more easily separate your services and move them around based on demand. the default virtualization technology supported in ubuntu is kvm. for intel and amd hardware kvm requires virtualization extensions. but kvm is also available for ibm z and linuxone, ibm power as well as for arm64. qemu is part of the kvm experience being the userspace backend for it, but it also can be used for hardware without virtualization extensions by using its tcg mode. while virtualization is in many ways similar to containers those are different and implemented via other solutions like lxd, systemd-nspawn, containerd and others. multipass is the recommended method to create ubuntu vms on ubuntu. it’s designed for developers who want a fresh ubuntu environment with a single command and works on linux, windows and macos. on linux it’s available as a snap: sudo snap i n s t a l l multipass−−beta−−c l a s s i c usage find available images find $ multipass image core core18 16.04 18.04 18.10 19.04 d a i l y : 1 9 . 1 0 a l i a s e s core16 x e n i a l bionic , l t s cosmic disco devel , eoan version 20190424 20190213 20190628 20190627.1 20190628 20190628 20190623 description ubuntu core 16 ubuntu core 18 ubuntu 16.04 lts ubuntu 18.04 lts ubuntu 18.10 ubuntu 19.04 ubuntu 19.10 launch a fresh instance of the current ubuntu lts $ multipass launch ubuntu launching dancing−chipmunk . . . downloading ubuntu 18.04 lts . . . . . . . . . . launched : dancing chipmunk check out the running instances 95

ipv4 10.125.174.247 10.125.174.243 release ubuntu 18.04 lts ubuntu 18.04 lts ubuntu snapcraft −− l i s t $ multipass name dancing−chipmunk l i v e−naiad snapcraft−asciinema b u i l d e r f o r core 18 state running running stopped learn more about the vm instance you just launched $ multipass name: state : ipv4 : release : image hash : load : disk usage : memory usage : i n f o dancing−chipmunk dancing−chipmunk running 10.125.174.247 ubuntu 1 8 . 0 4 . 1 lts 19 e9853d8267 (ubuntu 18.04 lts) 0.97 0.30 0.10 1.1g out of 4.7g 85.1m out of 985.4m $ multipass connect to a running instance welcome to ubuntu 1 8 . 0 4 . 1 lts (gnu/linux 4.15.0−42− g e n e r i c x86_64 ) s h e l l dancing−chipmunk . . . don’t forget to logout (or ctrl-d) or you may find yourself heading all the way down the inception levels… ;) run commands inside an instance from outside $ multipass exec dancing−chipmunk−− l s b _ r e l e a s e−a no lsb modules are a v a i l a b l e . d i s t r i b u t o r id : ubuntu description : release : codename : ubuntu 1 8 . 0 4 . 1 lts 18.04 bio nic $ multipass delete the instance stop an instance to save resources stop dancing−chipmunk $ multipass d e l e t e dancing−chipmunk it will now show up as deleted: $ multipass list name state ipv4 release snapcraft−asciinema stopped −− ubuntu snapcraft builder for core 18 dancing−chipmunk deleted−− not available and when you want to completely get rid of it: $ multipass purge 96

integrate into the rest of your virtualization you might have other virtualization already based on libvirt either through using the similar older uvtool already or through the common virt-manager. you might for example want those guests to be on the same bridge to communicate to each other or you need access to the graphical output for some reason. fortunately it is possible to integrate this by using the libvirt backend of multipass $ sudo multipass l o c a l . d r i v e r=l i b v i r t s e t after that when you start a guest you can also access it via tools like virt-manager or virsh $ multipass launch ubuntu $ v i r s h l i s t id name launched : engaged−amberjack −−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− engaged−amberjack running state 15 get help multipass help multipass help <command> see the multipass documentation for more details. qemu qemu is a machine emulator that can run operating systems and programs for one machine on a different machine. mostly it is not used as emulator but as virtualizer in collaboration with kvm kernel components. in that case it utilizes the virtualization technology of the hardware to virtualize guests. while qemu has a command line interface and a monitor to interact with running guests those is rarely used that way for other means than development purposes. libvirt provides an abstraction from specific versions and hypervisors and encapsulates some workarounds and best practices. running qemu/kvm while there are much more user friendly and comfortable ways, using the command below is probably the quickest way to see some called ubuntu moving on screen is directly running it from the netboot iso. warning: this is just for illustration - not generally recommended without verifying the check- sums; multipass and uvtool are much better ways to get actual guests easily. run: sudo qemu−system−x86_64−enable−kvm−cdrom http://archive.ubuntu.com/ubuntu/dists/ bionic−updates/main/installer−amd64/current/images/netboot/mini.iso • creating the disk > qemu−img create−f qcow2 disk.qcow 5g you could download the iso for faster access at runtime and e.g. add a disk to the same by: 97

• using the disk by adding−drive file =disk.qcow,format=qcow2 those tools can do much more, as you’ll find in their respective (long) man pages. there also is a vast assortment of auxiliary tools to make them more consumable for specific use-cases and needs - for example virt-manager for ui driven use through libvirt. but in general - even the tools eventually use that - it comes down to: qemu-system-x86_64 options image[s] so take a look at the man page of qemu, qemu-img and the documentation of qemu and see which options are the right one for your needs. graphics graphics for qemu/kvm always comes in two pieces. the graphical content. that can be an application window via gtk or a vnc. and provides more authentication methods than vnc. std, qxl, virtio . the default these days is qxl which strikes a good balance between guest compatibility and performance. the guest needs a driver for what is selected, which is the most common reason to switch from the default to either cirrus (e.g. very old windows versions) more about these in the libvirt section. all those options above are considered basic usage of graphics. there are advanced options for further needs. those cases usually differ in their ease-of-use and capability are: • a front end - controlled via the−vga argument - which is provided to the guest. usually one of cirrus, • a back end - controlled via the−display argument - which is what the host uses to actually display • in addition one can enable the−spice back-end (can be done in addition to vnc) which can be faster • if you want no graphical output at all you can save some memory and cpu cycles by setting−nographic if you run with spice or vnc you can use native vnc tools or virtualization focused tools like virt−viewer. • need some 3d acceleration:−vga virtio with a local display having a gl context−display gtk,gl=on; −device vfio−pci,host=05:00.0,bus=1,addr=00.0,multifunction=on,x−vga=on−device vfio−pci,host devices to shard a card on the host into multiple devices and pass those like−display gtk,gl =on−device vfio−pci,sysfsdev=/sys/bus/pci/devices/0000:00:02.0/4dd511f6−ec08−11e8−b839−2 that will use virgil3d on the host and needs guest drivers for [virt3d] which are common in linux since kernels >=4.4 but hard to get by for other cases. while not as fast as the next two options, the big benefit is that it can be used without additional hardware and without a proper iommu setup for device passthrough. • need native performance: use pci passthrough of additional gpus in the system. you’ll need an iommu setup and unbind the cards from the host before you can pass it through like =05:00.1,bus=1,addr=00.1 • need native performance, but multiple guests per card: like pci passthrough, but using mediated f163ddee3b3,display=on,rombar=0. more at kraxel on vgpu and ubuntu gpu mdev evaluation. the sharding of the cards is driver specific and therefore will differ per manufacturer like intel or nvidia. especially the advanced cases can get pretty complex, therefore it is recommended to use qemu through libvirt for those cases. libvirt will take care of all but the host kernel/bios tasks of such configurations. upgrading the machine type if you are unsure what this is, you might consider this as buying (virtual) hardware of the same spec but a newer release date. you are encouraged in general and might want to update your machine type of an existing defined guests in particular to: • to pick up latest security fixes and features 98

• continue using a guest created on a now unsupported release # should now l i s t your machine as ” shut o f f ” in general it is recommended to update machine types when upgrading qemu/kvm to a new major version. but this can likely never be an automated task as this change is guest visible. the guest devices might change in appearance, new features will be announced to the guest and so on. linux is usually very good at tolerating such changes, but it depends so much on the setup and workload of the guest that this has to be evaluated by the owner/admin of the system. other operating systems where known to often have severe impacts by changing the hardware. consider a machine type change similar to replacing all devices and firmware of a physical machine to the latest revision - all considerations that apply there apply to evaluating a machine type upgrade as well. as usual with major configuration changes it is wise to back up your guest definition and disk state to be able to do a rollback just in case. there is no integrated single command to update the machine type via virsh or similar tools. it is a normal part of your machine definition. and therefore updated the same way as most others. first shutdown your machine and wait until it has reached that state. v i r s h shutdown <yourmachine> # wait change this to the value you want. if you need to check what types are available via “-m ?” note that while providing upstream types as convenience only ubuntu types are supported. there you can also see what the current default would be. in general it is strongly recommended that you change to newer types if possible to exploit newer features, but also to benefit of bugfixes that only apply to the newer device virtualization. then edit the machine definition and find the type in the type tag at the machine attribute. v i r s h e d i t <yourmachine> v i r s h l i s t −−i n a c t i v e <type arch=’x86_64 ’ machine=’pc−i440fx−bionic ’>hvm</type> kvm−m ? pc−i440fx−x e n i a l pc−i440fx−bioni c v i r s h dumpxml <yourmachine> | xmllint−−xpath ” s t r i n g (// domain/ os / type / @machine ) ”− sudo dmidecode | grep product−a 1 version : pc−i440fx−bioni c after this you can start your guest again. you can check the current machine type from guest and host depending on your needs. v i r s h s t a r t <yourmachine> # check from host , via dumping the a c t i v e xml d e f i n i t i o n if you keep non-live definitions around - like xml files - remember to update those as well. # or from the guest via dmidecode ( i f supported ) ubuntu 16.04 pc ( i440fx + piix , 1996) ( d e f a u l t ) ubuntu 18.04 pc ( i440fx + piix , 1996) ( d e f a u l t ) # l i s t s machine types , e . g . . . . . . . product name: standard pc ( i440fx + piix , 1996) note this also is documented along some more constraints and considerations at the ubuntu wiki 99

100

qemu usage for microvms for example if you happen to already have a stripped down workload that has all it would execute in an initrd you would run it maybe like the following: qemu became another use case being used in a container-like style providing an enhanced isolation compared to containers but being focused on initialization speed. to achieve that several components have been added: - the microvm machine type - alternative simple fw that can boot linux called qboot - qemu build with reduced features matching these use cases called qemu−system−x86−microvm $ sudo qemu−system−x86_64−m ubuntu−q35−cpu host−m 1024−enable−kvm−serial mon:stdio− nographic−display curses−append ’console=ttys0,115200,8n1’−kernel vmlinuz−5.4.0−21−initrd /boot/ initrd.img−5.4.0−21−workload 1. run it with with type microvm, so change -m to−m microvm 2. use the qboot bios, add−bios /usr/share/qemu/bios−microvm.bin 3. install the feature-minimized qemu-system package, do $ sudo apt install qemu−system−x86− to run the same with microvm, qboot and the minimized qemu you would do the following microvm an invocation will now look like: $ sudo qemu-system-x86_64 -m microvm -bios /usr/share/qemu/bios-microvm.bin -cpu host -m 1024 -enable- kvm -serial mon:stdio -nographic -display curses -append ‘console=ttys0,115200,8n1’ -kernel vmlinuz-5.4.0-21 -initrd /boot/initrd.img-5.4.0-21-workload that will have cut down the qemu, bios and virtual-hw initialization time down a lot. you will now - more than you already have before - spend the majority inside the guest which implies that further tuning probably has to go into that kernel and userspace initialization time. ** note ** for now microvm, the qboot bios and other components of this are rather new upstream and not as verified as many other parts of the virtualization stack. therefore none of the above is the default. further being the default would also mean many upgraders would regress finding a qemu that doesn’t have most features they are used to use. due to that the qemu-system-x86-microvm package is intentionally a strong opt-in conflicting with the normal qemu-system-x86 package. libvirt the libvirt library is used to interface with different virtualization technologies. before getting started with libvirt it is best to make sure your hardware supports the necessary virtualization extensions for kvm. enter the following from a terminal prompt: a message will be printed informing you if your cpu does or does not support hardware virtualization. note on many computers with processors supporting hardware assisted virtualization, it is necessary to activate an option in the bios to enable it. 100 kvm−ok

101

virtual networking there are a few different ways to allow a virtual machine access to the external network. the default virtual network configuration includes bridging and iptables rules implementing usermode networking, which uses the slirp protocol. traffic is nated through the host interface to the outside network. to enable external hosts to directly access services on virtual machines a different type of bridge than the default needs to be configured. this allows the virtual interfaces to connect to the outside network through the physical interface, making them appear as normal hosts to the rest of the network. there is a great example how to configure an own bridge and combining it with libvirt so that guests will use it at the netplan.io. installation to install the necessary packages, from a terminal prompt enter: sudo apt update sudo apt i n s t a l l qemu−kvm l i b v i r t−daemon−system after installing libvirt-daemon-system, the user used to manage virtual machines will need to be added to the libvirt group. this is done automatically for members of the sudo group, but needs to be done in additon for anyone else that should access system wide libvirt resources. doing so will grant the user access to the advanced networking options. in a terminal enter: sudo adduser $user l i b v i r t note if the user chosen is the current user, you will need to log out and back in for the new group membership to take effect. you are now ready to install a guest operating system. installing a virtual machine follows the same process as installing the operating system directly on the hardware. you either need: - a way to automate the installation - a keyboard and monitor will need to be attached to the physical machine. - use cloud images which are meant to self-initialize (see multipass and uvtool) in the case of virtual machines a graphical user interface (gui) is analogous to using a physical keyboard and mouse on a real computer. instead of installing a gui the virt-viewer or virt-manager application can be used to connect to a virtual machine’s console using vnc. see virtual machine manager / viewer for more information. virtual machine management the following section covers the command-line tools around virsh that are part of libvirt itself. but there are various options at different levels of complexities and feature-sets, like: • multipass • uvt • virt-* tools • openstack 101

102

virsh there are several utilities available to manage virtual machines and libvirt. the virsh utility can be used from the command line. some examples: • to list running virtual machines: v i r s h l i s t • to start a virtual machine: v i r s h s t a r t <guestname> • similarly, to start a virtual machine at boot: v i r s h autostart <guestname> • reboot a virtual machine with: v i r s h reboot <guestname> • the state of virtual machines can be saved to a file in order to be restored later. the following will once saved the virtual machine will no longer be running. • a saved virtual machine can be restored using: save the virtual machine state into a file named according to the date: v i r s h save <guestname> save−my. s t a t e v i r s h r e s t o r e save−my. s t a t e v i r s h attach−disk <guestname> /dev/cdrom /media/cdrom • to shutdown a virtual machine do: v i r s h shutdown <guestname> • to change the definition of a guest virsh exposes the domain via v i r s h e d i t <guestname> • a cdrom device can be mounted in a virtual machine by entering: that will allow one to edit the xml representation that defines the guest and when saving it will apply format and integrity checks on these definitions. editing the xml directly certainly is the most powerful way, but also the most complex one. tools like virtual machine manager / viewer can help unexperienced users to do most of the common tasks. if virsh (or other vir* tools) shall connect to something else than the default qemu-kvm/system hipervisor one can find alternatives for the connect option in man virsh or libvirt doc system and session scope virsh - as well as most other tools to manage virtualization - can be passed connection strings. $ virsh –connect qemu:///system there are two options for the connection. • qemu:///system - connect locally as root to the daemon supervising qemu and kvm domains 102

103

• qemu:///session - connect locally as a normal user to his own set of qemu and kvm domains the default always was (and still is) qemu:///system as that is the behavior users are used to. but there are a few benefits (and drawbacks) to qemu:///session to consider it. qemu:///session is per user and can on a multi-user system be used to separate the people. but most importantly things run under the permissions of the user which means no permission struggle on the just donwloaded image in your $home or the just attached usb-stick. on the other hand it can’t access system resources that well, which includes network setup that is known to be hard with qemu:///session. it falls back to slirp networking which is functional but slow and makes it impossible to be reached from other systems. qemu:///system is different in that it is run by the global system wide libvirt that can arbitrate resources as needed. but you might need to mv and/or chown files to the right places permssions to have them usable. applications usually will decide on their primary use-case. desktop-centric applications often choose qemu :///session while most solutions that involve an administrator anyway continue to default to qemu:///system. read more about that in the libvirt faq and this blog about the topic. migration there are different types of migration available depending on the versions of libvirt and the hipervisor being used. in general those types are: • offline migration • live migration • postcopy migration there are various options to those methods, but the entry point for all of them is virsh migrate. read the integrated help for more detail. some useful documentation on constraints and considerations about live migration can be found at the ubuntu wiki v i r s h migrate−−help device passthrough / hotplug if instead of the here described hotplugging you want to always pass through a device add the xml content of the device to your static guest xml representation via e.g. virsh edit <guestname>. in that case you don’t need to use attach/detach. there are different kinds of passthrough. types available to you depend on your hardware and software setup. • usb hotplug/passthrough • vf hotplug/passthrough but both kinds are handled in a very similar way and while there are various way to do it (e.g. also via qemu monitor) driving such a change via libvirt is recommended. that way libvirt can try to manage all sorts of special cases for you and also somewhat masks version differences. in general when driving hotplug via libvirt you create a xml snippet that describes the device just as you would do in a static guest description. a usb device is usually identified by vendor/product id’s: <hostdev mode=’subsystem ’ type=’usb ’ managed=’yes ’> <source> <vendor id =’0x0b6d ’/> 103

104

<product </source> </hostdev> id =’0x3880 ’/> virtual functions are usually assigned via their pci-id (domain, bus, slot, function). <hostdev mode=’subsystem ’ type=’pci ’ managed=’yes ’> <address domain=’0x0000 ’ bus=’0x04 ’ s l o t =’0x10 ’ function =’0x0’/> <source> </source> </hostdev> note to get the virtual function in the first place is very device dependent and can therefore not be fully covered here. but in general it involves setting up an iommu, registering via vfio and sometimes requesting a number of vfs. here an example on ppc64el to get 4 vfs on a device: sudo tee / sys /bus/ pci / d r i v e r s / vfio−pci /new_id sudo tee / sys /bus/ pci / devices /0005\:01\:00.0/ sriov_numvfs you then attach or detach the device via libvirt by relating the guest with the xml snippet. # i d e n t i f y device 0 0 0 5 : 0 1 : 0 1 . 3 0200: 10 df : e228 ( rev 10) # r e g i s t e r and request vfs $ echo 10 df e228 | $ echo 4 | $ sudo modprobe vfio−pci $ l s p c i−n−s 0 0 0 5 : 0 1 : 0 1 . 3 v i r s h attach−device <guestname> <device−xml> v i r s h detach−device <guestname> <device−xml> # use the device i n t the guest access qemu monitor via libvirt libvirt covers most use cases needed, but if you every want/need to work around libvirt or want to tweak very special options you can e.g. add a device that way: the qemu monitor is the way to interact with qemu/kvm while a guest is running. this interface has many and very powerful features for experienced users. when running under libvirt that monitor interface is bound by libvirt itself for management purposes, but a user can run qemu monitor commands via libvirt still. the general syntax is virsh qemu−monitor−command [options] [guest] ’command’ v i r s h qemu−monitor−command−−hmp focal−test−log ’ drive_add 0 i f=none , f i l e =/var v i r s h qemu−monitor−command−−hmp y−ipns but since the monitor is so powerful, you can do a lot especially for debugging purposes like showing the guest registers: rax=00 f f f f c 0 0 0 0 0 0 0 0 0 rbx=f f f f 8 f 0 f 5 d 5 c 7 e 4 8 rcx=0000000000000000 rdx= / l i b / l i b v i r t / images / t e s t . img , format=raw , id=disk1 ’ rsi=0000000000000000 rdi=f f f f 8 f 0 f d d 5 c 7 e 4 8 rbp=f f f f 8 f 0 f 5 d 5 c 7 e 1 8 rsp= f f f f e a 0 0 0 0 7 5 7 1 c 0 ’ i n f o r e g i s t e r s ’ f f f f 8 f 0 f 5 d 5 c 7 d f 8 [ . . . ] 104

105

huge pages using huge pages can help to reduce tlb pressure, page table overhead and speed up some further memory relate actions. furthermore by default transparent huge pages are useful, but can be quite some overhead - so if it is clear that using huge pages is preferred making them explicit usually has some gains. while huge page are admittedly harder to manage, especially later in the lifetime of a system if memory is fragmented they provide a useful boost especially for rather large guests. bonus: when using device pass through on very large guests there is an extra benefit of using huge pages as it is faster to do the initial memory clear on vfio dma pin. huge page allocation huge pages come in different sizes. a normal page usually is 4k and huge pages are eithe 2m or 1g, but depending on the architecture other options are possible. the most simple, yet least reliable way to allocate some huge pages is to just echo a value to sysfs be sure to re-check if it worked. $ echo 256 | $ cat / sys / kernel /mm/ hugepages /hugepages−2048kb/nr_hugepages sudo tee / sys / kernel /mm/ hugepages /hugepages−2048kb/nr_hugepages there one of these sizes is “default huge page size” which will be used in the auto-mounted /dev/hugepages. changing the default size requires a reboot and is set via default_hugepagesz you can check the current default size: $ grep hugepagesize / proc /meminfo hugepagesize : 2048 kb 256 but there can be more than one at the same time one better check: $ t a i l / sys / kernel /mm/ hugepages /hugepages−*/nr_hugepages ‘ ==> / sys / kernel /mm/ hugepages /hugepages−1048576kb/nr_hugepages <== ==> / sys / kernel /mm/ hugepages /hugepages−2048kb/nr_hugepages <== 0 2 and even that could on bigger systems be further split per numa node. one can allocate huge pages at boot or runtime, but due to fragmentation there are no guarantees it works later. the kernel documentation lists details on both ways. huge pages need to be allocated by the kernel as mentioned above but to be consumable they also have to be mounted. by default systemd will make /dev/hugepages available for the default huge page size. feel free to add more mount points if you need different sized. an overview can be queried with options rw , relatime , pagesize=2m a one-stop info for the overall huge page status of the system can be reported with mount point /dev/ hugepages $ hugeadm−−l i s t−a l l−mounts $ hugeadm−−explain 105

106

huge page usage in libvirt with the above in place libvirt can map guest memory to huge pages. in a guest definition add the most simple form of <memorybacking> <hugepages/> </memorybacking> that will allocate the huge pages using the default huge page size from a autodetected mountpoint. for more control e.g. how memory is spread over numa nodes or which page size to use check out the details at the libvirt doc. apparmor isolation • a dynamic part created at guest start time and modified on hotplug/unplug => /etc/apparmor.d/ by default libvirt will spawn qemu guests using apparmor isolation for enhanced security. the apparmor rules for a guest will consist of multiple elements: • a static part that all guests share => /etc/apparmor.d/abstractions/libvirt−qemu libvirt/libvirt−f9533e35−6b63−45f5−96be−7cccc9696d5e.files of the above the former is provided and updated by the libvirt−daemon package and the latter is generated on guest start. none of the two should be manually edited. they will by default cover the vast majority of use cases and work fine. but there are certain cases where users either want to: • further lock down the guest (e.g. by explicitly denying access that usually would be allowed) • open up the guest isolation (most of the time this is needed if the setup on the local machine does not follow the commonly used paths. to do so there are two files to do so. both are local overrides which allow you to modify them without getting them clobbered or command file prompts on package upgrades. rather powerful, but also a rather blunt tool. it is a quite useful place thou to add additional deny rules. • /etc/apparmor.d/local/abstractions/libvirt−qemu this will be applied to every guest. therefore it is • /etc/apparmor.d/local/usr.lib. libvirt . virt−aa−helper the above mentioned dynamic part that is in- dividual per guest is generated by a tool called libvirt . virt−aa−helper. that is under apparmor isolation as well. this is most commonly used if you want to use uncommon paths as it allows to ahve those uncommon paths in the guest xml (see virsh edit) and have those paths rendered to the per-guest dynamic rules. resources • see the kvm home page for more details. • for more information on libvirt see the libvirt home page – xml configuration of domains and storage being the most often used libvirt reference • another good resource is the ubuntu wiki kvm page. • for basics how to assign vt-d devices to qemu/kvm, please see the linux-kvm page. 106

107

cloud images and uvtool introduction with ubuntu being one of the most used operating systems on many cloud platforms, the availability of stable and secure cloud images has become very important. as of 12.04 the utilization of cloud images outside of a cloud infrastructure has been improved. it is now possible to use those images to create a virtual machine without the need of a complete installation. creating virtual machines using uvtool starting with 14.04 lts, a tool called uvtool greatly facilitates the task of generating virtual machines (vm) using the cloud images. uvtool provides a simple mechanism to synchronize cloud-images locally and use them to create new vms in minutes. uvtool packages the following packages and their dependencies will be required in order to use uvtool: • uvtool • uvtool-libvirt to install uvtool, run: $ sudo apt−y i n s t a l l uvtool this will install uvtool’s main commands: • uvt-simplestreams-libvirt • uvt-kvm get the ubuntu cloud image with uvt-simplestreams-libvirt this is one of the major simplifications that uvtool brings. it is aware of where to find the cloud images so only one command is required to get a new cloud image. for instance, if you want to synchronize all cloud images for the amd64 architecture, the uvtool command would be: after an amount of time required to download all the images from the internet, you will have a complete set of cloud images stored locally. to see what has been downloaded use the following command: $ uvt−simplestreams−l i b v i r t−−verbose sync arch=amd64 $ uvt−simplestreams−l i b v i r t query $ uvt−simplestreams−l i b v i r t r e l e a s e=bio nic arch=amd64 l a b e l=d a i l y (20191107) r e l e a s e=f o c a l arch=amd64 l a b e l=d a i l y (20191029) . . . in the case where you want to synchronize only one specific cloud-image, you need to use the release= and arch= filters to identify which image needs to be synchronized. sync r e l e a s e=distro−short−codename arch=amd64 107

108

furthermore you can provide an alternative url to fetch images from. a common case are the daily images which helps to get the very latest images or if you need access to the not yet released development release of ubuntu. $ uvt−simplestreams−l i b v i r t f u r t h e r options ] [ . . . sync−−source http :// cloud−images . ubuntu . com/ d a i l y create the vm using uvt-kvm f i l e in which to save the key (/home/ubuntu /. ssh / id_rsa ) : in order to connect to the virtual machine once it has been created, you must have a valid ssh key available for the ubuntu user. if your environment does not have an ssh key, you can easily create one using the following command: generating public / private rsa key pair . enter enter passphrase ( empty f o r no passphrase ) : enter same passphrase again : your i d e n t i f i c a t i o n has been saved in /home/ubuntu /. ssh / id_rsa . your public key has been saved in /home/ubuntu /. ssh / id_rsa . pub . the key f i n g e r p r i n t $ ssh−keygen 4d : ba :5 d : 5 7 : c9 : 4 9 : e f : b5 : ab : 7 1 : 1 4 : 5 6 : 6 e :2 b : ad :9 b ubuntu@distro−short−codenames +−−[ rsa 2048]−−−−+ the key ’ s randomart image i s : i s : to create of a new virtual machine using uvtool, run the following in a terminal: this will create a vm named firsttest using the current lts cloud image available locally. if you want to specify a release to be used to create the vm, you need to use the release= filter: uvt-kvm wait can be used to wait until the creation of the vm has completed: r e l e a s e=distro−short−codename | | | | | | | | | . + s . o . . . . . | o .=| **| o+=| . . . = . | .+ . | o o | | * | e f i r s t t e s t +−−−−−−−−−−−−−−−−−+ $ uvt−kvm create $ uvt−kvm create secondtest $ uvt−kvm wait $ uvt−kvm ssh secondtest connect to the running vm s e co n d tt e s t once the virtual machine creation is completed, you can connect to it using ssh: you can also connect to your vm using a regular ssh session using the ip address of the vm. the address can be queried using the following command: 108

109

secondtest $ uvt−kvm l i s t $ uvt−kvm destroy secondtest destroy your vm once you are done with your vm, you can destroy it with: 192.168.122.199 $ uvt−kvm ip secondtest $ ssh−i ~/. ssh / id_rsa ubuntu@192 . 1 6 8 . 1 2 2 . 1 9 9 [ . . . ] to run a command as administrator see ”man sudo_root ” f o r d e t a i l s . ( user ” root ”) , use ” sudo <command>”. ubuntu@secondtest :~ $ get the list of running vms you can get the list of vms running on your system with this command: note: other than libvirts destroy action this will by default also remove the associated virtual storage files. more uvt-kvm options the following options can be used to change some of the characteristics of the vm that you are creating: • --memory : amount of ram in megabytes. default: 512. • --disk : size of the os disk in gigabytes. default: 8. • --cpu : number of cpu cores. default: 1. some other parameters will have an impact on the cloud-init configuration: • --password password : allow login to the vm using the ubuntu account and this provided password. • --run-script-once script_file : run script_file as root on the vm the first time it is booted, but never again. • --packages package_list : install the comma-separated packages specified in package_list on first boot. a complete description of all available modifiers is available in the manpage of uvt-kvm. resources if you are interested in learning more, have questions or suggestions, please contact the ubuntu server team at: • irc: #ubuntu-server on freenode • mailing list: ubuntu-server at lists.ubuntu.com 109

110

introduction the virt-manager source contains not only virt-manager itself but also a collection of further helpful tools like virt-install, virt-clone and virt-viewer. virtual machine manager the virt-manager package contains a graphical utility to manage local and remote virtual machines. to install virt-manager enter: sudo apt i n s t a l l virt−manager since virt-manager requires a graphical user interface (gui) environment it is recommended to be installed on a workstation or test machine instead of a production server. to connect to the local libvirt service enter: virt−manager virt−manager−c qemu+ssh :// virtnode1 . mydomain . com/system you can connect to the libvirt service running on another host by entering the following in a terminal prompt: note the above example assumes that ssh connectivity between the management system and the target system has already been configured, and uses ssh keys for authentication. ssh keys are needed because libvirt sends the password prompt to another process. virt-manager guest lifecycle when using virt−manager it is always important to know the context you look at. the main window initially lists only the currently defined guests, you’ll see their name, state and a small chart on cpu usage. virt-manager-gui-start|499x597 on that context there isn’t much one can do except start/stop a guest. but by double-clicking on a guest or by clicking the open button at the top one can see the guest itself. for a running guest that includes the guests main-console/virtual-screen output. virt-manager-gui-showoutput|690x386 if you are deeper in the guest config a click in the top left onto “show the graphical console” will get you back to this output. virt-manager guest modification virt−manager provides a gui assisted way to edit guest definitions which can be handy. to do so the per- guest context view will at the top have “show virtual hardware details”. here a user can edit the virtual hardware of the guest which will under the cover alter the guest representation. virt-manager-gui-edit|690x346 the ui edit is limited to the features known and supported to that gui feature. not only does libvirt grow features faster than virt-manager can keep up - adding every feature would also overload the ui to the extend to be unusable. to strike a balance between the two there also is the xml view which can be reached via the “edit libvirt xml” button. virt-manager-gui-xml|690x346 110

111

by default this will be read-only and you can see what the ui driven actions have changed, but one can allow rw access in this view in the preferences. this is the same content that the virsh edit of the libvirt-client exposes. virtual machine viewer the virt-viewer application allows you to connect to a virtual machine’s console like virt-manager reduced to the gui functionality. virt-viewer does require a graphical user interface (gui) to interface with the virtual machine. to install virt-viewer from a terminal enter: sudo apt once a virtual machine is installed and running you can connect to the virtual machine’s console by using: i n s t a l l virt−viewer virt−viewer <guestname> the ui will be a window representing the virtual screen of the guest, just like virt-manager above but without the extra buttons and features around it. virt-viewer-gui-showoutput|690x598 similar to virt-manager, virt-viewer can connect to a remote host using ssh with key authentication, as well: virt−viewer−c qemu+ssh :// virtnode1 . mydomain . com/system <guestname> be sure to replace web_devel with the appropriate virtual machine name. if configured to use a bridged network interface you can also setup ssh access to the virtual machine. virt-install virt-install is part of the virtinst package. it can help installing classic iso based systems and provides a cli options for the most common options needed to do so. to install it, from a terminal prompt enter: sudo apt install virtinst there are several options available when using virt-install. for example: virt−i n s t a l l −n web_devel−r 8192 \ −−disk path=/home/doug/vm/web_devel . img , bus=v i r t i o , s i z e =50 \ −c focal−desktop−amd64 . i s o \ −−network network=default , model=v i r t i o \ −−video=vmvga−−graphics vnc , l i s t e n =0.0.0.0−−noautoconsole−v−−vcpus=4 there are much more arguments that can be found in the man page, explaining those of the example above one by one: * -n web_devel the name of the new virtual machine will be web_devel in this ex- ample. * -r 8192 specifies the amount of memory the virtual machine will use in megabytes. * –disk path=/home/doug/vm/web_devel.img,bus=virtio,size=50 indicates the path to the virtual disk which can be a file, partition, or logical volume. in this example a file named web_devel.img in the current users directory, with a size of 50 gigabytes, and using virtio for the disk bus. depending on the disk path, virt- install my need to be run with elevated privileges. * -c focal-desktop-amd64.iso file to be used as a virtual cdrom. the file can be either an iso file or the path to the host’s cdrom device. * –network provides details related to the vm’s network interface. here the default network is used, and the interface model is configured for virtio. * –video=vmvga the video driver to use. * –graphics vnc,listen=0.0.0.0 exports the 111

112

guest’s virtual console using vnc and on all host interfaces. typically servers have no gui, so another gui based computer on the local area network (lan) can connect via vnc to complete the installa- tion. * –noautoconsole will not automatically connect to the virtual machine’s console. * -v: creates a fully virtualized guest. * –vcpus=4 allocate 4 virtual cpus. after launching virt-install you can connect to the virtual machine’s console either locally using a gui (if your server has a gui), or via a remote vnc client from a gui-based computer. virt-clone the virt-clone application can be used to copy one virtual machine to another. for example: virt−clone−−auto−clone−−original focal options used: * –auto-clone: to have virt-clone come up with guest names and disk paths on its own * –original: name of the virtual machine to copy also, use -d or –debug option to help troubleshoot problems with virt-clone. replace focal and with appropriate virtual machine names of your case. warning: please be aware that this is a full clone, therefore any sorts of secrets, keys and for example /etc/machine-id will be shared causing e.g. issues to security and anything that needs to identify the machine like dhcp. you most likely want to edit those afterwards and de-duplicate them as needed. resources • see the kvm home page for more details. • for more information on libvirt see the libvirt home page • the virtual machine manager site has more information on virt-manager development. lxd lxd (pronounced lex-dee) is the lightervisor, or lightweight container hypervisor. lxc (lex-see) is a program which creates and administers “containers” on a local system. it also provides an api to allow higher level managers, such as lxd, to administer containers. in a sense, one could compare lxc to qemu, while comparing lxd to libvirt. the lxc api deals with a ‘container’. the lxd api deals with ‘remotes’, which serve images and containers. this extends the lxc functionality over the network, and allows concise management of tasks like container migration and container image publishing. lxd uses lxc under the covers for some container management tasks. however, it keeps its own container configuration information and has its own conventions, so that it is best not to use classic lxc commands by hand with lxd containers. this document will focus on how to configure and administer lxd on ubuntu systems. online resources there is excellent documentation for getting started with lxd and an online server allowing you to try out lxd remotely. stephane graber also has an excellent blog series on lxd 2.0. finally, there is great documentation on how to drive lxd using juju. 112

113

this document will offer an ubuntu server-specific view of lxd, focusing on administration. installation lxd is pre-installed on ubuntu server cloud images. on other systems, the lxd package can be installed using: sudo snap i n s t a l l lxd this will install the self-contained lxd snap package. kernel preparation in general, ubuntu should have all the desired features enabled by default. one exception to this is that in order to enable swap accounting the boot argument swapaccount=1 must be set. this can be done by appending it to the grub_cmdline_linux_default=variable in /etc/default/grub, then running ‘update-grub’ as root and rebooting. configuration in order to use lxd, some basic settings need to be configured first. this is done by running lxd init , which will allow you to choose: • directory or zfs container backend. if you choose zfs, you can choose which block devices to use, or the size of a file to use as backing store. • availability over the network. • a ‘trust password’ used by remote clients to vouch for their client certificate. you must run ‘lxd init’ as root. ‘lxc’ commands can be run as any user who is a member of group lxd. if user joe is not a member of group ‘lxd’, you may run: adduser joe lxd as root to change it. the new membership will take effect on the next login, or after running newgrp lxd from an existing login. for more information on server, container, profile, and device configuration, please refer to the definitive configuration provided with the source code, which can be found online. creating your first container this section will describe the simplest container tasks. creating a container every new container is created based on either an image, an existing container, or a container snapshot. at install time, lxd is configured with the following image servers: • ubuntu: this serves official ubuntu server cloud image releases. • ubuntu−daily: this serves official ubuntu server cloud images of the daily development releases. 113

114

• images: this is a default-installed alias for images.linuxcontainers.org. this is serves classical lxc images built using the same images which the lxc ‘download’ template uses. this includes various distributions and minimal custom-made ubuntu images. this is not the recommended server for ubuntu images. the command to create and start a container is lxc launch remote : image containername images are identified by their hash, but are also aliased. the ubuntu remote knows many aliases such as 18.04 and bionic. a list of all images available from the ubuntu server can be seen using: lxc image l i s t ubuntu : to see more information about a particular image, including all the aliases it is known by, you can use: lxc image i n f o ubuntu : bi onic you can generally refer to an ubuntu image using the release name (bionic) or the release number (18.04). in addition, lts is an alias for the latest supported lts release. to choose a different architecture, you can specify the desired architecture: lxc image i n f o ubuntu : l t s /arm64 now, let’s start our first container: lxc launch ubuntu : bi onic b1 this will download the official current bionic cloud image for your current architecture, then create a container named b1 using that image, and finally start it. once the command returns, you can see it using: lxc lxc l i s t i n f o b1 and open a shell in it using: lxc exec b1−− bash the try-it page mentioned above gives a full synopsis of the commands you can use to administer containers. now that the xenial image has been downloaded, it will be kept in sync until no new containers have been created based on it for (by default) 10 days. after that, it will be deleted. lxd server configuration by default, lxd is socket activated and configured to listen only on a local unix socket. while lxd may not be running when you first look at the process listing, any lxc command will start it up. for instance: lxc l i s t this will create your client certificate and contact the lxd server for a list of containers. to make the server accessible over the network you can set the http port using: lxc c o n f i g s e t core . https_address :8443 this will tell lxd to listen to port 8843 on all addresses. 114

115

authentication by default, lxd will allow all members of group lxd to talk to it over the unix socket. communication over the network is authorized using server and client certificates. before client c1 wishes to use remote r1, r1 must be registered using: lxc remote add r1 r1 . example . com:8443 the fingerprint of r1’s certificate will be shown, to allow the user at c1 to reject a false certificate. the server in turn will verify that c1 may be trusted in one of two ways. the first is to register it in advance from any already-registered client, using: lxc c o n f i g t r u s t add r1 c e r t f i l e . c r t now when the client adds r1 as a known remote, it will not need to provide a password as it is already trusted by the server. the other step is to configure a ‘trust password’ with r1, either at initial configuration using lxd init , or after the fact using: lxc c o n f i g s e t core . trust_password password the password can then be provided when the client registers r1 as a known remote. backing store lxd supports several backing stores. the recommended and the default backing store is zfs. if you already have a zfs pool configured, you can tell lxd to use it during the lxd init procedure, otherwise a file-backed zpool will be created automatically. with zfs, launching a new container is fast because the filesystem starts as a copy on write clone of the images’ filesystem. note that unless the container is privileged (see below) lxd will need to change ownership of all files before the container can start, however this is fast and change very little of the actual filesystem data. the other supported backing stores are described in detail in the storage configuration section of the lxd documentation. container configuration containers are configured according to a set of profiles, described in the next section, and a set of container- specific configuration. profiles are applied first, so that container specific configuration can override profile configuration. container configuration includes properties like the architecture, limits on resources such as cpu and ram, security details including apparmor restriction overrides, and devices to apply to the container. devices can be of several types, including unix character, unix block, network interface, or disk. in order to insert a host mount into a container, a ‘disk’ device type would be used. for instance, to mount /opt in container c1 at /opt, you could use: lxc c o n f i g device add c1 opt disk source=/opt path=opt see: lxc help c o n f i g for more information about editing container configurations. you may also use: 115

116

lxc c o n f i g e d i t c1 to edit the whole of c1’s configuration. comments at the top of the configuration will show examples of correct syntax to help administrators hit the ground running. if the edited configuration is not valid when the editor is exited, then the editor will be restarted. profiles profiles are named collections of configurations which may be applied to more than one container. for instance, all containers created with lxc launch, by default, include the default profile, which provides a network interface eth0. to mask a device which would be inherited from a profile but which should not be in the final container, define a device by the same name but of type ‘none’: lxc c o n f i g device add c1 eth1 none nesting containers all share the same host kernel. this means that there is always an inherent trade-off between features exposed to the container and host security from malicious containers. containers by default are therefore restricted from features needed to nest child containers. in order to run lxc or lxd containers under a lxd container, the security .nesting feature must be set to true: lxc c o n f i g s e t container1 s e c u r i t y . nesting true once this is done, container1 will be able to start sub-containers. in order to run unprivileged (the default in lxd) containers nested under an unprivileged container, you will need to ensure a wide enough uid mapping. please see the ‘uid mapping’ section below. limits lxd supports flexible constraints on the resources which containers can consume. the limits come in the following categories: • cpu: limit cpu available to the container in several ways. • disk: configure the priority of i/o requests under load • ram: configure memory and swap availability • network: configure the network priority under load • processes: limit the number of concurrent processes in the container. for a full list of limits known to lxd, see the configuration documentation. uid mappings and privileged containers by default, lxd creates unprivileged containers. this means that root in the container is a non-root uid on the host. it is privileged against the resources owned by the container, but unprivileged with respect to the host, making root in a container roughly equivalent to an unprivileged user on the host. (the main exception is the increased attack surface exposed through the system call interface) 116

117

briefly, in an unprivileged container, 65536 uids are ‘shifted’ into the container. for instance, uid 0 in the container may be 100000 on the host, uid 1 in the container is 100001, etc, up to 165535. the starting value for uids and gids, respectively, is determined by the ‘root’ entry the /etc/subuid and /etc/subgid files. (see the subuid(5) man page.) it is possible to request a container to run without a uid mapping by setting the security . privileged flag to true: lxc c o n f i g s e t c1 s e c u r i t y . p r i v i l e g e d true note however that in this case the root user in the container is the root user on the host. apparmor lxd confines containers by default with an apparmor profile which protects containers from each other and the host from containers. for instance this will prevent root in one container from signaling root in another container, even though they have the same uid mapping. it also prevents writing to dangerous, un-namespaced files such as many sysctls and /proc/sysrq−trigger. if the apparmor policy for a container needs to be modified for a container c1, specific apparmor policy lines can be added in the raw.apparmor configuration key. seccomp all containers are confined by a default seccomp policy. this policy prevents some dangerous actions such as forced umounts, kernel module loading and unloading, kexec, and the open_by_handle_at system call. the seccomp configuration cannot be modified, however a completely different seccomp policy – or none – can be requested using raw.lxc (see below). raw lxc configuration lxd configures containers for the best balance of host safety and container usability. whenever possible it is highly recommended to use the defaults, and use the lxd configuration keys to request lxd to modify as needed. sometimes, however, it may be necessary to talk to the underlying lxc driver itself. this can be done by specifying lxc configuration items in the ‘raw.lxc’ lxd configuration key. these must be valid items as documented in the lxc.container.conf(5) manual page. snapshots containers can be renamed and live-migrated using the lxc move command: 117 they can also be snapshotted: lxc move c1 f i n a l−beta lxc snapshot c1 yyyy−mm−dd r e s t o r e u1 yyyy−mm−dd lxc copy u1/yyyy−mm−dd t e s t c o n t a i n e r later changes to c1 can then be reverted by restoring the snapshot: lxc new containers can also be created by copying a container or snapshot:

118

when a container or container snapshot is ready for consumption by others, it can be published as a new image using; the published image will be private by default, meaning that lxd will not allow clients without a trusted certificate to see them. if the image is safe for public viewing (i.e. contains no private information), then the ‘public’ flag can be set, either at publish time using foo−2.0 foo−2.0 public=true publishing images lxc publish u1/yyyy−mm−dd−−a l i a s lxc publish u1/yyyy−mm−dd−−a l i a s or after the fact using lxc image e d i t and changing the value of the public field. foo−2.0 foo−2.0 foo−2.0. tar . gz foo−2.0. tar . gz−−a l i a s image export and import image can be exported as, and imported from, tarballs: lxc image export lxc image import foo−2.0−−public to view debug information about lxd itself, on a systemd based host use troubleshooting j o u r n a l c t l−u lxd i n f o c1−−show−log container logfiles for container c1 may be seen using: lxc the configuration file which was used may be found under /var/log/lxd/c1/lxc.conf while apparmor profiles can be found in /var/lib/lxd/security/apparmor/profiles/c1 and seccomp profiles in /var/lib/lxd/security/ seccomp/c1. lxc containers are a lightweight virtualization technology. they are more akin to an enhanced chroot than to full virtualization like qemu or vmware, both because they do not emulate hardware and because con- tainers share the same operating system as the host. containers are similar to solaris zones or bsd jails. linux-vserver and openvz are two pre-existing, independently developed implementations of containers-like functionality for linux. in fact, containers came about as a result of the work to upstream the vserver and openvz functionality. there are two user-space implementations of containers, each exploiting the same kernel features. libvirt allows the use of containers through the lxc driver by connecting to lxc:///. this can be very convenient as it supports the same usage as its other drivers. the other implementation, called simply ‘lxc’, is not compatible with libvirt, but is more flexible with more userspace tools. it is possible to switch between the two, though there are peculiarities which can cause confusion. 118

119

in this document we will mainly describe the lxc package. use of libvirt-lxc is not generally recommended due to a lack of apparmor protection for libvirt-lxc containers. in this document, a container name will be shown as cn, c1, or c2. installation the lxc package can be installed using sudo apt i n s t a l l lxc this will pull in the required and recommended dependencies, as well as set up a network bridge for con- tainers to use. if you wish to use unprivileged containers, you will need to ensure that users have sufficient allocated subuids and subgids, and will likely want to allow users to connect containers to a bridge (see basic unprivileged usage below). basic usage lxc can be used in two distinct ways - privileged, by running the lxc commands as the root user; or unprivileged, by running the lxc commands as a non-root user. (the starting of unprivileged containers by the root user is possible, but not described here.) unprivileged containers are more limited, for instance being unable to create device nodes or mount block-backed filesystems. however they are less dangerous to the host, as the root uid in the container is mapped to a non-root uid on the host. basic privileged usage to create a privileged container, you can simply do: this will interactively ask for a container root filesystem type to download – in particular the distribution, release, and architecture. to create the container non-interactively, you can specify these values on the command line: sudo lxc−create−−template download−−name u1 sudo lxc−create−t download−n u1 sudo lxc−create−t download−n u1−−−−d i s t ubuntu−−r e l e a s e distro−short− codename−−arch amd64 sudo lxc−create−t download−n u1−−−d ubuntu−r distro−short−codename−a you can now use lxc−ls to list containers, lxc−info to obtain detailed container information, lxc−start to start and lxc−stop to stop the container. lxc−attach and lxc−console allow you to enter a container, if ssh lxc−destroy removes the container, including its rootfs. see the manual pages for more sudo lxc−l s−−fancy sudo lxc−s t a r t−−name u1−−daemon sudo lxc−i n f o−−name u1 sudo lxc−stop−−name u1 sudo lxc−destroy−−name u1 is not an option. information on each command. an example session might look like: or, abbreviated or amd64 119

120

user namespaces unprivileged containers allow users to create and administer containers without having any root privilege. the feature underpinning this is called user namespaces. user namespaces are hierarchical, with privileged tasks in a parent namespace being able to map its ids into child namespaces. by default every task on the host runs in the initial user namespace, where the full range of ids is mapped onto the full range. this can be seen by looking at /proc/self/uid_map and /proc/self/gid_map, which both will show 0 0 4294967295 when read from the initial user namespace. as of ubuntu 14.04, when new users are created they are by default offered a range of uids. the list of assigned ids can be seen in the files /etc/subuid and /etc/subgid see their respective manpages for more information. subuids and subgids are by convention started at id 100000 to avoid conflicting with system users. if a user was created on an earlier release, it can be granted a range of ids using usermod, as follows: sudo usermod−v 100000−200000−w 100000−200000 user1 the programs newuidmap and newgidmap are setuid-root programs in the uidmap package, which are used internally by lxc to map subuids and subgids from the host into the unprivileged container. they ensure that the user only maps ids which are authorized by the host configuration. basic unprivileged usage to create unprivileged containers, a few first steps are needed. you will need to create a default container configuration file, specifying your desired id mappings and network setup, as well as configure the host to allow the unprivileged user to hook into the host network. the example below assumes that your mapped user and group id ranges are 100000–165536. check your actual user and group id ranges and modify the example accordingly: grep $user / etc / subuid grep $user / etc / subgid mkdir−p ~/. c o n f i g / lxc echo ” lxc . id_map = u 0 100000 65536” > ~/. c o n f i g / lxc / d e f a u l t . conf echo ” lxc . id_map = g 0 100000 65536” >> ~/. c o n f i g / lxc / d e f a u l t . conf echo ” lxc . network . type = veth ” >> ~/. c o n f i g / lxc / d e f a u l t . conf echo ” lxc . network . l i n k = lxcbr0 ” >> ~/. c o n f i g / lxc / d e f a u l t . conf echo ”$user veth lxcbr0 2” | sudo tee−a / etc / lxc / lxc−usernet after this, you can create unprivileged containers the same way as privileged ones, simply without using sudo. lxc−create−t download−n u1−−−d ubuntu−r distro−short−codename−a amd64 lxc−s t a r t−n u1−d lxc−attach−n u1 lxc−stop−n u1 lxc−destroy−n u1 nesting in order to run containers inside containers - referred to as nested containers - two lines must be present in the parent container configuration file: lxc . mount . auto = cgroup lxc . aa_profile = lxc−container−default−with−nesting 120

121

the first will cause the cgroup manager socket to be bound into the container, so that lxc inside the container is able to administer cgroups for its nested containers. the second causes the container to run in a looser apparmor policy which allows the container to do the mounting required for starting containers. note that this policy, when used with a privileged container, is much less safe than the regular policy or an unprivileged container. see the apparmor section for more information. global configuration the following configuration files are consulted by lxc. for privileged use, they are found under /etc/lxc, while for unprivileged use they are under ~/.config/lxc. • lxc.conf may optionally specify alternate values for several lxc settings, including the lxcpath, the default configuration, cgroups to use, a cgroup creation pattern, and storage backend settings for lvm and zfs. network. contains at least a network section, and, for unprivileged users, an id mapping section • default .conf specifies configuration which every newly created container should contain. this usually • lxc−usernet.conf specifies how unprivileged users may connect their containers to the host-owned lxc.conf and default .conf are both under /etc/lxc and $home/.config/lxc, while lxc−usernet.conf is only host-wide. by default, containers are located under /var/lib/lxc for the root user. networking by default lxc creates a private network namespace for each container, which includes a layer 2 networking stack. containers usually connect to the outside world by either having a physical nic or a veth tunnel endpoint passed into the container. lxc creates a nated bridge, lxcbr0, at host startup. containers created using the default configuration will have one veth nic with the remote end plugged into the lxcbr0 bridge. a nic can only exist in one namespace at a time, so a physical nic passed into the container is not usable on the host. it is possible to create a container without a private network namespace. in this case, the container will have access to the host networking like any other application. note that this is particularly dangerous if the container is running a distribution with upstart, like ubuntu, since programs which talk to init, like shutdown, will talk over the abstract unix domain socket to the host’s upstart, and shut down the host. to give containers on lxcbr0 a persistent ip address based on domain name, you can write entries to /etc/ lxc/dnsmasq.conf like: if it is desirable for the container to be publicly accessible, there are a few ways to go about it. one is to use iptables to forward host ports to the container, for instance dhcp−host=lxcmail , 1 0 . 0 . 3 . 1 0 0 dhcp−host=t t r s s , 1 0 . 0 . 3 . 1 0 1 i p t a b l e s−t nat−a prerouting−p tcp−i eth0−−dport 587−j dnat \ −−to−d e s t i n a t i o n 1 0 . 0 . 3 . 1 0 0 : 5 8 7 then, specify the host’s bridge in the container configuration file in place of lxcbr0, for instance lxc . network . type = veth lxc . network . l i n k = br0 121

122

finally, you can ask lxc to use macvlan for the container’s nic. note that this has limitations and depending on configuration may not allow the container to talk to the host itself. therefore the other two options are preferred and more commonly used. there are several ways to determine the ip address for a container. first, you can use lxc−ls−−fancy which will print the ip addresses for all running containers, or lxc−info−i−h−n c1 which will print c1’s ip address. if dnsmasq is installed on the host, you can also add an entry to /etc/dnsmasq.conf as follows s e r v e r=/lxc / 1 0 . 0 . 3 . 1 after which dnsmasq will resolve c1.lxc locally, so that you can do: ping c1 ssh c1 for more information, see the lxc.conf(5) manpage as well as the example network configurations under /usr/share/doc/lxc/examples/. lxc startup lxc does not have a long-running daemon. however it does have three upstart jobs. use_lxc_bridge (true by default). it sets up a nated bridge for containers to use. is an optional job which only runs if /etc/default/lxc−net specifies • /etc/init/lxc−net.conf: • /etc/init/lxc−instance.conf is used by /etc/init/lxc.conf to autostart a container. • /etc/init/lxc.conf loads the lxc apparmor profiles and optionally starts any autostart containers. the autostart containers will be ignored if lxc_auto (true by default) is set to true in /etc/default/lxc. see the lxc-autostart manual page for more information on autostarted containers. backing stores lxc supports several backing stores for container root filesystems. the default is a simple directory backing store, because it requires no prior host customization, so long as the underlying filesystem is large enough. it also requires no root privilege to create the backing store, so that it is seamless for unprivileged use. the rootfs for a privileged directory backed container is located (by default) under /var/lib/lxc/c1/rootfs, while the rootfs for an unprivileged container is under ~/.local/share/lxc/c1/rootfs. if a custom lxcpath is specified in lxc.system.com, then the container rootfs will be under $lxcpath/c1/rootfs. a snapshot clone c2 of a directory backed container c1 becomes an overlayfs backed container, with a rootfs called overlayfs :/var/lib/lxc/c1/rootfs:/var/lib/lxc/c2/delta0. other backing store types include loop, btrfs, lvm and zfs. a btrfs backed container mostly looks like a directory backed container, with its root filesystem in the same location. however, the root filesystem comprises a subvolume, so that a snapshot clone is created using a subvolume snapshot. the root filesystem for an lvm backed container can be any separate lv. the default vg name can be specified in lxc.conf. the filesystem type and size are configurable per-container using lxc-create. the rootfs for a zfs backed container is a separate zfs filesystem, mounted under the traditional /var/ lib/lxc/c1/rootfs location. the zfsroot can be specified at lxc-create, and a default can be specified in lxc.system.conf. more information on creating containers with the various backing stores can be found in the lxc-create manual page. 122

123

templates creating a container generally involves creating a root filesystem for the container. lxc−create delegates this work to templates, which are generally per-distribution. the lxc templates shipped with lxc can be found under /usr/share/lxc/templates, and include templates to create ubuntu, debian, fedora, oracle, centos, and gentoo containers among others. creating distribution images in most cases requires the ability to create device nodes, often requires tools which are not available in other distributions, and usually is quite time-consuming. therefore lxc comes with a special download template, which downloads pre-built container images from a central lxc server. the most important use case is to allow simple creation of unprivileged containers by non-root users, who could not for instance easily run the debootstrap command. when running lxc−create, all options which come after – are passed to the template. command, –name, –template and –bdev are passed to lxc−create, while –release is passed to the template: lxc−create−−template ubuntu−−name c1−−bdev loop−−−−r e l e a s e distro−short− name to lxc−create. for instance, for help with the download template, lxc−create−−template download−−help you can obtain help for the options supported by any particular container by passing –help and the template in the following codename autostart lxc supports marking containers to be started at system boot. prior to ubuntu 14.04, this was done using symbolic links under the directory /etc/lxc/auto. starting with ubuntu 14.04, it is done through the container configuration files. an entry lxc . s t a r t . auto = 1 lxc . s t a r t . delay = 5 would mean that the container should be started at boot, and the system should wait 5 seconds before starting the next container. lxc also supports ordering and grouping of containers, as well as reboot and shutdown by autostart groups. see the manual pages for lxc-autostart and lxc.container.conf for more information. apparmor /sys files. mounting new filesystems outside of the container’s root filesystem. before executing the container’s init , lxc ships with a default apparmor profile intended to protect the host from accidental misuses of privilege inside the container. for instance, the container will not be able to write to /proc/sysrq−trigger or to most the usr.bin.lxc−start profile is entered by running lxc−start. this profile mainly prevents lxc−start from lxc requests a switch to the container’s profile. by default, this profile is the lxc−container−default policy which is defined in /etc/apparmor.d/lxc/lxc−default. this profile prevents the container from accessing lxc−execute does not enter an apparmor profile, but the container it spawns will be confined. many dangerous paths, and from mounting most filesystems. programs in a container cannot be further confined - for instance, mysql runs under the container profile (protecting the host) but will not be able to enter the mysql profile (to protect the container). 123

124

customizing container policies you can disable the lxc-start profile by doing: if you find that lxc−start is failing due to a legitimate access which is being denied by its apparmor policy, sudo apparmor_parser−r / etc /apparmor . d/ usr . bin . lxc−s t a r t sudo ln−s / etc /apparmor . d/ usr . bin . lxc−s t a r t / etc /apparmor . d/ disabled / this will make lxc−start run unconfined, but continue to confine the container itself. if you also wish to disable confinement of the container, then in addition to disabling the usr.bin.lxc−start profile, you must add: lxc . aa_profile = unconfined to the container’s configuration file. lxc ships with a few alternate policies for containers. if you wish to run containers inside containers (nesting), then you can use the lxc-container-default-with-nesting profile by adding the following line to the container configuration file lxc . aa_profile = lxc−container−default−with−nesting /etc/apparmor.d/lxc/lxc−default−with−nesting) by uncommenting the following line: mount fstype=cgroup−> / sys / f s / cgroup /** , if you wish to use libvirt inside containers, then you will need to edit that policy (which is defined in and re-load the policy. note that the nesting policy with privileged containers is far less safe than the default policy, as it allows containers to re-mount /sys and /proc in nonstandard locations, bypassing apparmor protections. unpriv- ileged containers do not have this drawback since the container root cannot write to root-owned proc and sys files. another profile shipped with lxc allows containers to mount block filesystem types like ext4. this can be useful in some cases like maas provisioning, but is deemed generally unsafe since the superblock handlers in the kernel have not been audited for safe handling of untrusted input. if you need to run a container in a custom profile, you can create a new profile under /etc/apparmor.d/lxc/. an easy way to start a new profile therefore is to do the same, then add extra permissions at the bottom of your policy. after creating the policy, load it using: its name must start with lxc− in order for lxc−start to be allowed to transition to that profile. the lxc −default profile includes the re-usable abstractions file /etc/apparmor.d/abstractions/lxc/container−base. sudo apparmor_parser−r / etc /apparmor . d/ lxc−containers lxc−containers. finally, to make container cn use this new lxc−cn−profile, add the following line to its lxc . aa_profile = lxc−cn−p r o f i l e the profile will automatically be loaded after a reboot, because it is sourced by the file /etc/apparmor.d/ configuration file: control groups control groups (cgroups) are a kernel feature providing hierarchical task grouping and per-cgroup resource accounting and limits. they are used in containers to limit block and character device access and to freeze 124

125

(suspend) containers. they can be further used to limit memory use and block i/o, guarantee minimum cpu shares, and to lock containers to specific cpus. by default, a privileged container cn will be assigned to a cgroup called /lxc/cn. in the case of name conflicts (which can occur when using custom lxcpaths) a suffix “-n”, where n is an integer starting at 0, will be appended to the cgroup name. by default, a privileged container cn will be assigned to a cgroup called cn under the cgroup of the task which started the container, for instance /usr/1000.user/1.session/cn. the container root will be given group ownership of the directory (but not all files) so that it is allowed to create new child cgroups. as of ubuntu 14.04, lxc uses the cgroup manager (cgmanager) to administer cgroups. the cgroup manager receives d-bus requests over the unix socket /sys/fs/cgroup/cgmanager/sock. to facilitate safe nested containers, the line lxc . mount . auto = cgroup can be added to the container configuration causing the /sys/fs/cgroup/cgmanager directory to be bind- mounted into the container. the container in turn should start the cgroup management proxy (done by default if the cgmanager package is installed in the container) which will move the /sys/fs/cgroup/cgmanager directory to /sys/fs/cgroup/cgmanager.lower, then start listening for requests to proxy on its own socket /sys/fs/cgroup/cgmanager/sock. the host cgmanager will ensure that nested containers cannot escape their assigned cgroups or make requests for which they are not authorized. cloning for rapid provisioning, you may wish to customize a canonical container according to your needs and then make multiple copies of it. this can be done with the lxc−clone program. clones are either snapshots or copies of another container. a copy is a new container copied from the original, and takes as much space on the host as the original. a snapshot exploits the underlying backing store’s snapshotting ability to make a copy-on-write container referencing the first. snapshots can be created from btrfs, lvm, zfs, and directory backed containers. each backing store has its own peculiarities - for instance, lvm containers which are not thinpool-provisioned cannot support snapshots of snapshots; zfs containers with snapshots cannot be removed until all snapshots are released; lvm containers must be more carefully planned as the underlying filesystem may not support growing; btrfs does not suffer any of these shortcomings, but suffers from reduced fsync performance causing dpkg and apt to be slower. snapshots of directory-packed containers are created using the overlay filesystem. for instance, a privileged directory-backed container c1 will have its root filesystem under /var/lib/lxc/c1/rootfs. a snapshot clone of c1 called c2 will be started with c1’s rootfs mounted readonly under /var/lib/lxc/c2/delta0. importantly, in this case c1 should not be allowed to run or be removed while c2 is running. it is advised instead to consider c1 a canonical base container, and to only use its snapshots. given an existing container called c1, a copy can be created using: sudo lxc−clone−o c1−n c2 sudo lxc−clone−s−o c1−n c2 a snapshot can be created using: see the lxc-clone manpage for more information. 125

126

snapshots which is a snapshot-clone called ‘snap0’ under /var/lib/lxcsnaps or $home/.local/share/lxcsnaps. the next to more easily support the use of snapshot clones for iterative container development, lxc supports snap- shots. when working on a container c1, before making a potentially dangerous or hard-to-revert change, you can create a snapshot sudo lxc−snapshot−n c1 snapshot will be called ‘snap1’, etc. existing snapshots can be listed using lxc−snapshot−l−n c1, and a snapshot can be restored - erasing the current c1 container - using lxc−snapshot−r snap1−n c1. after the restore command, the snap1 snapshot continues to exist, and the previous c1 is erased and replaced with the snap1 snapshot. snapshots are supported for btrfs, lvm, zfs, and overlayfs containers. if lxc-snapshot is called on a directory- backed container, an error will be logged and the snapshot will be created as a copy-clone. the reason for this is that if the user creates an overlayfs snapshot of a directory-backed container and then makes changes to the directory-backed container, then the original container changes will be partially reflected in the snapshot. if snapshots of a directory backed container c1 are desired, then an overlayfs clone of c1 should be created, c1 should not be touched again, and the overlayfs clone can be edited and snapshotted at will, as such lxc−clone−s−o c1−n c2 lxc−s t a r t−n c2−d # make some changes lxc−stop−n c2 lxc−snapshot−n c2 lxc−s t a r t−n c2 # etc ephemeral containers while snapshots are useful for longer-term incremental development of images, ephemeral containers utilize snapshots for quick, single-use throwaway containers. given a base container c1, you can start an ephemeral container using lxc−start−ephemeral−o c1 the container begins as a snapshot of c1. instructions for logging into the container will be printed to the console. after shutdown, the ephemeral container will be destroyed. see the lxc-start-ephemeral manual page for more options. lifecycle management hooks beginning with ubuntu 12.10, it is possible to define hooks to be executed at specific points in a container’s lifetime: • pre-start hooks are run in the host’s namespace before the container ttys, consoles, or mounts are up. if any mounts are done in this hook, they should be cleaned up in the post-stop hook. • pre-mount hooks are run in the container’s namespaces, but before the root filesystem has been mounted. mounts done in this hook will be automatically cleaned up when the container shuts down. • mount hooks are run after the container filesystems have been mounted, but before the container has called pivot_root to change its root filesystem. • start hooks are run immediately before executing the container’s init. since these are executed after pivoting into the container’s filesystem, the command to be executed must be copied into the container’s filesystem. • post-stop hooks are executed after the container has been shut down. 126

127

if any hook returns an error, the container’s run will be aborted. any post-stop hook will still be executed. any output generated by the script will be logged at the debug priority. please see the lxc.container.conf(5) manual page for the configuration file format with which to specify hooks. some sample hooks are shipped with the lxc package to serve as an example of how to write and use such hooks. consoles containers have a configurable number of consoles. one always exists on the container’s /dev/console. this consoles is specified by the lxc.tty variable, and is usually set to 4. those consoles are shown on /dev/ttyn (for 1 <= n <= 4). to log into console 3 from the host, use: is shown on the terminal from which you ran lxc−start, unless the -d option is specified. the output on /dev/console can be redirected to a file using the -c console-file option to lxc−start. the number of extra sudo lxc−console−n container−t 3 or if the−t n option is not specified, an unused console will be automatically chosen. to exit the console, use the escape sequence ctrl−a q. note that the escape sequence does not work in the console resulting from lxc−start without the−d option. each container console is actually a unix98 pty in the host’s (not the guest’s) pty mount, bind-mounted over the guest’s /dev/ttyn and /dev/console. therefore, if the guest unmounts those or otherwise tries to access the actual character device 4:n, it will not be serving getty to the lxc consoles. (with the default settings, the container will not be able to access that character device and getty will therefore fail.) this can easily happen when a boot script blindly mounts a new /dev. troubleshooting logging if something goes wrong when starting a container, the first step should be to get full logging from lxc: sudo lxc−s t a r t−n c1−l trace−o debug . out this will cause lxc to log at the most verbose level, trace, and to output log information to a file called ‘debug.out’. if the file debug.out already exists, the new log information will be appended. monitoring container status two commands are available to monitor container state changes. tainers for any state changes. it takes a container name as usual with the -n option, but in this case the container name can be a posix regular expression to allow monitoring desirable sets of containers. monitor continues running as it prints container changes. then exits. for instance, lxc−monitor monitors one or more con- lxc− lxc−wait waits for a specific state change and sudo lxc−monitor−n cont [0−5]* sudo lxc−wait−n cont1−s would print all state changes to any containers matching the listed regular expression, whereas ’stopped|frozen’ will wait until container cont1 enters state stopped or state frozen and then exit. 127

128

as of ubuntu 14.04, it is possible to attach to a container’s namespaces. the simplest case is to simply do which will start a shell attached to c1’s namespaces, or, effectively inside the container. the attach func- tionality is very flexible, allowing attaching to a subset of the container’s namespaces and security context. see the manual page for more information. attach sudo lxc−attach−n c1 container init verbosity if lxc completes the container startup, but the container init fails to complete (for instance, no login prompt is shown), it can be useful to request additional verbosity from the init process. for an upstart container, this might be: you can also start an entirely different program in place of init, for instance l o g l e v e l=debug sudo lxc−s t a r t−n c1 / sbin / i n i t sudo lxc−s t a r t−n c1 / bin /bash sudo lxc−s t a r t−n c1 / bin / s l e e p 100 sudo lxc−s t a r t−n c1 / bin / cat / proc /1/ status lxc api most of the lxc functionality can now be accessed through an api exported by liblxc for which bindings are available in several languages, including python, lua, ruby, and go. below is an example using the python bindings (which are available in the python3-lxc package) which creates and starts a container, then waits until it has been shut down: # sudo python3 python 3 . 2 . 3 ( default , aug 28 2012 , 0 8 : 2 6 : 0 3 ) [gcc 4 . 7 . 1 20120814 ( p r e r e l e a s e ) ] on linux2 type ” help ” , ” copyright ” , ” c r e d i t s ” or ” l i c e n s e ” f o r more information . >>> import __main__ : 1 : warning : the python−lxc api isn ’ t yet s t a b l e and may change at any lxc point in the future . >>> c=lxc . container (”c1”) >>> c . create (” ubuntu ”) true >>> c . s t a r t () true >>> c . wait (”stopped”) true security a namespace maps ids to resources. by not providing a container any id with which to reference a resource, the resource can be protected. this is the basis of some of the security afforded to container users. for instance, ipc namespaces are completely isolated. other namespaces, however, have various leaks which allow privilege to be inappropriately exerted from a container into another container or to the host. 128

129

by default, lxc containers are started under a apparmor policy to restrict some actions. the details of apparmor integration with lxc are in section apparmor. unprivileged containers go further by mapping root in the container to an unprivileged host uid. this prevents access to /proc and /sys files representing host resources, as well as any other files owned by root on the host. exploitable system calls it is a core container feature that containers share a kernel with the host. therefore if the kernel contains any exploitable system calls the container can exploit these as well. once the container controls the kernel it can fully control any resource known to the host. in general to run a full distribution container a large number of system calls will be needed. however for application containers it may be possible to reduce the number of available system calls to only a few. even for system containers running a full distribution security gains may be had, for instance by removing the 32-bit compatibility system calls in a 64-bit container. see the lxc.container.conf manual page for details of how to configure a container to use seccomp. by default, no seccomp policy is loaded. resources • the developerworks article lxc: linux container tools was an early introduction to the use of con- • the secure containers cookbook demonstrated the use of security modules to make containers more tainers. secure. • the upstream lxc project is hosted at linuxcontainers.org. databases ubuntu provides two popular database servers. they are: • mysql • postgresql both are popular choices among developers, with similar feature sets and performance capabilities. histor- ically, postgres tended to be a preferred choice for its attention to standards conformance, features, and extensibility, whereas mysql may be more preferred for higher performance requirements, however over time each has made good strides catching up with the other. specialized needs may make one a better option for a certain application, but in general both are good, strong options. they are available in the main repository and equally supported by ubuntu. this section explains how to install and configure these database servers. mysql mysql is a fast, multi-threaded, multi-user, and robust sql database server. it is intended for mission- critical, heavy-load production systems and mass-deployed software. installation to install mysql, run the following command from a terminal prompt: sudo apt i n s t a l l mysql−s e r v e r 129

130

once the installation is complete, the mysql server should be started automatically. you can quickly check its current status via systemd: sudo s e r v i c e mysql status฀ mysql . s e r v i c e− mysql community server enabled ) loaded : active : a c t i v e ( running ) loaded (/ l i b /systemd/system/mysql . s e r v i c e ; enabled ; vendor preset : s i n c e tue 2019−10−08 14:37:38 pdt; 2 weeks 5 days 2028 / usr / sbin /mysqld−−daemonize−−pid−f i l e =/run/mysqld/mysqld . pid oct 08 14:37:36 db . example . org systemd [ 1 ] : starting mysql community server . . . oct 08 14:37:38 db . example . org systemd [ 1 ] : started mysql community server . tasks : 28 ( l i m i t : 4915) cgroup : /system . s l i c e /mysql . s e r v i c e ฀฀ ago main pid : 2028 ( mysqld ) the network status of the mysql service can also be checked by running the ss command at the terminal prompt: sudo ss−tap | grep mysql bind−address when you run this command, you should see something similar to the following: listen 1 2 7 . 0 . 0 . 1 : mysql 151 0 users : ( ( ” mysqld ” , pid =149190 , fd =29) ) 0 users : ( ( ” mysqld ” , pid =149190 , fd =32) ) 70 *:33060 listen 0 . 0 . 0 . 0 : * *:* if the server is not running correctly, you can type the following command to start it: sudo s e r v i c e mysql r e s t a r t a good starting point for troubleshooting problems is the systemd journal, which can be accessed at the terminal prompt with this command: sudo j o u r n a l c t l−u mysql configuration you can edit the files in /etc/mysql/ to configure the basic settings – log file, port number, etc. for example, to configure mysql to listen for connections from network hosts, in the file /etc/mysql/mysql.conf.d/mysqld .cnf, change the bind-address directive to the server’s ip address: = 1 9 2 . 1 6 8 . 0 . 5 note replace 192.168.0.5 with the appropriate address, which can be determined via ip address show. after making a configuration change, the mysql daemon will need to be restarted: sudo systemctl r e s t a r t mysql . s e r v i c e 130

131

database engines whilst the default configuration of mysql provided by the ubuntu packages is perfectly functional and performs well there are things you may wish to consider before you proceed. mysql is designed to allow data to be stored in different ways. these methods are referred to as either database or storage engines. there are two main engines that you’ll be interested in: innodb and myisam. storage engines are transparent to the end user. mysql will handle things differently under the surface, but regardless of which storage engine is in use, you will interact with the database in the same way. each engine has its own advantages and disadvantages. while it is possible, and may be advantageous to mix and match database engines on a table level, doing so reduces the effectiveness of the performance tuning you can do as you’ll be splitting the resources between two engines instead of dedicating them to one. • myisam is the older of the two. it can be faster than innodb under certain circumstances and favours a read only workload. some web applications have been tuned around myisam (though that’s not to imply that they will slow under innodb). myisam also supports the fulltext data type, which allows very fast searches of large quantities of text data. however myisam is only capable of locking an entire table for writing. this means only one process can update a table at a time. as any application that uses the table scales this may prove to be a hindrance. it also lacks journaling, which makes it harder for data to be recovered after a crash. the following link provides some points for consideration about using myisam on a production database. • innodb is a more modern database engine, designed to be acid compliant which guarantees database transactions are processed reliably. write locking can occur on a row level basis within a table. that means multiple updates can occur on a single table simultaneously. data caching is also handled in memory within the database engine, allowing caching on a more efficient row level basis rather than file block. to meet acid compliance all transactions are journaled independently of the main tables. this allows for much more reliable data recovery as data consistency can be checked. as of mysql 5.5 innodb is the default engine, and is highly recommended over myisam unless you have specific need for features unique to the engine. advanced configuration creating a tuned configuration there are a number of parameters that can be adjusted within mysql’s configuration files that will allow you to improve the performance of the server over time. many of the parameters can be adjusted with the existing database, however some may affect the data layout and thus need more care to apply. first, if you have existing data, you will need to carry out a mysqldump and reload: mysqldump−−a l l−databases−−r o u t i n e s−u root−p > ~/ fulldump . s q l this will then prompt you for the root password before creating a copy of the data. it is advisable to make sure there are no other users or processes using the database whilst this takes place. depending on how much data you’ve got in your database, this may take a while. you won’t see anything on the screen during this process. once the dump has been completed, shut down mysql: sudo s e r v i c e mysql stop it’s also a good idea to backup the original configuration: 131

132

next, make any desired configuration changes. then delete and re-initialise the database space and make sure ownership is correct before restarting mysql: sudo rsync−avz / etc /mysql / root /mysql−backup sudo rm−r f / var / l i b /mysql/* sudo mysqld−−i n i t i a l i z e sudo chown−r mysql : / var / l i b /mysql sudo s e r v i c e mysql s t a r t the final step is re-importation of your data by piping your sql commands to the database. cat ~/ fulldump . s q l | mysql for large data imports, the ‘pipe viewer’ utility can be useful to track import progress. ignore any eta times produced by pv, they’re based on the average time taken to handle each row of the file, but the speed of inserting can vary wildly from row to row with mysqldumps: sudo apt pv ~/ fulldump . s q l i n s t a l l pv | mysql once that is complete all is good to go! note this is not necessary for all my.cnf changes. most of the variables you may wish to change to improve performance are adjustable even whilst the server is running. as with anything, make sure to have a good backup copy of config files and data before making changes. mysql tuner mysql tuner connects to a running mysql instance and offer configuration suggestions to optimize the database for your workload. the longer the server has been running, the better the advice mysqltuner can provide. in a production environment, consider waiting for at least 24 hours before running the tool. you can install mysqltuner from the ubuntu repositories: sudo apt i n s t a l l mysqltuner then once its been installed, run: mysqltuner and wait for its final report. the top section provides general information about the database server, and the bottom section provides tuning suggestions to alter in your my.cnf. most of these can be altered live on the server without restarting; look through the official mysql documentation (link in resources section) for the relevant variables to change in production. the following example is part of a report from a production database showing potential benefits from increasing the query cache: −−−−−−−− recommendations−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−− run optimize table to defragment increase table_cache gradually to avoid f i l e d e s c r i p t o r f o r better performance l i m i t s recommendations : general t a b l e s variables to adjust : key_buffer_size (> 1.4g) query_cache_size (> 32m) table_cache (> 64) innodb_buffer_pool_size (>= 22g) 132

133

it goes without saying that performance optimization strategies vary from application to application. so for example, what works best for wordpress might not be the best for drupal or joomla. performance can be dependent on the types of queries, use of indexes, how efficient the database design is and so on. you may find it useful to spend some time searching for database tuning tips based on what applications you’re using. once you’ve reached the point of diminishing returns from database configuration adjustments, look to the application itself for improvements, or invest in more powerful hardware and/or scaling up the database environment. resources • see the mysql home page for more information. • full documentation is available in both online and offline formats from the mysql developers portal • for general sql information see the o’reilly books getting started with sql: a hands-on approach for beginners by thomas nield as an entry point and sql in a nutshell as a quick reference. • the apache mysql php ubuntu wiki page also has useful information. postgresql postgresql is an object-relational database system that has the features of traditional commercial database systems with enhancements to be found in next-generation dbms systems. installation to install postgresql, run the following command in the command prompt: sudo apt i n s t a l l p o s t g r e s q l the database service is automatically configured with viable defaults, but can be customized based on your specialized needs. configuration postgresql supports multiple client authentication methods. by default, the ident authentication method is used for postgres and local users. please refer to the postgresql administrator’s guide if you would like to configure alternatives like kerberos. the following discussion assumes that you wish to enable tcp/ip connections and use the md5 method for client authentication. postgresql configuration files are stored in the /etc/postgresql/<version>/main directory. for example, if you install postgresql 12, the configuration files are stored in the /etc/postgresql /12/main directory. tip to configure ident authentication, add entries to the /etc/postgresql/12/main/pg_ident.conf file. there are detailed comments in the file to guide you. to enable other computers to connect to your postgresql server, edit the file /etc/postgresql/12/main/ postgresql.conf locate the line #listen_addresses = ‘localhost’ and change it to: l i s t e n _ a d d r e s s e s = ’* ’ 133

134

note to allow both ipv4 and ipv6 connections replace ‘localhost’ with ‘::’ for details on other parameters, refer to the configuration file or to the postgresql documentation for information on how they can be edited. now that we can connect to our postgresql server, the next step is to set a password for the postgres user. run the following command at a terminal prompt to connect to the default postgresql template database: sudo−u postgres psql template1 the above command connects to postgresql database template1 as user postgres. once you connect to the postgresql server, you will be at a sql prompt. you can run the following sql command at the psql prompt to configure the password for the user postgres. alter user postgres with encrypted password ’ your_password ’ ; after configuring the password, edit the file /etc/postgresql/12/main/pg_hba.conf to use md5 authentica- tion with the postgres user: l o c a l postgres md5 a l l finally, you should restart the postgresql service to initialize the new configuration. from a terminal prompt enter the following to restart postgresql: sudo systemctl r e s t a r t p o s t g r e s q l . s e r v i c e warning the above configuration is not complete by any means. please refer to the postgresql admin- istrator’s guide to configure more parameters. you can test server connections from other machines by using the postgresql client. sudo apt i n s t a l l postgresql−c l i e n t psql−h postgres . example . com−u postgres−w note replace the domain name with your actual server domain name. backups postgresql databases should be backed up regularly. refer to the postgresql administrator’s guide for different approaches. resources • as mentioned above the postgresql administrator’s guide is an excellent resource. the guide is also available in the postgresql-doc-12 package. execute the following in a terminal to install the package: sudo apt to view the guide enter file :///usr/share/doc/postgresql−doc−12/html/index.html into the address i n s t a l l postgresql−doc−12 • for general sql information see the o’reilly books getting started with sql: a hands-on approach bar of your browser. for beginners by thomas nield as an entry point and sql in a nutshell as a quick reference. • also, see the postgresql ubuntu wiki page for more information. 134

135

active directory integration accessing a samba share another, use for samba is to integrate into an existing windows network. once part of an active directory domain, samba can provide file and print services to ad users. for details on how to join a domain, see the sssd and active directory chapter of this guide. once part of the active directory domain, enter the following command in the terminal prompt: sudo apt smbclient i n s t a l l samba c i f s−u t i l s next, edit /etc/samba/smb.conf changing: workgroup = example . . . s e c u r i t y = ads realm = example.com . . . idmap backend = lwopen idmap uid = 50−9999999999 idmap gid = 50−9999999999 restart samba for the new settings to take effect: sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e you should now be able to access any samba shares from a windows client. however, be sure to give the appropriate ad users or groups access to the share directory. see securing file and print server for more details. accessing a windows share now that the samba server is part of the active directory domain you can access any windows server shares: • to mount a windows file share enter the following in a terminal prompt: mount . c i f s // fs01 . example . com/ share mount_point it is also possible to access shares on computers not part of an ad domain, but a username and password will need to be provided. • to mount the share during boot place an entry in /etc/fstab, for example: //192.168.0.5/ share /mnt/windows c i f s auto , username=steve , password=secret , rw 0 0 • another way to copy files from a windows server is to use the smbclient utility. to list the files in a windows share: • to copy a file from the share, enter: smbclient // fs01 . example . com/ share−k−c ” l s ” smbclient // fs01 . example . com/ share−k−c ” get this will copy the file .txt into the current directory. f i l e . txt ” 135

136

• and to copy a file to the share: this will copy the /etc/hosts to //fs01.example.com/share/hosts. smbclient // fs01 . example . com/ share−k−c ”put / etc / hosts hosts ” smbclient // fs01 . example . com/ share−k • the -c option used above allows you to execute the smbclient command all at once. this is useful for scripting and minor file operations. to enter the smb: \> prompt, a ftp like prompt where you can execute normal file and directory commands, simply execute: note replace all instances of fs01.example.com/share, //192.168.0.5/share, username=steve,password=secret, and file.txt with your server’s ip, hostname, share name, file name, and an actual username and password with rights to the share. resources for more smbclient options see the man page: man smbclient, also available online. the mount.cifs man page is also useful for more detailed information. the ubuntu wiki samba page. as a domain controller a samba server can be configured to appear as a windows nt4-style domain controller. a major advantage of this configuration is the ability to centralize user and machine credentials. samba can also use multiple backends to store the user information. primary domain controller samba libpam−winbind this section covers configuring samba as a primary domain controller (pdc) using the default smbpasswd backend. first, install samba, and libpam-winbind to sync the user accounts, by entering the following in a terminal prompt: sudo apt i n s t a l l next, configure samba by editing /etc/samba/smb.conf. the security mode should be set to user, and the workgroup should relate to your organization: workgroup = example . . . s e c u r i t y = user in the commented “domains” section add or uncomment the following (the last line has been split to fit the format of this document): domain logons = yes logon path = \\%n\%u\ p r o f i l e logon drive = h: logon home = \\%n\%u 136

137

logon s c r i p t = logon . cmd add machine s c r i p t = sudo / usr / sbin / useradd−n−g machines−c machine−d / var / l i b /samba−s / bin / f a l s e %u note if you wish to not use roaming profiles leave the logon home and logon path options commented. • domain logons: provides the netlogon service causing samba to act as a domain controller. • logon path: places the user’s windows profile into their home directory. it is also possible to configure a [profiles] share placing all profiles under a single directory. • logon drive: specifies the home directory local path. • logon home: specifies the home directory location. • logon script: determines the script to be run locally once a user has logged in. the script needs to be placed in the [netlogon] share. • add machine script: a script that will automatically create the machine trust account needed for a workstation to join the domain. in this example the machines group will need to be created using the addgroup utility see ??? for details. uncomment the [homes] share to allow the logon home to be mapped: [ homes ] comment = home d i r e c t o r i e s browseable = no read only = no create mask = 0700 d i r e c t o r y mask = 0700 v a l i d users = %s when configured as a domain controller a [netlogon] share needs to be configured. to enable the share, uncomment: [ netlogon ] comment = network logon service path = / srv /samba/ netlogon guest ok = yes read only = yes share modes = no note the original netlogon share path is /home/samba/netlogon, but according to the filesystem hierarchy standard (fhs), /srv is the correct location for site-specific data provided by the system. now create the netlogon directory, and an empty (for now) logon.cmd script file: sudo mkdir−p / srv /samba/ netlogon sudo touch / srv /samba/ netlogon / logon . cmd you can enter any normal windows logon script commands in logon.cmd to customize the client’s environ- ment. restart samba to enable the new domain controller: 137

138

sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e lastly, there are a few additional commands needed to setup the appropriate rights. with root being disabled by default, in order to join a workstation to the domain, a system group needs to be mapped to the windows domain admins group. using the net utility, from a terminal enter: sudo net groupmap add ntgroup=”domain admins” unixgroup=sysadmin r i d =512 type= d note change sysadmin to whichever group you prefer. also, the user used to join the domain needs to be a member of the sysadmin group, as well as a member of the system admin group. the admin group allows sudo use. if the user does not have samba credentials yet, you can add them with the smbpasswd utility, change the sysadmin username appropriately: sudo smbpasswd−a sysadmin rpc r i g h t s grant−u sysadmin ”example\domain admins” semachineaccountprivilege \ also, rights need to be explicitly provided to the domain admins group to allow the add machine script (and other admin functions) to work. this is achieved by executing: net seprintoperatorprivilege seaddusersprivilege sediskoperatorprivilege \ seremoteshutdownprivilege you should now be able to join windows clients to the domain in the same manner as joining them to an nt4 domain running on a windows server. backup domain controller with a primary domain controller (pdc) on the network it is best to have a backup domain controller (bdc) as well. this will allow clients to authenticate in case the pdc becomes unavailable. when configuring samba as a bdc you need a way to sync account information with the pdc. there are multiple ways of accomplishing this scp, rsync, or by using ldap as the passdb backend. using ldap is the most robust way to sync account information, because both domain controllers can use the same information in real time. however, setting up a ldap server may be overly complicated for a small number of user and computer accounts. see ??? for details. first, install samba and libpam-winbind. from a terminal enter: sudo apt i n s t a l l samba libpam−winbind now, edit /etc/samba/smb.conf and uncomment the following in the [global]: workgroup = example . . . s e c u r i t y = user in the commented domains uncomment or add: domain logons = yes domain master = no 138

139

make sure a user has rights to read the files in /var/lib/samba. for example, to allow users in the admin group to scp the files, enter: sudo chgrp−r admin / var / l i b /samba sudo scp−r username@pdc :/ var / l i b /samba / var / l i b next, sync the user accounts, using scp to copy the /var/lib/samba directory from the pdc: note replace username with a valid username and pdc with the hostname or ip address of your actual pdc. finally, restart samba: sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e you can test that your backup domain controller is working by stopping the samba daemon on the pdc, then trying to login to a windows client joined to the domain. another thing to keep in mind is if you have configured the logon home option as a directory on the pdc, and the pdc becomes unavailable, access to the user’s home drive will also be unavailable. for this reason it is best to configure the logon home to reside on a separate file server from the pdc and bdc. resources • for in depth samba configurations see the samba howto collection • the guide is also available in printed format. • o’reilly’s using samba is also a good reference. • chapter 4 of the samba howto collection explains setting up a primary domain controller. • chapter 5 of the samba howto collection explains setting up a backup domain controller. • the ubuntu wiki samba page. file server one of the most common ways to network ubuntu and windows computers is to configure samba as a file server. this section covers setting up a samba server to share files with windows clients. the server will be configured to share files with any client on the network without prompting for a password. if your environment requires stricter access controls see securing file and print server. installation the first step is to install the samba package. from a terminal prompt enter: sudo apt i n s t a l l samba that’s all there is to it; you are now ready to configure samba to share files. 139

140

configuration the main samba configuration file is located in /etc/samba/smb.conf. the default configuration file has a significant number of comments in order to document various configuration directives. note not all the available options are included in the default configuration file. see the smb.conf man page or the samba howto collection for more details. first, edit the following key/value pairs in the [global] section of /etc/samba/smb.conf: workgroup = example . . . s e c u r i t y = user the security parameter is farther down in the [global] section, and is commented by default. also, change example to better match your environment. create a new section at the bottom of the file, or uncomment one of the examples, for the directory to be shared: [ share ] comment = ubuntu f i l e server share path = / srv /samba/ share browsable = yes guest ok = yes read only = no create mask = 0755 • comment: a short description of the share. adjust to fit your needs. • path: the path to the directory to share. this example uses /srv/samba/sharename because, according to the filesystem hierarchy standard (fhs), /srv is where site-specific data should be served. technically samba shares can be placed anywhere on the filesystem as long as the permissions are correct, but adhering to standards is recom- mended. • browsable: enables windows clients to browse the shared directory using windows explorer. • guest ok: allows clients to connect to the share without supplying a password. • read only: determines if the share is read only or if write privileges are granted. write privileges are allowed only when the value is no, as is seen in this example. if the value is yes, then access to the share is read only. • create mask: determines the permissions new files will have when created. now that samba is configured, the directory needs to be created and the permissions changed. from a terminal enter: sudo mkdir−p / srv /samba/ share sudo chown nobody : nogroup / srv /samba/ share / note the -p switch tells mkdir to create the entire directory tree if it doesn’t exist. finally, restart the samba services to enable the new configuration: sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e 140

141

warning once again, the above configuration gives all access to any client on the local network. for a more secure configuration see securing file and print server. from a windows client you should now be able to browse to the ubuntu file server and see the shared directory. if your client doesn’t show your share automatically, try to access your server by its ip address, e.g. \\192.168.1.1, in a windows explorer window. to check that everything is working try creating a directory from windows. to create additional shares simply create new [dir] sections in /etc/samba/smb.conf, and restart samba. just make sure that the directory you want to share actually exists and the permissions are correct. note the file share named “[share]” and the path /srv/samba/share are just examples. adjust the share and path names to fit your environment. it is a good idea to name a share after a directory on the file system. another example would be a share name of [qa] with a path of /srv/samba/qa. resources • for in depth samba configurations see the samba howto collection • the guide is also available in printed format. • o’reilly’s using samba is another good reference. • the ubuntu wiki samba page. samba computer networks are often comprised of diverse systems, and while operating a network made up entirely of ubuntu desktop and server computers would certainly be fun, some network environments must consist of both ubuntu and microsoft windows systems working together in harmony. this section of the ubuntu sg-title introduces principles and tools used in configuring your ubuntu server for sharing network resources with windows computers. introduction successfully networking your ubuntu system with windows clients involves providing and integrating with services common to windows environments. such services assist the sharing of data and information about the computers and users involved in the network, and may be classified under three major categories of functionality: • file and printer sharing services. using the server message block (smb) protocol to facilitate the sharing of files, folders, volumes, and the sharing of printers throughout the network. • directory services. sharing vital information about the computers and users of the network with such technologies as the lightweight directory access protocol (ldap) and microsoft active directory. • authentication and access. establishing the identity of a computer or user of the network and determining the information the computer or user is authorized to access using such principles and technologies as file permissions, group policies, and the kerberos authentication service. 141

142

fortunately, your ubuntu system may provide all such facilities to windows clients and share network resources among them. one of the principal pieces of software your ubuntu system includes for windows networking is the samba suite of smb server applications and tools. this section of the ubuntu sg-title will introduce some of the common samba use cases, and how to install and configure the necessary packages. additional detailed documentation and information on samba can be found on the samba website. print server another common use of samba is to configure it to share printers installed, either locally or over the network, on an ubuntu server. similar to file server this section will configure samba to allow any client on the local network to use the installed printers without prompting for a username and password. for a more secure configuration see securing file and print server. installation before installing and configuring samba it is best to already have a working cups installation. see ??? for details. to install the samba package, from a terminal enter: sudo apt i n s t a l l samba configuration after installing samba edit /etc/samba/smb.conf. change the workgroup attribute to what is appropriate for your network, and change security to user: workgroup = example . . . s e c u r i t y = user in the [printers] section change the guest ok option to yes: browsable = yes guest ok = yes after editing smb.conf restart samba: sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e the default samba configuration will automatically share any printers installed. simply install the printer locally on your windows clients. resources • for in depth samba configurations see the samba howto collection • the guide is also available in printed format. • o’reilly’s using samba is another good reference. • also, see the cups website for more information on configuring cups. 142

143

• the ubuntu wiki samba page. securing file and print server samba security modes there are two security levels available to the common internet filesystem (cifs) network protocol user- level and share-level. samba’s security mode implementation allows more flexibility, providing four ways of implementing user-level security and one way to implement share-level: • security = user: requires clients to supply a username and password to connect to shares. samba user accounts are separate from system accounts, but the libpam-winbind package will sync system users and passwords with the samba user database. • security = domain: this mode allows the samba server to appear to windows clients as a primary domain controller (pdc), backup domain controller (bdc), or a domain member server (dms). see as a domain controller for further information. • security = ads: allows the samba server to join an active directory domain as a native member. see active directory integration for details. • security = server: this mode is left over from before samba could become a member server, and due to some security issues should not be used. see the server security section of the samba guide for more details. • security = share: allows clients to connect to shares without supplying a username and password. the security mode you choose will depend on your environment and what you need the samba server to accomplish. security = user this section will reconfigure the samba file and print server, from file server and print server, to require authentication. first, install the libpam-winbind package which will sync the system users to the samba user database: sudo apt i n s t a l l libpam−winbind note if you chose the samba server task during installation libpam-winbind is already installed. edit /etc/samba/smb.conf, and in the [share] section change: guest ok = no finally, restart samba for the new settings to take effect: sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e now when connecting to the shared directories or printers you should be prompted for a username and password. note if you choose to map a network drive to the share you can check the “reconnect at logon” check box, which will require you to only enter the username and password once, at least until the password changes. 143

144

share security there are several options available to increase the security for each individual shared directory. using the [share] example, this section will cover some common options. groups groups define a collection of computers or users which have a common level of access to particular network resources and offer a level of granularity in controlling access to such resources. for example, if a group qa is defined and contains the users freda, danika, and rob and a second group support is defined and consists of users danika, jeremy, and vincent then certain network resources configured to allow access by the qa group will subsequently enable access by freda, danika, and rob, but not jeremy or vincent. since the user danika belongs to both the qa and support groups, she will be able to access resources configured for access by both groups, whereas all other users will have only access to resources explicitly allowing the group they are part of. by default samba looks for the local system groups defined in /etc/group to determine which users belong to which groups. for more information on adding and removing users from groups see ???. when defining groups in the samba configuration file, /etc/samba/smb.conf, the recognized syntax is to preface the group name with an “@” symbol. for example, if you wished to define a group named sysadmin in a certain section of the /etc/samba/smb.conf, you would do so by entering the group name as @sysadmin. file permissions file permissions define the explicit rights a computer or user has to a particular directory, file, or set of files. such permissions may be defined by editing the /etc/samba/smb.conf file and specifying the explicit permissions of a defined file share. for example, if you have defined a samba share called share and wish to give read-only permissions to the group of users known as qa, but wanted to allow writing to the share by the group called sysadmin and the user named vincent, then you could edit the /etc/samba/smb.conf file, and add the following entries under the [share] entry: read l i s t = @qa write l i s t = @sysadmin , vincent another possible samba permission is to declare administrative permissions to a particular shared resource. users having administrative permissions may read, write, or modify any information contained in the resource the user has been given explicit administrative permissions to. for example, if you wanted to give the user melissa administrative permissions to the share example, you would edit the /etc/samba/smb.conf file, and add the following line under the [share] entry: admin users = melissa after editing /etc/samba/smb.conf, restart samba for the changes to take effect: sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e note for the read list and write list to work the samba security mode must not be set to security = share 144

145

now that samba has been configured to limit which groups have access to the shared directory, the filesystem permissions need to be updated. traditional linux file permissions do not map well to windows nt access control lists (acls). fortunately posix acls are available on ubuntu servers providing more fine grained control. for example, to enable acls on /srv an ext3 filesystem, edit /etc/fstab adding the acl option: ext3 noatime , relatime , a c l 0 1 uuid=66bcdd2e−8861−4fb0−b7e4−e61c569fe17d / srv sudo mount−v−o remount / srv then remount the partition: note the above example assumes /srv on a separate partition. if /srv, or wherever you have configured your share path, is part of the / partition a reboot may be required. to match the samba configuration above the sysadmin group will be given read, write, and execute permis- sions to /srv/samba/share, the qa group will be given read and execute permissions, and the files will be owned by the username melissa. enter the following in a terminal: sudo chown−r melissa / srv /samba/ share / sudo chgrp−r sysadmin / srv /samba/ share / sudo s e t f a c l −r−m g : qa : rx / srv /samba/ share / note the setfacl command above gives execute permissions to all files in the /srv/samba/share direc- tory, which you may or may not want. now from a windows client you should notice the new file permissions are implemented. see the acl and setfacl man pages for more information on posix acls. samba apparmor profile ubuntu comes with the apparmor security module, which provides mandatory access controls. the default apparmor profile for samba will need to be adapted to your configuration. for more details on using apparmor see ???. there are default apparmor profiles for /usr/sbin/smbd and /usr/sbin/nmbd, the samba daemon binaries, as part of the apparmor-profiles packages. to install the package, from a terminal prompt enter: sudo apt i n s t a l l apparmor−p r o f i l e s apparmor−u t i l s note this package contains profiles for several other binaries. by default the profiles for smbd and nmbd are in complain mode allowing samba to work without modifying the profile, and only logging errors. to place the smbd profile into enforce mode, and have samba work as expected, the profile will need to be modified to reflect any directories that are shared. edit /etc/apparmor.d/usr.sbin.smbd adding information for [share] from the file server example: / srv /samba/ share / r , / srv /samba/ share /** rwkix , now place the profile into enforce and reload it: 145

146

sudo aa−enforce / usr / sbin /smbd cat / etc /apparmor . d/ usr . sbin . smbd | sudo apparmor_parser−r you should now be able to read, write, and execute files in the shared directory as normal, and the smbd binary will have access to only the configured files and directories. be sure to add entries for each directory you configure samba to share. also, any errors will be logged to /var/log/syslog. resources • for in depth samba configurations see the samba howto collection • the guide is also available in printed format. • o’reilly’s using samba is also a good reference. • chapter 18 of the samba howto collection is devoted to security. • for more information on samba and acls see the samba acls page. • the ubuntu wiki samba page. samba - openldap backend note this section is flagged as legacy because nowadays samba 4 is best integrated with its own ldap server in ad mode. integrating samba with ldap as described here covers the nt4 mode, deprecated for many years. this section covers the integration of samba with ldap. the samba server’s role will be that of a “standalone” server and the ldap directory will provide the authentication layer in addition to containing the user, group, and machine account information that samba requires in order to function (in any of its 3 possible roles). the pre-requisite is an openldap server configured with a directory that can accept authentication requests. see service - ldap and service - ldap with tls for details on fulfilling this requirement. once those steps are completed, you will need to decide what specifically you want samba to do for you and then configure it accordingly. this guide will assume that the ldap and samba services are running on the same server and therefore use sasl external authentication whenever changing something under cn=config. if that is not your scenario, you will have to run those ldap commands on the ldap server. software installation there are two packages needed when integrating samba with ldap: samba and smbldap-tools. strictly speaking, the smbldap-tools package isn’t needed, but unless you have some other way to manage the various samba entities (users, groups, computers) in an ldap context then you should install it. install these packages now: sudo apt i n s t a l l samba smbldap−t o o l s 146

147

ldap configuration we will now configure the ldap server so that it can accomodate samba data. we will perform three tasks in this section: • import a schema • index some entries • add objects samba schema in order for openldap to be used as a backend for samba, the dit will need to use attributes that can properly describe samba data. such attributes can be obtained by introducing a samba ldap schema. let’s do this now. the schema is found in the now-installed samba package and is already in the ldif format. we can import it with one simple command: sudo ldapadd−q−y external−h ldapi :///−f / usr / share /doc/samba/ examples/ldap sudo ldapsearch−q−lll−y external−h ldapi :///−b cn=schema , cn=c o n f i g ’ cn=* to query and view this new schema: /samba . l d i f samba* ’ samba indices now that slapd knows about the samba attributes, we can set up some indices based on them. indexing entries is a way to improve performance when a client performs a filtered search on the dit. create the file samba_indices.ldif with the following contents: dn : olcdatabase={1}mdb, cn=c o n f i g changetype : modify r e p l a c e : olcdbindex olcdbindex : objectclass eq olcdbindex : uidnumber , gidnumber eq olcdbindex : l o g i n s h e l l eq olcdbindex : uid , cn eq , sub olcdbindex : memberuid eq , sub olcdbindex : member , uniquemember eq olcdbindex : olcdbindex : olcdbindex : olcdbindex : olcdbindex : sambadomainname eq olcdbindex : d e f a u l t sambasid eq sambaprimarygroupsid eq sambagrouptype eq sambasidlist eq sub , eq using the ldapmodify utility load the new indices: sudo ldapmodify−q−y external−h ldapi :///−f if all went well you should see the new indices using ldapsearch: samba_indices . l d i f 147

148

sudo ldapsearch−q−lll−y external−h \ ldapi :///−b cn=c o n f i g olcdatabase={1}mdb olcdbindex adding samba ldap objects next, configure the smbldap-tools package to match your environment. the package comes with a configu- ration helper script called smbldap-config. before running it, though, you should decide on two important configuration settings in /etc/samba/smb.conf: • netbios name: how this server will be known. the default value is derived from the server’s hostname, but truncated at 15 characters. • workgroup: the workgroup name for this server, or, if you later decide to make it a domain controller, this will be the domain. it’s important to make these choices now because smbldap-config will use them to generate the config that will be later stored in the ldap directory. if you run smbldap-config now and later change these values in /etc/samba/smb.conf there will be an inconsistency. once you are happy with netbios name and workgroup, proceed to generate the smbldap-tools configuration by running the configuration script which will ask you some questions: sudo smbldap−c o n f i g some of the more important ones: • workgroup name: has to match what you will configure in /etc/samba/smb.conf later on. • ldap suffix: has to match the ldap suffix you chose when you configured the ldap server. • other ldap suffixes: they are all relative to ldap suffix above. for example, for ldap user suffix you should use ou=people, and for computer/machines, use ou=computers. • ldap master bind dn and bind password: use the rootdn credentials. the smbldap-populate script will then add the ldap objects required for samba. password for the “domain root” user, which is also the “root” user stored in ldap: it will ask you for a the -g, -u and -r parameters tell smbldap-tools where to start the numeric uid and gid allocation for the ldap users. you should pick a range start that does not overlap with your local /etc/passwd users. sudo smbldap−populate−g 10000−u 10000−r 10000 you can create a ldif file containing the new samba objects by executing sudo smbldap−populate−e samba.ldif. this allows you to look over the changes making sure everything is correct. if it is, rerun the script without the ‘-e’ switch. alternatively, you can take the ldif file and import its data per usual. your ldap directory now has the necessary information to authenticate samba users. samba configuration to configure samba to use ldap, edit its configuration file /etc/samba/smb.conf commenting out the default passdb backend parameter and adding some ldap-related ones. make sure to use the same values you used when running smbldap-populate: # passdb backend = tdbsam workgroup = example # ldap s e t t i n g s 148

149

passdb backend = ldapsam : ldap :// ldap01 . example . com ldap s u f f i x = dc=example , dc=com ldap user s u f f i x = ou=people ldap group s u f f i x = ou=groups ldap machine s u f f i x = ou=computers ldap idmap s u f f i x = ou=idmap ldap admin dn = cn=admin , dc=example , dc=com ldap s s l = s t a r t ldap passwd sync = yes t l s change the values to match your environment. note the smb.conf as shipped by the package is quite long and has many configuration examples. an easy way to visualize it without any comments is to run testparm -s. now inform samba about the rootdn user’s password (the one set during the installation of the slapd package): as a final step to have your ldap users be able to connect to samba and authenticate, we need these users to also show up in the system as “unix” users. use sssd for that as detailed in service - sssd. install sssd-ldap sudo apt i n s t a l l sudo smbpasswd−w sssd−ldap configure /etc/sssd/sssd.conf : [ sssd ] c o n f i g _ f i l e _ v e r s i o n = 2 domains = example . com [ domain/example . com ] id_provider = ldap auth_provider = ldap ldap_uri = ldap :// ldap01 . example . com cache_credentials = true ldap_search_base = dc=example , dc=com adjust permissions and start the service: sudo chmod 0600 / etc / sssd / sssd . conf sudo chown root : root / etc / sssd / sssd . conf sudo systemctl s t a r t sssd restart the samba services: sudo systemctl r e s t a r t smbd . s e r v i c e nmbd. s e r v i c e to quickly test the setup, see if getent can list the samba groups: $ getent group replicators replicators : * : 5 5 2 : note the names are case sensitive! 149

150

if you have existing ldap users that you want to include in your new ldap-backed samba they will, of course, also need to be given some of the extra samba specific attributes. the smbpasswd utility can do this for you: sudo smbpasswd−a username you will prompted to enter a password. it will be considered as the new password for that user. making it the same as before is reasonable. note that this command cannot be used to create a new user from scratch in ldap (unless you are using ldapsam:trusted and ldapsam:editposix, not covered in this guide). to manage user, group, and machine accounts use the utilities provided by the smbldap-tools package. here are some examples: • to add a new user with a home directory: sudo smbldap−useradd−a−p−m username the -a option adds the samba attributes, and the -p option calls the smbldap-passwd utility after the user is created allowing you to enter a password for the user. finally, -m creates a local home directory. test with the getent command: getent passwd username in the above command, use the -r option to remove the user’s home directory. • to remove a user: • to add a group: • to make an existing user a member of a group: as for smbldap-useradd, the -a adds the samba attributes. sudo smbldap−u s e r d e l username sudo smbldap−groupadd−a groupname sudo smbldap−groupmod−m username groupname sudo smbldap−groupmod−x username groupname sudo smbldap−useradd−t 0−w username • to add a samba machine account: the -m option can add more than one user at a time by listing them in comma-separated format. • to remove a user from a group: replace username with the name of the workstation. the -t 0 option creates the machine account without a delay, while the -w option specifies the user as a machine account. resources • upstream documentation collection: https://www.samba.org/samba/docs/ • upstream samba wiki: https://wiki.samba.org/index.php/main_page 150

151

cups - print server the primary mechanism for ubuntu printing and print services is the common unix printing system (cups). this printing system is a freely available, portable printing layer which has become the new standard for printing in most linux distributions. cups manages print jobs and queues and provides network printing using the standard internet printing protocol (ipp), while offering support for a very large range of printers, from dot-matrix to laser and many in between. cups also supports postscript printer description (ppd) and auto-detection of network printers, and features a simple web-based configuration and administration tool. installation to install cups on your ubuntu computer, simply use sudo with the apt command and give the packages to install as the first parameter. a complete cups install has many package dependencies, but they may all be specified on the same command line. enter the following at a terminal prompt to install cups: sudo apt i n s t a l l cups upon authenticating with your user password, the packages should be downloaded and installed without error. upon the conclusion of installation, the cups server will be started automatically. for troubleshooting purposes, you can access cups server errors via the error log file at: /var/log/cups/ error_log. if the error log does not show enough information to troubleshoot any problems you encounter, the verbosity of the cups log can be increased by changing the loglevel directive in the configuration file (discussed below) to “debug” or even “debug2”, which logs everything, from the default of “info”. if you make this change, remember to change it back once you’ve solved your problem, to prevent the log file from becoming overly large. configuration the common unix printing system server’s behavior is configured through the directives contained in the file /etc/cups/cupsd.conf. the cups configuration file follows the same syntax as the primary configuration file for the apache http server, so users familiar with editing apache’s configuration file should feel at ease when editing the cups configuration file. some examples of settings you may wish to change initially will be presented here. tip prior to editing the configuration file, you should make a copy of the original file and protect it from writing, so you will have the original settings as a reference, and to reuse as necessary. copy the /etc/cups/cupsd.conf file and protect it from writing with the following commands, issued at a terminal prompt: sudo cp / etc /cups/cupsd . conf / etc /cups/cupsd . conf . o r i g i n a l sudo chmod a−w / etc /cups/cupsd . conf . o r i g i n a l • serveradmin: to configure the email address of the designated administrator of the cups server, simply edit the /etc/cups/cupsd.conf configuration file with your preferred text editor, and add or modify the serveradmin line accordingly. for example, if you are the administrator for the cups server, and your e-mail address is ‘bjoy@somebigco.com’, then you would modify the serveradmin line to appear as such: serveradmin bjoy@somebigco . com 151

152

• listen: by default on ubuntu, the cups server installation listens only on the loopback interface at ip address 127.0.0.1. in order to instruct the cups server to listen on an actual network adapter’s ip address, you must specify either a hostname, the ip address, or optionally, an ip address/port pairing via the addition of a listen directive. for example, if your cups server resides on a local network at the ip address 192.168.10.250 and you’d like to make it accessible to the other systems on this subnetwork, you would edit the /etc/cups/cupsd.conf and add a listen directive, as such: listen 1 2 7 . 0 . 0 . 1 : 6 3 1 listen / var /run/cups/cups . sock # e x i s t i n g socket listen listen 1 92 .1 68 .1 0.2 50 :6 31 # listen on the lan i n t e r f a c e , port 631 ( # e x i s t i n g loopback listen ipp) in the example above, you may comment out or remove the reference to the loopback address (127.0.0.1) if you do not wish cupsd to listen on that interface, but would rather have it only lis- ten on the ethernet interfaces of the local area network (lan). to enable listening for all network interfaces for which a certain hostname is bound, including the loopback, you could create a listen entry for the hostname socrates as such: listen s o c r a t e s :631 # listen on a l l the hostname ’ socrates i n t e r f a c e s f o r ’ or by omitting the listen directive and using port instead, as in: port 631 # listen on port 631 on a l l i n t e r f a c e s for more examples of configuration directives in the cups server configuration file, view the associated system manual page by entering the following command at a terminal prompt: man cupsd . conf note whenever you make changes to the /etc/cups/cupsd.conf configuration file, you’ll need to restart the cups server by typing the following command at a terminal prompt: sudo systemctl r e s t a r t cups . s e r v i c e web interface tip cups can be configured and monitored using a web interface, which by default is available at http://localhost:631/admin. the web interface can be used to perform all printer management tasks. in order to perform administrative tasks via the web interface, you must either have the root account enabled on your server, or authenticate as a user in the lpadmin group. for security reasons, cups won’t authenticate a user that doesn’t have a password. to add a user to the lpadmin group, run at the terminal prompt: sudo usermod−ag lpadmin username further documentation is available in the documentation/help tab of the web interface. 152

153

references cups website debian open-iscsi page domain name service (dns) domain name service (dns) is an internet service that maps ip addresses and fully qualified domain names (fqdn) to one another. in this way, dns alleviates the need to remember ip addresses. computers that run dns are called name servers. ubuntu ships with bind (berkley internet naming daemon), the most common program used for maintaining a name server on linux. installation at a terminal prompt, enter the following command to install dns: sudo apt i n s t a l l bind9 a very useful package for testing and troubleshooting dns issues is the dnsutils package. very often these tools will be installed already, but to check and/or install dnsutils enter the following: sudo apt i n s t a l l d n s u t i l s configuration there are many ways to configure bind9. some of the most common configurations are a caching nameserver, primary server, and secondary server. • when configured as a caching nameserver bind9 will find the answer to name queries and remember the answer when the domain is queried again. • as a primary server, bind9 reads the data for a zone from a file on its host and is authoritative for that zone. • as a secondary server, bind9 gets the zone data from another nameserver that is authoritative for the zone. overview the dns configuration files are stored in the /etc/bind directory. the primary configuration file is /etc/ bind/named.conf, which in the layout provided by the package just includes these files. • /etc/bind/named.conf.options: global dns options • /etc/bind/named.conf.local: for your zones the root nameservers used to be described in the file /etc/bind/db.root. this is now provided instead • /etc/bind/named.conf.default−zones: default zones such as localhost, its reverse, and the root hints by the /usr/share/dns/root.hints file shipped with the dns−root−data package, and is referenced in the named.conf.default−zones configuration file above. it is possible to configure the same server to be a caching name server, primary, and secondary: it all depends on the zones it is serving. a server can be the start of authority (soa) for one zone, while 153

154

providing secondary service for another zone. all the while providing caching services for hosts on the local lan. caching nameserver the default configuration acts as a caching server. simply uncomment and edit /etc/bind/named.conf. options to set the ip addresses of your isp’s dns servers: forwarders { 1 . 2 . 3 . 4 ; 5 . 6 . 7 . 8 ; }; note replace 1.2.3.4 and 5.6.7.8 with the ip addresses of actual nameservers. to enable the new configuration, restart the dns server. from a terminal prompt: sudo systemctl r e s t a r t bind9 . s e r v i c e see dig for information on testing a caching dns server. primary server in this section bind9 will be configured as the primary server for the domain example.com. simply replace example.com with your fqdn (fully qualified domain name). forward zone file to add a dns zone to bind9, turning bind9 into a primary server, first edit /etc/bind/named.conf.local: zone ”example . com” { type master ; f i l e ”/ etc /bind/db . example . com ” ; }; note if bind will be receiving automatic updates to the file as with ddns, then use /var/lib/bind /db.example.com rather than /etc/bind/db.example.com both here and in the copy command below. now use an existing zone file as a template to create the /etc/bind/db.example.com file: sudo cp / etc /bind/db . l o c a l / etc /bind/db . example . com edit the new zone file /etc/bind/db.example.com and change localhost . to the fqdn of your server, leaving the additional . at the end. change 127.0.0.1 to the nameserver’s ip address and root. localhost to a valid email address, but with a . instead of the usual @ symbol, again leaving the . at the end. change the comment to indicate the domain that this file is for. create an a record for the base domain, example.com. also, create an a record for ns.example.com, the name server in this example: ; ; bind data f i l e ; $ttl f o r example . com 604800 154

155

@ in soa example . com . 2 604800 86400 2419200 604800 ) root . example . com . ( ; s e r i a l ; refresh ; retry ; expire ; negative cache ttl @ @ @ ns in in in in ns a aaaa a ns . example . com . 1 9 2 . 1 6 8 . 1 . 1 0 : : 1 1 9 2 . 1 6 8 . 1 . 1 0 you must increment the serial number every time you make changes to the zone file. if you make multiple changes before restarting bind9, simply increment the serial once. now, you can add dns records to the bottom of the zone file. see common record types for details. note many admins like to use the last date edited as the serial of a zone, such as 2020012100 which is yyyymmddss (where ss is the serial number) once you have made changes to the zone file bind9 needs to be restarted for the changes to take effect: sudo systemctl r e s t a r t bind9 . s e r v i c e reverse zone file now that the zone is setup and resolving names to ip addresses, a reverse zone needs to be added to allows dns to resolve an address to a name. edit /etc/bind/named.conf.local and add the following: zone ” 1 . 1 6 8 . 1 9 2 . in−addr . arpa ” { type master ; f i l e ”/ etc /bind/db . 1 9 2 ” ; }; note replace 1.168.192 with the first three octets of whatever network you are using. also, name the zone file /etc/bind/db.192 appropriately. it should match the first octet of your network. now create the /etc/bind/db.192 file: sudo cp / etc /bind/db .127 / etc /bind/db .192 next edit /etc/bind/db.192 changing the same options as /etc/bind/db.example.com: ; ; bind r e v e r s e data f i l e ; $ttl @ l o c a l 1 9 2 . 1 6 8 . 1 .xxx net ns . example . com . 604800 in soa f o r 2 604800 86400 2419200 604800 ) ( root . example . com . ; s e r i a l ; refresh ; retry ; expire ; negative cache ttl 155

156

; @ 10 in in ns ptr ns . ns . example . com . the serial number in the reverse zone needs to be incremented on each change as well. for each a record you configure in /etc/bind/db.example.com, that is for a different address, you need to create a ptr record in /etc/bind/db.192. after creating the reverse zone file restart bind9: sudo systemctl r e s t a r t bind9 . s e r v i c e secondary server type master ; f i l e ”/ etc /bind/db . example . com ” ; once a primary server has been configured a secondary server is highly recommended in order to maintain the availability of the domain should the primary become unavailable. example forward and reverse zone definitions in /etc/bind/named.conf.local: zone ”example . com” { first, on the primary server, the zone transfer needs to be allowed. add the allow−transfer option to the allow−t r a n s f e r { 1 9 2 . 1 6 8 . 1 . 1 1 ; }; zone ” 1 . 1 6 8 . 1 9 2 . in−addr . arpa ” { allow−t r a n s f e r { 1 9 2 . 1 6 8 . 1 . 1 1 ; }; type master ; f i l e ”/ etc /bind/db . 1 9 2 ” ; }; }; note replace 192.168.1.11 with the ip address of your secondary nameserver. restart bind9 on the primary server: sudo systemctl r e s t a r t bind9 . s e r v i c e next, on the secondary server, install the bind9 package the same way as on the primary. then edit the /etc/bind/named.conf.local and add the following declarations for the forward and reverse zones: zone ”example . com” { type s l a v e ; f i l e ”db . example . com ” ; masters { 1 9 2 . 1 6 8 . 1 . 1 0 ; }; }; zone ” 1 . 1 6 8 . 1 9 2 . in−addr . arpa ” { type s l a v e ; f i l e ”db . 1 9 2 ” ; masters { 1 9 2 . 1 6 8 . 1 . 1 0 ; }; }; note replace 192.168.1.10 with the ip address of your primary nameserver. 156

157

restart bind9 on the secondary server: sudo systemctl r e s t a r t bind9 . s e r v i c e in /var/log/syslog you should see something similar to the following (some lines have been split to fit the format of this document): c l i e n t 192.168.1.10#39448: rec eived n o t i f y f o r zone ’ 1 . 1 6 8 . 1 9 2 . in−addr . arpa ’ s t a r t e d . from 192.168.1.10#53: t r a n s f e r of connected using 192.168.1.11#37531 zone 1 . 1 6 8 . 1 9 2 . in−addr . arpa/in : transfer ’ 1 0 0 . 1 8 . 1 7 2 . in−addr . arpa/in ’ zone 1 . 1 6 8 . 1 9 2 . in−addr . arpa/in : ’ 1 0 0 . 1 8 . 1 7 2 . in−addr . arpa/in ’ zone 1 . 1 6 8 . 1 9 2 . in−addr . arpa/in : t r a n s f e r of transfer completed : 1 messages , 6 records , 212 bytes , 0.002 s e c s c l i e n t 192.168.1.10#20329: zone example . com/in : transfer ’ example . com/in ’ t r a n s f e r of 192.168.1.11#38577 t r a n s f e r r e d s e r i a l 5 from 192.168.1.10#53: (106000 bytes / sec ) sending n o t i f i e s ( s e r i a l 5) rec eived n o t i f y f o r zone ’ example . com ’ s t a r t e d . from 192.168.1.10#53: connected using zone example . com/in : t r a n s f e r of ’ example . com/in ’ t r a n s f e r r e d s e r i a l 5 from 192.168.1.10#53: transfer completed : 1 messages , 8 records , 225 bytes , 0.002 s e c s (112500 bytes / sec ) }; in the example below: zone ”example . com” { type master ; f i l e ”/ etc /bind/db . example . com ” ; note note: a zone is only transferred if the serial number on the primary is larger than the one on the secondary. if you want to have your primary dns notifying other secondary dns servers of zone changes, you can add also−notify { ipaddress; }; to /etc/bind/named.conf.local as shown allow−t r a n s f e r { 1 9 2 . 1 6 8 . 1 . 1 1 ; }; also−n o t i f y { 1 9 2 . 1 6 8 . 1 . 1 1 ; }; zone ” 1 . 1 6 8 . 1 9 2 . in−addr . arpa ” { allow−t r a n s f e r { 1 9 2 . 1 6 8 . 1 . 1 1 ; }; also−n o t i f y { 1 9 2 . 1 6 8 . 1 . 1 1 ; }; type master ; f i l e ”/ etc /bind/db . 1 9 2 ” ; note the default directory for non-authoritative zone files is /var/cache/bind/. this directory is also configured in apparmor to allow the named daemon to write to it. for more information on apparmor see security - apparmor. }; troubleshooting this section covers diagnosing problems with dns and bind9 configurations. 157

158

testing resolv.conf the first step in testing bind9 is to add the nameserver’s ip address to a hosts resolver. the primary nameserver should be configured as well as another host to double check things. refer to dns client configuration for details on adding nameserver addresses to your network clients. in the end your nameserver line in /etc/resolv .conf should be pointing at 127.0.0.53 and you should have a search parameter for your domain. something like this: nameserver 1 2 7 . 0 . 0 . 5 3 search example . com to check which dns server your local resolver is using, run: systemd−r e s o l v e−−status note you should also add the ip address of the secondary nameserver to your client configuration in case the primary becomes unavailable. dig if you installed the dnsutils package you can test your setup using the dns lookup utility dig: • after installing bind9 use dig against the loopback interface to make sure it is listening on port 53. from a terminal prompt: dig−x 1 2 7 . 0 . 0 . 1 you should see lines similar to the following in the command output: ; ; query time : 1 msec ; ; server: 192.168.1.10#53(192.168.1.10) • if you have configured bind9 as a caching nameserver “dig” an outside domain to check the query time: dig ubuntu . com note the query time toward the end of the command output: ; ; query time : 49 msec after a second dig there should be improvement: ; ; query time : 1 msec ping now to demonstrate how applications make use of dns to resolve a host name use the ping utility to send an icmp echo request: ping example . com this tests if the nameserver can resolve the name ns.example.com to an ip address. the command output should resemble: 158

159

ping ns . example . com ( 1 9 2 . 1 6 8 . 1 . 1 0 ) 56(84) bytes of data . 64 bytes 64 bytes icmp_seq=1 t t l =64 time =0.800 ms icmp_seq=2 t t l =64 time =0.813 ms from 1 9 2 . 1 6 8 . 1 . 1 0 : from 1 9 2 . 1 6 8 . 1 . 1 0 : named-checkzone • to test our example forward zone file enter the following from a command prompt: this utility allows you to make sure the configuration is correct before restarting bind9 and making the changes live. a great way to test your zone files is by using the named−checkzone utility installed with the bind9 package. named−checkzone example . com / etc /bind/db . example . com named−checkzone 1 . 1 6 8 . 1 9 2 . in−addr . arpa / etc /bind/db .192 zone 1 . 1 6 8 . 1 9 2 . in−addr . arpa/in : if everything is configured correctly you should see output similar to: zone example . com/in : ok • similarly, to test the reverse zone file enter the following: the output should be similar to: loaded s e r i a l 3 loaded s e r i a l 6 ok note the serial number of your zone file will probably be different. quick temporary query logging with the rndc tool, you can quickly turn query logging on and off, without restarting the service or changing the configuration file. to turn query logging on, run: sudo rndc querylog on likewise, to turn it off, run: sudo rndc querylog o f f on ’ the logs will be sent to syslog and will show up in /var/log/syslog by default: jan 20 19:40:50 new−n1 named [ 8 1 6 ] : jan 20 19:40:50 new−n1 named [ 8 1 6 ] : query logging i s now on jan 20 19:40:57 new−n1 named [ 8 1 6 ] : ubuntu . com) : query : ubuntu . com in a +e(0)k ( 1 9 2 . 1 6 8 . 1 . 1 0 ) note the amount of logs generated by enabling querylog could be huge! receiv ed c o n t r o l channel command ’ querylog c l i e n t @0x7f48ec101480 192.168.1.10#36139 ( 159

160

bind9 has a wide variety of logging configuration options available, but the two main ones are channel and category, which configure where logs go, and what information gets logged, respectively. if no logging options are configured the default configuration is: logging { category d e f a u l t { default_syslog ; default_debug ; }; category unmatched { n u l l ; }; let’s instead configure bind9 to send debug messages related to dns queries to a separate file. we need to configure a channel to specify which file to send the messages to, and a category. in this example, the category will log all queries. edit /etc/bind/named.conf.local and add the following: logging { logging }; }; channel query . log { f i l e ”/ var / log /named/ query . log ” ; s e v e r i t y debug 3; }; category q u e r i e s { query . log ; }; note the debug option can be set from 1 to 3. if a level isn’t specified, level 1 is the default. • since the named daemon runs as the bind user the /var/log/named directory must be created and the ownership changed: sudo mkdir / var / log /named sudo chown bind : bind / var / log /named • now restart bind9 for the changes to take effect: r e s t a r t bind9 . s e r v i c e sudo systemctl you should see the file /var/log/named/query.log fill with query information. this is a simple example of the bind9 logging options. for coverage of advanced options see more information. references common record types this section covers some of the most common dns record types. • a record: this record maps an ip address to a hostname. www in a 1 9 2 . 1 6 8 . 1 . 1 2 • cname record: used to create an alias to an existing a record. you cannot create a cname record pointing to another cname record. web cname www in • mx record: used to define where email should be sent to. must point to an a record, not a cname. 160

161

• ns record: used to define which servers serve copies of a zone. it must point to an a record, not a @ mail in in mx 1 a mail . example . com . 1 9 2 . 1 6 8 . 1 . 1 3 cname. this is where primary and secondary servers are defined. @ @ ns ns2 ns . example . com . ns2 . example . com . 1 9 2 . 1 6 8 . 1 . 1 0 1 9 2 . 1 6 8 . 1 . 1 1 in in in in ns ns a a more information • upstream bind9 documentation • bind9.net has links to a large collection of dns and bind9 resources. • dns and bind is a popular book now in it’s fifth edition. there is now also a dns and bind on ipv6 book. • a great place to ask for bind9 assistance, and get involved with the ubuntu server community, is the #ubuntu-server irc channel on freenode. ftp server file transfer protocol (ftp) is a tcp protocol for downloading files between computers. in the past, it has also been used for uploading but, as that method does not use encryption, user credentials as well as data transferred in the clear and are easily intercepted. so if you are here looking for a way to upload and download files securely, see the openssh documentation instead. ftp works on a client/server model. the server component is called an ftp daemon. it continuously listens for ftp requests from remote clients. when a request is received, it manages the login and sets up the connection. for the duration of the session it executes any of commands sent by the ftp client. access to an ftp server can be managed in two ways: • anonymous • authenticated in the anonymous mode, remote clients can access the ftp server by using the default user account called “anonymous” or “ftp” and sending an email address as the password. in the authenticated mode a user must have an account and a password. this latter choice is very insecure and should not be used except in special circumstances. if you are looking to transfer files securely see sftp in the section on openssh-server. user access to the ftp server directories and files is dependent on the permissions defined for the account used at login. as a general rule, the ftp daemon will hide the root directory of the ftp server and change it to the ftp home directory. this hides the rest of the file system from remote sessions. vsftpd - ftp server installation vsftpd is an ftp daemon available in ubuntu. it is easy to install, set up, and maintain. to install vsftpd you can run the following command: sudo apt i n s t a l l vsftpd 161

162

anonymous ftp configuration by default vsftpd is not configured to allow anonymous download. if you wish to enable anonymous download edit /etc/vsftpd.conf by changing: anonymous_enable=yes during installation a ftp user is created with a home directory of /srv/ftp. this is the default ftp directory. if you wish to change this location, to /srv/ files /ftp for example, simply create a directory in another location and change the ftp user’s home directory: sudo mkdir−p / srv / f i l e s / ftp sudo usermod−d / srv / f i l e s / ftp ftp after making the change restart vsftpd: sudo systemctl r e s t a r t vsftpd . s e r v i c e finally, copy any files and directories you would like to make available through anonymous ftp to /srv/ files /ftp, or /srv/ftp if you wish to use the default. user authenticated ftp configuration by default vsftpd is configured to authenticate system users and allow them to download files. if you want users to be able to upload files, edit /etc/vsftpd.conf: write_enable=yes now restart vsftpd: sudo systemctl r e s t a r t vsftpd . s e r v i c e now when system users login to ftp they will start in their home directories where they can download, upload, create directories, etc. similarly, by default, anonymous users are not allowed to upload files to ftp server. to change this setting, you should uncomment the following line, and restart vsftpd: anon_upload_enable=yes warning enabling anonymous ftp upload can be an extreme security risk. anonymous upload on servers accessed directly from the internet. it is best to not enable the configuration file consists of many configuration parameters. the information about each parameter is available in the configuration file. alternatively, you can refer to the man page, man 5 vsftpd.conf for details of each parameter. securing ftp there are options in /etc/vsftpd.conf to help make vsftpd more secure. for example users can be limited to their home directories by uncommenting: chroot_local_user=yes you can also limit a specific list of users to just their home directories: 162

163

chroot_list_enable=yes c h r o o t _ l i s t _ f i l e=/etc / vsftpd . c h r o o t _ l i s t after uncommenting the above options, create a /etc/vsftpd.chroot_list containing a list of users one per line. then restart vsftpd: sudo systemctl r e s t a r t vsftpd . s e r v i c e also, the /etc/ftpusers file is a list of users that are disallowed ftp access. the default list includes root, daemon, nobody, etc. to disable ftp access for additional users simply add them to the list. ftp can also be encrypted using ftps. different from sftp, ftps is ftp over secure socket layer (ssl). sftp is a ftp like session over an encrypted ssh connection. a major difference is that users of sftp need to have a shell account on the system, instead of a nologin shell. providing all users with a shell may not be ideal for some environments, such as a shared web host. however, it is possible to restrict such accounts to only sftp and disable shell interaction. to configure ftps, edit /etc/vsftpd.conf and at the bottom add: ssl_enable=yes also, notice the certificate and key related options: r s a _ c e r t _ f i l e=/etc / s s l / c e r t s / s s l−cert−s n a k e o i l . pem rsa_private_key_file=/etc / s s l / private / s s l−cert−s n a k e o i l . key by default these options are set to the certificate and key provided by the ssl-cert package. in a production environment these should be replaced with a certificate and key generated for the specific host. for more information on certificates see security - certificates. now restart vsftpd, and non-anonymous users will be forced to use ftps: sudo systemctl r e s t a r t vsftpd . s e r v i c e to allow users with a shell of /usr/sbin/nologin access to ftp, but have no shell access, edit /etc/ shells adding the nologin shell: # / etc / s h e l l s : v a l i d l o g i n s h e l l s / bin / csh / bin /sh / usr / bin / es / usr / bin /ksh / bin /ksh / usr / bin / rc / usr / bin / tcsh / bin / tcsh / usr / bin / esh / bin /dash / bin /bash / bin / rbash / usr / bin / screen / usr / sbin / nologin this is necessary because, by default vsftpd uses pam for authentication, and the /etc/pam.d/vsftpd con- figuration file contains: required auth pam_shells . so 163

164

the shells pam module restricts access to shells listed in the /etc/ shells file. most popular ftp clients can be configured to connect using ftps. the lftp command line ftp client has the ability to use ftps as well. references • see the vsftpd website for more information. file servers if you have more than one computer on a single network. at some point you will probably need to share files between them. in this section we cover installing and configuring ftp, nfs, and cups. domain name service (dns) tbd iscsi initiator (or client) wikipedia iscsi definition: iscsi an acronym for internet small computer systems interface , an internet protocol (ip)-based storage networking standard for linking data storage facilities. it provides block-level access to storage devices by carrying scsi commands over a tcp/ip network. iscsi is used to facilitate data transfers over intranets and to manage storage over long distances. it can be used to transmit data over local area networks (lans), wide area networks (wans), or the internet and can enable location-independent data storage and retrieval. the protocol allows clients (called initiators) to send scsi commands (cdbs) to storage devices (targets) on remote servers. it is a storage area network (san) protocol, allowing organizations to consolidate storage into storage arrays while providing clients (such as database and web servers) with the illusion of locally attached scsi disks. it mainly competes with fibre channel, but unlike traditional fibre channel, which usually requires dedicated cabling, iscsi can be run over long distances using existing network infras- tructure. ubuntu server can be configured as both: iscsi initiator and iscsi target. this guide provides com- mands and configuration options to setup an iscsi initiator (or client). note: it is assumed that you already have an iscsi target on your local network and have the appropriate rights to connect to it. the instructions for setting up a target vary greatly between hardware providers, so consult your vendor documentation to configure your specific iscsi target. network interfaces configuration before start configuring iscsi, make sure to have the network interfaces correctly set and configured in order to have open-iscsi package to behave appropriately, specially during boot time. in ubuntu 20.04 lts, the default network configuration tool is netplan.io. 164

165

for all the iscsi examples bellow please consider the following netplan configuration for my iscsi initiator: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg { c o n f i g : disabled } /etc/netplan/50-cloud-init.yaml network : ethernets : enp5s0 : enp6s0 : match : enp7s0 : match : match : dhcp4 : true dhcp4 : true i s c s i 0 1 set−name : eth0 dhcp−i d e n t i f i e r : mac set−name : dhcp−i d e n t i f i e r : mac dhcp4−o v e r r i d e s : route−metric : 300 set−name : dhcp−i d e n t i f i e r : mac dhcp4−o v e r r i d e s : route−metric : 300 i s c s i 0 2 dhcp4 : true version : 2 renderer : networkd macaddress : 0 0 : 1 6 : 3 e : af : c4 : d6 macaddress : 0 0 : 1 6 : 3 e : 5 0 : 1 1 : 9 c macaddress : 0 0 : 1 6 : 3 e : b3 : cc :50 with this configuration, the interfaces names change by matching their mac addresses. this makes it easier to manage them in a server containing multiple interfaces. from this point and beyond, 2 interfaces are going to be mentioned: iscsi01 and iscsi02. this helps to demonstrate how to configure iscsi in a multipath environment as well (check the device mapper multipath session in this same server guide). if you have only a single interface for the iscsi network, make sure to follow the same instructions, but only consider the iscsi01 interface command line examples. iscsi initiator install to configure ubuntu server as an iscsi initiator install the open-iscsi package. in a terminal enter: $ sudo apt i n s t a l l open−i s c s i once the package is installed you will find the following files: • /etc/iscsi/iscsid.conf • /etc/iscsi/initiatorname.iscsi 165

166

iscsi initiator configuration configure the main configuration file like the example bellow: /etc/iscsi/iscsid.conf ### startup s e t t i n g s ## w i l l be c o n t r o l l e d by systemd , i s c s i d . startup = / usr / sbin / i s c s i d n o d e . startup = manual leave as i s ### chap s e t t i n g s # node . s e s s i o n . auth . authmethod = chap ## authentication of i n i t i a t o r by target # node . s e s s i o n . auth . username = username # node . s e s s i o n . auth . password = password ( s e s s i o n ) # discovery . sendtargets . auth . authmethod = chap ## authentication of # discovery . sendtargets . auth . username = username # discovery . sendtargets . auth . password = password i n i t i a t o r by target ( discovery ) ### timeouts l a y e r . ## c o n t r o l how much time ## upper i s d e s i r a b l e ## so multipath can handle path e r r o r s as quickly as p o s s i b l e ## ( and decide to queue or not node . s e s s i o n . timeo . replacement_timeout = 0 i f using multipath , having 0 here to propagate an e r r o r i f missing a l l paths ) takes i s c s i to the node . conn [ 0 ] . timeo . login_timeout = 15 node . conn [ 0 ] . timeo . logout_timeout = 15 f o r a nop−out request ## i n t e r v a l node . conn [ 0 ] . timeo . noop_out_interval = 5 ( a ping to the target ) ## and how much time to wait before d e c l a r i n g a timeout node . conn [ 0 ] . timeo . noop_out_timeout = 5 timeouts ## d e f a u l t node . s e s s i o n . err_timeo . abort_timeout = 15 node . s e s s i o n . err_timeo . lu_reset_timeout = 30 node . s e s s i o n . err_timeo . tgt_reset_timeout = 30 recovery l o g i c s e r r o r f o r ( lu & tgt r e s e t s ) ### r e t r y node . s e s s i o n . initial_login_retry_max = 8 ### s e s s i o n and device queue depth node . s e s s i o n . cmds_max = 128 node . s e s s i o n . queue_depth = 32 166

167

### performance node . s e s s i o n . xmit_thread_priority =−20 and re-start the iscsi daemon: $ systemctl r e s t a r t i s c s i d . s e r v i c e this will set basic things up for the rest of configuration. the other file mentioned: /etc/iscsi/initiatorname.iscsi initiatorname=iqn .1993−08. org . debian : 0 1 : 6 0 f3517884c3 contains this node’s initiator name and is generated during open-iscsi package installation. if you modify this setting, make sure that you don’t have duplicates in the same iscsi san (storage area network). iscsi network configuration before configuring the logical units that are going to be accessed by the initiator, it is important to inform the iscsi service what are the interfaces acting as paths. a straightforward way to do that is by: ’ s : . * \ s+l i n k / ether ’ s : . * \ s+l i n k / ether ] { 2 } ( \ : | ) ) {6}) . * : \ 1 : g ’ ) ] { 2 } ( \ : | ) ) {6}) . * : \ 1 : g ’ ) • configuring iscsi01 interface • configuring the following environment variables ’ s : . * (([0−9]{1 ,3}\.) $ i s c s i 0 1 _ i p=$ ( ip −4−o addr show i s c s i 0 1 | sed−r {3}[0−9]{1 ,3}) / . * : \ 1 : ’ ) ’ s : . * (([0−9]{1 ,3}\.) sed−r $ i s c s i 0 2 _ i p=$ ( ip −4−o addr show i s c s i 0 2 | {3}[0−9]{1 ,3}) / . * : \ 1 : ’ ) (([0− f sed−r $ iscsi01_mac=$ ( ip−o l i n k show i s c s i 0 1 | (([0− f $ iscsi02_mac=$ ( ip−o l i n k show i s c s i 0 2 | sed−r i s c s i 0 1−−op=new $ sudo iscsiadm−m i f a c e−i i s c s i 0 1−−op=update−n i f a c e . hwaddress−v $ sudo iscsiadm−m i f a c e−i i s c s i 0 1−−op=update−n i f a c e . ipaddress−v $ sudo iscsiadm−m i f a c e−i i s c s i 0 2−−op=new $ sudo iscsiadm−m i f a c e−i i s c s i 0 2−−op=update−n i f a c e . hwaddress−v $ sudo iscsiadm−m i f a c e−i $iscsi02_mac i s c s i 0 2 updated . $iscsi01_mac i s c s i 0 1 updated . • configuring iscsi02 interface new i n t e r f a c e i s c s i 0 1 added new i n t e r f a c e i s c s i 0 2 added $ i s c s i 0 1 _ i p i s c s i 0 1 updated . 167

168

$ i s c s i 0 2 _ i p storage . i s c s i 0 2 storage . i s c s i 0 1 i s c s i 0 2 updated . • discovering the targets • configuring automatic login $ sudo iscsiadm−m i f a c e−i i s c s i 0 2−−op=update−n i f a c e . ipaddress−v $ sudo iscsiadm−m discovery−i i s c s i 0 1−−op=new−−op=del−−type sendtargets −−portal 1 0 . 2 5 0 . 9 4 . 9 9 : 3 2 6 0 , 1 iqn .2003−01. org . linux−i s c s i . storage . x8664 : sn .2 c084c8320ca $ sudo iscsiadm−m discovery−i i s c s i 0 2−−op=new−−op=del−−type sendtargets −−portal 1 0 . 2 5 0 . 9 3 . 9 9 : 3 2 6 0 , 1 iqn .2003−01. org . linux−i s c s i . storage . x8664 : sn .2 c084c8320ca $ sudo iscsiadm−m node−−op=update−n node . conn [ 0 ] . startup−v automatic $ sudo iscsiadm−m node−−op=update−n node . startup−v automatic $ systemctl enable open−i s c s i synchronizing s t a t e of open−i s c s i . s e r v i c e with sysv s e r v i c e systemd/systemd−sysv−i n s t a l l . executing : / l i b /systemd/systemd−sysv−i n s t a l l enable open−i s c s i created symlink / etc /systemd/system/ i s c s i . s e r v i c e → / l i b /systemd/system/open− created symlink / etc /systemd/system/ s y s i n i t . target . wants/open−i s c s i . s e r v i c e → / l i b /systemd/system/open−i s c s i . s e r v i c e . systemd/systemd−sysv−i n s t a l l . executing : / l i b /systemd/systemd−sysv−i n s t a l l created symlink / etc /systemd/system/ s y s i n i t . target . wants/ i s c s i d . s e r v i c e → / • make sure needed services are enabled during os initialization: $ systemctl enable synchronizing s t a t e of l i b /systemd/system/ i s c s i d . s e r v i c e . i s c s i d . s e r v i c e with sysv s e r v i c e s c r i p t with / l i b / s c r i p t with / l i b / i s c s i . s e r v i c e . enable i s c s i d i s c s i d • restarting iscsid service $ systemctl r e s t a r t i s c s i d . s e r v i c e • and, finally, login in discovered logical units $ sudo iscsiadm−m node−−l o g i n a l l=automatic logging in to [ i f a c e : x8664 : sn .2 c084c8320ca , portal : 1 0 . 2 5 0 . 9 3 . 9 9 , 3 2 6 0 ] i s c s i 0 2 , target : logging in to [ i f a c e : i s c s i 0 1 , target : x8664 : sn .2 c084c8320ca , portal : 1 0 . 2 5 0 . 9 4 . 9 9 , 3 2 6 0 ] ( multiple ) iqn .2003−01. org . linux−i s c s i . storage . iqn .2003−01. org . linux−i s c s i . storage . iqn .2003−01. org . linux−i s c s i . storage . x8664 : sn iqn .2003−01. org . linux−i s c s i . storage . x8664 : sn s u c c e s s f u l . s u c c e s s f u l . ( multiple ) login to [ i f a c e : i s c s i 0 2 , target : .2 c084c8320ca , portal : 1 0 . 2 5 0 . 9 3 . 9 9 , 3 2 6 0 ] login to [ i f a c e : i s c s i 0 1 , target : .2 c084c8320ca , portal : 1 0 . 2 5 0 . 9 4 . 9 9 , 3 2 6 0 ] accessing the logical units (or luns) check dmesg to make sure that the new disks have been detected: 168

169

0002 pq: 0 ansi : 5 0002 pq: 0 ansi : 5 dmesg [ 166.840694] 166.840892] 166.841741] 166.841808] 166.842278] 166.842571] 0002 pq: 0 ansi : 5 0002 pq: 0 ansi : 5 166.843482] 166.843681] 166.843706] (1.07 gb/1.00 gib) 166.843884] 0002 pq: 0 ansi : 5 0002 pq: 0 ansi : 5 sd 7 : 0 : 0 : 4 : attached s c s i g e n e r i c sg2 type 0 sd 8 : 0 : 0 : 4 : attached s c s i g e n e r i c sg3 type 0 s c s i 7 : 0 : 0 : 4 : direct−access s c s i 8 : 0 : 0 : 4 : direct−access s c s i 7 : 0 : 0 : 3 : direct−access s c s i 8 : 0 : 0 : 3 : direct−access s c s i 8 : 0 : 0 : 2 : direct−access s c s i 7 : 0 : 0 : 2 : direct−access lio−org tcmu device > lio−org tcmu device > lio−org tcmu device > lio−org tcmu device > [ sdd ] 2097152 512−byte l o g i c a l blocks : > lio−org tcmu device > lio−org tcmu device > [ sdc ] 2097152 512−byte l o g i c a l blocks : > sd 8 : 0 : 0 : 3 : attached s c s i g e n e r i c sg4 type 0 sd 7 : 0 : 0 : 3 : attached s c s i g e n e r i c sg5 type 0 sd 8 : 0 : 0 : 4 : [ sdd ] write protect [ sdd ] mode sense : 2 f 00 00 00 [ sdd ] write cache : enabled , sd 8 : 0 : 0 : 4 : sd 8 : 0 : 0 : 4 : read cache : > sd 8 : 0 : 0 : 4 : sd 7 : 0 : 0 : 4 : i s o f f support dpo or fua sd 7 : 0 : 0 : 4 : sd 7 : 0 : 0 : 4 : sd 8 : 0 : 0 : 2 : attached s c s i g e n e r i c sg6 type 0 sd 7 : 0 : 0 : 4 : [ sdc ] write protect [ sdc ] mode sense : 2 f 00 00 00 [ sdc ] write cache : enabled , i s o f f support dpo or fua read cache : > sd 8 : 0 : 0 : 4 : sd 7 : 0 : 0 : 2 : attached s c s i g e n e r i c sg7 type 0 sd 8 : 0 : 0 : 3 : [ sdd ] optimal t r a n s f e r s c s i 8 : 0 : 0 : 1 : direct−access s c s i 7 : 0 : 0 : 1 : direct−access sd 7 : 0 : 0 : 4 : sd 8 : 0 : 0 : 3 : sd 8 : 0 : 0 : 3 : sd 8 : 0 : 0 : 3 : support dpo or fua i s o f f t r a n s f e r s i z e 65536 bytes s i z e 65536 bytes [ sdc ] optimal [ sde ] write protect [ sde ] mode sense : 2 f 00 00 00 [ sde ] 2097152 512−byte l o g i c a l blocks : > lio−org tcmu device > lio−org tcmu device > [ sdf ] 2097152 512−byte l o g i c a l blocks : > [ sdg ] 2097152 512−byte l o g i c a l blocks : > [ sdf ] write protect [ sdf ] mode sense : 2 f 00 00 00 [ sde ] optimal [ sde ] write cache : enabled , [ sdg ] write protect [ sdg ] mode sense : 2 f 00 00 00 [ sdf ] write cache : enabled , s i z e 65536 bytes read cache : > read cache : > i s o f f sd 8 : 0 : 0 : 1 : attached s c s i g e n e r i c sg8 type 0 sd 7 : 0 : 0 : 3 : sd 7 : 0 : 0 : 3 : sd 8 : 0 : 0 : 3 : sd 8 : 0 : 0 : 2 : t r a n s f e r i s o f f sd 8 : 0 : 0 : 2 : sd 8 : 0 : 0 : 2 : sd 7 : 0 : 0 : 3 : sd 7 : 0 : 0 : 3 : 166.843971] 166.843972] 166.844127] 166.844232] (1.07 gb/1.00 gib) 166.844421] enabled , doesn ’ t 166.844566] 166.844568] 166.844846] 166.845147] enabled , doesn ’ t 166.845188] 166.845527] 166.845678] (1.07 gb/1.00 gib) 166.845785] 166.845799] 166.845931] 166.845933] 166.846424] 166.846552] enabled , doesn ’ t 166.846708] (1.07 gb/1.00 gib) 166.847024] 166.847029] 166.847031] 166.847043] 166.847133] (1.07 gb/1.00 gib) 166.849212] 166.849214] 166.849711] [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ 0002 pq: 0 ansi : 5 0002 pq: 0 ansi : 5 169

170

support dpo or fua sd 7 : 0 : 0 : 1 : attached s c s i g e n e r i c sg9 type 0 sd 7 : 0 : 0 : 2 : [ sdh ] 2097152 512−byte l o g i c a l blocks : > [ sdg ] write cache : enabled , sd 8 : 0 : 0 : 2 : read cache : > support dpo or fua s i z e 65536 bytes sd 8 : 0 : 0 : 2 : sd 7 : 0 : 0 : 2 : sd 7 : 0 : 0 : 2 : sd 7 : 0 : 0 : 3 : sd 7 : 0 : 0 : 2 : t r a n s f e r [ sdg ] optimal [ sdh ] write protect [ sdh ] mode sense : 2 f 00 00 00 [ sdf ] optimal [ sdh ] write cache : enabled , t r a n s f e r i s o f f support dpo or fua s i z e 65536 bytes read cache : > i s o f f [ s d i ] write protect [ s d i ] mode sense : 2 f 00 00 00 [ sdh ] optimal [ s d i ] write cache : enabled , [ s d i ] 2097152 512−byte l o g i c a l blocks : > [ sdj ] 2097152 512−byte l o g i c a l blocks : > s i z e 65536 bytes [ sdj ] write protect [ sdj ] mode sense : 2 f 00 00 00 [ s d i ] optimal [ sdj ] write cache : enabled , s i z e 65536 bytes t r a n s f e r t r a n s f e r i s o f f read cache : > read cache : > support dpo or fua enabled , doesn ’ t 166.849718] 166.849721] (1.07 gb/1.00 gib) 166.853296] enabled , doesn ’ t 166.853721] 166.853810] 166.853812] 166.854026] 166.854431] enabled , doesn ’ t 166.854625] (1.07 gb/1.00 gib) 166.854898] 166.854900] 166.855022] 166.855465] enabled , doesn ’ t 166.855578] (1.07 gb/1.00 gib) 166.855845] 166.855847] 166.855978] 166.856305] enabled , doesn ’ t 166.856701] 166.859624] 166.861304] 166.864409] 166.864833] 166.867906] 166.868446] 166.871588] 166.871773] sd 8 : 0 : 0 : 1 : sd 8 : 0 : 0 : 1 : sd 8 : 0 : 0 : 1 : sd 7 : 0 : 0 : 2 : sd 8 : 0 : 0 : 1 : sd 7 : 0 : 0 : 1 : sd 7 : 0 : 0 : 1 : sd 7 : 0 : 0 : 1 : sd 8 : 0 : 0 : 1 : sd 7 : 0 : 0 : 1 : sd 7 : 0 : 0 : 1 : sd 8 : 0 : 0 : 4 : sd 7 : 0 : 0 : 4 : sd 8 : 0 : 0 : 3 : sd 7 : 0 : 0 : 3 : sd 8 : 0 : 0 : 2 : sd 8 : 0 : 0 : 1 : sd 7 : 0 : 0 : 1 : sd 7 : 0 : 0 : 2 : [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ support dpo or fua s i z e 65536 bytes t r a n s f e r [ sdj ] optimal [ sdd ] attached scsi disk [ sdc ] attached scsi disk [ sde ] attached scsi disk [ sdf ] attached scsi disk [ sdg ] attached scsi disk [ s d i ] attached scsi disk [ sdj ] attached scsi disk [ sdh ] attached scsi disk in the output above you will find 8 x scsi disks recognized. the storage server is mapping 4 x luns to this node, and the node has 2 x paths to each lun. the os recognizes each path to each device as 1 scsi device. you will find different output depending on the storage server your node is mapping the luns from, and the amount of luns being mapped as well. although not the objective of this session, let’s find the 4 mapped luns using multipath-tools. you will find further details about multipath in “device mapper multipathing” session of this same guide. i n s t a l l multipath−t o o l s $ apt−get $ sudo multipath−r $ sudo multipath− l l mpathd (360014051 a042fb7c41c4249af9f2cfbc ) dm−3 lio−org,tcmu device |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=a c t i v e s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler = ’0 ’ wp=rw 170

171

| | | | a c t i v e ready running a c t i v e ready running a c t i v e ready running a c t i v e ready running s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler = ’0 ’ wp=rw s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler = ’0 ’ wp=rw ‘− 7 : 0 : 0 : 4 sde 8:64 ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=enabled ‘− 8 : 0 : 0 : 4 sdc 8:32 mpathc (360014050 d6871110232471d8bcd155a3 ) dm−2 lio−org,tcmu device |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=a c t i v e ‘− 7 : 0 : 0 : 3 sdf 8:80 ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=enabled ‘− 8 : 0 : 0 : 3 sdd 8:48 mpathb (360014051 f65c6cb11b74541b703ce1d4 ) dm−1 lio−org,tcmu device |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=a c t i v e ‘− 7 : 0 : 0 : 2 sdh 8:112 a c t i v e ready running ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=enabled ‘− 8 : 0 : 0 : 2 sdg 8:96 mpatha (36001405 b816e24fcab64fb88332a3fc9 ) dm−0 lio−org,tcmu device |−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=a c t i v e ‘− 7 : 0 : 0 : 1 sdj 8:144 a c t i v e ready running ‘−+− p o l i c y =’ se r v i ce−time 0 ’ prio=1 status=enabled ‘− 8 : 0 : 0 : 1 s d i 8:128 a c t i v e ready running s i z e =1.0g f e a t u r e s = ’0 ’ hwhandler = ’0 ’ wp=rw a c t i v e ready running now it is much easier to understand each recognized scsi device and common paths to same luns in the storage server. with the output above one can easily see that: • mpatha device (/dev/mapper/mpatha) is a multipath device for: • mpathb device (/dev/mapper/mpathb) is a multipath device for: • mpathc device (/dev/mapper/mpathc) is a multipath device for: – /dev/sdj – /dev/dsi – /dev/sdh – /dev/dsg – /dev/sdf – /dev/sdd – /dev/sde – /dev/sdc • mpathd device (/dev/mapper/mpathd) is a multipath device for: do not use this in production without checking appropriate multipath configuration options in the device mapper multipathing session. the default multipath configuration is less than optimal for regular usage. finally, to access the lun (or remote iscsi disk) you will: • if accessing through a single network interface: – access it through /dev/sdx where x is a letter given by the os • if accessing through multiple network interfaces: – configure multipath and access the device through /dev/mapper/x for everything else, the created devices are block devices and all commands used with local disks should work the same way: • creating a partition: $ sudo f d i s k /dev/mapper/mpatha welcome to f d i s k ( u t i l−linux 2.34) . changes w i l l remain in memory only , u n t i l you decide to write them . 171

172

be c a r e f u l before using the write command . device does not contain a recognized p a r t i t i o n table . created a new dos d i s k l a b e l with disk i d e n t i f i e r 0 x92c0322a . command (m f o r help ) : p disk /dev/mapper/mpatha : 1 gib , 1073741824 bytes , 2097152 s e c t o r s units : sector i /o s i z e (minimum/ optimal ) : 512 bytes / 65536 bytes disklabel disk i d e n t i f i e r : 0 x92c0322a s e c t o r s of 1 * 512 = 512 bytes s i z e ( l o g i c a l / physical ) : 512 bytes / 512 bytes type : dos command (m f o r help ) : n p a r t i t i o n type p e s e l e c t f i r s t last s e c t o r primary (0 primary , 0 extended , 4 f r e e ) extended ( container ( d e f a u l t p) : p l o g i c a l p a r t i t i o n s ) f o r created a new p a r t i t i o n 1 of command (m f o r help ) : w the p a r t i t i o n table has been a l t e r e d . (2048−2097151 , d e f a u l t 2048) : p a r t i t i o n number (1−4, d e f a u l t 1) : sector , +/−s e c t o r s or +/−s i z e {k,m,g,t,p} (2048−2097151 , d e f a u l t 2097151) : $ sudo mkfs . ext4 /dev/mapper/mpatha−part1 mke2fs 1 . 4 5 . 5 (07−jan−2020) filesystem uuid: cdb70b1e−c47c−47fd−9c4a−03db6f038988 creating f i l e s y s t e m with 261888 4k blocks and 65536 inodes stored on blocks : 32768 , 98304 , 163840 , 229376 • creating a filesystem: superblock backups type ’ linux ’ and of s i z e 1023 mib. allocating group t a b l e s : done writing inode t a b l e s : done creating journal writing superblocks and f i l e s y s t e m accounting information : done (4096 blocks ) : done • mounting the block device: $ sudo mount /dev/mapper/mpatha−part1 /mnt • accessing the data: $ l s /mnt l o s t+found make sure to read other important sessions in ubuntu server guide to follow up with concepts explored in this one. references 1. iscsid 172

173

2. iscsi.conf 3. iscsid.conf 4. iscsi.service 5. iscsid.service 6. open-iscsi 7. debian open-iscsi kerberos kerberos is a network authentication system based on the principal of a trusted third party. the other two parties being the user and the service the user wishes to authenticate to. not all services and applications can use kerberos, but for those that can, it brings the network environment one step closer to being single sign on (sso). this section covers installation and configuration of a kerberos server, and some example client configura- tions. overview if you are new to kerberos there are a few terms that are good to understand before setting up a kerberos server. most of the terms will relate to things you may be familiar with in other environments: • principal: any users, computers, and services provided by servers need to be defined as kerberos principals. • instances: are used for service principals and special administrative principals. • realms: the unique realm of control provided by the kerberos installation. think of it as the domain or group your hosts and users belong to. convention dictates the realm should be in uppercase. by default, ubuntu will use the dns domain converted to uppercase (example.com) as the realm. • key distribution center: (kdc) consist of three parts: a database of all principals, the authentication server, and the ticket granting server. for each realm there must be at least one kdc. • ticket granting ticket: issued by the authentication server (as), the ticket granting ticket (tgt) is encrypted in the user’s password which is known only to the user and the kdc. • ticket granting server: (tgs) issues service tickets to clients upon request. • tickets: confirm the identity of the two principals. one principal being a user and the other a service requested by the user. tickets establish an encryption key used for secure communication during the authenticated session. • keytab files: are files extracted from the kdc principal database and contain the encryption key for a service or host. to put the pieces together, a realm has at least one kdc, preferably more for redundancy, which contains a database of principals. when a user principal logs into a workstation that is configured for kerberos authentication, the kdc issues a ticket granting ticket (tgt). if the user supplied credentials match, the user is authenticated and can then request tickets for kerberized services from the ticket granting server (tgs). the service tickets allow the user to authenticate to the service without entering another username and password. 173

174

kerberos server installation for this discussion, we will create a mit kerberos domain with the following features (edit them to fit your needs): • realm: example.com • primary kdc: kdc01.example.com (192.168.0.1) • secondary kdc: kdc02.example.com (192.168.0.2) • user principal: ubuntu • admin principal: ubuntu/admin note it is strongly recommended that your network-authenticated users have their uid in a different range (say, starting at 5000) than that of your local users. before installing the kerberos server a properly configured dns server is needed for your domain. since the kerberos realm by convention matches the domain name, this section uses the example.com domain configured in the section primary server of the dns documentation. also, kerberos is a time sensitive protocol. so if the local system time between a client machine and the server differs by more than five minutes (by default), the workstation will not be able to authenticate. to correct the problem all hosts should have their time synchronized using the same network time protocol (ntp) server. check out the ntp chapter for more details. the first step in creating a kerberos realm is to install the krb5-kdc and krb5-admin-server packages. from a terminal enter: sudo apt i n s t a l l krb5−kdc krb5−admin−s e r v e r you will be asked at the end of the install to supply the hostname for the kerberos and admin servers, which may or may not be the same server, for the realm. since we are going to create the realm, and thus these servers, type in the full hostname of this server. note by default the realm is created from the kdc’s domain name. next, create the new realm with the kdb5_newrealm utility: sudo krb5_newrealm it will ask you for a database master password, which is used to encrypt the local database. chose a secure password: its strength is not verified for you. configuration the questions asked during installation are used to configure the /etc/krb5.conf and /etc/krb5kdc/kdc.conf files. the former is used by the kerberos 5 libraries, and the latter configures the kdc. if you need to adjust the key distribution center (kdc) settings simply edit the file and restart the krb5-kdc daemon. if you need to reconfigure kerberos from scratch, perhaps to change the realm name, you can do so by typing sudo dpkg−r e c o n f i g u r e krb5−kdc 174

175

note the manpage for krb5.conf is in the krb5−doc package. once the kdc is properly running, an admin user – the admin principal – is needed. it is recommended to use a different username from your everyday username. using the kadmin.local utility in a terminal prompt enter: $ sudo kadmin . l o c a l authenticating as p r i n c i p a l kadmin . l o c a l : addprinc ubuntu/admin warning: no p o l i c y s p e c i f i e d f o r ubuntu/admin@example.com; d e f a u l t i n g to no root /admin@example.com with password . p o l i c y enter password f o r p r i n c i p a l ”ubuntu/admin@example.com” : re−enter password f o r p r i n c i p a l ”ubuntu/admin@example.com” : p r i n c i p a l ”ubuntu/admin@example.com” created . kadmin . l o c a l : quit in the above example ubuntu is the principal, /admin is an instance of tha principal, and @example.com signifies the realm. the “every day” principal, a.k.a. the user principal, would be ubuntu@example.com, and should have only normal user rights. note replace example.com and ubuntu with your realm and admin username. next, the new admin user needs to have the appropriate access control list (acl) permissions. the permissions are configured in the /etc/krb5kdc/kadm5.acl file: ubuntu/admin@example.com * this entry grants ubuntu/admin the ability to perform any operation on all principals in the realm. you can configure principals with more restrictive privileges, which is convenient if you need an admin principal that junior staff can use in kerberos clients. please see the kadm5.acl man page for details. note the extract privilege is not included in the wildcard privilege; it must be explicitly assigned. his privilege allows the user to extract keys from the database, and must be handled with great care to avoid disclosure of important keys like those of the kadmin/* or krbtgt/* principals. see the kadm5.acl man page for details. now restart the krb5-admin-server for the new acl to take affect: sudo systemctl r e s t a r t krb5−admin−s e r v e r . s e r v i c e the new user principal can be tested using the kinit utility: $ k i n i t ubuntu/admin password f o r ubuntu/admin@example.com: after entering the password, use the klist utility to view information about the ticket granting ticket (tgt): $ k l i s t ticket cache : file :/ tmp/krb5cc_1000 default p r i n c i p a l : ubuntu/admin@example.com valid s t a r t i n g 04/03/20 19:16:57 expires 04/04/20 05:16:57 renew u n t i l 04/04/20 19:16:55 service p r i n c i p a l krbtgt /example.com@example.com 175

176

where the cache filename krb5cc_1000 is composed of the prefix krb5cc_ and the user id (uid), which in this case is 1000. kinit will inspect /etc/krb5.conf to find out which kdc to contact, and its address. the kdc can also be found via dns lookups for special txt and srv records. you can add these records to your example.com dns zone: _kerberos . _udp .example.com. _kerberos . _tcp .example.com. _kerberos . _udp .example.com. _kerberos . _tcp .example.com. 0 88 in srv 1 in srv 1 0 88 in srv 10 0 88 in srv 10 0 88 in srv 1 in srv 1 kdc01 . example . com . kdc01 . example . com . kdc02 . example . com . kdc02 . example . com . 0 749 kdc01 . example . com . 0 464 kdc01 . example . com . _kerberos−adm. _tcp .example.com. _kpasswd . _udp .example.com. note replace example.com, kdc01, and kdc02 with your domain name, primary kdc, and sec- ondary kdc. see the dns chapter for detailed instructions on setting up dns. a very quick and useful way to troubleshoot what kinit is doing is to set the environment variable krb5_trace to a file, or stderr, and it will show extra information. the output is quite verbose, and won’t be shown fully here: $ krb5_trace=/dev/ s t d e r r k i n i t ubuntu/admin [ 2 8 9 8 ] 1585941845.278578: getting i n i t i a l f o r ubuntu/admin@example c r e d e n t i a l s .com [ 2 8 9 8 ] 1585941845.278580: sending unauthenticated request [ 2 8 9 8 ] 1585941845.278581: sending request [ 2 8 9 8 ] 1585941845.278582: resolving hostname kdc01 . example . com ( . . . ) (189 bytes ) to example.com your new kerberos realm is now ready to authenticate clients. secondary kdc once you have one key distribution center (kdc) on your network, it is good practice to have a secondary kdc in case the primary becomes unavailable. also, if you have kerberos clients that are in different networks (possibly separated by routers using nat), it is wise to place a secondary kdc in each of those networks. note the native replication mechanism explained here relies on a cronjob, and essentially dumps the db on the primary and loads it back up on the secondary. you may want to take a look at using the kldap backend which can use the openldap replication mechanism. it is explained further below. first, install the packages, and when asked for the kerberos and admin server names enter the name of the primary kdc: sudo apt i n s t a l l krb5−kdc krb5−admin−s e r v e r once you have the packages installed, create the host principals for both kdcs. from a terminal prompt, enter: kadmin−q ” addprinc−randkey host /kdc01 . example . com” kadmin−q ” addprinc−randkey host /kdc02 . example . com” 176

177

acl file. something like this: ubuntu/admin@example.com *e note the kadmin command defaults to using a principal like username/admin@example.com, where username is your current shell user. if you need to override that, use−p <principal−you −want> make sure the principal you are using has the extra extract−keys privilege in kdc01’s /etc/krb5kdc/kadm5. where “*” means all privileges (except extract−keys), and e means exactly extract−keys. kadmin−q ” ktadd−norandkey−k keytab . kdc02 host /kdc02 . example . com” there should now be a keytab.kdc02 in the current directory, move the file to /etc/krb5.keytab: sudo mv keytab . kdc02 / etc /krb5 . keytab sudo chown root : root / etc /krb5 . keytab extract the keytab file: note if the path to the keytab.kdc02 file is different adjust accordingly. also, you can list the principals in a keytab file, which can be useful when troubleshooting, using the klist utility: sudo k l i s t −k / etc /krb5 . keytab the -k option indicates the file is a keytab file. next, there needs to be a kpropd.acl file on each kdc that lists all kdcs for the realm. for example, on both primary and secondary kdc, create /etc/krb5kdc/kpropd.acl: host /kdc01 . example .com@example.com host /kdc02 . example .com@example.com create an empty database on the secondary kdc: sudo kdb5_util−s create i n s t a l l krb5−kpropd now install kpropd daemon, which listens for connections from the kprop utility from the primary kdc: sudo apt the service will be running right after installation. from a terminal on the primary kdc, create a dump file of the principal database: sudo kdb5_util dump / var / l i b /krb5kdc/dump still on the primary kdc, extract its keytab file and copy it to /etc/krb5.keytab: sudo mv keytab . kdc01 / etc /krb5 . keytab sudo chown root : root / etc /krb5 . keytab kadmin−q ” ktadd−k keytab . kdc01 host /kdc01 . example . com” you can now remove the extract−keys privilege from this principal in kdc01’s /etc/krb5kdc/ kadm5.acl file note 177

178

on the primary kdc, run the kprop utility to push the database dump made before to the secondary kdc: $ sudo kprop−r example.com−f / var / l i b /krb5kdc/dump kdc02 . example . com database propagation to kdc02 . example . com : succeeded note the succeeded message, which signals that the propagation worked. if there is an error message check /var/log/syslog on the secondary kdc for more information. you may also want to create a cron job to periodically update the database on the secondary kdc. for example, the following will push the database every hour: # m h 0 * * * * root / usr / sbin / kdb5_util dump / var / l i b /krb5kdc/dump && / usr / sbin / back on the secondary kdc, create a stash file to hold the kerberos master key: sudo kdb5_util kprop−r example.com−f / var / l i b /krb5kdc/dump kdc02 . example . com finally, start the krb5−kdc daemon on the secondary kdc: sudo systemctl dom mon dow command stash s t a r t krb5−kdc . s e r v i c e note the secondary kdc does not run an admin server, since it’s a read-only copy from now on, you can specify both kdc servers in /etc/krb5.conf for the example.com realm, in any host participating in this realm (including kdc01 and kdc02), but remember that there can only be one admin server and that’s the one running on kdc01: [ realms ] example.com = { kdc = kdc01 . example . com kdc = kdc02 . example . com admin_server = kdc01 . example . com } the secondary kdc should now be able to issue tickets for the realm. you can test this by stopping the krb5−kdc daemon on the primary kdc, then by using kinit to request a ticket. if all goes well you should receive a ticket from the secondary kdc. otherwise, check /var/log/syslog and /var/log/auth.log in the secondary kdc. kerberos linux client this section covers configuring a linux system as a kerberos client. this will allow access to any kerberized services once a user has successfully logged into the system. note that kerberos alone is not enough for a user to exist in a linux system. meaning, we cannot just point the system at a kerberos server and expect all the kerberos principals to be able to login on the linux system, simply because these users do not exist locally. kerberos only provides authentication: it doesn’t know about user groups, linux uids and gids, home directories, etc. normally another network source is used for this information, such as an ldap or windows server, and, in the old days, nis was used for that as well. 178

179

if you have local users matching the principals in a kerberos realm, and just want to switch the authentication from local to remote using kerberos, you can follow this section. this is not a very usual scenario, but serves to highlight the separation between user authentication and user information (full name, uid, gid, home if you just want to be able to grab tickets and use them, it’s enough to install directory, groups, etc). installation krb5−user and run kinit. we are going to use sssd with a trick so that it will fetch the user information from the local system files, instead of a remote source which is the common case. to install the packages enter the following in a terminal prompt: sudo apt i n s t a l l krb5−user sssd−krb5 you will be prompted for the addresses of your kdcs and admin servers. if you have been following this chapter so far, the kdcs will be: kdc01.example.com kdc02.example.com (space separated) and the admin server will be: kdc01.example.com. remember that kdc02 is a read-only copy of the primary kdc, so it doesn’t run an admin server. note if you have added the appropriate srv records to dns, none of those prompts will need answer- ing. configuration if you missed the questions earlier, you can reconfigure the package to fill them in again: sudo dpkg− reconfigure krb5−config. you can test the kerberos configuration by requesting a ticket using the kinit utility. for example: $ k i n i t ubuntu/admin@example.com password f o r ubuntu/admin@example.com: note kinit doesn’t need for the principal to exist as a local user in the system. in fact, you can kinit any principal you want. if you don’t specify one, then the tool will use the username of whoever is running kinit. since we are at it, let’s also create a non-admin principal for ubuntu: authenticating as p r i n c i p a l ubuntu/admin@example.com with password . password f o r ubuntu/admin@example.com: warning: no p o l i c y s p e c i f i e d f o r ubuntu@example.com; d e f a u l t i n g to no p o l i c y enter password f o r p r i n c i p a l ”ubuntu@example.com” : $ kadmin−q ” addprinc ubuntu” re−enter password f o r p r i n c i p a l ”ubuntu@example.com” : p r i n c i p a l ”ubuntu@example.com” created . the only remaining configuration now is for sssd. create the file /etc/sssd/sssd.conf with the following content: [ sssd ] c o n f i g _ f i l e _ v e r s i o n = 2 s e r v i c e s = pam domains = example . com 179

180

[pam] [ domain/example . com ] id_provider = proxy proxy_lib_name = f i l e s auth_provider = krb5 krb5_server = kdc01 . example . com , kdc01 . example . com krb5_kpasswd = kdc01 . example . com krb5_realm = example.com the above configuration will use kerberos for authentication (auth_provider), but will use the local system users for user and group information (id_provider). adjust the permissions of the config file and start sssd: $ sudo chown root : root / etc / sssd / sssd . conf $ sudo chmod 0600 / etc / sssd / sssd . conf $ sudo systemctl s t a r t sssd just by having installed sssd and its dependencies, pam will already have been configured to use sssd, with a fallback to local user authentication. to try it out, if this is a workstation, simply switch users (in the gui), or open a login terminal (ctrl-alt-<number>), or spawn a login shell with sudo login, and try logging in using the name of a kerberos principal. remember that this user must already exist on the local system: $ sudo l o g i n (gnu/linux 5.4.0−21− g e n e r i c password : welcome to ubuntu focal fossa ( development branch ) l o g i n : ubuntu focal−krb5−c l i e n t x86_64 ) ( . . . ) l o g i n : thu apr last $ k l i s t ticket cache : file :/ tmp/krb5cc_1000_nlfnsx default p r i n c i p a l : ubuntu@example.com 9 21:23:50 utc 2020 from 1 0 . 2 0 . 2 0 . 1 on pts /0 valid s t a r t i n g 04/09/20 21:36:12 expires 04/10/20 07:36:12 renew u n t i l 04/10/20 21:36:12 service p r i n c i p a l krbtgt /example.com@example.com and you will have a kerberos ticket already right after login. resources • for more information on mit’s version of kerberos, see the mit kerberos site. • the ubuntu wiki kerberos page has more details. • o’reilly’s kerberos: the definitive guide is a great reference when setting up kerberos. • also, feel free to stop by the #ubuntu-server and #kerberos irc channels on freenode if you have kerberos questions. 180

181

kerberos and ldap kerberos supports a few database backends. the default one is what we have been using so far, called db2. the db types documentation shows all the options, one of which is ldap. there are several reasons why one would want to have the kerberos principals stored in ldap as opposed to a local on-disk database. there are also cases when it is not a good idea. each site has to evaluate the pros and cons. here are a few: - the openldap replication is faster and more robust then the native kerberos one, based on a cron job - setting things up with the ldap backend isn’t exactly trivial and shouldn’t be attempted by administrators without prior knowledge of openldap - as highlighted in ldap section of db types, since krb5kdc is single threaded there may be higher latency in servicing requests when using the openldap backend - if you already have openldap setup for other things, like storing users and groups, adding the kerberos attributes to the same mix might be beneficial and can provide a nice integrated story this section covers configuring a primary and secondary kerberos server to use openldap for the principal database. note that as of version 1.18, the kdc from mit kerberos does not support a primary kdc using a read-only consumer (secondary) ldap server. what we have to consider here is that a primary kdc is read-write, and it needs a read-write backend. the secondaries can use both a read-write and read-only backend, because they are expected to be read-only. therefore there are only some possible layouts we can use: 1. simple case: primary kdc connected to primary openldap, secondary kdc connected to both primary and secondary openldap 2. extended simple case: multiple primary kdcs connected to one primary openldap, and multiple secondary kdcs connected to primary and secondary openldap 3. openldap with multi-master replication: multiple primary kdcs connected to all primary openl- dap servers we haven’t covered openldap multi-master replication in this guide, so we will show the first case only. the second scenario is an extension: just add another primary kdc to the mix, talking to the same primary openldap server. configuring openldap we are going to install the openldap server on the same host as the kdc, to simplify the communication between them. in such a setup, we can use the ldapi:/// transport, which is via an unix socket, and don’t need to setup ssl certificates to secure the communication between the kerberos services and openldap. note, however, that ssl is still needed for the openldap replication. see ldap with tls for details. if you want to use an existing openldap server that you have somewhere else, that’s of course also possible, but keep in mind that you should then use ssl for the communication between the kdc and this openldap server. first, the necessary schema needs to be loaded on an openldap server that has network connectivity to the primary and secondary kdcs. the rest of this section assumes that you also have ldap replication configured between at least two servers. for information on setting up openldap see openldap server. note cn=admin,dc=example,dc=com is a default admin user that is created during the installation of the slapd package (the openldap server). the domain component will change for your server, so adjust accordingly. • install the necessary packages (it’s assumed that openldap is already installed): i n s t a l l krb5−kdc−ldap krb5−admin−s e r v e r • next, extract the kerberos.schema.gz file: sudo apt 181

182

sudo cp / usr / share /doc/krb5−kdc−ldap / kerberos . schema . gz / etc / ldap /schema/ sudo gunzip / etc / ldap /schema/ kerberos . schema . gz • the kerberos schema needs to be added to the cn=config tree. this schema file needs to be converted to ldif format before it can be added. for that we will use a helper tool, called schema2ldif, provided by the package of the same name which is available in the universe archive: sudo apt schema2ldif i n s t a l l • to import the kerberos schema, run: sasl/external authentication s t a r t e d sasl username : gidnumber=0+uidnumber=0,cn=peercred , cn=external , cn=auth sasl ssf : 0 $ sudo ldap−schema−manager−i kerberos . schema executing ’ ldapadd−y external−h ldapi :///−f / etc / ldap /schema/ kerberos . sasl/external authentication s t a r t e d sasl username : gidnumber=0+uidnumber=0,cn=peercred , cn=external , cn=auth sasl ssf : 0 adding new entry ”cn=kerberos , cn=schema , cn=c o n f i g ” l d i f ’ • with the new schema loaded, let’s index an attribute often used in searches: $ sudo ldapmodify−q−y external−h ldapi :/// <<eof dn : olcdatabase={1}mdb, cn=c o n f i g add : olcdbindex olcdbindex : krbprincipalname eq , pres , sub eof modifying entry ” olcdatabase={1}mdb, cn=c o n f i g ” • let’s create ldap entries for the kerberos administrative entities that will contact the openldap server to perform operations. there are two: – ldap_kdc_dn: needs to have read rights on the realm container, principal container and if disable_last_success and disable_lockout are not set, however, then realm sub-trees. ldap_kdc_dn needs write access to the kerberos container just like the admin dn below. – ldap_kadmind_dn: needs to have read and write rights on the realm container, principal the kerberos admin s e r v e r 182 container and realm sub-trees simplesecurityobject here is the command to create these entities: objectclass : account objectclass : userpassword : {crypt}x d e s c r i p t i o n : account used f o r $ ldapadd−x−d cn=admin , dc=example , dc=com−w <<eof dn : uid=kdc−se r v i ce , dc=example , dc=com uid : kdc−s e r v i c e dn : uid=kadmin−s er v i c e , dc=example , dc=com uid : kadmin−s e r v i c e objectclass : account objectclass : userpassword : {crypt}x d e s c r i p t i o n : account used f o r simplesecurityobject the kerberos kdc

183

eof enter ldap password : now let’s set a password for them. note that first the tool asks for the password you want for the specified user dn, and then for the password of the cn=admin dn: $ ldappasswd -x -d cn=admin,dc=example,dc=com -w -s uid=kdc-service,dc=example,dc=com new password: <– password you want for uid-kdc-service re-enter new password: enter ldap password: <– password for the dn specified with the -d option adding new entry ” uid=kdc−se r vi c e , dc=example , dc=com” adding new entry ” uid=kadmin−se r v i ce , dc=example , dc=com” repeat for the uid=kadmin−service dn. these passwords will be needed later. $ ldapwhoami−x−d uid=kdc−se rv i c e , dc=example , dc=com−w dn : uid=kdc−s er v i c e , dc=example , dc=com • finally, update the access control lists (acl). these can be tricky, as it highly depends on what you have defined already. by default, the slapd package configures your database with the following acls: olcaccess : {0} to a t t r s=userpassword by s e l f write by anonymous auth by * you can test these with ldapwhoami: enter ldap password : none olcaccess : {1} to a t t r s=shadowlastchange by s e l f write by * read olcaccess : {2} to * by * read by anonymous auth by s e l f write by * none dn : olcdatabase={1}mdb, cn=c o n f i g add : olcaccess olcaccess : {2} to a t t r s=krbprincipalkey we need to insert new rules before the final to * by * read one, to control access to the kerberos related entries and attributes: $ sudo ldapmodify−q−y external−h ldapi :/// <<eof by dn . exact=”uid=kdc−s e rv i c e , dc=example , dc=com” read by dn . exact=”uid=kadmin−se r vi c e , dc=example , dc=com” write −add : olcaccess by dn . exact=”uid=kdc−s e rv i c e , dc=example , dc=com” read by dn . exact=”uid=kadmin−se r vi c e , dc=example , dc=com” write this will make the existing {2} rule become {4}. check with sudo slapcat−b cn=config (the output below was reformatted a bit for clarity): olcaccess : {0} to a t t r s=userpassword olcaccess : {3} to dn . subtree=”cn=krbcontainer , dc=example , dc=com” modifying entry ” olcdatabase={1}mdb, cn=c o n f i g ” by * none eof by s e l f write by anonymous auth by * none 183

184

olcaccess : {1} to a t t r s=shadowlastchange by s e l f write by * read olcaccess : {2} to a t t r s=krbprincipalkey by anonymous auth by s e l f write by * none by dn . exact=”uid=kdc−se r v ic e , dc=example , dc=com” read by dn . exact=”uid=kadmin−s er v i c e , dc=example , dc=com” write by dn . exact=”uid=kdc−se r v ic e , dc=example , dc=com” read by dn . exact=”uid=kadmin−s er v i c e , dc=example , dc=com” write olcaccess : {3} to dn . subtree=”cn=krbcontainer , dc=example , dc=com” olcaccess : {4} to * by * read by * none that’s it, your ldap directory is now ready to serve as a kerberos principal database. primary kdc configuration (ldap) with openldap configured it is time to configure the kdc. in this example we are doing it in the same openldap server to take advantage of local unix socket communication. • reconfigure the krb5−config package if neededd to get a good starting point with /etc/krb5.conf: sudo dpkg−r e c o n f i g u r e krb5−c o n f i g • now edit /etc/krb5.conf adding the database_module option to the example.com realm section: [ realms ] example.com = { kdc = kdc01 . example . com kdc = kdc02 . example . com admin_server = kdc01 . example . com default_domain = example . com database_module = openldap_ldapconf } then also add these new sections: [ dbdefaults ] ldap_kerberos_container_dn = cn=krbcontainer , dc=example , dc=com [ dbmodules ] openldap_ldapconf = { db_library = kldap # i f e i t h e r of these i s f a l s e , then the ldap_kdc_dn needs to # have write access disable_last_success = true disable_lockout = true to have read r i g h t s on # t h i s object needs # the realm container , p r i n c i p a l ldap_kdc_dn = ” uid=kdc−se r vi c e , dc=example , dc=com” container and realm sub− t r e e s 184

185

t r e e s to have read and write r i g h t s on # t h i s object needs # the realm container , p r i n c i p a l container and realm sub− ldap_kadmind_dn = ” uid=kadmin−se r v ic e , dc=example , dc=com” ldap_service_password_file = / etc /krb5kdc/ s e r v i c e . k e y f i l e ldap_servers = ldapi :/// ldap_conns_per_server = 5 } i s • next, use the kdb5_ldap_util utility to create the realm: important that you not forget t h i s password . realm ’example.com’ the database master password . password f o r ”cn=admin , dc=example , dc=com ” : i n i t i a l i z i n g database f o r you w i l l be prompted f o r i t enter kdc database master key : $ sudo kdb5_ldap_util−d cn=admin , dc=example , dc=com create−subtrees dc= example , dc=com−r example.com−s−h ldapi :/// re−enter kdc database master key to v e r i f y : sudo kdb5_ldap_util−d cn=admin , dc=example , dc=com stashsrvpw−f / etc / krb5kdc/ s e r v i c e . k e y f i l e uid=kdc−se r v ic e , dc=example , dc=com sudo kdb5_ldap_util−d cn=admin , dc=example , dc=com stashsrvpw−f / etc / krb5kdc/ s e r v i c e . k e y f i l e uid=kadmin−se r v i ce , dc=example , dc=com note the /etc/krb5kdc/service. keyfile file now contains clear text versions of the passwords used by the kdc to contact the ldap server! and ldap_kadmin_dn:: • create a stash of the password used to bind to the ldap server. run it once for each ldap_kdc_dn • create a /etc/krb5kdc/kadm5.acl file for the admin server, if you haven’t already: */admin@example.com * • start the kerberos kdc and admin server: sudo systemctl s t a r t krb5−kdc . s e r v i c e krb5−admin−s e r v e r . s e r v i c e you can now add kerberos principals to the ldap database, and they will be copied to any other ldap servers configured for replication. to add a principal using the kadmin.local utility enter: $ sudo kadmin . l o c a l authenticating as p r i n c i p a l kadmin . l o c a l : warning: no p o l i c y s p e c i f i e d f o r ubuntu@example.com; d e f a u l t i n g to no p o l i c y enter password f o r p r i n c i p a l ”ubuntu@example.com” : root /admin@example.com with password . addprinc ubuntu p r i n c i p a l ”ubuntu@example.com” created . kadmin . l o c a l : re−enter password f o r p r i n c i p a l ”ubuntu@example.com” : attributes to it? you use the−x parameter: 185 the above will create an ubuntu principal with a dn of krbprincipalname=ubuntu@example.com,cn =example.com,cn=krbcontainer,dc=example,dc=com. let’s say, however, that you already have an user in your directory, and it’s in uid=testuser1,ou=people,dc=example,dc=com, how to add the kerberos

186

$ sudo kadmin . l o c a l authenticating as p r i n c i p a l kadmin . l o c a l : t e s t u s e r 1 root /admin@example.com with password . addprinc−x dn=uid=testuser1 , ou=people , dc=example , dc=com warning: no p o l i c y s p e c i f i e d f o r testuser1@example .com; d e f a u l t i n g to no p o l i c y enter password f o r p r i n c i p a l ”testuser1@example .com” : re−enter password f o r p r i n c i p a l ”testuser1@example .com” : p r i n c i p a l ”testuser1@example .com” created . since the specified dn already exists, kadmin.local will just add the required kerberos attributes to this existing entry. if it didn’t exist, it would be created from scratch, with just the kerberos attributes, like what happened with the ubuntu example above, but in the specified location. both places are visible for kinit, since, when the realm was created with kdb5_ldap_util, the default value for the search scope and base were taken: subtree, and dc=example,dc=com. secondary kdc configuration (ldap) the setup of the secondary kdc (and its openldap replica) is very similar. once you have the openldap replication setup, repeat these steps on the secondary: - install krb5-kdc-ldap, ldap-utils. do not install krb5- admin-server. - load the kerberos schema using schema2ldif - add the index for krbprincipalname - add the acls - configure krb5.conf in the same way, initially. if you want and if you configured ssl properly, you can add ldaps://kdc01.example.com to the ldap_servers list after ldapi:///, so that the secondary kdc can have two ldap backends at its disposal - do not run kdb5_ldap_util. there is no need to create the database since it’s being replicated from the primary - copy over the following files from the primary kdc and place them in the same location on the secondary: - /etc/krb5kdc/stash - /etc/krb5kdc/service. keyfile - start the kdc: sudo systemctl start krb5−kdc.service resources • configuring kerberos with openldap back-end • mit kerberos backend types openldap server the lightweight directory access protocol, or ldap, is a protocol for querying and modifying a x.500-based directory service running over tcp/ip. the current ldap version is ldapv3, as defined in rfc4510, and the implementation used in ubuntu is openldap.” the ldap protocol accesses directories. a common mistake is to call a directory an ldap directory, or ldap database, but it’s really so common, and we all know what we are talking about, that it’s ok. here are some key concepts and terms: • a directory is a tree of data entries that is hierarchical in nature and is called the directory information tree (dit). • an entry consists of a set of attributes. • an attribute has a key (a name/description) and one or more values. • every attribute must be defined in at least one objectclass. 186

187

• attributes and objectclasses are defined in schemas (an objectclass is actually considered as a special kind of attribute). • each entry has a unique identifier: its distinguished name (dn or dn). this, in turn, consists of a relative distinguished name (rdn) followed by the parent entry’s dn. • the entry’s dn is not an attribute. it is not considered part of the entry itself. note the terms object, container, and node have certain connotations but they all essentially mean the same thing as entry, the technically correct term. for example, below we have a single entry consisting of 11 attributes where the following is true: • dn is “cn=john doe,dc=example,dc=com” • rdn is “cn=john doe” • parent dn is “dc=example,dc=com” dn : cn=john doe , dc=example , dc=com cn : john doe givenname : john sn : doe telephonenumber : +1 888 555 6789 telephonenumber : +1 888 555 1232 mail : manager : cn=larry smith , dc=example , dc=com objectclass : objectclass : organizationalperson objectclass : person objectclass : john@example . com inetorgperson top the above entry is in ldif format (ldap data interchange format). any information that you feed into your dit must also be in such a format. it is defined in rfc2849. such a directory accessed via ldap is good for anything that involves a large number of access requests to a mostly-read, attribute-based (name:value) backend, and that can benefit from a hierarchical struc- ture. examples include an address book, company directory, a list of email addresses, and a mail server’s configuration. installation the installation of slapd will create a minimal working configuration with a top level entry, and an adminis- trator’s dn. in particular, it will create a database instance that you can use to store your data. however, the suffix (or base dn) of this instance will be determined from the domain name of the host. if you want something different, you can change it right after the installation when you still don’t have any useful data. note this guide will use a database suffix of dc=example,dc=com. proceed with the install of the server and the main command line utilities: sudo apt i n s t a l l if you want to change your dit suffix, now would be a good time, because changing it discards your existing one. to change the suffix, run the following command: slapd ldap−u t i l s sudo dpkg−r e c o n f i g u r e slapd 187

188

to switch your dit suffix to dc=example,dc=com, for example, so you can follow this guide more closely, answer example.com when asked about the dns domain name. throughout this guide we will issue many commands with the ldap utilities. to save some typing, we can configure the openldap libraries with certain defaults in /etc/ldap/ldap.conf: base dc=example , dc=com uri ldap :// ldap01 . example . com tls_cacert / etc / s s l / c e r t s /ca−c e r t i f i c a t e s . c r t note adjust for your server name and directory suffix post-install inspection the packaging of slapd is designed to be configured within the service itself by dedicating a separate dit for that purpose. this allows one to dynamically configure slapd without the need to restart the service or edit config files. this configuration database consists of a collection of text-based ldif files located under /etc/ldap/slapd.d, but these should never be edited directly. this way of working is known by several names: the slapd-config method, the rtc method (real time configuration), or the cn=config method. you can still use the traditional flat-file method (slapd.conf ) but it’s not going to be covered in this guide. right after installation, you will get two databases, or suffixes: one for your data, based on your host’s domain (dc=example,dc=com), and one for your configuration, with its root at cn=config. to change the data on each we need different credentials and access methods: • dc=example,dc=com: the administrative user for this suffix is cn=admin,dc=example,dc=com and its password is the one selected during the installation of the slapd package • cn=config: the configuration slapd itself is stored under this suffix. changes to it can be made by the special dn gidnumber=0+uidnumber=0,cn=peercred,cn=external,cn=auth. this is how the local sys- tem’s root user (uid=0/gid=0) is seen by the directory when using sasl external authentication through the ldapi:/// transport via the /run/slapd/ldapi unix socket. essentially what this means is that only the local root user can update the cn=config database. more details later. • this is what the slapd-config dit looks like via the ldap protocol (listing only the dns): $ sudo ldapsearch−q−lll−y external−h ldapi :///−b cn=c o n f i g dn dn : cn=c o n f i g dn : cn=module {0} , cn=c o n f i g dn : cn=schema , cn=c o n f i g dn : cn={0}core , cn=schema , cn=c o n f i g dn : cn={1} cosine , cn=schema , cn=c o n f i g dn : cn={2}nis , cn=schema , cn=c o n f i g dn : cn={3} inetorgperson , cn=schema , cn=c o n f i g dn : olcdatabase={−1}frontend , cn=c o n f i g dn : olcdatabase={0} config , cn=c o n f i g 188

189

dn : olcdatabase={1}mdb, cn=c o n f i g explanation of entries: – cn=config: global settings – cn=module{0},cn=config: a dynamically loaded module – cn=schema,cn=config: contains hard-coded system-level schema – cn={0}core,cn=schema,cn=config: the hard-coded core schema – cn={1}cosine,cn=schema,cn=config: the cosine schema – cn={2}nis,cn=schema,cn=config: the nis schema – cn={3}inetorgperson,cn=schema,cn=config: the inetorgperson schema – olcdatabase={-1}frontend,cn=config: frontend database, default settings for other databases – olcdatabase={0}config,cn=config: slapd configuration database (cn=config) – olcdatabase={1}mdb,cn=config: your database instance (dc=example,dc=com) • this is what the dc=example,dc=com dit looks like: $ ldapsearch−x−lll−h ldap :///−b dc=example , dc=com dn dn : dc=example , dc=com dn : cn=admin , dc=example , dc=com explanation of entries: – dc=example,dc=com: base of the dit – cn=admin,dc=example,dc=com: administrator (rootdn) for this dit (set up during package install) notice how we used two different authentication mechanisms: • -x: this is called a simple bind, and is essentially a plain text authentication. since no binddn was provided (via -d), this became an anonymous bind. without -x, the default is to use a sasl bind. • -y external: this is using a sasl bind (no -x was provided), and further specifying the exter- nal type. together with -h ldapi:///, this uses a local unix socket connection in both cases we only got the results that the server acls allowed us to see, based on who we are. a very handy tool to verify the authentication is ldapwhoami: anonymous $ ldapwhoami−x $ ldapwhoami−x−d cn=admin , dc=example , dc=com−w enter ldap password : dn : cn=admin , dc=example , dc=com when you use simple bind (-x) and specify a binddn with -d as your authentication dn, the server will look for a userpassword attribute in that entry, and use that to verify the credentials. in this particular case above, we used the database rootdn entry, i.e., the actual administrator, and that is a special case whose password is set in the configuration when the package is installed. note 189

190

a simple bind without some sort of transport security mechanism is clear text, meaning the credentials are transmitted in the clear. you should add tls support to your openldap server as soon as possible. dn : gidnumber=0+uidnumber=0,cn=peercred , cn=external , cn=auth when using sasl external via the ldapi:/// transport, the binddn becomes a combination of the uid and gid of the connecting user, followed by the suffix cn=peercred,cn=external,cn=auth. the server acls know about this, and grant the local root user complete write access to cn=config via the sasl mechanism. dn : gidnumber=1000+uidnumber=1000,cn=peercred , cn=external , cn=auth here are the sasl external examples: $ ldapwhoami−y external−h ldapi :///−q $ sudo ldapwhoami−y external−h ldapi :///−q modifying/populating your database let’s introduce some content to our database. we will add the following: • a node called people (to store users) • a node called groups (to store groups) • a group called miners • a user called john create the following ldif file and call it add_content.ldif: dn : ou=people , dc=example , dc=com objectclass : organizationalunit ou : people dn : ou=groups , dc=example , dc=com objectclass : organizationalunit ou : groups dn : cn=miners , ou=groups , dc=example , dc=com objectclass : posixgroup cn : miners gidnumber : 5000 john dn : uid=john , ou=people , dc=example , dc=com objectclass : inetorgperson objectclass : posixaccount objectclass : shadowaccount uid : sn : doe givenname : john cn : john doe displayname : john doe uidnumber : 10000 gidnumber : 5000 userpassword : {crypt}x gecos : john doe l o g i n s h e l l : / bin /bash 190

191

homedirectory : /home/ john note it’s important that uid and gid values in your directory do not collide with local values. you can use high number ranges, such as starting at 5000 or even higher. add the content: $ ldapadd−x−d cn=admin , dc=example , dc=com−w−f add_content . l d i f enter ldap password : ******** adding new entry ”ou=people , dc=example , dc=com” adding new entry ”ou=groups , dc=example , dc=com” adding new entry ”cn=miners , ou=groups , dc=example , dc=com” adding new entry ” uid=john , ou=people , dc=example , dc=com” we can check that the information has been correctly added with the ldapsearch utility. for example, let’s search for the john entry, and request the cn and gidnumber attributes: $ ldapsearch−x−lll−b dc=example , dc=com ’( uid=john ) ’ cn gidnumber dn : uid=john , ou=people , dc=example , dc=com cn : john doe gidnumber : 5000 here we used an ldap “filter”: (uid=john). ldap filters are very flexible and can become complex. for example, to list the group names of which john is a member, we could use the filter: (&( objectclass=posixgroup ) (memberuid=john ) ) that is a logical and between two attributes. filters are very important in ldap and mastering their syntax will help a long way. they are used for simple queries like this, but can also select what content is to be replicated to a secondary server, or even in complex acls. the full specification is defined in rfc 4515. notice we set the userpassword field for the john entry to the cryptic value {crypt}x. this essentially is an invalid password, because no hashing will produce just x. it’s a common pattern when adding a user entry without a default password. to change the password to something valid, you can now use ldappasswd: $ ldappasswd−x−d cn=admin , dc=example , dc=com−w−s uid=john , ou=people , dc= re−enter new password : enter ldap password : example , dc=com new password : note remember that simple binds are insecure and you should add tls support to your server! modifying the slapd configuration database the slapd-config dit can also be queried and modified. here are some common operations. adding an index use ldapmodify to add an “index” to your {1}mdb,cn=config database definition (for dc=example,dc=com). create a file, call it uid_index.ldif, with the following contents: 191

192

dn : olcdatabase={1}mdb, cn=c o n f i g add : olcdbindex olcdbindex : mail eq , sub then issue the command: modifying entry ” olcdatabase={1}mdb, cn=c o n f i g ” $ sudo ldapmodify−q−y external−h ldapi :///−f uid_index . l d i f $ sudo ldapsearch−q−lll−y external−h ldapi :///−b \ ’( olcdatabase={1}mdb) ’ olcdbindex you can confirm the change in this way: cn=c o n f i g dn : olcdatabase={1}mdb, cn=c o n f i g olcdbindex : objectclass eq olcdbindex : cn , uid eq olcdbindex : uidnumber , gidnumber eq olcdbindex : member , memberuid eq olcdbindex : mail eq , sub change the rootdn password: first, run slappasswd to get the hash for the new password you want: $ slappasswd new password : re−enter new password : {ssha}vkrymxlskhongrpc6rnasknmxg2xhxfo now prepare a changerootpw.ldif file with this content: dn : olcdatabase={1}mdb, cn=c o n f i g changetype : modify r e p l a c e : olcrootpw olcrootpw : {ssha}vkrymxlskhongrpc6rnasknmxg2xhxfo we still have the actual cn=admin,dc=example,dc=com dn in the dc=example,dc=com database, so let’s change it too. since this is a regular entry in this database suffix, we can use ldappasswd: finally, run the ldapmodify command: modifying entry ” olcdatabase={1}mdb, cn=c o n f i g ” $ sudo ldapmodify−q−y external−h ldapi :///−f changerootpw . l d i f $ ldappasswd−x−d cn=admin , dc=example , dc=com−w−s re−enter new password : enter ldap password : <−− current password , about to be changed new password : adding a schema schemas can only be added to cn=config if they are in ldif format. if not, they will first have to be converted. you can find unconverted schemas in addition to converted ones in the /etc/ldap/schema directory. 192

193

note it is not trivial to remove a schema from the slapd-config database. practice adding schemas on a test system. in the following example we’ll add the password policy (ppolicy) schema. this schema exists in both converted (.ldif ) and native (.schema) formats, so we don’t have to convert it and can use ldapadd directly: $ sudo ldapadd−q−y external−h ldapi :///−f / etc / ldap /schema/ ppolicy . l d i f adding new entry ”cn=ppolicy , cn=schema , cn=c o n f i g ” if the schema you want to add does not exist in ldif format, a nice conversion tool that can be used is provided in the schema2ldif package. logging activity logging for slapd is very useful when implementing an openldap-based solution yet it must be manually enabled after software installation. otherwise, only rudimentary messages will appear in the logs. logging, like any other such configuration, is enabled via the slapd-config database. openldap comes with multiple logging levels with each one containing the lower one (additive). a good level to try is stats. the slapd-config man page has more to say on the different subsystems. create the file logging. ldif with the following contents: dn : cn=c o n f i g changetype : modify r e p l a c e : olcloglevel olcloglevel : s t a t s implement the change: sudo ldapmodify−q−y external−h ldapi :///−f rsyslogd−2177: this will produce a significant amount of logging and you will want to throttle back to a less verbose level once your system is in production. while in this verbose mode your host’s syslog engine (rsyslog) may have a hard time keeping up and may drop messages: imuxsock l o s t 228 messages from pid 2547 due to rate−l i m i t i n g logging . l d i f you may consider a change to rsyslog’s configuration. in /etc/rsyslog .conf, put: # disable rate # ( d e f a u l t $systemlogratelimitinterval 0 i s 200 messages l i m i t i n g in 5 seconds ; below we make the 5 become 0) and then restart the rsyslog daemon: sudo systemctl r e s t a r t s y s l o g . s e r v i c e backup and restore now we have ldap running just the way we want, it is time to ensure we can save all of our work and restore it as needed. what we need is a way to backup the directory database(s), specifically the configuration backend (cn=config) and the dit (dc=example,dc=com). if we are going to backup those databases into, say, /export/backup, we could use slapcat as shown in the following script, called /usr/local/bin/ldapbackup: 193

194

#!/ bin /bash backup_path=/export /backup slapcat=/usr / sbin / s l a p c a t s e t−e nice ${slapcat}−b cn=c o n f i g > ${backup_path}/ c o n f i g . l d i f nice ${slapcat}−b dc=example , dc=com > ${backup_path}/ example . com . l d i f chown root : root ${backup_path}/* chmod 600 ${backup_path}/*. l d i f note these files are uncompressed text files containing everything in your directory including the tree layout, usernames, and every password. so, you might want to consider making /export/backup an encrypted partition and even having the script encrypt those files as it creates them. ideally you should do both, but that depends on your security requirements. 45 22 * * * root / usr / l o c a l / bin /ldapbackup backup_path=/export /backup slapadd=/usr / sbin / slapadd then, it is just a matter of having a cron script to run this program as often as you feel comfortable with. for many, once a day suffices. for others, more often is required. here is an example of a cron script called /etc/cron.d/ldapbackup that is run every night at 22:45h: now the files are created, they should be copied to a backup server. assuming we did a fresh reinstall of ldap, the restore process could be something like this: #!/ bin /bash mailto=backup−emails@domain . com s e t−e [−n ”$ ( l s−l / var / l i b / ldap /* 2>/dev/ n u l l ) ”−o−n ”$ ( l s−l / etc / ldap / slapd . echo sudo rm−r f / etc / ldap / slapd . d/* / var / l i b / ldap /* sudo slapadd−f / etc / ldap / slapd . d−b cn=c o n f i g−l / export /backup/ c o n f i g . l d i f sudo slapadd−f / etc / ldap / slapd . d−b dc=example , dc=com−l / export /backup/ sudo chown−r openldap : openldap / etc / ldap / slapd . d/ sudo chown−r openldap : openldap / var / l i b / ldap / d/* 2>/dev/ n u l l ) ” ] ; echo run the f o l l o w i n g to remove the e x i s t i n g db : echo sudo systemctl this is a simplistic backup strategy, of course. it’s being shown here as a reference for the basic tooling you can use for backups and restores. sudo systemctl s t a r t slapd . s e r v i c e f i sudo systemctl stop slapd . s e r v i c e | | : then stop slapd . s e r v i c e i f e x i t 1 example . com . l d i f 194

195

references • the openldap administrators guide • ldap string representation of search filters openldap replication the ldap service becomes increasingly important as more networked systems begin to depend on it. in such an environment, it is standard practice to build redundancy (high availability) into ldap to prevent havoc should the ldap server become unresponsive. this is done through ldap replication. replication is achieved via the syncrepl engine. this allows changes to be synchronized using a consumer - provider model. a detailed description this replication mechanism can be found in the openldap admin- istrator’s guide and in its defining rfc 4533. there are two ways to use this replication: • standard replication: changed entries are sent to the consumer in their entirety. for example, if the userpassword attribute of the uid=john,ou=people,dc=example,dc=com entry changed, then the whole entry is sent to the consumer • delta replication: only the actual change is sent, instead of the whole entry the delta replication sends less data over the network, but is more complex to setup. we will show both in this guide. important you must have tls enabled already. please consult the ldap with tls guide provider configuration - replication user both replication strategies will need a replication user and updates to the acls and limits regarding this user. to create the replication user, save the following contents to a file called replicator . ldif : dn : cn=r e p l i c a t o r , dc=example , dc=com objectclass : objectclass : organizationalrole cn : d e s c r i p t i o n : replication user userpassword : {crypt}x simplesecurityobject r e p l i c a t o r then add it with ldapadd: example , dc=com new password : now set a password for it with ldappasswd: enter ldap password : adding new entry ”cn=r e p l i c a t o r , dc=example , dc=com” $ ldapadd−x−zz−d cn=admin , dc=example , dc=com−w−f $ ldappasswd−x−zz−d cn=admin , dc=example , dc=com−w−s cn=r e p l i c a t o r , dc= re−enter new password : enter ldap password : r e p l i c a t o r . l d i f 195

196

for that we need to update the acls on the provider. since ordering matters, first check what the existing acls look like on the dc=example,dc=com tree: =example , dc=com) ’ olcaccess dn : olcdatabase={1}mdb, cn=c o n f i g olcaccess : {0} to a t t r s=userpassword by s e l f write by anonymous auth by * none olcaccess : {1} to a t t r s=shadowlastchange by s e l f write by * read olcaccess : {2} to * by * read ’( o l c s u f f i x=dc what we need is to insert a new rule before the first one, and also adjust the limits for the replicator user. the next step is to give this replication user the correct privileges: • read access to the content that we want replicated • no search limits on this content dn : olcdatabase={1}mdb, cn=c o n f i g changetype : modify add : olcaccess olcaccess : {0} to * $ sudo ldapsearch−q−y external−h ldapi :///−lll−b cn=c o n f i g prepare the replicator−acl−limits.ldif file with this content: −add : olclimits $ sudo ldapmodify−q−y external−h ldapi :///−f by dn . exact=”cn=r e p l i c a t o r , dc=example , dc=com” read by * break olclimits : dn . exact=”cn=r e p l i c a t o r , dc=example , dc=com” time . s o f t=unlimited time . hard=unlimited s i z e . s o f t=unlimited s i z e . hard=unlimited modifying entry ” olcdatabase={1}mdb, cn=c o n f i g ” and add it to the server: r e p l i c a t o r−acl−l i m i t s . l d i f provider configuration - standard replication the remaining configuration for the provider using standard replication is to add the syncprov overlay on top of the dc=example,dc=com database.o create a file called provider_simple_sync.ldif with this content: # add indexes to the frontend db . dn : olcdatabase={1}mdb, cn=c o n f i g changetype : modify add : olcdbindex olcdbindex : entrycsn eq −add : olcdbindex olcdbindex : entryuuid eq #load the syncprov module . dn : cn=module {0} , cn=c o n f i g changetype : modify add : olcmoduleload olcmoduleload : syncprov 196

197

f o r primary db # syncrepl provider dn : olcoverlay=syncprov , olcdatabase={1}mdb, cn=c o n f i g changetype : add objectclass : olcoverlayconfig objectclass : olcsyncprovconfig olcoverlay : olcspcheckpoint : 100 10 olcspsessionlog : 100 syncprov customization warning the ldif above has some parameters that you should review before deploying in production on your directory. in particular: • olcspcheckpoint, olcspsessionlog: please see the slapo-syncprov(5) manpage. in general, olcspsessionlog should be equal to, or preferably larger, than the number of entries in your directory. also see its #8125 for details on an existing bug. add the new content: sudo ldapadd−q−y external−h ldapi :///−f provider_simple_sync . l d i f the provider is now configured. consumer configuration - standard replication install the software by going through installation. make sure schemas and the database suffix are the same, and enable tls. create an ldif file with the following contents and name it consumer_simple_sync.ldif: dn : cn=module {0} , cn=c o n f i g changetype : modify add : olcmoduleload olcmoduleload : syncprov dn : olcdatabase={1}mdb, cn=c o n f i g changetype : modify add : olcdbindex olcdbindex : entryuuid eq −add : olcsyncrepl olcsyncrepl : r i d=0 provider=ldap :// ldap01 . example . com bindmethod=simple binddn=”cn=r e p l i c a t o r , dc=example , dc=com” c r e d e n t i a l s=<secret > searchbase=”dc=example , dc=com” schemachecking=on type=refreshandpersist s t a r t t l s=c r i t i c a l r e t r y =”60 +” t l s _ r e q c e r t=demand −add : olcupdateref olcupdateref : ldap :// ldap01 . example . com ensure the following attributes have the correct values: 197

198

• provider (provider server’s hostname – ldap01.example.com in this example – or ip address). it must match what is presented in the provider’s ssl certificate. • binddn (the bind dn for the replicator user) • credentials (the password you selected for the replicator user) • searchbase (the database suffix you’re using, i.e., content that is to be replicated) • olcupdateref (provider server’s hostname or ip address, given to clients if they try to write to this consumer) • rid (replica id, an unique 3-digit that identifies the replica. each consumer should have at least one rid) note note that a successful encrypted connection via start_tls is being enforced in this configu- ration, to avoid sending the credentials in the clear across the network. see ldap with tls for details on how to setup openldap with trusted ssl certificates. add the new configuration: sudo ldapadd−q−y external−h ldapi :///−f consumer_simple_sync . l d i f you’re done. the dc=example,dc=com tree should now be synchronizing. provider configuration - delta replication the remaining provider configuration for delta replication is: • create a new database called accesslog • add the syncprov overlay on top of the accesslog and dc=example,dc=com databases • add the accesslog overlay on top of the dc=example,dc=com database add syncprov and accesslog overlays and dbs create an ldif file with the following contents and name it provider_sync.ldif: # add indexes to the frontend db . dn : olcdatabase={1}mdb, cn=c o n f i g changetype : modify add : olcdbindex olcdbindex : entrycsn eq −add : olcdbindex olcdbindex : entryuuid eq #load the syncprov and a c c e s s l o g modules . dn : cn=module {0} , cn=c o n f i g changetype : modify add : olcmoduleload olcmoduleload : syncprov −add : olcmoduleload olcmoduleload : a c c e s s l o g # accesslog database d e f i n i t i o n s 198

199

dn : olcdatabase={2}mdb, cn=c o n f i g objectclass : olcdatabaseconfig objectclass : olcmdbconfig olcdatabase : {2}mdb olcdbdirectory : / var / l i b / ldap / a c c e s s l o g o l c s u f f i x : cn=a c c e s s l o g olcrootdn : cn=admin , dc=example , dc=com olcdbindex : d e f a u l t eq olcdbindex : entrycsn , objectclass , reqend , reqresult , reqstart olcaccess : {0} to * by dn . exact=”cn=r e p l i c a t o r , dc=example , dc=com” read by * break olclimits : dn . exact=”cn=r e p l i c a t o r , dc=example , dc=com” time . s o f t=unlimited time . hard=unlimited s i z e . s o f t=unlimited s i z e . hard=unlimited # accesslog db syncprov . dn : olcoverlay=syncprov , olcdatabase={2}mdb, cn=c o n f i g changetype : add objectclass : olcoverlayconfig objectclass : olcsyncprovconfig olcoverlay : syncprov olcspnopresent : true olcspreloadhint : true f o r primary db # syncrepl provider dn : olcoverlay=syncprov , olcdatabase={1}mdb, cn=c o n f i g changetype : add objectclass : olcoverlayconfig objectclass : olcsyncprovconfig olcoverlay : olcspcheckpoint : 100 10 olcspsessionlog : 100 syncprov f o r primary db # a c c e s s l o g overlay d e f i n i t i o n s dn : olcoverlay=accesslog , olcdatabase={1}mdb, cn=c o n f i g objectclass : olcoverlayconfig objectclass : olcaccesslogconfig olcoverlay : a c c e s s l o g olcaccesslogdb : cn=a c c e s s l o g olcaccesslogops : writes olcaccesslogsuccess : true # scan the a c c e s s l o g db every day , and purge e n t r i e s older olcaccesslogpurge : 07+00:00 01+00:00 than 7 days customization warning the ldif above has some parameters that you should review before deploying in production on your directory. in particular: • olcspcheckpoint, olcspsessionlog: please see the slapo-syncprov(5) manpage. in general, olcspsessionlog should be equal to, or preferably larger, than the number of entries in your directory. also see its #8125 for details on an existing bug. • olcaccesslogpurge: check the slapo-accesslog(5) manpage create a directory: 199

200

sudo−u openldap mkdir / var / l i b / ldap / a c c e s s l o g sudo ldapadd−q−y external−h ldapi :///−f provider_sync . l d i f the provider is now configured. add the new content: consumer configuration install the software by going through installation. make sure schemas and the database suffix are the same, and enable tls. create an ldif file with the following contents and name it consumer_sync.ldif: dn : cn=module {0} , cn=c o n f i g changetype : modify add : olcmoduleload olcmoduleload : syncprov dn : olcdatabase={1}mdb, cn=c o n f i g changetype : modify add : olcdbindex olcdbindex : entryuuid eq −add : olcsyncrepl olcsyncrepl : r i d=0 provider=ldap :// ldap01 . example . com bindmethod=simple binddn=”cn=r e p l i c a t o r , dc=example , dc=com” c r e d e n t i a l s=<secret > searchbase=”dc=example , dc=com” logbase=”cn=a c c e s s l o g ” l o g f i l t e r =”(&( objectclass=auditwriteobject ) ( reqresult =0)) ” schemachecking=on type=refreshandpersist syncdata=a c c e s s l o g s t a r t t l s=c r i t i c a l t l s _ r e q c e r t=demand r e t r y =”60 +” −add : olcupdateref olcupdateref : ldap :// ldap01 . example . com ensure the following attributes have the correct values: • provider (provider server’s hostname – ldap01.example.com in this example – or ip address). it must match what is presented in the provider’s ssl certificate. • binddn (the bind dn for the replicator user) • credentials (the password you selected for the replicator user) • searchbase (the database suffix you’re using, i.e., content that is to be replicated) • olcupdateref (provider server’s hostname or ip address, given to clients if they try to write to this consumer) • rid (replica id, an unique 3-digit that identifies the replica. each consumer should have at least one rid) 200

201

note note that a successful encrypted connection via start_tls is being enforced in this configu- ration, to avoid sending the credentials in the clear across the network. see ldap with tls for details on how to setup openldap with trusted ssl certificates. add the new configuration: sudo ldapadd−q−y external−h ldapi :///−f consumer_sync . l d i f you’re done. the dc=example,dc=com tree should now be synchronizing. testing once replication starts, you can monitor it by running $ ldapsearch−z1−lll−x−s base−b dc=example , dc=com contextcsn dn : dc=example , dc=com contextcsn : 20200423222317.722667z#000000#000#000000 on both the provider and the consumer. once the contextcsn value for both match, both trees are in sync. every time a change is done in the provider, this value will change and so should the one in the consumer(s). if your connection is slow and/or your ldap database large, it might take a while for the consumer’s con- textcsn match the provider’s. but, you will know it is progressing since the consumer’s contextcsn will be steadly increasing. if the consumer’s contextcsn is missing or does not match the provider, you should stop and figure out the issue before continuing. try checking the slapd entries in /var/log/syslog in the provider to see if the consumer’s authentication requests were successful or its requests to retrieve data return no errors. in particular, verify that you can connect to the provider from the consumer as the replicator binddn using start_tls: ldapwhoami−x−zz−d cn=r e p l i c a t o r , dc=example , dc=com−w−h ldap01 . example . com $ ldapsearch−x−lll−b dc=example , dc=com−h ldap02 . example . com ’( uid=john ) ’ for our example, you should now see the john user in the replicated tree: dn : uid=john , ou=people , dc=example , dc=com uid : john uid references • replication types, openldap administrator’s guide • ldap sync replication - openldap administrator’s guide • rfc 4533. ldap workstation authentication once you have a working ldap server, you will need to install libraries on the client that will know how and when to contact it. on ubuntu, this has been traditionally accomplished by installing the libnss-ldap package, but nowadays you should use sssd. please refer to service - sssd. 201

202

user and group management - ldapscripts another very common usage case for having an ldap server is to store unix user and group information in the directory. there are many tools out there, but usually big deployments will have developed their own. here we will briefly show how to use the ldapscripts package for an easy and quick way to start storing user and group information in openldap. install the package: sudo apt l d a p s c r i p t s i n s t a l l then edit the file /etc/ldapscripts/ldapscripts .conf to arrive at something similar to the following: server=ldap :// ldap01 . example . com ldapbinopts=”−zz” binddn=’cn=admin , dc=example , dc=com ’ bindpwdfile=”/ etc / l d a p s c r i p t s / l d a p s c r i p t s . passwd” suffix=’dc=example , dc=com ’ gsuffix=’ou=groups ’ usuffix=’ou=people ’ msuffix=’ou=computers ’ note • adjust server and related suffix options to suit your directory structure. • note we are forcing start_tls usage here (-zz parameter), please refer to ldap with tls for details on how to set the server up with tls support store the cn=admin password in the /etc/ldapscripts/ldapscripts .passwd file and make sure it’s only read- able by the root local user: $ sudo chmod 400 / etc / l d a p s c r i p t s / l d a p s c r i p t s . passwd the scripts are now ready to help manage your directory. here are some examples of how to use them: • create a new user: sudo ldapaddgroup george sudo ldapadduser george george this will create a group and user with name george and set the user’s primary group (gid) to george • change a user’s password: $ sudo ldapsetpasswd george changing password f o r user uid=george , ou=people , dc=example , dc=com new password : retype new password : s u c c e s s f u l l y s e t password f o r user uid=george , ou=people , dc=example , dc=com • delete a user: sudo l d a p d e l e t e u s e r george > **note** > > this won ’ t d e l e t e the user ’ s primary group , but w i l l from supplementary ones . remove the user • add a group: 202

203

sudo ldapaddgroup qa • delete a group: sudo ldapdeletegroup qa • add a user to a group: sudo ldapaddusertogroup george qa you should now see a memberuid attribute for the qa group with a value of george. • remove a user from a group: sudo ldapdeleteuserfromgroup george qa the memberuid attribute should now be removed from the qa group. • the ldapmodifyuser script allows you to add, remove, or replace a user’s attributes. the script uses the same syntax as the ldapmodify utility. for example: sudo ldapmodifyuser george # about to modify the f o l l o w i n g entry : dn : uid=george , ou=people , dc=example , dc=com objectclass : account objectclass : posixaccount cn : george uid : george uidnumber : 10001 gidnumber : 10001 homedirectory : /home/ george l o g i n s h e l l : / bin /bash gecos : george d e s c r i p t i o n : user account userpassword : : e1ntsef9exfstfcywlhwwkf1eguybvdfwhzkrzjvmjftsg9vchk= # enter your m o d i f i c a t i o n s here , end with ctrl−d. dn : uid=george , ou=people , dc=example , dc=com r e p l a c e : gecos gecos : george carlin the user’s gecos should now be “george carlin”. • a nice feature of ldapscripts is the template system. templates allow you to customize the attributes of user, group, and machine objects. for example, to enable the user template edit /etc/ldapscripts/ ldapscripts .conf changing: utemplate=”/ etc / l d a p s c r i p t s / ldapadduser . template ” there are sample templates in the /usr/share/doc/ldapscripts/examples directory. copy or rename the ldapadduser.template.sample file to /etc/ldapscripts/ldapadduser.template: sudo cp / usr / share /doc/ l d a p s c r i p t s / examples/ ldapadduser . template . sample \ / etc / l d a p s c r i p t s / ldapadduser . template edit the new template to add the desired attributes. the following will create new users with an objectclass of inetorgperson: 203

204

dn : uid=<user >,<u s uf f i x >,< s u f f i x > objectclass : inetorgperson objectclass : posixaccount cn : <user> sn : <ask> uid : <user> uidnumber : <uid> gidnumber : <gid> homedirectory : <home> l o g i n s h e l l : <s h e l l > gecos : <user> d e s c r i p t i o n : user account t i t l e : employee notice the <ask> option used for the sn attribute. this will make ldapadduser prompt you for its value. there are utilities in the package that were not covered here. this command will output a list: dpkg−l l d a p s c r i p t s resources | grep / usr / sbin • the primary resource is the upstream documentation: www.openldap.org • zytrax’s ldap for rocket scientists; a less pedantic but comprehensive treatment of ldap • a ubuntu community openldap wiki page has a collection of notes • o’reilly’s ldap system administration (textbook; 2003) • packt’s mastering openldap (textbook; 2007) ldap & tls when authenticating to an openldap server it is best to do so using an encrypted session. this can be accomplished using transport layer security (tls). here, we will be our own certificate authority and then create and sign our ldap server certificate as that ca. this guide will use the certtool utility to complete these tasks. for simplicity, this is being done on the openldap server itself, but your real internal ca should be elsewhere. install the gnutls-bin and ssl-cert packages: sudo apt i n s t a l l gnutls−bin s s l−c e r t create a private key for the certificate authority: sudo c e r t t o o l−−generate−privkey−−b i t s 4096−−o u t f i l e / etc / s s l / private / mycakey . pem create the template/file /etc/ssl/ca.info to define the ca: cn = example company ca cert_signing_key expiration_days = 3650 204

205

create the self-signed ca certificate: note yes, the –outfile path is correct, we are writing the ca certificate to /usr/local/share/ca- certificates. this is where update-ca-certificates will pick up trusted local cas from. to pick up sudo c e r t t o o l−−generate−s e l f−signed \ −−load−privkey / etc / s s l / private /mycakey . pem \ −−template / etc / s s l /ca . i n f o \ −−o u t f i l e / usr / l o c a l / share /ca−c e r t i f i c a t e s / mycacert . c r t cas from /usr/share/ca-certificates, a call to dpkg−reconfigure ca−certificates is necessary. run update−ca−certificates to add the new ca certificate to the list of trusted cas. note the one added $ sudo update−ca−c e r t i f i c a t e s this also creates a /etc/ssl/certs/mycacert.pem symlink pointing to the real file in /usr/local/share/ca− sudo c e r t t o o l−−generate−privkey \ −−b i t s 2048 \ −−o u t f i l e / etc / ldap /ldap01_slapd_key . pem in / etc /ca−c e r t i f i c a t e s /update . d . . . note replace ldap01 in the filename with your server’s hostname. naming the certificate and key for the host and service that will be using them will help keep things clear. in / etc / s s l / c e r t s . . . ca: updating c e r t i f i c a t e s 1 added , 0 removed ; done . running hooks done . certificates. make a private key for the server: create the /etc/ssl/ldap01.info info file containing: organization = example company cn = ldap01 . example . com tls_www_server encryption_key signing_key expiration_days = 365 the above certificate is good for 1 year, and it’s valid only for the ldap01.example.com hostname. adjust accordingly. create the server’s certificate: sudo c e r t t o o l−−generate−c e r t i f i c a t e \ −−load−privkey / etc / ldap /ldap01_slapd_key . pem \ −−load−ca−c e r t i f i c a t e / etc / s s l / c e r t s /mycacert . pem \ −−load−ca−privkey / etc / s s l / private /mycakey . pem \ −−template / etc / s s l / ldap01 . i n f o \ −−o u t f i l e / etc / ldap / ldap01_slapd_cert . pem adjust permissions and ownership: sudo chgrp openldap / etc / ldap /ldap01_slapd_key . pem sudo chmod 0640 / etc / ldap /ldap01_slapd_key . pem 205

206

your server is now ready to accept the new tls configuration. create the file certinfo . ldif with the following contents (adjust paths and filenames accordingly): dn : cn=c o n f i g add : olctlscacertificatefile olctlscacertificatefile : / etc / s s l / c e r t s / mycacert . pem o l c t l s c e r t i f i c a t e f i l e : / etc / ldap / ldap01_slapd_cert . pem −add : o l c t l s c e r t i f i c a t e f i l e −add : olctlscertificatekeyfile sudo ldapmodify−y external−h ldapi :///−f olctlscertificatekeyfile : / etc / ldap /ldap01_slapd_key . pem use the ldapmodify command to tell slapd about our tls work via the slapd-config database: c e r t i n f o . l d i f contratry to popular belief, you do not need ldaps:// in /etc/default/slapd in order to use encryption. you should have just: slapd_services=”ldap :/// ldapi :///” note ldap over tls/ssl (ldaps://) is deprecated in favour of starttls. the latter refers to an existing ldap session (listening on tcp port 389) becoming protected by tls/ssl whereas ldaps, like https, is a distinct encrypted-from-the-start protocol that operates over tcp port 636. certificate for an openldap replica to generate a certificate pair for an openldap replica (consumer), create a holding directory (which will be used for the eventual transfer) and: mkdir ldap02−s s l cd ldap02−s s l c e r t t o o l−−generate−privkey \ −−b i t s 2048 \ −−o u t f i l e ldap02_slapd_key . pem create an info file, ldap02.info, for the consumer server, adjusting its values accordingly: organization = example company cn = ldap02 . example . com tls_www_server encryption_key signing_key expiration_days = 365 create the consumer’s certificate: sudo c e r t t o o l−−generate−c e r t i f i c a t e \ −−load−privkey ldap02_slapd_key . pem \ −−load−ca−c e r t i f i c a t e / etc / s s l / c e r t s /mycacert . pem \ −−load−ca−privkey / etc / s s l / private /mycakey . pem \ −−template ldap02 . i n f o \ −−o u t f i l e ldap02_slapd_cert . pem 206

207

note we had to use sudo to get access to the ca’s private key. this means the generated certificate file is owned by root. you should change that ownership back to your regular user before copying these files over to the consumer. get a copy of the ca certificate: cp / etc / s s l / c e r t s / mycacert . pem . cd . . on the consumer side, install the certificate files you just transferred: sudo cp ldap02_slapd_cert . pem ldap02_slapd_key . pem / etc / ldap sudo chgrp openldap / etc / ldap /ldap02_slapd_key . pem sudo chmod 0640 / etc / ldap /ldap02_slapd_key . pem create the file certinfo . ldif with the following contents (adjust accordingly regarding paths and filenames, if needed): dn : cn=c o n f i g add : olctlscacertificatefile olctlscacertificatefile : / etc / s s l / c e r t s / mycacert . pem we’re done. now transfer the ldap02−ssl directory to the consumer. here we use scp (adjust accordingly): ldap02−s s l user@consumer : scp−r sudo cp mycacert . pem / usr / l o c a l / share /ca−c e r t i f i c a t e s / mycacert . c r t sudo update−ca−c e r t i f i c a t e s −add : o l c t l s c e r t i f i c a t e f i l e −add : olctlscertificatekeyfile sudo ldapmodify−y external−h ldapi :///−f $ ldapwhoami−x−zz−h ldap02 . example . com o l c t l s c e r t i f i c a t e f i l e : / etc / ldap / ldap02_slapd_cert . pem test: anonymous olctlscertificatekeyfile : / etc / ldap /ldap02_slapd_key . pem configure the slapd-config database: c e r t i n f o . l d i f network file system (nfs) nfs allows a system to share directories and files with others over a network. by using nfs, users and programs can access files on remote systems almost as if they were local files. some of the most notable benefits that nfs can provide are: • local workstations use less disk space because commonly used data can be stored on a single machine and still remain accessible to others over the network. • there is no need for users to have separate home directories on every network machine. home directories could be set up on the nfs server and made available throughout the network. 207

208

• storage devices such as floppy disks, cdrom drives, and usb thumb drives can be used by other machines on the network. this may reduce the number of removable media drives throughout the network. installation at a terminal prompt enter the following command to install the nfs server: sudo apt i n s t a l l nfs−kernel−s e r v e r to start the nfs server, you can run the following command at a terminal prompt: sudo systemctl s t a r t nfs−kernel−s e r v e r . s e r v i c e configuration you can configure the directories to be exported by adding them to the /etc/exports file. for example: / srv /home / scratch *(rw , async , no_subtree_check , no_root_squash , noexec ) *( ro , sync , subtree_check ) *. hostname . com(rw , sync , no_subtree_check ) make sure any custom mount points you’re adding have been created (/srv and /home will already exist): sudo mkdir / scratch apply the new config via: sudo e x p o r t f s−a .com but not foo.bar.my−domain.com. you can replace * with one of the hostname formats. make the hostname declaration as specific as possible so unwanted systems cannot access the nfs mount. be aware that *.hostname.com will matchfoo.hostname the sync/async options control whether changes are gauranteed to be committed to stable storage before replying to requests. async thus gives a performance benefit but risks data loss or corruption. even though sync is the default, it’s worth setting since exportfs will issue a warning if it’s left unspecified. subtree_check and no_subtree_check enables or disables a security verification that subdirectories a client attempts to mount for an exported filesystem are ones they’re permitted to do so. this verification step has some performance implications for some use cases, such as home directories with frequent file renames. read-only filesystems are more suitable to enable subtree_check on. like with sync, exportfs will warn if it’s left unspecified. there are a number of optional settings for nfs mounts for tuning performance, tightening security, or providing conveniences. these settings each have their own trade-offs so it is important to use them with care, only as needed for the particular use case. no_root_squash, for example, adds a convenience to allow root-owned files to be modified by any client system’s root user; in a multi-user environment where executables are allowed on a shared mount point, this could lead to security problems. noexec prevents executables from running from the mount point. to enable nfs support on a client system, enter the following command at the terminal prompt: sudo apt nfs client configuration i n s t a l l nfs−common 208

209

use the mount command to mount a shared nfs directory from another machine, by typing a command line similar to the following at a terminal prompt: sudo mkdir /opt/example sudo mount example . hostname . com :/ srv /opt/example warning the mount point directory /opt/example must exist. there should be no files or subdirecto- ries in the /opt/example directory, else they will become inaccessible until the nfs filesystem is unmounted. an alternate way to mount an nfs share from another machine is to add a line to the /etc/fstab file. the line must state the hostname of the nfs server, the directory on the server being exported, and the directory on the local machine where the nfs share is to be mounted. the general syntax for the line in /etc/fstab file is as follows: example . hostname . com :/ srv /opt/example nfs r s i z e =8192, wsize =8192, timeo =14, i n t r references linux nfs wiki linux nfs faq ubuntu wiki nfs howto ubuntu wiki nfsv4 howto openssh server introduction openssh is a powerful collection of tools for the remote control of, and transfer of data between, networked computers. you will also learn about some of the configuration settings possible with the openssh server application and how to change them on your ubuntu system. openssh is a freely available version of the secure shell (ssh) protocol family of tools for remotely con- trolling, or transferring files between, computers. traditional tools used to accomplish these functions, such as telnet or rcp, are insecure and transmit the user’s password in cleartext when used. openssh provides a server daemon and client tools to facilitate secure, encrypted remote control and file transfer operations, effectively replacing the legacy tools. the openssh server component, sshd, listens continuously for client connections from any of the client tools. when a connection request occurs, sshd sets up the correct connection depending on the type of client tool connecting. for example, if the remote computer is connecting with the ssh client application, the openssh server sets up a remote control session after authentication. if a remote user connects to an openssh server with scp, the openssh server daemon initiates a secure copy of files between the server and client after authentication. openssh can use many authentication methods, including plain password, public key, and kerberos tickets. installation installation of the openssh client and server applications is simple. to install the openssh client applica- tions on your ubuntu system, use this command at a terminal prompt: sudo apt i n s t a l l openssh−c l i e n t 209

210

to install the openssh server application, and related support files, use this command at a terminal prompt: sudo apt i n s t a l l openssh−s e r v e r configuration you may configure the default behavior of the openssh server application, sshd, by editing the file /etc /ssh/sshd_config. for information about the configuration directives used in this file, you may view the appropriate manual page with the following command, issued at a terminal prompt: man sshd_config there are many directives in the sshd configuration file controlling such things as communication settings, and authentication modes. the following are examples of configuration directives that can be changed by editing the /etc/ssh/sshd_config file. tip prior to editing the configuration file, you should make a copy of the original file and protect it from writing so you will have the original settings as a reference and to reuse as necessary. copy the /etc/ssh/sshd_config file and protect it from writing with the following commands, issued at a terminal prompt: sudo cp / etc / ssh / sshd_config / etc / ssh / sshd_config . o r i g i n a l sudo chmod a−w / etc / ssh / sshd_config . o r i g i n a l sudo sshd−t−f / etc / ssh / sshd_config the following are examples of configuration directives you may change: furthermore since losing an ssh server might mean losing your way to reach a server, check the configuration after changing it and before restarting the server: • to set your openssh to listen on tcp port 2222 instead of the default tcp port 22, change the port directive as such: port 2222 • to make your openssh server display the contents of the /etc/issue .net file as a pre-login banner, simply add or modify this line in the /etc/ssh/sshd_config file: banner /etc/issue.net after making changes to the /etc/ssh/sshd_config file, save the file, and restart the sshd server application to effect the changes using the following command at a terminal prompt: sudo systemctl sshd . s e r v i c e r e s t a r t warning many other configuration directives for sshd are available to change the server application’s behavior to fit your needs. be advised, however, if your only method of access to a server is ssh, and you make a mistake in configuring sshd via the /etc/ssh/sshd_config file, you may find you are locked out of the server upon restarting it. additionally, if an incorrect configuration directive is supplied, the sshd server may refuse to start, so be extra careful when editing this file on a remote server. 210

211

ssh keys this will generate the keys using the rsa algorithm. at the time of this writing, the generated keys will with 4096 bits, you can do: rsa rsa−b 4096 ssh allow authentication between two hosts without the need of a password. ssh key authentication uses a private key and a public key. to generate the keys, from a terminal prompt enter: ssh−keygen−t have 3072 bits. you can modify the number of bits by using the−b option. for example, to generate keys ssh−keygen−t ssh−copy−id username@remotehost during the process you will be prompted for a password. simply hit enter when prompted to create the key. by default the public key is saved in the file ~/.ssh/id_rsa.pub, while ~/.ssh/id_rsa is the private key. now copy the id_rsa.pub file to the remote host and append it to ~/.ssh/authorized_keys by entering: finally, double check the permissions on the authorized_keys file, only the authenticated user should have read and write permissions. if the permissions are not correct change them by: chmod 600 . ssh / authorized_keys you should now be able to ssh to the host without being prompted for a password. import keys from public keyservers these days many users have already ssh keys registered with services like launchpad or github. those can be easily imported with: ssh−import−id <username−on−remote−s er v i ce > the prefix lp: is implied and means fetching from launchpad, the alternative gh: will make the tool fetch from github instead. two factor authentication with u2f/fido openssh 8.2 added support for u2f/fido hardware authentication devices. these devices are used to provide an extra layer of security on top of the existing key-based authentication, as the hardware token needs to be present to finish the authentication. it’s very simple to use and setup. the only extra step is generate a new keypair that can be used with the hardware device. for that, there are two key types that can be used: ecdsa−sk and ed25519−sk. the former has broader hardware support, while the latter might need a more recent device. once the keypair is generated, it can be used as you would normally use any other type of key in openssh. the only requirement is that in order to use the private key, the u2f device has to be present on the host. for example, plug the u2f device in and generate a keypair to use with it: 211

212

$ ssh−keygen−t ecdsa−sk generating public / private ecdsa−sk key pair . you may need to touch your authenticator touch device to authorize key generation . <−− f i l e in which to save the key (/home/ubuntu /. ssh /id_ecdsa_sk ) : enter enter passphrase ( empty f o r no passphrase ) : enter same passphrase again : your i d e n t i f i c a t i o n has been saved in /home/ubuntu /. ssh /id_ecdsa_sk your public key has been saved in /home/ubuntu /. ssh /id_ecdsa_sk . pub the key f i n g e r p r i n t sha256 :v9pq1mqau8fodxdhqdih9mxb8xk3o5avydqlvl9ifro ubuntu@focal i s : now just transfer the public part to the server to ~/.ssh/authorized_keys and you are ready to go: . ssh /id_ecdsa_sk ubuntu@focal . s e r v e r $ ssh−i confirm user presence f o r key ecdsa−sk sha256 : v9pq1mqau8fodxdhqdih9mxb8xk3o5avydqlvl9ifro <−− touch device welcome to ubuntu focal fossa (gnu/linux 5.4.0−21− g e n e r i c x86_64 ) ( . . . ) ubuntu@focal . s e r v e r :~ $ references • ubuntu wiki ssh page. • openssh website • openssh 8.2 release notes • advanced openssh wiki page vpn openvpn is a virtual private networking (vpn) solution provided in the ubuntu repositories. it is flexible, reliable and secure. it belongs to the family of ssl/tls vpn stacks (different from ipsec vpns). this chapter will cover installing and configuring openvpn to create a vpn. openvpn if you want more than just pre-shared keys openvpn makes it easy to set up a public key infrastructure (pki) to use ssl/tls certificates for authentication and key exchange between the vpn server and clients. openvpn can be used in a routed or bridged vpn mode and can be configured to use either udp or tcp. the port number can be configured as well, but port 1194 is the official one; this single port is used for all communication. vpn client implementations are available for almost anything including all linux distributions, os x, windows and openwrt based wlan routers. server installation to install openvpn in a terminal enter: sudo apt i n s t a l l openvpn easy−rsa 212

213

public key infrastructure setup the first step in building an openvpn configuration is to establish a pki (public key infrastructure). the pki consists of: • a separate certificate (also known as a public key) and private key for the server and each client. • a master certificate authority (ca) certificate and key, used to sign the server and client certificates. openvpn supports bidirectional authentication based on certificates, meaning that the client must authen- ticate the server certificate and the server must authenticate the client certificate before mutual trust is established. both server and client will authenticate the other by first verifying that the presented certificate was signed by the master certificate authority (ca), and then by testing information in the now-authenticated certificate header, such as the certificate common name or certificate type (client or server). certificate authority setup to setup your own certificate authority (ca) and generate certificates and keys for an openvpn server the scripts will not be lost when the package is updated. from a terminal, run: server keys and certificates next, we will generate a key pair for the server: and multiple clients first copy the easy−rsa directory to /etc/openvpn. this will ensure that any changes to sudo make−cadir / etc /openvpn/easy−rsa note: if desired, you can alternatively edit /etc/openvpn/easy−rsa/vars directly, adjusting it to your needs. as root user change to the newly created directory /etc/openvpn/easy−rsa and run: ./ easyrsa i n i t−pki ./ easyrsa build−ca ./ easyrsa gen−req myservername nopass ./ easyrsa gen−dh ./ easyrsa gen−req myservername nopass ./ easyrsa sign−req s e r v e r myservername diffie hellman parameters must be generated for the openvpn server. the following will place them in pki/dh.pem. all certificates and keys have been generated in subdirectories. common practice is to copy them to /etc/openvpn/: cp pki /dh . pem pki /ca . c r t pki / issued /myservername . c r t pki / private /myservername . and finally a certificate for the server: key / etc /openvpn/ 213

214

client certificates the vpn client will also need a certificate to authenticate itself to the server. usually you create a different certificate for each client. this can either be done on the server (as the keys and certificates above) and then securely distributed to the client. or vice versa: the client can generate and submit a request that is sent and signed by the server. to create the certificate, enter the following in a terminal while being user root: ./ easyrsa gen−req myclient1 nopass ./ easyrsa sign−req c l i e n t myclient1 can then import it via easyrsa import−req /incoming/myclient1.req myclient1. then you can go on with the second sign−eq command. if the first command above was done on a remote system, then copy the .req file to the ca server. there you in both cases, afterwards copy the following files to the client using a secure method: • pki/ca.crt • pki/issued/myclient1.crt as the client certificates and keys are only required on the client machine, you can remove them from the server. simple server configuration t o t a l 68 start with copying and unpacking server.conf.gz to /etc/openvpn/server.conf. along with your openvpn installation you got these sample config files (and many more if you check): root 3427 2011−07−04 15:09 c l i e n t . conf root 4141 2011−07−04 15:09 s e r v e r . conf . gz root@server :/# l s−l / usr / share /doc/openvpn/examples /sample−config−f i l e s / −rw−r−−r−− 1 root −rw−r−−r−− 1 root sudo cp / usr / share /doc/openvpn/ examples/sample−config−f i l e s / s e r v e r . conf . gz / sudo gzip−d / etc /openvpn/ myserver . conf . gz edit /etc/openvpn/myserver.conf to make sure the following lines are pointing to the certificates and keys you created in the section above. ca ca . c r t c e r t myservername . c r t key myservername . key dh dh2048 . pem etc /openvpn/ myserver . conf . gz complete this set with a ta key in etc/openvpn for tls-auth like: ta . key edit /etc/sysctl .conf and uncomment the following line to enable ip forwarding. #net . ipv4 . ip_forward=1 sudo openvpn−−genkey−−s e c r e t sudo s y s c t l−p / etc / s y s c t l . conf then reload sysctl. 214

215

that is the minimum you have to configure to get a working openvpn server. you can use all the default settings in the sample server.conf file. now start the server. be aware that the “systemctl start openvpn” is not starting your openvpn you just defined. openvpn uses templatized systemd jobs, openvpn@configfilename. so if for example your configuration file is myserver.conf your service is called openvpn@myserver. you can run all kinds of service and systemctl commands like start/stop/enable/disable/preset against a templatized service like openvpn@server. $ sudo systemctl s t a r t openvpn@myserver you will find logging and error messages in the journal. for example, if you started a templatized service openvpn@server you can filter for this particular message source with: sudo j o u r n a l c t l−u openvpn@myserver−xe openvpn@myserver . s e r v i c e− openvpn connection to myserver the same templatized approach works for all of systemctl: $ sudo systemctl status openvpn@myserver preset : enabled ) loaded : main pid : 4138 ( openvpn ) active : a c t i v e ( running ) docs : man: openvpn (8) tun0 l o c a l 1 0 . 8 . 0 . 1 peer 1 0 . 8 . 0 . 2 loaded (/ l i b /systemd/system/openvpn@ . s e r v i c e ; disabled ; vendor https :// community . openvpn . net /openvpn/ wiki /openvpn24manpage https :// community . openvpn . net /openvpn/ wiki /howto status : ” i n i t i a l i z a t i o n sequence completed” tasks : 1 ( l i m i t : 533) memory : 1.0m s i n c e thu 2019−10−24 10:59:25 utc; 10 s ago cgroup : /system . s l i c e /system−openvpn . s l i c e /openvpn@myserver . s e r v i c e ฀฀ 4138 / usr / sbin /openvpn−−daemon ovpn−myserver−−status /run/openvpn / myserver . status 10−−cd / etc /openvpn−−s c r i p t−s e c u r i t y 2−− c o n f i g / etc /openvpn/ myserver . conf−−writepid /run/ oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : / sbin / ip addr add dev oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : / sbin / ip route add oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : could not determine ipv4/ oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : socket buffers : r =[212992−>212992] s=[212992−>212992] oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : udpv4 l i n k l o c a l oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : udpv4 l i n k remote : oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : multi: multi_init called , oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : oct 24 10:59:26 eoan−vpn−s e r v e r ovpn−myserver [ 4 1 3 8 ] : ifconfig pool list i n i t i a l i z a t i o n sequence ipv6 protocol . using af_inet =10.8.0.4 s i z e =62, ipv6=0 af_unspec] r=256 v=256 1 0 . 8 . 0 . 0 / 2 4 via 1 0 . 8 . 0 . 2 ( bound ) : [ ifconfig pool: base [af_inet ] [ undef ] : 1 1 9 4 completed you can enable/disable various openvpn services on one system, but you could also let ubuntu do it for you. there is config for autostartin /etc/default/openvpn. allowed values are “all”, “none” or space 215

216

separated list of names of the vpns. configutation file name. if empty, “all” is assumed. the vpn name refers to the vpn i.e. home would be /etc/openvpn/home.conf if you’re running systemd, changing this variable will require running systemctl daemon−reload followed by a restart of the openvpn service (if you removed entries you may have to stop those manually). after “systemctl daemon-reload” a restart of the “generic” openvpn will restart all dependent services that the generator in /lib/systemd/system-generators/openvpn-generator created for your conf files when you called daemon-reload. now check if openvpn created a tun0 interface: root@server :/ etc /openvpn# ip addr show dev tun0 5: tun0 : <pointopoint,multicast,noarp,up,lower_up> mtu 1500 qdisc fq_codel s t a t e unknown group d e f a u l t qlen 100 l i n k /none i n e t 1 0 . 8 . 0 . 1 peer 1 0 . 8 . 0 . 2 / 3 2 scope g lobal f o r e v e r inet6 fe80 : : b5ac : 7 8 2 9 : f31e :32 c5 /64 scope l i n k stable−privacy f o r e v e r p r e f e r r e d _ l f t v a l i d _ l f t v a l i d _ l f t f o r e v e r p r e f e r r e d _ l f t tun0 f o r e v e r simple client configuration there are various different openvpn client implementations with and without guis. you can read more about clients in a later section on vpn clients. for now we use commandline/service based openvpn client for ubuntu which is part of the very same package as the server. so you have to install the openvpn package again on the client machine: sudo apt i n s t a l l openvpn openvpn/ this time copy the client.conf sample config file to /etc/openvpn/: sudo cp / usr / share /doc/openvpn/ examples/sample−config−f i l e s / c l i e n t . conf / etc / copy the following client keys and certificate files you created in the section above to e.g. /etc/openvpn/ and edit /etc/openvpn/client.conf to make sure the following lines are pointing to those files. if you have the files in /etc/openvpn/ you can omit the path. ca ca . c r t c e r t myclient1 . c r t key myclient1 . key and you have to specify the openvpn server name or address. make sure the keyword client is in the config. that’s what enables client mode. c l i e n t remote vpnserver . example . com 1194 t l s−auth ta . key 1 now start the openvpn client with the same templatized mechanism: $ sudo systemctl s t a r t openvpn@client you can check status as you did on the server: 216

217

incoming data channel : i n i t i a l i z e d with 256 b i t key i n i t i a l i z e d with 256 b i t key to 100 up mtu 1500 active : a c t i v e ( running ) docs : man: openvpn (8) $ sudo systemctl openvpn@client . s e r v i c e− openvpn connection to c l i e n t status openvpn@client preset : enabled ) loaded : loaded (/ l i b /systemd/system/openvpn@ . s e r v i c e ; disabled ; vendor 1 9 2 . 1 6 8 . 1 2 2 . 1 / 2 5 5 . 2 5 5 . 2 5 5 . 0 iface=ens3 hwaddr=52:54:00:3 c :5 a :88 https :// community . openvpn . net /openvpn/ wiki /openvpn24manpage https :// community . openvpn . net /openvpn/ wiki /howto status : ” i n i t i a l i z a t i o n sequence completed” tasks : 1 ( l i m i t : 533) memory : 1.3m s i n c e thu 2019−10−24 11:42:35 utc; 6 s ago cgroup : /system . s l i c e /system−openvpn . s l i c e / openvpn@client . s e r v i c e ฀฀ 3616 / usr / sbin /openvpn−−daemon ovpn−c l i e n t−−status /run/openvpn/ c l i e n t . status 10−−cd / etc /openvpn−−s c r i p t−s e c u r i t y 2−−c o n f i g / etc /openvpn/ c l i e n t . conf−−writepid /run/openvp oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : outgoing data channel : ’aes−256−gcm’ oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : ’aes−256−gcm’ oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : route_gateway oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : tun/tap device tun0 opened oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : tun/tap tx queue length s e t oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : / sbin / ip l i n k s e t dev tun0 oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : / sbin / ip addr add dev tun0 oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : / sbin / ip route add oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : warning: in memory−− use the auth−nocache option to prevent oct 24 11:42:36 eoan−vpn−c l i e n t ovpn−c l i e n t [ 3 6 1 6 ] : ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 tls: ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 verify ok: depth=1, cn=easy−rsa ca ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 verify ok: depth=0, cn=myclient1 ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 peer i n f o : iv_ver=2.4.7 i n f o : iv_plat=linux i n f o : iv_proto=2 i n f o : iv_ncp=2 iv_lz4=1 i n f o : i n f o : iv_lz4v2=1 i n f o : iv_lzo=1 i n f o : iv_comp_stub=1 i n f o : iv_comp_stubv2=1 i n f o : iv_tcpnl=1 on the server log an incoming connection looks like the following. you can see client name and source address as well as success/failure messages. ] 1 9 2 . 1 6 8 . 1 2 2 . 1 1 4 : 5 5 7 3 8 , s i d=5e943ab8 40 ab9fed may cache passwords t h i s i n i t i a l packet from [af_inet l o c a l 1 0 . 8 . 0 . 6 peer 1 0 . 8 . 0 . 5 1 0 . 8 . 0 . 1 / 3 2 via 1 0 . 8 . 0 . 5 t h i s c o n f i g u r a t i o n i n i t i a l i z a t i o n sequence main pid : 3616 ( openvpn ) cipher cipher completed 217

218

ipv4 =10.8.0.6 , ipv6=(not enabled ) myclient1 /192.168.122.114:55738 tlsv1 .3 tls_aes_256_gcm_sha384, 2048 b i t rsa f o r myclient1 / 1 9 2 . 1 6 8 . 1 2 2 . 1 1 4 : 5 5 7 3 8 : 1 0 . 8 . 0 . 6 i n i t i a t e d with [af_inet] 1 9 2 . 1 6 8 . 1 2 2 . 1 1 4 : 5 5 7 3 8 ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 control channel : tlsv1 . 3 , cipher ovpn−myserver [ 4 8 1 8 ] : 192.168.122.114:55738 [ myclient1 ] peer connection ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 multi_sva : pool ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 multi: learn : 1 0 . 8 . 0 . 6−> ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 multi: primary v i r t u a l ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 push: received c o n t r o l ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 sent control [ myclient1 ] : ’push_reply, route 1 0 . 8 . 0 . 1 , topology net30 , ping 10 , ping−r e s t a r t 120 , i f c o n f i g 1 0 . 8 . 0 . 6 1 0 . 8 . 0 . 5 , peer−id 0 , cipher aes−256−gcm’ ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 data channel : using ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 outgoing data channel : ovpn−myserver [ 4 8 1 8 ] : myclient1 /192.168.122.114:55738 incoming data channel : ’aes−256−gcm’ i n i t i a l i z e d with 256 b i t key i n i t i a l i z e d with 256 b i t key negotiated cipher message : ’push_request’ cipher cipher ’aes−256−gcm’ ’aes−256−gcm’ returned ip ( status =1) and you can check on the client if it created a tun0 interface: $ ip addr show dev tun0 4: tun0 : <pointopoint,multicast,noarp,up,lower_up> mtu 1500 qdisc fq_codel s t a t e unknown group d e f a u l t qlen 100 l i n k /none i n e t 1 0 . 8 . 0 . 6 peer 1 0 . 8 . 0 . 5 / 3 2 scope g lobal f o r e v e r inet6 fe80 : : 5 a94 : ae12 : 8 9 0 1 : 5 a75 /64 scope l i n k stable−privacy f o r e v e r p r e f e r r e d _ l f t f o r e v e r p r e f e r r e d _ l f t v a l i d _ l f t v a l i d _ l f t f o r e v e r tun0 check if you can ping the openvpn server: root@client :/ etc /openvpn# ping 1 0 . 8 . 0 . 1 ping 1 0 . 8 . 0 . 1 ( 1 0 . 8 . 0 . 1 ) 56(84) bytes of data . 64 bytes from 1 0 . 8 . 0 . 1 : icmp_req=1 t t l =64 time =0.920 ms note the openvpn server always uses the first usable ip address in the client network and only that ip is pingable. e.g. if you configured a /24 for the client network mask, the .1 address will be used. the p-t-p address you see in the ip addr output above is usually not answering ping requests. check out your routes: $ ip route d e f a u l t via 192.168.122.1 dev ens3 proto dhcp s r c 192.168.122.114 metric 100 1 0 . 8 . 0 . 1 via 1 0 . 8 . 0 . 5 dev tun0 1 0 . 8 . 0 . 5 dev tun0 proto kernel 192.168.122.0/24 dev ens3 proto kernel 192.168.122.1 dev ens3 proto dhcp scope l i n k s r c 192.168.122.114 metric 100 scope l i n k s r c 192.168.122.114 scope l i n k s r c 1 0 . 8 . 0 . 6 218

219

if the above didn’t work for you, check this: first trouble shooting • check your journal−xe server. option config option • check that you have specified the keyfile names correctly in client and server conf files • can the client connect to the server machine? maybe a firewall is blocking access? check journal on • client and server must use same protocol and port, e.g. udp port 1194, see port and proto config • client and server must use same config regarding compression, see comp-lzo config option • client and server must use same config regarding bridged vs routed mode, see server vs server-bridge advanced configuration advanced routed vpn configuration on server the above is a very simple working vpn. the client can access services on the vpn server machine through an encrypted tunnel. if you want to reach more servers or anything in other networks, push some routes to the clients. e.g. if your company’s network can be summarized to the network 192.168.0.0/16, you could push this route to the clients. but you will also have to change the routing for the way back - your servers need to know a route to the vpn client-network. the example config files that we have been using in this guide are full of all these advanced options in the form of a comment and a disabled configuration line as an example. note please read the openvpn hardening security guide for further security advice. advanced bridged vpn configuration on server openvpn can be setup for either a routed or a bridged vpn mode. sometimes this is also referred to as osi layer-2 versus layer-3 vpn. in a bridged vpn all layer-2 frames - e.g. all ethernet frames - are sent to the vpn partners and in a routed vpn only layer-3 packets are sent to vpn partners. in bridged mode all traffic including traffic which was traditionally lan-local like local network broadcasts, dhcp requests, arp requests etc. are sent to vpn partners whereas in routed mode this would be filtered. prepare interface config for bridging on server first, use netplan to configure a bridge device using the desired ethernet device. $ cat / etc / netplan/01− netcfg . yaml network : version : 2 renderer : networkd ethernets : enp0s31f6 : dhcp4 : no bridges : br0 : i n t e r f a c e s : dhcp4 : no addresses : [ enp0s31f6 ] [ 1 0 . 0 . 1 . 1 0 0 / 2 4 ] 219

220

gateway4 : 1 0 . 0 . 1 . 1 nameservers : addresses : [ 1 0 . 0 . 1 . 1 ] static ip addressing is highly suggested. dhcp addressing can also work, but you will still have to encode a static address in the openvpn configuration file. the next step on the server is to configure the ethernet device for promiscuous mode on boot. to do this, ensure the networkd-dispatcher package is installed and create the following configuration script. sudo apt update sudo apt i n s t a l l networkd−dispatcher sudo touch / usr / l i b /networkd−dispatcher /dormant . d/ promisc_bridge sudo chmod +x / usr / l i b /networkd−dispatcher /dormant . d/ promisc_bridge s e t−e # no networkd−dispatcher event f o r ip l i n k s e t enp0s31f6 up promisc on then add the following contents. #!/ bin /sh ’ c a r r i e r ’ on the physical i n t e r f a c e [ ”$iface” = br0 ] ; then i f f i prepare server config for bridging edit /etc/openvpn/server.conf to use tap rather than tun and set the server to use the server-bridge directive: ; dev tun dev tap ; s e r v e r 1 0 . 8 . 0 . 0 255.255.255.0 server−bridge 1 0 . 0 . 0 . 4 255.255.255.0 1 0 . 0 . 0 . 1 2 8 1 0 . 0 . 0 . 2 5 4 after configuring the server, restart openvpn by entering: sudo systemctl r e s t a r t openvpn@myserver prepare client config for bridging the only difference on the client side for bridged mode to what was outlined above is that you need to edit /etc/openvpn/client.conf and set tap mode: dev tap ; dev tun finally, restart openvpn: sudo systemctl r e s t a r t openvpn@client you should now be able to connect to the full remote lan through the vpn. references • easyrsa • openvpn quick start guide • snap’ed version of openvpn easy-openvpn • debians openvpn guide 220

221

installing a gitolite server gitolite provides a traditional source control management server for git, with multiple users and access rights management. gitolite can be installed with the following command: sudo apt i n s t a l l g i t o l i t e 3 gitolite configuration configuration of the gitolite server is a little different that most other servers on unix-like systems, in that gitolite stores its configuration in a git repository rather than in files in /etc/. the first step to configuring a new installation is therefore to allow access to the configuration repository. first of all, let’s create a user for gitolite to use for the service: sudo adduser−−system−−s h e l l / bin /bash−−group−−disabled−password−−home / now we want to let gitolite know about the repository administrator’s public ssh key. this assumes that the current user is the repository administrator. if you have not yet configured an ssh key, refer to openssh-keys in this manual. cp ~/. ssh / id_rsa . pub /tmp/$ (whoami) . pub home/ g i t g i t let’s switch to the git user and import the administrator’s key into gitolite. sudo su− g i t gl−setup /tmp/*. pub g i t clone git@$ip_address : g i t o l i t e−admin . g i t cd g i t o l i t e−admin gitolite will allow you to make initial changes to its configuration file during the setup process. you can now clone and modify the gitolite configuration repository from your administrator user (the user whose public ssh key you imported). switch back to that user, then clone the configuration repository: e x i t the gitolite-admin contains two subdirectories, “conf” and “keydir”. the configuration files are in the conf dir, and the keydir directory contains the list of user’s public ssh keys. managing gitolite users and repositories adding a new user to gitolite is simple: just obtain their public ssh key and add it to the keydir directory as $desired_user_name.pub. note that the gitolite usernames don’t have to match the system usernames - they are only used in the gitolite configuration file to manage access control. similarly, users are deleted by deleting their public key files. after each change, do not forget to commit the changes to git, and push the changes back to the server with g i t commit−a g i t push o r i g i n master repositories are managed by editing the conf/ gitolite .conf file. the syntax is space separated, and simply specifies the list of repositories followed by some access rules. the following is a default example 221

222

repo repo g i t o l i t e−admin rw+ r = = admin a l i c e project1 rw+ rw r = = = a l i c e bob denise using your server once a user’s public key has been imported by the gitolite admin and authorization granted to the user to one or more repositories, the user can access repositories with the following command: g i t clone git@$server_ip :$project_name. g i t to add the server as a new remote for an existing git repository: g i t remote add g i t o l i t e git@$server_ip :$project_name. g i t references • gitolite’s code repository provides access to source code. • gitolite’s documentation includes a “fool proof setup” guide and a cookbook with recipes for common • gitolite’s maintainer has written a book, gitolite essentials, for more in-depth information about the tasks. software. • general information about git itself can be found at the git homepage. client software implementations linux network-manager gui for openvpn many linux distributions including ubuntu desktop variants come with network manager, a nice gui to configure your network settings. it also can manage your vpn connections. it is the default, but if in doubt make sure you have package network−manager−openvpn installed. open the network manager gui, select the vpn tab and then the ‘add’ button. select openvpn as the vpn type in the opening requester and press ‘create’. in the next window add the openvpn’s server name as the ‘gateway’, set ‘type’ to ‘certificates (tls)’, point ‘user certificate’ to your user certificate, ‘ca certificate’ to your ca certificate and ‘private key’ to your private key file. use the advanced button to enable compression (e.g. comp-lzo), dev tap, or other special settings you set on the server. now try to establish your vpn. openvpn with gui for mac os x • tunnelblick is an excellent free, open source implementation of a gui for openvpn for os x. download the latest os x installer from there and install it. it also is recommended by upstream which would have a alternative on their own 222

223

then put your client.ovpn config file together with the certificates and keys in /users/username/library/ap- plication support/tunnelblick/configurations/ and lauch tunnelblick from your application folder. instead of downloading manually, if you have brew set up on macos this is as easy as: brew cask install tunnelblick openvpn with gui for win first download and install the latest openvpn windows installer. as of this writing, the management gui is included with the windows binary installer. you need to start the openvpn service. goto start > computer > manage > services and applications > services. find the openvpn service and start it. set it’s startup type to automatic. when you start the openvpn mi gui the first time you need to run it as an administrator. you have to right click on it and you will see that option. there is an updated guide by the upstream project for the client on windows. references • see the openvpn website for additional information. • openvpn hardening security guide • also, pakt’s openvpn: building and integrating virtual private networks is a good resource. sssd sssd stands for system security services daemon and it’s actually a collection of daemons that handle authentication, authorization, and user and group information from a variety of network sources. at its core it has support for: - active directory - ldap - kerberos sssd provides pam and nss modules to integrate these remote sources into your system and allow remote users to login and be recognized as valid users, including group membership. to allow for disconnected operation, sssd also can also cache this information, so that users can continue to login in the event of a network failure, or other problem of the same sort. this guide will focus on the most common scenarios where sssd is deployed. sssd and active directory this section describes the use of sssd to authenticate user logins against an active directory via using sssd’s “ad” provider. at the end, active directory users will be able to login on the host using their ad credentials. group membership will also be maintained. prerequisites, assumptions, and requirements • this guide does not explain active directory, how it works, how to set one up, or how to maintain it. • this guide assumes that a working active directory domain is already configured and you have access to the credentials to join a machine to that domain. • the domain controller is acting as an authoritative dns server for the domain. 223

224

• the domain controller is the primary dns resolver (check with systemd−resolve−−status) • system time is correct and in sync, maintained via a service like chrony or ntp • the domain used in this example is ad1.example.com . software installation install the following packages: sudo apt i n s t a l l sssd−ad sssd−t o o l s join the domain realmd a d c l i we will use the realm command, from the realmd package, to join the domain and create the sssd configu- ration. let’s verify the domain is discoverable via dns: * resolving : _ldap . _tcp . ad1 . example . com * performing ldap dse lookup on : 1 0 . 5 1 . 0 . 5 * s u c c e s s f u l l y discovered : ad1 . example . com ad1 . example . com type : kerberos $ sudo realm−v discover ad1 . example . com realm−name : ad1.example.com domain−name : ad1 . example . com server−software : active−d i r e c t o r y c l i e n t−software : required−package : sssd−t o o l s required−package : required−package : l i b n s s−s s s libpam−s s s required−package : required−package : a d c l i required−package : samba−common−bin configured : no sssd sssd this performs several checks and determines the best software stack to use with sssd. sssd can install the missing packages via packagekit, but we installed them already previously. now let’s join the domain: $ sudo realm j o i n ad1 . example . com password f o r administrator : that was quite uneventful. if you want to see what it was doing, pass the−v option: $ sudo realm j o i n−v ad1 . example . com j o i n−−verbose−−domain ad1 . example . com−−domain− realm ad1.example.com−−domain−c o n t r o l l e r 1 0 . 5 1 . 0 . 5−−login−type user−− login−user administrator−−stdin−password * resolving : _ldap . _tcp . ad1 . example . com * performing ldap dse lookup on : 1 0 . 5 1 . 0 . 5 * s u c c e s s f u l l y discovered : ad1 . example . com password f o r administrator : * unconditionally checking packages * resolving required packages * lang=c / usr / sbin / a d c l i 224

225

snippet to / var / cache /realmd/ adcli−krb5−huftug/krb5 . d/ * using domain name : ad1 . example . com * authenticated as user : administrator@ad1 .example.com * looked up short domain name : ad1 * using domain realm : ad1 . example . com * sending netlogon ping to domain c o n t r o l l e r : 1 0 . 5 1 . 0 . 5 * received netlogon i n f o from : server1. ad1 . example . com * wrote out krb5 . conf * calculated computer account name from fqdn : ad−client adcli−krb5−conf−hv2kzi * looked up domain sid : s−1−5−21−2660147319−831819607−3409034899 * using f u l l y q u a l i f i e d name : ad−c l i e n t . ad1 . example . com * using computer account name : ad−client * calculated computer account name from fqdn : ad−client * generated 120 character computer password * using keytab : file :/ etc /krb5 . keytab * found computer account * using domain realm : ad1 . example . com * using domain name : ad1 . example . com f o r ad−client$ at : cn=ad−client,cn=computers ,dc=ad1 , in d i r e c t o r y : cn=ad−client,cn= dc=example ,dc=com * f o r computer account computers ,dc=ad1 ,dc=example ,dc=com * sending netlogon ping to domain c o n t r o l l e r : 1 0 . 5 1 . 0 . 5 * received netlogon i n f o from : server1. ad1 . example . com * set computer password * retrieved kvno ’3 ’ * checking restrictedkrbhost /ad−c l i e n t . ad1 . example . com added restrictedkrbhost /ad−c l i e n t . ad1 . example . com * checking restrictedkrbhost /ad−client added restrictedkrbhost /ad−client * checking host /ad−c l i e n t . ad1 . example . com added host /ad−c l i e n t . ad1 . example . com * checking host /ad−client added host /ad−client * * discovered which keytab s a l t * added the e n t r i e s * * to use to the keytab : ad−client$@ad1.example.com: file :/ etc /krb5 to the keytab : host /ad−client@ad1.example.com: file :/ etc / to the keytab : host /ad−c l i e n t . ad1 . example .com@ad1.example to the keytab : restrictedkrbhost /ad−client@ad1.example. to the keytab : restrictedkrbhost /ad−c l i e n t . ad1 . example . by default, realm will use the administrator account of the domain to request the join. if you need to use another popular way of joining a domain is using an otp, or one time password, token. for that, use the . keytab * added the e n t r i e s krb5 . keytab * added the e n t r i e s .com: file :/ etc /krb5 . keytab * added the e n t r i e s com@ad1.example.com: file :/ etc /krb5 . keytab com: file :/ etc /krb5 . keytab sssd r e s t a r t * added the e n t r i e s * / usr / sbin / s e r v i c e * s u c c e s s f u l l y e n r o l l e d machine in realm * / usr / sbin /update−rc . d sssd enable another account, pass it to the tool with the−u option. −−one−time−password option. 225

226

sssd configuration the realm tool already took care of creating an sssd configuration, adding the pam and nss modules, and starting the necessary services. let’s take a look at /etc/sssd/sssd.conf: [ sssd ] domains = ad1 . example . com c o n f i g _ f i l e _ v e r s i o n = 2 s e r v i c e s = nss , pam [ domain/ad1 . example . com ] d e f a u l t _ s h e l l = / bin /bash krb5_store_password_if_offline = true cache_credentials = true krb5_realm = ad1.example.com realmd_tags = manages−system joined−with−a d c l i id_provider = ad fallback_homedir = /home/%u@%d ad_domain = ad1 . example . com use_fully_qualified_names = true ldap_id_mapping = true access_provider = ad note something very important to remember is that this file must have permissions 0600 and ownership root:root, or else sssd won’t start! let’s highlight a few things from this config: • cache_credentials: this allows logins when the ad server is unreachable • home directory: it’s by default /home/<user>@<domain>. for example, the ad user john will have a home directory of /home/john@ad1.example.com • use_fully_qualified_names: users will be of the form user@domain, not just user. this should only be changed if you are certain no other domains will ever join the ad forest, via one of the several possible trust relationships automatic home directory creation what the realm tool didn’t do for us is setup pam_mkhomedir, so that network users can get a home directory when they login. this remaining step can be done by running the following command: sudo pam−auth−update−−enable mkhomedir checks you should now be able to fetch information about ad users. in this example, john smith is an ad user: $ getent passwd john@ad1 . example . com john@ad1 . example . com:*:1725801106:1725800513: john smith :/ home/john@ad1 . example . com :/ bin /bash let’s see his groups: 226

227

$ groups john@ad1 . example . com john@ad1 . example . com : domain users@ad1 . example . com engineering@ad1 . example . com note if you just changed the group membership of a user, it may be a while before sssd notices due to caching. l o g i n : password : john@ad1 . example . com finally, how about we try a login: $ sudo l o g i n . . . creating d i r e c t o r y ’/home/john@ad1 . example . com ’ . ad−c l i e n t welcome to ubuntu 20.04 lts (gnu/linux 5.4.0−24− g e n e r i c x86_64 ) john@ad1 . example . com@ad−c l i e n t :~ $ welcome to ubuntu 20.04 lts (gnu/linux 5.4.0−24− g e n e r i c x86_64 ) john@ad1 . example . com@ad−c l i e n t :~ $ notice how the home directory was automatically created. you can also use ssh, but note that the command will look a bit funny because of the multiple *@* signs: $ ssh john@ad1 . example . com@10 . 5 1 . 0 . 1 1 note in the ssh example, public key authentication was used, so no password was required. remember that ssh password authentication is by default disabled in /etc/ssh/sshd_config. l o g i n : thu apr 16 21:22:55 2020 ( . . . ) last kerberos tickets if you install krb5−user, your ad users will also get a kerberos ticket upon logging in: john@ad1 . example . com@ad−c l i e n t :~ $ k l i s t ticket cache : file :/ tmp/krb5cc_1725801106_9uxviz default p r i n c i p a l : john@ad1 .example.com valid s t a r t i n g 04/16/20 21:32:12 expires 04/17/20 07:32:12 renew u n t i l 04/17/20 21:32:12 service p r i n c i p a l krbtgt /ad1.example.com@ad1.example.com let’s test with smbclient using kerberos authentication to list he shares of the domain controller: note realm also configured /etc/krb5.conf for you, so there should be no further configuration prompts when installing krb5−user john@ad1 . example . com@ad−c l i e n t :~ $ smbclient−k−l server1 . ad1 . example . com −−−− −−−−−−−−− −−−−−−− remote admin default share admin$ c$ sharename comment disk disk type 227

228

ipc disk disk notice how we now have a ticket for the cifs service, which was used for the share list above: ipc$ netlogon sysvol remote ipc logon s e r v e r logon s e r v e r smb1 disabled−− no workgroup a v a i l a b l e john@ad1 . example . com@ad−c l i e n t :~ $ k l i s t ticket cache : file :/ tmp/krb5cc_1725801106_9uxviz default p r i n c i p a l : john@ad1 .example.com share share valid s t a r t i n g 04/16/20 21:32:12 expires 04/17/20 07:32:12 renew u n t i l 04/17/20 21:32:12 04/16/20 21:32:21 04/17/20 07:32:12 .com service p r i n c i p a l krbtgt /ad1.example.com@ad1.example.com c i f s / server1 . ad1 . example .com@ad1.example desktop ubuntu authentication the desktop login only shows local users in the list to pick from, and that’s on purpose. to login with an active directory user for the first time, follow these steps: • click on the “not listed?” option: click-not-listed|690x517,50% • type in the login name followed by the password: type-in-username|690x517,50% • the next time you login, the ad user will be listed as if it was a local user: next-time|690x517,50% resources • github sssd project • active directory dns zone entries sssd and ldap sssd can also use ldap for authentication, authorization, and user/group information. in this section we will configure a host to authenticate users from an openldap directory. prerequisites, assumptions, and requirements for this setup, we need: • an existing openldap server with ssl enabled and using the rfc2307 schema for users and groups • a client host where we will install the necessary tools and login as an user from the ldap server 228

229

software installation install the following packages: sudo apt i n s t a l l sssd−ldap ldap−u t i l s sssd configuration create the /etc/sssd/sssd.conf configuration file, with permissions 0600 and ownership root:root, and this content: [ sssd ] c o n f i g _ f i l e _ v e r s i o n = 2 domains = example . com [ domain/example . com ] id_provider = ldap auth_provider = ldap ldap_uri = ldap :// ldap01 . example . com cache_credentials = true ldap_search_base = dc=example , dc=com make sure to start the sssd service: sudo systemctl s t a r t sssd . s e r v i c e note sssd will use start_tls by default for authentication requests against the ldap server (the auth_provider), but not for the id_provider. if you want to also enable start_tls for the id_provider, specify ldap_id_use_start_tls = true. automatic home directory creation to enable automatic home directory creation, run the following command: sudo pam−auth−update−−enable mkhomedir check ssl setup on the client the client must be able to use start_tls when connecting to the ldap server, with full certificate checking. this means: • the client host knows and trusts the ca that signed the ldap server certificate • the server certificate was issued for the correct host (ldap01.example.com in this guide) • the time is correct on all hosts performing the tls connection • and, of course, that neither certificate (ca or server’s) expired if using a custom ca, an easy way to have a host trust it is to place it in /usr/local/share/ca−certificates/ with a . crt extension and run sudo update−ca−certificates. alternatively, you can edit /etc/ldap/ldap.conf and point tls_cacert to the ca public key file. note you may have to restart sssd after these changes: sudo systemctl restart sssd 229

230

anonymous once that is all done, check that you can connect to the ldap server using verified ssl connections: $ ldapwhoami−x−zz−h ldap01 . example . com the−zz parameter tells the tool to use start_tls, and that it must not fail. if you have ldap logging enabled on the server, it will show something like this: slapd [ 7 7 9 ] : conn=1032 op=0 starttls slapd [ 7 7 9 ] : conn=1032 op=0 result oid= e r r=0 text= slapd [ 7 7 9 ] : conn=1032 fd=15 tls e s t a b l i s h e d t l s _ s s f =256 s s f =256 slapd [ 7 7 9 ] : conn=1032 op=1 bind dn=”” method=128 slapd [ 7 7 9 ] : conn=1032 op=1 result tag=97 e r r=0 text= slapd [ 7 7 9 ] : conn=1032 op=2 ext oid = 1 . 3 . 6 . 1 . 4 . 1 . 4 2 0 3 . 1 . 1 1 . 3 slapd [ 7 7 9 ] : conn=1032 op=2 whoami slapd [ 7 7 9 ] : conn=1032 op=2 result oid= e r r=0 text= start_tls with err=0 and tls established is what we want to see there, and, of course, the whoami extended operation. final verification john in this example, the ldap server has the following user and group entry we are going to use for testing: dn : uid=john , ou=people , dc=example , dc=com uid : inetorgperson objectclass : objectclass : posixaccount cn : john smith sn : smith givenname : john mail : userpassword : uidnumber : 10001 gidnumber : 10001 l o g i n s h e l l : / bin /bash homedirectory : /home/ john john@example . com j o h n s e c r e t john dn : cn=john , ou=group , dc=example , dc=com cn : objectclass : posixgroup gidnumber : 10001 memberuid : john dn : cn=engineering , ou=group , dc=example , dc=com cn : engineering objectclass : posixgroup gidnumber : 10100 john memberuid : john : * : 1 0 0 0 1 : 1 0 0 0 1 : john smith :/ home/ john :/ bin /bash the user john should be known to the system: ubuntu@ldap−c l i e n t :~ $ getent passwd john ubuntu@ldap−c l i e n t :~ $ id john 230

231

uid =10001( john ) gid =10001( john ) groups =10001( john ) ,10100( engineering ) password : welcome to ubuntu focal fossa ( development branch ) john and we should be able to authenticate as john: l o g i n : ubuntu@ldap−c l i e n t :~ $ sudo l o g i n ldap−c l i e n t john@ldap−c l i e n t :~ $ ( . . . ) creating d i r e c t o r y ’/home/john ’ . x86_64 ) sssd, ldap and kerberos (gnu/linux 5.4.0−24− g e n e r i c finally, we can mix it all together in a setup that is very similar to active directory in terms of the technologies used: use ldap for users and groups, and kerberos for authentication. prerequisites, assumptions, and requirements for this setup, we will need: • an existing openldap server using the rfc2307 schema for users and groups. ssl support is rec- ommended, but not strictly necessary because authentication in this setup is being done via kerberos, and not ldap. • a kerberos server. it doesn’t have to be using the openldap backend • a client host where we will install and configure sssd software installation on the client host, install the following packages: sudo apt i n s t a l l sssd−ldap sssd−krb5 ldap−u t i l s krb5−user you may be asked about the default kerberos realm. for this guide, we are using example.com. at this point, you should alreaedy be able to obtain tickets from your kerberos server, assuming dns records point at it like explained elsewhere in this guide: $ k i n i t ubuntu password f o r ubuntu@example.com: ubuntu@ldap−krb−c l i e n t :~ $ k l i s t ticket cache : file :/ tmp/krb5cc_1000 default p r i n c i p a l : ubuntu@example.com valid s t a r t i n g 04/17/20 19:51:06 expires 04/18/20 05:51:06 renew u n t i l 04/18/20 19:51:05 service p r i n c i p a l krbtgt /example.com@example.com but we want to be able to login as an ldap user, authenticated via kerberos. let’s continue with the configuration. 231

232

sssd configuration create the /etc/sssd/sssd.conf configuration file, with permissions 0600 and ownership root:root, and this content: [ sssd ] c o n f i g _ f i l e _ v e r s i o n = 2 domains = example . com [ domain/example . com ] id_provider = ldap ldap_uri = ldap :// ldap01 . example . com ldap_search_base = dc=example , dc=com auth_provider = krb5 krb5_server = kdc01 . example . com , kdc02 . example . com krb5_kpasswd = kdc01 . example . com krb5_realm = example.com cache_credentials = true this example uses two kdcs, which made it necessary to also specify the krb5_kpasswd server because the second kdc is a replica and is not running the admin server. start the sssd service: sudo systemctl sssd . s e r v i c e s t a r t automatic home directory creation to enable automatic home directory creation, run the following command: sudo pam−auth−update−−enable mkhomedir final verification john in this example, the ldap server has the following user and group entry we are going to use for testing: dn : uid=john , ou=people , dc=example , dc=com uid : objectclass : inetorgperson objectclass : posixaccount cn : john smith sn : smith givenname : john mail : uidnumber : 10001 gidnumber : 10001 l o g i n s h e l l : / bin /bash homedirectory : /home/ john john@example . com john dn : cn=john , ou=group , dc=example , dc=com cn : objectclass : posixgroup gidnumber : 10001 memberuid : john 232

233

dn : cn=engineering , ou=group , dc=example , dc=com cn : engineering objectclass : posixgroup gidnumber : 10100 john memberuid : uid =10001( john ) gid =10001( john ) groups =10001( john ) ,10100( engineering ) let’s try a login as this user: password : l o g i n : john note how the john user has no userpassword attribute. the user john should be known to the system: john : * : 1 0 0 0 1 : 1 0 0 0 1 : john smith :/ home/ john :/ bin /bash ubuntu@ldap−c l i e n t :~ $ getent passwd john ubuntu@ldap−c l i e n t :~ $ id john ubuntu@ldap−krb−c l i e n t :~ $ sudo l o g i n ldap−krb−c l i e n t welcome to ubuntu 20.04 lts (gnu/linux 5.4.0−24− g e n e r i c x86_64 ) john@ldap−krb−c l i e n t :~ $ k l i s t john@ldap−krb−c l i e n t :~ $ ticket cache : file :/ tmp/krb5cc_10001_borxwr default p r i n c i p a l : ( . . . ) creating d i r e c t o r y ’/home/john ’ . valid s t a r t i n g 04/17/20 20:29:50 expires 04/18/20 06:29:50 renew u n t i l 04/18/20 20:29:50 john@example.com service p r i n c i p a l krbtgt /example.com@example.com we logged in using the kerberos password, and user/group information from the ldap server. sssd and kdc spoofing when using sssd to manage kerberos logins on a linux host, there is an attack scenario you should be aware of: kdc spoofing. the objective of the attacker is to login on a workstation that is using kerberos authentication. let’s say he knows john is a valid user on that machine. the attacker first deploys a rogue kdc server in the network, and creates the john principal there with a password of his choosing. what he has to do now is to have his rogue kdc respond to the login request from the workstation, before (or instead of) the real kdc. if the workstation isn’t authenticating the kdc, it will accept the reply from the rogue server and let john in. there is a configuration parameter that can be set to protect the workstation from this attack. it will have sssd authenticate the kdc, and block the login if the kdc cannot be verified. this option is called krb5_validate, and it’s false by default. to enable it, edit /etc/sssd/sssd.conf and add this line to the domain section: 233

234

[ sssd ] c o n f i g _ f i l e _ v e r s i o n = 2 domains = example . com [ domain/example . com ] id_provider = ldap . . . krb5_validate = true kadmin : d e f a u l t i n g to no p o l i c y the second step is to create a host principal on the kdc for this workstation. this is how the kdc’s authenticity is verified. it’s like a “machine account”, with a shared secret that the attacker cannot control and replicate in his rogue kdc..the host principal has the format host/<fqdn>@realm. after the host principal is created, its keytab needs to be stored on the workstation. this two step process can be easily done on the workstation itself via kadmin (not kadmin.local) to contact the kdc remotely: $ sudo kadmin−p ubuntu/admin addprinc−randkey host /ldap−krb−c l i e n t . example .com@example.com warning: no p o l i c y s p e c i f i e d f o r host /ldap−krb−c l i e n t . example .com@example.com; p r i n c i p a l ” host /ldap−krb−c l i e n t . example .com@example.com” created . ktadd−k / etc /krb5 . keytab host /ldap−krb−c l i e n t . example . com entry f o r p r i n c i p a l host /ldap−krb−c l i e n t . example . com with kvno 6 , encryption type aes256−cts−hmac−sha1−96 added to keytab wrfile:/ etc /krb5 . keytab . entry f o r p r i n c i p a l host /ldap−krb−c l i e n t . example . com with kvno 6 , encryption type aes128−cts−hmac−sha1−96 added to keytab wrfile:/ etc /krb5 . keytab . then exit the tool and make sure the permissions on the keytab file are tight: sudo chmod 0600 / etc /krb5 . keytab sudo chown root : root / etc /krb5 . keytab kadmin : you can also do it on the kdc itself using kadmin.local, but you will have to store the keytab temporarily in another file and securely copy it over to the workstation. once these steps are complete, you can restart sssd on the workstation and perform the login. if the rogue kdc picks the attempt up and replies, it will fail the host verification. with debugging we can see that happening on the workstation: ==> / var / log / sssd / krb5_child . log <== (mon apr 20 19:43:58 2020) [ validate_tgt ] (0 x0020 ) : tgt f a i l e d v e r i f i c a t i o n using key f o r com@example.com] . (mon apr 20 19:43:58 2020) [ [ sssd [ krb5_child [ 2 1 0 2 ] ] ] ] [ host /ldap−krb−c l i e n t . example . [−1765328377][ server host /ldap−krb−c l i e n t . example . [ [ sssd [ krb5_child [ 2 1 0 2 ] ] ] ] [ get_and_save_tgt ] x0020 ) : 1741: com@example.com not found in kerberos database ] (0 and the login is denied. if the real kdc picks it up, however, the host verification succeeds: ==> / var / log / sssd / krb5_child . log <== (mon apr 20 19:46:22 2020) [ [ sssd [ krb5_child [ 2 2 6 8 ] ] ] ] [ host /ldap−krb−c l i e n t . example .com@example.com [ validate_tgt ] (0 x0400 ) : tgt v e r i f i e d using key f o r ] . and the login is accepted. 234

235

debugging and troubleshooting here are some tips to help troubleshoot sssd. debug_level the debug level of sssd can be changed on-the-fly via sssctl , from the sssd−tools package: sssd−t o o l s s s s c t l debug−l e v e l <new−l e v e l > sudo apt i n s t a l l or change add it to the config file and restart sssd: [ sssd ] c o n f i g _ f i l e _ v e r s i o n = 2 domains = example . com [ domain/example . com ] debug_level = 6 . . . either will yield more logs in /var/log/sssd/*.log and can help identify what is going on. the sssctl approach has the clear advantage of not having to restart the service. caching caching is useful to speed things up, but it can get in the way big time when troubleshooting. it’s useful to be able to remove the cache while chasing down a problem. this can also be done with the sssctl tool from 429 from api, waiting 32 seconds … (‘you’ve performed this action too many times. please wait 31 seconds before trying again.’) # irc server the ubuntu repository has many internet relay chat servers. this section explains how to install and configure the original irc server ircd-irc2. 235 l o c a l data already e x i s t s , override ? ( yes /no ) f i l e s . . . to be running . start sssd now? ( yes /no ) [ yes ] yes [ no ] yes l o c a l data . . . you can either remove the whole cache: creating backup of sssd backup of removing cache sssd= needs the sssd−tools package. # s s s c t l cache−remove s s s c t l cache−expire−u john s s s c t l cache−expire−e or expire everything: or just one element:

236

to install ircd-irc2, run the following command in the command prompt: sudo apt i n s t a l l the configuration files are stored in /etc/ircd directory. the documents are available in /usr/share/doc/ installation ircd−irc2 directory. configuration ircd−i r c 2 the irc settings can be done in the configuration file /etc/ircd/ircd.conf. you can set the irc host name in this file by editing the following line: m: i r c . l o c a l h o s t : : debian i r c d d e f a u l t c o n f i g u r a t i o n : : 0 0 0a please make sure you add dns aliases for the irc host name. for instance, if you set irc . livecipher .com as irc host name, please make sure irc . livecipher .com is resolvable in your domain name server. the irc host name should not be same as the host name. the irc admin details can be configured by editing the following line: a: organization , irc dept . : daemon <ircd@example . i r c . org >: client server : : ircnet : you should add specific lines to configure the list of irc ports to listen on, to configure operator credentials, to configure client authentication, etc. for details, please refer to the example configuration file /usr/share/ doc/ircd−irc2/ircd.conf.example.gz. the irc banner to be displayed in the irc client, when the user connects to the server can be set in /etc/ircd/ircd.motd file. after making necessary changes to the configuration file, you can restart the irc server using following command: sudo systemctl r e s t a r t ircd−i r c 2 . s e r v i c e references you may also be interested to take a look at other irc servers available in ubuntu repository. it includes, ircd-ircu and ircd-hybrid. • refer to ircd faq for more details about the irc server. dovecot server dovecot is a mail delivery agent, written with security primarily in mind. it supports the major mailbox formats: mbox or maildir. this section explains how to set it up as an imap or pop3 server. installation to install a basic dovecot server with common pop3 and imap functions, run the following command: sudo apt i n s t a l l dovecot−imapd dovecot−pop3d there are various other dovecot modules including dovecot-sieve (mail filtering), dovecot-solr (full text search), dovecot-antispam (spam filter training), dovecot-ldap (user directory). 236

237

configuration to configure dovecot, edit the file /etc/dovecot/dovecot.conf and its included config files in /etc/dovecot/conf .d/. by default all installed protocols will be enabled via an include directive in /etc/dovecot/dovecot.conf. ! include_try / usr / share / dovecot / p r o t o c o l s . d /*. protocol imaps and pop3s are more secure because they use ssl encryption to connect. a basic self-signed ssl conf. by default mbox format is configured, if required you can also use maildir. more about that can be found in certificate is automatically set up by package ssl-cert and used by dovecot in /etc/dovecot/conf.d/10−ssl. the comments in /etc/dovecot/conf.d//10−mail.conf. also see the dovecot web site to learn about further benefits and details. make sure to also configure your mail transport agent (mta) to transfer the incoming mail to the selected type of mailbox. once you have configured dovecot, restart its daemon in order to test your setup: sudo s e r v i c e dovecot r e s t a r t try to log in with the commands telnet localhost pop3 (for pop3) or telnet localhost imap2 (for imap). you should see something like the following: bhuvan@rainbow :~ $ t e l n e t trying 1 2 7 . 0 . 0 . 1 . . . connected to l o c a l h o s t . localdomain . i s escape character +ok dovecot ready . l o c a l h o s t pop3 ’ ^ ] ’ . dovecot ssl configuration dovecot is configured to use ssl automatically by default, using the package ssl-cert which provides a self signed certificate. you can instead generate your own custom certificate for dovecot using openssh, for example: sudo openssl req−new−x509−days 1000−nodes−out ”/ etc / dovecot / dovecot . pem” \−keyout ”/ etc / dovecot / private / dovecot . pem” then edit /etc/dovecot/conf.d/10−ssl.conf and amend following lines to specify dovecat use these custom certificates : s s l _ c e r t = </etc / dovecot / private / dovecot . pem ssl_key = </etc / dovecot / private / dovecot . key see certificates-and-security for more details on creating custom certificates. you can get the ssl certificate from a certificate issuing authority or you can create self-signed one (see certificates-and-security for details). once you create the certificate, you will have a key file and a certificate file that you want to make known in the config shown above. 237

238

firewall configuration for an email server to access your mail server from another computer, you must configure your firewall to allow connections to the server on the necessary ports. • imap - 143 • imaps - 993 • pop3 - 110 • pop3s - 995 references • see the dovecot website for more information. • also, the dovecot ubuntu wiki page has more details. exim4 exim4 is a message transfer agent (mta) developed at the university of cambridge for use on unix systems connected to the internet. exim can be installed in place of sendmail, although its configuration is quite different. installation to install exim4, run the following command: sudo apt i n s t a l l exim4 configuration to configure exim4, run the following command: file, so to re-configure you can either re-run the wizard or manually edit this file using your favorite editor. once you are finished, you can run the following command to generate the master configuration file: this displays a user interface “wizard” for configuring the software. for example, in exim4 the configuration files are split among multiple files; if you wish to have them in one file you can configure accordingly via this user interface. sudo dpkg−r e c o n f i g u r e exim4−c o n f i g all the configurable parameters from the user interface are stored in /etc/exim4/update−exim4.conf.conf sudo update−exim4 . conf .autogenerated, because it is updated automatically every time you run update−exim4.conf, so the master configuration file is stored in /var/lib/exim4/config.autogenerated. warning at any time, you should not manually edit the master configuration file, /var/lib/exim4/config your changes will risk being accidentally lost during a future update. 238

240

to configure the saslauthd to provide authentication for exim4, first install the sasl2-bin package by running this command at a terminal prompt: sudo apt i n s t a l l configuring sasl sasl2−bin sudo adduser debian−exim s a s l finally, start the saslauthd service: sudo s e r v i c e saslauthd s t a r t to configure saslauthd, edit the /etc/default/saslauthd configuration file and set: start=yes next, to make exim4 use the saslauthd service, the debian-exim user needs to be part of the sasl group: exim4 is now configured with smtp-auth using tls and sasl authentication. references • see exim.org for more information. • there is also an exim4 book available. • another resource is the exim4 ubuntu wiki page. • further resources to set up mailman3 with exim4 email services the process of getting an email from one person to another over a network or the internet involves many systems working together. each of these systems must be correctly configured for the process to work. the sender uses a mail user agent (mua), or email client, to send the message through one or more mail transfer agents (mta), the last of which will hand it off to a mail delivery agent (mda) for delivery to the recipient’s mailbox, from which it will be retrieved by the recipient’s email client, usually via a pop3 or imap server. mailman mailman is an open source program for managing electronic mail discussions and e-newsletter lists. many open source mailing lists (including all the ubuntu mailing lists) use mailman as their mailing list software. it is powerful and easy to install and maintain. installation mailman provides a web interface for the administrators and users, using an external mail server to send and receive emails. it works perfectly with the following mail servers: • postfix • exim 240

241

• sendmail • qmail we will see how to install and configure mailman with, the apache web server, and either the postfix or exim mail server. if you wish to install mailman with a different mail server, please refer to the references section. note you only need to install one mail server and postfix is the default ubuntu mail transfer agent. apache2 to install apache2 you refer to ??? for details. postfix for instructions on installing and configuring postfix refer to postfix exim4 to install exim4 refer to exim4. once exim4 is installed, the configuration files are stored in the /etc/exim4 directory. in ubuntu, by default, the exim4 configuration files are split across different files. you can change this behavior by changing the following variable in the /etc/exim4/update−exim4.conf file: dc_use_split_config =’true ’ mailman to install mailman, run following command at a terminal prompt: sudo apt i n s t a l l mailman it copies the installation files in /var/lib/mailman directory. it installs the cgi scripts in /usr/lib/cgi- bin/mailman directory. it creates list linux user. it creates the list linux group. the mailman process will be owned by this user. configuration this section assumes you have successfully installed mailman, apache2, and postfix or exim4. now you just need to configure them. apache2 an example apache configuration file comes with mailman and is placed in /etc/mailman/apache.conf. in order for apache to use the config file it needs to be copied to /etc/apache2/sites−available: sudo cp / etc /mailman/apache . conf / etc /apache2/ s i t e s−a v a i l a b l e /mailman . conf this will setup a new apache virtualhost for the mailman administration site. now enable the new config- uration and restart apache: 241

242

sudo a 2 e n s i t e mailman . conf sudo systemctl r e s t a r t apache2 . s e r v i c e mailman uses apache2 to render its cgi scripts. the mailman cgi scripts are installed in the /usr/lib/cgi- bin/mailman directory. so, the mailman url will be http://hostname/cgi-bin/mailman/. you can make changes to the /etc/apache2/sites−available/mailman.conf file if you wish to change this behavior. postfix for postfix integration, we will associate the domain lists .example.com with the mailing lists. please replace lists .example.com with the domain of your choosing. you can use the postconf command to add the necessary configuration to /etc/postfix/main.cf: ’ relay_domains = l i s t s . example . com ’ ’ transport_maps = hash :/ etc / p o s t f i x / transport ’ ’ mailman_destination_recipient_limit = 1 ’ sudo postconf−e sudo postconf−e sudo postconf−e unix − f l a g s=fr user=l i s t argv=/usr / l i b /mailman/ bin / postfix−to−mailman . py in /etc/postfix/master.cf double check that you have the following transport: mailman ${nexthop} ${ user } it calls the postfix-to-mailman.py script when a mail is delivered to a list. associate the domain lists .example.com to the mailman transport with the transport map. edit the file /etc/postfix/transport: l i s t s . example . com mailman : − n n pipe − now have postfix build the transport map by entering the following from a terminal prompt: sudo postmap−v / etc / p o s t f i x / transport then restart postfix to enable the new configurations: sudo systemctl r e s t a r t p o s t f i x . s e r v i c e exim4 once exim4 is installed, you can start the exim server using the following command from a terminal prompt: sudo systemctl s t a r t exim4 . s e r v i c e in order to make mailman work with exim4, you need to configure exim4. as mentioned earlier, by default, exim4 uses multiple configuration files of different types. for details, please refer to the exim web site. to run mailman, we should add new a configuration file to the following configuration types: • main • transport • router exim creates a master configuration file by sorting all these mini configuration files. so, the order of these configuration files is very important. 242

243

all the configuration files belonging to the main type are stored in the /etc/exim4/conf.d/main/ directory. main s c r i p t . value i s normally ”mailman” should be ”/ var / l i b /mailman” i s normally the same as ~mailman you can add the following content to a new file, named 04_exim4−config_mailman: f o r your mailman i n s t a l l a t i o n−− aka mailman ’ s p r e f i x should match your−−with−mail−gid # s t a r t # home d i r # d i r e c t o r y . # on ubuntu t h i s # this mm_home=/var / l i b /mailman # # user and group f o r mailman , # switch to mailman ’ s c o n f i g u r e mm_uid=l i s t mm_gid=l i s t # # domains that your # you may wish to add these into local_domains as well domainlist mm_domains=hostname . com # l i s t s are in− colon separated l i s t #−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−=−= # # these values are derived from the ones above and should not need # e d i t i n g unless you have munged your mailman i n s t a l l a t i o n # # the path of mm_wrap=mm_home/ mail /mailman # # the path of # v e r i f y i n g l i s t addresses ) mm_listchk=mm_home/ l i s t s /${ l c : : $local_part }/ c o n f i g . pck # end ( used as a required f i l e when the mailman mail wrapper c o n f i g f i l e s c r i p t l i s t the transport all the configuration files belonging to transport type are stored in the /etc/exim4/conf.d/transport/ direc- tory. you can add the following content to a new file named 40_exim4−config_mailman: mailman_transport : d r i v e r = pipe command = mm_wrap \ ’ ${ i f def : local_part_suffix \ {${ sg { $local_part_suffix }{−(\\w+)(\\+.*) ?}{\ $1}}} \ { post }} ’ \ $local_part current_directory = mm_home home_directory = mm_home user = mm_uid group = mm_gid 243

244

all the configuration files belonging to router type are stored in the /etc/exim4/conf.d/router/ directory. router mailman_router : d r i v e r = accept r e q u i r e _ f i l e s = mm_home/ l i s t s / $local_part / c o n f i g . pck local_part_suffix_optional you can add the following content in to a new file named 101_exim4−config_mailman: :−bounces+* : \ local_part_suffix =−bounces −confirm+* :−j o i n :−leave :−request :−admin −owner transport = mailman_transport : \ warning the order of main and transport configuration files can be in any order. but, the order of router configuration files must be the same. this particular file must appear before the 200_exim4- config_primary file. these two configuration files contain same type of information. the first file takes the precedence. for more details, please refer to the references section. mailman once mailman is installed, you can run it using the following command: sudo systemctl s t a r t mailman . s e r v i c e once mailman is installed, you should create the default mailing list. run the following command to create the mailing list: sudo / usr / sbin / n e w l i s t mailman enter the email address of i n i t i a l mailman password : to f i n i s h c r e a t i n g your mailing l i s t , you must e d i t your / etc / a l i a s e s equivalent ) ‘ newaliases ’ program : ( or f i l e by adding the f o l l o w i n g l i n e s , and p o s s i b l y running the the person running the l i s t : bhuvan at ubuntu . com ”|/ var / l i b /mailman/ mail /mailman post mailman” ”|/ var / l i b /mailman/ mail /mailman admin mailman” ”|/ var / l i b /mailman/ mail /mailman bounces mailman” ”|/ var / l i b /mailman/ mail /mailman confirm mailman” ”|/ var / l i b /mailman/ mail /mailman j o i n mailman” ”|/ var / l i b /mailman/ mail /mailman leave mailman” ”|/ var / l i b /mailman/ mail /mailman owner mailman” ”|/ var / l i b /mailman/ mail /mailman request mailman” ”|/ var / l i b /mailman/ mail /mailman subscribe mailman” ”|/ var / l i b /mailman/ mail /mailman unsubscribe mailman” ## mailman mailing l i s t mailman : mailman−admin : mailman−bounces : mailman−confirm : mailman−j o i n : mailman−leave : mailman−owner : mailman−request : mailman−subscribe : mailman−unsubscribe : hit enter to n o t i f y mailman owner . . . # 244

245

we have configured either postfix or exim4 to recognize all emails from mailman. so, it is not mandatory to make any new entries in /etc/ aliases . if you have made any changes to the configuration files, please ensure that you restart those services before continuing to next section. note the exim4 does not use the above aliases to forward mails to mailman, as it uses a discover approach. to suppress the aliases while creating the list, you can add mta=none line in mailman configuration file, /etc/mailman/mm_cfg.py. administration we assume you have a default installation. the mailman cgi scripts are still in the /usr/lib/cgi-bin/mailman/ directory. mailman provides a web based administration facility. to access this page, point your browser to the following url: http://hostname/cgi-bin/mailman/admin the default mailing list, mailman, will appear in this screen. if you click the mailing list name, it will ask for your authentication password. if you enter the correct password, you will be able to change administrative settings of this mailing list. you can create a new mailing list using the command line utility (/usr/sbin/ newlist). alternatively, you can create a new mailing list using the web interface. users mailman provides a web based interface for users. to access this page, point your browser to the following url: http://hostname/cgi-bin/mailman/listinfo the default mailing list, mailman, will appear in this screen. if you click the mailing list name, it will display the subscription form. you can enter your email address, name (optional), and password to subscribe. an email invitation will be sent to you. you can follow the instructions in the email to subscribe. references gnu mailman - installation manual howto - using exim 4 and mailman 2.1 together also, see the mailman ubuntu wiki page. mail filtering one of the largest issues with email today is the problem of unsolicited bulk email (ube). also known as spam, such messages may also carry viruses and other forms of malware. according to some reports these messages make up the bulk of all email traffic on the internet. this section will cover integrating amavisd-new, spamassassin, and clamav with the postfix mail transport agent (mta). postfix can also check email validity by passing it through external content filters. these filters can sometimes determine if a message is spam without needing to process it with more resource intensive applications. two common filters are opendkim and python-policyd-spf. • amavisd-new is a wrapper program that can call any number of content filtering programs for spam detection, antivirus, etc. 245

246

• spamassassin uses a variety of mechanisms to filter email based on the message content. • clamav is an open source antivirus application. • opendkim implements a sendmail mail filter (milter) for the domainkeys identified mail (dkim) standard. • python-policyd-spf enables sender policy framework (spf) checking with postfix. this is how the pieces fit together: • an email message is accepted by postfix. • the message is passed through any external filters opendkim and python-policyd-spf in this case. • amavisd-new then processes the message. • clamav is used to scan the message. if the message contains a virus postfix will reject the message. • clean messages will then be analyzed by spamassassin to find out if the message is spam. spamassassin will then add x-header lines allowing amavisd-new to further manipulate the message. for example, if a message has a spam score of over fifty the message could be automatically dropped from the queue without the recipient ever having to be bothered. another, way to handle flagged messages is to deliver them to the mail user agent (mua) allowing the user to deal with the message as they see fit. installation see postfix for instructions on installing and configuring postfix. to install the rest of the applications enter the following from a terminal prompt: sudo apt sudo apt i n s t a l l amavisd−new spamassassin clamav−daemon i n s t a l l opendkim postfix−policyd−spf−python razor there are some optional packages that integrate with spamassassin for better spam detection: sudo apt i n s t a l l pyzor along with the main filtering applications compression utilities are needed to process some email attachments: sudo apt i n s t a l l a r j cabextract cpio lha nomarch pax rar unrar unzip zip note if some packages are not found, check that the multiverse repository is enabled in /etc/apt/ sources. list if you make changes to the file, be sure to run sudo apt update before trying to install again. configuration now configure everything to work together and filter email. clamav the default behaviour of clamav will fit our needs. for more clamav configuration options, check the configuration files in /etc/clamav. add the clamav user to the amavis group in order for amavisd-new to have the appropriate access to scan files: 246

247

sudo adduser clamav amavis sudo adduser amavis clamav spamassassin spamassassin automatically detects optional components and will use them if they are present. this means that there is no need to configure pyzor and razor. edit /etc/default/spamassassin to activate the spamassassin daemon. change enabled=0 to: enabled=1 now start the daemon: sudo systemctl s t a r t spamassassin . s e r v i c e s t r i c t ; amavisd-new content_filter_mode: use first activate spam and antivirus detection in amavisd-new by editing /etc/amavis/conf.d/15− to re−enable spam checking through spamassassin # and to re−enable a n t i v i r u s checking . # you can modify t h i s f i l e # # default a n t i v i r u s checking mode # uncomment the two l i n e s below to enable # i t @bypass_virus_checks_maps = ( \%bypass_virus_checks , \@bypass_virus_checks_acl , \ $bypass_virus_checks_re ) ; # # default spam checking mode # uncomment the two l i n e s below to enable # i t @bypass_spam_checks_maps = ( \%bypass_spam_checks , \@bypass_spam_checks_acl , \$bypass_spam_checks_re ) ; 1; # insure a defined return bouncing spam can be a bad idea as the return address is often faked. the default behaviour is to instead d_discard rather than d_bounce. additionally, you may want to adjust the following options to flag more messages as spam: discard. this is configured in /etc/amavis/conf.d/20−debian_defaults where $final_spam_destiny is set to $sa_tag_level_deflt =−999; # add spam i n f o headers $sa_tag2_level_deflt = 6 . 0 ; # add ’spam detected ’ headers at $ s a _ k i l l _ l e v e l _ d e f l t = 2 1 . 0 ; # t r i g g e r s spam evasive a c t i o n s $sa_dsn_cutoff_level = 4; # spam l e v e l beyond which a dsn i s not i f at , or above that l e v e l l e v e l that sent 247

248

if the server’s hostname is different from the domain’s mx record you may need to manually set the $my- hostname option. also, if the server receives mail for multiple domains the @local_domains_acl option will $myhostname = ’ mail . example . com ’ ; @local_domains_acl = ( ”example . com” , ” example . org ” ) ; need to be customized. edit the /etc/amavis/conf.d/50−user file: if you want to cover multiple domains you can use the following in the/etc/amavis/conf.d/50−user @local_domains_acl = qw ( . ) ; after configuration amavisd-new needs to be restarted: sudo systemctl r e s t a r t amavis . s e r v i c e dkim whitelist amavisd-new can be configured to automatically whitelist addresses from domains with valid domain keys. there are some pre-configured domains in the /etc/amavis/conf.d/40−policy_banks. there are multiple ways to configure the whitelist for a domain: • ‘example.com’ => ‘whitelist’,: will whitelist any address from the “example.com” domain. • ‘.example.com’ => ‘whitelist’,: will whitelist any address from any subdomains of “example.com” that have a valid signature. • ‘.example.com/@example.com’ => ‘whitelist’,: will whitelist subdomains of “example.com” that use the signature of example.com the parent domain. • ‘./@example.com’ => ‘whitelist’,: adds addresses that have a valid signature from “example.com”. this is usually used for discussion groups that sign their messages. a domain can also have multiple whitelist configurations. after editing the file, restart amavisd-new: sudo systemctl r e s t a r t amavis . s e r v i c e note in this context, once a domain has been added to the whitelist the message will not receive any anti-virus or spam filtering. this may or may not be the intended behavior you wish for a domain. postfix for postfix integration, enter the following from a terminal prompt: ’ c o n t e n t _ f i l t e r = smtp−amavis : [ 1 2 7 . 0 . 0 . 1 ] : 1 0 0 2 4 ’ next edit /etc/postfix/master.cf and add the following to the end of the file: 2 unix sudo postconf−e − − smtp−amavis − −o smtp_data_done_timeout=1200 −o smtp_send_xforward_command=yes −o disable_dns_lookups=yes −o max_use=20 − − −o c o n t e n t _ f i l t e r= −o local_recipient_maps= −o relay_recipient_maps= 1 2 7 . 0 . 0 . 1 : 1 0 0 2 5 i n e t n 248 − − smtp smtpd −

249

−o smtpd_restriction_classes= −o smtpd_delay_reject=no −o smtpd_client_restrictions=permit_mynetworks , r e j e c t −o smtpd_helo_restrictions= −o smtpd_sender_restrictions= −o smtpd_recipient_restrictions=permit_mynetworks , r e j e c t −o smtpd_data_restrictions=reject_unauth_pipelining −o smtpd_end_of_data_restrictions= −o mynetworks =127.0.0.0/8 −o smtpd_error_sleep_time=0 −o smtpd_soft_error_limit =1001 −o smtpd_hard_error_limit=1000 −o smtpd_client_connection_count_limit=0 −o smtpd_client_connection_rate_limit=0 −o receive_override_options=no_header_body_checks , −o c o n t e n t _ f i l t e r= −o receive_override_options=no_header_body_checks no_unknown_recipient_checks , no_milters also add the following two lines immediately below the “pickup” transport service: this will prevent messages that are generated to report on spam from being classified as spam. now restart postfix: sudo systemctl r e s t a r t p o s t f i x . s e r v i c e content filtering with spam and virus detection is now enabled. amavisd-new and spamassassin when integrating amavisd-new with spamassassin, if you choose to disable the bayes filtering by editing /etc/spamassassin/local.cf and use cron to update the nightly rules, the result can cause a situation where a large amount of error messages are sent to the amavis user via the amavisd-new cron job. there are several ways to handle this situation: • configure your mda to filter messages you do not wish to see. • change /usr/sbin/amavisd−new−cronjob to check for use_bayes 0. for example, edit /usr/sbin/ amavisd−new−cronjob and add the following to the top before the test statements: egrep−q ”^[ \ t ]* use_bayes [ \ t ]*0” / etc / spamassassin / l o c a l . c f && e x i t 0 testing l o c a l h o s t 10024 first, test that the amavisd-new smtp is listening: t e l n e t trying 1 2 7 . 0 . 0 . 1 . . . connected to l o c a l h o s t . escape character 220 [ 1 2 7 . 0 . 0 . 1 ] esmtp amavisd−new s e r v i c e ready ^] i s ’ ^ ] ’ . 249

250

in the header of messages that go through the content filter you should see: bayes_00 x−spam−level : x−virus−scanned : debian amavisd−new at example . com x−spam−status : no, h i t s =−2.3 tagged_above=−1000.0 required =5.0 t e s t s=awl, x−spam−level : note your output will vary, but the important thing is that there are x-virus-scanned and x-spam- status entries. troubleshooting the best way to figure out why something is going wrong is to check the log files. • for instructions on postfix logging see the troubleshooting section. • amavisd-new uses syslog to send messages to /var/log/mail.log. the amount of detail can be increased by adding the $log_level option to /etc/amavis/conf.d/50−user, and setting the value from 1 to 5. $log_level = 2; note when the amavisd-new log output is increased spamassassin log output is also increased. • the clamav log level can be increased by editing /etc/clamav/clamd.conf and setting the following option: logverbose true by default clamav will send log messages to /var/log/clamav/clamav.log. note after changing an applications log settings remember to restart the service for the new settings to take affect. also, once the issue you are troubleshooting is resolved it is a good idea to change the log settings back to normal. references for more information on filtering mail see the following links: • amavisd-new documentation • clamav documentation and clamav wiki • spamassassin wiki • pyzor homepage • razor homepage • dkim.org • postfix amavis new also, feel free to ask questions in the #ubuntu-server irc channel on freenode. 250

251

postfix postfix is the default mail transfer agent (mta) in ubuntu. it attempts to be fast and secure, with flexibility in administration. it is compatible with the mta sendmail. this section will explain installation, including how to configure smtp for secure communications. note this guide does not cover setting up postfix virtual domains, for information on virtual domains and other advanced configurations see references. installation to install postfix run the following command: sudo apt i n s t a l l p o s t f i x for now, it is ok to simply accept defaults by pressing return for each question. some of the configuration options will be investigated in greater detail in the next stage. deprecation warning: please note that the mail−stack−delivery metapackage has been dep- recated in focal. the package still exists for compatibility reasons, but won’t setup a working email system. basic configuration there are four things you should decide before starting configuration: - the <domain> for which you’ll accept email (we’ll use mail.example.com in our example) - the network and class range of your mail server (we’ll use 192.168.0.0/24) - the username (we’re using steve) - type of mailbox format (mbox is default, we’ll use the alternative, maildir) to configure postfix, run the following command: sudo dpkg−r e c o n f i g u r e p o s t f i x the user interface will be displayed. on each screen, select the following values: • internet site • mail.example.com • steve • mail.example.com, localhost.localdomain, localhost • no • 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 192.168.0.0/24 • 0 • + • all to set the mailbox format, you can either edit the configuration file directly, or use the postconf command. in either case, the configuration parameters will be stored in /etc/postfix/main.cf file. later if you wish to re-configure a particular parameter, you can either run the command or change it manually in the file. to configure the mailbox format for maildir: sudo postconf−e ’ home_mailbox = maildir / ’ 251

252

note this will place new mail in /home/username/maildir so you will need to configure your mail delivery agent (mda) to use the same path. smtp authentication smtp-auth allows a client to identify itself through the sasl authentication mechanism, using transport layer security (tls) to encrypt the authentication process. once authenticated the smtp server will allow the client to relay mail. to configure postfix for smtp-auth using sasl (dovecot sasl), run these commands at a terminal prompt: sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e ’ smtpd_sasl_type = dovecot ’ ’ smtpd_sasl_path = private /auth ’ ’ smtpd_sasl_local_domain =’ ’ smtpd_sasl_security_options = noanonymous , noplaintext ’ ’ smtpd_sasl_tls_security_options = noanonymous ’ ’ broken_sasl_auth_clients = yes ’ ’ smtpd_sasl_auth_enable = yes ’ ’ smtpd_recipient_restrictions = \ permit_sasl_authenticated , permit_mynetworks , reject_unauth_destination ’ note the smtpd_sasl_path config parameter is a path relative to the postfix queue directory. there are several sasl mechanism properties worth evaluating to improve the security of your deployment. the options “noanonymous,noplaintext” prevent use of mechanisms that permit anonymous authentication or that transmit credentials unencrypted. next, generate or obtain a digital certificate for tls. see security - certificates in this guide for details about generating digital certificates and setting up your own certificate authority (ca). note muas connecting to your mail server via tls will need to recognize the certificate used for tls. this can either be done using a certificate from let’s encrypt, from a commercial ca or with a self-signed certificate that users manually install/accept. for mta to mta tls certficates are never validated without advance agreement from the affected organizations. for mta to mta tls, unless local policy requires it, there is no reason not to use a self-signed certificate. refer to security - certificates in this guide for more details. once you have a certificate, configure postfix to provide tls encryption for both incoming and outgoing mail: sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e sudo postconf−e ’ smtp_tls_security_level = may’ ’ smtpd_tls_security_level = may’ ’ smtp_tls_note_starttls_offer = yes ’ ’ smtpd_tls_key_file = / etc / s s l / private / s e r v e r . key ’ ’ smtpd_tls_cert_file = / etc / s s l / c e r t s / s e r v e r . crt ’ ’ smtpd_tls_loglevel = 1 ’ ’ smtpd_tls_received_header = yes ’ ’ myhostname = mail . example . com ’ if you are using your own certificate authority to sign the certificate enter: ’ smtpd_tls_cafile = / etc / s s l / c e r t s / cacert . pem ’ 252

253

again, for more details about certificates see security - certificates in this guide. note after running all the commands, postfix is configured for smtp-auth and a self-signed certifi- cate has been created for tls encryption. now, the file /etc/postfix/main.cf should look like this: # see / usr / share / p o s t f i x /main . c f . d i s t # version f o r a commented , more complete smtpd_banner = $myhostname esmtp $mail_name (ubuntu) b i f f = no # appending . domain i s append_dot_mydomain = no the mua’ s job . # uncomment the next #delay_warning_time = 4h l i n e to generate ” delayed mail ” warnings l o c a l h o s t . example . com , l o c a l h o s t myhostname = server1 . example . com alias_maps = hash :/ etc / a l i a s e s alias_database = hash :/ etc / a l i a s e s myorigin = / etc /mailname mydestination = server1 . example . com , r e l a yh o s t = mynetworks = 1 2 7 . 0 . 0 . 0 / 8 mailbox_command = procmail−a ”$extension” mailbox_size_limit = 0 r e c i p i e n t _ d e l i m i t e r = + i n e t _ i n t e r f a c e s = a l l smtpd_sasl_local_domain = smtpd_sasl_auth_enable = yes smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes smtpd_recipient_restrictions = permit_sasl_authenticated , permit_mynetworks , r e j e c t _unauth_destination smtpd_tls_auth_only = no smtp_tls_security_level = may smtpd_tls_security_level = may smtp_tls_note_starttls_offer = yes smtpd_tls_key_file = / etc / s s l / private /smtpd . key smtpd_tls_cert_file = / etc / s s l / c e r t s /smtpd . c r t smtpd_tls_cafile = / etc / s s l / c e r t s / cacert . pem smtpd_tls_loglevel = 1 smtpd_tls_received_header = yes smtpd_tls_session_cache_timeout = 3600 s tls_random_source = dev :/ dev/urandom the postfix initial configuration is complete. run the following command to restart the postfix daemon: sudo systemctl r e s t a r t p o s t f i x . s e r v i c e postfix supports smtp-auth as defined in rfc2554. it is based on sasl. however it is still necessary to set up sasl authentication before you can use smtp-auth. 253

254

when using ipv6, the mynetworks parameter may need to be modified to allow ipv6 addresses, for example: mynetworks = 1 2 7 . 0 . 0 . 0 / 8 , [ : : 1 ] / 1 2 8 configuring sasl postfix supports two sasl implementations: cyrus sasl and dovecot sasl. to enable dovecot sasl the dovecot-core package will need to be installed: sudo apt i n s t a l l dovecot−core to t h i s userdb socket by d e f a u l t . etc . t y p i c a l l y it ’ s i t s d e f a u l t readable only by root , but you may need to r e l a x these that have access socket are able to get a l i s t to t h i s r e s u l t s of everyone ’ s userdb lookups . to permit use of smtp-auth by outlook clients, change the following line in the authentication mechanisms s e r v i c e auth { # auth_socket_path points #mode = 0600 #user = #group = # permissions make i t # permissions . users # of a l l usernames and get next, edit /etc/dovecot/conf.d/10−master.conf and change the following: # used by dovecot−lda , doveadm , p o s s i b l y imap process , unix_listener auth−userdb { # postfix smtp−auth section of /etc/dovecot/conf.d/10−auth.conf from: unix_listener / var / spool / p o s t f i x / private /auth { mode = 0660 user = p o s t f i x group = p o s t f i x auth_mechanisms = plain } } to this: auth_mechanisms = plain l o g i n once you have dovecot configured, restart it with: sudo systemctl r e s t a r t dovecot . s e r v i c e testing smtp-auth configuration is complete. now it is time to test the setup. to see if smtp-auth and tls work properly, run the following command: t e l n e t mail . example . com 25 after you have established the connection to the postfix mail server, type: ehlo mail . example . com 254

255

if you see the following in the output, then everything is working perfectly. type quit to exit. 250−starttls 250−auth login plain 250−auth=login plain 250 8bitmime troubleshooting when problems arise, there are a few common ways to diagnose the cause. escaping chroot the ubuntu postfix package will by default install into a chroot environment for security reasons. this can add greater complexity when troubleshooting problems. to turn off the chroot usage, locate the following line in the /etc/postfix/master.cf configuration file: smtp smtpd i n e t n and modify it as follows: n smtp i n e t − n − − − − − − smtpd you will then need to restart postfix to use the new configuration. from a terminal prompt enter: sudo s e r v i c e p o s t f i x r e s t a r t smtps n i n e t if you need secure smtp, edit /etc/postfix/master.cf and uncomment the following line: smtps − − −o smtpd_tls_wrappermode=yes −o smtpd_sasl_auth_enable=yes −o smtpd_client_restrictions=permit_sasl_authenticated , r e j e c t −o milter_macro_daemon_name=originating − − smtpd log viewing postfix sends all log messages to /var/log/mail.log. however, error and warning messages can sometimes get lost in the normal log output so they are also logged to /var/log/mail.err and /var/log/mail.warn respectively. to see messages entered into the logs in real time you can use the tail -f command: t a i l −f / var / log / mail . e r r 255

256

the amount of detail that is recorded in the logs can be increased via the configuration options. for example, to increase tls activity logging set the smtpd_tls_loglevel option to a value from 1 to 4. ’ smtpd_tls_loglevel = 4 ’ reload the service after any configuration change, to make the new config active: sudo systemctl reload p o s t f i x . s e r v i c e increasing logging detail sudo postconf−e logging mail delivery sudo postconf−e sudo systemctl increasing daemon verbosity if you are having trouble sending or receiving mail from a specific domain you can add the domain to the debug_peer_list parameter. ’ debug_peer_list = problem . domain ’ reload p o s t f i x . s e r v i c e you can increase the verbosity of any postfix daemon process by editing the /etc/postfix/master.cf and adding a -v after the entry. for example, edit the smtp entry: smtp unix − − − − then, reload the service as usual: sudo systemctl reload p o s t f i x . s e r v i c e − smtp−v to increase the amount of information logged when troubleshooting sasl issues you can set the following logging sasl debug info options in /etc/dovecot/conf.d/10−logging.conf auth_debug=yes auth_debug_passwords=yes just like postfix if you change a dovecot configuration the process will need to be reloaded: sudo systemctl reload dovecot . s e r v i c e note some of the options above can drastically increase the amount of information sent to the log files. remember to return the log level back to normal after you have corrected the problem. then reload the appropriate daemon for the new configuration to take affect. references administering a postfix server can be a very complicated task. at some point you may need to turn to the ubuntu community for more experienced help. • the postfix website documents all available configuration options. • o’reilly’s postfix: the definitive guide is rather dated but provides deep background information about configuration options. 256

257

• the ubuntu wiki postfix page has more information from a ubuntu context. there is also a debian wiki postfix page that’s a bit more up to date; they also have a set of postfix tutorials for different debian versions. • info on how to set up mailman3 with postfix 429 from api, waiting 5 seconds … (‘you’ve performed this action too many times. please wait a few seconds before trying again.’) # squid squid is a full-featured web proxy cache server application which provides proxy and cache services for hyper text transport protocol (http), file transfer protocol (ftp), and other popular network protocols. squid can implement caching and proxying of secure sockets layer (ssl) requests and caching of domain name server (dns) lookups, and perform transparent caching. squid also supports a wide variety of caching protocols, such as internet cache protocol (icp), the hyper text caching protocol (htcp), the cache array routing protocol (carp), and the web cache coordination protocol (wccp). the squid proxy cache server is an excellent solution to a variety of proxy and caching server needs, and scales from the branch office to enterprise level networks while providing extensive, granular access control mechanisms, and monitoring of critical parameters via the simple network management protocol (snmp). when selecting a computer system for use as a dedicated squid caching proxy server for many users ensure it is configured with a large amount of physical memory as squid maintains an in-memory cache for increased performance. installation at a terminal prompt, enter the following command to install the squid server: sudo apt i n s t a l l squid configuration squid is configured by editing the directives contained within the /etc/squid/squid.conf configuration file. the following examples illustrate some of the directives which may be modified to affect the behavior of the squid server. for more in-depth configuration of squid, see the references section. tip prior to editing the configuration file, you should make a copy of the original file and protect it from writing so you will have the original settings as a reference, and to re-use as necessary. make this copy and protect it from writing using the following commands: sudo cp / etc / squid / squid . conf / etc / squid / squid . conf . o r i g i n a l sudo chmod a−w / etc / squid / squid . conf . o r i g i n a l • to set your squid server to listen on tcp port 8888 instead of the default tcp port 3128, change the http_port directive as such: http_port 8888 • change the visible_hostname directive in order to give the squid server a specific hostname. this hostname does not necessarily need to be the computer’s hostname. in this example it is set to weezie visible_hostname weezie • the cache_dir option allows one to configure an on-disk cache, the default option is on-memory cache. the cache_dir directive takes the following arguments: cache_dir <type> <directory−name> <fs−s p e c i f i c−data> [ options ] 257

258

in the config file you can find the default cache_dir directive commented out: # uncomment and adjust #cache_dir ufs / var / spool / squid 100 16 256 the f o l l o w i n g to add a disk cache d i r e c t o r y . you can just use the default option but you can also customize your cache directory, basically changing the <type> of this directory, it can be: – ufs: the old well-known squid storage format that has always been there. – aufs: uses the same storage format as ufs, utilizing posix-threads to avoid blocking the main squid process on disk-i/o. this was formerly known in squid as async−io. – diskd: uses the same storage format as ufs, utilizing a separate process to avoid blocking the main squid process on disk-i/o. – rock: is a database-style storage. all cached entries are stored in a “database” file, using fixed-size slots. a single entry occupies one or more slots. if you want to use a different directory type please take a look at their different options. • using squid’s access control, you may configure use of internet services proxied by squid to be available only users with certain internet protocol (ip) addresses. for example, we will illustrate access by users of the 192.168.42.0/24 subnetwork only: add the following to the bottom of the acl section of your /etc/squid/squid.conf file: a c l fortytwo_network s r c 192.168.42.0/24 then, add the following to the top of the http_access section of your /etc/squid/squid.conf file: http_access allow fortytwo_network • using the excellent access control features of squid, you may configure use of internet services proxied by squid to be available only during normal business hours. for example, we’ll illustrate access by employees of a business which is operating between 9:00am and 5:00pm, monday through friday, and which uses the 10.1.42.0/24 subnetwork: add the following to the bottom of the acl section of your /etc/squid/squid.conf file: a c l biz_network s r c 1 0 . 1 . 4 2 . 0 / 2 4 a c l biz_hours time m t w t f 9:00−17:00 then, add the following to the top of the http_access section of your /etc/squid/squid.conf file: http_access allow biz_network biz_hours note after making changes to the /etc/squid/squid.conf file, save the file and restart the squid server application to effect the changes using the following command entered at a terminal prompt: sudo systemctl squid . s e r v i c e r e s t a r t note if formerly a customized squid3 was used that set up the spool at /var/log/squid3 to be a mountpoint, but otherwise kept the default configuration the upgrade will fail. the upgrade tries to rename/move files as needed, but it can’t do so for an active mountpoint. in that case please either adapt the mountpoint or the config in /etc/squid/squid.conf so that they match. the same applies if the include config statement was used to pull in more files from the old path at /etc/squid3/. in those cases you should move and adapt your configuration accordingly. 258

259

references squid website ubuntu wiki squid page. httpd - apache2 web server apache is the most commonly used web server on linux systems. web servers are used to serve web pages requested by client computers. clients typically request and view web pages using web browser applications such as firefox, opera, chromium, or internet explorer. users enter a uniform resource locator (url) to point to a web server by means of its fully qualified domain name (fqdn) and a path to the required resource. for example, to view the home page of the ubuntu web site a user will enter only the fqdn: www. ubuntu . com to view the community sub-page, a user will enter the fqdn followed by a path: www. ubuntu . com/community the most common protocol used to transfer web pages is the hyper text transfer protocol (http). proto- cols such as hyper text transfer protocol over secure sockets layer (https), and file transfer protocol (ftp), a protocol for uploading and downloading files, are also supported. apache web servers are often used in combination with the mysql database engine, the hypertext pre- processor (php) scripting language, and other popular scripting languages such as python and perl. this configuration is termed lamp (linux, apache, mysql and perl/python/php) and forms a powerful and robust platform for the development and deployment of web-based applications. installation the apache2 web server is available in ubuntu linux. to install apache2: at a terminal prompt enter the following command: sudo apt i n s t a l l apache2 configuration apache2 is configured by placing directives in plain text configuration files. these directives are separated between the following files and directories: • apache2.conf: the main apache2 configuration file. contains settings that are global to apache2. • httpd.conf: historically the main apache2 configuration file, named after the httpd daemon. in other distributions (or older versions of ubuntu), the file might be present. in ubuntu, all configuration options have been moved to apache2.conf and the below referenced directories, and this file no longer exists. • conf-available: this directory contains available configuration files. all files that were previously in /etc/apache2/conf.d should be moved to /etc/apache2/conf−available. • conf-enabled: holds symlinks to the files in /etc/apache2/conf−available. when a configuration file is symlinked, it will be enabled the next time apache2 is restarted. 259

260

not all modules will have specific configuration files, however. • envvars: file where apache2 environment variables are set. • mods-available: this directory contains configuration files to both load modules and configure them. tion file is symlinked it will be enabled the next time apache2 is restarted. • ports.conf: houses the directives that determine which tcp ports apache2 is listening on. • sites-available: this directory has configuration files for apache2 virtual hosts. virtual hosts allow • mods-enabled: holds symlinks to the files in /etc/apache2/mods−available. when a module configura- • sites-enabled: like mods-enabled, sites−enabled contains symlinks to the /etc/apache2/sites−available directory. similarly when a configuration file in sites-available is symlinked, the site configured by it will be active once apache2 is restarted. apache2 to be configured for multiple sites that have separate configurations. • magic: instructions for determining mime type based on the first few bytes of a file. in addition, other configuration files may be added using the include directive, and wildcards can be used to include many configuration files. any directive may be placed in any of these configuration files. changes to the main configuration files are only recognized by apache2 when it is started or restarted. the server also reads a file containing mime document types; the filename is set by the typesconfig directive, typically via /etc/apache2/mods−available/mime.conf, which might also include additions and overrides, and is /etc/mime.types by default. basic settings this section explains apache2 server essential configuration parameters. refer to the apache2 documenta- tion for more details. • apache2 ships with a virtual-host-friendly default configuration. that is, it is configured with a single default virtual host (using the virtualhost directive) which can be modified or used as-is if you have a single site, or used as a template for additional virtual hosts if you have multiple sites. if left alone, the default virtual host will serve as your default site, or the site users will see if the url they enter does not match the servername directive of any of your custom sites. to modify the default virtual host, edit the file /etc/apache2/sites−available/000−default.conf. note the directives set for a virtual host only apply to that particular virtual host. if a directive is set server-wide and not defined within the virtual host settings, the default setting is used. for example, you can define a webmaster email address and not define individual email addresses for each virtual host. if you wish to configure a new virtual host or site, copy that file into the same directory with a name you choose. for example: sudo cp / etc /apache2/ s i t e s−a v a i l a b l e /000− d e f a u l t . conf / etc /apache2/ s i t e s− a v a i l a b l e /mynewsite . conf edit the new file to configure the new site using some of the directives described below. • the serveradmin directive specifies the email address to be advertised for the server’s administrator. the default value is webmaster@localhost. this should be changed to an email address that is delivered to you (if you are the server’s administrator). if your website has a problem, apache2 will display an error message containing this email address to report the problem to. find this directive in your site’s configuration file in /etc/apache2/sites-available. 260

261

• the listen directive specifies the port, and optionally the ip address, apache2 should listen on. if the ip address is not specified, apache2 will listen on all ip addresses assigned to the machine it runs on. the default value for the listen directive is 80. change this to 127.0.0.1:80 to cause apache2 to listen only on your loopback interface so that it will not be available to the internet, to (for example) 81 to change the port that it listens on, or leave it as is for normal operation. this directive can be found and changed in its own file, /etc/apache2/ports.conf • the servername directive is optional and specifies what fqdn your site should answer to. the default virtual host has no servername directive specified, so it will respond to all requests that do not match a servername directive in another virtual host. if you have just acquired the domain name mynewsite .com and wish to host it on your ubuntu server, the value of the servername directive in your virtual host configuration file should be mynewsite.com. add this directive to the new virtual host file you created earlier (/etc/apache2/sites−available/mynewsite.conf). you may also want your site to respond to www.mynewsite.com, since many users will assume the www prefix is appropriate. use the serveralias directive for this. you may also use wildcards in the serveralias directive. for example, the following configuration will cause your site to respond to any domain request ending in .mynewsite.com. serveralias *. mynewsite . com • the documentroot directive specifies where apache2 should look for the files that make up the site. the default value is /var/www/html, as specified in /etc/apache2/sites−available/000−default.conf. if desired, change this value in your site’s virtual host file, and remember to create that directory if necessary! enable the new virtualhost using the a2ensite utility and restart apache2: sudo a 2 e n s i t e mynewsite sudo systemctl r e s t a r t apache2 . s e r v i c e note be sure to replace mynewsite with a more descriptive name for the virtualhost. one method is to name the file after the servername directive of the virtualhost. similarly, use the a2dissite utility to disable sites. this is can be useful when troubleshooting configuration problems with multiple virtualhosts: sudo a 2 d i s s i t e mynewsite sudo systemctl r e s t a r t apache2 . s e r v i c e default settings this section explains configuration of the apache2 server default settings. for example, if you add a virtual host, the settings you configure for the virtual host take precedence for that virtual host. for a directive not defined within the virtual host settings, the default value is used. • the directoryindex is the default page served by the server when a user requests an index of a directory by specifying a forward slash (/) at the end of the directory name. for example, when a user requests the page http://www.example.com/this_directory/, he or she will get either the directoryindex page if it exists, a server-generated directory list if it does not and the indexes option is specified, or a permission denied page if neither is true. the server will try to find one of the files listed in the directoryindex directive and will return the first one it finds. if it does not find any of these files and if options indexes is set for that directory, the server will generate and return a 261

262

list, in html format, of the subdirectories and files in the directory. the default value, found in /etc/ • the errordocument directive allows you to specify a file for apache2 to use for specific error events. for example, if a user requests a resource that does not exist, a 404 error will occur. by default, thus, if apache2 finds a file in a requested directory matching any of these names, the first will be displayed. apache2/mods−available/dir.conf is “index.html index.cgi index.pl index.php index.xhtml index.htm”. apache2 will simply return a http 404 return code. read /etc/apache2/conf−available/localized −error−pages.conf for detailed instructions for using errordocument, including locations of example to accept the default, specified in /etc/apache2/conf−available/other−vhosts−access−log.conf. you may also specify the file to which errors are logged, via the errorlog directive, whose default is /var/log /apache2/error.log. these are kept separate from the transfer logs to aid in troubleshooting problems with your apache2 server. you may also specify the loglevel (the default value is “warn”) and the logformat (see /etc/apache2/apache2.conf for the default value). files. • by default, the server writes the transfer log to the file /var/log/apache2/access.log. you can change this on a per-site basis in your virtual host configuration files with the customlog directive, or omit it • some options are specified on a per-directory basis rather than per-server. options is one of these directives. a directory stanza is enclosed in xml-like tags, like so: <directory / var /www/html/mynewsite> . . . </directory> the options directive within a directory stanza accepts one or more of the following values (among others), separated by spaces: – execcgi - allow execution of cgi scripts. cgi scripts are not executed if this option is not chosen. caution most files should not be executed as cgi scripts. this would be very dangerous. cgi scripts should kept in a directory separate from and outside your documentroot, and only this directory should have the execcgi option set. this is the default, and the default location for cgi scripts is /usr/lib/cgi−bin. files. see apache ssi documentation (ubuntu community) for more information. – includes - allow server-side includes. server-side includes allow an html file to include other – includesnoexec - allow server-side includes, but disable the #exec and #include commands in cgi scripts. – indexes - display a formatted list of the directory’s contents, if no directoryindex (such as index.html) exists in the requested directory. caution for security reasons, this should usually not be set, and certainly should not be set on your documentroot directory. enable this option carefully on a per-directory basis only if you are certain you want users to see the entire contents of the directory. – multiview - support content-negotiated multiviews; this option is disabled by default for security reasons. see the apache2 documentation on this option. – symlinksifownermatch - only follow symbolic links if the target file or directory has the same owner as the link. 262

263

apache2 settings this section explains some basic apache2 daemon configuration settings. lockfile - the lockfile directive sets the path to the lockfile used when the server is compiled with either use_fcntl_serialized_accept or use_flock_serialized_accept. it must be stored on the local disk. it should be left to the default value unless the logs directory is located on an nfs share. if this is the case, the default value should be changed to a location on the local disk and to a directory that is readable only by root. pidfile - the pidfile directive sets the file in which the server records its process id (pid). this file should only be readable by root. in most cases, it should be left to the default value. user - the user directive sets the userid used by the server to answer requests. this setting determines the server’s access. any files inaccessible to this user will also be inaccessible to your website’s visitors. the default value for user is “www-data”. warning unless you know exactly what you are doing, do not set the user directive to root. using root as the user will create large security holes for your web server. group - the group directive is similar to the user directive. group sets the group under which the server will answer requests. the default group is also “www-data”. apache2 modules apache2 is a modular server. this implies that only the most basic functionality is included in the core server. extended features are available through modules which can be loaded into apache2. by default, a base set of modules is included in the server at compile-time. if the server is compiled to use dynamically loaded modules, then modules can be compiled separately, and added at any time using the loadmodule directive. otherwise, apache2 must be recompiled to add or remove modules. ubuntu compiles apache2 to allow the dynamic loading of modules. configuration directives may be condi- tionally included on the presence of a particular module by enclosing them in an <ifmodule> block. you can install additional apache2 modules and use them with your web server. for example, run the following command at a terminal prompt to install the python 3 wsgi module: sudo apt i n s t a l l libapache2−mod−wsgi−py3 the installation will enable the module automatically, but we can disable it with a2dismod: sudo a2dismod wsgi sudo systemctl r e s t a r t apache2 . s e r v i c e and then use the a2enmod utility to re-enable it: sudo a2enmod wsgi sudo systemctl r e s t a r t apache2 . s e r v i c e see the /etc/apache2/mods−available directory for additional modules already available on your system. https configuration the mod_ssl module adds an important feature to the apache2 server - the ability to encrypt communica- tions. thus, when your browser is communicating using ssl, the https:// prefix is used at the beginning of the uniform resource locator (url) in the browser navigation bar. 263

264

apache2 to provide https, a certificate and key file are also needed. the default https configuration the mod_ssl module is available in apache2-common package. execute the following command at a terminal prompt to enable the mod_ssl module: sudo a2enmod s s l there is a default https configuration file in /etc/apache2/sites−available/default−ssl.conf. in order for will use a certificate and key generated by the ssl−cert package. they are good for testing, but the auto- sudo a 2 e n s i t e default−s s l generated certificate and key should be replaced by a certificate specific to the site or server. for information on generating a key and obtaining a certificate see certificates. to configure apache2 for https, enter the following: note the directories /etc/ssl/certs and /etc/ssl/private are the default locations. if you install the certificate and key in another directory make sure to change sslcertificatefile and sslcertifi- catekeyfile appropriately. with apache2 now configured for https, restart the service to enable the new settings: sudo systemctl r e s t a r t apache2 . s e r v i c e note depending on how you obtained your certificate you may need to enter a passphrase when apache2 starts. you can access the secure server pages by typing https://your_hostname/url/ in your browser address bar. sharing write permission for more than one user to be able to write to the same directory it will be necessary to grant write permission to a group they share in common. the following example grants shared write permission to /var/www/html to the group “webmasters”. these commands recursively set the group permission on all files and directories in /var/www/html to allow reading, writing and searching of directories. many admins find this useful for allowing multiple users to edit files in a directory tree. sudo chgrp−r webmasters / var /www/html sudo chmod−r g=rwx / var /www/html/ the apache2 daemon will run as the www−data user, which has a corresponding www−data group. these should not be granted write access to the document root, as this would mean that vulnerabilities in apache or the applications it is serving would allow attackers to overwrite the served content. warning references • apache2 documentation contains in depth information on apache2 configuration directives. also, see the apache2-doc package for the official apache2 docs. • o’reilly’s apache cookbook is a good resource for accomplishing specific apache2 configurations. • for ubuntu specific apache2 questions, ask in the #ubuntu-server irc channel on freenode.net. 264

265

apache tomcat apache tomcat is a web container that allows you to serve java servlets and jsp (java server pages) web applications. ubuntu has supported packages for both tomcat 6 and 7. tomcat 6 is the legacy version, and tomcat 7 is the current version where new features are implemented. both are considered stable. this guide will focus on tomcat 7, but most configuration details are valid for both versions. the tomcat packages in ubuntu support two different ways of running tomcat. you can install them as a classic unique system-wide instance, that will be started at boot time will run as the tomcat7 (or tomcat6) unprivileged user. but you can also deploy private instances that will run with your own user rights, and that you should start and stop by yourself. this second way is particularly useful in a development server context where multiple users need to test on their own private tomcat instances. system-wide installation to install the tomcat server, you can enter the following command in the terminal prompt: sudo apt tomcat7 i n s t a l l this will install a tomcat server with just a default root webapp that displays a minimal “it works” page by default. configuration tomcat configuration files can be found in /etc/tomcat7. only a few common configuration tweaks will be described here, please see tomcat 7.0 documentation for more. changing default ports by default tomcat runs a http connector on port 8080 and an ajp connector on port 8009. you might want to change those default ports to avoid conflict with another application on the system. this is done by changing the following lines in /etc/tomcat7/server.xml: <connector port =”8080” protocol=”http/1.1” connectiontimeout =”20000” r e d i r e c t p o r t =”8443” /> . . . <connector port =”8009” protocol=”ajp/1.3” r e d i r e c t p o r t =”8443” /> changing jvm used by default tomcat will run preferably with openjdk jvms, then try the sun jvms, then try some other jvms. you can force tomcat to use a specific jvm by setting java_home in /etc/default/tomcat7: java_home=/usr / l i b /jvm/ java−6−sun 265

266

usernames, passwords and roles (groups) can be defined centrally in a servlet container. this is done in the declaring users and roles /etc/tomcat7/tomcat−users.xml file: <r o l e rolename=”admin”/> <user username=”tomcat ” password=”s 3 c r e t ” r o l e s =”admin”/> using tomcat standard webapps tomcat is shipped with webapps that you can install for documentation, administration or demo purposes. tomcat documentation the tomcat7-docs package contains tomcat documentation, packaged as a webapp that you can access by default at http://yourserver:8080/docs. you can install it by entering the following command in the terminal prompt: sudo apt i n s t a l l tomcat7−docs tomcat7−admin tomcat administration webapps the tomcat7-admin package contains two webapps that can be used to administer the tomcat server using a web interface. you can install them by entering the following command in the terminal prompt: sudo apt i n s t a l l the first one is the manager webapp, which you can access by default at http://yourserver:8080/manager/html. it is primarily used to get server status and restart webapps. note access to the manager application is protected by default: you need to define a user with the the second one is the host-manager webapp, which you can access by default at http://yourserver:8080/host- manager/html. it can be used to create virtual hosts dynamically. note access to the host-manager application is also protected by default: you need to define a user role “manager-gui” in /etc/tomcat7/tomcat−users.xml before you can access it. with the role “admin-gui” in /etc/tomcat7/tomcat−users.xml before you can access it. sudo chgrp−r tomcat7 / etc /tomcat7 sudo chmod−r g+w / etc /tomcat7 for security reasons, the tomcat7 user cannot write to the /etc/tomcat7 directory by default. some features in these admin webapps (application deployment, virtual host creation) need write access to that directory. if you want to use these features execute the following, to give users in the tomcat7 group the necessary rights: 266

267

tomcat examples webapps the tomcat7-examples package contains two webapps that can be used to test or demonstrate servlets and jsp features, which you can access them by default at http://yourserver:8080/examples. you can install them by entering the following command in the terminal prompt: sudo apt i n s t a l l tomcat7−examples using private instances tomcat is heavily used in development and testing scenarios where using a single system-wide instance doesn’t meet the requirements of multiple users on a single system. the tomcat packages in ubuntu come with tools to help deploy your own user-oriented instances, allowing every user on a system to run (without root rights) separate private instances while still using the system-installed libraries. note it is possible to run the system-wide instance and the private instances in parallel, as long as they do not use the same tcp ports. installing private instance support you can install everything necessary to run private instances by entering the following command in the terminal prompt: sudo apt i n s t a l l tomcat7−user creating a private instance you can create a private instance directory by entering the following command in the terminal prompt: tomcat7−instance−create my−instance this will create a new my−instance directory with all the necessary subdirectories and scripts. you can for example install your common libraries in the lib/ subdirectory and deploy your webapps in the webapps/ subdirectory. no webapps are deployed by default. configuring your private instance you will find the classic tomcat configuration files for your private instance in the conf/ subdirectory. you should for example certainly edit the conf/server.xml file to change the default ports used by your private tomcat instance to avoid conflict with other instances that might be running. you can start your private instance by entering the following command in the terminal prompt (supposing starting/stopping your private instance your instance is located in the my−instance directory): my−instance / bin / startup . sh 267

268

note you should check the logs/ subdirectory for any error. if you have a java.net.bindexception: address already in use<null>:8080 error, it means that the port you’re using is already taken and that you should change it. you can stop your instance by entering the following command in the terminal prompt (supposing your instance is located in the my−instance directory): my−instance / bin /shutdown . sh references • see the apache tomcat website for more information. • tomcat: the definitive guide is a good resource for building web applications with tomcat. • for additional books see the tomcat books list page. web servers the primary function of a web server is to store, process and deliver web pages to clients. the clients communicate with the server sending http requests. clients, mostly via web browsers, request for a specific resources and the server responds with the content of that resource or an error message. the response is usually a web page such as html documents which may include images, style sheets, scripts, and the content in form of text. when accessing a web server, every http request that is received is responded to with a content and a http status code. http status codes are three-digit codes, and are grouped into five different classes. the class of a status code can be quickly identified by its first digit: • 1xx : informational - request received, continuing process • 2xx : success - the action was successfully received, understood, and accepted • 3xx : redirection - further action must be taken in order to complete the request • 4xx : client error - the request contains bad syntax or cannot be fulfilled • 5xx : server error - the server failed to fulfill an apparently valid request more information about status code check the rfc 2616. implementation web servers are heavily used in the deployment of web sites and in this scenario we can use two different implementations: • static web server: the content of the server’s response will be the hosted files “as-is”. • dynamic web server: consist in a web server plus an extra software, usually an application server and a database. for example, to produce the web pages you see in the web browser, the application server might fill an html template with contents from a database. due to that we say that the content of the server’s response is generated dynamically. introduction to high availability a definition of high availability clusters from wikipedia: 268

269

high availability clusters high-availability clusters (also known as ha clusters , fail-over clusters or metroclus- ters active/active ) are groups of computers that support server applications that can be reliably utilized with a minimum amount of down-time. they operate by using high availability software to harness redundant computers in groups or clusters that provide continued service when system components fail. without clustering, if a server running a particular application crashes, the application will be unavailable until the crashed server is fixed. ha clustering remedies this situation by detecting hardware/software faults, and immediately restarting the application on another system without requiring administrative intervention, a process known as failover. as part of this process, clustering software may configure the node before starting the application on it. for example, appropriate file systems may need to be imported and mounted, network hardware may have to be configured, and some supporting applications may need to be running as well. ha clusters are often used for critical databases, file sharing on a network, business applications, and customer services such as electronic commerce websites. high availability cluster heartbeat ha cluster implementations attempt to build redundancy into a cluster to eliminate single points of failure, including multiple network connections and data storage which is redundantly con- nected via storage area networks. ha clusters usually use a heartbeat private network connection which is used to monitor the health and status of each node in the cluster. one subtle but serious condition all clustering software must be able to handle is split-brain, which occurs when all of the private links go down simultaneously, but the cluster nodes are still running. if that happens, each node in the cluster may mistakenly decide that every other node has gone down and attempt to start services that other nodes are still running. having duplicate instances of services may cause data corruption on the shared storage. high availability cluster quorum ha clusters often also use quorum witness storage (local or cloud) to avoid this scenario. a witness device cannot be shared between two halves of a split cluster, so in the event that all cluster members cannot communicate with each other (e.g., failed heartbeat), if a member cannot access the witness, it cannot become active. example 2nodehacluster|578x674,75% fencing fencing protects your data from being corrupted, and your application from becoming unavailable, due to unintended concurrent access by rogue nodes. 269

270

just because a node is unresponsive doesn’t mean it has stopped accessing your data. the only way to be 100% sure that your data is safe, is to use fencing to ensure that the node is truly offline before allowing the data to be accessed from another node. fencing also has a role to play in the event that a clustered service cannot be stopped. in this case, the cluster uses fencing to force the whole node offline, thereby making it safe to start the service elsewhere. fencing is also known as stonith, an acronym for “shoot the other node in the head”, since the most popular form of fencing is cutting a host’s power. key benefits: • active countermeasure taken by a functioning host to isolate a misbehaving (usually dead) host from shared data. • most critical part of a cluster utilizing san or other shared storage technology (ubuntu ha clusters can only be supported if the fencing mechanism is configured). • required by ocfs2, gfs2, clvmd (before ubuntu 20.04), lvmlockd (from 20.04 and beyond). linux high availability projects there are many upstream high availability related projects that are included in ubuntu linux. this section will describe the most important ones. the following packages are present in latest ubuntu lts release: ubuntu ha core packages packages in this list are supported just like any other package available in main repository would be. url package ubuntu | upstream libqb ubuntu | upstream kronosnet ubuntu | upstream corosync pacemaker ubuntu | upstream resource-agents ubuntu | upstream ubuntu | upstream fence-agents crmsh ubuntu | upstream ubuntu | upstream cluster-glue ubuntu | upstream drbd-utils ubuntu | upstream dlm gfs2-utils ubuntu | upstream ubuntu | upstream keepalived • kronosnet - kronosnet, often referred to as knet, is a network abstraction layer designed for high availability. corosync uses kronosnet to provide multiple networks for its interconnect (replacing the old totem redundant ring protocol) and add support for some more features like interconnect network hot-plug. • corosync - or cluster membership layer, provides reliable messaging, membership and quorum in- formation about the cluster. currently, pacemaker supports corosync as this layer. • resource agents - scripts or operating system components that start, stop or monitor resources, given a set of resource parameters. these provide a uniform interface between pacemaker and the 270

271

managed services. • fence agents - scripts that execute node fencing actions, given a target and fence device parameters. • pacemaker - or cluster resource manager, provides the brain that processes and reacts to events that occur in the cluster. events might be: nodes joining or leaving the cluster, resource events caused by failures, maintenance, or scheduled activities. to achieve the desired availability, pacemaker may start and stop resources and fence nodes. • drbd - distributed replicated block device, drbd is a distributed replicated storage system for the linuxplatform. it is implemented as a kernel driver, several userspace management applications, and some shell scripts. drbd is traditionally used in high availability (ha) clusters. • dlm - a distributed lock manager (dlm) runs in every machine in a cluster, with an identical copy of a cluster-wide lock database. in this way dlm provides software applications which are distributed across a cluster on multiple machines with a means to synchronize their accesses to shared resources. • keepalived - keepalived provides simple and robust facilities for loadbalancing and high-availability to linux system and linux based infrastructures. loadbalancing framework relies on well-known and widely used linux virtual server (ipvs) kernel module providing layer4 loadbalancing. keepalived implements a set of checkers to dynamically and adaptively maintain and manage loadbalanced server pool according their health. on the other hand high-availability is achieved by vrrp protocol. ubuntu ha community packages packages in this list are supported just like any other package available in [universe] repository would be. url package ubuntu | upstream pcs* csync2 ubuntu | upstream corosync-qdevice ubuntu | upstream ubuntu | upstream fence-virt ubuntu | upstream sbd booth ubuntu | upstream • corosync-qdevice - its primary use is for even-node clusters, operates at corosync (quorum) layer. corosync-qdevice is an independent arbiter for solving split-brain situations. (qdevice-net supports multiple algorithms). • sbd - stonith block device can be particularly useful in environments where traditional fencing mechanisms are not possible. sbd integrates with pacemaker, a watchdog device and shared storage to arrange for nodes to reliably self-terminate when fencing is required. note: pcs will likely replace crmsh in main repository in future ubuntu versions. ubuntu ha deprecated packages packages in this list are only supported by the upstream community . all bugs opened against these agents will be forwarded to upstream if makes sense (affected version is close to upstream). package ocfs2-tools ubuntu | upstream url 271

272

ubuntu ha related packages packages in this list aren’t necessarily ha related packages, but they have a very important role in high availability clusters and are supported like any other package provide by the main repository. package url multipath-tools ubuntu | upstream open-iscsi ubuntu | upstream sg3-utils ubuntu | upstream tgt or targetcli-fb* ubuntu | upstream lvm2 ubuntu | upstream • lvm2 in a shared-storage cluster scenario: clvm - supported before ubuntu 20.04 a distributed lock manager (dlm) is used to broker concurrent lvm metadata accesses. whenever a cluster node needs to modify the lvm metadata, it must secure permission from its local clvmd , which is in constant contact with other clvmd daemons in the cluster and can communicate a desire to get a lock on a particular set of objects. lvmlockd - supported after ubuntu 20.04 as of 2017, a stable lvm component that is designed to replace clvmd by making the locking of lvm objects transparent to the rest of lvm, without relying on a distributed lock manager. the lvmlockd benefits over clvm are: – lvmlockd supports two cluster locking plugins: dlm and sanlock. sanlock plugin can supports up to ~2000 nodes that benefits lvm usage in big virtualization / storage cluster, while dlm plugin fits ha cluster. – lvmlockd has better design than clvmd. clvmd is command-line level based locking system, which means the whole lvm software will get hang if any lvm command gets dead-locking issue. – lvmlockd can work with lvmetad. note: targetcli-fb (linux lio) will likely replace tgt in future ubuntu versions. upstream documentation the server guide does not have the intent to document every existing option for all the ha related softwares described in this page, but to document recommended scenarios for ubuntu ha clusters. you will find more complete documentation upstream at: • clusterlabs – clusters from scratch – managing pacemaker clusters – pacemaker configuration explained – pacemaker remote - scaling ha clusters • other – ubuntu bionic ha in shared disk environments (azure) a very special thanks, and all the credits, to clusterlabs project for all that detailed documen- tation. ubuntu ha - pacemaker resource agents supportability after discussions among ubuntu developers, it was decided that ubuntu project should focus in splitting all existing pacemaker resource agents into different categories: • resource agents: main • resource agents: [universe] 272

273

• resource agents: [universe]-community • resource agents: [non-supported] • resource agents: [deprecated] note: there is a current plan to split resource agents into different packages so supported agents can be installed independently. resource agents: main agents in this list are supported just like any other package available in main repository would be. | resource agent | resource agent description |named|bind/named server instance| |nfsnotify|nfs sm-notify reboot notifications daemon| | | support agents |delay|test resource for introducing delay| |mailto|sends email to a sysadmin whenever a takeover occurs| |clustermon|runs crm_mon to a html page from time to time| |healthcpu|measures cpu idling and up- dates #health-cpu attr| |healthiowait|measures cpu idling and updates #health-iowait attr| |healths- mart|measures cpu idling and updates #health-smart attr| || services (ocf, systemd, sysv) | |apache|apache web server instance| |dovecot|dovecot imap/pop3 server instance| |dhcpd|chrooted isc dhcp server instance| |mysql|mysql instance| |mysql-proxy|mysql proxy instance| |pgsql|pgsql database instance| |nf- sserver|nfs server resource| |exportfs|nfs exports (not the nfs server)| |nginx|nginx web/proxy server instance| |postfix|postfix mail server instance| |rabbitmq-cluster|cloned rabbitmq cluster instance| |remote|pacemaker remote resource agent| |rsyncd|rsyncd instance| |rsyslog|rsyslogd instance| |slapd|stand-alone ldap daemon instance| |squid|squid proxy server instance| |vsftpd|vsftpd server instance| | | storage |raid1|software raid (md) devices on shared storage| |iscsi|local iscsi initiator and its conns to targets| |iscsilogicalunit|iscsi logical units| |iscsitarget|iscsi target export agent (implementation: tgt / lio)| |lvm|lvm volume as an ha resource| |lvm-activate|lvm activation/deact work for vgs (lvmlockd+lvm- activate or clvm+lvm-activate)| |filesystem|filesystem on a shared storage medium| |symlink|symbolic link| |zfs|zfs pools import/export| || locking & reservations |controld|distributed lock manager for clustered fss| |clvm|clvmd daemon (cluster logical vol manager)| |lvmlockd|agent manages the lvmlockd daemon.| |mpathpersist|scsi persistent reservations on mpath devs| |sg_persist|master/slave resource for scsi3 reservations| || networking |route|network routes| |iface-vlan|vlan network interfaces| |ipaddr2|virtual ipv4 and ipv6 addresses| |ipsrcaddr|preferred source address modification| |ipv6addr|ipv6 aliases| |conntrackd|conntrackd instance| |sendarp|send gratuitous arp for ip address| |viparip|virtual ip address through rip2| |ifspeed|monitor action runs -> updates cib with if speed| || |iface-bridge|bridge network interfaces| |ipsec|ipsec tunnels for vips| 273

274

virtualization |virtualdomain|manages virtual domains through libvirt (virtual machine only)| || containers |lxc|allows lxc containers to be managed by the cluster| resource agents: [universe] agents in this list are supported just like any other package available in [universe] repository would be. resource agent resource agent description || support agents |anything|generic agent to manage virtually anything| |dummy|testing dummy resource agent (template for ra writers)| |audiblealarm|audible beeps at interval| |stateful|example agent that supports two states| |winpopup|sends a smb notification msg (popup) to a host| || services |asterisk|asterisk pbx| |ctdb|clustered samba (for needed clustered underlying)| |dnsupdate|ip take-over via dynamic dns updates| |fio|fio instance| |galera|galera instance| |garbd|galera arbitrator instance| |jboss|jboss application server instance| |jira|jira server instance| |kamailio|kamailio sip proxy/registrar instance| |mari- adb|mariadb master/slave instance| |nagios|nagios instance| |ovsmonitor|clone resource to monitor net- work bonds on diff nodes| |pgagent|pgagent instance| |pound|pound reverse proxy load-bal server instance| |proftpd|proftpd instance| |pure-ftpd|pure-ftpd instance| |redis|redis server (supports master/slave repli- cas)| |syslog-ng|syslog-ng instance| |tomcat|tomcat servlet environment instance| |varnish|varnish instance| || storage |aoetarget|ata over ethernet| || networking |ipaddr|virtual ipv4 addresses| |ocf:pacemaker:ping|records in cib number of nodes host can connect to| |portblock|temporarily block/unblock access to tcp/udp ports| || openstack |openstack-cinder-volume|attach cinder vol to an instance (os-info <->)| |openstack-floating-ip|move a float- ing ip from an instance to another| || virtualization |xen|xen unprivileged domains| || registration (cib) |lxd-info|nr of lxd containers running in cib| |machine-info|records various node attributes in cib| |nodeu- tilization|cpu / host mem / hypervisor mem etc… into cib| |openstack-info|records attributes of a node into cib| |sysinfo|records various node attributes into cib| |systemhealth|monitors health of system using ipmi| |attribute|sets node attr one way when started and vice-versa| 274

275

resource agents: [universe]-community agents in this list are only supported by the upstream community. all bugs opened against these agents will be forwarded to upstream if makes sense (affected version is close to upstream). resource agent resource agent description |zab- |xinetd|start/stop services managed by xinetd| || services |sphinxsearchdaemon|sphix search daemon| bixserver|zabbix server instance| || storage |o2cb|oracle cluster filesystem userspace daemon (oracle)| |sfex|excl access to shared storage using sf-ex| || virtualization |aliyun-vpc-move-ip|move ip within a vpc of the aliyum ecs (alibaba)| |awseip|manages aws elastic ip address (aws)| |awsvip|manages aws secondary private ip addresses (aws)| |aws-vpc-move-ip|move ip within a vpc of the aws ec2 (aws)| |aws-vpc-route53|update route53 vpc record for aws ec2 (aws)| |azure-events|monitor for scheduled events for azure vm (azure)| |azure-lb|answers azure load balancer health probe req (azure)| |gcp- vpc-move-ip|floating ip address within a gcp vpc (google)| |manageve|openvz virtual environment (vir- tuozzo)| |minio|minio server instance| |podman|creates/launches podman containers| |rkt|creates/launches container based on supplied image| || containers |docker|docker container resource agent| resource agents: [non-supported] agents in this list are not supported in ubuntu and might be removed in future ubuntu ha versions. resource agent resource agent description || unsupported |db2|manages ibm db2 luw databases (ibm)| |edir88|novell edirectory directory server instance (nov- ell)| |icp|icp vortex clustered host drive (intel)| |ids|ibm informix dynamic server (ids) (ibm)| |sap- database|sap database (of any type) instance agent (sap)| |sapinstance|sap application server instances agent (sap)| |serveraid|enables/disables shared serveraid merge groups (ibm)| |manageraid|raid de- vices (/etc/conf.d/hb-manageraid)| |oraasm|oracle asm agent / uses ohasd for asm disk grp (oracle)| |ora- cle|oracle database instance (oracle)| |oralsnr|oracle tns listener (oracle)| |sybasease|sybase ase failover in- stance (sybase)| |vdo-vol|https://bugs.launchpad.net/ubuntu/+bug/1869825| |was|websphere application server instance (ibm)| |was6|websphere application server instance (ibm)| 275

276

resource agents: [deprecated] agents in this list are not supported in ubuntu or upstream (due to being deprecated in favor of other agents) and might be removed in future ubuntu ha versions. resource agent resource agent description || deprecated |evmsd|clustered evms vol mgmt (evms is not maintained)| |evmsscc|clustered evms vol mgmt (evms is not maintained)| |linuxscsi|enables/disables scsi devs through kernel scsi hotplug| |scsi2reservation|scsi- 2 reservation agent (depends on scsi_reserve)| |ocf:heartbeat:pingd|monitors connectivity to specific hosts| |ocf:pacemaker:pingd|replaced by pacemaker:ping (this is broken)| |vmware|control vmware server 2.0 virtual machines (2009)| ubuntu ha - pacemaker fence agents supportability after discussions among ubuntu developers, it was decided that ubuntu project should focus in splitting all existing pacemaker fence agents into different categories: • fence agents: main • fence agents: [universe] • fence agents: [universe]-community • fence agents: [non-supported] • fence agents: [deprecated] note: there is a current plan to split fence agents into different packages so supported agents can be installed independently. fence agents: main agents in this list are supported just like any other package available in main repository would be. fence agent fence agent description extra description |fence_ipmilan|ipmi controlled machines|| || power fencing agents|| fence_ipmilan|| |fence_ilo4|symlink to fence_ipmilan|| |fence_ilo5|symlink to fence_ipmilan|| |fence_imm|symlink to fence_ipmilan|| |fence_idrac|symlink to fence_ipmilan|| || storage fencing agents|| |fence_mpath|scsi-3 persistent reservations to control mpath devs|| |fence_sbd|sbd (shared storage) fencing|| |fence_scsi|scsi-3 persistent reservations|| || virtualization fencing agents|| |fence_virsh|libvirt managed virtual machines|| |fence_ilo3|symlink to 276

277

fence agents: [universe] agents in this list are supported just like any other package available in [universe] repository would be. fence agent fence agent description extra description (w/ telnet/ssh support)|| |fence_lpar|ibm lpars (using hmc)|| |fence_amt|intel amt|| |fence_ilo|hp servers with ilo|| |fence_ilo5_ssh|-|symlink to fence_ilo_ssh| |fence_dummy|dummy fence agent (for testing)|| |fence_ack_manual|override |fence_kdump|kdump crash recovery service (acks being in kdump)|| |fence_ilo_mp|hp ilo mp|| |fence_cisco_ucs|cisco ucs (fence machines)|| || generic agents|| fencing operations manually|| |fence_kdump_send|-|acks entered kdump crash recovery service (tool)| || |fence_intelmodular|intel modular device power fencing agents|| (intel mfsys25, mfsys35)|| |fence_ilo2|-|symlink to fence_ilo| |fence_ilo_ssh|hp ilo devices through ssh|| |fence_ilo3_ssh|-|symlink to fence_ilo_ssh| |fence_ilo4_ssh|- |symlink to fence_ilo_ssh| |fence_ilo_moonshot|hp moon- |fence_hpblade|hp bladesystem and hp integrity super- shot ilo|| |fence_alom|sun microsystems alom|| dome x|| |fence_ipdu|ibm ipdu (network |fence_bladecenter|ibm bladecenter power switch) over snmp|| |fence_ibmblade|ibm bladecen- ter over snmp|| |fence_rsa|ibm rsa ii management interface|| |fence_drac|dell remote access card|| |fence_drac5|dell remote access card v5 or cmc (drac)|| |fence_hds_cb|hitachi compute blade systems|| |fence_rsb|fujitsu-siemens rsb management interface|| || network fencing agents|| |fence_heuristics_ping|uses ping-heuristics to exec other fence in same level|| |fence_ifmib|any snmp if-mib device (ethernet switches w/ iscsi)|| || storage fencing agents|| |fence_cisco_mds|cisco mds 9000 w/ snmp enabled|| |fence_sanbox2|qlogic sanbox2 fc switches|| |fence_brocade|brocade fc switches (disables specified port)|| || virtualization fencing agents|| |fence_vmware_rest|vmware virtual machines (w/ vmware api)|| tual machines (w/ soap api v4.1+)|| vcloud director api|| || cloud fencing agents|| |fence_azure_arm|azure resource manager (azure sdk for python)|| |fence_compute|openstack nova|| |fence_evacuate|openstack nova|| |fence_openstack|fence openstack’s nova (w/ python-novaclient)|| |fence_gce|google cloud engine (googleapiclient lib)|| || containers fencing agents|| |fence_docker|docker engine containers|| virtual machines| |fence_vmware_soap|vmware vir- |fence_vmware_vcloud|vmware virtual machines on vmware |fence_vmware|vmware esx|esxi |fence_aws|aws (boto3 library)|| fence agents: [universe]-community agents in this list are only supported by the upstream community. all bugs opened against these agents will be forwarded to upstream if makes sense (affected version is close to upstream). fence agent fence agent description extra description || power fencing agents|| |fence_apc_snmp|apc net- work power switch or tripplite pdu devices|| |fence_tripplite_snmp|-|symlink to fence_tripplite_snmp| |fence_apc|apc network power switch|| 277

278

|fence_rdc_serial|serial cable to reset motherboard switches|| |fence_eaton_snmp|eaton network power switch (snmp)|| |fence_emerson|emerson mpx and mph2 managed rack pdu|| |fence_eps|epowerswitch 8m+|| |fence_netio|koukaam netio-230b pdu (telnet)|| |fence_powerman|powerman management utility (llnl systems)|| |fence_raritan|raritan dominion px (dpxs12-20 pdu)|| |fence_redfish|out-of-band controllers supporting redfish apis|| |fence_wti|wti network power switch (nps)|| || virtualization fencing agents|| |fence_xenapi|citrix xen server over xenapi|| |fence_vbox|virtualbox virtual machines|| |fence_pve|proxmox virtual environment|| |fence_zvm|power fencing on gfs vm in z/vm cluster (z/vm smapi)|| |fence_zvmip|z/vm virtual machines (z/vm smapi via tcp/ip)|| || cloud fencing agents|| |fence_ovh|ovh cloud data centers|| |fence_aliyun|aliyun|| fence agents: [non-supported] agents in this list are not supported in ubuntu and might be removed in future ubuntu ha versions. |fence agent| fence agent description extra description fence_ironic fence_rhevm fence_ldom openstack’s ironic (not intended for production) rhev-m rest api to fence virtual machines sun microsystems logical domain virtual machines fence agents: [deprecated] agents in this list are not supported in ubuntu or upstream (due to being deprecated in favor of other agents) and might be removed in future ubuntu ha versions. |fence agent| fence agent description extra description n/a n/a n/a ubuntu ha - drbd distributed replicated block device (drbd) mirrors block devices between multiple hosts. the replication is transparent to other applications on the host systems. any block device hard disks, partitions, raid devices, logical volumes, etc can be mirrored. to get started using drbd, first install the necessary packages. from a terminal enter: sudo apt i n s t a l l drbd8−u t i l s note if you are using the virtual kernel as part of a virtual machine you will need to manually compile the drbd module. it may be easier to install the linux-server package inside the virtual machine. this section covers setting up a drbd to replicate a separate /srv partition, with an ext3 filesystem between two hosts. the partition size is not particularly relevant, but both partitions need to be the same size. 278

279

configuration the two hosts in this example will be called drbd01 and drbd02. they will need to have name resolution configured either through dns or the /etc/hosts file. see ??? for details. • to configure drbd, on the first host edit /etc/drbd.conf: 15; protocol c; startup { } net { common { syncer { rate 100m; } } resource r0 { globa l { usage−count no ; } wfc−timeout degr−wfc−timeout 60; cram−hmac−alg sha1 ; shared−s e c r e t ” s e c r e t ” ; meta−disk i n t e r n a l ; meta−disk i n t e r n a l ; } on drbd02 { } on drbd01 { device /dev/drbd0 ; disk /dev/sdb1 ; address 1 9 2 . 1 6 8 . 0 . 1 : 7 7 8 8 ; device /dev/drbd0 ; disk /dev/sdb1 ; address 1 9 2 . 1 6 8 . 0 . 2 : 7 7 8 8 ; } } note there are many other options in /etc/drbd.conf, but for this example their default values are fine. • now copy /etc/drbd.conf to the second host: scp / etc /drbd . conf drbd02 :~ • and, on drbd02 move the file to /etc: sudo mv drbd . conf / etc / • now using the drbdadm utility initialize the meta data storage. on each server execute: • next, on both hosts, start the drbd daemon: s t a r t drbd . s e r v i c e sudo drbdadm create−md r0 sudo drbdadm−−−−overwrite−data−of−peer primary a l l sudo systemctl • on the drbd01, or whichever host you wish to be the primary, enter the following: 279

280

• after executing the above command, the data will start syncing with the secondary host. to watch the progress, on drbd02 enter the following: watch−n1 cat / proc /drbd to stop watching the output press ctrl+c. • finally, add a filesystem to /dev/drbd0 and mount it: sudo mkfs . ext3 /dev/drbd0 sudo mount /dev/drbd0 / srv testing to test that the data is actually syncing between the hosts copy some files on the drbd01, the primary, to /srv: sudo cp−r / etc / d e f a u l t / srv next, unmount /srv: sudo umount / srv demote the primary server to the secondary role: sudo drbdadm secondary r0 now on the secondary server promote it to the primary role: sudo drbdadm primary r0 lastly, mount the partition: sudo mount /dev/drbd0 / srv using ls you should see /srv/default copied from the former primary host drbd01. references • for more information on drbd see the drbd web site. • the drbd.conf man page contains details on the options not covered in this guide. • also, see the drbdadm man page. • the drbd ubuntu wiki page also has more information. byobu one of the most useful applications for any system administrator is an xterm multiplexor such as screen or tmux. it allows for the execution of multiple shells in one terminal. to make some of the advanced multiplexor features more user-friendly and provide some useful information about the system, the byobu package was created. it acts as a wrapper to these programs. by default byobu is installed in ubuntu server and it uses tmux (if installed) but this can be changed by the user. invoke it simply with: 280

281

byobu now bring up the configuration menu. by default this is done by pressing the f9 key. this will allow you to: • help – quick start guide • toggle status notifications • change the escape sequence • byobu currently does not launch at login (toggle on) byobu provides a menu which displays the ubuntu release, processor information, memory information, and the time and date. the effect is similar to a desktop menu. using the “byobu currently does not launch at login (toggle on)” option will cause byobu to be executed any time a terminal is opened. changes made to byobu are on a per user basis, and will not affect other users on the system. one difference when using byobu is the scrollback mode. press the f7 key to enter scrollback mode. scroll- back mode allows you to navigate past output using vi like commands. here is a quick list of movement commands: • h - move the cursor left by one character • j - move the cursor down by one line • k - move the cursor up by one line • l - move the cursor right by one character • 0 - move to the beginning of the current line • $ - move to the end of the current line • g - moves to the specified line (defaults to the end of the buffer) • / - search forward • ? - search backward • n - moves to the next match, either forward or backward resources • for more information on screen see the screen web site. • and the ubuntu wiki screen page. • also, see the byobu project page for more information. etckeeper etckeeper allows the contents of /etc to be stored in a version control system (vcs) repository. it integrates with apt and automatically commits changes to /etc when packages are installed or upgraded. placing /etc under version control is considered an industry best practice, and the goal of etckeeper is to make this process as painless as possible. install etckeeper by entering the following in a terminal: sudo apt etckeeper i n s t a l l 281

282

the main configuration file, /etc/etckeeper/etckeeper.conf, is fairly simple. the main option is which vcs to use and by default etckeeper is configured to use git. the repository is automatically initialized (and committed for the first time) during package installation. it is possible to undo this by entering the following command: sudo etckeeper uninit by default, etckeeper will commit uncommitted changes made to /etc daily. this can be disabled using the avoid_daily_autocommits configuration option. it will also automatically commit changes before and after package installation. for a more precise tracking of changes, it is recommended to commit your changes manually, together with a commit message, using: sudo etckeeper commit ”reason f o r c o n f i g u r a t i o n change ” the vcs etckeeper command allows to run any subcommand of the vcs that etckeeper is configured to run. t will be run in /etc. for example, in the case of git: sudo etckeeper vcs log / etc /passwd to demonstrate the integration with the package management system (apt), install postfix: sudo apt i n s t a l l p o s t f i x when the installation is finished, all the postfix configuration files should be committed to the repository: [ master 5a16a0d ] committing changes author : your name <xyz@example . com> 36 f i l e s create mode 100755 i n i t . d/ p o s t f i x create mode 100644 i n s s e r v . conf . d/ p o s t f i x changed , 2987 i n s e r t i o n s (+) , 4 d e l e t i o n s (−) in / etc made by ” apt i n s t a l l p o s t f i x ” create mode 100644 p o s t f i x /dynamicmaps . c f create mode 100644 p o s t f i x /main . c f create mode 100644 p o s t f i x /main . c f . proto create mode 120000 p o s t f i x /makedefs . out create mode 100644 p o s t f i x / master . c f create mode 100644 p o s t f i x / master . c f . proto create mode 100755 network/ i f−down . d/ p o s t f i x create mode 100755 network/ i f−up . d/ p o s t f i x create mode 100755 p o s t f i x / post−i n s t a l l create mode 100644 p o s t f i x / postfix−f i l e s create mode 100755 p o s t f i x / postfix−s c r i p t create mode 100755 ppp/ip−down . d/ p o s t f i x create mode 100755 ppp/ip−up . d/ p o s t f i x create mode 100755 r e s o l v c o n f /update−l i b c . d/ p o s t f i x create mode 120000 systemd/system/ multi−user . target . wants/ p o s t f i x . s e r v i c e create mode 120000 rc0 . d/ k01postfix create mode 120000 rc1 . d/ k01postfix create mode 120000 rc2 . d/ s01postfix create mode 120000 rc3 . d/ s01postfix create mode 120000 rc4 . d/ s01postfix create mode 120000 rc5 . d/ s01postfix create mode 120000 rc6 . d/ k01postfix create mode 100644 ufw/ a p p l i c a t i o n s . d/ p o s t f i x create mode 100644 r s y s l o g . d/ p o s t f i x . conf for an example of how etckeeper tracks manual changes, add new a host to /etc/hosts. using git you can see which files have been modified: 282

283

sudo etckeeper vcs status and how: sudo etckeeper vcs d i f f if you are happy with the changes you can now commit them: sudo etckeeper commit ”added new host ” resources • see the etckeeper site for more details on using etckeeper. • for documentation on the git vcs tool see the git website. munin installation before installing munin on server01 apache2 will need to be installed. the default configuration is fine for running a munin server. for more information see ???. first, on server01 install munin. in a terminal enter: sudo apt i n s t a l l munin now on server02 install the munin-node package: sudo apt i n s t a l l munin−node configuration on server01 edit the /etc/munin/munin.conf adding the ip address for server02: ## f i r s t our ”normal” host . [ server02 ] address 172.18.100.101 note replace server02 and 172.18.100.101 with the actual hostname and ip address for your server. next, configure munin-node on server02. edit /etc/munin/munin−node.conf to allow access by server01: allow ^172\.18\.100\.100 $ note replace ˆ172\.18\.100\.100$ with ip address for your munin server. now restart munin-node on server02 for the changes to take effect: sudo systemctl r e s t a r t munin−node . s e r v i c e finally, in a browser go to http://server01/munin, and you should see links to nice graphs displaying information from the standard munin-plugins for disk, network, processes, and system. 283

284

note since this is a new install it may take some time for the graphs to display anything useful. additional plugins the munin-plugins-extra package contains performance checks additional services such as dns, dhcp, samba, etc. to install the package, from a terminal enter: sudo apt i n s t a l l munin−plugins−extra be sure to install the package on both the server and node machines. references • see the munin website for more details. • specifically the munin documentation page includes information on additional plugins, writing plugins, etc. nagios installation first, on server01 install the nagios package. in a terminal enter: sudo apt i n s t a l l nagios3 nagios−nrpe−plugin you will be asked to enter a password for the nagiosadmin user. the user’s credentials are stored in /etc/ nagios3/htpasswd.users. to change the nagiosadmin password, or add additional users to the nagios cgi scripts, use the htpasswd that is part of the apache2-utils package. for example, to change the password for the nagiosadmin user enter: sudo htpasswd / etc / nagios3 /htpasswd . users nagiosadmin to add a user: sudo htpasswd / etc / nagios3 /htpasswd . users steve next, on server02 install the nagios-nrpe-server package. from a terminal on server02 enter: sudo apt i n s t a l l nagios−nrpe−s e r v e r note nrpe allows you to execute local checks on remote hosts. there are other ways of accomplishing this through other nagios plugins as well as other checks. 284

285

configuration overview there are a couple of directories containing nagios configuration and check files. • /etc/nagios3: contains configuration files for the operation of the nagios daemon, cgi files, hosts, etc. • /etc/nagios: on the remote host contains the nagios-nrpe-server configuration files. • /usr/lib/nagios/plugins/: where the check binaries are stored. to see the options of a check use the • /etc/nagios−plugins: houses configuration files for the service checks. for example: /usr/lib/nagios/plugins/check_dhcp−h -h option. there are a plethora of checks nagios can be configured to execute for any given host. for this example nagios will be configured to check disk space, dns, and a mysql hostgroup. the dns check will be on server02, and the mysql hostgroup will include both server01 and server02. note see ??? for details on setting up apache, ??? for dns, and ??? for mysql. additionally, there are some terms that once explained will hopefully make understanding nagios configura- tion easier: • host: a server, workstation, network device, etc that is being monitored. • host group: a group of similar hosts. for example, you could group all web servers, file server, etc. • service: the service being monitored on the host. such as http, dns, nfs, etc. • service group: allows you to group multiple services together. this is useful for grouping multiple http for example. • contact: person to be notified when an event takes place. nagios can be configured to send emails, sms messages, etc. by default nagios is configured to check http, disk space, ssh, current users, processes, and load on the localhost. nagios will also ping check the gateway. large nagios installations can be quite complex to configure. it is usually best to start small, one or two hosts, get things configured the way you like then expand. configuration • first, create a host configuration file for server02. unless otherwise specified, run all these commands on server01. in a terminal enter: sudo cp / etc / nagios3 / conf . d/ localhost_nagios2 . cfg \ / etc / nagios3 / conf . d/ server02 . cfg note in the above and following command examples, “server02” 172.18.100.100, and 172.18.100.101 with the host names and ip addresses of your servers. replace “server01”, next, edit /etc/nagios3/conf.d/server02.cfg: d e f i n e host { use use generic−host 285 ; name of host template to

286

host_name a l i a s address } server02 server 02 172.18.100.101 # check dns s e r v i c e . d e f i n e s e r v i c e { use host_name s e r v i c e _ d e s c r i p t i o n check_command generic−s e r v i c e server02 dns check_dns ! 1 7 2 . 1 8 . 1 0 0 . 1 0 1 restart the nagios daemon to enable the new configuration: sudo systemctl r e s t a r t nagio3 . s e r v i c e • now add a service definition for the mysql check by adding the following to /etc/nagios3/conf.d/ } } services_nagios2.cfg: # check mysql s e r v e r s . d e f i n e s e r v i c e { hostgroup_name s e r v i c e _ d e s c r i p t i o n check_command $hostaddress mysql check_mysql_cmdlinecred ! nagios ! s e c r e t ! use n o t i f i c a t i o n _ i n t e r v a l 0 ; s e t > 0 i f you want to be r e n o t i f i e d mysql−s e r v e r s generic−s e r v i c e a mysql-servers hostgroup now needs to be defined. edit /etc/nagios3/conf.d/hostgroups_nagios2.cfg adding: # mysql hostgroup . d e f i n e hostgroup { a l i a s members hostgroup_name mysql−s e r v e r s mysql−u root−p−e ” create user nagios } the nagios check needs to authenticate to mysql. to add a nagios user to mysql enter: i d e n t i f i e d by ’ secret ’ ; ” note the nagios user will need to be added all hosts in the mysql-servers hostgroup. mysql s e r v e r s lo c a l ho s t , server02 restart nagios to start checking the mysql servers. sudo systemctl r e s t a r t nagios3 . s e r v i c e • lastly configure nrpe to check the disk space on server02. on server01 add the service check to /etc/nagios3/conf.d/server02.cfg: # nrpe disk check . d e f i n e s e r v i c e { use generic−s e r v i c e 286

287

host_name s e r v i c e _ d e s c r i p t i o n check_command ! 1 7 2 . 1 8 . 1 0 0 . 1 0 1 } server02 nrpe−disk check_nrpe_1arg ! check_all_disks now on server02 edit /etc/nagios/nrpe.cfg changing: allowed_hosts =172.18.100.100 and below in the command definition area add: command [ check_all_disks ]=/ usr / l i b / nagios / plugins / check_disk−w 20%−c 10% −e finally, restart nagios-nrpe-server: sudo systemctl r e s t a r t nagios−nrpe−s e r v e r . s e r v i c e also, on server01 restart nagios: sudo systemctl r e s t a r t nagios3 . s e r v i c e you should now be able to see the host and service checks in the nagios cgi files. to access them point a browser to http://server01/nagios3. you will then be prompted for the nagiosadmin username and password. references this section has just scratched the surface of nagios’ features. the nagios-plugins-extra and nagios-snmp- plugins contain many more service checks. • for more information see nagios website. • specifically the nagios online documentation site. • there is also a list of books related to nagios and network monitoring: • the nagios ubuntu wiki page also has more details. pam_motd when logging into an ubuntu server you may have noticed the informative message of the day (motd). this information is obtained and displayed using a couple of packages: • landscape-common: provides the core libraries of landscape-client, which is needed to manage systems with landscape (proprietary). yet the package also includes the landscape-sysinfo utility which is responsible for displaying core system data involving cpu, memory, disk space, etc. for instance: system load : usage of /: memory usage : 20% swap usage : 0% 0.0 30.2% of 3.11gb processes : users ip address logged in : 76 1 f o r eth0 : 10.153.107.115 graph t h i s data and manage t h i s canonical . com/ system at https :// landscape . 287

288

note you can run landscape-sysinfo manually at any time. • update-notifier-common: provides information on available package updates, impending filesystem checks (fsck), and required reboots (e.g.: after a kernel upgrade). pam_motd executes the scripts in /etc/update−motd.d in order based on the number prepended to the script. the output of the scripts is written to /var/run/motd, keeping the numerical order, then concatenated with /etc/motd.tail. you can add your own dynamic information to the motd. for example, to add local weather information: • first, install the weather-util package: i n s t a l l weather−u t i l sudo apt • the weather utility uses metar data from the national oceanic and atmospheric administration and forecasts from the national weather service. in order to find local information you will need the 4-character icao location indicator. this can be determined by browsing to the national weather service site. although the national weather service is a united states government agency there are weather stations available world wide. however, local weather information for all locations outside the u.s. may not be available. • create /usr/local/bin/local−weather, a simple shell script to use weather with your local icao indi- cator: #!/ bin /sh # # # prints # # the l o c a l weather information f o r the motd. # replace kint with your # local shtml s t a t i o n s can be found here : http ://www. weather . gov/ tg / s i t e l o c . l o c a l weather s t a t i o n . echo weather kint echo • make the script executable: sudo chmod 755 / usr / l o c a l / bin / l o c a l−weather • next, create a symlink to /etc/update−motd.d/98−local−weather: sudo ln−s / usr / l o c a l / bin / l o c a l−weather / etc /update−motd . d/98− l o c a l− weather • finally, exit the server and re-login to view the new motd. you should now be greeted with some useful information, and some information about the local weather that may not be quite so useful. hopefully the local-weather example demonstrates the flexibility of pam_motd. 288

289

resources • see the update-motd man page for more options available to update-motd. • the debian package of the day weather article has more details about using the weatherutility. puppet puppet is a cross platform framework enabling system administrators to perform common tasks using code. the code can do a variety of tasks from installing new software, to checking file permissions, or updating user accounts. puppet is great not only during the initial installation of a system, but also throughout the system’s entire life cycle. in most circumstances puppet will be used in a client/server configuration. this section will cover installing and configuring puppet in a client/server configuration. this simple example will demonstrate how to install apache using puppet. preconfiguration prior to configuring puppet you may want to add a dns cname record for puppet.example.com, where example.com is your domain. by default puppet clients check dns for puppet.example.com as the puppet server name, or puppet master. see domain name server for more details. if you do not wish to use dns, you can add entries to the server and client /etc/hosts file. for example, in the puppet server’s /etc/hosts file add: 1 2 7 . 0 . 0 . 1 l o c a l h o s t . localdomain l o c a l h o s t puppet 1 9 2 . 1 6 8 . 1 . 1 7 puppetclient . example . com puppetclient on each puppet client, add an entry for the server: 1 9 2 . 1 6 8 . 1 . 1 6 puppetmaster . example . com puppetmaster puppet note replace the example ip addresses and domain names above with your actual server and client addresses and domain names. installation to install puppet, in a terminal on the server enter: sudo apt i n s t a l l puppetmaster on the client machine, or machines, enter: sudo apt i n s t a l l puppet configuration create a folder path for the apache2 class: sudo mkdir−p / etc /puppet/modules/apache2/ manifests 289

290

now setup some resources for apache2. create a file /etc/puppet/modules/apache2/manifests/init.pp con- taining the following: c l a s s apache2 { package { ’ apache2 ’ : ensure => i n s t a l l e d , s e r v i c e { ’ apache2 ’ : ensure => true , enable => true , r e q u i r e => package [ ’ apache2 ’ ] , } } } } next, create a node file /etc/puppet/code/environments/production/manifests/site.pp with: node ’ puppetclient . example . com ’ { include apache2 note replace puppetclient .example.com with your actual puppet client’s host name. the final step for this simple puppet server is to restart the daemon: sudo systemctl r e s t a r t puppetmaster . s e r v i c e now everything is configured on the puppet server, it is time to configure the client. first, configure the puppet agent daemon to start. edit /etc/default/puppet, changing start to yes: start=yes then start the service: sudo systemctl s t a r t puppet . s e r v i c e view the client cert fingerprint sudo puppet agent−−f i n g e r p r i n t back on the puppet server, view pending certificate signing requests: sudo puppet c e r t l i s t on the puppet server, verify the fingerprint of the client and sign puppetclient’s cert: sudo puppet c e r t sign puppetclient . example . com on the puppet client, run the puppet agent manually in the foreground. this step isn’t strictly speaking necessary, but it is the best way to test and debug the puppet service. sudo puppet agent−−t e s t check /var/log/syslog on both hosts for any errors with the configuration. package and it’s dependencies will be installed on the puppet client. if all goes well the apache2 note this example is very simple, and does not highlight many of puppet’s features and benefits. for more information see resources. 290

291

resources • see the official puppet documentation web site. • see the puppet forge, online repository of puppet modules. • also see pro puppet. zentyal zentyal is a linux small business server that can be configured as a gateway, infrastructure manager, unified threat manager, office server, unified communication server or a combination of them. all network services managed by zentyal are tightly integrated, automating most tasks. this saves time and helps to avoid errors in network configuration and administration. zentyal is open source, released under the gnu general public license (gpl) and runs on top of ubuntu gnu/linux. zentyal consists of a series of packages (usually one for each module) that provide a web interface to configure the different servers or services. the configuration is stored on a key-value redis database, but users, groups, and domains-related configuration is on openldap. when you configure any of the available parameters through the web interface, final configuration files are overwritten using the configuration templates provided by the modules. the main advantage of using zentyal is a unified, graphical user interface to configure all network services and high, out-of-the-box integration between them. zentyal publishes one major stable release once a year based on the latest ubuntu lts release. installation if you would like to create a new user to access the zentyal web interface, run: sudo adduser username sudo import the public keys from zentyal: add the zentyal repository to your repository list: sudo add−apt−r e p o s i t o r y ”deb http :// archive . zentyal . org / zentyal 3.5 main extra sudo apt−key adv−−keyserver keyserver . ubuntu . com−−recv−keys 10e239ff sudo apt−key add wget−q http :// keys . zentyal . org / zentyal−4.2− archive . asc−o− | − ” update your packages and install zentyal: sudo apt update sudo apt i n s t a l l zentyal during installation you will be asked to set a root mysql password and confirm port 443. first steps any system account belonging to the sudo group is allowed to log into the zentyal web interface. the user created while installing ubuntu server will belong to the sudo group by default. 291

292

to access the zentyal web interface, point a browser to https://localhost/ or to the ip address of your remote server. as zentyal creates its own self-signed ssl certificate, you will have to accept a security exception on your browser. log in with the same username and password used to log in to your server. once logged in you will see an overview of your server. individual modules, such as antivirus or firewall, can be installed by simply clicking them and then clicking install. selecting server roles like gateway or infrastructure can be used to install multiple modules at once. modules can also be installed via the command line: sudo apt i n s t a l l <zentyal−module> see the list of available modules below. to enable a module, go to the dashboard, then click module status. click the check box for the module, then save changes. to configure any of the features of your installed modules, click the different sections on the left menu. when you make any changes, a red “save changes” button appears in the upper right corner. if you need to customize any configuration file or run certain actions (scripts or commands) to config- ure features not available on zentyal, place the custom configuration file templates on /etc/zentyal/s- tubs/<module>/ and the hooks on /etc/zentyal/hooks/<module>.<action>. read more about stubs and hooks here. modules zentyal 2.3 is available on ubuntu distro-rev-short universe repository. the modules available are: • zentyal-core & zentyal-common: the core of the zentyal interface and the common libraries of the framework. also includes the logs and events modules that give the administrator an interface to view the logs and generate events from them. • zentyal-network: manages the configuration of the network. from the interfaces (supporting static ip, dhcp, vlan, bridges or pppoe), to multiple gateways when having more than one internet connection, load balancing and advanced routing, static routes or dynamic dns. • zentyal-objects & zentyal-services: provide an abstraction level for network addresses (e.g. lan instead of 192.168.1.0/24) and ports named as services (e.g. http instead of 80/tcp). • zentyal-firewall: configures the iptables rules to block forbiden connections, nat and port redirections. • zentyal-ntp: installs the ntp daemon to keep server on time and allow network clients to synchronize their clocks against the server. • zentyal-dhcp: configures isc dhcp server supporting network ranges, static leases and other advanced options like ntp, wins, dynamic dns updates and network boot with pxe. • zentyal-dns: brings isc bind9 dns server into your server for caching local queries as a forwarder or as an authoritative server for the configured domains. allows to configure a, cname, mx, ns, txt and srv records. • zentyal-ca: integrates the management of a certification authority within zentyal so users can use certificates to authenticate against the services, like with openvpn. • zentyal-openvpn: allows to configure multiple vpn servers and clients using openvpn with dynamic routing configuration using quagga. • zentyal-users: provides an interface to configure and manage users and groups on openldap. other services on zentyal are authenticated against ldap having a centralized users and groups management. it is also possible to synchronize users, passwords and groups from a microsoft active directory domain. 292

293

• zentyal-squid: configures squid and dansguardian for speeding up browsing thanks to the caching capabilities and content filtering. • zentyal-samba: allows samba configuration and integration with existing ldap. from the same inter- face you can define password policies, create shared resources and assign permissions. • zentyal-printers: integrates cups with samba and allows not only to configure the printers but also give them permissions based on ldap users and groups. not present on ubuntu universe repositories, but on zentyal team ppa you will find these other modules: • zentyal-antivirus: integrates clamav antivirus with other modules like the proxy, file sharing or mail- filter. • zentyal-asterisk: configures asterisk to provide a simple pbx with ldap based authentication. • zentyal-bwmonitor: allows to monitor bandwith usage of your lan clients. • zentyal-captiveportal: integrates a captive portal with the firewall and ldap users and groups. • zentyal-ebackup: allows to make scheduled backups of your server using the popular duplicity backup tool. • zentyal-ftp: configures a ftp server with ldap based authentication. • zentyal-ids: integrates a network intrusion detection system. • zentyal-ipsec: allows to configure ipsec tunnels using openswan. • zentyal-jabber: integrates ejabberd xmpp server with ldap users and groups. • zentyal-thinclients: a ltsp based thin clients solution. • zentyal-mail: a full mail stack including postfix and dovecot with ldap backend. • zentyal-mailfilter: configures amavisd with mail stack to filter spam and attached virus. • zentyal-monitor: integrates collectd to monitor server performance and running services. • zentyal-pptp: configures a pptp vpn server. • zentyal-radius: integrates freeradius with ldap users and groups. • zentyal-software: simple interface to manage installed zentyal modules and system updates. • zentyal-trafficshaping: configures traffic limiting rules to do bandwidth throttling and improve latency. • zentyal-usercorner: allows users to edit their own ldap attributes using a web browser. • zentyal-virt: simple interface to create and manage virtual machines based on libvirt. • zentyal-webmail: allows to access your mail using the popular roundcube webmail. • zentyal-webserver: configures apache webserver to host different sites on your machine. • zentyal-zarafa: integrates zarafa groupware suite with zentyal mail stack and ldap. references zentyal official documentation page. zentyal community wiki. visit the zentyal forum for community support, feedback, feature requests, etc. 293

294

monitoring overview the monitoring of essential servers and services is an important part of system administration. most net- work services are monitored for performance, availability, or both. this section will cover installation and configuration of nagios for availability monitoring, and munin for performance monitoring. the examples in this section will use two servers with hostnames server01 and server02. server01 will be configured with nagios to monitor services on itself and server02. server01 will also be setup with the munin package to gather information from the network. using the munin-node package, server02 will be configured to send information to server01. hopefully these simple examples will allow you to monitor additional servers and services on your network. nagios installation first, on server01 install the nagios package. in a terminal enter: sudo apt i n s t a l l nagios3 nagios−nrpe−plugin you will be asked to enter a password for the nagiosadmin user. the user’s credentials are stored in /etc/ nagios3/htpasswd.users. to change the nagiosadmin password, or add additional users to the nagios cgi scripts, use the htpasswd that is part of the apache2-utils package. for example, to change the password for the nagiosadmin user enter: sudo htpasswd / etc / nagios3 /htpasswd . users nagiosadmin to add a user: sudo htpasswd / etc / nagios3 /htpasswd . users steve next, on server02 install the nagios-nrpe-server package. from a terminal on server02 enter: sudo apt i n s t a l l nagios−nrpe−s e r v e r note nrpe allows you to execute local checks on remote hosts. there are other ways of accomplishing this through other nagios plugins as well as other checks. configuration overview there are a couple of directories containing nagios configuration and check files. • /etc/nagios3: contains configuration files for the operation of the nagios daemon, cgi files, hosts, etc. • /etc/nagios−plugins: houses configuration files for the service checks. • /etc/nagios: on the remote host contains the nagios-nrpe-server configuration files. 294

295

• /usr/lib/nagios/plugins/: where the check binaries are stored. to see the options of a check use the -h option. for example: /usr/lib/nagios/plugins/check_dhcp−h there are a plethora of checks nagios can be configured to execute for any given host. for this example nagios will be configured to check disk space, dns, and a mysql hostgroup. the dns check will be on server02, and the mysql hostgroup will include both server01 and server02. note see details on setting up apache, domain name service, and mysql. additionally, there are some terms that once explained will hopefully make understanding nagios configura- tion easier: • host: a server, workstation, network device, etc that is being monitored. • host group: a group of similar hosts. for example, you could group all web servers, file server, etc. • service: the service being monitored on the host. such as http, dns, nfs, etc. • service group: allows you to group multiple services together. this is useful for grouping multiple http for example. • contact: person to be notified when an event takes place. nagios can be configured to send emails, sms messages, etc. by default nagios is configured to check http, disk space, ssh, current users, processes, and load on the localhost. nagios will also ping check the gateway. large nagios installations can be quite complex to configure. it is usually best to start small, one or two hosts, get things configured the way you like then expand. configuration • first, create a host configuration file for server02. unless otherwise specified, run all these commands on server01. in a terminal enter: sudo cp / etc / nagios3 / conf . d/ localhost_nagios2 . cfg \ / etc / nagios3 / conf . d/ server02 . cfg note in the above and following command examples, “server02” 172.18.100.100, and 172.18.100.101 with the host names and ip addresses of your servers. replace “server01”, next, edit /etc/nagios3/conf.d/server02.cfg: d e f i n e host { use use host_name a l i a s address } generic−host server02 server 02 172.18.100.101 ; name of host template to # check dns s e r v i c e . d e f i n e s e r v i c e { use generic−s e r v i c e 295

296

host_name s e r v i c e _ d e s c r i p t i o n check_command server02 dns check_dns ! 1 7 2 . 1 8 . 1 0 0 . 1 0 1 } restart the nagios daemon to enable the new configuration: sudo systemctl r e s t a r t nagio3 . s e r v i c e • now add a service definition for the mysql check by adding the following to /etc/nagios3/conf.d/ services_nagios2.cfg: # check mysql s e r v e r s . d e f i n e s e r v i c e { hostgroup_name s e r v i c e _ d e s c r i p t i o n check_command $hostaddress mysql check_mysql_cmdlinecred ! nagios ! s e c r e t ! use n o t i f i c a t i o n _ i n t e r v a l 0 ; s e t > 0 i f you want to be r e n o t i f i e d mysql−s e r v e r s generic−s e r v i c e a mysql-servers hostgroup now needs to be defined. edit /etc/nagios3/conf.d/hostgroups_nagios2.cfg adding: # mysql hostgroup . d e f i n e hostgroup { a l i a s members hostgroup_name mysql−s e r v e r s mysql−u root−p−e ” create user nagios } the nagios check needs to authenticate to mysql. to add a nagios user to mysql enter: i d e n t i f i e d by ’ secret ’ ; ” note the nagios user will need to be added all hosts in the mysql-servers hostgroup. mysql s e r v e r s lo c a l ho s t , server02 } } restart nagios to start checking the mysql servers. r e s t a r t nagios3 . s e r v i c e sudo systemctl • lastly configure nrpe to check the disk space on server02. on server01 add the service check to /etc/nagios3/conf.d/server02.cfg: # nrpe disk check . d e f i n e s e r v i c e { use host_name s e r v i c e _ d e s c r i p t i o n check_command ! 1 7 2 . 1 8 . 1 0 0 . 1 0 1 server02 generic−s e r v i c e nrpe−disk check_nrpe_1arg ! check_all_disks now on server02 edit /etc/nagios/nrpe.cfg changing: 296

297

allowed_hosts =172.18.100.100 and below in the command definition area add: command [ check_all_disks ]=/ usr / l i b / nagios / plugins / check_disk−w 20%−c 10% −e finally, restart nagios-nrpe-server: sudo systemctl r e s t a r t nagios−nrpe−s e r v e r . s e r v i c e r e s t a r t nagios3 . s e r v i c e also, on server01 restart nagios: sudo systemctl you should now be able to see the host and service checks in the nagios cgi files. to access them point a browser to http://server01/nagios3. you will then be prompted for the nagiosadmin username and password. references this section has just scratched the surface of nagios’ features. the nagios-plugins-extra and nagios-snmp- plugins contain many more service checks. • for more information see nagios website. • specifically the nagios online documentation site. • there is also a list of books related to nagios and network monitoring: • the nagios ubuntu wiki page also has more details. munin installation before installing munin on server01 apache2 will need to be installed. the default configuration is fine for running a munin server. for more information see setting up apache. first, on server01 install munin. in a terminal enter: sudo apt i n s t a l l munin now on server02 install the munin-node package: sudo apt i n s t a l l munin−node configuration on server01 edit the /etc/munin/munin.conf adding the ip address for server02: ## f i r s t our ”normal” host . [ server02 ] address 172.18.100.101 note replace server02 and 172.18.100.101 with the actual hostname and ip address for your server. 297

298

next, configure munin-node on server02. edit /etc/munin/munin−node.conf to allow access by server01: allow ^172\.18\.100\.100 $ note replace ˆ172\.18\.100\.100$ with ip address for your munin server. now restart munin-node on server02 for the changes to take effect: sudo systemctl r e s t a r t munin−node . s e r v i c e finally, in a browser go to http://server01/munin, and you should see links to nice graphs displaying information from the standard munin-plugins for disk, network, processes, and system. note since this is a new install it may take some time for the graphs to display anything useful. additional plugins the munin-plugins-extra package contains performance checks additional services such as dns, dhcp, samba, etc. to install the package, from a terminal enter: sudo apt i n s t a l l munin−plugins−extra be sure to install the package on both the server and node machines. references • see the munin website for more details. • specifically the munin documentation page includes information on additional plugins, writing plugins, etc. rsnapshot rsnapshot is an rsync-based filesystem snapshot utility. it can take incremental backups of local and remote filesystems for any number of machines. rsnapshot makes extensive use of hard links, so disk space is only used when absolutely necessary. it leverages the power of rsync to create scheduled, incremental backups. to install it open a terminal shell and run: sudo apt−get i n s t a l l rsnapshot if you want to backup a remote filesystem the rsnapshot server needs to be able to access the target machine over ssh without password. for more information on how to enable it please see openssh documentation. if the backup target is a local filesystem there is no need to set up openssh. configuration the rsnapshot configuration resides in /etc/rsnapshot.conf. below you can find some of the options available there. the root directory where all snapshots will be stored: 298

299

snapshot_root / var / cache / rsnapshot / how many old backups you would like to keep. since rsnapshot uses incremental backups, we can afford to keep older backups for awhile before removing them. you set these up under the backup levels / intervals section. you tell rsnapshot to retain a specific number of backups of each kind of interval. r e t a i n d a i l y r e t a i n weekly r e t a i n monthly 7 4 6 in this example we will keep 6 snapshots of our daily strategy, 7 snapshots of our weekly strategy, and 4 snapshots of our monthly strategy. these data will guide the rotation made by rsnapshot. if you are accessing a remote machine over ssh and the port to bind is not the default (port 22), you need to set the following variable with the port number: ssh_args −p 22222 and the most important part, you need to decide on what you would like to backup. if you are backing up locally to the same machine, this is as easy as specifying the directories that you want to save and following it with localhost/ which will be a sub-directory in the snapshot_root that you set up earlier. backup backup backup /home/ / etc / / usr / l o c a l / l o c a l h o s t / l o c a l h o s t / l o c a l h o s t / if you are backing up a remote machine you just need to tell rsnapshot where the server is and which directories you would like to back up. backup root@example . com :/ home/ example . com/ +rsync_long_args=−−bwlimit =16, exclude=mtab , exclude=core exclude=core backup root@example . com :/ etc / example . com/ as you can see you can see you can pass extra rsync parameters (the + append the parameter to the default list, if you remove the + sign you override it) and also exclude directories. you can check the comments in /etc/rsnapshot.conf and the rsnapshot man page for more options. test configuration after modifying the configuration file is a good practice to check if the syntax is ok: sudo rsnapshot c o n f i g t e s t you can also test your backup levels with the following command: sudo rsnapshot -t daily if you are happy with the output and want to see it in action you can run: sudo rsnapshot d a i l y scheduling backups with rsnapshot working correctly with the current configuration, the only thing left to do is to schedule it to run at certain intervals. we will use cron to make this happen since rsnapshot includes a default cron file in /etc/cron.d/rsnapshot. if you open this file there are some entries commented out as reference. 299

300

0 4 0 3 0 2 * * * * * 1 1 * * root root root / usr / bin / rsnapshot d a i l y / usr / bin / rsnapshot weekly / usr / bin / rsnapshot monthly the settings above added to /etc/cron.d/rsnapshot run: • the daily snapshot everyday at 4:00 am • the weekly snapshot every monday at 3:00 am • the monthly snapshot on the first of every month at 2:00 am for more information on how to schedule a backup using cron please take a look at executing with cron section in backups - shell scripts. references • rsnapshot offical web page • rsnapshot man page • rsync man page php - scripting language php is a general-purpose scripting language suited for web development. php scripts can be embedded into html. this section explains how to install and configure php in an ubuntu system with apache2 and mysql. this section assumes you have installed and configured apache2 web server and mysql database server. you can refer to the apache2 and mysql sections in this document to install and configure apache2 and mysql respectively. installation php is available in ubuntu linux. unlike python, which is installed in the base system, php must be added. to install php and the apache php module you can enter the following command at a terminal prompt: sudo apt i n s t a l l php libapache2−mod−php i n s t a l l php−c l i i n s t a l l php−c g i i n s t a l l php−mysql i n s t a l l php−pgsql 300 you can run php scripts at a terminal prompt. to run php scripts at a terminal prompt you should install the php-cli package. to install php-cli you can enter the following command: sudo apt you can also execute php scripts without installing the apache php module. to accomplish this, you should install the php-cgi package via this command: sudo apt to use mysql with php you should install the php-mysql package, like so: sudo apt similarly, to use postgresql with php you should install the php-pgsql package: sudo apt

301

configuration if you have installed the libapache2-mod-php or php-cgi packages, you can run php scripts from your web browser. if you have installed the php-cli package, you can run php scripts at a terminal prompt. by default, when libapache2-mod-php is installed, the apache 2 web server is configured to run php scripts using this module. please verify if the files /etc/apache2/mods−enabled/php7.*.conf and /etc/apache2 /mods−enabled/php7.*.load exist. command. once you have installed the php related packages and enabled the apache php module, you should restart the apache2 web server to run php scripts, by running the following command: sudo systemctl if they do not exist, you can enable the module using the a2enmod r e s t a r t apache2 . s e r v i c e testing to verify your installation, you can run the following php phpinfo script: <?php phpinfo () ; ?> you can save the content in a file phpinfo.php and place it under the documentroot directory of the apache2 web server. pointing your browser to http://hostname/phpinfo.php will display the values of various php configuration parameters. references • for more in depth information see the php.net documentation. • there are a plethora of books on php. a good book from o’reilly is learning php, which includes an exploration of php 7’s enhancements to the language. php cook book, 3rd edition is also good, but has not yet been updated for php 7. • also, see the apache mysql php ubuntu wiki page for more information. ruby on rails ruby on rails is an open source web framework for developing database backed web applications. it is optimized for sustainable productivity of the programmer since it lets the programmer to write code by favouring convention over configuration. installation before installing rails you should install apache (or a preferred web server) and a database service such as mysql. to install the apache package, please refer to httpd - apache2 web server. for instructions on installing and configuring a database service refer to mysql documentation for example. once you have a web server (e.g. apache) and a database service (e.g. mysql) installed and configured, you are ready to install ruby on rails package. to install the ruby base packages and ruby on rails, you can enter the following command in the terminal prompt: 301

302

sudo apt i n s t a l l r a i l s configuration web server modify the /etc/apache2/sites−available/000−default.conf configuration file to setup your domains. the first thing to change is the documentroot directive: documentroot /path/ to / r a i l s / a p p l i c a t i o n / public next, change the <directory “/path/to/rails/application/public”> directive: <directory ”/ path/ to / r a i l s / a p p l i c a t i o n / public”> indexes followsymlinks multiviews execcgi options allowoverride all order allow , deny allow from a l l addhandler cgi−s c r i p t . c g i </directory > you should also enable the mod_rewrite module for apache. to enable mod_rewrite module, please enter the following command in a terminal prompt: sudo a2enmod r e w r i t e finally you will need to change the ownership of the /path/to/rails/application/public and /path/to/rails/ application/tmp directories to the user used to run the apache process: sudo chown−r www−data :www−data /path/ to / r a i l s / a p p l i c a t i o n / public sudo chown−r www−data :www−data /path/ to / r a i l s / a p p l i c a t i o n /tmp if you need to compile your application assets run the following command in your application directory: rails_env=production rake a s s e t s : precompile database with your database service in place you need to make sure your app database configuration is also correct. for example, if you are using mysql your config/database.yml should look like this: # mysql production : adapter : mysql2 username : user password : password host : 1 2 7 . 0 . 0 . 1 database : app to finally create your application database and apply its migrations you can run the following commands from your app directory: rails_env=production rake db : create rails_env=production rake db : migrate that’s it! now you have your server ready for your ruby on rails application. you can daemonize your application as you want. 302

303

references • see the ruby on rails website for more information. • also agile development with rails is a great resource. backups there are many ways to backup an ubuntu installation. the most important thing about backups is to develop a backup plan consisting of what to backup, where to back it up to, and how to restore it. it is good practice to take backup media off-site in case of a disaster. for backup plans involving physical tape or removable hard drives, the tapes or drives can be manually taken off-site, but in other cases this may not be practical and the archives will need copied over a wan link to a server in another location. archive rotation the shell script in shell scripts only allows for seven different archives. for a server whose data doesn’t change often, this may be enough. if the server has a large amount of data, a more complex rotation scheme should be used. rotating nfs archives in this section, the shell script will be slightly modified to implement a grandfather-father-son rotation scheme (monthly-weekly-daily): • the rotation will do a daily backup sunday through friday. • on saturday a weekly backup is done giving you four weekly backups a month. • the monthly backup is done on the first of the month rotating two monthly backups based on if the month is odd or even. here is the new script: #!/ bin /bash #################################### # # backup to nfs mount # grandfather−father−son r o t a t i o n . # #################################### s c r i p t with # what to backup . backup_files=”/home / var / spool / mail / etc / root /boot /opt ” # where to backup to . dest=”/mnt/backup” the archive filename . f o r # setup v a r i a b l e s day=$ ( date +%a) hostname=$ ( hostname−s ) 303

304

i s . then then then then e l i f (( $day_num > 21 && $day_num < 32 ) ) ; e l i f (( $day_num > 14 && $day_num <= 21 ) ) ; e l i f (( $day_num > 7 && $day_num <= 14 ) ) ; # find which week of day_num=$ ( date +%−d) (( $day_num <= 7 ) ) ; the month i s odd or even . the month 1−4 i t week_file=”$hostname−week1 . tgz ” week_file=”$hostname−week2 . tgz ” week_file=”$hostname−week3 . tgz ” week_file=”$hostname−week4 . tgz ” [ $month−eq 0 ] ; month_file=”$hostname−month2 . tgz ” month_file=”$hostname−month1 . tgz ” a r c h i v e _ f i l e=”$hostname−$day . tgz ” [ $day_num == 1 ] ; a r c h i v e _ f i l e=$month_file [ $day != ” saturday ” ] ; a r c h i v e _ f i l e=$week_file # find i f month_num=$ ( date +%m) month=$ ( expr $month_num % 2) i f then # create archive filename . then i f e l i f e l s e e l s e f i i f f i f i then s t a r t # print status message . echo ” backing up $backup_files date echo to $dest / $ a r c h i v e _ f i l e ” # backup the tar c z f $dest / $ a r c h i v e _ f i l e $backup_files f i l e s using tar . # print end status message . echo echo ”backup f i n i s h e d ” date l s−lh $dest / # long l i s t i n g of f i l e s in $dest to check f i l e s i z e s . the script can be executed using the same methods as in executing the script. as discussed in the introduction, a copy of the backup archives and/or media can then be transferred off-site. tape drives a tape drive attached to the server can be used instead of an nfs share. using a tape drive simplifies archive rotation, and makes taking the media off-site easier as well. 304

305

when using a tape drive, the filename portions of the script aren’t needed because the data is sent directly to the tape device. some commands to manipulate the tape are needed. this is accomplished using mt, a magnetic tape control utility part of the cpio package. here is the shell script modified to use a tape drive: #!/ bin /bash #################################### # # backup to tape drive # #################################### s c r i p t . # what to backup . backup_files=”/home / var / spool / mail / etc / root /boot /opt ” # where to backup to . dest=”/dev/ st0 ” s t a r t # print status message . echo ” backing up $backup_files date echo to $dest ” # make sure the tape i s rewound . rewind mt−f $dest mt−f $dest # backup the tar c z f $dest $backup_files f i l e s using tar . # rewind and e j e c t r e w o f f l the tape . # print end status message . echo echo ”backup f i n i s h e d ” date note the default device name for a scsi tape drive is /dev/st0. use the appropriate device path for your system. restoring from a tape drive is basically the same as restoring from a file. simply rewind the tape and use the device path instead of a file path. for example to restore the /etc/hosts file to /tmp/etc/hosts: mt−f /dev/ st0 rewind tar−xzf /dev/ st0−c /tmp etc / hosts bacula bacula is a backup program enabling you to backup, restore, and verify data across your network. there are bacula clients for linux, windows, and mac os x - making it a cross-platform network wide solution. 305

306

overview bacula is made up of several components and services used to manage which files to backup and backup locations: • bacula director: a service that controls all backup, restore, verify, and archive operations. • bacula console: an application allowing communication with the director. there are three versions of the console: – text based command line version. – gnome based gtk+ graphical user interface (gui) interface. – wxwidgets gui interface. • bacula file: also known as the bacula client program. this application is installed on machines to be backed up, and is responsible for the data requested by the director. • bacula storage: the programs that perform the storage and recovery of data to the physical media. • bacula catalog: is responsible for maintaining the file indexes and volume databases for all files backed up, enabling quick location and restoration of archived files. the catalog supports three different databases mysql, postgresql, and sqlite. • bacula monitor: allows the monitoring of the director, file daemons, and storage daemons. currently the monitor is only available as a gtk+ gui application. these services and applications can be run on multiple servers and clients, or they can be installed on one machine if backing up a single disk or volume. installation note if using mysql or postgresql as your database, you should already have the services available. bacula will not install them for you. for more information take a look at databases -mysql and databases - postgresql. there are multiple packages containing the different bacula components. to install bacula, from a terminal prompt enter: sudo apt i n s t a l l bacula by default installing the bacula package will use a postgresql database for the catalog. if you want to use sqlite or mysql, for the catalog, install bacula−director−sqlite3 or bacula−director−mysql respectively. during the install process you will be asked to supply a password for the database owner of the bacula database. configuration bacula configuration files are formatted based on resources comprising of directives surrounded by “{}” braces. each bacula component has an individual file in the /etc/bacula directory. the various bacula components must authorize themselves to each other. this is accomplished using the password directive. for example, the storage resource password in the /etc/bacula/bacula−dir.conf file must match the director resource password in /etc/bacula/bacula−sd.conf. 306

307

by default the backup job named backupclient1 is configured to archive the bacula catalog. if you plan on using the server to backup more than one client you should change the name of this job to something more descriptive. to change the name edit /etc/bacula/bacula−dir.conf: # # define the main nightly save backup job # job { job w i l l back up to disk in by default , t h i s name = ” backupserver ” jobdefs = ” defaultjob ” write bootstrap = ”/ var / l i b / bacula / client1 . bsr ” } note the example above changes the job name to backupserver matching the machine’s host name. replace “backupserver” with your appropriate hostname, or other descriptive name. the console can be used to query the director about jobs, but to use the console with a non-root user, the user needs to be in the bacula group. to add a user to the bacula group enter the following from a terminal: sudo adduser $username bacula note replace $username with the actual username. also, if you are adding the current user to the group you should log out and back in for the new permissions to take effect. localhost backup this section describes how to backup specified directories on a single host to a local tape drive. device { # when device opened , name = ”tape drive ” device type = tape archive device = /dev/ st0 hardware end of medium = no ; automaticmount = yes ; alwaysopen = yes ; removablemedia = yes ; randomaccess = no ; • first, the storage device needs to be configured. edit /etc/bacula/bacula−sd.conf add: media type = dds−4 alert command = ” sh−c • after editing /etc/bacula/bacula−sd.conf the storage daemon will need to be restarted: • now add a storage resource in /etc/bacula/bacula−dir.conf to use the new device: ’ tape info−f %c | grep tapealert ’ ” r e s t a r t bacula−sd . s e r v i c e sudo systemctl the example is for a dds-4 tape drive. adjust the “media type” and “archive device” to match your hardware. you could also uncomment one of the other examples in the file. } read i t 307

308

# d e f i n i t i o n of ”tape drive ” storage device storage { name = tapedrive # do not use ” l o c a l h o s t ” here address = backupserver here sdport = 9103 password = ”cv70f6pf1t6pbopt4vqonigdrr0v3lt3cgkiyjc” device = ”tape drive ” media type = tape # n.b. use a f u l l y q u a l i f i e d name the address directive needs to be the fully qualified domain name (fqdn) of the server. change backupserver to the actual host name. also, make sure the password directive matches the password string in /etc/bacula/bacula−sd.conf. • create a new fileset, which will determine what directories to backup, by adding: # localhostbacup f i l e s e t . f i l e s e t { name = ” l o c a l h o s t f i l e s ” include { options { signature = md5 compression=gzip } f i l e = / etc f i l e = /home } } } } } this fileset will backup the /etc and /home directories. the options resource directives configure the fileset to create an md5 signature for each file backed up, and to compress the files using gzip. • next, create a new schedule for the backup job: # localhostbackup schedule−− daily . name = ” localhostdaily ” run = full d a i l y at 00:01 schedule { the job will run every day at 00:01 or 12:01 am. there are many other scheduling options available. • finally create the job: # localhost backup . job { name = ” localhostbackup ” jobdefs = ” defaultjob ” enabled = yes level = full f i l e s e t = ” l o c a l h o s t f i l e s ” schedule = ” localhostdaily ” storage = tapedrive write bootstrap = ”/ var / l i b / bacula / localhostbackup . bsr ” 308

309

the job will do a full backup every day to the tape drive. • each tape used will need to have a label. if the current tape does not have a label bacula will send an email letting you know. to label a tape using the console enter the following from a terminal: bconsole • at the bacula console prompt enter: l a b e l • you will then be prompted for the storage resource: automatically s e l e c t e d catalog : mycatalog using catalog ”mycatalog” the defined storage r e s o u r c e s are : 1: f i l e 2: tapedrive s e l e c t storage resource (1−2) :2 • enter the new volume name: enter new volume name : sunday defined pools : 1: default 2: scratch replace sunday with the desired label. • now, select the pool: the pool (1−2) : 1 s e l e c t connecting to storage daemon tapedrive at backupserver :9103 . . . sending l a b e l command f o r volume ”sunday” slot 0 . . . congratulations, you have now configured bacula to backup the localhost to an attached tape drive. resources • for more bacula configuration options, refer to bacula’s documentation. • the bacula home page contains the latest bacula news and developments. • also, see the bacula ubuntu wiki page. shell scripts one of the simplest ways to backup a system is using a shell script. for example, a script can be used to configure which directories to backup, and pass those directories as arguments to the tar utility, which creates an archive file. the archive file can then be moved or copied to another location. the archive can also be created on a remote file system such as an nfs mount. the tar utility creates one archive file out of many files or directories. tar can also filter the files through compression utilities, thus reducing the size of the archive file. 309

310

simple shell script the following shell script uses tar to create an archive file on a remotely mounted nfs file system. the archive filename is determined using additional command line utilities. #!/ bin /bash #################################### # # backup to nfs mount # #################################### s c r i p t . # what to backup . backup_files=”/home / var / spool / mail / etc / root /boot /opt ” # where to backup to . dest=”/mnt/backup” # create archive filename . day=$ ( date +%a) hostname=$ ( hostname−s ) a r c h i v e _ f i l e=”$hostname−$day . tgz ” s t a r t # print status message . echo ” backing up $backup_files date echo to $dest / $ a r c h i v e _ f i l e ” # backup the tar c z f $dest / $ a r c h i v e _ f i l e $backup_files f i l e s using tar . # print end status message . echo echo ”backup f i n i s h e d ” date l s−lh $dest # long l i s t i n g of f i l e s in $dest to check f i l e s i z e s . • $backup_files: a variable listing which directories you would like to backup. the list should be cus- tomized to fit your needs. • $day: a variable holding the day of the week (monday, tuesday, wednesday, etc). this is used to create an archive file for each day of the week, giving a backup history of seven days. there are other ways to accomplish this including using the date utility. • $hostname: variable containing the short hostname of the system. using the hostname in the archive filename gives you the option of placing daily archive files from multiple systems in the same directory. • $archive_file: the full archive filename. • $dest: destination of the archive file. the directory needs to be created and in this case mounted before executing the backup script. see ??? for details of using nfs. • status messages: optional messages printed to the console using the echo utility. • tar czf𝑑𝑒𝑠𝑡/archive_file $backup_files: the tar command used to create the archive file. 310

311

– c: creates an archive. – z: filter the archive through the gzip utility compressing the archive. – f: output to an archive file. otherwise the tar output will be sent to stdout. • ls -lh $dest: optional statement prints a -l long listing in -h human readable format of the destination directory. this is useful for a quick file size check of the archive file. this check should not replace testing the archive file. this is a simple example of a backup shell script; however there are many options that can be included in such a script. see references for links to resources providing more in-depth shell scripting information. executing the script executing from a terminal the simplest way of executing the above backup script is to copy and paste the contents into a file. backup.sh for example. the file must be made executable: chmod u+x backup . sh then from a terminal prompt: sudo ./ backup . sh this is a great way to test the script to make sure everything works as expected. executing with cron the cron utility can be used to automate the script execution. the cron daemon allows the execution of scripts, or commands, at a specified time and date. cron is configured through entries in a crontab file. crontab files are separated into fields: # m h dom mon dow command • m: minute the command executes on, between 0 and 59. • h: hour the command executes on, between 0 and 23. • dom: day of month the command executes on. • mon: the month the command executes on, between 1 and 12. • dow: the day of the week the command executes on, between 0 and 7. sunday may be specified by using 0 or 7, both values are valid. • command: the command to execute. to add or change entries in a crontab file the crontab -e command should be used. also, the contents of a crontab file can be viewed using the crontab -l command. to execute the backup.sh script listed above using cron. enter the following from a terminal prompt: sudo crontab−e note using sudo with the crontab -e command edits the root user’s crontab. this is necessary if you are backing up directories only the root user has access to. 311

312

add the following entry to the crontab file: # m h dom mon dow 0 0 * * * bash / usr / l o c a l / bin /backup . sh command the backup.sh script will now be executed every day at 12:00 pm. note the backup.sh script will need to be copied to the /usr/local/bin/ directory in order for this entry to execute properly. the script can reside anywhere on the file system, simply change the script path appropriately. for more in-depth crontab options see references. restoring from the archive once an archive has been created it is important to test the archive. the archive can be tested by listing the files it contains, but the best test is to restore a file from the archive. • to see a listing of the archive contents. from a terminal prompt type: tar−t z v f /mnt/backup/ host−monday . tgz tar−xzvf /mnt/backup/ host−monday . tgz−c /tmp etc / hosts • to restore a file from the archive to a different directory enter: the -c option to tar redirects the extracted files to the specified directory. the above example will extract the /etc/hosts file to /tmp/etc/hosts. tar recreates the directory structure that it contains. also, notice the leading “/” is left off the path of the file to restore. cd / • to restore all files in the archive enter the following: sudo tar−xzvf /mnt/backup/ host−monday . tgz note this will overwrite the files currently on the file system. references • for more information on shell scripting see the advanced bash-scripting guide • the book teach yourself shell programming in 24 hours is available online and a great resource for shell scripting. • the cronhowto wiki page contains details on advanced cron options. • see the gnu tar manual for more tar options. • the wikipedia backup rotation scheme article contains information on other backup rotation schemes. • the shell script uses tar to create the archive, but there many other command line utilities that can be used. for example: – cpio: used to copy files to and from archives. – dd: part of the coreutils package. a low level utility that can copy data from one format to another. 312

313

– rsnapshot: a file system snapshot utility used to create copies of an entire file system. also check the tools - rsnapshot for some information. – rsync: a flexible utility used to create incremental copies of files. lamp applications overview lamp installations (linux + apache + mysql + php/perl/python) are a popular setup for ubuntu servers. there is a plethora of open source applications written using the lamp application stack. some popular lamp applications are wiki’s, content management systems, and management software such as phpmyadmin. one advantage of lamp is the substantial flexibility for different database, web server, and scripting lan- guages. popular substitutes for mysql include postgresql and sqlite. python, perl, and ruby are also frequently used instead of php. while nginx, cherokee and lighttpd can replace apache. the fastest way to get started is to install lamp using tasksel. tasksel is a debian/ubuntu tool that installs multiple related packages as a co-ordinated “task” onto your system. to install a lamp server: at a terminal prompt enter the following command: sudo t a s k s e l i n s t a l l lamp−s e r v e r after installing it you’ll be able to install most lamp applications in this way: • download an archive containing the application source files. • unpack the archive, usually in a directory accessible to a web server. • depending on where the source was extracted, configure a web server to serve the files. • configure the application to connect to the database. • run a script, or browse to a page of the application, to install the database needed by the application. • once the steps above, or similar steps, are completed you are ready to begin using the application. a disadvantage of using this approach is that the application files are not placed in the file system in a standard way, which can cause confusion as to where the application is installed. another larger disadvantage is updating the application. when a new version is released, the same process used to install the application is needed to apply updates. fortunately, a number of lamp applications are already packaged for ubuntu, and are available for instal- lation in the same way as non-lamp applications. depending on the application some extra configuration and setup steps may be needed, however. this section covers how to install some lamp applications. moin moin moinmoin is a wiki engine implemented in python, based on the pikipiki wiki engine, and licensed under the gnu gpl. 313

314

installation to install moinmoin, run the following command in the command prompt: sudo apt i n s t a l l python−moinmoin you should also install apache2 web server. for installing the apache2 web server, please refer to ??? sub- section in ??? section. configuration to configure your first wiki application, please run the following set of commands. let us assume that you are creating a wiki named mywiki: cd / usr / share /moin sudo mkdir mywiki sudo cp s e r v e r /moin . c g i mywiki sudo cp−r data mywiki sudo cp−r underlay mywiki sudo chown−r www−data :www−data mywiki sudo chmod−r ug+rwx mywiki sudo chmod−r o−rwx mywiki now you should configure moinmoin to find your new wiki mywiki. to configure moinmoin, open /etc/moin /mywiki.py file and change the following line: data_dir = ’/ org /mywiki/data ’ to data_dir = ’/ usr / share /moin/mywiki/data ’ also, below the data_dir option add the data_underlay_dir: data_underlay_dir =’/ usr / share /moin/mywiki/ underlay ’ note if the /etc/moin/mywiki.py file does not exist, you should copy /usr/share/moin/config/wikifarm /mywiki.py file to /etc/moin/mywiki.py file and do the above mentioned change. note if you have named your wiki as my_wiki_name you should insert a line “(”my_wiki_name“, r”.*“)” in /etc/moin/farmconfig.py file after the line “(”mywiki“, r”.*“)”. once you have configured moinmoin to find your first wiki application, mywiki, you should configure apache2 and make it ready for your wiki. you should add the following lines in /etc/apache2/sites−available/000−default.conf file inside the “<vir- tualhost *>” tag: ### moin s c r i p t a l i a s /mywiki ”/ usr / share /moin/mywiki/moin . c g i ” a l i a s / moin_static<version > ”/ usr / share /moin/ htdocs ” <directory / usr / share /moin/ htdocs> order allow , deny allow from a l l </directory> ### end moin 314

315

the version in the above example is determined by running: $ moin−−version if the output shows version 1.9.7, your second line should be: a l i a s / moin_static197 ”/ usr / share /moin/ htdocs ” once you configure the apache2 web server and make it ready for your wiki application, you should restart it. you can run the following command to restart the apache2 web server: sudo systemctl r e s t a r t apache2 . s e r v i c e verification you can verify the wiki application and see if it works by pointing your web browser to the following url: http :// l o c a l h o s t /mywiki for more details, please refer to the moinmoin web site. references • for more information see the moinmoin wiki. • also, see the ubuntu wiki moinmoin page. phpmyadmin phpmyadmin is a lamp application specifically written for administering mysql servers. written in php, and accessed through a web browser, phpmyadmin provides a graphical interface for database administration tasks. installation before installing phpmyadmin you will need access to a mysql database either on the same host as that phpmyadmin is installed on, or on a host accessible over the network. for more information see ???. from a terminal prompt enter: sudo apt i n s t a l l phpmyadmin at the prompt choose which web server to be configured for phpmyadmin. the rest of this section will use apache2 for the web server. in a browser go to http://servername/phpmyadmin, replacing servername with the server’s actual hostname. at the login, page enter root for the username, or another mysql user, if you have any setup, and enter the mysql user’s password. once logged in you can reset the root password if needed, create users, create/destroy databases and tables, etc. 315

316

configuration the configuration files for phpmyadmin are located in /etc/phpmyadmin. the main configuration file is /etc /phpmyadmin/config.inc.php. this file contains configuration options that apply globally to phpmyadmin. to use phpmyadmin to administer a mysql database hosted on another server, adjust the following in /etc/phpmyadmin/config.inc.php: $cfg [ ’ servers ’ ] [ $i ] [ ’ host ’ ] = ’ db_server ’ ; note replace db_server with the actual remote database server name or ip address. also, be sure that the phpmyadmin host has permissions to access the remote database. once configured, log out of phpmyadmin and back in, and you should be accessing the new server. the config .header.inc.php and config . footer .inc.php files are used to add a html header and footer to phpmyadmin. another important configuration file is /etc/phpmyadmin/apache.conf, this file is symlinked to /etc/apache2/ conf−available/phpmyadmin.conf, and, once enabled, is used to configure apache2 to serve the phpmyadmin sudo ln−s / etc /phpmyadmin/apache . conf / etc /apache2/ conf−a v a i l a b l e /phpmyadmin . site. the file contains directives for loading php, directory permissions, etc. from a terminal type: conf sudo a2enconf phpmyadmin . conf sudo systemctl reload apache2 . s e r v i c e for more information on configuring apache2 see ???. references • the phpmyadmin documentation comes installed with the package and can be accessed from the phpmyadmin documentation link (a question mark with a box around it) under the phpmyadmin logo. the official docs can also be access on the phpmyadmin site. • also, mastering phpmyadmin is a great resource. • a third resource is the phpmyadmin ubuntu wiki page. wordpress wordpress is a blog tool, publishing platform and cms implemented in php and licensed under the gnu gplv2. installation to install wordpress, run the following comand in the command prompt: sudo apt i n s t a l l wordpress you should also install apache2 web server and mysql server. for installing apache2 web server, please refer to ??? sub-section in ??? section. for installing mysql server, please refer to ??? sub-section in ??? section. 316

317

configuration for configuring your first wordpress application, configure an apache site. open /etc/apache2/sites− available/wordpress.conf and write the following lines: alias / blog / usr / share / wordpress <directory / usr / share / wordpress> options followsymlinks allowoverride limit options f i l e i n f o directoryindex index . php order allow , deny allow from a l l </directory > <directory / usr / share / wordpress /wp−content> options followsymlinks order allow , deny allow from a l l </directory > enable this new wordpress site sudo a 2 e n s i t e wordpress once you configure the apache2 web server and make it ready for your wordpress application, you should restart it. you can run the following command to restart the apache2 web server: sudo systemctl r e s t a r t apache2 . s e r v i c e to facilitate multiple wordpress installations, the name of this configuration file is based on the host header of the http request. this means that you can have a configuration per virtualhost by simply matching the hostname portion of this configuration with your apache virtual host. e.g. /etc/wordpress/config- 10.211.55.50.php, /etc/wordpress/config-hostalias1.php, etc. these instructions assume you can access apache via the localhost hostname (perhaps by using an ssh tunnel) if not, replace /etc/wordpress/config- localhost.php with /etc/wordpress/config-name_of_your_virtual_host.php. once the configuration file is written, it is up to you to choose a convention for username and password to mysql for each wordpress database instance. this documentation shows only one, localhost, example. now configure wordpress to use a mysql database. open /etc/wordpress/config−localhost.php file and write the following lines: <?php d e f i n e ( ’db_name’ , d e f i n e ( ’db_user’ , d e f i n e ( ’db_password’ , d e f i n e ( ’db_host’ , d e f i n e ( ’wp_content_dir’ , ?> ’ wordpress ’ ) ; ’ wordpress ’ ) ; ’ l o c a l ho s t ’ ) ; ’ yourpasswordhere ’ ) ; ’/ usr / share / wordpress /wp−content ’ ) ; now create this mysql database. open a temporary file with mysql commands wordpress.sql and write the following lines: create database wordpress ; grant select,insert,update,delete,create,drop,alter on wordpress .* to wordpress@localhost identified by ’ yourpasswordhere ’ ; flush privileges; 317

318

execute these commands. | cat wordpress . s q l sudo mysql−−defaults−extra−f i l e =/etc /mysql/ debian . cnf your new wordpress can now be configured by visiting http://localhost/blog/wp-admin/install.php. (or http://name_of_your_virtual_host/blog/wp-admin/install.php if your server has no gui and you are completing wordpress configuration via a web browser running on another computer.) fill out the site title, username, password, and e-mail and click install wordpress. note the generated password (if applicable) and click the login password. your wordpress is now ready for use. references • wordpress.org codex • ubuntu wiki wordpress lamp applications overview lamp installations (linux + apache + mysql + php/perl/python) are a popular setup for ubuntu servers. there is a plethora of open source applications written using the lamp application stack. some popular lamp applications are wiki’s, content management systems, and management software such as phpmyadmin. one advantage of lamp is the substantial flexibility for different database, web server, and scripting lan- guages. popular substitutes for mysql include postgresql and sqlite. python, perl, and ruby are also frequently used instead of php. while nginx, cherokee and lighttpd can replace apache. the fastest way to get started is to install lamp using tasksel. tasksel is a debian/ubuntu tool that installs multiple related packages as a co-ordinated “task” onto your system. to install a lamp server: at a terminal prompt enter the following command: sudo t a s k s e l i n s t a l l lamp−s e r v e r after installing it you’ll be able to install most lamp applications in this way: • download an archive containing the application source files. • unpack the archive, usually in a directory accessible to a web server. • depending on where the source was extracted, configure a web server to serve the files. • configure the application to connect to the database. • run a script, or browse to a page of the application, to install the database needed by the application. • once the steps above, or similar steps, are completed you are ready to begin using the application. a disadvantage of using this approach is that the application files are not placed in the file system in a standard way, which can cause confusion as to where the application is installed. another larger disadvantage is updating the application. when a new version is released, the same process used to install the application is needed to apply updates. 318

319

fortunately, a number of lamp applications are already packaged for ubuntu, and are available for instal- lation in the same way as non-lamp applications. depending on the application some extra configuration and setup steps may be needed, however. this section covers how to install some lamp applications. phpmyadmin phpmyadmin is a lamp application specifically written for administering mysql servers. written in php, and accessed through a web browser, phpmyadmin provides a graphical interface for database administration tasks. installation before installing phpmyadmin you will need access to a mysql database either on the same host as that phpmyadmin is installed on, or on a host accessible over the network. for more information see mysql documentation. from a terminal prompt enter: sudo apt i n s t a l l phpmyadmin at the prompt choose which web server to be configured for phpmyadmin. the rest of this section will use apache2 for the web server. in a browser go to http://servername/phpmyadmin, replacing servername with the server’s actual hostname. at the login, page enter root for the username, or another mysql user, if you have any setup, and enter the mysql user’s password. once logged in you can reset the root password if needed, create users, create/destroy databases and tables, etc. configuration the configuration files for phpmyadmin are located in /etc/phpmyadmin. the main configuration file is /etc /phpmyadmin/config.inc.php. this file contains configuration options that apply globally to phpmyadmin. to use phpmyadmin to administer a mysql database hosted on another server, adjust the following in /etc/phpmyadmin/config.inc.php: $cfg [ ’ servers ’ ] [ $i ] [ ’ host ’ ] = ’ db_server ’ ; note replace db_server with the actual remote database server name or ip address. also, be sure that the phpmyadmin host has permissions to access the remote database. once configured, log out of phpmyadmin and back in, and you should be accessing the new server. the config .header.inc.php and config . footer .inc.php files in /etc/phpmyadmin directory are used to add a html header and footer to phpmyadmin. another important configuration file is /etc/phpmyadmin/apache.conf, this file is symlinked to /etc/apache2/ conf−available/phpmyadmin.conf, and, once enabled, is used to configure apache2 to serve the phpmyadmin site. the file contains directives for loading php, directory permissions, etc. from a terminal type: 319

320

sudo ln−s / etc /phpmyadmin/apache . conf / etc /apache2/ conf−a v a i l a b l e /phpmyadmin . sudo a2enconf phpmyadmin . conf sudo systemctl reload apache2 . s e r v i c e conf for more information on configuring apache2 see this documentation. references • the phpmyadmin documentation comes installed with the package and can be accessed from the phpmyadmin documentation link (a question mark with a box around it) under the phpmyadmin logo. the official docs can also be access on the phpmyadmin site. • another resource is the phpmyadmin ubuntu wiki page. wordpress wordpress is a blog tool, publishing platform and cms implemented in php and licensed under the gnu gplv2. installation to install wordpress, run the following comand in the command prompt: sudo apt i n s t a l l wordpress you should also install apache2 web server and mysql server. for installing apache2 web server, please refer to apache2 documentation. for installing mysql server, please refer to mysql documentation. configuration for configuring your first wordpress application, configure an apache site. open /etc/apache2/sites− available/wordpress.conf and write the following lines: alias / blog / usr / share / wordpress <directory / usr / share / wordpress> options followsymlinks allowoverride limit options f i l e i n f o directoryindex index . php order allow , deny allow from a l l </directory > <directory / usr / share / wordpress /wp−content> options followsymlinks order allow , deny allow from a l l </directory > enable this new wordpress site sudo a 2 e n s i t e wordpress 320

321

the following lines: <?php d e f i n e ( ’db_name’ , d e f i n e ( ’db_user’ , d e f i n e ( ’db_password’ , d e f i n e ( ’db_host’ , d e f i n e ( ’wp_content_dir’ , ?> ’ wordpress ’ ) ; ’ wordpress ’ ) ; ’ l o c a l ho s t ’ ) ; ’ yourpasswordhere ’ ) ; ’/ usr / share / wordpress /wp−content ’ ) ; once you configure the apache2 web server and make it ready for your wordpress application, you should restart it. you can run the following command to restart the apache2 web server: sudo systemctl reload apache2 . s e r v i c e to facilitate multiple wordpress installations, the name of this configuration file is based on the host header of the http request. this means that you can have a configuration per virtualhost by simply matching the hostname portion of this configuration with your apache virtual host. e.g. /etc/wordpress/config- 10.211.55.50.php, /etc/wordpress/config-hostalias1.php, etc. these instructions assume you can access apache via the localhost hostname (perhaps by using an ssh tunnel) if not, replace /etc/wordpress/config- localhost.php with /etc/wordpress/config-name_of_your_virtual_host.php. once the configuration file is written, it is up to you to choose a convention for username and password to mysql for each wordpress database instance. this documentation shows only one, localhost, example. now configure wordpress to use a mysql database. open /etc/wordpress/config−localhost.php file and write now create this mysql database. open a temporary file with mysql commands wordpress.sql and write the following lines: create database wordpress ; create user ’ wordpress ’@’ l o c a l ho s t ’ identified by ’ yourpasswordhere ’ ; grant select,insert,update,delete,create,drop,alter on wordpress .* to wordpress@localhost ; flush privileges; execute these commands. cat wordpress . s q l | sudo mysql−−defaults−extra−f i l e =/etc /mysql/ debian . cnf your new wordpress can now be configured by visiting http://localhost/blog/wp-admin/install.php. (or http://name_of_your_virtual_host/blog/wp-admin/install.php if your server has no gui and you are completing wordpress configuration via a web browser running on another computer.) fill out the site title, username, password, and e-mail and click install wordpress. note the generated password (if applicable) and click the login password. your wordpress is now ready for use. references • wordpress.org codex • ubuntu wiki wordpress 321

322

using the installer this document explains how to use the installer in general terms. there is another document that contains documentation for each screen of the installer. getting the installer you can download the server installer for amd64 from https://ubuntu.com/download/server and other ar- chitectures from http://cdimage.ubuntu.com/releases/20.04/release/. installer images are made (approximately) daily and are available from http://cdimage.ubuntu.com/ubuntu- server/focal/daily-live/current/. these are not tested as extensively as the images from release day, but they contain the latest packages and installer so fewer updates will be required during or after installation. installer ui generalities in general, the installer can be used with the up and down arrow and space or enter keys and a little typing. tab and shift-tab move the focus down and up respectively. home / end / page up / page down can be used to navigate through long lists more quickly in the usual way. running the installer over serial by default, the installer runs on the first virtual terminal, tty1. this is what is displayed on any connected monitor by default. clearly though, servers do not always have a monitor. some out-of-band management systems provide a remote virtual terminal, but some times it is necessary to run the installer on the serial port. to do this, the kernel command line needs to have an appropriate console specified on it – a common value is console=ttys0 but this is not something that can be generically documented. when running on serial, the installer starts in a basic mode that does using only the ascii character set and black and white colours. if you are connecting from a terminal emulator such as gnome-terminal that supports unicode and rich colours you can switch to “rich mode” which uses unicode, colours and supports many languages. ## connecting to the installer over ssh if the only available terminal is very basic, an alternative is to connect via ssh. if the network is up by the time the installer starts, instructions are offered on the initial screen in basic mode. otherwise, instructions are available from the help menu once networking is configured. in addition, connecting via ssh is assumed to be capable of displaying all unicode characters, enabling more translations to be used than can be displayed on a virtual terminal. help menu the help menu is always in the top right of the screen. it contains help, both general and for the currently displayed screen, and some general actions. switching to a shell prompt you can switch to a shell at any time by selecting “enter shell” from the help menu, or pressing control-z or f2. 322

323

if you are accessing the installer via tty1, you can also access a shell by switching to a different virtual terminal (control-alt-arrow or control-alt-number keys move between virtual terminals). global keys there are some global keys you can press at any time: key esc f1 control-z, f2 control-l, f3 control-t, f4 action go back open help menu switch to shell redraw screen toggle rich mode (colour, unicode) on and off using the installer step by step the installer is designed to be easy to use without constant reference to documentation. language selection welcome_c|690x517 this screen selects the language for the installer and the default language for the installed system. more languages can be displayed if you connect via ssh. refresh refresh|690x517 this screen is shown if there is an update for the installer available. this allows you to get improvements and bug fixes made since release. if you choose to update, the new version will be downloaded and the installer will restart at the same point of the installation. keyboard keyboard|690x517 choose the layout and variant of keyboard attached to the system, if any. when running in a virtual terminal, it is possible to guess the layout and variant by answering questions about the keyboard. zdev (s390x only) ==================================================================== ==================================================================== online names ^ zdev setup id ฀ 323

324

0.0.0009 0 . 0 . 0 0 0 c 0 . 0 . 0 0 0 d 0 . 0 . 0 0 0 e generic−ccw ฀ dasd−eckd ฀ 0.0.0190 0.0.0191 0 . 0 . 0 1 9 d 0 . 0 . 0 1 9 e ฀฀฀฀฀฀฀฀฀฀฀฀฀฀ 0.0.0200 ฀ 0.0.0300 ฀ 0.0.0400 ฀ 0.0.0592 ฀฀฀฀฀฀฀฀฀฀฀฀฀฀ > ฀ > ฀ > ฀ > ฀฀ > ฀ > ฀ > ฀ > > >< ( c l o s e ) ฀ > enable ฀ > disable ฀ v [ continue [ back ] ] this screen is only shown on s390x and allows z-specific configuration of devices. the list of device can be long. home / end / page up / page down can be used to navigate through the list more quickly. network network|690x517 this screen allows the configuration of the network. ubuntu server uses netplan to configure networking and the ui of the installer can configure a subset of netplan’s capabilities. in particular it can configure dhcp or static addressing, vlans and bonds. if networking is present (defined as “at least one interface has a default route”) then the installer will install updates from the archive at the end of installation. proxy proxy|690x517 the proxy configured on this screen is used for accessing the package repository and the snap store both in the installer environment and in the installed system. mirror mirror|690x517 the installer will attempt to use geoip to look up an appropriate default package mirror for your location. if you want or need to use a different mirror, enter its url here. storage storage_config|690x517 storage configuration is a complicated topic and has its own page for documentation. 324

325

storage_confirm|690x517 once the storage configuration is confirmed, the install begins in the background. identity identity|690x517 the default user will be an administrator, able to use sudo (this is why a password is needed, even if ssh public key access is enabled on the next screen). ssh ssh|690x517 a default ubuntu install has no open ports. it is very common to administer servers via ssh so the installer allows it to be installed with the click of a button. you can import keys for the default user from github or launchpad. if you import a key, then password authentication is disabled by default but it can be re-enabled again if you wish. snaps snaps|690x517 if a network connection is enabled, a selection of snaps that are useful in a server environment are presented and can be selected for installation. installation logs install_progress|690x517 the final screen of the installer shows the progress of the installer and allows viewing of the full log file. once the install has completed and security updates installed, the installer waits for confirmation before restarting. install_done|690x517 configuring storage in the server installer guided options storage_guided|690x517 selecting “use an entire disk” on the guided storage configuration screen will install ubuntu onto the selected disk, replacing any partitions or data already there. you can choose whether or not to set up lvm, and if you do whether or not to encrypt the volume with luks. if you encrypt the volume, you need to choose a passphrase that will need to be entered each time the system boots. if you select “custom storage layout” no configuration will be applied to the disks. 325

326

in either case, the installer moves onto the main storage customization screen. the main storage screen storage_manual|690x517 this screen presents a summary of the current storage configuration. each device or partition of a device corresponds to a selectable row, and pressing enter or space while a device is selected opens a menu of actions that apply to that device. partitions add_partition_menu|608x157 to add a partition to a device, select “add gpt partition” for that device. add_dialog|690x517 you can leave size blank to use all the remaining space on the device. raid add_raid|690x517,100% linux software raid (raid stands for “redundant array of inexpensive disks”) can be used to combine several disks into a single device that (usually) is tolerant to any one disk failure. a software raid device can be created out of entire disks or unformatted partitions. select the “create software raid (md)” button to open the creation dialog. the server installer supports creating devices with raid level 0, 1, 5, 6 or 10. it does not allow customizing other options such as metadata format or raid10 layout at this time. see the linux raid documentation for more. a software raid device can be formatted and mounted directly, or partitioned into several partitions (or even be used as part of another raid device or lvm volume group). lvm add_lvm|690x517 lvm (the “logical volume manager”) is a system of managing logical volumes, or filesystems, that is much more advanced and flexible than the traditional method of partitioning a disk into one or more segments and formatting that partition with a filesystem. it can be used to combine several disks into one larger pool of storage but it offers advantages even in a single disk system, such as snapshots and easy resizing of logical volumes. as with raid, a lvm volume group can be created out of entire disks or unformatted partitions. select the “create volume group (lvm)” button to open the creation dialog. once a volume group has been created, it can be divided into named logical volumes which can then be formatted and mounted. it generally makes sense to leave some space in the volume group for storage of snapshots and creation of more logical volumes as needed. the server installer does not supported configuring any of the many, many options lvm supports when creating volume groups and logical volumes. 326

327

selecting boot devices add_boot_device|614x163 on all architectures other than s390x, the bootloader needs to be installed to a disk in a way such that the system firmware can find it on boot. by default, the first device to have a partition created on it is selected as a boot device but this can be changed later. on amd64 and arm64 systems, multiple disks can be selected as boot devices, which means a system can be configured so that it will continue to boot after a failure of any one drive (assuming the root filesystem is placed on a raid). the bootloader will be installed to each of these drives, and the operating system configured to install new versions of grub to each drive as it is updated. amd64 systems use grub as the bootloader. amd64 systems can boot in either uefi or legacy (sometimes called “bios”) mode (many systems can be configured to boot in either mode) and the bootloader is located completely differently in the two modes. in legacy mode, the bootloader is read from the first “sector” of a hard drive (exactly which hard drive is up to the system firmware, which can usually be configured in a vendor specific way). the installer will write grub to the start of all disks selected as a boot devices. as grub does not entirely fit in one sector, a small unformatted partition is needed at the start of the disk, which will automatically be created when a disk is selected as a boot device (a disk with an existing gpt partition table can only be used as a boot device if it has this partition). in uefi mode, the bootloader loaded from a “efi system partition” (esp), which is a partition with a particular type guid. the installer automatically creates an 512mib esp on a disk when it is selected as a boot device and will install grub to there (a disk with an existing partition table can only be used as a boot device if it has an esp – bootloaders for multiple operating systems can be installed into a single esp). uefi defines a standard way to configure the way in which the operating system is chosen on boot, and the installer uses this to configure the system to boot the just-installed operating system. one of the esps must be mounted at /boot/efi. supported arm64 servers boot using uefi, and are configured the same way as an uefi-booting amd64 system. ppc64el systems also load their bootloader (petitboot, a small linux kernel) from a “prep” partition with a special flag, so in most ways they are similar to a uefi system. the installer only supports one prep partition at this time. limitations and workarounds currently the installer cannot edit partition tables. you can use existing partitions or reformat a drive entirely but you cannot, for example, remove a large partition and replace it with two smaller ones. the installer allows the creation of lvm volume groups and logical volumes and md raid devices, but does not allow tweaking of the parameters – for example, all logical volumes are linear and all md raid devics use the default metadata format (1.2). these limits can both be worked around in the same way: drop to a shell and use the usual shell commands to edit the partition table or create the lv or raid with desired parameters, and then select these partitions or devices as mount points in the installer. any changes you make while the installer is running but before altering the storage configuration will reflected in the installer. the installer cannot yet configure iscsi mounts, zfs at all, or btrfs subvolumes. 327

328

automated server installs introduction the server installer for 20.04 supports a new mode of operation: automated installation, autoinstallation for short. you might also know this feature as unattended or handsoff or preseeded installation. autoinstallation lets you answer all those configuration questions ahead of time with an autoinstall config and lets the installation process run without any interaction. differences from debian-installer preseeding preseeds are the way to automate an installer based on debian-installer (aka d-i). autoinstalls for the new server installer differ from preseeds in the following main ways: • the format is completely different (cloud-init config, usually yaml, vs debconf-set-selections format) • when the answer to a question is not present in a preseed, d-i stops and asks the user for input. autoinstalls are not like this: by default, if there is any autoinstall config at all, the installer takes the default for any unanswered question (and fails if there is no default). – you can designate particular sections in the config as “interactive”, which means the installer will still stop and ask about those. providing the autoinstall config the autoinstall config is provided via cloud-init configuration, which is almost endlessly flexible. in most scenarios the easiest way will be to provide user-data via the nocloud data source. the autoinstall config should be provided under the autoinstall key in the config. for example: #cloud−c o n f i g a u t o i n s t a l l : version : 1 . . . running a truly automatic autoinstall even if a fully noninteractive autoinstall config is found, the server installer will ask for confirmation before writing to the disks unless autoinstall is present on the kernel command line. this is to make it harder to accidentally create a usb stick that will reformat a machine it is plugged into at boot. many autoinstalls will be done via netboot, where the kernel command line is controlled by the netboot config – just remember to put autoinstall in there! quick start so you just want to try it out? well we have the page for you. 328

329

creating an autoinstall config the snap described here does not yet exist when any system is installed using the server installer, an autoinstall file for repeating the install is created autoinstall config (it is actually mostly the same code as that that runs the installation in interactive mode). # s t a r t at /var/log/ installer /autoinstall−user−data. alternatively there is a snap, autoinstall−editor, that can be used to either edit or create from scratch an $ a u t o i n s t a l l−e d i t o r $ a u t o i n s t a l l−e d i t o r−−create > my−a u t o i n s t a l l . yaml $ a u t o i n s t a l l−e d i t o r my−a u t o i n s t a l l . yaml # dump out to stdout a complete a u t o i n s t a l l c o n f i g with d e f a u l t answers e d i t i n g new c o n f i g f i l e everywhere # e d i t e x i s t i n g a u t o i n s t a l l c o n f i g the structure of an autoinstall config the autoinstall config has full documentation. technically speaking the config is not defined as a textual format, but cloud-init config is usually provided as yaml so that is the syntax the documentation uses. a minimal config is: version : 1 i d e n t i t y : hostname : hostname username : username password : $crypted_pass here is an example file that shows off most features: many keys and values correspond straightforwardly to questions the installer asks (e.g. keyboard selection). see the reference for details of those that do not. error handling progress through the installer is reported via the reporting system, including errors. in addition, when a fatal error occurs, the error−commands are executed and the traceback printed to the console. the server then just waits. possible future directions we might want to extend the ‘match specs’ for disks to cover other ways of selecting disks. 329

330

autoinstall quick start the intent of this page is to provide simple instructions to perform an autoinstall in a vm on your machine. this page assumes you are on the amd64 architecture. there is a version for s390x too. providing the autoinstall data over the network this method is the one that generalizes most easily to doing an entirely network based install, where a machine netboots and then is automatically installed. download the iso mount the iso write your autoinstall config this means creating cloud-init config as follows: the crypted password is just “ubuntu”. serve the cloud-init config over http leave this running in one terminal window: create a target disk run the install! this will boot, download the config from the server set up in the previous step and run the install. the installer reboots at the end but the -no-reboot flag to kvm means that kvm will exit when this happens. it should take about 5 minutes. boot the installed system this will boot into the freshly installed system and you should be able to log in as ubuntu/ubuntu. using another volume to provide the autoinstall config this is the method to use when you want to create media that you can just plug into a system to have it be installed. download the iso create your user-data & meta-data files the crypted password is just “ubuntu”. 330

331

create an iso to use as a cloud-init data source create a target disk run the install! this will boot, download the config from the server set up in the previous step and run the install. unless you interrupt boot to add ‘autoinstall’ to the kernel command line, the installer will prompt for confirmation before touching the disk. the installer reboots at the end but the -no-reboot flag to kvm means that kvm will exit when this happens. the whole process should take about 5 minutes. boot the installed system this will boot into the freshly installed system and you should be able to log in as ubuntu/ubuntu. json schema for autoinstall config introduction the server installer validates the provided autoinstall config against a json schema. how the config is validated although the schema is presented below as a single document, and if you want to pre-validate your config you should validate it against this document, the config is not actually validated against this document at run time. what happens instead is that some sections are loaded, validated and applied first, before all other sections are validated. in detail: 1. the reporting section is loaded, validated and applied. 2. the error commands are loaded and validated. 3. the early commands are loaded and validated. 4. the early commands, if any, are run. 5. the config is reloaded, and now all sections are loaded and validated. this is so that validation errors in most sections can be reported via the reporting and error-commands configuration, as all other errors are. schema the json schema for autoinstall data is as follows: regeneration the schema above can be regenerated by running “make schema” in a subiquity source checkout. 331

332

automated server installs config file reference overall format the autoinstall file is yaml. at top level it must be a mapping containing the keys described in this document. unrecognized keys are ignored. schema autoinstall configs are validated against a json schema before they are used. # command lists several config keys are lists of commands to be executed. each command can be a string (in which case it is executed via “sh -c”) or a list, in which case it is executed directly. any command exiting with a non-zero return code is considered an error and aborts the install (except for error-commands, where it is ignored). top-level keys ## version type: integer default: no default a future-proofing config file version field. currently this must be “1”. ## interactive-sections type: list of strings default: [] a list of config keys to still show in the ui. so for example: version : 1 i n t e r a c t i v e−s e c t i o n s : − network i d e n t i t y : username : ubuntu password : $crypted_pass would stop on the network screen and allow the user to change the defaults. if a value is provided for an interactive section it is used as the default. you can use the special section name of ”*” to indicate that the installer should ask all the usual questions – in this case, the autoinstall .yaml file is not really an “autoinstall” file at all, instead just a way to change the defaults in the ui. not all config keys correspond to screens in the ui. this documentation indicates if a given section can be interactive or not. if there are any interactive sections at all, the reporting key is ignored. ## early-commands type: command list default: no commands can be interactive: no a list of shell commands to invoke as soon as the installer starts, in particular before probing for block and network devices. the autoinstall config is available at /autoinstall .yaml (irrespective of how it was 332

333

if necessary. ## locale provided) and the file will be re-read after the early−commands have run to allow them to alter the config type: string default: en_us.utf−8 can be interactive: yes, always interactive if any section is the locale to configure for the installed system. ## refresh-installer type: mapping default: see below can be interactive: yes controls whether the installer updates to a new version available in the given channel before continuing. the mapping contains keys: update type: boolean default: no whether to update or not. channel type: string default: ”stable/ubuntu−$rel” the channel to check for updates. ## keyboard type: mapping, see below default: us english keyboard can be interactive: yes the layout of any attached keyboard. often systems being automatically installed will not have a keyboard at all in which case the value used here does not matter. the mapping’s keys correspond to settings in the /etc/default/keyboard configuration file. see its manual page for more details. the mapping contains keys: layout type: string default: ”us” corresponds to the xkblayout setting. variant type: string default: ”” corresponds to the xkbvariant setting. 333

334

toggle type: string or null default: null corresponds to the value of grp: option from the xkboptions setting. acceptable values are (but note that the installer does not validate these): caps_toggle, toggle, rctrl_toggle, rshift_toggle, rwin_toggle, menu_toggle, alt_shift_toggle, ctrl_shift_toggle, ctrl_alt_toggle, alt_caps_toggle, lctrl_lshift_toggle , lalt_toggle, lctrl_toggle, lshift_toggle , lwin_toggle, sclk_toggle the version of subiquity released with 20.04 ga does not accept null for this field due to a bug. ## network type: netplan-format mapping, see below default: dhcp on interfaces named eth* or en* can be inter- active: yes netplan formatted network configuration. this will be applied during installation as well as in the installed system. the default is to interpret the config for the install media, which runs dhcpv4 on any interface with a name matching “eth” or ”en” but then disables any interface that does not receive an address. for example, to run dhcp6 on a particular nic: network : version : 2 ethernets : enp0s31f6 : dhcp6 : yes note that thanks to a bug, the version of subiquity released with 20.04 ga forces you to write this with an extra “network:” key like so: network : network : version : 2 ethernets : enp0s31f6 : dhcp6 : yes later versions support this syntax too for compatibility but if you can assume a newer version you should use the former. ## proxy type: url or null default: no proxy can be interactive: yes the proxy to configure both during installation and for apt and for snapd in the target system. ## apt type: mapping default: see below can be interactive: yes apt configuration, used both during the install and once booted into the target system. this uses the same format as curtin which is documented at https://curtin.readthedocs.io/en/latest/topics/apt_source.html, with one extension: the geoip key controls whether a geoip lookup is done. the default is: apt : preserve_sources_list : f a l s e primary :− arches : [ i386 , amd64 ] u r i : ” http :// archive . ubuntu . com/ubuntu” 334

335

− arches : u r i : ” http :// ports . ubuntu . com/ubuntu−ports ” [ d e f a u l t ] true geoip : if geoip is true and the mirror to be used is the default, a request is made to https://geoip.ubuntu.com/ lookup and the mirror uri to be used changed to be http://cc.archive.ubuntu.com/ubuntu where cc is the country code returned by the lookup (or similar for ports). if this section is not interactive, the request is timed out after 10 seconds. any supplied config is merged with the default rather than replacing it. if you just want to set a mirror, use a config like this: apt : to add a ppa: apt : [ d e f a u l t ] u r i : your_mirror_goes_here primary :− arches : curtin−ppa : source : ppa : curtin−dev/ test−archive sources : ## storage type: mapping, see below default: use “lvm” layout in a single disk system, no default in a multiple disk system can be interactive: yes storage configuration is a complex topic and the description of the desired configuration in the autoinstall file can necessarily also be complex. the installer supports “layouts”, simple ways of expressing common configurations. supported layouts the two supported layouts at the time of writing are “lvm” and “direct”. storage : layout : name : storage : layout : lvm name : d i r e c t by default these will install to the largest disk in a system, but you can supply a match spec (see below) to indicate which disk to use: storage : layout : name : match : lvm s e r i a l : ct* storage : layout : name : disk match : ssd : yes 335

336

(you can just say “match: {}” to match an arbitrary disk) the default is to use the lvm layout. action-based config for full flexibility, the installer allows storage configuration to be done using a syntax which is a superset of that supported by curtin, described at https://curtin.readthedocs.io/en/latest/topics/storage.html. as well as putting the list of actions under the ‘config’ key, the grub and swap curtin config items can be put here. so a storage section might look like: storage : swap : s i z e : 0 c o n f i g :− type : disk − type : p a r t i t i o n . . . id : disk0 s e r i a l : adata_sx8200pnp_xxxxxxxxxxx the extensions to the curtin syntax are around disk selection and partition/logical volume sizing. disk selection extensions curtin supported identifying disks by serial (e.g. crucial_ct512mx100ssd1_14250c57fece ) or by path (e.g. /dev/sdc) and the server installer supports this as well. the installer additionally supports a ‘’match spec” on a disk action that supports more flexible matching. the actions in the storage config are processed in the order they are in the autoinstall file. any disk action is assigned a matching disk – chosen arbitrarily from the set of unassigned disks if there is more than one, and causing the installation to fail if there is no unassigned matching disk. a match spec supports the following keys: • model: foo: matches a disk where id_vendor=foo in udev, supporting globbing • path: foo: matches a disk where devpath=foo in udev, supporting globbing (the globbing support distinguishes this from specifying path: foo directly in the disk action) • serial : foo: matches a disk where id_serial=foo in udev, supporting globbing (the globbing sup- port distinguishes this from specifying serial: foo directly in the disk action) • ssd: yes|no: matches a disk that is or is not an ssd (vs a rotating drive) • size : largest |smallest: take the largest or smallest disk rather than an arbitrary one if there are multiple matches (support for smallest added in version 20.06.1) so for example, to match an arbitrary disk it is simply: − type : disk id : disk0 to match the largest ssd: to match a seagate drive: partition/logical volume extensions the size of a partition or logical volume in curtin is specified as a number of bytes. the autoinstall config is more flexible: • you can specify the size using the “1g”, “512m” syntax supported in the installer ui • you can specify the size as a percentage of the containing disk (or raid), e.g. “50%” 336

337

• for the last partition specified for a particular device, you can specify the size as “-1” to indicate that the partition should fill the remaining space. the snap described here does not yet exist autoinstall−editor supports creating and editing configs with arbitrary disk match specs. ## identity type: mapping, see below default: no default can be interactive: yes configure the initial user for the system. this is the only config key that must be present (unless the user-data section is present, in which case it is optional). a mapping that can contain keys, all of which take string values: realname the real name for the user. this field is optional. username the user name to create. hostname the hostname for the system. password the password for the new user, crypted. this is required for use with sudo, even if ssh access is configured. ## ssh type: mapping, see below default: see below can be interactive: yes configure ssh for the installed system. a mapping that can contain keys: install-server type: boolean default: false whether to install openssh server in the target system. authorized-keys type: list of strings default: [] a list of ssh public keys to install in the initial user’s account. 337

338

allow-pw type: boolean default: true if authorized_keys is empty, false otherwise ## snaps type: list default: install no extra snaps can be interactive: yes a list of snaps to install. each snap is represented as a mapping with required name and optional channel (defaulting to stable) and classic (defaulting to false ) keys. for example: ## debconf-selections type: string default: no config can be interactive: no the installer will update the target with debconf set-selection values. users will need to be familiar with the package debconf options. ## packages type: list default: no packages can be interactive: no a list of packages to install into the target system. more precisely, a list of strings to pass to “apt−get install ”, so this includes things like task selection (dns−server^) and installing particular versions of a package (my−package=1−1). at /target. you can run curtin in−target−− $shell_command (with the version of subiquity released with 20.04 ga you need to specify this as curtin in−target−−target=/target−− $shell_command) to run in the target system (similar to how plain in−target can be used in d−i preseed/late_command). ## late-commands type: command list default: no commands can be interactive: no shell commands to run after the install has completed successfully and any updates and packages installed, just before the system reboots. they are run in the installer environment with the installed system mounted ## error-commands type: command list default: no commands can be interactive: no shell commands to run after the install has failed. they are run in the installer environment, and the target system (or as much of it as the installer managed to configure) will be mounted at /target. logs will be available at /var/log/ installer in the live session. ## reporting type: mapping default: type: print which causes output on tty1 and any configured serial consoles can be interactive: no the installer supports reporting progress to a variety of destinations. note that this section is ignored if there are any interactive sections; it only applies to fully automated installs. the config, and indeed the implementation, is 90% the same as that used by curtin. each key in the reporting mapping in the config defines a destination, where the type sub-key is one of: the rsyslog reporter does not yet exist • print: print progress information on tty1 and any configured serial console. there is no other config- • rsyslog: report progress via rsyslog. the destination key specifies where to send output. • webhook: report progress via posting json reports to a url. accepts the same configuration as uration. curtin. • none: do not report progress. only useful to inhibit the default output. 338

339

examples: the default configuration is: report to rsyslog: suppress the default output: report to a curtin-style webhook: ## user-data type: mapping default: {} can be interactive: no provide cloud-init user-data which will be merged with the user-data the installer produces. if you supply this, you don’t need to supply an identity section (but then it’s your responsibility to make sure that you can log into the installed system!). netbooting the server installer on amd64 amd64 systems boot in either uefi or legacy (“bios”) mode (many systems can be configured to boot in either mode). the precise details depend on the system firmware, but both modes usually support the pxe (“preboot execution environment”) specification, which allows the provisioning of a bootloader over the network. the process for network booting the live server installer is similar for both modes and goes like this: 1. the to-be-installed machine boots, and is directed to network boot. 2. the dhcp/bootp server tells the machine its network configuration and where to get the bootloader. 3. the machine’s firmware downloads the bootloader over tftp and executes it. 4. the bootloader downloads configuration, also over tftp, telling it where to download the kernel, ramdisk and kernel command line to use. download the server iso from. 5. the ramdisk looks at the kernel command line to learn how to configure the network and where to 6. the ramdisk downloads the iso and mounts it as a loop device. 7. from this point on the install follows the same path as if the iso was on a local block device. the difference between uefi and legacy modes is that in uefi mode the bootloader is a efi executable, signed so that is accepted by secureboot, and in legacy mode it is pxelinux. most dhcp/bootp servers can be configured to serve the right bootloader to a particular machine. configuring dhcp/bootp and tftp there are several implementations of the dhcp/bootp and tftp protocols available. this document will briefly describe how to configure dnsmasq to perform both of these roles. 1. install dnsmasq with “sudo apt install dnsmasq” 2. put something like this in /etc/dnsmasq.conf.d/pxe.conf: i n t e r f a c e >, lo i n t e r f a c e=<your bind−i n t e r f a c e s dhcp−range=<your dhcp−boot=pxelinux .0 dhcp−match=s e t : e f i−x86_64 , option : c l i e n t−arch ,7 dhcp−boot=tag : e f i−x86_64 , bootx64 . e f i enable−t f t p tftp−root=/srv / t f t p 339 i n t e r f a c e > ,192.168.0.100 ,192.168.0.200

340

(this assumes several things about your network; read man dnsmasq or the default /etc/dnsmasq.conf for lots more options). 3. restart dnsmasq with sudo systemctl restart dnsmasq.service. serving the bootloaders and configuration. mode independent set up we need to make this section possible to write sanely ideally this would be something like: # apt i n s t a l l cd−boot−images−amd64 # ln−s / usr / share /cd−boot−images−amd64 / srv / t f t p /boot−amd64 # wget http :// cdimage . ubuntu . com/ubuntu−s e r v e r / daily−l i v e / current / focal− l i v e−server−amd64 . i s o # mount ubuntu−19.10− l i v e−server−amd64 . i s o /mnt 3. copy the kernel and initrd from it to where the dnsmasq serves tftp from: 1. download the latest live server iso for the release you want to install: 2. mount it. # cp /mnt/ casper /{ vmlinuz , i n i t r d } / srv / t f t p / setting up the files for uefi booting 1. copy the signed shim binary into place: tar x ./ usr / l i b /shim/shimx64 . tar x ./ usr / l i b /grub 2. copy the signed grub binary into place: # apt download shim−signed # dpkg−deb−−fsys−t a r f i l e shim−signed *deb | e f i . signed−o > / srv / t f t p /bootx64 . e f i # apt download grub−e f i−amd64−signed # dpkg−deb−−fsys−t a r f i l e grub−e f i−amd64−signed *deb | /x86_64−e f i−signed / grubnetx64 . e f i . signed−o > / srv / t f t p /grubx64 . e f i # apt download grub−common # dpkg−deb−−fsys−t a r f i l e grub−common*deb | unicode . pf2−o > / srv / t f t p / unicode . pf2 timeout=−1 s e t d e f a u l t =”0” s e t tar x ./ usr / share /grub/ then i f 3. grub also needs a font to be available over tftp: 4. create /srv/tftp/grub/grub.cfg that contains: loadfont unicode ; s e t gfxmode=auto 340

341

s e t s e t l o c a l e _ d i r=$ p r e f i x / l o c a l e lang=en_us f i terminal_output gfxterm s e t menu_color_normal=white / black s e t menu_color_highlight=black / l i g h t−gray i f background_color 44 ,0 ,30; c l e a r then f i function gfxmode { s e t gfxpayload=”${1}” i f [ ”${1}” = ” keep ” ] ; then s e t vt_handoff=vt . handoff=7 e l s e f i } s e t vt_handoff= s e t linux_gfx_mode=keep export linux_gfx_mode menuentry ’ubuntu 20.04 ’ { gfxmode $linux_gfx_mode linux /vmlinux $vt_handoff quiet i n i t r d / i n i t r d splash } setting up the files for legacy boot 1. download pxelinux.0 and put it into place: # wget http :// archive . ubuntu . com/ubuntu/ d i s t s /eoan/main/ i n s t a l l e r−amd64/ current / images / netboot /ubuntu−i n s t a l l e r /amd64/ pxelinux .0 # mkdir−p / srv / t f t p 2. make sure to have installed package syslinux−common and then: # cp / usr / l i b / s y s l i n u x /modules/ bios / l d l i n u x . c32 / srv / t f t p / # mv pxelinux .0 / srv / t f t p / 3. create /srv/tftp/pxelinux.cfg/default containing: default i n s t a l l label i n s t a l l kernel vmlinuz initrd i n i t r d append root=/dev/ram0 ramdisk_size =1500000 ip=dhcp u r l=http :// cdimage . ubuntu . com/ubuntu−s e r v e r / daily−l i v e / current / focal−l i v e−server−amd64 . as you can see, this downloads the iso from ubuntu’s servers. you may well want to host it somewhere on your infrastructure and change the url to match. i s o 341

342

this configuration is obviously very simple. pxelinux has many, many options, and you can consult its documentation at https://wiki.syslinux.org/wiki/index.php?title=pxelinux for more. netbooting the live server installer on ibm power (ppc64el) with petitboot • open a terminal window on your workstation and make sure the ‘ipmitool’ package is installed. • verify if you can reach the bmc of the ibm power system via ipmitool with a simple ipmitool call like: chassis power $ ipmitool−i $ ipmitool−i or: product name product version product extra product extra product extra product extra product extra product extra product extra or: $ ipmitool−i i s o f f status : openpower firmware lanplus−h power9box−u <user>−p <password> power lanplus−h power9box−u <user>−p <password> fru print 47 : open−power−supermicro−p9dsu−v2.12−20190404−prod op−build−1b9269e buildroot−2018.11.3−12− g222837a skiboot−v6 . 0 . 1 9 hostboot−c00d44a−pb1307d7 occ−8fa3854 linux−4.19.30−openpower1−p22d1df8 petitboot−v1 .7.5− p8f5fc86 lanplus−h power9box−u <user>−p <password> s o l set−complete i n f o : : : : : : : in progress set enabled force encryption force authentication p r i v i l e g e level character accumulate level character send threshold retry count retry i n t e r v a l v o l a t i l e bit rate ( kbps ) non−v o l a t i l e bit rate ( kbps ) payload channel payload port (ms) (ms) true f a l s e f a l s e : : : : : operator : 0 : 0 : 0 : 0 : 115.2 : 115.2 : 1 (0 x01 ) : 623 • open a second terminal and activate serial-over-lan (sol), so that you have two terminal windows open: 1) to control the bmc via ipmi 2) for the serial-over-lan console • activate serial-over-lan: . . . $ ipmitool−i $ ipmitool−i . . . lanplus−h power9box−u <user>−p <password> s o l a c t i v a t e lanplus−h power9box−u <user>−p <password> power on • and power the system on in the ‘control terminal’ and watch the sol console: it takes some time to see the first lines in the sol console: 342

343

7.22711|secure| security access bit> 0xc000000000000000 7.22711|secure| secure mode disable ( via jumper )> 0 x0000000000000000 9006−12p [sol session o p e r a t i o n a l . use ~? f o r help ] 3.15860| secure | booting in secure mode . 5.59684| booting from sbe s i d e 0 on master proc =00050000 6.67868|hwas|present> dimm[03]= a0a0000000000000 6.67870|hwas|present> proc [05]=8800000000000000 6.67871|hwas|present> core [07]=3fff0c33ffc30000 −−== welcome to hostboot ==−− 2.77131| secure | securerom v a l i d− enabling f u n c t i o n a l i t y 5.60502|istep 6. 5− ho st _i n it _f si 5.87228|istep 6. 6− host_set_ipl_parms 6.11032|istep 6. 7− host_discover_targets 6.98988|istep 6. 8− host_update_master_tpm 7.22731|istep 6. 9− host_gard 7.44509|istep 6.10− host_revert_sbe_mcs_setup… ( v1 .7.5− p8f5fc86 ) sr0 / 2019−10−17−13−35−12−00] sda2 / 295 f571b−b731−4ebb−b752−60aadc80fc1b ] ubuntu , with linux 5.4.0−14− g e n e r i c ( recovery mode) ubuntu , with linux 5.4.0−14− g e n e r i c 7.43353|hwas|functional> dimm[03]= a0a0000000000000 7.43354|hwas|functional> proc [05]=8800000000000000 7.43356|hwas|functional> core [07]=3fff0c33ffc30000 execute netboot enp2p1s0f0 ( pxelinux . 0 ) [ network : enp2p1s0f0 / 0c : c4 :7 a : 8 7 : 0 4 : d8 ] [cd/dvd: [ disk : ubuntu • after a moment the system reaches the petitboot screen: petitboot 1302nxa฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ i n s t a l l ubuntu server system information system c o n f i g u r a t i o n system status language rescan devices retrieve c o n f i g from url plugins log (0) * exit to s h e l l ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ enter=accept , e=edit , n=new , x=exit , l=language , g=log , h=help select ‘*exit to shell’ notice: make sure you really watch the sol, since the petitboot screen (above) has a time out (usually 10 or 30 seconds) and afterwards it automatically proceeds and it tries to boot from the configured devices (usually disk). this can be prevented by just navigating in petitboot. the petitboot shell is small linux based os: . . . 343

344

exiting petitboot . type ’ exit ’ to return . to gather d i a g n o s t i c data you may run ’pb−sos ’ notice: in case one needs to gather system details and diagnostic data for ibm support, this can be done here by running ‘pb-sos’ (see msg). • now download the ‘live-server’ iso image (notice that ‘focal-live-server-ppc64el.iso’ uses subiquity, ‘focal-server-s390x.iso’ uses d-i): again for certain web locations a proxy needs to be used: / # export http_proxy=http :// squid . proxy :3128 # in case a proxy i s i s o / # required / # mkdir 922m 0 : 0 0 : 0 0 eta • next is to loop-back mount the iso: or in case autodetect of type iso9660 is not supported or not working, explicitly specify the ‘iso9660’ type: / # wget http :// cdimage . ubuntu . com/ubuntu−s e r v e r / daily−l i v e / current / focal− l i v e−server−ppc64el . i s o connecting to <proxy−ip >:3128 (<proxy−ip >:3128) focal−l i v e−server−pp 100% | . . . . . . . . . . . . . . . . . . . . | / # mount−o loop focal−l i v e−server−ppc64el . i s o i s o / # mount−t iso9660−o loop focal−l i v e−server−ppc64el . i s o i s o / # kexec−l ./ i s o / casper /vmlinux−−i n i t r d =./ i s o / casper / i n i t r d . gz−−append =”ip=dhcp u r l=http :// cdimage . ubuntu . com/ubuntu−s e r v e r / daily−l i v e / current / focal−l i v e−server−ppc64el . i s o http_proxy=http :// squid . proxy :3128−−− quiet ” / # kexec−e • now load kernel and initrd from the loop-back mount, specify any needed kernel parameters and get it going: the system i s going down now! sent sigterm to a l l p r o c e s s e s sent sigkill to a l l p r o c e s s e s . . . • the system now performs the initial boot of the installer: [ 1200.687004] kexec_core : starting new kernel [ 1277.493883374 ,5] opal: switch to big−endian os [ 1280.465061219 ,5] opal: switch to l i t t l e−endian os ln : /tmp/mountroot−f a i l−hooks . d// s c r i p t s / i n i t−premount/lvm2 : no such f i l e copyright 2004−2018 internet systems consortium . r i g h t s info , please v i s i t https ://www. i s c . org / software /dhcp/ internet systems consortium dhcp client 4 . 4 . 1 or d i r e c t o r y reserved . all for listening on lpf/ enp2p1s0f3 /0 c : c4 :7 a : 8 7 : 0 4 : db sending on lpf/ enp2p1s0f3 /0 c : c4 :7 a : 8 7 : 0 4 : db listening on lpf/ enp2p1s0f2 /0 c : c4 :7 a : 8 7 : 0 4 : da sending on lpf/ enp2p1s0f2 /0 c : c4 :7 a : 8 7 : 0 4 : da listening on lpf/ enp2p1s0f1 /0 c : c4 :7 a : 8 7 : 0 4 : d9 sending on lpf/ enp2p1s0f1 /0 c : c4 :7 a : 8 7 : 0 4 : d9 344

345

listening on lpf/ enp2p1s0f0 /0 c : c4 :7 a : 8 7 : 0 4 : d8 lpf/ enp2p1s0f0 /0 c : c4 :7 a : 8 7 : 0 4 : d8 sending on sending on socket / f a l l b a c k dhcpdiscover on enp2p1s0f3 to 255.255.255.255 port 67 i n t e r v a l 3 ( xid=0x8d5704c ) dhcpdiscover on enp2p1s0f2 to 255.255.255.255 port 67 i n t e r v a l 3 ( xid=0x94b25b28 ) dhcpdiscover on enp2p1s0f1 to 255.255.255.255 port 67 i n t e r v a l 3 ( xid=0x4edd0558 ) dhcpdiscover on enp2p1s0f0 to 255.255.255.255 port 67 i n t e r v a l 3 ( xid=0x61c90d28 ) dhcpoffer of 10.245.71.102 from 1 0 . 2 4 5 . 7 1 . 3 dhcprequest f o r 10.245.71.102 on enp2p1s0f0 to 255.255.255.255 port 67 ( xid=0x280dc961 ) dhcpack of 10.245.71.102 from 1 0 . 2 4 5 . 7 1 . 3 ( xid=0x61c90d28 ) connecting to 9 1 . 1 8 9 . 8 9 . 1 1 : 3 1 2 8 ( 9 1 . 1 8 9 . 8 9 . 1 1 : 3 1 2 8 ) in 236 seconds . 48% |*************** 52% |**************** 55% |***************** 59% |****************** 345 17% |***** 20% |****** 0 : 0 0 : 2 9 eta 0 : 0 0 : 2 7 eta 0 : 0 0 : 3 3 eta 0 : 0 0 : 3 1 eta 0 : 0 1 : 0 4 eta 0 : 0 0 : 3 8 eta 11% |*** 14% |**** 1% | 4% |* 8% |** 0 : 0 0 : 2 5 eta 0 : 0 0 : 2 6 eta bound to 10.245.71.102−− renewal focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp 0 : 0 0 : 2 3 eta 0 : 0 0 : 2 1 eta 0 : 0 0 : 2 0 eta 0 : 0 0 : 1 8 eta 0 : 0 0 : 1 7 eta 0 : 0 0 : 1 6 eta 0 : 0 0 : 1 5 eta 0 : 0 0 : 2 2 eta 0 : 0 0 : 1 9 eta 0 : 0 0 : 1 4 eta 24% |******* 27% |******** 30% |********* 34% |********** 37% |*********** 39% |************ 42% |************* 45% |************** | 14.0m | 45.1m | 76.7m | | | | | | | | | | | | | | | | 105m 133m 163m 190m 222m 253m 283m 315m 343m 367m 392m 420m 451m 482m 514m 546m

346

| | | | | | | | | | | 0 : 0 0 : 0 5 eta 0 : 0 0 : 0 4 eta 0 : 0 0 : 0 9 eta 0 : 0 0 : 0 8 eta 0 : 0 0 : 0 7 eta 0 : 0 0 : 0 6 eta 0 : 0 0 : 1 0 eta 578m 607m 637m 669m 0 : 0 0 : 1 1 eta 0 : 0 0 : 1 3 eta 700m 729m 62% |******************** 65% |********************* 69% |********************** 72% |*********************** 75% |************************ 79% |************************* 82% |************************** 85% |*************************** focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp focal−l i v e−server−pp 100% |********************************| 52.672550] cloud−i n i t [ 3 7 5 9 ] : cloud−i n i t v . 20.1−10− g71af48df−0ubuntu1 ’ i n i t−l o c a l ’ at wed, 18 mar 2020 15:18:07 +0000. up 51.87 seconds . mount : mounting /cow on / root /cow f a i l e d : no such f i l e or d i r e c t o r y connecting to plymouth : connection refused passwd : password expiry information changed . [ [ 47.202736] /dev/ loop3 : can ’ t open blockdev 97% |******************************* | 93% |****************************** 91% |***************************** 88% |**************************** 758m 789m 817m 842m 867m 897m 922m 0 : 0 0 : 0 3 eta 0 : 0 0 : 0 2 eta 0 : 0 0 : 0 1 eta 0 : 0 0 : 0 0 eta running . . . 0 : 0 0 : 0 0 eta • and you will eventually reach the initial subiquity installer screen: ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ willkommen ! bienvenue ! welcome ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ ! welkom use up, down and enter keys to s e l e c t your language . ฀ [ english ฀ [ asturianu ฀ [ català ฀ [ hrvatski [ nederlands ฀ [ suomi [ français ฀ [ deutsch ฀ [ ε฀฀฀฀฀฀฀฀ [ magyar ฀ ฀ ] ] ] ] ] ] ] ] ] ] 346

347

฀ [ šlatvieu ฀ [ norsk bokmål [ polski [ [ español [ ฀฀฀฀฀฀฀฀ ฀ ฀ ฀฀฀฀฀฀฀฀฀฀฀ ( subiquity−) ‘ ‘ ‘ * the r e s t i s # a u t o i n s t a l l quick start i n s t a l l a t i o n as usual . . . f o r s390x ] ] ] ] ] ] to perform an the intent of t h i s page i s to provide simple i n s t r u c t i o n s a u t o i n s t a l l in a vm on your machine on s390x . this page i s j u s t a s l i g h t l y adapted page of https :// d i s c o u r s e . ubuntu . com/ t / draft−automated−server−i n s t a l l−q u i c k s t a r t /16614 mapped to s390x . ## download an iso at the time of writing ( j u s t before f o c a l r e l e a s e ) , the best place to go i s here : http :// cdimage . ubuntu . com/ubuntu/ r e l e a s e s /20.04/ r e l e a s e / > c o n f i g cd ~/www c o n f i g as f o l l o w s : ## mount the iso ## write your a u t o i n s t a l l <pre><code>wget http :// cdimage . ubuntu . com/ubuntu/ r e l e a s e s /20.04/ r e l e a s e /ubuntu −20.04− l i v e−server−s390x . i s o−p ~/downloads</code></pre> <pre><code>mkdir−p ~/ i s o sudo mount−r ~/downloads/ubuntu−20.04− l i v e−server−s390x . i s o ~/ iso </code></pre this means c r e a t i n g cloud−i n i t <pre><code>mkdir−p ~/www cat > user−data << ’eof’ #cloud−c o n f i g hostname : ubuntu−s e r v e r touch meta−data</code></pre> ## serve the cloud−i n i t zrtizm30jz4qroq2aoxj8yk96xpccof0kxkwux1kqlg/ygbj1f8wxed22btl4f46p0” password : ”$6$exdy1mhs4kuyce/2$zmn9tozwtklhcw. b4/b . a u t o i n s t a l l : version : 1 i d e n t i t y : the crypted password i s username : ubuntu c o n f i g over http j u s t ”ubuntu ” . eof 347

348

leave t h i s running in one terminal window : <pre><code>cd ~/www ## create a target disk python3−m http . s e r v e r 3003</code></pre> i n s t a l l qemu−u t i l s proceed with a second terminal window : <pre><code>sudo apt ... </ code></pre> lazy_refcounts=o f f <pre><code>qemu−img create−f qcow2 disk−image . qcow2 10g formatting ’ disk−image . qcow2 ’ , qemu−img i n f o disk−image . qcow2 image : disk−image . qcow2 s i z e : 10 gib (10737418240 bytes ) refcount_bits=16 format : qcow2 f i l e v i r t u a l disk s i z e : 196 kib c l u s t e r _ s i z e : 65536 format s p e c i f i c compat : 1.1 lazy r e f c o u n ts : refcount b i t s : 16 corrupt : ## run the i n s t a l l ! <pre><code>sudo apt ... </ code></pre> information : f a l s e f a l s e </code></pre> i n s t a l l qemu−kvm fmt=qcow2 s i z e =10737418240 c l u s t e r _ s i z e =65536 to the kvm group : <<br>> you may need to add the d e f a u l t user ‘ sudo usermod−a−g kvm ubuntu # re−l o g i n to make the changes <pre><code>kvm−no−reboot−name auto−inst−t e s t−nographic−m 2048 \ −drive f i l e=disk−image . qcow2 , format=qcow2 , cache=none , i f=v i r t i o \ −cdrom ~/downloads/ubuntu−20.04− l i v e−server−s390x . i s o \ −kernel ~/ i s o /boot/ kernel . ubuntu \ −i n i t r d ~/ i s o /boot/ i n i t r d . ubuntu \ −append ’ a u t o i n s t a l l ds=nocloud−net ; s=http :// _gateway :3003/ console= ttysclp0 ’</code></pre> this w i l l boot , download the c o n f i g from the s e r v e r s e t up in the previous take e f f e c t ‘ step and run the i n s t a l l . the i n s t a l l e r reboots at w i l l e x i t when t h i s happens . i t should take about 5 minutes . the end but the−no−reboot f l a g to kvm means that kvm ## boot the i n s t a l l e d system <pre><code>kvm−no−reboot−name auto−inst−t e s t−nographic−m 2048 \ −drive f i l e=disk−image . qcow2 , format=qcow2 , cache=none , i f=v i r t i o </code></pre> 348

349

this w i l l boot into the f r e s h l y i n s t a l l e d system and you should be able to log in as ubuntu/ubuntu . # reporting problems with the i n s t a l l e r we of course hope that every i n s t a l l with the s e r v e r succeeds . but r e a l i t y doesn ’ t always work that way and there w i l l be f a i l u r e s of course the most u s e f u l way to report them of various kinds . this so that we can f i x the bugs causing them , and we ’ l l keep the topic up to date as s e c t i o n explains i n s t a l l e r i n s t a l l e r changes . the the f i r s t thing to do i s that cause f i x i s s u e s working on f e a t u r e s to update your f a i l u r e s over to make f a i l u r e subiquity snap . not only because we time but a l s o because we ’ ve been reporting e a s i e r . a f a i l u r e w i l l r e s u l t the information we need to f u l l y diagnose a f a i l u r e . these l i v e crash in the p e r s i s t e d to the in a crash report being generated which bundles up a l l in / var / t h i s i n s t a l l e r environment , and f o r ubuntu 19.10 and newer i n s t a l l media by d e f a u l t space ) . there ( i f i s i s of f o r t o o l that to the e r r o r f o r continuing . l e t us e s t a b l i s h t h i s kind when an e r r o r occurs you are presented with a dia log which allows you to upload the report so they uploads to the e r r o r are u s e f u l tracking which kinds of e r r o r s are a f f e c t i n g most users , but they do not give us a way to ask you to help diagnose the f a i l u r e . tracker and o f f e r s options tracker are non−i n t e r a c t i v e and anonymous , run ” apport−c l i /path/ to / report . crash ” and i s part of ubuntu . copy the crash two way communication , based on the contents of a crash report by using to another system , report f o l l o w the prompts . you can create a launchpad bug report , which does s h e l l but apport won ’ t be able to open a browser the report the standard ‘ apport−c l i ‘ you can a l s o run apport−c l i :// ubuntu . com/ s e r v e r / docs / i n s t a l l / netboot−ppc64el ) . there i s a l s o documentation on [ booting the # using a v i r t u a l cdrom and petitboot ibm power ( ppc64el ) to s t a r t a l i v e so you ’ l l have to type the url by hand on another machine . i n s t a l l e r environment by switching to a to allow you to complete ibm power machines come with the c a p a b i l i t y to i n s t a l l via a v i r t u a l s e r v e r i n s t a l l a t i o n on * * notice :* not a l l the network ] ( https i n s t a l l e r over in the cdrom ! * a separate system ( i d e a l l y in the same network , because of ipmitool ) i s l a t e r used as v i r t u a l needed to host cdrom. the ppc64el iso image f i l e , that i s * login to t h i s i n s t a l l e d : separate host and make sure that the ipmitool package i s 349

350

$ sudo apt install ipmitool as well as samba: $ sudo apt install samba “‘ • next is to setup and configure samba: $ sudo touch / etc /samba/smb . conf && sudo tee−a / etc /samba/smb . conf <<eof [ winshare ] path=/var / winshare browseable = yes read only = no guest ok = yes eof and do a quick verification that the required lines are in: $ t a i l −n 5 / etc /samba/smb . conf [ winshare ] path=/var / winshare browseable = yes read only = no guest ok = yes • (optional) for downloading the image you may have to use a proxy server: $ sudo touch ~/. wgetrc && sudo tee−a ~/. wgetrc <<eof use_proxy=yes http_proxy=squid . proxy :3128 https_proxy=squid . proxy :3128 eof • the iso image needs to be downloaded now: • change file mode of the iso image file: the proxy can also be passed over as wget argument, like this: $ wget http :// cdimage . ubuntu . com/ubuntu/ r e l e a s e s / f o c a l / r e l e a s e /ubuntu −20.04− l i v e−server−ppc64el . i s o−−directory−p r e f i x=/var / winshare $ wget−e use_proxy=yes−e http_proxy=squid . proxy :3128 http :// cdimage . ubuntu . com/ubuntu/ r e l e a s e s / f o c a l / r e l e a s e /ubuntu−20.04− l i v e−server− ppc64el . i s o−−directory−p r e f i x=/var / winshare $ sudo chmod−r 755 / var / winshare / $ l s−l / var / winshare / 972500992 mar 23 08:02 focal−l i v e−server− −rwxr−xr−x 1 ubuntu ubuntu smbd . s e r v i c e− samba smb daemon loaded (/ l i b /systemd/system/smbd . s e r v i c e ; enabled ; vendor • restart and check the samba service: $ sudo s e r v i c e smbd r e s t a r t $ sudo s e r v i c e smbd status฀ loaded : preset : ena ppc64el . i s o s i n c e tue 2020−02−04 15:17:12 utc; 4 s ago active : a c t i v e ( running ) docs : man: smbd (8) man: samba (7) man: smb . conf (5) 350

351

main pid : 6198 (smbd) status : ”smbd : tasks : 4 ( l i m i t : 19660) cgroup : /system . s l i c e /smbd . s e r v i c e ฀฀ ready to serve connections . . . ” 6198 / usr / sbin /smbd−−foreground−−no−process−group฀฀ 6214 / usr / sbin /smbd−−foreground−−no−process−group฀฀ 6215 / usr / sbin /smbd−−foreground−−no−process−group฀฀ 6220 / usr / sbin /smbd−−foreground−−no−process−group systemd [ 1 ] : starting samba smb …daemon systemd [ 1 ] : started samba smb daemon . feb 04 15:17:12 host feb 04 15:17:12 host • test samba share: s e r v e r (samba , ubuntu) ) comment sharename comment workgroup workgroup master host printer drivers ipc service ( host type −−−− disk disk ipc print$ winshare ipc$ reconnecting with smb1 f o r workgroup l i s t i n g . server warning: the ” s y s l o g ” option i s deprecated enter workgroup\ubuntu ’ s password : ubuntu@host :~ $ smbclient−l l o c a l h o s t −−−−−−− −−−−−−−−− −−−−−−− −−−−−−−−− −−−−−−− −−−−−−−−− $ ip −4−b r i e f address show user@workstation :~ $ mkdir−p /tmp/ t e s t user@workstation :~ $ sudo mount−t c i f s −o user@workstation :~ $ l s−la /tmp/ t e s t / drwxr−xr−x −rwxr−xr−x 0 may root root 420 may root 1038249984 may 2 root drwxrwxrwt 18 root 1 root lo ibmveth2 unknown unknown t o t a l 1014784 ppc64el . i s o 1 2 7 . 0 . 0 . 1 / 8 10.245.246.42/24 • get the ip address of the samba host: • (optional) even more testing if the samba share is accessible from remote: username=guest , password=guest //10.245.246.42/ winshare /tmp/ t e s t / 4 15:46 . 4 19:25 . . 3 19:37 ubuntu−20.04− l i v e−server− • now use a browser and navigate to the bmc of the power system that should be installed (let’s assume the bmc’s ip address is 10.245.246.247): f i r e f o x http : //1 0. 24 5. 24 6. 24 7/ • login to the bmc and find and select: virtual media –> cdrom • enter the ip address of the samba share: 10.245.246.42 and the path to the samba share: \ winshare \ focal−l i v e−server−ppc64el . i s o 351

352

• click save and mount (make sure that the virtual cdrom is really properly mounted !) cd−rom image : this option allows you to share a cd−rom image over a windows share with a maximum s i z e of 4.7gb. this image w i l l be emulated to the host as usb device . device 1 there i s an i s o f i l e mounted . device 2 no disk emulation s e t . device 3 no disk emulation s e t . <refresh status> share host : 10.245.246.42 path to image : \ winshare \ focal−l i v e−server−ppc64el . i s o user password ( optional ) : <save> <mount> <unmount> ( optional ) : • notice: it’s important that you see a status like: device 1 there i s an i s o f i l e mounted • now use the ipmitool to boot the system into the petitboot loader: i n s t a l l ubuntu server only in this case the virtual cdrom is properly mounted and you will see the boot / install from cdrom entry in petitboot: [cd/dvd: sr0 / 2020−03−23−08−02−42−00] lanplus−h 10.245.246.247−u admin−p <password> power lanplus−h 10.245.246.247−u admin−p <password> s o l lanplus−h 10.245.246.247−u admin−p <password> power on 9006−12c ( v1 .7.5− p8f5fc86 ) $ ipmitool−i $ ipmitool−i $ ipmitool−i bos0026฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ chassis power control : up/on status a c t i v a t e • and reach the petitboot screen: petitboot [ network : enp2p1s0f0 / ac :1 f :6 b : 0 9 : c0 : 5 2 ] execute netboot enp2p1s0f0 ( pxelinux . 0 ) log system information system c o n f i g u r a t i o n system status language rescan devices retrieve c o n f i g from url * plugins exit (0) to s h e l l ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ enter=accept , e=edit , n=new , x=exit , default boot c a n c e l l e d l=language , g=log , h=help 352

353

9006−12c petitboot • and make sure that booting from cdrom is enabled: [ network : enp2p1s0f0 / ac :1 f :6 b : 0 9 : c0 : 5 2 ] bos0026฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ ( v1 .7.5− p8f5fc86 ) sda2 / ebdb022b−96b2−4f4f−ae63−69300 ded13f4 ] ubuntu , with linux 5.4.0−12− g e n e r i c ( recovery mode) ubuntu , with linux 5.4.0−12− g e n e r i c execute netboot enp2p1s0f0 ( pxelinux . 0 ) ubuntu [ disk : log system information system c o n f i g u r a t i o n system status language rescan devices retrieve c o n f i g from url * plugins exit (0) to s h e l l ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ enter=accept , e=edit , n=new , x=exit , [ sda3 ] processing new disk device l=language , g=log , h=help petitboot system configuration฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ autoboot : boot order : ( ) disabled (*) enabled (0) any cd/dvd device (1) disk : sda2 [ uuid : ebdb022b−96b2−4f4f−ae63−69300 enp2p1s0f0 [ mac : ac :1 f :6 b : 0 9 : c0 : 5 2 ] ded13f4 ] (2) net : [ [ [ add device clear & boot any clear ] ] ] timeout : 30 seconds network : (*) dhcp on a l l a c t i v e ) dhcp on a s p e c i f i c ( ( ) s t a t i c ip c o n f i g u r a t i o n ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ i n t e r f a c e s i n t e r f a c e tab=next , s h i f t+tab=previous , x=exit , h=help petitboot system configuration฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ network : (*) dhcp on a l l a c t i v e i n t e r f a c e s 353

354

dns server ( s ) : http proxy : https proxy : disk r/w: boot console : ( ( ) dhcp on a s p e c i f i c ) s t a t i c ip c o n f i g u r a t i o n i n t e r f a c e ( i f not provided by dhcp s e r v e r ) ( eg . 1 9 2 . 1 6 8 . 0 . 2 ) ) prevent a l l writes ( (*) allow bootloader to disk s c r i p t s to modify di s ks (*) /dev/hvc0 [ ipmi / s e r i a l ] ( current i n t e r f a c e : /dev/hvc0 ) /dev/ tty1 [vga] [ ok ] [ help ] [ cancel ] ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ tab=next , s h i f t+tab=previous , x=exit , h=help • now select the ‘install ubuntu server’ entry below the cd/dvd entry: sr0 / 2020−03−23−08−02−42−00] i n s t a l l ubuntu server [cd/dvd: * • and let petitboot boot from the (virtual) cdrom image: 119.355371] kexec_core : starting new kernel sent sigkill to a l l p r o c e s s e s [ [ [ 194.483947394 ,5] opal: switch to big−endian os 197.454615202 ,5] opal: switch to l i t t l e−endian os • finally the initial subiquity installer screen will show up in the console: ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ willkommen ! bienvenue ! welcome ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ ! welkom฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ use up, down and enter keys to s e l e c t your language . ฀ ฀ [ english ฀ [ asturianu ฀ [ català ฀ [ hrvatski [ nederlands ฀ [ suomi [ français ฀ [ deutsch ฀ [ ε฀฀฀฀฀฀฀฀ [ magyar ฀ [ šlatvieu ฀ [ norsk bokmål [ polski [ [ español ฀฀฀฀฀฀฀฀ ฀ ฀ ] ] ] ] ] ] ] ] ] ] ] ] ] ] ] ฀ 354

355

[ ฀฀฀฀฀฀฀฀฀฀฀ ] • the rest of the installation is business as usual … interactive live server installation on ibm z/vm (s390x) [this installation - without specifying a parmfile - works with the 20.04 aka ‘focal’ daily live image, that will later become the 20.04.1 image and any newer ubuntu releases, like 20.10 aka ‘groovy’.] • the following guide assumes that a z/vm guest got defined, and that it is able to either reach the public cdimage.ubuntu.com server or an internal ftp or http server that hosts an ubuntu server 20.04 installer image, like this 20.04 aka focal daily live image here: http://cdimage.ubuntu.com/ubuntu- server/focal/daily-live/current/ : 1 5 6 0 : 8 0 0 1 : : 1 d | : 8 0 . . . connected . . . . • find a place to download the installer image: resolving cdimage . ubuntu . com ( cdimage . ubuntu . com) . . . 2001:67 c : 1 5 6 0 : 8 0 0 1 : : 1 user@workstation :~ $ wget http :// cdimage . ubuntu . com/ubuntu−s e r v e r / f o c a l / daily−l i v e / current / focal−l i v e−server−s390x . i s o −−2020−06−03 21:17:46−− http :// cdimage . ubuntu . com/ubuntu−s e r v e r / f o c a l / daily−l i v e / current / focal−l i v e−server−s390x . i s o [ a p p l i c a t i o n /x−iso9660−image ] ‘focal−l i v e−server−s390x . ’ i s o http request length : 696588288 (664m) saving to : connecting to cdimage . ubuntu . com ( cdimage . ubuntu . com) |2001:67 c d , 2001:67 c : 1 3 6 0 : 8 0 0 1 : : 2 8 , 2001:67 c : 1 3 6 0 : 8 0 0 1 : : 2 7 , sent , awaiting response . . . 200 ok user@workstation :~ $ [696588288/696588288] • now loopback mount the iso to extract four files that are needed for a z/vm guest installation focal−l i v e−server− 100%[===================>] 664.32m 9.76mb/ s 2020−06−03 21:18:59 (9.04 mb/ s )− ‘focal−l i v e−server−s390x . ’ i s o saved user@workstation :~ $ sudo mount−o loop focal−l i v e−server−s390x . i s o i s o user@workstation :~ $ l s −1 ./ i s o /boot /{ubuntu . exec , parmfile . ubuntu , kernel . ubuntu , i n i t r d . ubuntu} ./ i s o /boot/ i n i t r d . ubuntu ./ i s o /boot/ kernel . ubuntu ./ i s o /boot/ parmfile . ubuntu ./ i s o /boot/ubuntu . exec user@workstation :~ $ user@workstation :~ $ mkdir iso user@workstation :~ $ in 73 s • now transfer these four files to your z/vm guest (for example to its ‘a’ file mode), using either the 3270 terminal emulator or ftp. • then log on to your z/vm guest that you want to use for the installation, in this example it will be guest ‘10.222.111.24’ • and execute the ubuntu rexx script to kick-off the installation: ubuntu 00: 0000004 files purged 355

356

00: rdr file 0125 sent from 10.222.111.24 pun was 0125 recs 101k cpy 001 keep 00: rdr file 0129 sent from 10.222.111.24 pun was 0129 recs 0001 cpy 001 keep 00: rdr file 0133 sent from 10.222.111.24 pun was 0133 recs 334k cpy 001 a nohold no a nohold no a nohold no keep 00: 0000003 files changed 00: 0000003 files changed 01: hcpgsp2627i the v i r t u a l machine i s placed in cp mode due to a sigp 02: hcpgsp2627i the v i r t u a l machine i s placed in cp mode due to a sigp i n i t i a l cpu r e s e t from cpu 00. i n i t i a l cpu r e s e t from cpu 00. 03: hcpgsp2627i the v i r t u a l machine i s placed in cp mode due to a sigp i n i t i a l cpu r e s e t from cpu 00. 0.390935| ¬ unable to find a medium container a l i v e initramfs unpacking f a i l e d : decoding f a i l e d system f i l e • in the usual case that no parmfile got configured, the installation system now offers to interactively i n t e r a c t i v e netboot configure the basic network: attempt yes no ( d e f a u l t yes ) : available qeth devices : 0.0.0600 0.0.0603 zdev to a c t i v a t e (comma separated , optional ) : 0.0.0600 qeth device 0 . 0 . 0 6 0 0 : 0 . 0 . 0 6 0 1 : 0 . 0 . 0 6 0 2 configured two methods a v a i l a b l e ip c o n f i g u r a t i o n : from a url? f o r * s t a t i c : * dhcp : f o r s t a t i c ip c o n f i g u r a t i o n f o r automatic ip c o n f i g u r a t i o n ’ dhcp ’ ) : s t a t i c dhcp ( d e f a u l t ip : 10.222.111.24 gateway ( d e f a u l t 1 0 . 2 2 2 . 1 1 1 . 1 ) : dns ( d e f a u l t . vlan id ( optional ) : . ) : . s t a t i c http :// cdimage . ubuntu . com/ubuntu−s e r v e r / f o c a l / daily−l i v e / current / focal− l i v e−server−s390x . i s o ( d e f a u l t ) ftp : / / 1 0 . 1 1 . 1 2 . 2 : 2 1 / ubuntu−l i v e−server−20.04/ focal−l i v e−server−s390x . http_proxy ( optional ) : u r l : i s o • make sure that the same version of the iso image is referenced at the ‘url:’ setting, that was used to extract the installer files - kernel and initrd. but it can be at a different location, for exam- ple directly referencing the public cdimage.ubuntu.com server: http://cdimage.ubuntu.com/ubuntu- server/focal/daily-live/current/focal-live-server-s390x.iso • the boot-up of the live-server installation now completes: configuring networking . . . qeth device 0 . 0 . 0 6 0 0 : 0 . 0 . 0 6 0 1 : 0 . 0 . 0 6 0 2 already configured ip−config : enc600 hardware address 0 2 : 2 8 : 0 a : 0 0 : 0 0 : 3 9 mtu 1500 ip−config : enc600 guessed broadcast address 10.222.111255 ip−config : enc600 complete : broadcast : 10.222.111255 address : 10.222.111.24 netmask : 255.255.255.0 356

357

gateway : 1 0 . 2 2 2 . 1 1 1 . 1 dns0 : 1 0 . 2 2 2 . 1 1 1 . 1 dns1 : 0 . 0 . 0 . 0 net6 to ¬0m skipping ¬0; 1 ; 3 9 mlogin prompts ¬ 594.766372| /dev/ loop3 : can ’ t open blockdev r o o t s e r v e r : 0 . 0 . 0 . 0 rootpath : filename connecting to 1 0 . 1 1 . 1 2 . 2 : 2 1 ( 1 0 . 1 1 . 1 2 . 2 : 2 1 ) : break ordering c y c l e ¬ ¬0; 1 ; 3 1m skip ¬0m| ordering c y c l e found , ¬ 595.623027| systemd¬1 | : failed unmounting /cdrom . ¬ ¬0; 1 ; 3 1mfailed ¬0m| failed unmounting ¬0; 1 ; 3 9m/cdrom ¬0m. ! 35.9m 0 : 0 0 : 1 7 eta 129m 0 : 0 0 : 0 8 eta ! ! 225m 0 : 0 0 : 0 5 eta 330m 0 : 0 0 : 0 4 eta ! 403m 0 : 0 0 : 0 3 eta ! 506m 0 : 0 0 : 0 1 eta ! 594m 0 : 0 0 : 0 0 eta ! 663m 0 : 0 0 : 0 0 eta passwd : password expiry information changed . qeth device 0 . 0 . 0 6 0 0 : 0 . 0 . 0 6 0 1 : 0 . 0 . 0 6 0 2 already configured no search or nameservers 5% !* 19% !****** 33% !********** 49% !*************** 60% !******************* 76% !************************ 89% !**************************** focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s 100% !********************************! found in /run/net−enc600 . conf /run/net−*. conf /run/ −*. conf ¬ 595.610434| systemd¬1 | : multi−user . target : job getty . target / s t a r t deleted s t a r t i n g with multi−user . target / s t a r t ¬ 598.973538| cloud−init¬1256 | : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 g ’ i n i t−l o c a l ’ at thu , 04 jun 2020 12:06:46 +0000. up 598.72 seconds . ¬ 599.829069| cloud−init¬1288 | : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 ci−i n f o : ++++++++++++++++++++++++++++++++++++ ¬ 599.829182| cloud−init¬1288 | : ci−i n f o : ¬ 599.829218| cloud−init¬1288 | : +−−−−−−−−+−−−−−−+−−−−−−−−−−−−−−−−−−−−− −−−−+−−−−−−−−−−−−−−−+−−−−−−−−+−−−−−−−−−−−−−−−−−−−+ ci−i n f o : ¬ 599.829255| cloud−init¬1288 | : hw−address ¬ 599.829292| cloud−init¬1288 | : ci−i n f o : +−−−−−−−−+−−−−−−+−−−−−−−−−−−−−−−−−−−−− −−−−+−−−−−−−−−−−−−−−+−−−−−−−−+−−−−−−−−−−−−−−−−−−−+ ci−i n f o : ¬ 599.829333| cloud−init¬1288 | : ¬ 599.829376| cloud−init¬1288 | : ci−i n f o : ci−i n f o : ¬ 599.829416| cloud−init¬1288 | : ¬ 599.829606| cloud−init¬1288 | : ci−i n f o : g ’ i n i t ’ at thu , 04 jun 2020 12:06:47 +0000. up 599.64 seconds . t device i n f o+++++++++++++++++++++++++++++++++++++ ! 255.255.255.0 ! gl obal ! 0 2 : 2 8 : 0 a : 0 0 : 0 0 : 3 9 ! ! enc600 ! true ! fe80 : : 2 8 : a f f : fe00 ! 0 2 : 2 8 : 0 a : 0 0 : 0 0 : 3 9 ! ! device ! up ! ! enc600 ! true ! l i n k host host 10.222.111.24 ! scope ! ! true ! ! true ! 1 2 7 . 0 . 0 . 1 : : 1 / 1 2 8 runnin runnin :3 /64 ! ! ! lo lo ne ! ! ! address ! ! ! mask 2 5 5 . 0 . 0 . 0 . . ! ! ! ! ! . . 357

358

! ! ! ! 0 1 ip ! ! ! ! u ++++ ug ! enc600 enc600 0 . 0 . 0 . 0 0 . 0 . 0 . 0 0 . 0 . 0 . 0 ! flags gateway genmask i n t e r f a c e 1 0 . 2 2 2 . 1 1 1 . 1 ! 10.222.1110 ! +++++++++++++++ ! 255.255.255.0 ! ! route ! destination v4 i n f o++++++++++++++++++++++++++++++ ¬ 599.829684| cloud−init¬1288 | : ci−i n f o : +−−−−−−−−+−−−−−−+−−−−−−−−−−−−−−−−−−−−− −−−−+−−−−−−−−−−−−−−−+−−−−−−−−+−−−−−−−−−−−−−−−−−−−+ ci−i n f o : ++++++++++++++++++++++++++++++route ¬ 599.829721| cloud−init¬1288 | : ci−i n f o : ¬ 599.829754| cloud−init¬1288 | : +−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−−−−−−−− +−−−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−+ ¬ 599.829789| cloud−init¬1288 | : ci−i n f o : ¬ 599.829822| cloud−init¬1288 | : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−−−−−−−− +−−−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−+ ¬ 599.829858| cloud−init¬1288 | : ci−i n f o : ci−i n f o : ¬ 599.829896| cloud−init¬1288 | : ¬ 599.829930| cloud−init¬1288 | : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−−−−−−−− +−−−−−−−−−−−−−−−+−−−−−−−−−−−+−−−−−−−+ ¬ 599.829962| cloud−init¬1288 | : ci−i n f o : +++++++++++++++++++route ipv6 i n f o ci−i n f o : ¬ 599.829998| cloud−init¬1288 | : +−−−−−−−+−−−−−−−−−−−−−+−−−−−−−−−+−−−−− −−−−−−+−−−−−−−+ ci−i n f o : ¬ 599.830031| cloud−init¬1288 | : ¬ 599.830064| cloud−init¬1288 | : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−+−−−−−−−−−+−−−−− −−−−−−+−−−−−−−+ ¬ 599.830096| cloud−init¬1288 | : ci−i n f o : ci−i n f o : ¬ 599.830131| cloud−init¬1288 | : ¬ 599.830164| cloud−init¬1288 | : ci−i n f o : ci−i n f o : ¬ 599.830212| cloud−init¬1288 | : +−−−−−−−+−−−−−−−−−−−−−+−−−−−−−−−+−−−−− −−−−−−+−−−−−−−+ ¬ 601.077953| cloud−init¬1288 | : generating public / private rsa key pair . ¬ 601.078101| cloud−init¬1288 | : your ¬ 601.078136| cloud−init¬1288 | : your public key has been saved in / etc / ssh / ¬ 601.078170| cloud−init¬1288 | : the key f i n g e r p r i n t i d e n t i f i c a t i o n has been saved in / etc / ! route ! destination ! gateway ! host_rsa_key . pub ssh_host_rsa_key fe80 : : / 6 4 f f 0 0 : : / 8 ! flags ! ! ! ! 1 3 4 u u u : : : : : : r f a c e en en en l o c a l c600 c600 c600 ! ! ! ! ! ssh / ssh ! ! ! ! ! ! ! ! ! inte ! ! ! i s : 358 ! ! !

359

360

i s : runnin i n s t a l l e r . ssh_host_ed25519_key ssh / ssh_ zi3so3b ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! host_ed25519_key . pub o o . s o o . . . . . . . . . . . . e.=o ! . . . . . + ! . o ! . ! . ! ! i d e n t i f i c a t i o n has been saved in / etc / ¬ 601.079525| cloud−init¬1288 | : ¬ 601.079557| cloud−init¬1288 | : ¬ 601.079589| cloud−init¬1288 | : ¬ 601.079621| cloud−init¬1288 | : ¬ 601.079653| cloud−init¬1288 | : ¬ 601.079685| cloud−init¬1288 | : ¬ 601.079717| cloud−init¬1288 | : +−−−−¬sha256|−−−−−+ ¬ 601.079748| cloud−init¬1288 | : generating public / private ed25519 key pair . ¬ 601.079782| cloud−init¬1288 | : your ¬ 601.079814| cloud−init¬1288 | : your public key has been saved in / etc / ssh / ¬ 601.079847| cloud−init¬1288 | : the key f i n g e r p r i n t ¬ 601.079879| cloud−init¬1288 | : sha256 :ywsz/5+7u7d3sicd7hynyajxyewnt5nq+ en8 root§ubuntu−s e r v e r ¬ 601.079911| cloud−init¬1288 | : the key ’ s randomart image i s : ¬ 601.079942| cloud−init¬1288 | : +−−¬ed25519 256|−−+ ¬ 601.079974| cloud−init¬1288 | : ¬ 601.080010| cloud−init¬1288 | : ¬ 601.080042| cloud−init¬1288 | : ¬ 601.080076| cloud−init¬1288 | : ¬ 601.080107| cloud−init¬1288 | : ¬ 601.080139| cloud−init¬1288 | : ¬ 601.080179| cloud−init¬1288 | : ¬ 601.080210| cloud−init¬1288 | : ¬ 601.080244| cloud−init¬1288 | : ¬ 601.080289| cloud−init¬1288 | : +−−−−¬sha256|−−−−−+ ¬ 612.293731| cloud−init¬2027 | : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 ¬ 612.293866| cloud−init¬2027 | : set ¬ 612.293940| cloud−init¬2027 | : ci−i n f o : no authorized ssh keys root§ubuntu−s e r v e r root§ubuntu−s e r v e r root§ubuntu−s e r v e r root§ubuntu−s e r v e r 4 12:07:00 ec2 :−−−−−begin ssh host key fingerprints−−−−− ! ! ! ! o ! s o=++! = + . o**§=! oo+&b%! . . o*%/e! khtkabzwk8ae80fy0kpztrcypht4ixdzmj37cgi3fj0 4 12:07:00 ec2 :−−−−−end ssh host key fingerprints−−−−− g ’ modules : config ’ at thu , 04 jun 2020 12:06:59 +0000. up 612.11 seconds . 4 12:07:00 ec2 : 1024 sha256 :zbnyksvvyzvhkjel+pwkpsducn21yicex/ 4 12:07:00 ec2 : 256 sha256 :ywsz/5+7u7d3sicd7hynyajxyewnt5nq+ i n s t a l l e r :wgysapzyqbfyqu2x2hym f i n g e r p r i n t s found f o r user ####################################################### bitar9fvhuh2fnyvsjjnldprdacm5est0dmrwftui8k <14>jun <14>jun 4 12:07:00 ec2 : 4 12:07:00 ec2 : <14>jun 4 12:07:00 ec2 : 3072 sha256 : <14>jun 4 12:07:00 ec2 : 256 sha256 : the f o l l o w i n g ’random ’ passwords <14>jun zi3so3ben8 ###### <14>jun <14>jun dboxqdpq0 (dsa) (ecdsa) (ed25519) (rsa) . . . . <14>jun 360

361

<14>jun 4 12:07:00 ec2 : ###### hgg4u8zgeqmimi= ####################################################### aaaae2vjzhnhlxnoytitbmlzdhayntyaaaaibmlzdhayntyaaabbbixm6t1/ 35 ot /api59thijbzg+qgjj17+1zvhfzmedbstwpm7e9pstpzum7w1ihwqdvlqdbm/ −−−−−begin ssh host key keys−−−−− ecdsa−sha2−nistp256 root§ubuntu−s e r v e r ssh−ed25519 aaaac3nzac1lzdi1nte5aaaain7qtu+en+rgruj2zuxwgkmqlmh+35/gr/ root§ubuntu−s e r v e r ssh−rsa aaaab3nzac1yc2eaaaadaqabaaabgqdjdkt7iuavsjkuqi1l3fhyse+ kchebbs3v48eroy9bmdisehfjyxgy2weh0tgjjnrrogjhzjvnr+qaqjbioj9d/ gj7ulwgggjyh639px oeod16k4na twxegwlp8eay9avtjb k1riylnmqltx/sihgiymjhlctklvois4l0frt9fif54qi/ jejlwgjiw3w2xgcy9odt0q5g3psmlz8ktr imtf9fy7wjepa08b3fimywsz9enus/ geceugv3m1mvrzpaqju27nueopsmzhr62imxgvijyiu3dukazm mbdwxhdlmq8ri8pehyhdifr6g2ifxoy5qlmb3hisklq/r6pllexbb748gn2i8wcvk0aegfa/ vyd+acbbzyhvbiw7w1cqw/ohik3wyosuyi9njq2iqoa7kkgh+1xoyq/e4/moqxhik/ kjdw3rnu oaiudyakacwmp1 f i n i s h runnin root§ub f i n g e r p r i n t s und f o r user i n s t a l l e r . g ’ modules : f i n a l ’ at thu , 04 jun 2020 12:07:00 +0000. up 612.79 seconds . r /fba3hlf0f7mvhvxa3twzc2wyuxfptmepvpydp2pscthmhgboahrgiy2cdsqg8sudpkroe= ed at thu , 04 jun 2020 12:07:00 +0000. datasource datasourcenocloud ¬seed=/var ci−i n f o : no authorized ssh keys untu−s e r v e r −−−−−end ssh host key keys−−−−− ¬ 612.877357| cloud−init¬2045 | : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 ¬ 612.877426| cloud−init¬2045 | : ¬ 612.877468| cloud−init¬2045 | : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 ¬ 612.877509| cloud−init¬2045 | : welcome to ubuntu server ¬ 612.877551| cloud−init¬2045 | : above you w i l l to ssh−in ¬ 612.877634| cloud−init¬2045 | : in the cloud−i n i t ke tty1 or hmc ascii terminal you can complete the i n s t a l l a t i o n there too . ib / cloud / seed / nocloud | ¬dsmode=net | . up 612.87 seconds ‘ i n s t a l l e r ‘ user . you can use these they were a l s o provisioned to the nd complete the i n s t a l l a t i o n . find ssh host keys and a i f you have access to the graphical console , i f you provided ssh keys password s e t f o r the i n s t a l l e r user . c r e d e n t i a l s i n s t a l l e r ü datasou rce , fo / l a l i random i s p o s s i b l e to connect i t i n s t a l l e r over might allow the use of a more capable terminal . to the the network , which 361

362

to connect , ssh to i n s t a l l e r § 1 0 . 2 2 2 . 1 1 1 . 2 4 . the password you should use i s ”kruxtz5duraypkcjcuva ” . the host key f i n g e r p r i n t s are : sha256 :3 ivymku05lqskbxovzujmzdtxpz3rjl3deqsg3uwc54 rsa ecdsa sha256 : xd1xnkbpn49dubup8uwro2mu1gm4mtnqr2wewg1fs3o ed25519 sha256 : hk3+/4+x7njbhl6/e /6xfhnxsbhbsovt6i8yefuepko ubuntu focal fossa ( development branch ) ubuntu−s e r v e r ttys0 • the next step is now to remotely connect to the install system and to proceed with the subiquity installer. • please notice that at the end of the installer boot up process all needed data is provided to proceed with running the installer in a remote ssh shell. the command to execute locally is: user@workstation :~ $ ssh i n s t a l l e r @ 1 0 . 2 2 2 . 1 1 1 . 2 4 • and a temporary randon password for the installation got created and shared as well, here: ”kruxtz5duraypkcjcuva” (use it without the leading and trailing double quotes.) user@workstation :~ $ ssh i n s t a l l e r @ 1 0 . 2 2 2 . 1 1 1 . 2 4 the a u t h e n t i c i t y of host ’ 1 0 . 2 2 2 . 1 1 1 . 2 4 ( 1 0 . 2 2 2 . 1 1 1 . 2 4 ) ’ can ’ t be ecdsa key f i n g e r p r i n t sha256 : xd1xnkbpn49dubup8uwro2mu1gm4mtnqr2wewg1fs3o . are you sure you want to continue connecting ( yes /no /[ f i n g e r p r i n t ] ) ? yes l i s t of known warning : permanently added ’ 1 0 . 2 2 2 . 1 1 1 . 2 4 ’ (ecdsa) to the i s e s t a b l i s h e d . hosts . i n s t a l l e r @ 1 0 . 2 2 2 . 1 1 1 . 2 4 ’ s password : kruxtz5duraypkcjcuva • one may now temporarily see some login messages like these: welcome to ubuntu focal fossa ( development branch ) g e n e r i c s390x ) * documentation : * management : * support : https :// help . ubuntu . com https :// landscape . canonical . com https :// ubuntu . com/ advantage (gnu/linux 5.4.0−42− system information as of wed jun 3 17:32:10 utc 2020 system load : usage of /home : unknown 0.0 memory usage : 2% swap usage : 0% 0 updates can be i n s t a l l e d immediately . 0 of these updates are s e c u r i t y updates . processes : users logged in : 0 146 the programs the exact d i s t r i b u t i o n terms i n d i v i d u a l f i l e s included with the ubuntu system are f r e e software ; f o r each program are described in the in / usr / share /doc /*/ copyright . 362

363

ubuntu comes with absolutely no warranty, a p p l i c a b l e law . to the extent permitted by • and eventually the initial subiquity installer screen shows up: ==================================================================== willkommen ! bienvenue ! welcome ! ????? ??????????! welkom ! ==================================================================== use up, down and enter keys to s e l e c t your language . [ english [ asturianu [ cataln [ hrvatski [ nederlands [ suomi [ francais [ deutsch [ magyar [ latvie ?u [ norsk bokm? l [ polski [ espanol > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] • from here just proceed with the installation as usual … (i’m leaving some pretty standard screenshots here just to give an example for a basic installation …) ==================================================================== keyboard c o n f i g u r a t i o n ==================================================================== s e l e c t your keyboard layout below , or s e l e c t ” i d e n t i f y keyboard ” to please detect your layout automatically . layout : [ english (us) variant : [ english (us) v ] v ] [ i d e n t i f y keyboard ] [ done [ back ] ] ==================================================================== ==================================================================== online names ^ zdev setup id ฀ 363

364

0.0.0009 0 . 0 . 0 0 0 c 0 . 0 . 0 0 0 d 0 . 0 . 0 0 0 e generic−ccw ฀ dasd−eckd ฀ 0.0.0190 0.0.0191 0 . 0 . 0 1 9 d 0 . 0 . 0 1 9 e 0.0.0200 0.0.0300 0.0.0400 0.0.0592 > ฀ > ฀ > ฀ > ฀฀ > ฀ > ฀ > ฀ > > > > > ] ] [ continue [ back v • if the list is long, hit the ‘end’ key that will automatically scroll you down to the bottom of the z devices list and screen. ==================================================================== ==================================================================== online names zdev setup id ฀ 0.0.0009 0 . 0 . 0 0 0 c 0 . 0 . 0 0 0 d 0 . 0 . 0 0 0 e generic−ccw ฀ dasd−eckd ฀ 0.0.0190 0.0.0191 0 . 0 . 0 1 9 d 0 . 0 . 0 1 9 e ฀฀฀฀฀฀฀฀฀฀฀฀฀฀ 0.0.0200 ฀ 0.0.0300 ฀ 0.0.0400 ฀ 0.0.0592 ฀฀฀฀฀฀฀฀฀฀฀฀฀฀ zdev setup id ฀ generic−ccw ฀ ==================================================================== ==================================================================== online names ^ ^ v > ฀ > ฀ > ฀ > ฀฀ > ฀ > ฀ > ฀ >< ( c l o s e ) ฀ > enable ฀ > disable ฀ > > [ continue [ back ] ] 364

365

0.0.0009 0 . 0 . 0 0 0 c 0 . 0 . 0 0 0 d 0 . 0 . 0 0 0 e dasd−eckd ฀ 0.0.0190 0.0.0191 0 . 0 . 0 1 9 d 0 . 0 . 0 1 9 e 0.0.0200 0.0.0300 0.0.0400 0.0.0592 > ฀ > ฀ > ฀ > ฀฀ > ฀ > ฀ > ฀ > > > > > ] ] onli ne dasda [ continue [ back ==================================================================== ==================================================================== zdev setup dasd−eckd 0.0.0190 0.0.0191 0 . 0 . 0 1 9 d 0 . 0 . 0 1 9 e 0.0.0200 0.0.0300 0.0.0400 0.0.0592 qeth ฀ 0 . 0 . 0 6 0 0 : 0 . 0 . 0 6 0 1 : 0 . 0 . 0 6 0 2 0 . 0 . 0 6 0 3 : 0 . 0 . 0 6 0 4 : 0 . 0 . 0 6 0 5 dasd−eckd ฀ 0.0.1607 onli ne dasda > > > > ฀ > ฀ > ฀ > ฀ > ฀฀ enc600 > ฀ > ฀฀ [ continue [ back > ] ] ==================================================================== network connections ==================================================================== configure at machines , and which p r e f e r a b l y provides l e a s t one i n t e r f a c e t h i s s e r v e r can use to talk to other f o r updates . s u f f i c i e n t access name type notes eth 10.222.111.24/24 [ enc600 s t a t i c 0 2 : 2 8 : 0 a : 0 0 : 0 0 : 3 9 / unknown vendor / unknown model > ] − [ create bond > ] 365 v ^ v

366

[ done [ back ] ] ==================================================================== ==================================================================== system r e q u i r e s a proxy to connect to the internet , enter i t s configure proxy t h i s i f d e t a i l s here . proxy address : i f you need to use a http proxy to access enter blank . the proxy information here . otherwise , the outside world , leave t h i s the proxy information should be given in the standard form of ” http : / / [ [ user ] [ : pass ]@] host [ : port ] / ” . [ done [ back ] ] ==================================================================== configure ubuntu archive mirror ==================================================================== i f you use an a l t e r n a t i v e mirror i t s d e t a i l s here . mirror address : f o r ubuntu , http :// ports . ubuntu . com/ubuntu−ports you may provide an archive mirror of the d e f a u l t . enter that w i l l be used instead 366

367

[ done [ back ] ] ==================================================================== guided storage c o n f i g u r a t i o n ==================================================================== configure a guided storage layout , or create a custom one : (x) use an e n t i r e disk [ 0x0200 l o c a l disk 6.876g [ ] set up t h i s disk as an lvm group [ ] encrypt the lvm group with luks passphrase : confirm passphrase : ( ) custom storage layout [ done [ back ] ] ==================================================================== ==================================================================== storage c o n f i g u r a t i o n file system summary ฀ mount point [ / size 6.875g new ext4 type device type ฀ new p a r t i t i o n of l o c a l disk > ] ฀฀฀ available devices ฀฀ no a v a i l a b l e devices ฀฀ [ create software raid (md) > ] [ create volume group (lvm) > ] ฀ ฀ used devices [ done [ reset [ back ] ] ] 367 v ] ^ v

368

==================================================================== ==================================================================== storage c o n f i g u r a t i o n file system summary ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ confirm d e s t r u c t i v e action ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ s e l e c t i n g continue below w i l l begin the i n s t a l l a t i o n process and ฀฀ r e s u l t in the l o s s of data on the di s ks s e l e c t e d to be formatted . ^ ฀฀฀฀ you w i l l not be able to return to t h i s or a previous i n s t a l l a t i o n has s t a r t e d . ฀฀฀฀ screen once the ฀฀ are you sure you want to continue ? ฀฀฀฀ [ no [ continue ฀฀ ] ] ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ [ reset [ back ] ] ==================================================================== p r o f i l e setup ==================================================================== enter can c o n f i g u r e ssh access on the next f o r the username and password you w i l l use to log in to the system . you s t i l l needed screen but a password i s sudo . your name : ed example your server ’ s name : 10.222.111.24 the name i t uses when i t t a l k s to other computers . pick a username : ubuntu choose a password : ******** confirm your password : ******** [ done ] ==================================================================== ssh setup ==================================================================== you can choose to i n s t a l l the openssh s e r v e r package to enable secure remote 368

369

access to your s e r v e r . [ ] i n s t a l l openssh s e r v e r import ssh i d e n t i t y : [ no you can import your ssh keys from github or launchpad . v ] import username : [x] allow password authentication over ssh [ done [ back ] ] • it’s an nice and convenient new feature to add the users ssh keys during the installation to the system, since that makes the system login password-less already on the initial login! ==================================================================== ssh setup ==================================================================== the openssh s e r v e r package to enable secure remote you can choose to i n s t a l l access to your s e r v e r . [x] i n s t a l l openssh s e r v e r import ssh i d e n t i t y : from launchpad v ] [ you can import your ssh keys from github or launchpad . launchpad username : user enter your launchpad username . [x] allow password authentication over ssh [ done [ back ] ] ==================================================================== ssh setup ==================================================================== you can choose to i n s t a l l access to your s e r v e r . ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ the openssh s e r v e r package to enable secure remote confirm ssh keys ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ 369

370

keys with the f o l l o w i n g f i n g e r p r i n t s were fetched . do you want to ฀฀ use them? ฀฀฀฀ 2048 sha256 : jogsdfw7nbjrkg17sryxaegor0izeddwdr9hpbc2kiw user@w520 ฀฀ (rsa) ฀฀ 521 sha256 : t3jzxvb6k1gzxjpp5nfgx4yxvk0jhhgvbw01f7/ fz2c ฀฀ frank . heimes@canonical . com (ecdsa) ฀฀฀฀ [ yes [ no ฀฀ ] ] ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ [ done [ back ] ] ==================================================================== featured server snaps ==================================================================== the package , publisher and in s e r v e r environments . s e l e c t or d e s e l e c t with snaps these are popular space, press enter to see more d e t a i l s of v e r s i o n s a v a i l a b l e . ] kata−containers lightweight v i r t u a l machines s t r e s s−ng docker container eclipse mosquitto mqtt broker to load , things s t r e s s that runtime seamlessly plug into > > > > t e s t and benchmark a computer s > > > > > r e s i l i e n t key−value s t o r e by coreos high a v a i l a b i l i t y vrrp/bfd and load−balancing f o r linu > a t o o l sabnzbd get python based softlayer api tool . digitalocean command l i n e secure and s t a b l e devops . juju keeps complexit > from one computer to another , simple , s a f e l y ] docker ] mosquitto ] etcd ] sabnzbd ] ] wormhole ] s l c l i ] doctl ] keepalived ] juju [ [ [ [ [ [ [ [ [ [ [ t o o l [ done [ back ] ] ==================================================================== i n s t a l l complete ! ==================================================================== ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ s e r v i c e ฀ ฀฀ c o n f i g u r i n g raid (mdadm) i n s t a l l i n g kernel s e t t i n g up swap ฀฀ apply networking c o n f i g ฀฀ writing etc / f s t a b ฀฀ c o n f i g u r i n g multipath ฀฀ updating packages on target c o n f i g u r i n g p o l l i n a t e user−agent on target ฀฀ system ฀฀ 370 ^฀

371

c o n f i g u r a t i o n ฀฀ running ’ curtin hook ’ updating i n i t r a m f s f i n a l i z i n g i n s t a l l a t i o n ฀฀ ฀฀ curtin command hook ฀฀ executing l a t e commands ฀฀ system c o n f i g u r a t i o n ฀฀ c o n f i g u r i n g cloud−i n i t i n s t a l l i n g openssh−s e r v e r ฀฀฀ | f i n a l ฀ ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ [ view f u l l log ] ==================================================================== ==================================================================== i n s t a l l a t i o n complete ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ finished i n s t a l l ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ apply networking c o n f i g ฀ writing etc / f s t a b ฀฀ c o n f i g u r i n g multipath ฀฀ updating packages on target c o n f i g u r i n g p o l l i n a t e user−agent on target ฀฀ c o n f i g u r a t i o n ฀฀ system ฀฀ running ’ curtin hook ’ updating i n i t r a m f s f i n a l i z i n g i n s t a l l a t i o n ฀฀ ฀฀ curtin command hook ฀฀ executing l a t e commands ฀฀ system c o n f i g u r a t i o n ฀฀ c o n f i g u r i n g cloud−i n i t i n s t a l l i n g openssh−s e r v e r ฀฀ r e s t o r i n g apt c o n f i g u r a t i o n ฀฀฀ ฀฀ f i n a l downloading and i n s t a l l i n g s e c u r i t y updates ฀ ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ [ view f u l l [ reboot log ] ] ==================================================================== i n s t a l l a t i o n complete ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ finished i n s t a l l ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ apply networking c o n f i g ฀ writing etc / f s t a b ฀฀ c o n f i g u r i n g multipath ฀฀ updating packages on target c o n f i g u r i n g p o l l i n a t e user−agent on target ฀฀ c o n f i g u r a t i o n ฀฀ system ฀฀ running ’ curtin hook ’ updating i n i t r a m f s f i n a l i z i n g i n s t a l l a t i o n ฀฀ ฀฀ curtin command hook ฀฀ executing l a t e commands ฀฀ system c o n f i g u r a t i o n ฀฀ f i n a l 371 v ^฀ v ^฀

372

c o n f i g u r i n g cloud−i n i t i n s t a l l i n g openssh−s e r v e r ฀฀ r e s t o r i n g apt c o n f i g u r a t i o n ฀฀฀ ฀฀ downloading and i n s t a l l i n g s e c u r i t y updates ฀ ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ v connection to 10.222.111.24 closed . user@workstation :~ $ [ connection to 10.222.111.24 closed by remote host . rebooting . . . ] [ • type a ‘reset’ to clear the screen and to revert it back to the defaults: user@workstation :~ $ r e s e t user@workstation :~ $ • now remove the old host key, since the system got a new ones during the installation: user@workstation :~ $ ssh−keygen−f ”/home/ user /. ssh /known_hosts”−r ”10.222.111.24” # host 10.222.111.24 found : l i n e 159 /home/ user /. ssh /known_hosts updated . original contents user@workstation :~ $ retained as /home/ user /. ssh /known_hosts . old • and finally login to the newly installed z/vm guest: user@workstation :~ $ ssh ubuntu@10 . 2 2 2 . 1 1 1 . 2 4 warning : permanently added the ecdsa host key f o r ’ 1 0 . 2 2 2 . 1 1 1 . 2 4 ’ welcome to ubuntu focal fossa ( development branch ) l i s t of known hosts . to the g e n e r i c s390x ) * documentation : * management : * support : https :// help . ubuntu . com https :// landscape . canonical . com https :// ubuntu . com/ advantage ip address (gnu/linux 5.4.0−42− system information as of wed 03 jun 2020 05:50:05 pm utc system load : 0.08 usage of /: 18.7% of 6.70gb memory usage : 2% swap usage : 0% processes : users logged in : 0 157 4 updates can be i n s t a l l e d immediately . 0 of these updates are s e c u r i t y updates . to see these a d d i t i o n a l updates run : apt l i s t −−upgradable the programs the exact d i s t r i b u t i o n terms included with the ubuntu system are f r e e software ; f o r each program are described in the i n d i v i d u a l f i l e s in / usr / share /doc /*/ copyright . ubuntu comes with absolutely no warranty, a p p l i c a b l e law . to the extent permitted by 372

373

to run a command as administrator see ”man sudo_root ” f o r d e t a i l s . ( user ” root ”) , use ” sudo <command>”. ubuntu 1 user , load average : 0.08 , 0.11 , 0.05 ubuntu@10 . 2 2 2 . 1 1 1 . 2 4 : ~ $ uptime 17:50:09 up 1 min , no lsb modules are a v a i l a b l e . d i s t r i b u t o r id : description : ubuntu focal fossa ( development branch ) release : codename : ubuntu@10 . 2 2 2 . 1 1 1 . 2 4 : ~ $ l s b _ r e l e a s e−a ubuntu@10 . 2 2 2 . 1 1 1 . 2 4 : ~ $ uname−a linux 10.222.111.24 5.4.0−42− g e n e r i c #30−ubuntu smp mon apr 20 16:57:22 utc 2020 s390x s390x s390x gnu/linux 20.04 f o c a l ubuntu@10 . 2 2 2 . 1 1 1 . 2 4 : ~ $ e x i t logout connection to 10.222.111.24 closed . user@workstation :~ $ done ! interactive live server installation on ibm z lpar (s390x) [this installation - without specifying a parmfile - works with the 20.04 aka ‘focal’ daily live image, that will later become the 20.04.1 image and any newer ubuntu releases, like 20.10 aka ‘groovy’.] • the following guide assumes that an ftp installation server is in place, that can be used by the ‘load from removable media and server’ task of the hmc. • download the ‘focal daily live image’ from here (later 20.04.1 image): http://cdimage.ubuntu.com/ubuntu- server/focal/daily-live/current/ and extract and host it on your ftp installation server. • open the ibm z hardware management console (hmc) and navigate to ‘systems management’ –> ‘<your system indicated by it’s serial number>’ • select the lpar that you are going to install ubuntu server on; in this example lpar ‘s1lp11’ is used • now select menu: ‘recovery’ –> ‘load from removable media or server’ task • and fill out the ‘load from removable media or server’ form like follows (adapt the settings to your particular installation environment): task to load operating system software or u t i l i t y programs load from removable media , or server− <s e r i a l >: s1lp11 from a cd / dvd−rom or a s e r v e r o hardware management console cd / dvd−rom o hardware management console cd / dvd−rom and assign f o r operating system o hardware management console usb f l a s h memory drive o hardware management console usb f l a s h memory drive and assign f o r that can be accessed using ftp. the source of the software : use use t h i s s e l e c t operating system use * ftp source host computer : user id : f t p u s e r password : ******** account ( optional ) : f i l e i n s t a l l−s e r v e r l o c a t i o n ( optional ) : ubuntu−daily−l i v e−server−20.04/ boot 373

374

name you may need to adjust the file location according to your install server environment. d e f a u l t kernel ) • confirm the entered data • confirm again that jobs might be canceled if proceeding the software to i n s t a l l . <s e r i a l >: s1lp11 s e l e c t s e l e c t * load from removable media or server− s e l e c t software to i n s t a l l− ubuntu−daily−l i v e−server−20.04/ boot/ubuntu . i n s load from removable media or server task confirmation− disruptive task confirmation : load from removable media or server− <s e r i a l >: s1lp11 load w i l l cause jobs do you want to continue with t h i s act33501 • and confirm a last time that it’s understood that the task is disruptive: to be c a n c e l l e d . <s e r i a l >: s1lp11 attention : the load from removable media or server task ? task i s d i s r u p t i v e . description ubuntu f o r ibm z ( executing the load from removable media or server adversely a f f e c t f o r each object before continuing with the load from removable media or server l i s t e d below . review the confirmation text the o b j e c t s task may task . objects server that w i l l be a f f e c t e d by the load from removable media or task system name <s e r i a l >: s1lp11 type image os name status operating confirmation text load from removable media or server causes operations c u r r e n t l y in use and operating normally . to be disrupted , s i n c e the target i s do you want to execute the load from removable media or server task ? • the ‘load from removable media or server’ task is now executed … load from removable media or server progress− p00b8f67 : s1lpb s e n s i t i v e help . 00:55:00 turn on context function duration time : elapsed time : 00:00:04 s e l e c t * object name <s e r i a l > s1lp11 status please wait while the image i s being loaded . • this may take a moment, but you will soon see: load from removable media or server progress− <s e r i a l >: s1lp11 00:55:00 function duration time : elapsed time : 00:00:21 s e l e c t * object name <s e r i a l > s1lp11 status success 374

375

• close the ‘load from removable media or server’ task and open the console aka ‘operating system messages’ instead. and in case no parmfile got configured or provided, one will find the following lines in the ‘operating system messages’ task: operating system messages− <s e r i a l >: s1lp11 message unable to find a medium container a l i v e attempt from a url? yes no ( d e f a u l t yes ) : i n t e r a c t i v e netboot f i l e system • so one will now by default land in the interactive network configuration menu (again, only if no parmfile got prepared with sufficient network configuration information). • proceed with the interactive network configuration, here in this case in a vlan environemnt: f i l e system i n t e r a c t i v e netboot unable to find a medium container a l i v e attempt from a url? yes no ( d e f a u l t yes ) : yes available qeth devices : 0 . 0 . c000 0 . 0 . c003 0 . 0 . c006 0 . 0 . c009 0 . 0 . c00c 0 . 0 . c00f zdev to a c t i v a t e (comma separated , optional ) : 0 . 0 . c000 qeth device 0 . 0 . c000 : 0 . 0 . c001 : 0 . 0 . c002 configured two methods a v a i l a b l e * s t a t i c : * dhcp : s t a t i c dhcp ( d e f a u l t s t a t i c ip : 10.222.111.11 gateway ( d e f a u l t 1 0 . 2 2 2 . 1 1 1 . 1 ) : 1 0 . 2 2 2 . 1 1 1 . 1 dns ( d e f a u l t 1 0 . 2 2 2 . 1 1 1 . 1 ) : 1 0 . 2 2 2 . 1 1 1 . 1 vlan id ( optional ) : 1234 s t a t i c ip c o n f i g u r a t i o n f o r automatic ip c o n f i g u r a t i o n ip c o n f i g u r a t i o n : ’ dhcp ’ ) : f o r f o r . i s o u r l : s390x . i s o ( d e f a u l t ) http_proxy ( optional ) : http :// cdimage . ubuntu . com/ubuntu−s e r v e r / l i v e / current / focal−l i v e−server− ftp : / / 1 0 . 1 1 . 1 2 . 2 : 2 1 / ubuntu−daily−l i v e−server−20.04/ focal−l i v e−server−s390x ip−config : encc000 .1234 hardware address 3e : 0 0 : 1 0 : 5 5 : 0 0 : f f mtu 1500 ip−config : encc000 .1234 guessed broadcast address 10.222.111.255 ip−config : encc000 .1234 complete : • after the last interactive step here, that this is about an optional proxy configuration, the installer will broadcast : 10.222.111.255 configuring networking . . . complete it’s boot-up process: netmask : 255.255.255.0 address : 10.222.111.11 gateway : 1 0 . 2 2 2 . 1 1 1 . 1 dns0 : 1 0 . 2 2 2 . 1 1 1 . 1 dns1 : 0 . 0 . 0 . 0 375

376

e x i s t s running running 401.547705] to skipping [ 0 ; 1 ; 3 9 mlogin prompts [0m break ordering c y c l e [ ip : rtnetlink answers : f i l e no search or nameservers r o o t s e r v e r : 0 . 0 . 0 . 0 rootpath : filename connecting to 1 0 . 1 1 . 1 2 . 2 : 2 1 ( 1 0 . 1 1 . 1 2 . 2 : 2 1 ) : 399.808930] /dev/ loop3 : can ’ t open blockdev [ [ [ 0 ; 1 ; 3 1m skip [0m] ordering c y c l e found , [ ’ i n i t ’ at wed, 03 jun 2020 17:07:40 +0000. up 406.87 seconds . [ [ | 72.9m 0 : 0 0 : 0 8 eta 10% |*** 168m 0 : 0 0 : 0 5 eta | 25% |******** 279m 0 : 0 0 : 0 4 eta | 42% |************* 390m 0 : 0 0 : 0 2 eta | 58% |****************** | 501m 0 : 0 0 : 0 1 eta 75% |************************ 595m 0 : 0 0 : 0 0 eta 89% |**************************** | 662m 0 : 0 0 : 0 0 eta 99% |******************************* | 663m 0 : 0 0 : 0 0 eta focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s focal−l i v e−server−s 100% |********************************| found in /run/net−encc000 . 1 2 3 4 . conf / run/net−*. conf /run/net6−*. conf systemd [ 1 ] : multi−user . target : job getty . target / s t a r t deleted s t a r t i n g with multi−user . target / s t a r t 406.241972] cloud−i n i t [ 1 3 2 1 ] : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 ’ i n i t−l o c a l ’ at wed, 03 jun 2020 17:07:39 +0000. up 406.00 seconds . 407.025557] cloud−i n i t [ 1 3 4 8 ] : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 407.025618] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : 407.025658] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : +−−−−−−−−−−−−−−+−−−−−−+−−−−−−−−−−−−−−− −−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−+−−−−−−−−+−−−−−−−−−−−−−−−−−−−+ 407.025696] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : hw−address ci−i n f o : 407.025731] cloud−i n i t [ 1 3 4 8 ] : +−−−−−−−−−−−−−−+−−−−−−+−−−−−−−−−−−−−−− −−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−+−−−−−−−−+−−−−−−−−−−−−−−−−−−−+ ci−i n f o : 407.025766] cloud−i n i t [ 1 3 4 8 ] : 407.025802] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : ci−i n f o : 407.025837] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : 407.025874] cloud−i n i t [ 1 3 4 8 ] : 407.025909] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : ci−i n f o : 407.025944] cloud−i n i t [ 1 3 4 8 ] : +−−−−−−−−−−−−−−+−−−−−−+−−−−−−−−−−−−−−− −−−−−−−−−−−−−−−+−−−−−−−−−−−−−−−+−−−−−−−−+−−−−−−−−−−−−−−−−−−−+ f : fea5 : c69e /64 | [ f : fea5 : c69e /64 | [ | 255.255.255.0 | global ++++net device i n f o++++ | encc000 .1234 | true | | encc000 .1234 | true | fe80 : : 3 ca7 | 72:5 d :0 d : 0 9 : ea :76 | | 72:5 d :0 d : 0 9 : ea :76 | | 72:5 d :0 d : 0 9 : ea :76 | | true | fe80 : : 3 ca7 236.11 [ 2 5 5 . 0 . 0 . 0 lo . lo . | scope | | | | | . 0 . 1 [ 128 [ device | up | | | | | | | | true | l i n k host host | true | :10 f 127.0 : : 1 / addr e s s [ :10 f 1 0 . 2 4 5 . [ [ [ encc000 l i n k mask . . . | | | | | | 376

377

| | | | u | | | | | 0 1 [ [ [ ug | 0 . 0 . 0 . 0 0 . 0 . 0 . 0 0 . 0 . 0 . 0 | flags gateway genmask i n t e r f a c e 1 0 . 2 2 2 . 1 1 1 . 1 | 1 0 . 2 2 2 . 1 1 1 . 0 | | encc000 .1234 | int e r f a c e [ | route | destination ++++++++++++++++++ [ [ pv4 i n f o++++++++++++++ [ | [ | 255.255.255.0 | encc000 .1234 | [ 407.025982] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : +++++++++++++route i 407.026017] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−−−−−−−− +−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−+ 407.026072] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : 407.026107] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−−−−−−−− +−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−+ 407.026141] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : ci−i n f o : 407.026176] cloud−i n i t [ 1 3 4 8 ] : 407.026212] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−−−−−−−− +−−−−−−−−−−−−−−−+−−−−−−−−−−−−−−+−−−−−−−+ 407.026246] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : ++++++++++++++++++++route ipv6 i n f o ci−i n f o : 407.026280] cloud−i n i t [ 1 3 4 8 ] : +−−−−−−−+−−−−−−−−−−−−−+−−−−−−−−−+−−−−− −−−−−−−−−+−−−−−−−+ ci−i n f o : 407.026315] cloud−i n i t [ 1 3 4 8 ] : 407.026355] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−+−−−−−−−−−+−−−−− −−−−−−−−−+−−−−−−−+ 407.026390] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : ci−i n f o : 407.026424] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : 407.026458] cloud−i n i t [ 1 3 4 8 ] : 407.026495] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : ci−i n f o : 407.026531] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : 407.026566] cloud−i n i t [ 1 3 4 8 ] : 407.026600] cloud−i n i t [ 1 3 4 8 ] : ci−i n f o : +−−−−−−−+−−−−−−−−−−−−−+−−−−−−−−−+−−−−− −−−−−−−−−+−−−−−−−+ 407.883058] cloud−i n i t [ 1 3 4 8 ] : generating public / private rsa key pair . 407.883117] cloud−i n i t [ 1 3 4 8 ] : your i d e n t i f i c a t i o n has been saved in / etc / | route | destination | gateway | 000.1234 | [ 000.1234 | [ 000.1234 | [ en cc000 [ en cc000 [ en cc000 [ fe80 : : / 6 4 fe80 : : / 6 4 f f 0 0 : : / 8 f f 0 0 : : / 8 | flags | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1 2 4 5 6 7 l o c a l l o c a l ssh / | | | u u u u u u : : : : : : : : : : : : encc encc [ | [ [ [ [ +++ encc 377

378

[ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ | | | | | | | | | | | | | | | | | | zmkgg9zdlezaeb+ . e . . o . o .= +o . . ssh / ssh_ qfz ssh_host_dsa_key [ ssh_host_rsa_key [ ssh_ i d e n t i f i c a t i o n has been saved in / etc / host_rsa_key . pub [ [ host_dsa_key . pub [ [ | | | + =ooo++ | | + s *. o . | . = o o . . o+o ..+ o . | o =.. =o+++| . . . . ++*o| 407.883154] cloud−i n i t [ 1 3 4 8 ] : your public key has been saved in / etc / ssh / 407.883190] cloud−i n i t [ 1 3 4 8 ] : the key f i n g e r p r i n t 407.883232] cloud−i n i t [ 1 3 4 8 ] : sha256 : kx5chc4yl9dxpvhnp6esfs+j/ rta root@ubuntu−s e r v e r 407.883267] cloud−i n i t [ 1 3 4 8 ] : the key ’ s randomart image i s : 407.883302] cloud−i n i t [ 1 3 4 8 ] : +−−−[rsa 3072]−−−−+ 407.883338] cloud−i n i t [ 1 3 4 8 ] : 407.883374] cloud−i n i t [ 1 3 4 8 ] : 407.883408] cloud−i n i t [ 1 3 4 8 ] : 407.883443] cloud−i n i t [ 1 3 4 8 ] : 407.883478] cloud−i n i t [ 1 3 4 8 ] : 407.883512] cloud−i n i t [ 1 3 4 8 ] : 407.883546] cloud−i n i t [ 1 3 4 8 ] : 407.883579] cloud−i n i t [ 1 3 4 8 ] : 407.883613] cloud−i n i t [ 1 3 4 8 ] : 407.883648] cloud−i n i t [ 1 3 4 8 ] : +−−−−[sha256]−−−−−+ 407.883682] cloud−i n i t [ 1 3 4 8 ] : generating public / private dsa key pair . 407.883716] cloud−i n i t [ 1 3 4 8 ] : your 407.883750] cloud−i n i t [ 1 3 4 8 ] : your public key has been saved in / etc / ssh / 407.883784] cloud−i n i t [ 1 3 4 8 ] : the key f i n g e r p r i n t 407.883817] cloud−i n i t [ 1 3 4 8 ] : sha256 : xu3vlg1brekdy3dsumzc/ lg5y/+nhzlemldk/ am0 root@ubuntu−s e r v e r 407.883851] cloud−i n i t [ 1 3 4 8 ] : the key ’ s randomart image i s : 407.883905] cloud−i n i t [ 1 3 4 8 ] : +−−−[dsa 1024]−−−−+ 407.883941] cloud−i n i t [ 1 3 4 8 ] : 407.883975] cloud−i n i t [ 1 3 4 8 ] : 407.884008] cloud−i n i t [ 1 3 4 8 ] : 407.884042] cloud−i n i t [ 1 3 4 8 ] : 407.884076] cloud−i n i t [ 1 3 4 8 ] : 407.884112] cloud−i n i t [ 1 3 4 8 ] : 407.884145] cloud−i n i t [ 1 3 4 8 ] : 407.884179] cloud−i n i t [ 1 3 4 8 ] : 407.884212] cloud−i n i t [ 1 3 4 8 ] : 407.884246] cloud−i n i t [ 1 3 4 8 ] : +−−−−[sha256]−−−−−+ 407.884280] cloud−i n i t [ 1 3 4 8 ] : generating public / private ecdsa key pair . 407.884315] cloud−i n i t [ 1 3 4 8 ] : your 407.884352] cloud−i n i t [ 1 3 4 8 ] : your public key has been saved in / etc / ssh / 407.884388] cloud−i n i t [ 1 3 4 8 ] : the key f i n g e r p r i n t 407.884422] cloud−i n i t [ 1 3 4 8 ] : sha256 :p+hbf3fj/pu6+0kaywuyii3lyuc09za9/ gde root@ubuntu−s e r v e r . . o | o . o o | +.o+o+ | | . . . e*oo . . s+o =.. | . +o+oo . o | **+o*o | . oo.*+oo | .+ ===| host_ecdsa_key . pub [ [ i d e n t i f i c a t i o n has been saved in / etc / ssh_host_ecdsa_key [ ssh / ssh_ i s : i s : i s : a2elcdo 378

379

[ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ [ ssh_host_ed25519_key [ i d e n t i f i c a t i o n has been saved in / etc / cbzpkr9efhub1scdzwsdsdwjzy9fpsiwriyc9ers host_ed25519_key . pub [ [ | | . | . . e . o | o . ooo o . | o +s . + . . . . +..* oo.+ . | = o+=.+.+ | . o . . . . . . + + o oo | oo . . +.*@*+| 407.884456] cloud−i n i t [ 1 3 4 8 ] : the key ’ s randomart image i s : 407.884490] cloud−i n i t [ 1 3 4 8 ] : +−−−[ecdsa 256]−−−+ 407.884524] cloud−i n i t [ 1 3 4 8 ] : 407.884558] cloud−i n i t [ 1 3 4 8 ] : 407.884591] cloud−i n i t [ 1 3 4 8 ] : 407.884625] cloud−i n i t [ 1 3 4 8 ] : 407.884660] cloud−i n i t [ 1 3 4 8 ] : 407.884694] cloud−i n i t [ 1 3 4 8 ] : 407.884728] cloud−i n i t [ 1 3 4 8 ] : 407.884762] cloud−i n i t [ 1 3 4 8 ] : 407.884795] cloud−i n i t [ 1 3 4 8 ] : 407.884829] cloud−i n i t [ 1 3 4 8 ] : +−−−−[sha256]−−−−−+ 407.884862] cloud−i n i t [ 1 3 4 8 ] : generating public / private ed25519 key pair . 407.884896] cloud−i n i t [ 1 3 4 8 ] : your 407.884930] cloud−i n i t [ 1 3 4 8 ] : your public key has been saved in / etc / ssh / 407.884966] cloud−i n i t [ 1 3 4 8 ] : the key f i n g e r p r i n t 407.884999] cloud−i n i t [ 1 3 4 8 ] : sha256 : hz0 root@ubuntu−s e r v e r 407.885033] cloud−i n i t [ 1 3 4 8 ] : the key ’ s randomart image i s : 407.885066] cloud−i n i t [ 1 3 4 8 ] : +−−[ed25519 256]−−+ 407.885100] cloud−i n i t [ 1 3 4 8 ] : 407.885133] cloud−i n i t [ 1 3 4 8 ] : 407.885167] cloud−i n i t [ 1 3 4 8 ] : 407.885200] cloud−i n i t [ 1 3 4 8 ] : 407.885238] cloud−i n i t [ 1 3 4 8 ] : 407.885274] cloud−i n i t [ 1 3 4 8 ] : 407.885308] cloud−i n i t [ 1 3 4 8 ] : 407.885345] cloud−i n i t [ 1 3 4 8 ] : 407.885378] cloud−i n i t [ 1 3 4 8 ] : 407.885420] cloud−i n i t [ 1 3 4 8 ] : +−−−−[sha256]−−−−−+ 418.521933] cloud−i n i t [ 2 1 8 5 ] : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 418.522012] cloud−i n i t [ 2 1 8 5 ] : set 418.522053] cloud−i n i t [ 2 1 8 5 ] : ci−i n f o : no authorized ssh keys root@ubuntu−s e r v e r root@ubuntu−s e r v e r 3 17:07:52 ec2 :−−−−−begin ssh host key fingerprints−−−−− g ’ modules : config ’ at wed, 03 jun 2020 17:07:52 +0000. up 418.40 seconds . [ [ the f o l l o w i n g ’random ’ passwords 3 17:07:52 ec2 : 1024 sha256 : xu3vlg1brekdy3dsumzc/ lg5y/+nhzlemldk/ 3 17:07:52 ec2 : 256 sha256 :p+hbf3fj/pu6+0kaywuyii3lyuc09za9/ i n s t a l l e r : c7bzrw76s4mjzmpf4euy f i n g e r p r i n t s found f o r user ####################################################### cbzpkr9efhub1scdzwsdsdwjzy9fpsiwriyc9ershz0 ../%x. . o .=o&*+= = .+*.* . . b = + o + s . . . <14>jun <14>jun 3 17:07:52 ec2 : 3 17:07:52 ec2 : <14>jun 3 17:07:52 ec2 : 256 sha256 : <14>jun a2elcdogde (dsa) (ecdsa) . o o o + e . . . i s : | | | | | | | | | ssh / ssh_ runnin ###### <14>jun <14>jun qfzam0 | | | | | | | | | | | | | | | | | | 379 i n s t a l l e r .

380

(rsa) ###### (ed25519) <14>jun rta <14>jun <14>jun 3 17:07:52 ec2 : ####################################################### 3 17:07:52 ec2 : 3072 sha256 : kx5chc4yl9dxpvhnp6esfs+j/zmkgg9zdlezaeb+ 3 17:07:52 ec2 :−−−−−end ssh host key fingerprints−−−−− root@ubuntu−s e r v e r root@ubuntu−s e r v e r −−−−−begin ssh host key keys−−−−− ecdsa−sha2−nistp256 root@ubuntu−s e r v e r ssh−ed25519 aaaac3nzac1lzdi1nte5aaaaijfzgips94njnor4qumiyqljoslz48p+ root@ubuntu−s e r v e r ssh−rsa aaaab3nzac1yc2eaaaadaqabaaabgqchko06o715fajd6imk7qzbwnl/cpgq2a2gqeqfno jof /41ygxuw5ag0iqobwfpv9jdsmf5z4qhkzx8tfcpkc0s4ur8qbxh1ddm4wcwcgtafvlqh7s4/ aaaae2vjzhnhlxnoytitbmlzdhayntyaaaaibmlzdhayntyaaabbbc2zp4fq r1+njoieqiisbx+ezej6ucxsli2xevurgwq8imyt6yyoxbopc/ xzefa6vbcdzk3sssw6lq83y7vmdrq= nvrd7zgd5k4t +1 ifnkczxthhnemarcrruty0mizspmcg/qvfe1wrxjzl+rtoj7giuhhqpm76fx+6 r9sqa zf1byhka87dxqiid2r yuubsxkgg0ntzlgszpqd3gb+hxrhhhlt5/xq+ njpq8jiupqsohtkbupsyvmcd9gdbz6vng2pubhwzp9x 17qtyowxddxk4xixatup4g8bh1of/czswqvxndfb7xqzrofuod9rmib+ dwbihsmh1krik4wwli6ih4hu xrykkvfb1xcze65kr42odi7jbbwxvxgrokx8drexnbpowozs0idm2zph3ci/0ucj4ltitbyycfae/ gyr root@ub f i n i s h [ runnin fo / l i n s t a l l e r . f i n g e r p r i n t s und f o r user [ 5si4skmxrixf5bnerzrgyjnfxkxmsfash7wf15w6gmsgzyd9si2jes9+4by32zzyoldpi0s= ed at wed, 03 jun 2020 17:07:52 +0000. datasource datasourcenocloud [ seed=/var g ’ modules : f i n a l ’ at wed, 03 jun 2020 17:07:52 +0000. up 418.79 seconds . [ ci−i n f o : no authorized ssh keys untu−s e r v e r −−−−−end ssh host key keys−−−−− 418.872320] cloud−i n i t [ 2 2 0 3 ] : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 418.872385] cloud−i n i t [ 2 2 0 3 ] : 418.872433] cloud−i n i t [ 2 2 0 3 ] : cloud−i n i t v . 20.2−45− g5f7825e2−0ubuntu1 418.872484] cloud−i n i t [ 2 2 0 3 ] : welcome to ubuntu server 418.872529] cloud−i n i t [ 2 2 0 3 ] : above you w i l l to ssh−in 418.872578] cloud−i n i t [ 2 2 0 3 ] : ib / cloud / seed / nocloud ] [ dsmode=net ] . up 418.86 seconds [ [ in the cloud−i n i t ‘ i n s t a l l e r ‘ user . you can use these they were a l s o provisioned to the nd complete the i n s t a l l a t i o n . to the graphical console , find ssh host keys and a i f you provided ssh keys i f you have access i n s t a l l e r user . password s e t c r e d e n t i a l s rce , [ l i i n s t a l l e r ! random a datasou f o r the 380

381

ke tty1 or hmc ascii terminal you can complete the i n s t a l l a t i o n there too . i s p o s s i b l e to connect i t i n s t a l l e r over might allow the use of a more capable terminal . to the the network , which to connect , ssh to i n s t a l l e r @ 1 0 . 2 2 2 . 1 1 1 . 1 1 . the password you should use i s ”c7bzrw76s4mjzmpf4euy ” . the host key f i n g e r p r i n t s are : sha256 : kx5chc4yl9dxpvhnp6esfs+j/zmkgg9zdlezaeb+rta rsa ecdsa sha256 :p+hbf3fj/pu6+0kaywuyii3lyuc09za9/a2elcdogde ed25519 sha256 : cbzpkr9efhub1scdzwsdsdwjzy9fpsiwriyc9ershz0 ubuntu focal fossa ( development branch ) ubuntu−s e r v e r ubuntu−s e r v e r l o g i n : ascii console or or with a remote ssh session. sclp_line0 • at this point one can proceed with the regular installation either by using recovery –> integrated • if the ‘integrated ascii console’ got opened (and maybe ‘f3’ was hit to refresh the task), the initial subiquity installation screen is presented, that looks like this: ================================================================================ willkommen ! bienvenue ! welcome ! ????? ??????????! welkom ! [ help ] ================================================================================ to s e l e c t your language . use up, down and enter keys [ english [ asturianu [ cataln [ hrvatski [ nederlands [ suomi [ francais [ deutsch [ magyar [ latvie ?u [ norsk bokm? l [ polski [ espanol > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] > ] • but since the user experience is nicer in a remote ssh session, it’s recommended to use that. however, with certain network environments it will just not be possible to go with a remote shell, and the ‘integrated ascii console’ will be the only option. • please notice that at the end of the installer boot up process all needed information is provided to proceed with a remote shell. • the command to execute locally is: user@workstation :~ $ ssh i n s t a l l e r @ 1 0 . 2 2 2 . 1 1 1 . 1 1 • a temporary random password for the installation got created and shared as well: 381

382

”c7bzrw76s4mjzmpf4euy” (use it without the leading and trailing double quotes.) * hence the remote session for the installer can be opened by: user@workstation :~ $ ssh i n s t a l l e r @ 1 0 . 2 2 2 . 1 1 1 . 1 1 the a u t h e n t i c i t y of host ecdsa key f i n g e r p r i n t are you sure you want to continue connecting ( yes /no /[ f i n g e r p r i n t ] ) ? yes warning : permanently added ’ 1 0 . 2 2 2 . 1 1 1 . 1 1 ’ to the i n s t a l l e r @ 1 0 . 2 2 2 . 1 1 1 . 1 1 ’ s password : c7bzrw76s4mjzmpf4euy i s sha256 :p+hbf3fj/pu6+0kaywuyii3lyuc09za9/a2elcdogde . ’ 1 0 . 2 2 2 . 1 1 1 . 1 1 ( 1 0 . 2 2 2 . 1 1 1 . 1 1 ) ’ can ’ t be e s t a b l i s h e d . l i s t of known hosts . (ecdsa) • one may swiftly see some login messages like the following ones: welcome to ubuntu focal fossa ( development branch ) s390x ) * documentation : * management : * support : https :// help . ubuntu . com https :// landscape . canonical . com https :// ubuntu . com/ advantage (gnu/linux 5.4.0−42− g e n e r i c system information as of wed jun 3 17:32:10 utc 2020 system load : usage of /home : unknown 0.0 memory usage : 2% swap usage : 0% 0 updates can be i n s t a l l e d immediately . these updates are s e c u r i t y updates . 0 of processes : users logged in : 0 146 the programs the exact d i s t r i b u t i o n terms i n d i v i d u a l f i l e s in / usr / share /doc /*/ copyright . included with the ubuntu system are f r e e software ; f o r each program are described in the ubuntu comes with absolutely no warranty, a p p l i c a b l e law . to the extent permitted by eventually the initial subiquity installer screen shows up: ==================================================================== willkommen ! bienvenue ! welcome ! ????? ??????????! welkom ! ==================================================================== use up, down and enter keys to s e l e c t your language . [ english [ asturianu [ cataln [ hrvatski [ nederlands [ suomi [ francais [ deutsch [ magyar [ latvie ?u 382 > ] > ] > ] > ] > ] > ] > ] > ] > ] > ]

383

[ norsk bokm? l [ polski [ espanol > ] > ] > ] • from here just proceed with the installation as usual … (i’m leaving some pretty standard screenshots here just to give an example for a basic installation …) ==================================================================== keyboard c o n f i g u r a t i o n ==================================================================== s e l e c t your keyboard layout below , or s e l e c t ” i d e n t i f y keyboard ” to please detect your layout automatically . layout : [ english (us) variant : [ english (us) v ] v ] [ i d e n t i f y keyboard ] [ done [ back ] ] ==================================================================== ==================================================================== online names zdev setup id ฀ dasd−eckd 0.0.1600 0.0.1601 0.0.1602 0.0.1603 0.0.1604 0.0.1605 0.0.1606 0.0.1607 0.0.1608 0.0.1609 0 . 0 . 1 6 0 a 0 . 0 . 1 6 0 b 0 . 0 . 1 6 0 c 0 . 0 . 1 6 0 d > > > > > > > > > > > > > > [ continue [ back ] ] 383 ^ v

384

==================================================================== ==================================================================== online names ==================================================================== ==================================================================== online names zdev setup id ฀ dasd−eckd 0.0.1600 ฀฀฀฀฀฀฀฀฀฀฀฀฀฀ 0.0.1601 ฀ 0.0.1602 ฀ 0.0.1603 ฀ 0.0.1604 ฀฀฀฀฀฀฀฀฀฀฀฀฀฀ 0.0.1605 0.0.1606 0.0.1607 0.0.1608 0.0.1609 0 . 0 . 1 6 0 a 0 . 0 . 1 6 0 b 0 . 0 . 1 6 0 c 0 . 0 . 1 6 0 d zdev setup id ฀ dasd−eckd 0.0.1600 0.0.1601 0.0.1602 0.0.1603 0.0.1604 0.0.1605 0.0.1606 0.0.1607 0.0.1608 0.0.1609 0 . 0 . 1 6 0 a 0 . 0 . 1 6 0 b 0 . 0 . 1 6 0 c 0 . 0 . 1 6 0 d >< ( c l o s e ) ฀ > enable ฀ > disable ฀ > > > > > > > > > > > [ continue [ back ] ] onli ne dasda > > > > > > > > > > > > > > ^ v ^ v * one may h i t bottom of ’end ’ key here , the the z devices l i s t and screen : [ continue [ back that w i l l automatically s c r o l l down to the ] ] ==================================================================== zdev setup 384

385

==================================================================== 0.0.f1de:0.0.f1df > ˆ 0.0.f1e0:0.0.f1e1 > 0.0.f1e2:0.0.f1e3 > 0.0.f1e4:0.0.f1e5 > 0.0.f1e6:0.0.f1e7 > 0.0.f1e8:0.0.f1e9 > 0.0.f1ea:0.0.f1eb > 0.0.f1ec:0.0.f1ed > 0.0.f1ee:0.0.f1ef > 0.0.f1f0:0.0.f1f1 > 0.0.f1f2:0.0.f1f3 > 0.0.f1f4:0.0.f1f5 > 0.0.f1f6:0.0.f1f7 > 0.0.f1f8:0.0.f1f9 > 0.0.f1fa:0.0.f1fb > 0.0.f1fc:0.0.f1fd > ฀ 0.0.f1fe:0.0.f1ff > v [ continue [ back ] ] ==================================================================== network connections ==================================================================== configure at least one interface this server can use to talk to other machines, and which preferably provides sufficient access for updates. name type notes [ encc000 eth - > ] 72:00:bb:00:aa:11 / unknown vendor / unknown model [ encc000.1234 vlan - > ] static 10.222.111.11/24 vlan 1234 on interface encc000 [ create bond > ] [ continue [ back ] ] • depending on the installer version you are using you may face a little bug here. in that case the button will be named ‘continue without network’, but the network is there. if you see that, just ignore and continue … (if you wait long enough the label will be refreshed an corrected.) ==================================================================== ==================================================================== system r e q u i r e s a proxy to connect to the internet , enter i t s configure proxy t h i s i f d e t a i l s here . proxy address : i f you need to use a http proxy to access enter blank . the proxy information here . otherwise , the outside world , leave t h i s 385

386

the proxy information should be given in the standard form of ” http : / / [ [ user ] [ : pass ]@] host [ : port ] / ” . [ done [ back ] ] ==================================================================== configure ubuntu archive mirror ==================================================================== i f you use an a l t e r n a t i v e mirror f o r ubuntu , i t s d e t a i l s here . that w i l l be used instead mirror address : http :// ports . ubuntu . com/ubuntu−ports you may provide an archive mirror of the d e f a u l t . enter [ done [ back ] ] ==================================================================== guided storage c o n f i g u r a t i o n ==================================================================== configure a guided storage layout , or create a custom one : (x) use an e n t i r e disk [ 0x1601 l o c a l disk 6.877g [ ] set up t h i s disk as an lvm group [ ] encrypt the lvm group with luks passphrase : confirm passphrase : 386 v ]

387

( ) custom storage layout [ done [ back ] ] ^ v ^ ==================================================================== ==================================================================== storage c o n f i g u r a t i o n file system summary ฀ mount point [ / size 6.875g new ext4 type device type ฀ new p a r t i t i o n of l o c a l disk > ] ฀฀฀ available devices ฀฀ no a v a i l a b l e devices ฀฀ [ create software raid (md) > ] [ create volume group (lvm) > ] ฀ ฀ used devices [ done [ reset [ back ] ] ] ==================================================================== ==================================================================== storage c o n f i g u r a t i o n file system summary ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ confirm d e s t r u c t i v e action ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ s e l e c t i n g continue below w i l l begin the i n s t a l l a t i o n process and ฀฀ r e s u l t in the l o s s of data on the di s ks s e l e c t e d to be formatted . ฀฀฀฀ you w i l l not be able to return to t h i s or a previous i n s t a l l a t i o n has s t a r t e d . ฀฀฀฀ screen once the ฀฀ are you sure you want to continue ? ฀฀฀฀ [ no [ continue ฀฀ ] ] ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ 387

388

[ reset [ back ] ] ==================================================================== p r o f i l e setup ==================================================================== enter can c o n f i g u r e ssh access on the next f o r the username and password you w i l l use to log in to the system . you s t i l l needed screen but a password i s sudo . your name : ed example your server ’ s name : s1lp11 the name i t uses when i t t a l k s to other computers . pick a username : ubuntu choose a password : ******** confirm your password : ******** [ done ] ==================================================================== ssh setup ==================================================================== the openssh s e r v e r package to enable secure remote you can choose to i n s t a l l access to your s e r v e r . [ ] i n s t a l l openssh s e r v e r import ssh i d e n t i t y : [ no you can import your ssh keys from github or launchpad . v ] import username : [x] allow password authentication over ssh [ done [ back ] ] • it’s an nice and convenient new feature to add the users ssh keys during the installation to the system, since that makes the system login password-less already on the initial login! 388

389

==================================================================== ==================================================================== the openssh s e r v e r package to enable secure remote ssh setup you can choose to i n s t a l l access to your s e r v e r . [x] i n s t a l l openssh s e r v e r import ssh i d e n t i t y : from launchpad v ] [ you can import your ssh keys from github or launchpad . launchpad username : user enter your launchpad username . [x] allow password authentication over ssh [ done [ back ] ] ==================================================================== ssh setup ==================================================================== you can choose to i n s t a l l access to your s e r v e r . ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ the openssh s e r v e r package to enable secure remote confirm ssh keys ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ keys with the f o l l o w i n g f i n g e r p r i n t s were fetched . do you want to ฀฀ use them? ฀฀฀฀ 2048 sha256 : jogscmiamcaoincinaäonnväineorvizeddwdr9hpbc2kiw user@w520 ฀฀ (rsa) ฀฀ 521 sha256 : t3jzxvb6k1gzidvoidhoidsaoicak0jhhgvbw01f7/ fz2c ฀฀ ed . example@acme . com (ecdsa) ฀฀฀฀ [ yes [ no ฀฀ ] ] ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ [ done [ back ] ] ==================================================================== featured server snaps ==================================================================== these are popular space, press enter to see more d e t a i l s of snaps in s e r v e r environments . s e l e c t or d e s e l e c t with the package , publisher and 389

390

v e r s i o n s a v a i l a b l e . that runtime ] kata−containers lightweight v i r t u a l machines s t r e s s−ng docker container eclipse mosquitto mqtt broker seamlessly plug into > > > > t e s t and benchmark a computer s > > > > > r e s i l i e n t key−value s t o r e by coreos high a v a i l a b i l i t y vrrp/bfd and load−balancing f o r linu > a t o o l sabnzbd get python based softlayer api tool . digitalocean command l i n e ] docker ] mosquitto ] etcd ] ] sabnzbd ] wormhole ] s l c l i ] doctl ] keepalived ] secure and s t a b l e devops . juju keeps complexit > from one computer to another , to load , simple , things s a f e l y s t r e s s juju t o o l [ [ [ [ [ [ [ [ [ [ [ [ done [ back ] ] ==================================================================== i n s t a l l complete ! ==================================================================== ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ s e r v i c e ฀ ฀฀ c o n f i g u r i n g raid (mdadm) i n s t a l l i n g kernel s e t t i n g up swap ฀฀ apply networking c o n f i g ฀฀ writing etc / f s t a b ฀฀ c o n f i g u r i n g multipath ฀฀ updating packages on target c o n f i g u r i n g p o l l i n a t e user−agent on target ฀฀ c o n f i g u r a t i o n ฀฀ system ฀฀ running ’ curtin hook ’ updating i n i t r a m f s f i n a l i z i n g i n s t a l l a t i o n ฀฀ ฀฀ curtin command hook ฀฀ executing l a t e commands ฀฀ system c o n f i g u r a t i o n ฀฀ c o n f i g u r i n g cloud−i n i t i n s t a l l i n g openssh−s e r v e r \ ฀ ฀฀฀ f i n a l ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ [ view f u l l log ] ==================================================================== ==================================================================== i n s t a l l a t i o n complete ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ finished i n s t a l l ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ apply networking c o n f i g ฀ writing etc / f s t a b ฀฀ c o n f i g u r i n g multipath ฀฀ updating packages on target system ฀฀ 390 ^฀ v ^฀

391

c o n f i g u r i n g p o l l i n a t e user−agent on target ฀฀ c o n f i g u r a t i o n ฀฀ running ’ curtin hook ’ updating i n i t r a m f s f i n a l i z i n g i n s t a l l a t i o n ฀฀ ฀฀ curtin command hook ฀฀ executing l a t e commands ฀฀ system c o n f i g u r a t i o n ฀฀ c o n f i g u r i n g cloud−i n i t i n s t a l l i n g openssh−s e r v e r ฀฀ r e s t o r i n g apt c o n f i g u r a t i o n ฀฀฀ ฀฀ f i n a l downloading and i n s t a l l i n g s e c u r i t y updates ฀ ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ [ view f u l l [ reboot log ] ] ==================================================================== i n s t a l l a t i o n complete ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ finished i n s t a l l ! ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ apply networking c o n f i g ฀ writing etc / f s t a b ฀฀ c o n f i g u r i n g multipath ฀฀ updating packages on target c o n f i g u r i n g p o l l i n a t e user−agent on target ฀฀ c o n f i g u r a t i o n ฀฀ system ฀฀ running ’ curtin hook ’ updating i n i t r a m f s f i n a l i z i n g i n s t a l l a t i o n ฀฀ ฀฀ curtin command hook ฀฀ executing l a t e commands ฀฀ system c o n f i g u r a t i o n ฀฀ c o n f i g u r i n g cloud−i n i t i n s t a l l i n g openssh−s e r v e r ฀฀ r e s t o r i n g apt c o n f i g u r a t i o n ฀฀฀ ฀฀ f i n a l downloading and i n s t a l l i n g s e c u r i t y updates ฀ ฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀฀ v ^฀ v connection to 10.222.111.11 closed . user@workstation :~ $ [ connection to 10.222.111.11 closed by remote host . rebooting . . . ] [ • now type ‘reset’ to clear the screen and to reset it to it’s defaults. user@workstation :~ $ r e s e t user@workstation :~ $ only for the use during installation: • before proceeding one needs to remove to old temporary host key of the target system, since it was user@workstation :~ $ ssh−keygen−f ”/home/ user /. ssh /known_hosts”−r ” s1lp11 ” 391

392

s1lp11 found : # host /home/ user /. ssh /known_hosts updated . original contents user@workstation :~ $ l i n e 159 retained as /home/ user /. ssh /known_hosts . old • and assuming the post-installation reboot is done, one can now login: user@workstation :~ $ ssh ubuntu@s1lp11 warning : permanently added the ecdsa host key f o r ’ 1 0 . 2 2 2 . 1 1 1 . 1 1 ’ welcome to ubuntu focal fossa ( development branch ) l i s t of known hosts . to the g e n e r i c s390x ) * documentation : * management : * support : https :// help . ubuntu . com https :// landscape . canonical . com https :// ubuntu . com/ advantage ip address (gnu/linux 5.4.0−42− system information as of wed 03 jun 2020 05:50:05 pm utc system load : 0.08 usage of /: 18.7% of 6.70gb memory usage : 2% swap usage : 0% processes : users logged in : 0 157 4 updates can be i n s t a l l e d immediately . 0 of these updates are s e c u r i t y updates . to see these a d d i t i o n a l updates run : apt l i s t −−upgradable the programs the exact d i s t r i b u t i o n terms i n d i v i d u a l f i l e s in / usr / share /doc /*/ copyright . included with the ubuntu system are f r e e software ; f o r each program are described in the ubuntu comes with absolutely no warranty, a p p l i c a b l e law . to the extent permitted by to run a command as administrator see ”man sudo_root ” f o r d e t a i l s . ( user ” root ”) , use ” sudo <command>”. ubuntu 1 user , load average : 0.08 , 0.11 , 0.05 ubuntu@s1lp11 :~ $ uptime 17:50:09 up 1 min , no lsb modules are a v a i l a b l e . d i s t r i b u t o r id : description : ubuntu focal fossa ( development branch ) release : codename : ubuntu@s1lp11 :~ $ l s b _ r e l e a s e−a ubuntu@s1lp11 :~ $ uname−a linux s1lp11 5.4.0−42− g e n e r i c #30−ubuntu smp mon jul 20 16:57:22 utc 2020 s390x s390x s390x gnu/linux 20.04 f o c a l ubuntu@s1lp11 :~ $ e x i t logout connection to s1lp11 closed . user@workstation :~ $ done ! 392