-
Fototrend
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ű.
-
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
- Építő/felújító topik
- Térerő gondok, tapasztalatok
- Debrecen és környéke adok-veszek-beszélgetek
- Android alkalmazások - szoftver kibeszélő topik
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Kecskemét és környéke adok-veszek-beszélgetek
- Netfone
- Kerékpársportok
- Xbox tulajok OFF topicja
- Székesfehérvár és környéke adok-veszek-beszélgetek
- További aktív témák...
- Assassin's Creed Shadows Collector's Edition PC
- Számlás!Steam,EA,Epic és egyébb játékok Pc-re vagy XBox!
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Új, bontatlan World of Warcraft gyűjtői kiadások
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
- 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 7 5700X 16/32/64GB RAM RTX 4060Ti 8GB GAMER PC termékbeszámítással
- Bomba ár! Lenovo ThinkPad P50 - i7-HQ I 16GB I 256SSD I Nvidia I 15,6" FHD I Cam I W10 I Gari!
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged