raid tömbök
Szisztok! Csak most tünt fel nekem a következő: fdisk -l ... ... ... /dev/md1 lemez: 448.0 GB, 447998001152 bájt 2 fej, 4 szektor, 109374512 cilinder Egység: cilinderek 8 * 512 = 4096 bájt Lemezazonosító: 0x A(z) /dev/md1 lemez nem tartalmaz érvényes partíciós táblát Ezt írja az összes raid tömbre. Ez rendben van így? _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid tömbök
Gergely Tamás írta: Ezt írja az összes raid tömbre. Ez rendben van így? Persze. A /dev/hda1 sem tartalmaz particiós táblát, mert maga egy partició. Szeretnéd az md1-et továbbparticionálni? _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid tömbök
Gergely Tamás wrote: Szisztok! Csak most tünt fel nekem a következő: fdisk -l ... ... ... /dev/md1 lemez: 448.0 GB, 447998001152 bájt 2 fej, 4 szektor, 109374512 cilinder Egység: cilinderek 8 * 512 = 4096 bájt Lemezazonosító: 0x A(z) /dev/md1 lemez nem tartalmaz érvényes partíciós táblát Ezt írja az összes raid tömbre. Ez rendben van így? Persze, linux. A kernel es a userland egy resze mar tudj nativan kezelni a diszkeket, amikor a diszken nincs particios tabla csak az md driveokon, mig a tobbi resze nem, igy jonnek a kusza uzenetek. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid tömbök
Gabor HALASZ halas...@freemail.hu writes: Ferenc Wagner wrote: Mi ebben a kusza? A feltett kérdésre (fdisk -l) teljesen korrekt választ adott. Szerintem. Izlesek es pofonok. man fdisk: -l List the partition tables for the specified devices and then exit. If no devices are given, those mentioned in /proc/partitions (if that exists) are used. userland toool, imho nem az a dolga, hogy a kernelinternalst vagy a fellelheto osszes blockdevicet reportolja a usernek. Úgy tűnik, a fejlesztők sem erre helyezik a hangsúlyt, mert -- mint észrevetted -- újabban a viselkedés nem a dokumentáció szerinti. Ez valóban egy hiba. De nem könnyű eldönteni, hogy a felhasználó mire gondolt, amikor nem írt eszközt a -l után. -- Feri. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: qemu host-ból consolon linux vm elér ése
On Fri, 12 Feb 2010 14:24:08 +0100, Gabor HALASZ halas...@freemail.hu wrote: 1. DMZ-be szeretnék tenni pár szolgáltatást (dns, www, mail gw). Ezen szolgáltatásokat tervezem külön virtuális gépekre. Ezek mellett ugyancsak dmz-be néhány próba gép is kerülne tesztelgetni. Ez imho hibas elgondolas, a virtualizacio es a security nem igazan fernek ossze. Az alap elképzelés - imho -, a hostot nem lehet elérni hálózaton. A guestek pedig külün-külön szolgáltatnak, így egy - virtuáls - gépen nem lesz karácsonyfa. A bridge körül érzek sántítást, de egyenlőre nem látom a konkrét veszélyt. :-( 2. Belső hálón elsősorban windows kerülne a guest(ek)re, ahol mssql vmware esxi. Nem fizetőst? Ránézek köszönöm! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid tömbök
Ferenc Wagner wrote: Gabor HALASZ halas...@freemail.hu writes: Ferenc Wagner wrote: Mi ebben a kusza? A feltett kérdésre (fdisk -l) teljesen korrekt választ adott. Szerintem. Izlesek es pofonok. man fdisk: -l List the partition tables for the specified devices and then exit. If no devices are given, those mentioned in /proc/partitions (if that exists) are used. userland toool, imho nem az a dolga, hogy a kernelinternalst vagy a fellelheto osszes blockdevicet reportolja a usernek. Úgy tűnik, a fejlesztők sem erre helyezik a hangsúlyt, mert -- mint észrevetted -- újabban a viselkedés nem a dokumentáció szerinti. Kerdes persze, hogy az en fdisk-em megis miert kepes a dokumentacionak megfeleloen viselkedni. A valasz nagyobb resze flame lenne, a kisebb resze pedig ez: sk8n:~# fdisk BusyBox v1.15.2 (2009-10-27 17:20:52 CET) multi-call binary -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid tömbök
On Fri, 12 Feb 2010, Gabor HALASZ wrote: Kerdes persze, hogy az en fdisk-em megis miert kepes a dokumentacionak megfeleloen viselkedni. A valasz nagyobb resze flame lenne, a kisebb resze pedig ez: Ha mar suroljuk a flame-et, akkor mar csak azt kerdeznem meg halkan, hogy az LVM, storage es raid koraban ki akar itt fdisket hasznalni? Inkabb osszeragaszgatni szoktam (stroge uj lun - uj scsi disk a linuxon, pv - bele egy meglevo vg-be), mint darabolni/particionalni. (igen, a storage tudna lun-t novelni, de a linux nem veszi eszre, ha menet kozben megno egy scsi diszk merete :) Udv, -=Lajbi=- LAJBER ZoltanSzent Istvan Egyetem, Informatika Hivatal HTH=Hope This Helps, YMMV=Your Mileage May Vary, HAND=Have A Nice Day _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: qemu host-ból consolon linux vm eléré se
szistvan wrote: On Fri, 12 Feb 2010 14:24:08 +0100, Gabor HALASZ halas...@freemail.hu wrote: 1. DMZ-be szeretnék tenni pár szolgáltatást (dns, www, mail gw). Ezen szolgáltatásokat tervezem külön virtuális gépekre. Ezek mellett ugyancsak dmz-be néhány próba gép is kerülne tesztelgetni. Ez imho hibas elgondolas, a virtualizacio es a security nem igazan fernek ossze. Az alap elképzelés - imho -, a hostot nem lehet elérni hálózaton. A guestek pedig külün-külön szolgáltatnak, így egy - virtuáls - gépen nem lesz karácsonyfa. Az osszes hypervisorban volt mar olyan hiba, ami lehetove tette a guest-ekbol kitorest. Nyilvan ezek nem tul gyakoriak es nem kis felkeszultseget igenyel a kihasznalasuk, igy valoszinuleg nem te leszel a celpontja egy ilyen tamadasnak, de a megkozelites problemas. A qmail/djbdns garantaltan biztonsagosabb es kisebb overheaddel jar, mint egy virtualizacio, arrol nem is beszelve, hogy mennyivel egyszerubb oket uzembiztosan bekonfiguralni. A www-vel meg semmit sem tudsz csinalni, mert ugyis a rajta futo bugos webappot fogjak felnyomni, elinditanak egy bot-ot, es spamelnek ezerrrel. 2. Belső hálón elsősorban windows kerülne a guest(ek)re, ahol mssql vmware esxi. Nem fizetőst? Ránézek köszönöm! Download VMware ESXi Get our free hypervisor. * Download Now http://www.vmware.com/products/esxi/ -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: qemu host-ból consolon linux vm elér ése
On Fri, 12 Feb 2010 14:56:10 +0100, Gabor HALASZ halas...@freemail.hu wrote: Az alap elképzelés - imho -, a hostot nem lehet elérni hálózaton. A guestek pedig külün-külön szolgáltatnak, így egy - virtuáls - gépen nem lesz karácsonyfa. Az osszes hypervisorban volt mar olyan hiba, ami lehetove tette a guest-ekbol kitorest. Nyilvan ezek nem tul gyakoriak es nem kis felkeszultseget igenyel a kihasznalasuk, igy valoszinuleg nem te leszel a celpontja egy ilyen tamadasnak, de a megkozelites problemas. A Ez világos. Nem örülök neki, de mérlegelve még mindig jobbank itélem meg, mint több gép vásárlása kis feladatokra, vagy 1 géppel ip aliassal karácsonyfát készíteni és 1 szolgáltatással borul minden (legfőképpen dns és mail gw zavarna). qmail/djbdns garantaltan biztonsagosabb es kisebb overheaddel jar, mint Ezzel egyetértek. egy virtualizacio, arrol nem is beszelve, hogy mennyivel egyszerubb oket uzembiztosan bekonfiguralni. A www-vel meg semmit sem tudsz csinalni, mert ugyis a rajta futo bugos webappot fogjak felnyomni, elinditanak egy bot-ot, es spamelnek ezerrrel. Sajnos ez van, de többek között emiatt virtualizálnék, az első pontban jelzett kitörési veszély mérlegelésével együtt. Download VMware ESXi Get our free hypervisor. * Download Now http://www.vmware.com/products/esxi/ Igen, eddig eljutottam ;-) Köszönöm! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid tömbök
Lajber Zoltan wrote: On Fri, 12 Feb 2010, Gabor HALASZ wrote: Kerdes persze, hogy az en fdisk-em megis miert kepes a dokumentacionak megfeleloen viselkedni. A valasz nagyobb resze flame lenne, a kisebb resze pedig ez: Ha mar suroljuk a flame-et, akkor mar csak azt kerdeznem meg halkan, hogy az LVM, storage es raid koraban ki akar itt fdisket hasznalni? Ha mar suroljuk a flamet, a zfs koraban ki akar lvm-et, storaget, raidet, ad absurdum linuxot hasznalni? :) Az lvm-hez kell egy teljesen felesleges absztrakcio, (dm lenyegeben ugyanazt csinalna, mint az md+udev), plusz meg az lvm a tetejere, mikozben a legtobb mai winux disztribucio 1-2 particiot hoz csak letre, igy erosen agyuval verebre, emelett, hogy valami performancia legyen, meg raraksz egy fs-t, amit pontosan hozza kell hangolni az alatta levo storage designjehez, br.. Inkabb osszeragaszgatni szoktam (stroge uj lun - uj scsi disk a linuxon, pv - bele egy meglevo vg-be), mint darabolni/particionalni. Ez meg csak hozzaadom a zpool-hoz, aztan utanaallitom a quotat azokon az fs-eken, ahol elfogyott a hely. -- Gabor HALASZ halas...@freemail.hu _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid tömbök
Lajber Zoltan la...@lajli.gau.hu writes: On Fri, 12 Feb 2010, Gabor HALASZ wrote: Kerdes persze, hogy az en fdisk-em megis miert kepes a dokumentacionak megfeleloen viselkedni. A valasz nagyobb resze flame lenne, a kisebb resze pedig ez: Ha mar suroljuk a flame-et, akkor mar csak azt kerdeznem meg halkan, hogy az LVM, storage es raid koraban ki akar itt fdisket hasznalni? A magam részéről már régóta várom, hogy kikerüljön a kernelből a partíciós táblák parse-olása, és a boot képernyőim megszabadulhassak több ring buffernyi SCSI hibaüzenettől. (igen, a storage tudna lun-t novelni, de a linux nem veszi eszre, ha menet kozben megno egy scsi diszk merete :) A commit c3279d1454cdfed02a557d789d8a6d08ab4cbe70 környékét nézted már? -- Feri. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
scponly chroot
Volt nemreg egy mukodo chroot-os scponly beallitas, amit meg az etch-ben raktam fel. Ez meg a lenny upgrade utan is mukodott (bar azt hiszem reboot nelkul zajlott le a dist-upgrade, es azota is folyamatosan megy a szerver), azonban ma egy ujabb hasonlo chroot-os scponly-t akartam beallitani a /usr/share/doc/scponly/setup-chroot -ban levo szkripttel, de nem sikerult eletet lehelni a dologba: * gftp-vel tesztelve (tobbek kozott) a password elkuldese utan csak var es var es nem tortenik semmi; * az /etc/scponly/debuglevel-t feljebb allitva az auth.log-ban *neha* a kovetkezot talaltam egy-egy probalkozas utan: Feb 12 12:17:37 galilei sshd[16561]: Accepted keyboard-interactive/pam for scpuser from 152.66.33.80 port 43769 ssh2 Feb 12 12:17:37 galilei sshd[16561]: pam_unix(sshd:session): session opened for user scpuser by (uid=0) Feb 12 12:17:37 galilei sshd[16561]: subsystem request for sftp Feb 12 12:17:37 galilei scponly[16564]: chrooted binary in place, will chroot() Feb 12 12:17:37 galilei scponly[16564]: 3 arguments in total. Feb 12 12:17:37 galilei scponly[16564]: ^Iarg 0 is scponlyc Feb 12 12:17:37 galilei scponly[16564]: ^Iarg 1 is -c Feb 12 12:17:37 galilei scponly[16564]: ^Iarg 2 is /usr/lib/openssh/sftp-server Feb 12 12:17:37 galilei scponly[16564]: opened log at LOG_AUTHPRIV, opts 0x0029 Feb 12 12:17:37 galilei sshd[16561]: pam_unix(sshd:session): session closed for user scpuser (A fenti *neha* az scponly debug-log-ra vonatkozik: azaz bizonyos probalkozasoknal nincs olyan log, csak az, hogy subsystem requested for sftp es aztan session closed ) Szoval az az abra, hogy probalkoztam a passwd-ben a kezdo dir allitgatasaval, aztan lattam, hogy a processzek kozott ket sftp-server is volt, azokat kilottem, es aztan most az a helyzet, ghogy a regi scponly user sem mukodik: ugyanugy hangup-ol a password elkuldese utan (ami persze jo, hiszen a pam szerint accepted). Lehetseges, hogy meg egy lenny elotti sftp-server processz futott, amivel mukodott a chrooted-scponly? (Ja, viszont az biztos, hogy az ssh-t ujrainditottam egy par hete, mert kivulrol a 22-es portot letiltottam es egy masikat allitottam be.) Na, mindegy... ha a problema nem ismeros, es tuti tipp nincs, akkor az lenne a kerdesem, hogy hogyan kellene azt megcsinalni, hogy * bizonyos userek rendesen hasznalhassak az sshd-t (ssh, sftp, stb.); * bizonyos userek neve alatt meg csak chroot-os sftp only szolgaltatashoz lehessen hozzaferni, normal ssh-hoz ne...? Lattam az sshd_config-ban olyan opciot, hogy ChrootDir, meg a man-ban olvastam olyat, hogy az internal-sftp subsystem-mel ez a chroot-os sftp eleg szimplan megoldahato, de akkor ez a beallitas kizarja a normal ssh hasznalatat, nem? Azaz a ket funkciohoz ket config file kell, es azokkal kell elinditani az sshd-t... A masik kerdes, hogy ha tobb ilyen scponly account lenne, akkor kicsit bonyolultnak erzem, hogy mindegyiknek kulon chroot-ot kelljen letrehozni... lehtne oket egy chroot-ba pakolni sajat incoming dir-rel, amit 2770-val egymas elol el is lehet zarni, nem? (Valoszinu, ha ez elobb eszembe jut, akkor most nem futok bele ebbe a nem mukodo scponly dologba... hanem majd csak vmikor kesobb :-) -- sZs _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Csak olvasható postafiókok
Norbert Vastagh írta: Merre induljak el? A csak olvasható pop3 / imap szerintem elég hülye ötlet, és nem is biztos, hogy megvalósítható: az archiválás jobb lenne talán. Exim4 van a szerveren. Olyan userrel tud futni az imap/pop szerver, ami csak olvasni tudja a maildireket(?), vagy akkor elhasal meg az elejen? _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Csak olvasható postafiókok
Merre induljak el? A csak olvasható pop3 / imap szerintem elég hülye ötlet, és nem is biztos, hogy megvalósítható: az archiválás jobb lenne talán. Exim4 van a szerveren. Emlekeim szerint az IMAP-ban nincs mozgatas, csak masolas es torles, tehat ha jol tevedek akkor valami igen okos proxyval szurheto ki. Pop3-nal nemileg egyszerubb a helyzet, bar az meg szeirntem nem fog sok evig mukodni, mert annyira sok level lesz az inbox-ban. Postfix-nel van always_bcc opcio ami hasznalhato erre, valoszinutlennek tartom, hogy exim nem tudna ilyet, szoval ez az irany ami meg szerintem a legjobbnak tunik. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Csak olvasható postafiókok
Norbert Vastagh vasti...@gmail.com wrote: Merre induljak el? A csak olvasható pop3 / imap szerintem elég hülye ötlet, és nem is biztos, hogy megvalósítható: az archiválás jobb lenne talán. Exim4 van a szerveren. Jo sok eve nem eximeztem, nem is akartam beleszolni, de aztan csak nem jon eximes tuti valasz, igy leirom halvany emlekeim a temaban :) Amikor csinaltam ilyet, akkor azt hiszem, hogy system filterrel csinaltam meg eloszor, aztan csinaltam egy transport/router parost erre. Mindent letett egy mailboxba (akkor meg az volt a divat) es egyebkent nem avatkozott bele a routerek melojaba. Azt hiszem, unseen volt a kulcsszo. Sajnos a konfigokat mar nem igen hiszem, hogy elo tudnam asni. Tudom ez nem sok, de hatha a ket kulcsszo segit valamit. -- Udv: Erdelyi Gabor _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Csak olvasható postafiókok
Norbert Vastagh írta: Merre induljak el? A csak olvasható pop3 / imap szerintem elég hülye ötlet, és nem is biztos, hogy megvalósítható: az archiválás jobb lenne talán. Exim4 van a szerveren. A pop3 esetén, ha a forrást megnézed és kikommentezed/kitörlöd belőle a DELE utasítást, fordíthatsz magadnak egy olyan pop3 démont amin nem lehet majd levelet törölni. Hogy mi értelme van, az kérdés, de ez is egy mód lehet. Balage _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
