Vlákno názorů k článku Debian stable na serveru po letech a jak dál od PavelC - Výše popsané problémy v článku s Debianem, absence...
-
Článek je starý, nové názory již nelze přidávat.
-
martink (neregistrovaný)
Pokud vim, software ve FreeBSD ports nema zadne QA, zadne oficialni security updaty, zadna zavazna pravidla (obdoba debian policy), a muze ho pridat kdokoli (a dal se o nej nestarat...). Balicky v backports.org jsou oficialni balicky z testing (ve vyjimecnych pripadech z unstable) zkompilovane pro stable. Pokud chce nekdo nejaky balicek do backports pridat, musi byt oficialni vyvojar Debianu.
Ja osobne nevidim zadne vyhody pouziti FreeBSD proti Debian stable s nekolika malo balicky z backports.org. I balicky z backports.org jsou pro me duveryhodnejsi nez software z FreeBSD ports. V aktualnosti software bych problem nevidel, malokdo chce preinstalovat produkcni server kazdy rok. Vydavat stable distribuci kazde 2 - 2.5 roku mi prijde docela rozumne (pro servery). Pokud nekdo potrebuje nejaky balicek aktualnejsi, backports.org mi pripada jako idealni reseni. -
PavelC (neregistrovaný)
Zkuste pochopit, že FreeBSD není jako Linuxové distribuce, tj. (opatchované) jádro + nějaká kolekce (GNU) aplikací, ale kompletní systém, tj. jádro a všechny potřebné administrativní, síťové, diskové aj. nástoje, za které vývojový tým "ručí", ikdyž to není typ komerčního QA, které ani Debian nemá. Zkuste si nastudovat, jakým auditem a jak dlouho to trvá, než vydají Release verzi, vhodnou pro produkci. Security team FreeBSD pak dozoruje a vydává bezpečnostní updaty pro tyto udržované větve.
Vámi zmiňované porty obsahují software _třetích stran_, za jejichž kvalitu pochopitelně _nemůže_ jedna organizace nebo distributor ručit. Každopádně nad porty má dohled Ports Management Team(bezp. oznámení, aktualizace) a pokud vás zajímají _pouze_ bezpečnostní aktualizace portů, má na to FBSD nástroj portaudit.
Více viz. http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/staff-who.html
a
http://www.freebsd.org
No a když si porovnáme bezp. model *BSD s jedinou trochu srovnatelnou variantou Linuxu a to SELinuxem, tak se ani není čemu divit, proč mají tyto servery tak nízké procento kompromitací. -
martink (neregistrovaný)
To o cem se tu bavime jsou aplikace jako treba mysql, postfix, spamassassin atd., tj. aplikace z portu. Neaktualnost base systemu nehraje na serveru zadnou roli. Nepochybuji, ze FreeBSD (bez ports, neco jako base system v Debianu) je kvalitni dobre otestovany system. Jenze ports nejsou "oficialni" soucasti FreeBSD. V Debianu je kazdy balicek oficialni soucasti distribuce, tj. kazdy balicek ma staleho maintanera, ktery musi byt vyvojar Debianu; musi dodrzovat debian policy; ma QA; nesmi mit RC chyby v dobe vydani stable; bezpecnostni diry kazdeho balicku opravuje Debian security team atd. Takze at nainstaluju jakykoli balicek z Debianu (v Sarge neco kolem 15000!), mam jistotu ze ma +- stejnou kvalitu jako zbytek distribuce. S ports zadnou takovou zaruku nemam.
SELinux implementuje mimo jine neco jako MAC ve FreeBSD (+ dalsi veci), takze to s bezpecnostnim modelem jsem moc nepochopil... -
bk (neregistrovaný)
Ja mel taky podobne pochybnosti o cemkoliv, co neni Debian, kdyz jsem zhruba pred rokem prechazel z Woodyho na FreeBSD, ale vysoky vykon a aktualnost aplikaci rozhodly o operacnim systemu, ktery na serveru zustal natrvalo. S odstupem casu si uvedomuji, ze tyto me pochybnosti a "zastavani" se Debianu byly spise projevem me neschopnosti naucit se spravovat novy system nez dusledkem skutecnych kvalit Debianu... Rozhodne bych ale ani dnes nevahal nasadit Debian stable kdekoliv, kde staci nizky vykon a zastarale aplikace. Ale v bezpecnost Debianu moc neverim (proc jeste nejsou k dispozici opravy tisicu chyb, ktere byly odstraneny v novejsich verzich Mozilly; proc nebyla vcas backportovana do jadra oprava bezpecnostni chyby, ktera byla vyuzita minuly rok pri utocich na debiani servery ...).
-
Jakub Moc (neregistrovaný)
Ano, a nez se tohle vsechno skvele testovani, QA, a ja nevim co jeste zrealizuje, tak mam na serveru nekolik tydnu deravou (ale stable!!!) verzi PHP, MySQL, ... (dopln si sam) a server mi hacknou. Bezva.
Takze pokud nejsem silenec, tak bud prejdu na unstable/testing a zazaplatuju tu diru hned, nebo holt zvolim jinou distribuci, ktera je schopna bezpecnostni upgrady vydat behem nekolika malo hodin nebo dni, nikoliv v radu tydnu nebo mesicu. -
martink (neregistrovaný)
Pardon, ale to je nesmysl. Nez jste odeslal svuj prispevek, mel jste si radeji par veci nastudovat, treba
http://www.debian.org/security/faq
http://lists.debian.org/debian-security/2001/12/msg00257.html
http://lxer.com/module/newswire/view/9986/index.html
"...it has taken the Debian security team an average of 35 days to fix vulnerbilities posted to the Bugtraq list. However, over 50% of the vulnerabilities where fixed in a 10-days time frame, and over 15% of them where fixed the same day the advisory was released! ..."
"... the survey based on vulnerabilities discovered between June 1st 2002 and May 31st 2003 and found out that the median value of delays between the disclosure and releasing an advisory including a correction was 10 days (average is 13.5 days)."
Citace se tykaji Debianu stable. Opravdu by me zajimalo, ktera distribuce opravuje chyby vyrazne rychleji... -
Jakub Moc (neregistrovaný)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=237422
"The stable-proposed-updates repository has had fixes for these bugs for months, since the maintainer incorporated my patches last October; see archived bugs 212464, 212466, 212467, 212481. When he uploaded the fixed packages, the bugs were closed, though not released as security updates, nor included in woody updates.
As to why the security team has not updated stable in the year and a half (at least) [!!!] since some of these security holes were disclosed, well, I'll let them explain that one..."
No comment. At zije stabilita. -
martink (neregistrovaný)
Nejdriv napisete jak v Debianu stable mate tydny derave PHP, MySQL, ..., ja to vyvratim jako nesmysl (prumer kolem 13.5 dne na opraveni chyby ve stable, stredni hodnota kolem 10 dnu) a vy sem hodite odkaz na (uz nekolikrat zminovane) chyby v mozille jako typicky priklad deravosti Debianu... No comment...
Take si myslim, ze neni idealni snazit se backportovat vsechny opravy. Nejake balicky pak mohou dopadnout jako ta mozilla. Nadruhou stranu nove verze programu prinaseji nove chyby, takze pro vetsinu software zvysuje backportovani oprav do starsich verzi celkovou bezpecnost. Navic diky tomu jsou zmeny v distribuci minimalni a zasahy administratora pri upgradu na opravenou verzi nejsou temer potreba. Backportovanim se resi opravy chyb u vsech enterprise distribuci. Smula je, ze debian nema alternativu pro bezne uzivatele nebo servery poskytujici hodne sluzeb, tam nejsou backporty novejsich verzi software do stable resenim. Testing se meni az moc casto a nema oficialni security updaty, unstable je "unstable". Resenim by mohly byt snapshoty testingu s podporou security teamu. Zatim se ale lide museji obratit na projekty jako Ubuntu a to je myslim pro Debian skoda. -
Jakub Moc (neregistrovaný)
Ne, ja to tady ukazuju jako priklad pristupu spravcu tech balicku - povazuju opravdu za naprosto neuveritelne, ze tam ty chyby jsou dva roky a ve stable Debianu je stale totalne mrtva a jako cednik derava verze Mozilly 1.0.1 (dnes mame verzi 1.7.5!!!) a nikoho z maintaineru to patrne nezajima. Tohle je ten prikladny pristup ke kvalite balicku, jo? Hmm... :-/ A po roce a pul tam maintainer napise:
"Nobody has done the work for option 2 [upgrade Mozilla to 1.0.2]. Pending a demonstration that it's a valid approach [!!!] it's not going to happen."
To snad neni dobre ani jako vtip, tyhle lidi zijou a alternativnim vesmiru nebo jak?! -
nxt (neregistrovaný)
*wd0[a-h]
a,b,e su partitiony v ramci slice
c je cely slice
d je cely disk
f,g,h su ostatne slice na disku
sorry, ale to je vsetko len nie konzistentne..
* ne0, ex0 (napriklad) miesto eth0, eth1.
cize ak vymenim jednu sietovu kartu za druhu, s inym driverom, aby som prechadzal vsetky konfiguracne subory a menil nazov interfacu... -
Yummy (neregistrovaný)
ja v tom naopak logiku vidim
ad oddily disku) to je snad super, ze u kazdeho BSDcka vzdy poznam uz podle nazvu zarizeni kde jsou jeho hlavni svazky, tj. root sd0s1a, swap sd0s1b, disk sd0s1c, ostatní sd0s1[d-h]
co je konzistentniho u Linuxu, ze jednou je hl. svazek na hda1, jednou hda5, swap jednou na hda5 nebo na sd7 ?
ad nazvy sit. zarizeni) ja radsi chci presne vedet, co za kartu konfiguruju nez lustit co se pod eth? skryva. U Linuxu se prirazuji nazvy podle ceho ? Podle pozice v PCI slotu nebo podle poradi v jakem byly zavedeny do jadra ? Napr. u Slacka 10.0(desktop) me dostalo, ze jednou bylo eth0 Gigabit, jednou WiFina a to podle toho jak si hotplug daemon zrovna vzpomenul ! Reseni je samozrejme alias nebo natvrdo nastavit poradi natazeni modulu. Jinak v *BSD prece neni problem pristupovat k zarizenim, pokud je k tomu duvod, pres syst. promenne, ne ?
V Linuxu jsou pojmenovany ethernetove karty eth0, eth1, ... , ale treba bezdratove jsou, podle driveru, jenou wlan0, jindy wvlan0, nebo taky eth0
- tak tomu rikam konzistence.
-
nxt (neregistrovaný)
aha. takze tebe vyhovuje, ze vies ze root je namountovany na sd0s1a, ale keby si vedel, ze jedina (najcastejsi pripad) sietova karta bude eth0, tak to uz je zle? ved to je smiesne :).
odhadujem, ze na serveroch sa nebude instalovanych viac OS a teda nevidim dovod, aby neboli pouzite partitiony od zaciatku, cize od hda1.
ako som napisal aj nizsie uz, hlavna vycitka smerovala k tomu, ze posledny znak z nazvu diskoveho zariadenia je raz cely fyzicky disk, raz ms-dos paritition v ramci disku a raz bsd parititon v ramci ms-dos partition. takze ma v kazdom pripade iny "rozmer". a to povazujem za koncepcne chore.
namespace eth[0-9] sa pouziva linearne od zaciatku, stylom kto skor pride, ten skor melie. a za 6 rokov s linuxom, >10 strojov, sa mi nestalo, ze by sietove rozhrania nekontrolovane menili svoje nazvy.
a neviem ako teba, ale mna ozaj nezaujima (pri administracii OS), ci ma ta sietovka chip od intelu alebo 3com. to ma zaujima max. tak pri nakupe hw. -
JaR (neregistrovaný)
Co je na tom divneho ? Podle teto "takyvyhrady" hadam, ze jste asi linux-only a nespravujete zadny komercni Unixovy system :-). Co je na tom sloziteho nebo nekonzistentniho, vyzaduje to snad IQ vyssi nez soucet cisel v dnesnim datu, zjistit proc to tak je (viz man pages *BSD, Solarisu, Tru64, HP-UX, AIX...) ?
Proc mate dojem, ze jedine partition tabulka podle PC/MSDOS a casti disku cislovane za sebou jsou to
jedine prave, potazmo jen to, jak se chova vas "oblibeny system (tm)" - ctete ten system, na ktery jsem si zvykl - je logicke a spravne ? Je snadne si zvyknout na cokoli, pokud si clovek da praci, aby porozumel a pochopil a me po letech na Unixech vseho druhu pripada normalni a prirozeny jak Unixovy, tak BSD i Linuxovy zpusob. Podobne narky a "takyvyhrady" jsou obvykle znamenim, ze dotycny se s danou veci ve skutecnosti nikdy nenaucil delat a videl ji jen zbezne (s jedinou vyjimkou - nechapu jak nekdo muze mit rad Javu ;-). Jakou vyhodu muze prinest pojmenovani zarizeni zavisle na driveru a tedy zeleze pod nim ?
Par jich je, a jsem za ne mezi vic jak 250 servery s unixovou vsehochuti v nekolika budovach a mestech vic nez rad, to mi verte. Napriklad jeste nez vyrazim, tak vim, jak dane zarizeni fyzicky vypada, kde je zhruba na serveru umistene, co je to za typovou radu od jakeho vyrobce, rovnou z hlavy aniz bych musel koukat do tabulek, logu nebo HW databaze. Neexistuje zadny "nejlepsi", "nejlogictejsi" atd zpusob pojmenovani nebo delani cehokoli. Jsou jen zpusoby, ktere vyhovuji vice ci mene vasim osobnim navykum. A navyky lze zmenit, s nimi se pak zmeni i preference.
Je az zoufale, jake zabomysi spory se tu vedou pro nic. Jeden rekne "me se libi tohle, ma to urcite vady, ale takhle je celkem snadno obejdete" a druhy zacne kricet "s tim dete k certu, to je na hovno, co je to za sragoru, to MUJ SYSTEM (tm)...." a vypukne mnohostranny flame, kde vrcholnym znevazenim druhe strany a posilenim zdani vlastni profesionality byvaji zaklinadla jako "...na produkcnim systemu...", "...hodi se tak pro nadsence na desktop, ale na produkcni...". Kolik adminu si muze od zacatku nadiktovat, jak a na cem neco pobezi ? Mizive procento, ja jeste v takovem prostredi nedelal, a znam jen asi tri lidi, co si sve systemy (max o peti standalone serverech :-) smeli navrhnout a dat dohromady sami (a pak odesli, nastoupil za ne nekdo jiny, a zoufal si z toho, "jak to ten magor amaterska pred nim udelal", no uplne presne jako nase vlady :-). Zbytek adminu zkratka jen drzi hubu a spravuje to, co jim management, marketing a dodavatel predhodi. V pripade osviceneho (nebo dodavatelem dobre pestovaneho :-) managementu se alespon bere od jednoho dodavatele. Nikoho pak nezajima, co je lepsi a co horsi, co se adminovi libi a co ne. Chteji, abyste to rozchodil a udrzel v chodu, a za to jsme placeni. Jak by bylo na podobnych debatach prazdno a vecno, kdyby se kazdy ridil pravidlem "Nekritizuj, dokud ses to poradne nenaucil.". Me osobne debian nesedne, ostatne ani windows ci AIX se svou ODM, ale nechapu tyhle vylevy na podobnych diskusich. Nesedne mi to a nechapu to, tak se to bud musim poradne naucit nebo kdyz mohu, tak jdu od toho k necemu, co mi je blizsi ne ? Kacirskou myslenku "taky muzu prilozit ruku k dilu a pomoci zlepsit produkt, ktery se mi libi nejvic" snad radsi ani nevypustit... -
pc (neregistrovaný)
Jo, ty diskove partitions, to je fakt hrozive zastaraly a chaoticky koncept, ale je snaha to resit. Aspon disky jsou pojmenovany konzistentne s ostatnimi zarizenimi - wd0 prvni, wd1 druhy, analogicky k treba sitovkam ci cemukoli jinemu - zatimco v linuxu mate hda, hdb ... oproti eth0, eth1.
To pristupovani k sitovkam podle jmen jejich driveru se mi naopak libi - aspon vim se kterou sitovkou manipuluju. Ostatne, to Vam nevadi, ze v Linuxu se jeden disk jmenuje sda a jiny hda? Co kdyz prekopirujete system z IDE na SCSI disk? Stejne budete muset menit fstab, coz je daleko neprijemnejsi nez zmena konfiguraku pro sit. -
nxt (neregistrovaný)
ano, hd[a-z] a eth[0-9] je kazde koncepcne inak.
ano, hd[a-z] a sd[a-z] je tiez rozdielne.
nie, mat nazov hardveru v zariadeni sa mi nepaci. ciste preto, ze ma nezaujima kto tu sietovu kartu vyrobil a aky chip pouziva. zaujima ma, ze posiela hore-dole data.
pri zmene sietovej karty by som nabootoval do ostreho systemu. pri zmene diskov by som nabootoval z CD, porobil vsetky zmeny naraz. takze s/hd/sd/ by nebolo az take bolestive.
v originali mi slo hlavne o to, ze 4. znak z nazvu zariadenia je raz cely disk, raz ms-dos partition v ramci disku, raz bsd partition v ramci ms-dos partition. takze ma vzdy iny "rozmer". a to povazujem za koncepcne uplne chore. -
pc (neregistrovaný)
me osobne zajima kdo tu kartu vyrobil a jaky pouziva cip, protoze potrebuju vedet jaky kabel mam zapojit do jake karty a podle toho typu si je poznam (problem samozrejme nastane kdyz jsou dve karty stejneho typu - nejcistsi by bylo mit nazvy ve stylu eth00:01:02:de:e4:fe, ale leckteri uzivatele by se s tim asi nesmirili :-))
S tim ctvrtym znakem je to ve skutecnosti tak, ze je to na stejnem "rozmeru" protoze vsechny ty partitions jsou v disklabelu cili na stejne urovni. Utilita mbrlabel projde tabulku partitions a vytvori BSD partitions ktere odpovidaji tem dosovym. Chore to tedy je, o tom neni sporu.
