Re: freeradius: user / mac-auth
Hi, "SZABO Zsolt" írta 2020-09-07 15:34-kor: > A kérdésem, hogy használ-e vki freeradius-t úgy, hogy > lehessen MAC címekkel egyéb auth nélkül hozzáférést kapni a LAN-hoz, > de ha valaki pl. EAP+TTLS / PAP-pal authentikál, annak ne kelljen > MAC címet regisztrálni. Már nem, de úgy rémlik, mintha régebben konfiguráltam volna hasonlót, de legalábbis láttam volna a catalyst-ek doksijában. Ha az akkori 2960-asok tudták, akkor a mostaniaknak is kell. Ami neked kell az a "mac auth bypass". Amikor kiküldi a switch az eapol üzeneteket, adott timeout-ig ha nem jön semmi válasz arra a porttól, akkor az első mac-cel, amit a porton hall, a switch maga játsza el az authenticator szerepét. Ha -X -el indítod a freeradius-t konzolon, az meg kilogol minden részletet szépen. Abból már ki lehet sakkozni, hogy milyen adatokat kell megadni a mac auth bypass működéséhez. De úgy rémlik, hogy ezt mint ha a config guide is leírná, csak ugye a sok részletben elveszik az ember, amikor olvassa ;-) Na már most feltéve, hogy egyáltalán Cisco switched van a történetre. Erről a részletről nem sokat árultál el. Felteszem egyébként, ha Cisco tud ilyeneket, akkor Juniper is. Soho játékosok esetén nem tudom van-e ilyesmi. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: HDD mount sikertelen, mi lehet a hiba?
Hi, "Csaba" írta 2020-07-24 14:30-kor: > Ezelőtt, ha nem is volt képes felcsatolni a HDD-t, ha kiadtam egy "dd > if=/dev/sda of=/dev/null bs=16M" parancsot, az hibátlanul lefutott, > tehát végigolvasta. > Táp nélkül használtam mindig is (táp nélküli sima USB ház), sose volt > probléma. A Raspberry Pi saját tápkábele nem cserélhető, a külső > házhoz pedig nem csatlakoztatható táp. Csereld le a hazat egy olyanra, aminek van sajat tapja. Siman lehet, hogy valami kondi, vagy feszstab adta meg magat az idok soran. Valoszinuleg nem erre lettek tervezve, hogy egy raspi minimal-powerjet konvertalgassak spinning disk motorjanak megtaplalasara. Akar a raspi usb portjaban is kinyirhatott egy feszstabot a folyamatos terheles. Esetleg, ha van hasonlo csatlakozoju (sata felteszem) ssd-d, akkor probalj egy olyat betenni a hazba, hogy azt olvassa-e a raspi. Abbol egyertelmuen kiderul, hogy feszultseg/ tapellatas gondok lesznek. Udv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Linux alatt használhatatlan HDD, mi lehet a hiba?
Hi, "Egon" írta 2019-01-25 13:23-kor: > "Fdisk -l" kimenettel rendben volt minden? Azt elso korben csak annyira neztem meg, hogy a szektorszam, amire panaszkodott kisebb-e, mint a lemez osszes szektoranak szama, de kb. meg a szamjegyek szama is kevesebb volt -> az elso egytizedben volt valahol a gebasz. Most leelenoriztem az fdisk-bol a szektorszamot: 3907029168 Pasztors-MacBook-Pro:~ pasztor$ echo $[3907029168/2] # Kilobajt 1953514584 Pasztors-MacBook-Pro:~ pasztor$ echo $[3907029168/2/1024] # Megabajt 1907729 Pasztors-MacBook-Pro:~ pasztor$ echo $[3907029168/2/1024/1024] # Gigabajt 1863 Az 1863 Giga seems legit. Ez egy 2TB-os (a gyarto altal szamolva) diszk. > Köszönöm az NCQ-ra vonatkozó tippet, megpróbálom. (y) > Egyébként az NCQ sima, SATA I. vezérlővel rendelkező, régi gépnél is > bekavarhatott? (abban is próbáltam tesztelni, meg más gépekben is, de > mindenhol egyforma volt a hibajelenség) Azt tippelnem igen. Ha a lemez lejelenti a vezerlo fele, hogy o tud ncq-t, akkor az OS megkuldi parhuzamosan tobb keressel, mint amennyit tenylegesen a hw + a rajta levo cache elbirna. Futottunk mar bele ilyenbe. Az ncq letiltasa megoldotta a problemat. > Megfelelő lesz, ha "libata.force=noncq" kernelparaméterrel kapcsolom > ki az NCQ-t? Azert annyira nem mostanaban volt, hogy fejbol emlekezzek ra, de ranezesre okesnak tunik. Udv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Linux alatt használhatatlan HDD, mi lehet a hiba?
Hi, "Egon" írta 2019-01-25 07:45-kor: > Mit tehetnék még? Probaltad mar az ncq-t kikapcsolni? Ugy remlik bizonyos lemezek/vezerlok nem annyira szeretik. Udv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: IP tables para
Hali, "Zoltán Gerendás" írta 2018-05-11 15:04-kor: > PÁSZTOR György írta (2018. május 10. 22:59): > > "Zoltán Gerendás" írta 2018-05-09 16:37-kor: > >> Az iptables-save kimenetét ide tettem: > >> https://pastebin.com/E3URP2KP > >> > > Ebben a kimenetben nem látom > >> >> -A ufw-user-input -s 192.168.0.0/16 -p tcp -m tcp --dport 8080 -j ACCEPT > >> >> -A ufw-user-input -s 192.168.0.0/16 -p udp -m udp --dport 8080 -j ACCEPT > > > > Ezt a két szabályt. > :( > Két gépen is volt hasonló és másikról küldtem a kimenetet :( > > > Lehet ez a gond? :) > > Könyörgöm, miért?! > > Gondoltam kipróbálom :) > Nekem is az jött le, hogy felejtős az egész. +1! Jó gondolat! Ahogy az embernek van már egy kis tapasztalata meg rálátása ezekre, a "konzerv" megoldásokkal olyan, mintha muszálykabátban kellene akrobatikus mutatványokat bemutatni. > Ami pastabin-en van az egy docker-en futó rendszer lenne. > > Már dobtam is az ufw-t, csak érdekelt, hogy mi miatt dobja el a > csomagok egy részét. Nyilván, akkor tudnánk biztosat nyilatkozni, ha azt az iptables-save-t látnánk, ahol eldobálja. Ha jól értem, akkor a dump nem is ott készült. Így nehéz meg-guesselni, hogy igaziból ott hogyan is ment félre, vagy mi volt az a másik szabály ami miatt idáig már nem jutott el, vagy hamarabb ment logdrop irányba. Vagy mi volt olyan feltétel, ami igaziből nem match-elt és nem is került be a logolt csomag ebbe a láncba. Kb. ez a kettő lehet: #1 korábban eldobódik #2 nem is kerül be ebbe a láncba, mert valami feltétel nem teljesül a "láncbaküldéshez". Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: IP tables para
Hi, "Zoltán Gerendás" írta 2018-05-09 16:37-kor: > Az iptables-save kimenetét ide tettem: > https://pastebin.com/E3URP2KP > Ebben a kimenetben nem látom > >> -A ufw-user-input -s 192.168.0.0/16 -p tcp -m tcp --dport 8080 -j ACCEPT > >> -A ufw-user-input -s 192.168.0.0/16 -p udp -m udp --dport 8080 -j ACCEPT Ezt a két szabályt. Lehet ez a gond? :) Nem gondolkodtál még az ufw skippelésén? Amennyire látom eléggé karácsonyfa rulesetet rak össze, és még csak nem is hatékony. De itt-ott a logikát sem értem benne. Pl. ilyen helyeken: -A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny -A ufw-before-input -m conntrack --ctstate INVALID -j DROP és -A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN -A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] " Miért nem teszi akkor az ufw-logging-deny végére azt a DROP-ot?! Így még a feldolgozásban végére ér az ufw-logging-deny láncnak, majd return-öl az ufw-before-input láncra, újra kiértékeli azt a szabályt, amit egyszer már kiértékelt, és csuda tudja mekkora lookup táblát kell egy ctstate kikereséséhez megnéznie... Maaajd ezután dobja el a csomagot. Könyörgöm, miért?! Értem én hogy script írta, de ekkora komplexitásnál biztos, hogy van még értelme ezt a salátát használni, ahelyett, hogy összeraknál valamit magadtól + esetleg ez, ahogy látom, tipikusan olyan use-case, amin még sokat tudna lendíteni egy ipset. De az is lehet, hogy nftables-el meg a logolás hatékonyságán tudnál fejleszteni. Bármi, csak... imho, ne ezt a kriptaszökevény scriptet. Eddig nem sok dolgom volt az ufw-vel, de ha ilyen módon szervezi a dolgait, akkor ennek kifejezetten örülök! ;-) Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: DHCP szerveren MAC-szűrés beállítása - nem működik?
Hi, "B. P. TBC" írta 2018-05-02 23:14-kor: > A kérdésem az lenne, hogy hol rontottam el a konfigolást, mit kéne másképp > csinálni, vagy egyáltalán hogy induljak el? > Köszönöm a segítséget! Ha a cél a "mac" szűréssel az lenne, hogy pl. dhcp snoopingot megfelelő adattal meg tudj etetni, akkor amit "hiánynak" láttam: be kell konfigurálni a dhcp szerverednek, hogy authoritatív. A különbség: ha nincs neki explicit megmondva, hogy adott subnetben ő authoritatív, akkor amire nem akar választ adni, egyszerűen csak nem küld választ. Lehet, hogy az allow class-ok mellé még kell neki explicit valami deny szabály is. Régen csináltam már ilyet. Viszont ha meg van neki mondva, hogy authoritatív és mindent jól csináltál, akkor a nem odavaló gépeknek kiküldi explicit a NAK replyt. Btw.: Annyira nem érzem "jó" védelemnek, hogy komplet oui-kat allowz. Így ha valaki besettenkedik a hálózatodra, egy ugyanolyan gyártójú eszközzel, mint a saját eszközparkod, máris a hajadra lehet kenni a mac szűrést. Nincs valami inventoryd valami egyszerű sql-ben/akármiben, amiből aztán lehetne generálni a konfigfájl adott részét? Ha nem is akarsz fix IP-t rendelni a gépekhez, az entryket attól még be lehet dobálni a poolba. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: IP tables para
Hali, "Zoltán Gerendás" írta 2018-05-03 11:07-kor: > Adott Ubuntu, 4.15.0-20-generic #21-Ubuntu SMP kernel. > Fut egy proxy 8080-as porton. > ufw a tűzfal generáló > > -A ufw-user-input -s 192.168.0.0/16 -p tcp -m tcp --dport 8080 -j ACCEPT > -A ufw-user-input -s 192.168.0.0/16 -p udp -m udp --dport 8080 -j ACCEPT > > Megy is jól a proxy, de néha pár IP csomagot még is megfog > > IN=eth0 OUT= MAC=00:16:3e:00:01:f6:00:16:3e:01:00:6d:08 > :00 SRC=192.168.2.2 DST=192.168.80.10 LEN=40 TOS=0x00 PREC=0x00 TTL=63 > ID=25179 DF PROTO=TCP SPT=34032 DPT=8080 W$ > (megy a 2.2 -es gépről a net!!) > > Hasonló egy másik gépen dnat -van (docker-be). > Jól megy a docker elérése kívülről, de néha pár csomagot szintén > blokkol az UFW szabály. > > Mi történhet itt? Úgy sokkal könnyebb ám, ha azt a szabályt is beidézed, ami a dropolást/ logolást csinálja, nem csak azt, hogy szerinted melyik allow-nak kellett volna átengednie! ;-) Meg mondjuk azt, hogy melyik másik chain-ből van és milyen szabály alapján meghívva ez az ufw-user-input lánc. Ha eldobta, akkor valószínűleg ezen szabályig el sem jutott a vezérlés. Valószínűleg ez a logolt csomag nem matchelt annak a szabálynak a feltételeire, ahol a -j ufw-user-input volt. Vagy már korábban futott rá a log-drop -ra. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Squid AD auth
Hali, "Hegedüs Ervin" írta 2017-11-07 08:06-kor: > On Mon, Nov 06, 2017 at 11:44:08PM +0100, PÁSZTOR György wrote: > > "Norbert Vastagh" írta 2017-11-06 22:19-kor: > > > Merre induljak el? És érdemes-e egyáltalán, vagy felejtse el a dolgot? > > > > Ami nekem kissé nem világos, hogy hogyan is jutna el a bejelentkezési infó > > a munkaállomástól a proxyig? > > úgy, hogy a proxy küld a kliensnek egy 407-es kódot. > https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.8 > > Ennek hatására a kliens (böngésző) bekéri az auth adatokat, ill > ha az rendelkezésre áll (cache, NTLM), akkor azonnal küldi. Na ez hasznos volt. Én is tanultam valamit. Ezek után már fogalmam nincs, hogy akkor ~10 éve, miért kellett kerülőút nekünk a satyr-ral :/ > > Ott a windowsos hálózat (domain és munkaállomások) már adottak voltak. > > Emlékeim szerint a http protokollban proxy-auth -ra nincs külön megoldás. > lásd fent. > > > Ha meg a http auth-ot ellövöd erre, akkor hogyan tud esetleg egy üf. / > > munkaállomás olyan weboldalt megnézni, aminek ténylegesen kellene http > > auth? > arra van a 401: > https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.2 > > A levél többi része nem releváns :) Yepp. Nekem csak a 401 volt meg. Ahogy írtam fent, a 407-ről lemaradtam. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Squid AD auth
Hi, "Norbert Vastagh" írta 2017-11-06 22:19-kor: > Merre induljak el? És érdemes-e egyáltalán, vagy felejtse el a dolgot? Ami nekem kissé nem világos, hogy hogyan is jutna el a bejelentkezési infó a munkaállomástól a proxyig? Maga a feladat nem lehetetlen! Volt részem hasonló "építményben". Ott a windowsos hálózat (domain és munkaállomások) már adottak voltak. Emlékeim szerint a http protokollban proxy-auth -ra nincs külön megoldás. Ha meg a http auth-ot ellövöd erre, akkor hogyan tud esetleg egy üf. / munkaállomás olyan weboldalt megnézni, aminek ténylegesen kellene http auth? Ennek a feloldására a mi esetünkben (pénzügyi intézmény külsős linux-os tanácsadója voltam ebben a történetben) egy másik 3rd party-t vontunk be. Ők konfiguráltak egy Zorp-ot a squid meg a munkaállomások közé. A satyr (ejtsd: "Szatír" ;-) ) mint agent fut a munkaállomásokon. A zorp így tudja a domain credential-okat. És ezt egy picit mágiával egy saját magunk által választott custom http headerbe (X-Proxy-User, X-Proxy-Groups, vagy fene emlékszik már. Ha jól rémlik, ebben viszont rugalmas volt a http, hogy X-* -al bármit beletehetsz a fejlécbe szabadon) ezeket az infókat betette a zorp. A squid oldalán meg faragtunk egy rakás szabályt, hogy ha X csoport tagja, akkor pl. csak ebédidőben és munkaidőn kívül tud FB-t nézni, kivéve ha amúgy Y csoport tagja, akiknek munkakörük, hogy hozzáférjenek bármikor. Meg ehhez hasonlók. Pl. Z csoport tagjainak meg eleve szinte semmi net, mert nem kell a munkájukhoz, csak intranet elérés. Ez / ezek most félig-meddig fiktív példák voltak, de a miket és hogyanra adhat kiindulási támpontot. A kulcsprobléma, amit írtam: A felhasználó adatait (usernév, csoporttagságok) beletenni a http-be, hogy aztán ezek mentén a squid tudjon döntést hozni az engedélyezésről vagy annak megtagadásáról. A satyr-t illetően nem tudom fejlesztik-e még. A Zorp-osokat kell megkérdezni. Magyar csapat. Profik. Jók. Privát véleményem szerint, a piacot tekintve olcsók is! Volt már aki ezt a meglátásomat vitatta. Aztán vett szart. Drágán. Ahogy egy volt kollégám szokta volt mondani, mikor hifi témákról beszéltünk: A jót egyszer kell csak megvenni, a szart sokszor. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Shell trace
Hi, "Attila Rajmund Nohl" írta 2017-05-08 15:26-kor: > PÁSZTOR György írta (2017. május 4. 22:58): > [...] > > Egy hint, mintának, kiindulási pontnak, ötletekhez: > > https://github.com/balabit/syslog-ng/blob/master/contrib/syslog-debun > > Itt keresd a debun_init() fv-t, és próbáld meg az ott felhasznált ötletet > > lemodellezni. Már ha az is megfelel neked, hogy el kell indíts egy tail -f > > -et a háttérben, amit a script futása legvégén meg le kell lőjj, ergo a > > leg-legvége a kimeneteknek nem fog bekerülni a scriptbe, ami a kill-ed után > > történik. Ha együtt tudsz élni ennyivel. > > Lelövés: debun_do_tarball(). > > Itt én a végén még a .tgz nevét kiírtam, + ami a .tgz elkészülte után > > történt, az értelemszerűen már nem került be a tgz-be. > > Ez majdnem jó. Illetve jó, csak azt is szeretném, hogy az stderr is el > legyen mentve meg ki is írja a képernyőre. Ha azt is átirányítom egy > trace file-ba és arra is megy egy tail -f, akkor látszik a kimenet, > csak éppen összekeveredik az stdout-tal (az egyik parancs kimenetébe > beleíródik a következő hibaüzenete). Ha alaposan megnézed a scriptet, akkor ez a stderr-t is menti, és kiírja. Igen, annyiban igazad van, hogy a stdout és stderr összefésülve fog a fájlban is megjelenni. Viszont úgy elég egy tail is. Őszintén szólva én pont így szerettem volna, mert így van esélyem meglátni, hogy mi mi után következett, annak meg nem éreztem jelentőségét, hogy valami a stderr-en jelent-e meg, vagy a stdin-en. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Shell trace
Hi, "Attila Rajmund Nohl" írta 2017-05-04 17:57-kor: > Egy shell (elég ha csak bash-ra megy, de ha ksh-ra is működik, még > jobb) scriptben szeretném logolni, hogy milyen parancsok hajtódnak > végre milyen kimenettel úgy, hogy közben minden kimenetet a user is > lásson. Nagyjából a 'set -x' kimenetét szeretném elmenteni. Amit > próbáltam: > > exec &> >(tee $LOGFILE) > exec 2>$TRACEFILE > > Elakad, ha a script meghívja önmagát még akkor is, ha a második > futásnál a LOGFILE értéke más (gondolom a két tee akad össze). Továbbá > a hibaüzenetet (ami stderr-re megy) nem látja a user. És nem megy ksh Egy hint, mintának, kiindulási pontnak, ötletekhez: https://github.com/balabit/syslog-ng/blob/master/contrib/syslog-debun Itt keresd a debun_init() fv-t, és próbáld meg az ott felhasznált ötletet lemodellezni. Már ha az is megfelel neked, hogy el kell indíts egy tail -f -et a háttérben, amit a script futása legvégén meg le kell lőjj, ergo a leg-legvége a kimeneteknek nem fog bekerülni a scriptbe, ami a kill-ed után történik. Ha együtt tudsz élni ennyivel. Lelövés: debun_do_tarball(). Itt én a végén még a .tgz nevét kiírtam, + ami a .tgz elkészülte után történt, az értelemszerűen már nem került be a tgz-be. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: backscatter?
Hi, "Zs" írta 2017-01-06 10:09-kor: > Úgy, hogy felokosítod a postfixet, hogy ellenőrizze a local-part > tartalmát is. Az Exchange ha nem tévedek, LDAP-ban tárolja az > user adatbázisát - tehát forrás van, ahonnan kinyerhető az > érvényes fiókok listája. Hogy ezt hogy oldod meg, az nyilván a helyi > adottságoknak és lehetőségeknek a függvénye... > - postfix virtual user és ez az LDAP-ból jön > - postfix virtual user, de file-ból jön, a file tartalmát meg az Exchange > frissítgeti. Ez ugyan kissé nyakatekertnek tűnik az előbbihez képest, > viszont ekkor a postfixes gépen nincs semmilyen lehetőség az Exchange > elérésére (kivéve a 25/tcp), ami biztonságosabb megoldásnak tekinthető > az előző megoldáshoz képest (Nyilván van hátulütője is, mert ha Kiss > Pista Jóska kap egy fiókot, akkor amíg a postfixen nem frissül a file, > addig nem eshet be levél se neki (kintről).) Hasonlo problema kezelesere irtam anno ezt: http://linux.gyakg.u-szeged.hu/~pasztor/projects/mailstuff/relaycheck.pl Nem a legokosabb, nem emlexem, hogy lenne benne cache-ing, vagy barmi, de kiindulasi alapnak jo! ;) Udv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Stream check
Hali, "Szima Gábor" írta 2016-10-25 13:38-kor: > On Tue, 25 Oct 2016, Kiss Gabor wrote: > >Akkor már jobb, ha írsz egy kurta perl scriptet. > > Akkor inkább az egészet C-ben. Gondoltam nem találom fel a meleg vizet, de > ezek szerint nem nagyon van még ilyen. Ha csak az kell, hogy leelenőrizd, hogy nem sérült meg, és nem ennyire szigorú a formátum, akkor miért nem vezeted át rar-on, -m0 Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: indításkor-leállításkor fusson le egy parancs
Szia, "Kovács Géza" írta 2016-09-20 15:51-kor: > Ezt a kis shell-scriptet, ami normálisan le is fut és amíg le nem > futott, a rendszer nem áll le, megírod? > Különösen ez a nehéz nekem. > A sleep nem jó ötlet, mert időnként továbbtarthat a grub-install. > Én sajnos nem értek hozzá, ötletem max ennyi: Avval együtt, hogy ilyen keveset tudsz a scriptelésről, a rendszer bootolási folyamatáról, runlevelekről, környezeti változókról, stb. Biztosan jó ötletnek tartod, egy ilyen dolog automatizált futtatását? Csak egy hint: Avval együtt, hogy meg is tudnám csinálni. Rettenetes ötletnek tartom, ami annyi szinten mehet félre. Van egy olyan érzésem, hogy valami történik a rendszereden. Megfelelő ismeretek hiányában próbálsz egy még annál is rosszabb tüneti kezelést adni a problémára, a valódi root cause feltárása helyett. Javaslom az alábbi kérdések megfontolását: * A jelenlegi helyzet kritikus / kezelhető vagy csak kényelmetlenség? Gyanítom, semmi esetre sem a kritikus. Ebből kiindulva én a következő kérdésekkel folytatnám: * Tudok-e / tudsz-e valamilyen egyéb megoldást adni a probléma mitigálására? * Mi lehet a valódi probléma? * Milyen ismereteket kell elsajátítanom a probléma feltárása érdekében? Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Melyik mini számítógéppel használható elfogadható sebességgel a Gnome környezet?
Hi, "Kovács Géza" írta 2016-08-20 19:42-kor: > Raspberry Pi, Banana Pi, vagy ODROID-XU4, ezek közül melyiken menne > legjobban a Gnome? > Természetesen tudom hogy nem asztali gépnek van kitalálva, csak Gnome > kellene, meg böngészés-levelezés. > Tudom hogy tán valami minimálisabb asztali környezet jobb lenne de a > Gnome érdekelne. > Raspbian-ban lévő Gnome úgy van optimalizálva hogy normál sbességgel > elmenjen rajta? > Érdekelne ha valakinek van tapasztalata. Intel nuc, Gigabyte Brix, stb.? Van Raspi-m. openelec elmegy rajta jol. De az nem desktop usage, es nagyobb bitrateknel mar akadozik. Most nemreg ota van egy Odroid C2-m. Egyelore meg eleg gyerekcipoben levo joszagnak erzem. A "gyari" ubuntu mate-t hasznal. Nem egy kapkodo idegbolond. Pedig 2G ram van benne! Probaltam rajta Archphile-t. "Szoros" a hangja. Meg ugy altalaban az mpd csinal rajta valami furcsat, amikor usb-n kell kitolja a hangot egy dac-nak. Probaltam az alpha allapotu libreelec-et. Eleg eroteljesen akadozik meg. Pedig ha azt nezzuk, boven sokkal erosebb mint a raspi, csak valami meg nagyon nincs rajta osszecsiszolva. Udv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
Hi, "Szima Gábor" írta 2016-02-03 13:19-kor: > >>Miért is kell ez neked? Fejtsd ki, kérlek! > > > >Le a kalappal! Nagyon szépen kifejtetted, amit én is gondolok az egészről. > > Gondolom az uránról is kizárólag az atombomba jut az eszetekbe, véletlenül > sem az erőmű... Nem, de ha sötétben villlogtat valaki egy nagykést, akkor nem feltétlenül az jut róla eszembe, hogy ő most falatozni szeretne. Picit tisztább és világosabb kommunikáció mentén nem lenne ilyen negatív sugallata a dolognak. Nyilván, mikor már rá lett kérdezve (!) akkor szépen megmagyaráztad. Ha rögtön az elején tisztázod a dolgokat, akkor kimarad egy fölösleges kör. > >A másik amit nem értek: gyakorlatilag le is írta emberünk a megoldást, csak > >a unix szemlélet hiányzik belőle. Ott a csomó kis legókocka. > >Az xwd-t, már meg is írta, hogy le tudja menteni a képernyőt. > > > >Ha nem akar protokoll-t túlbonyolítani, akkor fogja, és egy one-liner > >shellscriptbe rágyógyítja, hogy megnézi, ki az aktuális user a :0-n > >(feltéve, hogy nincs másik X session), sudo-zik rá, hogy a mit bűvös > >sütijét elérje, majd amit lement tempfile-t a cucc, azt kivágja stdout-ra, > >és del. > > Stabil ipari cucc kell, a meleg vizet pedig nem szeretném feltalálni. > Ha nincs ilyen, akkor állok neki rendesen megírni. Az xwd és inetd készletekből melyik nem stabil? Amennyire a feladatot megértettem, mivel ipari kivetítős mókáról van szó, még azt sem kell találgatni, hogy melyik user nevében fut a :0 X session, mert még valószínűleg az is fix. Csak össze kell passzintani a két legókockát. Izlés szerint, az ssl-t, mint harmadikat meg még odatenni. Ebből neked melyik a meleg víz feltalálása? Már egyszer javasoltam, amit Lenin is annyit mondott: Unix filozófia, Unix filozófia, Unix filozófia. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
Hi, "Kiss Gabor" írta 2016-02-03 11:02-kor: > Ha jól sejtem, bizonyos operációs rendszerű gépek bizonyos képernyőiről > szeretnél rendszeresen képeket gyűjteni az előtte ülő user > folytatólagos közreműködése nélkül. Ez a feladat? > > Ez minden cracker álma. :-) > Mármint a delikvens tudta és engedélye nélkül screenshotokat lopni. > És lássuk be, ez ellen kézzel-lábbal védekeznek a userek. > > Miért is kell ez neked? Fejtsd ki, kérlek! Le a kalappal! Nagyon szépen kifejtetted, amit én is gondolok az egészről. A másik amit nem értek: gyakorlatilag le is írta emberünk a megoldást, csak a unix szemlélet hiányzik belőle. Ott a csomó kis legókocka. Az xwd-t, már meg is írta, hogy le tudja menteni a képernyőt. Ha nem akar protokoll-t túlbonyolítani, akkor fogja, és egy one-liner shellscriptbe rágyógyítja, hogy megnézi, ki az aktuális user a :0-n (feltéve, hogy nincs másik X session), sudo-zik rá, hogy a mit bűvös sütijét elérje, majd amit lement tempfile-t a cucc, azt kivágja stdout-ra, és del. Ha még védelmet is akar, akkor az egész stdout-os történetet egy openssl-el becsomagolja, hogy a klienstől kérjen egy adott CA által aláírt tanúsítványt (meg persze ő is felmutasson egy szépet, amivel a saját stream-jét titkosítja), és kézcsók. A portra rátevés meg megint nem egy probléma. Ha másképp nem megy: inetd, xinetd, vagy egy kb. néhány soros Net::Server alapú perl program, a'la: http://search.cpan.org/dist/Net-Server/lib/Net/Server.pod Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: clone zilla
Hi,
"Zana János" írta 2015-12-30 12:33-kor:
> 2015-12-30 09:11 keltezéssel, Nemes Szabolcs írta:
> Megtehetem-e, hogy a clonezilla lemezzel újramásolom az XP-t?
> Ezúttal nem a teljes winchestert, hanem csak az XP partíciót. Ezzel
> annyi változott, hogy az új partíció nagyobb (pont ezért kezdtem nele az
> egészbe; a régi veszedelmesen kicsivé vált). Üdv, János
Amennyire emlékszem a thread-re te nem csak lemásolni akarod az XP
partíciót, de más helyre rakni a lemezen ("tolatni").
Lehet ilyet. De amennyire emlékszem, mikor utoljára én hasonlót csináltam,
akkor volt valami leírás róla, hogy a partícióban hol, mit és hogyan kell
hexaeditorral átírni.
Ti. a bootloadere valami szektorszámot fixen beledrótozott valahová.
Halvány emlék csak, rég nem használtam már XP-t.
De ha áthelyezed a partíciót az új lemezen, az eredeti helyéhez képest,
akkor érdemes lehet erre is figyelni!
Üdv,
Gyu
_
linux lista - linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: parancsok megjegyzése
Hi, "Almádi Péter" írta 2015-10-30 15:00-kor: > Google-zni mindenki tud, gondolom ő egyéni tapasztalatokra, már > kipróbált megoldásokra kíváncsi. "gondolni" mindenki tud. Sajnos a feladat környezeti paramétereinek specifikálása hiányos. Ahogyan másik thread-ben írták: mind megkerülhető. BTW: Ha kifejezetten az ssh-ra kell lőni, és tényleg fontos a feladat, akkor költségkeret is van rá, és akkor meg már lehet venni scb-t is. A múltkor (nem emlékszem pontosan mikor, de valamikor az elmúlt kb. fél évben) épp kiveséztük linux flame-n. A problémakört is, meg az scb-related és hasonló problémára készült megoldásokat is. ;-) Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: root csere boot kozben
Hi, "Attila Rajmund Nohl" írta 2015-08-25 13:25-kor: > dz Zana János írta (2015. augusztus 25. 12:48): > > A gépemből kiszedtük a PATA winchestert, és most SATA van benne. Ellenben az > > a harddiszk tertalma, amelyen a linux van, NEM VÁLTOZOTT. A probléma ennek > > ellenére mégis a régi. F12-vel választok boot winchestert (az elsőn van az > > új Windows 7, a másodikon a linux). A linux szabályosan bebootol, ám > > > > -> boot közben kicseréli önmagát a két harddiszk <- > > Nem értek különösebben hozzá, de mostanában nem UUID alapján szokás > mount-olni, pont azért, hogy az ilyen átneveződések ne okozzanak > gondot? Azt tippelném, nem a mountolással van a probléma, hanem később, ha grub-bal kell valamit machinálni. Amúgy meg a cserére tippem: /etc/udev-akármi környékén néznék szét, lévén az eth-ra is vannak hasonlók, amik ugye függetlenül, hogy melyik slotban, vagy a bios milyen sorrendben inicializálta, stb. a mac-ek szerint adja vissza az eth neveket, el tudom képzelni, hogy létezik ilyen a hdd-kre is. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: h.264
Hi, "Toth Zoltan" írta 2015-07-14 22:16-kor: > mondjuk persze az érdekel volna , hogyan..:-) milyen software-rel.. ... kérdésre ... válasz. De legyen neked gyereknap: ffmpeg, mplayer, vlc, ... Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: h.264
Hi, "Toth Zoltan" írta 2015-06-26 10:23-kor: > Linux alol el lehet érni ilyen video stream eszközöket ? Kamerarendszer, , > IP kamera.. El. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
Hi, "Kiss Gabor" írta 2015-06-11 11:04-kor: > > napod, vagy kettő? Igen. Megfizették? Igen. Hol a hiba? Nem csináltunk > > korszakalkotót? Kit érdekel, hogy távolról-e vagy helyben állítottál át > > 100 gép bios-át? Senkit. > > Attól félek nem lenne semmi értelme. > > a) A nettó munkavégzés semmivel sem lenne gyorsabb, hiszen ugyanúgy Yepp. Én tudom / sejtem / sejtettem miről van szó, ezért a feladat jogosultságát nem is kérdőjeleztem meg. Ennyire már ismerlek! ;-) (+ a jelenlegi munáltatómnál amúgy is a céges kultúra része, hogy ennyire azért bízunk a kollégákban, hogy ha kérdez egy ilyesmit, akkor biztosan elég alaposan körüljárta a dolgot, és biztosan jó oka van rá! ;-) ) > > Miért kell egy egyszerű dologból rakétakilövést > > csinálni? Mellesleg amennyi időt ezzel eltöltöttél, ennyi idő alatt (10 Válaszolok Benci kérdésére, helyetted is: Mert most csak ez a száz gép van éppen. De holnap lehet, hogy 400, lehet hogy másik 5 gépterem is becsatlakozik, pl. Szegedről, Pécsről, Sopronból, Dunaújvárosból és... Legyen mondjuk Veszprém! :) Ott hirtelen nem tudom van-e SC infratruktúra. + ahogy már alább g is megírta: további módosításokra is szükség lehet. > > perc/4 gép) már régen kész lennél. Ezt hívják komplikálásnak, nem? > > De hisz rég kész is vagyok! :-) > Viszont látom a jövőt. A gép tervezett üzemideje alatt biztosan > lesz még ilyen igény, hogy minden BIOS-ban turkálni kell. > És milyen jó lenne, hogy abban a pillanatban > le tudnám tenni a megoldást az asztalra. Amivel időt spórolok meg a > kollégáimnak. (Akiknek most csak besegítettem a rohammunkában.) Sejtettem, hogy az SC projekt van a háttérben. Viszont, ha ennyire raklapszám veszitek a gépet a HP-tól, akkor az is már szerintem tárgyalási alap. ...ci sok milliót kifizettek nekik. Még a windowsos HP laptopomra is, amit mondjuk utáltam, pont a HP ügyes-bajos szutykai miatt, de volt egy windowsos app, ahol ha megadtam (volna) a bios jelszót (amit sajnos elfelejtettem) körbe tudtam kattintgatni a bios beállításokat. (Átállításhoz kérte volna a bios jelszót, nézegetni a jelszó nélkül is tudtam. Valami TPM csoda is még pluszban levédte.) a; kértetek valamilyen szintű supportot is a gépekhez, hiszen garancia is szóba került -> kéritek a megfelelő tool-t .deb/.rpm/.run(linux,x86,elf) forátumban. Ha nem adnak, akkor hoci vissza a zsé kifizetése! b; nem lett semilyen support és rendelkezésreállás kérve (sajnos emlékszem, hogy akadémiai körökben szerettünk ilyesmin spórolni :'( ), akkor viszont meggondolandó, hogy ezen esetben ez miért maradt el, illetve nem-e megérte volna... Esetleg még mindig meg lehet keresni a HP-t avval, hogy ha legközelebb is szeretnék a következő párszáz gépet szállítani, akkor most üzletpolitikai érdekből adnak nektek egy ilyen tool-t, záros időn belül. (Mondjuk max. 3 hónap-ot tartok reálisnak, ha feltesszük, hogy 0-ról kell induljanak a linuxos bináris kifejlesztésével!) c; mégis tesztek openbios-t a gépekre ha ellenállnak, és ha nem akarják openbios-sal a garis cseréket ellátni, akkor... hacsak nem épp alaplaphiba van... a garis ügyintézés menetrendjébe / munkafolyamatába beírjátok, hogy mielőtt a HP-nek leadjátok a hibajegyet, előtte az alaplapot flasheljétek vissza ;-) Ha az openbios segítségével managelhetőbb lesz, még lehet, hogy az az 1-2 elhullott alaplap, árban még akkor is alatta marad az egésznek, mint amit esetleg a support áron elspóroltatok. De azt mondom nem kell a HP-val sem a "baz+ nyuszika a fűnyíródat" mentalistával kezdeni. Nagyon szeretik PR-olni, hogy mennyire linux, meg debianbarátok, meg minden félét. Esetleg megérhet nekik egy PR-jópontot, hogy a magyar szuperszámítógép projekten két pixelel nagyobb hp logó lehet... Amikor igaziból le is lehetne tagadni ;-) Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
Hi, "Kiss Gabor" írta 2015-06-09 16:00-kor: > Lehet, bár nem értünk egyet abban, hogy mi a releváns és mi nem. > De konkrét kérdésekre természetesen konkrét választ tudok adni. ... > > segíteni: egyéb lehetőségek, amiket már eddig megfigyeltél -> > > Pl. van-e olyan ilo-n keresztül bekonfigurálható boot opsün (ibm-eknél és > > supermicroknál láttam ilyet, a hp-t meg már egy évtizede megútáltam :P), > > hogy a következő boot, az a biosba belépés legyen > > Nincs, és megint csak hangsúlyozom, nem azt kértem, hogy felgyorsítani > segítsetek a favágómunkát, hanem kiváltani egy teljesen más koncepciójú > megközelítéssel. Aminek hosszú távon bontakoznak majd ki a rejtett > előnyei. :-) > Tehát egyetlen olyan kérdés nem releváns, ami a setup menüre, > annak elérésére stb. vonatkozik. Ok. Openbios, és egyéb custom főzött ilo-k lehetőségét már elvetetted arra való hivatkozással, hogy gari ugrott. Miután elcseppentetted, de legalábbis utaltál rá, hogy a garancia neked fontos lehet. Meg gondolom, akkor az is, hogy Gyártó által támogatott módon tedd ezt az egész hóbelevancot. Akkor viszont az nvram írogatás sem épp a gyártó által támogatott, max. megpróbálod megkerülni, hogy a gyártó rád tudja bizonyítani, hogy amit elkövettél, azt úgy tetted, ami nem a támogatott út. > Nekem az az információ értékes, hogy miként lehet programból > írni/olvasni ugyanazokat az eltárolt biteket, amelyeket általában > a setup menü révén, interaktívan manipulál az ember. Személy szerint, nem igazán látom az érdemi különbséget aközött, hogy melyik "nvram"-ban (beállítások vs. "bios" / "ilo" kód flashelése) turkálsz, a gyártó által adott interfészeket megkerülve. Hákolás mindkettő. > Erre van szükségem. Pont. Nem érdekelnek az interaktivitás felőli > megközelítések. Ok. Értjük. Most már tudjuk is. > (Talán felesleges megemlítenem, hogy ezt én jobban el tudom dönteni, > mert én ismerem a gondolataimat, az érdekeltségi viszonyaimat, a > motivációmat, az emberi és tárgyi környezetemet, a hosszú távú > stratégiámat stb.) Igen, viszont itt a listán mi a szakmai segítségnyújtással foglalkozunk és nem a gondolatolvasással. Ami olyan információ, hogy a feladathoz tartozik, oszd meg és ne várd, hogy azt is mi találjuk ki. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
Hi, "Kiss Gabor" írta 2015-06-09 15:12-kor: > A "belépek gépek BIOS-ába" konkrétan úgy történik, hogy egy adott > rövidke intervallumban, meg kell nyomnom az F9 gombot. Amikor > az adott gép ezt írja ki. Nehezítés: nem egyformán gyorsak, nem > egyszerre jutnak el erre a pontra. (Onnan tudom, hogy négyesével > végigmentem rajtuk.) Ok, és ha kezdőállapotnak, először egyesével mégy körbe, mindegyiket csak odáig tolod el, hogy ott legyen a BIOS ugyanazon menüjének, ugyanazon pontján állva? > > belépsz a gépek BIOS-ába és setupolod őket. Így képzeltem. > > Szóval mit fogok látni a képen, ha egyszerre lépek be az összes gépre, > és mi biztosítja, hogy mindegyikhez akkor jusson el az F9, > amikor kell? :-) Az a rész kézimunka. Hacsak... Nincs olyan az ilo-ban, hogy next boot device: boot into bios. > További nehezítés: két gép nem reagál az F9-re sem, és üres a kép. > (Már le is adtam hibára a HP-nek.) Releváns ez az információ most a feladat szempontjából? (ha már :P) > > De olyan lassan csöpögteted az információt, hogy kábé csak találgatni > > tudunk... > > Bocs, de egy másik feladatot akarsz/akartok megoldani, mint amit > megkérdeztem. :-) Nem. Ő / mi a problémát megoldani segítünk Nekem az az érzésem, hogy te látsz bele, berögződések és prekoncepciók mentén olyan dolgokat, amik nem biztos, hogy úgy vannak még! Tegyük el az idejétmúlt paradigmáinkat a pincébe (mint a turbó Pascal-ból írt dos-os hákolások!), és nézzük a _problémát_ tiszta szemüvegen át! > A kérdés az volt: hogy lehetne az NVRAM egészét, és nem csak a > standard 112 byte-ot manipulálni az adott vason futó Linuxból? > EHHEZ milyen információt kérsz még? Az "NVRAM", az az említett 112 (biztos?) byte. Az ami nem ott van, az már gyártó/ biosspecifikus. Hmm... Amik magadtól is eszedbe kellettek volna, hogy jussanak, mint releváns infók a probléma szempontjából: * A konkrét gépek típusa (HP Proliant ML ..., vagy akármi, pontos spec) * A BIOS konkrét gyártója (AMI?) és verziója (0.0.0.0.1 :P) * Ilo pontos verzió * proaktívan, minket segítve és nem szopatva, hogy hatékonyabban tudjunk segíteni: egyéb lehetőségek, amiket már eddig megfigyeltél -> Pl. van-e olyan ilo-n keresztül bekonfigurálható boot opsün (ibm-eknél és supermicroknál láttam ilyet, a hp-t meg már egy évtizede megútáltam :P), hogy a következő boot, az a biosba belépés legyen * Van-e password a bios-okon, illetve azt kell-e beállítanod? (magyarán, kell-e extra komplikációkra számítsunk) * Ilo tud-e virtuális floppy-t emulgeálni * Bios tudja-e floppy-ra kimenteni a beállításait * Bios be tudja-e tölteni az iLo által emulált floppy-ról is a beállításait It dag dalie Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
Hi, "Kiss Gabor" írta 2015-06-08 17:35-kor: > On 06/08/2015 05:06 PM, Ferenc Wagner wrote: > > Kiss Gabor writes: > > > >> Volna itt majdnem 100 egyforma gép, aminek a BIOS Setupját módosítani > >> kellene. > > > > Nincs semmilyen konzol átirányítási lehetőség ezekben a BIOS-okban? > > Serial over LAN, IPMI, bármi? > > Dehogynincs. TEXTCONS az iLO-ban. > > De mit segít ez a scriptelésben? > Pontosan azt akartam elkerülni, hogy mindegyiket kézzel setupoljam. > (De már hozzákezdtem. Négyesével. Kb. 10 percig tart egy turnus.) Az nagyon ortodox ötlet, hogy custom főzött ilo-t teszel beléjük? Bár, ha jól értettem, akkor HP, azért az elég zárt. Supermicro-k főzött ipmi firmware-éről hallottam már sikertörténeteket! ;-) Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
Hi, "Kiss Gabor" írta 2015-06-08 15:09-kor: > Volna itt majdnem 100 egyforma gép, aminek a BIOS Setupját módosítani > kellene. Sebaj, mondtam, egynél módosítok, aztán megnézem > milyen bitek változtak a /dev/nvram-ban, majd azt beírom a többibe is. > > No, elbuktam. A /dev/nvram-ban csak a tradicionális 112 byte látszik. > Az viszont változatlan. Ezen a tartományon kívül módosul az adat. > Mit lehetne itt még tenni azon kívül, hogy arcom verejtékével > mind az összeset egyenként ???egállítom, kézzel setupolom, aztán reboot? Körbenézted már a bios lehetőségeit? Kb. 10 évvel ezelőtti HP gépeknél volt ilyen a biosban, hogy egyet beállítottál, kimentetted (akkor még) kisfloppy-ra a beállítást, majd fogtad a floppy-t odamentél a következőhöz, és arról betöltötte a beállításokat, majd a következőhöz is, majd a következőhöz is, sít. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: hálózat eltűnik
Hi, "B. P. TBC" írta 2015-05-29 13:14-kor: > De az ethtool p3p1 ezt adja: (valamiért ez a hálózati interfész neve) Arra gondoltál már, hogy ez esetleg, valamilyen suse-specifikus viselkedés, és nem kifejezetten "generál"-linuxos a háttere? Suse-related listákon, fórumokban, gugli keresést a témában próbáltál már? Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: partial lv
Hi, "Árpád Magosányi" írta 2015-05-02 20:27-kor: > Azt mondja az lvm, hogy ő inkább nem szeretné aktiválni a vg-t, mert > partial lv-k vannak rajta. > Viszont az lvdisplay -m kimenetében én látom az összes extentet. Mi > lehet a baja? Nem néztem mélyebben utána, de: * az lvdisplay -m , hogy mutassa, ellenőrzi is, hogy elérhető az a terület a vg-ből? * előfordulhat olyan szituáció, hogy a vg több pv-ből áll, és bár a többi pv-ről még semmi nem lett felhasználve, de esetleg ezért látszódik az lvdisplay -m -ben? (Bár, akkor nem partial lv-t mondana) * esetleg, hogy az lvdisplay -m, nem-e csak azokat az lv-ket mutatja a vg-ben, amikhez aktuálisan minden pe elérhető, a többit meg nem? Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Strapabíró távolra logolás
Hi, "Kiss Gabor" írta 2015-04-13 11:45-kor: > > On 04/13/2015 11:13 AM, PÁSZTOR György wrote: > > AFAIK az OSE verzióba is a tervek között van a sima disk buffer. ;-) > > Érdemes lehet már most github-on jelezni, hogy a tervezéskor a disk buffert > > Ööö... félek kicsúsznék minden határidőből, ha erre várnék. :-) Nem is azt mondtam, hogy ez konkrétan most a te problémád meg fogja záros időn belül oldani. De az utókor számára hagyhatsz egy újabb pozitív nyomot, hogy az OSE diskbuffer ilyen remekbeszabott dolog lesz, hogy még erre az igényre is figyelnek az implementációjánál! ;-) Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Strapabíró távolra logolás
Hi, "Kiss Gábor" írta 2015-04-12 20:59-kor: > On 04/12/15 20:05, Almádi Péter wrote: > > Esetleg syslog-ng > > A fizetős változat valóban tudná... Abban van kétféle disk buffer is. Simán disk buffer és reliable disk buffer. AFAIK az OSE verzióba is a tervek között van a sima disk buffer. ;-) Érdemes lehet már most github-on jelezni, hogy a tervezéskor a disk buffert te olyannak szeretnéd, hogy konfigurálható legyen, és adott esetben ringbuffer legyen, és a régebbieket csapja felül az újabbakkal adott esetben, és ne a legrégebbieket őrizze, majd amit már nem tud letárolni dobja el... Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Read-only diszk Ubuntuval
Hi,
"Árpád Magosányi" írta 2015-03-09 07:24-kor:
> read-only diszkre szeretnék ubuntut tenni (virtuális gép, kvm-ben)
> Jelenleg két baj van vele:
>
> 1. a grub valamiért megáll a menüben, kézzel kell entert nyomni
>
> 2. utána meg kiírja hogy "failure writing sector 0x(nemtommennyi) to
> hd0", és hogy nyomjak egy any key-t.
>
> bármi ötlet hogy ezek mitől vannak és hogyan javíthatóak?
A menüben megáll részt nem sejtem mi lehet, de a másodikra a tippem, hogy
el akarná menteni, mit választottál. Részlet egy "átlag" grub.cfg-ből:
if [ "${prev_saved_entry}" ]; then
set saved_entry="${prev_saved_entry}"
save_env saved_entry
set prev_saved_entry=
save_env prev_saved_entry
set boot_once=true
fi
function savedefault {
if [ -z "${boot_once}" ]; then
saved_entry="${chosen}"
save_env saved_entry
fi
}
function recordfail {
set recordfail=1
if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env
recordfail; fi; fi
}
Az a tippem, hogy ezej a save_env -ek, ezek 0x(nemtommenyi) sectorba
mentődnek.
A "megáll" hogy néz ki? Nem tudod valahogy úgy indítani, hogy felvedd az
ablakot "screencast"-nak? (VirtualBox tud ilyet pl.)
El se kezd visszaszámolni az óra timeout-ról, vagy az áll meg valahol,
mintha gombot nyomnál?
Üdv,
Gyu
_
linux lista - linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: DNS beálljtás
Hi, "Gábor Kovács" írta 2015-01-10 15:57-kor: > >> Ha a két dns közül az elsö leáll, onnan kezdve nincs a kliensen > >> névfeloldás, olyan, mintha csak az elsö dns-t látná a kliens. Azt > >> szeretném, hogy ha az elö dns nem válaszol, akkor kérjen névfeloldást > >> a másodikról. > >> A második dns korrektül müködik, ha kiveszem az elö cimét a > >> resolv.conf-ból, akkor van névfeloldás. > > Ebben biztos vagy? Hogyan ellenőrizted? Nem csak türelmetlen voltál a > > timeoutot kivárni? > Ha az első helyen a kikapcsolt dns ip címe van, akkor: > # ping gepnev > ping: unknown host gepnev > > ha a bekapcsolté, akkor: > # ping gepnev > PING gepnev (192.168.220.26) 56(84) bytes of data. strace és tcpdump mit mond, mi történik? Nem lehet, hogy a másik explicit mond rá valami elutasítót? Vagy ha mindkét gép be van kapcsolva, akkor mindkettő jó? Ez elég furán hangzik. host és dig paranccsal amúgy tudod explicit is kérdezgetni őket Azokat a köröket is érdemes lefutni, akár még azelőtt, hogy tcpdump és strace-el elkezdenéd a libc resolválási rutinjaiban a hibát keresni. Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: DNS beálljtás
Hi, "Gábor Kovács" írta 2015-01-09 13:18-kor: > > Ok, de mi a kerdes, nem mukodik, gond van vele ahogy probaltad, stb? :) > Ha a két dns közül az elsö leáll, onnan kezdve nincs a kliensen > névfeloldás, olyan, mintha csak az elsö dns-t látná a kliens. Azt > szeretném, hogy ha az elö dns nem válaszol, akkor kérjen névfeloldást > a másodikról. > A második dns korrektül müködik, ha kiveszem az elö cimét a > resolv.conf-ból, akkor van névfeloldás. Ebben biztos vagy? Hogyan ellenőrizted? Nem csak türelmetlen voltál a timeoutot kivárni? Üdv, Gyu _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Socket probléma
Hi, "Kiss Gábor" írta 2014-11-23 15:40-kor: > Annak részeként character device-okon át elérhető kernel driverek > működését szeretném utánozni user space-ben. (Vagy a /proc alatti > egysoros file-okét.) Két külön dolog. char/block deviceok reagálnak mindenféle ioctl-ekre, socketek legjobb emlékeim szerint nem. > Egy démon létrehoz egy unix domain socketet, és várja a klienseket. > Ha valaki ír bele, azt megjegyzi. Ha valaki olvas belőle, kiadja > amit megjegyzett. Mármint, ez az összes működése? Mi van, ha többen nyitják meg? Picit tudnád ezt a működési algoritmust pontosítani? > A f?? gond, hogy nem lehet a socket listener oldalán megállapítani, > hogy a kliens olvasásra vagy írásra nyitotta-e meg. Socket. Kétirányú, nem pipe! Lehet bele írni is, meg olvasni is belőle, egyszerre. Like, when http-re kapcsolódsz. Az is socket, csak tcp-n: Beleírod, hogy get http-ül szépen paraméterezve, cserébe kapsz egy http-ül formázott fejlécet, majd (jó esetben) az annak megfelelő content-type-ú választ. Esetleg innen újra játszhat az elejétől, vagy lezárod a socket. > Így aztán bizonytalan, hogy accept után a démon indítsa-e a > küldést, vagy várjon a bejövő adatra. Mi a pontos "működési algoritmus"? Esetleg próbáltál már valami állapotdiagramot rajzolni az egyes socketekhez? Abból amit írtál bármi lehet. select(), meg más poll-félék a te barátaid. Ha ezerszám kell párhuzamosan ilyet kezelj, akkor epoll() meg ilyen újmódi dolgoknak célszerű utánanézni, ha csak PoC kód, akkor select() bőven jó. > Most mindkettőt csinálja, és a flush meg a shutdown környékén > van a probléma. Az output irány lezárása azt eredményezi, > hogy az olvasás is megszakad azzal, hogy 0 byte jött, a kliens > megszakította a kapcsolatot. És ez nincs így jól? Mi a probléma evvel? Mit szeretnél, hogy történjen? BTW.: Ha pl. select szerint nem blokkol a read az fd-ből, és mégis 0-t olvasol belőle, az azt jelenti, hogy a kliens már lezárta a csatornát. Gondolom socketeknél is van olyan féloldalas lezárás, mint tcp-nél, hogy ő jelzi, hogy többet már nem akar írni bele, de olvasni azért még olvashat belőle. Ezt most nem csekkoltam. Ill, még egy tipp: Én, ha ilyesmit akarnék írni, és bizonytalan vagyok, akkor megnézném a socat forrását is! ;-) (Talán tanulságosabb a kész kód, mint 0-ról olvasgatni a manokat a manpages-dev -ből.) Üdv, Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ext3 helyfoglalas furcsasag
Hi, "Kosa Attila" írta 2014-11-04 15:20-kor: > Van egy gep, lvm-es ext3 particiokkal, vserverrel. A vserverben > ufs-kent latszik az egyebkent ext3-as particio, es ilyet > produkal: Az "normális". Nem lát ki, az kerül mtab-ba. Keep calm. > Nem birok rajonni, hogy hogyan csinalja... Lehetseges lenne, hogy > valami fajlrendszer-serules okoz ilyet? > > Valami jo otlet? sparse fájljaid nincsenek véletlenül ott? Habár, azt a tar-nak jobban kellene tömörítenie. Biztos nincs hardlinked? Hogyan ellenőrizted? Üdv, Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: php állományok jogosultsága
Hi, "Kiss Gabor" írta 2013-04-11 13:18-kor: > On 04/11/2013 12:35 PM, PÁSZTOR György wrote: > > > > "Hofferek Attila" írta 2013-04-11 12:16-kor: > >> Sztem egyebkent cgi modban futtatjak, hogy a tulaj neveben futhasson, ne > >> wwwdata legyen mindenki scriptje hogy osszevissza irogathassak egymas > >> cuccait. Ezert kell futtathatonak lennie. > > > > Arra jó suphp is, ahhoz meg nem kell 755. > > Ha meg cgi-ként futtatják, akkor kellene hozzá shabang is, nemde? > > "shebang" a #! neve. > http://en.wikipedia.org/wiki/Shebang_(Unix) > (Bocs, hogy közbeszóltam!) Innen már necces, hogy flame-re át kellene vezetni a topicot, de az általad mutatott wikipédia szócikk első fél mondata: "In computing, a shebang (also called a sha-bang,[1][2][3] hashbang,[4][5] pound-bang,[2][6] hash-exclam,[2] or hash-pling[2][7]), ..." Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Re: php állományok jogosultsága
"Hofferek Attila" írta 2013-04-11 12:16-kor: > Sztem egyebkent cgi modban futtatjak, hogy a tulaj neveben futhasson, ne > wwwdata legyen mindenki scriptje hogy osszevissza irogathassak egymas > cuccait. Ezert kell futtathatonak lennie. Arra jó suphp is, ahhoz meg nem kell 755. Ha meg cgi-ként futtatják, akkor kellene hozzá shabang is, nemde? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: php állományok jogosultsága
Hi, "Laborczi Pál" írta 2013-04-11 11:08-kor: > Adott egy szolgáltató, mely a webhosting mellé php szolgáltatást is > nyújt, viszont a biztonságra (!) való hivatkozással megköveteli, hogy az > összes php állomány jogosultsága 644 helyett 755 legyen. Ami számomra > azért furcsa, mert a php scripteket nem a rendszer, pontosabban nem a > bash vagy valamelyik más shell futtatja. > > És ha nem 755 a jogosultság, a rendszer ezt a választ adja: > > 500 Internal Server Error > The server encountered an internal error and was unable to complete your > request. > Error message: Premature end of script headers: index.php > > Normális ez így? És mi lehet a háttérben? Követelhetem, hogy 664 mellett > is működjék a php script? Kérdés: Azt is megköveteli, hogy legyen shabang a fájl elején, vagy csak sima php elég neki, és 755-öt kér? El tudom képzelni, hogy azért kér ilyet, mert nem apahce2+mod_php-t használ, hanem valami fejlettebb megoldást, ahol tényleg ilyet kér a rendszer. Én nagyon nem hisztiznék ezen. Nem tűnik teljesíthetetlen elvárásnak. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
svn pre-commit script
Sziasztok,
Svn-hez írok pre-commit scriptet, és ebben kellene egy kis segítség.
Szeretném az apache konfigfájljait svn alá vonni, és megoldani, hogy
a pre-commit script csak akkor fogadja el a commit, hogyha az a konfigfájl
rendben van.
A terv, ill. előfeltételek ezek:
/var/lib/svn/reponev alatt van a repó.
/var/lib/svn/working_copy alatt van egy munkapéldány, amit a sikeres
commitok végén a post-commit script minden egyes alkalommal update-l.
Szóval, a terv az lenne, hogy /tmp/apacheck könyvtár alá előállítani "FIXME"
módon azt az állapotot, amit a commit csinálna. (Ez most munkaverzió.
Nyilván a véglegesben mindenféle race conditionök, meg ilyen etwasok ki
lészenek védve a /tmp-ben.)
pre-commit script lényegi váza:
rsync --kapcsolok --delete /tmp/apacheck/ /etc/apache2
if apache2ctl configtest ; then
echo Remekez
else
rsync --kapcsolok --delete /var/lib/svn/working_copy/apache /etc/apache2
fi
post-commit script-be meg mehet egy apache2ctl reload (esetleg restart
autodetection, ha nagyon ráérek ;-) )
A kérdés csak az, hogy FIXME-re tegyen nekem vki. javaslatot.
Alapból nem lenne olyan nehéz az svnlook changes -en végigmenni.
Nade, az apache konfigjaiban vannak symlink-ek is:
{sites,mods}-{available,enabled} könyvtárakra gondolok.
És ha már nem elég a changed első betűjét (A, D, U) nézni, akkor elég
böszme nagy magú while ciklus kell, ami elő tudja állítani az új állapotot.
Hacsaaak, nem tud vki. nekem egy jobb trükköt mondani...
Köszi a segítséget!
Üdv:Gyur!
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: nonlocal bind
Hi, "Magosányi Árpád" írta 2012-12-17 20:27-kor: > Nem létező ip címre bindolok. > net.ipv4.ip_nonlocal_bind=1 beállítva (anélkül a bind se menne) > A routing is jónak néz ki, látom a syn csomagot, és a dst ethernet cím a > fogadó interfész ethernet címe, tehát a network stackig eljut a csomag. > De a daemon aki figyel nem kapja meg. > net.ipv4.ip_forward=1 is beállítva kínomban > Még egy redirect-et is nyomtam a dest address-re, pedig emlékeim szerint > az sem kellene. > Mi hiányzik még? > 3.2.0 -ás kernel Én első közelítésben megnézném egy réteggel feljebb is. netfilterbe felvennék egy szabályt, ahol az iptables-nek nem mondok -j -t, csak illeszkedik a várt csomagra, és figyelném a countert, hogy tényleg nő-e. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: honnan íródik vissza?
Hi, "Kosa Attila" írta 2012-10-09 10:22-kor: > On Mon, Oct 08, 2012 at 10:23:46PM +0200, "Magosányi, Árpád" wrote: > > kvm-el szórakozom, és klónozgatnék. Csináltam egy "guest1" nevű lv-t. > > Ezt használva hda-ként, telepítettem egy ubuntu servert. > > A hostname guest1 lett. lvm-et használtam benne, a vg neve guest1 lett. > > Azt nem tudom, hogy miert irodnak vissza a fajlok, de nekem > feleslegesnek tunik a ket lvm. Miert nem jo az, ha csak a hoston > vannak lvm-es particiok, es minden lvm particiot odaadsz a > guest-nek? Egyszerubb az eleted is, ha novelni kell, mert a > hoston megnoveled, a guest-ben mar csak a fajlrendszert kell > megnovelned, es keszen is vagy. Raadasul a kpartx-es dolgot is > kihagyhatnad a dologbol. Annyiból is van értelme ennek a megközelítésnek, hogy ha performanciát is akar, akkor az offsetekre nem kell külön figyelni, pl. xfs-nél, lv az lv-ben, meg a többi galádsággal. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: honnan íródik vissza?
Hi,
""Magosányi, Árpád"" írta 2012-10-08 22:23-kor:
> mount /dev/mapper/guest2-root /mnt/ #bemountolom az egészet a /mnt alá
> mount /dev/mapper/gill-guest2p1 /mnt/boot # -+-
> chroot /mnt # bemegyek
> vi /boot/grub/grub.cfg /etc/fstab /etc/hostname /etc/hosts #
> s/guest1/guest2/
> update-initramfs -u -k all #az initramfs-t is update-olom
>
> Mindezek után
> kvm -vnc 127.0.0.1:2 -hda /dev/gill/guest2 -net
> nic,macaddr=FE:AD:EF:75:AD:BE -net tap
>
> A vm rendesen bebootol, megtalálja a rootot meg a swapet is.
>
> DE:
>
> a /etc/{fstab,hostname,hosts} fájlokban guest1 van guest2 helyett.
> guest1 hostname-el is jön fel.
>
> Mit rontok el, honnan íródnak vissza a fájlok?
Nagyon lámer kérdés, de volt umount + sync mielőtt a guest2 vm-et
bebootoltad? :$
Üdv:Gyur!
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
icinga jogosultsagok
Sziasztok, Konfiguráltam már sok mindent icingával, de most azt se tudom mi az a kulcsszó, amit keressek, vagy hogy jó irányba indulok-e... Mondjuk úgy, hogy lennének "szigetek" a megfigyelt objektumokbann, és csoportok a felhasználók közt. Hogyan tudom megoldani, hogy egy-egy szigetet csak 1-1 csoport lásson? Van egy különleges felhasználó: én. Lényegében a szigetek és csoportok közt lehet 1-1 megfeleltetést csinálni. Az kellene 1-1 csoport, csak a hozzá tartozó hostokat+ service-okat lássa és a többiekét ne. + persze lennék én, akinek mindent látnia kellene, de ez talán az a rész, amit még meg is tudok oldani a cgi configban az authorized_for_all_hosts, authorized_for_all_services és hasonló beállításokkal. Láttam ilyen fogalmat, hogy "instance"-okat lehet csinálni, de ha jól sejtem ez az, hogy egy icingatelepítés + db az url alapján lényegében teljesen diszjunkt legyen, és a http://egyikvhost.hu/icinga/ címen más jöjjön be, mint a http://masikvhost.hu/icinga/ címen, még akkor is, ha ugyanarra a könyvtárra mutatnak az alias-olások + ha jól sejtem, itt nem lehetne olyan felhasználót csinálni, aki az összesítésben egyszerre lát minden service-t és host-ot. Tudja valaki mit keressek és hol? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Postfix recipient_bcc_maps probléma
Hi, "szistvan" írta 2012-07-10 17:36-kor: > Debian, postfix 2.5.5-1.1+lenny1, felhasználók LDAP-ban. > Kérés volt, hogy egyes felhasználók beérkező leveleiről a főnök kapjon > másolatot. Adta magát a recipient_bcc_maps, de nem működik jól, vagy én > értem félre. Ugyanis a külső levelekről valóban dob egy másolatot, viszont > a belső levelezésről "elfelejt". Tehát ha az us...@ceg.hu-ra külső partner > ír, akkor azt a főnök is megkapja, viszont, ha us...@ceg.hu ír user1-nek, > akkor arról már nem megy másolat. > A main.cf-ben: > > always_bcc = ikt...@ceg.hu > recipient_bcc_maps = hash:/etc/postfix/recipient_bcc Nem emlékszem fejből, minden apró részletére a postfix doksinak, de amikor 1-1 felhasználó leveleiről kell másolat egy másik folderbe, akkor miért nem csinálsz olyat az aliases-ba, hogy user1: user1,bccipse ? Vagy, ha félsz, hogy az aliases túl nyilvánvaló helyen van a többi rendszergazda számára, aki olvashatja a fájlt, tedd át egy külön fájlba, és add hozzá azt a fájlt is az aliaseshoz. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: VPN server építése router-be?
Hi, "SOLYMOSSY Zoltán" írta 2012-05-17 14:42-kor: > > routereket. Elég nagy a választék, és ezek (fél?)profi cuccok, készen. > > Igaz, az oprendszer zárt, de elég komoly, van benne VPN támogatás is meg > > miegymás. > > > > Némileg persze drágább mint a TP-Link. > > Köszönöm, a Mikrotik routereket többen is ajánlottátok, renedeltem > egyet, meglátjuk. Ha már szóba kerültek a mikrotik-ek, és még csak felfedező / kipróbálós fázisban vagy, akkor javasolnám a témára az ubiquity termékeit is. A routereket openWRT-vel előtelepítve szállítják. A nanostation-ök, meg hasonlók pedig vmi. saját pici rendszerrel, ami ha nem tetszik, cserélhető openWRT-re. A 10.03.1-es wrt meg elég jól szabható jószág! ;-) Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Folyamattámogatás polgármesteri hivatalnak?
Hi, "Magosányi Árpád" írta 2011-12-16 09:32-kor: > Egy polgármesteri hivatal számára melyik open source folyamattámogató > szoftvert használnátok? > Esetleg valakinek van ilyen tapasztalata? > Nincs semmijük, még egy bugzillával is sokkal beljebb lennének... Ha ilyesmi kaliberre kell gondolni, akkor én redmine-ra szavaznék. Nekem kifejezetten tetszik, csak jól ki kell gondolni a kategóriákat, csoportokat, stb. Én két oldalról ismerem csak: "alulról", aki a szerveren tocogtatja, ha kell, de leginkább nem kell etetni itatni, büfiztetni, meg "userként", akinek redmine-ban izengetnek, hogy ez kéne' az kéne'. Aki "adminolja", hogy kik, kinek, mit, mi merre látszódjon, azon a részen, annyira mélyen nem, de amennyi rálátásom van, az alapján azt mondanám, _lehet_ benne okosan csinálni! Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Hylafax, 7 analóg vonal
Hi, "Hofferek Attila" írta 2011-12-10 20:50-kor: > létezik olyan hardver, ami pc -re kötve vagy -be dugva, linux alatt, > hylafax-szal működik, 7 analóg érpár dugható bele, 7 faxvonalon > fogad és küld faxokat hylafax segítségével? Igen. Pl.: Soroskártya + 7 faxmodem. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: 3c905B dili
Hi, "Gádori Zsolt" írta 2011-12-02 21:52-kor: > Látszólag csak az interrupt száma változott. Mit történt valójában? A mi történt egy részére a tippem: udev-ben lekövetted a változást? A /etc/udev/rules.d-be, talán 75-össel be szok jegyezni a debian, hogy melyik mac-ű kártya, milyen eth nevet visel, hogy ha átteszed másik PCI slotba, a neve akkor is maradjon. Szerintem ezért maradt fenntartva az eth1 név, miután a kártyát kivetted, és az újat eth2-ként kellett volna keresd. Javadra válik még a /proc/net/dev megvizsgálása, hasonló esetben! Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Használt memória nem stimmel
Hi, "Attila Rajmund Nohl" írta 2011-11-03 18:26-kor: > Azaz swap nincs használatban. Akkor hol van a maradék ~180 MB memória? Shared memória (pl. shared lib)? PCI, vagy más i/o terület bemappelése? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
samba pdc upgrade lenny vs. squeeze
Sziasztok, Kezdem a falat kaparni az idegtől, és már valószínűleg a fától nem látom az eredőt sem, stb. Volt egy régi kisebb nyűgökkel küszködő samba pdc-m. Debian Lenny hoston egy Debian Lenny vserverben ment a dolog. Userek psql-ben, kis script időnként lefutott és szinkronba hozta a pdbedit és smbpasswd használatával a helyi állapotot a psql szerintivel. Ez mondhatni, kisebb zökkenőkkel de ment. Ezt most szerettem volna továbbvinni, és egy Squeeze-s domU-ba tenni az egészet. A konfigok, nfs-mapek, minden szépen át lett költöztetve az új helyére, és eljött a pillanat, amikor a szolgáltatást is át kellett volna vegye az új pdc. vserver dc stop ; majd a squeeze -s domU-ban ifdown eth0 ; ip átír a pdc-ére; ifup eth0 És... ekkor jött a pofáraesés! Azok a munkaállomások, amelyeknek a gazdája még itt túlórázott, az új pdc-re vissza tudott lépni, lefutottak a logonscriptek a userekhez. (Na jó, nem elsőre, de ott én bénáztam a konfiggal) De ha egy olyan gépet bekapcsoltam, ami az eset közben ki volt kapcsolva, arra azt mondta, nem tud a tartományba belépni/ csatlakozni. Próbáltam lokál rendszergazdaként újramegismertetni a tartománnyal. Nem ment. (Bár azt nem próbáltam meg, hogy kiléptet && reboot && újrabeléptet && reboot, nézdmilett, de ezt elkerülném a másik 130 gépen...) Csodák csodája, amelyik gépek viszont átvészelték bekapcsolva a tartományvezérlő váltást, azok múkodtak reboot után is! Találtam a témában ilyet: http://samba.2283325.n4.nabble.com/PDC-broke-after-upgrade-td3220595.html Pont hasonló eset: Lenny-ről upgradelt Squeeze-re a muksó. De nálam nem hinném, hogy ez az ábra, mert: * már eleve tdbsam passdb-t használtam * néhány gép valami csodával határos módon túlélte * a /var/lib/samba alkönyvtár tartalmát a régin stop ; újon ifdown eth0 utáni ponton rsync-eltem. (eth1-en rálát egy privát hálóra, ahonnan nfs share-ket felcsatol, és ezeket is megosztja sambán) Ha azt mondtam log level = 99, akkor még a régi jó scriptjeim sem futottak jól le, mert a tdbedit -et aki írta, azt egy kicsorbult szívlapáttal agyon kéne verni, hogy a stdout tartalma a konfigbeli loglevel állítástól megváltozik. És ettől még továbbra sem láttam, hogy mi a probléma a tartományhoz csatlakozáskor. Egyelőre most újra lelőttem a squeeze-s gépet, és vserver dc start a lenny-n, de valamikor megejteném ezt a szeánszot, ha valaki meg tudja mondani, hogy tudom nyakoncsípni ezt a fura esetet. Minden segítséget nagyon köszönök! Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: 2 wan
Hi, "Lajber Zoltan" írta 2011-10-03 14:12-kor: > On Mon, 3 Oct 2011, Kiss Gabor wrote: > > > Minden tisztelem Lajbié, de sajnos tényleg mellélőtt. > > Tenyleg bal labbal keltem fel. Es azota meg inkabb, ezert nem is > szoltam... Ettől függetlenül, szerintem jogos volt, az alábbiak miatt: * ezen a listán legyen már alap, hogy érdekli, és utána is olvas. Úgy emlékszem illemtan.html ír vmi. ilyenről, hogy megfelelő pointerekkel ellátott rtfm válasz is elfogadott * és a smart questions howto is szerintem itt alapnak számíthat, és aszerint sem sok tanulságát tette a kérdező, hogy mikkel foglalkozott eddig, nagyjából olyasmi stílusnak tűnt, mint amikor vki. a házifeladatát bedobja a közösbe, hátha megoldják helyette. Legalábbis nekem így tűnt, én így láttam. Ellenérveket persze elfogadok, nyitott vagyok. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: 2 wan
"Norbert Vastagh" írta 2011-10-03 08:59-kor: > 2011/10/2 Lajber Zoltan : > > akkor vegyel valamit a tplink-cisco vonalon, es ne kerdezgessel itt. > > Én nem kérdezgettem, hanem válaszolgattam! Bár nem én vagyok az admin, de a "válaszolgatás" stílusa nem volt a listához méltó. Erre van a ~flame. Ott elmegy ez a stílus. De ameddig Lajbi építően szólt hozzá, a tiéd inkább nem minősíteném. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: IBM System x3620 M3/debian
Hi, "Kónya Zoltán" írta 2011-06-08 09:58-kor: > A következő szervert tervezzük vásárolni: IBM System x3620 M3 > Van valakinek tapasztalata - Debian5/6 alatt - ezzel a konfiggal? > Leginkább a RAID kártyával kapcsolatos élmények érdekelnének. > /a rajta lévő vezérlő egy Serveraid M1015 SAS/SATA Controller, ami egy > LSI MegaRAID SAS 9240-8i kártya/ hw-ileg jó az IBM, bár nekünk HS22 pengénk van tőlük, abban meg LSI-SAS1064E. Működik, korrekt, mpt driver. smartmontools-al diszkenként külön le lehet a smart értékeket is kérdezni. 6-os debiannal sokat javult a támogatottság, legalábbis ami a HS22-ben lévő alkatrészeinket illeti, másik helyre szintén tervben van x3620, de nem félek, hogy debian ne tudná kezelni, ha RHEL5-höz, meg SLES ???-hez is nyomnak ők maguk hivatalos supportot. Mindamellett, előfordult, hogy 5-ös debianon nálunk pont a NIC elég instabil volt. Jó, ha felkészülsz rá, hogy a hibákat tudd reprodukálni a supported OS-eken is! (5-6-8 pengénél könnyebben képzel tartalékot ilyesmire, mint 1-2-3 x3620-nál) Amúgy persze idővel a problémák is oldódnak, ha nagyon új dolgot veszel, mert eleinte még szinte 2-3 hetente tolják a firmware upgradeket... Arra figyelj IBM-el, hogy ameddig meg nem veszed, addig készségesek, segítenek, minden van, mindent igérnek, és az átadásig tényleg mindent teljesítenek. Szerintem technológiailag nagyon jók (Dell sztem hozzájuk képest 1-2 évvel le van maradva, HP meg labdába sem rúg) De ha valami kérdésre nem adtak időben választ, és "úgy maradt" valami a rendelt konfigban, és a szállításkor jösz rá, hogy helyette inkább azt a 100$-al olcsóbb, de tudásban sokkal jobb másik eszközt szeretnéd... Na azt felejtsd el! Bár, ha van sok pénz, supportszerződést kötni velük, meg még vmi. éves v. akármilyen support/ rendelkezésreállást is fizetsz nekik, akkor talán készségesebbek, azt nem tudom, mi közintézmény vagyunk, jobbára pályázati pénzekből burst-ökben tudunk fejleszteni, és arra még a magyarországi markecosaik nem jöttek rá, hogy talán jó lenne, ha az ügyfélnek nem maradna kesernyés szájíze, nehogy a legközelebbi fejlesztéskor, inkább Cisco UCS felé kacsingasson, még ha az drágább is. (Bár, ez utóbbiban sem vagyok biztos, TCO-t tekintve) Összegezve: Még rendelés _előtt_ nézd át alaposan mit akarsz, biztos azt akarod-e! Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: xen hiba (?)
Hi, "Erdelyi Gabor" írta 2011-05-09 10:36-kor: > Volt egy virtualszerver, amin etch futott, xen-nel, rajta par domU. i386. > Ment is, de lett uj vas, lenny-s. Tegnap attettem az etch-es domU-kat ra. ... > kernel = '/boot/vmlinuz-2.6.26-2-xen-amd64' > ramdisk = '/boot/initrd.img-2.6.26-2-xen-amd64' ^ Az i386 vs. amd64 átállás körül nem lehet galiba? Nem őrizted meg véletlenül a domU eredeti initrd+kerneljét? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: openvpn + bridge
Hi, "SZABO Zsolt" írta 2011-04-19 18:40-kor: > Eddig route-olva hasznaltam az oepnvpn-t, de gondoltam kiprobalom, hogy a > bridge-el hogyan mukodne... a howtokat igyekeztem figyelmesen elolvasni, > es el is jutottam odaig, hogy a kliens felhuzza a tap device-ot a > bridge-elt cimmel, de aztan semmi... mintha valami ip_forward szeru dolog Mert rosszul csinálod: Döntsd el: tap-ot akarsz, vagy IPcímet. Ha tapot akarsz, akkor tedd a bridge group-ba a tap interfészed, meg ne küldözgess neki IPcímet. Ha meg IPcímet akarsz az interfészre, akkor tun kell neked. De halkan megkérdem: minek akarsz te tap-ot? Ha nem tudod mire való, akkor nem az kell neked, hanem tun. Ennyi ;-) Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Postfix postconf - debian squeeze
Hi, "Szládovics Péter" írta 2011-04-11 13:30-kor: > 2011-04-11 13:25 keltezéssel, PÁSZTOR György írta: > > "Szládovics Péter" írta 2011-04-11 12:38-kor: > >> 2011-04-11 11:15 keltezéssel, Gabor HALASZ írta: > >>> On 2011.04.11. 9:46, Szládovics Péter wrote: > >> Tehát hozzáírja, nem pedig átírja. > >> GyK: nem bírál fölül semmit, ami előzőleg a $destinations-ben szerepelt. > > > > Olvasd el please, miről beszélünk: > > 1. írtam, hogy ez vsz. nem az a rész, de itt is csinál csúnya szövevényes > > dolgokat > > 2. igen, hozzáírja: pont ez a bajom. az NE legyen ott, ami a "mailname" a > > destinations-ban. én ÍGY akarom! > > Próbáltad a scriptben átírni? > Lehet, hogy a Satellite beállítás és az Internet Site ezen a ponton ugyanaz. Te tényleg ennyire write-only vagy? 1. Ha megnézed a scriptet, nem "hozzáír", átír! Tökmindegy mi volt előtte a destination-ben, helyette beteszi ezt a fix 3 elemű listát. Ráadásul a legnagyobb bajom, hogy bárhogy is manipulálom, akkor is hozzáírja a mailname-t. Mert abba még belenyugodnék, ha scriptelhető lenne úgy, hogy debconf-set-selections <http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Postfix postconf - debian squeeze
Hi, "Szládovics Péter" írta 2011-04-11 12:38-kor: > 2011-04-11 11:15 keltezéssel, Gabor HALASZ írta: > > On 2011.04.11. 9:46, Szládovics Péter wrote: > Tehát hozzáírja, nem pedig átírja. > GyK: nem bírál fölül semmit, ami előzőleg a $destinations-ben szerepelt. Olvasd el please, miről beszélünk: 1. írtam, hogy ez vsz. nem az a rész, de itt is csinál csúnya szövevényes dolgokat 2. igen, hozzáírja: pont ez a bajom. az NE legyen ott, ami a "mailname" a destinations-ban. én ÍGY akarom! Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Postfix postconf - debian squeeze
Hi,
"Kovács Attila" írta 2011-04-10 18:16-kor:
> 2011.04.09. 17:29 keltezéssel, PÁSZTOR György írta:
> > Utálom, ha valaki evvel a sztereotípiával jön, de most kénytelen vagyok én
> > is feltenni a kérdést: Miért gondolja az okos maintainer úgy, hogy ő jobban
> > tudja mit akarok, mint én magam?
> Ha ez segít
> http://serverfault.com/questions/243638/automate-postfix-instalaltion-with-debconf-set-selections
> DEBIAN_FRONTEND=noninteractive apt-get install
Neminteraktív módban is "felülbírál". Pont ez a bajom. Egyszerűen bármit
preseedelek, átugorja, és felülírja, ha úgy gondolja. Próbáltam elemezni a
/var/lib/dpkg/info/postfix.config scriptet, ami ezt csinálja, de elég
"szövevényes"...
Ellenben van benne pl. ilyen részlet:
if ($mailertype eq "Internet Site") {
if ($mailname eq $hostname) {
$destinations = join ", ",($mailname, "localhost." . $domain, ",
localhost");
} else {
$destinations = join ", ",($mailname, $hostname, "localhost." . $domain .
", localhost");
}
Azt nem értem, mikor, vagy miért, és hogyan kerül erre a vezérlés, de nekem
gyanús. Pedig a mailer type-nak nem is internet site, hanem satelit van
beállítva. Persze, lehet, hogy másutt a scriptben szintén vannak ehhez
hasonló felülbírálások, hogy tökmindegy mit mond a felhasználó, ő majd
okosb lesz...
Üdv:Gyur!
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Postfix postconf - debian squeeze
Hi, Próbálnám automatizálni a (nem-levelező) szervereim telepítését. Korábban ilyesmivel nem volt gondom, bár korábban a célra nullmailer-t használtam. (Most is csak a kisérletezésre való hajlam miatt próbálkozom postfix-el) Az alábbit futtatnám le, az "alaptelepített" debianon: rm /etc/aliases debconf-set-selections
Re: xen lassulás
Hi, "BORBELY Zoltan" írta 2011-04-05 23:55-kor: > A TCP window méret elsőre egy kicsit karcsúnak tűnik. Próbáltad már > nagyobbal? Kipróbáltam manuálisan megadni: * Warningol hogy 2x akkora lesz, mint kértem * Még rosszabb jön ki, mint default értékekkel * Amikor nincs xen hypervisor, akkor is ue. defaulttal meg tudja hajtani 9.9Gbps-re. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: xen lassulás
Hi, "Simon Imre" írta 2011-04-01 03:24-kor: > > > /etc/xen/xend-config.sxp: (network-script network-dummy) > > Ezt csak azert, mert szeretem kiirtani a xen scriptjeit es sajat magam > letrehozni. > (Ne csinaljon nekem mindefele bridge-t hulye nevekkel.) És ez a network-dummy honnan van? Ilyen scriptet nem látok. De valóban, szeretem én is magam megkreállni a bridgeim. > > > ha ez nem megy, akkor: > > >http://wiki.xensource.com/xenwiki/Xen4.1 > > > (egyebkent ha igazan akarod hasznalni, akkor ez ugyis jobb lesz mint a > > > debianos) > > > > Pont ez jutott eszembe, hogy megpróbálom forrásból feltenni a 4.1-es > > hypervisor-t. > > http://wiki.xensource.com/xenwiki/Xen4.0 > > Itt le van irva, hogy mit kell tenni. Majdnem csak copy-paste az > egesz. Hát... Nem teljesen. Legalábbis a korábban megkreált vm-ek nem indultak. Azt mondta "linux" nevű loader nincs. meg "pygrub"-ot sem találok a feltelepített cuccok közt... > (cserebe lesz pl. tapdev2, meg olyan dom0 kernelt csinalhatsz > magadnak, > amilyet szeretnel:) Leginkább gyári deianos dom0-t szeretek, ami frissül nekem apt-get update-el, ha olyan kell :D Viszont egy érdekes mérés: node02:~# iperf -c 10.10.3.5 -P 2 -t 30 Client connecting to 10.10.3.5, TCP port 5001 TCP window size: 27.9 KByte (default) [ 3] local 10.10.3.4 port 47647 connected with 10.10.3.5 port 5001 [ 4] local 10.10.3.4 port 47646 connected with 10.10.3.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-30.0 sec 10.3 GBytes 2.95 Gbits/sec [ 4] 0.0-30.0 sec 24.3 GBytes 6.95 Gbits/sec [SUM] 0.0-30.0 sec 34.6 GBytes 9.90 Gbits/sec Vagyis, ha legalább 2 paralell tcp megy, akkor már kihajtja a 9.9gbit/sec-et. Olvastam olyat, hogy ezeknél az új kártyáknál már több puffer van rajtuk, és pufferenként 1 cpu core-t hozzárendel... Itt elkezdtem gondolkodni, ha meg az egész toe-nek elég egy core, és "normál" körülmények közt 1 core nógatásával kitolható a 10G, még xen-nél meg bizonyos offload engineket a hypervisor nem enged ki a kezéből, h. a vm-ek egymás közt is tudjanak komenikálni, meg ne csináljon olyan csúnyaságokat mint régebben(lenny), h. ha nem kapcsoltad ki a toe-t, akkor mindenféle checksum-erroros csomagokkal lett teli a háló... Ezért valahogy "belenyúl" egy picit mélyebbre a xen... Valaki esetleg ismeri ennyire mélyen a xen-t esetleg network stack-et? Jófelé kapisgálok? Ne akarjak xen fölött 1 tcp-n 10G-t és kész? Csak azért aggaszt, mert akkor ez az iscsi-nek is oda..sz. Vagy merjek nyugodtan multipath-t vmi. elszállt konfiggal, hogy loadbalance-oljon, ne active/backup-oljon? Lehet ilyet? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: xen lassulás
Hi, "Simon Imre" írta 2011-03-31 14:33-kor: > > Please help, aki tud! > > brctl show > ip link show > stb. > /etc/xen/xend-config.sxp: (network-script network-dummy) root@node05:~# brctl show bridge name bridge id STP enabled interfaces br202 8000.0010185ee6b0 no bond0.202 br300 8000.0010185ee6b0 no bond0.300 root@node05:~# ip link show 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 9000 qdisc mq master bond0 state UP qlen 1000 link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 9000 qdisc mq master bond0 state UP qlen 1000 link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 4: usb0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether e6:1f:13:3b:be:2b brd ff:ff:ff:ff:ff:ff 5: bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 6: bond0.11@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 7: bond0.201@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 8: br202: mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 9: bond0.202@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 10: bond0.300@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff 11: br300: mtu 9000 qdisc noqueue state UNKNOWN link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff root@node05:~# grep -vE '^(#|\s*$)' /etc/xen/xend-config.sxp (vif-script vif-bridge) (dom0-min-mem 196) (enable-dom0-ballooning yes) (total_available_memory 0) (dom0-cpus 0) (vncpasswd '') Nem-xen-es gép: node02:~# ip link show 1: lo: mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 9000 qdisc pfifo_fast master bond0 state UP qlen 1000 link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 3: eth1: mtu 9000 qdisc pfifo_fast master bond0 state UP qlen 1000 link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 4: usb0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether e6:1f:13:3b:bc:33 brd ff:ff:ff:ff:ff:ff 5: bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 6: bond0.10@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 7: br202: mtu 1500 qdisc noqueue state UNKNOWN link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 8: bond0.202@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 9: br201: mtu 9000 qdisc noqueue state UNKNOWN link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 10: bond0.201@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 11: br300: mtu 9000 qdisc noqueue state UNKNOWN link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 12: bond0.300@bond0: mtu 9000 qdisc noqueue state UP link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff 13: vboxnet0: mtu 1500 qdisc noop state DOWN qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff > ha ez nem megy, akkor: > http://wiki.xensource.com/xenwiki/Xen4.1 > (egyebkent ha igazan akarod hasznalni, akkor ez ugyis jobb lesz mint a > debianos) Pont ez jutott eszembe, hogy megpróbálom forrásból feltenni a 4.1-es hypervisor-t. Ilyet még sose csináltam. Mennyi mindent kell újrafordítani? Ilyenekre gondolok, mint hogy, kell-e újrafordítani a... ... dom0 kernelt? ... a userspace utilokat (pl. xm)? ... mást? Valahol láttam egy leírást, h. forrásból hogy tegyünk debianra naprakész xen-t, de most még a bookmarkajim közt se látom. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: xen lassulás
Hi, "PÁSZTOR György" írta 2011-03-28 19:32-kor: > Ötleteket keresek, hogy mit nézzek még meg, mert már kezdenek a hajszálaim > kihullani ettől a problémától. ... > Amit semmi nem magyaráz: Miért lassul rettenetesen le, amikor a xen-es > kernelt XEN hypervisorral együtt bootolom a node05-re: Közben figyelmes lettem néhány üzenetre a xen dmesgjéből, hátha ez valakinek mond valamit: (XEN) ACPI: RSDP 000FDFD0, 0024 (r2 IBM ) (XEN) ACPI: XSDT 7F7FE120, 0094 (r1 IBMBLADE 0 113) (XEN) ACPI: FACP 7F7FB000, 00F4 (r4 IBMBLADE 0 IBM 113) (XEN) ACPI: DSDT 7F7F8000, 224E (r1 IBMBLADE 3 IBM 113) (XEN) ACPI: FACS 7F72C000, 0040 (XEN) ACPI: TCPA 7F7FD000, 0064 (r00 0) ... (XEN) HVM: Hardware Assisted Paging detected. (XEN) Intel VT-d Snoop Control supported. (XEN) Intel VT-d DMA Passthrough not supported. (XEN) Intel VT-d Queued Invalidation supported. (XEN) Intel VT-d Interrupt Remapping not supported. - Nem gáz az, h. dma passthrough not supported? A többi VT-d -s featúrát nem is értem mi. dom0 dmesg-jében: [0.00] ACPI: RSDP 000fdfd0 00024 (v02 IBM ) [0.00] ACPI: XSDT 7f7fe120 00094 (v01 IBMBLADE 0113) [0.00] ACPI: FACP 7f7fb000 000F4 (v04 IBMBLADE IBM 0113) [0.00] ACPI Warning: Invalid length for Pm1aControlBlock: 32, using default 16 (20090903/tbfadt-607) [0.00] ACPI: DSDT 7f7f8000 0224E (v01 IBMBLADE 0003 IBM 0113) [0.00] ACPI: FACS 7f72c000 00040 [0.00] ACPI: TCPA 7f7fd000 00064 (v00 ) ... - Mi az, hogy a FACP meg a DSDT közt vmi. "invalid length" lesz? A xen érti, ha nincs hypervisor, akkor a "normál körülmények" közt futó kernel érti. Ez a retek mit, és miért nem ért? ... [0.00] ACPI: Local APIC address 0xfee0 [0.00] No NUMA configuration found [0.00] Faking a node at -0003e9c46000 ... - Miért nem talált numa konfigot? Nem kellett volna neki? normál kernelnél így néz ki:[0.00] NUMA: Using 31 for the hash shift. (Meg ott lát is egy 0-s és egy 1-es node-t, és nem "faking"-el) Ez a numa fel nem ismerés milyen következményekkel járhat? Folytatva a hypervisoros környezet dom0-jának dmesgjét: [0.00] IOAPIC[0]: apic_id 8, version 0, address 0xfec0, GSI 0-0 [0.00] ACPI: IOAPIC (id[0x09] address[0xfec8] gsi_base[24]) [0.00] IOAPIC[1]: apic_id 9, version 0, address 0xfec8, GSI 24-24 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) [0.00] ERROR: Unable to locate IOAPIC for GSI 2 [0.00] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) [0.00] ERROR: Unable to locate IOAPIC for GSI 9 [0.00] Using ACPI (MADT) for SMP configuration information ... [3.839310] bio: create slab at 0 [3.840406] ERROR: Unable to locate IOAPIC for GSI 9 [3.840494] ACPI: EC: Look up EC in DSDT [3.847800] ACPI: Interpreter enabled [3.847804] ACPI: (supports S0 S1 S5) [3.847828] ACPI: Using IOAPIC for interrupt routing ... [4.296983] Broadcom NetXtreme II 5771x 10Gigabit Ethernet Driver bnx2x 1.52.1 (2009/08/12) [4.297114] xen: registering gsi 24 triggering 0 polarity 1 [4.297119] xen_allocate_pirq: returning irq 24 for gsi 24 [4.297121] xen: --> irq=24 [4.297127] Already setup the GSI :24 [4.297131] bnx2x :15:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24 [4.297144] bnx2x :15:00.0: setting latency timer to 64 [4.299312] bnx2x: part number 394D4342-31373735-31314131-473036 [4.299333] bnx2x: Loading bnx2x-e1h-5.0.21.0.fw [4.299338] bnx2x :15:00.0: firmware: requesting bnx2x-e1h-5.0.21.0.fw ... [4.352898] eth0: Broadcom NetXtreme II BCM57711 XGb (A0) PCI-E x8 5GHz (Gen2) found at mem 9600, IRQ 24, node addr 00:10:18:5e:e6:b0 [4.352935] xen: registering gsi 34 triggering 0 polarity 1 [4.352945] alloc irq_desc for 34 on node -1 [4.352947] alloc kstat_irqs on node -1 [4.352952] xen: --> irq=34 [4.352960] bnx2x :15:00.1: PCI INT B -> GSI 34 (level, low) -> IRQ 34 [4.352970] bnx2x :15:00.1: setting latency timer to 64 [4.354851] bnx2x: part number 394D4342-31373735-31314131-473036 [4.354866] bnx2x: Loading bnx2x-e1h-5.0.21.0.fw [4.354869] bnx2x :15:00.1: firmware: requesting bnx2x-e1h-5.0.21.0.fw ... [4.361848] eth1: Broadcom NetXtreme II BCM57711 XGb (A0) PCI-E x8 5GHz (Gen2) found at mem 9680, IRQ 34, node addr 00:10:18:5e:e6:b2 ... [ 23.314723] bnx2x: eth0: using MSI-X IRQs: sp 2243 fp[0] 2242 ... fp[15] 2227 ... [ 23.756889] bnx2x: eth1: using MSI-X IRQs: sp 2226 fp[0] 2225 ... fp[15] 2210 ... [ 24.321285] bnx2x: eth0: using MSI-X IRQs: sp 2243 fp[0] 2242 ... f
xen lassulás
Hi, Ötleteket keresek, hogy mit nézzek még meg, mert már kezdenek a hajszálaim kihullani ettől a problémától. Alapszitu: Debian Squeeze (6.0) Dom0, IBM HS22-es pengék, 57711-es broadcom nic-ekkel, bnx2x driver. Ha simán két debian közt mérek egyet iperf-el, akkor ilyeneket mérek: node02:~# iperf -c 10.10.3.7 TCP window size: 27.9 KByte (default) [ 3] local 10.10.3.4 port 38408 connected with 10.10.3.7 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 11.5 GBytes 9.90 Gbits/sec node02:~# iperf -c 10.11.3.7 TCP window size: 27.9 KByte (default) [ 3] local 10.11.3.4 port 33478 connected with 10.11.3.7 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 11.5 GBytes 9.89 Gbits/sec node02: 10.x.3.4, node05: 10.x.3.7 A 10-es 2. byte-u a node05-es natív vlanjában van, a többi taggelve, a 11-es 2. byte-u alhálót a node02-es kapja az interfészen natívan, és a többit tagelve. (A 10-es és 11-es alháló azért van, mert az iSCSI storage-t multipath-al tervezem elérni, és így a szerverek egyik fele az egyik interface-n látja tageletlenül, a szerverek másik fele a másik interface-n látja tageletlenül.) Ugyanezek az eredmények, ha a default kernel helyett a 2.6.32-5-xen-amd64 kernelt bootolom a node05-ön. node02-n lenny van + virtualbox + hw offload kikapcsolva a vbox miatt. Szerintem ezek magyarázzák, miért rosszabbak kicsit az eredmények, amikor node05-ről mérem node02-t: root@node05:~# iperf -c 10.10.3.4 TCP window size: 27.9 KByte (default) [ 3] local 10.10.3.7 port 37561 connected with 10.10.3.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 10.4 GBytes 8.92 Gbits/sec root@node05:~# iperf -c 10.11.3.4 TCP window size: 27.9 KByte (default) [ 3] local 10.11.3.7 port 58597 connected with 10.11.3.4 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 9.78 GBytes 8.40 Gbits/sec Amit semmi nem magyaráz: Miért lassul rettenetesen le, amikor a xen-es kernelt XEN hypervisorral együtt bootolom a node05-re: node02:~# iperf -c 10.10.3.5 TCP window size: 27.9 KByte (default) [ 3] local 10.10.3.4 port 51229 connected with 10.10.3.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 6.34 GBytes 5.45 Gbits/sec node02:~# iperf -c 10.11.3.5 TCP window size: 27.9 KByte (default) [ 3] local 10.11.3.4 port 58196 connected with 10.11.3.5 port 5001 [ ID] Interval Transfer Bandwidth [ 3] 0.0-10.0 sec 6.32 GBytes 5.42 Gbits/sec root@node05:~# xm info host : node05 release: 2.6.32-5-xen-amd64 version: #1 SMP Wed Jan 12 05:46:49 UTC 2011 machine: x86_64 nr_cpus: 8 nr_nodes : 2 cores_per_socket : 4 threads_per_core : 1 cpu_mhz: 2000 hw_caps: bfebfbff:28100800::1b40:009ce3bd::0001: virt_caps : hvm hvm_directio total_memory : 16372 free_memory: 3674 node_to_cpu: node0:0-3 node1:4-7 node_to_memory : node0:2802 node1:871 node_to_dma32_mem : node0:478 node1:0 max_node_id: 1 xen_major : 4 xen_minor : 0 xen_extra : .1 xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p hvm-3.0-x86_64 xen_scheduler : credit xen_pagesize : 4096 platform_params: virt_start=0x8000 xen_changeset : unavailable xen_commandline: placeholder cc_compiler: gcc version 4.4.5 (Debian 4.4.5-10) cc_compile_by : waldi cc_compile_domain : debian.org cc_compile_date: Wed Jan 12 14:04:06 UTC 2011 xend_config_format : 4 t@node05:~# tail -20 /proc/cpuinfo processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 26 model name : Intel(R) Xeon(R) CPU E5504 @ 2.00GHz stepping: 5 cpu MHz : 2000.112 cache size : 4096 KB fpu : yes fpu_exception : yes cpuid level : 11 wp : yes flags : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm bogomips: 4000.22 clflush size: 64 cache_alignment : 64 address sizes : 40 bits physical, 48 bits virtual power management: Bármilyen használható tipp, ötlet, bármi nagyon jól jönne! Köszi! Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: mount: /dev/sdb already mounted or /mnt busy
Hi, "Ferenc Wagner" írta 2011-03-23 12:45-kor: > PÁSZTOR György writes: > > > root@node05:~# mount /dev/sdb /mnt > > mount: /dev/sdb already mounted or /mnt busy > > # dmesg|tail > Esetleg: > # mount /dev/sdb /mnt -onouuid Közben azt hiszem megfejtettem: multipath "fogta" az eszközt. Bár továbbra sem értem, hogy attól még, hogy /dev/mapper/##-ként is el tudtam érni, miért nem engedte csak a "forrás"-node-ot felcsatolni. Amikor nem fut multipathd nem csinál ilyet. Azonban másik "szívás", hogy ha fut a multipath, akkor egy helyi lv létrehozására olyan csúnya üzeneteket ír a kernel, és olyan szinten magábafordul, hogy öröm nézni. Még nem sikerült szűkíteni a körülményeket, amik adottak: Debian Squeeze, helyi SAS raid controllerrel hw raid1 diszken az OS, Xen (csomagból), xen-es kernel (csomagból), multipathd fut, iSCSI-ről lemez felszedve, amit két path-on is elérek. Ha ilyenkor multipath -F -el kiszedek mindent, iscsi le, iscsi vissza, akkor működ minden, ha közben kerültek új lun-ok is a targetre, akkor azokat is felismeri. Ha lvcreate-el csinálok egy új vol-t, akkor csúnyán magába fordul. multipath-on nem konfiguráltam semmit. Feltettem a csomagot, és fut magától. Okozhat az gondot, hogy nincs konfigfájlja, így blacklistje sem? Hogy érdemes az ilyet megközelíteni, és bugreportolni? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
mount: /dev/sdb already mounted or /mnt busy
Hi, Az alábbi a helyzet: root@node05:~# head -c 128 /dev/sdb | hd 58 46 53 42 00 00 10 00 00 00 00 00 00 c8 00 00 |XFSB| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 0020 b8 90 f0 6a 3f 9b 46 76 a0 bd ab d8 de e5 3c 4c |...j?.Fv..http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: KVM/Qemu networking
Hali, "Szládovics Péter" írta 2011-01-31 09:12-kor: > Hol keressem a hibát, ill. hol kereshettem volna? Jelenleg a kvm-et > leszedtem, mert mennie kell a cuccnak, ami tűzfalfunkciót lát el, így > kísérletezésre most nincs alkalmam. > > Thx előre is a tippeket. Próbáltad már a kártya mindenféle checksum meg egyéb offload funckióit letiltani, pl. ethtool-al? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Virtualizáció
Hi, "Makó Gábor" írta 2010-07-30 07:52-kor: > Mikor érdemes virtualizációt használni (OpenVZ)? > Pl. FTP, Samba, VPN funkciókra érdemes 3 virtuális gépet tenni? Bár személy szerint a vservert jobban szeretem, de nagyjából jól látod. Ezeket én pl. külön VE-kbe tenném. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Novell Suse 10.0 vált ás bacup internetre
Hi, "Kiss Gabor" írta 2010-06-09 09:47-kor: > Természetesen a használati utasításban leírtak szerint > kell használni mindent. (Vagy arra célzol, volt egy ki nem mondott > követelmény is, miszerint önerőből kell megoldani mindent?) Nem én arra a kimondott alapszituációról beszélek, hogy a szolgáltatóknál szakemberbeli és minőségbeli hiány van. Tény, hogy ebből csak feltételezéssel jön ki az, hogy akkor routing protocollról már ne is álmodjunk, de IMHO a feltételezés maga nem merész, ellenben nagyon is reális. > Pénz és szakértelem kérdése. :-) > (V.ö.: "van annyi pénz, amennyitől Juditnak korpás lesz a haja".) Vsz. van az a pénz, amiért ki tudná képeztetni az adott ISP dolgozóit, permanensen megemeltethetné a fizetésüket, hogy utána maradjanak is ott még egy darabig, stb. De ez megint egy valóságtól elrugaszkodott elméleti eszmefuttatás. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Novell Suse 10.0 vált ás bacup internetre
Hi, "Kiss Gabor" írta 2010-06-02 07:04-kor: > > In article , > =?ISO-8859-2?Q?Czingl=E9r_Csaba?= writes: > > lg=E1ltat=F3t=F3l is net. A probl=E9m=E1m az =E1tv=E1lt=E1ssal van. > > > 1) Nem lehetne-e ezt szebben, mondjuk egy script-el megoldani? > > Erre találták ki a routing protokollokat. Ahhoz a szemközti oldalaknak is kellene valamilyen RP-n defgw-t hirdetni. Amikor vmi. egyszerű dhcp-s betárcsázós (nem a hagyományos értelemben vett) valami, akkor nem hinném, hogy a szolgáltató mondjuk BGP-zni fog felé. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: kvm fizikai particio source-kent
Hi, "Papp Tamás" írta 2010-03-23 09:38-kor: > >> Kikeresed belőle a neked való mezőt (eleje oszlop!), ez legyen x > Nem mukodik egyebkent: > > Device Boot Start End Blocks Id > System > /dev/vg/adfe-lenny_disk1 * 633125102315625480+ 83 Linux > /dev/vg/adfe-lenny_disk23125102441942879 5345928 82 > Linux swap / Solaris > > $ losetup -o $[31251023*512] /dev/vg/adfe-lenny_disk > Egyaltalan miert mutat particiokat a particion az fdisk? Ez olyan szagu, > mint fbsd-n a slice-ok es a particiok. 1. nem partíción mutatja, hanem egy lv-ben 2. mert abban az lv-ben egy egész diszk képe van 3. a xen scriptjei is így csinálják +1: tanulj meg _helyesen_ olvasni! PS.: És ha magadtól nem jöttél volna rá, azért kell a loop device, hogy adott offsettől tedd elérhetővé a device tartalmát, hogy felmountolható legyen. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: kvm fizikai particio source-kent
Hi! "Papp Tamás" írta 2010-03-22 23:29-kor: > Keresem-keresem, de nem talalom. Ebbol arra kovetkeztetek, hogy ilyet > nem is lehet. Rosszul. > Konkretan azt szeretnem, hogy egy particio a VM-ben is particiokent > latszodjon es forditva. > Magyaran a VM particiojat fel tudjam mountolni a VM-en kivul is. Jol > latom, hogy ezt tovabbra Raw diszkformátumnál, röviden: fdisk -lu /dev/vmdiskje Kikeresed belőle a neked való mezőt (eleje oszlop!), ez legyen x losetup -o $[x*512] /dev/vmdiskje mount /dev/loopdev /ahova Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: van-e host a tartomanyban
Hi! "Laszlo Baranyai" írta 2010-03-16 19:09-kor: > Hofferek Attila írta (2010. március 16. 17:16): > > van arra valami gyors mod, hogy kitalaljam scriptbol, hogy egy -mondjuk- > > /24 tartomanyban van-e legalabb egy elo (pingre valaszolo) host? Nagyon > > hosszu vegigpingetni 250 cimet sajnos. > > "arp-scan" esetleg: > > http://linux.die.net/man/1/arp-scan > > default timeout 100ms Az csak szórási tartományon belül működik, még a ping az tetszőleges routeolt gépet tud tesztelni. Bár nem tudom volt-e ilyen igénye a kérdezőnek, vagy van-e ennyi helyzeti előnye. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: van-e host a tartomanyban
Hi! "Hofferek Attila" írta 2010-03-16 17:30-kor: > PÁSZTOR György írta: > > "Hofferek Attila" írta 2010-03-16 17:16-kor: > >> van arra valami gyors mod, hogy kitalaljam scriptbol, hogy egy -mondjuk- > >> /24 tartomanyban van-e legalabb egy elo (pingre valaszolo) host? Nagyon > >> hosszu vegigpingetni 250 cimet sajnos. > > Miért hosszú? > > Mert egy pingelés min. 1 mp, nekem nem érti a -w 0.2 kaccsolót. Igen. És? Kb. Annyiszor egy másodperc, ahány menetre osztod a tartomány pingelését. Mondjuk 4 részletben, kb. 4-5 sec alatt megvan. Most írtam meg shellscriptben, csak a hecc kedvéért: (sshd)pasz...@newbie:~$ time ./pping.sh ... real0m4.700s user0m0.164s sys 0m0.536s Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: van-e host a tartomanyban
Hi, "Hofferek Attila" írta 2010-03-16 17:16-kor: > van arra valami gyors mod, hogy kitalaljam scriptbol, hogy egy -mondjuk- > /24 tartomanyban van-e legalabb egy elo (pingre valaszolo) host? Nagyon > hosszu vegigpingetni 250 cimet sajnos. Miért hosszú? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: KVM hálózat választás
Hi! "szistvan" írta 2010-02-05 12:17-kor: > Na és itt van némi problémám. Ugyanis a nagy keresgélés közben > - ahogy Te is írtad - tap interface-k felé keresgéltem, de > közben más irányból megoldódni látszik, és működik is, > csak épp a fent látható vnet0, vnet1 interfacekat nem tudom > hova tenni. :-( > Szóval valami összejött, már csak meg szeretném tudni, hogy > mi is ez a vnet... ha esetleg ebben tudna még valaki segíteni. Nézd meg a virt-install forrását. Én nem ismerem azt. Gyanítom egy tap interfész lesz, átnevezve! ;-) Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: KVM hálózat választás
Hi!
"szistvan" írta 2010-02-02 23:05-kor:
> Bővebben:
>
> |- guest1:dns -|
> eth0-- guest2:www ---eth1
> |- guest3:mail-||
> |
> H o s t -
>
[...]
> A kérdésem tehát: a fent vázolt elképzelés megvalósítható KVM-el?
> Amennyiben igen, mit olvassak, mire keressek rá?
Meg. Nem nagy kaland.
Gondoskodj róla, hogy legyen egy br0 és br1-ed. Boot után éledjenek fel
automatice. Br0-ba bekerül eth0, br1-be eth1.
br1-en IP is legyen.
Debianban nagyjából így nézne ki az interfaces-ed
auto br0
iface br0 inet manual
bridge_ports eth0
auto br1
iface br1 inet static
address x.y.z
...
bridge_ports eth1
kvm -nek pedig paraméterek (ymmv):
-net nic,macaddr=52:54:00:00:00:01,model=e1000,vlan=0 -net
tap,vlan=0,ifname=tap0,script=/etc/kvm/kvm-ifup_eth0
-net nic,macaddr=52:54:00:00:00:02,model=e1000,vlan=1 -net
tap,vlan=1,ifname=tap1,script=/etc/kvm/kvm-ifup_eth1
A script pedig nagyjából vmi. ilyesmi:
iface=${0##*_}
/sbin/ifconfig $1 0.0.0.0 up
/usr/sbin/brctl addif $iface $1
exit 0
Esetleg, hogy shutdownkor se kiabáljon, érdemes lehet a shutdown scripteket
is megírni.
Arra figyelj, hogy minden tap interfésznek adj külön sorszámot, guestenként
is. Magyarán guest1: tap0, tap1; guest2: tap2, tap3, stb.
Üdv:Gyur!
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ipv6-up.d
Hi! "Kiss Gabor" írta 2010-01-11 09:28-kor: > Az csak pár másodperccel később lesz meg. Csak a part széléről kérdem: paraméterben nem jön át? A /etc/ppp/ipv6-up így kezdődik: PPP_IFACE="$1" PPP_TTY="$2" PPP_SPEED="$3" PPP_LOCAL="$4" PPP_REMOTE="$5" PPP_IPPARAM="$6" ... majd később ugyanezekkel hívja meg a run-parts-al a .d-t is. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Offsite backup
Hi! "Moczik Gabor" írta 2009-11-19 19:57-kor: > Ha mar backup, akkor en olyan rendszert keresek, amivel neten keresztul > lehet offsite backupot kesziteni egy masik szerverre. Elkezdtem mar irni > egy rsync-en es SQL szerveres metadata tarolason alapulo script > gyujtemenyt, de ido es kedv hianyaban nem fejeztem be... baculával milyen problémád volt? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: telnet korlatozasok
Hi! "Peter REPAS" írta 2009-09-28 00:21-kor: > Adott egy szerver, amin van 5+ user van es adott 20+ switch, amelyek csak > telnet segitsegevel erhetok el (csak ezzel erheto el mindegyik sajnos) . A > cel, hogy ugy alakitsam ki , hogy az egyes userek csak egyes switch-ekre > tudjanak telnet-elni, a tobbit ne erhessek el. Megoldhato ez valamilyen uton- > modon? (telnet korlatozas, user-re szabott korlatozasok, stb.) Megoldható. Ha pl. radiussal csinálod, akkor a nasipaddress attributum lesz a te barátod. Sőtt, ha Cisco-ról van szó, akkor a shell:priv-lvl VSA-val további finomságokat is lehet hangolni! ;-) Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: loopmount user-kent
Hi! "SZABO Zsolt" írta 2009-09-27 21:01-kor: > Apropo mount: a sudo-n kivul milyen megoldas letezik arra, hogy cd > image-eket adott user is mountolhasson a loop opcioval...? > (vmi pmount -szeru dologra gondolok, de az csak a /dev-ben levo eszkozt > fogad el argumentumkent) mc "belemegy", ha a megfelelő (talán isoinfo?) backend parancsok fel vannak téve. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: OpenVZ - bind VPS-en REFUSED...
Hi! "Makó Gábor" írta 2009-09-13 13:55-kor: > CentOS 5.3 rendszer, a vz102.example-hu.com (192.168.1.102) VPS-en van > bind telepitve. Itt működik is! veneth vagy veth -en keresztül vannak a kliensek felé a kapcsolatok? > Miért van REFUSED a többi VPS-en? A 102-es VPS-en - ahol a bind van - > meg megy szépen? > (A VPS-ek látják egy mást, mert be tudnak ssh-zni egymáshoz. > A 102-es VPS-en a named a 127.0.0.1 és a 192.168.1.102 címen is fut!) Bind log-ja mit ír róla? tcpdump van a bind-os vz-ben? A többiben? Akadálya, hogy feltedd? Mit mutat? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ssl
Hi! "Hóbor István" írta 2009-08-20 14:56-kor: > Mit ronthatok el? teljes egészében a manual szerint csináltam, nyilván a > flienevek változtak néhol. Tipp: Az ssl-t használó szervernek van joga felolvasni a kulcsfájlt? Esetleg a szerveroldali logokat nézd meg. Ha másképp nem megy, akkor pedig strace, hogy biztos azokat a kulcs és certificate fájlokat olvassa-e fel, amit te gondolsz! ;-) Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ssh tunnel biztonság
Szia! ""Kónya Zoltán (EVM)"" írta 2009-08-19 21:01-kor: > > > permitopen="host:port" > > > szerintem ez nekem nekem nem teljesen jó > vannak userek amik az egyik szerver egyik portjához, míg mások másik > szerver másik portjához férhetnek hozzá - nincs userre való korlátozási > lehetőség Mielőtt biztos jelét adod annak, hogy nem értetted meg, amit kissg beidézett a man-ból, javaslom fuss neki még egyszer az idézett kézikönyv megfelelő fejezetének. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: iptables gyorssegely
Hi! "Kiss Gabor" írta 2009-08-13 07:16-kor: > Ez mindenfele szolgaltatasokat nyujt a regi szomszedainak. > Illetve csak nyujtana. Van ami nem megy, mert a kliensei most > hiaba kuldik a broadcastokat a 137-es UDP portra (netbios-ns), > baratunk nem kapja meg oket. Ez ugyan nem a kérdésedre a válasz, csak egy észrevétel: Miért akarod, hogy broadcast storm legyen a hálódon? Wins-t tessék beállítani, és előre eldönteni ki a master browser. Lajbi élményszámbamenően tudja elmondani, milyen az, amikor broadcast segítségével van browser election! ;-) Ha meg dhcp is van a környéken, akkor dhcp-ből el is tudod mondani a klienseknek, hogy csak a kijelölt wins szervert használják, és az ki legyen. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: inet mukodesenek tesztelese nem default gw-n keresztul
Hi! "Fried Zoltan" írta 2009-08-11 16:01-kor: > Azt hiszem ezt most nem ertem. ^^^ Itt lesz a probléma. > A pingnek van egy -r kapcsoloja is. > -r Bypass the normal routing tables and send directly to a > host on an attached interface. If the host is not on a > directly-attached network, an error is returned. This option > can be used to ping a local host through an interface > that has no route through it provided the option -I is also used. > > Ezt is probaltam, de a helyzet valtozatlan volt. Ne haragudj meg, hogy ezt írom, de ezeknek a kérdéseknek a kezdő listán lenne a helye, ameddig fogalmad nincs arról, hogy működik az ethernet, arp, ip, routing, stb. Sőtt ehhez a témához ezen a listán az is elvárt minimum lenne, hogy ehhez a kérdéshez a lartc 4.2-es fejezetét elolvasd és megértsd, és csak _az_után_ kérdezz. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: apache ekezet: debian vs. ubuntu
Hi! "Papp Tamas" írta 2009-07-16 16:17-kor: > On Thu, Jul 16, 2009 at 12:39:10PM +0200, Hegedüs Ervin wrote: > > > > be tudod masolni a ket szerver altal elkuldott fejleceket? > > Debian: > > HTTP/1.1 400 Bad Request A hibaüzenetet tartalmazó oldalról van szó? > Date: Thu, 16 Jul 2009 14:05:33 GMT > Server: Apache/2.2.3 (Debian) PHP/5.2.0-8+etch15 > Content-Length: 324 > Ubuntu: > Content-Length: 392 Mi az eltérés a két fájl közt? Nem lehet, hogy tényleg másképp vannak kódolva a fájlok? A méretük nem egyezik. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: apache ekezet: debian vs. ubuntu
Hi! "Papp Tamas" írta 2009-07-16 11:00-kor: > On Wed, Jul 15, 2009 at 09:16:58PM +0200, SZOKOVACS Robert wrote: > Ha van addefaultcharset ha nincs, ugyanazt a rossz eredmenyt adja > vissza, Ubuntu 8.04-en. Tehat mindenkeppen a html-ben at kell irni, > attol fuggetlenul, mi van a http headerben (azt is megneztem). > > Ez hogy lehet? Konkrétan mi az adddefaultcharset értéke? on, off, vagy utf-8, esetleg iso-8859-2? Mind mást jelent! Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Re: Rendszerkialakít ás virtualizáció (samba, imap)...
Hi! "Lajber Zoltan" írta 2009-07-02 10:43-kor: > > >> NTP és NTPdate > > > xen-nel a dom0 oraja legyen pontos, a domU orak igazodnak hozza. > > Nem xen-t használok, hanem qemu -t. hvm és paravirt mellett érdemes lehet még az OS virtualizációt is figyelembe venni. > > Azért gondoltam ide tenni és nem a log szerverre, mert azon nem akarok > > külső hozzáférhetőséget biztosítani senkinek és semminek. Munin-hoz > > meg kell apache2 és azt tudomásom szerint gyakran támadják. Szerintem > > így biztonságosabb... > > Ez az igaz resze. De a munin-t futtato gep eleri az osszes szervert. Ha > feltorik, akkor gaz van... > Igazabol az lenne a jo, ha munin egy adatbazisba gyujtene, es egy masik > gep ezt mutatna weben. De az mar nem munin (de vannak igeretes > probalkozasok) Én szoktam olyat csinálni, hogy a munin a host-ra, és a host /var/www/munin egy symlink az apacheos vserver /var/www/munin-jába. De igazából olyan könyvtárba teszed, ahova csak szeretnéd. A lényeg, hogy a munin-al egy gépre _nem kell_ apache. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Content-Type probléma
Hi, "Szládovics Péter" írta 2009-06-29 13:54-kor: > Gyanítom, hogy egy környezeti változó lesz a tettes, de melyik, és mit > állítsak rajta? Én első körben az LC_ALL-t, ill. a LANG-ot nézném meg. Meg, hogy a locale parancs a kimenetére miket üzen. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Serveraid 8k
Hi! "Papp Tamás" írta 2009-06-05 17:47-kor: > Mukodik, relativ jol es gyors is. Ket ilyen gep van, rajta drbd. Amikor > az initial sync-et futtatom, a Source-on ez van a logokban: > > [ 543.533516] aacraid: Host adapter abort request (0,0,0,0) > [ 543.533604] aacraid: Host adapter reset request. SCSI hang ? Ezek adaptec cuccok. Nem nagyon gáz? Én már anno próbáltam adaptec oldalain végigmenni, hogy vmi. management sw-m legyen, mint 3ware-nél a tw_cli, de nem jutottam végére, ill. épp csak azt nem kérdezték, mekkora óvszer kell. És akkor még arra se mernék az on-line leírások alapján megesküdni, hogy ebből is tudok olyanokat, mint a tw_cli-vel, hogy a mgmt sw-vel hozok létre tömböt, mert a !+/%=+"%'+ HP Biosa kiütötte a kártyáét, és az nem tudta a bootkor a tömböt inicializálni, bár szerencsére a rendszer a HP compaq smartarray-en van... De ez egy másik történet. Raid-elést mertél a kártyára bízni? Vagy inkább úgy teszem fel: TG vagy lajbi esetleg más merne rá nem sw-raidet tenni? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: 2TB diszk limit
Hi! "Kosa Attila" írta 2009-05-25 15:03-kor: > On Mon, May 25, 2009 at 03:00:49PM +0200, PÁSZTOR György wrote: > > > > Futott már bele vki. ilyen problémába? > > Milyen partíciós séma van még, amit PC biosa be tud bootolni, de képes >2TB > > lemezt kezelni? > > http://groups.google.hu/group/hun.lists.mlf.linux++/browse_thread/thread/6c1e112913e557e1/c473a9af606b?hl=hu&lnk=gst&q=parted#c473a9af606b Utalást a GPT+parted kombóra találtam. Kérdés: fdisk tudja kezelni, ha parteddel teszek rá, vagy onnantól kezdve parteddel tudom csak managelni? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
2TB diszk limit
Hi! Adódott egy probléma: hw raid vezérlő, benne 4x750GB (698) diszk, raid5-ben, ami ugye nettó 2.05TB, ami pedig >2TB. A probléma, hogy erre a "normál" PC-s partíciós táblával nem lehet partíciós táblát csinálni, mert annak van egy 2TB-os limitje. Mivel ezzel egy gép lett bővítve most nem estem kétségbe, mert figyelmen kívül hagytam a pvcreate nyűgjét, és a diszkből csináltam PV-t, és úgy rá a kötetkezelés, bootolni meg bootol a mellette levő scsi vezérlőről. De az a kérdés, hogy mi lenne a teendő, ha csak ez a tömb lenne a gépben, és bootolnom is kellene róla?! Futott már bele vki. ilyen problémába? Milyen partíciós séma van még, amit PC biosa be tud bootolni, de képes >2TB lemezt kezelni? Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: kimenő smtp problém a
Hi! "Vastagh Norbert" írta 2009-04-23 10:05-kor: > 450 Client host rejected: cannot find your hostname, [ip címem] Ahogyan már KisG is megírta: Vannak akik megkövetelik, hogy az a név, amit a HELO-nál mondasz, az érvényes DNS-ben szereplő név legyen. Némi google után: http://www.exim-users.org/forums/archive/index.php/t-51901.html " In exim.conf under main configuration settings: smtp_banner = mail.server.domain " Persze érdemes azt is ellenőrizni, hogy a reverzre adott név-hez tartozó A rekord ugyanoda mutat-e. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: utf8 kodolas a listan
Hi! "Andras HORVATH" írta 2009-04-14 11:19-kor: > Szoval szerintem Content-type:, Content-transfer-encoding:, es akinek > ez nem mukodik, az kuldjon bugreportot a levelezoje/newsreadere iroinak. > http://www.ietf.org/rfc/rfc2045.txt Ez így kicsit sarkos. Mintha úgy láttam volna a listán, hogy lennének páran (gondolom nem azért, mert a kedvenc levelezőjük), de kényszerűségből Kitekintőt használnak. Annak meg hiába csinálsz szabványos fejlécet, magasról tojik rá. Persze el lehet benne olvasni, csak kézzel kell átkapcsolni a kódolást utf-8-ra. Mondjuk azt is el lehet fogadni ezen a listán, hogy itt ők a nem számító kisebbség. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: 3ware raid tomb mozgatas uj diskekre
"Kovács Attila" írta 2009-03-25 20:55-kor: > Kovács Attila írta: > > Mi az a DCE egyébiránt? Mert ezt a hárombetűset nem ismerem. > > Persze, google, de szánj meg pls :). > > > > > Kigugliztam, már csúszik lefelé a forrás. > Tetszetős első blikkre. Akkor nem jól gugliztál. Lajbi a DataCenterEthernet-et értette alatta. Pl. Cisco nexus termékvonal. A lényege, hogy 10GBit/sec-es sebesség mellett nem store&forward technológiával kapcsol, hanem patch-through-val. Elkezd jönni a switch-be a keret, meghallgatja belőle a mac-et, és a crossbar már kapcsolja is a bejövő vonalat a célgép felé kis áramköri késleltetéssel, hogy a cél is hallja a teljes keretet. Ezt jól megcsinálni nem egyszerű. Viszont a 10GB előnye, hogy átmegy rajta az 1, 2, 4 és 8 GB/s-es FC sebesség is, meg talán ebbe az infiniband-et is bele lehet kergetni. Ez utóbbira már nem emlékszem. Viszont arra igen, hogy ami miatt eltrjedhet az az, hogy léteznek olyan spéci kártyák amik árban közelebb állnak egy 10GE NIC árához, mint egy HBA árához, ami >100kHUF nettó, valamint a DCE-vel való kapcsolattartásra is tökéletesen alkalmasak, és ha épp normál IP-t kell ethernetbe keretezni akkor az megy, ha meg FC-t kell bekeretezni, akkor arra az ethernet szabványban van protokollszám, hogy FC csomag megy belül. De lehet, hogy rosszul emlékszem, és az FC keretezés sincs rajta, csak natív scsi megy abban az ethernet keretben. Lajbi majd kijavít. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Postgrey...
Hi, "Kiss Gabor" írta 2009-03-06 13:54-kor: > > > Pontosan milyen szabályt sért az, aki "3 órával később, vagy még > > > később próbálkozik újra"? > > Ezt a kérdést feltenni szándékoztál a szőnyeg szélén? > > Szándékozom? > A szőnyeg szélén? > TŐLED kérdezem itt és most, mint "szakértőtől". [snip] > Eddig senki (beleértve téged is) nem beszélt arról, hogy az első kisérlet > után feladja. Akkor nem tudom mit problémázol? > Most miért tereled minden áron ebbe az irányba a társalgást? > A kérdés az volt, hogy aki 3 órával később próbálkozik újra. > azt milyen alapon titulálod szabálysértőnek? Ezt kötözködésnek érzem. Olvastad a thread elejét, ahol az volt a feltételezett helyzet, hogy 3 órával később érkezett be egy levél és nekem / akárkinek, hívjuk "szakértő", magyarázkodnia kell. A legegyszerűbb nyilván az a válasz, ha szakmai kell, hogy az SMTP-ben nincs garantált idő a levél kézbesítésére. De a szőnyeg szélén magyarázkodva, ha már magyarázkodni kell, ez fogja legkevésbé érdekelni a nem technikai érdeklődésű ügyfelet/ főnököt. De beismerem az, hogy magyarázkodnom kell a szőnyeg szélén és én ezt úgy interpretáltam, hogy "szabályt sértek", pongyola megfogalmazás volt. De akkor ha már nyelvészkedünk: Te hogyan fogalmaztad volna meg? Mielőtt a leveled többi részére válaszolnék arra lennék kiváncsi olvastad-e a thread elejét is, ahonnan elindultunk? Ha nem, akkor tedd meg légy szíves, és azután kérdezd meg, amiket szeretnél. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Postgrey...
Hi, "Szládovics Péter" írta 2009-03-06 14:13-kor: > Aláhúztam. Emlegetjük, hogy nem spamszűrő, de spamszűrésre használjuk. > De ha tudsz más felhasználási terültetet, ahol a postgrey használható, > akkor az érdekel :) Pontosítanék: Nem a spamek, hanem a zombi gépek ellen védekezel vele. Zombi gépből nem csak spam, hanem vírus is jöhet. A nagy hasonlatosság bennük, hogy csak próbálnak élő smpt relay-eket keresni, és szórni a világba a mindenféle szemetet. A szürkelistázás meg arra szolgál, hogy megelőzés címén az ilyen zombi gépek leakadjanak rólad. Üdv:Gyur! _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
