A xinetd egy régi „szuperszerver”: a beállított portokon figyel, és amikor egy kapcsolat érkezik, elindítja a hozzá tartozó programot, amely a kapcsolaton keresztül kommunikál a klienssel. Így olyan egyszerű programok is hálózati szolgáltatássá válhattak, amelyek csak a standard bemenetről olvasnak és a standard kimenetre írnak.

A Red Hat-alapú rendszerekből a xinetd kikerült: AlmaLinux 9-en és 10-en sem a rendszer tárolóiban, sem az EPEL-ben nem érhető el (a teszten a dnf info xinetd mindkettőn „No matching Packages” választ adott). Ha egy régi szerverről xinetd alatt futó szolgáltatást költöztetsz, azt systemd socketként kell beállítanod. A systemd ugyanezt tudja: a porton ő figyel, és kapcsolatonként elindítja a programot.

A lépéseket AlmaLinux 10.2 rendszeren próbáltuk ki; minden systemd-t használó disztribúción (Rocky Linux, Ubuntu, Debian) ugyanígy működik.

A kiinduló xinetd szolgáltatás

Egy tipikus xinetd beállítás a /etc/xinetd.d/ könyvtárban:

service fontosapp
{
    type        = UNLISTED
    port        = 3662
    socket_type = stream
    protocol    = tcp
    wait        = no
    user        = nobody
    server      = /usr/local/bin/fontosapp
    disable     = no
}

A TCP 3662-es porton figyel, minden kapcsolatra elindítja a /usr/local/bin/fontosapp programot nobody felhasználóként, és a program kimenetét a kliensnek küldi. A wait = no azt jelenti, hogy minden kapcsolat külön folyamatot kap.

1. A socket fájl

A systemd-ben a porton figyelő rész egy .socket fájl, például /etc/systemd/system/fontosapp.socket:

[Unit]
Description=Sajat alkalmazas socket

[Socket]
ListenStream=3662
Accept=yes

[Install]
WantedBy=sockets.target

Az Accept=yes felel meg a xinetd wait = no beállításának: minden kapcsolathoz külön szolgáltatáspéldány indul.

2. A szolgáltatás fájl

A programot elindító rész a /etc/systemd/system/fontosapp@.service fájl. A névben a @ kötelező: Accept=yes mellett a systemd ebből a sablonból indít egy példányt minden kapcsolathoz, és a fájl nevének a socket nevével kell egyeznie (fontosapp.socket → fontosapp@.service).

[Unit]
Description=Sajat alkalmazas kiszolgalo

[Service]
ExecStart=-/usr/local/bin/fontosapp
User=nobody
StandardInput=socket

• ExecStart: a program teljes elérési útja. Az elején álló - miatt a systemd nem tekinti hibának, ha a program nem nulla kóddal lép ki.
• User: a xinetd user beállításának megfelelője. Ha nem kell root jog, ne adj; a példa nobody felhasználóval fut.
• StandardInput=socket: a program bemenete (és alapból a kimenete is) a hálózati kapcsolat lesz, ahogy xinetd alatt.

3. Engedélyezés és indítás

Nem a szolgáltatást, hanem a socketet kell engedélyezni és elindítani:

sudo systemctl daemon-reload
sudo systemctl enable --now fontosapp.socket
systemctl status fontosapp.socket

A porton ezután a systemd figyel; a teszten a sudo ss -tlnp | grep 3662 kimenete *:3662 … users:(("systemd",pid=1,…)) volt.

4. Kipróbálás

Egy egyszerű próbaprogram, amely kiírja a gép nevét és az időt:

#!/bin/sh
echo "Szia, $(hostname)! Ido: $(date +%T)"

Kapcsolódás a porthoz (a nc helyett a bash beépített /dev/tcp lehetőségével, így nem kell semmit telepíteni):

exec 3<>/dev/tcp/127.0.0.1/3662; cat <&3; exec 3<&-

A teszten a válasz Szia, vps! Ido: 23:04:07 volt, a systemctl status fontosapp.socket pedig az elfogadott kapcsolatok számát is mutatta (Accepted: 1; Connected: 0;).

Ha kívülről is el kell érni

A socket minden hálózati felületen figyel. Ha a szolgáltatást csak a gépen belül használod, írd a ListenStream sorba a helyi címet (ListenStream=127.0.0.1:3662). Ha kívülről is el kell érni, és fut a firewalld, nyisd meg a portot (sudo firewall-cmd --permanent --add-port=3662/tcp, majd sudo firewall-cmd --reload). Nem szabványos port esetén a SELinux is beleszólhat, lásd: SELinux: miért kapok „Permission denied” hibát?

A systemd szolgáltatások kezeléséről a Szolgáltatások kezelése systemctl paranccsal, a naplóikról a journalctl cikk szól.