- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- GoodSpeed: ASUS ROG STRIX B650E-F GAMING WIFI - Power Connectors evolúció 21 év alatt
- bb0t: Gyilkos szénhidrátok, avagy hogyan fogytam önsanyargatás nélkül 16 kg-ot
- Meggyi001: A Lidl Silvercrest kenyérsütő jó?.........Jelentem:Jó!
-
IT café
Debian GNU/Linux
Új hozzászólás Aktív témák
-
urandom0
aktív tag
válasz Shyciii #9704 üzenetére
Tudtommal erre nincsen minden kétséget kizáró módszer. Pont nemrég olvastam, de már meg nem mondom, hogy hol, de egy disztró összeállító blogger panaszkodott, hogy az egyik probléma a grafikus csomagkezelő fejlesztésével, hogy sok csomag nem jelez vissza, ha újraindításra van szükség.
-
urandom0
aktív tag
válasz trapi007 #9707 üzenetére
Hogy eth0 helyett enp2s0 van, az új elnevezési konvekcióknak köszönhető. Ezt vissza lehet állítani, ha megkeresed az /etc/systemd/network/ könyvtárban az adott kapcsolathoz tartozó link fájl (nálam ez 50-wired.link), és kitörlöd.
De szebb megoldás, ha készítesz egy udev szabályt, valahogy így: https://www.shellhacks.com/change-network-interface-name-eth0-eth1-eth2/
Tehát a /etc/udev/rules.d/70-persistent-net.rules fájlban lesz egy ilyen sorod:
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*",
ATTR{address}=="00:00:00:00:00:00",ATTR{dev_id}=="0x0", ATTR{type}=="1",
KERNEL=="eth*", NAME="eth0"Ahol az ATTR az adott hálózati interfész MAC címe kell legyen.
-
urandom0
aktív tag
A backports nem tartalmazza a stable összes csomagját, hanem csak annak egy részhalmaza (ha jól számolom, bullseye-backportsban 737 csomag van, míg a stable main-ben 4846). Úgy készül, hogy vesznek a testingből néhány csomagot, azokat lefordítják a stable-ben, letesztelik, és ha minden oké velük, akkor mennek a backportsba. A szisztéma nagyjából ugyanolyan, mint ha Ubuntuhoz adnál hozzá egy PPA-t, hogy frissebb programverziód legyen.
Ennyit kell hozzáadni az sources.list-hez:deb http://deb.debian.org/debian bullseye-backports main
. A backportsban nincs ilyen felosztás, mint free nonfree contrib, csak main van. Utána kiadsz egy "apt update"-et és kész. Az APT alapesetben az elérhető legfrissebb verziót telepíti tehát a -t paraméter nélkül is mennie kell a frissítésnek.Amikor majd kijön az új stable, akkor az abban lévő csomagverziók meg fognak egyezni a backports-ban lévő verzióval (hiszen abból lett visszaportolva), tehát ebből bajod nem lehet.
Maximum annyi problémád lehet, hogy a backports-os csomagok nincsenek annyira alaposan letesztelve, mint a stable csomagok, de azért a Debian a testing ágon is bőven elég stabil, tehát nagy valószínűséggel nem lesz semmi gond. -
urandom0
aktív tag
A minimalizálással kevesebb erőforrása lesz lekötve a gépnek, de ezt a saját erőforrásaidból kell pótolni. Ez jellemzően sokkal több belefeccölt időt/energiát jelent, megtérülés pedig aligha van.
Ráadásul az ilyen minimalista konfigok jellemzően sokkal nehezebben adaptálódnak új környezetbe, vagy nehezebben küzdenek meg új kihívásokkal. Ez egy tipikus hozzászólás, valamelyik nap láttam valahol:
Well using pipewire instead of pulseaudio breaks my volume control key bindings in dwm, so I’ve reverted for now. Shall investigate further when I have more time.
Vagy mondjuk van egy tök frankón belőtt laptopod, ami otthon teljesen jól megy, de átviszed haverhoz, és ott rá kéne dugni az USB-s hangfalat, de ez már nem fog menni neki, mert annyira ki van heréve a rendszer...A másik téma, a tiling wm-et használni, ami tök jó addig, amíg terminállal meg egy-két egyszerűbb programmal kell dolgozni. De amint képbe kerül a böngésző, a Gimp. az Inkscape, a LO... ahol úgyis egérrel kell vakarászni, ott már elveszik a tiling előnye. Sőt, történetesen épp az fogja elvenni az idődet, hogy be kell állítani minden egyes ilyen programra, hogy ne tiling hanem float ablakként kezelje...
Most egy régi Lenovo laptopról írok (i5 4300U), Fedora Gnome van rajta. Én a Gnome-mal úgy vagyok, hogy feltelepítem, max 10 perc alatt belövöm aztán jóidő. Lehetne ezen is futtatni egy systemd-mentes disztrót mondjuk i3-mal, meg pipewire helyett ALSA-t használni, meg gdm helyett lightdm-et (vagy akár xdm-et),...
és akkor nem 3,6 GB RAM lenne foglalt, hanem csak mittudomén, 1,5 GB. De minek? Álljon üresen a RAM? Akkor minek vettem?
A sebességre így sem lehet panaszom, nagyon gyors minden. A négy mag így is alig dolgozik, jellemzően 40% alatt, ritkán megy afölé, de az idő nagy részében 20% alatt van.[ Szerkesztve ]
-
urandom0
aktív tag
Ezek a minimál konfigok arra jók, hogy amire az ember összerak egy ilyet magának, sok mindent megtanul. De ez is olyan, hogy szinte napról napra avul el. Emlékszem, régebben "xset m"-mel be tudtam állítani az egérérzékenységet, de egy időben ez már nem működött. Aztán rászoktam az "xinput"-ra, az egy darabig teljesen jó volt, de újabban már az sem megy. A Fedorámon már nincs is fent az xinput...
-
urandom0
aktív tag
A firmware-realtek csomagot kell telepítened.
Milyen Debianod van, 10 vagy 11?
Ha 10-es, akkor az /etc/apt/source.list fájlban ezek mindenképp legyenek benne:deb http://deb.debian.org/debian/ stable main contrib non-free
De ha ügyesebben akarod csinálni, akkor minimum ez legyen benne:
deb http://ftp.hu.debian.org/debian/ stable main contrib non-free
deb http://ftp.hu.debian.org/debian/ stable-updates main contrib non-free
deb http://security.debian.org/ stable/updates main contrib non-freeA végén szereplő non-free a lényeg, onnan fogja lehúzni neked a csomagot.
Ha hozzá van adva a sources.list-hez, akkor kiadsz egy
apt update
-et, majd egyapt install firmware-realtek
parancsot, és így fel fogja telepíteni a firmware-t.[ Szerkesztve ]
-
urandom0
aktív tag
A KVM kb. a legszélesebb körben használt virtualizációs megoldás. Rengeteg nagy forgalmú szervernek ez adja a virtualizációs rétegét, a Linux mellett MacOS-on is használdják, de pl. az Android Studio Linuxos változatának virtuális gépe is KVM-en alapul.
Otthoni felhasználás során nem annyira elterjedt, és emiatt nincs is annyira kényelmes felülete, mint a Virtualboxnak vagy VMWare-nek. De pl. a Gnome Boxes is KVM alapú, megpróbálhatod azt is. -
urandom0
aktív tag
Alapvetően én is Leap párti vagyok, de látván, hogy milyen régi Gnome van benne, inkább a Tumbleweedet telepítettem fel. Viszont valamit nem volt teljesen okés a telepítés folyamán, mert alapvető csomagok hiányoznak, a Gnome control center például el sem indult, amíg a libvulkan1 csomagot fel nem telepítettem.
Nem tudom, hogy a pendrive hibás-e, avagy a Tumbli, de szerintem én is dobok fel inkább egy Leap-et másik pendrive -ról.[ Szerkesztve ]
-
urandom0
aktív tag
válasz sh4d0w #10265 üzenetére
Azért ez a cikk...gondolom érzed te is, hogy van azért benne ferdítés, igaz? Azon problémázik, hogy egyes flatpakos programoknak van írási joga a /home-ba. De a natívan csomagolt programok közül gyakorlatilag mindegyiknek van, és még kikapcsolni sem egyszerű. Flatpak esetén legalább egyszerűbb letiltani, van rá GUI. Egyébként elég hülyén nézne ki, ha a Gimp nem tudna írni a /home-ba. Akkor hova menti a user a képeit?
Az, hogy valaki meg nem frissíti a saját maga által kezelt, csakis a saját felelőssége. Ne már a Red Hat meg a flatpak hibája legyen az, ha a maintainer tojik a frissítésre. Ennyi erővel megkérdezhetem azt, mi van, ha a natív deb-es git csomag marad foltozatlan a tárolóban? Akkor az ÖSSZES ettől függő program lyukas marad.
Ez a cikk kicsit olyan "belekötök az élő fába is" jellegű. -
urandom0
aktív tag
válasz SirRasor #10254 üzenetére
Elsőre nincs rendes megoldás a desktoposra: ez feature, ilyen az új Gnome. Xfce vagy bármi más jó megoldásnak.
Dehogy nincs, van rá kiegészítő: https://extensions.gnome.org/extension/4099/no-overview/
De ha feltelepíted mondjuk a dash-to-dock-ot vagy a dash-to-panelt, azokban is van ilyen opció. -
urandom0
aktív tag
válasz Roxkex #10245 üzenetére
Ez a kulcstartós dolog alapvetően úgy működik, hogy ha első alkalommal nem adsz meg semmilyen jelszót, csak simán nyomsz egy entert, akkor a továbbiakban nem fog jelszót kérni. Most ettől függetlenül is kérhet jelszót, mert vannak olyan alkalmazások, amik úgy vannak megírva, hogy minden alkalommal kérjen jelszót. Tipikusan ilyen, ha pl. az ssh kulcsot véded passphrase-el...
A Seahorse-ot nem érdemes letörölni, az igazából nem csinál semmit, csak egy grafikus előtétprogram a secret-service-hez ("titoktároló"). Ez a rendszer titkos adait (jelszavak, stb.) tároló szolgáltatás.
Seahorse-ban a jelszavaknál a kulcstartó jelszavát meg tudod változtatni itt:Megadod azt a jelszót, amivel bejelentkezel a rendszerbe, majd kétszer kérni fogja a kulcstartó új jelszavát. Ha itt entert ütsz, akkor elméletileg többet nem kérdezősködik.
Az nem fura, hogy az Opera jelszót kér, ugyanis a böngészők az érzékeny adatokat (helyileg tárolt jelszavak, tokenek, sütik, localstorage, indexedb, sessiondb...) titkosítva tárolják, és ennek a titkosításnak a feloldásához kell a titoktároló jelszava.
[ Szerkesztve ]
-
urandom0
aktív tag
válasz sh4d0w #10287 üzenetére
Senki nem mondta, hogy a Red Hat hibaja, ha a maintainer nem frissit, a formatumnak viszont hibaja.
Pedig nekem ez a rész eléggé úgy tűnik, hogy a Red Hatra próbálja kenni az egészet:
Let's hope not! Sadly, it's obvious Red Hat developers working on flatpak do not care about security, yet the self-proclaimed goal is to replace desktop application distribution - a cornerstone of linux security.
Szerintem a vitatott pontok amúgy nem a formátum hibájából erednek.
Viszont az, ha kritikus sechole-ek benne vannak egy flatpakben, a karbantarto nem tart karban es visszavonni sem lehet a kerdeses flatpaket kozpontilag - na az ultragaz.
Ez nem így van, az adott flatpak terjesztő oldal (ami általában a flathub) adminjainak kell írni egy e-mail, megvizsgálják az adott flatpak csomagot, és ha kell, eltávolítják.
A flatpaket senki nem nezi at, release idejen is lehet benne akarmilyen kritikus hiba, azt sem vizsgalja senki, hogy egy korabban artalmatlan csomagba nem rakott-e a fejleszto vmi disznosagot.
Ez sincs egészen így, minden csomagot átvizsgálnak, legalábbis a flathubon biztosan. De ha ez így is van, ahogy leírtad, akkor ez megint csak nem a formátum hibája, hanem azé, aki az adott infrastruktúrát üzemelteti, és tojik rá, hogy milyen csomagok kerülnek fel az oldalára. Ha egy flatpak csomagot nem hajlandó frissíteni a maintainere, le kell szedni és kész.
Új flatpak csomagoknak egyébként már a portals API-t illik használniuk, azzal pedig még annyira sem férnek hozzá a fájlrendszerhez, mint egy átlagos natív deb csomagos program.
szerk: egyébként elsősorban én is a disztró natív csomagjait használom, csak akkor nyúlok flatpakhoz, ha nincs natív csomag, vagy ha nagyon régi.
[ Szerkesztve ]
-
urandom0
aktív tag
válasz sh4d0w #10289 üzenetére
Speciel pont nem a Red Hates resz az, ami miatt linkeltem az irast - ha eddig nem lett volna egyertelmu.
Tudom, nem is rád értettem, hanem a cikk szerzőjére.
ne irogasson semmit se a user home-ba, se mashova, csak a sajat kis konyvtaraba, ha a usernek kell onnan valami, majd kiszedi egyszeru filerendszer muveletekkel.
Ne haragudj, de ez egy baromság. Én ebbe belefutottam pár éve, a Gimp-nek egyik kezdetleges flatpak verziója nem tudott a home-ba írni. Úgy nézett ki a dolog, hogy menteni akartad a képet, a save as ablakban kijeltölted a home-ot, de az nem a valódi home volt, hanem a ~/.var/app/org.gimp.GIMP/... alá bemappelt könyvtár. Hogyan néz már ki az, hogy a user nem tud írni a saját home-jába? Mondjuk egy zenelejátszó nem tudja listázni a zenéidet, mert nem fér hozzá a ~/Music-hoz? Vagy a képnézegetővel nem tudod taggelni a képeid, mert nem fér hozzá a ~/Pictures-höz? Ez nonszensz...
Ilyet flatpakkel nem tudsz csinalni.
Ezek a sechole-os cuccok valóban gázak, ezek szerint változott a policy, régebben az ilyeneket ideiglenesen elérhetetlenné tették, sok contributor sírt is emiatt a fórumon. Erre az a megoldás, hogy erősebb szabályozás kell. Az megint más kérdés, hogy ezek a sebezhetőségek mennyire használhatók ki.
Az olyan csomagokat, amiknél fel van tüntetve, hogy elavult, sebezhetőség van benne, stb., én azokat fen hagynám, esetleg valami jól látható jelzést még tennék oda.
-
urandom0
aktív tag
Nem így van.
Nem maga a flatpak a veszélyforrás, hanem a maintainerek meg az adminok hozzáállása. Ha Debian alatt ugyanilyen nemtörődöm hozzáállás lenne a maintainerek részéről, az sem lenne biztonságosabb.
Az a történet például megvan valakinek, amikor a Void Linux csapat vezetője hónapokra eltűnt, és egyedül neki voltak meg a core repók kulcsai? Egyedül ő fért hozzá a Githubhoz (meg az egyik fő domainhez, az IRC-hez...). Ezen idő alatt a userek egy szál biztonsági frissítést nem kaptak.
Ezek mind emberi hibák, amiket ki lehet küszöbölni. De nem a flatpak hibájából erednek."tehát egyre kisebb az emberi erőforrás igénye egy csomagolási eljárásnak, miért is kell dobni"
Nem kell dobni, senki nem akarja dobni a natív csomagokat. Egyébként flatpak csomagokra is ugyanúgy fel lehet állítani egy automatikus csomagolási pipeline-t, ahova betolják a forráskódokat és egyéb erőforrásokat, és a végén kipottyan a csomag (a Flathub pontosan ezt is csinálja).
"Miért kell a népet egy tipikusan windowsos agyhalál elé terelni?"
A flatpak pont nem Windowsos, nincs is a Windows-ban olyan, ami hasonlítana rá.
"Leterakni az alkatilag ellenálló rendszert potenciális veszélyforrással???"
A legtöbb Linux disztró alkatilag nagyon nem ellenálló. Nincs bennük semmilyen vírusírtó, nincs bekapcsolva a tűzfal, nem sandbox-ban futnak a programok, az X nagyon sok disztróban még mindig rootként fut, létezik az LD_PRELOAD típusú agymenés, ami jobb helyeken évtizedek óta tiltva van... egy átlagos desktop Linux disztró egyetlen okból biztonságosabb, mert nagyon kevés Linuxra írt vírus létezik, azok is jellemzően a szerveroldalt támadják.
Ha most én bejuttatnék valahogy a gépedre egy keyloggert, hogyan vennéd észre? Gondolom, vírusírtót nem használsz.Másrészről alapvetően a flatpak épp, hogy ellenállóbb tud lenni (ha rendesen meg van csinálva), mint a natív csomagok, mert alapvetően egy natív csomagból indított program bármit megtehet, amit te is, míg flatpak esetén legalább le lehet korlátozni, hogy mihez férhet hozzá. Persze, lehet korlátozottabb user nevében futtatni a programokat, meg van SELinux, Apparmor, stb., de ezeket néhány programok kívül egyik sem használja alapértelmezetten.
-
urandom0
aktív tag
válasz sh4d0w #10296 üzenetére
A user írjon a könyvtárába, a biztonságosnak talált Debian csomagból telepített app írjon a könyvtárába, megbízhatatlan process meg írjon a saját sandboxába.
Nekem olyan Gimp nem kell, ami nem tud írni a /home/Pictures mappámban, én az ilyenre azt mondom, hogy bugos, vagy valami el lett kefélve a csomagolásnál. Persze, biztonságosnak biztonságos, de inkább ne.
-
urandom0
aktív tag
Nem. Úgy értem, hogy nekem olyan Gimp nem kell, ami nem fér hozzá a saját fájlaimhoz. Ha elindítom a Gimpet, és odanavigálok a Pictures könyvtáramhoz, akkor érje el, ami abban van, tudjon belőle olvasni és írni abba.
Az megint más kérdés, hogy a portal API épp az ilyen jellegű problémák megoldására jött létre. Egy korrektül összerakott flatpak csomagnak az esetek túlnyomó többségében nincs szüksége arra arra, hogy filesystem=home jogosultságot kérje magának, tehát hogy egy az egyben elérje a user dolgait. Ehelyett dbus-on keresztül megüzeni az org.freedesktop.portal.FileChooser portalnak, hogy legyen kedves megnyitni egy fájltallózó ablakot, hogy a user ki tudja választani azt a fájlt, amivel dolgozni szeretne, és akkor a rendszer ezt megteszi neki, és innentől fogva a program eléri azt az egy fájlt. És innentől fogva nem lehet megcsinálni az ilyen echo download_and_execute_evil >> ~/.bashrc jellegű aljasságokat, mert a program csak és kizárólag azokat a fájlokat éri el, amiket a felhasználó explicit módon megenged neki.
-
urandom0
aktív tag
válasz growler #10301 üzenetére
Alapvetően nem is nagyon van szükség rá, mert ha a csomag jogosultságai észszerűen vannak beállítva, akkor azon nem nagyon fogsz te állítgatni semmit, mert az funkcióvesztéssel jár. Mittudomén, beállítod a VLC-nek, hogy ne érje el a hálózatot? Minek? Nem listen-el egy porton se... vagy beállítod a Cheese-nek, hogy ne érje el a kamerát?
Persze, lehet olyan eset, amikor szükség van rá, de szerintem ez nagyon ritka.
-
urandom0
aktív tag
válasz olivera88 #10327 üzenetére
El kéne távolítani az nvidia csomagját, blacklistre kéne tenni a modulját vagy olyan kernel paraméterrel indítani, hogy az i915-öt használja. Én most ezt így mobilról nem tudom leírni, de ha utánajársz, találni fogsz hozzá anyagot. Remove nvidia package, blacklist nvidia, ilyen kifejezésekkel keress rá
-
urandom0
aktív tag
Az ilyen évtizedes támogatásokkal rendelkező kernelek inkább csak beágyazott rendszerek számára készülnek?
A beágyazott eszközökre - ha csak külön szerződés nem rögzíti - a legritkább esetben szoktak frissítések jönni, kivétel a mobilok, ott egyre inkább kezd terjedni a long term support.
Jellemzően inkább olyan enterprise szervereken használnak igen hosszú támogatású rendszert, ahol mission critical cuccok futnak, és nem lehet megengedni azt, hogy egy frissítés miatt esetleg ne működjön valami.
Pl. a Rocky Linuxnak, amit sokan a régi CentOS helyettesítésére használnak, a 2022-ben kiadott release-nek 2032-ig tart a security supportja. -
urandom0
aktív tag
-
urandom0
aktív tag
válasz g.gergo #10600 üzenetére
Határozottan nem illik bekapcsolni az SMB 1.0-át, és nem is kell a Sambához, mert ismeri a 2-es és 3-as verziókat is. A Samba konfigjában kell kényszeríteni:
server min protocol = SMB3_11
Itt vannak a lehetséges opciók: https://www.samba.org/samba/docs/current/man-html/smb.conf.5.html#SERVERMAXPROTOCOL[ Szerkesztve ]
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Alpha Laptopszerviz Kft.
Város: Pécs