- Samsung Galaxy S24 Ultra - ha működik, ne változtass!
- Fotók, videók mobillal
- iPhone topik
- Erős specifikáció, kompakt formában
- Honor 200 - kétszázért pont jó lenne
- Samsung Galaxy S21 FE 5G - utóirat
- Samsung Galaxy S23 Ultra - non plus ultra
- Yettel topik
- Android alkalmazások - szoftver kibeszélő topik
- Milyen okostelefont vegyek?
-
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
-
-
-
urandom0
senior tag
Viccesek ezek az OpenBSD-s srácok, egy tegnapelőtti e-mailben felvetették, hogy gzip-ről át kéne állni xz-re, abból is a v5.6.1-es verzióra, mert az biztonságos: https://marc.info/?l=openbsd-cvs&m=171200100510963&w=2
Nem sokkal később Theo de Raadt, az OpenBSD és az OpenSSH projektek alapítója, beküldött egy olyan e-módosítást, hogy "remove useless whitespace; from Jia Tan"
-
urandom0
senior tag
Lecseréltem az oprendszer a Raspberrymen.
Eredetileg Fedora IoT-ot akartam rá, de háromszori próbálkozásra sem sikerült elindítanom az installját, aminek magától el kellett volna indulnia. Sebaj, gondoltam, úgyis kísérletezős kedvemben vagyok, feldobtam rá egy Devuant. Oké, frankó, működik, és nagyon gyors, csak hát na... az összes disztróm systemd-es, vannak systemd service fájlaim, én systemd-re vagyok berendezkedve, úgyhogy gondoltam, legyen inkább Debian (Raspberry Pi OS), mégis csak ez a hivatalosan ajánlott rendszer RPi-re.
Ez is felment, frankó, működik, elkezdtem összerakni a dolgaim, Apache virtual hostok, radicale, stb., na a radicale elhasalt, egy csodálatos hibaüzenet (valami ilyesmi volt, hogy requests.exceptions.SSLError: HTTPSConnectionPool(host='www.url.com', port=443): Max retries exceeded with url: (Caused by SSLError(SSLError(336265225, '[SSL] PEM lib (_ssl.c:3837)')))) és fél méter traceback kíséretében (persze, ezt is úgy kellett kikönyörögni tőle, alapból csak az stdout-ra logol). Valószínűleg valami Python hiba lehetett, amit azóta javítottak, de Debian-ig még nem csorgott le a javítás.Na jó, mondom, a Debian nem a barátom, keressünk mást. Mivel úgyis RHEL-alapú rendszert akartam rá, elkezdtem vacillálni a Rocky és az AlmaLinux között. A Rocky jelen pillanatban népszerűbb, úgyhogy az ment rá.
Feltelepítettem, beállítottam a szokásos dolgokat, hozzáadtam az RPM Fusiont (ez hozza magával az EPEL-t is), és összeraktam a radicale szerverem, és most teljesen jól működik. Általános használat közben egy kicsit lassabb, mint Devuannal, illetve hát a dnf jóval lassabb, de legalább minden működik.
Egyetlen egy hibába futottam bele, segfaultot dob, ha kbdrate-tel állítgatom a billentyűzetet, de ez valami RPi specifikus hiba lehet, mert másnál is előjött már évekkel ezelőtt Raspbian alatt. -
urandom0
senior tag
Az xz backdoorhoz még annyit, hogy valaki csinált egy idővonalat, ami összefoglalja Jia Tan "fantasztikus" munkásságát, illetve néhány más érdekességet is lehoz: https://boehs.org/node/everything-i-know-about-the-xz-backdoor
Ebből is látszik, hogy már 2021-ben próbált ő backdoort csempészni a libarchive kódjába, illetve később több kamufiókkal együtt próbáltak nyomást gyakorolni, hogy a patchjeik kerüljenek bele a kódba, azután pedig el akarták érni, hogy az xz projekt vegyen be új fejlesztőket, ami sikerült is, így került be Jia Tin a fejlesztésbe. Az egyik nyomásgyakorló, "Jigar Kumar" szomorúnak tartotta (akit se előtte, se azóta nem látott senki), hogy az xz projekt nem halad, mert a jelenlegi maintainer (Lasse Collin) elvesztette az érdeklődését a projekt iránt, vagy nem törődik többé a karbantartással.
Biztos, hogy szervezett akció volt ez az egész, nem kizárt, hogy valamelyik kormányzat áll mögötte. -
urandom0
senior tag
Persze, jó a nyílt forráskód, én a kényesebb adataimat nem is bízom zárt forráskódú programokra.
De ez a történet nem ilyen egyszerű. Itt emberi hibák is bőven belejátszottak abba, hogy ez megtörténhetett. Az egyik ilyen az volt, hogy Lasse Collin volt az xz egyedüli fejlesztője, aki mellékállásban, hobbiként csinálta, és aki egyébként mentális gondokkal is küzdött. Ami mondjuk nem meglepő, ha azt vesszük, hogy az xz egy kurva fontos szoftver az egész open source közösségben, és nyilván egy ilyen fontos szoftver fejlesztőjeként nem kis nyomás van rajtad.
Lehet, hogy ez az egész nem történt volna meg, ha a nagy cégek (Red Hat, Suse, IBM, Intel, Canonical...) kicsit jobban odafigyelnek az xz projektre, és nem egyetlen emberre bízzák az egészet. Jó lenne, ha ezek a cégek prioritizálnák a dolgaikat, és nagyobb hangsúlyt fektetnének a fontos szoftverekre, ahelyett, hogy a libadwaitát reszelgetik, hogy bugyirózsaszín ablakkeret mellé babakéket is be lehessen állítani.
Itt azért nem érvényesült a manyeyeball, mert nem volt manyeyeball. A backdoor sem azért derült ki, mert valaki vizsgálgatta a forráskódot, hanem mert a bináris túl nagy CPU loadot generált.
És mondhatnám azt, hogy zárt forráskódú programba eleve nem tud bekommitolni senki sem backdoort. De teljesen mindegy, szerintem ez a mostani egy tipikusan olyan dolog, amit nem lehet kivédeni. -
urandom0
senior tag
válasz
bambano
#33977
üzenetére
Nem mondom, hogy nincs igazság abban, amit mondasz. Az tény, hogy a systemd marha nagyra nőtt, és ott van már PID1-ben majdnem az egész Linux, és ez nem biztos, hogy jó így.
De ez itt nem a systemd hibája volt. Ha bele akarunk menni, megkérdezhetjük, hogy miért gondolták jó ötletnek azt, hogy az sshd dependáljon a systemd-re? Én nagyjából tudom (mert utánaolvastam), azért, mert a systemd által nyújtott sd_notify() fv-t használja arra, hogy értesítse a systemd-et arról, amikor elindult.
Nem lehetett-e volna megoldani valami jó kis POSIX cuccal, vagy UNIX socket domainnel?
De biztos meg lehetett volna, de szerintem teljesen jogos volt a maintainerek törekvése arra, hogy ha már úgyis systemd-es környezetben fog futni az sshd, akkor használjuk már ki a systemd szolgáltatásait (ezzel systemd függővé tenni az sshd-t), mert hogy ennek előnyei is vannak. Nyilván, ha nem lennének előnyei, nem használnánk.
Tehát itt volt egy döntés a Debian és néhány másik disztribúció részéről, aminek lettek következményei. De szerintem ebbe nem nagyon lehet belekötni. -
urandom0
senior tag
válasz
urandom0
#33969
üzenetére
Na még ennyit: a backdoort Andreas Freund - Microsoft dolgozó - vette észre, amikor egy friss xz csomaggal ellátott Debian Sides gépre be akart jelentkezni SSH-n keresztül. A bejelentkezés irreálisan nagy CPU terhelést okozott, és a Valgrind hibákat dobott, ezekből vette észre, hogy valami nem okés. Itt az e-mailje: [link]
-
urandom0
senior tag
válasz
urandom0
#33969
üzenetére
Még egy érdekesség, a Jia Tan által beküldött commitban van egy szándékos hiba. Ezt úgy idézte elő, hogy az egyik függvény (my_sandbox) elé berakott egy .-ot: https://git.tukaani.org/?p=xz.git;a=commitdiff;h=328c52da8a2bbb81307644efdb58db2c422d9ba7
Ez megakadályozta a Landlock nevű sandboxing működésbe lépését, így az xz olyan erőforrásokhoz is hozzáférhetett a rendszeren, amikhez alapvetően nem szabadott volna.
Lasse Collin commitja javította a hibát. -
urandom0
senior tag
Egyébként az elmúlt ~2 évben 750 commitja volt az xz projekthez a backdoort elhelyező jóembernek (név szerint Jia Tannak, aki valószínűleg Szingapúrban vagy annak közelében él), így lehet, hogy fognak még backdoort találni korábban kiadott verziókban is. Folyamatosan nézik át a régebbi kódokat, de ez elég nehéz munka, eltart egy darabig.
-
urandom0
senior tag
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.
-
urandom0
senior tag
válasz
Mr Dini
#33959
üzenetére
Nem tudtam még alaposabban utánajárni, most is rokonokhoz megyünk épp. De kb. ezt írják a legtöbb helyen:
"Remember to update your systems.
This backdoored version was in OpenSUSE Tumbleweed, Arch, Debian Testing and Sid, Fedora Rawhide (and maybe Fedora 40 Beta), Ubuntu 24.04 development versions, NixOS Unstable, and other distros. But not all distros with the backdoored version are believed to be vulnerable.
However, the backdoor was added by a maintainer who had been committing for years, so it may be possible that even older versions may be vulnerable in some way (but this is only conjecture at this point)."
Az utolsó mondat még fontos lehet. Lényeg, hogy aki tud, frissítsen.
Én reggel lefrissítettem a rendszereim, Debian stable-hez és Fedora 39-hez nem láttam jönni új xz csomagot (ugye ők nem érintettek), OpenSuse TW-hez viszont igen. -
urandom0
senior tag
válasz
kovaax
#33957
üzenetére
Right now no Debian stable versions are known to be affected. Compromised packages were part of the Debian testing, unstable and experimental distributions, with versions ranging from 5.5.1alpha-0.1 (uploaded on 2024-02-01), up to and including 5.6.1-1. The package has been reverted to use the upstream 5.4.5 code, which we have versioned 5.6.1+really5.4.5-1.
Users running Debian testing and unstable are urged to update the xz-utils packages.
https://lists.debian.org/debian-security-announce/2024/msg00057.html
-
urandom0
senior tag
válasz
urandom0
#33955
üzenetére
Olvasnivaló:
https://news.ycombinator.com/item?id=39868673
https://news.ycombinator.com/item?id=39868673
https://www.openwall.com/lists/oss-security/2024/03/29/4
Izgalmas történet, bár nem tudom, mennyi az igazság belőle. Úgy tűnik, hogy egy olyan karbantartó csempészett backdoort az xz-be, aki évek óta hozzájárul a feljesztéséhez.
Azt rebesgetik, talán valamelyik szervezet embere lehet a tettes (ki tudja?). Mindenesetre a Github accountja (és egy másik emberé is) fel lett függesztve.
A végcél valószínűleg az lehetett, hogy hátsó ajtót nyissanak az SSH-ban. -
urandom0
senior tag
Kicsit nyomatékosabban kell ezt csinálni.
Na szóval, veszélyes backdoort találtak az xy utilsban, ami kb. az összes disztrón jelenlévő xz tömörítő segédprogramjában. Nagyon sok disztró érintett, Red Hat származékok, Debian, Suse, Arch, stb.
A lényeg, hogy mindenki toljon egy frissítést a rendszerére/rendszereire, minél előbb!!https://archlinux.org/news/the-xz-package-has-been-backdoored/
https://www.darkreading.com/vulnerabilities-threats/are-you-affected-by-the-backdoor-in-xz-utils
https://www.theregister.com/2024/03/29/malicious_backdoor_xz/
https://gist.github.com/thesamesam/223949d5a074ebc3dce9ee78baad9e27
-
urandom0
senior tag
-
urandom0
senior tag
Őszintén szólva, én ki szoktam kapcsolni a SELinuxot. Nem egyszer belefutottam már rejtélyes hibákba, amiket a SELinux okozott. Egyszer egy szimpla gcc-s fordítást tiltott le, máskor egy docker containerben kellett nyúlkálnom, az nem tetszett neki, volt hogy a céges LT2P VPN-t fogta meg...
De ha te nem ütközöl ilyen problémákba, akkor azt javaslom, hagyd bekapcsolva, alapbeállításon.A tűzfal beállítása megint csak használatfüggő. Nincsenek kötelezően tiltandó portok. Ha van olyan szolgáltatásod, ami kifelé hallgatózik, és nincs rá szükséged, akkor távolítsd el. Ha korlátozni akarod egyes szolgáltatások elérését, akkor csinálhatsz rá tűzfalszabályt. Illetve azt megcsinálhatod, hogy mindent deny-re állítasz, és csak azokat a portokat/programokat engedélyezed, amiket feltétlenül ki akarsz engedni (szerveren mi így szoktuk csinálni).
A szolgáltatások esetében megint csak azt tudom mondani, hogy amelyikre szükséged van, azt tartsd meg, amelyikre nincs, azt távolítsd el. Ez a systemd-analyze security parancs olyan szempontból szerintem kicsit megtévesztő, hogy igazából nem csinál mást, mint megmutatja, hogy a systemd által biztosított biztonsági feature-ök közül mennyit használ ki az adott service. Ha ezt optimalizálni szeretnéd, csak úgy lehetne megtenni, ha mélységében ismernéd a systemd-et, és az adott service-eket is, mindet egyesével. Ez azért nem kis munka, ráadásul van olyan service, aminél beállítasz egy adott opciót, és két hét múlva, ha mondjuk be akarsz dugni egy pendrive-ot, akkor jön elő, hogy nem működik...
Ahogy látom, elég sok virtualizáláshoz kapcsolódó szolgáltatásod van. Ha nem virtualizálsz, akkor azokat tiltogasd le, aztán ha esetleg valami nem működne, akkor engedélyezed.
-
urandom0
senior tag
válasz
Ablakos
#33898
üzenetére
Tudtommal nincs jelentősége. Az fstabban megadott csatolásokból is mount ponintot csinál a systemd, ha kiadod a systemctl --type=mount parancsot, láthatod is a mount pointokat. Szerintem egyszerűbb beszúrni fstabba egy sort, mint egy .mount (és egyetleg egy .automount) fájlt megírni.
De felcsatolhatod rc.local-ban is (ebből is systemd service lesz), vagy írhatsz saját systemd service-t hozzá, de igazából legegyszerűbb az fstab-os megoldás.
Ha esetleg speciálisabb opciók kellenek, amik nem érhetők el fstabból (pl. adott systemd unit függőségeként csatolódjon fel a partíció), akkor érdemes rá systemd mount-ot írni. -
urandom0
senior tag
válasz
f_sanyee
#33834
üzenetére
Ahogy írja itt a kolléga, a Clear Linux az egy másik cucc.
A bootolás mindegy, úgyis ritkán indítom újra a gépet, kb. havonta egyszer. Csak meglepődtem, hogy ilyen gyorsan bebootolt, ilyet még nem láttam. 8 másodperc alatt ott volt előttem a Gnome...
Az, hogy melyik DE melyik gépen hogyan fut, szerintem eléggé változó, géptől és disztrótól is függ. A múlt héten feldobtam erre a gépre egy KDE-t, azt hittem, szaladni fog, mint villám. Ehhez képest lassabb volt, mint a Gnome. Igaz, ez egy régi HP masina, nem igazán mérvadó a teljesítménye, de akkor is fura volt.
Mondjuk az utóbbi időben a Gnome is belehúzott, ez a gép, amiről most írok, egy i5-2320-as Fujitsu brand gép, 8 GB RAM-mal, Samsung EVO SSD-vel, és teljesen jól fut rajta a Gnome. Ezen persze a KDE is hasít.Aztán a napokban Cinnamont használtam azon a HP-n, azt leszámítva, hogy a grafika kissé akadozós, semmi gond vele. Nyilván egy XFCE-vel, amiben még animációk sincsenek, villámgyors lenne (már ahhoz képest, hogy HDD van benne).
Végül ma délután OpenSuse Tumbleweed-et telepítettem rá, Gnome-mal, de majd teszek egy próbát KDE-vel is, hátha OpenSuse alatt gyorsabb lesz, mint Fedora alatt. -
urandom0
senior tag
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). -
urandom0
senior tag
Hali!
Clear Linux-szal vagy CachyOS-sel van valakinek tapasztalata? Egy régebbi (10+ éves) asztali PC-re kellene valami gyors Linux. Leginkább webszerkesztésre és hírlevelek gyártására használnám.
Ehhez kapcsolódva, nézegetem az ilyen kevésbé ismert, egzotikusabb asztali környezeteket, az UKUI és a CuteFish fogott meg. Ezek mennyire használhatók?
-
urandom0
senior tag
-
urandom0
senior tag
válasz
bambano
#33414
üzenetére
Ez világos, a kérdéses részek azok, amiket ő GPL licencel emel be a saját kódjai közé. Azoknál nem teheti meg, hogy ne adja ki a vásárló részére a forráskódot, a vásárló meg továbbadhatja azokat.
Mindegy is, közben megtaláltam a választ a kérdésemre Almáék egy tweetjében: https://twitter.com/AlmaLinux/status/1671560898819784704
A licence egy része tiltja, hogy saját buildet terjesszenek. -
urandom0
senior tag
Szerintem ezzel a Red Hattal kapcsolatos jogi vita egy olyan dolog, hogy még az iparági szakértők sem tudják pontosan eldönteni, történik-e GPL sértés vagy sem. Van egy Software Freedom Conservancy nevű szervezet, akik kifejezetten FOSS jogokkal foglalkoznak, ők is írták nem egyszer a Red Hatról, pl. itt is: A Comprehensive Analysis of the GPL Issues With the Red Hat Enterprise Linux (RHEL) Business Model
Én úgy tudom, és itt is azt írják, hogy GPL esetén nem mindenki számára kell közzétenni a forrást, hanem aki beszerzi (megvásárolja) a szoftvert.
Viszont azt nem értem, hogy ha a GPL nem tilthatja meg, hogy a forráskódokat tovább terjeszd, akkor az olyan disztrók, mint az Alma vagy a Rocky, miért nem vásárolnak egy licencet, és a mellé kapott forráskódból már építkezhetnének? Nyilván persze van ennek valami jogi akadálya... -
urandom0
senior tag
válasz
urandom0
#33220
üzenetére
Na, az én Fedorám le is frissült gond nélkül. Ha érdekel valakit, itt van a bejelentés és egy rövid összefoglaló az újdonságokról:
Announcing Fedora Linux 38
What’s new in Fedora Workstation 38Ennek örömére az OpenSuse telepítéseimet is frissítettem, azok is szépen frissültek gond nélkül, úgyhogy nincs okom panaszra.
-
urandom0
senior tag
-
#33212
urandom0
senior tag
Neil Watts
#33207
urandom0
senior tag
válasz
Neil Watts
#33207
üzenetére
- 2FA-t még beállíthatsz SSH-ra
- állítólag az rng-tools már felesleges -
-
urandom0
senior tag
Az alkalmazást lefordítom intel gépen ubuntu környezetben. Aztán átviszem azt a binárist ubuntu alól intel vagy amd processzoros redhat, centos, akármi linux alá. Számíthatok változatlan futásképességre egészen biztosan?
Nagyon valószínű, hogy működni fog (főleg egyszerűbb programoknál), de ez tényleg az a tipikusan letesztelős dolog, másrészt ahogy írták, linkelhetsz statikusan, avagy csinálhatsz belőle appimage/snap/flatpak csomagot is, vagy konténert is.
De ha nem is működik, akkor sem a glibc-n fog múlni a dolog, hanem az esetlegesen használt egyéb függőségeken. De szerintem egy sima BSD socketes cucc aligha lesz problémás.
Én lefordítanám a legrégebbi glibc-vel, ami valószínűsíthetően előfordulhat a célközönségnél (nem tudom, Ubuntu 20.04 talán vagy Debian 10...), és kipróbálnám újabb disztrókon.
Ha publikus a program, elküldheted nekem is, segítek tesztelni. Van telepített Fedora 37-em, CentOS Stream-em, Debian 10-esem, Debian 11-esem és OpenSuse Leap-em.A processzor generációkat teljesen felesleges belekeverni a dologba, annak a legkevésbé van köze a disztrók közti kompatibilitáshoz.
Ezt elolvashatod.
-
urandom0
senior tag
Ti mit tudtok arról, hogy OpenSuse Leap-ből a 15.5 lesz az utolsó, és onnantól valami ALP nevezetű, immutable Linuxot fog tolni a Suse? Nem olvastatok erről? Én sajnálnám ha így lenne, Leap van az asztali gépemen is, és az új Raspberrymre is azt terveztem telepíteni.
-
urandom0
senior tag
válasz
#68216320
#33171
üzenetére
Szerintem root partícióra legfeljebb akkor lehet megcsinálni, ha találsz olyan VPS szolgáltatót, ami kifejezetten támogatja ezt. Ilyet kell keresni, hátha van.
De amúgy miért fontos a root partíció titkosítása?
Ha van is virtuális konzol, az jellemzően onnantól fogva képes működni, hogy a rendszer már bebootolt.Szerintem egyszerűbb és jobb (és persze drágább is) a saját szerver elhelyezés, ott azt csinálsz a gépeddel, amit akarsz.
-
#33131
urandom0
senior tag
arcoskönyv
#33128
urandom0
senior tag
válasz
arcoskönyv
#33128
üzenetére
Azért az elég durva lenne, ha a repón kívül bármit is megpróbálna szinkronizálna
Én legalábbis nem örülnék neki. Gondolj bele, leklónozol valamit, és csendben meglapul benne egy symlink, ami mondjuk az ~/.ssh/id_rsa-ra mutat, és te gyanútlanul felpusholod... -
#33127
urandom0
senior tag
arcoskönyv
#33125
urandom0
senior tag
válasz
arcoskönyv
#33125
üzenetére
Mert a symlinkben lehet abszolút útvonal is, ami akkor is probléma, ha a repón belülre mutat. Ha pedig a repón kívülre, akkor pláne. Ráadásul egyáltalán nem biztos, hogy az eltérő platformokon (pl. Windows) biztosítható a symlink azonos módon történő viselkedése. FAT, exFAT fájlrendszeren nem is tudsz symlinket létrehozni.
Egyébként szerintem a repón belülre mutató, relatív útvonalat használó symlinkeket lekezeli, ha a core.symlinks true-ra van állítva. Vagy nem? Sosem próbáltam.
-
urandom0
senior tag
A Red Hat-os doksit, amit linkeltem, béztétek?
The ECDSA (Elliptic Curve Digital Signature Algorithm) offers better performance than RSA at the equivalent symmetric key strength. It also generates shorter keys. The Ed25519 public-key algorithm is an implementation of twisted Edwards curves that is more secure and also faster than RSA, DSA, and ECDSA.
-
urandom0
senior tag
válasz
#68216320
#33097
üzenetére
Bocs, hogy triplázok, de lassan jutnak eszembe a dolgok.
Beállíthatsz egyszerre public key authenticationt és passwordauthenticationt is:AuthenticationMethods "publickey,password"
PubkeyAuthentication yes
PasswordAuthentication yesÍgy csak akkor tudsz belépni, ha a pubkey ÉS a jelszó is jó.
-
urandom0
senior tag
válasz
#68216320
#33110
üzenetére
Esetleg be lehetne állítani, hogy az sshd ne a root nevében fusson, de ezt csak akkor tudod megcsinálni, ha engedélyezve van a PAM. Bár ha 2 faktort tervezel, igen, akkor is kelleni fog a PAM.
Egyébként én még ezeket be szoktam állítani:
UsePrivilegeSeparation yes
StrictModes yes
MaxSessions 1
MaxStartups 1
MaxAuthTries 2Egyébként a Red Hat Enterprise Linux 9 Securing Networks doksi szerint az Ed25519 algoritmust ajánlja az RSA helyett.
-
urandom0
senior tag
Az LSB scriptekről jutott eszembe, mikor ránéztem a Debianomra, meglepődtem, milyen sok script van az /etc/init.d-ben. Most megnéztem egy frissen telepített Debiant, így fest az /etc/init.d mappa:
Így egy nem régen telepített Fedora 37 /etc/init.d mappája:
Ez a szintén nem rég telepített OpenSuse Leap:
Ez pedig itt a Centos 9 Stream:
-
#33046
urandom0
senior tag
lionhearted
#33044
urandom0
senior tag
válasz
lionhearted
#33044
üzenetére
Igen, HDD-n is gyors volt, így vm-ben pedig még gyorsabb, csak úgy száguld.
-
urandom0
senior tag
Ma volt egy kis időm, mivel úgyis csináltam egy dd-s lemezképet a régi XP-s gépről, gondoltam, belököm KVM-be, vajon megy-e. Meglepően könnyen bebootolt, utána szöszölt egy darabig a driverek telepítésével, de egyébként szépen megy.
szerk: a gépen lévő Windows mappa 2011. február 16-on lett létrehozva, azaz egy 12 éve telepített rendszerről van szó. -
urandom0
senior tag
Jól összezavartalak, bocs.
Egyelőre semmi mást ne csinálj, csak ennyit:
wget -O /etc/init.d/mpdlcd https://github.com/rbarrois/mpdlcd/blob/c39cce8eafd4308bf255a9fcb2f92db4cfcab586/initd/mpdlcd.debian
chmod +x /etc/init.d/mpdlcdUtána indítsd újra az RPi-t, és elméletileg mennie kell.
-
urandom0
senior tag
Jajj, ez így nem lesz jó! Lehet, hogy én fogalmaztam rosszul, de a lényeg az, hogy van a systemd unit fájl, ez most így néz ki:
[Unit]
Description=mpdlcd
After=mpd.service lcdd.service
[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=mpdlcd.debian
RestartSec=5
Restart=always
[Install]
WantedBy=multi-user.targetUgye az első sorból látszik is, hogy ez egy unit.
És van az init script, ez pedig ez az mpdlcd.debian.
Na mármost, két lehetséges megoldás van. Az 1. elméletileg megy Debianon (ha a systemd-sysv-generator működik):
1. Fogd az mpdlcd.debian-t, másold be az /etc/rc2.d mappába, és adj neki x jogot.
Igazából az /etc/init.d mappába kellene másolni, és egy symlinket tenni az /etc/rc2.d-be, de most ne bonyolítsuk.
Próbáld ki, hogy így működik-e. Ez esetben a unit fájlt el is lehet felejteni.2. Fogd az mpdlcd.debian-t, másold be az /usr/bin mappába, és adj neki x jogot. A /etc/systemd/system/mpdlcd.service fájlod pedig így nézzen ki:
[Unit]
Description=mpdlcd
After=mpd.service lcdd.service[Service]
Type=simple
WorkingDirectory=/tmp
ExecStart=/usr/bin/mpdlcd --no-syslog &
RestartSec=5
Restart=always[Install]
WantedBy=multi-user.targetEnnek ne adj semmilyen jogot. Próbáld meg így is, elindul-e.
-
urandom0
senior tag
Alighanem hiányzik pár sor a script elejéről, valami ilyesmi:
### BEGIN INIT INFO
# Provides: mpdlcd
# Required-Start: $syslog
# Required-Stop: $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: MPD client for lcdproc
# Description: Display MPD status
### END INIT INFONézd meg itt az init scripteket: https://github.com/rbarrois/mpdlcd/tree/master/initd
Szerintem az ExecStart= sorban nem az mpdlcd-t kellene beleírni, hanem az
mpdlcd.debian-t. Ez legalább valid LSB scriptnek tűnik (így néz ki egy LSB initscript), Szóval lemented valahová, adsz neki +x jogosultságot, ha kell kijavítod benne az elérési utakat, bemásolod mondjuk az /etc/systemd mappába, és átírood a systemd unit-ot, hogy ezt indítsa el. De ez csak tipp, nem ismerem a szoftvert. -
#33026
urandom0
senior tag
lionhearted
#33024
urandom0
senior tag
válasz
lionhearted
#33024
üzenetére
100 dollár/év egy developer RHEL licence a cégeknek, igazából nem nagy összeg.
Ha prod szerver lenne, akkor elgondolkodnék rajta, de igazából ez csak ahhoz kell, hogy ezt-azt leteszteljek néhány tíz gépes környezetben.
Ja, sokan írták, hogy Debianra váltottak...
-
urandom0
senior tag
Igazából RHEL-ből van free verzió, de csak magánszemélyek részére, 16 gépig (azt hiszem). De ez most céges dolog lesz. Lehet, hogy akkor maradok mégis a CentOS-nél.
Ez a Oracle Linux nem tűnik rossznak, állítólag 1:1 RHEL kompatibilis, de van belőle "unbreakable kernel" nevű, hiper-szuper stabil változat.
-
urandom0
senior tag
CentOS Stream? Végső soron az sem lenne rossz, csak kicsit tartok tőle, hogy instabilabb, mint egy downstream disztró.
A Suse nem lenne rossz, de azért a RHEL/CentOS vonalnak nagyobb a támogatottsága. Igazából az Oracle Linux vs. Rocky vs. Alma között vacillálok, csak nem tudok dönteni. Én szívem szerint az Oracle-t választanám, de ahogy utánaolvastam, a többség inkább az Almát vagy a Rockyt ajánlja (jellemzően csak azért, mert az Oracle az az Oracle-é). -
#33007
urandom0
senior tag
arcoskönyv
#33006
urandom0
senior tag
válasz
arcoskönyv
#33006
üzenetére
Szerintem lényegében semmi.
-
urandom0
senior tag
válasz
#63718632
#33001
üzenetére
Hiányolja a franc, nekem totál mindegy, mit csinálnak az Archosok, nem használok Archot. Én csak leírtam, hogy az apt, a dnf, a zypper és más csomagkezelőket támogatja a PackageKit, a pacmant, pamacot, yayt és a többi AUR helpert nem, és Archban nincs összeheggesztve a PackageKit azokkal az összetevőkkel, amikkel sok más disztróban összevan (pl. a Gnome Software, KDE Discover, Muon, Apper...).
-
urandom0
senior tag
válasz
vargalex
#32997
üzenetére
Mert az Arch egy különutas disztró ilyen szempontból.
Maga a PackageKit egy disztrók közötti csomagkezelő, ami a különböző csomagkezelők funkcióinak egy közös halmazát valósítja meg. Olyan disztrók használják, mint Fedora, Kubuntu, OpenSuse, és olyan csomagkezelőket támogat, mint pl. az apt, zypper, dnf, slapt...
Az Arch és leszármazottai alapvetően nem használják a PackageKitet. -
urandom0
senior tag
Ha valaki Gnome-ot használ, találtam néhány tippet a memóriafogyasztás csökkentésére itt (nem csak Fedorára érvényes): https://www.reddit.com/r/Fedora/comments/11aw1uw/should_gnome_use_this_much_ram_and_why_does/
# First, configure packagekitd to shut down on idle:
sudo sed -i -e 's/^#ShutdownTimeout=/ShutdownTimeout=/' /etc/PackageKit/PackageKit.conf
sudo systemctl restart packagekit.service
# Next, configure your desktop session not to start gnome-software in the background:
mkdir -pv ~/.config/autostart && cp /usr/share/applications/org.gnome.Software.desktop ~/.config/autostart/
echo "X-GNOME-Autostart-enabled=false" >> ~/.config/autostart/org.gnome.Software.desktop
# Finally, disable gnome-software as a search provider, so that searches don't start gnome-software in the background:
dconf write /org/gnome/desktop/search-providers/disabled "['org.gnome.Software.desktop']"Ez megtiltja a PackageKit-nek, hogy folyamatosan fusson a háttérben, és hogy automatikusan elinduljon a rendszer indításakor. Hátránya az, hogy a Gnome keresője nem fog többé keresni a Gnome Szoftverekben, nem fog figyelmeztetni, hogy vannak frissítések, és a command-not-found parancs is lassabban fog működni.
Természetesen mindenki csak saját felelősségre használja. -
#32989
urandom0
senior tag
arcoskönyv
#32983
urandom0
senior tag
válasz
arcoskönyv
#32983
üzenetére
Olyan mint a Győri keksz
-
-
urandom0
senior tag
válasz
CPT.Pirk
#32981
üzenetére
Nagyon szépen fejlődik a KDE, közel sem olyan omlós már, mint régen volt. Ezeket a hibákat, amik nálam előjönnek, szerintem a gép, a kernel vagy valamelyik modul okozza. Pedig nem egy dzsunka vacak laptopot használok, hanem egy Thinkpadet, de akármilyen Linux van rajta, olyanokat csinál, hogy pl. ébredés után másképp érzékeli a touchpad-et, mint közvetlen boot után. Boot után valami Think... valami a neve (most nincs előttem a gép), ébredés után pedig már SynPS/2 Synaptics TouchPad-nek látja az xinput, és ezzel együtt elállítódik az érzékenysége, a kétujjas görgetés, minden.
Sokszor az egeret sem érzékeli ébredés után, de erre már írtam egy scriptet.
Illetve újabban mint ha halkabban lennének a hangszórók, mint korábban, bár lehet, hogy csak az én fülem romlik
Viszont hamarosan jön a KDE 6, reméljük nem lesz olyan nehézkes a váltás, mint 4-ről 5-re
-
urandom0
senior tag
válasz
olivera88
#32977
üzenetére
Én powert szoktam nyomni, nem túl kíméletes megoldás, de hatékony... valamelyik nap pont leállításnál fagyott le a KDE, úgy, hogy csak a háttérkép maradt, semmi más. Átléptem konzolra, nézegettem dmseg-et, ps-t, htop-ot, journal-t, strace-t, de nem jöttem rá a hiba okára...
-
#32975
urandom0
senior tag
arcoskönyv
#32972
urandom0
senior tag
válasz
arcoskönyv
#32972
üzenetére
Nyitok Githubon egy issue-t, hogy mi itt magyarisztánban képtelenek vagyunk leírni az OS nevét, nevezzék már át másra, mondjuk Artemisre
-
urandom0
senior tag
válasz
CPT.Pirk
#32970
üzenetére
2-3 naponta új kernel??? Az komoly... igazából nekem nem kellenek annyira friss csomagok, inkább legyen stabil a cucc. Alapvetően egy Debiannal is elvagyok, csak azért jó lenne, ha Xfce-ből nem a 4.16-os lenne benne, hanem legalább a 4.17-es, mert abban már lehet rendezgetni a Thunar eszköztárát
De ha azt mondod, hogy nem kellett kézzel utánadolgozni, akkor szerintem teszek vele egy próbát.
-
urandom0
senior tag
válasz
CPT.Pirk
#32968
üzenetére
A gyakran jönnek frissítések mit jelent? Hetente többször?
Két gépemen Kubuntu van egy ideje, és az őrületbe tud kergetni azzal, hogy a Discover naponta kicsapja az ikonját az értesítési területre, mert hogy neki frissíthetnékje van
Aztán a legtöbb esetben semmi különösebb indoka nincs rá, csak épp átrajzoltak két pixelt valamelyik telepített icon packban...
Ráadásul sokszor hibára fut a frissítés.Amúgy stabilnak stabil az Ende... szóval a rendszer?
Nem kell faragni a frissítések után? -
#32399
urandom0
senior tag
lionhearted
#32397
urandom0
senior tag
válasz
lionhearted
#32397
üzenetére
Igen, elég nyilvánvaló, hogy itt Azure volt a célplatform igazából, nem a Pista meg a Mariska otthoni Ubuntuja.
-
urandom0
senior tag
válasz
bambano
#32394
üzenetére
Ha eddig az tartott vissza valakit attól, hogy .NETtel fejlesszen Linuxra*, hogy nem volt egyszerű, gyors, könnyen tesztelhető és megbízható módja annak, hogy ott legyen a .NET a rendszerben, akkor ezután már ez sem fogja. Tudom, hogy van más módja az alkalmazások terjesztésének mint a natív csomagformátum, de most azok mellé megkapták ezt is.
* Ubuntura, de sok cég számára Linux=Ubuntu (más disztrót nem támogatnak)
-
-
urandom0
senior tag
válasz
supi007
#32310
üzenetére
Ha megvan a régi rpm csomag, akkor megpróbálhatod simán dnf-fel telepíteni, pl. dnf install ./syslinux-3.86-1.el7.rf.x86_64.rpm
Sok esetben sikerül, de van, amikor nem. Ilyenkor meg lehet próbálni hozzáadni régebbi repót. Ha az sem megy, akkor esetleg statikusan fordított binárist keresni (itt is azt keresett valaki). Ha az sincs, akkor meg lehet próbálni forrásból fordítani, akár úgy is, hogy feltelepítesz egy a syslinux régi verziójának megfelelő korú disztrót, azaz egy régi CentOS-t, Fedorát, Red Hatot vagy ezzel kompatibiliset, és azon csinálod a fordítást.
Átgondolni azt kell, hogy ha hozzáadsz egy régebbi repót a mostani rendszeredhez, vagy ha egy rendszerközeli csomaggal matatsz, nem okozol-e helyrehozhatatlan problémát. Én az ilyesmit virtuális gépre telepített rendszerben csinálnám.
-
#32304
urandom0
senior tag
DrojDtroll
#32303
urandom0
senior tag
válasz
DrojDtroll
#32303
üzenetére
ldd ./programneve
Próbáltad?
Vagy strace, ha lehet telepíteni.
-
#32155
urandom0
senior tag
MasterMark
#32142
urandom0
senior tag
válasz
MasterMark
#32142
üzenetére
Anyám borogass
Aki egy ilyet képes összetákolni, az bármilyen elvetemültségre képes... -
#31830
urandom0
senior tag
Netszemete
#31827
urandom0
senior tag
válasz
Netszemete
#31827
üzenetére
Nem próbáltam. Ha úgy akarnám használni, akkor úgy használnám. Az autó elé se kötök lovat, mert nem úgy akarom használni.
De részemről én itt befejeztem, ez tényleg nem idevaló. -
urandom0
senior tag
válasz
urandom0
#31823
üzenetére
Na jó, én feladom.
Már nagyjából mindent kipróbáltam, kicseréltem a billentyűt/egeret másikra, dugdostam ide-oda, de ennek a szerencsétlen szar Windowsnak sehogy sem tetszik, ugyanúgy megmerevedik egy idő után az egér és a billentyűzet. Bezzeg a Linux-szal minden gond nélkül megy, ide-oda kapcsolgatom, meg se kottyan neki...
Még egyetlen megoldás jöhet szóba, hogy dugjam a perifériákat egy USB hubba, a hubot pedig a switchet, állítólag így talán működni fog... -
#31823
urandom0
senior tag
Netszemete
#31821
urandom0
senior tag
válasz
Netszemete
#31821
üzenetére
Én is keresgéltem már, valahol azt írták, az USB3-as portokat nem szereti a switch, de nálam az összes port USB2-es.
Driver nincs hozzá, semmi a világon. Ez egy nagyon alap, buta kis cucc.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
- Eredeti Microsoft termékek - MEGA Akciók! Windows, Office Pro Plus, Project Pro, Visio Pro stb.
- Sea of Thieves Premium Edition és Egyéb Játékkulcsok.
- Windows 10/11 Home/Pro , Office 2024 kulcsok
- Bontatlan - BATTLEFIELD 1 Collectors Edition - Játékszoftver nélkül
- Windows 10 11 Pro Office 19 21 Pro Plus Retail kulcs 1 PC Mac AKCIÓ! Automatikus 0-24
- AKCIÓ! Gigabyte H610M i5 12400F 16GB DDR4 512GB SSD RX 6700XT 12GB Zalman S2 TG Seasonic 650W
- BESZÁMÍTÁS! MSI B450M R5 5500 32GB DDR4 512GB SSD RTX 3060 12GB Rampage SHIVA Chieftec 600W
- DELL PowerEdge R730xd 12LFF+2SFF rack szerver - 2xE5-2680v3,64GB RAM,4x1GbE,H730 RAID v ZFS
- Apple Watch SE 2 44mm, Újszerű, 1 Év Garanciával
- Új és használt laptopok , üzletitől a gamerig , kedvező áron. Garanciával !
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest