Tips for installing the machine on FI

Here are some tips on how to properly set up your computer on FI. These tips will help increase the speed, efficiency or safety of your machine. Please direct any suggestions for improving or expanding 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 a disk, consider mounting /home on a separate partition. The advantage may be a simpler reinstallation of the system, the disadvantage is less efficient use of disk capacity.

Consider the same local account login as the faculty account

If you intend to configure faculty press using pure IPP, it is necessary to have a local login identical to the login of the faculty account. This is not necessary for other options (IPP + Kerberos or Samba).

Use DHCP

Use DHCP, not static configuration, to configure the network. The advantage is the possibility of central administration and easier mass changes. The DHCP configuration for the devices you manage can be set up in the Faculty Administration in Device management (possible additions / modifications to the list will be made by Unix administrators upon request).

IPv6 address assignment

If you are interested in IPv6 We will be happy to assign you an IPv6 address (including its introduction into DNS) and help with configuration.

Set up a local distribution mirror

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

If we do not mirror your distribution and you use it on multiple machines, you can send a mirror request to ftp-admin @ fi .

Set up automatic security updates

To increase machine security, it is important to install security updates that correct identified vulnerabilities. This can be automated, but the method varies depending on the distribution. For example, in Ubuntu, the article describes the procedure AutomaticSecurityUpdates (however, they are enabled after installation) and an article for Fedora AutoUpdates .

Faculty ssh_known_hosts

If you log in to other faculty machines via SSH via your machine, you can download the faculty machines' public keys from the central repository for greater security and convenience (or use an automatic download script). Details can be found here: SSH Known Hosts .

Machine mail system configuration

In some cases, your machine may send e-mails (system updates, errors in some daemons). If configured incorrectly, these emails may reach Unix administrators. Therefore, please check your configuration according to our instructions .

If necessary, you can also send e-mails directly from your machine (for example, with the command mail , eventual sendmail ).

Mail client configuration

You will find the necessary information in the section Post in our technical documentation. Most clients are able to find out this configuration automatically.

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

Time synchronization

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

Persistent log systemd

If your system uses systemd, we recommend that you ensure that log logs are stored persistently (ie, survive a machine restart). You can achieve this, for example, by setting Storage=persistent in the file /etc/systemd/journald.conf and subsequent restart of the journaling service: systemctl restart systemd-journald .

Data Backup

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

Regular wake-on-LAN wake-up

On request, it is possible to ensure regular excitation of the machine via Wake-On-LAN .

Server-specific recommendations

In this section, you will find tips that will find application especially for servers.

Consult with us on the purchase of servers

Thanks to our experience, we can help you with the specification - we monitor important parameters and also verify that the server is suitable for the data center. Therefore, before entering the purchase us contact .

Auto power-on

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

AHCI disk interface

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

Test the hardware

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

How to test memory can be found here: Memory testing: memtester .

The procedure for thorough disk testing is as follows:

• Find out the name of the tested disk, you will get a list of connected disks fdisk -l
• Save your 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 again smartctl -a /dev/sdX and compare the state before the SMART test.
• If you have a magnetic disk, check for bad blocks. Attention! This is a destructive test that will overwrite the entire disk: badblocks -sw /dev/sdX
• Finally, check the output dmesg and compare the current output smartctl -a /dev/sdX with the initial output (for example, the tool vimdiff ).

Remote administration configuration

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

Hardware error detection

Modern processors make it possible to inform the OS about hardware errors. We recommend installing the tool rasdaemon , which allows you to activate various problem detection methods and should also add more user - readable information to the system log in the event of a problem than is directly from the kernel. (Usage mcelog instead of rasdaemon rather, we don't recommend it, as it's probably no longer under development.)

Saving logs on syslog.fi.muni.cz

For security reasons, it is advantageous to send logs to the central server as well. Another advantage is the possibility of detecting problems at the level of the faculty network by unix @ fi. If interested, arrange with Unix administrators.

Disk monitoring via SMART

SMART is a hard disk monitoring system. The demon takes care of the surveillance smartd which is in the package smartmontools . In configuration /etc/smartd.conf we recommend commenting 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)

String MAIL replace with a suitable e-mail address to which information about possible problems will be sent (change of attributes indicating a failed disk or self-test failure). This configuration includes due to the parameter -s that drive /dev/sda will be checked by a short self-test every day at 2 am and a long self-test once every 7 days at 4 am. Although this load is not significant, we recommend running tests for individual disks at different times. See the command documentation for more details man smartd.conf . Also, be sure to activate the daemon to start at system startup.

Disable sudo for regular users

If other users log in to your server under their accounts, you probably don't want to give them root access. This is because some distributions allow you to use the command sudo for regular users. This can be checked and, if necessary, set in /etc/sudoers command visudo .

Web server and SSL settings

If you plan to run secure websites on the machine, it is a good idea to pay attention to the correct and secure SSL / TLS configuration. You can read about secure connection settings on the page Web server and SSL settings .

Kernel panic response

This should not happen, but if you have an important machine, consider setting it up kernel.panic . 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 backwards what was happening on the machine at a given time. You can try our little script procesy.sh which stores the output of the command top every 20 seconds and stores this history in hourly files for the last 24 hours. See installer .

Monitoring

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

Examples of monitorable services / stuff: ping availability, SSH availability, HTTP (S), TLS certificate validity, IPMI, disk fullness, load, overall service status according to systemctl , the time is set correctly, and so on.