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 unixParsE42QH@fi.
The following section applies to both personal computers and servers. Most of the recommendations also apply to virtual machines.
Consider a network installation
You can use network boot via PXE to install any of the systems we provide without having to create installation media. See the PXE documentation for details, including a list of available systems.
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 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 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-admin122yzwH38@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.
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
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).
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.
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. Therefore, before you make a purchase, we will contact.
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
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
- 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/sdXagain 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
dmesgand compare the current output of
smartctl -a /dev/sdXwith the initial output (for example, with the
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.)
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, please contact Unix administrators.
S.M.A.R.T. is a monitoring system for hard disks. The monitoring is handled by the
smartd daemon , which is bundled with
smartmontools. 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
-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
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
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
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
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.