Re: freeradius: user / mac-auth

[PÁSZTOR György]

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?

[PÁSZTOR György]

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?

[PÁSZTOR György]

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: IP tables para

[PÁSZTOR György]

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: IP tables para

[PÁSZTOR György]

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

[PÁSZTOR György]

Hali,

"Hegedüs Ervin" <airw...@freemail.hu> írta 2017-11-07 08:06-kor:
> On Mon, Nov 06, 2017 at 11:44:08PM +0100, PÁSZTOR György wrote:
> > "Norbert Vastagh" <vasti...@gmail.com> í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: Shell trace

[PÁSZTOR György]

Hi,

"Attila Rajmund Nohl" <attila.r.n...@gmail.com> írta 2017-05-08 15:26-kor:
> PÁSZTOR György <pasz...@linux.gyakg.u-szeged.hu> í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

[PÁSZTOR György]

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?

[PÁSZTOR György]

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

[PÁSZTOR György]

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

[PÁSZTOR György]

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?

[PÁSZTOR György]

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

[PÁSZTOR György]

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: clone zilla

[PÁSZTOR György]

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

[PÁSZTOR György]

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

[PÁSZTOR György]

Hi,

Attila Rajmund Nohl attila.r.n...@gmail.com írta 2015-08-25 13:25-kor:
 dz Zana János janos.z...@t-online.hu í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

[PÁSZTOR György]

Hi,

Toth Zoltan toth...@gmail.com í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

[PÁSZTOR György]

Hi,

Toth Zoltan toth...@gmail.com í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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu írta 2015-06-08 17:35-kor:
 On 06/08/2015 05:06 PM, Ferenc Wagner wf...@niif.hu wrote:
  Kiss Gabor ki...@ssg.ki.iif.hu 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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi,

B. P. TBC tbc_...@mailbox.hu í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

[PÁSZTOR György]

Hi,

Árpád Magosányi m...@magwas.rulez.org í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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi,

Kiss Gábor ki...@ssg.ki.iif.hu írta 2015-04-12 20:59-kor:
 On 04/12/15 20:05, Almádi Péter dj.p...@gmail.com 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

[PÁSZTOR György]

Hi,

Árpád Magosányi m...@magwas.rulez.org í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

[PÁSZTOR György]

Hi,

Gábor Kovács furto...@gmail.com í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

[PÁSZTOR György]

Hi,

Gábor Kovács furto...@gmail.com í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

[PÁSZTOR György]

Hi,

Kiss Gábor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi,

Kosa Attila zs...@kosaek.hu í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

[PÁSZTOR György]

Hi,

Laborczi Pál lp...@pse.siemens.hu í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

Re: Re: php állományok jogosultsága

[PÁSZTOR György]

Hofferek Attila h...@soka.co.hu í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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu írta 2013-04-11 13:18-kor:
 On 04/11/2013 12:35 PM, PÁSZTOR György wrote:
 
  Hofferek Attilah...@soka.co.hu  í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

svn pre-commit script

[PÁSZTOR György]

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

[PÁSZTOR György]

Hi,

Magosányi Árpád m...@magwas.rulez.org í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?

[PÁSZTOR György]

Hi,

Magosányi, Árpád m4g...@gmail.com í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

Re: honnan íródik vissza?

[PÁSZTOR György]

Hi,

Kosa Attila zs...@kosaek.hu í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: Postfix recipient_bcc_maps probléma

[PÁSZTOR György]

Hi,

szistvan szist...@mail.vcsk.hu í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?

[PÁSZTOR György]

Hi,

SOLYMOSSY Zoltán itsys...@ertekhaz.hu í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?

[PÁSZTOR György]

Hi,

Magosányi Árpád m...@magwas.rulez.org í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

[PÁSZTOR György]

Hi,

Hofferek Attila h...@soka.co.hu í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

[PÁSZTOR György]

Hi,

Gádori Zsolt tak...@freemail.hu í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

samba pdc upgrade lenny vs. squeeze

[PÁSZTOR György]

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: IBM System x3620 M3/debian

[PÁSZTOR György]

Hi,

Kónya Zoltán zko...@evmzrt.hu í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 (?)

[PÁSZTOR György]

Hi,

Erdelyi Gabor erdel...@host.epgep.bme.hu í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

[PÁSZTOR György]

Hi,

SZABO Zsolt sz...@mm.bme.hu í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

[PÁSZTOR György]

Hi,

Szládovics Péter p...@szladovics.hu í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

[PÁSZTOR György]

Hi,

Szládovics Péter p...@szladovics.hu írta 2011-04-11 13:30-kor:
 2011-04-11 13:25 keltezéssel, PÁSZTOR György írta:
  Szládovics Péter p...@szladovics.hu í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 END
preseed settingek
END
apt-get --purge install postfix
debconf-set-selections END
destinations-ra még vmi
END
dpkg-reconfigure postfix
De ÍGY is oda...sza a mailname-t. Azt meg NE tegye nekem oda.

2. Az eredeti kérdésben azt vetettem fel, hogy meg lehet-e valahogy
szépen oldani, annélkül, hogy a csomag telepítése előtt odatennék egy
saját moddolt scriptet chattr +i-zve.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Postfix postconf - debian squeeze

[PÁSZTOR György]

Hi,

Kovács Attila ka...@l3.hu í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

[PÁSZTOR György]

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 END
postfix postfix/mailname string domain.hu
postfix postfix/recipient_delim string +
postfix postfix/main_mailer_type select Satellite system
postfix postfix/relayhost string [mail.domain.hu]
postfix postfix/procmail boolean true
postfix postfix/chattr boolean false
postfix postfix/mynetworks string 127.0.0.0/8 [:::127.0.0.0]/104 [::1]/128
postfix postfix/destinations string $(uname -n).domain.intra, 
localhost.domain.intra,  localhost
postfix postfix/mailbox_limit string 0
postfix postfix/protocols multiselect ipv4
END
apt-get --purge --yes install postfix

Az rm azért kell, hogy ha az alias-est újra kell gyártani, megtegye, és ne
maradjon ott, amit az alap-exim telepítés hozott. Ugyanezért van a --purge
is az install-nál.
A problémám az, hogy a végén tojik az én preseedelt settingjeimre, és
akármit követek el, a destinations-t vmi. saját ötlettől vezérelve
átállítja:
domain.hu, $(uname -n).domain.intra, localhost.domain.intra, localhost
-ra. Ez meg nekem nem jó, mert innentől azt hiszi magáról, hogy ő
destination-ja a domain.hu-nak, miközben meg nem.
De jó lenne, hogy ha jön egy hibaüzenet, akkor az mégiscsak kézbesítődjön
el a szerveremig, amin a normál levelezés folyik.

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?
Hogy tudom meggyőzni a postinst scriptet, hogy nekem van igazam?
(Leszámítva azt a verziót, hogy az install előtt odateszek egy moddoltat,
majd chattr +i :D)

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: xen lassulás

[PÁSZTOR György]

Hi,

BORBELY Zoltan b...@andrews.hu í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

[PÁSZTOR György]

Hi,

Simon Imre simon.i...@gmail.com í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

[PÁSZTOR György]

Hi,

Simon Imre simon.i...@gmail.com í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: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP 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: BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP 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: BROADCAST,MULTICAST 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: BROADCAST,MULTICAST,PROMISC,MASTER,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 9000 qdisc 
noqueue state UP 
link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff
8: br202: BROADCAST,MULTICAST,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 9000 qdisc 
noqueue state UP 
link/ether 00:10:18:5e:e6:b0 brd ff:ff:ff:ff:ff:ff
11: br300: BROADCAST,MULTICAST,UP,LOWER_UP 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: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN 
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP 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: BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP 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: BROADCAST,MULTICAST 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: BROADCAST,MULTICAST,PROMISC,MASTER,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 9000 qdisc 
noqueue state UP 
link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff
7: br202: BROADCAST,MULTICAST,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 9000 qdisc 
noqueue state UP 
link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff
9: br201: BROADCAST,MULTICAST,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 9000 qdisc 
noqueue state UP 
link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff
11: br300: BROADCAST,MULTICAST,UP,LOWER_UP 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: BROADCAST,MULTICAST,MASTER,UP,LOWER_UP mtu 9000 qdisc 
noqueue state UP 
link/ether 00:10:18:5e:e4:d8 brd ff:ff:ff:ff:ff:ff
13: vboxnet0: BROADCAST,MULTICAST 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

[PÁSZTOR György]

Hi,

PÁSZTOR György pasz...@linux.gyakg.u-szeged.hu í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 bio-0 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 ...  fp[15] 
2227
[   24.856620] bnx2x: eth1: using MSI-X

xen lassulás

[PÁSZTOR György]

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

[PÁSZTOR György]

Hi,

Ferenc Wagner wf...@niif.hu írta 2011-03-23 12:45-kor:
 PÁSZTOR György pasz...@linux.gyakg.u-szeged.hu 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

[PÁSZTOR György]

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..L|
0030  00 00 00 00 00 80 00 04  00 00 00 00 00 00 00 80 ||
0040  00 00 00 00 00 00 00 81  00 00 00 00 00 00 00 82 ||
0050  00 00 00 01 00 32 00 00  00 00 00 04 00 00 00 00 |.2..|
0060  00 00 19 00 b4 a4 02 00  01 00 00 10 74 65 73 74 |test|
0070  00 00 00 00 00 00 00 00  0c 09 08 04 16 00 00 19 ||
0080
root@node05:~# mount /dev/sdb /mnt
mount: /dev/sdb already mounted or /mnt busy
root@node05:~# umount /dev/sdb
umount: /dev/sdb: not mounted
root@node05:~# mkdir xxx
root@node05:~# mount /dev/sdb xxx
mount: /dev/sdb already mounted or xxx busy

Akkor most wtf?

proc/mounts-ban, etc/mtab-ban nem szerepel az sdb.

Mi a retek lehet?

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: KVM/Qemu networking

[PÁSZTOR György]

Hali,

Szládovics Péter p...@szladovics.hu í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ó

[PÁSZTOR György]

Hi,

Makó Gábor mak...@freestart.hu í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

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu írta 2010-06-02 07:04-kor:
 
 In article freemail.20100601152049.1860...@xmldata06.freemail.hu,
   =?ISO-8859-2?Q?Czingl=E9r_Csaba?= j4p...@freemail.hu 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: Novell Suse 10.0 vált ás bacup internetre

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu í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: kvm fizikai particio source-kent

[PÁSZTOR György]

Hi,

Papp Tamás tom...@martos.bme.hu í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

[PÁSZTOR György]

Hi!

Papp Tamás tom...@martos.bme.hu í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

[PÁSZTOR György]

Hi,

Hofferek Attila h...@soka.co.hu í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: van-e host a tartomanyban

[PÁSZTOR György]

Hi!

Hofferek Attila h...@soka.co.hu írta 2010-03-16 17:30-kor:
 PÁSZTOR György írta:
  Hofferek Attila h...@soka.co.hu í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

[PÁSZTOR György]

Hi!

Laszlo Baranyai laszlo.baran...@uni-corvinus.hu írta 2010-03-16 19:09-kor:
 Hofferek Attila h...@soka.co.hu í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: KVM hálózat választás

[PÁSZTOR György]

Hi!

szistvan szist...@mail.vcsk.hu í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: ipv6-up.d

[PÁSZTOR György]

Hi!

Kiss Gabor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi!

Moczik Gabor pm_levli...@progzmaster.hu í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: loopmount user-kent

[PÁSZTOR György]

Hi!

SZABO Zsolt sz...@mm.bme.hu í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: telnet korlatozasok

[PÁSZTOR György]

Hi!

Peter REPAS sjrex...@ktk.bme.hu í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: végtelen sleep

[PÁSZTOR György]

Hi!

Kiss Gabor ki...@ssg.ki.iif.hu írta 2009-09-23 10:44-kor:
 
 In article 200909231220.07083@szo.hu,
 Szokovacs Robert s...@szo.hu linux@mlf.linux.rulez.org writes:
  a while(1) sleep(1); tul sok cpu-t eszik?
 
 Igen. Nekem ne ébredezzen fel folyton, ha nem kell! (Itt most szó szerint
 évekig tartó sleepről van szó. Csak áramszünet esetén kell felriadnia.)

De miért is baj, ha felébred, majd újra elmegy sleep-be?

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: OpenVZ - bind VPS-en REFUSED...

[PÁSZTOR György]

Hi!

Makó Gábor mak...@freestart.hu í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: iptables gyorssegely

[PÁSZTOR György]

Hi!

Kiss Gabor ki...@ssg.ki.iif.hu í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

[PÁSZTOR György]

Hi!

Fried Zoltan zoltan.fr...@deirf.hu í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: Re: Rendszerkialakít ás virtualizáció (samba, imap)...

[PÁSZTOR György]

Hi!

Lajber Zoltan la...@lajli.gau.hu í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

[PÁSZTOR György]

Hi,

Szládovics Péter p...@szladovics.hu í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

2TB diszk limit

[PÁSZTOR György]

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: 2TB diszk limit

[PÁSZTOR György]

Hi!

Kosa Attila zs...@kosaek.hu í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=hulnk=gstq=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

Re: kimenő smtp problém a

[PÁSZTOR György]

Hi!

Vastagh Norbert vasti...@gmail.com í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

[PÁSZTOR György]

Hi!

Andras HORVATH r...@elvis.elte.hu í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: Postgrey...

[PÁSZTOR György]

Hi!

Kosa Attila zs...@kosaek.hu írta 2009-03-06 08:56-kor:
 On Fri, Mar 06, 2009 at 01:41:16AM +0100, PÁSZTOR György wrote:
  Ha három óra kell neki, az a túloldal gubanca is! Simán, akár
  rendeltetésszerű működés közben sok levél miatti megterhelés miatt is lehet
  4xx hibakód! Ilyenkor a túloldal kötelessége újraküldeni.
  Szerinted ez takarózás az rfc822-vel, szerintem pedig az rfc egyértelműen
  megmondja kié a felelősség! A szürkelista 5 perc után már beengedi. Ha ő
  csak 3 órával később, vagy még később próbálkozik újra, akkor ő az aki nem
  a szabályok szerint játszik.
 
 Nem emlekszem olyasmire, hogy ha 4xx-es hibakoddal utasitja
 vissza egy szerver a levelet, akkor 5-10 perccel kesobb kotelezo
Nem írtam olyat, hogy 5-10 perccel később kellene újraküldje. Én csak
annyit írtam, hogy ha 5 perccel később próbálkozik, akkor már bejön.

Alapértelmezés szerint, ha jól emlékszem 20 v. 30 perc múlva próbálja újból
a postfix.

 ujrakuldeni. Azt gondolni pedig doreseg, hogy egy sok userrel
Ezt nem értem, miért teher a sok user. Mármint azonkívül, hogy
statisztikailag nagyobb a valószínűsége egy-egy adott pillanatban, hogy épp
valaki elküld egy levelet. De ha nem kell a CPU-nak spamellenőrzéssel
_annyit_ foglalkoznia, akkor az gyorsan átszalad a queue-n meg se zizzen
bele a rendszer.

 szerverenek a terheleset. Tehat az egy dolog, hogy te 5 perc
 mulva beengedned, de ezt a tuloldal honnan tudja? Es ha tudna is,
 mit tud kezdeni ezzel az informacioval az smtp demon?
A túloldal nem tudja sehonnan. Nyilván, mikor vki.-től először jön levél az
nem csúszik át gyorsan, csak a fenti kb. 20-30 perc múlva.
Vagy telefon mellé ha sürgős, és megbökik a queue-t, hogy lökje ki magából
újra.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Postgrey...

[PÁSZTOR György]

Hi!

Mihaly Zachar zmih...@madein.hu írta 2009-03-06 02:16-kor:
 Ilyenkor jon a user, hogy xy-tol nem kap levelet, es kulonben is huzzak
 a fenebe, milyen szar levelezorendszert uzemeltetek, hisz ugyanez az
 ember el tudta kuldeni a levelet a gmail-os cimere. Ilyenkor johetsz
 barmilyen RFC-vel, netikettel, akarmivel, a usert _csak_ az erdekli,
 hogy megkapja a levelet.
 
 A napokban kellett foglalkoznom a temaval, kulonben elveszitettem volna
 egy ceget a szerveremrol.
 
 Midezt azert irtam le, hogy ramutassak, hogy azt is meg kell oldani
 szerintem, hogy cimzett alapjan ki lehessen kapcsolni a HELO name
 ellenorzest is, nem eleg a HELO name whitelist. Igy ha valaki pattog,
 akkor ot vagy az egesz domaint felmentem a HELO name ellenorzes alol.
Node RCPT-t később mond mint HELO-t. Hogy ütöd felül?

Mondjuk ilyen még nem jutott eszembe, de helo_restrictons-nél lehet rcpt-t
vizsgálni?

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: ethx kérdés

[PÁSZTOR György]

Hi!

Kónya Zoltán zko...@evmzrt.hu írta 2009-03-06 12:47-kor:
 Ezt letárolja valahol?
/etc/udev/rules.d/*net*
Van egy persistent-net vmi, meg egy persistent-net-generator.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Postgrey...

[PÁSZTOR György]

Hi,

Szládovics Péter p...@szladovics.hu í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

Re: Postgrey...

[PÁSZTOR György]

Hi,

Kiss Gabor ki...@ssg.ki.iif.hu í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...

[PÁSZTOR György]

Hi,

Hegedüs Ervin airw...@freemail.hu írta 2009-03-06 00:32-kor:
  Minden feladó - kliens ip - címzett trióból csak az első lesz
  várakoztatva, normál esetben 30p-en belül megjön a levél, terheltebb
  levelezők esetleg 3 órát is késhetnek, az extrém eseteket nem számolva.
 
 Nem ertem pontosan mit szeretnel ezzel mondani, de ugy gondolom,
 hogy pont az ilyenek miatt erdemes a magyar tld-s visszaoldhato
 klienseket atengedni a Postgrey-en. Van ahol 3 oraert mar a
 szonyeg szelen all a rendszergazda :), ezzel meg siman bejon
 elsore.
Ha három óra kell neki, az a túloldal gubanca is! Simán, akár
rendeltetésszerű működés közben sok levél miatti megterhelés miatt is lehet
4xx hibakód! Ilyenkor a túloldal kötelessége újraküldeni.
Szerinted ez takarózás az rfc822-vel, szerintem pedig az rfc egyértelműen
megmondja kié a felelősség! A szürkelista 5 perc után már beengedi. Ha ő
csak 3 órával később, vagy még később próbálkozik újra, akkor ő az aki nem
a szabályok szerint játszik. Kb. mintha egy ajánlva feladott küldeményre
panaszkodnának, hogy csak 3 hét múlva érkezett meg, és ezt rám akarnák
testálni, mint fogadóra, miközben itthon ültem, csak nem nyitottam ki az
ajtót az első csengetésre.

Ezt akár a szőnyeg szélén is el lehet mondani. Ha nem fogadják el, akkor
álláskeresés start, majd felmondólevél be, és postgrey meg spamszűrő ki,
konfigja töröl, és fulladjanak bele a spamba.

Tapasztalván hogy a postgrey+spamassasin-milter+clamav-milter (figyelem!!!
milter!!!) milyen hatékonysággal és milyen kevés cpu igénnyel szűr idáig
mindenki akinek elmondtam milyen kellemetlenségekkel jár 1-1 új
levelezőpartner betanulásakor, mindegyik maximálisan elégedett vele. Ha
vmi. sürgős, akkor kapcsolatfelvételkor csak első alkalommal tudják, hogy
nyomnak mellé egy telefont, hogy esetleg 5 perc múlva küldjék újra, majd az
újraküldött előbb megjön, és vmikor fél óra múlva az eredeti is, ez senkit
sem zavart.

BTW.: A milteres szűrések miatt a 15 spamassassin által 15 pontosra itélt
spammokat, valamint a clamav szerint vírusokat át se veszi permanens
hibakóddal, innentől még a mailqueue sincs terhelve visszapattanókkal.

Ezt az egész fentit én még avval szoktam kiegészíteni, hogy aki invalid
helo-val köszön be, azt is elhajtom a susnyásba. Ügyfelek már erre is
ráéreztek, hogy új partnerrel vennék fel a kapcsolatot, de vmi. gáz van
velük, és már ők is sejtik, hogy ilyenkor be kell írjam a levelezőpartnerük
ip-jét a balfaszipk nevű konfigfájlba: szólnak,  rákeresek log-ban, látom
valóban odavalók, beírom, és náluk eltekintés van az invalid helo-tól.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: Hálózati sebessé g gond

[PÁSZTOR György]

Hi!

Illés Árpád i...@kozvetito.hu írta 2009-01-28 14:51-kor:
 Samba, scp, ftp protokollokon keresztül file-transzfer oda-vissza, időmérés, 
 és iptraf. (Windows-os kliensről néztem, de két windows között azonos 
 switch-en és kábelen keresztül hozza a rendszer amit elvárok.)
 Mind ugyanazt mutatja.
 Lassú. Kb. tizede az elvárhatónak. (Elvárható alatt nem 1Gbit/s-ot értek, 
 hanem mondjuk 300 Mbit/s-ot. Amit másik két gép között hoz is.)
A win-es gépben milyen kártya volt?
Mert ha részt vesz egy rtl8169-es gigás kártya a dologban, meg egy windows,
akkor az egekből a M$ és a RTL közös haragja egyesülve csap le rád.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: route port valasztas

[PÁSZTOR György]

Hi!

Gabor HALASZ halas...@freemail.hu írta 2008-12-16 09:13-kor:
 PÁSZTOR György wrote:
  Igen, de az OUTPUT chain a routing decision előtt van mind a nat, mind a
  mangle táblában.
  
 
 Eszerint nem:
 
 http://www.netfilter.org/documentation/HOWTO//packet-filtering-HOWTO-6.html
Ez a doksi hibás. Ha már felfedezted küldj nekik bugreport! ;-)

  Szal ennek működnie kell:
  
  iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 80 -j MARK --set-mark 123
  ip rule add fwmark 123 tablad
  iptables -t nat -A OUTPUT -p tcp -m tcp --dport 80 -s masikifipje -j 
  MASQUERADE
  
  Ha mégsem, akkor pebkac.
 
 Ennel az is jobb magyarazat, amit irtam; ismetelni nem akarom, legyen 
 eleg ennyi:
 
 MASQUERADE
This  target  is  only  valid  in  the  nat  table, in the 
 POSTROUTING chain.
Bocs, ezt elírtam, a MASQ-ost POSTROUTING-ba akartam írni.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: route port valasztas

[PÁSZTOR György]

Hi!

Ferenc Wagner wf...@niif.hu írta 2008-12-16 11:47-kor:
 Lásd http://ebtables.sourceforge.net/br_fw_ia/br_fw_ia.html 3b ábra alatt:
 
   Note that the iptables nat OUTPUT chain is situated after the
   routing decision. As commented in the previous section [...], this
   is too late for DNAT. This is solved by rerouting the IP packet if
   it has been DNAT'ed, before continuing.
Ez az ábra is készülhetett azon hibás howto alapján, amit HG beírt.

Kerestem is most olyan szervert, ahol OUTPUT-ban DNAT-olok, és megy:

# iptables-save -c |grep OUTPUT |grep DNAT
[7771:553506] -A OUTPUT -d 127.0.0.1 -p udp -m udp --dport 53 -j DNAT 
--to-destination 192.168.0.1:1053 
[0:0] -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 53 -j DNAT --to-destination 
192.168.0.1:1053 
[1030408:61824480] -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 25 -j DNAT 
--to-destination 192.168.4.1 
[1:60] -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 2401 -j DNAT 
--to-destination 192.168.0.1 


Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: route port valasztas

[PÁSZTOR György]

Hi!

Gabor HALASZ halas...@freemail.hu írta 2008-12-16 12:38-kor:
 PÁSZTOR György wrote:
  
  Kerestem is most olyan szervert, ahol OUTPUT-ban DNAT-olok, és megy:
  
  # iptables-save -c |grep OUTPUT |grep DNAT
  [7771:553506] -A OUTPUT -d 127.0.0.1 -p udp -m udp --dport 53 -j DNAT 
  --to-destination 192.168.0.1:1053 
  [0:0] -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 53 -j DNAT 
  --to-destination 192.168.0.1:1053 
  [1030408:61824480] -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 25 -j DNAT 
  --to-destination 192.168.4.1 
  [1:60] -A OUTPUT -d 127.0.0.1 -p tcp -m tcp --dport 2401 -j DNAT 
  --to-destination 192.168.0.1 
  
 A 192.168.0.1 lokalis ezen a gepen?
Igen, de másik RSBAC jail.
(A 192.168... címek rsbac jailek)

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: postfix + spam

[PÁSZTOR György]

Hi!

Kónya Zoltán zko...@evmzrt.hu írta 2008-12-15 14:10-kor:
 ez megvan, de sajnos ez nincs hatassal a problémára
 a From: mező (ahol az én userem van) a data sekcióban van! az igazi
 küldő MAIL FROM:jean_marie.kle...@agents.agf.fr (persze ez csak egy példa)
 a sender_access gondolom erre (MAIL-FROM) vonatkozik!? vagyis ez alapján
 nem tudom ellenőrizni!
 
 gondolom a probléma az, h az assassin nem data-ként kezeli azt amit
 akként kellene, hanem header-ként

És abba belegondoltál már, hogy mikor ide küldesz levelet, akkor From:
-ként a use...@tedomained.hu lesz a DATA után következő From-nál, ellenben
az MAIL FROM: ... -résznél linux-boun...@mlf.linux.rulez.org lesz.
Sőtt! Ez ilyenkor így van rendjén.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: route port valasztas

[PÁSZTOR György]

Hi!

Gabor HALASZ halas...@freemail.hu írta 2008-12-15 16:58-kor:
iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j 
  MASQUERADE
 Sajnos ez sem működik.
 
 Nem is fog. Mire az output chainben a mangle table sorra kerul, mar tul 
 van a routing decision-on, es onnan meg par lepes a nat table, plane az 
 postrouting chain.
Ok. De abból indultunk ki, hogy előtte már ip rule-al az adott forgalmat
beletette explicit az adott táblába.

Szóval nem értem hol a probléma, mert ennek már kellene működnie.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: route port valasztas

[PÁSZTOR György]

Hi!

Gabor HALASZ halas...@freemail.hu írta 2008-12-15 20:24-kor:
 Nem, tobb rendbeli problema van, azt hiszem, csak interface-re 
Ahogyan az elméleteddel is.

 bindelessel oldhato meg. Az alapeveto problema az, hogy routing az 
 ~layer3, a tcp meg ~layer4, igy a routingnak mindegy, hogy http vagy 
Mindegy lenne, ha ilyen buta lenne az ip rule parancs.
De ahogyan írtad ott az fwmark alpaján is lehet döntést hozni.
Az fwmarkot meg akármi alapján rá lehet aggatni a netfilter/iptables
segítségével.

 smtp. A lartc-s peldak, ha figyelmesen nezegeted, mindit prerouting 
 chainel es nat tablaval operal, az neked meg nincs, es ugy altalaban, 
Igen, de az OUTPUT chain a routing decision előtt van mind a nat, mind a
mangle táblában.

Szal ennek működnie kell:

iptables -t mangle -A OUTPUT -p tcp -m tcp --dport 80 -j MARK --set-mark 123
ip rule add fwmark 123 tablad
iptables -t nat -A OUTPUT -p tcp -m tcp --dport 80 -s masikifipje -j MASQUERADE

Ha mégsem, akkor pebkac.

 mire az iptables input/output sorra kerul, addigra mar az interface 
Az INPUT-nál igen, de ott csak bejövő interfész van.
Olvasd el a manuált!
Idézem:

mangle:
This table is used for specialized packet alteration.  Until
kernel 2.4.17 it had two built-in  chains:  PREROUTING (for
altering  incoming  packets  before routing) and OUTPUT (for
 ~~~
altering locally-generated packets before  routing).  Since

   ~~~
kernel  2.4.18,  three  other  built-in chains are also sup?
ported: INPUT (for packets coming into the box itself), FOR?
WARD  (for  altering  packets being routed through the box),
and POSTROUTING (for altering packets as they are  about to
go out).

Ha nem megy, akkor a ~-vel aláhúzott résznek fuss még neki néhányszor!

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: route port valasztas

[PÁSZTOR György]

Hi!

li...@avia.kfkipark.hu li...@avia.kfkipark.hu írta 2008-12-14 19:21-kor:
 A multi-route-olassal nics semmi gond.
 
 Viszont egyes cel-portokat a megadott szolgaltaton keresztul
 szeretnem elerni. Pl.: a 25-os porot a tcom-on keresztul szeretnem elerni.
 
 // A gateway-en mail server, squid cache van, tehat nincs nat-olas.
A postfix-nek emlékeim szerint meg lehet mondani, mely interfészekre
bind-oljon, ill. mely interfészre bindolva kézbesítsen.

 Amit tettem:
   o ket route tablat hoztam letre: tcom, upc
   o ip rule add from ip_tcom table tcom
 ip route add default via ip_tcom_gw dev ppp0 src ip_tcom  table tcom
 ip rule add from all fwmark 23 table tcom
 
 iptables -A POSTROUTING -t mangle -p tcp --dport 25 -j MARK --set-mark 23
 
 Ez viszont nem mukodik.
Ha postfixen kívül van másod is, akkor még olyat lehet, hogy ip rule-al
explicit az adott portra kimenőt beletolod a megfelelő route táblába, és ha
az kevés neki (mert mégis a default interfész IP-jét adja src IP-nek), akkor
postrouting-ban még elsimítod egy masq-al.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: route port valasztas

[PÁSZTOR György]

Hi!

linux li...@avia.kfkipark.hu írta 2008-12-14 20:05-kor:
   A postfix-nek emlékeim szerint meg lehet mondani, mely interfészekre
qmail-em van.
Az majdnem olyan jó. Szerintem azt is lehet konfigurálni, bár tény, hogy
macerásabb lehet.

   postrouting-ban még elsimítod egy masq-al.
// van másom is: a 80, 443 portokat az upc-n kívánom.
Ehhez buta vagyok; hogyan?
Noss, ha ip rule-al explicit odatetted, _és_ ennyitől még nem működött,
akkor:
iptables -t nat -A POSTROUTING -p tcp -m tcp --dport akarmelyik -j MASQUERADE

Egyébként squid-nek is meg lehet mondani melyik interfészről indítsa a
kifelé menő kapcsolatokat, így amiatt nem fog kelleni MASQ.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: snapshot hogyan

[PÁSZTOR György]

Hi!

Ferenc Wagner [EMAIL PROTECTED] írta 2008-11-24 12:27-kor:
 PÁSZTOR György [EMAIL PROTECTED] writes:
 
  Az lenne a kérdésem, hogy van-e lehetőség tetszőleges block-device
  snapshotolására valahogy a dmsetup vagy valamelyik kernelbeli
  okosság segítségével?
 
 Pontosan. linux-source-2.6.X/Documentation/device-mapper/snapshot.txt
Azt már néztem.

Mit nem vettem észre?

Én ezt úgy értettem, hogy maga a kernelmodul képes rá, de ebből még nem
tudom milyen utility-vel, és hogyan tudom rávenni, _nem_ LV
snapshotolására.

Hint?

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux

Re: snapshot hogyan

[PÁSZTOR György]

Hi!

Ferenc Wagner [EMAIL PROTECTED] írta 2008-11-24 18:00-kor:
 PÁSZTOR György [EMAIL PROTECTED] writes:
 Nem teljesen világos, hogy mit szeretnél...  Létrehozhatsz dm
 blokkeszközöket, amiket dmsetup segítségével különféle módon
 leképezhetsz tetszőleges blokkeszközökre.  Ezzel természetesen nem
 tudod eltéríteni mondjuk a már megnyitott /dev/sdc felé irányuló
 műveleteket, de létrehozhatsz mellé egy COW eszközt, ami arról olvas,
 de máshova ír.
Adott egy partíció.
Egyelőre, most a példa kedvéért hívjuk sda3-nak.

Szeretnék róla hetente egy full backupot készíteni a lemountolása nélkül.

Ehhez milyen előkészületek kellenek a mountolásakor, és hogyan tudok
snapshotot csinálni róla?

Tipikus eset pl. mysql. Viszonylag használható bináris backup készíthető
róla. Mintha vmi. kész debian csomagot is láttam volna hozzá, de ha jól
emlékszem az lvm-el dolgozott.
A lényege annyi volt, hogy flush a táblákra és ro-lock, majd mond egy
snapshotot az lv-re, felcsatolja az lv-t egy ideiglenes könyvtárba, lement
onnan mindent, majd eldobja az lv-t.

No, nagyjából egy ilyen dolgot szeretnék használni olyan környezetben, ahol
nincs lv, csak sima blokk device.

Üdv:Gyur!
_
linux lista  -  linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux