Syscp bemutatása

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 ([1]) 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. A fejlesztők elmondása szerint az 1.4-es verzióba az 1.2-es verzió óta annyi commit került az SVN-be, mint az 1.2-es verzióig összesen...

A rendszer előnyei között kell megemlíteni a rendszeres SVN verziókat, a felmenő verziókkal való kompatibilitást, a teljes mértékig phpben megírt forrást, wiki / forum támogatást, ticketing systemet, illetve alapszintű számlázási információk kezelését.

Hátrányok között említeném a dokumentáció hiányát, én személy szerint azért elvárnám egy ennyi idős projekttől, hogy egy valamire való 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.

Támogatott szoftverek

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

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ázis névre, jelszóra, illetve a mysql root jelszóra, admin felhasználó / jelszóra, illetve egykét szerverbeállításra. Ezek után lefuttat egy tesztet, felhívja a figyelmünket egyké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. A Settings pontban miután végigzongoráztunk minden beállitást, a Configuration pontban kiválasztva a használt disztribúciót és szolgáltatást a felület felajánlja milyen shell parancsokat kell kiadnunk, és hogyan kell módosítanunk a szolgáltatások konfigurációs filejait hogy együttműködjön a rendszerrel.

Könyvtárstruktúra

Érdemes megemlíteni a Syscp könyvtárstruktúráját: A honlapok /var/www/customers/web/felhasználónév/domainnév/ struktúrában találhatóak. 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. A felhasználókhoz tartozó levelek a mail, a logok a log, a tmp fileok értelemszerűen a tmp könyvtárakba kerülnek, minden felhasználó esetében külön alkönyvtárban.

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 [2] (leginkább apache alatt, lighttpd alatt igyis úgyis fastCGIhez nyúl az ember): Mindenképpen érdemes a Settings / Security optionsban a mod_fcgid/suexec/libnss_mysql beállításokat használni. Miért jó ez nekünk azon kívül, hogy a kezdeti beállitás kicsit több ideig tart? Azért mert:

-minden felhasználót egy saját uid alatti fastCGI php process szolgál ki (a felhasználók egymás filejait nem tudják módosítani)

-mert jobban skálázhatóak a fastcgi processek, 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 process-t [3].

-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 [4]

A fastCGI Syscp beállításokrol pedig itt: [5]

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. [6]

• É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-nk figyel), mire az végrehajtja a konfigurációs fileban megadott php filet.

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

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 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 opcio a mailserver settings részben, ha ezt no-ra állítjuk, akkor értelemszerűen a szerverünk nem fog mailszerverként funkcionálni. Ennek az a gyakorlati haszna, hogyha 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 recordban szereplő szerveren létezik a postafiók. Sajnos azonban 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 zone file, 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 zona file 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.

Egykét érdemes módosítás a Syscp forrásában

• Postmaster email címek

Egész idáig nem találtam arra megoldás, hogy postfix alatt hatékonyan megoldjam azt, hogy a postmaster@* email címek mind landoljanak egy alőre megadott email cimre, úgy, hogy én ezeket a postmaster@* email címeket előzetesen hozzá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. Ennek a problémának az orvoslásához, két helyen kell a Syscp forrásába belenyúlnunk.

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, ki van kapcsolva, alapvetően ami feladatot a safe mode meg akart valósítani, azt nem phpból kell csinálni. 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');

Mostmár csak a warningot kell megszűntetni, mégpedig admin domains 580. és 1093. sorában:

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

erre:

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