- VoLTE/VoWiFi
- iPhone topik
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Xiaomi 13 - felnőni nehéz
- Szerkesztett és makrofotók mobillal
- Motorola Edge 40 neo - színre és formára
- Motorola Edge 30 Neo - wake up, Jr...
- Google Pixel topik
- Ford SYNC 3 infotainment rendszer teszt
- Motorola Edge 50 Neo - az egyensúly gyengesége
-
Mobilarena
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
-
bambano
titán
válasz
gt7100
#23996
üzenetére
milyen gyakori rendszer van még, ami nem linux és nem windows?
azért okoz gondot, mert a routing döntés célja, hogy kiderüljön, melyik interfészen kell kifelé tolni a csomagot a célja felé. ha pedig ugyanabban a subnetben van két interfész, akkor a válasz nem egyértelmű.
-
#23992
lionhearted
őstag
gt7100
#23976
válasz
gt7100
#23976
üzenetére
Nekem is van egy J1800 és J1900 "szerverem" is. A cryptsetup benchmark ad egy becslést, hogy milyen sebességgel bírják a titkosítást. Ilyen mértékben nálam nem okoznak gondot. A különbség szerintem nem az ssh-ban keresendő hanem a transfer schemaban. Az scp lineárisan tunkolja át az adatot, az rsync sokkal komolyabb deltákban és diffekben gondolkozik. Nem tartom kizártnak, hogy összességében jobban optimalizált az ssh kapcsolati sajátosságokra. Egyébként helyi hálón gondolom nem feltétlen akarsz mindig titkosítani, én úgy tudom, hogy rsync daemon titkosítás nélkül fut.
-
vargalex
félisten
válasz
gt7100
#23984
üzenetére
Én a CPU terheltségből azt gondolom, hogy azért, mert nem (vagy nem olyan erős tömörítést használ). Ha -z (vagy --compress) kapcsolóval rsync-eztél, akkor tömörített, ha nem, akkor nem.
Persze, ahogy a fentebbi példám is mutatja, még tömörítés mellett sem indokolt olyan kis sebesség, amit írtál. Nálam ugye elvileg picit erősebb a CPU, de ahogy írtam, tömörítéssel is tudott 12 MB/s környékén.
Most gyorsan megnéztem kábelen is. Az eredmény:SCP tömörítés nélkül: 60 MB/s
SCP tömörítéssel: 11.6 MB/sAzaz tömörítésnél már valóban a CPU volt a szűk keresztmetszet wifi esetén is.
-
vargalex
félisten
válasz
gt7100
#23982
üzenetére
Szia
Ha -C kapcsolóval másoltad, akkor ugye jóval magasabb a CPU terhelés a tömörítés miatt. Most kipróbáltam, nálam egy J1900 van használatban. Wifi-n másoltam, akár tömörítéssel, akár nélküle 12 MB/s körül ment a másolás. Viszont, amíg tömörítés nélkül a wifi volt a szűk keresztmetszet (a J1900-on 1 mag 16-18%-ra terhelt), addig tömörítéssel a CPU is, mivel 1 magot 100%-ra kihajtott. Szóval, ha nem tetted, akkor próbáld meg -C nélkül.
-
bencze
senior tag
válasz
gt7100
#23976
üzenetére
Ssh nem tűnik túl hatékonynak nagyobb adatátvitelre, ezt sokszor tapasztaltam. Nem tudom, hogy ez csak a cipherek miatt vagy más okokból. Ha ez fontos lenne én alternatívákat keresnék, https, ftps, vagy akár valamiféle nfs vagy rsync valami titkosított tunnel fölött... csinálj benchmarkokat
-
dni
őstag
válasz
gt7100
#23961
üzenetére
Most csak az alábbi útvonalakat írja ki az echo $PATH parancs:
:/mnt/nfs/k/:/root/bin
a korábbi /usr/lib64/qt 3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin helyett, így a bash parancsok nem működnek.Hogy tudom visszaállítani az eredetire? Az alábbi parancs kiadásau után, majd ki-be jelentkezést követően továbbra sem érem el a bash paracsokat.
PATH={$PATH}:/usr/lib64/qt-3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/binA /etc/profile.d/scripts-path.sh fájlban most csak a /usr/lib64/qt 3.3/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin útvonalak vannak így működnek újra a bash parancsok.
Eredetileg azt szerettem volna elérni, hogy a k_drive változóra automatikusan kicserélje a a rendszeren futó scriptekben az útonalakat /mnt/nfs/k -ra mert Windowson futó appokból küldenénk ki renderelésre anyagokat és Winen ugye más útvonalon érjük el a hálózati tárolót... -
-
bambano
titán
válasz
gt7100
#23936
üzenetére
azért tiltja az összes nem https portot connecttel, mert ha nem tiltaná, lendületvesztés nélkül lehetne átmenni az összes tűzfalon, amiben squid van. például ha a munkaadó letiltaná az ssh portot, de a proxyban nem lenne tiltva, akkor a squidon keresztül lehetne ssh-zni kifelé.
-
gt7100
tag
válasz
gt7100
#23935
üzenetére
Részben az utókor számára, ha netán más is belefutna:
az az apróság kimaradt, hogy a nem szabványos SSL portokhoz kapcsolódás a CONNECT metódussal, tiltva vagyon a squid alap konfigurációban.
Kellett pár plusz sor és remélem, hogy nem csinálok vele valami csúf sec.hole-t:# .lichess.org settings
acl lichess dstdomain .lichess.org
acl lichess_socket_ports port 80
acl lichess_socket_ports port 9021
acl lichess_socket_ports port 9022
acl lichess_socket_ports port 9023
acl lichess_socket_ports port 9024
acl CONNECT method CONNECT
http_access allow CONNECT lichess_socket_ports lichessEzzel elvben azt érem el, hogy a .lichess.org domain alá tartozó szervereken a 80-as és a 9021-9024 portokat el lehet érni CONNECT-tel is. Nem állíthatom, hogy szép megoldás a lichess.org fejlesztői részéről, mert gondolom, nem ok nélkül tiltja a squid ezeket a portokat...
-
bencze
senior tag
válasz
gt7100
#23889
üzenetére
Nem akarok erősen off lenni de tudtommal a syslog-ng tud tls-t is manapság szóval a bizalmasság és integritás adott lehet. Ha valaki megbízik a 0 pidben és készítőiben eléggé akkor jó lehet feltéve hogy pl a kimeneti formátuma megfelel (nem tudom logelemzők mennyire támogatják jelenleg, melóban még syslogozunk én meg slackre váltottam). A syslog-ng-t mondjuk nem csak objektív okokból támogatom lévén hogy magyarok tolják.
-
Thusor
őstag
válasz
gt7100
#23893
üzenetére
Rendben, köszönöm a válaszaitokat. Akkor lemondok róla. Én elsősorban a nagyobb tárhely kialakítása és a sebesség miatt szerettem volna elsősorban RAID0-át. Biztonsági mentés külső NAS-ra szokott menni amiben RAID5 van. Bioinformatikával foglalkozom ami során nagyon nagy adatbázisokban kell keresnem lokálisan, ami akár 2-3TB adatot vagy többet is jelenthet. Erre esélytelen anyagi okok miatt SSD-ket befogni. Ezért gondoltam két HDD összefűzését, biztonsági mentésnek mg ott a NAS. De ha ennyire veszélyes a RAID0 akkor inkább hanyagolom.
Új hozzászólás Aktív témák
Hirdetés
- Kamionok, fuvarozás, logisztika topik
- Mibe tegyem a megtakarításaimat?
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- Horgász topik
- Kerékpárosok, bringások ide!
- Xbox Series X|S
- Egyre csak fejlődik az AI, emberek tízezreit rúgja majd ki a BT
- VoLTE/VoWiFi
- Gyúrósok ide!
- EAFC 25
- További aktív témák...
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Játékkulcsok olcsón: Steam, Uplay, GoG, Origin, Xbox, PS stb.
- Samsung Galaxy A14 64GB, Kártyafüggetlen, 1 Év Garanciával
- Iphone 16E 128GB Fekete Bontatlan 24 Hónap Garancia
- Azonnali készpénzes INTEL CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 16/32/64GB RAM RX 7700XT 12GB GAMER PC termékbeszámítással
- Lenovo Yoga Pro 9 (16IMH9) - Intel Core Ultra 9 185H, RTX 4060, 32GB, érintős ELKELT
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged