- Akciófigyelő: Jelentősen olcsóbban nyit az Ulefone új mindenese
- VoLTE/VoWiFi
- Samsung Galaxy Watch7 - kötelező kör
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Google Pixel topik
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- Android szakmai topik
- Samsung Galaxy A56 - megbízható középszerűség
- Ugyanakkora telepet kap a Redmi csúcstelefon, mint a csúcstábla
- A lapkakészlet és az akku különbözteti meg a Motorola Edge 60 és Edge 60 Pro-t
-
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
- TCL LCD és LED TV-k
- PlayStation 4
- Steam, GOG, Epic Store, Humble Store, Xbox PC Game Pass, Origin Access, uPlay+, Apple Arcade felhasználók barátságos izgulós topikja
- Világ Ninjái és Kódfejtői, egyesüljetek!
- Bambu Lab 3D nyomtatók
- Energiaital topic
- VR topik
- Drum 'n' bass
- Formula-1
- Pécs és környéke adok-veszek-beszélgetek
- További aktív témák...
- Vírusirtó, Antivirus, VPN kulcsok
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Assassin's Creed Shadows Collector's Edition PC
- ROBUX ÁRON ALUL - VÁSÁROLJ ROBLOX ROBUXOT MÉG MA, ELKÉPESZTŐ KEDVEZMÉNNYEL (Bármilyen platformra)
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Samsung Galaxy A23 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RX 7600 8GB GAMER PC termékbeszámítással
- Dell OptiPlex MT/SFF 3040, 3050, 7050, 3060, 3070, 5070, 7060 /WIN 11 - SZÁMLA- GARANCIA
- Kaspersky, McAfee, Norton, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Csere-Beszámítás! Intel Core I9 14900KS 24Mag-32Szál processzor!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: Promenade Publishing House Kft.
Város: Budapest