translated by Google

Machine-translated page for increased accessibility for English questioners.

Tips for installing the machine on FI

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

General recommendations

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

Consider separating system and user data

When partitioning the disk, consider whether you want to mount /home on a separate partition. The advantage may be a simpler reinstallation of the system, a disadvantage of less efficient use of disk capacity.

Use your faculty login for your machine account

Print jobs must be sent from a user account whose login is the same as your faculty login. Therefore, it is strongly recommended to set the login you use on FI. See the documentation for details printing at FI .

Use DHCP

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

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 you don't mirror it and 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 machine safety, it is important to install security updates to correct vulnerabilities. This can be automated, but the method differs depending on the distribution. For example, in Ubuntu describes the procedure article AutomaticSecurityUpdates and an article for Fedora AutoUpdates .

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

Faculty ssh_known_hosts

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

Configuring the machine's mail system

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

You can then also send emails directly from your machine (for example, using the mail , eventually sendmail ).

Configure the mail client

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

Especially mention only the configuration of sending mails, 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, 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 on FI .


Server-specific recommendations

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

Auto power-on

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

AHCI disk interfaces

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

Test the hardware

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

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

The procedure for thoroughly testing disks is as follows:

  • Determine the name of the disk being tested to obtain a list of mounted 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 it to the status 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 initial output (for example vimdiff ).

IPMI and serial console configuration

Some IPMI servers are equipped with a special independent processor that is connected to the motherboard and main processor for hardware monitoring and control. This machine can be connected via a separate IP address, often on a dedicated network interface. Typical options include power control, machine health monitoring, BIOS configuration, and access to the operating system serial console. If your machine supports it (it can use different names: IPMI, iLO, iDRAC, BMC), we recommend using this option to configure IPMI.

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

In any case, make sure you don't leave 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

You must also configure the GRUB / kernel correctly for it to work. Usually you just need to add / modify these GRUB configuration parameters and then run update-grub . Here's 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 that BIOS and kernel console numbering may vary, ie BIOS consoles are usually numbered from 1, whereas kernels are numbered from ttyS0 .

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

If you need help configuring, you can contact the faculty Unix administrators.

MCE hardware error detection

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

Update: This is true for Intel processors. With AMD, the kernel module edac_mce_amd takes care of logging and mcelog may not work.

Logging on syslog.fi.muni.cz

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

Monitoring disks via SMART

SMART is a hard drive monitoring system. A demon is taking care of watching smartd that is in the package smartmontools . In configuration /etc/smartd.conf we recommend commenting DEVICESCAN and add one line per drive, 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 it with a suitable mailing address where information about possible problems (changing attributes indicating a failing disk or self-test failure) will be sent. This configuration includes a parameter -s that drive /dev/sda will be checked by short self-test every day at 2 am and long self-test every 7 days at 4 am. Although this load is not significant, we recommend running tests for each disk at different times. See command documentation for more details man smartd.conf . Also, be sure to activate the daemon to start at system startup.

Disable sudo for normal users

If other users log 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 regular users. This can be checked and possibly set in /etc/sudoers command visudo .

Webserver and SSL settings

If you plan to run a secure Web site on your machine, you should pay attention to the correct and secure SSL / TLS configuration. Learn how to set up a secure connection on the page Webserver and SSL settings .