A toolchain-t még nem kaptam meg hozzá, ezért próbáltam ki kíváncsiságból egy másik arm-gcc-vel. Ezért más valóban a két readelf kimenet (EABI/GNU EABI).

De ez megmagyarázhatja az eltérő magic numbert is?

[ Szerkesztve ]

Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!

cronból lefut egy shellscript, amiben az rsync SSH-n keresztül letölt pár fájlt. eddig szuper.
a scriptet a nobody futtatja, ami eddig működött is, most viszont futás helyett elhasal azzal, hogy

Could not create directory '/nonexistent/.ssh'.
Warning: Permanently added 'asdfasdfadsfa.com,78.xxx.xxx.xxx' (ECDSA) to the list of known hosts.

/nonexistent ugyebár a nobody home könyvtára Debian esetén, és persze, hogy nem létezik.

hiába mondom az SSH-nak, hogy hagyja a francba a .ssh könyvtárat, nem tudom ezt kiverni a fejéből.
rsync -riHvz --chmod=ugo=rwX -e "ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -i /home/stbstbstb" egyéb parancsok

[ Szerkesztve ]

Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data

Rendben, magic number probléma elhárítva! Ténylegesen a gcc okozta a galibát.

Most egy másik fw-vel próbálkozom, aminek az initrd fájlja 35,7 MB. Ezt kicsit nehézkes lenne a ramba tölteni, majd bootolni vele u-boot alól minden alkalommal... Fogtam, felcsatoltam, majd kibontottam a teszt pendriveom rootfs cimkéjű partíciójára. Viszont initrd nélkül nem tudom használni a root=LABEL=rootfs bootargs argumentumot... UUID alapján is próbáltam azonosítani, sajnos az sem ment. Hogyan tudnék initrd nélkül bootolni közvetlenül az USB HDD-mről?

Illetve megpróbáltam tömöríteni ezt a monstrumot. Egy cpio és egy gzip tömörítés után kaptam egy 8.8 MB-os fájlt. Faragtam belőle egy uInitrd-t, a szemlátomást betölti az u-boot rendben a fájlt. Csak a hiba továbbra is fennáll, innen gondolom, hogy valami mégsem jó...

Mit tudok tenni?

[ Szerkesztve ]

Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!

Üdv a szakiknak.

Több Debian8-ról és 1db Debian9-ről szeretnék egy távoli Debian8 gépre 1db titkosított állományt átvinni automatikusan. A titkosításra asszimetrikuskulcsokat használnék, openssl-el. (openssl új téma még számomra..) Az scp, vagy ssh kulcsos auth, stb most nem járható sajnos. Átviteli közeg csak FTP lehet.

Debian8 openssl 1.0.1t-1+deb8u7
Debian9 openssl 1.1.0f-3+deb9u1

A script: legyárt egy random 128 karakter hosszú kulcsot, valamint ezzel titkosítja a hasznos adatot, majd a másik oldal (fogadó) publikus kulcsával titkosítja a 128 karakteres kulcsot, és ezeket utaztatom..
/usr/bin/openssl rand -base64 128 -out key.bin
/usr/bin/openssl enc -aes-256-cbc -salt -in $DATA -out $DATA.enc -pass file:key.bin
/usr/bin/openssl rsautl -encrypt -inkey $PUBKEY -pubin -in key.bin -out key.bin.enc

Itt jegyezném meg, hogy ez a script szépen lefut Debian8 gépeken, Debian9-en viszont csak akkor megy, ha az első sorban az -out $KEY a rand után következik..

Szóval megvan a titkosított "kulcs" és a titkosított adat.

Fogadó oldalon így nyitom ki őket:
/usr/bin/openssl rsautl -decrypt -inkey $PUBKEY -in key.bin.enc -out key.bin
/usr/bin/openssl enc -d -aes-256-cbc -in $DATA.enc -out $DATA -pass file:key.bin

Debian8 alatt létrehozott adat szépen kinyílik, Debian9 alatt létrehozott adat kititkosítása ezzel a hibával száll el:
bad decrypt
3074016956:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:516:

Az openssl különbözősége az ok? Mit lehet tenni ilyenkor?

Köszönöm!
letix

[ Szerkesztve ]

don't panic! ... http://www.letix.hu - linux parancsok

Kipróbáltam, sajnos szimpla passphrase-el titkosítva (küldő-Debian9) sem nyitható ki a fogadó oldalon (Debian8), ugyanezzel a hibával.

Köszi!

don't panic! ... http://www.letix.hu - linux parancsok

Némi google után a megoldást (nem biztonságos!) megtaláltam
[link]

-md md5 kapcsoló a key.bin-el történő encrypt sor mögé.
Ahogy a fenti link is taglalja ez a digest nem biztonságos, ámbár működik. Kérdés hogy mekkora kockázatot rejt magában? Nem feltétlen szenzitív adatokat utaztatnék de még is jobb ha nem plaintext-ben menne/jönne.

Ötlet esetleg?
Köszi!

udv
letix

don't panic! ... http://www.letix.hu - linux parancsok

nekem a tbird azért hisztizett, mert túl rövid volt a kulcs.
próbáld ki az eredeti felállást úgy, hogy nem 128 karakteres kulcsot használsz, hanem 256-ot vagy 512-t.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Az md5 hashelesre valo, nem titkositasra.

https://www.coreinfinity.tech

Köszi, kipróbáltam 256, és 512-vel is, sajnos nem jött be.

Pontosítanék:
A titkosítás lefut ugyan a Debian9-en csak épp a 8-on nem tudok vele mit kezdeni..

[ Szerkesztve ]

don't panic! ... http://www.letix.hu - linux parancsok

Az asszimetrikus titkosítás még elég új dolog számomra, így el tudom ugyan olvasni amit írsz, de nem tudok vele mit kezdeni. . Van -md sha256 kapcsoló is, azzal sajnos nem működik. Mit tudok ezzel kezdeni, merre induljak?
Vagy lehet hogy nincs is a két különböző verziójú openssl között átjárhatóság?

Köszi
letix

don't panic! ... http://www.letix.hu - linux parancsok

Találtam egy md5-nél remélhetőleg jobb megoldást. Debian8-on az openssl.cnf-ben a digest md5, sha1.

Tehát küldő oldalon (Debian9) ha így titkosítok:
-md sha1

és fogadó oldalon (Debian8) így titkosítok ki, abban az esetben működik szépen.

Így jobb lehet a dolog?
Köszönöm

letix

don't panic! ... http://www.letix.hu - linux parancsok

Hash: a plain textbol csinalsz egy sornyi krixkraxot. A plain textet visszanyerni nem tudod. Tipikus pelda: passwordok.

Encryption: a plain textbol egy kulcs segitsegevel csinalsz krixkraxot. A kulcs segitsegevel visszanyerheto a plain text a krixkraxbol. Ennek van szimmetrikus es asszimetrikus valtozata. A szimmetrikusnal ugyanazt a kulcsot hasznalod a titkositasra, mint a decryptre es sokkal gyorsabb, mint az asszimetrikus megoldasok. Problema a kulcs disztributalasa (hogyan juttatod el a celrendszerre). Asszimetrikusnal kulon kulcs van a titkositasra (publikus kulcs) es a visszafejtesre (privat kulcs). Itt ugye nem kell foglalkoznod a kulcs disztibutalasaval, ellenben joval lassabb a szimmetrikus megoldasoknal.

Gondolom a celszerveren vissza akarod nyerni a plain adatot, ergo a hashing (mint pl. az md5) nem johet szoba.

Atjarhatosag altalaban lehetseges, ha nem valtoztatnak a hasznalt eljarason. Mivel a te eseted pont beleesik egy ilyen valtoztatasi ciklusba, ezert nem mukodik ugy, ahogy elvarod. Trivialis megoldaskent ugyanazt az openssl-t kellene hasznalnod mindket rendszeren.

https://www.coreinfinity.tech

Köszi a válaszod sh4d0w, így már sokkal világosabb a dolog mint ezelőtt
Olvasgattam a feladat előtt ugyan, de most már tényleg tisztább.

Közben megszületett a végleges megoldás, kíváncsi volnék a szakik véleményére.

Minden Debian8-on az openssl.cnf-ben a digest-hez felvettem az sha256-ot is az md5,sha1 mellé.

A titkosítást Debian verziótól függetlenül mindenhol -md sha256 kapcsolóval teszem meg, ami a 128 karakter hosszú "kulccsal" történő titkosítást illeti.
Ugyanilyen kapcsolóval titkosítom ki fogadó oldalon (Debian8-on) az imént leteszteltem, és szépen megy Debian8 és Debian9 küldőtől is.

Remélem így már a biztonságosabbnak mondható!

Köszönöm!
letix

[ Szerkesztve ]

don't panic! ... http://www.letix.hu - linux parancsok

Az md5 itt nyilvan nem azt jelenti, hogy hashelve megy at az adat, hanem ezzel az algoritmussal generaljak a kulcsot. de pl. digitalis alairasoknal is hasznalnak "cryptographic hash function"-t.

A SHA-1 ugyanolyan rossz, mint az MD5. Tavaly mar volt ra mukodo collision attack.
A sha256 OK.

Köszönöm az infót!

don't panic! ... http://www.letix.hu - linux parancsok

Sziasztok!

Egy minimális, Busybox alapú initrd ramdisket gyártok épp, melynek célja ténylegesen csak egy speciális eszköz rootfs-ének indítása lenne. Vagyis nem más, mint egy switch_root parancs futna le rajta.

A kernel támogatja az EXT2-t, illetve az USB-t is, viszont a device node-ok érthető módon nem jönnek létre, hiszen jóformán csak egy busyboxos bin mappám van, illetve a sys és proc fel van csatolva. Így viszont nem tudom a teszt pendriveom - melyen a rootfs van - azonosítani...

A findfs természetesen üres kimenettel tér vissza. Így csak egy rescue shell-t tudok indítani.

Hogy tudnám megoldani?

Szerk.:

Ez a parancs hibát dob egyébként:

mount -n -t devtmpfs devtmpfs /dev

[ Szerkesztve ]

Eleinte angol billentzuyetet akartam. De aztán megismerkedtem a nagy 'Ő'-vel!

Adott egy hdd amire kiadtam a
hdparm -S 120 /dev/sda
parancsot, hogy 10 perc semmittevés után kikapcsoljon. Hogyan tudom ellenőrizni, hogy valóban leáll?

Gép: Intel NUC i3, SSD és HDD.
Proxmox szerver az SSD-n. A rajta lévő 3 VM közül 1 használja a HDD-t. Debian- minidlna funkcióval.

hdparm -C ?

Vigyázat, csalok!

Sziasztok,

Live CD vagy USB stick-re telepített rendszer esetén ha a HDD-t titkosítom, totál értelmezhetetlen random lesz a rajta lévő anyag, az első pár bájttal együtt, vagy van valami header-je az ilyen partíciónak ?

Ha nincs header, ergo megállapíthatatlan avatatlan szemnek, mi van rajta, klassz.

Ha van header, lehetséges boot és a partíció feloldása/mount-olása után a header-t felülírni, miközben élesben megy a rendszer és a HDD mount-olva ? Szóval ha jön egy áramszünet, egy header nélküli random bájtos titkosított hdd-m legyen, aminek titkosított partícióját újra boot-olva tudom használni ismét, ha feloldás/mount-olás előtt a header-t helyreállítom (majd újra törlöm).

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Gentoo wiki, itt megtalalod a valaszt

Vigyázat, csalok!

A titkosítás az titkosítás, az mindegy, hogy Live rendszer alól csináltad, vagy USB-re vagy akármi másra telepített rendszernél.

Az avatatlan szemnek a header is „láthatatlan”, hiába van ott, ha csak egy átlagos particionálóprogrammal vagy Windowszal ránéz, annyit lát, hogy formázatlan RAW partíció, ha megnyitja hex-editorral, akkor meg csak random adathalmaz az egész. A nem avatatlan szem is csak annyit tud megállapítani a header alapján (mondjuk valami normálisabb linuxos particionálóprogi felismeri, hogy encrypted partition), hogy LUKS-szal titkosítottad, egészségére, nem fog vele sokra menni, nem hinném, hogy egyhamar megtörik.

Szóval, ha annyira akarod, akkor a Gentoo Wiki alapján csináld meg azt a detached headert, de nem látom sok értelmét. A tényleg szakavatott szem header nélkül is felismeri, hogy pseudo random adathalmazról van szó, és hogy emiatt titkosítás állhat mögötte, nem /dev/urand segítségével felülírás. Ez már a paranoiának egy teljesen értelmetlen szintje.

Esetleg egy fokkal lehet finomítani az elképzeléseden, nem partíciót titkosítasz, hanem partíción kívüli egész lemezt, ergo a lemezen nem lesz még partíciós tábla sem, meg a headert is eltünteted, akkor viszont tényleg tűnhet úgy, hogy valaki letörölte az egész drive-ot /dev/urand igénybevételével. Akkor aztán a particionálóprogik is úgy látják, hogy teljesen particionálatlan a lemez.

Ph-s palyafutasom soran ritkan talalkozok ennyire informativ, tiszta, vilagos es reszletes valasszal. Wow, kitisztult a kep, ez erdekelt pontosan. Koszonom !!

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Koszi ide is, rapezsgek.

Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Helló

Olvastam ezt a cikket: Is Linux Immune to Viruses?, és felvetődött bennem a kérdés, hogy valaki találkozott már ilyen incidenssel ?
Gyanítom átlagos használat mellett ígyse-úgyse "kapok el" semmit se.

változnak az idők, változnak a vírusok.

régen romboltak, ma sokkal inkább rejtőzködnek, hogy minél tovább használhassák saját disznóságaikhoz a te erőforrásaidat.

ha ezt tekinted definíciónak, hogy általad nem kívánt céllal általad nem kívánt kód fut, akkor igen, találkoztam ilyennel. ezek zömében olyan esetek voltak, amik vagy találékonyságból indultak ki (senki nem gondolta, hogy arra is jó), vagy emberi hanyagságból.

én klasszikus vírussal soha nem találkoztam linuxon.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Tehát olyan mint "vírusirtó" egyrészt feleslegesnek mondható átlag felhasználás mellett, másrészt meg a paranoia bizonyos felsőbb fokait már megüti ?

Én nagyon win-en se találkoztam vele (kopp kopp), persze nem is nagyon járkálok olyan helyen, ahol potenciálisan sz@rba nyomnám a kezem....

én abban látom a fő problémát, hogy ma már nem nagyon lehet megkülönböztetni a malware-t a rendes programtól oprendszer szinten. te, mint vírusirtó, hogy döntöd el, hogy az a levél, ami épp kifelé megy a gépedről, az szándékosan küldött levél, vagy az akaratod ellenére kiküldött spam? ugyanígy, hogy döntöd el, hogy az a dns rezolválási kérelem, amit kitol a géped, miattad van, vagy egy botnet miatt?

sehogy. ugyanazokat az oprendszer szolgáltatásokat veszi igénybe az általad direkt elindított levelező program is, mint egy vírus. ugyanúgy nem tudod eldönteni, hogy most azért nyitotta meg egy program a gyereked fotóját, mert ki akarod venni a vörösszem effektust, vagy azért, mert le akarja kódolni váltságdíjért.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Köszi,
Egy kicsit trükközni kell.
A /home van a hdd-n így ahogy bejelentkezem egyből felpörög.
vsz írok egy scriptet ami időnként kiírja egy filebe az eredményt (cc 10 percenként)

Nem vagyok szakavatott a témában, meg ez inkább paraszti gondolkodás, de az nem lehet egy jó módszer rá, ha:

Return owner of process given PID - nem magát a felhasználó nevét kellene kikeresni, hanem magát az elindított folyamat szülőjét ?
Vagy itt nincs ilyen szülő-gyerek viszony a folyamatoknál ?

Arra gondolok, hogyha végignézzük ezt a kit ki hívott meg láncolatot, és ebbe van olyan amit felhasználó indított az oké, míg ami gyanúsan nélküle indult az meg "kuka" ?

Bár ez eleve már távol esik a kezdeti kérdésemtől, meg nem is biztos, hogy valid eszmefuttatás

Vannak elismert vírusírtók linuxra is, vagy a legtöbbje "garázsprojekt" ?
Esetleg van ennek szakirodalma, vagy fórumja ?

El kell felejteni legelsokent, hogy ha "megbizhato" oldalakon jarsz, akkor nem kapsz be semmit. Megbizhatonak tekintett site-okrol ugyanugy bekaphatod a malware-t, tehat a bongeszesi szokasok megvaltoztatasa nem ad semmit a vedelmedhez. (Hetkoznapi pelda: azzal, hogy nem mesz a varos rossz hiru negyedebe, meg csunyan helyben hagyhatnak a jonevu kornyeken is.)
Mi van akkor, ha a veled egy halozaton levo geprol fertozik meg a tiedet? Meg bongeszni sem kell hozza...

Linuxra egyebkent van clamav, de nem rezidens es leginkabb akkor lehet szukseged ilyesmire, ha ez egy szerver es Windows gepeknek nyujt szolgaltatasokat - ekkor sem a sajat vedelmeben van az AV, hanem hogy a Windows-ok egymast ne fertozzek ossze.

Linux alatt a kovetkezoket teheted az atlagos biztonsagi szint elereseert: stabil rendszert hasznalsz, amit frissen tartasz; nem veszel fel 3rd party repokat, vagy ha megis kell, akkor csak a minimalisan szuksegeset; nem rootkent hasznalod a rendszert; rendszeres backup a szamodra fontos dolgokrol (DVD, kulso HDD, akarmi).

Ha ennel emeltebb szintu biztonsagot akarsz, akkor teljes lemez titkositasa LUKS-szal vagy VeraCrypt kontenerek hasznalata; fail2ban, ha vmilyen szervert uzemeltetsz; ketfaktoros azonositas; HIDS/NIDS; online backup a kulso eszkozon kivul.

Aztan meg mindig lehet fokozni ezt egeszen addig, amig hasznalhatatlan lesz a cucc.

https://www.coreinfinity.tech

Abban egyetértünk, hogy megbízható oldalakon is meg lehet fertőződni Windows alatt. Ugyanis a legtöbb oldal igénybe vesz reklámszervereket, és oda tudnak a támadók rosszindulatú kódot injektálni, amire az oldal üzemeltetőjének nincs ráhatása, volt már párszor, hogy így egy csomó megbízható oldal terjesztett így ártalmas kódot. Itt nem csak arra kell gondolni, hogy valami összefertőzi a gépet, hanem mondjuk míg fut az aktuális oldal a böngészőben, addig a reklámszerverről letöltött cryptominer, coinminer script szépen dolgozgat a háttérben. Kárt nem okoz, leköt némi memóriát és prociidőt, az oldal bezárásával el is múlik, mégis olyan dolog futott le, aminek nem kellett volna.

Azzal viszont nem értek egyet, hogy a LUKS és egyéb titkosítás segít a malware-ek ellen. A biztonságot valóban növelik, mert fizikailag kizárják az illetékteleneket az adathozzáférésből, de mikor épp futnak, akkor az OS számára transzparensek, így pedig a malware szempontjából úgy látszik, mintha nem is lenne titkosítva.

En nem azt mondtam, hogy ved a malware-ektol, hanem azt, hogy egy emeltebb biztonsagi szint hasznalata eseten ajanlatos a hasznalata. Egyebkent meg van olyan scenario, ahol malware-ektol is megvedhet (pl. nem allandoan becsatolt lemezterulet/kontener).

https://www.coreinfinity.tech

"megbízható oldalakon is meg lehet fertőződni Windows alatt"

Nem csak windows alatt. Linux alatt is

You may corrupt the souls of men, but I am steel. I am doom.

Lehet igazad van, én nem láttam még olyat, hogy valaki Linuxon egy weboldal meglátogatása után megfertőződött volna. Max. csak lefagyott vagy crashelt a böngésző, de újraindítva a rendszert, semmi gubanc, ugyanis nem tudott az oldalon futó script sem a sandboxból kilépni, sem a rendszerbe beleirkálni. Amit eddig vírust Linuxon ismerek, azok mind olyanok, hogy a felhasználónak kell tevőlegesen futtatni őket su/sudo-val, hogy össze tudják fertőzni a rendszert. Esetleg elméletileg még nem rendszergizdaként a windowsos vírus futhat le Wine-ben, de az is legfeljebb a home mappába tud belehányni, a rendszermappákba nem, meg valami másik Wine folyamatot tud létrehozni.

És még nem hallottál olyanról hogy exploit? Például: [link]

Más kérdés hogy a payload az esetek túlnyomó részében windows specifikus.

Amúgy meg windows-on is megy a sandbox Chrome alatt, szóval érdekes a logikád mszerint ott árthat itt meg nem.

[ Szerkesztve ]

You may corrupt the souls of men, but I am steel. I am doom.

Én még akkor sem láttam ilyet Linuxon. Windows alatt is van sandbox, de nem ér valami sokat.

Ahogy nézem, ezek az exploitok is csak annyit tudnak, hogy kilépnek a sandboxból, de innen még messze van egy rendszer összefertőzése.

[ Szerkesztve ]

De hogy legyen itt valami szakmaibb is: tudja valaki, hogy i3wm-nél Compton segítségével hogyan lehetne az ablakfejléceket átlátszóvá tenni? Erre a Compton -e kapcsolója lenne való, de az nem működik, de még így sem lenne reménytelen, mert az --opacity-rule alapján meg lehetne neki adni, de nem tudom mire hivatkozzak, milyen elemnévre. Az i3bar-t már sikerült átlátszóvá tenni, csak az ablakfejléceket nem.

Fél-off topik:

Ha én felhasználok olyan Free/OSS projektet, a saját projektembe, amiből később nyereséget remélek, akkor ennek, hogy vannak a jogi következményei ?

feltettem a jogász-topikba is, de ott több napos a legutóbbi értelmes hsz.

Le van írva mindegyik licenszhez, el kell olvasni.

You may corrupt the souls of men, but I am steel. I am doom.

[link]

Legelső találat

[ Szerkesztve ]

You may corrupt the souls of men, but I am steel. I am doom.

azért helytelen a kérdésed, mert open source licenszből van vagy 140 féle.
a válaszhoz tudni kellene, hogy melyik.

"feltettem a jogász-topikba is, de ott több napos a legutóbbi értelmes hsz.": van ott értelmes hsz?

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

2 óra próba után feladom, inkább kérdezek:

adott egy friss telepítésű debian 9

cron telepítve, cron.service fut

Crontab tartalma:

# Global variables
SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin


*/1 * * * * root chown -R minidlna:minidlna /home/minidlna
*/1 * * * * root /winyoteszt/winyoteszt

crontab lefut, de semmi eredménye

syslog:

Mar 18 18:57:01 home-server CRON[1706]: (root) CMD (root chown -R minidlna:minidlna /home/minidlna)
Mar 18 18:57:01 home-server CRON[1705]: (CRON) info (No MTA installed, discarding output)[/S]

[S]Mar 18 18:57:01 home-server CRON[1707]: (root) CMD (root /winyoteszt/winyoteszt)
Mar 18 18:57:01 home-server CRON[1704]: (CRON) info (No MTA installed, discarding output)

mit felejtettem el?

A "root" felesleges volt a sorokban.

[ Szerkesztve ]

Üdv a szakiknak!

iptables-el kapcsolatban lenne egy érdekes kérdésem.

Adott egy publikus oldalról is elérhető szolgáltatás, ezen szolgáltatáshoz az ISP DNS szerverében fel lesz véve egy rekord (xyz.valami.hu), melyet az internetről meghívva egy adott belső hálózati szerverhez fog eljutni a kérés. A port forward ezen szerver felé nem probléma, legalábbis a net felől, ez eddig tiszta.

Az lenne a kérdésem, hogy megoldható-e, hogy a belső hálózatból is elérhető legyen a szolgáltatás xyz.valami.hu néven? Helyi DNS jelen helyzetben nem használható.

Annyival bonyolódik még a helyzet, hogy az átjárót megvalósító Debian tűzfal előtt van egy NAT-oló szolgáltatói eszköz is, tehát dupla NAT van. Az ISP eszközén DMZ-ben van a szóban forgó Debian tűzfal.

Jelen helyzetben megoldható lehet?
Első körben NAT loopback-hairpin kifejezésekre találtam hasznos infókat, elvileg megoldható, viszont a dupla NAT miatt problémás lehet.

Köszönöm!

udv
letix

don't panic! ... http://www.letix.hu - linux parancsok

ha például nem iptables-szel akarod megoldani, akkor van triviális megoldás

redir.

Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis

Újra megakadtam és egy kis segítséget szeretnék kérni.

Még egyszer a rendszer:

NUC kisgép egy SSD-vel
SSD-n van egy PROXMOX szerver (debian)
Virtuális gép (később gépek) telepítve. Jelenleg csak egy debian.

Van a gépben egy HDD (/dev/sda) is, ami a PROXMOX-ra nincs felcsatolva , csak odadva a virtuális debiannak.
Szeretném ha ez a hdd leállna ha nincs használva .
A proxmox alatt hdparm -S 60 /dev/sda kiadva. Soha nem áll le.

Tesztelve a következő módon:
egy RPI szerű gépből (banana-R1) került át, és ott tökéletesen működött.
Virtuális gépek kikapcsolva.
hdparm -Y /dev/sda és hdparm -y /dev/sda parancsra a HDD leáll, de pár másodperc múlva elindul újra.
USB-n egy alap ARCH linuxxal bootolva, a hdparm parancsra leáll és úgy is marad, tehát nem a BIOS ébresztgeti fel.

Kizárásos alapon marad a proxmox. Kérdés az, hogy egy fel sem csatolt HDD-t mi az isten ébresztgeti fel?

[ Szerkesztve ]

MÉg egy két teszt:

A smartd futott, de leállítottam, -> eredmény ugyanaz..

inotifywatch kimenet:

inotify /dev/sda
-bash: inotify: command not found
root@nuc:~# inotifywatch /dev/sda
Establishing watches...
Finished establishing watches, now collecting statistics.
total access close_nowrite open filename
684 128 278 278 /dev/sda

Üdv!

Van valakinek tapasztalata az i8kutils nevű ventillátor szabályozó programmal? Egy Dell e6430-on szeretnék Linuxot (Mint 18.3 Cinnamon) használni, de folyamatosan indokolatlanul nagy forulatszámon járatja a ventit és ez zavaró. A gép hardveresen rendben van, a hőfokok is megegyeznek a Windowsnál tapasztalt számokkal, csak a gép sokkal hangosabb.
Az említett programot nem sikerül működésre bírni, illetve a hatása nem látszik.
Feltettem a csomagkezelőből, beállítottam a konfig fájlokat is, de olyan, mintha mégsem nyúlna hozzá a ventillátorhoz, pedig konkrétan Dell laptopokhoz való. Akinek sikerült már működésre bírnia az tudna segíteni, hogy megtaláljam mi a probléma? (Kezdő Linux felhasználó vagyok, 20 év Windoes után)

.

Sziasztok,

Jelenleg egy Manjaro linuxot használok (Arch linuxon alapul). Notebookot fogok cserélni 2-3 napon belül. A mostani SSD-met átteném az új notebookba. A linux ugyanúgy probléma nélkül működni fog tovább automatikusan esetlegesen módosítva a drivereket (mint mondjuk egy Windows 10), vagy kézi beavatkozás szükséges ilyenkor? Vagy biztos ami biztos telepítsem újra a rendszert?

Taijiquan

A Wi-Fi problémámat nem tudtam megoldani azóta sem. Annyit kizártam, hogy nem az IPv6 hibája, mert azt letiltva is rendszeresen előjön. Azóta a 2.37-es systemd is frissült 2.38-ra. A beállításokat is kézire raktam, fix IP, átjáró, Google-féle 8.8.8.8-as DNS. Még mindig szórakozik. Kezdem azt hinni, hogy a Wi-Fi modul haldoklik az X220-ban. Egyelőre most kilőttem a NetworkManagert, és a wpa_supplicant alapú wifi-menu-vel hoztam létre a kapcsolatot. Szerintem ez sem fog segíteni, de majd meglátjuk.