-
IT café
Debian GNU/Linux
Új hozzászólás Aktív témák
-
Friczy
senior tag
5. Nekem meg a su tűnik biztonságosabbnak.
Attól függ, hogy használod. Ha a sudonál nem nyitod szélesre a kaput (nincs NOPASSWD opció, csak a megadott user/userek használhatják), vagyis csak az használhatja, akinek azt tényleg meg akarod engedni, akkor semmivel sem biztonságosabb a su, mint a sudo. Ha több embernek akarod biztosítani a rendszeren, hogy root lehessen, akkor pedig a sudo biztonságosabb, mert nem kell megosztott jelszót használni, és akkor vonod vissza a többletjogosultságot, amikor akarod.
-
Friczy
senior tag
Ettől még nem lesz biztonságosabb. A jelszó megszerzésének lehetősége nem attól függ, hogy hányszor használja valaki, hanem attól, hogy az adott jelszót hogy tárolja, hány helyen használja, és mennyire biztonságos a jelszó továbbítása hálózati használat esetén.
A linkelt cikkedet természetesen olvastam, tulajdonképpen az ottani végkövetkeztetéseddel nem értek egyet, bár a cikk jó
-
Friczy
senior tag
Jelszó megszerzésről írtál, még véletlenül sem említve azt, hogy hogyan szerez jelszót valaki. Te most a jelszó megszerzési esetei közül önkényesen kiragadtad a jelszó lelesését. Nos, ugyanilyen hozzáállással simán tudok neked igennel válaszolni, csak a feltételeket kell megfelelően belőni.
Pl. az otthoni gépem esetén többnyire senki nincs a szobában, amikor a jelszót begépelem, így esélye sincs lelesni. Ha mégis megtenné, akkor a szóbajöhető személyek száma összesen kettő, a feleségem és a fiam. Egyik esetben sem félek attól, hogy akár a root jelszót, akár a saját jelszavamat megpróbálná lelesni, még kevésbé attól, hogy felhasználni. Szóval a válasz egyszerű igen, a jelszó lelesése rosszindulatú személy részére meglehetősen nehéz, annyira hogy nyugodtan mondhatom egyenlőnek az esélyt.
Mindenesetre arról volt szó eredetileg, hogy a su vagy a sudo a biztonságosabb, most pedig egyes jelszavak biztonságáról beszélünk, nem pedig egyik vagy másik technikai megoldás biztonságáról önmagában. Ebből az következik, hogy inkább a használati mód biztonságáról van értelme beszélni, azaz azt mondani, hogy 'a su biztonságosabb, használd azt a sudo helyett' egyszerűen egy túl sommás és így téves értékítélet.
(Mellesleg ajánlom figyelmedbe a sudoban a rootpw és runaspw opciókat, ha ezeket beállítod, akkor a saját jelszó helyett a root jelszót illetve azt a jelszót kell használni, amelyik user nevében akarsz valamit csinálni, így aztán a fenti félelmed - gyakran használt jelszó megszerzése - is kiküszöbölhető)
-
Friczy
senior tag
Úgy látom, erősen mozog a célpont .) Eddig nem volt feltétel, hogy alapértelmezett lehessen. Mellesleg pl. szerintem ez hátrány, ha egynél több felhasználónak van joga roottá válni, akkor a shared jelszó önmagában is felvet biztonsági problémákat, erről korábban írtam, így én nem örülnék annak, ha alapértelmezett lenne. De ha valakinek ez az aggálya sudoval szemben, van lehetősége megoldani.
-
Friczy
senior tag
válasz bambano #7201 üzenetére
Nehéz válasz. Szívem szerint mondtam volna a bash_profile-t, de ah valaki átállítja a shelljét másra, akkor ezt is buktad.
Az /etc/environment lehet a megoldás szerintem is (nekem legalábbis az szokott működni), ha valamiért nem működik, akkor nézd át a pam.d beállításokat, megvan-e a pam_env.so mindenhol, ahol kell.
A session beállításoknál kell, létezik egy common-session, amit szinte minden pam.d file beránt, érdemes oda betenni.
-
Friczy
senior tag
válasz #59070464 #7264 üzenetére
Tegyük fel, írok egy dev-nek, ha érdemlegesnek találja (nem tudom mi alapján dönti(k) el) és bekerül, akkor az onnantól számítva benne lesz a tárolóban?
Ha lesz egy maintainer, aki felvállalja, csinál belőle csomagot, akkor bekerül a fejlesztői (sid) tárolóba, onnan pedig a testingbe. És amikor a testingből stable lesz, és a befagyasztási időszak alatt nem tartalmaz release critical bugot, akkor a következő stabil kiadásban benne lesz.
-
Friczy
senior tag
válasz #59070464 #7267 üzenetére
https://www.debian.org/Bugs/
https://bugs.debian.org/release-critical/Ha egy csomagban release critical bug van az adott release kiadásakor, akkor az nem kerül be a kiadásba. Ez viszonylag ritka dolog, mert a freeze időszak viszonylag hosszú, és elsősorban erre való. Általában a népszerűbb, fontosabbnak ítélt programok hibáira jobban koncentrálnak, tehát az általad említett Evolution nem valószínű, hogy erre a sorsra jutna egy ilyen esetben (más kérdés, hogy szerintem nem lenne kár érte , de ez csak azért van, mert én nem szeretem)
Az, hogy 'a tárolóból is kikerül' nehezen értelmezhető. A stabil kiadás tárolójába természetesen nem kerül bele, de attól még magát a programot nem dobják ki a Debianból, az unstable és testing tárolóban benne marad. Ahogy az oldstable-ben is, a stabil - értsd: már kiadott - release-ek tárolóiból nem kerülnek ki csomagok, és nem is kerülnek be újak.
-
Friczy
senior tag
válasz #59070464 #7269 üzenetére
Gnome-ot használok, az Evolutionnal csak az a bajom, hogy nagy, nehézkes és ronda A Thunderbird fejlesztése nem ért véget, rendszeresen jönnek ki új verziók. Miért is halott?
A Claws se tetszik, egy időben használtam, tetszetős, de sok hibája volt. Lehet, hogy azóta megjavult, de pillanatnyilag nem érdekel. Én vígan elvagyok a Thunderbirddel.
-
Friczy
senior tag
válasz Apollyon #7293 üzenetére
ffmpeg visszatért a Debianba legalábbis a sidben már benne van (és ismét benne van az mplayer is).
Szóval a következő stabil kiadásban is várhatóan benne lesz, ahogy tudtommal a testingben is benne van már.Nem tudom, mennyire macerás a testingből vagy a sidből backportolni a stabilba mostanság, régen elég sokat csináltam ilyet. Inkább, mint külső repo.
-
Friczy
senior tag
A Debian levelezőlistán is cikkeztek erről, ismert bug, egyelőre a workaround annyi, hogy használj régebbi kernelt. A videokártya kernel részénél van a probléma, emiatt X alatt, és nem minden videokártyánál jelentkezik.
(szerencsére nálam unstable van Intel videokártyával, így nem érint
-
Friczy
senior tag
válasz bambano #7689 üzenetére
Nem tricky, sticky De nem javaslom, az pont nem azt csinálja, ami itt az igény, hanem azt, hogy bár a könyvtáron 777 van, mégis mindenki csak a saját file-ját tudja módosítani (1777 érték a könyvtáron).
Itt pedig pont az a cél, hogy az adott könyvtárban bárki tudja módosítani az ottani file-t. Samba oldalon acl-t célszerű használni (régen használtam Sambát komolyabban, tehát konfigot nem tudok mondani most), valamint a force user és force group opciók.
A Linux jogosultságon érdemes lehet a group-nak módosítási jogot adni (könyvtár szinten 775), valamint a setgid opció a könyvtáron. Ez az újonnan létrehozott file-okat mindenképpen abba a csoportba teszi, amely a könyvtár tulajdonosa (és amelynek beállítottad a törlési jogot, lásd 775 a könyvtáron).
Szerintem a samba force group és a setgid együtt már jó eséllyel megcsinálja, amit az eredeti kérdező szeretne.
-
Friczy
senior tag
válasz CPT.Pirk #7716 üzenetére
Nem jól érzed Van elég ember, de a stabil disztribúció Debianban azt jelenti, hogy kiadás után már csak security bugokat javítanak, verziót nem frissítenek. Akkor se, ha nem jól működik. Ennek van előnye is (pont a stabilitás, csak disztribúció-frissítéskor kell meglepetésekre számítani), és hátránya is (ha bugos volt az upstream, akkor bizony évekig az marad a kiadásban).
Ha valakinek ez nem felel meg, nyugodtan választhat másik disztribúciót.
-
Friczy
senior tag
válasz Lathronos #7744 üzenetére
A PPA-t ne tekintsük az Ubuntu részének, ugyanis nem az. És az az érzésem, hogy a Debianban több csomag van, mnt az Ubuntuban, főleg, ha figyelembe vesszük, hogy az Ubuntu esetén a universe (és főleg a multiverse) már félig kilóg a repositoryból). Annak idején futottam bele Ubuntun olyan problémába, hogy egy csomagnak függőségi problémái voltak,rákerestem a bug leírására, a karbantartó el is ismerte, és lezárta azzal, hogy a universe-ben van, ahol nem feltétlenül kell kijavítani a hibákat
Tehát az Ubuntu 'nagyobb csomagválasztéka' kissé megtévesztő.
-
Friczy
senior tag
Pár éve visszaszoktam a Debianra desktopon
Korábban testinget használtam, mert a három éves programokat desktopon túl réginek tartottam, és amikor az Ubuntu először megjelent, megdöbbentő volt, hogy elsőre működik sok minden, amit Debianon külön reszelni kellett - több-kevesebb sikerrel.
Aztán az Ubuntu valahogy kezdett egyre gépigényesebb lenni, párhuzamosan pedig időnként meglepő bugokat produkált, és egyre inkább az volt az érzésem, hogy kevesebb a kontrollom a rendszer felett. Kerestem ismét mást, találtam is egy nagyon jót: Arch. Ez egy szép kitérő volt, aki szereti időnként low-level szinten konfigurálni a rendszerét, cserébe átlátható, annak nagyon jó, feltéve, ha hajlandó is rászánni az időt, mert ha mondjuk fél évig nem frissíted a rendszered, utána már nagyon nehéz dolgod lesz. De mindegy, arra jó volt, hogy megszeressem a rolling-release rendszert, viszont sok gépen egyszerre nem szeretnék Archot használni, túl sok időt venne el a karbantartás.
Így aztán jött a kompromisszum: vettem egy mély levegőt, és Debian unstable. Kicsit valóban észnél kell lenni, és ha pl. úgy látszik, hogy függőségi gondok vannak, akkor frissítés stop. apt-listbugs csomag életmentő, frissítéskor átnyálazza a bugokat, ha van nyitott bug a felrakandó verzióra, akkor szól, eldöntheted, hogy az egész frissítést megállítod, a hibás csomagot rögzíted (pin) a korábbi verzión, vagy a hiba ellenére mégis felteszed. Pinning esetén a cron napi futáskor átnézi, hogy még megvan-e a hiba, ha nincs, akkor leszedi a pinninget automatikusan, szerintem zseniális
További óvintézkedésként etckeeper minden frissítéskor egy újab git verziót készít az /etc könyvtárról, könnyű visszatérni korábbi konfigurációra - bár ezt a feature-t még nem kellett életmentésre használnom.
Jó egy-másfél éve használom így a desktopot, kellően friss, és ritkán futottam bele tényleg idegesítő problémába.
Flash - működik, bár a Flash maga helyből megérett a kidobásra oprendszertől és disztribúciótól függetlenül.
Iceweasel-Firefox: bár az Iceweasel elvileg minimálisan különbözik a Firefoxtól, én is tapasztaltam furcsa viselkedéseket, így inkább a bináris FF-et használtam, ugyanígy a Thunderbirdöt az Icedove helyett.
Viszont a Debian-Mozilla vita megegyezéssel zárult, ennek eredményeképpen eltűnt/eltűnik az Iceweasel, és ismét Firefox van a Debianban, és valamikor a közeljövőben a Thunderbird is visszatér. -
Friczy
senior tag
válasz gilfoyle #7777 üzenetére
Alapvetően nem egészséges keverni. Általában a függőségek miatt amúgy is elég nehéz megoldani hosszú távon a keverést, ráadásul ha csak simán beállítod az újabb verzió tárolóját, akkor a következő apt-get upgrade-kor nagyon sok csomagot akar majd frissíteni, te ezt nem akarod
Az apt-pinning mechanizmus (https://wiki.debian.org/AptPreferences) segítségével be lehet állítani, hogy egyes dolgokat a frissebb tárolóból hozzon, a többit pedig a régebbiből, de mivel pl. nagyon sok csomag függ a libc-től (áttételesen vagy közvetlenül), sok mindent nem fogsz így elérni. Egy próbát megérhet, de legyél óvatos, ne frissíts olyan csomagot, amit nem akartál.
Biztonságosabb, de idő- és erőforrásigényesebb megoldás a csomagok backportolása, ilyenkor a source tárolót állítod be a frissebb tárolóból (is), lehúzod a forráscsomagot, és elékszíted a csomagot a saját rendszereden, aztán dpkg-val már mehet is fel. Ezzel nem kutyulod össze a csomagrendszert, de a kézi karbantartás kicsit több munkát igényel. Egy-két csomagnál megoldás lehet.
-
Friczy
senior tag
válasz sergiooo #7819 üzenetére
A külön letölthető .deb alkalmazásokat első körben felejtsd el. Szinte minden benne van a repositoryban, ami kellhet, aztán ha később megismered a rendszert, és mégis lesz olyan, amit külön kell feltenni, azt majd ráérsz megkérdezni.
A standard tárolókban lévő programok nem fogják a rendszer stabilitását veszélyeztetni, az innen-onnan külön letöltött programokról ez nem mindig mondható el.
Skype-ot nem használok, ezt azért nézd meg, hátha segít:
https://wiki.debian.org/skype
-
-
Friczy
senior tag
válasz Geller72 #7834 üzenetére
Sose használtam az ePIN-t, viszont a mobiltokent le tudod generálni, ha a kártyával belépsz az ebankba. Az app frissítése óta _csak_ a mobiltoken használható, a régi appos belépés nem működik, mindenképpen le kell generálni a mobiltokent.
Egy ilyen lejárt kártyadátumot vagy valami hasonlót nekem is produkált egyszer Firefoxszal Windows alatt, akkor az volt a megoldás, hogy eltávolítottam a böngészőből a plugint és feltelepítettem még egyszer.
-
Friczy
senior tag
válasz Fooler89 #7901 üzenetére
Ehhez nem iptables kell, hanem policy based routing. Persze iptables is kell, de az csak a legvégén, amikor a csomag elhagyja a gépet, akkor egy MASQUERADE, de az a legkevesebb benne.
Policy based routingra egy rövid példát itt találsz:
http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.rpdb.simple.html -
-
Friczy
senior tag
válasz Fooler89 #7931 üzenetére
Elvben elég, ha át tudod az egészet másolni. Attól függ, hogy hogyan tárolja a rendszer (Maildir vagy mbox formátumban), vagy egy egész könyvtárstruktúrát, vagy felhasználónként egy-egy file.
Az imap illetve pop3 csak egy hozzáférési protokoll, ennek nem sok köze van ahhoz, hogy hogyan tárolod a levelezést, ha az átmásolás sikeres, akkor mindegy, hogy pop3 vagy imap hozzáférés lesz.
-
Friczy
senior tag
válasz Fooler89 #7933 üzenetére
Megpróbálom röviden leírni, hangsúlyozom, hogy régen csináltam ilyet a gyakorlatban, de akkor működött.
Lehetőséged van különféle routing táblákat lérehozni egymástól függetlenül. A routing tábla egy szám és egy név, a táblákat az /etc/iproute2/rt_tables file-ban tárolod. Ebben a file-ban a 'reserved values' részt ne piszkáld, a 'local' részben vehetsz fel saját táblát, pl:
200 szerverek
Az, hogy mi kerüljön melyik táblába, azt az ip rule paranccsal tudod megadni, tehát ha mondjuk a szervereid IP címe 192.168.1.4 és 192.168.1.5, akkor
ip rule add from 192.168.1.4 table szerverek
és
ip rule add from 192.168.1.5 table szerverekellenőrizni az ip rule list paranccsal tudod.
Az így létrehozott táblának a defaulthoz képest teljesen más routing táblát adhatsz, tehát
ip route add table szerverek 0.0.0.0/0 via a.b.c.d (a.b.c.d helyére behelyettesíted a sulinetes interface-et)
Így a szerverek táblában lévő gépek default gateway-e a sulinetes interface lesz.ezek után a default gatewayt (a többieknek) már nyugodtan beállíthatod a másik, új címre:
ip route add 0.0.0.0/0 via ujinternetkijárat
és törölheted a régit, hogy ne két gatewayed legyen
ip route del 0.0.0.0/0 via régiinternetkijáratNa, valahogy így. Hangsúlyozom, hogy leellenőrizni nem tudtam, mert most nincs olyan hálózati topológiám amin partizánkodhatok és több kijárat lenne, de a parancsok szintaktikailag helyesek, és amikor csináltam hasonlót, akkor az nagyjából így ment.
-
Friczy
senior tag
válasz Fooler89 #7936 üzenetére
Az iptables szabályoknak ehhez nem sok közük van. Megint ott vagyunk, hogy kevés konkrétum, így nehéz válaszolni. Ha a címkiosztásról (mi nem ér el mit, és azok milyen alhálóban vannak), topológiáról többet tudnék, akkor tudnék konkrét magyarázatot, megoldást mondani.
Ha publikusban nem szeretnél (ami valahol érthető) részleteket elárulni, de privátban esetleg kevésbé vagy aggályos, akkor írhatsz privátban is részleteket, ígérem, nem adom tovább, és nem fogok itt sem idézni belőle.
-
Friczy
senior tag
-
Friczy
senior tag
válasz SwissAirplan #8751 üzenetére
Pedig egy pendrive-os telepítés is csak annyiból áll, hogy letöltöd, dd-vel kiírod aztán boot. Feltéve, hogy a géped tud pendrive-ról bootolni.
A 6-7 év szerintem nem nagy akadály, én tavaly cseréltem alaplapot, addig vígan futott a Sandy Bridge-es gépen a legfrissebb Debian.
-
Friczy
senior tag
Nem Debian, hanem Arch, de 7520-as Dell Latitude gyakorlatilag csont nélkül működik. Debianon leginkább a non-free firmware-ekkel szokott gond lenni, ha szerencséd van, akkor a telepítéshez nem kell olyan, ha nincs, akkor pedig olyan telepítőt kell keresni, ahol már betették a non-free cuccokat.
-
Friczy
senior tag
válasz Neil Watts #8770 üzenetére
Az miért nem jó, hogy kiírod az iso-t dd-vel egy pendrive-ra, és bootnál arról bootolsz?
-
Friczy
senior tag
válasz Neil Watts #8773 üzenetére
Nekem új hogy a 7z másol. Nem arra való, hanem archív file létrehozására ill. kibontására.
-
Friczy
senior tag
válasz Neil Watts #8776 üzenetére
A dd egyszerűbb és biztosabb, de ha neked az a megoldás nem felel meg, akkor nem zavarlak.
-
Friczy
senior tag
válasz Sequadon #8792 üzenetére
Most épp nincs olyan Linuxom, ahol vlanok vannak definiálva, régen volt, és elég egyszerűen ment howto alapján.
Most így gyorsan ezt találtam, első pillantásra egybevág az emlékeimmel:
http://www.microhowto.info/howto/configure_an_ethernet_interface_as_a_vlan_trunk_on_debian.html
[ Szerkesztve ]
-
Friczy
senior tag
válasz kojak27 #8838 üzenetére
Én már nagyon sokszor költöztettem rendszert, ha van lehetőséged arra, hogy a két HDD együtt legyen bent a gépben, akkor a legegszerűbb az új HDD-n létrehozni a partíciót(partíciókat, ha többet akarsz), és cp paranccsal átvinni mindent, grubot betenni az új HDD-be, és hajrá.
Én a cp -ax parancsot szoktam használni, ez csak az adott partíciót másolja át, ha több partíción van a rendszer, akkor ezt egyenként kell kiadni, de ez nem szokott gond lenni.
-
Friczy
senior tag
Hadd javítsalak ki. A kernelben nincs olyan driver, ami zárt kódrészletet tartalmaz, lévén a kernel maga is GPL.
Kernel alatt azt a kernelt értem, ami a hivatalos linux kernel (https://www.kernel.org/).
Az már más kérdés, hogy az egyes disztribúciók készítői esetenként patch-elik a kernelt nem GPL licencű kóddal. A felhaszálónak ugyan egykutya, de nem árt tudni, hogy nem a Debian 'hagyja ki' a driver kódját a kernelből, hanem más disztribúciók 'teszik bele'.
-
Friczy
senior tag
A firmware tulajdonképpen nem a kernel része, még ha a git.kernel.orgon fenn is van, nem a kernelbe kerül bele, hanem betöltődik az egyes eszközökbe. Ezt ne keverjük a driverekkel, mindkettő szükséges (lehet) a működéshez, de a driver tulajdonképpen a gép CPU-jában futó kódot jelent, a firmware pedig a kezelt eszközben fut.
Ha belenézel a kernel.orgon lévő kernelbe (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/?h=v4.19-rc7), ott a firmware könyvtár üres, a drivers/firmware alatt is csak a firmware kezeléséhez szükséges kódok vannak, maga a firmware nincs.
Jogilag nem is lehet része, mert a kernelre a GPL licenc érvényes, a firmware-ekre viszont nem, ha benne lenne a kernelben, akkor GPL-nek kéne lennie.
A firmware-ek a Debian esetében külön csomagban is vannak, licenctől függően a main vagy a non-free részben.
-
Friczy
senior tag
Abból, hogy a linux kernel karbantartója valamit blob-nak nevez (teljesen jogosan amúgy) hogyan következik, hogy a kernel része?
Ahogy korábban írtam, nincs benne a kernelfában. Ezek a firmware-ek ugyanazt a funkciót valósítják meg a különféle eszközökben, mint a korábban a hasonló eszközökön elhelyezett ROM-ok. Gondolom, a BIOS-t (ami nem más, mint az alaplap firmware-e) nem tekinted a kernel részének (vagy mondjuk az Intel mikrokódot). Hasonlóképpen az eszközök firmware-ei sem azok, csak a korábbi ROM-on elhelyezéshez képest megváltozott a használat, most a firmware nincs fixen benne az eszközben, hanem az eszköz inicializálása során tölti át a rendszer.
És mivel nem a kernel része, kihagyni sem lehet belőle.
-
Friczy
senior tag
Jó helyen keresgélsz.
A következőket kell csinálni:
- nézz bele az /etc/apt/sources.list file-ba, ilyesmit fogsz látni (várhatóan több sort
deb http://ftp.hu.debian.org/debian jessie main contrib non-free (nyilván nálad más a disztribúció neve, ez egy régi gép)Na most ha nálad esetleg csak a main van, a contrib és a non-free nincs, akkor írd be a sorba.
Utána add ki:
apt-get update
apt-get install firmware-misc-nonfree(ha a non-free benne van a sources.list file-ban, akkor elég ez a két parancs)
Utána reboot és kész vagy.
Szerk: A régi kernelt nyugodtan megtarthatod, nem zavar az ott semmit.
[ Szerkesztve ]
-
Friczy
senior tag
válasz zoltanz #8997 üzenetére
Itt nézz körül
Szerintem non-free image-eket itt nem találsz, azt külön kell hozzáadni[ Szerkesztve ]
-
Friczy
senior tag
válasz ubyegon2 #9029 üzenetére
Az /etc/X11/xorg.conf.d/ mappában nem kell xorg.confot létrehozni, az konfig részletek tárolására való. Ahogy az emlytatt synaptic conf is.
Alapvetően xorg.conf már régóta nem kell, egy két specifikus dolgot kell csak (ha egyáltalán kell) definiálni az xorg.conf.d-ben. Ha viszont generálsz xorg.conf file-t, azt ne az xorg.conf.d-be tedd, hanem az /etc/X11/ mappába.
-
Friczy
senior tag
-
-
Friczy
senior tag
Úgy rémlik, hogy a 9-esben sem volt benne. A Virtualbox policyje nem igazán fér össze a Debian patching megoldásával (a stable disztribúcióban a programok verziója nem változik, csak a biztonsági javítások mennek bele). Tény, ez alól már van kivétel, a böngészők, de gondolom, nem akarták kiterjeszteni.
És valóban, az utolsó disztribúció, amiben benne volt, az a jessie.
https://packages.debian.org/search?keywords=virtualbox&searchon=names&suite=all§ion=all -
Friczy
senior tag
Az iptables csak egy eszköz, amivel a kernelben lévő tűzfalat konfigurálod. Nem veszett kárba a ráfordított időd, bármikor használhatod az nftablest is, de még működik az iptables is. Ez csak az áttérést könnyíti meg.
Hasonló megoldás, mint az ipchains/iptables váltásnál volt, ott is volt időszak, amikor használható volt az ipchains, de a kernelben már a netfilter (aminek toolja az iptables) volt benne.
Új hozzászólás Aktív témák
- STEEL BOX! - EEP Eisenbahn.exe 3 & 4 Steel BOX
- Vírusirtó, Antivirus, VPN licenckulcsok - kedvezményes ajánlatok (frissítve: 2024. 05. 01.)
- GameStar / Gamer Magazin / PC Guru stb papírtokos játékmellékletek 350Ft/db
- Windows 10, 11 Professional, Home, Enterprise licenckulcsok 64, 32 bit - MEGA Akció!
- Mass Effect 1 PC
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs