A WooCommerce hatékony marketingeszközei közé tartozik a kuponkódok használata. Ugyan beakciózhatunk termékeket a webshopunkban globális paraméterek megadásával is, ám a kuponokkal sokkal kifinomultabb módon osztogathatjuk a kedvezményeket, legyen szó ingyenes szállításról vagy a végösszeg csökkentéséről. A legtöbb esetben a felhasználó azonban a kupont csak a Kosár oldalon tudja megadni, pedig hatékony vásárlásösztönző lehet, ha az egyes termékek böngészése közben már rögtön lehetőséget biztosítunk a kuponkódok megadására.

Az alábbi kódrészlet segítségével a termékoldalakon is megjeleníthetjük a kuponkód megadására szolgáló mezőt, amely aztán természetesen a teljes vásárlásra is érvényes lesz (a kupon beállításainál megadott feltételeknek megfelelően) a vásárlási munkamenet egésze alatt. (Eltávolítani pedig alapesetben majd csak a Kosár oldalon tudjuk.)

Megjegyzés: Az egyéni PHP-kódok megadásához a Code Snippets vagy a WPCode használatát javasoljuk.

Kuponkód mezőjének megjelenítése a WooCommerce-termékoldalakon

// Add a text input field inside the add to cart form
add_action('woocommerce_single_product_summary','add_custom_text_field_single_product', 2 );
function add_custom_text_field_single_product(){
    global $product;

    if( $product->is_type('variable') ){
        add_action('woocommerce_before_single_variation','custom_product_text_input_field', 30 );
    } else {
        add_action('woocommerce_before_add_to_cart_button','custom_product_text_input_field', 30 );
    }
}

function custom_product_text_input_field(){
    echo '<div class="hidden-field">
    <p class="form-row product-coupon form-row-wide" id="product-coupon_field" data-priority="">
        <label for="product-coupon" class="">' . __("Rendelkezik kuponkóddal?") . '</label>
        <span class="woocommerce-input-wrapper">
            <input type="text" class="input-text " name="product-coupon" id="product-coupon" placeholder="'.__("Kuponkód").'" value="">
        </span>
    </p></div>';
}

// Apply the coupon code from product custom text imput field
add_filter('woocommerce_add_cart_item_data', 'coupon_code_product_add_to_cart', 20, 3);
function coupon_code_product_add_to_cart($cart_item_data, $product_id, $variation_id) {
    if (isset($_POST['product-coupon']) && ! empty($_POST['product-coupon'])) {
        WC()->cart->apply_coupon( sanitize_title( $_POST['product-coupon'] ) );
    }
    return $cart_item_data;
}

Akár a webhelyek fejlesztése, akár éles üzem során előfordulhat, hogy szükségessé válik a WooCommerce-ben lévő termékek tömeges, alapos törlése.

Sajnos a WordPress az ilyen feladatok terén nem túlságosan előzékeny, és az adminfelületen csak nagyon lassan és erőforrásigényes módon tudnánk ezt a feladatot elvégezni, ám ha rendelkezünk phpmyAdmin-hozzáféréssel vagy SSH-eléréssel a szerverhez, akkor pillanatok alatt lenullázhatjuk a webshop tartalmát, hogy tiszta lappal indulhasson a termékfeltöltés.

A műveletet kétféleképpen végezhetjük el, a termékkategóriák legyalulásával vagy a termékkategóriák megőrzése mellett. Lássuk hát az ehhez szükséges parancsok sorát!

FONTOS! Az alábbi parancsok a WordPress alapértelmezett táblaneveit feltételezik. Egyéni előtag használata esetén módosítani kell a parancsokat.

Az adatbázis minden módosítása előtt javasolt biztonsági mentést készíteni az adatokról!

WooCommerce-termékek tömeges törlése a termékkategóriák megőrzésével

Amennyiben csak a termékeket szeretnénk kigyomlálni az adatbázisunkból, a termékkategóriákat (az azonosítóikkal együtt) viszont megtartanánk, akkor az alábbi parancsokat kell kiadnunk:

Attribútumok törlése

DELETE FROM wp_terms WHERE term_id IN (SELECT term_id FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%'); DELETE FROM wp_term_taxonomy WHERE taxonomy LIKE 'pa_%'; DELETE FROM wp_term_relationships WHERE term_taxonomy_id not IN (SELECT term_taxonomy_id FROM wp_term_taxonomy);

Termékek törlése

DELETE FROM wp_term_relationships WHERE object_id IN (SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation')); DELETE FROM wp_postmeta WHERE post_id IN (SELECT ID FROM wp_posts WHERE post_type IN ('product','product_variation')); DELETE FROM wp_posts WHERE post_type IN ('product','product_variation');

Elárvult metaadatok törlése

DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts wp ON wp.ID = pm.post_id WHERE wp.ID IS NULL;

Megjegyzés: Multisite környezetben a fenti táblaneveket a környezetnek megfelelően módosítani kell, és hozzájuk kell fűzni a megfelelő számot.

WooCommerce-termékek tömeges törlése a termékkategóriák törlésével

Ha a termékkategóriákat is törölni szeretnénk, és mindent nulláról kezdenénk, az alábbi parancsokra lesz szükségünk:

DELETE relations.*, taxes.*, terms.*
FROM wp_term_relationships AS relations
INNER JOIN wp_term_taxonomy AS taxes
ON relations.term_taxonomy_id=taxes.term_taxonomy_id
INNER JOIN wp_terms AS terms
ON taxes.term_id=terms.term_id
WHERE object_id IN (SELECT ID FROM wp_posts WHERE post_type='product');

DELETE FROM wp_postmeta WHERE post_id IN (SELECT ID FROM wp_posts WHERE post_type = 'product');
DELETE FROM wp_posts WHERE post_type = 'product';

Megjegyzés: Multisite környezetben a fenti táblaneveket a környezetnek megfelelően módosítani kell, és hozzájuk kell fűzni a megfelelő számot.

Az utóbbi időben számos optikai címükön cserélte le a DIGI a régebbi, Wi-Fi-kapcsolatra nem alkalmas modemeit újabb ONT-eszközökre, amelyek immáron Wi-Fi 6-kapcsolatot is képesek biztosítani, ráadásul több antennával is el vannak látva, így önmagukban, külön router használata nélkül is használhatók már a vezeték nélküli internet biztosításához.

Az eszköz átállítása ROUTER üzemmódba

Ahhoz, hogy az eszköz Wi-Fi routerként is funkcionáljon, elsőként ROUTER üzemmódba kell helyezni (ha ez a telepítésekor nem történt meg automatikusan). A beállítás az Ügyfélkapu (önkiszolgáló felület) segítségével adható meg. A beállítás életbe léptetéséhez akár 15 perc is szükséges lehet, ezért mindenképpen várjuk meg, amíg a felületen már azt látjuk, hogy befejeződött a módosítások alkalmazása. Mivel a változtatás ideje alatt a helyi internetünk nem lesz elérhető, ezért ehhez a módosításhoz mobilinternet használata javasolt. (De amúgy ha kivárjuk a 10-15 perces folyamatot, további internetkapcsolat használata nélkül is elvégezhetjük a módosítást.)

Az adminfelület megnyitása

A router adminfelületének eléréséhez az alapértelmezett IP-címet kell beírnunk a böngészőbe, ha már csatlakoztunk az általa biztosított Wi-Fi-hálózathoz vagy vezetékes kapcsolattal közvetlenül a routerhez kapcsolódunk: 192.168.1.1

A lehetséges felhasználónév és jelszó párosok a következők:

A fentiek közül valamelyiknek működnie kell. 3 sikertelen próbálkozás után az adminfelület 1 percre kitiltja a felhasználót, de utána folytatni lehet a próbálkozást.

A gyári számot és a Wi-Fi-kapcsolathoz szükséges SSID-t és jelszót a router hátulján található matricáról tudjuk leolvasni.

Amennyiben úgy tapasztaljuk, hogy az egyik pillanatról a másikra megszűnt a phpMyAdmin elérhetősége, pedig korábban minden rendben működött, érdemes első körben körülnézni az Apache error.log naplófájljában. (/var/log/apache2/error.log)

Ha abban az alábbihoz hasonló hibaüzenetet találunk, akkor a probléma okát az inkompatibilis alapértelmezett PHP-verzió okozza:

[Sat Jun 18 15:38:38.906793 2022] [proxy_fcgi:error] [pid 657600] [client X.X.X.X:63235] AH01071: Got error 'PHP message: PHP Warning: Unsupported declare 'strict_types' in /usr/share/php/PhpMyAdmin/MoTranslator/Loader.php on line 23\nPHP message: PHP Parse error: syntax error, unexpected '?' in /usr/share/php/PhpMyAdmin/MoTranslator/Loader.php on line 116\n'

Ennek megoldása elég egyszerű, ugyanis a phpMyAdmin rendelkezik egy saját Apache conf-fájllal, amelyet módosítva megadhatjuk, hogy melyik PHP-verzióval fusson. Ehhez mindössze módosítanunk kell az /etc/phpmyadmin/apache.conf tartalmát, és beszúrnunk a következőt:

<Directory /usr/share/phpmyadmin>
    <FilesMatch \.php$>
    SetHandler "proxy:unix:/var/run/php/php7.4-fpm.sock|fcgi://localhost/"
    </FilesMatch>
</Directory>

A fenti megoldással a PHP 7.4-es verzióját adjuk meg a phpMyAdmin futtatásához (jelenleg ezzel a verzióval biztosan működnie kell, ha ez volt a hiba oka).

Természetesen a módosítások életbe léptetéséhez újra kell indítanunk az Apache2-t. (/etc/init.d/apache2 restart)

A fail2ban egy nagyon hatékony és hasznos eszköz, amennyiben meg szeretnénk bizonyosodni arról, hogy próbálgatásos (brute-force) technikával nem lehet kitalálni a különböző szolgáltatások hitelesítő adatait.

Ám természetesen alkalmanként itt is előfordulhat, hogy jóhiszemű felhasználókat zár ki a rendszer, például azért, mert egy jelszóváltozásról későn kapta meg az értesítést a felhasználó, vagy egyszerűen csak túl sokszor vétett hibát egy jelszó beírásakor.

A jó hír az, hogy a tiltást pillanatok alatt feloldhatjuk, ha SSH-n keresztül bejelentkezünk a rendszerünkbe.

Ennek mikéntjére rögtön két módszert is bemutatunk!

Tiltás feloldása az iptables használatával

A legáltalánosabb és minden esetben működő megoldást az jelenti, ha az iptables használatával távolítjuk el az érintett felhasználót blokkoló tűzfalszabályt. Ehhez két parancsra lesz szükségünk. Az elsővel kilistázzuk az érvényben lévő  tűzfalszabályokat, a sorszámukkal egyetemben:

sudo iptables -n -L --line-numbers

A listában keressük ki az érintett szolgáltatásnak megfelelő láncot (például ssh esetén ez a f2b-sshd chain lesz), és jegyezzük fel, hogy az általunk keresett IP-cím sorának elején, a num oszlopban milyen szám található.

Ha megvan ez a két információ, kiadhatjuk a második parancsot:

sudo iptables -D <fail2ban-chain> <sorszám>

Ennek hatására eltávolítjuk a tűzfalból az érintett szabályt, és ezzel megszűnik az IP-cím blokkolása. A fenti példánál maradva a <fail2ban-chain> helyére a f2b-sshd érték kerül, a <sorszám> helyére pedig az IP-címet tartalmazó sor elején látható szám.

Tiltás feloldása a fail2ban-client használatával

A fail2ban saját eszközt is biztosít ahhoz, hogy kezelhessük a tiltott címek listáját, ennek használata azonban egy verziófrissítést követően kicsit megváltozott. Éppen ezért létezik egy parancsszintaxis a 0.8.8-as verzió előtti fail2ban-hoz, és egy másik szintaxis az ennél újabb verziókhoz. Elsőként azonban mindkét esetben érdemes megnézni a fail2ban által használt jailek nevét:

sudo fail2ban-client status

Ha megvan az általunk keresett szolgáltatás neve (pl. sshd) akkor a 0.8.8-asnál korábbi verziók esetén a következő parancsot kell kiadnunk:

sudo fail2ban-client get <jail_neve> actionunban <IP-cím>

A 0.8.8-as verziótól kezdődően a parancs az alábbi formátumot követi:

sudo fail2ban-client set <jail_neve> unbanip <IP-cím>

Tiltás feloldása a Plesk használatával

Van egy jó hírünk azoknak, akik beruháztak a Pleskre, ugyanis a webes adminfelületen, a Tools & Settings alatt elérhető egy IP Address Banning (Fail2Ban) menüpont, ahol a kényelmes felület előnyeit kihasználva is kezelhetik a tiltólistás IP-címeket, a jaileket, a kivételeket és a naplókat.

Miért éppen WordPress-webhelyet válasszak a céges oldalamhoz?

Manapság a WordPress az egyik legnépszerűbb és leginkább elterjedt tartalomkezelő rendszer (CMS), ami nem véletlen. Először is vegyük sorra az előnyeit:

• Nagyon egyszerű és szinte minden szolgáltatóval kompatibilis az üzembe helyezése
• Nem igényel semmilyen programozói vagy rendszergazdai tudást
• Könnyen kezelhető az adminisztrációs felülete
• Teljes körű felhasználókezelést és különálló szerepköröket biztosít
• Teljes mértékben le van fordítva magyar nyelvre (igaz, számos hiba csúszott a közösségi fordításba, de ettől még jól használható magyarul)
• Minden tekintetben követi az éppen aktuálisan elvárt és használt szabványokat
• Automatikusan frissíthető (a bővítményeivel együtt), így mindig naprakész (és biztonságos) verziót használhatunk
• Rengeteg sablon és bővítmény érhető el hozzá (számos közülük teljesen ingyenesen), így minden céges igény kielégíthető
• A megfelelő bővítmények birtokában ugyanolyan jól használható blogként, magazinként, céges webhelyként vagy webáruházként
• Kiemelkedően jól teljesít a keresőoptimalizálás (SEO) terén
• Egy jó sablon birtokában könnyedén igazítható a céges arculathoz
• Ráadásul teljesen ingyenes

Rendszerkövetelmények

• PHP 7.4-es vagy magasabb verzió
• MySQL 5.7-es vagy magasabb VAGY MariaDB 10.2-es vagy magasabb verzió
• HTTPS-támogatás

A céges WordPress-webhely üzembe helyezésének költségei

Ha eldöntöttük, hogy szeretnénk egy biztonságos és szabványos webhelyet magunknak, akkor már csak az alapvető körülményeket kell megteremtenünk a sikeres beüzemeléséhez.

Dönthetünk úgy, hogy saját szervert üzemeltetünk, amennyiben a webhelyen kívül más szolgáltatásokat is elérhetővé szeretnénk tenni. Ebben az esetben nagy segítségünkre lehet a virtuális szerverek (VPS) kiválasztását elősegítő útmutatónk. Magának a rendszernek a kialakításához pedig érdemes elolvasni a tökéletes Ubuntu 20.04 LTS szerver telepítésének útmutatóját.

A saját szerver fenntartásának természetesen magasabbak a költségei, de érdemes megnézni a konkrét csomagjánlatokat, hiszen már havi 5 ezer forintért lehet egy minden alapvető igényt kielégítő VPS-ünk, ráadásul az egyes paramétereket mi magunk szabhatjuk meg, amihez az ár is azonnal igazodik, így csupán azért a kapacitásért kell fizetnünk, amelyre valóban szükségünk van.

A saját rendszer kialakításához és üzembe helyezéséhez igénybe veheti szakértő segítségünket, és mi a céges igényeihez igazítva hozzuk létre a gyors és biztonságos rendszert, amelyet akár saját maga is üzemeltethet az ISPConfiggal, vagy minket is felkérhet az üzemeltetési és karbantartási feladatokra.

Vagy a webhely üzemeltetésének feladatát másra is bízhatjuk, ebben az esetben webtárhelyet kell vásárolnunk, és itt helyezhetjük üzembe a WordPress-webhelyünket.

Webtárhely vásárlása esetén éves szinten akár 10 ezer forint alatti összeggel is számolhatunk, és a ténylegesen fizetendő ár az általunk igényelt tárhely méretétől függ. Amennyiben igencsak nagy méretű a céges oldalunk (pl. sok képet és videót szeretnénk elhelyezni rajta), akkor érdemesebb saját VPS-t vennünk, de ha megelégszünk néhány GB-tal is, akkor sokkal jobban járunk a webtárhellyel.

Cégünk kifejezetten a WordPress-webhelyek minél gyorsabb és stabilabb kiszolgálására és biztonságos üzemeltetésére kialakított szervereket tart fenn, amelyekkel nem csupán a legjobb felhasználó élményt tudjuk garantálni a látogatóknak, de arról is gondoskodunk, hogy a lehető legjobb pontszámot lehessen elérni a szabványosság, a válaszidő és számos más olyan tényező esetén, amelyek nagyban befolyásolják, hogy a webhelyünket milyen pozícióban jelenítik meg az egyes keresőmotorok.

Kiegészítő tanácsadás keretében további finomhangolással segítjük a képek méretének és megjelenítésének optimalizálását, a keresőoptimalizálást (SEO), valamint az oldalak gyorsítótárazását, a webáruházak létrehozását és a fizetési megoldások integrálását.

További információ kéréséhez vegye fel velünk a kapcsolatot!

És akkor nézzünk néhány konkrét példát!

Minimális céges webhelyigény (webtárhely)

Éves szinten egy átlagos, alapszintű céges WordPress-webhely minimális igényekkel évi 6300 Ft-ért tartalmazza a következőket:

• 500 MB SSD-tárhely
• 5 db e-mail-fiók (egyenként 500 MB tárhellyel)
• 1 db adatbázis
• WordPress + Divi sablon
• FTP-elérés
• Webmail
• Webhelystatisztika
• ISPConfig-elérés (webhely, e-mailek, adatbázis és egyebek kezelésére szolgáló önkiszolgáló felület)
• HTTPS-tanúsítvány (LetsEncrypt)
• PHP 7.x és 8.x (igény szerint választható verzió)
• DNS-szolgáltatás (1 domainhez)

A megrendeléséhez vegye fel velünk a kapcsolatot!

A nettó árak tájékoztató jelleggel lettek feltüntetve, a cikk írásának pillanatában érvényes állapotot tükrözik, és bármikor megváltozhatnak.

Közepes céges webhelyigény (webtárhely)

Éves szinten egy átlagos, közepes szintű céges WordPress-webhely évi 35 000 Ft-ért tartalmazza a következőket:

• 20 GB SSD-tárhely
• 10 db e-mail-fiók (egyenként 1 GB tárhellyel)
• 10 db adatbázis
• WordPress + Divi sablon
• FTP-elérés
• Webmail
• Webhelystatisztika
• Automatikus biztonsági mentés
• ISPConfig-elérés (webhely, e-mailek, adatbázis és egyebek kezelésére szolgáló önkiszolgáló felület)
• HTTPS-tanúsítvány (LetsEncrypt)
• PHP 7.x és 8.x (igény szerint választható verzió)
• DNS-szolgáltatás (10 domainhez)
• Segítségnyújtás a webhely kezdeti üzembe helyezéséhez (legfeljebb 2 munkaóra)

A megrendeléséhez vegye fel velünk a kapcsolatot!

A nettó árak tájékoztató jelleggel lettek feltüntetve, a cikk írásának pillanatában érvényes állapotot tükrözik, és bármikor megváltozhatnak.

Komolyabb céges webhelyigény (VPS)

Éves szinten egy magasabb szintű céges WordPress-webhely évi 65 000 Ft-ért + egyszeri 25 000 Ft-os üzembehelyezési díjért tartalmazza a következőket:

• 120 GB SSD-tárhelyű saját VPS
• Korlátlan e-mail-fiók, DNS, saját levelezés
  
• A tökéletes Ubuntu 20.04 LTS szerver (és annak minden szolgáltatása)
• WordPress
• ISPConfig
• HTTPS-tanúsítvány (LetsEncrypt)
• PHP 7.x és 8.x
• Alapszintű hardening (tűzfalbeállítások, értesítés SSH-bejelentkezésekről, fail2ban, .htaccess-védelem a nyilvánosan elérhető szolgáltatásoknál, DDoS-védelem)
• Segítségnyújtás a webhely kezdeti üzembe helyezéséhez (legfeljebb 2 munkaóra)

A megrendeléséhez vegye fel velünk a kapcsolatot!

A nettó árak tájékoztató jelleggel lettek feltüntetve, a cikk írásának pillanatában érvényes állapotot tükrözik, és bármikor megváltozhatnak.

Amennyiben az alábbihoz hasonló hibaüzenetet kapunk a leveleink saját levelezőrendszeren keresztül történő kiküldésekor, nagy valószínűséggel a legjobban akkor járunk, ha letiltjuk az IPv6-os forgalmat a Gmail felé.

gmail-smtp-in.l.google.com[2a00:1450:400c:c07::1b]
     said: 550-5.7.1 [2a01:270:933e::1] Our system has detected that this message does not 550-5.7.1 meet IPv6 sending guidelines regarding PTR records and authentication 550-5.7.1 . Please review 550-5.7.1 https://support.google.com/mail/?p=IPv6AuthError for more information 550
     5.7.1 . 10si2520914wrz.992 - gsmtp (in reply to end of DATA command)

A konfiguráció módosítása

Elsőként is módosítanunk kell az /etc/postfix/main.cf fájlt, és a következő értékkel kell bővítenünk a transport_maps tartalmát: hash:/etc/postfix/transport

Ha követtük a tökéletes Ubuntu 20.04 LTS szerver utasításait, akkor az érintett sor így fog kinézni:

transport_maps = hash:/var/lib/mailman/data/transport-mailman, proxy:mysql:/etc/postfix/mysql-virtual_transports.cf, hash:/etc/postfix/transport

Ezután módosítanunk kell az /etc/postfix/master.cf fájlt, és a következőt kell beszúrnunk a fájl végére:

smtp-ipv4 unix - - - - - smtp
  -o inet_protocols=ipv4

Ahogy mindig, most is fontos, hogy legyenek szóközök a második sor elején!

Most hozzuk létre az előbbi transport-fájlt az /etc/postfix/transport elérési úton, és írjuk bele a következőket:

gmail.com smtp-ipv4:

google.com smtp-ipv4:

*.google.com smtp-ipv4:

googlemail.com smtp-ipv4:

*.googlemail.com smtp-ipv4:

Ahhoz, hogy megfelelő formátumban legyen ez a fájl, futtassuk az alábbi parancsot:

postmap hash:/etc/postfix/transport

A postfix újraindítása

Amennyiben minden előkészülettel megvagyunk, adjuk ki az újraindítási parancsot:

systemctl restart postfix

Hibaelhárítás

Ha valamit elrontottunk volna a konfiguráció módosítása során, akkor a postfix nem indul el, és a hibaüzenetet megtaláljuk a /var/log/mail.err fájlban.

Ebben az útmutatóban az Ubuntu 20.04 LTS (Focal Fossa) verzióra frissítünk a 18.04 LTS verzióról, a do-release-upgrade szkript használatával.

MEGJEGYZÉS

A művelet elkezdése előtt mindenképpen készítsünk a szerverünkről egy teljes értékű biztonsági mentést. Ez történhet egy snapshot vagy checkpoint (Hyper-V) létrehozásával, vagy egy ISO-fájlba történő mentéssel, illetve a rendszer klónozásával.

Ha elindítjuk a frissítést a do-release-upgrade szkripttel, és nem járunk sikerrel, manuálisan kell majd helyreállítanunk a működésképtelen rendszerünket!

Manuális biztonsági mentés

Amennyiben nem tudunk a teljes rendszerről biztonsági mentést készíteni a fenti lehetőségek egyikével sem, fájlszintű mentést is létrehozhatunk, amelynek segítségével kicsit ugyan nehezebben, de újra működőképessé tehetjük a rendszert egy sikertelen frissítést követően. Ennek lépései a következők:

/* fontos adatok mentése */ 
sudo -s cd /root tar -pczf ./completesystembackup.tar.gz /etc/letsencrypt /home/USER-DIRECTORY /var/vmail /var/log /var/www /etc/cron.d /etc/apache2 /etc/bind /usr/local/ispconfig/interface/lib /usr/local/ispconfig/server/lib /etc/postfix /etc/dovecot /etc/php* 
/* adatbázisok mentése */ 
mysqldump -u root -p --all-databases > all-databases.sql 
/* konfigurációs fájlok mentése (/etc) */
tar -pczf ./backup-etc.tar.gz /etc 

Felkészülés a frissítésre

Mielőtt belekezdenénk a frissítésbe, meg kell győződnünk arról, hogy minden frissítést telepítettünk a jelenlegi rendszerre:

sudo apt update
sudo apt upgrade
sudo apt dist-upgrade

Ha bármilyen frissítést telepíteni kellett, indítsuk újra a rendszert:

sudo reboot

A frissítés elindítása előtt győződjünk meg arról, hogy a műveletet a screen használatával futtatjuk, ebben az esetben ugyanis akkor is folytathatjuk majd a műveletet, ha véletlenül megszakadna az SSH-kapcsolatunk:

sudo apt install screen
screen

Ha valamilyen okból megszakadna a kapcsolat, akkor a következő paranccsal tudjuk folytatni a megkezdett munkamenetet:

screen -x

MEGJEGYZÉS

A frissítési folyamat során a szkript meg fog nyitni egy további SSH-kapcsolati portot is, a 1022-es porton. Ezt a portot a tűzfalon is érdemes megnyitni a frissítési művelet kezdetén, a szkript által megjelenített iptables-parancs futtatásával.

A frissítés elindítása (do-release-upgrade)

Amennyiben minden előkészülettel megvagyunk, adjuk ki a frissítési parancsot:

sudo do-release-upgrade

MEGJEGYZÉS

Amennyiben az első két kérdésnél a telepítés folytatását választjuk, onnantól nincs visszaút. Ha valami balul sül el, a biztonsági mentésből tudjuk csak helyreállítani a rendszerünket.

A felkínált lehetőségek mindegyikénél elfogadhatjuk az alapértelmezett értéket, az apt-listchangesből a legegyszerűbben a q billentyű lenyomásával tudunk kilépni, az LXD frissítését érintő kérdés után pedig egy ideig nem történik semmi, de nincs más dolgunk, mint várni türelemmel.

Előfordulhat, hogy a phpmyadmin és a roundcube adatbázisának újrakonfigurálására felszólító üzenetet kapunk a frissítés során, ám mivel egyes szolgáltatások a háttérben már nem futnak, a változtatásokat nem tudja a frissítési varázsló végrehajtani. Pánikra semmi ok, ezt a lépést nyugodtan kihagyhatjuk mindenféle változtatás nélkül.

Ugyanígy ügyeljünk arra is, hogy bármilyen konfigurációs fájlt szeretne a folyamat felülírni, mindig az alapértelmezett N választ adjuk, hiszen az összes érintett szolgáltatást vagy saját magunk konfiguráltuk, vagy az ISPConfig kezeli.

Ha sikerrel jártunk, akkor a gép újraindítását követően már a 20.04-es Ubuntu rendszerbe tudunk bejelentkezni. Ha valami mégsem stimmelt volna, akkor viszont érdemes visszaállni a korábbi rendszerre a biztonsági mentésből, és újból nekifutni a folyamatnak. Ha semmilyen konstellációban sem boldogulunk a frissítéssel, akkor érdemes egy tiszta telepítést végrehajtani, és a biztonsági mentésből helyreállítani a tartalmakat.

A frissítést követő lépések

Ugyan a rendszer már frissült az új verzióra, ám néhány további lépést még végre kell hajtanunk ahhoz, hogy minden működőképes legyen.

Elsőként is futtassuk az apparmor eltávolítási parancsát:

sudo service apparmor stop
sudo update-rc.d -f apparmor remove 
sudo apt-get purge apparmor apparmor-utils

Majd nézzük meg, hogy van-e olyan csomag, amelyet még frissíteni szükséges, és tegyünk egy kicsit rendet a már szükségtelenek eltávolításával:

sudo apt update
sudo apt upgrade
sudo apt dist-upgrade
sudo apt autoremove
sudo apt autoclean

Ha ez is megvan, akkor tegyük rendbe a dovecot levélkiszolgáló szolgáltatást, amelynek az új verziója a korábbinál szigorúbb követelményeket támaszt az általa használt tanúsítvánnyal szemben:

sudo openssl dhparam -out /etc/dovecot/dh.pem 4096
sudo systemctl restart dovecot

Ez a lépés eltarthat pár percig.

Ha befejeződött, akkor még végig kell mennünk a tökéletes Ubuntu 20.04 LTS szerver telepítésének lépésein, ugyanis egyes csomagok vagy konfigurációs beállítások még hiányozhatnak, többek között a postfixnél, a mariadb-nél  és az apache-nál.

Ha ez is megvan, akkor újrakonfigurálhatjuk az ISPConfigot az alábbi paranccsal:

ispconfig_update.sh --force

A vonatkozó kérdéseknél a szolgáltatásokat és a master adatbázist is újra kell konfigurálnunk, ám ha nem tapasztalunk problémákat, akkor az ISPConfig által beállított tanúsítványokat nem szükséges újra létrehozni.

Végül pedig engedélyeznünk kell a frissítéssel együtt letiltott külső csomagforrásokat (pl. az alternatív PHP-verziókat).

És ha mindez megvan, akkor már csak annyi a feladatunk, hogy utánanézünk a naplófájlokban, hogy minden problémamentesen működik-e. Ha pedig nem, akkor célzott hibaelhárítást kell végeznünk az érintett szolgáltatáson.

Érdemes az ISPConfig adminfelületére is bejelentkezni, és megnézni, hogy ott is a megfelelő adatok látszanak-e. Többszerveres környezetben előfordult, hogy az alárendelt szerver verziószáma csak egy nappal később frissült, és voltak olyan webhelyek is, ahol a tárhelykvótát újra be kellett állítani ahhoz, hogy az áttekintő lapon ne korlátlanként szerepeljenek.

Összegzés

A fenti lépéseket követve egy biztonságos, éles üzemben is használható LAMP-kiszolgálót kapunk, amelyen az Ubuntu 20.04 LTS fut. Mindennek természetesen az alapfeltétele az, hogy a kiindulási alapként szolgáló Ubuntu 18.04 LTS is mindenben kövesse a tökéletes Ubuntu 18.04 LTS szerverre vonatkozó útmutató előírásait. Ha mégsem sikerülne megbirkózni a feladattal, akkor vegye fel velünk a kapcsolatot, és segítünk a frissítésben!

Ebben az útmutatóban sorra vesszük az Ubuntu 20.04 LTS (Focal Fossa) szolgáltatásainak üzembe helyezéséhez szükséges lépéseket, majd telepítjük az ISPConfigot, végül pedig elvégezzük a szerver biztonságossá tételét (hardening).

MEGJEGYZÉS

Az ISPConfig telepíthető többszerveres konfigurációban is, mi ebben az útmutatóban csak a főszerver (master) telepítését ismertetjük. Az ISPConfig telepítése ki is hagyható, ha nincs szükség webes kezelőfelületre a szerver és annak felhasználóinak adminisztrálásához (például egyfelhasználós környezetben, ha nem kell több webhelyet adminisztrálni). Ebben az esetben a megjegyzéseket követve néhány opcionális lépést ki lehet hagyni, végeredményül azonban továbbra is egy biztonságos szerverkörnyezet áll majd a rendelkezésünkre, amely éles üzemben is használható.

Az eredeti, angol nyelvű útmutató itt található: https://www.howtoforge.com/tutorial/perfect-server-ubuntu-20.04-with-apache-php-myqsl-pureftpd-bind-postfix-doveot-and-ispconfig/

Az alábbi, magyar nyelvű útmutató az következő plusz információt nyújtja az eredetihez képest:

• helyenként részletesebb magyarázatok
• az ext4 mellett az xfs fájlrendszer támogatása a kvóták beállításánál
• a pontos idő rendszeres szinkronizálása ntpdate segítségével
• jelszóval védett phpmyadmin
• e-mailes értesítés minden SSH-bejelentkezés és -kijelentkezés esetén
• mod_evasive Apache-modul a szigorúbb webes védelem és a DDoS-támadások megelőzése érdekében
• fail2ban-szabályok az Apache és a roundcube védelméhez

Előfeltételek

Az útmutatóban szereplő lépések feltételezik egy már telepített Ubuntu 20.04 LTS szerver meglétét, amelyhez a felhasználó root jogosultsággal rendelkezik. Ez VPS-szerverek esetén általában automatikusan megtörténik a VPS létrehozásakor, saját környezetben viszont egy telepítési adathordozóról kell először telepíteni az operációs rendszert. Ez az útmutató ezekkel a lépésekkel nem foglalkozik, csak a már müködő rendszer konfigurálásával. Ugyanígy nem tér ki arra sem, hogyan lehet bejelentkezni a frissen telepített rendszerre SSH-n keresztül.

FIGYELEM!

A sikeres konfigurálás érdekében érdemes egy teljesen újonnan telepített rendszert használni, mivel egyéb esetben a korábbi beállítások ütközést okozhatnak az egyes lépések utasításainak végrehajtása során.

Az összes használt parancs root jogosultságot igényel, ezért a konzolra történő bejelentkezést vagy az SSH-kapcsolat létrejöttét követően elsőként érdemes kiadni az alábbi parancsot:

sudo -s

Az egyes fájlok szerkesztéséhez a nano szerkesztőt használjuk a példákban. Érdemes megismerkedni a használatával és a benne elérhető parancsokkal, mindenesetre kezdőknek segítségül jelezzük, hogy a módosítások mentéséhez és a fájlok bezáráshoz a CTRL + X billentyűkombinációt kell lenyomni, majd az Y billentyűt.

Az /etc/apt/sources.list tartalmának ellenőrzése és a források frissítése

Amennyiben a telepítés valamilyen fizikai adathordozóról történt, előfordulhat, hogy az még szerepel a telepítési források között. Ennek ellenőrzéséhez érdemes megnyitni az /etc/apt/sources.list fájlt:

nano /etc/apt/sources.list

majd meggyőződni annak tartalmáról:

# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
# newer versions of the distribution.
deb http://de.archive.ubuntu.com/ubuntu focal main restricted
# deb-src http://de.archive.ubuntu.com/ubuntu focal main restricted

## Major bug fix updates produced after the final release of the
## distribution.
deb http://de.archive.ubuntu.com/ubuntu focal-updates main restricted
# deb-src http://de.archive.ubuntu.com/ubuntu focal-updates main restricted

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb http://de.archive.ubuntu.com/ubuntu focal universe
# deb-src http://de.archive.ubuntu.com/ubuntu focal universe
deb http://de.archive.ubuntu.com/ubuntu focal-updates universe
# deb-src http://de.archive.ubuntu.com/ubuntu focal-updates universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb http://de.archive.ubuntu.com/ubuntu focal multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal multiverse
deb http://de.archive.ubuntu.com/ubuntu focal-updates multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal-updates multiverse

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb http://de.archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal-backports main restricted universe multiverse

## Uncomment the following two lines to add software from Canonical's
## 'partner' repository.
## This software is not part of Ubuntu, but is offered by Canonical and the
## respective vendors as a service to Ubuntu users.
# deb http://archive.canonical.com/ubuntu focal partner
# deb-src http://archive.canonical.com/ubuntu focal partner

deb http://de.archive.ubuntu.com/ubuntu focal-security main restricted
# deb-src http://de.archive.ubuntu.com/ubuntu focal-security main restricted
deb http://de.archive.ubuntu.com/ubuntu focal-security universe
# deb-src http://de.archive.ubuntu.com/ubuntu focal-security universe
deb http://de.archive.ubuntu.com/ubuntu focal-security multiverse
# deb-src http://de.archive.ubuntu.com/ubuntu focal-security multiverse

Ezt követően pedig jöhet a rendszer frissítése:

apt-get update

apt-get upgrade

Ha a frissítések között újabb kernelverziók is láthatók, akkor ezt követheti egy:

apt-get dist-upgrade

apt-get autoremove

majd pedig egy újraindítás:

reboot

Az alapértelmezett rendszerhéj beállítása

Az Ubuntu alapértelmezett rendszerhéja a dash, ám nekünk a bashre lesz szükségünk, ehhez pedig az alábbi parancsot kell kiadni:

dpkg-reconfigure dash
Use dash as the default system shell (/bin/sh)? <-- No

FIGYELEM!

Ennek a lépésnek az elmulasztása esetén az ISPConfig ugyan nem lesz telepíthető, de a rendszer ettől még használható lesz.

Az AppArmor letiltása

Az Ubuntu egyik beépített biztonsági szolgáltatása az AppArmor, ám általában inkább több problémát okoz, mint amennyit segítene a biztonság fokozása terén, ezért érdemes letiltani. Az általa biztosított biztonsági megoldásokat bőven pótoljuk majd a későbbiekben.

service apparmor stop
update-rc.d -f apparmor remove 
apt-get remove apparmor apparmor-utils

FIGYELEM!

Ennek a lépésnek az elmulasztása esetén az ISPConfig ugyan nem lesz telepíthető, de a rendszer ettől még használható lesz.

A rendszeróra szinkronizálása és naprakészen tartása (opcionális)

Minden rendszeren fontos, hogy pontos legyen a rendszeridő, ehhez pedig érdemes telepíteni az ntp nevű csomagot, illetve rendszeres időközönként szinkronizálni az egyik időkiszolgálóval.

apt-get -y install ntp ntpdate

Ezt követően szerkeszteni kell a crontabot, és be kell szúrni az alábbi sort.

nano /etc/crontab 

00 2 * * * root ntpdate time.kfki.hu

Ebben a példában minden nap hajnali 2-kor fut le a szinkronizálás a magyarországi time.kfki.hu szerverrel. Érdemes mindig egy közeli szervert kiválasztani a szinkronizáláshoz. Nemzetközi környezetben a pool.ntp.org használata javasolt.

A postfix, dovecot, mariaDB, rkhunter és binutils telepítése

A postfix telepítéséhez biztosnak kell lennünk abban, hogy nincs telepítve a sendmail:

service sendmail stop; update-rc.d -f sendmail remove

Ha nincs telepítve, az alábbi hibaüzenet jelenik meg:

Failed to stop sendmail.service: Unit sendmail.service not loaded.

Ekkor jöhet a többi csomag telepítése:

apt-get -y install postfix postfix-mysql postfix-doc mariadb-client mariadb-server openssl getmail4 rkhunter binutils dovecot-imapd dovecot-pop3d dovecot-mysql dovecot-sieve sudo patch

General type of mail configuration: <-- Internet Site
System mail name: <-- mail.sajatdomain.hu

A mail.sajatdomain.hu helyett egy olyan domainnevet kell megadni, amelyet éles rendszerek esetén aztán majd beállítunk a DNS-ben is. Soha ne olyan nevet adjunk itt meg, amely egyben weboldal címe is lesz, hanem egy technikai nevet, amelyet webes tartalom kiszolgálására biztosan nem használunk.

Ezt követően engedélyezzük a TLS és SASL működését:

nano /etc/postfix/master.cf

Ki kell szedni a megjegyzésből a submission és az smtp alábbi szakaszait, valamint be kell szúrni 1-1 sort is:

[...]
submission inet n       -       y       -       -       smtpd
  -o syslog_name=postfix/submission
  -o smtpd_tls_security_level=encrypt
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_tls_auth_only=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
smtps     inet  n       -       y       -       -       smtpd
  -o syslog_name=postfix/smtps
  -o smtpd_tls_wrappermode=yes
  -o smtpd_sasl_auth_enable=yes
  -o smtpd_client_restrictions=permit_sasl_authenticated,reject
#  -o smtpd_reject_unlisted_recipient=no
#  -o smtpd_client_restrictions=$mua_client_restrictions
#  -o smtpd_helo_restrictions=$mua_helo_restrictions
#  -o smtpd_sender_restrictions=$mua_sender_restrictions
#  -o smtpd_recipient_restrictions=permit_sasl_authenticated,reject
#  -o milter_macro_daemon_name=ORIGINATING
[...]

Fontos, hogy a -o előtti szóközök nem hagyhatók le.

Most újraindíthatjuk a szolgáltatást:

service postfix restart

Majd beállítjuk, hogy a MariaDB a kívülről jövő kapcsolatokat is engedélyezze:

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Ehhez megjegyzésbe (#) kell tenni a localhostra (127.0.0.1-re) vonatkozó alábbi sort:

[...]
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#bind-address           = 127.0.0.1

[...]

Ezt követően jelszóval kell ellátnunk az adatbáziskiszolgáló root jogosultságú felhasználóját, letiltjuk az anonim felhasználókat, illetve a távoli bejelentkezést root jogosultságokkal:

mysql_secure_installation

Enter current password for root (enter for none): <-- Enter billentyű szöveg beírása nélkül
Set root password? [Y/n] <-- y
New password: <-- A MariaDB root jelszava
Re-enter new password: <-- A jelszó még egyzer
Remove anonymous users? [Y/n] <-- y
Disallow root login remotely? [Y/n] <-- y
Reload privilege tables now? [Y/n] <-- y

Beállítjuk a phpmyadmin használatához a megfelelő azonosítási módot:

echo "update mysql.user set plugin = 'mysql_native_password' where user='root';" | mysql -u root

Majd az előbb beállított jelszót megadjuk a rendszer karbantartási feladatai számára:

nano /etc/mysql/debian.cnf

# Automatically generated for Debian scripts. DO NOT TOUCH!
[client]
host = localhost
user = root
password = a_root_felhasználó_jelszava
socket = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host = localhost
user = root
password = a_root_felhasználó_jelszava
socket = /var/run/mysqld/mysqld.sock
basedir = /usr

Szerkesszük az /etc/security/limits.conf fájlt, és adjuk a következő sorokat a fájl végéhez:

nano /etc/security/limits.conf

mysql soft nofile 65535
mysql hard nofile 65535

Hozzunk létre egy új könyvtárat, benne egy fájllal és az alábbi tartalommal:

mkdir /etc/systemd/system/mysql.service.d/

nano /etc/systemd/system/mysql.service.d/limits.conf

[Service]
LimitNOFILE=infinity

Végül pedig indítsuk újra a szolgáltatást a változtatások életbe léptetéséhez:

systemctl daemon-reload
service mariadb restart

Az amavisd-new, spamassassin és clamav telepítése

A vírusok és a kéretlen levelek kiszűréséhez telepítsük az alábbi csomagokat:

apt-get -y install amavisd-new spamassassin clamav clamav-daemon unzip bzip2 arj nomarch lzop cabextract apt-listchanges libnet-ldap-perl libauthen-sasl-perl clamav-docs daemon libio-string-perl libio-socket-ssl-perl libnet-ident-perl zip libnet-dns-perl postgrey

Az ISPConfig használata esetén nincs szükség arra, hogy a spamassassin külön fusson:

service spamassassin stop
update-rc.d -f spamassassin remove

Indítsuk el a clamavot (ha egy hibaüzenet jelenik meg a parancs futtatásakor, azzal most nem kell foglalkoznunk):

freshclam
service clamav-daemon start

Az apache, php, phpmyadmin, fcgi, suexec és pear telepítése

A weboldalak kiszolgálásához telepítsük az alábbi csomagokat:

apt-get -y install apache2 apache2-doc apache2-utils libapache2-mod-php php7.4 php7.4-common php7.4-gd php7.4-mysql php7.4-imap phpmyadmin php7.4-cli php7.4-cgi libapache2-mod-fcgid apache2-suexec-pristine php-pear libruby libapache2-mod-python php7.4-curl php7.4-intl php7.4-pspell php7.4-sqlite3 php7.4-tidy php7.4-xmlrpc php7.4-xsl memcached php-memcache php-imagick php7.4-zip php7.4-mbstring php-soap php7.4-soap php7.4-opcache php-apcu php7.4-fpm libapache2-reload-perl

Web server to reconfigure automatically: <-- apache2 
Configure database for phpmyadmin with dbconfig-common? <-- Yes
MySQL application password for phpmyadmin: <-- Enter billentyű lenyomása szöveg bevitele nélkül

Ezt követően engedélyezzük a szükséges modulokat:

a2enmod suexec rewrite ssl actions include cgi alias proxy_fcgi
a2enmod dav_fs dav auth_digest headers

Majd pedig bebiztosítjuk a kiszolgálót a HTTPOXY-támadásokkal szemben:

nano /etc/apache2/conf-available/httpoxy.conf

Ennek új tartalma ez lesz:

<IfModule mod_headers.c>
    RequestHeader unset Proxy early
</IfModule>

MEGJEGYZÉS

Ez egy viszonylag régi támadástípus, amelyet 2016 közepén fedeztek fel, és a legnagyobb veszélyt a CGI-környezetekben folytatott PHP-s kódfuttatásra jelenti, ám mivel LTS rendszert használunk, így érdemes duplán bebiztosítani magunkat. (További információ: https://httpoxy.org/.)

Majd engedélyezzük a szabályzatot:

a2enconf httpoxy

És ezt követően újraindítjuk a szolgáltatást:

service apache2 restart

A hhvm telepítése (opcionális)

A Facebook által létrehozott HipHop Virtual Machine segít felgyorsítani a PHP-kódok futását. A telepítése a következő paranccsal történik:

apt-get -y install hhvm

A mod_evasive telepítése (opcionális)

A mod_evasive segít megakadályozni a szolgáltatásmegtagadásos támadásokat (DoS, DDoS) és a vég nélküli jelszókitalálásos próbálkozásokat, ugyanis korlátozza, hogy egy felhasználó egy adott időintervallumon belül hány oldalt kérhet le. Önmagában nem nyújt elegendő védelmet, azonban tökéletes kiegészítése a fail2ban működésének, mivel az főként csak a hitelesítésre összpontosít.

A telepítése a következő paranccsal történik:

apt-get -y install libapache2-mod-evasive

Ha esetleg rákérdez a telepítő bármire, akkor az alapértelmezett beállítást kell elfogadni. A következő paranccsal lehet ellenőrizni a sikeres telepítését:

apachectl -M | grep evasive

Erre egy ehhez hasonló választ kapunk:

 evasive20_module (shared)

Alapértelmezés szerint a konfiguráció nincs élesen üzembe helyezve, ezért most ezt kell módosítanunk:

nano /etc/apache2/mods-enabled/evasive.conf

Éles üzemben használt szervereken az alábbi értékek használata a javasolt:

<IfModule mod_evasive20.c>
    DOSHashTableSize    3097
    DOSPageCount        2
    DOSSiteCount        50
    DOSPageInterval     1
    DOSSiteInterval     1
    DOSBlockingPeriod   10

    DOSEmailNotify      root@mail.sajatdomain.hu
    DOSSystemCommand    "su - someuser -c '/sbin/... %s ...'"
    DOSLogDir           "/var/log/mod_evasive"
</IfModule>

Értelemszerűen a fenti példában lévő root@mail.sajatdomain.hu címet egy saját használatú e-mail-címre kell lecserélni. Ezt követően még létre kell hoznunk a naplózáshoz szükséges mappát, megfelelő jogosultságot kell adnunk annak, majd újra kell indítanunk az apache szolgáltatást:

mkdir /var/log/mod_evasive
chown -R www-data:www-data /var/log/mod_evasive

systemctl restart apache2

A phpmyadmin jelszavas védelme

Bármilyen hihetetlen is, de a phpmyadmin alapértelmezett konfigurációban csak egy olyan jelszavas mezőt tesz elérhetővé, amellyel magához a MySQL szolgáltatáshoz lehet csatlakozni. Ez nem túl biztonságos megoldás, hiszen bárki elkezdhet próbálkozni a jelszavakkal. Szerencsére nem kell túl sok erőfeszítést tennünk ahhoz, hogy az Apache segítségével egy olyan jelszavas bejelentkezést hozzunk létre még ezt megelőzően, amelynél a sikertelen próbálkozásokat már a fail2ban kezeli, így a megadott számú téves próbálkozás után le is tiltja a próbálkozó szellemű támadót.

Ehhez első körben módosítanunk kell az alábbi konfigurációs fájlt, és engedélyeznünk kell a beállítások .htaccess általi módosítását (AllowOverride All):

nano /etc/apache2/conf-available/phpmyadmin.conf

# phpMyAdmin default Apache configuration

Alias /phpmyadmin /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin>
    Options SymLinksIfOwnerMatch
    DirectoryIndex index.php
    AllowOverride All
[...]

Ezt követően létrehozzuk a bejelentkezést megkövetelő fájl:

nano /usr/share/phpmyadmin/.htaccess

És beleírjuk az alábbi tartalmat:

AuthType Basic
AuthName "Restricted Files"
AuthUserFile /etc/phpmyadmin/.htpasswd
Require valid-user

Majd létrehozunk egy phpmyadmin nevű felhasználót a belépéshez:

htpasswd -c /etc/phpmyadmin/.htpasswd phpmyadmin

Ha további felhasználókat szeretnénk hozzáadni ehhez a fájlhoz, akkor az alábbi parancsot kell használnunk:

htpasswd /etc/phpmyadmin/.htpasswd felhasznalonev

A felhasznalonev helyére az adott felhasználó nevét írjuk. Végül pedig indítsuk újra a szolgáltatást a változtatások életbe léptetéséhez:

systemctl restart apache2

A Let's Encrypt telepítése

Napjaink webhelyei szinte kizárólag HTTPS-kapcsolaton keresztül érhetők el, és az olyan oldalak esetén, amelyeknél ez a feltétel nem teljesül, a böngésző biztonsági értesítést jelenít meg, és egyben nem is tanácsolja annak felkeresését. Régen az ehhez szükséges tanúsítványok csak fizetős verzióban voltak elérhetők (jó drágán), az önaláírt tanúsítványokat pedig szintén nem részesítik előnyben a böngészők. Szerencsére manapság már elérhető a Let's Encrypt, amely ugyan nem veheti fel a versenyt a komolyabb tanúsítványokkal, az alapfunkciókat tökéletesen ellátja, és minden böngésző biztonságosként fogja feltüntetni a nálunk tárolt webhelyeket. És ami a legfontosabb, teszi mindezt teljesen ingyenesen és automatikusan.

Így telepíthetjük:

apt-get -y install certbot

A pureftpd és quota telepítése

A szerverhez engedélyezhetünk FTP-kapcsolatot (és SSH-kapcsolatot is, de utóbbi használatát nehezebb lesz egyes felhasználóinknak elmagyarázni), és természetesen lehetőségünk nyílik arra, hogy elejét vegyük felhasználóink korlátlan terjeszkedésének, azaz mindenkinek beállíthatunk egy kvótát a webes, adatbázisban tárolt és levelezési tartalmak tárhelyhasználatára vonatkozóan.

Elsőként is telepítsük a szükséges csomagokat:

apt-get -y install pure-ftpd-common pure-ftpd-mysql quota quotatool

Ezt követően ellenőrizzük, hogy standalone módban fut-e a démon, és a felhasználókat bezárja-e a saját könyvtárukba:

nano /etc/default/pure-ftpd-common

[...]
STANDALONE_OR_INETD=standalone
[...]
VIRTUALCHROOT=true
[...]

Mivel a pureftpd alapesetben titkosítatlan kapcsolatokat is engedélyez, itt az ideje, hogy konfiguráljuk hozzá a TLS-kapcsolatokat és létrehozzunk egy (önaláírt) tanúsítványt, mivel nem szeretnénk, hogy a jelszavak sima szövegként utazgassanak az interneten:

echo 1 > /etc/pure-ftpd/conf/TLS

mkdir -p /etc/ssl/private/

openssl req -x509 -nodes -days 7300 -newkey rsa:2048 -keyout /etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem

Country Name (2 letter code) [AU]: <-- HU
State or Province Name (full name) [Some-State]:<-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []:<-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]:<-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []:<-- Részleg neve (pl.: informatikai részleg)
Common Name (eg, YOUR name) []:<-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []:<-- A webmester vagy a rendszergazda e-mail-címe

chmod 600 /etc/ssl/private/pure-ftpd.pem

Majd indítsuk újra a szolgáltatást:

service pure-ftpd-mysql restart

Ezt követően a kvótarendszer aktiválásához módosítanunk kell a következő fájlt:

nano /etc/fstab

Minden rendszernél más lehet az egyes csatolt fájlrendszerek elnevezése, mindenesetre nekünk a root fájlrendszert kell megkeresnünk, amit a sima perjel ("/") jelöl, és ehhez kell hozzáadnunk a megfelelő plusz paramétereket.

Néhány példa erre:

ext4 fájlrendszer esetén: (,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0)

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/server1--vg-root / ext4 errors=remount-ro,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0 0 1
/dev/mapper/server1--vg-swap_1 none swap sw 0 0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0

Vagy ext4 és UUID használata esetén: (,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0)

UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / ext4 defaults,usrjquota=quota.user,grpjquota=quota.group,jqfmt=vfsv0 0 0
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX /boot ext4 defaults 0 0
/swap.img       none    swap    sw      0       0

xfs fájlrendszer esetén: (,uquota,gquota)

proc            /proc   proc    defaults        0 0
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX / xfs defaults,uquota,gquota 1 1
UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX none swap sw 0 0

Ezt követően a módosítások életbe léptetéséhez a következők parancsok kiadására van szükség:

mount -o remount /

quotacheck -avugm
quotaon -avug

FIGYELEM!
xfs fájlrendszer esetén további lépésekre van szükség, ugyanis a kernelben is engedélyezni kell (rootflags=uquota,gquota) a kvótát. Ennek lépéseit lásd alább:

nano /etc/default/grub

[...]
GRUB_CMDLINE_LINUX="console=tty0 console=ttyS0,115200n8 net.ifnames=0 rootflags=uquota,gquota"
[...]

grub-mkconfig -o /boot/grub/grub.cfg

A végén pedig újra is kell indítanunk a rendszert a változtatások életbe léptetéséhez, hiszen a kernelt paramétereztük fel a rootflags=uquota,gquota attribútumokkal, így azt is újra be kell tölteni:

reboot

A kernel által nem támogatott kvótaformátum hiba

Előfordulhat, hogy a kernelben még ext4 fájlrendszer esetén sem érhetők el a megfelelő modulok, ebben az esetben a következő hiba jelenik meg:

quotaon: cannot find //aquota.group on /dev/vda1 [/]
quotaon: using //aquota.user on /dev/vda1 [/]: No such process
quotaon: Quota format not supported in kernel.

Szerencsére ennek a megoldása nagyon egyszerű, csak az alábbi parancsokat kell futtatnunk:

apt-get install linux-image-extra-virtual

echo quota_v1 >> /etc/modules
echo quota_v2 >> /etc/modules

Ha ezzel megvagyunk, akkor már csak újra kell indítanunk a szervert, és máris aktiválni tudjuk a kvótánkat.

A bind telepítése

A DNS-rendszerünket és -kéréseinket kiszolgáló szolgáltatás a manapság iparági szabványnak tekinthető bind lesz, amelynek kísérőjeként egy véletlenszám-generátort is telepítünk. Ennek lépései:

apt-get -y install bind9 dnsutils haveged

systemctl enable haveged
systemctl start haveged

A vlogger, webalizer és awstats telepítése

A nálunk elhelyezett egyes webhelyekhez statisztikákat is elérhetővé tehetünk, amelyek segítségével jobban nyomon követhető a forgalom, illetve a látogatók statisztikái:

apt-get -y install vlogger webalizer awstats geoip-database libclass-dbi-mysql-perl

echo "deb https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/goaccess.list
wget -O - https://deb.goaccess.io/gnugpg.key | sudo apt-key --keyring /etc/apt/trusted.gpg.d/goaccess.gpg add -
sudo apt-get update
sudo apt-get install goaccess

nano /etc/cron.d/awstats

Majd itt az összes sort megjegyzésbe kell tenni:

#MAILTO=root

#*/10 * * * * www-data [ -x /usr/share/awstats/tools/update.sh ] && /usr/share/awstats/tools/update.sh

# Generate static reports:
#10 03 * * * www-data [ -x /usr/share/awstats/tools/buildstatic.sh ] && /usr/share/awstats/tools/buildstatic.sh

A jailkit telepítése

A jailkit segítségével lehet a saját könyvtárukra korlátozni az SSH-val bejelentkező felhasználókat:

apt-get -y install jailkit

A fail2ban és ufw telepítése

A fail2ban abban segít minket, hogy az egyes szolgáltatások használatakor korlátozza az azonosítási kísérletek számát, így a rosszindulatú támadók nem tudnak egy-egy szolgáltatásnál végtelen alkalommal próbálkozni, amíg ki nem találják a helyes jelszót.

apt-get -y install fail2ban

nano /etc/fail2ban/jail.local

(ez egy újonnan létrehozott fáj, így az alábbi teljes tartalmat bele kell másolni)

[pure-ftpd]
enabled  = true
port     = ftp
filter   = pure-ftpd
logpath  = /var/log/syslog
maxretry = 3

[dovecot]
enabled = true
filter = dovecot
action = iptables-multiport[name=dovecot-pop3imap, port="pop3,pop3s,imap,imaps", protocol=tcp]
logpath = /var/log/mail.log
maxretry = 5

[postfix]
enabled  = true
port     = smtp
filter   = postfix
logpath  = /var/log/mail.log
maxretry = 3

[apache]
enabled  = true
port     = http,https
filter   = apache-auth
# logpath  = /var/log/apache*/*error.log
logpath  = /var/log/ispconfig/httpd/*/error.log
findtime = 3600
maxretry = 3
bantime  = 86400

[roundcube]
enabled  = true
port     = http,https
filter   = roundcube
logpath  = /var/log/roundcube/userlogins
maxretry = 5

service fail2ban restart

Az ufw egy alapszintű tűzfal, amely kompatibilis az ISPConfiggal, így annak webes felületén lehet konfigurálni a megnyitni kívánt portokat. Mivel nem túl kifinomult, így általában nem szoktuk használni, hanem saját tűzfalszabályokat szoktunk alkalmazni az adott környezetnek megfelelően, viszont ha valaki csak egy egyszerű környezetben szeretné biztonságosabbá tenni a rendszerét, annak az ufw által nyújtott lehetőségek (az egyes szolgáltatások portjainak engedélyezése vagy letiltása) is elegendőek lehetnek. Akárhogyan is, telepíteni azért érdemes, mert a működése a webes felületről teljes mértékben irányítható (és ki is kapcsolható).

apt-get install ufw

A roundcube webmail telepítése

Levelezésünket ugyan teljes mértékben kezelni tudjuk a különböző levelezőkliensekből, mégis egyes felhasználók előnyben részesítik néha a webes kezelőfelület használatát. Arról nem is beszélve, hogy a spamszűrést és egyéb, a levelezéssel kapcsolatos beállítási lehetőséget csak a webmailen keresztül tudjuk elérhetővé tenni a számukra (ezzel egy külön cikkben foglalkozunk). Ehhez a roundcube-ot hívjuk segítségül:

apt-get -y install roundcube roundcube-core roundcube-mysql roundcube-plugins roundcube-plugins-extra javascript-common libjs-jquery-mousewheel php-net-sieve tinymce

Configure database for roundcube with dbconfig-common? <-- Yes
MySQL application password for roundcube: <-- Enter billentyű szöveg beírása nélkül

nano /etc/apache2/conf-enabled/roundcube.conf

Itt engedélyeznünk kell a roundcube aliasait (az egyiknél csak a megjegyzést kell eltávolítani, a másikat újonnan kell beírni), illetve engedélyezni kell a .php kiterjesztést is.

# Those aliases do not work properly with several hosts on your apache server
# Uncomment them to use it or adapt them to your configuration
    Alias /roundcube /var/lib/roundcube
    Alias /webmail /var/lib/roundcube

<Directory /var/lib/roundcube/>
  AddType application/x-httpd-php .php
  Options +FollowSymLinks
  # This is needed to parse /var/lib/roundcube/.htaccess. See its
  # content before setting AllowOverride to None.
  AllowOverride All
[...]

Majd újraindítjuk a szolgáltatást:

service apache2 restart

Végül pedig csak a helyi gép levelezéséhez engedélyezzük a csatlakozást:

nano /etc/roundcube/config.inc.php

[...]
$config['default_host'] = 'localhost';
[...]
$config['smtp_server'] = 'localhost';
$config['smtp_port']  = 25;
[...]

Az ISPconfig telepítése

A legújabb verzió a következő parancsokkal telepíthető:

cd /tmp 
wget -O ispconfig.tar.gz https://www.ispconfig.org/downloads/ISPConfig-3-stable.tar.gz
tar xfz ispconfig.tar.gz
cd ispconfig3*/install/

php -q install.php

A telepítő gyakorlatilag minden szolgáltatást konfigurál nekünk, csupán néhány kérdésre kell választ adnunk.

FONTOS!
Az alábbiakban a főkiszolgáló (master) beállításait tüntetjük fel. Többkiszolgálós környezetben a többi szerver telepítésénél más beállításokat kell kiválasztani!

--------------------------------------------------------------------------------

>> Initial configuration
Operating System: Ubuntu 18.04 (Bionic Beaver)
Following will be a few questions for primary configuration so be careful.
Default values are in [brackets] and can be accepted with <enter>.
Tap in "quit" (without the quotes) to stop the installer.

Select language (en,de) [en]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Installation mode (standard,expert) [standard]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Full qualified hostname (FQDN) of the server, eg server1.domain.tld [mail.sajatdomain.hu]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL server hostname [localhost]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL server port [3306]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL root username [root]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL root password []: <-- A MySQL-nél megadott rootjelszó
MySQL database to create [dbispconfig]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
MySQL charset [utf8]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Configuring Postgrey
Configuring Postfix
Generating a 4096 bit RSA private key
.......................................................................++
........................................................................................................................................++
writing new private key to 'smtpd.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: <-- HU
State or Province Name (full name) [Some-State]: <-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) []: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy a rendszergazda e-mail-címe
Configuring Mailman
Configuring Dovecot
Configuring Spamassassin
Configuring Amavisd
Configuring Getmail
Configuring BIND
Configuring Jailkit
Configuring Pureftpd
Configuring Apache
Configuring vlogger
Configuring Metronome XMPP Server
writing new private key to 'localhost.key'
-----
Country Name (2 letter code) [AU]: <-- HU
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) [server1.canomi.com]: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy a rendszergazda e-mail-címe
Configuring Ubuntu Firewall
Configuring Fail2ban
[INFO] service OpenVZ not detected
Configuring Apps vhost
Installing ISPConfig
ISPConfig Port [8080]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Admin password [admin]: <-- Enter billentyű lenyomása szöveg bevitele nélkül (a jelszót a webes felületen érdemes módosítani, az első bejelentkezés után)
Do you want a secure (SSL) connection to the ISPConfig web interface (y,n) [y]: <-- Enter billentyű lenyomása szöveg bevitele nélkül
Generating RSA private key, 4096 bit long modulus
.......................++
................................................................................................................................++
e is 65537 (0x10001)
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: <-- HU
State or Province Name (full name) [Some-State]: <-- Budapest (vagy bármely más megye, ékezetek nélkül)
Locality Name (eg, city) []: <-- Budapest (vagy bármely más város, ékezetek nélkül)
Organization Name (eg, company) [Internet Widgits Pty Ltd]: <-- Vállalat vagy szervezet neve
Organizational Unit Name (eg, section) []: <-- Részleg neve (pl.: informatikai részleg)
Common Name (e.g. server FQDN or YOUR name) []: <-- A rendszer teljesen minősített tartományneve (pl.: mail.sajatdomain.hu)
Email Address []: <-- A webmester vagy rendszergazda e-mail-címe
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []: <-- Enter billentyű lenyomása szöveg bevitele nélkül
An optional company name []: <-- Enter billentyű lenyomása szöveg bevitele nélkül
writing RSA key

Symlink ISPConfig LE SSL certs to postfix? (y,n) [y]:  <-- Enter billentyű lenyomása szöveg bevitele nélkül
Symlink ISPConfig LE SSL certs to pureftpd? Creating dhparam file takes some times. (y,n) [y]:  <-- Enter billentyű lenyomása szöveg bevitele nélkül

Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
.............................................................+.........................................................................................................................................................................+...................

Configuring DBServer
Installing ISPConfig crontab
no crontab for root
no crontab for getmail
Detect IP addresses
Restarting services ...
Installation completed.

Ezt követően pedig a 8080-as porton máris be tudunk jelentkezni az ISPConfigba. A felhasználónév és a jelszó azonos (admin), ám a jelszót az első bejelentkezés után erősen javasolt megváltoztatni!

https://mail.sajatdomain.hu:8080

E-mailes értesítés az SSH-bejelentkezésekről

Egy nyilvános szerver esetén érdemes minden óvintézkedést megtenni annak érdekében, hogy minden furcsa eseményről értesüljünk. A parancssori (SSH-) bejelentkezés egy kiemelten kritikus pontja a rendszerünknek, még akkor is, ha a korábbi lépéseket követve mindenkit bezártunk a saját könyvtárába. Az események nyomon követését segíti, ha e-mailes értesítést kapunk az SSH-s bejelentkezésekről. Ehhez először is hozzuk létre a figyelést végző szkriptet:

nano /usr/sbin/user-monitor.pl

#!/usr/bin/perl
# user_monitor.pl v0.4 :: keep track on who's logged in
# Written by Stephan Schmieder - http://www.unix-geek.info, 2003
# Usage: ./user-monitor.pl&

use strict;
use warnings;
use diagnostics;
use Net::SMTP;

#configuration
my $server =`uname -a|cut -d" " -f2`;
my $smtp_server ='localhost';
my $mail_to     ='root@mail.sajatdomain.hu';
my $mail_from   ='root@' . $server;
my $subject     ="$server :: User login monitor";
#configuration

my @old_users=split(/n/, qx/who/);
while(sleep(60))
{
        my @users=split(/n/, qx/who/);
        if(@users ne @old_users)
        {
                my $smtp = Net::SMTP->new($smtp_server);
                die "Couldn't connect to server" unless $smtp;
                $smtp->mail( $mail_from );
                $smtp->to( $mail_to );
                $smtp->data();
                $smtp->datasend("Subject: $subjectnn");
                foreach my $user (@users)
                {
                        $smtp->datasend("$usern");
                }
                $smtp->dataend();
                $smtp->quit();
        }
        @old_users=@users;
}

A root@mail.sajatdomain.hu helyére azt az e-mail-címet írjuk, ahová az értesítéseket kérjük.

FONTOS!
A szkript a rendszer saját postfix szolgáltatását használja a kimenő levelekhez, és elég kevés információt tesz bele a levélbe, ezért könnyen lehet, hogy az olyan nagyobb rendszerek, mint a gmail, levélszemétként észlelik az így küldött üzeneteket. Érdemes engedélyezési listára (whitelist) tenni a feladót, de a fenti szkriptet át is lehet írni igény szerint (akár egy külső SMTP-szolgáltatás, például a Postmark használatára).

Ezután módosítjuk a futtatási engedélyeket:

chmod 755 /usr/sbin/user-monitor.pl

Ahhoz, hogy a szkript minden rendszerindításkor elinduljon a háttérben, felvesszük a crontab bejegyzései közé a következő sor beszúrásával:

nano /etc/crontab

@reboot root    /usr/sbin/./user-monitor.pl&

Most pedig elindítjuk kézzel:

/usr/sbin/./user-monitor.pl&

A sikeres indítást követően meg kell jelennie a futó folyamatok listájában:

ps aux | grep monitor.pl

root      1026  0.0  0.2  59548 11380 ?        S    Aug09   0:22 /usr/bin/perl /usr/sbin/./user-monitor.pl

Összegzés

A fenti lépéseket követve egy biztonságos, éles üzemben is használható LAMP-kiszolgálót kapunk, amely ráadásul egy webes kezelőfelületen keresztül menedzselhető. Akár késznek is nyilváníthatjuk, ha az alapfunkciókon felül különösebb igényeink nincsenek, de alapul is szolgálhat a további testreszabásokhoz.

Kiindulási pontként tegyük fel, hogy van egy virtuális gépünk (VPS), amelyet elhelyeztünk egy szolgáltatónál, vagy pedig saját magunk üzemeltetünk. Mivel a VPS esetén az erőforrásokat dinamikusan, az igények megváltozásával összhangban tudjuk kiosztani, így amikor elkezd elfogyni a tárhely, egyszerűen csak több tárterületet adunk a gépnek, és ez a változtatás azonnal életbe is lép.

Igen ám, de mi a helyzet a partíció megnövelésével? Attól még, hogy a virtuális gép rendelkezik a megfelelő erőforrásokkal, a meglévő partíciós sémánk és partícióink nem fogják rögtön használatba venni a rendelkezésükre álló tárhelyet. Szerencsére a manapság használatos rendszerek esetén már nincs szükség új partíciók létrehozására, megformázására, adatok másolgatására vagy a rendszer újraindítására. Néhány egyszerű lépésben birtokba vehetjük a plusz kapacitást.

Előkészületek

Mielőtt bármilyen parancsot is futtatnánk, először is meg kell győződnünk arról, hogy a gépünk rendelkezik a megnövelt kapacitással. Ha a szolgáltató felületén megrendeltük a nagyobb tárhelyet, vagy a saját üzemeltetési környezetünkben kiosztottuk a további erőforrásokat, a következő parancsok futtatásával azonosíthatjuk be a későbbi parancsokhoz szükséges partíciót és a rendelkezésre álló hely mennyiségét:

blkid

A segítségével megjeleníthetjük a jelenleg elérhető partíciókat és az azonosítójukat, valamint a használt fájlrendszer típusát. Utóbbi fogja meghatározni, hogy az alábbiakban pontosan mely parancsokkal tudjuk megnövelni a fájlrendszer méretét.

lsblk

A segítségével megjeleníthetjük a lemezek és partíciók listáját, továbbá láthatjuk, hogy valamelyik lemezen rendelkezésre áll-e a számunkra a még kiosztatlan tárterület.

A partíció megnövelése

Ha meggyőződtünk arról, hogy ext2/3/4 vagy xfs fájlrendszert használunk, illetve hogy rendelkezésünkre áll a szabad tárhely, akkor következő lépésként meg kell növelnünk a kiszemelt partíció méretét. Ehhez először meg kell győződnünk arról, hogy rendelkezünk a megfelelő parancs futtatásához szükséges csomagokkal a rendszeren:

sudo apt -y install cloud-guest-utils gdisk

(Ubuntu/Debian rendszer esetén)

sudo yum -y install cloud-utils-growpart gdisk

(CentOS/Fedora/RHEL rendszer esetén)

Tegyük fel, hogy a megnövelendő partíció a fenti példában is látható /dev/vda1. Ebben az esetben a használandó parancs a következő:

sudo growpart /dev/vda 1

(Ügyeljünk arra, hogy a partíció száma előtt egy szóköz is van!)

Ha most lefuttatjuk az lsblk parancsot, akkor már a megnövelt partícióméretnek kell megjelennie.

A fájlrendszer megnövelése

Egyetlen feladatunk maradt hátra, és ez a tényleges tárhely használatba vétele. Ehhez ext2/3/4 fájlrendszer esetén a következő parancsot kell kiadnunk:

sudo resize2fs /dev/vda1

xfs fájlrendszer használata esetén pedig a következő parancsot:

sudo xfs_growfs /

Ha nem a root fájlrendszert méretezzük át, akkor használhatjuk az alábbi szintaxist is:

sudo xfs_growfs -d /dev/vda1

Most már csak annyi a dolgunk, hogy ellenőrizzük, életbe léptek-e a változások:

df -hT | grep /dev/vda

Ha minden jól ment, máris rendelkezünk a megnövelt tárhellyel, és ehhez még csak a rendszert sem kellett újraindítani!