Postavitev ter administracija strežnika

Pozdravljeni!
Dolgo me ni bilo tukaj, sem že malo pozabil na tale forum :) Imam eno čisto informativno vprašanje.
Zanima me namreč približna cena postavitve ter vzdrževanje strežnika.
Kaj bi se moralo zrihtat na serverju?

CentOS!/Debian s custom kernelom in grsecurity patchom, Xen.
Imel bi 2-3 virtualke, na katerih bi laufali ApachePhp+Mysql nodi. Imel bi dva strežnika na fizično ločenih lokacijah, ki bi laufala ha loadbalancing + proxy serverji. Apache nodi vzdržujejo iste fajle z rsyncom, mysql z mysql replicationom.
Nginx bi bil za preusmerjanje prometa in statične file, Apache za serviranje php filov. Študiral sem tudi o greenmysql (kao mysql firewall pred mysql injection) ter modsec za apache. Na enem vps-u bi bil tudi cpanel.

Postavili bi se servisi kot so ftp over ssl, mail (ssl), celoten dns servis, nek centralen auth sistem, "cloud" file storage, ... Monitoring vseh servisov na serverju z grafi. Vsi serverji bi bili povezani v privat VPN mrežo, torej vzdržeanje poteka iz centralenga serverja (no ssh, monitoring, admin pages od "zunaj").
Pozabil omenit vse potrebne servise/aplikacije za stranke. dns, vhosti, phpmyadmin, mogoče celo vps control panel.
Celoten disk oz. raid array bi bil encryptan. Napisana iptables skripta.
Pisali bi se tudi grsecurity policy rules-i, vsak servis zavarovan in ločen.
Automatski backup (dump mysqla, rsync filov oz. snapshoti) vsak dan.

Vem da so določene stvari zmedeno in na hiterco napisane, vendar je pomembno kaj bi se moglo v osnovi zrihtat (če vas zanimajo podrobnosti, pišite v temo). Zadeva je itak še bolj zakomplicirana, sam me res samo informativno zanima, kakšne cene so v teh biznisih.

Bi bilo pa zelo lepo, če bi se lahko povezal s kakšnim sistemcom, me še zanimajo določene stvari :)

Hvala in lep pozdrav!

19 odgovorov

hvala za vse odgovore. torej
@stesi: kakor je že Frajder povedal, router se z 84.255.xxx.xxx/32 poveže na modem ter dobimo 84.255.xxx.0/24 subnet. kako uporabiti /29 povezovalni segment, da se lahko oba routerja povežeta na modem, ter uporabljata floating ip(kaj drugega)?

@boco: vsa oprema, na kateri delamo je enterprise, tudi vsa mrežna oprema, samo backup router je noname mašina. je pa bilo v osnovi zasnovano, da delamo izključno na opensource rešitvah, ker nimamo astronomskega bugdeta. sistem res ni profesionalen, kar tudi ne potrebujemo, vendar mislimo, da se da veliko narediti v to smer. pfsense pa drugje povsod hvalijo, ker se da z njim ogromno naredit.

bomo še rekli kakšno v prihodnjih dneh.
hvala in lp, brix

1

@brix ni problema, sicer so tudi opensource rešitve velikokrat v redu in stvar, ki ste jo zastavili je zelo dobra in če že ideja se sliši precej profesionalna. Ne vem sicer točno, ampak predvidevam, da za vsem stoji oziroma, da to delaš za neko podjetje. Pri vseh opensource rešitvah je edini "problem" podpora, ko le to potrebuješ in takrat ko nastanejo težave vodstva (šefov) več ne briga koliko si prihranil pri opensource. Najlepše je seveda, če podpore ne potrebuješ ;-) Upam, da ti uspe s pfsense....

1

@boco hja načeloma smo sami svoji šefi in s tem v veliki meri ne bo problemov.
imamo pa še vedno tale problem z routerji, ker načeloma še nismo ugotovili kako tole zadevo rešit. ima še kdo kakšno idejo, kaj v takšni situaciji? bo treba enga t-2 sistemca direkt vprašat :)
hvala in lp, brix

Frajder:
Sedanje stanje je: 84.255.xxx.xxx/32 < 84.255.xxx.0/24

ni 84.255.xxx.xxx/18 < 84.255.xxx.0/24 ?

Če koga zanima, sem tule odprl temo pa bomo vidli :)

@brix ti moraš na t-2 zaprosit če ti lahko namesto povezovalnega segmenta 84.255.xxx.xxx/30 (ni 84.255.xxx.xxx/32 < to je samo en ip naslov v subnetu, /30 sta dva uporabna + network in broadcast) dajo 84.255.xxx.xxx/29, potem imaš 6 uporabnih ip naslovov v povezovalnem segmentu, eden izmed teh je router od t-2.

Bi bilo pa dobro razmislit, glede na to da delate večji sistem o BGP usmerjevalnem protokolu, če imate na lokaciji možnost drugega ponudnika (siol, amis, telemach, itd.)

S tem se izognete tudi nedelovanju sistema, ko kaj odpove pri t-2 in če boste kadarkoli zamenjali ponudnika, vam pridobljeni IP naslovi ostanejo.

1

@boco mislim da si fino na slabšem če imaš samo enega dragega juniperja. :) Pa tud pri podpori imaš veliko več opcij pri odprti kodi. Eno in drugo je pa treba znat uporabljat.

@brix z failover configuracijo nebi smel met problema. Kot je @stesi namignil, rabiš kak IP več, vsaka mašina svojega pa enega virtualnega. Maš ogromno tut-ov to nebi smel bit problem.
Mislim pa da PfSense v stable še vedno ne podpre proxyarpja, tak da boš moral delat z routed subneti. Mal je muka k prvič nastavljaš, pol bo pa šlo.

1

@weselko Napisal sem, da sta SRX-a v HA načinu, katr pomeni v High Avilability, torej govorimo o dveh požarnih pregradah, ki sta med seboj povezani in če izpade ena prevzame druga. Kar se tiče supporta se pa pri odprti kodi ne strinjam ravno s tvojo trditvijo. Ko odleti router in imaš od zadaj sistem na katerem je nekaj "hudih" uporabnikov včasih nimaš časa iskati po forumih in prositi, če bi ti kdo pomagal. Verjemi, da govorim iz izkušenj in v takšnem primeru je fajn če veš, da je od zadaj support, ki ti bo pomagal rešiti težavo v nekaj urah. Pri nas za Juniper produkte ponujamo support 24/7

@stesi, predlog o BGP je vsekakor profesionalna rešitev glede na to, da se zadeve rešujejo na opensource dvomim, da so šli v AS , sicer pa je predlog za resne zadeve na mestu

1

@boco moja napaka, prehitro prebral. Zakaj pa primerjaš hruške pa jajca? Če sam rešuješ težavo s forumi in mailing listami, naj vsak sam ugane, o kateri temi najdeš več napisanega. Ponudba podjetij v Slo., ki nudijo podporo za eno ali drugo opcijo je pa popolnoma enakovredna.
Pluvanje po defaultu, samo za to da sebe promoviraš, je res grda navada. Če bi enkrat prebral licenčne pogoje ali navodila za SRX pa bi vedel da operacijski sistem, cenjenega Juniperja, bazira na odprti kodi. LINK, piše Junos daleč dol pod PfSense, skupaj z Sophos, Ironport, Citrix, PS3... Potemtakem vaši tehniki pridejo in forume berejo pri stranki? :)
Brez zamere, ampak open source ni samo tisto kar te naučijo brand managerji. Brix je predstavil kredibilen setup in ni prav, da se implicira češ da je to manjvredna rešitev.

3

Zagovorniki odprtokodnih rešitev bi lahko malo manj zagrizeno branili svoj vrtiček.

Po vašem mnenju komercialni ponudniki rešitev zgolj zmečejo skupaj nekaj odprte kode, to potlačijo v neko škatlo in gor nalepijo svojo nalepko in to potem drago prodajo.

Da nekaj 'bazira' na odprti kodi, lahko pomeni, da so si tam izposodili source za kernel, ga modificirali 'utrdili' in vključili v svojo rešitev. V sklopu rešitve so lahko uporabili tudi drugr fragmente kode drugih razvijalcev, ki ima določena licenčna pravila ali celo patente. Zato se na koncu licenčnih pravil običajno navaja tudi lastnike teh pravic. S tem pa še zdaleč ni rečeno, da ima proizvod kakršnokoli podobnost s samo rešitvijo, pri kateri so si izposodili del kode.

Zagotovo se da na odprti kodi sestaviti 'delujoč sistem'. V to nihče ne dvomi, lahko tudi najdemo na miljone takšnih sistemov. Vendar bi bil zelo zelo pazljiv pri primerjavi odprtokodne rešitve z neko zaokroženo komercialno rešitvijo.
Ko nekdo na veliko razlaga, da je njegova odprtokodna rešitev boljša od nekega Juniperja ali podobnega resnejšega proizvoda, se mi poraja misel, da takega proizvoda še nikoli ni imel priložnosti testirati in govori na osnovi izkušenj z nekimi SOHO proizvodi.

Če so odprtokodne rešitve tako superiorne, bi se potem najprej vprašal, zakaj vsi ISP-ji in velike korporacije uporabljajo komercialne rešitve in ne odprtokodne.

Kdor si vzame le minuto časa za razmislek, bo hitro ugotovil, da je problem v vzdrževanju odprtokodne rešitve. Upravljalec v podjetju lahko postane suženj odprtokodne rešitve, če hoče vsak dan spremljati, ali je kdo objavil kakšno luknjo v kodi, pa potem še išče, kje bo našel popravke, ki jih mora nato še namestiti. Ker odprtokodna rešitev ni sestavljena le iz ene komponente, ampak iz najmanj desetih, se zadeva že podeseteri. Če ima več odprtokodnih požarnih pregrad.... ?

Ker pa vsi dobro vemo, da nihče nima časa stalno se samo z požarno pregrado ukvarjati, se ponavadi zgodi, da se zadevo postavi, nato pa se jo zanemari in ne doživi nobene nadgradnje, dokler nekega dne ne zariba disk in je treba zadevo takointako na novo postaviti.
Tudi sicer so nadgradnje problematične, saj se jih praktično ne da izvajati na delujočem sistemu, brez da bi prekinili internetno povezavo. Torej moramo imeti pri roki še rezervni sistem.

Zadnje čase se na veliko uporablja besedna zveza 'security awareness' - pojem, ki je pri nas še kako na psu. Če nekdo misli, da ima varen sistem samo zato, ker je baziran na Linuxu in da ga zato ne rabi neprestano krpati, potem je ta oseba popolnoma skregana s kakršnokoli zavednostjo.

Komercialne rešitve so drage. Drži. Ene bolj, druge manj. Vendar se v ceni odraža trud, ki ga razvijalci vlagajo, da ti v paketu dostavijo vse popravke sistema, ki jih v nekaj sekundah naložiš in se lahko posvetiš drugim nalogam. Ne rabiš ure in ure tuhtati, kako boš neko novo funkcionalnost implementiral, ne rabiš iskati nasvete po forumih - vse dobiš že narejeno.

Baje, da je čas denar. Mislite, da je vaš delovni čas zastonj? Preračunajte enkrat, koliko ur bi letno porabili, če bi resno hoteli vzdrževati neko kompleksno odprtokodno rešitev, da bi imeli vse luknje v sistemu pokrpane najkasneje en teden po odkritju. Bi bili dve vaši plači dovolj? Za ta denar pa lahko že kupite dokaj spodoben komercialni proizvod, ki bo počel isto, kot vaša kompleksna rešitev, le da bo malo bolj eleganten za upravljati in nudil še dodatne funkcionalnosti, ki jih na odprti kodi nikakor niste mogli implementirati.

Res nočem v nič dajati odprtokodnih rešitev. Nekatere so odlične in iz mnogih so se kasneje razvile komercialne rešitve. Vendar je že v tem stavku bilo povedano bistvo - iz njih so se razvile - dodalo se jim je nekaj. Govorimo o dodatni funkcionalnosti, uporabniških vmesnikih, enotnem upravljanju - in ne na koncu storitvah, ki vso zgodbo zaokrožijo.

ZATO se mi zdi nepošteno sploh primerjati odprtokodne rešitve in komercialne rešitve. Ene so za akademska okolja, učenje tehnologij, domačo rabo in podobno, druge pa so za komercialno rabo, ki podlega svojim zakonitostim. Žal pa te zakonitosti marsikomu niso niti približno jasne.

3