Storage Server használata WordPresshez: mi működik, és mi nem

A wp-content/uploads könyvtár a WordPress azon része, amely fékezhetetlenül nő. Képek, PDF-fájlok, videók, ezen felül minden képből több méret, amelyet a WordPress automatikusan elkészít. Néhány év után több tucat gigabájt fekszik ott, és a webszerveren lévő hely a legdrágább, amit vásárolni lehet.

Egy Storage Server ennek a töredékébe kerül. A kérdés csak az, mi helyezhető át valóban. A neten sok olyan olvasható erről, ami a gyakorlatban nem működik. Ez a cikk tisztán szétválasztja a három esetet.

A három eset áttekintése

Az utolsó pont az, amelyen a legtöbben elbuknak. Ezért álljon itt először a kényelmetlen igazság.

Miért nincs bővítmény a médiatárhoz

A WordPress ismert kiszervező bővítményei mind ugyanazt a nyelvet beszélik: S3. Az Amazon S3-hoz vagy egy kompatibilis szolgáltatáshoz kapcsolódnak, feltöltik oda a fájlt, törlik a helyi példányt, és a bejegyzésben lévő címet a szolgáltatás egy nyilvános címére cserélik.

Pontosan ez nem vihető át egy Storage Serverre, mégpedig két okból:

• A tárhely beszéli az SMB, az SFTP és a WebDAV protokollt, de S3-at nem.
• Fájlonként nincs nyilvános cím. Minden hozzáférés hitelesítéshez kötött, tehát nem létezhet olyan hivatkozás, amelyet a látogató böngészője közvetlenül meghív.

Van néhány bővítmény, amely FTP-vel dolgozik, de egy sincs említésre érdemes elterjedtséggel és friss gondozással, amely a médiatárat teljesen SFTP-n vagy WebDAV-on keresztül szervezné ki. Aki talál ilyet, az a bevetés előtt nézze meg a legutóbbi frissítés dátumát és az aktív telepítések számát.

Az út, amely működik: csatolás kiszervezés helyett

Saját szerveren, root jogokkal a dolgot meg kell fordítani. Ahelyett, hogy a WordPresst tanítanánk meg idegen tárhellyel beszélni, a tárhelyet hozzuk arra a helyre, ahová a WordPress amúgy is ír:

apt install -y cifs-utils
mkdir -p /mnt/storage
printf 'username=u123456-sub1\npassword=AZ_ON_JELSZAVA\n' > /etc/samba/storage.cred
chmod 600 /etc/samba/storage.cred

Bejegyzés az /etc/fstab fájlba:

//u123456.storage.kernelhost.net/backup /mnt/storage cifs credentials=/etc/samba/storage.cred,uid=www-data,gid=www-data,file_mode=0660,dir_mode=0770,seal,_netdev,nofail 0 0

Utána a meglévő fájlokat át kell költöztetni, és a könyvtárat kicserélni:

mount -a
mkdir -p /mnt/storage/uploads
rsync -a /var/www/example.com/wp-content/uploads/ /mnt/storage/uploads/
mv /var/www/example.com/wp-content/uploads /var/www/example.com/wp-content/uploads.alt
ln -s /mnt/storage/uploads /var/www/example.com/wp-content/uploads

A WordPress ebből semmit nem érzékel, az alkalmazás számára ez egy teljesen közönséges útvonal. A régi könyvtár uploads.alt néven ott marad, amíg le nem ellenőrizte, hogy minden működik. Csak akkor törölje, előbb ne.

A csapda ebben: a bélyegképek

A WordPress minden képből több méretet készít, és minden oldalletöltésnél betölti őket. Ha ezek az apró fájlok a hálózati tárhelyen fekszenek, fájlonként hozzáadódik a hálózati késleltetés, és egy negyven képes galéria negyvenszer várakozik.

Két megoldás, mindkettő jó:

• Tenni elé egy köztes tárolót, például egy gyorsítótárat a webszerverben, amely helyben tartja a kiszolgált fájlokat.
• Csak az eredetiket tenni a tárhelyre, és az elkészített méreteket helyben hagyni. Ez kissé több munka, de sok képet tartalmazó oldalaknál ez a legtisztább út.

Biztonsági mentés: a leggyorsabb haszon

Ha csak egyetlen dolgot tesz meg, akkor ezt. Az ugyanazon a szerveren tartott mentés nem mentés: ha a lemezt letörlik vagy a weboldalt titkosítják, a mentés is vele együtt tűnik el. Külön tárhelyen viszont túléli.

Az ingyenes WPvivid bővítmény már az alapváltozatában tud SFTP-n keresztül a tárhelyre menteni, ütemezéssel és megőrzési szabállyal. A teljes útmutató ehhez a WordPress-mentések a Storage Serverre cikkben áll.

Saját szerveren még jobban megy, mégpedig rsynccel vagy BorgBackuppal, közvetlenül egy ütemezésből. Ilyenkor csak a változásokat viszi át, a BorgBackup pedig ráadásul deduplikál is.

Nagy letöltések kiszolgálása

Azokhoz a fájlokhoz, amelyeket a látogatók letöltenek, a tárhely ideális: ritkán olvassák őket, nagyok, és nem kell gyorsnak lenniük, csak célba érniük. A hozzáférés egy kis szkripten keresztül fut, amely előtte ellenőrzi a jogosultságot:

<?php
// a functions.php fájlban vagy önálló bővítményként
add_action('template_redirect', function () {
    if (!isset($_GET['kh_download'])) {
        return;
    }
    if (!is_user_logged_in()) {
        wp_die('Kérjük, jelentkezzen be', '', ['response' => 403]);
    }

    $pfad = '/mnt/storage/downloads/' . basename($_GET['kh_download']);
    if (!is_readable($pfad)) {
        wp_die('A fájl nem található', '', ['response' => 404]);
    }

    header('Content-Type: application/octet-stream');
    header('Content-Disposition: attachment; filename="' . basename($pfad) . '"');
    header('Content-Length: ' . filesize($pfad));
    readfile($pfad);
    exit;
});

A példa csatolt tárhelyet feltételez. Csatolás nélkül a readfile() hívást SFTP- vagy WebDAV-lekérésre cseréli, ahogyan azt a Storage Server használata a saját weboldalhoz című cikk leírja.

A mellékhatás kellemes: mivel a fájlnak soha nincs nyilvános címe, senki nem tudja továbbadni a hivatkozást. A jogosultság-ellenőrzést nem lehet kijátszani.

Mi marad osztott webtárhelyen

Osztott webtárhelyen a HTTPS-en futó WebDAV a legmegbízhatóbb út, mert a 443-as port gyakorlatilag soha nincs tiltva. Az SFTP szintén működik, nálunk viszont a 23-as porton fut, és nem minden szolgáltató engedi a kimenő kapcsolatokat ilyen portokon. Ezt a megrendelés előtt érdemes röviden ellenőrizni.

Célonként egy alfiók

Minden Storage Server legfeljebb 100 alfiókot engedélyez, mindegyiket saját kezdőkönyvtárral, saját jelszóval és saját protokollengedélyekkel. A WordPress esetében ez legalább kettőt jelent:

• Egy fiók a weboldalnak, amely csak az /uploads könyvtárat látja.
• Egy fiók a biztonsági mentéseknek, amely csak a /backup könyvtárat látja.

Ha a weboldalt egyszer átveszi valaki, a támadó a wp-config.php fájlban megtalálja az első fiók hitelesítő adatait. A mentések érintetlenek maradnak, mert ez a fiók nem is ismeri őket. Egyetlen főfiókkal ezen a ponton minden odalenne.

Ha több felhasználónak saját helyre van szüksége

A Storage Server nem ismer alfiókonkénti kvótát. A fiók a saját könyvtárában marad, ott viszont az egész tarifát megtöltheti. Aki az ügyfeleknek, fotósoknak vagy szerkesztőknek egyenként korlátozott kontingenst akar adni, az ezért egy alkalmazást tesz elé, amely ezt elvégzi. Erre a Nextcloud a legkézenfekvőbb, magával hozza a felhasználókat, a kvótákat és a megosztási hivatkozásokat: Nextcloud összekapcsolása a Storage Serverrel.

Melyik tarifa illik

Egyetlen WordPress-oldalhoz, mentésekkel együtt, a Storage-1 általában hosszú időre elég. Aki több oldal médiatárát szervezi ki, vagy videóval dolgozik, az hamar a Storage-2-nél vagy a Storage-3-nál landol. Minden tarifa Németországban áll, beállítási díj nincs, az elszámolás PrePaid alapú, és nincs minimális futamidő. A következő nagyobb tarifára bármikor át lehet váltani, anélkül, hogy az adatokhoz hozzá kellene nyúlni.