- Kábeleket és csövezést rejtő "kirakatház" a GameMax logójával
- Felvarrták az Arctic rackmount rendszerekhez szánt CPU-hűtőjének ráncait
- Háromféle kivitelben, és nem kis kapacitásokkal jönnek a Micron 6550 ION SSD-i
- Már a Samsung sem szolgálja ki modern AI lapkákkal Kínát
- Havazáshoz igazított kiadás kap a Steam Deck OLED
-
PROHARDVER!
Mára a ProHardver!/IT.News Fórum is nagylétszámú Linuxban jártas taggal büszkélkedhet. Nehéz szinteket felállítani egy olyan rendszer ismeretében, ami annyira sokrétű, hogy teljesen szinte lehetetlen megismerni minden egyes részét. Azt azonban mindenki tudja, hogy kezdő-e vagy sem. Elsősorban nekik szólnak az alábbiak, de érdemes mindenkinek elolvasnia, mint útjelző táblát.
Új hozzászólás Aktív témák
-
#30304
lionhearted
őstag
kovaax
#30301
válasz
kovaax
#30301
üzenetére
Nem tértek, és jobb is így. Az említett docker is igen parádésan viselkedik mondjuk egy CentOS8 firewalld+nftables környezetben....
A lényeg amúgy is az, hogy ezeket már többnyire backendnek tekintik, ez elé teszik az ufw/firewalld/egyéb szolgáltatásokat.
Ezért szomorú, hogy az erre buzdító hozzászólásomat gyakorlatilag mindenki ignorálta. A probléma, és néhány megoldása: [link]
[ Szerkesztve ]
Tegnap még működött...
-
#30305
inf3rno
nagyúr
lionhearted
#30304
inf3rno
nagyúr
-
#30308
lionhearted
őstag
Lenry
#30306
-
-
Lenry
félisten
válasz
togvau
#30309
üzenetére
én azóta látok hasonlókat, mióta bekerült egy PCI-ex SATA vezérlő a gépbe. a rákötött lemezeknél látom időnként.
kicsit zavar, de inkább gondolom a vezérlő bénaságának, mint tényleges lemezhibának[ Szerkesztve ]
Gvella Glan! | There are two types of people: Those who can extrapolate from incomplete data
-
lordkolya
újonc
Sziasztok!
Remélem jó helyre írok,kis segítséget kérnék hátha van valakinek ötlete a problémámra.
Bind9 DNS szervert használnék a domain-em kezelésére. Teszt jelleggel a modem/routert bridge módba raktam meg is kapta a szerver a Public IP címet. Minden tökéletesen is működött, 15 percen belül frissültek is mindenhol a DNS rekordok. Ezzel kiderült hogy a szolgáltató nem blokkolja az 53-as portot.
Vissza tettem a modemet és így már nem frissülnek a rekordok.. beállítottam a port forwardot, nmap, telnettel teszteltem el is éri a szervert, listázta hogy az 53-as port nyitva. Dig Any <sajatdomain.hu> @<az én public IP címem> fel is oldja látom az összes rekordot, de ha csak Dig A <sajatdomain.hu> @<az én public IP címem> vagy dig SOA <sajatdomain.hu> @<az én public IP címem> ezeket már egyenként nem. -
-
fecus
őstag
Ubuntu 20.04 szerver. Megkértem a cron-t, hogy futtassa a clamscant és küldjön az eredményről levelet:
0 4 1 * * clamscan -i -r /MENTES | mail -s "Az új szerver MENTES vírusellenőrzése lezajlott" root
Kapok is levelet:Az új szerver MENTES vírusellenőrzése lezajlott2020. jún. 1. 6:23 (8 nappal ezelőtt)címzett: root/MENTES/Tablet/moborobo.exe: Win.Malware.Installcore-6951886-0 FOUND----------- SCAN SUMMARY -----------Known viruses: 7108171Engine version: 0.102.3Scanned directories: 2600Scanned files: 41235Infected files: 1Data scanned: 55997.88 MBData read: 289179.30 MB (ratio 0.19:1)Time: 8593.090 sec (143 m 13 s)A gond, hogy kapok egy másikat is ha a clamscan-nek gondja akadt:
Cron <root@szerverneve> clamscan -i -r /MENTES | mail -s "Az új szerver MENTES vírusellenőrzése lezajlott" rootjún. 1., H 6:23 (8 nappal ezelőtt)címzett: rootLibClamAV Warning: Bytecode run timed out in interpreter after 261030000 opcodesLibClamAV Warning: Bytecode 35 failed to run: CL_ETIMEOUT: Time limit reachedLibClamAV Warning: Bytecode run timed out in interpreter after 260935000 opcodesLibClamAV Warning: Bytecode 35 failed to run: CL_ETIMEOUT: Time limit reachedLibClamAV Warning: cli_scanxz: decompress file size exceeds limits - only scanning 27262976 bytes
Az utóbbit miért kapom, és miért a teljes parancssor a levél címe?"Szörnyek léteznek, de túl kevesen vannak ahhoz, hogy igazán veszélyesek legyenek. Sokkal veszélyesebbek az átlagemberek, a funkcionáriusok, akik készek hinni és cselekedni anélkül, hogy kérdéseket tennének fel." (fordította DeepL ) - Primo Levi
-
bambano
titán
-
szoke12
őstag
Sziasztok!
Keresgéltem a fórum keresőjében, de nem találtam egyértelmű választ a kérdésemre.
Nem túl régóta kezdtem a hálózati dolgokkal foglalkozni linuxon, úgyhogy elnézést, ha buta kérdésem lesz.Adott egy gép (konkrétan egy debian linuxon futó lxc - ebben kell megoldanom), és van benne 2 hálókártya. Tehát:
LAN1 (192.168.0.0/24 - DHCP) <> (192.168.0.x) LXC (192.168.1.90) <> LAN2 (192.168.1.0/24)
Miért van az, hogy ha a LAN1-re csatlakozok, és ott nem dhcp-től kérek címet, hanem 1-es tartománybeli statikus címet használok, akkor látom az lxc LAN2-beli IP-jét?
Vagyis a LAN1-ben eléthető a 192.168.1.90.
A baj az, hogy egy hálózatba kellene tennem sok ilyen kis lxc-t ugyanolyan konfigurációval.Előre is köszönöm a válaszokat!
"Élj úgy, hogy ha majd lepereg előtted életed filmje, érdemes legyen végignézni!"
-
-
szoke12
őstag
Köszönöm a jelzést, a dolog dhcp-részével nincsen gond, az szépen beállítódik. A gondom az, hogy a LAN1-es hálókártyán megjelenik a gép LAN2-es IP címe is. És fordítva.
És mivel ebből az eszközből sokat akarok egy hálózatra tenni, ez címűtközést okozhat."Élj úgy, hogy ha majd lepereg előtted életed filmje, érdemes legyen végignézni!"
-
Jester01
veterán
válasz
szoke12
#30318
üzenetére
Ha beállítottad a default gatewayt és engedélyezve van az ip forward akkor nyilván fogod látni a másik címet is mivel a csomagod akkor a gatewayhez megy mint ismeretlen cím. Ütközésből szerintem nem lesz probléma ha nem akarsz azokra a címekre forgalmazni.Ha zavar akkor tűzfal szabállyal megmondhatod, hogy dobja el az ilyen csomagokat (már ha a default gw vagy az ip forward kikapcsolása nem járható). Vagy kliens oldalon is csinálhatsz olyan route táblát ami nem küldi ki a másik tartománybeli csomagot.
[ Szerkesztve ]
Jester
-
-
radi8tor
MODERÁTOR
Egy ideje ezt írja minden frissítés ellenőrzésnél. Mit lehet/kellene ezzel csinálni?
root@gp-wifi-01:/home/admin# apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu bionic InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic-updates InRelease
Hit:3 http://archive.ubuntu.com/ubuntu bionic-backports InRelease
Hit:4 http://archive.ubuntu.com/ubuntu bionic-security InRelease
Ign:6 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 InRelease
Get:7 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release [3,457 B]
Get:8 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg [801 B]
Err:8 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg
The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
Get:5 https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease [3,010 B]
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release: The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
E: Repository 'https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease' changed its 'Suite' value from 'oldstable' to ''
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
root@gp-wifi-01:/home/admin# apt full-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.⭐ Stella
-
-
radi8tor
MODERÁTOR
Ugyanazt írja utána is. Feltette a kérdést első alkalommal, Y nyomtam.
root@gp-wifi-01:/home/admin# apt-get update
Ign:1 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 InRelease
Hit:2 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:3 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:4 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release [3,457 B]
Get:5 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg [801 B]
Get:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Get:7 http://archive.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Err:5 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg
The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
Hit:8 https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease
Fetched 256 kB in 2s (165 kB/s)
Reading package lists... Done
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release: The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Failed to fetch http://repo.mongodb.org/apt/ubuntu/dists/xenial/mongodb-org/3.4/Release.gpg The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.
root@gp-wifi-01:/home/admin# apt update
Ign:1 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 InRelease
Get:2 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release [3,457 B]
Get:3 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg [801 B]
Hit:4 http://archive.ubuntu.com/ubuntu bionic InRelease
Get:5 http://archive.ubuntu.com/ubuntu bionic-updates InRelease [88.7 kB]
Get:6 http://archive.ubuntu.com/ubuntu bionic-backports InRelease [74.6 kB]
Err:3 http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release.gpg
The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
Get:7 http://archive.ubuntu.com/ubuntu bionic-security InRelease [88.7 kB]
Hit:8 https://dl.ubnt.com/unifi/debian unifi-5.10 InRelease
Fetched 256 kB in 1s (182 kB/s)
Reading package lists... Done
Building dependency tree
Reading state information... Done
All packages are up to date.
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 Release: The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Failed to fetch http://repo.mongodb.org/apt/ubuntu/dists/xenial/mongodb-org/3.4/Release.gpg The following signatures were invalid: EXPKEYSIG BC711F9BA15703C6 MongoDB 3.4 Release Signing Key <packaging@mongodb.com>
W: Some index files failed to download. They have been ignored, or old ones used instead.[ Szerkesztve ]
⭐ Stella
-
fecus
őstag
válasz
bambano
#30317
üzenetére
Gondolom nem teljesen haladó a kérdésem, de tudnátok segíteni?
Ez parancssorból simán lefut és küld szép emailt:clamscan -i -r /home |& mail -s "Az új szerver home vírusellenőrzése lezajlott" rootA cronból viszont megint ezt kapom:
Cron <root@szerverneve> clamscan -i -r /home |& mail -s "Az új szerver home vírusellenőrzése lezajlott" rootjún. 13., Szo 4:30 címzett: root/bin/sh: 1: Syntax error: "&" unexpectedMit rontok el?
"Szörnyek léteznek, de túl kevesen vannak ahhoz, hogy igazán veszélyesek legyenek. Sokkal veszélyesebbek az átlagemberek, a funkcionáriusok, akik készek hinni és cselekedni anélkül, hogy kérdéseket tennének fel." (fordította DeepL ) - Primo Levi
-
I02S3F
addikt
Sziasztok! Ha érdekl a Linux és szeretném behatóbban megtanulni, akkor egy Linux rendszergazda, vagy Linux rendszerüzemeltető pozi e cél elérésére alkalmas lenne? (Fél év múlva ehhez lesz papírom, mérnökinfó felsőoktatási szakképzés) Mit gondoltok?
(Most a cél pozi érdekelne és nem a learning path) -
vzozo
senior tag
Adott egy Odroid N2, és USB-SATA adapteren keresztül egy SSD-ről fut a rendszer. Szeretnék biztosra menni, hogy a TRIM használva van, mivel a SMART adatok szerint a wear level elkezdett durván növekedni szinte nulla használat mellett
Titt nem látok discard opciót az fstab-ban:
/dev/sda1 on / type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=writeback)/dev/sda1 on /var/log.hdd type ext4 (rw,noatime,nodiratime,errors=remount-ro,commit=600,data=writeback)Legalább van noatime.
Ugyanakkor maga a diszk elvileg támogatja:
root@odroidn2:/home/vz# lsblk --discardNAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZEROsda 0 4K 4G 0└─sda1 0 4K 4G 0sdb 0 0B 0B 0└─sdb1 0 0B 0B 0mmcblk1 0 4M 3.5G 1└─mmcblk1p1 0 4M 3.5G 1zram0 0 4K 2T 1zram1 0 4K 2T 1root@odroidn2:/home/vz# hdparm -I /dev/sda | grep TRIM* Data Set Management TRIM supported (limit 8 blocks)Innen ti merre indulnátok tovább? Simán tegyem be a "discard" opciót az fstab-ba? Illetve olvastam az "fstrim" toolról, de őszintén szólva nem tiszta, hogy mi volt a gond a "discard" mountolással, miért kellett új valamit kitalálni?
[ Szerkesztve ]
-
Frawly
veterán
Igen, tedd be a /etc/fstab-ba az adott partíciókhoz a discard paramétert. Vagy futtasd időnként kézzel az fstim-et, vagy ütemezd be systemd service-ként systemctl-lel.
Azért létezik a két megoldás együtt, mert kezdetben egyik fájlrendszer ezt a megoldást támogatta, a másik a másikat. Ma már kb. minden fájlrendszer támogatja mindkét módszert, így mára az maradt, hogy ki melyik módszerre esküszik. A Linux disztrók zöme fstrim-et használ systemd-vel beütemezve, az Arch Linux és a rá épülő disztrók fstab discard-ot. Mindegy melyiket használod.
Ami gond lehet még, az az USB-SATA adapter. A TRIM parancsot nem mindegyik engedi át az SSD felé. Az adapterchiptől függ.
-
vzozo
senior tag
válasz
Frawly
#30337
üzenetére
Köszi mindkettőtöknek. Qrva sok szívás van az USB-SATA miatt, de az SBC-knek ez a borzasztó hátrányuk, már ezerszer megbántam, hogy ebbe vágtam a fejszémet. Ugyanakkor a lakásban jelenleg nincs olyan zug, ahová elrakhatnék egy "rendes" x86 alapú vasat, asszony meg nyilván nem szeretné se a nappaliban, se a háló- vagy gyerekszobában látni. Paff.
Itt (https://forum.manjaro.org/t/solved-trim-not-working-on-a-usb-3-0-drive/45585/33) azt állítják hogy a JMS 578 támogatja a trimet.
Ami érdekes az fstrim-mel, hogy amikor először futtattam 19-én a posztolás után, akkor trimmelt kb. 220 gigát. Majd pár órára rá néhány megát.
Most délelőtt újra futtattam, és:
root@odroidn2:/home/vz# fstrim -a -v/var/log: 39.3 MiB (41156608 bytes) trimmed on /dev/zram0/media/mmcboot: 56.7 GiB (60854341632 bytes) trimmed on /dev/mmcblk1p1/: 226.8 GiB (243520970752 bytes) trimmed on /dev/sda1kb. fél órával később:
/: 69.3 MiB (72646656 bytes) trimmed on /dev/sda1Volt a hétvégén néhány restart, lehet amiatt trimmelte újra az egész SD-t és az SSD-t is? Fura...
-
#30340
lionhearted
őstag
vzozo
#30339
-
#30341
vzozo
senior tag
lionhearted
#30340
vzozo
senior tag
válasz
lionhearted
#30340
üzenetére
Nekem még mindig nem tiszta, hogy pontosan mit csinál az fstrim. Ilyen rövid idő alatt nem tud ~200 gigát kiírni, tehát pontosan hova, hogyan mondja el az SSD-nek, hogy akkor azok üres blokkok?
-
#30342
lionhearted
őstag
vzozo
#30341
Röviden: nem írja ki, csak megjelöli szemétként, amit a GC egyszer csak törölni fog.
Hosszan: az fstrim megkérdezi a fájlrendszert, hogy melyik fájlrendszer szektor üres, majd a szektor - LBA táblából átadja az eszköznek azon LBA tereket, amik valójában már üresek/szemetek. Az eszköz az LBA - belső címzés alapján bejelöli azokat a pageeket, amik szemetet tartalmaznak. Legközelebb, mikor:
* vagy az egész block (több page) invalid lesz és jön rá egy GC törlés
* vagy újrafelhasználva írni akar a pagere, akkor ugye törölni kell a blockot, majd vagy ott, vagy máshol (dinamikus WearLeveling dönti el) kiírja, akkor már nem viszi magával az invalid paget, helyére új kerülhet
* vagy a statikus WearLeveling úgy dönt, hogy túl sokáig állt ott az adat és áthelyezi, akkor kivágja az SSD a fenébe ezeket a pageeket, nem viszi őket tovább.Tegnap még működött...
-
Dißnäëß
nagyúr
Sziaszok,
van arra ötlete valakinek, milyen irányban kellene-lehetne tovább menni.. ? Adott pár célgép, amikre sftp-vel akarnánk kliens oldalról feltölteni fájlokat. A célgépek identikusak, előttük egy load balancer dobálgatja a forgalmat ide-oda. Mivel a kliens oldalon csak 1 virtuál ip és 1 hostname látszik mindegyik tényleges host-ot illetően, viszont a valóságban mikor melyik host-on végződik a kapcsolat, változik a host RSA key, ami oké a kliensnek, ha éppen random a nála eltárolt key-ű host szolgálja ki a kapcsolatot, minden egyéb esetben errort dob és nincs kapcsolódás. Ezen ellenőrzés kikapcsolása kliens oldalon nem megoldás. A host-okra egységesen 1 kulcsot rátenni (mindre ugyanazt) szintén elég hülye lenne (még ha működne is, valaki így csinálta és megy). SSL terminálás a load balanceren szintén nem megoldás, ha onnan titkosítás nélkül megyünk a célgépekre. Lehet kapcsolódó kliens oldalon kellene vmit script-elni, vagy megoldható a címzett oldalon valami ügyes trükkel ? Úgy tudom, egy kliens oldalról látszó host-hoz csak 1 key rendelhető (ha lehetne többet is, az megoldaná instant a fejfájást). Köszi.
[ Szerkesztve ]
Kígyó vére, béka hája, pók levedlett ruhája.. kondéromban lepke sül, kívánságom teljesül !
-
bambano
titán
válasz
Dißnäëß
#30343
üzenetére
ha az architektúrád nem alkalmas a feladat végrehajtására, architektúrát kell cserélni.
"SSL terminálás a load balanceren szintén nem megoldás, ha onnan titkosítás nélkül megyünk a célgépekre.": pedig eléggé ez tűnik a normális megoldásnak.Egy átlagos héten négy hétfő és egy péntek van (C) Diabolis
-
#30347
vzozo
senior tag
lionhearted
#30342
vzozo
senior tag
válasz
lionhearted
#30342
üzenetére
Köszönöm a válaszod - igazából ez a nagyvonalakbeli működés úgy-ahogy tiszta volt számomra is. Amit nem értek, hogy pontosan mi is történik, mivel itt pár másodperc alatt lezajlik az akció akár a 64 gigás SD kártyára, akár a 200 gigás SSD-re.
A teljes fájlrendszer összes blokkja a memóriában van mountolás után, és ezért fut ez le ilyen gyorsan?
[ Szerkesztve ]
-
vzozo
senior tag
válasz
Dißnäëß
#30349
üzenetére
Nem fogok farokméregetési versenybe kezdeni, hogy ki mennyi LB-vel dolgozott már az év(tized)ek alatt, de azért vegyük már észre, hogy egy Layer4 LB-vel túl sokat itt nem tudsz tenni source IP affinity beállításán kívül vagy SSL termináláson (de az meg L7, és általában nem load balancernek, hanem proxy-nak nevezzük.)
Persze ha megosztod a megoldásod, azzal mindenki előrébb lesz.
Új hozzászólás Aktív témák
Hirdetés
- HDD probléma (nem adatmentés)
- Sorozatok
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Építő/felújító topik
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Opel topik
- Filmvilág
- Pendrive irás-olvasás sebesség
- BIOS frissítés
- Már jövőre befuthat a Stellar Blade PC-s kiadása
- További aktív témák...
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: HC Pointer Kft.
Város: Pécs