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
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 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
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.
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 a script for automatic download). 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 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).
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 .
In this section, you will find tips that will find application especially for servers.
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
- 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/sdXand 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
dmesgand compare the current output
smartctl -a /dev/sdXwith the initial output (for example, the tool
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 (we recommend setting the speed as high as possible, typically 115.2k):
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 . See also
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.
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 methods of problem detection 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 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)
-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
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 reaction
This shouldn't 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
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 saves the output of the `top` command every 20 seconds and stores this history in hourly files for the last 24 hours. See