SELinux nginx 403 hatası ve dosya etiketleri

İzinleri doğru olan bir dosyada nginx neden 403 döndürür?

Dosyanın izin bitleri doğru olmasına rağmen nginx'in 403 döndürmesi neredeyse her zaman SELinux'un (security-enhanced Linux) okuma işlemini reddettiği anlamına gelir. SELinux, normal izin denetimi geçtikten sonra ikinci bir kural kümesini denetler. Web sunucusunun yalnızca web içeriği etiketi taşıyan dosyaları okumasına izin verilir. Dosyanız farklı bir etiket taşıdığı için open işlemi başarısız olur ve nginx'in göndereceği bir içerik kalmaz.

Yalnızca izin moduna değil, etikete de bakılmalıdır:

ls -ldZ /data/www /data/www/index.html

drwxr-xr-x. root root unconfined_u:object_r:default_t:s0 /data/www
-rw-r--r--. root root unconfined_u:object_r:default_t:s0 /data/www/index.html

drwxr-xr-x sonrasında yazdırılan nokta, dosyanın bir SELinux etiketi taşıdığını gösterir. default_t, policy'nin daha önce hiç karşılaşmadığı bir yol için atanır. Web sunucusunun kurallarında bu türün okunmasına izin verilmez. Hata günlüğü sıradan bir Unix hatası gösterir. Bu nedenle sorun izinlerle ilgiliymiş gibi görünür:

2026/08/11 09:14:02 [error] 1183#1183: *1 open() "/data/www/index.html" failed (13: Permission denied), client: 203.0.113.9, server: _, request: "GET / HTTP/1.1"

Kernel, normal ve SELinux kaynaklı retlerin her ikisi için de 13: Permission denied döndürür. Bu nedenle ilk iş, reddetme kararını hangi katmanın verdiğini belirlemektir. setenforce 0 ile başlamayın.

İhtiyaç duyulan model bölümü

SELinux, genellikle MAC olarak yazılan zorunlu erişim denetimidir. Her işlem, web sunucusu için httpd_t gibi bir etki alanında çalışır. Her dosya ve her ağ portu, httpd_sys_content_t gibi bir tür taşır. Politika, etki alanı, tür ve eylemden oluşan izin verilen birleşimlerin listesidir. Bu listede bulunmayan her işlem reddedilir. SELinux, klasik Unix denetiminden sonra çalışır. Bu nedenle drwxr-xr-x içindeki izin bitlerinin önce erişime izin vermesi gerekir. Her iki katmanın da izin vermesi gerekir.

Tam bağlam, system_u:system_r:httpd_t:s0 örneğinde olduğu gibi iki nokta üst üste ile ayrılan dört alana sahiptir: SELinux kullanıcısı, rol, tür ve seviye. Bir sunucuda zamanın neredeyse tamamı üçüncü alan olan tür üzerinde geçirilir. Etkin değerleri iki komut gösterir:

ps -eZ | grep nginx
id -Z

nginx çalışan süreçlerinin bağlamı httpd_t ile biter. Oturum açma kabuğunun bağlamı unconfined_u:unconfined_r:unconfined_t:s0 değerini gösterir. Bunun nedeni, varsayılan targeted politikasının servisleri sınırlandırması ve etkileşimli kullanıcıları bu sınırlamanın dışında bırakmasıdır. Bu bilgi önemlidir, çünkü SELinux servislerin en az ayrıcalıklı kullanıcılarla çalıştırılmasının yerini tutmaz. Bir servis ele geçirildikten sonra erişebileceği kaynakları sınırlar.

Üç mod ve SELinux kullanılan imajlar

sestatus
getenforce

Enforcing erişimi engeller ve olayları günlüğe kaydeder. Permissive tüm işlemlere izin verir ve engelleyeceği işlemleri günlüğe kaydeder. Disabled hiçbir policy yüklemez. getenforce mevcut modu görüntüler. sestatus ayrıca yeniden başlatma sonrasında geri gelen mod olan /etc/selinux/config içindeki modu da görüntüler.

Rocky Linux, AlmaLinux, Fedora ve RHEL, targeted policy ile SELinux'u enforcing modunda sunar. Bu ortak varsayılan tesadüfi değildir; dört dağıtım da Rocky Linux ve AlmaLinux ortaya çıkmadan önce CentOS üzerinden ilerleyen aynı Red Hat çizgisinden türemiştir. Bu sayfadaki hiçbir konu açısından hangi dağıtımın kullanıldığı fark etmez; çünkü aynı policy'yi ve aynı araçları sunarlar. Bu nedenle Rocky Linux ile AlmaLinux arasındaki seçim, güvenlik varsayılanlarından çok uyumluluk taahhütlerine ve eski CPU desteğine bağlıdır. Ubuntu ve Debian bunun yerine AppArmor sunar. AppArmor farklı bir mekanizmayla aynı işi yapar; son bölümde ele alınır. Bu nedenle aynı uygulama sunucularınızdan birine sorunsuz şekilde kurulabilirken diğerinde 403 döndürebilir.

İhtiyaç duymadan önce araçları kurun

sudo dnf install -y policycoreutils-python-utils setroubleshoot-server

Minimal bir image üzerinde semanage: command not found komutunun başarısız olması, policycoreutils-python-utils paketinin eksik olduğu anlamına gelir: Bu paket semanage ve audit2allow bileşenlerini içerir. setroubleshoot-server ise sealert bileşenini ekler ve her reddetme işleminin anlaşılır bir özetini journal'a yazar. Her ikisini de yeni bir sunucu üzerinde önceden kurun; çünkü bu araçlara ihtiyaç duyduğunuz anda sistemde zaten bir şeyler bozulmuş olur.

Denetim günlüğünde bir SELinux engellemesi nasıl okunur

Her ret, audit daemon tarafından AVC (access vector cache) iletisi olarak kaydedilir:

sudo ausearch -m AVC,USER_AVC,SELINUX_ERR -ts recent

type=AVC msg=audit(1754896442.881:412): avc:  denied  { read } for  pid=1183 comm="nginx" name="index.html" dev="vda1" ino=17203 scontext=system_u:system_r:httpd_t:s0 tcontext=unconfined_u:object_r:default_t:s0 tclass=file permissive=0

Tüm durumu dört alan açıklar. comm engellenen programdır. scontext kaynak bağlamıdır; işlemin çalıştığı domain'i belirtir. tcontext hedef bağlamıdır; işlemin erişmeye çalıştığı nesnenin etiketidir. tclass nesne türüdür; bu örnekte bir dosyadır. Birlikte okunduğunda anlam şudur: httpd_t içindeki işlem, default_t etiketiyle işaretlenmiş bir dosyayı okumayı denemiştir. permissive=0 ise isteğin yalnızca günlüğe kaydedilmediğini, gerçekten engellendiğini belirtir.

ausearch hiçbir çıktı üretmiyorsa audit daemon çalışmıyor olabilir. Bu durumda ret kayıtları kernel ring buffer içine yazılır:

sudo journalctl -k | grep -i avc

Şimdi kaydı İngilizce bir cümleye dönüştürün:

sudo ausearch -m AVC -ts recent | audit2why
sudo journalctl -t setroubleshoot --since today
sudo sealert -a /var/log/audit/audit.log

audit2why aynı kayıtları okur ve algıladığı nedeni belirtir: kapalı bir boolean, policy ile eşleşmeyen bir etiket veya hiç kural bulunmaması. sealert günlüğün tamamını tarar ve her ret için önerilen bir komut yazdırır. Öneriyi yalnızca bir ipucu olarak değerlendirin. İfadeler release'ler arasında değişir. Ayrıca sealert bazen tek satırlık bir etiket düzeltmesinin doğru çözüm olduğu durumlarda özel bir policy module oluşturmayı önerir.

Bilinmesi gereken bir nokta daha vardır. Policy, zararsız kabul edilen retleri gizleyen dontaudit kuralları içerir. Bu nedenle günlük boş kalırken bir program hatalı davranabilir. Tek bir test süresince bu kayıtları görünür hale getirin:

sudo semodule -DB
# reproduce the problem, then read the log again
sudo semodule -B

semanage fcontext ve restorecon ile yanlış etiketlenmiş bir yolu düzeltme

İki komut kullanılır ve sıra önemlidir. semanage fcontext -a bir yolun sahip olması gereken etiketi kaydeder. restorecon kaydedilen varsayılan etiketi diskteki dosyalara uygular.

sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?"
sudo restorecon -Rv /data/www
ls -ldZ /data/www/index.html

Yol, düzenli ifade olarak değerlendirilir. (/.*)? dizinin kendisini ve altındaki her şeyi kapsar; belge kökü için gereken davranış budur. Değişiklik yapmadan önce nelerin değişeceğini görün: sudo restorecon -Rvn /data/www planlanan yeniden etiketleme işlemlerini yazdırır, çünkü -n işlem yapılmayacağını belirtir. Gerçek bir restorecon işleminden sonra etiket httpd_sys_content_t olarak görünür ve 403 hatası, servis yeniden başlatılmadan ortadan kalkar.

chcon yalnızca test amacıyla kullanılmalıdır. chcon -t httpd_sys_content_t index.html etiketi doğrudan ayarlar; sonraki restorecon işlemi, paket güncellemesi veya tam yeniden etiketleme bu ayarı sıfırlar, çünkü policy hâlâ yolun başka bir türde olması gerektiğini belirtir. dnf-automatic güvenlik güncellemelerini zamanlanmış olarak uyguluyorsa, bu sıfırlama makinenin başında bulunduğunuz bir anda değil, kendi zamanlamasına göre gerçekleşir. Bu nedenle site, en son müdahaleden saatler sonra çalışmaz hale gelebilir. Kalıcı olan sürüm semanage fcontext komutudur. Kaydettiğiniz kuralları sudo semanage fcontext -l | grep '^/data' ile listeleyin.

Servisin yazması gereken içerik için farklı bir tür gerekir. Bir upload dizini veya cache için httpd_sys_rw_content_t kullanın ve bunu yalnızca ilgili yollarla sınırlayın: salt okunur bir siteyi yazılabilir bir tür altında çalıştırmak, uygulamanın ihtiyaç duyduğundan daha geniş erişim sağlar.

Etiket neden baştan yanlıştı? Bunun nedeni neredeyse her zaman dosyaların sisteme nasıl geldiğidir. mv dosyanın mevcut etiketini korur. Bu nedenle /root dışına taşınan bir site admin_home_t etiketiyle gelir ve bu şekilde kalır. Düz bir cp, yeni dosyaya hedef dizinin varsayılan etiketini verir. Genellikle istenen davranış budur. Buna karşılık cp -a ve rsync -X kaynak etiketlerini dosyayla birlikte kopyalar. Yeni bir üst düzey dizine yapılan git clone işlemi default_t sonucunu üretir. Bir sayfa /usr/share/nginx/html konumundan sorunsuz yükleniyor, ancak kendi dizininizden yüklenemiyorsa bunun nedeni budur.

Boolean ile davranış sınıfını düzeltme

Bazı hatalar etiket sorunundan kaynaklanmaz. Yeni kurulmuş bir Rocky veya AlmaLinux sunucusundaki reverse proxy 502 döndürür ve hata logunda şu mesaj görülür:

2026/08/11 10:02:55 [crit] 1183#1183: *3 connect() to 127.0.0.1:3000 failed (13: Permission denied) while connecting to upstream

Upstream servisiniz çalışır durumdadır. httpd_t domain'i, varsayılan olarak dış ağa bağlantı açamaz. Bu nedenle connect() çağrısı loopback arayüzüne ulaşmadan önce reddedilir. Bu davranışı tek bir anahtar denetler:

getsebool -a | grep httpd_can_network
sudo setsebool -P httpd_can_network_connect on

Önemli olan seçenek -P değeridir. Bu seçenek, değeri diske yazar. -P kullanılmazsa değişiklik bir sonraki yeniden başlatmada kaybolur. Bu durumda servis, makine yeniden başlatılana kadar çalışır. Çalışan değeri kayıtlı değerin yanında görüntüleyen semanage boolean -l | grep httpd_can_network_connect ile sonucu doğrulayın.

Bir boolean mevcutsa elle yazılmış bir kural yerine boolean tercih edilmelidir. Boolean'lar dağıtım politikasıyla birlikte gelir. Bu nedenle bakımları yapılır, belgelenir ve sonraki yöneticinin bulması kolaydır. getsebool -a sistemdeki tüm boolean'ları listeler.

Standart olmayan bir portta servis dinletme

Portlar da etiketlenir. nginx'i 8081 portuna taşıdığınızda başlatılamaz:

nginx: [emerg] bind() to 0.0.0.0:8081 failed (13: Permission denied)

httpd_t yalnızca http_port_t etiketli portlara bağlanabilir ve 8081 bunlardan biri değildir. Portu ekleyin:

sudo semanage port -l | grep -w http_port_t
sudo semanage port -a -t http_port_t -p tcp 8081

Önce listeyi kontrol edin. 8008 ve 8443 dahil olmak üzere birkaç yüksek port zaten izinlidir. Bir portu ikinci kez eklemek ValueError: Port tcp/8081 already defined hatasıyla başarısız olur. Port zaten farklı bir türe aitse eklemek yerine semanage port -m -t http_port_t -p tcp 8081 ile türünü değiştirin.

Taşınan bir SSH portunun çalışmasını sağlayan komut da aynıdır. journalctl -u sshd içindeki Bind to port 2222 on 0.0.0.0 failed: Permission denied, 2222'nin ssh_port_t içinde eksik olduğu anlamına gelir. Bu nedenle daemon'u yeniden başlatmadan ve oturumunuzu kapatmadan önce sudo semanage port -a -t ssh_port_t -p tcp 2222 komutunu çalıştırın. Red Hat ailesinden bir imaj üzerinde VPS'te SSH'yi sağlamlaştırma için genel bir kılavuz izlenirken atlanan adım budur. SELinux bir firewall değildir. Bu nedenle portun ayrıca açılması gerekir: burada sudo firewall-cmd --permanent --add-port=8081/tcp && sudo firewall-cmd --reload veya Debian ya da Ubuntu imajında ufw. --permanent flag'i, bir boolean üzerindeki -P ile aynı yeniden başlatma tuzağını taşır. Bir kuralın hangi arayüzlere uygulanacağını belirleyen zone'ları da Rocky veya AlmaLinux VPS'te firewalld temelleri bölümünde bir kez incelemek gerekir.

Boolean veya label değiştirilemediğinde

Bu durum normal bir sunucuda nadir görülür ve hasara yol açılması en olası noktadır. audit2allow, günlükteki denial kayıtlarından bir policy module oluşturabilir:

sudo ausearch -m AVC -ts recent -c nginx | audit2allow -M nginx_local
cat nginx_local.te
sudo semodule -i nginx_local.pp

Kurulumdan önce nginx_local.te dosyasını okuyun. İki alışkanlık bu işlemi güvenli tutar. Girdiyi -c ile yalnızca düzelttiğiniz programa ait kayıtlarla filtreleyin; çünkü bir haftalık ilgisiz denial kayıtlarını audit2allow içine yönlendirmek bunların tamamını tek seferde yetkilendirir. Açıklayamadığınız bir denial kaydından oluşturulan module hiçbir zaman kurmayın: httpd_t öğesinin sistemdeki tüm dosyaları okumasına izin veren bir kuralı oluşturmak kolaydır, ancak aylar sonra fark etmek zordur. Bir module sudo semodule -r nginx_local ile kaldırılır.

Permissive tanılama modudur, çözüm değildir

sudo setenforce 0
# reproduce the problem once, all the way through
sudo ausearch -m AVC -ts recent
sudo setenforce 1

Permissive modu erişime izin verir ve bunu günlüğe kaydeder. Asıl değeri eksiksiz kayıt sağlamasıdır. Enforcing modunda servis ilk reddetmede durur. Bu nedenle tek bir sorunu düzeltip servisi yeniden başlatırsınız ve ikinci reddetmeyle karşılaşırsınız. Permissive modunda işlem devam eder. Günlük, tek bir çalıştırmada tüm reddetmeleri toplar. Ardından enforcing moduna dönülür ve sorunlar birlikte giderilir.

setenforce, /etc/selinux/config üzerinde değişiklik yapmaz. Bu nedenle yeniden başlatma sonrasında sistem enforcing moduna döner. Bu bir güvenlik ağıdır. Ayrıca setenforce 0 işleminden ibaret bir "çözümün" en kritik anda yeniden ortaya çıkmasının nedeni de budur. Üzerinde çalışırken bir servisin geçici olarak daha geniş erişime ihtiyaç duyması durumunda tüm makine yerine ilgili domain işaretlenmelidir: sudo semanage permissive -a httpd_t, diğer her şeyi enforcing modunda bırakır; sudo semanage permissive -d httpd_t ise bu değişikliği geri alır.

SELinux etiketini düzeltmek yerine devre dışı bırakmanın maliyeti

SELINUX=disabled ayarını /etc/selinux/config içinde yapmak, tek satırlık bir etiket düzeltmesi karşılığında sunucunun kalıcı olarak daha zayıf hale gelmesine yol açar. Fark, bir web uygulamasının ele geçirildiği gün ortaya çıkar. Enforcing modunda saldırganın kodu httpd_t içinde çalışır. Bu nedenle web içeriğini okuyabilir; ancak Unix kullanıcısının izin vereceği duruma bakılmaksızın /etc/shadow okuma veya bir systemd unit yazma işlemi policy tarafından reddedilir. Hiçbir policy yüklenmediğinde ise aynı kod, servis hesabının sahip olduğu tüm yetkilere sahip olur.

Devre dışı bırakmanın daha sonra ödenen bir maliyeti de vardır. Policy yüklenmediği sürece yeni dosyalar etiketsiz oluşturulur ve dosya sistemi policy ile uyumunu kaybeder. SELinux yeniden etkinleştirildiğinde tam bir yeniden etiketleme gerekir. Aksi halde çok sayıda servis aynı anda başarısız olabilir:

sudo fixfiles -F onboot
sudo reboot

Bu işlem /.autorelabel yazar ve sonraki boot sırasında her dosya sistemini yeniden etiketler. Büyük bir diskte bu işlem uzun sürer ve konsol yanıt vermiyor gibi görünebilir. Bu nedenle işlem, bekleyebilecek durumda olunduğunda başlatılmalıdır. Makine zaten kapatılacakken yeniden başlatma için başka nelerin sıraya alındığını önceden kontrol etmek gerekir. dnf update sonrasında eski kernel ve kütüphaneler bellekte kaldığında needs-restarting bunu bildirir. Rocky Linux ve AlmaLinux 9 üzerinde yapılandırma dosyası artık kernel tarafını tek başına devre dışı bırakmaz. SELinux'u tamamen devre dışı bırakmanın belgelenmiş yolu bir kernel argümanı kullanmaktır (sudo grubby --update-kernel ALL --args selinux=0). Bu komutun bilinmesi, başka birinden devralınan sunucularda yararlıdır. Bu işlem 403 hatasının çözümü değildir.

Kapsayıcılara bir etiket daha eklenmesi

Red Hat ailesindeki bir ana bilgisayarda kapsayıcı işlemleri container_t içinde çalışır ve yalnızca container_file_t etiketiyle işaretlenmiş dosyaları okuyabilir. Ana bilgisayardaki bind mount, ana bilgisayarda ls -l tamamen normal görünürken kapsayıcı içinde Permission denied hatasıyla başarısız olur. :Z soneki, çalışma zamanına mount işlemini yeniden etiketlemesini bildirir:

docker run -d -v /data/appdata:/var/lib/app:Z myimage

:Z, dizini yalnızca bu kapsayıcı için etiketler. :z, dizini kapsayıcılar arasında paylaşılacak şekilde etiketler. :Z değerini diğer servislerin kullandığı bir dizine yöneltmek, bu dizini özyinelemeli olarak yeniden etiketler ve söz konusu servisleri bozar. Bu nedenle kapsayıcılara özel yollar kullanılmalıdır. Engine henüz makinede kurulu değilse, bu dağıtımlarda docker komutunun çoğu zaman bu adla çalışan podman olduğunu unutmayın. Bu ayrıntı, Rocky ve AlmaLinux kurulum adımları tarafından, bunlarla karşılaşmadan önce ele alınır. Kurulumun diğer tüm bölümleri, bir VPS üzerinde Docker çalıştırma bölümünde açıklanan diğer tüm image kurulumlarıyla aynıdır.

Ubuntu ve Debian size AppArmor sağlar

Aynı işi yapar, ancak tasarımları farklıdır. AppArmor, disk üzerindeki dosyaları etiketlemek yerine bir programı, çalıştırılabilir dosyasının yolu üzerinden /etc/apparmor.d/ altında bulunan bir profil kullanarak sınırlar. Yeniden etiketlenecek bir şey yoktur ve restorecon bulunmaz. Başlangıç için:

sudo aa-status
sudo journalctl -k | grep -i apparmor

Bir ret kaydı apparmor="DENIED" operation="open" profile="/usr/sbin/nginx" name="/data/www/index.html" requested_mask="r" olarak görünür. İş akışı aynıdır: reddedilen işlemi okuyun, profili bulun ve kuralı değiştirin. sudo apt install apparmor-utils size aa-complain (tek bir profil için permissive) olanağını, aa-enforce ise bu ayarı geri alma olanağını sağlar. Ubuntu, paketlenmiş servislerin belirli bir kümesini sınırlar ve diğerlerini sınırlamadan bırakır. Bu nedenle varsayımda bulunmak yerine gerçekte hangi profillerin etkin olduğunu görmek için aa-status okuyun.

Her iki sistemde de geçerli olan bir alışkanlık vardır. Bir servis doğru görünen bir işlem veya kaynak için Permission denied bildirirse izinlere dokunmadan önce güvenlik günlüğünü okuyun. Sorun çoğu zaman iki kez izin bitlerinde olmaz.

FAQ

Dosya izinleri doğru olduğu halde nginx neden 403 döndürüyor?

Bunun nedeni izin bitleri değil, SELinux'un okuma erişimini reddetmesidir. Web sunucusu httpd_t domain'inde çalışır ve yalnızca web içeriği için etiketlenmiş dosyaları okuyabilir. Bu nedenle default_t veya admin_home_t etiketi taşıyan bir dosya reddedilir ve nginx sunacak içerik bulamaz. sudo ausearch -m AVC -ts recent ile doğrulama yapılabilir. Bu komut, scontext değerinin httpd_t ile bittiğini ve tcontext değerinin yanlış türe sahip olduğunu gösterir. Ardından doğru etiket kaydedilmeli ve uygulanmalıdır: sudo semanage fcontext -a -t httpd_sys_content_t "/data/www(/.*)?", ardından sudo restorecon -Rv /data/www.

Bir servisi çalışır duruma getirmek için setenforce 0 kullanmak güvenli midir?

setenforce 0 bir tanılama adımıdır, çözüm değildir. Sorunu bir kez yeniden üretmek ve günlükteki tüm reddetme kayıtlarını tek geçişte toplamak için kullanın. Ardından kayıtları sudo ausearch -m AVC -ts recent ile okuyun, sudo setenforce 1 komutunu çalıştırın ve nedenleri giderin. Permissive modda bırakılan bir sunucu tüm reddetmeleri günlüğe kaydeder ancak hiçbirini engellemez. Böylece gereksiz kayıtlar korunur ve güvenlik kaybedilir. Çalışma sırasında tek bir servisin geçici olarak izinli çalışması gerekiyorsa sudo semanage permissive -a httpd_t komutunu kullanın. Böylece makinenin geri kalanı enforcing modunda kalır.

Bir servisi SELinux enforcing modunda standart olmayan bir portta nasıl çalıştırabilirim?

Portu, servisin bağlanmasına izin verilen tipe ekleyin. 8081 portunda çalışan bir web sunucusu için: sudo semanage port -a -t http_port_t -p tcp 8081. 2222 portunda çalışan SSH için: sudo semanage port -a -t ssh_port_t -p tcp 2222. Önce mevcut listeyi sudo semanage port -l | grep -w http_port_t ile kontrol edin. Zaten listede bulunan bir port ValueError: Port tcp/8081 already defined nedeniyle başarısız olur. Bu adım uygulanmazsa başka hiçbir süreç portu kullanmıyor olsa bile daemon, başlangıçta bind() ... Permission denied ile sonlanır.

Ubuntu'da SELinux var mı?

Hayır. Ubuntu ve Debian, dosya etiketleri yerine çalıştırılabilir dosyanın yoluna bağlı bir profil uygulayan AppArmor ile birlikte gelir. sudo aa-status ile kontrol edin ve sudo journalctl -k içinde apparmor="DENIED" satırlarını arayın. Ubuntu, paketlenmiş servislerin seçili bir bölümünü kısıtlar. Bu nedenle birçok program varsayılan olarak kısıtlanmadan çalışır. Rocky Linux ve AlmaLinux'ta SELinux'u varsayılan olarak enforcing modunda görürsünüz. Fedora ve RHEL için de aynı durum geçerlidir.