Már megint egy tárhelykezelőn dolgozom (MVCP II)

Fórumok

Na itt van tessék 2020 és megint előálltam a perverziómmal, hogy megcsinálom életem munkáját.
7. tárhelykezelő, de most FreeBSD -re, tudtommal jelenleg semmi értelmes nincs rá.

De amúgy is, a piac tele van förtelmekkel, nem akarom megnevezni őket, de nagyon elavultak és agyontaknyoltak, agyon scripteltek, lassú, feltörik őket, dögvész.

Nem titkoltan azért írom, hogy adjatok ötleteket, esetleg lehet tesztelni későbbeikben vagy dobáljatok meg azt is szeretem ^^
Máskülönben szemléletet és tudást is megosztok az ifjabb lelkesebb padawanok számára.

Lesz ingyenes verzió is, de nem OpenSource, valahogy nincs késztetésem arra, hogy 10 év munkáját kitegyem a világnak és ezzel lezártuk, meg egy zárt rendszer még mindig sokkal biztonságosabb.
Volt már hasonló projektem, itt, működött és elkészült, pár helyen még használják különben elég aktívan, de nem jött be a Linux, gyenge sebességet produkált, csináltam egyet azóta FreeBSD -re, sokkal jobban szerepel, de az marad az ami, most meg teljesen új.

Summa: Eléggé nukleáris fegyverrel agyonlőni egy galambot sztori, mert az összes szaromat beimplementálom:
 - Ki és bemenő Spam szűrés + "Okos" Greylist (azért okos, mert tanul nem csak mert jobban hangzik) (Ez önmagában létező projekt, több mint 1éve ezért van időm fejlesztgetni nem pedig IP -ket levakargatni a SORBSról)
 - Spam szűrés esetén + Botnet észlelés (azonnal tiltja a felhasználót, köszönjük Wordpress a teszteket)
 - Szokásos: Backend (root), Frontend (nobody) + API, AES128 titkosítással.
 - Fasza CLI installer, előre gyártott és forgatott csomikkal, verziókövetés, tehát upgradelhető.
 - mySQL auto-tuning (helyetted bekonfigolja, elég jól különben)
 - Let's Encrypt integráció, "One-Click" és automatikusan megújít és értesít ha error van
 - CRON (De nem crontab, figyeli a szerver load -ot és ha magas késlelteti)
 - DNS Szerver: PowerDNS, integráció: DNSSEC + DKIM + SPF ("One-Click")
 - AXFR Zóna transzfer, akár csoportosan UI -ból ^^
 - Váltható PHP: PHP5.6, 7.0, 7.1, 7.2, 7.3, 7.4 (Értem én, hogy EoL csak azokat nem érdekli, akik nem tudnak váltani és pénzt keresnek vele, így engem se :) )
 - Váltható Webszerver: NGINX vagy NGINX + Apache (igen jól olvastad, apache kell a .htaccess véget, igen meglehetne oldani nginx-be is, de tudok mutatni 27821 soros .htaccess -t)
 - Webmail: Roundcube (Dovecot, Postfix, Sieve, Amavisd, Spamd, stb..)
 - PMA
 - Legújabb csomikkal
 - Fizikailag szeparált tárhelyek, tehát van lehetőség ugynazzal az userrel + grouppal több site -ot futtatni, így ha egyet megtörnek viszik az összeset, illetve lehet külön is akkor nem, ez ilyen subdomain / site és site/user dolog.
 - PHP-FPM állítható erőforrás, RAM, Processzek, php funkciók, limitek, stb...
 - DOS Védelem L4
 - Nagios vagy munin féle, de saját integrált monitoring cucc, mondja a tömböket, smart -ot és gyakorlatilag mindent amit az előbbi kettő tud, csak szebben.
 - Bootstrap3 Frontend, van kézi mód ahol minden beállítható (érteni kell hozzá, mármint ezekhez: domain, átirányítás, ssl, A, AAAA, NS, MX rekordok) és van "varázsló" ami mindent megcsinál egy gombnyomásra.
 - C/C++ a keretrendszer, tehát gyors baromi gyors, könnyen fejleszthető és lófasz erőforrás igénye van, beépített webszerverrel, semmi nem kell hozzá, ugye mert mi van ha becrashel a PHP? nem jön be a webadmin se, tisztelet a kivételnek.
 - Biztonsági Mentés és Visszaállítás: Háááát ezt nem biztos, hogy beletenném.

A keretrendszerről annyit, hogy 10 éve fejlődik, 2019 -ben alaposan átlett szabva, Windows, Linux, FreeBSD, Apple -n elfut, C/C++ -ban beleírtam nagyjából az összes értelmes PHP funkciót nulláról, tehát semmi copy&paste, amit squirrel-lang -al lehet scriptelni, a squirrel-lang pedig kapott egy bytecode cache-t, meg egy-két extrát így gyakorlatilag a PHP -t megeszi sebességben és nem-permisszív nyelv lett, arról nem beszélve, hogy többszálú és tényleg thread-safe. A socket része async és egy szálon fut, de több szálon lehet parallel alkotni vele, ez így elsőre elég bonyolúlt, de a lényege, hogy 10.000 online kapcsolatot 13ms alatt kiszolgál (TLS) -en keresztül 300MB RAM és 70% -os CPU mellett egy $5 VPS -en, ami szerintem tök jó, memleak 1év után már nincs(!), igen 1 év kellett hozzá "Threads are evil", amúgy az openSSL volt a ludas, meg én.

Amit tud még a keretrendszer nagy vonalakban, scriptelhető így nem kell várni míg lefördül ezzel lényegesebben gyorsabban lehet dolgozni még is tudja a C++ elvárt sebességet általában, TLS implementálva, AES és társai szintén, websocket (HYBI) implementálva, többszálú vezérelt és debugolható működéssel, HA-kompatibilis, öndiagnosztika, bytecode-cache, natív 64bit, php_serialize és json_encode támogatott (kompatibilitás végett), a php_serialize pl. gyorsabb mint PHP -n, bár objektumokkal nem foglalkozik, minden funkció binary safe.

Na szóval egy erre épülő csodát kivánok lerakni az asztalra kizárólag FreeBSD -re, elsőnek csak közösségi support -al és ha beválik, akkor méltó ellenfele lesz a cPanelnek, ó és akkor itt mindenki fogja a fejét, úristen de elszállt az ember, és tök igazad van, de egy ilyen projekthez elszántság kell vagy megszállottság, ezekhez meg cél és most a technikai és UX részt nézzük.

Azt hozzáteszem, hogy több éve bevált dolgokat kell, Copy&Paste -zni egy helyre, + frontend.

Amit még tudni kell és kiváncsi lennék a véleményekre, az az, hogy a rendszer csinál használati statisztikát, ez annyiból áll, hogy elküldi a hosztnevet az IP nyilván adott és az operációs rendszer nevét induláskor, illetve ha hiba van a szoftverben akkor küld egy ilyet:

 

Array ((table : 0x0x802d9ee80)) {
         (string) error -> (string) the index 'cpu_nice' does not exist
         (string) count -> (integer) 2
         (string) tstamp -> (integer) 1591491927
         (string) full -> (string) the index 'cpu_nice' does not exist at application/trackit/worker/tasks/vminfo.c(48)
 ********************** VM/THREAD INTERNAL ERROR ********************** 
	[*] Stack Traceback:
		[0] application/trackit/worker/tasks/vminfo.c(48)::vminfo_stat
		[1] application/trackit/worker/realtime_worker.c(95)::thread_main
		[2] utils/thread.class.c(268)::main
 ********************************************************************** 

}

 

Különben full hivatalos, megkapta a FreeBSD logót is.

Akkor a fő kérdés: váltanátok -e FreeBSD -re linuxosok, ha lenne rá egy jó rendszer vagy még jobb ami van?
Ellenvetés a használati statnak, weboldal nevek vagy bizalmas dolgokat nem tud a rendszer küldeni?
A csomagok adottak, kézzel kell a ports-ból forgatni mert a gyári bin nem jó, hogyan oldjam meg ezt közösségi erővel, úgy, hogy ne kontárkodjanak bele, az nem annyira pálya ha minden egyes bugfix esetén nekem kell kiadni a csomikat, bár havi 1x upgrade simán bevállalható de jó lenne ezt kisourcolni. Amúgy adok a rendszerhez mindent csak egy entert kell nyomni és feltelepül magától, csak a későbbeikben.. 

Köszi, hogy elvolastad, POTATO.

Hozzászólások

Szerintem a váltás akkor tud működni, ha olyasmit készitesz mint a cloudlinux, tehát vagy már úgy jön az iso, vagy pedig tényleg egy soros installer megold mindent és nem kell hackelni. Ha jól értem akkor PHP szinten van megoldva a biztonság? Nem gondolkoztál róla hogy már webszerver konténert indítson és abba menjen minden (cloudlinux pl igy oldja meg), ezzel elég személyreszabható környezetet tudsz adni a usernek kb mindentől függetlenül.

A biztonság POSIX szinten van megoldva.

Szerk: FreeBSD -n konténer nincs, ellenben JAIL, alapvetően egy "Mass Virtual Hosting" esetében nem fér bele, hogy mindenkit elszeparáljunk, itt egy szerveren kb. 800-1500 weboldalnak kell elfuttnia és ez így önmagában is egy rettenetes szám az erőforrásokat tekintve ezért is nehéz összerakni egy olyan rendszert ami nem borul meg egy könnyen és maximális biztonságot ad.

Most nem azt mondom, hogy egy szerver ennyire túl kell zsúfolni ahogyan páran csinálják, de valljuk be annál több a profit egy webhosztingnak ahány embert egy szerverre tud tenni.
Sokan trükköznek azzal, hogy VPS -eket tekintenek szervereknek és akkor azt mondják maximum 200 embert raknak egy szerverre, közben fut 5 VPS és az már 1000 ember ugyanúgy + VM overhead.

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

Nekem cloudlinux alatt van több ezer user egy gépen (én nem user számot korlátozok gépekre hanem több gép szolgálja ki ugyanazt elosztva). A konténereket a httpd indítja és ha nincs használatban akkor leállításra kerül idővel, így lényegében az extra erőforrás az a minimális memória ami ahhoz kell hogy fentmaradjon a többlet.

 

A konténerek nálam pár óráig élnek, egyszerre úgy sincs lekérés minden oldalra, így bőven elmegy 64giga rammal 1-1 gép. Szuperul lehet userenként mindent állítani, cpu, memória, lehet flageket adni - elvenni egyes konténerekbe, szóval teljes mértékben személyreszabható a tárhely. Ja, és persze ha úgy döntenék hogy a usereknek PHP-n kivül mást is adok, az is a konténerben lesz, tehát nem kell foglalkozni azzal hogy akkor azt miként fogom chrootolni, jailelni, vagy akármicsinálni hogy ne férjen hozzá a többi user és/vagy a szerveren lévő egyéb fájlokhoz.

Szóval ilyen szempontból a BSD rossz választás szerintem, mivel a konténer a jövő (és már a jelen is) biztonság szempontjából.

Szóval ilyen szempontból a BSD rossz választás szerintem, mivel a konténer a jövő (és már a jelen is) biztonság szempontjából.

Ezzel a kijelentéssel azért még várnék. Haltak már el világot megváltó tervek. Tény, jelenleg én sem látok jobbat....

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

Előrebocsátom: semmi offense, csak hitvallás, nem ismerem a cloudlinuxot btw.

Lássuk... Konténer.. különben pofára egy az egyben a JAIL FreeBSD alatt, szóval az sem kizárt, hogy onnan jött az ötlet, mert JAIL elég régóta van, sőt talán találkoztam is egy cikkel ami azt taglalja valahol, hogy a FreeBSD JAIL-ből számrazik a konténer explicit módon, majd megkeresem, így ilyen értelemben már támadható, hogy rossz választás lenne a BSD.

Én most abból indulok ki, hogy biztonságos legyen egy osztott tárhely, védem a PHP -val és védem fájlrendszer jogokkal (POSIX), nincs még chroot sem, csak annyi, hogy minden tárhely kap egy unique user -t, (ezt anno linuxon MPM_ITK -val oldottam meg, itt POSIX userekkel), a webtárhely mappája olvasható/írható csak user által és olvasható a WWW -vel, a PHP user-el fut és a group NEM www.
Az összes rendszerfájl és tanúsítvány és mappa és a logok minden el van szeparálva és egy normál user nem tud hozzáférni (ellenben a legtöbb tárhelykezelővel).
A rendszer figyel és javítja a jogokat, "ismerjük ugye a chmod 755: problem solved" mechanizmust.. Ez egyszerű mint a faék és működik jól kb. 1992 óta.

Konténer: relatíve friss és egy borzasztó bonyolúlt dolog, alapból van privileged és unprivileged konténer, a kettő között a különbség az, hogy a privileged konténerből lehet piszkálni a kernelt az unprivileged konténerből meg nehezebben. Na most itt jön egy kis hitvallás is, tehát az alábbiakat szokták elkövetni:

1. szarok a biztonságra mert úgy is konténerből csinálok mindent, tehát mindent a konténerre bízunk. Csak, hogy sűrűn kilehet exploitolni rootba velük és hello world!
2. szarok a biztonságra mert van konténerem, valami nyígja van az usernek a python scripjével, stackoverflowról random/vakon bemásolgatom a kódokat rootként és problem megoldva, és máris lett egy unprivileged konténer.
3. foglalkozok a biztonsággal és konténert használok, így biztosítom a legjobb védelmet a teljesítmény rovására. <- helyes út.

Auto-deploy, nodejs, composer, DevOPS, és társai, itt a közös az, hogy egy nagyon összetett és gyorsan fejlődő valamiről van szó akár csak a DevOPS szócskát nézve és ember legyen a talpán aki követi a változásokat, ergó: rábízzuk sokszor magunkat a scriptekre, amik az internetről töltenek le random dolgokat és updatelnek és fogalmunk sincs mi a lószar van, de bízunk benne.

Én meg pont ettől riadok meg, ha éles szerveren nekem önnáló életet élnek a szoftverek, vagy egyik napról a másikra változik valami és lekell követni az összes konténerre.

Különben chroot és konténer ide-oda, a levelezés és adatbázis nem lesz elszeparálva így megette a fene, pont a kettő legfontosabb.

Nem mondom, hogy a konténer szar, azt se, hogy az a helyes amit az én hitem diktál, alapvetően a probléma az, hogy tudás nélkül veszélyes bármi ami production és kint van a neten, a konténer és a linux manapság annyira divatcikk lett, hogy minden boldog boldogtalan nyomkodja, de még fejleszt is hozzá, ami rendben van, csak valahogy ez már nyomonkövethetetlen megtanulhatatlan katyvasz ahol nincs időnk se energiánk kitanulni, de még is ezzel fejlesztünk és ezt használjuk és ott hagyjuk a biztonsági réseket, melyek jócskán szaporodnak.

Én akkor vagyok boldog ha a lehető legkevesebb szoftver van feltelepítve, az is kézzel fordítva biztonságos forrásból a FreeBSD ezt garantálja, abban a pillanatban, hogy tutorialt kell nézni és hozzákell adni a sources.list -hez valamit, nem biztonságos, hacsak nem a komplett rendszer jön onnan amit én választok pl: ProxMox.

Scripteket utálom, van belőlük 120.000 elég egyet találni ami "véletlenül" írható és átírni és lehet máris rootal rohangálni.

Ha én most a konténerekhez értenék a legjobban, biztosan azzal nyomulnék, de nem értek hozzájuk, legalább is olyan szinten nem mint az egyszerű rég működő dolgohoz, amire van C API és script se kell.
Így én itt megtámadom azt a pontot, hogy a FreeBSD rossz választás mert a konténerben van a jövő, valakiknek biztosan én konzervatív lettem az idők során, rengeteg szervert üzemeltetek és egyszerűen nem volt probléma FreeBSD -vel, nyilván ehhez az is hozzájárul, hogy kevesebb számban van jelen és egy picivel jobban kell hozzá érteni.
 

A másik: amelyik rendszer engedi, hogy hibázz ott lehet is, ezért sem szeretem a permisszív programnyelveket pl: PHP, bár PHP mesterien megy, de mai napig belefutok a "shadow variable" dologba: pl:

foreach($tmp as $k=>$v)
{

blablablabla
$tmp = $i + 1; <- és máris felülírtam a $tmp -t, pici figyelmetlenség, de nem biztos, hogy kiderül, happy debugging része.

}

Az ilyenekből is vannak CVE -k és ha rákeresel, hogy Docker breakout, Container escape, Jailbreak Exploit akkor láthatod, hogy van abból is bőven.
Tehát biztos védelmet a mai világban SEMMI NEM AD, csak meg lehet nehezíteni ha olyan rendszert használsz ami "egyedi" vagy arra alapozol, hogy kevesebb az esélye annak, hogy a PHP és a konténer is egyszerre legyen sebezhető, mindenesetre ez: "mivel a konténer a jövő (és már a jelen is) biztonság szempontjából." már is transzlogikus, hiszen a konténer csak egy plussz sebezhetőség és nem néztük a függőségeket, mindenesetre
"Ja, és persze ha úgy döntenék hogy a usereknek PHP-n kivül mást is adok, az is a konténerben lesz" ez nekem máris hasonlít arra az opcióra, hogy IDC I HAVE CONTAINER whatever.

Konténernek is van overheadje, nem annyi mint egy KVM, de van.
Nem feltétlenül működik minden a konténer alatt, és vannak dolgok amik kifejezetten instabilak tehát sajnos nem minden esetben lehet őket használni.

EPOLL például kernel syscall amit linuxon használ az NGINX is, a konténer ha nem engedi akkor lassú lesz, ha engedi akkor máris a kernelt túrjuk vele, ha ez technikailag le van választva a kernelben (nem tudom), akkor már is csak egy POLL() -t kapunk sebességben ha nem rosszabbat, így alacsonyan nézve a dolgokat, legalább 3-12% -os overheadre tippelek, ami nem egy borzasztó dolog.

Az elmúlt években sokszor kellett 8ms válaszidő alá vinni oldalakat, mert ezt kívánták SEO szempontjából vagy realtime API miatt, azt biztosan nem tudnám adni konténer alól.

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

Lehetséges hogy a BSD-s jail-ből indult ki, igazából sose néztem utána honnan jött, de jelen állás szerint én azt látom hogy jóval megelőzte a Linux kernelben lévő namespaces. Nem fogalmaztam egyértelműen korábban, konténer alatt én nem a Docker-t vagy bármilyen más erre épülő szoftvert értettem, hanem a Linux kernel-ben rejlő namespace, amivel könnyedén megoldható a szeparáció és az erőforrás limitáció.

Mivel ugye webhosting-ról beszélünk, ezért fontos, hogy az erőforrás limitálva legyen, amit a hivatalos Wiki szerint a Jail nem tud nyújtani jelenleg: https://wiki.freebsd.org/Jails

A Docker-es résszel egyetértek, annak megvannak a biztonsági kockázatai, pláne ha valaki eszetlenül használja, de az általam említett technológia nem használ dockert, sőt még csak httpd-t se futtat minden usernek. A httpd-nek van egy beépülő modulja, ami indítja a kernel szinten szeparált környezeteket, majd ezt fenntartja addig ameddig szükséges (konfigba beállított). Az hogy ebben el van-e indítva a PHP (vagy más értelmező) az részletkérdés (így lehet erőforrást spórolni, hogy csak bizonyos ideig marad és utána leáll, így a namespace-t nem kell újra felhúzni amikor legközelebb jön a lekérés). Tehát az overheadje lényegében memória, meg diszk terület, de ez nem túl sok gigában mérhető egyik esetében sem.

És abszolút, vannak olyan helyzetek ahol nem alkalmazható, ahol más a szempont mint a biztonság és a userek szeparáltsága, de a webhosting esetében, úgy hogy már a sok év alatt én is végigmentem mindenféle opción a POSIX limitációtól azon keresztül hogy a PHP forrásába volt beleírva a chrootolás, én személy szerint a kernel szinten történő szeparációt tartom a legjobb és legbiztonságosabb megoldásnak most. Aktívan fejlődik és annyira mélyen van a kernelben, hogy ha nem konfigurálja el az ember, akkor jó eséllyel megkerülhetetlen (persze hacsak nem valamilyen kernel exploit van).

Én abszolút értem amit mondassz és egyet is értek vele a FreeBSD jail valóban ilyen szempontból le van maradva, tehát nem is volt opció, ész érvekkel probáltam megindokolni a választásomat és megerősíteni, hogy nem feltétlenül handicap a FreeBSD.

Máskülönben én általánosságban beszéltem erről, szerintem a te megoldásod kiváló.

Én azért erőltetem a FreeBSD -t, mert Linuxos tárhelykezelőkből nagyon sok van én is próbálkoztam anno. volt sikerélmény is bőven, a problémák pontosan azok voltak amik itt is felvetettek páran.
Jött egy frissítés pl: clamav és eltöröltek egy változót ami miatt (és biztosan sokan belefutottak) nem igazán működött megfelelően (kikerestem: 3évvel ezelőtt: AllowSupplementaryGroups).

Mivel sok szervert menedzselek és a lehető legkevesebbet akarok szopni velük elkezdtem centralizálni évekkel ezelőtt, de ez mindig problémákat vetett fel (inkonzisztenica), és gondolkodtam azon, hogy lehetne rendszerszinten menedzselni és ekkor jutott eszembe a FreeBSD és elkezdtem rá portolni melynek a vége az lett, hogy ott maradtam. Linux alatt is megoldható a csomagok kezelése sőt bizonyos téren jobban, viszont a FreeBSD (ports-tree) rendszere egy olyan előnyt ad az egész "forgassuk forrásból" dolognak, hogy most ott tart a dolog, hogy autodeployba hetente / havonta fordulnak a csomagok, manuál kontrol, teszt szerver utána release. 

Meg van az az előny, hogy én magam is tudok patchelni és eldönthetem, hogy akarom -e frissíteni, továbbá, milyen paraméterekkel forduljon le, pl: ha én nem akarok GSSAPI -t akkor nem lesz és kisebbek lesznek a függőségek és a csomagok,kritikus csomagoknál lehet static -ba forgatni, ez különben a teljesítménynek is jót tesz és mivel csak az van benne ami a rendszer stabil működéséhez kell, ezért kisebb és gyorsabb szoftvereket kapunk (jelentősen) és ezt nagyon komolyan mondom, de már tartozom a HUP -nak egy benchmark -al.

A legfrissebb stable csomagokkal is lehet dolgozni, tehát nemkell megvárni a Debian 11 -et, hogy ha akarok PHP 7.5 -öt a jövőben és akár aznap tehát 0day napján ahogy kiportolják lehet nyomatni fel, tudom linuxok esetében is lehet más repóból telepíteni csak gyakran függőségi problémát okoz, pl újabb libssl.so -t kér mint ami van és jön a symlink megoldás "parasztba" ami különben nem egy életbiztosítás vagy frissítünk mindent, csak nem biztos, hogy az ERP örülne egy újabb PostgreSQL -nek.

Ennél a tárhely kezelőnél a csomagok és azok paraméterei meg folyamatosan elérhető lesz, így ha nem is nyílt a forráskód teljes egészében, de menedzselhető közösség által is mert bárki tudja forgatni akár saját magának is és külföldi oldalakon kimondottan van kereslet egy ilyen DO-IT-YOURSELF -et támogató webhoszting rendszerre, mert valjuk be maga a tárhelykezelő rendszernek 3 valamit kell tudnia: grafikus admin + api + backend / worker.

Nálam ezért szimpibb a BSD.

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

Nekünk is van egy hasonló elvet követő fejlesztés, mely egy streamvezérlő hosting panel: https://mscp.pro

- Hülyebiztos installer. Elindítod, feltesz pár kérdést és települ, tehát semmi gépészkedés.
- Az összes Debian alapú disztróra telepíthető. (És CentOS 7 és 8-ra is)
- Már futó más szolgáltatások mellé is telepíthető, nem fogják egymást zavarni.
- A felhasználókat és a viszonteladókat lehet CPU mag és prioritások szerint korlátozni.
- Keretrendszer és backend szintén C/C++, tehát lényegében 0 erőforrás igény.
- Nem kell neki MariaDB/MySQL, független a webszerver, sőt ha megpusztul a fél rendszer, ez a panel még akkor is megy.
- API interface, mobil appokkal is vezérelhető, valamint a már fejlesztés alatt álló Bootstrap3 Frontenddel is.
- Biztonsági mentés távoli kiszolgálóra és visszaállítás
- Az ügyfél pár kattintással importálható másik panelről is (távoli Centova Cast, EverestCast)
- Webes upgrade egy kattintással de úgy, hogy az ügyfél rádiója vagy TV-je nem áll meg.
- Automatikus lejárati értesítés küldése, türelmi idő támogatása.
- WHMCS support

Egy hostingnál ha a webszerver megáll egy percre, lényegében senkinek sem fog feltűnni. Ha viszont az adás áll meg akár 10 másodpercre, az azonnal észlelhető. Ezt figyelembevéve készült a fenti elvek alapján a panel.

https://onlinestream.live/ - A legtöbb magyar rádió és TV egy helyen!

Szia!

Én nem váltanék. Okok:

1, (Biztonság) Mivel szűk a fejlesztők köre, felmerül a kérdés, hogy mi van ha megáll a projekt. Ez rizikó. Ellenben egy nyílt forrású, ne adj Isten közösségi fejlesztésű projektnél ennek kisebb a rizikója. Ez igaz a fejlesztésekre is. Illetve végszükség esetén még akár mi magunk is patkolhatjuk, hiszen elérhető a forrás

2, (Költségek/Munka) Bár nem ismeretlen nekem sem a BSD világa, azért nem mernék -jelenleg- élesben működő szervert így üzemeltetni, mert tisztában vagyok a hiányosságaimmal. Ergo időt és erőforrást kellene áldoznom a tudásom frissítésére, illetve egy tesztüzemre is. Ez pénz.

3, (Hatékonyság) Akármilyen projektről is beszélünk, lesznek benne hibák. A most működtettet rendszereken is vannak, de

   a, ismerem őket

   b, nem ismerem, de mások igen, így pár perc olvasás után minden fasza

   c, linux alatt ha valami nem megy panel alól, akkor jó eséllyel hamar megoldható parancssori hozzáféréssel - ld. 2-es pont

Ennek ellenére ha megosztod, biztos ki fogom próbálni.

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

1, (Biztonság) Jogos, egy rendszert általánosságban kb. 5 évre terveznek ez az 5év megfigyelhető nagyvállalati szektorokban is, de élő példa: "Enterprise SASok" is 5évre szólnak, maga a termék 5 évig garantáltan elérhető lesz és frissíthető továbbá egy kész termék megállni nem igazán tud "elvileg", gyakorlatilag meg azért valami garanciát erre adni kell.

2, (Költségek/Munka) Mit preferálnál jobban, oktatóvideókat vagy inkább olvasmányokat? esetleg mind a kettőt?

3, (Hatékonyság) Ez így van, de .. 2 opció van, csináld magad és bevállalod, vagy kérsz rá támogatást és akkor van teljesértékű garancia és segítség, az egyik nyilván egy Community szemlélet míg a másik inkább a Corporate.

Nagyon jók az észrevételek különben, köszönöm.

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

Szia!

1, Az öt év is sok tud lenni, ha a második évben elhal a projekt. Meg tud állni. Elég egy olyan változás, amely egy adott program meghívását módosítja (elnevezés, path, symlink, stb.) vagy egyszerűen egy másik program váltja fel. A zárt projektnél itt már hasznavehetetlen is lesz.

2, Én informatikában olvasni szeretek, befordulok a screencastos videóktól, amik klikkelgetésekből, meg parancsok begépeléséből állnak. Szerintem videónak ott van létjogosultsága, ahol fizikailag kell matatni. (Valaminek szétszedése, fizikai jellemzőinek megváltoztatása, stb.)
A te esetedben egyértelműen a doksi.

3, Ez így van, de a kérdésed arra irányult, hogy váltana-e egy linuxos. Nos, ebből a szempontból mindegy a support. Mert nem a te szoftvered támogatása a gyenge láncszem, hanem -jelen esetben- az én bsd-s tudásom. Az, hogy te hétfőn reggel 8:00-kor megoldod a pénteki 23:35-kor felmerült problémám, attól még a köztes időben tennem kell valamit. Ha ismerem a rendszert, akkor jobb eséllyel patkolom meg a hiba elhárításáig.

 

Kicsit off, de a 3. ponthoz. Éles szerverem kizárólag debian-t futtatok. Itthon beállítottam egy teszt vasat és tettem rá ubuntut. Már az ubuntu elhasalt kompatibilitás terén. Pl. az rdiff verzió különbség miatt a másik teszt szerveren futó debiannal nem működött együtt, nem tudott menteni.
Megoldások lehetnek:

-másik szoftver a mentésre
-patkolás

Patkolás pl. hogy sshfs-sel becsatlakoztatod a távoli fájlrendszer és úgy mentesz.

Na most felmerül a kérdés, hogy a hibrid rendszerek elkerülése miatt mi az amiért egy teljes infrastruktúrát átmigrálna valaki linuxról bsd-re? Szerintem egy tárhelykezelő miatt nem. Nyilván egy darab webszerver esetén elképzelhető.

 

üdv: pomm

A 852-es kídlap telepötúsa sikeresen befejezádétt

1) Nem hívunk programokat itt minden egyben van, semmi script, a konfigurációs fájlok (pl: nginx) template -ből van, ergó: ha változik valami akkor a template -t átírva problem solved, másik program nem tudja felváltani mert itt az egész egy komplex valami és adott csomagok vannak, ha a csomag megszűnik akkor is támogatott marad sőt a FreeBSD frissítése esetén is minden ugyanúgy működhetne.... de ez még teszt alatt áll.

2) ÁMEN.

3) Ez vitathatatlan

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

Én alapul a HestiaCP-t venném, és ha az bedőlne, akkor bele férne, hogy váltsak oprendszert, igen. (Linuxhoz sem értek, hobbista vagyok. Pár dolog kell az oldalaimhoz, pl. Pandoc, ami miatt egyszerűbb nem menedzselt VPS-en (most épp dedikált szerveren) allinone megoldásokkal bajlódnom.) Mondjuk a backup kezelés valamilyen szinten fontos volna nekem.

subscribe, bar engem inkabb a(z elozo) linuxos verzio erdekelne, egy kiprobalas erejeig.

a greylistedre is kivancsi lennek, en is irtam egy "okos" verziot 10+ eve, bar en inkabb adaptivnak hivom:

- spamszurohoz hasonloan pontozza a klienst, pl. gyanus hostnev (ip cim van benne, dyn, pool, catv stb), hibas HELO, dns problemak (nincs rev, nem oda mutat a rev stb), + a dnsbl blacklistek is 1-1 pontot ernek, illetve van sajat white/blacklistem is amit a contentfilter eredmenyetol fuggoen updatel automatikusan.

- kis pontszammal befogadom a levelet, 2 ponttol 4xx reject (probalkozzon kesobb, addigra nagyobb valoszinuseggel benne lesz a blacklistekben/virusdb-kben is), egy limit folott meg 5xx reject.

- mar ez megfogja a spamek 90%-at, a maradekra meg jon a tobblepcsos tartalomszures

A'rpi

Itt úgy működik, hogy MILTER protokollon keresztül megkapom a HOSZT + IP cím és a fejléceket, ki és bemenő levelek esetén is.
Kifelé menő leveleknél nézem, hogy mennyi és X időn belül hány különböző IP.

Bejövők esetében van egy adatbázis mely "sender host" cache, ha létezik a DB -ben, aszerint jár el (cache), ha nincs akkor 20 másodperc alatt ha sikerül validálni akkor átengedi, ha nem akkor greylist.
A validálás áll egy RBL listából ami weben keresztül szerkeszthető illetve feloldunk egy SOA -t, MX -et, PTR -t, A és AAAA rekordokat és megpróbálunk levelet küldeni a feladónak, persze az utolsó entert nem nyomjuk le, ha a feladó létezik a validálás sikeres X napig.

A rendszer figyelembe veszi az aktív szálakat, ergó: ha alice küld egy levelet bobnak, akkor bobot feltételes whitelistre tesszük nála a validálás gyorsabb és megengedőbb.

Így leírva egyszerűen hangzik, technikailag izgalmas megoldani, ha néha 10.000 domaint le kell ellenőrízni pár perc alatt és közben még a ki és bemenő leveleket is kezelni kell, úgy, hogy senki ne érezze, hogy lassú lenne bármi is.

Itt pontozás nincs, konfiguráció függvénye mire mit csináljon, dobjon vagy jelölje SPAM -nek.
Amióta ez fut a SPAM levelek 99,9% -a a SPAM mappába landol.

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

> megpróbálunk levelet küldeni a feladónak

ezzel csak akkor van gond, ha a felado szervere is hasznal greylistet :)      nem veletlen nem terjedt el vegul a sender address verify...

az implementaciorol: hiaba kuldod te ki baromi gyorsan meg parhuzamosan a DNS es RBL kereseket, a legtobb RBL neha tetu lassan vagy egyaltalan nem valaszol. en kulon bele kellett rakjam, hogy ha 1 RBL egymas utan tobbszor timeoutol akkor azt 1 orara rakjuk tiltasba, ne lassitsa a forgalmat... persze ettol meg nem egyszeru megirni, en is tudom :)

a spammek 99.9%-at meg biztos nem fogod meg igy, mert az utobbi evekben egyre jellemzobb az, hogy adathalaszattal ellopott valos email fiokokbol kuldik a virust vagy spammet (sokszor olyan domainrol amivel amugy levelezunk), sot egy par honapja mar valid gmail accokrol (nem hamis cim, gmail szerverrol jon, valid dkim-el) is kapunk nem is keveset.

A'rpi

ezzel csak akkor van gond, ha a felado szervere is hasznal greylistet:

SMTP protokol előírja, hogy a címzetttől érkező bounce -ot fogadni kell, ha ezt megfogja a greylist akkor nem működik jól, ha pedig még is megfogja, akkor majd X perc után átengedi a legtöbb greylist sajnos csak annyit csinál, hogy az első próbálkozást eldobja, viszont én QUEUE -ba állítom és most jelenleg 5x alkalommal tesz kisérletet az ellenőrzésre kb. 10 percenként, de ha nem is tud kapcsolódni az SMTP -re vagy a feladót nem tudja ellenőrízni sem feltétlenül dobja el a levelet, sőt nem is minden esetben megy el odáig a rendszer, hogy visszaellenőrízze a feladót van amikor megelégszik azzal, hogy az MX rendben, SMTP létezik, PTR rendben, SOA rendben az algoritmus az nem machine learning alapú, de valamilyen szinten tud tanulni.

hiaba kuldod te ki baromi gyorsan meg parhuzamosan a DNS es RBL kereseket:

LIBLDNS beágyazva, így a timeout nem rendszer szinten van, különben az /etc/resolv.conf -ba állítható a retry és a timeout, (rendszer szinten) nagyon hasznos tud lenni.
Én is szívtam nagyon sokat, sőt a DNS Kliens pont ezért került bele a C++ frameworkbe.
Ha használsz CACHE -t akkor kb 1-3 parallel ellenőrzésre van szükség realtime, jelenleg 57.920 SMTP host van a DB -ben, amiből 14049 ami megfelelt és ez a szomorú, nem jó már ez az SMTP protocol ideje lenne, már újítani rajta, mert csak a taknyolása folyik.

Ez ilyen 3 másodperc alatt leszokott futni kb 15-20 listán, és lehetne hova optimalizálni, pl: nem futtatom végíg az rbl_lookup funkciót és ott is kibreakelek ha kapás van, egy időben használtam DNSCACHE -t is.

        /** RBL_CHECK **/
        local ht = htime();
        foreach(k2,rbl in rbls)
        {
            local tmp = netTools.rbl_lookup(row["ip"],rbl["domain"],Config["core"]["dns_ip"]);
            if(tmp["listed"])
            {
                listed = tmp["message"];
                break;
            }
        }

        local rbl_listed = "0";
        if(listed.len() > 0)
        {
            rbl_listed = "1";
        }
        /** RBL_CHECK **/
    /** RBL_LOOKUP **/
    function rbl_lookup(ip,list,ns_ip)
    {
        local dns = DNS();
        dns.set_nameserver(ns_ip);

        local debug = {};
        local ret = {};
        ip = host2ip(ip);

        debug["original_ip"] <- ip;
        if(Utils.strstr(ip,":"))
        {
            ip = expand_ipv6(ip);
            debug["ip"] <- ip;
        }
        else
        {
            debug["ip"] <- ip;
        }

        debug["reverse"] <- rbl_reverse(ip);
        debug["query"] <- debug["reverse"] + "." + list;
        debug["result_a"] <- dns.get_a(debug["query"]);
        debug["result_txt"] <- dns.get_txt(debug["query"]);

        if("error" in debug["result_a"])
        {
            ret["listed"] <- false;
        }
        else
        {
            ret["listed"] <- true;
        }

        ret["message"] <- "";
        foreach(k,v in debug["result_txt"])
        {
            ret["message"] <- k;
            break;
        }

        ret["debug"] <- debug;


        return ret;
    }
    /** RBL_LOOKUP **/

spammek 99.9%-at meg biztos nem fogod meg igy, mert az utobbi evekben egyre jellemzobb az, hogy adathalaszattal ellopott valos email fiokokbol kuldik a virust vagy spammet:

Valóban előfordul kb. havonta pár alkalommal, hogy "Tudunk utalni levelet" kapnak egyesek, ha ezt megnézem az eldobott és a megjelölt levelekkel akkor benne van a .01 -ben, az elmúlt 72 órában 18,000 levélből csak 5.000 -et fogadott el (kerekítéssel) én személy szerint egyáltalán nem kapok SPAM -et a beérkező mappába pedig mindenhol kint az email címem viszont valóban hazudtam, mert a 99.9% úgy igaz, hogy AMAVISD -al együtt én ezt akkor is nagyon jó teljesítménynek könyvelem el, arról nem beszélve, hogy jelentős terhelést levesz a szerverről és mindenki nagyon meg van vele elégedve.

2019 első negyedévében annyi SPAM érkezett be, hogy már mindenki felsírt és azonnali megoldást akart és pont az ilyen feltört accountok végett, szóval eléggé ideg voltam míg végül kikisérleteztem ezt és egy kis bónusz: azóta egyszer sem került semelyik szerver spamlistára, így eléggé megtérült a belefektett idő és életet mentett.

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