Intel Atom Home Server and Centos 7 OS

  • Tutorial
In my article I want to present to the respected habitation community a practical guide for assembling, configuring, and commissioning an inexpensive and economical server based on Intel Atom and Centos 7. This work does not pretend to be a full-fledged and comprehensive tutorial and is aimed more at beginners than at professionals. If a person who has never seen Linux before can use this article to configure his first server, I will consider my task completed.

The first part of the article (small in volume) is devoted to the hardware component, and the second, main part is to a detailed description of the process of setting up the Centos 7 system on this equipment. Who cares, please, under cat.


Seventh Generation of Red Hat Systems (RHEL7, Centos 7 , Sceintific Linux 7, Fedora 20 ) is still quite new, and despite the very detailed documentation on the official Red Hat website , not everyone managed to get half-turned. Therefore, I decided to write a detailed how-to on the topic of setting up a general-purpose server using the latest Centos distribution.

What I wanted to get in terms of iron:
  • Energy efficiency
  • 19-inch rack-mount chassis with a height of not more than 1.5U and a depth of not more than 30 cm,
  • Front drive access
  • At least two gigabit network ports,
  • Completely passive cooling, that is, the absence of fans on both the processor and the power supply. This requirement is purely aesthetic, as the product will be used at home.

The software functionality on the first will be like this:
  • Router (IP router) and firewall (firewall),
  • X-server with a modern shell, I personally really like the third Gnome. It will be used both for administration and for the infrequent launch of applications that I deal with by the nature of my professional activity,
  • Exact Time Server (NTP),
  • DNS for the internal network with blocking banner networks (the idea was borrowed from here ),
  • High performance file server.

An SVN server with a browser shell (I ask you not to blame for outdated technologies), a batch repository (such as Nexus ), a release server (most likely Hudson , although I have not decided yet) will also get into the same place. Although I will not describe these last components.

A little bit about the hardware component


I found the case quickly enough: Only 1U in height and 25 cm in depth. From here, restrictions on the Mini-ITX motherboard and the 1U FlexATX power supply appeared immediately.

With the motherboard, everything was not so simple. The Mini-ITX format, two gigabit ports and passive cooling turned out to be serious limitations. At first, I considered the option from GIGABYTE and almost came to terms with 10 watts of the dissipated processor power and, judging by the forums, possible problems with Linux. However, at the very last moment, I literally accidentally stumbled upon a board from SUPERMICROwith an Intel Atom processor and after a couple of days I held it in my hands. The main factor besides low power consumption was the fact that the manufacturer announced full and unconditional support for this Red Hat board, although not the latest version. Looking ahead, I’ll say that it was justified - there were no problems setting up Linux on the iron side, from the word at all.

The board has one memory slot, maximum 8GB DDR3-1333 ECC SO-DIMM. The list of certified memory on the manufacturer’s website is rather scarce, I had to go on the other side. I began to look for which of the memory manufacturers supports this board. Found. The choice fell on Crucial , as on their website there is not only the ability to search by the name of the motherboard, but also the ability to order directly. I ordered them250 GB SSD , with almost the same read / write speed of about 500 MB / s.

The last detail is the power supply. Unfortunately, PSU with passive cooling is still exotic, I found only one option, I ordered it. It turned out to be FSP150-50TNF. The manufacturer’s website could not be found, but you can buy it in a huge number of online stores.

There were no problems with the assembly. Stick, as they say, do not solder. There are two fans in the case, I did not connect them. Total, we got such a design:


The total cost of all components with delivery turned out to be 745 euros. Looking ahead, I’ll say that the power consumption of the assembled and fully configured server is about 14-15 watts.

A lot about the software component


The software configuration of this server will be discussed further. I chose the Linux distribution based on mercantile considerations. In the company where I work (offtopic: I am a mathematician-engineer, developing application software in the field of air traffic control systems), we use Red Hat or Centos both for development and as a platform for installation to clients.

Step one: prepare the installation flash drive.

An ISO distribution optimized for network installation (CentOS-7-x86_64-NetInstall-1503.iso) can be taken from here . Then from it you need to make a bootable USB flash drive.

My first mistake was to use the Unetbootin utility for Windows for this purpose. This utility recorded the USB flash drive, it was even recognized as bootable, but the installer core categorically refused to boot from it, constantly crashing with some kind of left-handed messages like “kernel panic”. A study of the forums has shown that I'm not the only one who is so crooked. Therefore, as a result, I prepared a flash drive from under Linux:
  1. We insert an empty USB flash drive of a volume larger than the ISO file. The type of file system on it is not important. most importantly, it should not be divided into volumes.
  2. We look at how it is mounted and which device corresponds to:
    # cat / proc / mounts
  3. unmount this device, otherwise it will not be available in the required mode:
    # umount / dev / NNN
  4. go to root mode and go to the directory where the ISO file is saved.
  5. We use the standard utility for block copying data :
    # dd bs = 4M if = CentOS-7-x86_64-NetInstall-1503.iso of = / dev / NNN

Everything, the flash drive is ready. For the next step, you need any monitor with the ability to connect to a VGA connector, since the board does not have either DVI or HDMI, only the good old VGA. There are only two external USB3 ports on the board, there are no internal ports. One port is needed for a bootable USB flash drive; in the second, through a USB hub, plug in the keyboard and mouse.

Step two: preparing the product for loading.

We connect a monitor, keyboard, mouse, network cable with Internet access, power cable. The device turns on itself. The green LED flashes on the board, as I understand it, it is associated with clocking. We enter the BIOS. The goal and end result is to allow booting from USB. I left all other settings unchanged.

Step Three: Network Installation

We insert the USB flash drive into a free slot, reboot. In my opinion, the graphical installer is intuitive, so for now I’ll manage without pictures. Already in the process of writing the article, I found a colorful installation guide , everything is photographed in great detail there. I will only describe what needs to be done at this stage in order to save time and nerves later:
  • Set all the parameters of the network card to which the cable is connected so that Internet access works: ip, gateway, dns, and activate the adapter.
  • In the time settings window, select the correct time zone and set the time. I personally always use time synchronization over the network.
  • Partition a disk. Usually I use the default layout scheme. In it, the home folder is located in its own section. Since I have one user (myself), not counting the root, I do not really need home. Therefore, I rename the home volume to work in this scheme, so that in the future the system creates user home directories in the root / home partition.
  • Set the server address from where packets will be pulled during the installation process.
  • Choose the components that you definitely need. In my case, this is a file server, development tools, hardware monitoring utilities, http server. Everything else can be added later.

After that, click on "Start Installation". While downloading and installing packages, it is possible to set the root password, as well as add users to the system. After the installation is complete, we reboot and check access via ssh from another computer. Since it is configured by default, then everything should work. It's time to unhook the monitor and keyboard and install the server in a permanent location in a rack, connect to the network and start. Further configuration will be done remotely through the console.

Fourth step: setting up the basic functionality.

So, we are logging in from another computer via SSH. If another computer is running Windows, then you can take the good old putty as an ssh client. Naturally, all further operations are done from under the root. Banality, but I note that the transition to root mode is carried out by the command:
[user @ supermicro] # su

1. The first thing to do on a freshly installed system is to update it. The system already has a yum package manager. It is accessible from the console (yum command). Batch repositories are already configured by default, so the command is enough to update the entire system:
[root @ supermicro] # yum update

2. Ever since the days of dos, I can’t live without a file manager, preferably in blue tones, so I immediately set myself the Linux analogue of the Norton commander. Although this is a matter of personal preference. About 30 additional packages are pulled, mainly perl:
[root @ supermicro] # yum install mc

3. Then I need monitoring tools for the sensors located on the motherboard. One additional package is put:
[root @ supermicro] # yum install lm_sensors

4. Sensors need to be initialized:
[root @ supermicro] # sensors-detect

5. You can view the sensor values ​​as follows:
[root @ supermicro] # sensors

Issuing sensors command
acpitz-virtual-0
Adapter: Virtual device
temp1: + 26.8 ° C (crit = + 127.0 ° C)
temp2: + 26.8 ° C (crit = + 175.0 ° C)
coretemp-isa-0000
Adapter: ISA adapter
Core 0: + 48.0 ° C (crit = + 100.0 ° C)
Core 1: + 49.0 ° C (crit = + 100.0 ° C)
w83795adg-i2c-3-2f
Adapter: SMBus iSMT adapter at fe482000
in0: +0.99 V (min = +0.54 V, max = +1.49 V)
in3: +1.28 V (min = +1.13 V, max = +1.38 V)
in4: +1.83 V (min = +1.63 V, max = +2.00 V)
in5: +1.28 V (min = +1.13 V, max = +1.38 V)
in6: +1.56 V (min = +1.20 V, max = +1.65 V)
in11: +1.07 V (min = +0.94 V, max = +1.17 V)
+ 3.3V: +3.26 V (min = +2.96 V, max = +3.63 V)
3VSB: +3.26 V (min = +2.96 V, max = +3.63 V)
Vbat: +3.13 V (min = +2.70 V, max = +3.63 V)
fan1: 0 RPM (min = 709 RPM) ALARM
fan2: 0 RPM (min = 709 RPM) ALARM
fan3: 0 RPM (min = 709 RPM) ALARM
temp1: + 82.2 ° C (high = + 105.0 ° C, hyst = + 100.0 ° C)
                       (crit = + 105.0 ° C, hyst = + 100.0 ° C) sensor = thermistor
temp2: + 82.5 ° C (high = + 105.0 ° C, hyst = + 100.0 ° C)
                       (crit = + 105.0 ° C, hyst = + 100.0 ° C) sensor = thermistor
temp3: + 80.8 ° C (high = + 85.0 ° C, hyst = + 105.0 ° C)
                       (crit = + 105.0 ° C, hyst = + 100.0 ° C) sensor = thermistor
temp5: + 33.8 ° C (high = + 85.0 ° C, hyst = + 80.0 ° C)
                       (crit = + 100.0 ° C, hyst = + 95.0 ° C) sensor = thermistor
temp6: + 37.5 ° C (high = + 85.0 ° C, hyst = + 80.0 ° C)
                       (crit = + 100.0 ° C, hyst = + 95.0 ° C) sensor = thermistor
intrusion0: OK


Let me remind you that the fans are turned off. The temperature at three points is somewhat high, but still far from critical.

Step Five: Remote Desktop

I can’t say anything specific about these or those solutions, I chose VNC and GNOME simply because I already used them before. The following components are installed on the server:
[root @ supermicro] # yum install vnc-server 
[root @ supermicro] # yum groupinstall "GNOME Desktop" 
[root @ supermicro] # yum install tigervnc-server

About 650 additional packages are pulled (download volume about 660 MB, installation volume about 2 GB).

We will configure the firewall later, but since it is already out of the box and is active, you need to add the newly installed service to its rules.
 
[root @ supermicro] # firewall-cmd --permanent --zone = public --add-service vnc-server
[root @ supermicro] # firewall-cmd --reload

Since I need a remote desktop occasionally, I did not set it up to automatically boot. If you need it, you must first log in to the server via ssh (not as root, but as the user on behalf of whom the session will be launched), and start it manually with the command:
[user @ supermicro] # vnc-server

At the first start, it will be offered to set the session password and the terminal number will be issued under which the session is available. For all subsequent launches, the session number will be displayed again:
[family @ supermicro] # vnc-server
New 'supermicro: 1 (family)' desktop is supermicro: 1
Starting applications specified in /home/family/.vnc/xstartup
Log file is /home/family/.vnc/supermicro:1.log

This number and password will be required on the client to connect to the desktop using any VNC client.

Many things can be configured through the remote desktop in the graphical interface, and not in the console. For example, there are gpk-application applications for installing / uninstalling and gpk-update-view for updating packages:


To facilitate customizing the desktop to your habits, you can additionally install the configuration utilities and a module that allows you to install shell extensions from the browser (only from Firefox) GNOME:
[root @ supermicro] # yum install dconf-editor gnome-shell-browser-plugin alacarte gnome-tweak-tool

To install shell extensions, you can visit the official repository using Firefox.

Step Six: Configure Network Interfaces and Routing.

One of the network cards is already configured at the time of system installation. This board (interface) with the address 192.168.178.2 will be used to access the world, an external Internet connection will be directly connected to it. The second board with the address 192.168.1.1 will be the gateway for the internal network, the cable from it will go to the network hub of the local network. It is this interface that needs to be configured now.

The network is served by the NetworkManager module, which is configured both from the console and using the graphical configurator. Since the module is already running, the command for checking its status is expected to produce the following:
[root @ supermicro] # systemctl status NetworkManager
NetworkManager.service - Network Manager
   Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service; enabled)
   Active: active (running) since Wed 2015-09-30 20:33:01 CEST; 2h 2min ago

We’ll use the graphical configurator, for which we’ll run from the console:
[root @ supermicro] # gnome-control-center



Next, select the network icon:


Set the necessary parameters for both network adapters. It is important that the “Connect automatically” flag must be enabled for each adapter, otherwise after rebooting the network interface will remain off:


For the new parameters to take effect, you must restart the network service using the command:
[root @ supermicro] # service network restart
Restarting network (via systemctl): [OK]

The adapter configuration is stored in the text files / etc / sysconfig / network-scripts / ifcfg-enp5s0f0 and / etc / sysconfig / network-scripts / ifcfg-enp5s0f1, which can be edited manually. Unfortunately, this will have to be done later, since from the graphical interface there is no way to bind the adapter to the desired area of ​​the firewall, but more on that below. At this stage, the status of network interfaces is as follows:
[root @ supermicro] # ifconfig

Issuing ifconfig command
enp5s0f0: flags = 4163  mtu 1500
        inet 192.168.1.1 netmask 255.255.255.0 broadcast 192.168.1.255
        inet6 fe80 :: ec4: 7aff: fe52: ea84 prefixlen 64 scopeid 0x20
        ether 0c: c4: 7a: 52: ea: 84 txqueuelen 1000 (Ethernet)
        RX packets 154172 bytes 27984732 (26.6 MiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 211719 bytes 187981730 (179.2 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        device memory 0xfe120000-fe13ffff  
enp5s0f1: flags = 4163  mtu 1500
        inet 192.168.178.2 netmask 255.255.255.0 broadcast 192.168.178.255
        inet6 fe80 :: ec4: 7aff: fe52: ea85 prefixlen 64 scopeid 0x20
        ether 0c: c4: 7a: 52: ea: 85 txqueuelen 1000 (Ethernet)
        RX packets 97054 bytes 130894810 (124.8 MiB)
        RX errors 0 dropped 0 overruns 0 frame 0
        TX packets 72249 bytes 6523040 (6.2 MiB)
        TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
        device memory 0xfe100000-fe11ffff 


Linux allows you to enable or disable packet forwarding between interfaces. It can be disabled on workstations and application servers. Our server acts as a router and a firewall. Therefore, routing should obviously be allowed.

Routing is controlled by the net.ipv4.ip_forward parameter from the /etc/sysctl.conf file. To enable it, the parameter must be set to unity:
[root @ supermicro] # cat /etc/sysctl.conf
net.ipv4.ip_forward = 1

Now you need to update the configuration for the routing settings to take effect:
[root @ supermicro] # sysctl -p
net.ipv4.ip_forward = 1

To check if IP routing is enabled, you can run the following command, which should return a unit:
[root @ supermicro] # cat / proc / sys / net / ipv4 / ip_forward
1


Seventh step: Configure the firewall.

A firewall is needed to control and filter network packets passing through the server. The goal is to deny access to all services outside the network. The firewall is served by the Firewalld module, which is configured both from the console (command # firewall-cmd) and using the graphical interface (command # firewall-config). The FirewallD service uses the iptables tool (iptables tool) to interact with the kernel packet filter.

You can find detailed documentation for this module on the official Red Hat website . Also on the network there are detailed guides for setting it up, for example this .

Checking the status of the service quite expectedly reports that the service is running:
[root @ supermicro] # firewall-cmd --state
running

FirewallD uses network zones to determine the trust level of a network connection, a connection can be part of only one zone, but one zone can define several network connections.
What zones are there by default?
[root @ supermicro] # firewall-cmd --get-zones
block dmz drop external home internal public trusted work

A zone is active if at least one network card is attached to it. Filtering rules are set specifically for active zones. What zones do we have active initially?
[root @ supermicro] # firewall-cmd --get-active-zones
public
  interfaces: enp5s0f0 enp5s0f1

Both network interfaces are tied to one board, which means that you cannot set your own filtering rules for each interface. The situation needs to be radically changed.

The enp5s0f0 interface with the address 192.168.1.1 will be accessible from the internal network, so all services installed on the server should be accessible via this interface. Access via the external interface enp5s0f1 should be minimized as much as possible. For the internal network, we choose the internal zone by the willful decision You need to throw the enp5s0f0 interface into it.

The nuance, however: there are two filter tables - currently active and constant. When the server reboots, the active table is restored from a permanent one. Therefore, you must either work with a constant table (the --permanent parameter in commands), or then remember to copy the active table to a constant table when all changes are made. Changes to the active table are applied instantly: saving or applying changes is not required. Changes in the permanent table will take effect only after the table is reloaded (firewall-cmd --reload command), service (systemctl restart firewalld command) or server.

I will immediately edit the persistent table. I remove the interface from the public zone:
[root @ supermicro] # firewall-cmd --permanent --zone = public --remove-interface = enp5s0f0
success

Add it to the internal zone:
[root @ supermicro] # firewall-cmd --permanent --zone = internal --add-interface = enp5s0f0
success

Check the result:
[root @ supermicro] # firewall-cmd --get-active-zones
internal
  interfaces: enp5s0f0
public
  interfaces: enp5s0f1

Here, an ambush awaits us, namely, the well-known and still not closed bug in Centos 7. The bottom line: the interface zone when rebooting is taken from the settings of the interface itself (file / etc / sysconfig / network-scripts / ifcfg-enp5s0f0), and there she has not changed. You have to do this manually: edit the file / etc / sysconfig / network-scripts / ifcfg-enp5s0f0 and add the line ZONE = internal there:
[root @ supermicro] # cat / etc / sysconfig / network-scripts / ifcfg-enp5s0f0

Cat command output
TYPE = Ethernet
DEVICE = enp5s0f0
NAME = ifInternal
BOOTPROTO = none
NETWORK = 192.168.1.0
ONBOOT = yes
DEFROUTE = yes
IPV4_FAILURE_FATAL = no
IPV6INIT = no
IPV6_AUTOCONF = yes
IPV6_DEFROUTE = yes
IPV6_FAILURE_FATAL = no
UUID = 61c21319-6b66-4e4e-adef-4fae7fc3f12b
IPV6_PEERDNS = yes
IPV6_PEERROUTES = yes
IPADDR = 192.168.1.1
PREFIX = 24
ZONE = internal


After that, it is better to restart the server for verification purposes. After rebooting, the binding of interfaces to zones should not be lost:
[root @ supermicro] # firewall-cmd --get-active-zones
internal
  interfaces: enp5s0f0
public
  interfaces: enp5s0f1

Services are added to the zone with a command of the type
[root @ supermicro] # firewall-cmd --permanent --zone = internal --add-service vnc-server

I prefer to do this from the graphical shell:


Unfortunately, that's not all. There is a nuance associated with masking an IP address (IP masquerading). In packets originating from the internal network, the sender address must be replaced by the address of the server itself. If this function is turned off, the computer from the internal network will never wait for an answer from the outside, since its address is unknown there.

I don’t know what this is connected with, but changing the mask flag for the enp5s0f1 adapter both from the graphical shell and through firewall-cmd did not give any effect. A working solution was found in this article . Its essence: to set an additional direct POSTROUTING rule in the iptables table, on which FirewallD is an add-on:
[root @ supermicro] # firewall-cmd --permanent --direct --passthrough ipv4 -t nat -I POSTROUTING -o enp5s0f1 -j MASQUERADE -s 192.168.1.0/24

Reload the table and check the changes:
[root @ supermicro] # firewall-cmd --reload
[root @ supermicro] # firewall-cmd --direct --get-all-passthroughs
ipv4 -t nat -I POSTROUTING -o enp5s0f1 -j MASQUERADE -s 192.168.1.0/24

On this, the firewall is configured. You can check the current firewall configuration with this useful command:
[root @ supermicro family] # firewall-cmd --list-all-zones

A fragment of the firewall-cmd command
internal (active)
  interfaces: enp5s0f0
  sources: 
  services: dns http https ntp samba samba-client ssh vnc-server
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: 
  rich rules: 
public (default, active)
  interfaces: enp5s0f1
  sources: 
  services: 
  ports: 
  masquerade: yes
  forward-ports: 
  icmp-blocks: 
  rich rules: 



Step Eight: Exact Time Server (NTP).

To synchronize time over the network (both the time of the server itself and the time on client machines with the server), I will configure the NTP server. In Centos 7, instead of the good old ntpd, a new service is preinstalled and activated - chrony.

Since the option of synchronizing time over the network was selected during the installation of the system, the service is already there and is running:
[root @ supermicro] # systemctl status chronyd

Issuing the systemctl command if the service is operating normally
chronyd.service - NTP client / server
   Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled)
   Active: active (running) since Fri 2015-10-02 23:01:57 CEST; 12min ago
  Process: 2949 ExecStartPost = / usr / libexec / chrony-helper add-dhclient-servers (code = exited, status = 0 / SUCCESS)
  Process: 2946 ExecStart=/usr/sbin/chronyd -u chrony $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 2948 (chronyd)
   CGroup: /system.slice/chronyd.service
           └─2948 /usr/sbin/chronyd -u chrony
Oct 02 23:01:57 supermicro chronyd[2948]: chronyd version 1.29.1 starting
Oct 02 23:01:57 supermicro chronyd[2948]: Linux kernel major=3 minor=10 patch=0
Oct 02 23:01:57 supermicro chronyd[2948]: hz=100 shift_hz=7 freq_scale=1.00000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000 shift_pll=2
Oct 02 23:01:57 supermicro chronyd[2948]: Frequency -6.239 +/- 1.721 ppm read from /var/lib/chrony/drift
Oct 02 23:01:57 supermicro systemd[1]: Started NTP client/server.
Oct 02 23:02:02 supermicro chronyd[2948]: Selected source 129.70.132.32


If the status command indicates that the service is either not installed or not running, then the procedure is standard :
[root @ supermicro] # yum install chrony
[root @ supermicro] # systemctl start chronyd
[root @ supermicro] # systemctl enable chronyd
[root @ supermicro] # systemctl is-enabled chronyd
enabled

Automatic time synchronization with a remote server is allowed by the command:
[root @ supermicro] # timedatectl set-ntp yes

To access the service from the internal network, you need to enable the service in the firewall:
[root @ supermicro] # firewall-cmd --permanent --zone = internal --add-service ntp
[root @ supermicro] # firewall-cmd --reload

Then you can tweak the service settings, which are stored in the /etc/chrony.conf file. In this file, it was enough for me to make only two adjustments:
# Add custom pool servers instead those defined in the installation:
server 0.de.pool.ntp.org iburst
server 1.de.pool.ntp.org iburst
server 2.de.pool.ntp.org iburst
server 3.de.pool.ntp.org iburst
# Allow NTP client access from local network.
allow 192.168.1.0/24

Restart the service:
[root @ supermicro] # systemctl restart chronyd

Check the status and synchronization:
[root @ supermicro] # chronyc sources

Issuing chronyc sources command
210 Number of sources = 4
MS Name / IP address Stratum Poll Reach LastRx Last sample
^ + mizar.pmsf.net 2 8 377 479 + 688us [+ 729us] +/- 54ms
^ * stratum2-3.NTP.TechFak.Un 2 8 377 217 -1261us [-1241us] +/- 26ms
^ + dns2.teleport-iabg.de 2 9 377 87 + 1102us [+ 1102us] +/- 86ms
^ + server2.as2.ch 2 8 377 218 + 631us [+ 651us] +/- 56ms


[root @ supermicro] # chronyc tracking

Chronyc tracking command output
Reference ID: 129.70.132.32 (stratum2-3.NTP.TechFak.Uni-Bielefeld.DE)
Stratum: 3
Ref time (UTC): Fri Oct 2 21:29:03 2015
System time: 0.000020543 seconds slow of NTP time
Last offset: 0.000020316 seconds
RMS offset: 0.001376700 seconds
Frequency: 5.580 ppm slow
Residual freq: 0.011 ppm
Skew: 0.203 ppm
Root delay: 0.045198 seconds
Root dispersion: 0.003463 seconds
Update interval: 261.1 seconds
Leap status: Normal


After replacing the NTP server address on client devices (Windows, Linux, Zyxel), all of them together picked up time from the server.

The penultimate step: DNS.

The only reason I decided to raise the DNS service on the server is to block banner networks, statistics sites, and all kinds of telemetry servers (for example, Microsoft) on all devices on the local network. The idea is not mine, taken from here . Searching the web, I found several sites that regularly publish blacklisted domains in the format of hosts files.

For example, this and this . A feature of the second list is that Microsoft telemetry server is already there.

I chose dnsmasq as the DNS service simply because I found a simple and understandable instructionto install and configure it. Dnsmasq implements both DNS and DHCP server at the same time, but the second one is unnecessary for me so far, so I will configure only DNS.

Start standard:
[root @ supermicro] # yum install dnsmasq dnsmasq-utils
[root @ supermicro] # systemctl start dnsmasq
[root @ supermicro] # systemctl enable dnsmasq
[root @ supermicro] # firewall-cmd --permanent --zone = internal --add-service = dns
[root @ supermicro] # firewall-cmd --reload

Further, in the configuration file of the internal network interface (in my case / etc / sysconfig / network-scripts / ifcfg-enp5s0f0), you need to indicate that the DNS server is the local host, i.e. add line:
DNS1 = 127.0.0.1

[root @ supermicro] # cat / etc / sysconfig / network-scripts / ifcfg-enp5s0f0

Cat command output
TYPE = Ethernet
DEVICE = enp5s0f0
NAME = ifInternal
BOOTPROTO = none
NETWORK = 192.168.1.0
ONBOOT = yes
DEFROUTE = yes
IPV4_FAILURE_FATAL = no
IPV6INIT = no
IPV6_AUTOCONF = yes
IPV6_DEFROUTE = yes
IPV6_FAILURE_FATAL = no
UUID = 61c21319-6b66-4e4e-adef-4fae7fc3f12b
IPV6_PEERDNS = yes
IPV6_PEERROUTES = yes
IPADDR = 192.168.1.1
PREFIX = 24
ZONE = internal
DNS1 = 127.0.0.1


After turning on or restarting the server, the NetworkManager service, based on the settings from this file, updates the /etc/resolv.conf file, which contains the addresses of both the external DNS server (in my case it is DSL / FritzBox) and ours:
[root @ supermicro] # cat /etc/resolv.conf 
# Generated by NetworkManager
nameserver 192.168.178.1
nameserver 127.0.0.1

Having downloaded the sources of the installed version from here , you can pull out an example configuration file from there, correct it and save it as /etc/dnsmasq.d/main.conf. I configured it in a minimal way:
Fragment (active parameters) of the /etc/dnsmasq.d/main.conf file
bogus-priv
server = / kama / 192.168.1.1
local = / kama /
interface = enp5s0f0
no-dhcp-interface = enp5s0f0
addn-hosts = / etc / black_list_hosts.txt
expand-hosts
domain = kama


The main thing here is the addn-hosts = / etc / black_list_hosts.txt parameter, where black_list_hosts.txt is the blacklist of domains. In my case, I just downloaded it from here for now . As a result, there were practically no banner ads on all devices on the local network (both desktop and mobile). In the future, I am going to automate the process of updating this list.

Last step: file server (Samba).

This is the last component that I will write a little about. Samba - file server for sharing files from all devices on the local network. It is installed simply:
yum install samba * -y

I will share only one folder: / work / nas. To do this, edit the /etc/samba/smb.conf file and specify the access settings for this folder there:
Fragment (active parameters) of the /etc/samba/smb.conf file
workgroup = KAMA
server string = Samba Server Version% v
netbios name = SUPERMICRO
interfaces = lo enp5s0f0
hosts allow = 127. 192.168.1.
max protocol = SMB2
log file = /var/log/samba/log.%m
max log size = 50
[nas]
comment = NAS Working directory
path = / work / nas
public = no
read only = yes
printable = no
write list = family
create mode = 660
directory mode = 770


By default, the folder is configured as read-only, but a user named family has write access. We start the service and check its settings:
[root @ supermicro] # systemctl start smb
[root @ supermicro] # systemctl enable smb
[root@supermicro]# firewall-cmd --permanent --zone=internal --add-service=samba
[root@supermicro]# firewall-cmd --reload
[root@supermicro]# testparm

Выдача команды testparm
Load smb config files from /etc/samba/smb.conf
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[nas]"
Loaded services file OK.
Server role: ROLE_STANDALONE
[global]
	workgroup = KAMA
	server string = Samba Server Version %v
	interfaces = lo, enp5s0f0
	log file = /var/log/samba/log.%m
	max log size = 50
	server max protocol = SMB2
	idmap config * : backend = tdb
	hosts allow = 127., 192.168.1.
	cups options = raw
[nas]
	comment = NAS Working directory
	path = /work/nas
	write list = family
	create mask = 0660
	directory mask = 0770


Next, you need to create a folder and provide access to it. Access will be granted to the fileshare user group:
[root @ supermicro] # cd / work /
[root @ supermicro] # mkdir nas
[root @ supermicro] # groupadd -g 10000 fileshare
[root @ supermicro] # chgrp fileshare / work / nas
[root @ supermicro] # chmod g + w / work / nas

Further there is a feature. The fact is that Centos has an additional security subsystem that regulates access to resources not only for users, but also for modules (components) of the system. It is called SELinux. In order for the Samba server itself to gain access to the / work / nas folder, it must have an additional samba_share_t attribute set in addition to the usual read-write rights:
[root @ supermicro] # ls -Z
drwxrwxr-x. family fileshare unconfined_u: object_r: samba_share_t: s0 nas
drwxr-xr-x. apache apache unconfined_u: object_r: httpd_sys_rw_content_t: s0 svn
drwxr-xr-x. apache apache unconfined_u: object_r: httpd_sys_rw_content_t: s0 www

There is a standard chcon command for flag manipulation. The samba_share_t flag with its help is set like this:
[root @ supermicro] # chcon -t samba_share_t / work / nas

In order for Windows machines on the local network to see our server and shared folder, you must also enable the NetBIOS service. It does not require additional configuration, you only need to run it:
[root @ supermicro] # systemctl start nmb
[root @ supermicro] # systemctl enable nmb

Often it is necessary to mount an external drive (disk or flash drive) formatted for NTFS to this folder. There is no NTFS driver on the system by default. Also, it is not in standard repositories. If there is a need to connect NTFS drives to the system, then you need to install the 3rd-party EPEL repository from the Fedora project and install the driver from there:
[root @ supermicro] # yum install epel-release
[root @ supermicro] # yum install ntfs-3g

After that, external drives NTFS drives will be automatically recognized by the system.

The final chord is to create a user who will have write permissions to the shared folder. As you can see from the configuration above, this is user family:
[root @ supermicro] # usermod -a -G fileshare family
[root @ supermicro] # id family
uid = 1000 (family) gid = 1000 (family) groups = 1000 (family), 10000 (fileshare)
[root @ supermicro] # smbpasswd -a family
New SMB password:
Retype new SMB password:
Added user family.


This, perhaps, will end. In general, it turned out an economical and multi-functional machine with great potential. As I already noted, the power consumption is in the range of 14-15 watts, which is quite acceptable for a home device that is constantly on. The first month of his life, he worked without a single problem.


If you have any questions, comments, or ideas for improvement and further development, I will be glad to comment. Thanks!

Also popular now: