Az alábbiak frissen telepített Proxmox 6.0-án, így Debian 10-en történnek. Feltételezem, hogy egy ideálisan beállított node-on vagy, amelynek van publikus ip címe (vagy legalábbis ide jut be), és van egy, az ip címhez társított host neved. Példának kedvéért:

• host neved: pve01.host.hu
• ip címed: 1.1.1.1

Feltételezem azt is, hogy nincs webszerver telepítve a node-on, vagyis azt, hogy egy program sem használja a 80-as portot.

Mint minden webhely tanúsítványa, ez is 3 fontos dolgot igényel: tanúsítványt, privát kulcsot és a felsőbb szintű lánc tanúsítványokat – ebben tehát nincs ördöngösség. A plusz az, hogy a pveproxy-t kell újra indítani.

Először is célszerű telepíteni a certbot-ot:

#apt install certbot

Ezután kérjünk egy tanúsítványt:

certbot certonly --standalone --preferred-challenges http -d pve01.host.hu

Ezzel tulajdonképpen meg is vagy. Megkérdez 1-2 dolgot (email cím, hozzájárulás), majd ha a hitelesítés rendben lefut, máris legenerálta a tanúsítványt, kulcsot és miegymást, amire csak szükséged lehet. Mindezt az /etc/letsencrypt/live/pve01.host.hu könyvtárban fogod megtalálni.

A következő lépésben másold át az alábbi fájlokat az /etc/pve/local könyvtárba:

• /etc/letsencrypt6archive/pve01.host.hu/fullchain1.pem
• /etc/letsencrypt6archive/pve01.host.hu/privkey1.pem

Ezek tulajdnonképpen symlinkelve vannak a korábban említett /etc/letsencrypt/live/pve01.host.hu könyvtárba, csak éppen symlinket nem lehet használni az /etc/pve könyvtárban, így a tényleges tartalmat kell áthelyezni.

Következő lépésben le kell cserélned a Proxmox tanúsítványát és kulcsát. ezt mindig az adott node könyvtárában találod, amit az /etc/pve/local alatt találsz. Ide másoltad át az előbbiekben a fájlokat, és itt fogod megtalálni pve-ssl.key és pve-ssl.pem fájlokat, amelyekt most lecserélsz. Ha gondolod, előtte mentsd le ezeket.

Átnevezések:

• /etc/pve/local/fullchain1.pem -> /etc/pve/local/pve-ssl.pem
• /etc/pve/local/privkey1.pem -> /etc/pve/local/pve-ssl.key

Ezután már csak újra kell indítanod a pveproxy szolgáltatást.

#systemctl restart pveproxy

A webfelület pedig máris valid. Ha mégsem (és ez előfordulhat), akkor először próbáld ki privát ablakban, majd ha ott jól működik, akkor egyszerűen csak zárd be a korábbi tab-ot/ablakot, és nyiss egy újat, abban nyisd meg a Proxmox webfelületét.

Az Elasticsearch alapból nem ad hitelesítéssel és jogosultsággal kapcsolatos funkciókat. Ezeket az X-Pack nevű modul biztosítja, ami bár fizetős, csak akkor, ha teljes körűen akarjuk használni. Ingyen is használható pár hitelesítési és jogosultságkezelési opciója. Erről bővebben az Elasticsearch hitelesítés oldalon tudsz olvasni.

Ahogy korábban említettem, Arch Linux esetében pacman-el telepíthető lenne az elasticsearch csomag, de ebből sajnos hiányzik az X-Pack. Valószínűsítem, hogy licencelési okok állnak a háttérben. Neked a teljes változatra van szükséged, amely tartalmazza az X-Pack modult. A teljes változat nem azt jelenti, hogy egyből fizetőssé válik a szoftver. Az X-Pack modul sok funkciót tartalmaz, fizetni pedig csak a modul bővebb használatáért kell. Kétféle előfizetés választható, amikhez szokásos módon külön licence is jár. Ennek birtokában tudod elérni a plusz funkciókat. Erről többet itt olvashatsz: https://www.elastic.co/subscriptions

Érdekesség kedvéért találtam 1-2 beszélgetést a Reddit-en az X-Pack költségeit illetően. Ezek alapján:

Telepítés

Hivatalosan .deb és .rpm csomag, illetve a forráskód áll rendelkezésünkre az Elasticsearch oldalán: https://www.elastic.co/downloads/elasticsearch. A .deb és .rpm csomagok telepítésének leírását nem taglalom.

A hivatalos Arch telepítő csomag esetében a PKGBUILD-ben lévő forrás URL-ben van egy oss jelölés, ami által – vélhetően – csupán az Open Source változat tölthető le. Az oss jelölés nélküli URL a teljes változatot tartalmazza. Megoldásként két dolgot tehetsz:

1. telepítesz Elasticsearch forrásból, amihez összeütsz egy service fájlt – ez némileg fapados, pár dolgot manuálisan kell még utána megcsinálnod (felhasználó létrehozás, tmp könyvtár, stb)
2. az eredeti PKGBUILD alapján készítesz egy saját csomagot, amiben a forrás a teljes változat

Én az utóbbit választanám. Ehhez letöltöd az Arch Linux community repóját, hogy hozzáférj az elasticsearch csomaghoz szükséges egyéb fájlokhoz (service, tmpfile, stb). Ezzel sok időt nyerhetsz.

git clone https://git.archlinux.org/svntogit/community.git .

A PKGBUILD-ben kicseréled a forrást a teljes verzióra (https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-7.1.1-linux-x86_64.tar.gz), illetve kicserélted hozzá az aktuális sha256sum értéket. Generálsz hozzá egy .SRCINFO fájlt majd minden mást módosítatlanul hagyva futtattod a makepkg-t és végül telepíted a csomagot.

Az elasticsearch alapból nem ad hitelesítéssel és jogosultsággal kapcsolatos funkciókat. Ezeket az X-Pack nevű modul biztosítja, amelynek használata első olvasatra fizetős.

Második olvasatra viszont észre vehetjük, hogy ha nem igényeljük az X-Pack teljes fegyvertárát, akkor a Basic verzióként (ami még szintén ingyenes) használhatunk alapfokú hitelesítési és jogosultságkezelő funkciókat. Jól látható, hogy az RBAC (Role-based access control), illetve a file és native realm típusú hitelesítés érhető el számunkra:

Első lépések

A telepítésről itt tudsz bővebben olvasni: Elasticsearch telepítése Arch Linuxon. Miután telepítetted a megfelelő verziót és megejtetted az első beállítások (cluster, node, network), először érdemes beállítani a beépített felhasználók jelszavát. Jelen állapotban ugyanis szabad a vásár, az csatlakozik az adatbázishoz aki akar. A jelszavak beállítása után ezt már nem lehet megtenni. A beépített felhasználók listája:

• apm_system
• kibana
• logstash_system
• beats_system
• remote_monitoring_user
• elastic

A jelszavak beállítását egy parancssoros programmal tudjuk megtenni:

#elasticsearch-setup-password auto

Használható az interactive opció is az auto helyett, de túl sok jelszót kell bepötyögni, érdemes az auto-t használnod. A felhasználókat és a generált jelszavakat kiírja a konzolra, ezeket érdemes elmenteni. Ezek után ha csatlakozni akarsz a REST API-hoz, az elastic felhasználót és annak jelszavát kell használnod (amíg nincsenek más felhasználóid).

Konfiguráció

Ahogy korábban is beszéltük, a sokfajta hitelesítési megoldás közül a file és a native realm áll ingyenesen a rendelkezésünkre. Mindegy, hogy melyiket választod, azt előtte engedélyezned kell.

xpack.security.enabled: true xpack.security.transport.ssl.enabled: true xpack:   security:     authc:       realms:         file:           file1:             order: 1             enabled: false         native:           native1:             order: 0

Először is engedélyezned kell az X-Pack security-t. Ez a beállítás megköveteli a transport csatorna SSL beállítását, tehát ezt is beállítjuk. Ezután beállíthatod a file vagy native realm-t. Akár mindkettőt is használhatod egyszerre, lényeg, hogy az order tulajdonságuk is beállításra kerüljön, amivel a hitelesítési sorrendet határozzuk meg. Jelen példában sorrendben első a native, majd a file, bár a fenti példában a file realm kikapcsolásra került (enabled: false).

Native realm

A dokumentácó szerint a legkönnyebb hitelesítési lehetőséget a native realm adja (persze annak, akinek a REST API használata nem gond). A native realm által kezelt felhasználói adatok a clusterre egészére vonatkoznak, így nem konfigurációs fájl, hanem REST API segítségével lehet menedzselni a felhasználókat, jogosultságokat és jelszavakat. Ezeket az adatokat a _security index alatt tárolja a rendszer, ami természetesen a cluster összes node-ján megtalálható lesz.

Mivel korábban már beállítottuk a beépített felhasználók jelszavát, a REST API használatához loginolni kell. Az elastic nevű felhasználó megfelelő lesz hozzá.

curl -u elastic -X POST "127.0.0.1:9200/_security/user/username" -H 'Content-Type: application/json' -d' {   "password" : "password",   "roles" : [ "superadmin"],   "full_name" : "User Name",   "email" : "username@example.com",   "metadata" : {     "intelligence" : 7   } } '

A parancs futtatásakor a curl bekéri az elastic user jelszavát, de ha megadható előre a -u elastic@password formátummal is. Ha minden rendben, az alábbi választ kapod vissza:

{     "created": true }

Ezek után tudod lekérdezni a felhasználó adatait:

curl -u username -X GET "127.0.0.1:9200/_security/_authenticate"

És a válasz:

{   "username": "username",   "roles": [     "superadmin"   ],   "full_name": "User Name",   "email": "username@example.com",   "metadata": {     "intelligence": 7   },   "enabled": true,   "authentication_realm": {     "name": "native1",     "type": "native"   },   "lookup_realm": {     "name": "native1",     "type": "native"   } }

File realm

A file realm segítségével a felhasználókat és jogait konfigurációs fájlból olvassa ki az adatbázis. Mivel ez a módszer fájl alapon működik, a konfigurációs fájlokat a cluster mindegyik node-jára át kell másolni. A használható fájlok:

• role_mapping.yml
• roles.yml
• users
• users_roles

A role_mapping.yml fájlt most nem érintjük. A roles.yml tárolja az általunk létrehozott egyedi role szabályokat, az users tárolja a felhasználókat és azok hash jelszavait, az users_roles pedig a felhasználók és role-ok kapcsolásait. Egy felhasználóhoz akár több role is társítható, ezek soronként kerülnek be az users_role fájlba.

Nem kell a fájlokat magunknak szerkesztenünk, kapunk hozzá parancssoros programot: elasticsearch-users. Használata faék egyszerű:

#felhasznalok listazasa elasticsearch-users list #felhasznalo letrehozasa elasticsearch-users useradd username #role beallitasa elasticsearch-users roles username -a superadmin #role torlese elasticsearch-users roles username -r superadmin #felhasznalo torlese elasticsearch-users userdel username  #jelszo csere elasticsearch-users passwd username

Role rendszer – RBAC

A szerver mindegyik felhasználóhoz társít egy alapértelmezett role-t. Ez a role engedélyezi a felhasználóknak az authentication végpont elérését, jelszavuk cseréjét és információ kérését saját magukról.

Ezen felül van pár beépített role a rendszerben, amelyek közül majdnem bármelyiket hozzáköthetjük bármelyik felhasználóhoz. Ezek a role-ok rögzített jogosultságokkal rendelkeznek és nem módosíthatóak. Van olyan role, amit nem lehet felhasználóhoz társítani.

• apm_system
  Biztosítja az APM rendszer felhasználójának szükséges hozzáférést ahhoz, hogy rendszer szintű adatokat (például monitoring) küldjön az Elasticsearch-nek.
• apm_user
  Biztosítja az APM-felhasználók számára szükséges jogosultságokat (például az apm-* és .ml-anomalies* indexek olvasási és view_index_metadata jogosultságait).
• beats_admin
  Hozzáférést biztosít a .management-beats indexhez, amely a Beats konfigurációs adatait tartalmazza.
• beats_system
  A Beats rendszer felhasználójának hozzáférést biztosít a rendszer szintű adatok (például megfigyelés) elküldéséhez az Elasticsearch-nek.
• ingest_admin
  Hozzáférést biztosít az összes index sablon és az összes ingest pipeline konfiguráció kezeléséhez.
• kibana_dashboard_only_user
  Hozzáférést biztosít a Kibana Dashboardhoz, és csak olvasási engedélyeket biztosít a Kibana számára. Ez a role nem fér hozzá a Kibana szerkesztési eszközeihez.
• kibana_system
  A Kibana rendszer felhasználójának szükséges hozzáférést biztosít a Kibana indexek olvasásához és írásához, index sablonok és tokenek kezeléséhez, valamint az Elasticsearch fürt elérhetőségének ellenőrzéséhez. Ez a szerep biztosítja a read hozzáférést a .monitoring-* indexekhez, valamint az olvasási és írási hozzáférést a .reporting-* indexekhez.
• kibana_user
  Kibana minden funkciójának elérése.
• logstash_admin
  Hozzáférést biztosít a .logstash* indexekhez a konfigurációk kezeléséhez.
• logstash_system
  Biztosítja a Logstash rendszer felhasználójának szükséges hozzáférést ahhoz, hogy rendszer szintű adatokat (például monitoring) küldjön az Elasticsearch-nek.
• machine_learning_admin
  Biztosítja a manage_ml cluster jogosultságokat, ezenkívül olvasási elérést az .ml-anomalies*, .ml-notifications*, .ml-state *, .ml-meta* indexekhez és írási jogosultságot az .ml-annotations* indexekhez.
• machine_learning_user
  Biztosítja a gépi tanulás konfigurációjának, állapotának és eredményeinek megtekintéséhez szükséges minimális jogosultságokat. Ez a szerepkör biztosítja a monitor_ml cluster jogosultságait, olvasási hozzáférést az .ml-notifications és a .ml-anomalies* indexekhez (amelyek a gépi tanulási eredményeket tárolják), és írási hozzáférést az .ml-annotations* indexekhez.
• monitoring_user
  Biztosítja az X-Pack monitoring használatához szükséges minimális jogosultságokat, kivéve a Kibana használatához szükséges jogosultságokat. Ez a szerepkör lehetővé teszi a monitoring indexekhez való hozzáférést és az alapvető cluster információk olvasásához szükséges jogosultságokat. A monitoring_users felhasználókhoz a kibana_user role-t is hozzá kell rendelni.
• remote_monitoring_agent
  Biztosítja a minimális jogosultságokat az adatok monitoring indexekbe történő írásához (.monitoring-*). Ez a szerepkör a Metricbeat indexek (metricbeat- *) létrehozásához és a hozzájuk tartozó adatok írásához szükséges jogosultságokkal is rendelkezik.
• remote_monitoring_collector
  Biztosítja azokat a minimális jogosultságokat, amelyek az Elastic Stack monitoring adatainak gyűjtéséhez szükségesek.
• reporting_user
  Biztosítja az X-Pack felhasználóknak a riport jogosultságot, kivéve a Kibana használatához szükséges más jogosultságokat. Ez a szerepkör hozzáférést biztosít a report indexekhez; de mindegyik felhasználó csak saját jelentéseihez férhet hozzá. A riport felhasználókhoz hozzá kell rendelni a kibana_user szerepkört és egy olyan szerepkört, amely hozzáférést biztosít számukra a jelentések létrehozásához használt adatokhoz.
• snapshot_user
  Biztosítja a szükséges jogosultságokat az összes index pillanatfelvételének létrehozásához és a meta adatok megtekintéséhez. Ez a szerepkör lehetővé teszi a felhasználók számára, hogy megtekinthessék a meglévő pillanatfelvétel-tárolók és pillanatfelvételek részleteit. Nem engedélyezi a tárolók eltávolítását vagy hozzáadását, illetve a pillanatképek visszaállítását. Nem teszi lehetővé az index beállítások módosítását vagy az index adatok olvasását vagy frissítését.
• superuser
  Teljes hozzáférést biztosít a cluster-hez, beleértve az összes indexet és adatot. A felhasználók, akiknek a superadmin szerepe van, a felhasználókat és szerepköröket is kezelheti, és bármilyen más felhasználót is megszemélyesíthet a rendszerben.
• transport_client
  Biztosítja a Java Transport Client által a cluster eléréséhez szükséges jogosultságokat. A Java Transport Client a cluster csomópontjairól információkat gyűjt a Node Liveness API és a Cluster State API használatával.
• watcher_admin
  Olvasási hozzáférést biztosít a .watches indexhez, olvasási hozzáférést a watch history-hoz a triggered watch indexekhez és lehetővé teszi az összes watch action végrehajtását.
• watcher_user
  Biztosítja az olvasási hozzáférést a .watches indexhez, és szintén biztosítja a get watch action és a watcher statisztikát.

Az összes beépített role közül a superadmin a legérdekesebb. Ez a role teljes hozzáférést biztosít mindenhez, így csínján kell vele bánni.

Egyedi role

Saját role-ok is létrehozhatóak. Egy role-ban pár tulajdonságot szabályozni kell:

• applications
  Lista, amely az alkalmazások jogosultsági listáját tartalmazza. A lista elem tartalmazza: application, privileges, resources. Nem kötelező mező.
• cluster
  A cluster jogosultságok listája. Ezek a jogosultságok határozzák meg azokat a cluster-szintű műveleteket, amelyeket az ilyen szerepkörrel rendelkező felhasználók képesek végrehajtani. Nem kötelező mező.
• global
  A globális jogosultságokat meghatározó objektum. A globális jogosultság a cluster jogosultságának formája, amely kérés-érzékeny. A szabványos cluster jogosultság kizárólag a végrehajtott cselekvésen alapuló engedélyezési döntéseket hoz. A globális jogosultság figyelembe veszi a kérelemben szereplő paramétereket is. A globális jogosultságok támogatása jelenleg az alkalmazásjogosultságok kezelésére korlátozódik. Ez a mező nem kötelező.
• indices
  Az indexek hozzáférési listája. A lista elem tartalmazza: field_security, names, privileges, query. Nem kötelező mező.
• metadata
  Objektum, amely opcionális metaadatokat tartalmazhat. A metaadat objektumon belül az _ használatával kezdődő kulcsok a rendszerhasználat számára vannak fenntartva.
• run_as
  Azoknak a felhasználóknak a listája, akik az ezt tulajdonoló felhasználókat megszemélyesíthetik.

role

{   "run_as": [ ... ],    "cluster": [ ... ],    "global": { ... },    "indices": [ ... ],    "applications": [ ... ]  }

indices

{   "names": [ … ],   "privileges": [ … ],   "field_security" : { … },   "query": "…" }

• names
  Az indexek (vagy indexnevek) listája, amelyekre az ebben a bejegyzésben szereplő jogosultságok érvényesek.
• privileges
  Indexszintű jogosultság a kapcsolódó indexeken (azok az indexek, amelyek a name mezőben vannak megadva)
• field_security
  A dokumentum mezők leírása amelyhez a felhasználók olvasási hozzáféréssel rendelkeznek
• query
  Egy olyan keresési lekérdezés, amely meghatározza az elérhető dokumentumok olvasási jogát. A társított indexeken belüli dokumentumnak meg kell egyeznie ezzel a lekérdezéssel annak érdekében, hogy a szereplők számára hozzáférhető legyen.

global

{   "application": {     "manage": {             "applications": [ ... ]      }   } }

• manage
  Az egyetlen támogatott globális jogosultság az alkalmazások jogosultságainak kezeléséhez
• applications
  A kezelendő alkalmazások neveinek listája. Ez a lista támogatja a helyettesítő karaktereket (pl. “myapp-*”) és a reguláris kifejezéseket (pl. “/ app[0-9]*/”)

application

{   "application": "my_app",    "privileges": [ ... ],      "resources": [ ... ]      }

• application
  Alkalmazás neve.
• privileges
  Az alkalmazáshoz tartozó jogosultságok neveinek listája.
• resources
  Azok az erőforrások, amelyekre e kiváltságok érvényesek. Ezeket ugyanúgy kezelik, mint az indexnév minta az indices jogosultságban. Ezeknek az erőforrásoknak nincs különösebb jelentősége az Elasticsearch biztonsági jellemzőihez.

Egy teljes példa

{   "cluster": ["all"],   "indices": [     {       "names": [ "index1", "index2" ],       "privileges": ["all"],       "field_security" : { // optional         "grant" : [ "title", "body" ]       },       "query": "{\"match\": {\"title\": \"foo\"}}" // optional     }   ],   "applications": [     {       "application": "myapp",       "privileges": [ "admin", "read" ],       "resources": [ "*" ]     }   ],   "run_as": [ "other_user" ], // optional   "metadata" : { // optional     "version" : 1   } }

A role-okat természetesen REST API-n keresztül a legkönnyebb menedzselni, amihez a felhasználónak szüksége van a manage_security cluster jogosultságra.

Egy role létrehozása:

curl -u username -X POST "127.0.0.1:9200/_security/role/clicks_admin" -H 'Content-Type: application/json' -d' {   "run_as": [ "clicks_watcher_1" ],   "cluster": [ "monitor" ],   "indices": [     {       "names": [ "events-*" ],       "privileges": [ "read" ],       "field_security" : {         "grant" : [ "category", "@timestamp", "message" ]       },       "query": "{\"match\": {\"category\": \"click\"}}"     }   ] } '

A válasz:

{   "role": {     "created": true    } }

A fenti definíció alapján a clicks_admin szerepkörrel rendelkező felhasználó:

• megszemélyesítheti a clicks_watcher_1 felhasználót és kéréseket hajthat végre a nevében
• monitorozhatja az Elasticsearch cluster-t
• olvashatja az összes events- kezdetű indexből származó adatokat
•  ezeken az indexeken belül csak a click kategóriájú events olvashatja el
•  ezeken a dokumentumon belül csak a category-, @timestamp- és message mezők olvashatók.

Fájl alapú role-ok

A fájl alapú role-ok esetében egy role definicióját a roles.yml fájlban hozzuk létre:

click_admins:   run_as: [ 'clicks_watcher_1' ]   cluster: [ 'monitor' ]   indices:     - names: [ 'events-*' ]       privileges: [ 'read' ]       field_security:         grant: ['category', '@timestamp', 'message' ]       query: '{"match": {"category": "click"}}'

Az Elasticsearch folyamatosan monitorozza a roles.yml fájlt, és automatikusan alkalmazza a változásokat.

A users_roles fájlban társítjuka felhasználót és a role-t. Egy sorban egy társítás:

superuser:user1 click_admins:user2

Ne felejtsd el, hogy a file realm (azaz a fájl alapú felhasználó és role kezelés) node alapú. Ha több node-ból áll a clustered, akkor a cluster összes node-jára el kell juttatnod a fájlokat, illetve az esetleges változtatásokat.

Az SSSD PAM és NSS modulokat is biztosít (illetve D-BUS alapú felületet is a későbbiekben), míg a háttérben számos backend támogatja a különböző rendszerek elérhetőségét. A backendek tárolják az identitásokat és egyéb adatokat. A backend nevet Én akasztottam rá, egyébként authentication provider-nek hívják. Backendek a teljesség igénye nélkül:

• LDAP
• Windows Active Directory (AD)
• FreeIPA
• krb5
• local SSSD
• proxy

Azt nem mondanám, hogy a téma zsebemben van, így elképzelhető, hogy egy-két részlet nem teljes, következetlen, vagy más rendszereken (pl. Ubuntu) nem teljes mértékben használható.  A krb5 például teljesen felesleges (csak szerverek között az Active Directory is, elég lenne az LDAP), de korábban még ezzel alakítottam ki a rendszereket, és nem volt időm foglalkozni a krb5 nélküliséggel.

A leírás során azt feltételezem, hogy van már egy beállított Samba 4 vagy Windows AD rendszered unixos felhasználókkal és csoportokkal.

Az SSSD telepítése rém egyszerű:

pacman -Sy sssd

Amennyiben nem létezik az /etc/sssd/sssd.conf fájl, hozd létre az alábbi tartalommal:

[sssd] services = nss, pam, sudo, ssh domains = domain.tld #debug_level = 9 [nss] [pam] [domain/domain.tld] #debug_level = 9 cache_credentials = true krb5_store_password_if_offline = true id_provider = ad access_provider = ad auth_provider = ad krb5_keytab=/etc/krb5.keytab krb5_realm = DOMAIN.TLD ldap_id_mapping = false #fallback_homedir = /home/%u #default_shell = /bin/bash enumerate = true

A domain.tld tartomány egy példa tartomány, Neked le kell cserélned a sajátodéra. Az sssd.conf fájlt csak a root írhatja és olvashatja (0600).

Az /etc/krb5.conf fájlban az  alábbiakat állítsd be:

[libdefaults]         default_realm = DOMAIN.TLD         dns_lookup_realm = true         dns_lookup_kdc = true         ticket_lifetime = 1d         forwardable = true         proxiable = true [realms]         DOMAIN.TLD = {                 kdc = domain.tld                 admin_server = domain.tld                 default_domain = domain.tld         } [domain_realm]         .domain.tld = DOMAIN.TLD         domain.tld = DOMAIN.TLD #       domain = DOMAIN.TLD [appdefaults]         pam = {         ticket_lifetime         = 1d         renew_lifetime          = 1d         forwardable             = true         proxiable               = false         retain_after_close      = false         minimum_uid             = 10000         debug                   = false         } [logging]         default                 = FILE:/var/log/krb5libs.log         kdc                     = FILE:/var/log/kdc.log         admin_server            = FILE:/var/log/kadmind.log

A domain.tld tartomány szintén lecserélendő a saját tartományoddal. A kdc és admin_server értéke a valós szerver legyen ne a tartomány neve. Ha samba-t használsz, akkor annak a neve, ha pedig ténylegesen Windows AD-hoz akarsz csatlakozni, akkor azét. Előfordulhat, hogy megegyezik a tartomány nevével, de általában külön aldomaint kap, mivel a domain controller szokta ezt a funkciót ellátni (pl. ad.domain.tld, pdc.domain.tld, kdc.domain.tld, stb).

Exportáld ki a krb5 machine keytab fájlt a samba vagy AD szerveren. Samba esetében:

net ads keytab create -U Administrator

Az Administrator nevű user a Te rendszeredben más is lehet, erre figyelj oda. Ha esetleg egy másik gépeden már megvan a keytab fájl, akkor csak másold át. A keytab fájlt csak a root írhatja és olvashatja (0600).

/etc/nssswitch.conf módosítása:

# Begin /etc/nsswitch.conf passwd: files sss group: files sss shadow: files sss sudoers: files sss publickey: files hosts: files dns myhostname networks: files protocols: files services: files ethers: files rpc: files netgroup: files # End /etc/nsswitch.conf

Ebben tulajdonképpen felvettük az sss értéket, illetve a sudoers teljes sort.

Az /etc/nscd.conf fájlban kapcsoljuk ki a rendszer cache funkcióját userek és groupok tekintetében. A módosítandó rekordok:

enable-cache            passwd          no enable-cache            group           no

Létrehozzuk az /etc/pam.d/sss fájlt az alábbi tartalommal:

auth     sufficient pam_unix.so nullok try_first_pass auth     sufficient pam_sss.so use_first_pass auth     required   pam_deny.so account  required   pam_unix.so #account  [default=bad success=ok user_unknown=ignore] pam_sss.so account  optional   pam_sss.so password    requisite     pam_cracklib.so try_first_pass retry=3 minlen=8 dcredit=0 ucredit=0 ocredit=0 lcredit=0 type= password sufficient pam_unix.so try_first_pass nullok sha512 shadow password sufficient pam_sss.so use_authtok password required   pam_deny.so session         required        pam_mkhomedir.so skel=/etc/skel umask=0077 session  required   pam_unix.so session  optional   pam_sss.so

Szintén létrehozzuk a /etc/pam.d/sssd-shadowutils fájlt (az sssd telepítése után valószínűleg már létezik):

#%PAM-1.0 auth        [success=done ignore=ignore default=die] pam_unix.so nullok try_first_pass auth        required      pam_deny.so account     required      pam_unix.so account     required      pam_permit.so

Az /etc/pam.d könyvtárban az alábbi fájlokat módosítjuk:

/etc/pam.d/passwd

#%PAM-1.0 password        include         sss 

/etc/pam.d/su

#%PAM-1.0 auth            sufficient      pam_rootok.so auth            include         sss account         include         sss session         include         sss

/etc/pam.d/su-l

#%PAM-1.0 auth            sufficient      pam_rootok.so auth            include         sss account         include         sss session         include         sss

/etc/pam.d/system-auth

#%PAM-1.0 auth      include   sss auth      required  pam_unix.so     try_first_pass nullok auth      optional  pam_permit.so auth      required  pam_env.so account   include   sss account   required  pam_unix.so account   optional  pam_permit.so account   required  pam_time.so password  include   sss #password  required  pam_unix.so     try_first_pass nullok sha512 shadow password  optional  pam_permit.so session   required  pam_limits.so session   include   sss session   required  pam_unix.so session   optional  pam_permit.so

Elméletileg az összes szükséges elem megvan, csupán a szolgáltatásokat kell elindítani vagy újra indítani:

systemctl restart nscd systemctl enable sssd systemctl start sssd 

Ezután a teszt, például felhasználók listázása. Ebben már meg kell jelennie az AD-ban lévő felhasználóknak is:

getent passwd vagy getent passwd username

A csoportok hasonlóképpen működnek:

getent group vagy  getent group groupname

Amit még ne felejts el: /etc/sudoers fájl szerkesztése felhasználók és/vagy csoportok jogosultság beállításának érdekében. Nem kötelező, de általában szoktuk.

Ha minden igaz, telepítési metódja Linux disztribúciótól független, de tudnod kell, hogy jelen leírásnak Arch Linux-on történő telepítés az alapja. Aktuális verzió a 9.4.5

Telepítés

pacman -S postgresql

Inicializálás

Első lépésként létre kell hozni az adatbázist tároló területet – SQL-ben erre a cluster catalog kifejezést használják. Az adatbázis cluster egy olyan adatbázis gyűjtemény, amelyet egy futó adatbázis szerver egyetlen példánya kezel. Az első inicializáció után a cluster egy postgres nevű adatbázist tartalmaz. Minden további adatbázis létrehozása a template1 nevezetű adatbázis alapján történik.

Fájlrendszer szinten a cluster adatok egy könyvtáron belül lesznek tárolva, amit data directory vagy data area-nak neveznek. A könyvtár helye teljesen szabad választás, bár a különféle disztribúciók felkínálnak egy alapértelmezett helyet.

Az inicializálást a postgres nevű felhasználóval kell végrehajtanod, ehhez a su vagy sudo segítségét tudod igénybe venni:

su - postgres # ekkor postgres felhasználó leszel vagy sudo -i -u postgres [command] # ekkor postgres felhasználó nevében hajtod végre az utasítást

A cluster létrehozása (az elérési út disztribúciónként változhat, pl.: ubuntun /var/lib/postgresql):

[postgres] initdb --locale en_US.UTF-8 -E UTF8 -D '/var/lib/postgres/data'

A kimenet nagyjából ehhez hasonló (Én hu_HU.UTF8-at adtam meg):

initdb --locale hu_HU.UTF-8 -E UTF8 -D '/var/lib/postgres/data' The files belonging to this database system will be owned by user "postgres". This user must also own the server process. The database cluster will be initialized with locale "hu_HU.UTF-8". The default text search configuration will be set to "hungarian". Data page checksums are disabled. fixing permissions on existing directory /var/lib/postgres/data ... ok creating subdirectories ... ok selecting default max_connections ... 100 selecting default shared_buffers ... 128MB selecting dynamic shared memory implementation ... posix creating configuration files ... ok creating template1 database in /var/lib/postgres/data/base/1 ... ok initializing pg_authid ... ok initializing dependencies ... ok creating system views ... ok loading system objects' descriptions ... ok creating collations ... ok creating conversions ... ok creating dictionaries ... ok setting privileges on built-in objects ... ok creating information schema ... ok loading PL/pgSQL server-side language ... ok vacuuming database template1 ... ok copying template1 to template0 ... ok copying template1 to postgres ... ok syncing data to disk ... ok WARNING: enabling "trust" authentication for local connections You can change this by editing pg_hba.conf or using the option -A, or --auth-local and --auth-host, the next time you run initdb. Success. You can now start the database server using:     postgres -D /var/lib/postgres/data or     pg_ctl -D /var/lib/postgres/data -l logfile start

Ezután már csak engedélyezni és indítani kell:

systemctl enable postgresql systemctl start postgresql

 Autentikáció beállítása

Első telepítéskor a postgres felhasználóval jelszó nélkül lehet belépni, ezért ezt célszerű módosítani. Először is adj meg egy új jelszót:

sudo -u postgres psql template1   ALTER USER postgres with encrypted password 'az_uj_jelszo';   \q

Ezután a hozzáféréseket szabályzó fájlban (pg_hba.conf) szigorítanod kell a hozzáféréseken:

local   all         postgres                          md5 local   all             all                           md5

git init git add . git commit -a -m 'First commit' git remote add origin ssh://.... git push origin master --set-upstream origin master

1. Webszerver és php

Apache vagy Nginx: Sajnos apache mindenféleképpen kell, ha valami miatt .htaccess támogatást is kell nyújtanod. Ehhez javaslom a mod_itk használatát, amellyel VirtualHost-onként tudod megadni, hogy melyik linux user jogosultságaival fusson egy folyamat.

pacman -S apache mod_itk php-apache pacman -S php-intl php-mcrypt php-gd php-pear

A webszerver beállítása mod_itk-hoz egy kicsit becsapós. Alapból az mpm_event van engedélyezve. Ezt kommentezd, illetve inkább az alábbiakat másold be:

#LoadModule mpm_event_module modules/mod_mpm_event.so                         LoadModule unixd_module modules/mod_unixd.so                                  LoadModule mpm_prefork_module modules/mod_mpm_prefork.so                      LoadModule mpm_itk_module modules/mpm_itk.so

A php használatához erre van szükség:

LoadModule php5_module       modules/libphp5.so AddHandler php5-script php Include conf/extra/php5_module.conf

Pár konfiguráció van még hátra:

1. Korrektól beállítani a betöltendő modulokat, amelyekre szükséged van
2. dir_module bejegyzéshez felvenni az index.php-t
3. VirtualHost beállítás
4. httpd.conf alján az Include-ok kezelése (melyik kell, melyik nem kell)
5. extra/httpd-mpm.conf-ban másolni az IfModule mpm_prefork_module, majd átnevezni: mpm_itk_module
6. /etc/php/php.ini-ben a szükséges beállításokat megejteni.

Ezután már csak el kell indítani az apache-ot:

systemctl enable httpd systemctl start httpd

2. Mysql telepítése

Az Oracle mysql alapból nem érhető el, viszont van mariaDb és Percona szerver. Én a MariaDb-t szoktam telepíteni.

pacman -S mariadb innotop xtrabackup

Az xtrabackup csak a mentések miatt szükséges.

Inicializálni kell az adatbázisokat:

mysql_install_db --user=mysql --basedir=/usr --datadir=/var/lib/mysql

Ezután indítsd el a szervert, és adj egy új jelszót a root-nak:

systemctl enable mysqld systemctl start mysqld /usr/bin/mysqladmin -u root password 'new-password' /usr/bin/mysqladmin -u root -h szervered_fqdn_hosztneve password 'new-password'

3. Ftp szerver telepítése

Magam részéről a pure-ftpd-t kedvelem. Az aur4-ről való telepítéshez:

yaourt pure-ftpd-db

Telepítés közben editálni szoktam a PKGBUILD fájlt, kiveszem a postgresql-re vonatkozó dolgokat (depends, fordítási opció), de Neked ezt nem szükséges meglépni.

Legegyszerűbb a mysql alapú adattárolás tűnik. Ehhez az /etc/pure-ftpd/pure-ftpd.conf fájlban ez az egy opció legyen olyan, amelyik nincs kikommentezve:

MySQLConfigFile               /etc/pure-ftpd/pureftpd-mysql.conf

Tehát az LDAPConfigFile, PGSQLConfigFile, PureDB, ExtAuth,PAMAuthentication, UnixAuthentication paraméterekre nincs szükségünk, ezek legyenek kikommentezve. Ezután hozd létre az /etc/pure-ftpd/pureftpd-mysql.conf nevű fájlt, a tartalma pedig az alábbi legyen:

MYSQLServer     localhost MYSQLPort       3306 MYSQLSocket     /run/mysqld/mysqld.sock MYSQLUser       {mysql_user} MYSQLPassword   {mysql_user_password} MYSQLDatabase   {mysql_database} # Valid values are : "cleartext", "crypt", "md5" and "password" MYSQLCrypt      cleartext MYSQLGetPW      SELECT passw as Password FROM ftpaccount WHERE ftpaccount="\L" MYSQLGetUID     SELECT uid as Uid FROM ftpaccount WHERE ftpaccount="\L" MYSQLGetGID     SELECT gid as Gid FROM ftpaccount WHERE ftpaccount="\L" MYSQLGetDir     SELECT homedir as Dir FROM ftpaccount WHERE ftpaccount="\L"

A lekérdezéshez az adatbázis és a táblát is hozd létre. A tábla létrehozási sql-je:

CREATE TABLE `ftpaccount` (   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,   `status` enum('ENABLED','DISABLED') NOT NULL DEFAULT 'ENABLED',   `ftpaccount` varchar(50) NOT NULL COMMENT 'ftp account neve (belepesi nev)',   `passw` varchar(64) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL,   `uid` int(11) NOT NULL DEFAULT '-1',   `gid` int(11) NOT NULL DEFAULT '-1',   `homedir` varchar(255) NOT NULL COMMENT 'ftp account home konyvtar (abszolut eleresi ut)',   `ulbandwith` smallint(5) unsigned NOT NULL DEFAULT '0',   `dlbandwidth` smallint(5) unsigned NOT NULL DEFAULT '0',   `ipaccess` varchar(15) CHARACTER SET utf8 COLLATE utf8_bin NOT NULL DEFAULT '*',   PRIMARY KEY (`id`),   UNIQUE KEY `NewIndex1` (`ftpaccount`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8

Nézd át az alap konfigurációs tulajdonságokat, amelyiket úgy érzed, azt állítsd be. Én főleg ezeket szoktam érinteni:

ForcePassiveIP {server_ip_address} ChrootEveryone yes BrokenClientsCompatibility  no DisplayDotFiles             yes AnonymousOnly               no NoAnonymous                 yes DontResolve                 yes MaxIdleTime                 5 AnonymousCanCreateDirs      no PassivePortRange          30000 50000 ProhibitDotFilesWrite       no ProhibitDotFilesRead        no AnonymousCantUpload         yes AltLog                     clf:/var/log/pureftpd.log 

Ezután már csak el kell indítani az ftp szervert:

systemctl enable pure-ftpd systemctl start pure-ftpd

A telepítés során azt feltételezem, hogy két db 250 GB-os SSD lemezre telepítesz, és két hálózati kártyád van.

A telepítő használata

Győződj meg arról, hogy a BIOS-ban be van állítva az USB eszközről való bootolás (vagy eltudod érni a boot menüt). Miután a telepítő betöltődött, látni fogod az Arch Linux logót, és a GRUB-ot. A boot folyamat végeztével meg fog jelenni a parancssoros felület. Úgy sejtem, meglepetésként ér, hogy más disztribúcióknál megszokott (pl. Ubuntu) telepítési folyamat nincs – de azt gondolom, hogy nem is kezdő linuxosnak van szükségük Arch Linuxra.

A legfontosabb tennivalók: merevlemezek előkészítése (particionálás, raid, fájlrendszerek létrehozása), alaprendszer másolása, majd chroot-ba lépés után pár fontos beállítás megejtése, és kész is vagy. Nem állítom, hogy az alábbi telepítési lépések mindegyike kötelező – Én ezeket és pontosan ebben a sorrendben szoktam megejteni.

Telepítési lépések:

1. Boot
2. Magyar billentyűzetkiosztás betöltése
3. Hálózat beállítása
4. Pontos idő beállítása
5. Csomagforrások beállítása
6. Merevlemez particionálása (UEFI és MBR)
7. Raid létrehozása
8. Particiók formázása: fájl rendszerek és swap
9. Csatolási pontok megadása
10. Alaprendszer telepítése
11. Fstab beállítása
12. arch-chroot
13. RAID beállítások érvényesítése
14. Tükörszerver választása
15. Idő, időzóna beállítása
16. Hosztnév, locales, vconsole beállítása
17. RAM disk készítése
18. Root password beállítása, új felhasználó hozzáadása, sudo telepítése
19. Egyebek telepítése
20. Rendszerbetöltő telepítése (UEFI és MBR)
21. Újraindítás

1. Boot

Boot iso letöltése: https://www.archlinux.org/download/

USB-re kiírva máris bootolhatsz, tulajdonképpen egy live rendszert. Miután a telepítő betöltődött, látni fogod az Arch Linux logót, és a GRUB-ot. Az első opció máris megfelelő lesz: Boot Arch Linux (x86_64). A boot folyamat végén kapsz egy root promptot.

2. Magyar billentyűzetkiosztás betöltése

Ha nem akarsz angol billentyűzet kiosztással vacakolni, akkor célszerű a magyart beállítani.

localectl list-keymaps | grep hu loadkeys hu

3. Hálózat beállítása

A telepítéshez internet kapcsolatra lesz szükséged. Bizonyos meg arról, hogy van hálózati interfészed:

ip link

Ha nincs, akkor győzödj meg arról, hogy van bedugva hálózati kábel vagy a kábel megfelelő, esetleg a hálózati eszközök megfelelően működnek.

Működő hálózatu interfész esetén dhcp-vel vagy statikus ip beállítással tudsz hálózathoz csatlakozni.
Ha statikus ip címet szeretnél majd használni, érdemes már most előkészülni. Mindenek előtt győződj meg arról, hogy kaptál-e ip címeket. Otthoni környezetben (vagyis dhcp-s router mögött) nagy valószínűséggel igen, így statikus ip cím megadása nélkül is van interneted (szükséges a csomagok telepítéséhez). Önmagában ez nem gond, de statikus ip cím használatához az esetlegesen működő dhcp kliensedet ki kell kapcsolni.

# ip cím kiosztas és dhcp kliens ellenőrzese #ip a #systemctl status dhcpcd

Ha megelégszel a dhcp-vel, akkor ellenőrizned kell, hogy van-e ip címed, illetve ha nincs (vagy csak ipv6), akkor indítsd el a dhcp-t.

#ip a #systemctl start dhcpcd

Jómagam a systemd-networkd rendszert használom hálózat kezelésére, így statikus ip címhez készíts konfigurációs fájlokat: /etc/systemd/network/eth0.network és /etc/systemd/network/eth1.network néven. Tulajdonképpen a fájl neve mindegy, egyedül a .network kiterjesztés a fontos. Én az adott hálókártya eszköznevét szoktam használni.

Ne tévesszen meg az eth0 vagy eth1-es hivatkozás. Most csak az egyszerűség kedvéért használom ezeket az elnevezéseket, Neked viszont fontos a saját gépeden kiolvasni a hálókártyák adatait és azokat használni. A hálókártyákat az ip a parancssal megtudod jeleníteni.

#touch /etc/systemd/network/eth0.network #touch /etc/systemd/network/eth1.network

Beállítások:

#/etc/systemd/network/eth0.network [Match]  Name=eth0 [Network]  Address=192.168.0.50/24 # sajat halozatodbol adj meg egy szabad ip cimet  Gateway=192.168.0.1 # sajat routered ip cimet ad meg

#/etc/systemd/network/eth1.network [Match]  Name=eth1 [Network]  Address=192.168.0.50/24 # sajat halozatodbol adj meg egy szabad ip cimet #itt ne add meg a gateway beallitast 

A Match/Name fontos, az adott hálókártya neve legyen.

Kapcsold ki a dhcpt és be a networkd-t:

systemctl disable dhcpcd systemctl enable systemd-networkd

Ha esetleg kavarodás van a hálókártya körül, a legegyszerűbb a down/up:

ip link set eth0 down ip link set eth0 up

4. Pontos idő beállítása

Ha már van internetes kapcsolatod, az időt is betudod állítani. A systemd-timesyncd alapból engedélyezve van, így internetes kapcsolat esetén automatikusan szinkronizálódik a pontos idő – elegendő csak ellenőrizni.

timedatectl status # ha nem megfelelő timedatectl set-ntp true

5. Csomagforrások beállítása

Érdemes a csomagforrást beállítani. A csomagokat a hivatalos Arch Linux szerverek tükörszervereiről kell telepíteni. A következő paranccsal állíthatod be a számodra elérhető leggyorsabb tükrözési listát, majd szinkronizáld le az új szerverekről a csomaglistákat.

reflector -c 'Hungary' -a 12 - -sort rate - -save etc/pacman.d/mirrorlist pacman -Syy

6. Merevlemez particionálása

Bizonyos, hogy korábban már megtervezted a lemez(ek), particiók  kiosztását. Ezt kell most megtenned, a számodra legmegfelelőbb eszközzel: fdisk, parted. Particionálás után elkészítheted az esetleges raid tömbjeidet is.

Az UEFI és a BIOS egyaránt alacsony szintű szoftver, amely akkor indul, amikor elindítod a számítógépet, és mielőtt az az operációs rendszert indítaná. Az UEFI egy korszerűbb megoldás a BIOS_nál: nagyobb merevlemezeket, gyorsabb indítási időket, több biztonsági funkciót, valamint kényelmes grafikát és egeret támogat.

UEFI:

Ezt a lépést kihagyhatod, ha MBR rendszert akarsz.
Mivel UEFI módban kell elinduljon a számítógéped, első lépésben ellenőrizd le, hogy tényleg így történt:

ls /sys/firmware/efi/efivars

Ha hiba nélkül listázza a könyvtárat, akkor a rendszered UEFI módban indult el. Ha a könyvtár nem létezik, előfordulhat, hogy a rendszer BIOS (vagy CSM) módban indult el – ekkor vélhetően alaplap beállításaiban kell tevékenykedned. Ha pl. USB-ről boot-olsz, az alaplap boot menüjében a pendrive-odhoz kétféle opciód lesz, az egyiik UEFI elő vagy utótaggal. Ezt válaszd.

Amikor a live rendszer felismeri a lemezeket egy blokkeszközhöz rendeli azokat, például /dev/sda, /dev/nvme0n1 vagy /dev/mmcblk0. Ezen eszközök azonosításához használhatod az lsblk vagy az fdisk parancsot. Példa kimenet (saját gépemről):

#lsblk NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS sda           8:0    0 465,8G  0 disk  └─sda1        8:1    0 465,8G  0 part /shared/data nvme0n1     259:0    0 232,9G  0 disk  ├─nvme0n1p1 259:1    0   512M  0 part /boot ├─nvme0n1p2 259:2    0   220G  0 part / └─nvme0n1p3 259:3    0  12,4G  0 part [SWAP] # fdisk -l Disk /dev/nvme0n1: 232,89 GiB, 250059350016 bytes, 488397168 sectors Disk model: Samsung SSD 970 EVO Plus 250GB           Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: gpt Disk identifier: 9D06D441-CF00-4841-87A0-745E9B5B6CAE Device             Start       End   Sectors  Size Type /dev/nvme0n1p1      2048   1050623   1048576  512M EFI System /dev/nvme0n1p2   1050624 462424063 461373440  220G Linux filesystem /dev/nvme0n1p3 462424064 488397134  25973071 12,4G Linux swap Disk /dev/sda: 465,76 GiB, 500107862016 bytes, 976773168 sectors Disk model: WDC  WDS500G2B0A Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0xd8fd5e07 Device     Boot Start       End   Sectors   Size Id Type /dev/sda1        2048 976773167 976771120 465,8G 83 Linux 

Annak ellenére, hogy az UEFI rendszer támogatja a fő rendszerindítási rekordot (MBR) és a GUID partíciós táblát (GPT), a lemezt a GPT címkével kell ellátnod, mivel az MBR partíciók mérete és száma korlátozott.

Legalább két particíót kötelező készítened: egy root és egy efi particíót. Az EFI rendszerpartíció (más néven ESP) egy operációs rendszertől független partíció, amely az UEFI firmware által elindítandó EFI rendszerbetöltők, alkalmazások és illesztőprogramok tárolóhelyeként működik. Ez kötelező az UEFI rendszerindításhoz. Ha már van egy efi particíód, akkor nem kell másikat készítened, tökéletes lesz az is. Az efi particíó a /boot könyvtárban lesz elérhető.

Az efi paticíó méretére többféle ajánlás létezik. Nyilván el kell férnie a rendszertöltőknek és a rendszerindításhoz szükséges egyéb fájloknak. A microcode itt helyezi el a CPU mikrokódos initramfs fájljait, illetve az mkinitcpio a kerneleket és az initramfs image-ket.
Én 512 MiB adok, az biztos elég (de láttam már 100, 200, 250, 300 MiB ajánlásokat is).

A legegyszerűbb módszertan (fdisk-el):

#van egy /dev/sda eszközünk, meg erintetlen, nincs rajta particios tabla fdisk /dev/sda # guid particios tabla letrehozasa g # efi particio n enter enter +512M t 1 # root particio n enter enter +XG # root particio merete  # swap particio n enter enter enter # ha a hatralevo teruletet adod a swapnak t 3 # particio szama 19 w

Az efi particióra FAT32 fájlrendszert kell készíteni:

mkfs.fat -F 32 /dev/sda1 # mount mount --mkdir /dev/sda1 /mnt/boot

MBR:

A legegyszerűbb módszertan (fdisk-el):

fdisk -l #van egy /dev/sda eszközünk fdisk /dev/sda #particionalsz: elso particio n p 1 enter +XGB # az X helyre add meg a meretet #paricionalsz: swap n p2 enter enter # ha a hatralevo teruletet adod a swapnak t 82 w

Ha esetleg szeretnél gyorsítani, akkor az sfdisk-el másolhatod a partíciós táblákat:

sfdisk -d /dev/sda | sfdisk --force /dev/sdb

7. Raid készítése

Szoftveres raid készítéséhez először is az igénybe veendő particíóktípusát kell módosítanod. Jelen példánk alapján sda1 – sdb1, sda2-sdb2 kettő kell “Linux raid autodetect” típusra állítani. Swap-nek szánt particíónkat is bevonjuk ebbe a körbe.

#fdisk /dev/sda Command (m for help): t Partition number (1,2 default 2): 1 Partition type (type L to list all types): fd Command (m for help): t Partition number (1,2 default 2): 2 Partition type (type L to list all types): fd w 

/dev/sdb lemeznél gyorsíthatsz:

sfdisk -d /dev/sda | sfdisk --force /dev/sdb

Ellenőrízd az eredményt (látni fogod, hogy mindkét lemezed egyforma méretű és típusú particíókat tartalmaz):

#fdisk -l

Most létre tudod hozni a raid tömbjeidet.

mdadm --create --verbose --level=1 --metadata=1.2 --raid-devices=2 /dev/md0 /dev/sda1 /dev/sdb1 mdadm: size set to xxxxK madadm: automatically enabling write-intent bitmap on large array mdadm: array /dev/md0 started # az eredmeny ellenorzese cat /proc/mdstat

Ha esetleg hiányzik egy lemezed a tömbhöz, akkor a hiányzó helyére missing-et írj (… /dev/md0 /dev/sda1 missing).

Példánk következő particíója (swap)

mdadm --create --verbose --level=1 --metadata=1.2 --raid-devices=2 /dev/md1 /dev/sda2 /dev/sdb2 mdadm: size set to xxxxK mdadm: array /dev/md1 started # az eredmeny ujboli ellenorzese cat /proc/mdstat

EFI particíó esetén – bár lehetséges – nem tanácsolják RAID készítését. EFI raid készítése esetén kulcsfontosságú az 1.0 metadata.

mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/ESP /dev/sdaX /dev/sdbY

Ha esetleg korábbi RAID bejegyzéseket kellene törölnöd (mdadm stop, remove, ilyesmi) de nem sikerül a zero-superblock, az alábbival tudsz segíteni magadoon:

dd if=/dev/zero of=/dev/sdY bs=1M count=100

Ha esetleg gyorsabb lemezeid vannak, a lemezek szinkronizálását gyorsíthatod:

echo value > /proc/sys/dev/raid/speed_limit_min echo value > /proc/sys/dev/raid/speed_limit_max # vagy mas modon sysctl -w dev.raid.speed_limit_min=value sysctl -w dev.raid.speed_limit_max=value 

8. Particiók formázása: fájl rendszerek és swap

Root rendszeren ext4

mkfs.ext4 /dev/md0

Swap

mkswap /dev/md1 swapon /dev/md1

9. Csatolási pontok megadása

Mountold fel az új rendszered leendő root-ját a live rendszer /mnt-je alá:

mount /dev/md0 /mnt # ha van efi particiod mount --mkdir /dev/sda1 /mnt/boot

Tegyél ugyanúgy a többi lemezzel, ha szükségesek a telepítéshez. A swap-et nem kell mountolni.

10. Alaprendszer telepítés

Nagyjából 200 MB-nyi adatból 700 MB-nyi területfoglalással telepítheted az alaprendszert. Én a base-devel csomagokat is telepíteni szoktam, a későbbiek során biztos, hogy szükség lesz ezekre, felesleges kihagyni. Régebben nem volt rá szükség, mostanában viszont még meg kell adni az mdadm és a linux csomagot is. Az mdadm a base csomag része, de nem települ. A linux csomag helyett választhatod még a linux-lts-t is.

Nagyon kevés időt vesz igénybe a művelet – persze függ az adott környezettől (hardware), de szerintem ne menj el kávézni.

pacstrap /mnt base base-devel mdadm linux linux-firmware mc 

11. Fstab beállítása

Ez már a swap-et is rögzíti. Érdemes a kimenetet megnézni úgy, hogy nem irányítod fájlba. A -U kapcsoló UUID azonosítókat ír forrásként az fstab fájlba, egyébként blokk eszköz elérési útvonalakt (pl. /dev/md0 vagy /dev/sda1).

genfstab -U /mnt >> /mnt/etc/fstab

És amit nagyon érdemes meglépned: ez eddigi beállításaidat (ha volt ilyen) másold át az /mnt alá a megfelelő helyre

12. arch-chroot

Innentől kezdve már nem a live területén kell dolgoznod, így környezetet kell váltanod – minden, amit csinálsz, az az új rendszeredre lesz befolyással. Váltás után mc-t is telepíts.
Váltás előtt viszont érdemes átmásolnod a live rendszer /etc/systemd/network tartalmát, ha statikus ip címet állítottál be, és a telepített rendszer esetében is ugyanazt akarod használni.

#arch-chroot /mnt sh-4.3# #nem lesz mc az uj kornyezetben igy erdemes eloszor azt telepiteni #pacman -S mc

13. Raid beállítások érvényesítése

Ha a telepítés első részében készítettél raid tömböket, akkor ne felejtsd el a raid beállításokat érvényesíteni, vagy egyáltalán nem fogsz tudni bootolni. Fontos, hogy a /mnt alá mountolt leendő új rendszeren csináld ezt meg, ne a live területén.

Először is: updatel-ni kell az /etc/mdadm.conf-ot

mdadm --detail --scan >> /etc/mdadm.conf

Ezután add az mdadm_udev -et a mkinitcpio HOOK részéhez, az /etc/mkinitcpio.conf-ban:

#mcedit /etc/mkinitcpio.conf HOOKS="base udev autodetect block mdadm_udev filesystems usbinput fsck"

Majd generáld le újra az initramfs image-t:

mkinitcpio -p linux

14. Tükör szerver választása

Konkrétan újra el kell játszanod azt, amit a live rendszer beállítása esetében is. Ehhez viszont fel kell telepítened a szükséges csomagokat is:

pacman -S reflector rsync reflector -c 'Hungary' -a 12 - -sort rate - -save etc/pacman.d/mirrorlist pacman -Syy

15. Idő, időzóna beállítása

Az operációs rendszerben az időt (órát) négy rész határozza meg: az időérték, legyen az helyi idő vagy UTC, vagy valami más, időzóna és adott esetben a nyári időszámítás (DST). Két óra van jelen a rendszereken: egy hardver óra és egy rendszer óra.

A legtöbb operációs rendszertől elvárt viselkedés:

• indításkor állítsa be a rendszer óráját a hardver órájából,
• tartsa a rendszeróra pontos idejét
• leállításkor állítsa be a hardver óráját a rendszer órájából

A hardver óra (más néven a valós idejű óra (RTC) vagy CMOS óra) az év, hónap, nap, óra, perc és másodperc értékeket tárolja. Csak 2016-os vagy később UEFI firmware képes tárolni az időzónát, és hogy a DST-t használják-e.

A hardver óra által használt szabványt (CMOS óra, BIOS idő) az operációs rendszer határozza meg. Alapértelmezés szerint a Windows helyi időt, a macOS UTC-t használ, az UNIX-szerű rendszerek pedig változatosan. Az UTC szabványt használó operációs rendszer általában a hardver óráját UTC-nek tekinti, és kiigazítja azt, hogy az OS-t az indításkor az időzóna szerint állítsa be.

Időzóna beállítása:

ln -sf /usr/share/zoneinfo/Europe/Budapest /etc/localtime

Hardveróra

A hardver óra kiolvasható:

hwclock --show

A hardver óra beállítható a rendszeróráról, ami generálja az /etc/adjtime fájlt is (vagy módosítja). Ez a fájl a hwclock által az egyik meghívástól a másikig használt információkat tartalmazza.

hwclock --systohc

Rendszeróra

A rendszeróra (más néven a szoftveres óra) nyomon követi az időt, időzónát és adott esetben a DST-t. A Linux kernel az UTC 1970. január 1. éjfél óta eltelt másodpercek számaként számítja ki. A rendszeróra kezdeti értékét a hardver órájából számoljuk, az /etc/adjtime tartalmától függően. Az indítás befejezése után a rendszer órája függetlenül fut a hardver órájától. A Linux kernel az időzítő megszakításainak számlálásával követi a rendszer óráját.

Az aktuális rendszeróra (helyi időben és UTC-ben egyaránt) és az RTC (hardver óra) lekérdezhető és beállítható a timedatectl paranccsal.

# lekerdezni #timedatectl # beallitani #timedatectl set-time "yyyy-MM-dd hh:mm:ss" 

Ezután még érdemes a pontos időt aktualizálni és rendszeresen frissíteni.
Először is a rendszeróra frissítése, beállítása:

#timedatectl set-ntp true #timedatectl status

Vagy ugyanez ntp-vel:

#pacman -S ntp  #ntpdate 0.hu.pool.ntp.org

Beállíthatod a systemd-timesyncd programot az állandó pontos idő érdekében:

#mcedit /etc/systemd/timesyncd.conf NTP=0.hu.pool.ntp.org #A FallbackNTP elol torold a komment jelet #systemctl enable systemd-timesyncd

16. Editor, hosztnév, locales, vconsole beállítása

Editor beállításához hozz létre egy editor.sh fájlt az /etc/profile.d könyvtárban:

#mcedit /etc/profile.d/editor.sh EDITOR="/usr/bin/mcedit" export EDITOR export VISUAL=$EDITOR 

Hosztnév beállítása:

echo "hosztnév" > /etc/hostname

Locale beállítása:

A locale lista az /etc/locale.gen fájlban található. editáld úgy, hogy amelyikre szükséged van, azt élesíted (a komment jeled törlöd a sor elejéről). Javaslom az angol és a magyar locale-t: en_US.UTF-8 UTF-8, hu_HU.UTF-8 UTF-8.

Ezután generáld le:

locale-gen

A locale beállításokat mentsd is el az /etc/locale.conf fájlban:

echo "LANG=hu_HU.UTF-8" >> /etc/locale.conf

Az /etc/vconsole.conf tartalma:

#mcedit /etc/vconsole.conf KEYMAP=hu FONT= FONT_MAP=

17. RAM disk készítése

Szerkeszd az /etc/mkinitcpio.conf fájlt, ha a kernel modulokat szeretnéd kezelni, majd generálj egy RAM diszket:

mkinitcpio -p linux

18. Root jelszó beállítása, új user felvétele, sudo telepítése

root jelszavának módosítása a szoksáso passwd programmal oldható meg.

Új user telepítése:

useradd -m -U -G wheel username passwd username

Ezután editáld az /etc/sudoers fájlt, a %wheel bejegyzés előtt töröld a komment jelet. Ezzel a wheel csoport tagjai használhatják a sudo utasítást, de csak a jelszavuk megadása után.

19. Rendszerbetöltő telepítése (UEFI és MBR)

Magam részéről a grub-ot ajánlom. Ha van raid tömböd, akkor ne arra telepítsd, hanem a fizikai eszközre – az összes olyan eszközre, amely része a bootnak, jelen esetben /dev/sda és /dev/sdb. Ha UEFI rendszered van, akkor szükséged lesz az efibootmgr csomagra is.

UEFI:
Grub mellett szükséged van az efibootmgr csomagra is. A GRUB a rendszerbetöltő, míg az efibootmgr-t a GRUB telepítőszkriptje használja rendszerindítási bejegyzések NVRAM-ba írásához.

Feltételezem azt, hogy a korábban elkészített efi particíót mountoltad a /boot könyvtárba. A /boot könyvtárban lesz egy EFI könyvtár, ezen belül pedig pl. általad kitalált nevű (ez valójában ID) könyvtár (nem most, hanem a folyamat végén). Tehát választanod kell egy ún. rendszerbetöltő azonosítót, pl. ArchLinux néven (de bármi lehet, akár alma is). Az /boot/EFI könyvtárban létrejön egy ilyen nevű könyvtár az EFI bináris tárolására, és ez a név fog megjelenni az UEFI rendszerindító menüjében a GRUB rendszerindító bejegyzés azonosítására.

pacman -S grub efibootmgr grub-install --target=x86_64-efi --efi-directory=boot --bootloader-id=ArchLinux grub-mkconfig -o /boot/grub/grub.cfg

Ezek után a /boot/grub könyvtár is létrejön,

MBR:
Némileg egyszerűbb a dolgod: a szokásos grub telepítésre és az mkconfig futtatásra van szükséged.

pacman -S grub grub-install --target=i386-pc --recheck --debug /dev/sda /dev/sdb grub-mkconfig -o /boot/grub/grub.cfg 

Ha esetleg a grub-mkconfig futása során hibaüezenetek kapsz, tele ‘null’ jelzésekkel (most nem tudom repordukálni a pontos szöveget), akkor esetleg kifelejtetted az mkinitcpio.conf fájlban a HOOK változóban az mdadm_udev bejegyzést. Ha tényleg így van, akkor pótold (12-es pont alapján), majd újra futtasd az mkinitcpio -p linux utasítást, és ezután próbáld meg újra a grub-mkconfig-ot.

Az is elépzelhető, hogy a szoftveres raid létrehozása során csak egy lemezt tettél be (esetleg máris szétesett a raid tömböd, esetleg még nem szinkronizálódott), a lényeg az, hogy degraded vagy fél állapotban vagy. Ebben az esetben nem kell aggódnod, a fent említett hiba üzenet csak alkalmi.

20. Egyebek telepítése

Kikapcsolhatod a speakert:

rmmod pcspkr 

Telepítések:

pacman -S mc ntp #ha meg nem tetted meg pacman -S cronie dnsutils yaourt openssh pacman -S bash-completion screen wget curl pacman -S atop pwgen rsync zip unzip git

Ha használni is akarod az ssh-t, cron-t, akkor engedélyezned kellőket. Chroot környezetben a cront nem tudod elindítani, de elég csak engedélyezned (enable), reboot után már futni is fog.

systemctl enable sshd systemctl enable cronie

21. Újraindítás

Ha végeztél mindennel, lépj ki a chroot környezetből:

exit # vagy CTRL+D

Csatold le a felcsatolt particiókat:

umount /mnt

Végül reboot, de csatold le a médiaeszközt, nehogy arról indulj el megint.

Sikeres bootolás után ellenőrizd le a hálózatot, pingelj ip címet és hoszt nevet külön-külön. Elképzelhető, hogy a névfeloldás nem fog működni, ezért szerkeszd az /etc/resolv.conf-ot:

nameserver 8.8.8.8 nameserver 8.8.4.4

Tesztelj ping segítségével (hoszt nevet). Lehet, hogy kell várnod pár másodpercet.

Így tulajdonképpen a kérdés az alábbira egyszerűsödik: a levél tartalma módosult-e, és a levél digitálisan titkosított aláírása megegyezik-e a küldő fél DNS rekordjaiban található információkkal? Ha sorrendben nem, igen a válasz akkor a levél megbízható. Most ezt a funkcionalitást próbáljuk meg a saját levelezőszerverünkhöz hozzáadni.

DKIM tudnivalók

A DKIM (Domain Key Identified Mail) megoldást prominens szolgáltatók, mint pl. a Yahoo, Gmail, AOL, Fastmail közösen fejlesztették ki. Csak ismételni tudom magam: a DKIM segítségével a fogadó oldal egyrészt láthatja, hogy módosult-e a levél a két szerver között, illetve láthatja, hogy az aláírás tényleg a mi kulcsunkkal történt-e? Ez úgy történhet meg, hogy a kimenő levelek fejlécéhez az aláíró program egy DKIM-Signature  fejlécet ad hozzá, amely egy “tag=value” típusú, vesszővel elválasztott lista elemeit tárolja.  Ez csak a levelező szerverek számára látható, a mindennapi levelezésben egyáltalán nem zavaró. Az aláíráshoz használatos privát kulcsunk publikus részét az adott domain (selector) TXT típusú DNS rekordjában helyezzük el.  A DNS rekord neve (aldomain) kötött.

A lista elemeinek tag neve gyakran rövid, egy-két betűs szó. Legismertebbek:

• v= verziószám (statikus 1)
• a= aláírás algortimusa
• c= canonizálási algortimus a header és body tartalomra
• q= az alapértelmezett publikus kulcs lekérdezési eljárás (pl. dns/txt)
• b= a tartalom elektornikus aláírása, amely az email header és body-ra vonatkozik
• bh= egy body hash
• d= az aláíró domain
• s= a selector
• l=a body canonilizált részének hossza
• t= aláírási időbélyeg
• x= lejárati idő
• h= az aláírásba bekerült fejlécek listája

Egy minta DKIM fejléc:

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane;      c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938;      h=from:to:subject:date:keywords:keywords;      bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;      b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ               VoG4ZHRNiYzR

A selector kérdésere vissza kell térnünk. Ahhoz, hogy a fogadó fél a publikus kulcsunkat megszerezhesse, azt kihelyezzük egy TXT típusú dns rekordba. A DNS rekord már önmagában is egy elfogadható eljárás, hiszen a saját domainünk DNS rekordjait – elméletileg – csak mi tudjuk kezelni. A kérdés az, hogy vajon melyik DNS rekordban rejtettük el az adatokat? Ezt megadhatjuk, méghozzá a tag-ek segítségével.

A DNS rekord nevét az alábbi adja meg: selector._domainkey.domain, vagy ha tag-ekkel írjuk le s._domainkey.d . A fenti példa adataival behelyettesítve ezt kapjuk: brisbane._domainkey.example.net

Tehát a fogadó szerver fogja magát és lekéri a brisbane._domainkey.example.net TXT típusú rekordját, amelyben megtalál a hitelesítéshez minden szükséges információt.

Nézzünk egy példa TXT rekordot:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDGJY5QnshY9TYF+IL2wU2kBydf971bpGhr9uCNp27Hs9NuxB0G1WOGRFe7mCT+X+6FSc8t9dvhJVlTWuVy6CjyirJ6EiVHZx3ZbNXI067+BV/bktRN5cuCb+NrTF0B1dpZ6p8EIURoJkdtB Yw5pUeZ2ks3y9JWxDM3l9Cc73fanwIDAQAB

Láthatod, hogy itt is van néhány paraméter, a legfontosabb a p=, ez tartalmazza a publikus kulcsot.

Telepítés, beállítás

A postfix telepítéséről most nem beszélek, feltételezem, hogy már van egy jól működő példányod.

apt-get install opendkim opendkim-tools

Az opendkim egy önállón futó démon program, ne lepődj meg, ha látod a folyamat listában. Fontos, hogy betoljuk magunkat az /etc/default/opendkim fájlba, és módosítsuk a SOCKET változó értékét. Egyelőre használjunk TCP-t, így adjuk meg: SOCKET=”inet:8891@localhost”. Tehát az opendkim csak a localhost 8891-es portján figyeljen a kérésekre. Ha socket-et szeretnél hazsnálni (és miért ne akarnál), valószínűleg célszerű lesz a postfix-ot az opendkim csoporthoz adni.

A részletes beállítási lehetőségeket az /etc/opendkim.conf fájlban találod. Máris a multi domaines környezet fogod beállítani (hogy ne kelljen kétszer fáradnod). Egy láma szintű konfiguráció:

# Always oversign From (sign using actual From and a null From to prevent # malicious signatures header fields (From and/or others) between the signer # and the verifier.  From is oversigned by default in the Debian pacakge # because it is often the identity key used by reputation systems and thus # somewhat security sensitive. OversignHeaders         From # List domains to use for RFC 6541 DKIM Authorized Third-Party Signatures # (ATPS) (experimental) #ADSPDiscard no #ATPSDomains            example.com Canonicalization        relaxed/relaxed Mode                    sv SubDomains              yes Syslog                  yes LogWhy                  yes UMask                   022 UserID                  opendkim:opendkim KeyTable                /etc/opendkim/KeyTable SigningTable            /etc/opendkim/SigningTable ExternalIgnoreList      /etc/opendkim/TrustedHosts InternalHosts           /etc/opendkim/TrustedHosts Socket                  inet:8891@localhost Selector                mail DNSTimeout              5 SignatureAlgorithm      rsa-sha256

Ebből csak az a fontos egyelőre, hogy a kulcsok, aláírások, egyebek az /etc/opendkim könyvtárban vannak (ne lepődj meg, a fájlnevek kisnagybetúsek). Ez a könyvtár egyébként nem létezik, Neked kell létrehoznod, a fájlokkal együtt:

mkdir -p /etc/opendkim/keys touch /etc/opendkim/KeyTable touch /etc/opendkim/SigningTable touch /etc/opendkim/TrustedHosts 

Beszéljünk egy kicsit a fájlok szerepeiről:

• KeyTable, amely domainenként a privát kulcsok adatait tartalmazza
• SigningTable, amelyben összepárosítjuk a küldő domaint a DNS rekorddal
• TrustedHosts, amely IP címeket vagy host neveket tárol

KeyTable

A KeyTable formátuma meglehetősen egyszerű: ez egy multi mezős sorokat tároló fájl, amelyben a mezők kettősponttal vannak elválasztva, a kulcs-érték párok viszont szóközzel. A rekord struktúra sem nehéz.

rekord_alneve domain:selector:privat_kulcs_abszolut_eleresi_utja

tehát azt akarják mondani, hogy adj egy álnevet, aliast midne egyes rekordnak, amellyel azonosíthatod a a benne lévő beállítási készeletet (domain, selector, kulcs). Én magam azt csinálom, hogy a TXT rekord nevét adom meg álnévként, így biztos nem kavarodok bele, méghozzá az alábbi módszertan szerint:

dns_rekord_neve

domain

:

selector

:/etc/opendkim/keys/

domain

/

selector

.private

Az előző példánál maradva így nézne ki:

brisbane._domainkey.example.net example.nte:brisbane:/etc/opendkim/keys/example.net/brisbane.private

Így aztán 1000 rekordot is lehet, könnyű lesz keresgélnde – és hivatkoznod – az adatokra.

SigningTable

A SigningTable segít összepárosítani a küldő felet a saját kulcsával (azaz a KeyTable megfelelő sorával). Ebben kétmezős sorok vannak, a mezők whitespace-el vannak elválasztva. Bal oldalon a küldő fél, jobb oldalon a KeyTable kompetens sorának álneve.  A küldő fél lehet teljes e-mail cím, vagy domain, illetve e-mail címben használhatunk csillagot is a kukac előtt.

Példa:

president@example.com	brisbane._domainkey.example.net example.com  mail._domainkey.example.net *@example.net selector._domainkey.example.net

 TrustedHosts

Ez tulajdonképpen ip címeket és hostokat tárol, amit több célra is felhasználunk. Az ExternalIgnoreList arra használja, hogy melyek azok a külső szerverek, amelyek további autentikáció nélkül küldhetnek levelet az opendkim által kezelt domainek nevében. Az InternalHosts adja meg azokat, akiket nem kell ellenőrizni, és aláírhatóak.

Kulcsok generálása

Lépjünk be az /etc/domainkey/keys könyvtárba, és készítsünk egy könyvtárt az adott domainek, majd ide is lépjünk be:

cd /etc/opendkim/keys mkdir /etc/opendkim/keys/example.net cd /etc/opendkim/keys/example.net

A kulcsgeneráláshoz meg kell adnunk a domaint és a selectort:

opendkim-genkey -s brisbane -d example.net

Ez két fájlt fog létrehozni:

• brisbane.private, amely a privát kulcsot
• brisbane.txt, amely a publikus kulcsot tartalmazza

Cseréld le a a privát kulcs tulajdonosát:

chown opendkim:opendkim brisbane.private

A publikus kulcsot add a DNS rekordhoz. A brisbane.txt erre elő van készítve, bár az idézőjelekre figyelj oda: a teljes rekord legyen egy idézőjelben.

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDGJY5QnshY9TYF+IL2wU2kBydf971bpGhr9uCNp27Hs9NuxB0G1WOGRFe7mCT+X+6FSc8t9dvhJVlTWuVy6CjyirJ6EiVHZx3ZbNXI067+BV/bktRN5cuCb+NrTF0B1dpZ6p8EIURoJkdtB Yw5pUeZ2ks3y9JWxDM3l9Cc73fanwIDAQAB

Postfix beállítása

Ahhoz, hogy a kimenő levelek tényleg aláírásra is kerüljenek, jelezni kell a postfix-nak, hogy tegye is meg. Ezt az /etc/postfix/main.cf fájlban pár sorral meg is oldjuk. Adjuk hozzá:

milter_default_action = accept milter_protocol = 6 

smtpd_milters = inet:localhost:8891 non_smtpd_milters = inet:localhost:8891

A vastagon kiemelt sorok a fontosak. Az opendkim-et és a postfix-ot is érdemes a beállítások után újrarúgni.

service opendkim restart service postfix restart

És máris tesztelhetsz.

Mivel a csak kimenő smtp létjogosultsága általában a szolgáltatás sebességnövelése, az autentikáció nem relációs adatbázisból történik  (pl. mysql), és természetesen nincs vírus-, spam-, és RBL szűrés. Először alapozunk, azután elvégezzük a telepítéseket és beállításokat, majd tesztelünk.

Alapozás

Egy bejövő levelezésre is alkalmas környezet telepítéséről (és ezen belül a postfix-ről) itt irtam, ezért az alapokról már nem írok. A postfix telepítése/beállítása lényegében majdnem ugyanazok, az igazi különbség az, hogy nincs bejövő e-mail kezelés, illetve az autentikáció no-sql-sasl típusú. Ráadásul – hogy ne legyen túl sok réteg – a sasl által kínált sasldb metódust választjuk, ami azt jelenti, hogy nem fordul pl. a PAM-hez, hanem egy általa kezelt adatbázis fájlból veszi az autentikációs adatokat.

De mi is az a SASL?

A SASL egy autentikációs réteg vagy keretrendszer, amelynek segítségével SASL-t implementásló alkalmazások tudnak SASL-t implementáló alkalmazásokkal hitelesíttetni magukat. A SASL jó pár mechanizmust és adattárolási forrást ismer. Ahogy korábban említettem, az adattárolási formák közül a sasldb típusút választjuk, amit hivatalosan talán úgy is hívnak, hogy libsasl authentication database.

A postfix önmagában kétféle SASL implementációt ismer: dovecot és cyrus. A dovecot most nem lényeges, a cyrus pedig a legjobb olyan megoldás, amely a postfix átírása nélkül lehetséges legtöbb/legjobb funkcionalítást adja. Amit még tudnod kell: a cyrus sasl által egy különálló hitelesítési démon fut a háttérben, amit saslauthd-nek hívnak.

Telepítés, beállítások

Először is telepítsük a legfontosabb programokat:

Ubuntu:

#Ubuntu apt-get install postfix postfix-pcre pfqueue libsasl2-modules sasl2-bin libsasl2-2 #Arch Linux pacman -S postfix cyrus-sasl sudo -H -u username yaourt -S pfqueue

A postfix mellett új elemként tűnhet fel:

• pfqueue, amely egy queue nézegető program, hibakereséshez kiváló
• libsasl2, amellyel az smtp autentikációt fogjuk kezelni
• libsasl-modules, amely a sasldb kezelésének ismeretét hordozza magában
• sasl2-bin, amely a parancssoros programokat adja, pl. az adatbázis fájl kezeléséhez

A postfix beállításait két fájlban találjuk: /etc/postfix/main.cf és /etc/postfix/master.cf. A main.cf tartalmazza a postfix beállításait, míg a master.cf a postfix belső folyamatainak beállításait.

Először a main.cf-ben állítsuk be a legfontosabb paramétereket: hálózat, továbbítások, adatforrások (ezeket később vázoljuk), stmp szerver autentikácó, smtp szerver ellenőrzési paraméterek:

# NETWORK myhostname = smtp.szerverem.hu myorigin = /etc/mailname mydestination = smtp.szerverem.hu, localhost relayhost = mynetworks = 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 inet_interfaces = all inet_protocols = ipv4 # MAPS mailbox_size_limit = 0 recipient_delimiter = + relay_recipient_maps = local_transport = error local_recipient_maps = transport_maps = hash:/etc/postfix/transport alias_maps = hash:/etc/aliases alias_database = hash:/etc/aliases # TUNING default_destination_concurrency_limit=100 default_destination_recipient_limit=100 default_process_limit=300 smtp_mx_session_limit=200 smtpd_client_connection_count_limit=200 smtp_destination_concurrency_limit=100 maximal_backoff_time = 1000s minimal_backoff_time = 300s # SMTP AUTH RULES smtpd_helo_required = yes smtpd_sender_restrictions =  permit_mynetworks,  permit_sasl_authenticated,  reject_unknown_sender_domain smtpd_recipient_restrictions =  reject_non_fqdn_sender,  reject_non_fqdn_recipient,  permit_mynetworks,  permit_sasl_authenticated,  reject_unauth_destination smtpd_relay_restrictions =   permit_mynetworks,  permit_sasl_authenticated,   defer_unauth_destination #STMPD AUTH SETTINGS smtpd_sasl_type = cyrus smtpd_sasl_path = smtpd smtpd_sasl_auth_enable = yes smtpd_sasl_local_domain = szerverem.hu smtpd_sasl_security_options = noanonymous broken_sasl_auth_clients = yes disable_vrfy_command = yes 

A permit_mynetworks akár el is hagyható, legalábbis egy hanyagabb hálózatban veszélyes is lehet. Amire figyelned érdemes, az az smtpd_sasl_local_domain paraméter, illetve annak értéke. Később meglátod, hogy miért.

Továbbiakban a postfix folyamatait állítjuk be:

smtp      inet  n       -       -       -       -       smtpd 26      inet  n       -       -       -       -       smtpd submission inet n       -       n       -       -       smtpd   -o smtpd_sasl_auth_enable=yes   -o smtpd_sasl_security_options=noanonymous   -o smtpd_sasl_local_domain=example.tld   -o header_checks=   -o body_checks=   -o smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_destination   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject   -o smtpd_sasl_tls_security_options=noanonymous smtps     inet  n       -       -       -       -       smtpd   -o smtpd_tls_wrappermode=yes   -o smtpd_sasl_auth_enable=yes   -o smtpd_relay_restrictions=permit_sasl_authenticated,reject   -o smtpd_client_restrictions=permit_sasl_authenticated,reject_unauth_destination   -o smtpd_sasl_security_options=noanonymous,noplaintext   -o smtpd_sasl_tls_security_options=noanonymous   -o smtpd_sasl_local_domain=example.tld   -o header_checks=   -o body_checks= 

Figyeld meg, hogy itt is megjelenik az smtpd_sasl_local_domain paraméter.

Most pedig állítsuk be az smtpd hitelesítéshez szükséges sasl paramétereket. Az /etc/postfix mappában hozzunk létre egy könyvtárt: sasl.

mkdir /etc/postfix/sasl

A sasl könyvtár fogja tartalmazni az smtp authentikáció paramétereit. Itt hozzunk létre egy smtpd.conf fájlt:

touch /etc/postfix/sasl/smtpd.conf

Az smtpd.conf fájl tartalma:

pwcheck_method: auxprop auxprop_plugin: sasldb mech_list: PLAIN LOGIN CRAM-MD5 DIGEST-MD5 allow_plaintext: true 

Hozzuk létre a sasldb adatbázist, amely egyébként alapértelmezetten az /etc/sasldb fájl. Az adatbázis kezelését parancssoros programokat teszik lehetővé. A legalapvetőbb feladatok:

• új user felvétele
• user módosítása
• user törlése

Állítsuk be a sasl adatbázist:

saslpasswd2 -c -u

szerverem.hu

 $user chown postfix:postfix /etc/sasldb2 chmod 660 /etc/sasldb2

Kapcsolók jelentése:

• -c kapcsoló: create,
• -u kapcsolo: realm (domain, tartomány)

A -u kapcsoló a lényeg. Korábban már említettem az smtpd_sasl_local_domain postfix paramétert: annak értéke kerüljön ide. Mindig. Ha az smtpd_sasl_local_domain értéke humbug.hu, akkor az userek kezelésénél a -u humbug.hu kapcsolót kell használnod. Miért fontos? Mert az adatbázis fájlban több alkalmazás adatait tudod tárolni, és az első elválasztó/csoportosító megoldás a realm megadása.

A saslpasswd2 bekéri a jelszót kétszer, és nagyjából ennyi az összes feladatod.

Tulajdonképpen el is készültél, a programok telepítve, beállítva, az első usered rögzítve. Indulás előtt még meg kell tenned azt, hogy:

Ubuntun: az /etc/default/saslauthd fájlban a START=no értékét állítsd yes-re állítani, illetve a MECHANISMS értéke sasldb legyen (enélkül nem fog menni, mert az alapértelemezett a pam).

Arch Linuxon: az /etc/conf.d/saslauthd fájlban a “-a pam” értéket állítsd át:

SASLAUTHD_OPTS="-a sasldb -n 5 -c "

Ezután indítsd el a saslauthd démont:

#Ubuntu service saslauthd start #Arch Linux systemctl enable saslauthd systemctl start saslauthd

És itt jön az igazi cheat: ha master.cf-ben az smtp és/vagy a 26-os port chroot oszlopa “-” vagy “y” értékű, akkor az /etc/sasldb2 fájlt át kell másolnod a /var/spool/postfix/etc mappába, mert a postfix chroot-ban fut, tehát nem lát ki az igazi /etc/sasldb fájlra. Neki ekkor a /var/spool/postfix a root, ezért az itt található etc mappába kell átmásolnod a sasldb fájlt.

A másik megoldás az lehet, ha a chroot oszlop értékét “n”-re állítod, és akkor nem kell ezzel foglalkoznod:

smtp      inet  n       -

n

       -       -       smtpd 26      inet  n       -

n

       -       -       smtpd

Én ezt választottam.

Ezután elindíthatod a levelezőszervert is:

#Ubuntu service start postfix #Arch Linux systemctl enable postfix systemctl start postfix

Smtp teszt

Smtp kapcsolatot (akár autentikációs, akár küldést) a swaks programmal tudsz a legjobban tesztelni.

Autentikációs teszt:

swaks --server szerverem.hu --port 26 --auth PLAIN --auth-user smtpUsername --auth-password smtpuserPassworrd --quit-after AUTH

Teszt levélküldés:

swaks --server szerverem.hu --port 26 --auth PLAIN --auth-user smtpuserName --auth-password smtpuserPassword --to to@toDomain.hu --from from@fromDomain.hu