Red Hat, Fedora, CentOS

Sziasztok,

Adott egy könyvtár 777 UNIX jogosultsággal, amelyhez a következő ACL-ek tartoznak:

# file: könyvtár_neve
# owner: 777
# group: root
# flags: --t
user::rwx
user:felhasználó:rwx
group::---
group:csoport:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:felhasznalo:rwx
default:group::---
default:group:csoport:rwx
default:mask::rwx
default:other::---

Ebben fájlok vannak, 777 UNIX jogosultsággal és a következő ACL-ekkel:

# file: fájl_neve
# owner: 777
# group: felhasználó
user::rwx
user:x2xr7wi:rwx
group::---
group:csoport:rwx
mask::rwx
other::rwx

"csoportnak" tehát a szülőkönyvtárra RWX jogosultsága van.  
"csoport" tagjaként tudok fájlokat másolni a könyvtárba és meglévő fájlokat módosítani, de nem tudom a meglévő fájlokat törölni (semmivel).
Lock-olva nincsenek a fájlok.

Van ötletetek, hogy miért? 🤷‍♂️

Jól látom, ez ma történt? https://fedoramagazine.org/announcing-fedora-linux-41/

https://fedoraproject.org/

Valaki próbálta már esetleg a 41-est?

Üdv,

CentOS9-en nem lehet semmit frissíteni, time out van. (Friss telepítés.) https://mirrors.centos.org/mirrorlist?path=/9-stream/BaseOS/x86_64/iso/…

Nálatok is ezt csinálja?

Sziasztok,

Az lenne a cél hogy az újonnan létrejövő fájlok örököljék a szülő ACL-jeit,
erre megadtam a -d kapcsolót a setfacl-nek.

Így néznek ki jelenleg egy könyvtár ACL-jei:
 

# owner: root
# group: root
user::rwx
group::r-x
other::---
default:user::rwx
default:user:user_name:rwx
default:group::r-x
default:group:group_name:rwx
default:mask::rwx
default:other::---

 

A "group_name" tagjainak nincs rwx joga, nem értem miért.

A default ACL-ek nem jelentenek egyből effektiv hozzáférést vagy nem értek valamit? :)

Köszönöm!

A következőn elmélkedem - feltehetően hiányos ismeretek birtokában:
Létezik a Red Hat linux fejlesztőknek szánt ingyenes előfizetése, amivel a teljes értékű Red Hat linux letölthető, telepíthető, frissíthető.
Egy előfizetés maximum 16 hoston használható és alanyi személyhez kell, hogy kötődjön, azaz cég nevére nem regisztrálható.
Szigorúan szem előtt tartva azt a felhasználási területet, amikor a Red Hat linuxszal való legnagyobb kompatibilitás elérése a cél és az ingyenes előfizetés által biztosított darabszám is bőven elegendő, akkor látjátok-e létjogosultságát a Red Hat "klónok" használatának Red Hat helyett?

Kissé másként fogalmazva: miért érdemes Red Hat alapú disztribúciót (AlmaLinux/Rocky/Oracle) használni Red Hat helyett ott, ahol nem lenne túllépve az ingyenes Red Hat licenc által biztosított 16-os darabszám?

Ott volt áprilisban ez a CVE-2024-1086-os kernelhiba, melyet előbb javítottak az AlmaLinuxban, majd valamivel később a Red Hat-ban is, tehát mindkettőben javításra került.
Az AlmaLinux feladta az 1:1-es Red Hat kompatibilitást, helyette arra törekszik, hogy binárisan maradjon kompatibilis. (After much discussion, the AlmaLinux OS Foundation board today has decided to drop the aim to be 1:1 with RHEL. AlmaLinux OS will instead aim to be binary compatible with RHEL.)

Kíváncsi volnék a véleményetekre a fent megfogalmazottakkal kapcsolatban.

Olvastam ezt a cikket, hogy a Fedora 40 kiadása teljes mértékben megszabadul az Xorgtól, mivel a KDE (Plasma 6) is kizárólag Wayland támogatással fog kijönni. 

A Fedora 39-ben lehet még grafikus meghajtót választani, ezért próba alá vetettem a Waylandot. Fotósként használom a Fedorát és eddig, -Fedora 16-óta-  nekem megfelelő tökéletes a rendszer.

Átváltottam Waylandra és a színprofil betöltéstől kezdve a fotós programokig,  Displaycal, Gimp,  Rapid Photo Downloader, Aftershot, csakhogy a lényegesebbeket soroljam, nem állnak a helyzet magaslatán. A színprofilt nem tudja betölteni, így színhelyességről nem is beszélek. Egyes programok Aftershot, Rapid Photo Downloader nem jeleníti meg a képet illetve találomra csak valami minta látszik.

Létezhet, hogy Wayland döbbenetes fejlődésen megy keresztül a Fedora 40 kiadásáig? :)

Aki Waylandot használ tapasztalt hasonló jelenségeket?                

Sziasztok,

Ennek a posztnak nem problémamegoldás a célja,
csupán szeretném megérteni hogy Linuxon ez általában hogyan működik (és így kellene-e jól működnie ahogy nálunk megy).

Adottak RedHat VM-ek, [nagyon]nagyvállalati környezetben, amiben én csak end-user vagyok.
A gépekhez a CyberARK megoldásnál keresztül, lényegében egy jumpserver ahol egy generált account-ot kapok a session-ben.
Technikai userek hozzéférését kezelése egy külön fejlesztett rendszeren keresztül lehet rendelni, ezek képesek jumpserver nélkül is SSH session-t nyitni,
viszont sudo nem érhető el a számukra.

Systemd service-t szeretnék egy AD user nevében futtatni, igényeltem neki hozzáférést, futik is.

Jelszót nem kért és itt kezdtem el gondolkodni hogy ez technikailag hogyan lehet megoldva?
SU-val kontextust tudok váltani a technikai userre, de érdekes módon működik olyan userre is, amire biztosan nem kértem hozzáférést.

Hogyan működik az impersonation AD userekkel Linuxon általában?
Miért enged user context-et váltani jelszó nélkül? (mi történik ilyenkor a motorháztető alatt?)

(/etc/passwd-ben nincsenek userek, realm csomag nincs telepítve, nem tudom hogyan megy az AD integráció)
 

Egy Fedora 39 desktop Linuxon akarok telepíteni KVM alá egy Windows 10-et.
Ezt a virtuális gépet viszont több különböző linux usernek el kellene érnie, természetesen nem egyidőben, mert egy desktopon egyszerre csak egy ember dolgozik.
Eddig a KVM-be telepített virtuális gépeket csak én használtam, de most a munkahelyen többen is használjuk ugyanazt a szervíz laptopot, amire Linuxot akarunk, de néha Windows is jó lenne.

Arra gondoltam, hogy az /opt/WMs/ könyvtárba teszem magát az imaget, de elég az, ha minden usernek úgy konfigurálom a KVM-et , hogy ugyanazt az imaget használja?

Sziasztok! Valaki tudna nekem segíteni abban hogyan tudnám bekapcsolni a koppintásos kattintást? Mert nincs ilyen lehetőség a beállításokban.

Jeff Geerling

Removing official support for Red Hat Enterprise Linux
June 23, 2023

For all of my open source projects, effective immediately, I am no longer going to maintain 'official' support for Red Hat Enterprise Linux.
I will still support users of CentOS Stream, Rocky Linux, and Alma Linux, as I am able to test against those targets. Support will be 'best effort', and if you mention you are using my work on Red Hat Enterprise Linux, I will close your bug/feature/support request as 'not reproducible', since doing so would require I jump through artificial barriers Red Hat has erected to prevent the use of their Linux distribution by the wider community. For more of my reasoning, see my previous blog post: Dear Red Hat: Are you dumb?. This decision will not change until and unless I see evidence Red Hat cares about giving free and open access to the sources required to build and test against their Linux distribution.

Process
The timeline for this transition to not supporting RHEL is as follows: Today: Removing official support for RHEL in Ansible role metadata, so users searching for roles to work with RHEL will not find my roles (I would rather they find roles that are actually tested against RHEL, because I cannot guarantee my roles will work for these users). Ongoing: As issues crop up on various roles against RHEL, I will decide on a case-by-case basis whether to strip all RHEL-like support (effectively making the project only run on Fedora, Arch, Ubuntu, Debian, or other distros), or attempting to fix the problem so existing users of Rocky Linux, AlmaLinux, and CentOS Stream may still benefit from the fix.