"Súlyos problémák a FreeBSD fókuszával, élettartamával és életciklusával"

FreeBSD

A freebsd-hackers listán néhány nap alatt egy rendkívül hosszú szál bontakozott ki John Kozubik "FreeBSD has serious problems with focus, longevity, and lifecycle" című levele nyomán, amelyben arról ír a listatag, hogy merre tart a FreeBSD a kiadások terén. Kozubik - akinek elmondása szerint közel 1000 FreeBSD rendszere van 3 kontinensen - pontokba szedte, hogy szerinte milyen problémák vannak a FreeBSD projekttel felhasználói szemmel nézve. A problémák felsorolása mellett - amelyekkel látszólag többen is egyetértenek - a levélíró lehetséges megoldásokat is javasol. A szálban több FreeBSD projekttag is kifejti véleményét a témában. Esős délutánon érdekes olvasmány lehet.

( tompos v | 2012. 01. 19., cs – 17:01 )

Nem esik, vki osszefoglalhatna:)

tompos

( Nyosigomboc v | 2012. 01. 19., cs – 17:02 )

Ertelmes fickonak tunik, viszont.. csak nekem van olyan erzesem, hogy neki inkabb egy Debian stable kellene, csak mas alapokon? Arrafele divat, hogy sid-tol oldstable-ig minden van. (esetleg Ubi LTS, annak van hosszu supportja)

--
Yesterday I set my wifi's name to "Hack this if you can".
When I checked it today, it was called "Challenge accepted".

FreeBSD-n ott a ports. Ha nincs bajod az alaprendszerrel, akkor nem szokás sokat kavarni. :)

Nekem pl. van egy ilyenem: FreeBSD 6.4-RELEASE-p5, 9:35PM up 861 days, 23:19, load averages: 0.05, 0.09, 0.07

Ezen Apache 2.0+PHP 5.2 duett ment shared hosting jelleggel, mert néhány hete már egy IBM szerveren megy a webkiszolgálás. Erről csak a levelezést kell még átmigrálni és sajnos a 900 napos uptime csak szerencsés esetben lesz meg.

1000 szervernél (de már 50-nél is, tetszőleges OS esetén) központi management nélkül jó esetben is hülyét kap a frissítésektől, szóval azt management cucc nélkül nem nagyon fogja tudni érdemben kezelni. Szóval az ilyen kiadási ciklus és tsai hőzöngést erősen a helyén kell kezelni, mert pont a FreeBSD-nél szerintem :) elég normális az ütemezés és amit kiadnak az általában tudja amit ráírnak.

( Aadaam v | 2012. 01. 19., cs – 18:02 )

Jo, ilyenek azert a debian-ubuntu vilagban is vannak:
1) A debian hajlamos a debian devekrol szolni, cserebe a stable-t obsolete editionnek hivjuk.
2) Az ubuntu eseten az LTS az A Long-Time-Sh.tting-on-your-head, annak az idoszaknak a roviditese, hogy hany evig fogjak a ketsegbeesett enterprise rendszergazdaknak mondogatni, hogy az epp kurrens (midyear) release-ben mukodik. Mindez akar olyan obvious dolgokkal is, mint ket halokartya konzisztens kezelese (8.06 nem tudta, 9.10-ben mar javitva volt de az meg nem LTS)

Pontosan.

Na itt az volt az extra, hogy virtualis volt a gep, es kulonbozo okok miatt nem lehetett lecserelni.

Volt teljesen hivatalos ubu bugreport, sot,vagy 12 orat elb.tam a VMWare Silver Supportunkbol telefonalasra.

Es egyetlen valasz volt az ubuntutol, "az upstreamben (vagy hivjuk minek az azutan kovetkezo oszi vagy kov. nyari kiadast) mukodik".

A persistent binding MAC address alapon a 90-es évek eleje óta konfigurálható mindegyik linuxban, még ha ez nem is volt sokáig default / nem adtak hozzá segítséget a disztribúció init scriptek. Ha valaki ezt nem tudja beállítani, az inkább őt, mint a használt disztribúciót minősíti.

Ez nagyon szep, csak akkor szivas, ha egy tavoli szerverben a technikus halokartyat cserel, mert mondjuk kinyirta egy villam. :-)

Ezt elkerulendo irtam egy szkriptet, ami a PCI slot ID alapjan nevezi el a halokartyakat, igy nyugodtan ki lehet cserelni akar mas tipusura is, ugyanaz lesz a neve. A 2.6.33-as kernel ota amugy is parhuzamosan tortenik a hardver inicializalasa, mindenkeppen kell valami program, ami konzisztens neveket ad a halokartyaknak.

Azért "feltalálták" már vagy 20 éve azokat a hw-eket, amiknél az alaplap közepén egy NVRAM tartalmazta a gép "personality" beállításait, többek között az Ethernet interfész MAC címét... Az alaplap cseréjekor egy mozdulat az NVRAM-ot átrakni csere alaplapba. Csak a buta PC-s világban nem sikerült mindezidáig lemásolni az ötletet.

"Csak a buta PC-s világban nem sikerült mindezidáig lemásolni az ötletet."

Ez azért így erős túlzás. Fujitsu Virtual IO, HP Virtual Connect és a többi.

A lényege, hogy egy datacenterben ha van 10 csillió blade, akkor annak a MAC address-ét és WWN-jét egy rakás helyen regisztrálni kell (pl. swicthek, SAN boot, LUN-ok kiosztása stb.) Ha beszarik a blade, akkor az új csere blade-nek elvileg új MAC-jei és WWN-jei vannak. Beteszed és nekiállhatsz átírni az összes előfordulási helyen az új MAC-eket és WWN-eket. Ez baromi nagy adminisztrációs overhead.

Helyette már minden vendornál elérhetők a virtualizált megoldások. Csinálsz egy szerver profilt, ahhoz hozzáadod egy poolból a MAC-et és WWN-t. Ha beszarik a vas, jön a gyárból az új blade, bedugod, felveszi az előző fizikai vas MAC-jét és WWN-jét és minden megy tovább. Semmit sem kell állítani.

Nem kell semmilyen NVRAM-ot áttenni. Kihúzod a régit, be az újat és kész is vagy.

--
trey @ gépház

Egyfelől igazad is van, másfelől meg ez azért nem a teljes kép.

Akkor lenne ez a teljes igazság, ha nem létezne más, csak blade, meg vm-ek, vagy minden szituáció kezelhető lenne blade-ekkel meg vm-ekkel. Ez azért nyilván nem így van.

Ami mondjuk elveszi az "élét" :) a problémának, hogy a valós enterprise igények nagyon nagy részét szinte mindenhol manapság blade-ekkel meg vm-ekkel fedik le, így náluk nem is igazán merül fel a probléma.

Ellenben nem hallottam róla, hogy egy standalone HP szerver (mondjuk egy akár DL380 G7) tudna bármi ilyesmit. Akinek hiányozna, marad neki a virtuális gép.

Nem állítottam, hogy minden szerver tud ilyet (speciel az utolsó kettő, amivel dolgom volt, az tudott, de ez más kérdés, ráadásul nem is olcsó mulatság, sem a hw, sem a licencek), mindössze cáfoltam azt, hogy a "Csak a buta PC-s világban nem sikerült mindezidáig lemásolni az ötletet".

Persze, ha a buta PC-be nem tartozik bele mondjuk egy HP c7000-es bladekeret, akkor igazad van, viszont ahol ilyesmi számít (nem Pistike IRC szervere a $gagyihostingban), ott ez rendelkezésre álló technológia.

--
trey @ gépház

A standalone gépek tényleg nem szokták tudni, egyer-kétszer néha kitalálnak valamit, ami aztán a következő változatban nincs benne. Utolsó normális megoldás szerintem a Sun gépekben volt, a konfigurációs kártya. De szerintem ez egy non-issue, ahol nagy gépszám van, ott olyan megoldást választanak, ami megfelelő, vagy - pl nagy webfarmnál - olcsó gépek esetén nem is túl realisztikus, hogy minden gépet adminisztrálni kelljen ezer helyen (pl. több telephelyi SAN hálózat, truecopy, otv, stb) mert mondjuk még FC HBA sincs bennük. Ahol nagy standalone gép kell, és akkora a hálózat is, ott meg egy meghibásodás esetén bőven belefér a munka. Pistike IRC szervere pedig nincs regisztrálva több telephelyen hálózati eszközökön, tricsilliárd storage eszközön, ha alaplapot cserél és elszámozódik valami, az egyes egyedül őt érinti.

Nem latom es mivel eljottem a cegtol evekkel ezelott ezert nem is tudom elokeresni :(

A szitu az volt, hogy 3 gepet kellett egyetlen developer image-be osszerakni, meghozza ugy, hogy kivulrol is hozza tudjanak ferni a devek. Ugy kepzeld el, hogy van egy stock ubuntud vmware-rel, mint desktop os, es ezen belul fut egy devszerver, ami kiajanlja neked a fajljait, meg bongeszoben is latod. Mindez persze click-n-go alapon, sot, lehetoleg a devnek root jog se kelljen (napersze)

Az ip-knek belul is kulonboznie kell, mert osszeakadtak volna bizonyos - kommersz, statikus binarisban terjesztett - szoftverek; valami ket apache futott, az egyik sima php kiszolgalo volt, a masik meg futtatott egy binaris cdn emulatort (ami apache modul volt, a cdn ceg adta; kesz template nyelve volt), es ezek nem lehettek egy gepen.

Aliasokat akartam a kartyan, mert igy nem kell valami 40-50 vmware client licenszet venni pluszba, eleg az ingyen player.

A vegen dobni kellett az egesz projektet a francba, mert a lehetosegek az unstable ubuntu (lts-re volt standardizalva a ceg, sysadminok hallani se akartak rola odaat), mas disztro, vmware client minden gepen... Mondjuk en a devszerver hive voltam es vagyok is (egy env, nem negyven, nekem eleg volt egyszer 15 fejleszto lokalis gepen torteno fejleszteseit koordinalni, azota ezt ha lehet kerulom, virtualhosting rulez), igy oszinten szolva orultem amikor a menedzsment letett errol a hulyesegrol.