Tips when installing the machine on FI

Here are some tips on how to properly set your computer to FI. These tips will help increase the speed, efficiency, or safety of your machine. Any suggestions for improving or expanding this page should be directed to unix@fi.muni.cz .

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.

Use the faculty login for your account on the machine

Print jobs must be sent from a user account whose login is the same as your faculty login. Therefore, we strongly recommend setting up the login you use on FI. See the documentation for details press on FI .

Use DHCP

Use DHCP to configure the network, not a static configuration. The advantage is the possibility of central administration and easier mass changes. The DHCP configuration for the devices you manage can be set in the Faculty Administration in Device management (possible additions / modifications of the list will be performed by Unix administrators on request). If you are interested in configuring IPv6, please also contact your Unix administrator.

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 don't mirror it and you use it on multiple machines, you can try sending a mirror request to ftp-admin@fi.muni.cz .

Set up automatic security updates

To increase the security of machines, 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 and for Fedora, an article AutoUpdates .

Note: In Ubuntu, this is enabled after installation. And probably in other distributions as well.

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 emails directly from your machine (for example, with the command mail , eventual sendmail ).

Mail client configuration

You can find the necessary information in the section Post in our technical documentation. Most clients are able to detect 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 the time synchronization daemon (ntpd, chronyd) installed and use a local NTP server time.fi.muni.cz . More detailed instructions can be found here: Exact time in the FI network .

Server-specific recommendations

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

Auto power-on

You can set the BIOS to turn on the computer again if there is a power outage for any reason. For servers, this may be desirable behavior. This item is usually named Restore on AC/Power Loss .

AHCI disk interface

In the BIOS, make sure you have 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 for the operating system to detect a disk swap.

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 done, save the output again smartctl -a /dev/sdX and compare with 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 ).

IPMI and serial console configuration

Some servers are equipped with a special stand-alone processor according to the IPMI standard, which is connected to the motherboard and main processor and which allows monitoring and control of the hardware. This machine can be connected via a separate IP address, often on a dedicated network interface. Common options include power control, machine status monitoring, BIOS configuration, and access to the operating system's serial console. If your machine supports it (it can act under different names: IPMI, iLO, iDRAC, BMC), we recommend using this option and configuring IPMI.

Because this configuration varies from hardware and BIOS manufacturer to manufacturer, no general instructions can be given here. Typically, however, it is advisable to set up the use of a separate / dedicated Ethernet port, obtain the network configuration via DHCP (addresses are assigned for security reasons from a private range available only from agreed machines or parts of the FI network). Sometimes a machine with a single (shared) Ethernet port can support IPMI. In this case, a tagged VLAN can typically be set up for IPMI - Unix administrators will provide you with a connection to our infrastructure.

In any case, make sure that you have not left the IPMI exposed to the world with the default password.

The serial console is also configured separately, for example as follows:

Console redirection........Serial Port 1
Failsafe Baud Rate.........115200
Remote Terminal Type.......VT100/VT220
Redirection After Boot.....Enabled

In order for it to work, you also need to configure the GRUB / kernel correctly. Usually it is enough to add / modify these GRUB configuration parameters and then run it update-grub . An example of what a configuration might look like:

GRUB_CMDLINE_LINUX="<původní parametry> console=tty0 console=ttyS0,115200n,8"
GRUB_TERMINAL="serial console"
# následující parametr je zde zalomen, ale v konfiguraci
# musí být uveden v jednom řádku
GRUB_SERIAL_COMMAND="serial --unit=0 --speed=115200;
    terminal --timeout=5 serial console"

Note here that the numbering of consoles in the BIOS and in the kernel may be different, ie consoles in the BIOS are usually numbered from 1, while in the kernel they are numbered from ttyS0 .

You can then connect to the console with the command: ipmitool -I lanplus -H mgmt-stroje.fi.muni.cz -U user -P pass password sol activate

If you want help with configuration, you can contact the faculty Unix administrator.

MCE hardware error detection

Modern processors make it possible to inform the OS about hardware errors. In Linux, this data can be retrieved using a daemon mcelog which logs detected hardware errors to a file /var/log/mcelog or it can be configured to respond to errors.

Update: This applies to Intel processors. For AMD, the logging is taken care of by the kernel module edac_mce_amd and mcelog will probably not work.

Saving logs to 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 you are interested, talk to Unix administrators.

Disk monitoring via SMART

SMART is a monitoring system for hard disks. The demon is watching 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 disky
/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 disk /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. For more details, see the command documentation man smartd.conf . Also, be sure to activate the daemon to start at system startup.

Disable sudo for regular users

If other users are logging in to your server under their accounts, you probably don't want to give them root access. In some distributions it is allowed to use the command sudo for ordinary 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 .