Linux-haladó

Adva van egy gép, amin futott az X, dübörgött a MySQL grub/centos és egy videó feldolgozó célszoftver.
Meghalt az alaplap - kicserélték, sajnos nem tudom mi volt az eredeti felállás. Úgy tűnik mintha a kernelt forgatták volna - ki tudja minek.
Mindenesetre az új alapap+cpu -val folyamatosan újra indul. Kell egy új kernel, lehetőleg nem ilyen zárt. A centos nekem teljesen idegen - a grub-ot sem használtam soha (bár ez nem tűnik nagyon bonyolultnak, végül is fel van telepítve). Debian és lilo az én barátom!
Elképzelt menetrend:

1. Le kell menteni a komplett diszket. Tartok tőle hogy dd -vel kicsit soká tartana, az lenne a legszebb, ha a szokásos módon tar a komplett partíció (van belőle 4), viszont a grub esetében nem tudom hogy lehet a botolhatóságot helyreállítani (a lilo -val ezt már számtalanszor megcsináltam).

2. Vajon milyen kernelt lehet ez alá a cucc alá telepíteni? Nem tudom pontosan milyen dolgokat állítottak be, az ideális valami moduláris kernel lenne intrd -vel, hogy tág legyen a hardware lehetőség. Szerintem a Debian stable kernel-2.6.26-2-686 megfelelne, de nem tudom, hogy a centos egyéb dolgai hogy fogják ezt megemészteni - még azt sem tudom milyen verzió :(
Minden ötletet, kiegészítést szívesen fogadok.

Sziasztok!

Adott egy hálózat 150-200 db win XP-vel.
Az alkalmazásszervereken kívül, van fizikailag 2 szerver, mindkettő linux:
1. Router funkciókat lát el OpenVPN-en keresztül és ez a tűzfal is egyben.
2. XEN virtualizációt futtat,
2/a. Windows 2003 terminal szerver
2/b. Linux szerver, drupal, postgres, samba stb.
2/c. Még nem definiált..

Hova tennéd a dhcp és a dns szervert? A tűzfalra? A XEN motorra? Egy új virtuális gépre? A 2/b-re?

Adva van egy ilyen csinos kis netbook. "Unattended" xp telepítést szeretnék rá csinálni, de legalább 2.6.35.x kernel kellene hozzá. Az "unattended" projekt boot disk kreáló szerkezetével készített PXE/image azonban már az elején (alig fejezi be a pöttyözést) kiakad és egy csinos kis crash dump -al kimerevedik :( Próbáltam az olyan alap kernel paramétert benyomni mint az acpi=off - de semmi. Nincs más választás mint konfigurálni a kernelt, csak az a baj, hogy sejtelmem sincs honnantól kezdjem - nem tudom megmondani mitől is akad ki, mi nem tetszik neki.
Sajnos ezen a cuccon nincs soros - USB, LAN és kártya olvasó. A kernel úgy elszáll hogy csak a crash dump végét látom - ebből én nem tudom mihez is kellene nyúlni. Az "unattended" telepítő kreátora pedig valami nagyon "huszárosan" oldja meg a konfigurálást, az "LFS" -ből vesz át valamit (nem igazán értem mit). Valakinek van ilyenhez működő konfigurációja? Mi az ördögtől tud már az elején kiborulni a kenrel - ennyire rosszul még nem sikerült kernelt konfigurálnom, valami nem működött vagy ilyesmi, de hogy az elején elszáll ...

SZERK:
Bocs, ugye a bzImage az a bz2 tömörítést jelenti? - kezdek szétzuhanni :(

SZERK:
Találós kérdés, mi az amitől egy kernel kiakad egy intel Atom procival felkantározott gépen, de egy P4 nem, már a futtatás legelején?

Sziasztok,

Tudni hogy mikor jön ki az első használható verzió a samba 4esből?
Nézve az oldalukat alpha verziók tömegét látni csak.

Sziasztok!

A következő problémám akadt:
Van két szerver. Ezen szervereken elég sok alkalmazást vezérel a Heartbeat. Addig nem is volt probléma, míg ki nem derült, hogy ahova kerül, csak egy szabad IP címet fog kapni, nem pedig a legtöbb leírás szerint igényelt 3-at. eth0-ra így nem állítottam be IPt.
Elkezdtem átkonfigurálni, hogy csak az egyik kapja meg eth0:0-án a külső IP címet.
Ekkor kezdődtek a problémák, hiszen a Heartbeat tudomásom szerint egy virtuális interfészt hajlandó csak felhúzni a fizikai fölé, így gyakorlatilag egyik gépen sem megy a névfeloldás (ping: unknown host google.com), és a külső kapcsolatok (ping 74.125.87.104 connect: Network is unreachable).

resolv.conf:
search xy.hu
nameserver 8.8.4.4
nameserver ...
nameserver ...
nameserver ...

CentOS 5.5

Tud valaki jó megoldást erre?

Köszönöm!

Valami okoságot várnék, hogy tudom az apache suexec useret chroot jailba tenni, úgy, hogy sftp-vel is csak a jail és a saját document root legyen látható. A gondom nem az, hogy jailba tegyem, vagy hogy nem megy a suexec, ezeket külön-külön szépen bekonfigoltam, hanem az, hogy, ha jail-ban van az user, úgy nem működik a suexec, és nem tudok rájönni, hogy miért nem. A suexec doksi írja, hogy neki valid user kell, de biztosan megkerülhető ez valahogy, csak nem tudom merre keresgéljek.
Minden ötletet szívesen veszek, ami az sftp és suexec párosra biztonságos megoldást nyújt, mert nem kizárt,hogy eleve rossz irányba indultam el.

Sziasztok!

Nemrég kezdtem el foglalkozni a Heartbeat alkalmazással, s vannak problémáim.
Láttam, itt sokan foglalkoztok ezzel a témával, ezért bátorkodtam ide írni.

A következő lenne a kérdésem:
Azt lehet ellenőrizni a Heartbeat-el, hogy a gépben a hálózati kártyák működnek e? Ha igen, akkor hogyan?

Előre is köszönöm!

borbelym

Sziasztok!

Bár az eddigi kutakodásom nem vezetett semmi jóra, de azért felvetem a kérdést, hátha tudtok segíteni.
Adott egy szerver GNU/Linux operációs rendszerrel, a rendszert egy külső, megbízott rendszergazda tartja karban. A szervert nem használnánk másra, mint a munkában használt céges Git repository-kat tartanánk rajta. Az a kérés, hogy ezeket a repository-kat ne tudja elérni a rendszergazda, ne tudjon róluk másolatot készíteni, teljesen védve legyenek tőle. A rendszergazda ismeri a Git-et, tudja, hogy miről van szó, ezek pedig belső használatra szánt programkódok.
Első gondolatom valamilyen file-rendszer titkosítás volt, akár loopback eszközön, de ez nem old meg semmit, hiszen a repository eléréséhez mindenképpen fel kellene mountolni. Valahogy azt kellene megoldani, hogy a Git szerver titkosítsa az anyagot. A szerverhez van távoli ssh elérés (a repository-k eléréséhez is ezt használnánk) és rendelkezem rendszergazdai jogosultsággal.

Van valami ötletetek a megoldásra?

Szerk.: Az kimaradt, hogy a szerver virtualizált, a rendszergazda eléri a mögötte található host-ot is, szóval végső soron azt is meg tudja tenni, hogy "lemásolja" az egész szervert.

sziasztok!

elore is elnezest kerek, ha a kerdesem egyertelmu, en kb egy orat toltottem guglizassal, de nem talaltam a kerdesemre valaszt. de lehet, hogy csak nem jol kerestem.

van egy sajat linux konzolom, es van egy tavoli szerver. a tavoli szerverhez kaptam usernevet, publikus es privat kulcsot. a tavoli szerverre ezek kombinaciojaval kene kapcsolodnom es egy konyvtarban levo fajlt letoltenem. a tavoli szerveren rssh restriction van sftpre es scp-re, tehat siman ssh-val nem tudok kapcsolodni. az sftp/scp-nel pedig nem taltaltam olyan kapcsolot, amivel megadhatnam, hogy en kulccsal szeretnek bejelentkezni.

a kerdes: hogyan tudnam letolteni a fajlt _konzolbol_?

koszonom,
ene

Adott nekünk néhány fürt, amik egy-egy közös, nfs -el mountolt / (root) fájlrendszerről üzemelnek. Ezek Debian Lenny rendszerek, amik egy kicsit mókolva vannak, hogy működjenek az osztott / -ről.

Sajnos a géppark nem homogén. Ha a fürtök közt gépet akarunk átmozgatni, akkor a gép tulajdonságaihoz kell igazítani a rendszerképet és úgy felbootolni (pl. megadni a helyi diszk nevét, a hálózati kártyák sorrendjét). Ez nem egy túl bonyolult feladat, de mégiscsak bajlódni kell vele, pedig az átmozgatás akár automatikus is lehetne: a kis terheléssel üzemelő rendszerképekből leállna pár, hogy a nagy terhelést vivő rendszerképből induljon el helyette.

Odáig találtuk ki, hogy nfs -el mountolt osztott / -ről egy alaprendszernek kellene futnia, ami képes virtualizálni. A workload -ot fogadó guest rendszerkép szintén osztott / -el üzemelne nfs -ről, de a hardverrel neki már nem kellene foglakoznia: /mnt/localdisk a helyi diszk, eth0 az internet eth1 a DMZ, stb, stb. Így a produktív rendszerképek könnyen -akár automatikusan- kicserélhetőek lennének.

Ami fontos, hogy csak lightweight virtualizáció jöhet szóba: LXC, Vserver, OpenVZ. Csak minimális teljesítményveszteség elfogadható a mostani bare-metal felálláshoz képest. A produktív (guest) rendszerkép Debian kell hogy maradjon, de a host természetesen lehet bármilyen OS.

Tudtok kész open-source megoldásról*? Csináltatok már ilyen cloud-szerűséget? Végső esetben össze tudom rakni Debian alapokon is, de jobb lenne elkerülni a mókolást.

Azt is megköszönöm, ha esetleg bedobtok valami más megoldást, ami hasonlóan rugalmas lenne. Egy dolgot vetettem el eddig: scriptelni nem akarok. Mert ugye nyilván meg lehetne oldani tengernyi scriptel is, de azokat megírni, karbantartani, portolni a fene se akarja. Valami egyszerű, de robusztus megoldás lenne az ideális.

A tippeket előre is köszönöm.

* A google keresőt ismerem, de a "cloud" jelenleg akkora hype, hogy nehéz kiszűrni a sok bullshit közül a gyöngyöt.

(Bocs ha a "rendszerkép" szó szúrja a szemed, de az "system image" olyan hülyén ragozható!)