Red Hat, Fedora, CentOS

Rejtélyes hiba F15-re történt upgrade után - timeout; HEEELP

hola mindenki,

már lassanként beleőszülök ebbe a problémába, a neten nem találok hozzá semmit, viszont elég durva hiba.

szóval: van öt szerverünk, ezek közül egy kapásból friss F15-öt kapott, egy F12-essel megy (és már nem is lesz jobb, nyugdíjazásra váró hardverről van szó), a maradék hármat múlt csütörtökön upgradeeltem F13-ról F15-re.

mióta megtörtént az upgrade, a három upgrade-elt szerver közül kettő a következő jelenséget mutatja NÉHÁNY gépen: weboldal betöltés (vagy IMAP kapcsolat létrehozása, néha SSH login) közben időnként, eléggé sokszor, timeoutba fut bele. ha megtörténik egy ilyen timeout, utána néhány (tíz) másodpercig a szerver arról a gépről elérhetetlen. a weblapoknál gyakori, hogy az első pár elemet (pl. alap htm, css) rendben leszedi, aztán a képek letöltése közben kiakad, és nem tölt tovább, ezután egy másik linkre kattintva a site-on már jön a timeout azonnal.

és itt jön a feketeleves: *bizonyos* klienseknél van ez így. eddig három kliensgépet találtam, különböző hálózatokon, ahol ez a jelenség előfordul. mindegyik windows xp, mindegyik router mögött. és hogy szórjunk még egy kis kávét is a feketelevesbe: UGYANAZON router mögött bizonyos gépeken nincs hiba. az egyik hálózaton egy wifin csatlakoztatott gép nem megy, és a kábeles igen, a másik hálózaton egy csatlakoztatott és egy wifis gép nem megy, egy wifis xp-s notebook és egy android telefon tökéletesen.

és amitől teljesen elszáll az agyam: a három gép közül az egyik tökéletesen megy, igaz, az egy xeon, és azon az upgrade processz f15-ös részének post-upgradejénél volt egy váratlan újraindulás, tehát valami nem futott le rendesen, és emiatt maradt működőképes.

10+ éve vagyok rendszergazda, de ilyen szinten érthetetlen problémával még nem találkoztam.

amire eddig jutottam:
- amikor a tcp alapú protokollok timeoutolnak a "rossz" klienseken, a ping változatlanul működik, tehát a dhcp megy... és mivel nem csak az apache érintett, hanem a dovecot, a vsftpd és néha az openssh is, ezért arra gyanakszom, hogy valami a tcp layeren szabódott el (de mi? az MTU maradt a régi, nem a NetworkManager kontrollálja az eth0 interface-t, stb...).
- ifconfiggal nézve nincs se RX, sem TX hiba az eth0-n.
- apache error logokban nézegetve nincs error.
- maillogban nézve a hibás gépekről néha olyat látok, hogy Disconnected (no auth attempts), más hibát nem ír.
- a timeout a szerver oldalon úgy látszik, hogy a kliens gépről megnyitott kapcsolatok TIME_WAIT állapotban állnak egy ideig, aztán elhalnak.
- az upgrade után egyik gépen sem futott a cron daemon, ez valami fedora upgrade hiba lehetett; azon a gépen, ami jól működik, még pénteken észrevettem a hibát, és beindítottam a cron daemont, a másik kettőn, ami még mindig hibás, csak tegnap este vettem észre és indítottam el a crond-t. ez viszont semmit nem javított a helyzeten.
- megnéztem, hogy az egyik hibát produkáló kliensgép (amihez elérésem volt) nem vírusos-e. F14 livecd-ről bebootolva, nod32 v4-et letöltve és lefuttatva a C:-re nem talált vírust. ettől még lehet vírus, de még nem találkoztam olyannal, ami átcsúszna mind a nod32-n, mind az aktívan működő SAV-on, és ilyen problémákat produkálna.
- mindhárom gépnél a sysctl.conf-on keresztül komolyan át van állítva sok kernel paraméter (a nagyobb network teljesítmény kedvéért + a tempfs maximális méretének növeléséért). ez az egyik szervernél (ahol a legnagyobb a forgalom) nem okoz gondot, a másik kettőnél igen. megpróbáltam a "gyári" sysctl.conf-ot alkalmazni az egyiken, semmi nem változott.
- próbáltam lekapcsolt és felkapcsolt tűzfallal is, ugyanaz a helyzet (gyanakodtam a conntrack-os stateful packet szűrésre, de akkor tűzfal nélkül működnie kellett volna rendesen... nem működött)
- próbáltam közös dolgokat találni a "rossz" és a helyesen működő gépek között, de semmi. ami még a leginkább valószínű volt, hogy háromból két gépen működik egy-egy logitech hd270-es webcam, de már hónapok óta, és csak a F15 upgrade óta van ez a probléma.

az eddigi kutatás alapján nagyon kevés kliens-gépet érint a probléma (a szerverek forgalma jobbára változatlan), de mivel spec nekem ezekre a szerverekre kéne fejlesztenem, és a fejlesztő desktop gépem az egyik érintett "rossz" gép, eléggé szar a helyzet, nem tudok dolgozni rendesen.

valaki valami ötlet? hasonló dolgokba belefutottatok már? vagy van valakinek ilyen tapasztalata F15 upgrade után?

RHCE/RHCSA vizsga felkészülés

Sziasztok.

Az ULX által indított 300e Ft-os tanfolyamon kívül ismertek alternatívát RH300 tanfolyam és vizsga elvégzésére? MIchael Jang könyve meg van, gyúrom is, de igazából oktatás érdekelne, akár magánszemélytől is, online, ha vki Red Hat guru. Alapdíj + sikeres vizsga után bónusz :) Láttam már Red Hat-ot és CentOS-t is, azon nyújtunk hostin g szolgáltatást, de a vizsga ettől függetlenül fontos lenne.

Köszönöm!

www.it-samurai.hu

Melyik milyen verzió

Szükségem lenne egy Red Hat 6.2-es verzióra. Hamarabb kell sajnos telepítenem, mint ahogy azt meg tudják hozni.
Honnan tudnék letölteni? Egyáltalán lehet e ilyet?

Még nem volt dolgom Rad Hat Linux-al, ez a verzió mit takar?
Red Hat Enterprise Linux AS (v. 3 for AMD64/Intel EM64T)

Kicsit káosz az egész, és minél jobban beleásom magam, annál zavarosabb az egész.

Linux újraindítás hetente: hogyan beszéljem le a kollégákat erről?

Multinál dolgozom, adatközpontunk Indiában. Projecthez kaptunk 4 gépet, amiken RHES 5.4 (Tikanga) fut. Az indiai legények minden gépen beállítottak egy automatikus újraindítást hétfő hajnalban (helyi idő szerint), mert szerintük "disabling autoreboot increases the risk of OS crash day by day". Hogyan beszéljem őket le erről?
A szervereken egy elosztott/grid megoldás fut, szerencsére biztonságoz eléggé ahhoz, hogy ne legyen adatvesztés/korrupció még akkor sem, ha kimegy as OS vagy a hardver alóla. Ugyanakkor pain in the ass minden hétfőn újraindítani a node-okat és néha a vasárnapi feldolgozás nem ér időben véget és kezdhetjük előről hétfőn.
Namármost egyértelmű, hogy amit az indiai fiúk írnak, az egetverő baromság és minden bizonnyal a tudatlanságukból eredő tévhit, de ezt nem mondhatom meg nekik így nyíltan. Tudtok valami olyan angol nyelvű forrást, ami hitel érdemlően bizonyítja, hogy a Linux képes akár egy hétnél tovább is futni, annélkül, hogy összeomolna? A saját, házi szervereinken aktuális 64 napos uptime (szerelték a hútést, le kellett kapcsolni a gépeket) nem volt elég meggyőző nekik.
Köszönöm előre is.

cPanel + Mono CentOS 6-on

Jelenleg van egy Ubuntu Server 11.04-em (Apache, MySQL, PostFix, Courier), rajta 8-10 kisebb-közepes forgalmú site és kb. 200 ember levelezése. Ezt kellene migrálnom cPanel alá, mert már nem fér bele az időmbe, hogy minden user problémájával én foglalkozzak, és a phpMyAdminban kattintgassak. A CentOS-t majd megszokom, viszont a kérdés: van egy Mono alatt futó webes alkalmazásom, amit szintén vinnem kéne vele. Nem szükséges, hogy a cPanel alól bármilyen ASP.NET-es dolog konfigurálható legyen, a cucc saját fejlesztés.

Van valakinek ezzel kapcsolatban tapasztalata?

RHEL 5.5

Üdv!

Néhány munkatársam küzd RHEL 5.5 telepítésével.
Ennyi infóm van:
RHEL 5.5 telepítése folyik (virtuális gépre; vmware).
Sima telepítéskor nincs háló és egér, majd vmilyen csomag felrakása után bootolás után összeomlik.

Ha valaki ért efféléhez, várnék visszajelzést.

(megolddva) Fedora 15 VirtualBoxban nem megy a Gnome3

Sziasztok!

Fedora 15-öt telepítettem VirtualBoxban. Gnome-shell nem megy. Eddig mindent megpróbáltam amit az interneten találtam. De nem segített.

VirtualBox 4.1
Extension Pack telepítve
3D gyorsítás engedélyezve
Guest Additions telepítve
Host: Mac OS X és Windows 7 (egyiken sem megy, teljesen más hardver)

Bacula windows mentés

Sziasztok,

Tudom van egy pár téma a Baculával kapcsolatban, de nem mindegyik takarja amit kérdezni szeretnék.
Jelenleg tesztkörnyezetben van összelőve a Bacula. Egy linux a "director", és windows xp klienst kellene menteni.
A bat és a konzol is látja a "directort" bárhonnan, és a kliensek is látják a "director" gépet. Azonban a job futtatása után csak annyit látok a log-ban, hogy "fut", de nem ment le fájlt, könyvtárat, csak áll (nem fagy le). Cancel job-ra természetesen megszakítja a folyamatot.
Lehet hogy nem jól csinálok valamit ezért lenne egy pár kérdésem:

- Három conf fájl van. bacula-dir.conf,bacula-sd.conf,bacula-fd.conf. Ezek a director gépen vannak, és ott szerkesztem őket, illetve a kliensekre is létre kell hozni egy bacula-fd.conf-ot. Jól tudom ?
- A FileSet-et(hogy mit mentek le) hol kell megadni ? A director gépen, vagy a kliensen ?

Köszi