- Gurulunk, WAZE?!
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- gban: Ingyen kellene, de tegnapra
- bitpork: MOD Júni 13 Augusztus 2- szombat jelen állás szerint.
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Argos: Szeretem az ecetfát
- sziku69: Szólánc.
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Sub-ZeRo: Euro Truck Simulator 2 & American Truck Simulator 1 (esetleg 2 majd, ha lesz) :)
-
LOGOUT
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
inf3rno
#32623
üzenetére
j5040 asrock alaplap 10 wattos tdp-jű procival van. plusz ethernet kártyával routerként szerintem kevesebb lesz, mint a hap ac^3.
én is váltottam am4-re nemrég, és most vissza 1170-re, mert az amd-s driverek minőségével tele lett a hócipőm. az energiagazdálkodás se az igazi. -
vicze
félisten
válasz
inf3rno
#32619
üzenetére
Ne nekem írd.
"driver támogatásuk is nagyon jó"
Hát ööö ebben azért nem adnák igazat, a AMD oldali támogatás elég foghíjas sokéves termékekre is. RAID, HBA, NIC-nél is nagyon oda kell figyelni mit vesz az ember, és minding csekkolni az adott verzió HW comp listáját. Ez tök érthető a közösség mérete miatt ahogy írtad, de tényleg minding meg kell nézni.
Pár éve sikerült pont elnézzek egy számot egy NetXtreme II-nél, hát jó pár óra volt mire rájöttem, hogy el***sztam. -
#32613
lionhearted
őstag
inf3rno
#32612
-
válasz
inf3rno
#32572
üzenetére
Információbiztonságban általában úgy megy, hogy megveszik a hardvert, ami tud annyi sávszélességet, aztán kalap. Kicsiben, ha több ezer node-ot kell deployolni akkor már elkezdenek inkább konfigurálni
Otthonra egyet értek amúgy a BSD alapú megoldásokban. (#32579) bambano Tudtommal mindenki DPDK-t használ ([link]) magas szintű szűrésre. Ehhez kell egy Linux kernel, meg valami jó brutál vas. Az ilyen arm, meg mips 1 gigára jó ha elég.
(#32583) vicze1 Ma már olyan brutál erősek az x86 procik, hogy nem igazán kell FPGA. Akár virtuális gépen elmegy ilyesmi, csak kell neki adni megfelelő hálózati kártyát. De régen is FPGA volt, ASIC-el nem szűrsz forgalmat
-
bambano
titán
válasz
inf3rno
#32582
üzenetére
oké, amiben "purpose built" asic van, azt elfogadom hardveres tűzfalnak.
tudtommal a mikrotiknek nincs ilyenje. én mostanában ids/ips-t sem láttam tőlük. alapvetően wireles isp beszállítóként indultak és azóta lett switch meg router termékvonal is. kb. az a szint, mint a cisco linksyses termékcsaládja, vagy annál kicsit jobb. -
bambano
titán
válasz
inf3rno
#32574
üzenetére
a pc-ben nehézsúlyú processzor van, ahhoz képest viszonylag rendes buszokkal. a "hardveres" tűzfalakban vagy valami gagyi intel proci van (asa500-ban celeron, 100 megás depca kártyákkal anno, rotfl), vagy a mikrotikben mips, újabban arm architektúrájú proci(mago)k, és viszonylag kevés darab.
teljesen biztos vagyok benne, hogy egy pc tovább bírja, mint pl. egy mikrotik. A mikrotik korábbi csúcsgépében 72 magos tilera proci volt, ezt is leveri egy 16c32t amd pc. A mostani elérhető árú (fél milleren innen) mikrotikekben 4 magos 2GHz-es arm alapú proci van, a csúcsgépben 16 magos arm.
Nem, ez soha nem éri utol a pc-t. Akkor lehet vele teljesítményt elérni, ha a routerben valamiért van rendes switch is, és a switch chip elég okos, akkor jöhet az a szint, hogy egy mikrotik elkezd összemérhető eredményt elérni egy pc-vel. A komolyabb szolgáltatók (pl. netflix) most ott tartanak pc-vel, hogy 400-800 Gbps között tudnak https forgalmat egy pc-ből.
én egyébként szeretem a mikrotiket, de két hónapnyi kísérletezés után most egy efficient mag csinálja a hálózati kapcsolatomat.
-
ledgeri
nagyúr
válasz
inf3rno
#32443
üzenetére
& #32444 sh4d0w & #32445 Lenry & #32446 B.Géza
Az lett a terv, hogy friss win-en futott volna friss win vm, vpn-en át, csak az alap win nem talált DNS-t 5 perccel a telepítése után, lett belőle az hogy tails-t használtam végig.
Kerekedett egy háttértörténetke is, majd meglátom medig jutok vele. -
ledgeri
nagyúr
válasz
inf3rno
#32441
üzenetére
Lényegében azzal érkeztem hogy kéne potenciálisan malware-es scammer interakció kezelésre, valamilyen olyan megoldás, amit tudok biztonságban használni az egyszem, alapéletre használt PC-men. De máshol meg a "statisztikailag a VM elég" lett a végszó... Majd meglátom mi lesz belőle.
-
válasz
inf3rno
#32435
üzenetére
Hogyne, van jó pár kiegészítő: [link] Én Fedora alatt is Windowsos Chromeot "hazudok" vele, de leginkább azért, mert csomó webapp el sem indul enélkül böngészőben, pedig menne rendesen.
Ugyanakkor ezernyi más módja van a fingerprintingnek, amin esetleg a user.js tud segíteni: [link] Ennek én sok ideig a relaxed verzióját használtam, de viszonylag sok kényelmi áldozattal jár a használata. Pl a böngészőm nem mentett előzményeket stb.
-
gregory91
senior tag
válasz
inf3rno
#32415
üzenetére
Elvileg csak Oracle Java 1.8-al megy és csak azzal a felhasználóval, aki telepítette. Azt mondják root-al nem jó telepíteni pont emiatt. Hol látod the package managerben? Milyen verzió?
itt
Nekem /usr/share/abevjava -t kínált mint mappa,de ehhez root jogosultság kell.
Ha profilmappát választasz akkor nem hiszem.Amennyire értem a Java 1.8 valami JDK verzió, és nekünk a JRE verzió kell, ami 8-as (gondolom ami a másikban a minor version number, az itt a major).
openjdk java 11 runtime-al indítottam és úgy feltelepült.Majd a abevjava.jar fájlnak adtam futtatási jogot(ugyanannak a telepítőjével el is tudod távolítani). -
bambano
titán
válasz
inf3rno
#32413
üzenetére
keresel egy megfelelően támogatott java vm-et, ez nem csak annyi, hogy 1.8, hanem elég magas harmadik alverziószámot is jelent.
ezt rendesen felrakod kézzel az ubuntudra rootként, majd beállítod a környezeti változókat, utána userként felrakod a saját jar-os telepítőjével.
igyekszel kerülni a dupla monitoros gépeket, ha neked ilyen van, akkor végigolvasod a netet guglival az "eclipse jawa awt bug" megoldásai után. -
-
-
bambano
titán
válasz
inf3rno
#31388
üzenetére
egyrészt aggályos, hogy ilyen nyilatkozat törvényes-e. (2012. évi I. törv. 179. par. 3. bek).
másrészt ha bármit alá akarnak íratni velem, ami a munkaszerződés módosításával jár, akkor az egyrészt kétoldalú egybehangzó akarat kérdése, másrészt ha már módosul a munkaszerződés, akkor más pontok is módosulnak. -
válasz
inf3rno
#31388
üzenetére
Hát... ez egy igen nagy múltú cég, bár lehet ezért koptak ki az értelmes emberek mára
Ám ott - legalábbis a belső infrás részeken - nem volt ilyen nyilatkozat, pedig ott is volt olyan support (nem is egy) ami regionális, vagy globál cuccokra ment. Ügyfélrendszereken lehet, de ott sem említett senki ilyet.
Meg mérlegelni kell, hogy egy ilyen nyilatkozat mennyi fizunál éri meg... -
válasz
inf3rno
#31374
üzenetére
Az eredeti kérdésben nem szerepelt az otthoni környezet, de később említette
"Hogy a kérdésre is válaszoljak, akkor éri meg ezeknek a tesztelése, ha egy elgépelés miatt lecsukhatnak x évre vagy rádvernek egy több milliós bírságot,"
Ehhez képest az ilyesminek gyak. egy cégnél sem látom a tesztelését. Ennyi erővel azt is felügyelhetnéd, hogy az admin mit gépel. Mondjuk van, ahol próbálták, pár év után elég lett, és felmondtam, mert 2:1 volt az adminisztráció a tényleges munkával.
Mit beszélek, oktatás se szokott lenni, felvesznek, 2 nap múlva root jog Komplett környezetek úgy rárakása csapatokra, hogy sosem láttak olyan OS-t, middleware-t, semmit Jó esetben csak én jártam néhány ilyen helyen, és nem a túlnyomó többség ilyen Komolyabb helyeken össze szokták szedni - elméletben gondolom, bár remélem, hogy van, ahol tényleg
Meg azt se hiszem, hogy az olyan szintű dolgokat szedik össze, amiket páran használnak, senkinek az orrára nem kötve. A komolyabban használt dolgokat persze össze kell, de az egy másik szint. -
bambano
titán
válasz
inf3rno
#31370
üzenetére
azért kanyarodjunk már vissza a kezdetekhez: biztonsági másolatot akar verziózva úgy, hogy a kliens oldalhoz nem tud hozzányúlni.
Erre egy lehetséges megoldás, hogy a szerveren létrehoz napi mappákat például Sun Mon stb. neveken, majd cronból minden nap lefuttat egy:rm -f backupln -s $(LANG=C date '+%a') backuputasításpárt. Ezen a bonyolultsági szinten nem írunk unit tesztet, pláne nem otthoni felhasználáskor, nem tervezünk projektet a megvalósítására, nem tűzünk ki a projekben mérföldköveket, nem csinálunk drp-t, bcp-t, nem készül projekt alapító dokumentum, nem írjuk le hetven oldalban a projekt termék elfogadási kritériumait, stb. hanem odaülünk a konzolhoz és bevésünk egy sort a crontabba. hasonló módon nem írunk maven szkriptet ötven gigabájtnyi függőség és könyvtár letöltéséhez, nem használunk hatféle keretrendszert, nem használunk mvc framewörköt, perzisztencia réteggel és különösen nagyon határozottan nem rakunk fel dockert egy tetves link létrehozására. kubernetest se. érthető okból nem illesztjük a rendszert távmenedzsment cuccokhoz, még Muninhoz se.
A személyes tapasztalatomban minden túltervezett projekt becsődölt.
A segítségem nélkül is... -
bambano
titán
válasz
inf3rno
#31368
üzenetére
overengineeringnek hívják.
a unix alapfilozófiája : KISS. Keep It Stupid and Simple."Természetesen jól működik, csak az egyik esetben erre a bizonyíték a te szavad, a másik esetben meg az, hogy átmegy a működést ellenőrző teszteken": amely tesztek adekvát voltára a bizonyíték a te szavad, de legalább egy rakás melót belefeccöltél.
-
válasz
inf3rno
#31367
üzenetére
Nem egészen. Valamilyen shelled van, tehát annak a használata nem jelent sem addicionális telepítést, sem extra kockázatot. Ellenben ha akár csak pythonban készítesz valamit, akkor kell az intepreter plusz a modulok, amelyekkel megoldod a feladatot - ez mind plusz telepítés és kockázat, plusz ha binárisba fordítod, aránytalanul nagy lesz.
Most is nyomozok egy érdekes, kábé naponta ismétlődő kapcsolat után, aminek nincs tulajdonosa. Megírhattam volna pythonban a monitoringját, de mivel a shell kéznél van és az egész 7 sor, nem vacakoltam vele - pláne, hogy prod szerver.
-
válasz
inf3rno
#31370
üzenetére
Nos, egy otthoni felhasználású scriptet bizonyára automatizáltan szoktak tesztelni.
Amúgy tudom, hogy mi az a szoftvertesztelés, de egy átlagos munkahelyen a sysadminok scriptjeit nem szokás különösebben tesztelni, általában elég, ha jól működnek.
Az előző helyemen meg kötve hiszem, hogy a cég hivatalos belső ellenőrző scriptjei bármilyen tesztelésen átmentek volna, olyan trágyák voltak -
-
kovaax
őstag
válasz
inf3rno
#31013
üzenetére
Na, csak nekifutottam harmadjára is, és kiderült a turpisság. Amikor kiválogatom az Oracle Software Delivery Cloud-ban az iso-kat, akkor szürke marad a Download gomb, ha felé megyek, azt mondja, hogy "The Download manager is not compatible with your environment.". De fönt meg ezt írja: "You may download files: Individually - Click the file name to download". És ez működik.
Szerk.: Lesz Orákli Linuxom, hát én olyan boldog vagyok!
-
Frawly
veterán
válasz
inf3rno
#30818
üzenetére
Nem, a hibás szektor nem jelent rossz kondíciót. Főleg, ha a vezérlő nem detektálta a hibát még. HDSentinel minősítései kb. semmit nem érnek, csak tájékoztató jellegűek. Sokszor irkál totál baromságot. De maga a SMART se ér sokat. Jelezhet előre meghibásodást, de sokszor van, hogy semmit nem jelez, 100%-osnak látszik a meghajtó, semmi hibára utaló bejegyzés, vagy attribútum, erre egyik napról a másikra megdöglik és tégla lesz belőle. A SMART csak egy ilyen +1 védelmi vonal, ami esetlegesen jelezni tud. Plusz ma már egyik tároló sem megbízható, mióta agyonolcsósították ezeket, redundanciának és/vagy biztonsági mentésnek mindig lennie kell, utóbbi még user errornál is jó, ha valaki beszop egy ransomware-t, vagy letöröl/felülír valamit véletlenül, akkor legyen hova nyúlni, ne bőgés legyen, hogy jajjazadataim, azonvoltanemtudomén, pótolhatatlan, brühű.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30818
üzenetére
Hát utal rá, nyilván nem egészséges az olyan kütyü, amin megjelenik 1-2 hibás szektor, de ha poreszt tárol polcon, nem téma, ha pedig logikai rétegekben van megoldva ennek a hibának az áthidalása, szintén nemtéma. Azonnal nem temetném.
Mindjárt megnézem, mennyi a reallocated sector count-om a "gyógyult" HDD-mre.
-
válasz
inf3rno
#30818
üzenetére
Itt nem hdsentinelről beszélünk, hanem olyan szoftverekről, amelyet a gyártó kifejezetten a lemezhez írt. Egy bad sector kutyafüle, átallokálja a vezérlő a spare területről, majd tesz egy SMART bejegyzést, hogy megcsinálta, de addig senki nem foglalkozik ezzel, amíg megy a lemez.
A hdsentinel meg mondta nekem hdd-re, hogy 40%-os, még évekig használtam adatvesztés nélkül.
-
-
Frawly
veterán
válasz
inf3rno
#30378
üzenetére
Értem, szóval a bitflip még mindig urban legend, mindenki hallott róla, csak még senki nem tapasztalta. Amit a képen mutatsz, olyat én is láttam már, az nem bitflip, hanem okozhatja meghibásodott háttértár, rossz letöltődés. Persze RAM hiba is, de nem bitflip, hanem en bloc kaka RAM. Ezért kell CRC-ről meg redundanciáról gondoskodni, mert nem csak a RAM lehet hibás, meg nem csak bitflip fordulhat elő, önmagában az ECC sem tesz csodát, csak plusz egy védelmi intézkedés a sok közül.
Félre ne értesetek, nem az ECC RAM ellen vagyok, ha a platformja támogatja és valaki tud szerezni olcsón (pl. DDR3-ból még olcsóbb is az ECC, mert sok szerverből kukázott RAM-ot árulnak használtan), akkor miért ne, plusz egy védelmi vonal, senkit nem vitt még el a mentő, mert ECC-set használt. Én arról beszélek, hogy ez a divathájp, meg tömegpánik, hogy ZFS, jajjaisntem, csak-ECC, jajjmerhamivanhabitflipvanezeréventeegyszer hiszti csak ilyen marketingesek által felfújt baromság. Nem szabad neki bedőlni, van élet az ECC-n túl is.
-
Frawly
veterán
válasz
inf3rno
#30375
üzenetére
De milyen adatvesztéshez? Tegye már fel itt a kezét, aki bitflip miatt vesztett adatot. Mondom kizárólag bitflip miatt, nem teljesen hibás RAM, bedöglött háttértár, villámkár, kártevő miatt, hanem tényleg csak is kizárólag bitflip miatt. Na, ugye, hogy senki.
Arról nem is beszélve, hogy a tömörített fájlok, médiafájlok (kép, videó, audió), SQL adatbázisok, torrentek, komoly fájlrendszerek (mint a Btrfs, ZFS, és társaik, meg az összes többi fájlrendszer, ami használ tömörítést vagy titkosítást) stb. eleve valamilyen szinten mindig használnak valamiféle CRC megoldást, alapból. Tehát maximum nagyon alap fájlrendszereken lévő plain text fájloknál, és binárisoknál vagy kitéve, hogy a bitflip miatt félremehet valami. De binárisoknál is elméleti az esélye, mert ha egy bit is félremegy, az már másik opcode, azonnal crashel a program, vagy fagy az egész gép, nem marad észrevétlen. Plain text fájlokban, úgy, hogy tömörítve sincsenek, azokban nem tárol senki kritikus fontosságú adatot. Forráskódok általában fent vannak git-en, helyileg pedig megint tömöríteni szokták őket. Így maximum logokról meg CSV fájlokról tudom elképzelni, hogy csak így plain text-ben vannak hagyva, natúron.
-
bambano
titán
válasz
inf3rno
#30244
üzenetére
egy csomó programnál bevezették azt a szokást, hogy nem egy konfig fájl van, hanem egy könyvtárban levő összes fálj konfig(részlet). annak érdekében, hogyha szükség van sorrendiségre, a megfelelő sorrendben olvassa be a konfig részleteket, megszámozzák az elejét, és az alapján sorbarendezik.
-
Krystal_s
addikt
válasz
inf3rno
#30198
üzenetére
Fix asztali gépként van használva. Ugyanúgy, ahogy a másik gép is.....
Írtam már, hogy Windows alatt mindig stabil. Így nem lehet sem antenna, sem Wifikártya hiba. Inkább Linux driver gond... mivel a neten rengetegen panaszkodnak ugyanezzel a problémával.Egyedül még azt nem tudtam megpróbálni, hogy USB-s külső eszközre (pendrive, hdd) kiírom a Linuxot, mert csak notebookjaink vannak és nem tudom lehúzni a hdd-t. Nem szeretném, ha a Grub elrontaná a boot menüt.
Úgy láttam telepítésnél ki lehet választani hova írja a Grubot, de ennek ellenére mégis mindenhol azt írják, hogy ajánlott kihúzni azt a HDD-t, amire már másik rendszer (Windows) van telepítve. -
Krystal_s
addikt
válasz
inf3rno
#30193
üzenetére
Soha nem ugrál Win alatt. Nincs a közelben más Wifi, ami bezavarna.
Nincs meg a 270 sem, csak néha ugrik fel annyira. Most nézem jelerősség 100%, sebesség 1 Mbit/s, aztán 40...
Lementem a másik géphez. Ott stabilan 270 Mbit/s.
Nem értem mi lehet, x-akta. :/
Èn gépemben Intel Centrino Ultimate-N 6300 AGN van, a másikban Intel Centrino Advanced-N 6200. -
Krystal_s
addikt
válasz
inf3rno
#30191
üzenetére
Köszönöm.
Az előbb próbálgattam pár beállítást.
Windowsban látom mennyivel kapcsolódik. Amikor a sebességnél azt írja max 144 Mbit/s, akkor 20 MHz-en megy, amikor max 300 Mbit/s, akkor 40 MHz-en.
Ubuntu 20.04-et néztem... Sosem mutatott 300-at, csak max 270 Mbit/s volt, de az már 40 MHz-en megy.
Folyamatosan ugrál a sebességérték 1 és 270 Mbit/s között. (a jelerősség jó, itt van mellettem pár m-re a Router és Win alatt mindig stabil).
Lehet mégsem a sávszélességgel van a gond.
Úgy láttam kis időre javul a helyzet, ha tiltom a Power Management-et, de egy idő után újra nagyon ingadozik a sebesség 1-270 között.
Ez nem egyedi gond. Egy másik gépemnél (más router) másik Intel Wifivel is pont ez volt pár éve.
A neten rengeteg ilyen panasz van, de még a konkrét megoldást nem találtam meg.Amiket írtak pl sudo modprobe iwlwifi 11n_disable=8 és 2 egyáltalán nem segítettek.
sudo nano /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf
wifi.powersave = 2
elmentettem, de a rendszert nem restartoltam, mert Live... -
Dißnäëß
nagyúr
válasz
inf3rno
#30154
üzenetére
Hááát maradok a saját nyelvén, valami Processing vagy mi, jó lesz az, nem egy nagy rakétatudomány ahogy elnéztem. Egész érthető. Csak kéne egy induló szett
PoE jó dolog, rahedli kis Arudino kütyüt elbír egyetlen kábel, de valszeg valami ultraolcsó kis wifi modullal oldom meg, így egyetlen kábellel végig tudok menni áramellátást illetően a kütyük hadán sorosan, nem kell switch-ből kiindulva csillagpontosan húznom mindenhova 1 tyúkbelet. Előbbi esetben kell a wifi az adatátvitelhez, utóbbi esetben meg PoE miatt magára a kábelre tehetem rá az adatot is, de inkább wifizek, még a többlet költség ellenére is. Szerintem tálcánként - de majd kiadja úgyis a tényleges projekt - elég lesz 1 kisebb Arduino kontroller a "cserepekbe" tett szenzorokat figyelni, de majd meglátom. Jó kis hókamókák ezek. Milyen poén lehet úgy enni valamit az asztalon, mondjuk egy kis tepsis fűszeres burgonyát, hogy a krumpli a saját biokrumplink, amit a kütyük neveltek fel, az ubisali uborkája és fokhagymája dettó, paradicsom, stb. minden az asztalon az "üvegházból" van Nagy álmom így élni. Egyszeri nagyobb költség, de aztán évekig nyugi van. Egy RPi-re már kellene mindig OS frissítés, ez, az, amaz, az Arduino kellően buta ahhoz, hogy 20 év múlva is csinálja ugyanazt, amit ma, zéró logic. Bár egy mai Pi is elvan, de azért ott az OS mégiscsak egy Debian rajta, logolgat, kicsit önállóbb életet él, tényleg nem egy olyan eszköz, amibe beleírod a programot és elvan míg szét nem esik. De tuti lesz Pi is a rendszerben, de szerintem ő csak a fej lesz majd. -
Dißnäëß
nagyúr
válasz
inf3rno
#30150
üzenetére
Úgy van, ahogy a kolléga mondja, határvédelemben kopog az ember.
Kicsiben privátban én is NAT mögött vagyok, van egy olyan-amilyen iptables script-em mégis a linux host-omon, de ennyi. Ha Kína bejönne a Netflix-en keresztül az okostévébe és elkezdené törni a gépem, ne essen el azonnal, kicsit megnehezítem a dolgukat (pár perccel)
Viccet félre, paranoidnak lenni mindig jó és hasznos.
Tanulás: én most meló mellett próbálok tanulni annyi mindent, hogy nem győzöm
Elektronika, frontend, node.js és régi dédelgetett álmom, az Arduino. Akarok egy vagy termőföldes, vagy teljesen hidropónikus minifarm projektet építeni vele, talajnedvesség szenzorokkal meg minden pittyputty-al és mindig azon kattogok, hogy ha már node-ot tudok, akkor miért nem Raspberry Pi-zek, de rájöttem, hogy nem kell nekem OS ahhoz, hogy alap tökautomatizált rendszert építsek fel, ami bekapcsolás után pár mp-el már működik is és ha 20 évig nem update-elem, akkor sem történik semmi. Egyszerű, igénytelen, teszi a dolgát. Szóval maradok az Arduino-nál és majd valamiféle aggregált módon állok hozzá az egészhez, hogy 1 Arduino több szenzort visz, az őket begyűjtő és vezérlő Arduino-k (nem sok) pedig végül befutnak 1 Pi-be mondjuk. Hát ez is egy hosszú út, de legalább látom értelmét. Próbálok mostanság olyat csinálni, aminek van is értelme, nagyon elvesztem az elmúlt években haszontalan dolgokban. Mikrotik lett volna még, de azt is annak gondolom, pedig piszok jó cucc, de többet hoz nekem real-life-ban egy raklap itthon termesztett zöldség, amit automatán öntözök és monitorozok + figyelmeztet egy naptár funkció, ha megérett "aratásra", mint az, hogy most milyen router oszt nekem egy netet. Sajnos egy nap még mindig csak 24 órából áll 
-
Dißnäëß
nagyúr
válasz
inf3rno
#30144
üzenetére
Látom jó kis egészséges vita alakult ki REJECT és DROP körül az általad linkelt fórumon.
man iptables -ben a REJECT target írója Jozsef Kadlecsik, lehet elő tudnád ásni az arcot, ha utánajárnál. Nála lesz olyan infó, ami ÚGY VAN és 100% hihető, feltételezem (ha 1. a Netfilter csapat tagja, 2. ő írta a REJECT-et).De amúgy meg azt is látom, hogy az iptables is kifutó lassan, itt az nftables helyette: [link]
Picit más szintaktika és logika, de többet tud + teljesítményben is jobb. Lehet érdemes lenne erre felülni, mielőtt túlzottan kitanulod az iptables-t. (Én meg ipchains-el szívtam anno sokat és iptables-ön tanultam. Nem kell egyik a másikhoz, most sem kell iptables mester lenni, hogy nftable guru legyél.. ha már kézzel írogatunk)
. -
bambano
titán
válasz
inf3rno
#30138
üzenetére
"Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat.": ha előbb accepteled az establishedet meg a relatedet, és utána dobálod el a synt, akkor nem záródik be.
"csak azokra a portokra tolunk port forwardot, amik a szekvencia részei, akkor baromi gyorsan fel lehet törni.": ez önmagában igaz, csak kopogtatást nem így csinálnak. a szekvencia részeit képző portokra nem kell forward, ugyanúgy dropolod, mint a többit, csak másik ipset-be jegyzed fel.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30138
üzenetére
A második felvetésedre: hááát ez jó kérdés, iptables-ben (vagy még az elődjében, ipchains-ben) volt anno olyan target, hogy REJECT, talán ma is megvan még akármilyen okok miatt, na az viselkedik úgy, hogy elutasításkor visszajelez, hogy "ide nem jöhetsz be" , aminek puszta megtörténte miatt elárulva, hogy ott van gép, port, szolgáltatás, amit lehetne törni. Az akkoriban erre válaszul hozott DROP target már olyan végződtetés, hogy onnan semmi infó nem megy vissza a küldő fele, szóval mintha fekete lyuknak beszélne, DROP esetén nemigen tudja megállapítani, van-e ott valami vagy sem. Még TCP SYN dolgokkal bohóckodhat, de mindenre fel lehet készíteni egy gépet úgy megcsinálva, hogy távolról isten se mondja meg, hogy ott van valami az adott ip címen, hacsak nincs fizikai hozzáférése a network-höz.
Első felvetésed:
Ha csak ideiglenesen van nyitva a port, miután bezáródik, nem fog működni az SSH, mert megszakad a kapcsolat. Vagy valamit nagyon nem értek a hálózati kommunikációból.
Az, hogy egy port nyitva van-e, egy dolog. Arra is kihatásunk van, MIRE van nyitva. Egy nagyonegyszerű csecsemőbiztos példa most így fejből gyorsba, a teljesség igénye nélkül, csak az INPUT chain-re fókuszálva (pedig egy korrekt tűzfalban az OUTPUT is szűrve van, legalábbis akkor, ha magáról a tűzfal gép védelméről beszélünk.. ha a többiekéről, akkor meg a FORWARD mindkét iránya nat mangle és egyéb táblákban is, felhasználástól függően).Tehát egy marha primitív kézi fal arra a host-ra, amit védeni akarunk, és egy SSH-t beengedünk. Illetve a mi saját kimenő csomagjaink visszatérő lábát is
különben semmit nem lehet erről nagyon csinálni azon kívül, hogy egy buta SSH kiszolgáló.
iptables -X
iptables -F
iptables -P INPUT DROP
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j ACCEPTÉs akkor a vastaggal emeltet lehet (igazából erősen illik) cizellálni, hogy source-ot adunk neki, egy adott ip-t vagy ip régiót, satöbbi.
Kérdésedre a válasz a state-ekben rejlik, azaz a 22-es port knocking alatt csukva marad NEW csomagok számára, de természetesen ha egy másik host már sikeresen bekopogott oda és kapcsolódva van, őt egy RELATED,ESTABLISHED szabály beengedi, ami generalizáltan, minden protokollra és minden source/destination portra értelmezve van. (Ezért nem szoktam használni ebben a formában, csak szűkítve, de akkor hasznos).
Ha csak 22-es portra akarunk kétszintű definíciót, ami beengedi a már felépült SSH-k visszatérő lábait, de újakat nem enged be korlátlanul:
iptables -A INPUT -p tcp --dport 22 -m limit --limit 10/s -m state --state NEW -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state RELATED,ESTABLISHED -j ACCEPTEz minden 22-es portra érkező ÚJ kérést úgy enged be, hogy csak másodpercenként 10-et enged ebből, a többit dobja. Minden új kérésre érvényes, de csak újakra. Az alatta levő sor pedig korlát nélkül enged minden 22-es portra beeső SSH csomagot, aminek van egy korábbi kimenő párja a táblákban már, így ha egyszer kapcsolódott valaki, egy SSH fájlátvitel sem okoz limit miatt gondot, bármennyi csomaggal korlátlanul kommunikálhat az sshd-vel.. szóval RELATED,ESTABLISHED lábakat nem szokás (vagy csak nagyon paranoid esetben) limit-el ellátni, burst-re is ügyelve de arra most nem térek ki.
A port knocking NEW-ra értendő, hiszen nem egy korábban kiment csomagra adott válaszcsomag az, ami érkezik és kopogna be, hanem új csomag, amolyan azonosítatlan, követés nélküli akarna bejönni. Őt csak számolni kell, mint kopogásszámot, de dobja is DROP-ra, míg a szekvencia nem teljesül, ergo nem lesz kimenő lába, mindig minden "kopogó" csomag NEW-nak minősül.
Ha ezen dimenzió mentén nézed, máris nem lehet azt mondani, hogy nyitva egy port vagy zárva: van, amire nyitva, van, amire limitáltan nyitva és van, amire zárva.
A limit egyébként hasznos, de érdemes a burst-öt is definiálni az elején, illetve tudni azt, hogy ha a szabályban definiált limitet pont egy hülye bot, vagy akármi lezabálja, Te sem jössz be már
Csináltam egyszer olyat, amikor egy hobbigépem törni akarták (még kezdő szöcske koromban, amikor 22-esre tettem ki SSH-t a nagy világhálóra), hogy láttam a logokban a millió jelszópróbálkozást, auth-ot, úristen mondom mivanitt, bruteforce indult ellenem
és úgy döntöttem, teszek 22-es portra NEW próbálkozásokra egy 3/m limitet, azaz 3 próbálkozás / perc, utána csőváz mindenkinek.1x tudtam belépni, utána kvázi örökre kizártam magam, mert a percenkénti 3-at elérte a próbálkozások száma a botok által, a fal zárt, én meg ugyanúgy kint maradtam egy putty zárás és újranyitás után
Szóval mindenre a limit sem megoldás, de mondjuk túlterhelések ellen egy egészséges mérték beállítása jó lehet, ami azon képzeletbeli határ felett van, ahányan akarnak oda jönni amúgy, botokkal együtt. Meg általában ezek a zombi gépek, botok, akármik többnyire 22-es porton kopognak, tehát ha a 22-est vagy az sshd-ban, vagy iptables-en keresztül nem 22-re rakod ki a publik interfészen, hanem valami tökmáson (1024 felett lehetőleg), az sokat segít. (Persze ne híres port legyen lehetőleg). SSH esetében úgy tudom kell induláskor a root jog, de egyébként ha most IRC szervert vagy akármi egyéb alkalmazást akarnál kitenni a netre, mindenképp 1024 fölé érdemes tenni, mert 1024-es alatti portokhoz root jog szükséges, azt meg nem akarjuk odaadni minden processznek (hacsak fel nem vesz utána nobody-t stb, de az megint más tészta). Azt vettem észre mindenesetre, hogy 22-ről ha elviszed SSH-t bármilyen módszerrel is, drasztikusan lecsökkennek az auth próbálkozások számai. Ez még nem jelent semmit, csak plussz háttérinfó, könnyítünk az sshd lelkén kicsit
Knocking esetén a NEW próbálkozások számát kell nézni, nem a RELATED,ESTABLISHED-eket, értelemszerűen. Utóbbiakból másodpercenként irdatlan sok jöhet és kell is bejönnie, lásd fájlátvitel, így a már felépült SSH kapcsolat nincs elkaszálva. NEW-val meg kopogjanak bátran, akinél teljesül, az eljut a szent grálhoz
-
Dißnäëß
nagyúr
válasz
inf3rno
#30114
üzenetére
Még annyit, hogy nagyon figyelmesen olvasd el stopperos összefoglalóját, amit linkeltem előzőben. Arany
Lesz benne érintve memória is, struktúra is, minden ilyesmi.Nem ez lesz az első 1-2 pool-od ma megkreálva, ami életed legjobban agyonoptimalizáltja lesz
de nem elméleti fizika azért. -
Dißnäëß
nagyúr
válasz
inf3rno
#30112
üzenetére
Így van, csak dedup, amit ritkán ajánlanak hogy használva legyen, totál felhasználásfüggő. Legalábbis ZFS fronton a "földi halandó" ne dedup-al kezdje. Egy médiafájlokat tartalmazó fájlrendszeren, ahol - feltehetően - nincs két egyforma fájl, se alatta lévő blokk, meg úgy semmi sem, teljesen felesleges és memóriafaló. Compression szintén nagyon függ sokmindentől, be is lehet kapcsolva (úgysem tömörít pl. már eleve tömörített fájlokat, lásd megint a híres média fájlok, FLAC-ok, mkv-k, stb), de nálam pl. a fontos fájlokat és vegyesbazár mindenfélémet tartalmazó mirror-on be van kapcsolva, míg a nagy médiafájlokat tartalmazó raidz-men kikapcsoltam már kreáláskor (ez kihatással van nem csak a puszta tényre, hogy tömörítve van-e adat, hanem arra is, hogy a blokkméretek fixek, vagy változóak). ZFS fine tune-ról külön könyvet lehetne írni, ezt sokan mondják és én is így látom.. nagyon mélyvíz és nagyon eltérően viselkedő megoldás ahhoz, hogy csak úgy általánosan egy skatulyába téve kijelentsünk róla dolgokat úgy, mint egy ext4-ről mondjuk. De a generalizálással mindig is gondja van az emberiségnek, törekszik mindenki az egyszerű dolgokra, na a ZFS nem az
De öröm az ürömben, hogy default beállításban is egész vállalhatóan műxik és amire létre lett hozva, az adat integritás garantálása, arra hibátlan. (1 lemeznél tudja jelezni a hibát, 2 vagy több esetén egy raid felállásban már korrigálni is). Az említett COW is fura így megemlítve, ugyanis a zfs alapból cow-s, ez a default másik jellemzője (ezért is SSD barát, ZOL TRIM támogatás hiánya ellenére - de már dolgoznak azon is). Meg nem csak fájlrendszer, hanem logikai kötetkezelő is egyben, kicsit LVM szagú. Dedup nélkül a zfs nem eszik sokat, csak valamivel többet, az ARC miatt (is), de az pl. paraméterezhető, ha a default beállítás nem tetszik, viszont dedup nyilvántartó táblák komplett kiesnek a képletből, default install és használat, pool/dataset creation esetén sincs bekapcsolva, jobbnak látta mindenki ezt off-ban tartani, enterprise felhasználásban egy (vagy több) dedikált storage admin ember már feltehetően még nálunk is jobban tudják, mit csinálnak és miért, ha szakértői a ZFS-nek és bekacsolhatják a dedup-ot.
ZFS-ről csinált egy marhajó összefoglalót stopperos fórumtárs, [link] , aminek már megírtam egy 2., gyakorlati részét jómagam, majd hamarosan publikálom talán. Lesz benne kicsiben is, VM-ben elpróbált játékok, meg a saját nagyobb példám is. Valamikor..
Nálam itthon 24 terányi diszk van különféle konstellációkban ZFS-re befogva, eddig nagyon elégedett vagyok vele. Nemsokára jönnek a cache drive-ok is, két enterprise grade SSD személyében, szóval egy egész pattogós házi storage motyó áll össze, de most sem panaszkodom. Talán idén át tudom a mostani workstation PC-met konvertálni egy igazi komoly storage vassá, egy új rack házikóban, ez még a jövő zenéje.
Az ARC mérete általában a rendelkezésre álló RAM /2 -ig mehet max, nálam most reggel óta van bekapcsolva a gép és 32G RAM-ból 5.76G foglalt, ebből a linux szerint 1.5G a buffer/cache és mérete a ZFS-ről történő olvasás és ráírás ellenére nem látszik változni perpillanat.
-
Dißnäëß
nagyúr
válasz
inf3rno
#30066
üzenetére
Igazából aki "komolykodni" szeretne, annak csak arra jó bármiféle Media Markt-os konzumer csicsarouter, hogy gigabit portok, meg modern wifi képességek, mert 3 kattból van nete. Komolyabb célokra dedikált gép kell, szokták emlegetni a Mikrotikot is, nekem spec. nincs kedvem megtanulni, szoptam már annyit Linuxon pppoe-vel, hogy mára már ne jelentsen gondot Linuxból fasza router-tűzfal-vpn-koncentrátort építeni, meg ilyen mindenes házi vagy irodai szervert. Nálam is kényelemből van az ASUS a hálón, szemezek is már egy kis passzív mini ITX motyóval, hogy végre megszabaduljak tőle mint router-től (és akkor marad a wifi része butában). Csak mindig van az embernek valami sokkal fontosabb projektje is
-
Dißnäëß
nagyúr
válasz
inf3rno
#30064
üzenetére
Hát OpenWRT-t nem ismerem, DD-WRT-ztem régen egy Linksys WRT54GL-el, most meg egy korszerűbb ASUS-ra tettem fel a "Padavan" féle firmware-t, mert a gyári kicsit bugos itt-ott, ez meg enged parancsokat szkriptből lefuttatni magán, akár többet is, szóval jó.
Szerintem bármilyen Linux alapú motyón megy a dolog.
Nem kell amúgy egy nagy darab tartományra beállítanod a port fw-ot. Elég csak azokra a konkrét portokra, amiken kopogást vársz
és amíg nem a megfelelő sorrendben történik ez meg, onnan is leesik mindenki, tehát a külvilág felől az látszik, hogy nincs reakció. Én nem adnék meg egész tartományokat port fw-nak.
-
F34R
nagyúr
válasz
inf3rno
#29927
üzenetére
FreeBSD van ellatva a legjobban a driverek tekinkteteben, meg talan a Dragonfly BSD. Utobbi jobban szerverre valo. Egyebkent en hasznaltam mar FreeBSD-t desktopon is.. El lehet vele lenni de nem alomszeru, ezt is kell baszogatnod hogy elegedett legyel vele. A lassu fetching rakfeneje a nagyon szornyu mirrorok, de ha egyet eltalasz akkor marha gyorsan tudsz csomagot telepiteni es frissiteni.. A masik hatranya a filerendszer inkompatiblitas. Linuxos filerendszert csak read-only-ba tudod ext2 folott, nativan. Onnantol meg fuse. [link]
Mi az elkepzelesed egyebkent? mi a celod a szerverrel?
-
samujózsi
senior tag
válasz
inf3rno
#29902
üzenetére
Alpine eddigi ismereteim szerint nem szerverre való. Inkább beágyazott rendszerek alá és konténerekbe (lxc, docker) - tévedés jogát fenntartom ugyan, de mikor rájöttem, hogy az ArchLinux a rolling release és az ezzel érkező esetleges gondok miatt nem túl nyerő, az Alpine-t kezdtem volna nézni és akkor futottam egy ilyen kijelentésbe, sajnos nem írtam fel, hogy hol. (pro/kontra tud valaki bővebbet?)
-
válasz
inf3rno
#29844
üzenetére
Noh, újabb fejlemény: az alap security hagy kívánnivalót maga után, a halt, reboot, poweroff parancsoknak nem kell megadni a jelszavadat sudo után - me még van egy rakás egyéb kivétel a /etc/sudoers.d/ alatti fileokban. Szóval továbbra is az a véleményem, hogy szervernek csak LAN-on alkalmas komoly hardening nélkül.
-
leviske
veterán
válasz
inf3rno
#29877
üzenetére
A lutris kifejezetten windows-os játékok telepítését segíti. Olyan scripteket tartalmaz, amik automatikusan leszedik a lauchereket (Battle.net, Uplay, egyebek) és leszednek egy rakás extra függőséget, amik a közösség szerint szükségesek a játék futtatásához. Ráadásul grafikus felületen Te magad is tudsz a beállításokon módosítani.
A Wine telepítése szükséges hozzá, hacsak nincs felrakva a Steam a Protonnal.
(#29878): Én használtam, mert a Witcher 3-at Steam Play-en toltam. Mostanra hozza aránylag azt a szintet vele a játék, mint amit Windows-on. Viszont nem Steam-es cuccokat szerintem nem annyira triviális futtatni rajta, pláne Lutris nélkül.
Egyébként van játék fokusszal rendelkező Linux topik, csak nem fájóan népszerű és az első hsz még nem lett kidolgozva.
Otthonra egyet értek amúgy a BSD alapú megoldásokban. 
Mert tök jó, volt itt szó libekről, meg mindenről, de hogy te miben akarnád megírni a dolgot arról nem.
.
Új hozzászólás Aktív témák
Hirdetés
- sziku69: Fűzzük össze a szavakat :)
- Nintendo Switch 2
- Kuponkunyeráló
- Formula-1
- PlayStation 5
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Genshin Impact (PC, PS4, Android, iOS)
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Kertészet, mezőgazdaság topik
- Barátokká váltak az eddig rivális AI-óriások
- További aktív témák...
- Bomba ár! HP EliteBook 820 G2 - i5-5GEN I 8GB I 256GB SSD I 12,5" FHD I Cam I W10 I Garancia!
- 129 - Lenovo Legion Pro 7 (16ARX8H) - AMD Ryzen 9 7945HX, RTX 4080
- Azonnali kézbesítés az év bármely pillanatában
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X3D 32/64GB RAM RX 7800 XT 16GB GAMER PC termékbeszámítással
- Bowers/Wilkins PX8 fejhallgatók (dupla Bluetooth eszköz csatlakoztatása!) - ELKELTEK
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged