Project: Mass-Virtual-Hosting [BRAINSTORMING]

Segédprogramok

Felcsattintok egy komolyabb témát és ebben szeretnék segítséget kérni.

Prológ:
Első munkáim között szerepelt egy webhoszting panel még a windows 2003 -as korszakban, és ez odáig fajult, hogy FreeBSD 10-en full C++ -ba írt saját webadmin futkorászik a szervereimen, mysql,apache-mpm-itk,nginx (flood protection,cache),postfix,courier,sasl,pure-ftpd,powerdns,amavisd,postfwd(mail outgoing limit) társaságában.

Mivel a csomagok elavultak a jelenlegin (BSD) és akármilyen unix-like párti vagyok beláttam, hogy Debian kelendőbb meg jobb a HW támogatása, így ezt egy új keretrendszerrel(C++ és LUA) és UI -val portolnám debian -ra.

Mivel kinőttem a birtoklási vágyakból, úgy látnám értelmét, hogy elérhető lenne mindenki számára 0 forintért.

Ergó publikálnék egy Cpanel szerűt. Most a csavar az egészben, hogy az én ügyfél köröm, külön örvend annak hogy nem egy túl
bonyolított katyvasz (jelenlegi) az egész és ami van az mindenre elég és működik, szóval letisztult mindent tudó ideális Small-Business számára és nem turkál meg irogat konfigokba, így a rendszergazdák szabad kezet kapnak az OS felett. Külön megemlítem, hogy per-user vagy per-site privilégiumra épül, ergó fájlrendszer jogokkal védve van minden tárhely, egymástól függetlenül, de van rá lehetőség domain/aldomain prefixelésére mappán belül azonos jogokkal és nem azonos jogokkal is.

mySQL táblákból veszi az infót, ott is amit lehet szeparált db/user jogokkal.
Lenne egy worker process meg egy frontend, ami nem PHP hanem a rendszer része, így a szolgáltatásoktól független.

A projekt szabadidős, de kb 1 hónapon belül megvan.
Amit szeretnék tőletek az egy rohadt nagy BRAINSTORMING, hogy ha már "yet another... cpanel like crap" -et csinálok, használható legyen, mert lenne sikere és lehet dobálni kövekkel.. de nekem nem jön át a cpanel se az ispconfig se a többi ...

- Szóval mi az amit utáltok, vagy hiányoltok az ilyen rendszerekben?
- Telepítés, Üzemeltetés, Hibakeresés, Frissítés..
- Funkciók, S.M.A.R.T,CPU,MEM graph? Inline editor a konfigokhoz?
- Backup, Rollback, Import, Export?

P.S:
Tudom, van már 100 + 1 ilyen rendszerekből, ez a 102. lesz. és?

Update (2016-03-01):
Köszönöm a segítségeteket és az ötleteket.
- Teljesen a Backend/API -ra fókuszálva.
- Release Plan kész (https://devel.npulse.net/lmvh/release)
- Import/Export/IMAP SYNC!/ZFS Opcionális Támogatása
- OS: Debian-Like / FreeBSD
- Stage: API/Backend devel
- Highlights: Security, Lightweight, Simplicity, Speed, Portability
- Pricing: Free-of-Charge

Update (2016-03-15):
- Backend Engine Kész.
- API Engine Kész.
- Teszt API kész (json) (PHP)
- Frontend via Backend Kész
- Felhasználó Kezelés: Backend, API, Frontend Kész
- Domain Kezelés: Backend, API, Frontend Kész (Featuring: DNSSEC)
- Csomagok Kezelése: Backend, API, Frontend Kész.

  • 6718 megtekintés

( Pene | 2016. 02. 23., k – 13:35 )

én szívesen tesztelem, ha már ott tart a projekted majd. amúgy kissé ódzkodom ezektől. szemetelnek, sokszor rákényszeríten(én)ek (ha használnám) felesleges dolgok feltelepítésére, és szerintem viszonylag nagy biztonsági kockázatot jelentenek, ha nem frissíted őket rendszeresen és időben, ami viszont relatíve sokszor eredményez törött weboldalakat és szolgáltatásokat. a debug és a log része meg sohasem tetszett. az ma már kevés, hogy adott statikus logfile-okat meg tudjak nézni. on air keresési funkció kell ezekben stb.

ha én, mint az egyszeri rendszergazda használom egy ügyfél third party rendszerén, akkor biztos, hogy nehezebben találom meg a dolgokat, mintha command line kéne megoldani, emellett sokszor nem vagyok benne biztos, hogy mégis mit és mikor írok majd felül egy-egy beállítással (feature request: olyan funkció jó lenne, amivel "silent" meg lehet nézni, mi változik, ha ezt vagy azt átállítom).

ha én, mint az egyszeri programozó használom, akkor egyáltalán nem találom meg a dolgokat, maximum a phpmyadmint :)

ha pedig én az a rendszergazdi vagyok, aki ezt a rendszert üzemelteti, akkor meg szintén vegyes érzéseim vannak. tud jó lenni, meg problémás is. ezért is inkább skippelem ezeket a vezérlő felületeket. van létjogosultságuk, azt persze nem tagadom.

Teljesen egyetértek, pont ezért nem vagyok hajlandó cpanel -t telepíteni és a hasonlókat ha én üzemeltetek egy szervert akkor azt csak SSH -n vagyok hajlandó konfolni. Ugyanakkor kell vízuális megerősítés, pl diagrammok CPU és Memória használatra, mert nem mindig van időm és jut eszembe SSH -ra belépni, ha egy vinyónak beanyázik SMART -ja arról meg küldjön emailt, de ne kelljen scripteket irogatnom hozzá.

Éppen ezért akarok egy egyszerű felületet és az egyszerűség nem dizájn és feature lessből áll.

A schema a következő: vannak az /etc -n belül a configok .default -tagel a végén, a rendszerben lesz egy script amit ha a sysadmin lefuttat mindenhol lecseréli a jelszót (opcionálisan) (amit a rendszer kezel, md5(rand(y,x)..time())) és behúzza a .default configot a helyére, de nem indítja újra a szolgáltatásokat.

Így ahol .default is lesz, akkor majd azt érdemes configolni.

PL:


root@lmvh16:/etc/postfix/mysql# cat mysql_relay_domains_maps.cf.default
#Syntax with postfix 2.2.x:
user = {CONTROL_USER}
password = {CONTROL_PASS}
hosts = SQL
dbname = {CONTROL_DB}
query = SELECT name FROM local_domains WHERE name='%s'AND relay='1'

Mivel az accountok (NEM PAM!) mysql -ben lesznek tárolva (FTP,MailBox,Vhost Path,PHP Env,Domains) ezért azokat nem kell konfigolni új site vagy mailbox esetén.

Én a konfigokat szeretem meghagyni a rendszernek, és csak globális beavatkozásnak tervezem, pl: max levél küldés / óra / feladó (spam)

Biztonsági rések miatt pedig minden szolgáltatás külön DB külön ACC külön USER, chroot ha van rá lehetőség.

System Dash része meg már meg is van, az elöző projectből:

http://upload.npulse.net/image/49f8dd3dd0edfe0a586ff3cfeffd9603/
http://upload.npulse.net/image/30e1cd8f9c7ab80c6c25dd257c99b8f2/

A rendszer alap felépítése X éve megy mint osztott tárhely (elöző verzió) FreeBSD alapokon, eddig törés mentesen ;) Remélem és bízok benne, hogy Debianból is kitudom hozni a max security -t.

--
#define true ((rand() % 100)>3) // Happy debugging ...

( davies007 | 2016. 02. 26., p – 23:41 )

Update #1

Csomagok, minden webhelyhez rendelhető egy előre beállított tárhely csomag.
A csomagok létrehozásánál a következő választási lehetőségek vannak:

- Név
- Max Postfiókok száma
- Max Alias -ok száma
- FTP -k száma
- Adatbázisok száma
- Max Aldomainek
- Max Biztonságos Aldomainek (jailezett/fs sep. priv.)
- PHP Max Futtatási ideje
- PHP Max Post Méret
- PHP Max Mem Méret
- Összesített Max Kvóta (egybevont, db, mail, fs-level)
- Felfüggesztés típusa ha a kvóta túllépve, enum:
{ 'Csak figyelmeztet', 'Figyelmeztet és Limitál', 'Figyelmeztet és szünetel' }

http://upload.npulse.net/image/84eb8c7bf9613ac403bcb33b156047fe/
--
#define true ((rand() % 100)>3) // Happy debugging ...

( kila | 2016. 02. 27., szo – 08:09 )

- Ne legyen hozzánőve a MySQL/MariaDB-hez, menjen PostgreSQL-el és SQLite-al is.
- Jó lenne a ha a felhasználóit tudná venni/authentikálni LDAP-ból és AD-ból is.
- Működjön revese proxyn keresztül is.
- Képek nélkül az az konzolos/szöveges böngészővel is legyen használható (Lynx és társai).
- Az információiról tudjon szöveges riportot is adni.
- Esetleg valamilyen plugin/keret rendszer ami tud futtatni scripteket és más is egyszerűbben írhat hozzá dolgokat.

Inkább cli-ben/ssh-n szoktam intézni a dolgokat, esetleg pdmenu-vel kiegészítve.
--
Légy derűs, tégy mindent örömmel!

Update #2

Az API jó ötlet, mivel nem akarok root jogosultságú nyitott webszervert, ezért mindenképpen szükség van backendre, ami egyben az API is.

Tehát csapó-1, localhoston bindelő webserver (root joggal) ami csak API hívásokat tud és tulajdonképpen mindent, amihez csatlakozik majd a frontend és jelenleg egy PHP-CLI -vel kisérletezem, kommunikáció megvan, csak nem titkosított de nembaj mert a loopbacket sniffelni nem sokan fognak, meg ha valaki megnyitja a portot talán lesz annyi esze, hogy az SSL -est nyitja csak meg.

Metódus egyszerű, JSON tömbökkel dobálózunk..
Annyi a varázslat, hogy minden boldog és boldogtalan ne tudjon API -zni, hogy van egy API Key mindkét oldalon és annak úgy egyformának kell lennie, mert ezzel a kulccsal lesz aláírva sha256() az üzenet.


$_arr = array();
$_arr["DATA"] = json_encode($data);
$_arr["SEC"] = strtoupper(hash("sha256", $api_key.$_arr["DATA"]));
return "".json_encode($_arr)."";

A szöveges webinterface -t meg egyelőre hanyagolom ha kész a project betaként akkor lehet rágyúrni.

--
#define true ((rand() % 100)>3) // Happy debugging ...

( hrgy84 | 2016. 02. 28., v – 10:50 )

Abbol, amit lattam, alapvetoen tetszik a dolog. Amit en fontosnak tartok:

- opcionalisan tudjon tobb grafikont alapbol csinalni (postfix mailqueue, apache statok, mysql statok, etc), ugy, hogy nem latszik ki alatta, hogy ez most egy muninbol vagy mibol jon.
- Ne az Linux-Apache-MySQL-PHP szentnegyseg legyen az alap. Legalabb tamogasson Nginx-et, PostgreSQL-t es BSD-t ezek kozul, illetve az sem baj, ha a PHP mellett tamogat "custom vhost"-okat is, ahol teljesen en irom meg a konfigot, o csak a ServerName/DocumentRoot/ErrorLog/CustomLog jellegu dolgokat tolti ki alam/folem.
- Egyszeru, konnyen attekintheto SNI tamogatas, es notifikaljon ha a cert lejarofelben van. Opcionalisan a usernek is, ne csak az adminnak.
- Angol nyelvu felulet legyen valaszthato. Please.
- Legyen valami ertelmes per-account backup, amibol konnyu export/import packageket gyartani. Egy opcionalisan cryptelt duplicity backupot az export soran eleg ossze tar-olni valami kis metadata.json-nel, amibol ki tudja okmulalni, hogy miaf.
- A backupok onallo feltoltese FTP/NFS/S3/SMB/RSYNC tarhelyekre. Ne csak az FTP legyen. Duplicitynel raadasul mindez alapbol meg is van, csak a konfiguracios feluletke kell hozza (don't feel the pressure, a Duplicity csak egy pelda, mert ezt ismerem, hasznald azt, amit szeretnel).
- Ha mar FTP: FTP/TLS, SFTP alap, es nem csak a backupok feltoltesehez, de az accountokhoz is. ProFTPD tudja mind a harmat, de gondolom ez a problema tobbfelekeppen is megoldhato, megint csak tipp volt, nem pressure.
- Mindenkeppen legyen SSH key tamogatas, akar generalassal is egybekotve. Igen, tisztaban vagyok a security vonzataval, hogy a private key valamikor megjelenik a szerveren, meg ha temporary is, de jelenleg a fo akadaly a customereknel valo SFTP/keyonly kommunikacio bevezetesenek a kulcs legeneralasa, PITA elmagyarazni, secu threat emailben elkuldeni. Ennel egy on-the-fly generalas csak jobb lehet.
- Tobb admin user. Ne csak a root legyen, sot, legyen letilthato a default keszitett admin user teljesen, vagy lehessen a telepites soran custom usernevet adni neki.
--
Blog | @hron84
Üzemeltető macik

Köszönöm az ötleteket, minden szoftverem basically made with english primary language, utána lesz magyarral fordítva, tehát ez pipa.

nginx mint reverse proxy, custom configok generálása megoldott, SNI támogatás és mikéntje még kérdéses.

Admin Acc több lehet, de az alapérelmezettet letiltani nem lehet.
Admin és root teljesen különböző fogalom és az is marad.
SFTP Kulcsos megoldás kivitelezhető.

Import & Export az egyik legfontosabb, ha migrálás vagy upgrade van, akkor az mindenképp kell, és nem utólag!

PostgreSQL és BSD. Ha elkészül project Debian/mySQL -base re lesz annyira nyitott, hogy lehessen portolni a többire, pl SQL parancsokat külön lehet majd megadni. Szeretném majd ha lehetne pluginezni is. (LUA)

--
#define true ((rand() % 100)>3) // Happy debugging ...

"az alapérelmezettet letiltani nem lehet." - miert?

"Import & Export az egyik legfontosabb, ha migrálás vagy upgrade van, akkor az mindenképp kell, és nem utólag!"

Nyilvan, de a backupbol konnyu eloallitani, erre problatam utalni. a cPanel is igy dolgozik.

"lehessen portolni a többire"

Ne, ne kelljen portolni. Mar a fejlesztes kozben keszulj arra, hogy nem biztos, hogy MySQL engine lesz alatta. Ertem ez alatt, hogy a lekerdezeseket erdemes atvinni valami absztrakcios retegen, nem nyers SQL parancsokkal operalni, esetleg eleve objektum-orientaltan kozeliteni a dolgot. Hidd el, ez ugyan baromi sok munka az elejen, de kesobb halas leszel magadnak, ha igy indulsz el. Az admin felulet eseteben boven belefer, ha par ezredmasodperccel lassabb queryk futnak le.

Ugyanez a Linux/BSD tamogatas kapcsan. Eleve keszulj arra, hogy a szervizeket nem biztos, hogy ugy akarjak inditani, ahogy te jonak latod, hanem valahogy maskeppen.

"nginx mint reverse proxy"

A PHP-FPM tamogatas miert annyira bonyolult? Marmint, nem ertem, hogy miert gondolkodik minden panel csak Apache-ban meg mod_php-ban, mikor az Nginx+PHP-FPM pont ugyanolyan jo, sot.
--
Blog | @hron84
Üzemeltető macik

Egy része a dolgoknak abból indult, hogy van egy alapszabály ami SAJNOS sok esetben igaz: "Jól bevállt és működő dolgokat nem bántunk"

Jelen pillanatban egy réggebbi adminra és csomagokra épülő rendszer már több éve stabilan működik, és nem egy cég weboldala és levelezése fut rajta.

Én abból indultam ki, hogy meggyorsítja a folyamatot a rutin, a PHP-FPM - el az elején volt probléma ezért hanyagoltam, most már stabil tudom, de nem jutottam el odáig, hogy átnyálazzam. Úgy rendszert nem szívesen adnék ki, hogy találomra összeállítom, hiszen bennmaradhatnak sebezhetőségek, de mindenképp a rugalmasságra törekszem, és értem amit mondassz igen és tervezem is az absztrakt rétegek / template -k kiépítését is, hogy ne szívassam le magam később.

A többit egyszerűen pluginokkal illetve beállításokkal szeretném tovább fejleszteni több irányba, mivel a piacon új ismeretlen valaki által összerakott valami lesz, úgy is kelleni fog neki még kis idő mire kifejlődik egy irányba.

--
#define true ((rand() % 100)>3) // Happy debugging ...

( sj | 2016. 02. 28., v – 12:19 )

egy ilyen termeknek is megvan a maga celkozonsege, bar en inkabb irok egy ansible playbook-ot...

--
"nem tárgyszerűen nézem a dolgot, hanem a vádló szerepéből. Sok bosszúságot okoztak, örülnék ha megbüntetnék őket - tudom gyarló dolog, de hát nem vagyok tökéletes." (BehringerZoltan)

( pryus | 2016. 02. 29., h – 16:22 )

És ez mennyivel lesz jobbb mint egy virtualmin? Nem vagyok rendszergizda, de a felsorolt feature-ök ott is megvannak lsd: nginx, postgre, több php verzió, moddolhatóság(pearl) stb.
Persze hajrá, megfogom nézni én is :)

Jobb nem lesz, de más lesz. (Kevesebb néha több, ELV)

Ez a rendszer nem fogja teleszarni a rendszert meg a syslogot.

2 service -ből áll, backend, frontend. C++ és LUA

Nem nyúl bele a konfigokba, gyors, megbízható, biztonságos, portabilis.
Ha valami kefe van küldjön emailt, amúgy meg kussoljon és csinálja a dolgát ;)

A csomagokat szeretem én frissítgetni, vannak igények külön virtualhostokra akkor ne egy textbox-ba kelljen beírkálnom a VAR -okat, hogy majd ő pár perc múlva valahova belerakja. Ha kidöglik az egész gép, megakarom fogni az egészet, export & import és jó napot.

Szeretném automatán tudatni az userekkel, hogy ha létrehoz egy aldomaint és ha nem biztonságos üzemmódban van, akkor ha azt megtörik pl: (WordPress) hozzáfér a többihez is. Szeretném automatán rávenni őket, hogy egy gombnyomással saját magának csináljon biztonsági mentést ezzel se nekem kelljen foglalkoznom.

Kicsit bosszant, hogy a reptéren elhalásznak pár email címet és spammelnek róla, és nem lehet lelimitálni a levél kiküldést mert éppen beanyázik egy függőségre, amit nem lehet feloldani mert minden mindentől függ.

(Linux/FreeBSD)

Átlátható és a lehető legegyszerübb.
És ez biztos, mert pont azért készül, mert elegem van a többiből, python, perl, php keverék ha véletlenül az ember átír valamit tuti beszarik az egész.

És ha megspékelem ZFS -el, akkor tud snapshotot is, azt meg eddig ha jól tudom nem tud semelyik ;)

--
#define true ((rand() % 100)>3) // Happy debugging ...

" ha nem biztonságos üzemmódban van, akkor ha azt megtörik pl: (WordPress) hozzáfér a többihez is"

Van baj, van baj. Ezt pl. értelmezni sem tudom, az alapvetés az, hogy paraszonként külön user neve alatt futnak a site-ok (mpm itk, PHP-FPM külön pool), adott esetben chrootolva (az FPM ezt valódi chroot nélkül is tudja). Ha megtörik a site-ot, hát tessék, elvihetik azt az egyet oszt punktum.

"nem lehet lelimitálni a levél kiküldést mert éppen beanyázik egy függőségre, amit nem lehet feloldani mert minden mindentől függ."

Erre egy felelős rendszergazda a megoldás, nem egy automata panel, ami épp ugyanúgy nem fog tudni semmit kezdeni ezekkel a problémákkal.

"ha véletlenül az ember átír valamit tuti beszarik az egész."

Erre lásd előző pont. Mielőtt átírsz valamit, meg kell nézni, beszarhat-e tőle az egész, oda kell figyelni, meg kell érteni a rendszer működését, akkor is, ha egy kalap szar az egész.
--
Blog | @hron84
Üzemeltető macik

( gdavid v | 2016. 02. 29., h – 23:08 )

nem tudom vki emlitette-e de szerintem klassz lenne, ha tudna import/export-ot.
tehat ha van 2 szerverem, akkor vagy tudjam atmozgatni a user-t vagy tudjam exportalni itt es ott meg importalni.

Igen volt, róla szó és lesz.
Kiegészítettem a TODO -t egy IMAP Sync -el is mert hasznos ;)

Frissült a téma indító HSZ egy Update jelentéssel és egy Release Plan linkel.

U.I:

Köszönöm szépen az eddigi hozzászólásokat, ötleteket és véleményeket!

--
#define true ((rand() % 100)>3) // Happy debugging ...

( Proci85 v | 2016. 03. 01., k – 13:32 )

Ötlet merítésnek nézd meg az IspCP Omega-t vagy az utódját, az i-MSCP-t is.
Az előbbivel foglalkoztam mélyebben. Elég jól átgondolt, összerakott rendszer. Nyílván lehetne mit javítani rajta, de a koncepció jó, ahogy összerakták.
Gondolok itt arra, hogy több template-ből generálja a vhost confot, mindegyikbe bele tudsz nyúlni.
Minden vhosthoz tartozik egy custom$vhost.conf, amit a rendszergazda piszkálhat és a panel sosem írja felül.
Ott is egy C-ben megírt backend + php frontend van.
6 éve használom. Ritkán éreztem magam általa korlátozva.

Igen, tudom az IspCP Omega már megszűnt, Debian 8 alatt alapból nem is megy, de aki viszont kicsit is ért hozzá, hamar átportolhatta.
Utódja még az easySCP. Esetleg az is megér egy megtekintést.

mégiscsak meg kell néznem ezt. az i-MSCP és az easySCP közül melyikkel kezdjem? :)

btw. az, hogy "Minden vhosthoz tartozik egy custom$vhost.conf, amit a rendszergazda piszkálhat és a panel sosem írja felül." minden egyes szolgáltatás konfigurálásánál egy kötelező elem kellene legyen.

( davies007 | 2016. 03. 02., sze – 19:14 )

Még 1 ötlet, annyira, hogy még én sem gondoltam át.

Plugin rendszer, lehessen hozzá plugineket gyártani, Pl:
Wordpress-installer. :)

Csak ezzel meg az a baj, hogy egy rosszúl megírt plugin katasztrófális lehet, szóval valahogy jailezni kéne és limitált hozzáférést kéne neki biztosítani.

Plussz erre egy felület ahol lehet böngészni, meg irogatni hozzá egy tracking/changelog meg auto-updater csak a biztonság számomra kérdéses.

Ha LUA-ba wrapperelek pár safe functions-t és külön process forkolja non-elevated userrel akkor talán rálehetne nyomni a safe bélyeget. de ezt így nagyon ki kell találni, na és azt hiszem ilyen még nincs ilyen rendszereknél, hogy rakd össze magadnak.

Akarom én ezt?

--
#define true ((rand() % 100)>3) // Happy debugging ...

( davies007 | 2016. 05. 28., szo – 02:37 )

Ja amúgy elkészült. :)

Igaz nem minden feature került bele még, és egyelőre csak debian 8 és mySQL, de egész pretty lett.

+ Integrated Domain Server (DNS)
+ Based on Debian Jessie
+ SSL/SNI Support
+ FTP Accounts
+ Mail with SPAM/Virus Filtering
+ Web Flood / Denial Of Service Protection
+ Outgoing Mail Limiting
+ Integrated PHP ByteCode Cache
+ Integrated switchable Static Cache via nginx
+ Integrated Web Auth protection
+ Separated PHP Log Manager

Pre-Release szóval lehetnek benne bugok és nem production ready (bár én már ezt nyomatom élesben), részletek itt:

https://npulse.net/en/introducing-lmvh/

Khm. Akik jelezték, hogy kipróbálnák, hát hajrá és várom a bugokat és az ötleteket.

--
#define true ((rand() % 100)>3) // Happy debugging ...

( gdavid v | 2017. 08. 03., cs – 23:43 )

rég nem szólt már hozzá senki.

van ebben valami előrelépés?

Szia!

Csak annyi, hogy elkészült.
Élesbe fut már pár helyen.

Amúgy jelenleg a fejlsztésben van a második kiadása FreeBSD -re PHP -ban írva, azzal a különbséggel, hogy a Apache -ot szélnek eresztjük végre és csak nginx lesz, választható php5 vagy php7 -el.

--
#define true ((rand() % 100)>3) // Happy debugging ...