Re: alpine vs. gmail
On 6/9/22 09:40, SZABO Zsolt wrote: Üdv! Használ vki alpine-t gmail-es inbox imap elérésére? Újabban INVALID CREDENTIALS-szal visszadobja az azonosítást (semmi nem változott: eddig @ előtti azonosítóval történt, de most átírtam teljes gmail-es címre és úgy sem megy)... Debugold! Fogsz egy működő IMAP klienst, lehallgatod a hálózati forgalmát és összehasonlítod az alpine-éval. (TLS esetén kicsit trükközni kell, de nem megoldhatatlan. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: google spamszűrő kérdés/probléma
On 5/21/22 11:11, Vertike László wrote: Az SRS emlékeim szerint csak az envelope from / return-path módosításával foglalkozik, a From-hoz nem nyúl (az a DKIM aláírt leveleknek is ártana). Tehát a GMail által megjelenített levélen nem fog látszani, hogy az SRS hozzányúlt. A módosított envelope from-mal leginkább csak bounce esetén kell foglalkozni, de az meg úgyis nagy valószínűséggel átmegy az átírást végző szerveren/szervezeten a visszaúton is. Ááá! Most már világos! :-) Kösz! (Mi tagadás, felületes voltam.) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: google spamszűrő kérdés/probléma
On 5/21/22 10:46, Vertike László wrote: Ahogy most utánaolvastam, elhűltem miféle módszereket ajánlanak a probléma orvoslására: Sajnos sok választásunk nincs. Vagy SRS-el forwardolunk, vagy sehogy... Viszont az SRS-sel a "nevedre veszed" a továbbított levelet, ezért nagyon meg kell válogatni, mit továbbítunk; de gondolom, hogy a bejövő levelek eleve szűrve vannak? Ha nem, akkor az SRS-el valóban könnyű út vezethet a saját levelező szerverünk RBL-ekre felíratásához... Nem azért húzom a szám szélét. Az RBL-re a sima forwardolással is felkerül az ember. (IP címet listáznak, nem a feladót.) Az zavar, hogy itt lényegében egy tunnelt hozok létre. Na de ehhez a fogadó oldalon is kell infrastruktúra, ami kicsomagolja az elrejtett feladót és helyreállítja az eredeti headert. Ez meg nem tipikus. Lefogadom a Gmail nem teszi meg ezt a szívességet! :-) kissg -- _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: google spamszűrő kérdés/probléma
On 5/20/22 20:54, Sörös Zoltán wrote: Bocsánat, ha az eredeti levélből nem lett volna egyértelmű, 'mi' a filmjus.hu domain vagyunk, a val...@valahol.hu küld egy levelet a bar...@filmjus.hu címre, ami /etc/aliases -ből továbbítódik pár címre, többek között az egyik kolléga @gmail.com -os, mobilos címére is. És ezzel pont hatástalanítja az SPF-et, amint azt már Ervin is taglalta. Ez volt a legnagyobb kifogás a módszerrel szemben már kezdettől fogva. Ahogy most utánaolvastam, elhűltem miféle módszereket ajánlanak a probléma orvoslására: http://www.open-spf.org/Best_Practices/Forwarding/ -> http://www.open-spf.org/SRS/ kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Lemezkép felcsatolása hogyan?
On Mon, 13 Sep 2021, Csaba wrote: > > Annak idején volt hasonló feladat. A legegyszerűbb az volt, hogy fdisk > > $IMAGEFILE, kiírattam a partíciókat, majd számoltam egy sor: melíik partíció > > hol kezdődik? Majd a losetup programmal megmondtam, hogy a loop0 legyen > > ehhez az image fájlhoz rendelve, de offset megadással, így nem az elejéről > > kezd olvasni. Így ahány partíció, annyi loop eszköz, de működött. > > Ha van újabb technika, akkor az engem is érdekel. > > > Én is csak ezeket találtam. https://stackoverflow.com/questions/1419489/how-to-mount-one-partition-from-an-image-file-that-contains-multiple-partitions kissg -- L.I.B.A.B. Őrző-védő Kft. _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: dpkg verziósorrend (RPM csomagnevek helyett)
On 3/6/21 2:12 PM, Zs wrote: 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? Ki tudja? Version lock viszont van. (V.ö. apt pinning) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: dpkg verziósorrend
On 3/7/21 9:31 AM, Hegedüs Ervin wrote: pl. ha egy csomagnak egy adott repository-ban magasabb prioritást adok, és ha egy alacsonyabb prioritású repository-ban megjelenik egy frisebb verzió, akkor fog-e frissülni a csomag? Ha jól emlékszem, ez a prioritás konkrét értékétől is függ. Predesztinált értéktartományok vannak. Az egyik így viselkedik, a másik úgy. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: RPM csomagnevek
On 3/4/21 5:29 PM, Hegedüs Ervin wrote: Nemrég csináltam saját Debian/Ubuntu repository-t bizonyos csomagoknak, és ott ezt követtem. Pl.: 3.0.3-1+deb10u2 - ez a Debian official repoban levő csomag 3.0.5pre-1+0~20210114.01+debian10~1.310cbf - ez meg a saját. Itt már a verziószám is nagyobb eleve. Nem hasonlít az én esetemhez. Nem nagyon. De hasonló gondokat látok felmerülni. 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. Ha így tervezted, akkor jó. Ha nem, akkor figyelned kell. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: RPM csomagnevek
On 3/4/21 3:11 PM, Varadi Gabor wrote: 1.10-1.el6 helyett 1.10-1-mypkg.el6 Amit viszont felülcsapna a következő gyári, az 1.10-2.el6. Legalábbis elméletben. Ha lenne még frissítés a CentOS 6-hoz. De már úgyis csak elméleti megbeszélést folytatunk, mert 1.10-2021_5 lett végül. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: RPM csomagnevek
On 3/4/21 1:16 PM, Kiss Gabor wrote: A https://www.thegeekdiary.com/understanding-rpm-versions-and-naming-schemes/ oldal szerint az "e_2" frissebbnek számít, mint az "1". Nem tudom hogy igaz-e amit olvastam a fenti linken, Az anyja szömit! És nem igaz. https://ftp.lip6.fr/pub/linux/rpm/api/4.4.2.2/rpmvercmp_8c-source.html 00076 /* numeric segments are always newer than alpha segments */ Akkor viszont találhatom ki, mi lenne az a release string, ami übereli az "1"-t, és a hivatalos csomagolók nem fogják használni soha. 20210304.1? :-( kissg -- Use the source, Luke. _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
RPM csomagnevek
Sajnos nem értek annyira az RPM/yum vonalhoz, mint kellene. Elakadtam. Adott egy csomag. Volt benne egy hiba. Elővettem az rpmbuild programot és megpatcheltem. A régi release 1 volt, az új e_2 lett. Betettem a repóba. Ennyit lát belőle a target host: # yum list --showduplicates perl-XML-Validator-Schema Loaded plugins: fastestmirror, versionlock Loading mirror speeds from cached hostfile Installed Packages perl-XML-Validator-Schema.noarch1.10-1.el6@Repo1 Available Packages perl-XML-Validator-Schema.noarch1.10-e_2.el6 Repo1 perl-XML-Validator-Schema.noarch1.10-1.el6Repo2 # A https://www.thegeekdiary.com/understanding-rpm-versions-and-naming-schemes/ oldal szerint az "e_2" frissebbnek számít, mint az "1". És ennek dacára mégsem hajlandó a nyavalyás yum frissíteni 1.10-e_2-re. Nem tudom hogy igaz-e amit olvastam a fenti linken, illetve hogy miként kell ezt debugolni. Debianban az apt-cache policy segítőkészebb. A target egy CentOS 6, a yum verziója 3.2.29-81.el6.centos.0.1. Szeretném elkerülni, hogy ötletszerűen gyártsak egy tucat másik csomagot mindenféle nevekkel, és kikísérletezem, hogy melyiket hiszi frissebbnek a yum. "Please help" (Lilu Az ötödik elemben) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Debian: stable/unstable prioritás csomagkezelőben?
On 1/24/21 3:28 PM, Csaba wrote: Rendszer szinten meg lehet -e oldani és ha igen, hogyan, miképpen, hogy ha egy rendszeren a sources.list fájlban meg van adva a stable és unstable forrás is, csak bizonyos csomagokat vegyen az unstable forrásból, a többit viszont ne? http://ubuntu.hu/node/24158 kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: USB-RS232 ttyACM
On 1/20/21 5:10 PM, Szima Gábor wrote: Az okára még nem jöttem rá, hogy miért csereberélődik a BUS ID (a júzerek nem cserélgetik), a többi gépben nincs ilyen probléma. Mondjuk azokban egyforma mind, ebben nem: Nem determinisztikus a különböző driverek inicializálási sorrendje. Ha csak egy driver van, az nem versenyez senkivel, és mindig ugyanabban a sorrendben nézi végig a hardvert. Ha nem automatikusan töltöd be az összes modult, hanem legalább az egyiket utólag, "kézzel", akkor itt is fix lesz a sorrend. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: .tar fájlból való törlés biztonságos?
On 1/12/21 10:16 PM, Gabor Gombas wrote: Lemásolni? Minek? Csak össze tud rakni egy 431 byte-os tesztfile-t. :) És legyen kéznél a strace! Ez a teszt semmit nem mond. Lesz benne 1 db read() es 1 db write() (nagyjából). Az openek az érdekesek. A fő veszély nem az, hogy a "tar --delete" hibás. A dokumentáció szerint a "--delete" helyben írja felül a fájlt, és lassú. Ha nincs hely Hol olvashatnám én is azt dokumentációt? Mánuel nem mond erről semmit. :) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: .tar fájlból való törlés biztonságos?
On 1/10/21 10:20 PM, Szládovics Péter wrote: Én azt mondom, fogd meg a tar fájlt, másold le valahová, és kísérletezz vele másutt, ha félsz tőle, hogy baja esik. Lemásolni? Minek? Csak össze tud rakni egy 431 byte-os tesztfile-t. :) És legyen kéznél a strace! kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: A Mozilla Firefox ugyan nem tökéletes, de ez az ingyenes bővítménye telitalálat - Rakéta
On 11/19/20 3:08 PM, Zsolt Gádori wrote: https://raketa.hu/mozilla-firefox-relay-adatvedelem Ööö... mivel tud ez többet, mint mondjuk a mailnesia.com? kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Partíció kiterjesztése új méret szerint hogyan?
A news gateway csuklása miatt kézzel megismétlem Váradi Gábor hozzászólásának érdemi részét. kissg | parted -s /dev/mmcblk0 "resizepart 2 -1" quit | reboot | resize2fs /dev/mmcblk0p2 _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: HDD mount sikertelen, mi lehet a hiba?
On 7/25/20 3:38 AM, PÁSZTOR György wrote: > Csereld le a hazat egy olyanra, aminek van sajat tapja. Vagy tegyél közéjük egy külsõ tápos USB hubot! kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: HDD mount sikertelen, mi lehet a hiba?
On 7/24/20 7:12 AM, Kiss Gabor wrote: Jul 23 17:51:42 raspberrypi kernel: [ 5371.415257] print_req_error: critical target error, dev sda, sector 63 Jul 23 17:51:42 raspberrypi kernel: [ 5371.415267] Buffer I/O error on dev sda1, logical block 0, lost sync page write Mit tudnék tenni? Lecserélni az SD kártyát. Ez a jelek szerint megmurdelt. Izé... azt hittem az sda az SD kártya. (Nem, nnem azért, mert ugyanazzal a két betűvel kezdődik a nevük! :-) ) Bocs, tévedtem. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: HDD mount sikertelen, mi lehet a hiba?
On 7/23/20 8:02 PM, Csaba wrote: Sziasztok! Raspberry-hez csatlakoztatva használtam egy külső házban lévő HDD-t hónapokig, (eddig) probléma nélkül. Semmit sem változtattam, legfrissebb Raspbian van fent, egyik napról a másikra nem volt hajlandó fel csatolni a HDD-t. Fsck nem ír ki hibát, Jul 23 17:51:42 raspberrypi kernel: [ 5371.415257] print_req_error: critical target error, dev sda, sector 63 Jul 23 17:51:42 raspberrypi kernel: [ 5371.415267] Buffer I/O error on dev sda1, logical block 0, lost sync page write Jul 23 17:51:42 raspberrypi kernel: [ 5371.415313] EXT4-fs (sda1): I/O error while writing superblock Mit tudnék tenni? Lecserélni az SD kártyát. Ez a jelek szerint megmurdelt. kissg -- "A bajt megelőző pillanatig még semmi baj nem volt" (Micimackó) _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: titkositott particio tapasztalatok
On 08/07/2017 01:42 PM, Zsolt Gádori wrote: > Érdemes az titkosítani, ahol maguk az érzékeny adatok vannak, illetve > ahol olyan adat töredékek > lehetnek amikből kellő tudással ki lehet következtetni miként lehet > kijátszani a titkosítást. Na például a /usr nem ilyen. Azt mondanám, elég neked a /home (és esetleg a swap) titkosítása. > böszme és elhagyom :) akkor legalább a munkáim, meg az egyéb nem nyilvános > dolgaim ne menjenek ebek harmincadjára. Ha elveszted a gépet, csak a backup adhatja vissza az adataidat. (Az "ebek harmincadján" nem biztos, hogy azt jelenti, amire te gondolsz. Nem a nyilvánosságot, hanem a pusztulást.) > Meg aztán egy felkonfigurált, használat alatt álló szerkezetről van > szó, és szeretném, ha elsőre > sikerülne, és HA LEHET, elkerülném az újra telepítést, de ez nem kizáró > tényező. Van annyi hely a HDD-n, hogy le tudd másolni a /home-ot? Az sokat lendítene a dolgon. Lehet on-the-fly is titkosítani, de ha valamiért megszakad, nagy bajban leszel. (Ld. még "Backupoltál ma este, Desdemona?") kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: titkositott particio tapasztalatok
On 08/02/2017 05:54 PM, Zsolt Gádori wrote: > Azt szeretném megkérdezni, hogy: > -érdemes-e a rendszer partíciókat is titkosítani, vagy elég csak a userekét? > -egyáltalán, melyik partíciókat érdemes titkosítani? "Érdemes"??? De jó szó! Ki tudja mit értesz ez alatt? :-) Próbáld megfogalmazni, hogy milyen célt akarsz elérni, és mennyi áldozatot vagy hajlandó hozni érte. Akkor lehet belemenni ilyesmibe. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fali rack szekrény
On 06/01/2017 10:10 AM, Móczik Gábor wrote: > Egy tipikus(an szar) falba egy 8-as tiplivel gyakran még egy virágtartót > se lehet felrakni. A bojlert üresen se tennéd fel két 8-as tiplivel, nem? > > A problémát az okozza, hogy az a kötőelem erre a célra nem megfelelő. > Ha a szekrény szerkezetileg egyébként elbírja a terhet a felfogatási > pontokon, akkor átmenő csavart kell használni, betonba dübelt, > befalazott kötést, stb., és máris nem kerül börtönbe senki. > A nem jellemző, az nem jelenti azt, hogy tilos használni, ugyanabban az > irodaházban a klíma is fent van a falon valahogy... Értem én hogy _te_ érted, mi a műszaki követelmény. Csak abban nem vagyok biztos, hogy érted-e, hogy egy irodaházi mindenes esetleg nem úgy gondolkodik, mint te. A bojlert nem ő szereli és nem az irodába. Ellenben az irodában szempont, hogy az egyik bérlő szobájából ne menjen át 3-4 M12-es vasrúd a másik bérlőhöz. Emiatt esetleg hajlamos a műszaki megfontolásokat mellőzni. Szóval az emberek hibáznak. Meg a gipszkarton fal is. Ha dobozgyártóként nyugodtan akarok aludni, a profit 150%-át felelősségelhárító jogászokra kell költenem. Megéri? Szóval ez az elméletem arról, miért van itt egy piaci résnek látszó valami. :-) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fali rack szekrény
On 05/28/2017 11:12 PM, Móczik Gábor wrote: > 2017.05.24. 9:39 keltezéssel, Kiss Gabor írta: >>> Gyanúm szerint nem :( >>> Viszont nem találtam olyan fali rackszekrényt, amibe ez az állat >>> belemenne. >>> Figyelmetlen vagyok, vagy itt a nagy piaci rés és gazdag leszek? :D >> >> Vagy sittre kerülsz. :-) >> Egy 80 centire kilógó, alacsony szekrényt nehezen lehet biztonságosan >> felszerelni a falra. Egyszer szakadjon csak rá valakire...! > > Bullshit. > 120 literes boylert fel lehet? Hevenyészett modell: Legyen az alsó és felső csavarok távolsága h, a súlypont faltól vett távolsága d. A súly d/h-szorosa akarja kitépni a felső csavarokat a falból. A bojlernél a d/h cirka 0.4 lehet, és 10-12 mm-es, falon átmenő csavarokkal fogják fel a 140 kilót. Egy csavarra juthat úgy 28 kp szakítóerő. Legyen 30. A kis szekrényke esetén d/h sacimetria 1.2-1.5. Az is lehet úgy 50 kiló, tehát a csavarokat összesen mintegy 60-75 kp erő tépi ki a falból. Az irodaházban az átmenő csavar nem jellemző. Ehelyett a mesterek befúrnak két 8-as lyukat, tesznek bele műanyag tipliket és hatos pozdorjacsavarokat. A súrlódás tartja majd a helyén a terhet. (Erővel záró kötés, szemben a fenti alakkal záróval.) Na ez a miskulancia szakadhat ki ha pechje van valakinek. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fali rack szekrény
On 05/23/2017 03:43 PM, Hofferek Attila wrote: > az általában kapható > 600mm mélynek mondott rack szekrényekbe belefér egy hp proliant > dl180? Ami 3.45 inches x 17.64 inches x 28.23 inches (8.76 x 44.80 x > 71.71 cm) > > Gyanúm szerint nem :( > Viszont nem találtam olyan fali rackszekrényt, amibe ez az állat belemenne. > Figyelmetlen vagyok, vagy itt a nagy piaci rés és gazdag leszek? :D Vagy sittre kerülsz. :-) Egy 80 centire kilógó, alacsony szekrényt nehezen lehet biztonságosan felszerelni a falra. Egyszer szakadjon csak rá valakire...! kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: APC UPS
On 03/15/2017 05:12 PM, zamek42 wrote: > Probaltam az upssched.conf-ban: > > AT ONBATT apc@localhost EXECUTE shutdown > > ez a doksi szerint /bin/upssched-cmd-t hivna meg shutdown parameterrel. > > Oda ezt tettem: > case $1 in > upsgone) >logger -t upssched-cmd "The UPS has been gone for awhile" > ;; >shutdown) > logger -t upssched-cmd "System shutdown started" > shutdown -h now > ;; > *) > logger -t upssched-cmd "Unrecognized command: $1" > ;; > esac > > A logban viszont csak ez jelenik meg, ha kihuzom a csatlakozot: > > Mar 15 17:07:01 organ upsmon[543]: UPS apc@localhost on battery > Mar 15 17:07:11 organ upsmon[543]: UPS apc@localhost on line power > > Szoval csoborbol vodorbe? Ha nem akarsz naphosszat szórakozni vele, akkor strace. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: erősen offtopic atmel-ice - linux kérdés
On 10/31/2016 09:18 AM, Zsolt Gádori wrote: > Elnézést, hogy itt ezzel jövök, de más ötletem nincs, hogy hol találhatnék > ezzel > kapcsolatos tapasztalatot. Az Elektro levelezési listán. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Stream check
On 10/25/2016 10:08 AM, Szima Gábor wrote: > Olyan parancsot keresek, amely pipe-on keresztül HASH/CRC-t generál az > adatfolyamról és azt annak a végére teszi, echo -n lo | tee >(sha1sum|cut -f1 -d' ') > illetve ugyanez fordítva is > megy: leellenőrzi, hogy jó-e az adatfolyam. Kb. ugyanaz, mint mondjuk a Akkor már jobb, ha írsz egy kurta perl scriptet. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ulimit ubuntun
On 10/10/2016 07:31 PM, Magosányi, Árpád wrote: > Az a gyanúm, hogy az upgrade ezt felül fogja vágni, azt meg biztosan nem > fogja tudni, hogy mire neveztem át az eredeti binárist. Nem a konkrét esetre mondom, de amikor meg akarom előzni, hogy mindenféle okos gyári programok felülírják a beállításaimat, akkor a "chattr +i " igen hatásos tud lenni. :-) kissg -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ 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
On 09/20/2016 03:51 PM, Kovács Géza wrote: > Ezt a kis shell-scriptet, ami normálisan le is fut és amíg le nem > futott, a rendszer nem áll le, megírod? Ez nem a linux-kezdő lista. kissg _ 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
On 09/20/2016 02:25 PM, Kovács Géza wrote: > A rendszer indításakor és leállításakor is fusson le a: > grub-install --force /dev/sda2 > parancs, ehhez mit és hogy kell editálni? A legjobb talán egy init scriptet csinálni, és belinkelni a megfelelő /etc/rc*.d/ directory-kba a megfelelő néven. kissg -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ 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?
On 08/20/2016 07:42 PM, Kovács Géza wrote: > Érdekelne ha valakinek van tapasztalata. Szerintem csalódni fogsz, ha ragaszkodsz a Gnome-hoz. Nem véletlenül adnak defaultban mindenféle pehelysúlyú desktop managereket a Raspbianhoz. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: revoke key
On 06/29/2016 09:11 AM, Lajber Zoltan wrote: > On Wed, 29 Jun 2016, Kiss Gabor wrote: > >> Ha létezik "biztos hely", akkor miért ne magát a titkos >> kulcsot tárolná ott? :-) > > Egyik biztos helyen a privat kulcs, másik biztos helyen a revoke key > szerintem jó ötlet. Mennyivel jobb, mint egyik biztos helyen a privát kulcs és a másikon is.? :-) Lássunk már végre egy kockázatelemzést, ne csak a megérzéseket! (Éppensgel tudnék érvelni a ti változatotok mellett is, de most arra vagyok kíváncsi, hogy a _ti_ fejetekben mi jár.) Mellesleg egy gyakorlati tanács annak, aki időtálló módon akarja tárolni a kulcsát: http://www.jabberwocky.com/software/paperkey/ kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: revoke key
On 06/28/2016 09:46 PM, Ferenc Wágner wrote: > készíteni. Ha nem készítetted el előre, akkor most kell előásnod a régi > kulcsodat. Egyébként javasolt új kulcs készítésekor rögtön visszavonó > tanúsítványt is készíteni hozzá, és eltenni biztos helyre, hogy ne > legyél bajban, ha elveszíted a privát kulcsod. Ha létezik "biztos hely", akkor miért ne magát a titkos kulcsot tárolná ott? :-) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
icedove meghibbant
Mióta a Debianban ismét firefox-nak híjják az iceweaselt, azóta az icedove figyelmen kívül hagyva a konfigját, erőszakkal firefox-esr nevű böngészőt indít, ha egy linkre kattintok. Nálatok mi a helyzet ezzel? kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Távszamba
On 05/02/2016 06:40 PM, Hofferek Attila wrote: > Olyan nem játszik hogy gdrive vagy dropbox? Abban nekem mi is lenne a szerepem? g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Távszamba
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...? kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Szaggat a video
Youtube, indavideo stb. filmlejátszás. Full screenben villog, csíkos a kép. Kivéve, ha folyamatosan mozgatom a pointert. (Értsd: interruptokat generálok.) Akkor ugyanis tökéletes a képminőség. HD-ben is. (Tehát nem a hálózati sávszélességgel van a baj.) Ki látott már ilyet? :-o kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ssh izé
On 03/22/2016 02:38 PM, Hegedüs Ervin wrote: >> Hogy is hívják azt a démont, aminek az a dolga, hogy ssh kapcsolatokat >> tartson életben? Ha kihal az sshd, újraindítja. > > autossh? Az, az! Kösz! Közben megtaláltam én is. :) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
ssh izé
Hogy is hívják azt a démont, aminek az a dolga, hogy ssh kapcsolatokat tartson életben? Ha kihal az sshd, újraindítja. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: melyik poolbol melyik csomag?
On 02/26/2016 09:45 AM, Kosa Attila wrote: > Miutan leirtam az alabbiakat egy korabbi levelben? :) > >> Azt nem tudom, hogy aptitude (vagy egyeb csomagkezelo) eseten mi >> a helyzet, mert azokat nem hasznalom. Elfelejtettem. Bocsánat! g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: melyik poolbol melyik csomag?
On 02/26/2016 09:24 AM, Kosa Attila wrote: > On Fri, Feb 26, 2016 at 09:21:25AM +0100, Kiss Gabor wrote: >> On 02/26/2016 09:05 AM, Kosa Attila wrote: >>> Akkor van egyaltalan lehetoseg megtudni azt, honnan telepul_tek_ >>> a csomagok? >> >> A logokból? > > Melyik logokbol? A /var/log/apt konyvtarban levo histoy.log es /var/log/aptitude.log. Már ha konzekvensen azt használod. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: melyik poolbol melyik csomag?
On 02/26/2016 09:05 AM, Kosa Attila wrote: > Akkor van egyaltalan lehetoseg megtudni azt, honnan telepul_tek_ > a csomagok? A logokból? g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: melyik poolbol melyik csomag?
On 02/16/2016 11:30 AM, Kosa Attila wrote: > Debian, a /etc/apt/sources.list fajlban felsorolva a pool-ok. Mi > a legegyszerubb megoldas arra, hogy megtudjam, a rendszerre > telepitett csomagok melyik pool-bol telepultek? Az apt-cache policy CSOMAGNEVE is érdekes lehet. Bár annak fő funkciója a jóslás. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On 02/03/2016 07:11 PM, Szokovacs Robert wrote: > On 02/03/2016 04:18 PM, Kiss Gabor wrote: >> De én inkább periodikusan futtatnék egy >> "convert x: /var/www/screenshot.png" >> parancsot lokálisan, és hagynám, hogy akit illet elvigye a képet. > > ez nekem klikkentesre var Ó! Igaz. Bocs! import -window root MyScreenshot2.png (http://tips.webdesign10.com/how-to-take-a-screenshot-on-ubuntu-linux) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On 02/03/2016 05:06 PM, Szima Gábor wrote: >> Oké, de az X szerver process mégiscsak valakinek a nevében fut. > > inittab/systemd -ből indul, nincs semmi login, no kbd, nincs display > manager, csak pucér X. Erre dolgozik rá egy daemon szintén inittab-ból, > amely xv porton keresztül pakolgatja fel az infókat innen-onnan (video, > képek file-ból, info szöveg UDP-n, stb.) > > Kb. ez történik: > X :0 & A szó, amit keresel a "root". :-) > sleep 5 > export DISPLAY=:0 (while true; do sleep 60; convert x: /var/www/screenshot.png) & > mplayer ... kissg -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On 02/03/2016 01:08 PM, Szima Gábor wrote: >> bizonyos képernyőiről >> szeretnél rendszeresen képeket gyűjteni az előtte ülő user >> folytatólagos közreműködése nélkül. Ez a feladat? > > Igen, csak nincs előtte user... Mondjuk úgy, hogy ipari kivetítő, amit > sokezren látnak. Oké, de az X szerver process mégiscsak valakinek a nevében fut. Ha az illető "user" kikapcsolja az X védelmi mechanizmusait, akkor alighanem megoldható a dolog. (Esetleg azon az áron, hogy a kamcsatkai halászok is el tudnak indítani programokat, melyek erre a display-re dolgoznak. :-) Ld. xhost(1) De én inkább periodikusan futtatnék egy "convert x: /var/www/screenshot.png" parancsot lokálisan, és hagynám, hogy akit illet elvigye a képet. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: screenshotd
On 02/03/2016 10:23 AM, Szima Gábor wrote: > Létezik X alá olyan screenshot app, amivel több gép képernyőképeit lövi > adott időnként, Pardon??? Itt valami koncepcionális félreértést látok. Kezdjük ott, hogy a "képernyőkép" nem géphez tartozik, hanem X szerverhez. Amiből egy hardveren akár több is lehet. Például két fizikai és három VNC-s. Ebben az esetben mit is szeretnél lelopni? Az X szerver lehet dedikált vas is. "X terminál a neve", nincs operációs rendszere. https://en.wikipedia.org/wiki/X_terminal Ez biztos nem fog együttműködni veled. Szóval oda akarok kilyukadni, hogy amit szeretnél, annak nem sok köze van az X-hez. Ha jól sejtem, bizonyos operációs rendszerű gépek bizonyos képernyőiről szeretnél rendszeresen képeket gyűjteni az előtte ülő user folytatólagos közreműködése nélkül. Ez a feladat? Ez minden cracker álma. :-) Mármint a delikvens tudta és engedélye nélkül screenshotokat lopni. És lássuk be, ez ellen kézzel-lábbal védekeznek a userek. Miért is kell ez neked? Fejtsd ki, kérlek! kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Aptitude adatbázis: hol?
On 01/27/2016 01:36 PM, Kiss Gabor wrote: > Már fél napom elment vele. Keresem, hogy hol tárolja az aptitude, > hogy melyik volt az automatikusan felrakott csomag. Sehol. Ez a libapt-pkg dolga, nem aptitude-specifikus. Az apt-mark program kell nekem! :-) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Aptitude adatbázis: hol?
On 01/27/2016 01:39 PM, Kosa Attila wrote: >> A végcél: át akarom vinni ezeket az információkat is egyik gépről >> a másikra. Dumpolva is jó lenne, de azt sem tudja a program. > A dpkg --get-selections / --set-selections nem jo? Nem. Az csak annyit mond, hogy installálva van-e. Azt nem, hogy miért. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Aptitude adatbázis: hol?
Már fél napom elment vele. Keresem, hogy hol tárolja az aptitude, hogy melyik volt az automatikusan felrakott csomag. Doksikat olvasok, a forrást bogarászom (nem nagy meggyőződéssel), strace-szel nézem, mit nyit meg. Eddig semmi eredmény. A kezdetben nagyon ígéretesnek tűnő /var/lib/aptitude/pkgstates csalódás. Nem változik, hiába váltogatom egy random csomag flagjét a programmal. A végcél: át akarom vinni ezeket az információkat is egyik gépről a másikra. Dumpolva is jó lenne, de azt sem tudja a program. Van ötletetek? kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: mappaszinkronizálás mivel gyors?
On 01/23/2016 04:19 AM, Géza Kovacs Géza wrote: > Esetleg a rsync-et paramétereztem rosszul? Meglehet. (Nem írtad ide a parancssort.) Vannak olyan kapcsolói, amivel kényszeríteni lehet, hogy olvassa végig a file-okat, hogy így döntse el, változott-e valami. Ld. -I. De szerintem nálad a lassú diszk elérés okozza a problémát. Nem lehet gyorsabb az rsync felderítési fázisa, mint amennyi idő a find parancsnak kell, hogy bejárja a fát. Futtasd az utóbbit, és mérd az idejét. Az rsync akkor hatékony, ha a hálózat relatíve lassú. Intenzív helyi feldolgozással éri el, hogy kevés adatot kelljen átküldeni a dróton. De ha a processzor és a diszk is lassú, akkor meg vagy lőve. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
On 01/22/2016 06:20 PM, Volarics István wrote: > A VG szabad helyén csinálsz egy LV-t azt ezt telenyomod > dd if=/dev/random of=/dev/vg/lv > és ha végzett letörlöd az LV-t és így amíg új PV-t nem raksz be > nem is kell foglalkoznod a dologgal. Na, mivel már sokadszor kerül szóba: A /dev/random lassú. Onnan kiolvasni sok száz gigát nem hatékony. Ehelyett választ az ember egy random kulcsot, azzal titkosítja a /dev/null-t a teleszemetelendő diszkterületre. Ld. http://loop-aes.sourceforge.net/loop-AES.README g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
On 01/22/2016 04:53 PM, Keller Viktor wrote: >>> Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után >>> dd-vel telirakni a titkosított kötetet egy óriásfile segítségével, >>> amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés >> >> -> Known plaintext attack >> (Ismerem az óriásfile-t, ismerem a titkos leképzését. Minél hosszabb >> a file, annál könnyebb kitalálni a kulcsot.) > > OK, ezt értem, és jogos (mondjuk miután a listán feldobtam, olyan > lenne, ha ilyet csinálok, mint pin kódnak az 1234). Akkor vegye a dd > /dev/zero helyett a véletlenszám generátorról a bemenetét. Akkor is? Akkor nincs semmi gond. Szokták is. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
On 01/22/2016 10:42 AM, Keller Viktor wrote: > Zs írta (2016. január 22. 0:41): >> 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ő!!! > > Csak kíváncsiságból, a partvonalról kérdem, hogy a méretnövelés után > dd-vel telirakni a titkosított kötetet egy óriásfile segítségével, > amit rögtön le is töröl, miben hoz eltérő eredményt? Az öntökönlövés -> Known plaintext attack (Ismerem az óriásfile-t, ismerem a titkos leképzését. Minél hosszabb a file, annál könnyebb kitalálni a kulcsot.) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
On 01/22/2016 09:56 AM, Kosa Attila wrote: > On Thu, Jan 21, 2016 at 04:30:03PM +0100, Kiss Gabor wrote: >> On 01/21/2016 03:28 PM, Kosa Attila wrote: >>> 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? Blokkokat másol. Függetlenül a tartalmuktól. Az LVM csak azt tartja nyilván, hogy melyik blokkba írtál a snapshot után, az nem érdekli, hogy mit. A titkosítási réteg efelett van. Azon meg a filesystem. Összefoglalva: igen, nyugodj meg! :-) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
On 01/22/2016 12:41 AM, Zs wrote: > 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ő!!! Biztonságosabb, ha az LV növelése _előtt_ maszatoljuk össze az összes szabad helyet a diszken, és csak utána engedjük rá a titkosítást. Akkor nem festhetjük ki az elő filesystemeket. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: fajlrendszer titkositas
On 01/21/2016 03:28 PM, Kosa Attila wrote: > 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. Tizensok éve a loop-aes a kedvencem, de már kivették a Debianból. A dm-cryptnek van kompatibilis üzemmódja, bár nem annyira kényelmes. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: hp m2727nf + pdf 1.5
On 01/13/2016 12:50 PM, Kosa Attila wrote: > Hogy lehetne rajonni, hogy mi es miert hasal el? strace. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: USB mobil rack probléma Linux alatt
On 12/30/2015 04:53 AM, Géza Kovacs Géza wrote: > A nobarrier csatolási opcióval történő csatolás úgy tűnik működik: > ilyen módon nem rontja el a fájlrendszert. > Nem tudom, hogy érdemes -e így használni vagy mindenképp meg kellene > oldani a problémát, mert ha fontos adatokat mentek rá és egyszer > elfelejtem csatolni nobarrier opcióval, úgy elrontja, hogy Más filesystem nem jöhet szóba? Legalább egy teszt erejéig. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: A Sendmail nem írja át a címet
On 11/19/2015 10:35 AM, Ferenc Wagner wrote: >> Az elrohan a lilára, de az envelope headerben nem az áll, hogy > > Mi az a "lila", és mi az az "envelop header"? Azért lila, mert háromszor írtam át a levelet, hogy olvasmányos legyen. Az első változatban még színek jelölték a gépeket. Ez úgy látszik bent maradt. Igen. Azt is elírtam. Envelope addressee akart lenni. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: A Sendmail nem írja át a címet
On 11/19/2015 09:56 AM, Kiss Gabor wrote: > Adott egy host (mondjuk beteg.example.com), RHEL5 van rajta. > Sendmail 8.13.8 az MTA-ja. > az MTA adott. Magamtól is lecserélném, ha lehetne. Mégis kaptam engedélyt az MTA cseréjére! :-) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
A Sendmail nem írja át a címet
Adott egy host (mondjuk beteg.example.com), RHEL5 van rajta. Sendmail 8.13.8 az MTA-ja. Be van állítva a /etc/aliases file-ban, hogy a root levelei a címre menjenek. Valamint, hogy minden kimenő levél egy smarthost, a kijarat.example.com felé menjen. (Szintén Sendmail.) A betegen keletkezik egy levél, címzettje a root. Az elrohan a lilára, de az envelope headerben nem az áll, hogy , hanem az, hogy [1]. Meglepő módon[2] a kijarat ennek ellenére továbbküldi a gonoszra. Az persze röhögve visszapattintja. Na ezek miatt nézek, mint Misi a moziban. :-( Mit nézzek meg? Hol debugoljak? Hálás lennék egy jó iránymutatásért. A 90-es évek közepe óta nem foglalkoztam Sendmaillel. [1] minden log, trace és a tcpdump szerint is. [2] pedig amúgy a "sendmail -bt"-nek adott "3,0 r...@beteg.example.com" szerint visszafelé kellene mennie a betegre. De lehet, hogy nem veszek figyelembe valamit. Ha szabadna megjegyeznem annyit, hogy a peremfeltételek adottak. Az itt leírt környezetben az itt leírt probléma megoldásához keresek segítséget. Hagyjuk most azokat a tanácsokat, amelyek a környezet megváltoztatására irányulnak! Az op. rendszer adott, az MTA adott. Magamtól is lecserélném, ha lehetne. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: parancsok megjegyzése
On 10/30/2015 01:56 PM, Gábor Kovács wrote: > Az lenne a feladatom, hogy naplózzak minden parancssorból kiadott parancsot. Best effort jelleggel, vagy a user akarata ellenére is? (Merthogy minimális erőfeszítéssel kijátszható a legtöbb ilyen intézkedés.) kissg -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: root csere boot kozben
On 09/29/2015 11:32 AM, Zana János wrote:
> Nos ez áll a gub.conf-ban:
> menuentry 'Debian GNU/Linux, Linux 3.2.0-4-686-pae verzióval' --class
> debian --class gnu-linux --class gnu --class os {
> load_video
> insmod gzio
> insmod part_msdos
> insmod ext2
> set root='(hd0,msdos5)' <<<- ?
> Ugye, amit fent jelöltem, nem kell átírnom?Üdv, János
A /boot/grub/device.map file-ban az van, ami neked kell?
g
_
linux lista - linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux
Második cím
Van két gépem, tűzfalak. Hol az egyik, hol a másik visel négy floating address-t. Most kissé át kellett alakítanom őket. Megcsináltam az egyiken a policy based routing újabb fejezetét. Minden zúg-búg, csörög-csattog. Ugyanazokat a változtatásokat végrehajtottam a tartalékon is. Aztán szóltam nekik, hogy csere. Az egyik elhajította a lebegő címeket, a másik felvette. Igen ám, de hiába mutatta az "ip addr" parancs, hogy ketteske eth0.87 interfésze megkapta az 128.66.145.105 másodlagos címet az 128.66.145.106 mellé, a gép valamiért nem jött rá, hogy a 105 helyben van, és elkezdett ARP requesteket küldeni a hálózatra: 14:00:41.022458 arp who-has 128.66.145.105 tell 128.66.145.106 Túl sokáig nem hagyhattam ebben az állapotban, mert élesben megy minden. Visszaváltottam az első gépre. A kérdés: ugyan mit nézhettem el? (RHEL 5.6 vagy ilyesmi van rajtuk.) Arra gyanakszom, mégsem sikerült egyformára konfigurálni őket. Mondjuk ha az lenne a feladat, hogy ilyen szituációt idézzek elő, nem tudnék hozzákezdeni. :-) Néha egy-egy percre átkapcsolva ketteskére milyen ügyes kis teszteket lenne érdemes elvégezni, amelyek leleplezik a problémát? Lehet a 2.6.18-238.el5 kernel is szar, de bootolni csak a legvégső esetben bootolnék. Mondjatok okosakat! :-) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Mark és IPv6
On 09/01/2015 04:22 PM, Kiss Gabor wrote:> > Elképzelhető, hogy ez nem működik IPv6-on? > > -A PREROUTING --jump MARK --set-mark 3 > > Utána logolom a csomagokat, és csak IPv4-en írja, hogy MARK=0x3, > IPv6-on semmit. Na, most már vannak MARK= szavak a logban. Nem tudom mitől. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Mark és IPv6
Elképzelhető, hogy ez nem működik IPv6-on? -A PREROUTING --jump MARK --set-mark 3 Utána logolom a csomagokat, és csak IPv4-en írja, hogy MARK=0x3, IPv6-on semmit. Pedig a Red Hat saját manuáljában rengeteg hasonló példa van. Esetleg csak be kellene töltenem egy modult? # lsmod | grep -i mark xt_MARK 1057 4 xt_mark 1057 4 xt_CONNMARK 1507 6 nf_conntrack 79758 9 xt_helper,ipt_MASQUERADE,iptable_nat,nf_nat,xt_CONNMARK,nf_conntrack_tftp,nf_conntrack_ipv4,nf_conntrack_ipv6,xt_state # A kernel verziója 2.6.32-431.el6.x86_64. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: root csere boot kozben
On 08/26/2015 11:12 AM, dr Zana János wrote: > 2015.08.26. 9:34 keltezéssel, Kiss Gabor írta: >> >> https://wiki.centos.org/HowTos/GrubInstallation >> >> g > Ebben ez áll: > 4 title CentOS 5.6 i686 > 5 root (hd0,5) > 6 kernel /boot/vmlinuz-2.6.18-238.19.1.el5.centos.plusPAE ro > root=/dev/sda6 rhgb noquiet > 7 initrd /boot/initrd-2.6.18-238.19.1.el5.centos.plusPAE.img Ne ezt olvasd, hanem ami a mapelésről szól! g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: root csere boot kozben
On 08/25/2015 06:55 PM, dr Zana János wrote: > # cat /boot/grub/device.map > (hd0) /dev/disk/by-id/ata-SAMSUNG_HD252HJ_S17HJ9DQ817645 http://askubuntu.com/questions/484042/boot-grub-device-map-is-missing-on-ubuntu-14-04 https://wiki.centos.org/HowTos/GrubInstallation https://www.suse.com/documentation/sles11/book_sle_admin/data/sec_grub_basic.html#sec_grub_map g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: root csere boot kozben
On 08/25/2015 01:25 PM, Attila Rajmund Nohl wrote: > 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? Nem a mountolással volt baja, hanem a kernelfrissítéssel. (Gondolom a grub-install ordított, szállt el, festett ki valamit.) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/11/2015 09:45 PM, Gabor Gombas wrote: >> Ilyesmi nem jöhet szóba, mert ezek a HP gépek 300 km-re vannak tõlem. > > Na nezzuk, ez elmegy-e... > > Szoval, ha HP, akkor google: hp linux hprcu > Te vagy az ász! :-) Köszönöm! http://h20564.www2.hp.com/hpsc/doc/public/display?docId=emr_na-c03323813 kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/10/2015 10:16 PM, Benák István wrote: > Kiss G.: javaslom 100 gép esetén ülj autóba kényelmesen utazz el a > célállomásra és kérj el érte 100 * X forintot + utiköltséget. Ráment egy > 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 végig kell nyomkodni a gombokat a helyszínen is, és kivárni a boot folyamat egyes fázisait. Sőt! Mivel Pesten ülve egyszerre négy gépet piszkáltam négy terminálablakból. A nettó idő 60%-t megspóroltam. b) A helyszínen nem is lehet hozzáférni a VGA és USB csatlakozókhoz, mivel ezekhez egy ilyen farkinca kellene: http://www.amazon.com/gp/offer-listing/B002FRHMW0/ref=olp_tab_all/180-6866546-0418101 De a HP Magyarország álláspontja szerint ez nem tartozéka a sok száz millióért beszerzett szupergépeknek. (Pesten is van egy kisebb.) c) Havi fixért vagyok alkalmazva, és legfeljebb az adózott fizetésemből finanszírozhatnék meg egy ilyen kétnapos vasúti kirándulást Debrecenbe a szabadságom terhére. És nincs ínyemre a dolog. > 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 > 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.) Kérlek, fiúk! Bízzatok bennem annyira, hogy elhiszitek, ha nem is evidens mit miért kérdezek, azért annak komoly oka van és nem csak ugráltatom a társaságot! Talán le tudom szűrni a probléma esszenciáját, és nem kell Ádámtól-Évától kezdve beszámolnom róla, hogy mit csinálok éppen, hogy utána minden mellékvágányon és zsákutcán magatok is végigrohangáljatok. kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/09/2015 03:52 PM, Ferenc Wagner wrote: > Én a tevés könyv sarkának alkalmas elhelyezésével próbálkoznék először. Most vettem meg a negyedik kiadást. 1130 oldal, és igen súlyos... :-) >> 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? > > Idézlek: "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?" > Ehhez adtam egy ötletet. Hát jó. Igazad van. Rosszul kérdeztem. :-( g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/09/2015 03:29 PM, PÁSZTOR György wrote: >> 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. Nincs. > >> 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) Az egész beszélgetés irreleváns. Mondtam: a feladat az NVRAM manipulálása programból, amivel ki tudom váltani azt az időigényes munkát, amit láthatóan mindannyian mégiscsak el akartok végeztetni velem, még ha ilyen-olyan, gyorsítónak szánt turbóötletekkel is. :-) >> Bocs, de egy másik feladatot akarsz/akartok megoldani, mint amit >> megkérdeztem. :-) > > Nem. Ő / mi a problémát megoldani segítünk Nem bíztok bennem annyira, hogy tudom miben kérlek segítséget és miben nem? :-) >> 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. Igen. Csak az egyszerűség kedvéért hívtam így. > Hmm... Amik magadtól is eszedbe kellettek volna, hogy jussanak, mint > releváns infók a probléma szempontjából: 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. 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. Erre van szükségem. Pont. Nem érdekelnek az interaktivitás felőli megközelítések. (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.) Gábor _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/09/2015 02:11 PM, Ferenc Wagner wrote: >> Hangsúlyozom: a management kártyának (=iLO) nincs semmilyen közvetlen >> befolyása az NVRAM tartalmára. Mégis hogy képzelted? :-o > > Belépsz az összes iLO-ra egyszerre clusterssh-val, kiadod a TEXTCONS > parancsot, Hopp, hopp! ne siessünk! Részletezzük csak ezt a néhány másodpercet! 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.) > 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? :-) 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.) > 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. :-) 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? kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/08/2015 08:36 PM, PÁSZTOR György wrote: > 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! ;-) Félek eltévesztetted az "ortodox" szó jelentését. :-)) A válasz: nem, ez egyáltalán nem ortodox. És magával vonná a jótállás azonnali elvesztését, meg egy pár Budapest-Debrecen utat. :-( Amúgy sem világos, hogy mit segítene ez a setupon. Kizárva. g -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/08/2015 09:33 PM, Ferenc Wagner wrote: >> De mit segít ez a scriptelésben? >> Pontosan azt akartam elkerülni, hogy mindegyiket kézzel setupoljam. > > Nyomulj clusterssh-val az iLO-kra, és akkor csinálhatod egyszerre az > összeset. Hangsúlyozom: a management kártyának (=iLO) nincs semmilyen közvetlen befolyása az NVRAM tartalmára. Mégis hogy képzelted? :-o g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/08/2015 05:06 PM, Ferenc Wagner wrote: > Kiss Gabor writes: > >> Volna itt majdnem 100 egyforma gép, aminek a BIOS Setupját módosítani >> kellene. > > Nincs semmilyen konzol átirányítási lehetőség ezekben a BIOS-okban? > Serial over LAN, IPMI, bármi? Dehogynincs. TEXTCONS az iLO-ban. De mit segít ez a scriptelésben? Pontosan azt akartam elkerülni, hogy mindegyiket kézzel setupoljam. (De már hozzákezdtem. Négyesével. Kb. 10 percig tart egy turnus.) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: BIOS Setup
On 06/08/2015 04:50 PM, PÁSZTOR György wrote: > 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. Ilyesmi nem jöhet szóba, mert ezek a HP gépek 300 km-re vannak tõlem. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
BIOS Setup
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? kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: hálózat eltűnik
On 06/02/2015 10:53 AM, B. P. TBC wrote: > internet. Ugyanis a két hálókártya közül nem azt konfigoltam, amelyikbe > a kábel be volt dugva. Ajánlott irodalom: http://dawn.royalcomp.hu/~raas/lc.html :-) _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: hálózat eltűnik
On 05/29/2015 08:45 AM, B. P. TBC wrote: > Amikor nincs internet, a routeren a "link" led világít, de a 100MBPS már > nem. > Ebben a problémában kérném a segítségeteket! Esetleg az autonegotiation nem megy. Mit mond az "ethtool eth0"? g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: 852-es kódlap
On 05/14/2015 03:41 PM, Gábor Kovács wrote: >>> 852-es kódlapal készült programokat kell szerkesztenem és futtatnom. >> >> Milyen programnyelven írták ezeket? :-o > Ezek DataFlex források, örökségként hordozzák magukkal kiirthatatlanul > kódlapot és billentyűkombinációkat. Ebben a DataFlexben nem lehet átírni az ékezetes betűket szekvenciákká? (Mint pl. \x84) Mert akkor csak egyszer kellene konvertálni mindet, és az összes user tudná szerkeszteni. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: 852-es kódlap
On 05/13/2015 04:59 PM, Gábor Kovács wrote: > 852-es kódlapal készült programokat kell szerkesztenem és futtatnom. Milyen programnyelven írták ezeket? :-o g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: karaktertörlés Backspace delete billentyűkkel
On 05/12/2015 12:02 PM, Feil Ferenc wrote: > cygwint használok. "startx --" parancsal indítom az x szervert, rxvt-unicode > terminállal, bash shellel. Bejelentkezem távoli SGI irix 6.5 szervergépre, > ahol a delete és backspace billentyűket sehogy sem tudom rávenni hogy a ^H > karaktertörlésnek megfelelően funkcionáljon. > Tippet, segítséget megköszönök! stty(1) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ssl és name based virtual hosting
On 04/22/2015 12:23 PM, Sörös Zoltán wrote: > De bekonfiguráltam a 'fő' domainre a https-t, ennek mellékhatásaként ha > valaki https-en nézné valamelyik másik domaint, akkor kap egy > hibaüzenetet, hogy a tanusítvány másik domainre szól. > > Mivel a többi domainre nem kell https, gondoltam átirányítom őket a sima > http kapcsolatra - kérdés csak az, hogy hogyan? Attól tartok bárhogy is csinálod, a kliens már panaszkodni fog. Annak az információnak, hogy hol próbálkozzon újra a browser (ezt hívjuk átirányításnak, ugye) még az SSL kapcsolaton kell átmennie. A legolcsóbb megoldás: Két IP cím. Az egyiken a HTTP only szerverek laknak, a másikon amelyeknek korrekt tanúsítványa is van. A legkirályabb megoldás: IPv6 és mindenkinek saját cím. :-) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Strapabíró távolra logolás
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. :-) kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Bind hiba
On 02/26/2015 09:50 AM, Sörös Zoltán wrote: > Bónusz kérdés: Ha szeretném tűzfallal lezárni az 53-as bejövő portot, > hogy kívülről ne érjék el a namedünket, kiket kell kivételbe tenni, hogy > azért megtalálják a www.filmjus.hu -t? A T-online-nál van a másodlagos > szerverünk, gondolom ha az elsődlegest totál lezárom, akkor azon > megtalálnak minket, de ezt inkább csak végszükség esetén csinálnám. Ilyet ne tegyél! Ha egyszer bejelentetted, hogy X szerver szolgáltatja Y zónát, akkor be kell tartanod az ígéreted. (Vagy vond vissza!) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Embereket keresünk
Álláshirdetés itt: http://hup.hu/node/138495 g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: ext3 helyfoglalas furcsasag
On 11/04/2014 03:20 PM, Kosa Attila wrote: > Van egy gep, lvm-es ext3 particiokkal, vserverrel. A vserverben > ufs-kent latszik az egyebkent ext3-as particio, es ilyet > produkal: > Nem birok rajonni, hogy hogyan csinalja... Lehetseges lenne, hogy > valami fajlrendszer-serules okoz ilyet? Nem ismerem eléggé az ufs-t, ezért azt sem tartom kizártnak, hogy az okozza. Ki tudja milyen ott a garbage collection? g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: sed: line number beszuras
On 09/08/2014 11:49 AM, Pirity Tamas Gabor wrote: > cat -n nem jó? Miért akarod pont sed-del? Challenge. :-) Talán ez segít: https://www.gnu.org/software/sed/manual/html_node/cat-_002db.html g -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: EPERM: a hajam kihullik
On 03/17/2014 05:20 PM, elsik.ga...@on-line.hu wrote: > olyasmi, hogy apparmor nem kavar bele a dologba? nekem attól szokott De. Pont az volt. :-( Tegnap este egy kollégám kinyomozta. Kösz a segítséget a többieknek is! g -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: EPERM: a hajam kihullik
On 03/17/2014 02:26 PM, Laszlo Baranyai wrote: > > 2014-03-17 13:25 GMT+01:00 Kiss Gabor : >> Mar 17 13:03:30 service0 ntpd[6132]: getconfig: Couldn't open >> > > Nem kellene ntp csoporthoz tartozzon? > chown root:ntp /etc/ntp.conf.real Tudományos megfontolásból azt mondanám: nem. Világolvasható file. Eddig az ntp.conf pontosan ugyanilyen tulajdonossal, csoporttal, mode-dal nem okozott gondot az ntpd-nek. És az open() pillanatában még nem dobta el a privilégiumait a process. g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
EPERM: a hajam kihullik
Adott egy "SUSE Linux Enterprise Server 11 SP3 (x86_64)"
Bizonyos okokból -- és most ne azokat firtassuk, és ne
próbáljunk kerülőutat találni, mert ez már a kerülőút --
azt vettem a fejembe, hogy az ntpd ne a /etc/ntp.conf, hanem
a /etc/ntp.conf.real file-t tekintse konfigjának.
Az init scriptben át is írtam: NTP_CONF="/etc/ntp.conf.real"
A file létezik, olvasható:
# find /etc /var/lib -name '*ntp.conf*' -ls
46750974 -rw-r--r-- 1 root root 2408 Aug 25 2013
/etc/ntp.conf
46762364 -rw-r--r-- 1 root root 2155 Mar 17 12:34
/etc/ntp.conf.real
86769294 -rw-r- 1 root ntp 2028 May 8 2013
/var/lib/ntp/etc/ntp.conf.iburst
86783404 -rw-r--r-- 1 root root 2430 Jan 9 11:17
/var/lib/ntp/etc/ntp.conf
86767314 -rw-r--r-- 1 root root 2155 Mar 17 12:34
/var/lib/ntp/etc/ntp.conf.real
#
Az ntpd ugyan úgy van idomítva, hogy chrootoljon a /var/lib/ntp/-be,
de még mielőtt odáig jutna, megbotlik:
Mar 17 13:03:30 service0 ntpd[6132]: getconfig: Couldn't open
A strace ezt mutatja:
6132 open("/etc/ntp.conf.real", O_RDONLY) = -1 EACCES (Permission denied)
6132 write(2, "getconfig: Couldn't open http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: dynamic dns server ddclienthez
On 01/23/2014 09:49 AM, Thiering Péter wrote: > Sajnos a dyn.com-ra havonta be kell lépni, legutóbb két domainemet is > törölték, mert már figyelmeztető e-mailt sem kapok tőlük, úgyhogy > elvinném a saját szerveremre ezeket a szolgáltatásokat... Nekem ez bevált: http://www.dnsdynamic.org/ (Ha esetleg mégsem akarsz magadnak építeni.) g -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: bash ctrl+c gondok
On 10/27/2013 12:11 PM, Elsik Gábor wrote: Tortent egyszer, hogy lefrissitettem a linuxot, amitol a bash fogta magat es elkezdett eleg fura modon mukodni, pontosabban nem mukodni. Ha siman inditok egy terminalt X alatt, akkor a ^C es ^Z nem mukodik. Tippem szerint ez nem a bash problémája. Minden abból az ablakból indított programot érint. A termináldriver nyilván el van állítva. Raw mode-ban van cooked helyett, vagy csak a megfelelő signalokat generáló karakterek vannak elállítva. Ezzel vesd öszve az stty -a kimenetét: $ stty -a speed 38400 baud; rows 24; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8 opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke $ kissg _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Képméret
Még mindig a squeeze -> wheezy upgrade.
Az X szerver is másképp megy. Változataln xorg.conf mellett az eddigi
1920x1080-as natív felbontás helyett virtuális 2048x1080-as
screenem van, és most 128 pixelnyit jobbra balra csúszkál a kép,
ahogy a pointerrel kiérek a szélére.
Mondanom sem kell, az xorg.conf-ban nincs "Virtual 2048 1080" sor.
Nagyon bosszant a dolog. Miközben a jelek szerint mást nem,
mert a guggolizálás nem vezetett eredményre.
Mi lehet a tudományos magyarázat?
("nvidia" driver van "Onboard GeForce 6150 Video Card" device-hoz.)
kissg
_
linux lista - linux@mlf.linux.rulez.org
http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Kernelméret
On 05/23/2013 06:56 PM, SZÉKELYI Szabolcs wrote: Ajanlom figyelmedbe a kernel-package csomagot. Köszönöm. :-> Eddig eszerint haladtam: http://kernel-handbook.alioth.debian.org/ch-common-tasks.html 4.5 Building a custom kernel from Debian kernel source g -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
Re: Kernelméret
On Wed, 22 May 2013 21:45:39 +0200, Gábor Lénárt wrote: Nezd meg mi kerult belejuk. Pl objdump -h kernel/fs/binfmt_misc.ko vagy hasonlo, elso korben csak elf section header-ek stb. Hatha ranezesre latszik a tied es a distrib kozott hogy mi hol miert. Nyert! Mégis be volt ikszelve a CONFIG_DEBUG_KERNEL. :-) g _ linux lista - linux@mlf.linux.rulez.org http://mlf.linux.rulez.org/mailman/listinfo/linux
