Syscp bemutatása

A lap jelenlegi, 2010. január 29., 11:50-kori változata

Írta: Murányi Gergely, 2010. január.

[szerkesztés] 1 Általános leírás

A Syscp egy nyílt forráskódú php-ben megírt Linux/FreeBSD disztribúciót használó szerverek adminisztrálására használható sok nyelvre lefordított adminisztrációs felület. A felület fejlesztése 2003. óta tart; egy ideig a honlap csak német nyelven volt elérhető, mára azonban szerencsére nagyon sok anyag, leírás, wiki oldal angolul is megtekinthető. Ebben a leírásban az 1.4.2.1-es verzióra fogok támaszkodni.

Sajnos hiányzik egy rendes dokumentáció; én személy szerint azért elvárnám egy ennyi idős projekttől, hogy egy valamirevaló dokumentáció létezzen, és ne a wikiről, fórumokról, forrásból böngészve kelljen az embernek a megfelelő megoldást megtalálnia.

A felület az alábbi programcsomagok webes konfigurálását teszi lehetővé:

Adatbázis szerver: MySQL

Böngésző: Apache, Apache 2.x, Lighttpd

DNS szerver: Bind9, PowerDNS

Pop3/IMAP szerver: Courier, Dovecot

SMTP szerver: Postfix, Exim4

FTP szerver: ProFTP, PureFTP

Statisztika: Awstats, Webalizer

Támogatott disztribúciók

Debian 4.0 (Etch)

Debian 3.1 (Sarge)

Ubuntu 8.04 (Hardy Heron)

Gentoo Linux

OpenSuSE Linux 10.0

FreeBSD

Ezen kívül nem túl nagy áldozattal minden valószínűség szerint az összes Linux disztribúcióra is fel lehet telepíteni a szoftvert, egyedül talán a cron scripteket kell kicsit az adott disztribúció szájízére szabni.

A rendszer felépítése

Fájl:syscp components.jpg

[szerkesztés] 2 Telepítés

A telepítés megkezdése előtt mindenképp szükséges, hogy a webszerver php5-el illetve a MySQL-szerver fel legyen telepítve, és működjön is.

A konfiguráció eléggé magától értetődő: első körben a rendszer rákérdez a használni kívánt nyelvre, MySQL adatbázisnak a nevére amelyben a felület tárolja majd az adatokat, jelszóra, illetve a MySQL-szerver root jelszavára, admin felhasználó / jelszóra, illetve egykét szerverbeállításra. Ezek után lefuttat egy tesztet, felhívja a figyelmünket egy-két beállitásra, majd irány a bejelentkezés.

Kezelőfelület

A telepítés során nekünk a Server fül, Configuration és Settings pontjára lesz szükségünk. Amikor végeztünk a Settings ponttal, jöhet a Configuration. Itt ki tudjuk választani a kívánt szolgáltatást, a felhasznált disztribúciót. Ezután a felület felajánla a futtatandó shell parancsok sorát, illetve a módosítandó config fájlokat.

Könyvtárstruktúra

Érdemes megemlíteni a Syscp könyvtárstruktúráját: A honlapok /var/customers/web/felhasználónév/domainnév/ struktúrában találhatóak. A logok a /var/customers/log/felhasználónév/, a levelek a /var/customers/mail/felhasználónév, a tmp fileok a /var/customers/tmp/felhasználónév/ könyvtárakba kerülnek. A domainnéven és a felhasználónéven kívül a könyvtárfa összes többi részét specifikálni lehet a server / settings részben, érdemes ezeket jól kitalálni még az elején.

Megjegyzések

Mivel mindenkinek megvan a saját maga preferenciája, ezért nem megyek abba bele, hogy tanácsokat osztogassak milyen levelező szervert, illetve milyen webszervert használjunk. Én személy szerint az apache2-fastcgi,php5, postfix, courier/dovecot, bind9, pureFTPd megoldást használom. Két hasznos dologra azonban fel szeretném hívni a figyelmet:

• FastCGI (leginkább apache alatt, lighttpd alatt igy is, úgy is fastCGIhez nyúl az ember): Mindenképpen érdemes a Settings / Security optionsban a mod_fcgid/suexec/libnss_MySQL beállításokat használni. Ennek a következő előnyei vannak:

• minden felhasználót egy saját uid alatti FastCGI php processz szolgál ki (a felhasználók egymás fájljait nem tudják módosítani)

• mert skálázhatóbbak a FastCGI processzek, adott esetben akár más szerveren is lehet őket futtatni

• mert minden domain egyedi php.ini filet tud használni, nem kell egy központi php.ini-re hagyatkozni, majd utána php_admin_value-kal szórakozni

• mert a suexec egy halom biztonsági ellenőrzést elvégez mielőtt elindít egy FastCGI processzt [1].

• mert libnss_MySQL-el a MySQLben tárolt usernevek a rendszer 'részei' lesznek, shell alól pont ugyanúgy fognak látszani mint a tradicionális passwd fileban tárolt felhasználók [2]

A FastCGI Syscp beállításokrol pedig itt: [3]

Mindezeken felül, igazi perverzeknek, ez a beállitás nagyban megkönnyíti (a különböző usernevek miatt) a FastCGI processek RSBAC-ban való elszigetelését. RSBAC-ról bővebb dokumentációt a fejlesztő által írt könyvben találsz. Sajnos fizetős, de megéri.

• És egy kis kényelmi funkció: a Settings / System settings részben, a Port for realtime SysCP-be beleírva a megfelelő portot, el tudjuk érni, hogy minden változtatáskor, a mentés gombra nyomva azok egyből működésbe lépjenek, ne kelljen megvárni az 5 perces időközöket amíg a crontab lefut. Ehhez fel kell telepítenünk egy xinetd-t a standard inetd helyett. Ezek után a control panel nyit egy tcp kapcsolatot a megadott portra (amin az xinetd figyel), mire az elindítja a konfigurációs fileban megadott php filet.

Erről bővebb leírást itt lehet találni: [4]

[szerkesztés] 3 Használat

Felhasználó / domain hozzáadása

Syscpben minden domain egy felhasználó alá tartozik, tehát első körben létre kell hoznunk egy felhasználót, majd létrehozni a domaint amit az adott felhasználóhoz adunk. Érdemes a kvótákat(web tárhely, email tárhely, fiókok száma, MySQL adatbázisok száma, FTP felhasználók száma) minden felhasználó esetében korlátlanra állítani, majd egyenként a hozzáadott domainek esetében limitálni. A felhasználó hozzáadásánál lehetőség van jelszót készíteni a felhasználónak, amivel ő maga tudja majd a beállításait kezelni.

Hasznos opció az emaildomain opció a mailserver settings részben, ha ezt no-ra állítjuk, akkor értelemszerűen a szerverünk nem fog mailszerverként funkcionálni, az SMTP szerver figyelmen kívül hagyja a domainünket. Ezt azért írtam le, mert ha a levelezés mondjuk egy másik szerveren található, de a domain már nálunk van, és kimenő szervernek a saját szerverünket használjuk, akkor könnyen belefuthatunk abba a problémába, hogy a Postfix (az én esetemben) közli, hogy ilyen postafiók nem létezik, holott mi tudjuk, hogy a MX-rekordban szereplő szerveren létezik a postafiók. Sajnos a postfix valamiért ilyenkor figyelmen kívül hagyja a DNS recordot, és közvetlenül a saját adatbázisát veszi alapul. Ha erre bárki tud valami magoldást, akkor kérem ossza meg velem.

Ezen kívül még relatíve sűrűn használt opcio a nameserver settingsben a zónafájl, ahol a névszerver könyvtárától (én esetemben /etc/bind) vett relatív elérési úttal meg tudjuk adni a saját magunk által elkészített zónafájl elérési útját.

Levelezés, adatbázis, ftp, aldomainek

Az alcímben felsorolt összes feladatot a resources / customers részben lehet kezelni. Itt ha rányomunk a felhasználó nevére, akkor átjutunk egy az egyben arra a felületre amire a felhasználó is bejut a jelszavának megadásával. A felület kezelése triviális, annyi megkötésünk van, hogy a Syscp az sql adatbázisoknak / userneveknek illetve az ftp fiókok usernevének egy előre definiált rendszer szerint (kicsi beleszólásunk a telepítéskor van) adja a nevét, nincs módunk teljesen egyedi user/adatbázis nevek megadására. Ez első körben a szabadságjogaink erős korlátozásának tűnhet, de több mint fél éves használat után, ez egyáltalán nem jelentett gondot. Pl. az én esetemben joco user esetében joco első adatbázisa jocosql1, második adatbázisa jocosql2 stbstb.

[szerkesztés] 4 Egykét ajánlott módosítás a Syscp forrásában

• Postmaster email címek

Egész idáig nem találtam arra megoldást, hogy postfix alatt hatékonyan megoldjam azt, hogy a postmaster@* email címek mind landoljanak egy előre megadott email címre, úgy, hogy én ezeket a postmaster@* email címeket előzetesen hozzá ne adtam volna a virtual táblába. Erre azért lenne szükség, mert magyarországon ahhoz, hogy egy .hu-s domain nevet beregisztráljunk, szükség van egy postmaster@domainnév email címre, ami minden egyes domain hozzáadásakor felesleges klikkelgetést jelent.

admin_domains.php 509. sor után beszúrni:

$db->query("INSERT INTO `" . TABLE_MAIL_VIRTUAL . "` (`customerid`, `email`, `email_full`, `iscatchall`, `domainid`,`destination`) VALUES ('" . (int)$customerid . "', 'postmaster@" . $db->escape($domain) . "', 'postmaster@" . $db->escape($domain) . "', '0', '" . (int)$domain_check['id'] . "','domain@sajatdomain.hu')");

Fontos, hogy a query legvégén levő domain@sajatdomain.hu helyére érdemes beírni a létező email címet ahova szeretnénk a postmaster emaileket továbbítani ezek után. A wiki egy következő verziójában egy diff által készített patch filet is beszúrok megígérem...

• Safemode / safemode warning

Van a Syscpnek egy idegesítő tulajdonsága, miszerint a Safemode új domain hozzáadásánál automatikusan be van állítva, és ezek után, ha az ember kikapcsolja akkor még külön rá is kérdez, biztos vagyok-e benne, hogy ki akarom kapcsolni. A tapasztalat azt mutatja, hogy a safemode akkor működik a legflottabbul, ha ki van kapcsolva, alapvetően ami feladatot a safe mode meg akart valósítani, azt nem phpból kell csinálni (hanem pl. a fent említett suexec/FastCGI megoldással, netalán Suhosin-nal). Ahhoz, hogy alapjáraton kikapcsolt legyen a Safemode új domain hozzáadásánál, az admin_domains.php 708. sorát kell átírni:

$safemode = makeyesno('safemode', '1', '0', '1');

helyett inkább:

$safemode = makeyesno('safemode', '1', '0', '0');

Most már csak a warningot kell megszüntetni, mégpedig az admin_domains.php 580. és 1093. sorában:

ezt:

'reallydisablesecuritysetting' => (($openbasedir == '0' || $safemode == '0') && $userinfo['change_serversettings'] == '1')

erre:

'reallydisablesecuritysetting' => ($openbasedir == '0' && $userinfo['change_serversettings'] == '1')