- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Magyarországon is kapható a Moto G85 5G
- Samsung Galaxy A56 - megbízható középszerűség
- Hat év támogatást csomagolt fém házba a OnePlus Nord 4
- Milyen okostelefont vegyek?
- Okosóra és okoskiegészítő topik
- Motorola Edge 40 - jó bőr
- Yettel topik
- Érintésnélküli fizetési megoldások - PayPass via NFC
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
-
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
- Csere-Beszámítás! Számítógép PC Játékra! I5 14400F / RTX 4060ti 16GB / 32GB DDR5 / 1TB SSD
- Bomba ár! Lenovo ThinkPad P50 - i7-HQ I 16GB I 256SSD I Nvidia I 15,6" FHD I Cam I W10 I Gari!
- BESZÁMÍTÁS! GIGABYTE H77-DS3H H77 chipset alaplap garanciával hibátlan működéssel
- REFURBISHED és ÚJ - HP USB-C Dock G5 docking station (5TW10AA) - 3x4K felbontás, 120Hz képfrissítés
- Bomba ár! Lenovo X1 Yoga 2nd - i7-7G I 8GB I 256SSD I 14" WQHD I HDMI I W11 I CAM I Garancia!
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: CAMERA-PRO Hungary Kft
Város: Budapest