Re: Mustek szunetmentes USB csatlakozassal
Hi! Szeretnek egy Mustek 600 szunetmentes tapegyseget USB porton monitorozni (=azaz egy programmal kikapcsolni a gepet, ha merul az aksi) grafikus felulet nelkul. A CD-n hozza adott software egy kb 10MByte-os Java alkalmazas. ... [4376948.289000] input: USB HID v1.00 Gamepad [Cypress Semiconductor USB to Serial] on usb-:00:10.1-2 Úgy tűnik, drivert talál hozzá. cat /proc/bus/usb/devices (reszlet) ... I: If#= 0 Alt= 0 #EPs= 1 Cls=03(HID ) Sub=00 Prot=00 Driver=usbhid És ezt ez a sor meg is erősíti. Amennyiben szabványosan kommunikál, akkor igazából bármely USB alapú USB figyelő proggynak illene kezelnie az eszközt - már feltéve, hogy a proggy is szabványosan kommunikál. Magánban áttolok egy 10k-s forrást, próbáld ki vele, remélem, menni fog. Nálam APC Back UPS-ekkel kommunikál és nincs gondom vele. Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: adsl korlatozas, fullduplex BIOS-Kernel
Hi! Ha egy eszköz a BIOSban letiltásra kerül, akkor az az eszköz le van tiltva. Azaz nem jelenik meg egyetlen I/O porton sem, nem küld megszakítást, stb. Egy ilyen eszözt nem fog látni a Linux sem - ergo _nem_ fogja megtalálni az IDE vezérlőt és így a rajta lévő wincsit sem. Igaz, a boot nem is fog elakadni ezen. Nekem regi gepem van, nem ismeri fel a 80G-s vinyot. Ezt letiltottam a BIOS-bol Egy 4,3-asrol bootolok, azutan vigan hasznalom a 80-ast Ne keverjük a dolgokat. A winyó letiltása és a vezérlő letiltása nem ugyanaz! Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: adsl korlatozas, fullduplex
Hi! Tedd a boot wincsit a Primary Masterre, a CD-ROM-ot a Primary Slave-re, es a BIOSban kapcsold ki a Secondary IDE adaptert... Persze oda dugd a NAGY vinyot.. Kernel nem foglalkozik a BIOS-al, meg kell talalnia a Secondary IDE adaptert es rajta a nagyonnagy vinyodat... Ha egy eszköz a BIOSban letiltásra kerül, akkor az az eszköz le van tiltva. Azaz nem jelenik meg egyetlen I/O porton sem, nem küld megszakítást, stb. Ezt honnan veszed? :) A BIOS is csak egy software mint ahogy pl a kernel is az. Eddig egyetértünk. Sok BIOS tiltas tipikusan csak pl primitiv real mode megszakitas (int 13h pl) fele nyujtott dolgokat allit, amit modern OS ugysem hasznal. Ebben már nem értek egyet. Ugyi kezdődik azon, hogy túl sok minden megváltoztatható: RAM frissítéstől proci ffrekiig majd minden. De rendben van, ez nem tiltás kategória, hagyjuk hát. De valahogy nem érzem interrupt alapú tiltásnak azt sem, hogy az alaplapra integrált eszközöket engedélyezem-e avagy nem. Percig nem vitatom, hogy winyó esetén a dolog igaz - de esetünkben már az IDE port tiltásáról volt szó. Az meg nem simán inetrrupt alapú. Egyszerű dolgot mondok: kell neki I/O port is... ;-) Mas esetben persze allithat erdekesebb hw kozelibb dolgot is, de akkor is gyakran az van, hogy az barmikor felulbiralhato pl kernel altal ugyanugy ahogy BIOS tiltotta. Maradjunk annyiban: szerintem az alaplapi eszközök tiltása/engedélyezése alapvetően ez a kategória, azaz erdekesebb, hw közelibb dolog. Amiben viszont nem értek egyet: hogy ez kernelből felülbírálható. Lévén ez a dolog alaplap specifikus, ráadásul nem jellemző, hogy ezt gyakran kelljen állítgatni, akkor meg tedd meg egyszer az eszközhöz adott programmal, azaz a BIOS'-szal felkiálltással állítom, hogy ez _nem_ kerül bele egyetlen épeszű kernelbe sem. Ezzel együtt ha keresel nekem egy olyan kódrészletet a kernel forrásban, amely pl. a BIOS-ból letiltott IDE vezérlőt visszakapcsolja... nos, akkor fejet hajtok a tudásod elött. Normal esetben persze ez nem tul szep megoldas, de azert azt sem szabad kijelenteni hogy lehetetlen, mert ez nem igaz ... Ebben egyetértünk. Mivel a BIOS is csak software, ezért valóban nincs akadálya egy _másik_ programot írni, ami _ugyanazt_ tudja. Csak szerintem ez nem tipikus igény, épp ezért ilyet kernelbe nem fognak integrálni. Pl egyes BIOS bug workaround-okra szokott a kernel olyat csinalni hogy letilt/enged dolgokat amirol a BIOS maskepp rendelkezne ... Hmmm... A Linux ugyi nem is használja a BOIS-t, tehát ebben az esetben a BIOS workaround sem szükséges. A másik: amíg a BIOS teljes mértékben figyelmen kívül hagyható, addig melyik komponense nem bírálható felül? Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: imap terhelt...
Hi! Gondolom mbox. Igen, uw-imap. Sok webmail (pl. Openwebmail, stb) index-eket keszit az mbox file-okrol, igy hatekonyabb, csak azt a reszt olvassa ami ot erdekli. Ra-seek-el az adott reszre, kiolvassa amit akar, aztan kesz. Esetleg a dovecot is megér egy próbát. Ez ugyanis szintén készít indexeket - szemben az uw-imapd -vel, ami nem - és ez is lökhet valamelyest a sebességen... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: apache public_html könyvtár áthelyezése
Hi! Az Apache konfigjában van egy olyasmi, hogy # Control access to UserDir directories. The following is an example # for a site where these directories are restricted to read-only. # Directory /home/*/public_html Na most ha ebben a Directoty direktívát máshova tesszük, nem az user $HOME-jába, akkor az a probléma, hogy hol is legyen a könyvtár, letudva. Ha ezek után 750 jogokat teszünk rá (rwxr-x---), majd az adott user tulajdonába helyezzük és csoportként az apache csoportját adjuk meg, akkor az összes eredeti probléma le van tudva: minden user a saját könyvtárába bármit tehet, a másikéba meg nem lát be. Az apache meg a csoport jogok alapján mindenkiét tudja olvasni és így szolgáltatni. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: OpenVPN rossz ip cimet kap...
Hi! Eddig ment az openvpn-em, de most valami nem koser. Nalam lehet valami, mert egy masik kliensgeprol megy ugyanarra a linux szerverre. Szoval nalam az openvpn kapcsolat latszolag letrejon a win kliens ki is irja, hogy Assigned IP: 10.1.0.3. De valojaban ha megnezem az ipconfig-al, nem kapja meg az IP cimet (valami 169.254.168.68 cimet kap). Ilyenkor mi van? :( Ha a Windows alatt OpenVPNGUI-t használsz, akkor az telepíti a Windowsos tun/tap drivert, amit az OpenVPN használ. Ennek a drivernek viszont tun alatt van egy nagyon komoly limitációja is: a felhúzott IP-nek ha a fene fenét eszik is, egy /30-as subnetbe kell esnie. A kapott 10.1.0.3-as IP cím egy /30-as subnet broadcastja, azzal tehát nem fog menni. A 169.254.168.68 viszont emlékezetem szerint az az IP, amit a Windows akkor húz fel, ha az interface-t UP-ba teszi és nem kap DHCP-vel IP-t... Honnan jön ez a 10.1.0.3-as IP? Nem lehetne ezt valami más IP-re felhúzni? pl. 10.1.0.1, 10.1.0.2, 10.1.0.5, 10.1.0.6, stb... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ADSL kabelezes
Hi! Nagy rózsaszín szolgáltatónál - legalábbis régebben, amikor teszteltem - kettő is bemegy. Kisebb szolgáltatóknál tényleg csak egy, úgy tudom. Datanet jobban teccik: beenged ugyan ketszer, de ugyanazt az IP-t adja mindket kliensnek - aztan meg csodalkozol, hogy mi a banatert nem megy rendesen a net... :-) (kb. egy eve futottam bele)járt A gond az hogy a rózsaszin telefon hálózatán ez sac/kb 6-hete nem elérhető! A megszoritást azonban csak ugy tudják alkalmazni, hogy addot végponthoz(telefonszam) tartozó alternatív szolgáltató(pl: datanet, tv-net stb) accát bármilyen, a szolgáltatóhoz tartozó élő acc-al igénybe veheted! Nekünk nem a rózsaszín a szolgáltatónk és tavaly év vége felé megkaptuk a hivatalos papírt, hogy a törvényi módosulások miatt a továbbiakban a különböző ADSL végpontjaink _csak_ ahhoz a szolgáltatóhoz fognak tudni belépni, amelyikkel a netes szerződést megkötötték. A szigor érvénybe lépési határideje 2008.01.15 volt, a gyakorlatban úgy tűnik, majd másfél hónap csúszás történt - de azóta igaz a dolog. Pl. datanet-es végponton bármilyen élő datanet-es acc-al beléphetsz, de ugyanerre a végpontra T-Comos vagy Externet-essel nem! A fentebbi miatt - és ha igaz a dolog, akkor mindegyik szolgáltatónál így van már... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ppp kérdés
Hi! Meg lehet valahol adni egy ppp kapcsolatnak, hogy statikusan /dev/pppX interfészt húzzon magára? Lesz ugyanis egy + adsl vonalunk és nem szeretném ha összekeverednének. (debian etch) A kérdésedre a válasz: igen. Bővebben: man pppd /unit Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: courier imap + tar
Hi! egy scriptbol szeretnem lementen a maildireket, veszont a tar mindig hibara fut, ugyanis a spamek miatt sajnos ejjel 2kor is erkeznek be levelek, valtozik a konyvtar tartalom, es ezt ugylatszik nem szereti (file changed as we read it). leallitani nem akarom a levelezest erre az idoszakra, csak vegso esetben. Mi lenne akkor, ha az MTA két konfigot kapna? Arra gondolok, hogy lenne egy normál és egy queue-only. Mentés elött nyomsz egy restartot a queue-only konfiggal, elvégzed a mentést, majd ismét restart a normál konfiggal. Ekkor a mentés alatt a queue-only mód miatt a levelet az MTA átveszi ugyan, de nem dobja be a címzett fiókjába csak leteszi a saját spooljába - amit nem mentesz. A mentés végén pedig nem csak restart az eredeti konfiggal, hanem runq a spoolba került levelek gyors kiszórása érdekében... Zsolt Ui.: a dolog persze így is fejre állhat, ha egy IMAP kilens pont ekkor tölt fel vagy töröl levelet... Esetleg ezen időre a POP3+IMAP esetleg leállhat? _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: tavfelugyelet tobb vonalon keresztül
Hi! Szabo Istvan írta: ---|Irodai tűzfal| -- :(WIFI): -- |Uzem tűzfal| | |Uzemi cliens| Meg lehet azt oldani, hogy az irodán keresztül is elérjem az üzemi clienst? Merre keresgéljek, mit nézzek meg? Az SNAT-ot nézegetem, de nem igazán boldogulok vele :-( Az elgondolásom szerint egy visszafelé (kintről) NAT kellene portra lebontva (a belső gép azt lássa, mintha a tűzfal beszélgetne a cliensel). Meg lehet ezt oldani, vagy rossz irányba keresgélek? Közben megnéztem és valóban az a baj, hogy az üzem felöl bemenve a cliens gateway - iroda - felé akarna visszamenni a csomag. A szép megoldás az lenne, ha egy router lenne - vagy dinamikus routing protokoll, de az ebben az esetben ágyúval verébre. Ha marad a jelen felállás, akkor a SNAT + MASQ kombó a nyerő, azaz ahogy írod, nem elég a cél IP-t lejavítani és a csomagot tovább küldeni, de a forrás IP-t is cserélni kell, hogy a válasz a tűzfalra essen be és az tolja vissza a csomagot a kérő gépnek. Ekkor a csomag onnan érkezik, ahonnan várja a masina, így működni fog a dolog. Szóval jó irányba keresgélsz, ha már megy a SNAT, akkor csak a MASQ-ot kell sinre tenni. ;-) Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: WiFi kartya
Hi! Log-ban nincs semmi? Próbáld meg, hogy ifconfig eth1 up, aztán Próbáltam. Azt a választ kaptam, hogy nincs eth1 interfész. A próbálkozások idejére kábelen az eth0-án csatlakozik a gép, ezért volna a második a vezeték nélküli. ra0? wlan0? Ilyenek vannak a readmek-ben, amiket eddig találtam. Pl. eth-home eth-work ifconfig -a Kilistázza az _összes_ interface-t, azokat is, amelyek ugyan léteznek, de down-ban vannak. Amit ez nem mutat, az nincs. Használatával nem kell találgatni, hogy mi lett a neve a wifi kártyának, illetve az is látszik, hogy létezik-e egyáltalán... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: openvpn route
Hi! EN ugy latom, a rpute-ok is rendben vannak, es mivel az intraneten levo gepek default gw-je az A jelu linux, azt gondolnam, el kellene erniuk a B jelut gepet es a virtualis halozatot. Megsem teszik. Mit jelene beallitani, hogy mukodjon ez? Van erre vmi extra funckio, vagy alapbol kellene mukodnie? Szia! A linux-Bn fel kell vennia route táblába az A mögöt lévő hálózatot. Ez megtörtént? Utána elvileg mennie kell. Én meg azt is hozzá tenném, hogy a linux-Bn is fel kell venni a linux-A mögötti hálót, mert enélkül a válasz csomagok nem fognak begyűrődni az openvpn tunelba a linux-Bn... Ugyanakkor ennek viszont lesz egy olyan hatása is, hogy innen kezdve B telephely gépei is elérhetik az A telephely gépeit. Ha ez nem kívánatos, akkor viszont nem linux-Bn kell felvenni a linux-A mögötti hálót, hanem linux-An kell MASQUERADE a B telephely irányába. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: VPN és tűzfal beállítás
Hi! Jelen pillanatban a 10.0.0.n szegmensbe működik a VPN, a másik még ezt követően kerül kialakításra. A tűzfalon volt egy ilyen üzenetem: FORWARD packet died: IN=br10 OUT=br10 PHYSIN=tap10 PHYSOUT=eth1.10 SRC=10.0.0.151 DST=10.0.0.4 LEN=60 TOS=0x00 PREC=0x00 TTL=128 ID=5360 PROTO=ICMP TYPE=8 CODE=0 ID=1024 SEQ=2048 Ez annyit jelent, hogy a br10 if-en bejövő csomag a br10 if-en is akart kimenni, de gondolom ez nem lett megengedve. Az ok jól látszik: PHYSIN=tap10 azaz az openvpn-en jött be, PHYSOUT=eth1.10 azaz a helyi háló felé mutató hálókártyán ment ki. Ezt orvosoltam imigyen: iptables -I FORWARD -i br10 -j ACCEPT Ez szerintem két okból nem jó: - nem korrekt, ha csak ezt akarod orvosolni vele, akkor nem elég a -i br0, hanem kell a -o br0 is! Így ez kicsit több engedélyt ad, mint az ideális lenne. - szerintem nem így kéne orvosolni. echo 0 /proc/sys/net/bridge/bridge-nf-call-iptables és már nem is adja fel az iptables felé azokat a csomagokat, amelyek forgalma tisztan a bridge interface-k között mennének Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: rsync vfat...
Hi! Hogyan lehetne rsync-elni pendrive-ra (vfat)? fstab: /dev/sdd1 /mnt/usbautonoauto,users,uid=500 0 0 rsync parancs: rsync -uv --delete --force --ignore-errors $SRC $DST Operation not permitted, chgrp nem lehetséges üzenetek vannak. NTFS a forrás partició és sok fájlt nem másol át. Vagy nem is fog igy menni? :( Pár villám kérdés: - umsdos a vfat helyett? Ott rögtön lesznek unix jogok - igaz a hosszú nevekkel lesz jó eséllyel baj - ha a forrás partíció ntfs, akkor mennyire szentségtörő a gondolat, hogy a pendrive-on is valami más legyen, ne vfat - pl. ntfs, udf, ad absurdum ext3 - ha a penen mindenképpen vfat kell de amit rsync rávisz, az csak mentés így csak unix-like rendszerek alól kell használni, akkor tegyél rá egy nagy file-t, tolj rá mkfs-t, majd csatold be loop device segítségével. Ekkor a penen vfat maradt, az rsync meg neked szimpi fs-re dolgozik a penen. Vagy kell használni ezeket a file-okat nem unix-like rendszerek alól is? Akkor viszont miért/mennyire fontosak a tulajdonosi jogok? Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: [volt] rsync vfat...
Hi! pendrive-ra erdmees lehet ext3-at vagy hasonlot rakni, ha pl. egy linuxos gep adatmentesere akarjuk hasznalni? Ha igen, akkor el lehet gondolkodni valami dirvish-szeru setup-on (a nem valtozott allomanyokat csak hardlinkeli a korabbi tree-khez), de persze a szep az lenne, ha az ember bedugja az USB csatiba, az udev felismeri, hogy ez egy backup pendrive, aztan elinditja a dirvish-t (ha kell) vagy ilyesmi. Az udev-nek elég sok szép rule-ja lakik az /etc/udev alatt. Itt lesz az is, amelyik felismeri a bedugott pen-t és eszköz bejegyzést készít hozzá a /dev alá. Ha ezt a scriptet kicsit kibővíti az ember gyereke, hogy utolsó lépésben nézze meg az aktuálisan élesztett eszköz egyedi sorszámát, akkor ennek alapján felismerhető, hogy a mentésre használatos pen került bedugásra, tehát el kell indítani a dirvish-t. Szóval nem megoldhatatlan a feladat - bár az eredeti kérdéstől kissé elkanyarodtunk... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: postfix smtp auth/tls ldap-ból
Hi! Lészen egy smtp gw, rajta postfix, mögötte ldap-ban userek. SMTP auth/TLS-t kellene készíteni ldap-ból. Szinte mindenhol olyan leírást találok, ahol az authot dovecot, courier, esetleg PAM-on keresztül oldják meg. Valamit biztos rosszul gondolok, de tényleg nem lehet postfixet rábeszélni, hogy kérdezzen LDAP-ot és kész? Ha mégis megoldható, esetleg egy leírást tudnátok linkelni? Ez nem jó? http://www.postfix.org/LDAP_README.html Vagy valamit félreértek? Tartok tőle, igen. Ahogy az eredeti kérdezőnek, úgy nekem is az kéne, hogy SMTP authentikáció történjen és ehhez kéne kihalászni az adatokat az LDAP-ból. Ez a leírás viszont arról szól, hogy a levél továbbitáshoz szükséges adatokat hogy kell elővenni... Van egy olyan vad gyanúm, hogy saslauthd lesz belőle - de még nem kapkodom el... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: sata diskek...
Hi! ki lehet valahogy deriteni, hogy pontosan melyik sata disk fizikailag melyik (sda,sdb.. stb.)? Adott 2db sata kártya és 2db alaplapi sata csatlakozás. Azt biztos tudom, hogy az alaplai sata az utolsó felismert sde és sdf. A diskek egyformák! Van valami ügyes trükk/módzser, hogy kiderüljön melyik disk melyik? Vagy szét kell szedni a rendszert és (egyenként) kitökölni? A smartctl emlékezetem szerint kiírja az adott winyó egyedi szériaszámát is. Ez a szériaszám viszont a winyóra is fel van írva. Ennek alapján szerintem megoldható a feladat. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: inet mukodesenek tesztelese nem default gw-n keresztul
Hi! # ping -c 2 -q -I eth8 index.hu PING index.hu (217.20.130.97) from x.y.8.z eth8: 56(84) bytes of data. --- index.hu ping statistics --- 2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1010ms A tcpdump -i eth8 teljesen ures. Jogosan. Elmeletileg az ping -c 2 -q -I eth8 index.hu parancsnak mukodni kellene, es a kernel sulyeszti el a csomagjaimat ?? Szerintem a parancs működik és a kernel nem süllyeszti el a csomagjaidat. Amit viszont érdemes mindenképpen megnézni: man ping -I interface address Set source address to specified interface address. Argument may be numeric IP address or name of device. Ez azt jelenti, hogy amikor te a -I eth8 opcióval pingelsz, akkor az azt jelenti, hogy a kimenő csomag az eth8 IP címével megy ki - de arról messze szó nincs, hogy azon az interface-n is megy ki! Felveszi annak az IP-jét, majd megtörténik a route-olás és mivel most áll az ADSL, nincs route ami oda mutatna, ezért kimegy a cucc a default gw irányába az eth4-en. No persze ha tűzfal szabály nem engedi ki az eth4-en, akkor nem megy ki. A másik huncutság, hogy útközben nem lesz-e bárki ideges amiatt, hogy olyan IP címről jön a csomag, ami elvben arrafele van, ahonnan jön a csomag. Végül de nem utolsó sorban áll a másik kérdés is: visszafelé hogy fog visszajönni a csomag? Vissza tud találni az eth4 irányon keresztül, miközben az eth8 IP címével gurul? Ha viszont több default gw is van a gépen, akkor ha jól sejtem, iproute2 csomagot használsz. Nem lenne az jó megoldás, ha a helyi gép - és csak a helyi gép(!) - az index.hu-t mindenképpen az adsl-en keresztül látná? Akkor ugyanis a route-olási szabályok alapján is az eth8-on kéne kimennie a csomagnak, tehát ott is fog kimenni. A problémád elvben más irányból is megközelíthető - szerintem. Konkrétan arra gondolok, hogy azok a külön kis dobozkák, amelyeknek már saját IP-jük van és gw-ként jelennek meg és kihúzhatják az ADSL kapcsolatot, azok nagy része SNMP-n keresztül lekérdezhető. Ilyen irányba nincs mozgási lehetőséged? Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: proftpd + pgsql
Hi! Készítettem egy proftpd + pgsql ftp szervert Ubuntura, sajnos nem működik úgy, ahogy szeretném. Azt akarom hogy ftp-n csak a virtual userek kapcsolódhassanak, más felhasználók nem. Egyenlőre fordított a helyzet, a postgres authentikáció nem sikerül. A /var/log/proftpd/postgres.log: ... Sep 22 07:56:54 mod_sql/4.2.2[3048]: + pwd.pw_shell : /bin/false Csak egy tipp, de ha a RequireValidShell = On, akkor a /bin/false nem jó érték és automatikusan azt jelenti, hogy nem léphet be az user. Mivel virtuális usernek nem illik valós shell-t adni, ezért lehet érdemes ezt az opciót kikapcsolni. Másik kérdés: nem lehetséges-e, hogy a logoláson még egy kicsit tekerjél, mert ez a rész nem túl bőbeszédű: Sep 22 07:56:56 mod_sql/4.2.2[3048]: cmd_check Sep 22 07:56:56 mod_sql/4.2.2[3048]: checking SQLAuthType 'Backend' Sep 22 07:56:56 mod_sql/4.2.2[3048]: entering postgres cmd_checkauth Sep 22 07:56:56 mod_sql/4.2.2[3048]: exitingpostgres cmd_checkauth Sep 22 07:56:56 mod_sql/4.2.2[3048]: 'Backend' auth handler reports failure Pontosan mi is az oka a faulire állapotnak? A logból nem derül ki... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: telnet korlatozasok
Hi! Az nagyon fapados elgondolás, hogy a telnetről legyen levéve úgy a futtatási jog, hogy csak a root futtathassa, utána pedig sudo-val megmondani, hogy A user futatthatja ugyan, de csak a1, a2, vagy a3 paraméterrel, B user is futtathatja, de csak b1 vagy b2 paraméterrel, stb. Ebben az eseten a paraméter értelemszerűen az user által elérhető switchek IP-i. Zsolt Peter REPAS írta: Hello! Sajnos a switch-ek egy resze nem tudja a radius-t, ezert most ezt a lehetoseget nem tudom megjatszani. Eleg regi 3Com es HP ProCurve switch-ek is vannak, amiket csak telnet segitsegevel lehet adminolni, ezert remelem, hogy van lehetoseg a telnet korlatozasara meg a szerveren, de koszonom a tippet :) On Monday 28 September 2009 02.01.49 PÁSZTOR György wrote: 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 _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Belso fereg elcsipese.....
Hi! Egy jó tűzfal szabály minden bentről induló levelet redirectel a tűzfalon futó MTA-nak, ami elvégzi a vírus- és spamm szűrést. Ha jó, továbbítja, ha nem jó, blokkolja. A tűzfalon futó MTA kintről nem elérhető, kizárólag a belső hálónak mail-relay - ezekkel a korlátokkal (tartalom szűrés, ugyebár). Zsolt Szilveszter Pinter írta: Udv Mindenkinek! Sajnos vegigfutott nehany Windows-os kollega gepen egy nem vart csunya fereg, aminek eredmenye fekete listara kerulesunk volt. Termeszetesen utolag megtalaltam a bunost es a habat javitottam, viszont meglehetosen kenyelmetlen volt a fekete lista a levelezes szempontjabol.. A kerdesem a kovetkezo lenne. Van-e valamilyen szerverre /atjaro/ telepitheto alakalmazas, vagy esetleg tuzfal szabaly, aminek a segitsegevel azonnal es automatikusan felefedezhetem es letilthatom illetve riaszthatom a belso fertozott gepet /DMZ/. Termeszetesen a szerver linux, es minden kliens a kozponti atjaron keresztul kommunikal a kulvilaggal Az otleteket, linkeket, megoldasi lehetosegeket elore is koszi. Szilvo PS:Meg nem gogliztam, hatha valakinek van mar bejaratott, kiprobalt eljarasa erre a problemara.Ha nem marad a probalgatas. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Belso fereg elcsipese.....
Hi! Ha egy normalisan regisztralt belso geprol a spammer elarasztja mondjuk a belso mail szervert, azt szures nelkul hogy fogom meg, hiszen az a kliens jogosult mail-t kuldeni, es az XP ugyis minden pwd-t rogzit Szilvo Nem a gép van regisztrálva, hanem a felhasználó kliense. (usernév + password). Ha a féreg nem tudja a passwordot, nem tud konnektálni, nem tud levelet küldeni. A mailserveren meg van vírusszűrés mindig minden irányba, ergo kifele se mehet szemét, még akkor se, ha sikerül valahogy konnektálni. A férget nem fogja érdekelni a password: simán rámegy pl. OutLook MAPI-ra. A t. user meg elmentette a jelszavát, tehát a MAPI boldogan előkapja és máris tolja - authentikálva(!) - amit a féreg kér. Szóval innen kezdve csak az authentikáció kevés... Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Belso fereg elcsipese.....
Hi! Ha valaki tud olyan féregről, ami a MUA MAPI/IMAP/SMTP beállításain keresztül a szerveren át küldi a leveleket, írhatna hozzá linket is, nem árt tudni, ha van ilyen gonosztevő. Technikailag elképzelhető ennek a lehetősége, de nem hiszem, hogy tényleg van. Egy ismerősöm kért segítséget: hostingban lévő gépe ontani kezdte a szemetet és nem volt világos, hogy a fenébe használják gyakorlatilag mail-relay-nak a gépét. A logok alapján a szemét SMTPSA kapcsolaton jött be - azaz authentikált a kliens, emiatt viszont az MTA mint trusted client kezelte és csont nélkül átvette a levelet. Mivel a log-ban az user neve is benne volt, egy szimpla jelszó csere megoldotta azt a problémát, hogy a gép mail-relay, hiszen így már nem az. Viszont hogy ez hogy történhetett, arra csak tippem van, mert a beteg géphez nem volt szerencsém - a masina tulajdonosa az ismerősöm egyik ügyfele volt. De azt az estet, hogy az user SMTP szerverét használva, az user azonosítójával és jelszavával authentikálva dől be az SMTP szerverre a szemét, mással egyenlőre nem tudom magyarázni. Ha van rá ötlet, szívesen veszem - csak legyen legalább annyira hihető a sztori, mint az, hogy a féreg az user saját használatra felkonfigurált MAPI-jára ült rá és azt használta. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: OCFS2 mentese Xen domU alatt
Hi! Az ocfs2 érdekes állat. A csatoláshoz nem elég megadni, hogy -t ocfs2, nem elég a modult betölteni - a node-ot be kell léptetni az ocfs2 clusterba is. Zsolt van egy domU, amin van egy drbd dual-primary kötet, rajta ocfs2 fs. A domU lvm-en van a dom0 felett, a domU egyéb részeit le tudom menteni LVM snapshot-tal, de ahol az OCFS van, azt valamiért nem lehet felcsatolni a dom0 alatt: /sbin/lvcreate -s -L10G -nbackuplv /dev/vg-appserv/app-repository modprobe ocfs2 /bin/mount -t ocfs2 /dev/vg-appserv/backuplv /media/backup mount: hibás fájlrendszertípus, hibás kapcsoló, hibás szuperblokk a(z) /dev/mapper/vg--appserv-backuplv eszközön, hiányzó kódlap vagy segédprogram, vagy egyéb hiba Egyes esetekben hasznos információk találhatók a syslogban próbálja kiadni a dmesg | tail parancsot vagy egy ehhez hasonlót _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
ext3 - elfogyó inode
Hi! Egy 700GB-s köteten sikerült bele futnom abba a problémába, hogy a 89%-os foglaltság mellett a kötet tele van, nem írható. Ez azt jelenti, hogy bár kicsit több mint 70GB szabad, mégsem tudok rá írni, mert sz inode-ok elfogytak. A kötet backup célokra használt, a napi mentésnél ha nincs változás egy file-ban, akkor van egy hardlink arra, így ez külön helyet nem foglal, viszont emiatt a szokásos inode felhasználás többszöröse van a köteten. A kérdés az, hogy van-e mód arra, hogy utólag, adat vesztés nélkül növeljem az inode számot a szabad hely rovására. Ha szükséges, a kötet kicsatolható, tehát off-line művelet lehetséges. A témában már kugliztam egy sort, de sok bíztatót nem találtam. Eddíg egy tippet kaptam: mentsem le a kötet tartalmát, a hard linkeket tartsam meg úgy, hogy rsync -a viszi át a cuccost, tegyem újra az fs-t, majd vissza az egészet. Más megoldás valóban nincs? Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ext3 - elfogyó inode
Hi! A kérdés az, hogy van-e mód arra, hogy utólag, adat vesztés nélkül növeljem az inode számot Nincs (vagyis hexeditorral maximum ;), de egy mentes-visszatoltes ennel joval egyszerubb.) A hexeditorhoz olyan szintű fs ismeret kell, amely keveseknek van. Én nem vagyok közöttük... A mentés-visszatöltést azért nem érzem egyszerűbbnek, mert mint a levél nem idézett részében említettem, nagyon sok a hardlink. Egy sima copy minden file-t át fog vinni egy példányban, így a jelenlegi 630GB pillanatok alatt 2.5-3TB lesz. Vagy rsync -a és ki tudja meddíg tart... A témában már kugliztam egy sort, de sok bíztatót nem találtam. Eddíg egy tippet kaptam: mentsem le a kötet tartalmát, a hard linkeket Ha ezt az utat valasztod, javaslom, hogy az uj filesystemed dinamikusan foglalja le az inode-okat (pl. xfs). Maradt ez az út. Winyó csere és rajta xfs. Itt meg bebukom a 70GB-t, majd egy év múlva amikor ismét ezekre indul a mentés, akkor már figyelni fogok erre. Köszi a válaszod. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ext3 - elfogyó inode
Hi! A mentés-visszatöltést azért nem érzem egyszerűbbnek, mert mint a levél nem idézett részében említettem, nagyon sok a hardlink. Egy sima copy minden file-t át fog vinni egy példányban, így a jelenlegi 630GB pillanatok alatt 2.5-3TB lesz. Vagy rsync -a és ki tudja meddíg tart... Ki mondta, hogy cp-t használj? Barátod a tar, cpio, afio... soroljam? :-) Igen, kérlek sorold. Különös tekintettel arra a peremfeltétlere, hogy a ha egy file 15 helyen szerepel, de ez hely tekintetében egyetlen file, a másik 14 pedig hardlink, akkor őszintén érdekelne, hogy a tar, cpio, afio és egyebek hogyan oldják meg azt, hogy detektálják a hardlinket és a példabeli 15 file-t csak egy példányban viszik ki. Jelzem, nem véletkenül írtam rsync-et, ott ugyanis a man szerint van lehetőség a hardlinkek detektálására és megtartására... man rsync ... Note that -a does not preserve hardlinks, because finding multiply-linked files is expensive. You must separately specify -H. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: ext3 - elfogyó inode
Kedves Listatagok! Szeretnék elnézést kérni meglehetősen udvariatlan korábbi levelemért. Az említett programok valóban tudják a hardlink megőrzését, ahogy azt még példával is illusztráltátok. Bár nem mentségnek szánom, de enyhítő körülményként azért két dolgot megemlítenék: - nagyon a bögyömben van ez a dolog - a levél olvasásakor elhívtak megbeszélésre, így szokásomtól eltérő módon ahelyett, hogy kipróbáltam volna, megelégedtem a man oldal behívásával. Átböngészni persze ezt sem volt időm, így a 'hard' kulcsszóra kerestem rá, feltételezve azt, hogy lesz említés róla, hogy átviszi. Nos, egyik manuálban sincs találat. Mivel én abból indultam ki, hogy ha ezt tudja, akkor megemlítik, így ennek hiányából azt a téves következtetést vontam le, hogy nem tudja. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: procmail
Hi!
A levelekről másolatot egy filterrel csinálok, ami így néz ki:
unseen deliver arc...@localhost
Ezen belul lehetne a cel:
/path/to/mail/arcvhiv_all/${domain}/${local_part}/
akkor megvan az onallo maildir userenkent. Az in/out -ra nincs tippem.
Mi lenne akkor, ha nem egy, hanem két filtert csinálnál az eximben?
Mindkét router a sor elején állna, persze unseen opcióval - de az egyik
a bejövő-, a másik a kimenő levelek archiválásáért felelne.
A bejövő levelek archiválásához egy közel hasonló konstrukció
készíthető, mint ami a tényleges kézbesítést végzi, csak a $HOME
meghatározása történne máshogy, így az archív/incoming könyvtárba
potyogna a levél. (További eltérés lehet, ha a végső kézbesítést nem
az exim végzi - pl. dovecot delivery -, ekkor nyilván ebben az esetben
ez is változni fog: az archiv/incoming mappába az exim kézbesít.)
A kimenő levelek esetén a router és transport hasonló lehet a bejövő
levelek archiválásához használttal, azzal a különbséggel, hogy a
kézbesítési útvonal nem a $local_part és $domain_part alapján
rakható össze, hanem a $sender_address(?) alapján.
(Nem vagyok benne biztos, hogy a változó neve $sender_address,
de hogy van változó, ami tárolja a feladó e-mail címét, az tuti. Ezen
túl ha /$ARCHPERFIX/$DOMAIN/$LOCAL formában akarsz tárolni,
akkor elő kell kapni az exim-HOWTO string műveletek szekcióját és
annak alapján a $sender_address-t darabolni local_part-ra és
domain_part-ra.)
Zsolt
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: php5, libxls
Hi! Naszóval: nekem nem kell, hanem a webfejlesztő kérte ;-)) Egy webáruházhoz kell nekik, az árak frissítéséhez ha jól tudom, de tök mindegy... Tudom hogy nem az eredeti feladat megoldásának az iránya - de... Nem lenne egyszerűbb eleve cvs file-ba kérni az inputot? Ami tud xls-t gyártani, az tud cvs-t is. Az xls file-t valahogy úgyis elő kell állítani - nem lenne egyszerűbb ott belenyúlni a folyamatba és egy könnyebben feldolgozható formátumot létre hozni ott és akkor? Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: cron day of month megadasi formalya
Hi! A kovetkezot raktam a crontab-ba: 53 10 1-7 * 5 oracle echo XXX aminek az eredmenye, hogy minden nap lefut a parancs, nem csak penteken! man 5 crontab: Note: The day of a command's execution can be specified by two fields — day of month, and day of week. If both fields are restricted (i.e., aren't *), the command will be run when either field matches the current time. Segitek ertelmezni: az 1-7 helyett *-t kell irnod. Ez önmagában kevés, ugyanis az eredeti feltétel szerint pénteknek is kell lennie, meg a hónap első hetének is. Ha az 1-7 helyére csillag kerül, akkor az 5 miatt valóban csak pénteken fog futni a script - viszont a hónap összes péntekén, nem csak az elsőn. Ennek fényében tisztán crontabból szerintem a feladat nem megoldható: a crontab minden pénteken elindítja a scriptet és a scriptnek kell első lépésben megnéznie, hogy a hónap első hete van-e? Ha tévednék és a feladat mégis megoldható tisztán crontab beállítással, akkor érdekel a megoldás! Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid10 szervezes - volt: mdadm raid10 szetesik
Hi! Hany diszkes raid10-bol? 4, 4 diszkesbol nem eshet ki ketto. miért? a fenti linken az ábra: The standard near layout 4 drives -- A1 A1 A2 A2 A3 A3 A4 A4 A5 A5 A6 A6 A7 A7 A8 A8 .. .. .. .. most kiesett mondjuk a 3. diszkem. Az 1-es vagy 2-es diszkem miert nem eshet meg ki? más irányból megközelítve, lehet-e ilyet: mdadm /dev/md1 --create --level=raid10 --raid-devices=4 /dev/sda1 /dev/sdb1 missing missing Kibicelek egy kicsit... dd if=/dev/zero of=/tmp/image1.img bs=1M count=10 losetup /dev/loop0 /tmp/image1 Ezzel a módszerrel csinálsz még pár virtuális eszközt, majd elkezdesz kisérletezni: mdadm /dev/md1 --create --level=raid10 --raid-devices=4 /dev/loop0 /dev/loop1 missing missing Illetve ezt variálhatod, a vélt mirroroknak megfelelően: mdadm /dev/md1 --create --level=raid10 --raid-devices=4 /dev/loop0 missing /dev/loop1 missing Amikor a kisérletekkel megvagy és kiderül, hogy ez így működik-e, akkor el lehet kezdeni kisérletezni azzal, hogy mit bír el a tömb, ha kiveszel belől pár diszket. Ezt elsőként érdemes a virtuális eszközökön létrehozott tömbbel lepróbálni, majd ha ott működik, akkor garázdálkodni az élesen. Azt is fontos figyelembe venni, hogy melyik eszköz a tömb hányadik eleme! A valós tömb tesztelése: - masina leáll - 2 RAID winyó lehúz - mdadm parancs, assemble művelet. Szigorúan READ-ONLY-ban indul a tömb, így ha bármi gond lenne, semmit nem fog módosítani, tehát leállás után a másik két winyó visszarakásával normálisan el kell indulnia a tömbnek. - ha a tömb összerakható két winyóból READ-ONLY-ba, akkor azért azt mindenképpen ellenőrizném, hogy mindent jól lát-e a rendszer - innen kezdve két lehetőség van: vagy nem rakható össze a tömb két winyóból csak háromból - vagy elindul két winyóval is. Ez utóbbi persze azt is jelenti, hogy erősen degradedben fut, ami nem igazán ideális állapot. Ha közben a winyók bad block hibákat is jeleznek, akkor degradedbe vinni a tömböt nem egy életbiztosítás! Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Centos 5.5 bind 9.x - domain...
Hi!
Ezzel sem változott a helyzet:
view internal
{
match-clients { localnets; };
match-destinations { localnets; };
recursion no;
// all views must contain the root hints zone:
//include /etc/named.root.hints;
# ...
Szerintem változott, mert innen kezdve nem megy ki
a netre domaint keresni...
Ugyanakkor:
+ A named.rfc1912.zones
+ # --
...
+ zone intranet.domain.hu.in-addr.arpa IN {
Erre írtam már korábban, hogy
+ - saját belső zóna esetén a zóna nevét nem kell .in-addr.arpa
kiegészítéssel
+ ellátni - az in-addr.arpa egy speciális zóna, a reverz feloldáshoz
+ használatos
Szóval ha ezt a sort lejavítod, hogy
zone intranet.domain.hu {
akkor mi a helyzet?
Zsolt
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: iptables dnat localhost-rol
Hi! A cég weboldalán az egyik oldalon van egy iframe, amiben a hivatkozás a gép publikus IP-je (tehát nem DNS név, hanem IP) és egy port, mondjuk 1.2.3.4:82. Ez van DNAT-tal továbbítva az 5.6.7.8:80-ra. Akkor van gond, ha a proxy mögött ülő kliensek megpróbálják megnézni ezt az oldalt, ui a Squid az őt futtató gép egyik interface-ére próbál csatlakozni, vagyis ilyesmi: A problémát az okozza, hogy ebben az esetben mindkét gép a belső hálón van, így a szerver a válasz csomagot nem a tűzfal felé küldi el, hanem direktben oda tolja a kliensnek. A bibi ott van, hogy a tűzfal manipulálta az eredeti csomagot, a válasz viszont nem ment át rajta, így a válasz csomag vissza- alakítása nem történhet meg. A megoldás az lehet, hogy a nat tábla POSTROUTING láncába is felveszel egy szabályt, ami azt mondja, hogy minden csomag, amely a belső hálóból jön és a kérdéses szerver felé halad, az MASQUERADE. Ekkor a belső hálós csomagok úgy kerülnek a szerverhez, mintha a tűzfal küldte volna, így a válasz csomag is a tűzfalnak megy - ergo lehetőség van a válaszcsomag visszaalakítására és így működni fog a kapcsolat. Amiért ennek a megoldásnak a szépsége vitatható, az az, hogy a szerver innen kezdve az összes belső hálózatból származó forgalmat az eredeti valós gép helyett a tűzfalról származó csomagnak fogja naplózni - viszont a kommunikáció működni fog. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Mi küldi a levelet?
Hali! Az ötleteket fölhasználva a követkző született: Az iptables-be beraktam egy sort --dport 25 -j LOG opcióval, tehát bárki bárhova megnyit egy smtp portot, a naplóban keletkezik nem is egy sor. Ajánlanám a következő bővítést a szabályban: -m state --state NEW Ez csak az első, kapcsolat létre hozását kérő csomagot naplózza. Ahhoz, hogy kiderüljön: ki, honnan, hova, ahhoz elég, a többi adatforgalomhoz tartozó csomag már nem naplózódik. Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: adsl nyűg, részletesebb log kéne
Hali! Az egyik gépen lezajlott az enternet-btelnet átmenet. Ennek következtében a btelnet nem enged be, mi több, az ottani szervizes kolléga nem is látja a login próbálkozást. Arra a következtetésre jutottuk, hogy valahol útközben siklik ki a bejelentkezési kísérlet. Pár évvel ezelőtt volt egy olyan törvényi változás, hogy az ADSL kapcsolat kizárólag annál a szolgáltatónál terminálódhat, amelyiknél a szolgáltatásra előfizettek. Míg korábban az username domain part alapján dőlt el, hogy melyik szolgáltatóhoz kell kapcsolódni, most dirktben mindig az ADSL kapcsolatot biztosító szolgáltatónál végződik a pppd kapcsolat másik fele. Tipp: az ADSL fizikai része még mindig az enternetnél végződik, ami annyit tesz, hogy a fizikai ADSL réteg működik, a pppd-nek van partnere a túloldalon - csak nem azzal beszél, akivel szeretnéd, így az ottani előfizetés megszűnése miatt az authentikáció már sikertelen. Ezt a feltételezést erősti meg az is, hogy a btelnetnél az ottani szervizes kolléga semmit sem lát, még login próbálkozást sem. Arra kért a kolléga, hogy próbáljak valami részletesebb logot kicsikarni a rendszerből, hátha segít előrelépni. Most az a kérdésem, hogy mit-hogy kéne konfigurálni, hogy az alábbinál ... A debug alapvetően jó ötlet - de jelen esetben megvan a hiba ok: PAP authentication failed. A debug bekapcsolásával csupán a részletesebb forgalmat fogod látni - újabb hiba okot szerintem nem. Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid mizeria
Hali! Koszonok minden segitseget, tanacsot. Sajnos semmilyen modszerrel nem tudtam a raid tomboket ujraeleszteni, ezert ujrainstallalom a rendszert. Ugy latom, hogy a fontos config file-okat a lementett imige-kbol strings-szel ki tudom szedni :-( Tanulsag: meglevo raid melle masik gepbol kiszedet raidban levo diszkeket ne tegyunk be. Mivel eddig senki nem vetette fel azt a szentségtörő gondolatot, hogy mi van akkor, ha az UUID megegyezett a két raid tömb esetén, ezért megteszem én. Igen, tudom, hogy ennek az esélye irgalmatlan kicsi - de nem nulla! Mindkét raidtömb /dev/md0 néven futott, tehát ez is egyezik. A későbbi /proc/mdstat kimenet is ilyesmire utal - merthogy van egy olyan raid tömb, ami két lemezből áll és ehhez tartozik további két lemez, azaz lett egy négy lemezes tömb - amiből később két lemez eltűnt. Ha az UUID is egyezik, az eszköz bejegyzés is egyezik, akkor azért nem lehetetlen, hogy a kernel összefogta egy tömbbe az eredetileg két független tömböt. Ha ezek után írni is próbált rá, akkor onnan kezdve bármi lehet... Nagyon lehetetlen gondolat? Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: raid mizeria
Hali! On Wed, 15 Aug 2012 09:07:09 +0200 Zs horz...@freemail.hu wrote: Mivel eddig senki nem vetette fel azt a szentségtörő gondolatot, hogy mi van akkor, ha az UUID megegyezett a két raid tömb esetén, én pont ezt fejtegettem pár levéllel feljebb és leírtam egy esetet, ahol ez pont ilyen jellegű hibát okozott. Érdekes lenne tudni, hogy ez volt-e esetleg, csak hogy valami használható tanulsága legyen az esetnek Miki Semmikeppen nem ez volt. Mint irtam, az eredetileg bent levo ket diszk fel volt particionalva sdb[a,b][1-6] reszre, es kulon-kulon volt raid1-ben osszerakva az azonos particiok: md0: sd[a,b]2, md1: sd[a,b]3 ... Ezeknek a raid-eknek per definito kulonbozo volt az UUID-je, leven korabban a gep mukodott. A betett diszkeken viszont csak egy particio volt, egy raid1, tehat ennek UUID-je semmikeppen nem egyezhetet a meglevo valamennyi UUID-vel (mivel azok kulonbozok voltak). Viszont az osszes raid-et hazavagta a muvelet... Az eltérő particionálást én önmagában nem tekinteném kizáró oknak. Tegyük fel a következő extrém esetet: - a legelső partíción lévő raid UUID egyezik azzal az UUID-val, ami a vendég winyó egyetlen partícióján van - az egyező UUID miatt a raid driver mind a 4 partíciót közös raid-be teszi, de a _vendég_ winyó fejlécében lévő partíció méretet használja - ezek után sikerült egy átlapoló raid tömböt létre hozni, azaz ha az írási művelet az adatterület végére történik, az a vendég winyón még a saját partíció egy része, az a gépben lévő eredeti winyón viszont már a következő partíció... Innen kezdve az első raid-re írás simán haza tudja vágni a második raiden lévő adatokat... De ez csak elmélet... ;-) Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Nem megy a su
Hi! http://www.wmszki.hu/strace.2.log Ebben látok már valamit, de az okát nem. A bash-t nem tudja elinditani. Elképzelhető, hogy azért megy a root user, mert neki alapban nem a bash a shell-je? A többi usernek meg bash kell és azzal valami gond van? root-ként tudsz bash-t indítani? Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: Egy IP, több virtuális gép, eltérő tanúsítványokkal
Szia! Adott egy szerver, melyhez a DNS szerint két IP szám tartozik, magyarán az ügyfelek hol az egyik, hol a másik IP-t kapják meg. Az egyik IP számon két virtuális webszerver fut (apache) értelemszerűen két különböző néven, két különböző tanúsítvánnyal. Hogy lehet lekérdezni távolról az IP számhoz kötötten az egyik, ill. a másik szerver tanúsítványát, pl. hogy érvényes-e még? Kicsit pontosítsunk a dolgon. Ha egy IP ugyanazon portján két virtuális szerver is fut, akkor ahhoz az IP címhez legalább két különböző névnek illene tartozni a DNS-ben. Kérdés: csak az egy ik IP-n van két virtuális szerver, vagy mindkettőn? Én abba az irányba indulnék, hogy a webszervert konfigurálnám úgy, hogy az egyik IP-n megszólítva, de nevet nem adva mindenképpen az egyik tanúsítványt használja, a másik IP-n névtelenül megszólítva pedig a másik tanúsítványt. Ekkor IP alapján egyértelműen el fog dőlni, hogy melyik tanúsítványt kell használni. Ha -I IP számot adok meg, akkor a két tanúsítvány közül csak az egyikre nézve hajlandó válaszolni. Az ssl beállításoknál kéne szétszedni a dolgot. Ha jól sejtem, akkor most egy közös definíció van, pontosítva a virtualhostban. Ha ezt szétszeded két definícióra és a 0.0.0.0 helyett az egyik az első IP-re bindel, a másik a másodikra, akkor ráveheted a masinát arra, hogy egyik esetben a default cert az egyik cert legyen, másik esetben meg a másik cert. Én legalábbis ebbe az irányba kacsintgatnék... Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: syslog-ng help
Hi! ido utan elkezdenek szaporodni a syslog-ng processek, egy ilyen logsor utan: Mar 6 06:08:12 xx kernel: [2833042.058859] init: syslog-ng main process ended, respawning Mar 6 06:08:12 xx syslog-ng[1720]: syslog-ng starting up; version='3.3.4' de kozben a regi process meg ott van es fut, es szivatjak egymast gondosan... Az időpont alapján ez nem a logrotate akciója? A rotáláshoz újra kéne nyitni a logfile-t, kérdés hogy ezt a logrotate mivel biztosítja, mit küld a syslog-ngnek - és az hogy reagálja le? Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: zentyal samba 4 ro megosztas kattintgatva
Hali! Nem szép megoldás, de működhet: - létre hozol egy könyvtárat a backup megosztásának - ide mount --bind -o ro $EREDETI $MEGOSZTAS Ekkor az $EREDETI az az útvonal, ahova eredetileg készül a backup, a $MEGOSZTAS meg az a könyvtár, amit a Samba kiajánl. Ekkor fs szinten lesz RO a teljes backup. Zsolt 2015-03-31 15:18 keltezéssel, Kosa Attila írta: Hello! A megosztasok hozzaferese acl-lel van megoldva. A megosztasok rsync-kel kerulnek mentesre egy masik raid tombre datumozott konyvtarakba, az acl-ek megtartasaval (hogy ha kell, akkor vissza lehessen allitani). A datumozott konyvtarakat tartalmazo konyvtarat szeretnem read-only megosztaskent kiajanlani, hogy a userek egyszeruen hozzaferhessenek a megosztasok menteseihez (termeszetesen csak annak a megosztasnak a mentesehez, amely megosztasnak eleresehez egyebkent is van joguk). Az acl-ek azonban az eredeti megosztasban levo jogosultsagokat engedelyezik a usereknek, ami nem jo. Megvaltoztathatnam az acl-eket, de az jocskan bonyolitana az eletet :) Hogyan lehet read-only megosztast csinalni zentyal 4, samba 4 alatt a webes feluleten? Mert a konfigfajlba be tudom irni, de rogton fejbeveri az egeszet, ha valaki a webes feluleten menti a samba konfigjat... Hasonlo problemanak erzem, hogy peldaul nem latom, hogyan lehet finomhangolni kattintgatva, mit akarok logolni egy megosztas kapcsan... _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: clone zilla
Szia! Szeretném egy 160 Gbytos diszk tartalmát egy 500 Gbytosra átrakni. Ha sikerül, akkor gparted-del meg tudom (?) növelni a partíciók tartalmát. Van rajta egy XP, egy Debian oldstable és a Windows7 boot-ja. A gép lilo-val indul. Mi a véleményetek, mekkora a rizikó? Fog-e menni Clonezillával? Addig elmerészkedtem, hogy bebootoltam a Clonezilla lemezzel, kijelöltem a forrás diszket, a céldiszket ... aztán kiléptem. Mire vigyázzak? Mennyi ideig fog tartani? (8-10 órát jósolnak). Üdv, János Nem tudom, hogy meg tudod-e növelni a partíciók tartalmát gparted-del - de javasolnám, hogy tégy egy próbát a még üres diszkkel (partícionálod, mint a 160GB-st, dobsz rá fs-t, pár file-t felmásolsz - majd megnézed, mi történik resize után.) Amire viszont érdemes lehet figyelni, az az, hogy ha egy partíciót meg akarsz növelni, akkor a mögötte lévő partíciót "hátrébb kell tolni". Amiatt, hogy ekkor a forrás- és cél diszk ugyanaz, ez nem fog lökni a sebességen, sőt! Ráadásul itt fennáll annak a veszélye, hogy az eredeti forráspartíció vége azon a területen van, ahol az új célpartíció kezdődik, akkor a standard "átmásolom az elejétől fogva" módszer csúnyán pofon törli a partíció végén lévő adatokat... :-| Ezen problémát elkerülendő én első lépésben már a tervezett új partíciókat kialakítanám, majd partíciónként másolnám át az adatokat az új partícióra. Persze minden partíción kell majd egy resize*fs, illetve bootolhatóvá kell tenni a lemezt, ez még valóban plusz feladat. Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
Hi! Egy szolgaltato virtualis gepen kellene egy adatbazisban olyan adatokat tarolni, amelyekhez nem kellene hozzaferniuk attol, hogy esetleg direktben elerik a diszket. Emiatt valamilyen titkositott fajlrendszerre gondoltam. Meg nem kezdtem el nyomozni, hogy mely megoldasok a legelterjedtebbek mostanaban. Ubuntu elég régóta felajánlja telepítéskor, hogy a $HOME könyvtár titkosítható legyen. Utólag is könnyen telepíthető, a file tartalmat titkosítja és tárolja, igazából a könyvtár tartalma sem lesz emészthető - értsd: a file nevek is titkosításra kerülnek. Kódszó: ecryptfs. Nálam Kubuntu 14.04 alatt két éve stabilan gurul, úgy tudom, Debian alá is van. Megoldás lehet a cryptsetup is, bár amiatt, hogy ez már nem filerendszert titkosít, hanem egy teljes kötetet, az utólagos beüzemelése nem feltétlen, egyszerű - cserébe viszont olyan fs tehető rá, amilyet akarunk. Mindkét esetben az indulásnál lehet probléma, mert ha a jelszó be van égetve a csatoló scriptbe, akkor az nagyjából a "kulcs a lábtörlő alatt" típusú betörésvédelemnek felel meg, ha meg a script nem tudja automatikusan elővenni, akkor nincs automatikus reboot, be kell lépni a csatoláshoz. ... illetve lehet olyat csinálni, hogy egy script segítségével máshonnan vevődik elő a jelszó, de... Nekem a lenyeg az lenne, hogy Debianon minel kevesebb barkacsolassal mukodokepes legyen, ... de ez már barkácsolás. Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
Hi! Megoldás lehet a cryptsetup is, bár amiatt, hogy ez már nem filerendszert titkosít, hanem egy teljes kötetet, az utólagos beüzemelése nem feltétlen, egyszerű - cserébe viszont olyan fs tehető rá, amilyet akarunk. Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni, legalabb az online meretnoveles mukodjon. man cryptsetup ... resize Resizes an active mapping . ... Tehát első kanyarban lvresize -L megnöveli az LVM kötet méretét, második lépésben dd if=/dev/urandom of=$LVMKOTET bs=1M seek=$MERET feltölti random adattal az új területet, majd jöhet a cryptsetup resize $TITKOSKOTET parancs. Utolsó lépésként a resize$FS $TITKOSKOTET futtatásával meg kell növelni magát a filerendszer is és készen is vagyunk. Az egész on-the-fly elkövethető. Az új terület random adattal feltöltése elhagyható, de security szempontból nem szerencsés - elkövetése esetén viszont *nagyon* észnél kell lenni és precízen ki kell számolni a seek paraméter értékét, ellenkező esetben az öntökönlövés szigorú esetét állítjuk elő!!! Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
Hi! Ami meg eszembe jutott: lvm-mel egyutt kell tudnia mukodni, legalabb az online meretnoveles mukodjon. Az LV-n található block device-t kell titkosítani, és menni fog a bövítés. Es egy snapshot is csak a titkositott eszkozt fogja "lefenykepezni", ugye? Tehat jelszo nelkul az sem lesz olvashato? A snapshot arról a tartalomról készít pillanatképet, ami a snapshot elkövetésének pillanatában van. Mivel a volume titkosított, minden, ami az LV-re íródna, előbb átmegy a titkosító eljáráson, ezért a snapshot csak a titkosított állapotról tud pillanatképet készíteni. Az egyszavas válasz tehát: igen. :-) Ezzel együtt az egy jó kérdés, hogy jelszóval olvasható lesz-e egyáltalán, ugyanis a titkosító modulok is szeretik bejegyezni, hogy a kötet épp meg van nyitva. Namost a snapshot erősen read only, kérdés tehát, hogy erre mit lép pl. egy cryptsetup? Mindezzel együtt ha valamit muszáj, akkor muszáj: az opció lehet, hogy a snapshotot kimásolod egy külön valós LV kötetre, ott már nem read only, így ha máshogy nem, akkor így olvasható lesz. Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Iptables-kérdés
Hi! Asus router gyári firmware (Linux fut rajta) kiexportáltam a tűzfalat és valamit nem értek: Ez a sor: -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT Ez azt jelenti, hogy ha mar lat kimeno kapcsolatot, akkor engedje be a valaszt (RELATED). udp-n nincs ertelmezve az ESTABLISHED. A lényegen nem változtat, csak kis pontosítás: én úgy emlékszem, hogy a válasz beengedéséért az ESTABLISHED felel és a RELATED, ami nincs értelmezve UDP esetén. A lényeg: egy kapcsolat felépítésekor az első csomag NEW opcióval jön, ha az nincs beengedve (és ez a szabály nem engedi be), akkor új kapcsolat nem fog tudni létre jönni, de a már létezőket (valahol valamely másik szabály beengedte, vagy a kapcsolat a másik irányból (OUTPUT) épült fel,) nem bántja. megoldaná az alábbit is és feleslegesen van engedélyezve, vagy rosszul gondolom? -A INPUT -p udp -m udp --sport 67 --dport 68 -j ACCEPT Ez a bejovo dhcp -t engedelyezi. Ha nincs ez a sor, akkor dhcp klienskent fog mukodni, de nem tud dhcp szerver lenni. Ez a konkrét magyarázat. Egyébként meg azt nézd meg, hogy itt mind a forrás-, mind a cél port is meg van adva. Tehát nem elég, hogy UDP-n eltalálod a 68-as portot, de a csomagnak tőled a 67-es portról kell indulnia! Ez azért bőven nagyobbat szűr, mint az előző szabály, ahol nincs semmilyen port korlátozás. Mivel már kezdeményezett kapcsolatokra utal és nekem sima Linux alatt soha nem volt bajom tűzfallal, ha csak ezt az egyetlen sort tartalmazta és csak a related és established csomagokat engedtem, UDP üzenetek is mentek, DNS lekérdezés stb. Nem jelent kockázatot külön az UDP engedélyezése? Nem. A portok szűkítése miatt minimális forgalmat engedélyezel, azt meg engedned kell ahhoz, hogy a masina DHCP szerver legyen. Illetve ha ezt nem akarod, akkor ezt a szabályt kiveheted. Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas <linux@mlf.linux.rulez.org>
Hi! Na, mivel már sokadszor kerül szóba: A /dev/random lassú. Onnan kiolvasni sok száz gigát nem hatékony. Egyetértünk, ezért is volt az eredeti hozzászólásban /dev/urandom. Azzal mi a baj? Üdv Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Távszamba
Hi! Arra gondoltam, csinálok egy barátomnak egy távoli SMB szervert, ahová menteni tud. De mindjárt elakadtam ott, hogy a jelek szerint a forgalom nincs titkosítva. A jelszó sem. (Rosszul tudom?) Az SSHFS biztonságos lenne, de alighanem túl lassú. Az iSCSI nekem is túl komplikált. Az rsync és haverjai csak a barátomnak. :-) Mi jöhet még szóba? A végén tán mégis kiegyezek egy unison-gtk-val...? A forgalom titkosítását oldd meg mással - pl. openvpn. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: backscatter?
Hi! Van egy Postfix levelező szerver, ami fogadja az example.hu -ra érkező leveleket. Vírus/spam szűrés után továbbküldi a céges Exchange -nek. Ha nem létezik a címzett, akkor az Exchange 5xx -es hibakódal eldobja a levelet, amikor a Postfix megpróbálja továbbítani neki. Ezért a Postfix visszaküld egy levelet a feladónak, hogy nem kézbesíthető a levél. Szerintem ez így korrekt is. Korrektnek korrekt - csak ugye lenne korrektebb megoldás is... Merthogy miért is veszünk át olyan levelet, amely a domain-part alapján ugyan ide tartozik, de nincs hozzá fiók? Dobjuk el ezt már az átvétel pillanatában és innen kezdve tököljön a küldő azon, hogy mihez kezd a tuti kézbesíthetetlen levéllel. Szerintem most azért került az IP spam listára, mert az egyik feladó spam-trap cím volt. Nem is lett volna baj, ha a Postfixet futtató gépen az amavisd felismerte volna, hogy spam és eldobja a levelet, de nem, ezért kerülthetett a spam csapdába a visszapattanó levél. Hogy kezelhető az ilyen helyzet? Ú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).) Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: backscatter?
Hi! Szerintem az MX-re nem kell címlista. Ha az én MX-em küldi nekem a levelet és nincs ilyen rcpt akkor nem visszadobom 5xxx-el, hanem kuka. Ez azért nem teljesen RFC kompatibilis megoldás! Melyik RFC-nek nem felel meg? Amelyik szerint levél nem tűnik el "csak úgy". Esetedben viszont van olyan levél, amit az elsődleges azonnal kirúg - 500, menjél innen -, a másik átvesz - 200, rendben -, majd amikor továbbítaná az elsődlegesnek, az átveszi és simán eldobja a levelet, azaz nyomtalanul eltűnik. Nem ugyanaz a kettő! Senki nem mondta, hogy ugyan az. Igaz. Azonban az ember azt várná, hogy ha több MX rekord több gépet ad meg, akkor függetlenül attól, hogy melyik gépnek továbbítom a levelet, ugyanaz fog történni a levéllel. Esetedben ez nem igaz. Igen elvettem kapott rá 200-as kódot, majd landol a kukában, nem tehetem meg?? De, megteheted. Sőt! De az eredeti kérdés az volt, hogy RFC kompatibilis-e ez a megoldás vagy nem, nem pedig az, hogy megoldható-e, megteheted-e... Amikor AMAVIS teszi ~karantánba~ a levelet ott is a felado 200-as kap. Attól, hogy itt is RFC inkompatibilis vagy, nem lesz jobb a helyzet. Bár, legalább következetes vagy. :-) Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: backscatter?
Hi! Szerintem az MX-re nem kell címlista. Ha az én MX-em küldi nekem a levelet és nincs ilyen rcpt akkor nem visszadobom 5xxx-el, hanem kuka. Ez azért nem teljesen RFC kompatibilis megoldás! Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: backscatter?
Hi! Valószínűleg legeneráltatom a teljes címlistát és azt használom, mert * ha valamiért nem tudja leellenőrizni az első megoldás a cím meglétét (jelszócsere az exchange -en, vagy éppen nem megy, vagy csak nem elérhető, mert pl. újraindul), akkor visszapattintja a levelet. (Bár lehetne cache -elni a sikeres válaszokat vagy egy napig.) Azért ez így nem teljesen igaz! Más az, hogy 5xx hibával azt mondom, hogy "ne is próbálkozz, mert ezzel így esélyed sincs" és megint más, ha 4xx kód mellet kinyefegem, hogy "most éppen nem tudom átvenni, de egyébként igen, én vagyok az illetékes". Ez utóbbi esetben ugyanis a túloldal a későbbiekben újrapróbálkozik - vagy ha van másik MX, akkor akár azonnal de a másiknál. * A backup MX teljesen máshol van, nem éri el az exchange ldap portját. Azért ezen lehet segíteni, a titkosított portforwardtól a VPN-en át sok mindennel. Ellenben nem biztos hogy érdemes ezt az irányt erőltetni, mert ekkor ha az exchange esik el, akkor automatikusan ugrik az összes MX ellenőrzési lehetősége. * És amúgy is, azért jön ide a levél, mert az elsődleges nem megy. :) Ezt annyira nem érzem oknak arra, hogy átvetessek a géppel olyan levelet, amit egyébként az elsődleges nem venne át. (Abba se menjünk bele, hogy pont ezen hozzáállás miatt terjed az a megoldás a spammerek körében, hogy az alacsonyabb prioritású MX felé próbálkozik első kanyarban.) * Tudok róla, ha változás van, majd csinálok egy szkriptet, amit lefuttatok, ha kell. Ez leszedi a listát és szétmásolja ahová kell. Borítékolhatod, hogy ebből így szopás lesz. El fog jönni az az eset, amikor gyorsan kell új fiók, megcsinálod és elfeleded lefuttatni a scriptet... A szép az lenne, ha trigger indítaná, kevésbé szép a crontab. De valami automatizmus kell. Általánosságban: ugyanilyen szituáció adódik, ha van egy tartalék mx, ami nem tudja a pontos címlistát. Mert ha nem megy az éles, akkor jön ide a levél, befogadja, előbb-utóbb, ha elindul az elsődleges mx, akkor megpróbálja kézbesíteni, nem sikerül, mert nem létezik a címzett, és visszapattan a levél. Ha véletlenül spam csapdába, akkor megvan a baj. Ez máshol hogy megy? A tartalék MX -en ott a teljes címlista? Igen. Ott a címlista. :-) Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: backscatter?
Hi! Szerintem az MX-re nem kell címlista. Ha az én MX-em küldi nekem a levelet és nincs ilyen rcpt akkor nem visszadobom 5xxx-el, hanem kuka. Ez azért nem teljesen RFC kompatibilis megoldás! Melyik RFC-nek nem felel meg? Amelyik szerint levél nem tűnik el "csak úgy". Ha egy levél átvételre került azon felkiáltással, hogy becsszó kézbesítem, akkor ha ez bármi miatt mégsem lehetséges, akkor értesítenem kell a feladót. A feladó értesítésétől egy esetben tekinthetünk el: ha a feladó fiókja is elérhetetlen. Azzal, hogy te azt mondod, hogy ha a levél az MX-ről jön és a címzett nem létezik, akkor eldobod a teljes levelet, a feladó értesítése nélkül, szembe mész ezzel az ajánlással. Ráadásul nem látom be, hogy ugyanaz az ellenőrzés, ami az elsődlegesen elvégezhető, a másodlagoson miért nem elvégezhető? Csak mert ez élből jelenti azt is, hogy a két gép eltérő szabály rendszerrel fut. Nekem az tűnik logikus szabály rendszernek, hogy bármely mail szerverem is veszi át a levelet, ugyanaz fog történni vele. Esetedben viszont van olyan levél, amit az elsődleges azonnal kirúg - 500, menjél innen -, a másik átvesz - 200, rendben -, majd amikor továbbítaná az elsődlegesnek, az átveszi és simán eldobja a levelet, azaz nyomtalanul eltűnik. Nem ugyanaz a kettő! Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: virtuális lan
Hi! mutassatok utat kérlek, vannak szerte a világon szerverek, amiket szeretnék egy 192.168-ban látni, meg ők is egymást. Merre induljak? tetszőleges VPN megoldás felé, pl: https://openvpn.net/ Ez megfelel annak a kitételnek, hogy 192.168.x.y háló legyen. StrongSwan/OpenSwan/akárhogy hívják https://www.strongswan.org/ ... Ez viszont nem. Ez IPSec, a két megadott pont közötti forgalmat titkosítja, de a szerverek nem kapnak új IP-t. Na jó, ez így nem teljesen igaz. Sőt! Végül is megteheted azt, hogy felhúzol egy dummy0 interface-t, amelynek már a 192.168.x.y alól osztasz netet, az IPSec-et meg úgy lövöd be, hogy a 192.168.x.y net egyes elemeinek a forgalmát titkosítja a valós IP-ket mint érkeztetési végpont. De egyrészt itt nem az IPSec miatt kap új IP-t a szerver, másfelől ezt a megoldást azért nem feltétlenül kell elvetni a bonyolultabb felállás miatt, mert ennek előnye is van! Ebben a felállásban nincs kitüntetett gép - VPN fogadó -, amin minden forgalom átmegy és amelynek kiesése esetén a megmaradó szerverek se látják egymást. Ez azért nem elhanyagolható előny... ... mondjuk ha kellően elborulsz, akkor openvpn alapokon is össze lehet hozni p2p kapcsolatot, láttam is erre egy projektet régebben - az sem feltétlenül járhatatlan út. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Squid AD auth
Szia! Haladok, ha lassan is, de aztán természetesen elakadtam... Ami kész virtuális gépeken: - szerver: debian9, sama4 ad - Windows 7 kliens, működik rendesen (roaming profil, stb.) - tűzfal: debian9, squid3 transzparens proxy. Amit kiemelnék: _transzparens_ proxy A tűzfal gépre került samba4, winbind, bekonfiguráltam, része az AD-nak, wbinfo -u és wbinfo -g mutatja, amit kell. Elvileg létezik egy egyszerű módja annak, hogy squid acl-eket hozzak létre az AD-ban lévő csoportok alapján: wbinfo_group a neve. https://www.systutorials.com/docs/linux/man/8-ext_wbinfo_group_acl/ És itt az elakadás: nem indul a squid. Ennyi van a konfigomban egyelőre, mint acl: external_acl_type wbinfo_check %LOGIN /usr/lib/squid/ext_wbinfo_group_acl Ez meg a másik: %LOGIN acl inetcsoport1 external wbinfo_check inet1 acl inetcsoport2 external wbinfo_check inet2 http_access allow inetcsoport2 http_access allow inetcsoport2 Indítanám, az eredménye: ERROR: Invalid ACL: acl inetcsoport1 external wbinfo_check inet1 ERROR: Invalid ACL: acl inetcsoport1 external wbinfo_check inet1 A transzparens proxy lényege, hogy a kliensen nem csak hogy nem kell hozzá semmit sem konfigurálni, de a kliens igazából nem is tud arról, hogy proxy-n megy át - ezt a tűzfal fogja intézni. Viszont ebből következik egy másik dolog is: a kliens _nem_ fogja magát authentikálni egy olyan komponens felé, amelynek a létezéséről nem is tud! Tehát vagy van proxy auth, de akkor nem transzparens, vagy transzparens, de akkor nincs auth a proxy felé! Ez ugyan nem az előző hiba magyarázata (hacsak nem nagyon okos a squid3 és ki nem szúrta ezt a logikai bukfencet), ellenben egy másik logikai hibáról jelzés. Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Squid AD auth
Hali! A transzparens proxy is kell, mert majd szűrni kell azokat is, akik csak úgy beesnek... Két apróság: - megoldható a proxy automatikus detektálása is - transzparens proxy helyett egy saját webszerverre is átirányíthatod az ismeretlen klienst, ahol is elmondod neki, hogy itt pedig proxy kell! (Ez persze feltételez olyat, hogy a kliens előtt ülő ember be tud állítani ilyesmit...) (Nem feltétlenül job b ez a megoldás, mint a transzparens proxy - csupán lehetőségként említettem meg! Zsolt _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: dpkg verziósorrend (RPM csomagnevek helyett)
Halihó! Debian alatt ilyen esetben biztosra megyek: HOLD-ra teszem a csomagot oszt frissítsd ha tudod. Ráadásul mezei frissítésnél szól is, hogy lenne mit frissíteni, de nem frissít, mert HOLD-on van a csomag. Csacska kérdés: az rpm alapú disztrók esetén hasonló megoldás nincs? Zsolt 2021. 03. 06. 8:50 keltezéssel, Hegedüs Ervin írta: Szia Feri, On Fri, Mar 05, 2021 at 06:56:04PM +0100,wf...@niif.hu wrote: Hegedüs Ervin writes: On Fri, Mar 05, 2021 at 08:03:14AM +0100, Kiss Gabor wrote: Mert amikor kijön a gyári 3.0.5-1, akkor nem fog érvényesülni a tiéddel szemben. 5pre üti az 5-öt. Valszeg nem fog kijönni - mivel Debianról van szó, pont az a probléma, hogy ha ki is jön, az most a SID-be kerül be max, majd a testing-be, ami majd valamikor stable lesz. Ezek viszont kvázi backport csomagok. Ha kijön a következő stable Debian 1.0.5-tel, amikor neked még valamelyik 1.0.5pre változat van telepítve, akkor nem az fog történni, aminek kellene. valóban, köszi az észrevételt. Egyébként egy ilyen esetben a verzió felülírja a policy beállítást is? (Megj.: esetemben nem nagyon kell attól tartani, hogy egy adott Debian verzión belül kijön egy újabb upstream verzió... :)) Pont erre van kitalálva a ~ karakter a Debian verizójelölésekben: az a semminél kisebb. Így például: 1.0.4 < 1.0.4.99 < 1.0.5~alpha3 < 1.0.5~beta1 < 1.0.5~rc2 < 1.0.5 ez az, amit így leírva nem találtam meg - de simán lehet, hogy én voltam figyelmetlen. Backportok verziózására is hasznos, de íme a szokásos watch file fordulat az upstream verzió "jól sorrendezővé" alakítására: uversionmangle=s/(\d)[_\.\-\+]?((RC|rc|pre|dev|beta|alpha)\d*)$/$1~$2/ Nos, azt hiszem akkor elkezdem az újrabuildelést :). Köszi, a. _ linux lista -linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Raspbian Buster-frissítési probléma
Hali! A dist-upgrade előtt erősen javasolt egy normál upgrade. Anno volt, hogy ezt kihagytam, - szívás is lett belőle. A nálad lévő hibaüzenet erre emlékeztet. A "buster" átírása "stable"-ra sem jó ötlet. Annak idején demo előtt másfél órával még egy csomagot tegyünk fel a demó szerverre. A kérdéses csomagnak meglepően sok függősége volt, de a feljesztői szerveren sem volt gond belőle. Csak a fejlesztőin a a konkrét verzió neve volt beírva, a demo szerveren meg az, hogy stable. Így ez a sok függőség egy részleges ám nem tervezett dist-upgrade-t eredményezett - jó tanulópénz volt. Zsolt 2021. 09. 12. 11:25 keltezéssel, Csaba írta: Sziasztok! Raspbian-t szerettem volna frissíteni. Múltkor jelezte számomra a csomagkezelő, hogy a "Buster" "oldstable" lett. Gondoltam: frissítek a legújabb stabil verzióra. A /etc/apt/sources.list fájlban átírtam a "buster"-t "stable"-ra, majd kiadtam az "apt-get update", "apt-get update --fix-missing" és "apt-get dist-upgrade" parancsokat. Apt-get dist-upgrade esetén hibába ütköztem, amit nem tudok megoldani: root@raspberrypi:~# apt-get dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Error! Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.3.0-6+rpi1 is to be installed E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages. root@raspberrypi:~# apt-get -f install Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 820 not upgraded. Több ötletem nem igazán van. Mit tegyek? Üdvözlettel: Csaba _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Boot vár 2 percet
Szia! Kiemelem a két lényeges sort: [3.539062] sd 0:0:0:0: [sda] Attached SCSI disk [ 131.197879] PM: Image not found (code -22) Itt vár két percet, ami egyébként pont a time out értéke. Majd hibaüzenetet küld. Tipp: sda probléma van, esélyesen valóban HW gond, amit alátámaszt, hogy a másik oprendszer is lassabban bootol: az is küzd ezzel a diszkkel. Zsolt 2021. 09. 22. 12:15 keltezéssel, Attila Rajmund Nohl írta: Hello! Néhány hónapja az asztali gépemen a boot elkezdett várakozni kb. két percet: [2.649966] scsi 9:0:0:0: CD-ROMHL-DT-ST DVDRAM GE20NU10 EE06 PQ: 0 ANSI: 0 [2.652156] ata5: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [2.656011] sr 9:0:0:0: [sr0] scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray [2.656012] cdrom: Uniform CD-ROM driver Revision: 3.20 [2.656831] ata5.00: ATAPI: HL-DT-ST DVDRAM GSA-4082B, A204, max UDMA/33 [2.661655] ata5.00: configured for UDMA/33 [2.688562] sr 9:0:0:0: Attached scsi CD-ROM sr0 [2.698369] scsi 4:0:0:0: scsi scan: 96 byte inquiry failed. Consider BLIST_INQUIRY_36 for this device [2.700186] scsi 4:0:0:0: CD-ROMHL-DT-ST DVDRAM GSA-4082B A204 PQ: 0 ANSI: 5 [2.874566] sr 4:0:0:0: [sr1] scsi-1 drive [2.992590] sr 4:0:0:0: Attached scsi CD-ROM sr1 [3.472154] ata6: SATA link up 1.5 Gbps (SStatus 113 SControl 300) [3.473616] ata6.00: ATA-8: WDC WD1600AAJB-00J3A0, 01.03E01, max UDMA/133 [3.473618] ata6.00: 312581808 sectors, multi 16: LBA48 [3.475147] ata6.00: configured for UDMA/133 [3.475356] scsi 5:0:0:0: Direct-Access ATA WDC WD1600AAJB-0 3E01 PQ: 0 ANSI: 5 [3.480195] sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/466 GiB) [3.480201] sd 0:0:0:0: [sda] Write Protect is off [3.480202] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [3.480210] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.480255] sd 5:0:0:0: [sdc] 312581808 512-byte logical blocks: (160 GB/149 GiB) [3.480256] sd 1:0:0:0: [sdb] 488397168 512-byte logical blocks: (250 GB/233 GiB) [3.480260] sd 5:0:0:0: [sdc] Write Protect is off [3.480262] sd 5:0:0:0: [sdc] Mode Sense: 00 3a 00 00 [3.480262] sd 1:0:0:0: [sdb] Write Protect is off [3.480264] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00 [3.480270] sd 5:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.480271] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [3.506070] sdb: sdb1 sdb2 sdb3 sdb4 [3.506689] sd 1:0:0:0: [sdb] supports TCG Opal [3.506691] sd 1:0:0:0: [sdb] Attached SCSI disk [3.509503] sdc: sdc1 [3.509774] sd 5:0:0:0: [sdc] Attached SCSI disk [3.538500] sda: sda1 sda2 < sda5 sda6 > [3.539062] sd 0:0:0:0: [sda] Attached SCSI disk [ 131.197879] PM: Image not found (code -22) [ 141.268667] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null) Az "Attached SCSI disk" után vár bő két percet. Három meremlevez van a gépben, egy régi 500 gigás HDD (ez az sda), egy újabb 250 GB-os SDD (ez az sdb) és egy nagyon régi 160 GB-os HDD (ez az sdc). Ezen kívül van még egy régi belső IDE-s DVD író meg egy külső USB-s lejátszó (de ezek gondolom nem számítanak). Mi okozhatja a megállást? Egyelőre a google nem segített :-( Korábban pillanatok alatt bootolt, nem változtattam semmit a hardveren. Ráadásul mintha a Windows is lassabban bootolna, ami felveti azt a lehetőséget, hogy hardverhiba van? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: sata_mv
Papp Tamas [EMAIL PROTECTED] az alábbiakat írta a következo hírüzenetben: [EMAIL PROTECTED] cso! Mennyi igen/nem mukodik ez korrektul masoknak? Lehet, hogy csak nekem megy rendesen? HP Proliant ML150, 6 db 36 GB-os UW SCSI HDD-vel, 2 db 3.0 GHz Intel Xeon procival, de megy. Rendszeresen frissítem a kernelt. Volt már rajta: 2.6.13, 2.6.14.2, 2.6.14.4, 2.6.15, és most 2.6.15.2 Megy rendesen! 2.6.14-es kernellel tobbe kevesbe muxik, .15-os kernellel be sem bootol, boot kozben emlekeim szerint vmi dma cuccra panaszkodik es befagy. Viszont láttam már olyan SMP-s gépet, ami tényleg panaszkodott néhány kernelnél valami DMA gondra. Meg tudod írni pontosan, hogy milyen hibaüzi van? Ugy veszem eszre, mintha a performancia akkor tunne el, amikor sw raid1-be pakolom a diszkeket. SW RAID1 alap, mindig ilyen használok szervereknél, HW RAID-re nem telik ügyfeleknek! :) A rendszer amugy egy Proliant ML150. Jol latom egyebkent, hogy ez lenyegeben nem tud HW raidet es kesz? Akkor mit tud, ami extra? Extra? Hát hogy HP! :) Szoval konkretan ezzel a vezerlovel valo konfiguraciok eredmenyei erdekelnenek. 10x tompos _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux Üdv, OBi _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
