- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Android alkalmazások - szoftver kibeszélő topik
- VoLTE/VoWiFi
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Szívós, szép és kitartó az új OnePlus óra
- Samsung Galaxy Watch (Tizen és Wear OS) ingyenes számlapok, kupon kódok
- CMF Phone 2 Pro - a százezer forintos kérdés
- Egyszerre legnagyobb és legkisebb is a Garmin Venu X1
- Mobil flották
- Samsung Galaxy A52s 5G - jó S-tehetség
-
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
-
-
Dißnäëß
nagyúr
válasz
samujózsi
#29774
üzenetére
Természetesen
de egyből overwrite kérdés, majd másol és a végén a hiba, hogy nincs joga (még szerencse, root-ként képes lenne felülvágni).. 
1 fájllal.
Ha viszont 2+ fájllal csinálom ezt, vagy fájlok-könyvtárak vegyesen, devnull már nem is adható meg, mert eleve ugat, hogy könyvtárat kér
-
Frawly
veterán
válasz
samujózsi
#29742
üzenetére
Egyrészt az épp aktuális DDR RAM specifikációkba is be van építve némi hibakorrekció, másrészt a bitflip annyira ritka, hogy csillagászatian kicsi az esélye, nincs gyakorlati jelentősége. Főleg nem egy otthoni NAS-nál, max. csak bankoknál tudnám elképzelni. Meg ha kormánytitokról van szó és az űrben vagy (pl. ISS), és az ionizáló sugárzás miatt ki vagy téve ennek.
Nem csak velem nem fordult elő még ilyen RAM bithiba, de senkivel akit ismerek, vagy olvastam volna róla. Olyanom volt már, meg másnak is, hogy RAM hiba, de az nem bithiba volt, hanem vagy halódó RAM fizikailag vagy halódó alaplaphiba, és nem ilyen bitátbillenésben jelentkezett, hanem komplett memóriarégiót adtak vissza teljesen fals adattömböt, rövid távon csonttá fagyott a gép vele, vagy lépkedtek ki az alkalmazások összeomlással, meg tömörített fájlok kivétel nélkül sorban dobták a CRC hibát, szóval sokkal konzisztensebb, durvább, észrevehetőbb.
Ez az ECC RAM is csak ilyen cégek pánikoltatása elméleti gyengeségen, ugyanolyan ultraparanoia, mint egy HDD-t 100× felülírni /dev/random-mal. Jajj, hú, mert mi van ha bithiba, vége a világnak. Közben meg ha egymillió évenként be is üt egy ilyen bitátbillenős RAM hiba valakinél, akkor sincs gyakorlati jelentősége, mert a fontos adatokat kezelő szoftverekbe, meg az általuk kezelt adatfájlokba és adatbázisokba is be szokott lenni építve külön hibajavító és hibafelismerő mechanizmus, checksum, konzisztenciaellenrőzés, hibajavító bit, stb., meg korábbi backupokból is ki lehet okoskodni, azaz a hibát több rétegben is lehet javítani. Tehát semmi tragédia nincsen, ha nem ZFS meg ECC RAM van a rendszer alatt.
Ez tipikusan megint olyan hype-paranioa, amivel az öltönyös-nyakkendősök egymás tudják szivatni, hogy jajj, nem secure, meg nem minősíthető, mert hű, ha egy bithiba is, hőjjjj, akkormilesz, mindmeghalunk. Közben meg semmi nem lesz, ugyanolyan elméleti vita, mint hogy egy képzeletbeli küzdelmet Bruce Lee vagy Superman nyerne meg, gyakorlatilag meg ugye egyik sem, mert Chuck Norris mindkettő valagát szétrúgja egy pörgőrúgással (két legyen egy csapásra módon) még az összecsapás előtt, és a mérkőzés elmarad.
-
Frawly
veterán
válasz
samujózsi
#29641
üzenetére
Én is keepassx-et használok. A titok, hogy online nem szinkronizálom, hanem helyileg használom linuxos PC-n, meg androidos okostelefonon, az eszközök között kézzel másolgatva a .kdbx fájlt. De erre is csak azért adtam a fejem, hogy multiplatformos legyen, mert ha csak PC-n kéne, akkor simán egy titkosított LUKS vagy VeraCrypt konténerbe vagy titkosított 7-zip-be beletennék egy közönséges jelszavaim.txt fájlt (plain text, UTF-8 kódolás, \n unixos sorvég), 30 karakteres AES256 master jelszóval védve, és ezt vagy felcsatolnám, vagy ramdrive-ra bontanám ki és cat-tel listáznám és ed-del szerkeszteném, hogy a rendszeren semmi nyoma ne maradjon, se backup fájlban, se logban, se semmiben, historyt kell csak üríteni. Csak ez okostelefonon az Android meg a tapicskaképernyő miatt nem lehetséges.
Korábban úgy voltam vele, hogy nem vagyok gyépés, nem ülök fel a hájpnak, nem kell nekem password manager, fejben tartom a jelszavakat, csak úgy egy éve a városban ügyintéznél be kellett volna lépnem az egyik mailfiókomba, ahonnan kellett volna valami, igen ám, de nem emlékeztem a jelszóra, és a meglévőt nem akartam jelszónullázással széjjelqrni, elég kellemetlen volt hazautazni megnézni otthoni gépen. Így beadtam a derekam, és elkezdtem Keepass-t használni.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29749
üzenetére
Nem mondom, hogy nincs igazad, de én úgy tudom, 1 drive mellett nincs zfs integritás-kezelés még. Nemrég rágtam át magam n+1 doksin és leíráson, szerintem kell hozzá a kettő. De megoldható 1 drive-on valahogy, valami nyakatekert trükkel, lehet. Csak úgy out-of-the box nem.
Zfs-en már az is előny, hogy az ellenőrző blokkok nem ugyanott vannak, mint egy dm-integrity esetén az adott adat blokkban, hanem máshol, így ha adat blokk sérül (jó eséllyel fizikai hiba miatt), annak az ellenőrzője nem ott lesz és ha van másik adatblokk +1 diszken (és annak ellenőrzője), 3-ból már egyértelmű, mi a jó és mi a rossz.
De 2 diszkkel nem csak redundáns, hanem golyóálló is lesz a motyó, az biztos
Amúgy lehet ECC nélkül is élni, de nonstop bekapcsolt gépnél sok csillagnak kell úgy állnia az égen, hogy nagyon ritkán történjen bithiba. Mindenesetre jó cucc, egy ASUS lapban Ryzen 3500-el most állok át ECC-re. (Szívom is a fogam, tuning RAM-ok ki, szottyadt 2400-asok be aranyáron, de legalább ECC, majd ellenőrzöm is, ha kicsit túl feszesre veszem gyáriról a timing-okat, ahol már kezd hibázgatni, hogy hogyan viselkedik).
-
haddent
addikt
válasz
samujózsi
#29721
üzenetére
Minden esetben, jelenleg is saját dns -t használok vele. Mi ezzel a probléma? Arch -on van egy systemd-networkd és egy másik ami netctl használ, egyiknél sincs probléma, nem nyúl soha hozzá az /etc/resolv -hoz. Ha szerverre gondolsz, az is van, bind szerver, ahhoz sem nyúl.
Melóban Suse esetén meg úgyis az a bánat Yast kezel mindent
Igen, na ez jogos. Szeret várakozni 1-2 percet ha megrogyik valami requirement boot során. Utána viszont ad egy recovery root shellt aztán uccu. Én ezt eddig nem tapasztaltam a kellőnél irritálóbbnak, hogy őszinte legyek, de igen, ez lehetne jobb -
-
Jester01
veterán
válasz
samujózsi
#29666
üzenetére
Például az /usr az read-only így ha valami telepítő gonoszkodni akar, nem tud. (Ideális esetben a / is az lenne.) /usr/local is jó ötlet ha szoktál magadnak dolgokat telepíteni. Olyankor elég azt átmenetileg olvashatóra csatolni és megint nyugodt lehetsz, hogy az /usr-t nem írja felül. A /var az néha meg szokott telni logoktól, sokkal jobb, ha nem tölti meg a többit is. A /tmp az mehet ramdiszkre.
-
haddent
addikt
válasz
samujózsi
#29666
üzenetére
Nincs. Ahogyan (szerintem) ma és már jó ideje a swap partíciónak sincs létjoga. Ahogy te magad is írtad, backup-restore, vagy akár másik gépbe betéve, bármi.. PCI -os SSD -k korában élünk, percekről van szó. Sokkal többet ér egy heti/napi mentés valami (privát) felhőba tgz -ben aztán viszlát
-
válasz
samujózsi
#29671
üzenetére
MX ment a helyére. Több évig szolgált a Debian, a distrohopper időmnek már vagy 10 éve vége, de nincs kedvem megvárni, amíg pöcstering elkezd hozzábaszakodni a /home-hoz is.
Nem mellesleg a megtartott /home szolgált Linux Mint, Debian 9/10 és most MX alatt is, keveredés nélkül.
-
growler
őstag
válasz
samujózsi
#29668
üzenetére
Pár éve úgy megborítottam a rendszert, hogy csak az újratelepítés jöhetett szóba.
Volt /home partícióm - ez megmaradt - a / partíciót pedig a megborítás előtt nem
sokkal a belakott rendszerről készített és kiírt Systemback .iso-val telepítettem
újra. Nem kellett lementeni/másolgatni semmit - 1 az 1-ben visszakaptam a
régi rendszert. (Persze, ilyesmit nem túl gyakran csinál az ember.) -
haddent
addikt
válasz
samujózsi
#29641
üzenetére
Kipróbáltam nem egyet, természetesen szigorúan self-hosted változatban és egyértelműen a Bitwarden-RS a legjobb. A Bitwarden önmagában egy szolgáltatás is tud lenni távoli szerveren (egyébként így is biztonságos, hiszen a tömény brutális privát kulcsod csak nálad van meg..), de van self-hosted verzió. Sajnos utóbbi sok komponensből áll, bonyolult, nem túl gyors, szóval otthoni felhasználásra (sem) az igazi, szerintem. Viszont létezik egy Rust nyelven újraírt változata, a Bitwarden RS.
Na ő self-hosted, nagyon egyszerű, nagyon gyors, nagyon biztonságos. Működik a hivatalos Bitwarden kliensekkel, amik ingyenes elérhetőek iOS, Android, Win, Mac, Linux tehát minden alá. Szinkronizál, telefonokon ki tudja váltani a gyári beépített pass managert (pl. ios -en faceid -val nyílik, alapból oda ment mindent nem az icloudba stb.)samujózsi a "matemágiában" (ahogy a laposföldiek hívják) akkor érhet meglepetés, ha hülye vagy (nem te, értsd jól). Mindig akkor bukott 1-1 nagy cég aki elvileg komoly kódolást használt, amikor pl. a random seed mondjuk úgy, hogy egy statik "n4gY0nR4nd0mCuCCczzz" volt, lásd Sony
-
Frawly
veterán
válasz
samujózsi
#29633
üzenetére
Nem szűkösek, mert tiling WM köré is tudzs Gnome ökoszisztémát építeni. A Gnome-ban eleve lecserélhető a Mutter nevű WM-jük. De akármilyen tiling WM köré is tudod ugyanazt a Gnome panelt, Gnome alkalmazásokat és appleteket tenni, futtatni, ugyanazokat a billkombókat beállítani.
Amiről itt a végén írsz, azt minden grafikus felület, DE, WM tudja. Az ablak bal felső sarkában lévő ablakgomb egy menüt hoz elő általában, és ott be lehet állítani az Always On Top funkciót, akkor nem tudja kitakarni semmi. De ez csak félmegoldás, mert az ilyen alkalmazást ugyan nem takarja semmi, de ő maga viszont takarhat olyat, amit nem kéne neki. A tilingozás az egyetlen normális megoldás erre, pont erre is van kitalálva.
A Chrome/Chromium meg egy nagy rakás kula. Nem csak amiatt, hogy elveszi a rendes ablakkezelő funkciókat, ez is felesleges hibája persze. Ennek ellenére van rá workaroud, a WM-ben beállítasz az Always On Top funkcióra gyorsbillentyűt, és azt nyomkodod.
-
samujózsi
senior tag
válasz
samujózsi
#29633
üzenetére
Ma is tanultam valamit...
Ha nem is pont az, amit akartam, de így is elmegy:
(csak példa - a "Super"-ként hivatkozott bill. nálam a Windows gomb)
Böngésző -> Super+Jobbra, terminál -> Super+Balra. Így felosztják egymás közt a desktopot, vertikálisan maximalizálva, horizontálisan 50%-ra "maximalizálva" az ablakot.
És itt jön a poén: ha az egyik ablakot horizontálisan átméretezem, akkor a másik is megy vele.Na jó, ez inkább a kezdőbe való, csak azért ide írtam, mert itt kezdtem kérdezni.
Sajnos az xrandr nem működik laptop kijelzővel.(#29634) sh4d0w
Nálam nincs ilyen és úgy emlékszem, már a unity is mellőzte ezt az opciót.Szerk: helyesbítek, alapállapotban nem volt ilyen. Kiválasztva a "Use system title bar and borders"-t már van, csak nem tudok visszaváltani az eredetire...
-
Frawly
veterán
válasz
samujózsi
#29627
üzenetére
Ezt a koncepciót hívják tiling-nak. Pont ez a lényege, felosztod a képernyőt egymást nem takaró régiókra, úgy, hogy ki van használva az egész képernyőterület. Erre a felhasználásra van kitalálva, amit körbeírtál, hogy a böngésző mellett még más alkalmazások ablakait is teljesen lásd. Elég hatékony tud lenni, ha tényleg nagy a monitorod felbontása.
Nem csak fele-fele alapon lehet felosztani, hanem mindenféle felosztásban, függőlegesen, vertikálisan, akármilyen arányban, vegyítve is a felosztásokat, bináris fa, fibonachi elrendezés, master-stack és egy csomó megoldás van rá, tiling WM-ek általában ezeket tudják, lehet váltogatni e felosztási sémák között, akár menet közben is folyton átvariálva.
A tiling WM-ekből is van kétféle. Az egyik a dinamikus tiling, amikor előre programozott sémák mentén nyílnak eleve a progik, egyfajta előre eldöntött szisztéma szerinti felosztásban, amit te váltogathatsz is. A legtöbb tiling WM dinamikus, nem is sorolom fel őket, mert lényegében szinte mind az.
A másik fajta a manuális/kézi tiling, amikor az adott alkalmazás megnyitása előtt te mondod meg, hogy majd milyen régióba kerüljön, nem egy séma mentén megy. Ilyen tiling WM-ből kevesebb van, a legismertebb az i3wm.
-
#63718632
törölt tag
válasz
samujózsi
#29627
üzenetére
Ha az egyik ablakot kihúzod jobbra középre, a másikat balra középre a monitor széle felé markolással. Nem az lessz ami szeretnél? Két ablak függölegesen, szimmetrikusan illesztve,megfelezve a kijelzőt. Ehhez nem kell virtuális asztal sem.
Ezt mindegyik DE ablakkezelője tudja, max nem default, de biztos be lehet állítani. -
haddent
addikt
válasz
samujózsi
#29620
üzenetére
Lehet, hogy irreleváns, de én pont azt figyeltem meg 1 hónapja, hogy az egyik hdd magától kikapcsolt, jobban mondva a mount eltűnt és az lsblk sem látta, mint device. Sata áram ki/be megoldotta, és működött is rendesen pár órát, de megint .., indokolatlanul. Az a poén, hogy "érzésre" ilyenkor is pörgött és működött. Gyanúm szerint haldoklott valami, mert kicseréltem egy másik hdd -re, minden egyéb beállítás, mount, minden azonos és megszűnt a probléma
Bár ilyen hdd pusztulatot még sosem láttam. Zörögni, csörögni, lassulni, hibázni szoktak, mindezt jó sokáig (mármint napokban-hetekben mérhető), majd használhatatlanná válni. De ilyet.. fura
-
haddent
addikt
válasz
samujózsi
#29612
üzenetére
Jester01 köszi mindkettőtöknek, akkor gyanítom az történt, hogy a játék végeztével rátoltam egy "pi*&#ba mindent on" és ez lett a vége
Már csak azt kell megtalálnom mi a bánatért nem marad offon reboot utánIlletve ha jól látom, akkor a GSO samunál nem szerepel (tehát on gondolom?), nálam meg off [requested on] nem igazán tudom értelmezni, de gondolom az is on akar lenni. Lehet, hogy azt visszabillentem akkor
-
AcCEsS
senior tag
válasz
samujózsi
#29528
üzenetére
Ezt a megoldást valahol olvastam én is, de sajna nincs Xwrapper.config fájl. Egyébként Raspbian fut rajta, ami egy minimálisan módosított Debian, abból is a legújabb, a Buster. Az alaptelepítésben egyébként Raspbian Lite verzió volt (ami nagyjából a Debian Netinst-nek felel meg), arra húztam fel az xserver-xorg + xinit + raspberrypi-ui-mods csomagokat a szükséges függőségeikkel együtt. A raspberrypi-ui-mods egyébként egy openbox alapú Pixel nevű minimal grafikus környezetet rak fel. De ez ebből a szempontból mindegy lenne, mivel ugyanolyan átlagos desktop linux. A monitor előtt ülve a startx a szokásos módon elindítja a grafikus asztali környezetet, na, én ugyanezt szeretném távolról ssh-n keresztül véghezvinni mindenféle forward nélkül. Csak fusson a lelkem a helyi gépen / monitoron.
-
bambano
titán
válasz
samujózsi
#29517
üzenetére
valóban nem.
ha rendesen összerakták a csomagmenedzsmentet, akkor fel lehet rakni egy lib-ből több verziót.
attól kezdve pedig a linker paraméterezése dönti el, hogy melyikkel használod. docker mániások nem szokták tudni, hogy a konténernek ezt az "előnyét" secperc alatt meg lehet oldani konténer nélkül is. -
haddent
addikt
válasz
samujózsi
#29510
üzenetére
Ja sry, senki. Soha a büdös életben nem lesz rendes helyen productionben sem rolling sem pedig non-enterprise linux. Egyetlen harmadik út van: saját, belsős disztro
Random mindfuck: tegnap kiadtam egy pacman -Syu -t 2 hónap után. Hát mondjuk úgy, hogy a csomagok számából ítélve már kerestem a boot usb -t chroot -hoz, mire megtaláltam felállt a htpc, az összes kvm vm meg minden. Néztem nagyot
-
-
válasz
samujózsi
#29506
üzenetére
Az éles rendszer az több ezer node is lehet, tökéletes teszt nincs, főleg nem gyorsan. Célszerű nem cserélni csomag verziót ha nem feltétlen kell, mert túl nagy a veszélye, hogy nem lesz kompatibilis. Csak security patchet érdemes szállítani. Arról nem is beszélve, hogy a saját rendszernek is elképzelhető, hogy több verziója fut.
Ideális esetben a saját kód lesz igazítva az alaprendszerhez. Ha ez nem megoldható akkor jönnek a workaroundok, backportok.
-
haddent
addikt
válasz
samujózsi
#29490
üzenetére
A suse nem rolling, csak van rolling IS. A Leap 15.1 sima LTS, a Tumbleweed a rolling. Attól függetlenül, hogy rolling amennyire tudom elég megfontolt lépésekben halad. Ettől tényleg kár tartani. Arch -tól jogosan tartasz, minden pacman -syu és reboot után kicsit szurkolni kell, nagy ritkán néha helyrerakni, oszt?
-
Frawly
veterán
válasz
samujózsi
#29478
üzenetére
Celeron meg Celeron között óriási különbségek vannak, de a 8 GB RAM-ból úgy tűnik, hogy egy modernebb, DDR3-as vagy DDR4-es rendszer, arra mehet az Ubuntu 18.04 is. De én mindenre Archot teszek, ami támogatja, akár in production szerverre, akár hobbi kenyérpirítóra. Semmilyen gond nincs a stabilitásával, főleg nem szerverre, amikor úgyis csak egy kernel, konzol, tűzfal fut, meg néhány szerver daemon, de nem futtatsz rajta grafikus felületet, meg egy csomó sallangot, így nincs is nagyon mi eltörjön.
A Debian Testinget rég nem néztem, de az Arch stabilitásával semmi baj nincs, én kapásból feltenném mindenre, ami architekturálisan támogatja, akár csak az Arch32-őt, vagy Artixot, és nem túl lassú rajta.
De a szerver is relatív fogalom, milyen szerver, milyen protokollokon szolgál ki, milyen gépeket, hányat? Helyi szerver vagy netre van kötve? Elég sok tényező van.
(#29479) haddent: az Arch komolyságával nincs semmi gond. Vállalatoknál azért nem szeretik, mert sok helyen nem ismerik, nincs hozzá annyi beginner leírás, mint a szokványosabb disztrókhoz, nincs vele tapasztalat annyi évtized, mint a már befutott Ubuntu, Debian, akármi disztrókkal, és az Arch mögött nincs semmilyen corporate háttér, hogy fizetős támogatást, vagy bármi garanciát tudnának hozzá venni. Semmi LTS meg egyéb nincs belőle, sőt, kapaszkodj meg, támogatás sincs hozzá, nem hogy 5-10 év, de 0 év sem. Magadnak támogatod. Ha nem ért hozzá valaki olyan szinten, hogy nem tudja magának támogatni, akkor tényleg ne tegye fel, telepítsen helyette Ubuntut.
A cégek, szervezet egyszerűen konzervatívak, lusták, rugalmatlanok, se frissíteni nem szeretnek, inkább beragadnak egy régi technológiába és egész addig halogatják a frissítést, amíg csak lehet. Ilyen mentalitással nem is való az Arch, nem is annak a hibája, ha valaki nincs rá megérve. Akkor tényleg nem jó ötlet erőltetni.
-
haddent
addikt
válasz
samujózsi
#29482
üzenetére
Nézd ez nem kérdéses, hogy egy LTS enterprise háttérrel bíró disztro az nagyobb nyugodtság sokaknak, mint egy Arch rolling bleeding edge cucc
De... ennek ellenére, én speciel jobban elvagyok Arch-csal, viccen kívül. Minden másnak, pl suse, centos, ubuntu vannak olyan irdatlan disztro-specifikus fa#*@!ágai, amiket nem csipázok, főleg, hogy jól láthatóan a "vanilla" tök jól, jobban működik és így... demiiilllyyjért?!
Illetve amikor beüt a krach, akkor tudom, hogy mivel és hova kell nyúlni.
Amúgy nem kötekedés meg semmi, de szerintem suse esetén valamit benézhettél, nem lenne alapvetően indokolt, hogy többet egyen bármi másnálvargalex semmi nem hatja meg, tényleg. Volt 2 proci csere, 3 NIC csere, ram össze-vissza, ssd amin van volt, hogy live!!! futó rendszert önmagával átt dd -tem egy másik ssd -re, majd csere és a klónt használom most is
Vicc, imádom 
-
válasz
samujózsi
#29482
üzenetére
Fedora szerver nem jöhet szóba? Hatalmas az image, de nagyon jól teszi a dolgát nálam (dedikált szerverek). Selinux van, de nem kötelező használni. Stabil és friss csomagok vannak, csak egyszer futottam bele, hogy a grubot kiadták hibásan, ezért nem frissült a kernel lista.
Vagy az, vagy Alpine, vagy Ubuntu Server.
-
haddent
addikt
válasz
samujózsi
#29478
üzenetére
Természetesen semmilyen komoly helyen nem használnak Arch -ot productionben. A tipped, hogy Debian testing szerintem nem jó. Egyik oldalról valószínűleg a Debian testingnél is még sokkal gyorsabb, frissebb csomagok vannak benne, másik oldalról viszont sokkal jobban karbantartott, nagyobb, érdeklődöbb közösség által. Mondjuk így "szumma kábéra" lehet pont kijön.
Arch esetén egyébként pacman -t kell kicsit megtanulni, ezen felül minden alapvető dolog (is) vanilla.Nyilván neked kell tudnod dönteni, én jó szívvel ajánlom az Archot szervernek is, nálam lassan 3. éve fut gond nélkül. Pár havonta nagy update esetén előfordul 1-1 kernel panic, mert 1-1 csomag nem érzi jól magát a többi közt, ilyenkor chroot, eggyel régebbi package fel, aztán megy minden tovább mintha muszáj lenne neki
Általad is leírt szempontok miatt (is) nálam ő a baremetal host, rajta vannak a kvm -ek, docker mindenIlletve alternatívának én valami valódi enterprise server os -t választanék már, pl. openSUSE, redhat, centos. Mi/én most melóban is openSUSE mellett döntöttem, saltstack is tök jól integrálódik stb.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29464
üzenetére
Én is ipchains, de folytattam kézzel netfilterrel, nem is értettem jópár rajzig, mi van
Ezt is átbújtam töviről hegyire anno.. azért itt sokminden ülepedett.De amúgy ma már annyira komplex a védelem mint olyan, hogy túl időigényes kézzel tolni, absztrakt réteget kényelmesebb nyomkodni, egy ideje ismerkedek az OPNSense-el egy VM-ben, hát GUI ide vagy oda, van egy logikája...
-
Dißnäëß
nagyúr
válasz
samujózsi
#29460
üzenetére
Én mai napig iptables-t használok, kézzel, bár az ufw könnyít(het) dolgokon.
Csekkold az iptables-persistent-et
(apt install iptables-persistent), /etc/iptables könyvtárba kell és lehet a meglévő ruleset-et kitenni rules.v4 és rules.v6 fájlokba (legalábbis nálam spec, bár v6-ot nem használok sehol, így üres), iptables-save > rules.v4, ip6tables-save > rules.v6 és ezeket utána minden boot-nál tölti szépen be.Mr. Dini: iptables -Lcsak a filter tábla szabályait mutatja mindig, defaultban a filter-en mókol, Neked pedig a nat táblában is kell ügyködni. Tehát iptables -t nat -L |less és ha az is üres, akkor kvázi nincs se nat, se csomagszűrés, se semmi, feltételezhetően policy-k is ACCEPT-en mindenhol, magyarul nyitott, default tűzfalad van, azaz bocs, nincs.
Gyorsan guglizva egy jó tutorial, a csomagok útja a kernelen keresztül ascii ábrácska arany.
[link] -
válasz
samujózsi
#29460
üzenetére
Fogalmam sincs, amit írtam, az iptables-re vonatkozik. De egy szösszenet:
Firewalld currently does not support outbound rules to the same capacity of inbound rules. Limitations include things such on ipsets, service names, and default outbound block by default rules required by standards such as NIST 800-171 and 800-53. Default block all needs to be done at the "raw" IPTables level via the --direct flag, and with the order of operations FirewallD uses to prioritize Rrules, rich rules, direct rules, it may be easier to enter all rules for outbound via --direct or use iptables (netfilter-persist)
-
Dißnäëß
nagyúr
válasz
samujózsi
#29446
üzenetére
Ha megmondod, melyik típus, lehet tudok egy jobb formware-t is ajánlani Neked.
Enyémen Padavan becenevű van egy fél éve, toronymagasan veri a gyárit, pedig az sem volt rossz (sőt). Esetleg guglizd körbe. Annyi, hogy ha ASUS-nál regisztált dinamikus DNS-ed van, az ugrik az új firmware-el, nem hajlandó felvenni a gyári fw-el beállítottat. Vagy ASUS Support-al kell töröltetni, vagy elfogadni, hogy elég kretén megoldás. (És a supportot elérni is elég kretén náluk, sajnos). -
Dißnäëß
nagyúr
válasz
samujózsi
#29429
üzenetére
Szia, ha mindent és mindenkit be szeretnél terelni proxy-ba, úgy, hogy ne kerülhessék meg, én úgy csinálnám, hogy:
- transzparent proxy setup, 80, 443 kienged, meg még amit akarsz-akarnak az appok, persze proxy-tól függ, utoljára a tintahallal mókoltam ilyet, annak konfigjában is kellett túrni, hogy ő most transzparens proxy ezentúl
- böngészőkben így semmit nem kell állítani, extra portokhoz kellhet külön SOCKS5 proxy esetleg..
- iptables-el natolva vannak a kliensek gondolom, nat tábla FORWARD láncban tiltani a forgalmat kifele, akár az egészet, akár csak bizonyos portokat, de inkább az egészet és akkor csak lyukat ütni annak, amit elérhetnek a kliensek
- B opció, talán csinosabb is, bár nem annyira paraméterezhető akkor a "szűrés", hogy C osztályú hálón ülnek a kliensek mondjuk, de nincs semmi nat-olás és nincs routing-juk a net irányába, nincs gateway-ük, csak egyetlen gépnek, amit - természetesen - látnak. Ezen fut a proxy, aztán hajrá.
A fix gép lehet egy mondjuk 0.1-0.10-es fix ip tartományú régióból valami, amit "papíron" tudsz követni (MAC cím alapú DHCP által osztott-at szoktam én csinálni amúgy, de ha fontos szerverek, ne függjenek a dhcp szerver leállásától, inkább kézzel állítanám be rajtuk a fix ip-t), 0.10-től felfele meg a DHCP szerver oszt már ip-ket a pool-nak és jónapot.
-
inf3rno
nagyúr
válasz
samujózsi
#29421
üzenetére
Ja, de senki sem követi, akkor meg sok értelme nincsen. A JSON meg az XML ezzel szemben standard formátumok. De ha ezen belül is kell valami szabvány külön logra, akkor vagy külön MIME típust kell valamelyik fölé gyártani, ami meghatározza, hogy milyen property-k lehetnek pl egy JSON-ban. A másik megoldás az RDF vagy XML+RDF vagy JSON-LD, aminél lehet vocabot gyártani az adott célra. Nekem egyébként az szimpatikusabb, mert könnyebb módosítani, bővíteni, mint egy szabványt. A schema.org pl ilyen, csak az nem logokra van.
Sokszor jobbak a kész megoldások. Azért érdemes belenézni a kódba, mert ha sűrűn megy az eval, akkor pl injektálhatnak. Markdown parsereknél láttam ilyesmit azt hiszem.
-
samujózsi
senior tag
válasz
samujózsi
#29424
üzenetére
O.K., részben tárgytalan, a kérdés csak annyi, hogy hogyan lehetne ezt is átterelni a proxy-n, ha az nem transzparens?
Az amazonaws kapcsolat azért van, mert szinkronizálom a firefox beállításait, könyvjelzőit és ehhez valamiért szüksége van az állandó kapcsolatra.
Viszont nagyon utálom, ha valaki megkerüli a proxyt. -
inf3rno
nagyúr
válasz
samujózsi
#29408
üzenetére
Én személy szerint rühellem ezeket a shell scriptes parancsokat, vagy nevezd, aminek akarod. sed = stream editor, grep = global regular expression print. Aztán próbálj emlékezni, hogy melyik fogalomhoz melyik rövidítés tartozik, főleg ha magyarul jegyzed meg, hogy melyik mit csinál. Kb. olyan, mint szótárat magolni. Lehet, hogy a 70-es években még ez volt a menő, de szerintem manapság már elég túlhaladott. Egyébként a funkcionális programozásra emlékeztet elég erőteljesen, nem véletlenül utálom azt is. A hülyék meg pont abban szoktak azzal kérkedni, hogy jajj mekkora májer vagyok, megcsináltam egy ezer karakteres sorban az egész programot...
-
Dißnäëß
nagyúr
válasz
samujózsi
#29410
üzenetére
Szerintem már hülyére beszéltétek a témát, olvasom itt fél szemmel, de leginkább az eszköz és a felhasználás határolhatja be szvsz, min ÉRDEMES fejleszteni egy adott dolgot. A múltunk pedig, hogy mit TANULTUNK, ezzel néha nagyon nincs köszönőviszonyban..
.. ragaszkodni viszont szeretünk dolgokhoz. (Ez magyar hiba).Esetemben például erősítőket tervezek monitorozni Arduino-kkal, amiket egy központi Pi-vel poll-olnék, adatot ide gyűjtenék be, majd lehet egy "csinos"
frontendet is építek az egész elé.Egy másik konténerben, ugyanezen a Pi-n, meg mondjuk futtatom a teljes házautomatizálásomat akár. De legyen két Pi, köztük pacemaker+corosync és máris megvan a virtuális ip-vel létrehozott HA (high availability), ha egyik elszállna és este nem lenne fűtés.
Ok, túlzok, de értitek.Eszembe nem jutna azon agyalni, hogy bash-ben mókoljak bármivel is.
(Ezt csak példaként hoztam).Valid dolgokról beszélgettek, csak nagyon elmenve a részletekben sztem.
-
vargalex
félisten
válasz
samujózsi
#29410
üzenetére
Bocsánat, akkor félreértettelek. Lehet, hogy haddent kolléga hozzászólásával összemostam a tiédet, mindenesetre én úgy értettem, hogy inkább a bash hiányzik ezeken a rendszereken, mint a python/perl.
Persze, bash nincs, de van busybox ash, elég sok minden megoldható. Viszont 4 MB-os flash-el szerelt routerre nem nagyon lehet python-t/perl-t varázsolni (de még 8 MB-al szereltre is csak nehezen). Attól most tekintsünk el, hogy az OpenWrt csapat dobta is a támogatását az ilyen eszközöknek 19.07-től. -
Frawly
veterán
válasz
samujózsi
#29400
üzenetére
Igen, pont ez az, hogy „általában”, meg „plusz lehetőség”. Aztán mindenki máshogy szokta. Eredetileg csak vesszővel választották el, és nem használtak idézőjeles csoportosítást, de végül úgy néz ki, hogy ez lett a szabvány, vagyis csak egy RFC ajánlás, de ez tekinthető kvázi annak, még ha sokan nem is tartják be, és pontosvesszőznek meg minden.
-
bambano
titán
válasz
samujózsi
#29400
üzenetére
ha általános csv parsert írsz, akkor fel kell rá készülni, hogy a csv, amit beletolsz, nem felel meg a szabványnak.
ha te írtad meg azt a programot is, ami a csv-t generálja, akkor meg nem. (egyébként ha a csv mezőiben soremelés van, akkor egy rekord=több sor...)egyébként poén szinten el lehet fogadni, hogy szerencsétlen a csv, mert a neve szerint vesszővel elválasztott mezők a valóságban leggyakrabban semicolon-nal elválasztottak.
-
bambano
titán
válasz
samujózsi
#29395
üzenetére
"írj korrekt csv parsert shellben! (+1: minek, ha van készen más script nyelven?": azt felejtetted ki a történetből, hogy olyan csv parsert kell írnod, ami az általad generált, nem általános csv-t képes parsolni.
vagyis ha a parsered nem tudja parsolni a csv-det, akkor saját magadban kell keresned a hibát.
-
válasz
samujózsi
#29397
üzenetére
"While there are various specifications and implementations for the CSV format (for ex. [4], [5], [6] and [7]), there is no formal specification in existence, which allows for a wide variety of interpretations of CSV files. This section documents the format that seems to be followed by most implementations:"
Szoval nincs standard, csak szokasok. Ellentetben pl. az XML-el.
-
bambano
titán
válasz
samujózsi
#29382
üzenetére
"Te egyszerűen gyülölöd valamiért.": igen, ez így van.
azért, mert azt látom, hogy egy csomó kód "overengineered", túl van tervezve, és ahelyett, hogy hatékonyan, tömören megcsinálták volna, "szépen" csinálták meg.egyszer régen egy korábbi munkámban monitoring adatokat kellett gyűjtenem egy appból, és a tisztelt fejlesztővel hetekig veszekedtem, hogy azt az adatot, amit egyszerű, egysoros, csv jellegű formátumban ki tud adni, ne json-ben meg xml-ben adja már ki, mert azt sokkal nagyobb meló parsolni.
de jártam már úgy is, még a múlt évezredben, hogy egy internet szolgáltató rendszerét megtervezték úgy, ahogy a cisco elképzelte (ami nyilván minél több dobozt akart eladni). lett belőle egy akkora architektúra, hogy a2-es lapra fért csak ki nyomtatva. azt megkaptam, kiröhögtem, utána megcsináltam ugyanazt shellben, összesen kevesebb, mint két képernyőnyi shell kóddal meg ötvenedannyi programmal.
ja nem. nem csak a múlt évezredben jártam így, hanem a mostaniban is...
de szerintem ha ebből flame-t akarunk csinálni, akkor élesszük fel egy korábbi posztom topicját és ott: [link]
-
Dißnäëß
nagyúr
válasz
samujózsi
#29370
üzenetére
Az ntfs szvsz jó igásló, de annyira nem agyonszofisztikált, még az újabb iterációiban sem, mint a már említettek.
Van automatikus defrag W10-ben, igen, nálam ki is kapcsolva. Épp elég volt nagyjából 22 óráig másolni az adatokat egyikről a másikra, ami többnyire szekvenciális beolvasásra hasonlít (ha nem töredezett) és őrült random seek-elést hoz, ha töredezett. A forrás meghajtón, nyilván. Hát nálam középen volt kb. a dolog, de mindkét HDD tud olyan 150-160 mega körül, ehhez képest volt, amikor 30-50 körülre berogyott a motyó, mert seek-elt az a HDD, amiről épp olvasta az rsync a fájlt. Meg közben én tettem-vettem és csak azt hallom finoman, hogy a Seagate-emnek le akar esni a feje egy szimpla iso mellett is (tartok 1-2 Linux telepítőt is magamnál itthon). Hát mondom uhhh, ideje volt. Ugyanez az újról visszaolvasva /dev/null-ba nyersen gyakorlatilag full tempón megtörténik, seek hang nulla (bár a Purple amúgyis halkabb, de kihallom ha akarom, hát semmi nem volt).
Már 1 tera is nagyon sok. Nagyon
Az ember akkor jön erre rá, mikor egész élete belefér párszáz gigába, sőt, .. és mikor másolsz, másolsz és másolsz és csak vánszorog tetű lassan, uhh .. 4 tera = ~8 óra, szekvenciálisan, lehetőleg nulla nagyobb seek mellett, így tartható a névleges (átlag-)tempó (150MB/s). Ha a matekom nem csal. Egy töredezett HDD-ről, fájlokat másolva, nagyon megcsúszik. (Blokk módban dd-vel átment volna említett idő alatt max tempó mellett, csak akkor ugye a teljes cluster map-et, minden vittem volna, a töredezettséggel együtt). És még mindig jobban jártam így, mintha engedtem volna a Windows-nak, hogy le-defragolja telibe, pici apró blokkonként téve az adatot egyik helyről a másikra, iszonyú sokat bukva seek időn. Sehogy se jó, de a kevésbé rosszat sikerült meglépni.
-
Dißnäëß
nagyúr
válasz
samujózsi
#29368
üzenetére
Én ntfs-t, egy hete. Vettem a meglévő 4 terásom mellé egy másikat, hogy na majd jól megnasozom itt a kicsi itthoni életem.
És akkor szembesültem több évnyi fragmentációval az ntfs-en, uh mondom neeee. Végül az lett, hogy btrfs-t kapott az új, áttoltam oda mindent egy rsync-el és most mindkét helyen megvannak az adatok. Az új diszk jó, agyon teszteltem, így bevállalom most azt, hogy egy zfs-t kreálok a régin, lezúzva mindent rajta nyilván, majd arra átteszek mindent az újról, végül az újat is leradírozom, zfs, majd a két zfs-t mirror-ba vágom és elvileg műxik úgy a dolog, hogy adat megmarad.
Mindezt még egy VM-ben kicsiben ledemózom és akkor elvileg jó leszek + fragmentációm sem lesz a fájl szintű másolás miatt. Legalábbis mondjuk úgy, tutira nem.
Megspórolhattam volna egy lépést, ha eleve zfs-t teszek az újra, csak meg akartam még őrizni a btrfs kompatibilitást pár napra, elég aktív zenehallgató vagyok és a W10-em látja a btrfs-t, illetve asszony raplizott, hogy elkésünk vendégségből, NAGYON csúnyán nézett, így nem volt kedvem agyonparaméterezett, jól optimalizált zfs-t kreálni rajta, maradt egy quick&dirty btrfs.
Mára meg letisztultak a dolgok, szóval...
Persze a legfontosabbakról van mentés, külső USB ház ...
Sokmindent mondanak amúgy defrag-ról, de én mostanában rájöttem arra, hogy jobb referenciadoksik alapján menni és ők általában szépen kitérnek arra, mikor igen és mikor nem. Ha jól csináljuk, soha nem kell, én sem tervezem.
-
Frawly
veterán
válasz
samujózsi
#29349
üzenetére
Lehet az a baj, hogy még régen próbáltam, régi gépen, 2 magos Core Celeroncs proci. Igen, gyorsabb volt a /dev/urand, de még azt is kínzás lett volna kivárni egy ~200 gigás meghajtónál is. Lehet mai normális gépen próbálnám, nem lenne már olyan nagy szám. Lehet egyszer ki is próbálom, akár még dd if=/dev/urand of=/dev/null segítségével is, jó sokáig, hogy mennyit tol át. Hétvégénél előbb nem lesz időm most ilyennel játszani.
Nekem egyébként bőven elég az egy menetes zerofill. Vagy SSD-nél az egy menetes TRIM (egész meghajtóterületen, nem csak a szabad szektorokban).
(#29350) haddent: nálam semmi különös. Régen főleg nagyobb léptékű torrentezés miatt titkosítottam. Ma már sokkal kevesebbet torrentezek, alig valamit, inkább csak személyes doksik vannak a gépen, semmi komoly hadititok. Inkább csak megszokásként maradt rajtam, hogy ha egyszer elérhető titkosítás, meg nem lassít, akkor miért ne használjam. Bár nem mindent titkosítok, próbatelepítéseket pl. nem, mert azokon OS-eket tesztelek, vagy csak 1-2 játék miatt vannak fent, azokon semmi személyeset nem tárolok amúgy sem, meg egy idő után mindig törölve is vannak ezek. Igaz én semmi ultraparanoid szigorítást sem használok hozzá, default beállításokkal titkosítok mindent. Tehát semmi ilyen header nélküliség, meg random felülíráshoz ragaszkodás, stb.. Annyira érdekes dolgaim egyébként sincsenek, hogy valakinek túl sok energiát érdemes lenne beleölni a visszafejtésbe.
Azért valami titkosítást nem árt használni. Engem azért nyugtalanítana, hogy ha valaki idegen ráteszi a kezét a gépre, nézegetheti, hogy mi van a browser historyban (nem, nem fogom törölni minden kilépéskor, kényelmetlen, a weblapokra visszataláláskor hasznos), mit töltöttem le, milyen doksikat írtam, kivel leveleztem. mondom semmi nagy titokról nincs szó, de ne legyen már az életem bárkinek nyitott könyv.
-
Frawly
veterán
válasz
samujózsi
#29344
üzenetére
Tévedsz. Headerrel sem törtek fel még soha LUKS titkosítást. Lehet akármilyen lelkes akárki. Már a 128 bites AES-t ilyen 8 karakteres jelszóval is csak szuperszámítógéppel tudnak törni és évekig tart, 256 bites AES-t ilyen 20-30 karakteres jelszóval és XTS blokktárolással (ezek a default értékek LUKS-ban) meg kb. soha, esetleg az univerzum végégig tartana. Hacsak nem találnak idővel valami gyengeséget magában az AES algoritmusában, vagy a LUKS blokkezelésében (a CBC-ben találtak, igaz abban is csak elméletileg, azt nem is használja már default semmi).
De nem kell ehhez LUKS sem. Az eredeti UNIX forráskódjában ott maradt néhány UNIX-os fejlesztő felhasználói fiókjához tartozó jelszó hash-e. A legtöbbet megtörték néhány perc-nap alatt, de azok egyszerű jelszavak voltak, 4-5 karakter, és egyéb blődségek. Viszont volt ott pár emberke, akinek a jelszavát már több mint 10 éve nem tudják visszafejteni, pedig számos hobbista dolgozik rajta, ilyen erősen párhuzamosított, csúcs GPU-s / bitcoinbányászatban edzett vasszörnnyel mennek rá, és még mindig semmi eredmény. Pedig ez nem AES, meg SHA512 meg LUKS XTS, csak egy mezei, régi hash, egy 70-es évekbeli rendszerről visszamaradva. Nem is komoly szándékkal törik, csak egyfajta fun hobby projekt, hogy a régi nagy UNIX-szerzők közül ki milyen jelszót használt.
A Secure erase-nek ha van is hiányossága, nehéz kihasználni, mivel az SSD vezérlőjét kell hozzá megkerülni, az meg eleve rettenet nehéz, csak ilyen NSA, CIA szintjén ha lehetséges, és még ott sem garantált a siker, hogy a tényleges töréshez találnak is rajta fogást.
Szóval maradjunk abban, hogy ha el is adok a jövőben háttértárat, az új tulaj lehet bőven lelkes, de hozzáférni maximum a p5sömhöz tud, ha lent van a sliccem, akkor is csak úgy, hogy ha engedem, hogy l3×0pjon kézen állva.
Ja hogy az sok pénz, hát ez van 
(apt install iptables-persistent), /etc/iptables könyvtárba kell és lehet a meglévő ruleset-et kitenni rules.v4 és rules.v6 fájlokba (legalábbis nálam spec, bár v6-ot nem használok sehol, így üres), iptables-save > rules.v4, ip6tables-save > rules.v6 és ezeket utána minden boot-nál tölti szépen be.
Az ember akkor jön erre rá, mikor egész élete belefér párszáz gigába, sőt, .. és mikor másolsz, másolsz és másolsz és csak vánszorog tetű lassan, uhh .. Új hozzászólás Aktív témák
Hirdetés
- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Sütés, főzés és konyhai praktikák
- Autós topik
- Audi, Cupra, Seat, Skoda, Volkswagen topik
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- IGP nélküli processzorokkal készül az Intel és az AMD
- WoW avagy World of Warcraft -=MMORPG=-
- Azonnali fotós kérdések órája
- Tőzsde és gazdaság
- Melyik tápegységet vegyem?
- További aktív témák...
- Gyermek PC játékok
- Windows, Office licencek kedvező áron, egyenesen a Microsoft-tól - Automata kézbesítés utalással is!
- Eladó Steam kulcsok kedvező áron!
- Microsoft licencek KIVÉTELES ÁRON AZONNAL - UTALÁSSAL IS AUTOMATIKUS KÉZBESÍTÉS - Windows és Office
- Adobe Előfizetések - Adobe Creative Cloud All Apps - 12 Hónap - NYÁRI AKCIÓ!
- 120 - Lenovo Legion Pro 5 (16ARX8) - AMD Ryzen 7 7745HX, RTX 4070 (48 hónap garancia!)
- Csere-Beszámítás! AMD Számítógép PC Játékra! R5 5500 / RX 5700XT / 32GB DDR4 / 256SSD+1TB HDD
- Azonnali készpénzes Intel i3 i5 i7 i9 8xxx 9xxx processzor felvásárlás személyesen / csomagküldés
- Lenovo ThinkCentre M720s SFF / M920T tower -Számla, garancia, WIN11
- BESZÁMÍTÁS! Gigabyte H610M i5 13400F 16GB DDR4 512GB SSD RX 6700XT 12GB DeepCool MATREXX 40 650W
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest