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 HgbZNltNs@ 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 ihK8LadTn@ 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 outputsmartctl -a /dev/sdX
with the initial output (for example, the toolvimdiff
).
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.