Hirdetés
- Tucatszámú OnePlus élvezheti a legfrissebb Androidot
- Milyen okostelefont vegyek?
- Kis méret, nagy változás a Motorolánál
- iPhone topik
- Azonnali mobilos kérdések órája
- MIUI / HyperOS topik
- Samsung Galaxy S23 Ultra - non plus ultra
- Xiaomi 15T - reakció nélkül nincs egyensúly
- Samsung Galaxy A56 - megbízható középszerűség
- Poco F3 - a mindenes, de nem mindenkinek
-
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
-
vargalex
félisten
válasz
sh4d0w
#34841
üzenetére
Ez igaz, de daninet eredetileg a qemu csomagot írta, hogy hibás... Egyébként Archon valóban az edk2-ovfm csomag kell az UEFI boot-hoz, ahogy Lenry kolléga írta. De ez a qemu-tól teljesen független, csak úgy látszik openSUSE-n saját csomagot csinálnak belőle és ellátják qemu előtaggal.
-
.-..-.
tag
válasz
sh4d0w
#34785
üzenetére
Akkor hogyan kellene használnom az admin felületet, phpmyadmint,
Oké, localhost-on engedem, de azt távolról hogyan érem el?
Vagy alapvetően legyen tiltva az admin és phpmyadmin és amikor használom ssh-val engedem a külső elérést IP szűréssel, majd újra letiltom amikor végeztem?
Akkor az ssh-t hagyjam a 22-es porton? -
válasz
sh4d0w
#34672
üzenetére
miert kell elbaltazni valamit, ami jol mukodik?
Miért, el van baltázva? Nem logol a rendszered? Vagy nem tudod elolvasni őket?
Én elsősorban a könnyű kereshetőség, szűrhetőség miatt szeretem a bináris logot, és szerintem ez kicsit gyakoribb use case, mint az, hogy 10 év múlva is szükség lesz a logokra. De itt még van pár érv.
Ha nem systemd service, akkor se induljon el - ha mar ugyis rakkent terjedt szet a systemd.
Ha nem systemd serviceként definiálsz valamit (és nem is timer, nem mount unit), akkor
hogy várod el, hogy a systemd kezelje?semmi koze a lokalis systemdnek ahhoz, hogy a tavoli rendszeren mennyi eroforrast zabal a process
Én távoli processzről beszéltem. A távoli processzt a távoli OOM killer lelövi, ha túl sok memóriát eszik.
Egyébként az OOM killer nem systemd feature, hanem kernel feature, és kikapcsolható (ha tényleg ez lövi ki a processzt).ha a userneved szammal kezdodott, akkor root jogosultsagot kaptal
Ez ugyanaz a hiba, mint amiről korábban beszéltünk. A számmal kezdődő usernevet a Systemd invalidnak tekinti (ilyen nevű user nem létezhet a Systemd policyja szerint), ezért fallbackelt rootra. Egyébként 2017-ben lett javítva.
-
válasz
sh4d0w
#34668
üzenetére
Pl. azert akarhatsz logokat olvasni 10 ev mulva, mert torveny irja elo.
De ez nem 10 év múlva derül, hogy hoppá, vissza kéne olvasni, hogy mi volt 2015 március 18-n, hanem ezt tudja az ember. Ha pedig tudja, akkor nyilván fel is készül rá, átküldi log szerverre, amit aztán archivál.
lehetne, hogy ne huzza fel a halozatot, ha valamiert nem sikerul betolteni a tuzfal konfigot?
Biztos lehet, kérdés, hogy hogy van megoldva a tűzfal konfig betöltése. Ha az egy systemd service, és hibára fut, akkor meg lehet adni a network service-nek is, hogy ne induljon el.
Lehetne, hogy a screenben inditott tavoli processeket ne loje le?
Én tmuxot használok, de sosem lőtte még le a systemd egyetlen processzemet sem. Amikor mégis ilyesmi történt, az az OOM Killer okozta, de hát annak pont az a dolga, hogy lelőjje a túl sokat zabáló processzt.
Lehetne, hogy az alaplap EFI ertekei ne valtozokba toltodjenek be, hanem konstansokba?
Itt nem tudom, mire gondolsz, én a dmidecode és a biosdecode programokat ismerem, de azoknak semmi köze a systemdhez.
-
válasz
sh4d0w
#34543
üzenetére
ujabb fekete pont a systemd bizonyitvanyaba.
Na, hát mondom. Ha megcsinálná, akkor meg az lenne a baj, hogy miért akar a Systemd mindent megcsinálni
Na mindegy, szerintem is hagyjuk. A lényeg az, hogy hálózati fájlrendszernél meg kell a _netdev paramétert, különben nincs garancia arra, hogy előbb fog felépülni a hálózat, mint hogy a Systemd megpróbálná felcsatolni a megosztást. -
válasz
sh4d0w
#34538
üzenetére
Na pont ez az, ha a Systemd mindent megcsinál, akkor az a baj, ha nem csinál meg mindent, akkor az a baj... mindegy, csak lehessen szidni a Systemd-et.
Tudsz mondani ilyen peldakat?
Csak a systemd-mount man oldalát kell fellapoznod, ott rögtön találsz egyet:
Mount units referring to local and network file systems are distinguished by their file system type specification. In some cases this is not sufficient (for example network block device based mounts, such as iSCSI), in which case
_netdevmay be added to the mount option string of the unit, which forces systemd to consider the mount unit a network mount.
Mondjuk ha egy SAN egyik LUN-ját akarod felcsatolni, az pont így néz ki, és azt jellemzően a /dev/mapper vagy simán csak a /dev alatt éred el. -
válasz
sh4d0w
#34141
üzenetére
Ha valami a helyi gépen képes a bármelyik portra indítani valamit, akkor már bent van az illető
@urandom0 : "(ha csak nincs valami local privilege escalation vulnerability a rendszerben)"
Onnantól kezdve meg nem fog ezzel szórakozni
Nekem sem a 22-n van az sshd, bár nem magason, csak kicsit máshol -
#78522999
törölt tag
válasz
sh4d0w
#34137
üzenetére
sh4d0w, urandom0:
Köszönöm az infókat.Amit jelenleg is használok/használtam:
ssh
- ed25519 kulcspár (+passphrase jelszóval)
- root belépés tiltva
- jelszavas belépés tiltva
- port áthelyezve 32000+ tartományba
- pam tiltva (bár ez most nem számít, de nem használom)ufw
- kizárólag az ssh, 80/443, 8080/8443 portok vannak nyitva (ezeket használom)fail2ban
- bantime 1440m, findtime 30m, maxretry 3folyamatosan up-to-date, de manuálisan szoktam frissíteni
egyelőre nem használok külső repo-t (csak Arch esetében, Debian esetében szükséges volt)A többit nem használtam, nem ismertem, nem állítottam be. Ezeket meglesem, köszi még1x.
Log-okat nézegetem.Amúgy a 2db IP biztosan nem én voltam, minden gépem és a vpn is "Europe/Budapest" időzónával fut.
Láttam, hogy Digital Ocean az IP tartomány, de valamelyik oldal New York-ra mutat, valamelyik Frankfurtra.
Mindegy, biztosan nem én voltam. (Proton VPN-t használok a klienseken)Akkor egyelőre figyelek ... és a többi eszköz használatát megnézem.
-
válasz
sh4d0w
#34044
üzenetére
Mi nem mukodott az unittal? Nem tudom, hogy mi az, ami abban nem tud mukodni. Csinalsz egy unit fajlt egy perc alatt, kesz. A harmadik utan mar a vilag legegyszerubb dolga, mindent egy helyen konfigolsz.
"Red Hat megírja a unitokat"
?
resolved: ez az, ami megbizhatoan tudja a kovetkezoket:
- interfeszenkenti DNS feloldas (VPN-ek, kontenerek, stb. eseten letfontossagu)
- DNS over TLS (biztonsag)
- D-Bus tamogatas
- domain-alapu nevfeloldasi szabalyokSzerintem megegyezhetunk abban, hogy a Tailscale mernokei a vilag tetejet kepviselik, ha Linuxos halozatokrol van szo. Ok irjak:
As an aside, one major difficulty in all of this is that name resolution on Linux systems is very poorly specified, and each of these methods results in slightly different behavior. If we do a resolution for
go.akua, what will happen? Will it go to the resolver for the public internet? Will it go to the right split server? Will it get sent over Tor for some reason? Will it get sent to the potentially dodgy DNS server on the public Wi-Fi hotspot at your local coffee shop? Will it get sent over UDP, TCP or DNS over HTTPS? We don’t know. This stuff is not documented and as a result, you need to figure out what it does through blood, tears and heartbreak. For extra fun, the behavior of glibc and musl differs here too. Please document your behaviors when you write new software. This saves so many people so much time.An example of how to do this right is systemd-resolved. It can do everything a modern split-DNS VPN needs natively, so in theory there’s no extra work (except see below, because reality is not quite as clean as we’d like). The systemd team painstakingly wrote down what they do, and made it unambiguously obvious how you should twiddle things to get what you want. This is the kind of documentation that infrastructure programs should strive to have.
Szoval a resolved
1) mukodik
2) mindent tud, amit egy modern DNS kliensnek tudnia kell
3) reszletesen dokumentaltnincs mas olyan DNS megoldas, ami ezeket igy mind tudja.
A binaris logolas meg egy erdekes tema, kezdve onnan, hogy minden logolas binaris ...
Azert hasznaljak a systemd-t a a valo vilagban, mert komplex kornyezetekben is jol mukodik.
-
vicze
félisten
válasz
sh4d0w
#34008
üzenetére
Csodás clickbait cím...
Schleswig-Holstein megint megpróbálkozik a Linux-szal. Jól haladnak 2021 óta...
Majd 2027-ben lesz cikk, hogy már 35000 PC-t váltanak...Az egészben az a leghumorosabb, hogy a német közigazgatás még minding 90%-ban papíron zajlik. Szóval végső soron nem Windowsról váltanának, hanem papírról.
Mondjuk úgy hogy egyik állam se költ lószart se digitális átállásra, ja lehet az open Source olcsóbb lesz, de ahogy szokásos megint nem...Szerk: Azt hiszem elolvastam életem legszebb német mondatát.
"Die Zukunft der Verwaltung ist cloudifiziert, automatisiert, algorithmisiert und datenbasiert. " -
-
válasz
sh4d0w
#33961
üzenetére
Csak a development verziók vannak bajban, meg a rollingok, azok közül se mind. Ubuntu 22.04, 23.10, Linux Mint, Debian Stable, Fedora 39, OpenSuse Leap nem érintettek.
Fedora 41, Rawhide, OpenSuse TW, Friss Kali érintettek, Debianból testing, unstable és experimental lehet érintett.Kivéve, ha nincs esetleg valamelyik régebbi xz-ben is backdoor.
-
válasz
sh4d0w
#33859
üzenetére
De, valójában escapelni kell a wildcardokat, abban az esetben, ha a helyi könyvtárban van a wildcardnak megfelelő nevű fájl.
A shell megpróbálja kifejteni, ha sikerül, helyettesíti, ha nem sikerül, akkor nem. Neked azért működött, mert nem sikerült.szerk: tuttira. az előbb teszteltem.
-
CPT.Pirk
Jómunkásember
válasz
sh4d0w
#33831
üzenetére
Az nVidia developre repója hozzá lett adva, mert cuda specifikus lib-ek nincsenek meg a zárt driverben. De most nem tudom mit tudok kezdeni ezzel a helyzettel, hogy a csomag verzió nevek nem stimmelnek össze:
535.154.05-0ubuntu1-vs- 535.154.05-0ubuntu0.22.04.1
Eddig sem értettem az Ubuntu csomag elnevezési szisztémáját...
-
válasz
sh4d0w
#33828
üzenetére
Futottam egy kört live-ban mindkét rendszerrel. A ClearOS nagyon gyors, ezen a régi vacak gépen is kb. 8 másodperc alatt bebootolt. Érdekes a csomagkezelője, package helyett "bundle"-t használ, és a dokumentáció szerint egy bundle mindent tartalmaz, amire az adott szoftvernek szüksége van, és minden szoftverösszeállítás egy egyedi verziót képvisel, és könnyen lehet rollbackelni a verziók között (kicsit hasonlóan, mint gitnél). Emiatt a bundle-s megoldás miatt elméletileg nem alakulhatnak ki függőségi problémák, egyébként tud delta update-et is, a csomagokból csak egy-egy fájlt frissíteni.
Ez nekem így szimpatikus, csak nagyon kevés bundle van hozzá, de gondolom amiatt, mert alapvetően nem asztali felhasználásra szánták, hanem inkább vm-ek és konténerek hostolárása.A CachyOS-t is megnéztem, háát... az Arch vonal sosem volt az én világom, és ha a CachyOS-en múlik, akkor nem is lesz
Amúgy ugyanarról a pendrive-ról, ugyanazon a gépen kb. 40 másodperc alatt bootolt be.Az asztali környezeteket még nem próbáltam ki. Azt közben láttam, hogy a CuteFish-t nem fejlesztik.
Az viszont, hogy az UKUI kínai, nem zavar, nyílt forráskódú az egész (amúgy a Google-nél, a Facebooknél és a Microsoftnál nagyobb adathalász cégek nem léteznek, a kínai pártállam hozzájuk képest amatőr kisóvodás). -
vicze
félisten
válasz
sh4d0w
#33420
üzenetére
Microcode még csak is kizárólag Rome-hoz van, (az lenne ez), a többihez még nincs. A linkek nem tudom mit szeretnének mutatni(egyik egy példa egy 4éves mikrokód frissítésre, a másik leírja, hogy csak Rome-ához van), az AMD hivatalos target ideje október-december.
Tehát még egyszer Rome-ot kivéve semmire nincs ebben a pillanatban javítás mikrokód szinten, Linux 6.5 RC3-ba a bit állítás és a Roma mikrocode kivétel került bele, de ezen a verzión elég kevesen vannak...Aki telepíteni akarja a workoround-ot akkor ennyit kell csinálni:
apt install msr-tools (ki milyen csomagkezelőt használ)
modprobe msr
wrmsr -a 0xc0011029 $(($(rdmsr -c 0xc0011029) | (1<<9)))A bit egy nem dokumentált kapcsoló, és AMD-n kívül senki se tudja, hogy mit csinál...
Remélem hamarosan elárulják, mert így elég érdekes CPU beállítást módosítani...Az SW oldali fix-ek nagy eséllyel (főleg böngésző) előbb lesznek mint mikrokód, AGESA, vagy bármi más.
Szerk:
Engem is ott cseszeget tegnap óta:
amd64-microcode/focal-updates,focal-security 3.20191218.1ubuntu1.1 amd64 [upgradable from: 3.20191218.1ubuntu1]
Ettől nem lesz a hiba kijavítva, nem lesz javított mikrokód, csak a fenti bit fix kerül bele, amit nem tudja senki, hogy mit csinál... Állítólag javítja, reméljük igen, és nem okoz más problémát. -
vicze
félisten
-
Vladi
nagyúr
válasz
sh4d0w
#33346
üzenetére
A minimum, hogy valamelyik civil szervezet bíróságra viszi. Viszont lehet, hogy itt az ideje a gpl v4-nek.
(#33350) emvy:
2004-től 2013-ig ez nem volt bosszantó? most ez bosszantó, vagy az a baj, hogy nem lehet maximalizálni a profitot? Most akkor a redhat veszteséges lett?
-
-
válasz
sh4d0w
#33344
üzenetére
Oke, a lentebb linkelt szovegben nem lattam arra utalast, hogy megtiltana a customereknek, hogy megosszanak forraskodot. Van linked erre?
(BTW, egyaltalan nem gondolom, h a Red Hat valami jo vagy ertelmes dolgot csinal -- nem latom, h igy lenne. De a GPL-sertest se latom egyelore.)
-
válasz
sh4d0w
#33341
üzenetére
> nem teszi vissza a kozosbe, amit onnan kivett - es az az a pont, ahol valoszinuleg GPL-t sert a ceg.
A GPL-ben nincs szo olyasmirol, hogy 'vissza kell tenni a kozosbe'. A GPL arrol szol, hogy a szoftver hasznaloja szabadon hozzaferjen a forraskodhoz. A GPL nem szol arrol, hogy a kozossegnek vissza kell adni valahogy.
Konkretan lentebb linkeltem a GNU FAQ-jat, ahol cafoljak azt, amit (szerintem) gyanitotok.
"Red Hat customers and partners can access RHEL sources via the customer and partner portals, in accordance with their subscription agreement."
Tehat mindenki, aki a Red Hat-tol kap binarist, elerheti melle a forraskodot is.
-
shina
tag
válasz
sh4d0w
#33311
üzenetére
Bár a Red Hat sok projekthez ad hozzá nem triviális mennyiségű kódot, de ettől szerintem nem kell tartani. Egyrészt a systemd-t leginkább Microsoft (ugye a főfejlesztő Lennart Poettering is itt van), Meta, és Suse szoftvermérnökei írják, másrészt a GPL miatt bármelyik Red Hat előfizető elkérheti a forráskódot és kirakhatja a netre büntetés nélkül, ha a Red Hat féle patchekre is szükség van. Az IBM itt már nem sok vizet zavar.
-
válasz
sh4d0w
#33311
üzenetére
> Mi lesz, ha eccercsak az IBM aszondi, hogy ez már az ő szellemi IP-je és magasról tesz a GPL-re
Szerintem nem tehet magasrol a GPL-re, tul kockazatos a jatek. A GPL senkit nem kotelez arra, hogy siman publikalja a kodjat, nem? Az usernek kell megkapnia.
Licenszet barmikor lehet cserelni, nyilvan, a kovetkezo verzioban.
-
Vladi
nagyúr
válasz
sh4d0w
#33311
üzenetére
te vén róka vagy itt, az sco sztorira emlékszel? Most itt tömeges pert kellene indítani, mert gyakorlatilag megsértik a gpl-t. mostjuk az fsf az ilyesmire van.
A másik: láttad valaha, hogy a redhat egyébként mit szponzorál? Az összes gpl kónak nagyjából 1/3-a fizetett programozók munkája. Most mi van akkor, ha az ibm elkezd felvásárolni és bezárni? Mondjuk libreoffice, gnome3...
-
-
#33209
Neil Watts
veterán
sh4d0w
#33208
-
válasz
sh4d0w
#32798
üzenetére
Nem tudom, nem jottunk ra. Ryzen 3600-as szervereken neztuk, determinisztikusan softlockupoltak a gepek par naponta, tucatnyi. Default Ubuntu 22.04 minimal installacio + K8s.
https://forum.proxmox.com/threads/kernel-bug-cpu-soft-lockup-vm-host-freezes.110059/
Ezt talaltuk, ami kozel all a problemahoz.
"Since I downgraded to 5.11 it did not crashed while it was crashing several times a day on 5.15 and 5.19." -- ezt esetleg probald meg meg. Nekunk nem jott be.
-
-
vicze
félisten
válasz
sh4d0w
#32564
üzenetére
Mindenki nyilván azt és úgy használja ahogy akarja semmi közöm hozzá.
De személy szerint úgy érzem, hogy Debian igen nagy mértékben hozzájárul ahhoz, hogy Linux ne fejlődjön olyan mértékben ahogy kéne és nagyon sok új technológia nagyon-nagyon lassan adoptálódik a Debian extrém konzervatív hozzáállása miatt. És nem azt mondom, hogy egy Arch legyen YOLO módjára, de van ésszerű középút.
Már a legtöbb LTS distro is belátta, hogy értelmetlen visszatartani a kernelt, mert ahhoz vezet hogy újabb HW-n használatlan lesz. Még a legfrissebb Linux kernel is sok esetben lemaradásokkal küzd, az utóbbi 4-5évben.Amúgy akkor szerinted DDoS egy fűzfal esetében nem security probléma?
-
válasz
sh4d0w
#32576
üzenetére
az l7 tűzfalak, szerintem, mind valamilyen applikáción keresztül szűrik a magasabb szintű forgalmat. Nagyon-nagyon alap szintű l7 szűrést lehet csinálni a kernellel is, de nem feltétlenül érdemes.
a mikrotikben szerintem nincs l7 szűrési lehetőség. azok egyébként viszonylag sztenderd arm magos, korábban mips magos cpu-kon futó nagyjából sztenderd linux kernelek.
-
válasz
sh4d0w
#32569
üzenetére
Szervert nem szoftveres tűzfallal védünk elsősorban, hanem hardveressel. Ha kell az otthoni szerver, tegyél elé rendes eszközt: Bitdefender, WatchGuard, Mikrotik, Netgear - és akkor nem probléma, hogy az iptables kicsit többet eszik a CPU-dból, mint az nftables
Hülyeség, egy mai Linux bőven megállja a helyét közvetlen az interneten. Lassan a core network routerek 100%-a Linuxot futtat. Plusz a dedikált firewall eszközök is általában Linuxal mennek.
Különösebb baj amúgy nincs az iptables-el. Ami szerintem nagy hibája az a teljesen külön IPv4 és IPv6 stack. De mivel amúgy mindkettő netfilter module akár egyszerre is használhatod a kettőt.
-
f_sanyee
senior tag
válasz
sh4d0w
#32558
üzenetére
Red Hat, Fedora itt pl igy van.
RHEL8 óta van nftables btw.iptables vs nftables:
igazábol kár ezen vitázni, ha valaki megszokta és ragaszkodik a legacy toolokhoz, használjon iptables, nslookup, ifconfig, meg hasonló deprecated parancsokat amíg teheti, aki pedig inkább tanulna valami újat, annak ott az nftables... -
Shyciii
veterán
válasz
sh4d0w
#32564
üzenetére
Debian cutting edgelése (Testing verzióra gondoltál ugyebár) nem csak stabilitás vész oda, hanem a biztonsági frissítések azonnali megkapása is, ugyanis nem egy időben kapja meg a Stable verzióval. Bár ezt nem említetted, de biztos tudod, ha már 8 éve Debian-t használsz ugyebár, és ha már konkrétumokat vársz...
Értem, hogy az iptables nem skálázódik jól, esetleg lehetnek vele performance problémák (a mai hw környezetben ez tényleg számít?), de hogy jön ide a biztonság?
Jössz a performance-al, ami mai hw környezetben nem számít. Jaj...Először is, ha csak nem rendelkezel Google féle szerverparkkal, akkor te, vbagy az általad üzemeltetett gép, nas, home szerver pillanatok alatt megfexik DOS, vagy DDOS alatt, de ha xmas tcp-vel floodolnak akkor is. Egyáltalán maga a feltételezés hogy egy tűzfal, vagy bármilyen biztonsági eszköznél nem számít a performance...ez nagyon az úristen kategória. Csak úgy közlöm, hogy igencsak baromira számít a performance mind szoftveres oldalon, mind hardveres oldalon. Ugyanis az sem mindegy, hogy milyen hálókártyád van, és ahhoz milyen drivert használsz.
Az meg hogy "hogy jön ide a biztonság" kérdésed egy tűzfalas beszélgetésnél, meg végképp vicc. Bocs, de pont ezért nem válaszoltam értelmesen, mert ez a dőlt betűs részed borzalmasan leírja, hogy mi a véleményed a biztonságról, és a hozzá kapcsolódó technológiáról, és működéséről. Amivel nem is lenne baj, csak akkor nem feltétlenül neked kellene diktálnod ebben a kérdésben, főleg nem egy haladó topicban. -
vicze
félisten
válasz
sh4d0w
#32560
üzenetére
Azért Debian nem éppen egy "cutting edge" distro, kb. az egyik legkonzervatívabb és legvisszamaradottabb. Nyilván megvan ennek is az előnye, de a jelenlegi frissítési tempó nagyon nem ez. (A májusi RHEL 9 újabb kernel verzión van, mint az augusztusi Bullseye.)
Sajnos van egy olyan következménye, hogy mivel sok minden épül Debianra, így minden mást is visszatart.
-
Shyciii
veterán
válasz
sh4d0w
#32560
üzenetére
Akkor másképp írom. A BTRFS is már régóta van, mégis "csak" most kezd szélesebb rétegben elfogadottá válni, a pipewire is van egy ideje, de csak most kezdett bizonyos distrokon default lenni. Ugyanez van az nftables-el is. El kellett érnie egy olyan "szintet", hogy azt mondják rá, hogy oké, stabil, gyors, biztos fogják fejleszteni sokáig, lehet ez a default most már.
Értem, hogy az iptables nem skálázódik jól, esetleg lehetnek vele performance problémák (a mai hw környezetben ez tényleg számít?), de hogy jön ide a biztonság?
Nah, ha ez egy komoly kérdés volt részedről, akkor teljesen felesleges ezt megválaszolnom, és így már értem, hogy miért tök mindegy neked egy tűzfal esetén, hogy egy elavult technológiájú iptables, vagy friss nftables. -
Shyciii
veterán
válasz
sh4d0w
#32556
üzenetére
Ha jobban megnézed, akkor azaz iptables, az valójában iptables-nft és külön van legacy. Értem én, hogy fel kell tenni az nftables csomagot, de valójában már a Bullseye-ban felkészítették a kivonásra az iptables-t. Jelen állapot szerint a következő verzióban végleg ki is kapják. Amúgy meg nem a Debian-t venném alapnak technológia kérdésekben, mert mindig le van maradva, főleg ha a stable verziót nézzük (nézd csak meg a btrfs filerendszert. Máshol már az a default, míg a Debian a közelében sincsen).
Szal egy többszörösen régi, és már "elavultnak" tekinthető tűzfalat én nem ajánlanék senkinek, már a munkámból kifolyólag sem, és biztonság miatt sem. Főleg hogy nem csak hogy többre képes az nftables, de még csak nem is rémesen bonyolultabb, mint az iptables. -
ledgeri
nagyúr
válasz
sh4d0w
#32449
üzenetére
Bele a kíváncsiság vitt, az első léps meg az volt, hogy felhívtak ezzel, a nulladik meg hogy már minden leakel/brechelt...
Ami meg sikeredett, hogy ők most abban a tudatban vannak (vagy hagytak abban a tudatban, hogy azt hiszem, hog abban vannak), hogy én épp egy Pestről Pécse költöző belső építész vagyok, aki tegnap azért nem jutott nethez, mert a kölcsön-laptopba dugott net-stick valamiért nem ment, de ma otthon rápróbált az ajánlatra:
Beregelt, szépen megadta a címét, mailjét, teló-számát választott portfoliót, és pont mikor az alapösszeget töltötte volna valamiért az nem ment át.
Hát de miért nem ment át, passz... pedig az elmúlt két hétben volt használva a kártya...
Megpróbáltuk a bankos belépést is. Még csak telós aszisztenciával, az sem ment...
Na csak ekkor néztek rá arra, hogy én milyen IP-ről is léptem be hozzájuk ami USA-s volt (a tor ott végződött)... de hát ezt hogy? ja hát akitől kölcsönkaptam a laptopot, ő egy android-App-Dev, és rajtafelejtette az autolauncheres VPN-t a gépen, és hát a gép is linuxosmert terminal, és én meg nem értek hozzá, ezért nem megy a banki oldal ahogy kéne, szóval akkor mobil, mint backup.![;]](//cdn.rios.hu/dl/s/v1.gif)
Azzal meg az a baj, hogy csak buta-teló, mert az okos pont két napja lecsúszott egy költözős dobozról, így még bank appozni sem lehet. de van megoldás:
Kaptam 3 bankszámlaszámot amire küldhetem az alaptőkét, csak hát beszéltünk egy órán át, és már pont zárogattak a bankok. Holnap meg, hát költözök és kitudja mikor jutok oda hogy ezzel foglalkozzak...
Minden ami dölt az kitaláció vagy fedés, mivel nem én kezdtem így a szám amiről épp beszéltünk az az egyedüli fix.
A három bank.-számmal már ha eljutok oda tudok feljelentést tenni, más kérdés, hogy megéri-e a cécó az én oldalomon... sajna a háttérben hallottam pár "ohh, we have recived the founds, madam"-ot, szóval megy az ottani business rendesen.
Minimum velem töltött kb 1-2órát, nem mással, max meg a 3 számlaszáma lecserélendős lesz nekik.
Ja és nincs igazán ennek topikja itt... szóval bocsi!
-
ledgeri
nagyúr
válasz
sh4d0w
#32434
üzenetére
"én gépemnek" számít-e egy tails-es, TORon keresztül kommunikáló tesztkörnyezet, amin nincs háttértár?
Nem tudom, hogy milyen 20%-ot említesz...& #32436 inf3rno Azért a "nincs szükségem eszközre" és a "majd visszahívom miután csekkoltam a dolog hitelességét" az feltételezné, hogy lehet, hogy valós dolog miközben tudom hogy egyértelműen nem az. Emiatt jöttem ide, hogy megtudjam melyik OS szintű váltás a legbiztosabb (gondolnám, hogy nem alaplap, CPU, viedeókari meta-azonosítók alapján fognak levadászni, IP-t meg addig a pár napig, míg nem kapok újat a szolgáltatótóla beépített toron-átvezetés is megoldja így egy OS csere az elégséges, csak hogy mivel ehhez már kell a linux féle rugalmasság és áttekinthetőség kell), és vannak szaki disztrók, jöttem kérdezni a legajánlottabbakról.
De akkor marad a tails, és holnap lefutom körömet... -
janos666
nagyúr
válasz
sh4d0w
#32094
üzenetére
Nem, mert ez egy általam konfigolt Gentoo, és a rendszer egy külön SSD-ről fut, nem erről a HDD tömbről.
A rendszer single/single filerendszerén nem szivárog el a szabad hely, de a HDD-s RAID5 tömbön kitartóan.
Snapshot csak backup kezdetekor kèszül, a végén pedig törlődik, és ellenőriztem, hogy törlődött.
Defrag fut rajta minden este, de nincs deduplikáció, vagy snapshot, amit "kibontson" (ez a backup után fut, és most sincs ottragadba a "back" nevű mappa, ami a snapshot lenne). -
válasz
sh4d0w
#32019
üzenetére
Na jó, de nem csak ISO-t, hanem akármit, vhd, qcow, img... lenne jó.
(Nem tud a virtuálhostom PCIE passthrough-t, és kéne a hostban levő nyomtatóportot OS-nek adnom néha... ez legegyszerűbb, ha nem kell külön háttértárat, vagy partíciót adni neki, hanem image-ből tudnám bootolni.) -
Meg azé, hogy feltűnik-e valakinek.
Látod, most is komolyan vettem a dolgot, egyből lecsekkoltam a Mint-et meg az LMDE-t.
Remélem hamarosan elárulják, mert így elég érdekes CPU beállítást módosítani...
![;]](http://cdn.rios.hu/dl/s/v1.gif)
nah, erre gondoltam én is, h semmi mail service nem fut, hogy küldené? De a többi rész az érdekes inkább, a clamscan. Lehet verbose-ra rakom, mert most log sem volt. Azt nem tudom, hogy ha a cli ablakot bezárják, attól a folyamat leáll-e 
Új hozzászólás Aktív témák
- Kaspersky, BitDefender, Avast és egyéb vírusírtó licencek a legolcsóbban, egyenesen a gyártóktól!
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Assassins Creed Shadows, Civilization VII, Battlefield 6 és Dying Light: The Beast, az utolsók!
- Eladó Steam kulcsok kedvező áron!
- Vírusirtó, Antivirus, VPN kulcsok
- Apple iPhone 14 128GB, Kártyafüggetlen, 1 Év Garanciával
- Bomba ár! Lenovo ThinkPad T460 - i5-6GEN I 8GB I 128GB SSD I 14" HD I Cam I W10 I Garancia!
- Azonnali készpénzes INTEL CPU AMD VGA számítógép felvásárlás személyesen / postával korrekt áron
- ÁRGARANCIA!Épített KomPhone Ryzen 7 7700X 32/64GB RAM RTX 5070 Ti 16GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RX 9070 XT 16GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest