Tips for installing a machine on FI

Here you can read some tips on how to properly set up your FI machine. These tips will help to increase the speed, efficiency or safety of your machine. Please direct any suggestions for improvements or additions to this page to unix@fi.

General recommendations

The following section applies to both personal computers and servers. Most of the recommendations also apply to virtual machines.

Consider separating system and user data

When partitioning your disk, consider mounting /home on a separate partition. The advantage may be easier system reinstallation, the disadvantage less efficient use of disk capacity.

Consider the same login for the local account as the faculty account

If you intend to configure faculty printing using pure IPP, you must have the local login match the faculty account login. This is not required for the other options (IPP + Kerberos or Samba).

Use DHCP

Use DHCP to configure your network, not static configuration. The advantage is the ability to centrally manage and make bulk changes more easily. The DHCP configuration for the devices you manage can be set up in the Faculty Administration in Device Management (any additions/modifications to the list can be made by Unix administrators on request).

IPv6 address assignment

If you are interested in IPv6, we will be happy to assign you an IPv6 address (including loading it into DNS) and help you with configuration.

Set up your local distribution mirror

If your distribution mirror is available on FI - ftp.linux.cz, set this server as a mirror. See your distribution documentation for instructions.

If your distribution is not mirrored and you use it on multiple machines, you can send a mirroring request to ftp-admin@fi.

Set up automatic security updates

To increase the security of your machines, it is important to install security updates that fix identified vulnerabilities. This can be automated, but the method varies by distribution. For example, for Ubuntu, the AutomaticSecurityUpdates article describes the procedure (but here they are enabled after installation), and for Fedora, the AutoUpdates article describes the procedure.

Faculty ssh_known_hosts

If you will be logging into other faculty machines from your machine via SSH, you can download the public keys of the faculty machines from a central repository for added security and convenience (or use an auto-download script). Details can be found here: SSH Known Hosts.

Configuring the machine's mail system

Your machine may send mail in some cases (system updates, bugs in some daemons). If configured incorrectly, these mails can reach Unix administrators. Therefore, please check your configuration according to our instructions.

If necessary, you can also send mails directly from your machine (e.g. using the command mail, or sendmail).

Configuring the mail client

The necessary information can be found in the Mail section of our technical documentation. Most clients are able to detect this configuration automatically.

We will only specifically mention the mail sending configuration, where the correct configuration is the SMTP server relay.fi.muni.cz and port 465 (with SSL).

Time synchronization

To ensure accurate time on the machine, make sure you have the time synchronization daemon installed (ntpd, chronyd) and use the local NTP server time.fi.muni.cz. See the exact time on the FI network.

Persistent systemd log

If your system uses systemd, we recommend that you ensure that the logs are persisted (i.e., survive machine reboots). This can be done, for example, by setting Storage=persistent in the /etc/systemd/journald.conffile and then restarting the logging service: systemctl restart systemd-journald.

Backing up data

If you are interested, we can set up a data backup on your machine to us.

Regular wake-up via Wake-on-LAN

On request, it is possible to provide regular wake-up of the machine via Wake-On-LAN.

Server-specific recommendations

In this section you will find tips that are particularly applicable to servers.

Consult with us when purchasing servers

Thanks to our experience, we can help you with the specification - we will look at the important parameters and also verify that the server is suitable for the datacenter. So contact us before you make your purchase.

Auto power-on

In the BIOS, you can set the computer to power itself back on if the power is interrupted for any reason. For servers, this may be a desirable behavior. This item is usually named Restore on AC/Power Loss.

AHCI disk interface

In the BIOS, make sure that you have set the AHCI interface for SATA drives. AHCI is a standard that supports hot-swap drives, for example. In contrast, the older IDE standard requires a system reboot for the operating system to recognize a disk swap.

Test the hardware

Some later complications can be avoided by testing the hardware before commissioning.

You can find out how to test the memory here: Testing memory: memtester.

The procedure for thoroughly testing disks is as follows:

• Find out the name of the disk to be tested, get a list of connected disks fdisk -l
• Save the output smartctl -a /dev/sdX (replace X with something else)
• Run a long SMART test smartctl -t long /dev/sdX
• The test will run for some time. When finished, save the output of smartctl -a /dev/sdX again and compare with the state before the SMART test.
• If you have a magnetic disk, check for bad blocks. Caution. This is a destructive test that will overwrite your entire disk: badblocks -sw /dev/sdX
• Finally, check the output of dmesg and compare the current output of smartctl -a /dev/sdX with the initial output (for example, with the vimdiff tool ).

Configuring remote management

Most modern servers support some form of remote administration, which we strongly recommend using. See our page on options and configuration.

Hardware error detection

Modern processors allow you to notify the OS of hardware errors. We recommend installing the rasdaemon tool, which allows you to activate various ways of detecting problems and should also add more user-readable information to the system log in the event of a problem than that provided directly by the kernel. (Using mcelog rather than rasdaemon is not recommended, as it is probably no longer under development.)

Storing logs at syslog.fi.muni.cz

For security reasons, it is also convenient to send logs to a central server. Another advantage is that unix@fi can detect problems at the faculty network level. If you are interested, talk to the Unix administrators.

Disk monitoring via SMART

S.M.A.R.T. is a monitoring system for hard disks. The monitoring is handled by the smartd daemon , which is included in the smartmontools package. In the /etc/smartd.conf configuration, we recommend that you comment out DEVICESCAN and add one line for each disk, e.g.

# ata/sata disks
/dev/sda -S on -d ata -o on -a -m MAIL -M once -s (S/../.././02|L/../../7/04)
/dev/sdb -S on -d ata -o on -a -m MAIL -M once -s (S/../.././03|L/../../7/05)

Replace the string MAIL with a suitable mail address where information about possible problems (change of attributes indicating a failed disk or self-test failure) will be sent. This configuration includes, thanks to the -s parameter, that the /dev/sda disk will be checked by a short self-test every day at 2am and by a long self-test once every 7 days at 4am. While this workload is not significant, we recommend running the tests for each disk at different times. For more details, see the documentation at man smartd.conf. Also, be sure to activate the daemon to run at system startup.

Disable sudo for normal users

If other users will be logging into your server under their own accounts, you probably don't want to give them root access. In fact, some distributions allow the sudo command for regular users. This can be checked and possibly set up in /etc/sudoers with the command visudo.

Webserver and SSL settings

If you plan to run a secure website on the machine, it is advisable to pay attention to the correct and secure SSL/TLS configuration. You can read about setting up a secure connection on the Webserver and SSL Settings page.

Kernel panic response

For a more important machine, it is worth considering setting the sysctloption kernel.panic to ensure that if the kernel panics, the machine attempts to reboot itself and does not remain in this state. For example:

echo 'kernel.panic = 60' >/etc/sysctl.d/panic.conf
sysctl -p /etc/sysctl.d/panic.conf

Process monitoring

Sometimes it can be useful to know in retrospect what was happening on the machine at a given time. You can try our little script procesy.sh, which saves the output of the top command every 20 seconds and keeps this history in hourly files for the last 24 hours. See the installer.

Monitoring

For servers, we are able to provide service monitoring upon request using our Nagios instance. However, there is only the ability to receive alert emails, not access to the web interface.

Examples of services/things that can be monitored: ping availability, SSH availability, HTTP(S), TLS certificate validity, IPMI, disk fullness, excessive load, overall service status according to systemctl, correct time, etc.