Názory k článku Arch Linux na serveru
-
Slavius (neregistrovaný)
Arch som na serveri prevadzkoval niekolko rokov (uz nebola cesta spat z produkcneho serveru) a hned po niekolkych mesiacoch som to olutoval. Rolling update je fajn, no Arch rozbija vsetko naokolo.
Prvy problem bol v case, ked sa v jadre vymenil ovladac IDE za ovladac SATA so spatnou kompatibilitou s IDE. Vtedy sa vsetky zariadenia v udev premenovali a moj /dev/sda, co bol primarny bootovaci disk s OS sa dostal na /dev/sdb a Arch nenabootoval. Samozrejme, mal som pouzit UUID alebo Label, ale v instalacnej prirucke este aj v roku 2012 figuruje /dev/sdX bez akehokolvek upozornenia alebo porovnania vyhod/nevyhod.
Za druhe, prevazdkovat na Archu nieco, co zavisi na Perl-e a nie je z repozitarov je utrpenie. Arch vydava verzie Perl-u ako na beziacom pase, bez nejakych update skriptov inkrementuje verzie (najvacsi problem bol od verzie 5.000, tam to slo asi kazdy tyzden jedna verzia). Problem nastal s modulmi skompilovanymi z CPAN. Po upgrade na novsiu verziu cesty ukazovali na nespravne adresare a programy nevedeli najst svoje moduly. Takto sa mi pravidelne rozbijali spamassassin, sqlgrey, mailgraph a spol. A potom ze preco nejde mail server, pan administrator?
-
iwtu (neregistrovaný)
Nie som ziadny admin, skor bezny Arch user, ale problemy, ktore popisujete sa mi zdaju trivialne, i ked mozno sa mylim.
Nabootovanie. Neviem aky bootloader pouzivate, ale s grub nie je ziadny problem. Staci nabootovat instalacku, mount /boot particiu a upravit jeden riadok v /boot/grub/menu.lst.
Caste updatovanie Perlu. Ako je zmenene v clanku, zakazanie updatovania nejakeho balicku je jednoduche. Staci pridat do /etc/pacman.conf IgnorePkg = Perl.
-
Archer Cpt. (neregistrovaný)
"Nabootovanie. Neviem aky bootloader pouzivate, ale s grub nie je ziadny problem. Staci nabootovat instalacku, mount /boot particiu a upravit jeden riadok v /boot/grub/menu.lst."
A ted si predstav, ze server rebootujes vzdalene a datacentrum je od tebe treba desitky kilometru.
"Ako je zmenene v clanku, zakazanie updatovania nejakeho balicku je jednoduche. Staci pridat do /etc/pacman.conf IgnorePkg = Perl."
Dobra rada. V pripade Perlu to asi pujde i delsi dobu, ale jinde se casem muzes dostat do stavu, kdy ti upgrade selze kvuli zavislostem, nebo kdy ti neco prestane fungovat kvuli binarni nekompatibilite (upgraduje se knihovna, na ktere ti zavisi dany SW).
-
Petr Ježek (neregistrovaný)
Nějak nechápu tu výhradu ohledně vzdáleného datacentra. Pokud spravuji server vzdáleně (a Arch to plně umožňuje), mám samozřejmě k dispozici všechny nástroje včetně možnosti editace konfiguráků. Práce s fyzicky vkládanými rescue médii není jediný způsob, jak to řešit. Arch je síťově velmi silný...
-
Slavius (neregistrovaný)
Trivialne rozhodne su, no odstavka mail serveru, ktory je zavrety v serverovni, bez monitoru, so zaheslovanym BIOS, zakazanym bootovanim z externych medii je zalezitost na minimalne hodinu. Popisem skratene proceduru:
Priniest vlastny lcd, klavesnicu, mys. Pozapajat, zisit z konzoly preco nebootuje. Restart, prekonfigurovat BIOS - povolit boot z USB. Nabootovat live archu, zistit poradie diskov, upravit grub, reboot, zistenie, ze jadro na liveUSB je starsie a radi disky inak (USB, 2x2 disky v RAId poli), reboot, 2. pokus ta ista procedura, zistenie ze funguje . Reboot, prekonfigurovat BIOS, reboot, test, v poriadku. Poodpajat, zbalit, odist.
Co sa tyka Perl, ano, da sa pridat do vynimiek, ktory balik sa nema updatovat. Skusil som to raz. Ked som zistil, ze zvysok systemu sa mi rozbil kvoli zavislostiam (program XY je skompilovany so zavislostou na konkretnej verzii perl-db, ktory sa nemoze upgradnut, pretoze zavisi na perl-5.0xxx, ktory sa nemoze upgradovat) som musel ustupit tejto logike... Perl je tak integralna sucast OS, ze nie je mozne ho zakazat upgradovat. A pridavat vsetky perl-* baliky do vynimiek sa mi zda na hlavu postavene...
-
lempl (neregistrovaný)
predstavy o teoretickom nasadeni open source servra od praktickeho su u niektorych ludi dost rozdielne (az abstraktne)
viem si predstavit ze ak sa taketo nieco stane (ze vypadne mail server) v neakej firme ktora je zavysla od prichadzajucich objednavok cez mail (napr maloobchod)tak do 5 min po pade servra ti vola obchodnik co je s mailami , po dalsich 5 mintach ti vola druhy obchodnik preco este nejdu maily , po dalsich 5 min uz vola sef a chce vediet preco obchodnici nemozu pracovat a nedostavaju maily
toto sa opakuje kazdych 5 min, pricom obchodnici a vsetci ostatny zamestnanci firmy a hlavne sef je cim dalej viac nasrany
po hodine uz ti do telefonu ziape preco to este nejde
po 2 hodinach od padu uz vysis za gule v prievane ani nevies ako a vsetci zamestnanci do teba pichaju vidlami a faklami ti palia vlasy a sef si to foti pre svoj facebook album aby ukazal ako spravne robit team buildinga popri odpovedani kazdych 5 min na telefon opravuj server
Slavius > sucitim, ale zaujmalo by ma ake riesenie ste nasadili namiesto archu , resp ake riesenie funguje teraz ?
-
skywaker (neregistrovaný)
sice nespravujem ziadny server. teda no par krat som instaloval web server ale na mne bola len instalacia, a nastavenie SSH ostatne si uz urobil typek cez SSH vsetko ponastavoval ale z vlastnej skusenosti mozem povedat ze ak na server nejaky linux tak JEDINE DEBIAN. na desktop je debian mozno zastaraly hlavne ak sa nejedna o testing ale na server je debian boziiii. clovek to nainstaluje a potom uz len pravidelne updaty, ziadne stresy ze sa nieco rozbije.
-
snajpa (neregistrovaný)
Taky jsem byl toho nazoru, ze jedine Debian :)
Pak jsem objevil, ze RHEL (a jeho klony) jsou lepe spravovatelne ve vetsim prostredi (10+ serveru), teda vetsina veci jde poresit i s Debianem, ale napriklad automatizace provisioningu (tzn. instalovani novych serveru) se na RHELu s Anacondou dela jednoduseji (jakkoliv je to zabugovana sr*cka)
-
Slavius (neregistrovaný)
Bohuzial, v danej firme uz nepracujem (ale nie kvoli tomu! :D :D). Predpokladam, ze tam stale bezi Arch a za par rokov to bude vyzerat rovnako, ako ked sme sa my rozhodli rootnut mail server, ktory "spravovala" externa firma stylom "fakturujte mesacne, my to spravujeme". Po roote sme zistili, ze tam bol 5 rocny debian bez aktualizacii. Ani tu namahu si nedali ze by urobili sa-update, ale na fakture "antispam" svietilo spolu s ostatnymi sluzbami. Riesilo sa len ked mail server nesiel, aj to tak ze sa to restartlo a nabehlo to = je to opravene.
Osobne by som nabuduce vybral bud debian alebo ubuntu server v tomto poradi... -
Standa (neregistrovaný)
V horším případě má tvá firma s obchodní firmou smlouvu, která povoluje 5 minut výpadku ročně, a každý další výpadek je penalizován 10000$ za každou započatou hodinu. A ty sedíš někde v serverovně, hraješ si s grubem, rebootuješ z flashky a edituješ konfiguráky.
Představa, že si můžeš dovolit zablokovat bezpečnostní aktualizace perlu, je samozřejmě nemyslitelná.
Nasadil bys Arch v takovém prostředí? Firmy provozující takové instalace rády zaplatí statisíce dolarů za to, že jejich distro novou verzi perlu nedostane.
A to ještě nepíšu o kritickém nasazení. V případě opravdu kritického nasazení nejsou výpadky tolerovány vůbec. Máš povoleno nejvýše několik sekund, během kterých musí přejít záložní server do plně aktivního stavu. V takové firmě tě vůbec k textovému editoru na serveru nepustí.
-
Trident (neregistrovaný)
Pokud mate jen par sekund na vypadek rocne, tak potom nema cenu se bavit se o PC. Tyto aplikace bezi na mainframech(klidne v nekolika lokacich). Pripadne je logika primo redundantne nadratovana v hw(letectvi,kosmonautika,telekomunikace atp.)
V pripade tech 5ti minut rocne uz se da jit i na low cost reseni s hromadou pecek a inteligentne navrzenou siti.
Spolehlivost sluzby je vzdy takova, kolik je do ni ochoten vrazit zakaznik. Nebot on je od toho aby si spocital kolik ho bude stat pripadny vypadek. Pokud zakaznik zaplati tak malo, ze je ochoten nechat hrat si nekoho cely den s grubem tak proc ne.
I u low cost masiny JE ALE DULEZITE MIT NA MASINE OUT-OF-BAND MANAGEMENT!!! Nebot nikdy nevite co se muze stat. Alespon externi jako zasuvku ovladanou pres IP nebo externi IP over KVM.
-
Petr Ježek (neregistrovaný)
Přesně tak. Začínám mít pocit, že s rozšiřující se linuxovou obcí uživatelů a adminů klesá jejich schopnost předcházet, analyzovat, detekovat a vyřešit... Článek ale není o kritických nasazeních, takže pokud někdo chce Arch do větší firmy, musí o něm vědět opravdu hodně, protože specifických věcí je tu dost.
-
mrv (neregistrovaný)
proto se taky pouzivaji HA a loadbalancery. navic nevim, jak to souvisi s oss, spadnout ti muze jakykoliv server a vyhoret taktez, s tim co na tom bezi to nesouvisi ani trochu.
bez duplikovani dulezitych soucasti systemu si zas profi nasazeni nedokazu predstavit ja...a pokud jsou ty soucasni ta linuxu, tak se tim da vyrazne usetrit...
-
>Priniest vlastny lcd, klavesnicu, mys. Pozapajat, zisit z konzoly preco nebootuje. Restart, prekonfigurovat BIOS - povolit boot z USB. Nabootovat live archu, zistit poradie diskov, upravit grub, reboot, zistenie, ze jadro na liveUSB je starsie a radi disky inak (USB, 2x2 disky v RAId poli), reboot, 2. pokus ta ista procedura, zistenie ze funguje . Reboot, prekonfigurovat BIOS, reboot, test, v poriadku. Poodpajat, zbalit, odist.
...anebo se místo toho všeho naučit nakonfigurovat seriovou konzoli :)
-
To spolu úzce souvisí. Pisatel dle modelové situace má na mysli, že musíš v BIOSu nastavit boot z USB protože ti systém nenabootuje vzhledem k nekorektně označenému bootovacímu zařízení. Nicméně tohle se dá přeskočit, protože to UUID můžes nastavit už v GRUBU, který naběhne a dostat se tak do systému a potom to pro automatický boot přenastavit v tom configu, což bys stejně dělal akorát přes nájaký liveUSB. Ten sériák ti nepomůže, protože abys ho mohl použít, tak musíš mít naběhlý systém, což v tomto případě nemáš. Samozřejmě že pokud používáš nějaký druh vzdálené správy tak tam možnost sériového připojení být může a pak to je využitelné, nicméně ze zkušenosti můžu říci, že drtivá většina i produkčních serverů v serverovnách běží na železe co podobnou funkcí nedisponují a nebo není nakonfigurovaná a nebo admin ani netuší, že tam něco takového je :)
-
To hostujes v JZD ve Chvojkovicich ne, ze si musis prinest vlastni periferie. Solidni hostingova spolecnost ma k dispozici vozik s monitorem+klavesnice+mys nebo podobne reseni a nemusis nikam nic tahat. To je u housingu v zakladni vybave stejne jako volant u auta a pokud ne tak se nema cenu namahat spekulovat ci s takovou spolecnosti vubec ztracet cas.
-
Je to alternativa ale neřekl bych že standartní. Nevím jak dneska, ale před dvěma roky určitě ne. Navíc vycházíme z předpokladu, že víme co je na jednotce špatně, dle popisu uživatele, nicméně pokud restartuješ po nějakém zásahu do systému tím spůše jako v tomto případě do jádra tak už ti to na dálku tak jasné nebude a veškeré podobné zásahy je lepší řešit na místě se starým jádrem v záloze, kdyby se něco po....
-
Nebyl jsem to ja, kdo se tady ohanel nejakym JZD Chvojkovice.
KVM mas napr. u Masteru i u nejlevnejsiho housingu za 969Kc mesicne: http://www.master.cz/server-housing-brno/
...takze nevim, o jakem standardu je vlastne rec. -
Ok, to tezko posoudim. Ja tim jen myslel, ze kazdej provider ma minimalne ten vozejk k dispozici s prehistorickym monitorem a klavesnici ci mysitkem, abys nemusel tahat svoje. Navic to ani nebyla reakce na tvuj prispevek.
Jen vim, ze treba Cassa pred dvema lety KVM k dispozici nemela a nebo to dobre skryvala :).
-
Slavius (neregistrovaný)
Od urciteho casu to tam uz pridali. Sice regulernym pismom, takze standardne tomu nikto nepriklada vyssi vyznam a navyse, stalo sa to iba raz, v dobe ked sa prechadzalo na novsi SATA driver. Ale v kazdom pripade, pouzivat UUID alebo Label je vyhodnejsie oproti udev nazvom...
-
jehovista (neregistrovaný)
Na druhou stranu z toho prvniho odstavce vyplyva, ze je Arch vhodny na server s blogem. Podle me teda neni arch vhodny na zadny server. Dokonce si myslim, ze ani na pracovni desktop neni moc vhodny. Proste clovek vazne nikdy nevi, co se mu pri updatu rozbije. Jednou je v repozitari driv nejaky balik, nez jeho zavislosti(stalo se mi nedavno - novy VirtualBox se mi nainstaloval driv, nez jsem mel v pacmanu nove jadro, ktere ten VBox vyzadoval. To byly horke chvilky...), jindy si balik s novou minor verzi v klidu premlaskne uzivatelske konfiguraky(tomcat6 a zadne .pacnew se nekonalo), najednou zmizi Gnome 2, casto je potreba uzivatelsky zasah v konfiguraku, ...
Ja mam arch rad a pouzivam ho kde se da, ale je to proste system pro lidi, ktere Linux bavi. Kdyz clovek cte newsy, ma na to cas a ma nejake znalosti o pulce veci, co ma v systemu, tak je to super. Rozhodne to ale neni system, na ktery by se dalo spolehnout a provozovat na nem nejakou sluzbu*.
*samozrejme, mozne je vsechno. To bysme ale taky mohli tvrdit, ze na server jsou vhodne Windows. -
Petr Ježek (neregistrovaný)
No, ono to tupé -Syu každý večer zasluhuje pohlavek v podobě problémů a horkých chvilek. Pokud mi záleží na stabilitě a plynulém provozu, tak není problém zjistit, kdy se jaké baláčky aktualizují, je v tom totiž dost pravidelnosti. Pravidelně je pak třeba číst info na hlavní stránce, sledovat bugs a hlavně při instalaci instalační zprávy. Pospávat u toho a myslet si, že ono to nějak dopadne, je diskvalifikující pro jakéhokoli admina čehokoli...
-
rastakajakwanna (neregistrovaný)
At uz je hovadina cpat Arch na server nebo ne, podobne clanky maji smysl! Podobne ocenuju jakoukoliv snahu o priblizeni podobnym zpusobem *BSD (* = Open, Free, ...).
Arch by svym zpusobem pritom mel byt podobnejsi BSD nez jine Linux distra, takze se mozna podobne postupy a prekazky muzou objevit v jine podobe i u nej. Cesty Linuxaka jsou nevyzpytatelne, takze viz titulek... ja si pokracovani rad prectu :) -
Podobne clanky rozhodne smysl maji i proto, ze autor predem upozornuje na mozna uskali vyhody i nevyhody pouziti systemu objektivnim zpusobem i kdyz treba ne uplne kompletne. Naopak by clanku tohoto typu melo byt na rootu daleko vice, aby se ctenari seznamili a is vyhodami/nevyhodami reseni ktere sami nepouzivaji a mohli porovnavat se svojim jiz treba funkcnim resenim.
Nicmene by me zajimala ta podobnost BSD s Archem, to jsem uplne nedal:).
-
Arch jsem pouzival na svem serveru vic nez tri roky. Byl jsem s nim vzdy spokojen, az na poslednich par mesicu, kdy se mi dvakrat stalo, ze server po upgradu jadra a naslednem restartu nenajel a ja to musel jit do serverovny resit. No a naposledy jsem to proste vyresit neumel a tak Arch musel jit a nahradilo ho openSUSE. Nicmene i pres tuhle negativni zkusenost muzu Arch linux na server doporucit. Ale rozhodne vyuzijte LTS kernel nebo nejaky, ktery si sami zkompilujete, tam se prece jen ta frekvence upgradu snizi a tim se snizi i riziko nejake te chybky.
Moje zkusenosti tedy potvrzuji obsah clanku. -
Arch je pěkné distro, ale je fakt, že problémů a nedodělávek je trochu víc, než by bylo na server zdrávo.
Existoval i projekt ArchServer, který měl ambici vytvořit nad Archem trochu stabilnější (hlavně co se updatů týče) serverovou verzi, ale jak dopadl, to netuším. V současnosti vypadá web www.archserver.org úplně mrtvě. Škoda, docela jsem se na tuhle verzi těšil.
-
Radeji nic upresnovat nebudu, nemam potrebu rozdmychavat flame.
Berte to jako moje ryze subjektivni hodnoceni, ktere nikomu nenutim a ktere nemam v umyslu nijak dokazovat: napr. FreeBSD na me pusobi jako system, ktery se do nemilych, prekvapivych a nepredvidanych stavu dostava daleko mene casto nez Arch. (napr. jednoduse uz proto, ze alespon base je stabilni a nemeni se jako ameba kazdou chvili)
Ale znovu zduraznuju: je to muj osobni nazor. Jini lidi muzou mit nazor prave opacny.
-
A nebylo na toto upozornovano i v clanku? Ze Arch neni distro pro produkcni reseni kde FreeBSD uz ze same podstaty ano?
Lide kteri hledaji reseni pro produkcni servery o tom asi neco vedi a Arch i jine distribuce by stejnak nepouzili. Pro domaci server na hrani rikam: "Arch, proc ne"? I kdyz ja osobne bych dal prednost rovnez *BSD reseni, ale pokud je nekdo vylozene Archista a chce si vyzkouset server funkce jako DHCP server, bind, apache, mail servery, etc. tak proc ne zrovna na Archu? Konfigurace jednotlivejch daemonu bude stejna a ucel to splni pri znalosti zakladni spravy Archu jako takoveho a nutnosti studia dalsiho os, coz treba i u linuxaku neznalych BSD muze byt usetreny cas. -
lord_kuko (neregistrovaný)
Nechcem neopravnene kritizovat, cenim si kazdy pokus o akekolvek clanky a rozsirovanie povedomia, ale clanok je o com? V celom clanku je uvedene akurat tak ze pouziva rolling-release model a potom je to prebrane 10 krat... Mozno by to chcelo trochu hlbsi pohlad dovnutra.
K teme:
Archa provozujem na desktope uspesne uz niekolko rokov, nielen u mna ale aj u fotrovcov, znamych... A som spokojny. Niezeby neboli problemy, ale vzdy je to nejak normalne riesitelne a to co potrebujem vykuzlim relativne lahko. Na server som ho nasadil par krat na kratsie obdobia, ale dlhodobo by som fakt nechcel.. Chcel by som nieco presne ako arch, ale so stabilnymi repozitarmi, inac balickovaci system aj cely release model vyhovuje.
