Linux İkili Dizinleri Açıklandı: Eksiksiz Teknik Referans

Linux ikili dizinleri, yürütülebilir programların, sistem yönetim araçlarının ve paylaşılan kütüphanelerin bulunduğu standartlaştırılmış dosya sistemi konumlarıdır. Dosya Sistemi Hiyerarşi Standardı (FHS), dağıtımlar genelinde tutarlı yazılım yerleşimini sağlamak amacıyla bu yolları tanımlar; böylece öngörülebilir `PATH` çözümlemesi, temiz paket yönetimi ve güvenilir sistem kurtarma mümkün olur — zorunlu olmayan dosya sistemleri kullanılamaz durumda olsa bile.

Bir VPS Hosting ortamını veya fiziksel sunucuyu yöneten herhangi bir yönetici için, hangi ikili dosyanın nerede bulunduğunu ve nedenini tam olarak bilmek isteğe bağlı bir bilgi değildir. Bu durum doğrudan önyükleme davranışını, ayrıcalık ayrımını, yazılım dağıtım stratejisini ve güvenlik sıkılaştırmasını etkiler.

İkili Dizin Yapısının Önemi

Tek tek dizinlere geçmeden önce, ayrımın arkasındaki mimari mantığı anlamak faydalı olacaktır. FHS, dosya sistemini iki temel eksen üzerinde böler:

• Temel ve temel olmayan: Tek kullanıcı modu ve acil durum onarımı için gereken ikili dosyalar, `/usr` bağlanmadan önce kullanılabilir olmalıdır. Diğer her şey `/usr` altında yer alabilir.
• Sistem ve kullanıcı düzeyi: Root düzeyinde yönetim için tasarlanmış ikili dosyalar, ayrıcalıksız kullanıcılara açık olanlardan ayrılır; bu sayede dosya sistemi izinleri aracılığıyla daha sıkı erişim denetimi sağlanır.

Bu tasarım felsefesi modern init sistemlerinden önceye dayanır, ancak hâlâ büyük ölçüde geçerliliğini korumaktadır. Yanlış yapılandırılmış bir `PATH`, yanlış dizine yerleştirilmiş bir ikili dosya veya eksik bir kütüphane sembolik bağlantısı, önyükleme dizilerini, cron görevlerini veya servis başlatma betiklerini sessizce bozabilir.

Temel İkili Dizinlere Genel Bakış

/bin — Temel Kullanıcı İkili Dosyaları

`/bin`, sistemin önyükleme yapması ve bir kullanıcının tek kullanıcı veya kurtarma modunda temel işlemleri gerçekleştirebilmesi için gereken minimum yürütülebilir dosya kümesini barındırır. Bu ikili dosyalar, yalnızca kök dosya sistemi bağlı olduğunda bile erişilebilir olmalıdır.

Tipik örnekler: `ls`, `cp`, `mv`, `cat`, `bash`, `echo`, `grep`, `chmod`, `ln`, `mkdir`, `rm`, `ps`

Kritik teknik ayrıntı: Debian 10+, Ubuntu 20.04+, Fedora, Arch Linux ve RHEL 8+ dahil olmak üzere systemd tabanlı dağıtımlarda `/bin` artık `/usr/bin`’e işaret eden bir sembolik bağlantıdır. Bu, initramfs tasarımını basitleştirmek ve atomik işletim sistemi güncellemelerini etkinleştirmek amacıyla kök düzeyindeki ikili dizinleri `/usr` karşılıklarında birleştiren UsrMerge girişiminin bir parçasıdır. Bunu birleştirilmiş herhangi bir sistemde doğrulayabilirsiniz:

“`bash

ls -la /bin

lrwxrwxrwx 1 root root 7 /bin -> usr/bin

“`

Operasyonel etki: Kurtarma ortamlarında veya erken önyükleme kancalarında (örneğin initramfs betikleri) çalışması amaçlanan kabuk betikleri yazıyorsanız, `/usr/bin`’nin kullanılabilir olduğunu asla varsaymayın. Her zaman shebang olarak `/bin/sh` kullanın ve yalnızca POSIX tarafından zorunlu kılınan yardımcı programlara başvurun.

/sbin — Temel Sistem İkili Dosyaları

`/sbin`, tam dosya sistemi ağacı henüz kullanılabilir olmadan önce, önyükleme ve dosya sistemi onarım işlemleri sırasında yürütülebilir olması gereken sistem yönetimi görevlerine ayrılmış ikili dosyaları içerir.

Tipik örnekler: `fsck`, `ifconfig`, `ip`, `reboot`, `shutdown`, `mkfs`, `mount`, `umount`, `fdisk`, `modprobe`, `init`

Ayrıcalık nüansı: `/sbin` ikili dosyaları root kullanımı için *tasarlanmış* olsa da çoğu dağıtımda dünya genelinde yürütülebilir durumdadır. Kısıtlama, ikili dosyanın yürütme biti tarafından değil, işlemlerin kendisi tarafından uygulanır — `fsck` ham aygıt erişimi gerektirir, `mount` ise `CAP_SYS_ADMIN` gerektirir. Bu durum, güvenlik denetimlerinde sık karşılaşılan bir karışıklık kaynağıdır.

Modern durum: `/bin` gibi, `/sbin` de birleştirilmiş-usr sistemlerinde `/usr/sbin`’e bir sembolik bağlantıdır. `/sbin` ile `/bin` arasındaki ayrım artık yapısal olmaktan çok anlambilimsel ve tarihsel bir nitelik taşımaktadır.

/usr/bin — Birincil Kullanıcı İkili Dosyaları Deposu

`/usr/bin`, tipik bir Linux kurulumunda en büyük ve en sık erişilen ikili dizinidir. Acil durum işlemleri için gerekli olmayan, sistem paket yöneticisi aracılığıyla kurulan tüm standart kullanıcı odaklı komut satırı yardımcı programlarını ve uygulamalarını içerir.

Tipik örnekler: `vim`, `nano`, `git`, `python3`, `perl`, `gcc`, `curl`, `wget`, `ssh`, `tar`, `gzip`, `awk`, `sed`, `find`

Pratikte ölçek: Minimal bir Debian sunucu kurulumunda `/usr/bin` 200–400 ikili dosya içerebilir. Tam bir masaüstü ortamı kurulumu bu sayıyı 2.000’in üzerine çıkarabilir. Bu dizin her zaman tüm kullanıcılar için varsayılan `PATH`’da yer alır.

Paket yöneticisi sahipliği: Buradaki her dosya `dpkg`, `rpm` veya dağıtımınızın eşdeğeri tarafından izlenir. Dosyaları `/usr/bin`’e manuel olarak yerleştirmek kesinlikle önerilmez — paket yükseltmeleri bunları uyarı vermeksizin sessizce üzerine yazabilir.

/usr/sbin — Temel Olmayan Sistem Yönetimi İkili Dosyaları

`/usr/sbin`, önyükleme süreci veya tek kullanıcı modu kurtarması sırasında gerekli olmayan ancak günlük sunucu yönetimi için vazgeçilmez olan sistem yönetimi araçlarını içerir.

Tipik örnekler: `apache2`, `nginx`, `sshd`, `useradd`, `userdel`, `usermod`, `groupadd`, `iptables`, `nftables`, `cron`, `logrotate`, `tcpdump`

Mimari bakış açısı: `/sbin` ve `/usr/sbin` ayrımı, başlangıçta bir sistem yöneticisinin `/usr`’yi bağlamaya gerek kalmadan tek kullanıcı modunda önyükleme yapıp onarım gerçekleştirebilmesi için tasarlanmıştır. Pratikte, initramfs ve erken kullanıcı alanına sahip modern sistemlerde bu ayrım büyük ölçüde ortadan kalkmıştır. Ancak eski RHEL 6/CentOS 6 sistemleriyle veya `/usr`’nin gerçekten ayrı bir bölüm olabileceği gömülü Linux ortamlarıyla çalışırken bu ayrımı anlamak hâlâ önemlidir.

/usr/local/bin — Yönetici Tarafından Kurulan Kullanıcı İkili Dosyaları

`/usr/local/bin`, sistem paket yöneticisinin dışında manuel olarak kurulan ve sistemdeki tüm kullanıcılar tarafından erişilebilir olması gereken ikili dosyalar için doğru konumdur.

Tipik kullanım senaryoları:

• Kaynaktan derlenen yazılımlar (örneğin standart dışı modüllerle özel olarak derlenmiş `nginx`)
• `pip install –prefix=/usr/local` aracılığıyla kurulan Python betikleri
• Bağımsız ikili dosyalar olarak dağıtılan üçüncü taraf CLI araçları (örneğin `kubectl`, `helm`, `terraform`, `hugo`)
• Sistem genelinde olması gereken özel otomasyon betikleri

PATH önceliği: Standart FHS uyumlu bir sistemde `/usr/local/bin`, varsayılan `PATH`’da `/usr/bin`’den *önce* yer alır. Bu, buraya yerleştirilen bir ikili dosyanın aynı ada sahip paket yönetimli bir ikili dosyanın önüne geçeceği anlamına gelir. Bu kasıtlıdır — yerel özelleştirmelerin dağıtım varsayılanlarını geçersiz kılmasına olanak tanır — ancak sürümler arasında farklılık oluştuğunda ince hataların sık görülen bir kaynağıdır.

“`bash

echo $PATH

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

“`

Güvenlik değerlendirmesi: `/usr/local/bin` paket yöneticisi tarafından denetlenmediğinden, buraya yerleştirilen ikili dosyalar otomatik güvenlik güncellemeleri almaz. Üretim iş yüklerini çalıştıran sunucularda — Dedicated Servers üzerindekiler dahil — manuel bir güncelleme takvimi oluşturun veya bu ikili dosyaları izlemek ve güncellemek için bir yapılandırma yönetim aracı (Ansible, Puppet, Chef) kullanın.

/usr/local/sbin — Yönetici Tarafından Kurulan Sistem İkili Dosyaları

`/usr/local/sbin`, `/sbin` ile `/bin` arasındaki ilişkiyi yerel düzeyde yansıtır. Yükseltilmiş ayrıcalıklar gerektiren veya yalnızca root için tasarlanmış, manuel olarak kurulmuş sistem yönetimi araçları için doğru konumdur.

Tipik kullanım senaryoları:

• Cron aracılığıyla root olarak çalışan özel yedekleme betikleri
• Manuel olarak derlenmiş izleme ajanları (örneğin özel olarak derlenmiş `node_exporter`)
• Ayrıcalıklı sistem çağrılarını çağıran yönetici sarmalayıcı betikleri
• Paket yerine tarball olarak gelen satıcı tarafından sağlanan yönetim yardımcı programları

Operasyonel disiplin: `/usr/local/sbin` içinde her ikili dosyanın kaynağını, sürümünü ve güncelleme prosedürünü belgeleyen bir `README` veya envanter dosyası tutun. Paylaşılan altyapıda, bu dizindeki belgelenmemiş ikili dosyalar güvenlik ve denetlenebilirlik açısından bir risk oluşturur.

/opt — Bağımsız Üçüncü Taraf Uygulamalar

`/opt`, FHS dizin düzenine uymayan yazılım paketleri için tasarlanmıştır — genellikle ticari veya tescilli uygulamalar, büyük satıcı tarafından dağıtılan yazılım paketleri ve bağımlılık çakışmalarını önlemek amacıyla kendi kütüphanelerini bir arada sunan uygulamalar.

Tipik örnekler:

• `/opt/google/chrome/` — Google Chrome tarayıcısı
• `/opt/lampp/` — XAMPP yığını
• `/opt/pycharm/` — JetBrains PyCharm IDE
• `/opt/gitlab/` — Omnibus GitLab kurulumu
• `/opt/aws/` — AWS CLI v2 ve SSM Agent

Yapısal kural: `/opt` altındaki her uygulama, `/opt/<provider>/` veya `/opt/<package>/` kalıbını izleyen kendi alt dizinini kullanmalıdır. Uygulamanın ikili dosyaları genellikle `/opt/<package>/bin/` konumunda bulunur ve satıcının `/usr/local/bin`’ye bir sembolik bağlantı kurması ya da yolu eklemek için `/etc/profile.d/`’yi değiştirmesi beklenir.

`/opt` ile `/usr/local` arasında ne zaman hangisini kullanmalı: Yazılım kendi kütüphaneleri, yapılandırması ve veri dizinleriyle birlikte bağımsız bir paket olarak geliyorsa `/opt` kullanın. Mevcut sistem kütüphane yığınıyla temiz bir şekilde entegre olan tek ikili araçlar veya betikler için `/usr/local/bin` kullanın.

Gerçek dünya uç durumu: GitLab Omnibus tamamen `/opt/gitlab/` altına kurulur ve kendi PostgreSQL, Redis ve Nginx örneklerini yönetir. Bu izolasyon kasıtlıdır — sistem düzeyindeki servislerle sürüm çakışmalarını önler. Ancak bu aynı zamanda, sistem düzeyindeki izleme araçlarının `/opt`’e bakmak üzere açıkça yapılandırılmadıkça bu süreçleri otomatik olarak keşfedemeyeceği anlamına gelir.

/lib, /usr/lib, /lib64 ve /usr/lib64 — Paylaşılan Kütüphaneler

Bu dizinler, ilgili ikili dizinlerdeki ikili dosyaların çalışma zamanında bağımlı olduğu paylaşılan nesne dosyalarını (`.so` dosyaları) içerir. Geleneksel anlamda yürütülebilir değillerdir; dinamik bağlayıcı (`ld-linux.so`) tarafından işlem belleğine yüklenir.

Temel dizinler ve rolleri:

• `/lib` — `/bin` ve `/sbin`’deki ikili dosyalar tarafından gereken paylaşılan kütüphaneler. Birleştirilmiş-usr sistemlerinde `/usr/lib`’e sembolik bağlantıdır.
• `/usr/lib` — Tüm sistem paylaşılan kütüphaneleri için birincil depo. Paket yönetimli kütüphaneler burada bulunur.
• `/lib64` — Çoklu kütüphane sistemlerinde (x86_64 RHEL/CentOS’ta yaygın) `/lib`’nin 64-bit varyantı. Genellikle `/usr/lib64`’e sembolik bağlantıdır.
• `/usr/lib64` — RPM tabanlı dağıtımlarda 64-bit paylaşılan kütüphaneler.
• `/usr/local/lib` — Manuel olarak derlenen yazılımlarla birlikte kurulan kütüphaneler.
• `/usr/lib/x86_64-linux-gnu/` — 32-bit ve 64-bit kütüphanelerin bir arada bulunmasına olanak tanıyan Debian/Ubuntu çoklu mimari kütüphane yolu.

Çalışma zamanı bağlayıcı mekaniği: Bir ikili dosya çalıştırıldığında, çekirdek kontrolü ELF başlığında belirtilen dinamik bağlayıcıya (genellikle `/lib64/ld-linux-x86-64.so.2`) devreder. Bağlayıcı, `/etc/ld.so.conf`’i ve dahil etme dizinini okuyan `ldconfig` tarafından oluşturulan önbelleği kullanarak paylaşılan kütüphane bağımlılıklarını çözer. Bir kütüphane kurulu olmasına rağmen `ldconfig` çalıştırılmamışsa, dosya mevcut olsa bile ikili dosya “paylaşılan kütüphane bulunamadı” hatasıyla başarısız olur.

“`bash

After installing a library to /usr/local/lib, always run:

ldconfig

Verify library resolution for a specific binary:

ldd /usr/bin/curl

“`

Yaygın tuzak: Özel olarak derlenmiş bir kütüphaneyi `/usr/local/lib`’e ardından `ldconfig` çalıştırmadan kurmak, Linux sunucularında “cannot open shared object file” hatalarının en sık görülen nedenlerinden biridir. Bu durum, özellikle derleme sürecinin `ldconfig` çalıştırmak için root erişimine sahip olmayabileceği VPS with cPanel veya benzeri yönetilen ortamlarda kaynaktan yazılım derlerken sıkça karşılaşılır.

UsrMerge: Modern Dosya Sistemi Birleştirmesi

UsrMerge (veya `usr-merge`) girişimi, pek çok yöneticinin eski sistemlerden taşıdığı zihinsel modeli temelden değiştirdiği için ayrı bir ilgiyi hak etmektedir.

Çözdüğü sorun: Tarihsel olarak `/bin`, `/sbin`, `/lib` ve `/lib64`, `/usr`’den ayrı olarak kök dosya sisteminde bağımsız dizinler olarak bulunuyordu. Bu durum, tam sistem başlatılabilmeden önce `/usr`’yi bağlamak için initramfs’in minimal bir araç seti içermesini gerektiriyordu. initramfs evrensel hale gelip `/usr` salt okunur, ağ üzerinden bağlanabilir veya anlık görüntü yönetimli bir birim olarak ele alınmaya başlandıkça, bu ayrım atomik güncellemelerin ve görüntü tabanlı dağıtımların önünde bir engel haline geldi.

Değişen şey: Birleştirilmiş sistemlerde kök düzeyindeki dizinler sembolik bağlantıya dönüşür:

“`

/bin -> usr/bin

/sbin -> usr/sbin

/lib -> usr/lib

/lib64 -> usr/lib64

“`

UsrMerge’i tamamlamış dağıtımlar:

• Fedora (Fedora 17’den itibaren, 2012)
• Arch Linux (2013’ten itibaren)
• Debian (Debian 12 Bookworm’dan itibaren, 2023)
• Ubuntu (Ubuntu 21.10’dan itibaren)
• RHEL/CentOS (RHEL 7’den itibaren)

Pratik etki: `/bin/bash`’yi sabit kodlayan betikler, `/bin` `/usr/bin`’e sembolik bağlantı olduğundan çalışmaya devam eder. Ancak bir yolun “temel” olup olmadığını `/usr/bin` yerine `/bin` ile başlayıp başlamadığını kontrol ederek belirlemeye çalışan betikler hatalı sonuçlar üretecektir. Otomasyon araçlarınızdaki bu tür mantığı güncelleyin.

İkili Dizin İzinleri ve Güvenlik Sıkılaştırması

İkili dizinleri anlamak, güvenlik etkilerini anlamaktan ayrı düşünülemez. Bu yollar için doğrudan geçerli olan çeşitli sıkılaştırma önlemleri mevcuttur.

Önerilen izin temel değerleri:

SUID/SGID ikili dosyaları: `/usr/bin` ve `/usr/sbin`’deki bazı ikili dosyalar SUID bitini taşır; bu sayede kim çalıştırırsa çalıştırsın yükseltilmiş ayrıcalıklarla yürütülebilirler. Örnekler arasında `passwd`, `sudo`, `su` ve `ping` sayılabilir. Bunları düzenli olarak denetleyin:

“`bash

find /usr/bin /usr/sbin /bin /sbin -perm /4000 -o -perm /2000 2>/dev/null

“`

Değişmez bayraklar: Yüksek güvenlikli sistemlerde kritik ikili dosyalara `chattr +i` uygulamayı veya `/usr`’yi salt okunur olarak bağlamayı düşünün. Bu, kötü amaçlı yazılımlar veya güvenliği ihlal edilmiş bir süreç tarafından çalışma zamanında değiştirilmeyi önler; ancak meşru paket güncellemeleri için okuma-yazma modunda yeniden bağlanması gerekir.

`noexec` bağlama seçeneği: `/tmp` ve `/var/tmp`’yi `noexec` ile bağlamak, oraya bırakılan ikili dosyaların doğrudan çalıştırılmasını engeller — bu, web kabuğu saldırılarında yaygın kullanılan bir tekniktir. Bu durum ikili dizinlerin kendisini etkilemez; ancak web uygulamaları çalıştıran sunucular için tamamlayıcı bir sıkılaştırma önlemidir; Shared Web Hosting ortamlarını kullananlar dahil.

PATH Ortam Değişkeni ve İkili Dosya Çözümleme Sırası

`PATH` değişkeni, kabuğun yürütülebilir dosyalar için dizinleri hangi sırayla aradığını belirler. Bu sırayı anlamak, “komut bulunamadı” hatalarını ayıklamak ve kasıtlı ikili dosya gölgeleme için gereklidir.

Debian/Ubuntu sisteminde tipik root PATH:

“`

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

“`

Tipik ayrıcalıksız kullanıcı PATH:

“`

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

“`

Temel gözlemler:

• `/usr/local/bin`, `/usr/bin`’den önce gelir; bu nedenle yerel olarak kurulan ikili dosyalar paket yönetimli olanların önüne geçer.
• `/sbin` ve `/usr/sbin`, bazı dağıtımlarda varsayılan ayrıcalıksız kullanıcı PATH’inde yer almaz; bu nedenle root olmayan bir kullanıcı olarak `ifconfig` çalıştırmak, ikili dosya mevcut olsa bile “komut bulunamadı” hatasıyla başarısız olabilir.
• Bir servis root olmayan bir kullanıcı hesabı altında çalışırken (örneğin bir web uygulaması kullanıcısı), PATH’i daha da kısıtlı olabilir. Servis birim dosyalarında ve cron görevlerinde her zaman mutlak yollar kullanın.

PATH sorunlarını ayıklama:

“`bash

Find all instances of a binary across PATH directories:

which -a python3

Show full PATH resolution including aliases and functions:

type -a python3

Check the effective PATH for a specific service:

systemctl show myservice | grep -i environment

“`

Pratik Karar Matrisi: İkili Dosya Nereye Kurulmalı

Bir Linux sunucusuna yazılım dağıtırken — ister derlenmiş bir araç, ister indirilen bir ikili dosya, ister özel bir betik olsun — şu karar çerçevesini kullanın:

Sistem paket yöneticisi tarafından mı yönetiliyor?

• Evet: Paket yöneticisi onu otomatik olarak `/usr/bin` veya `/usr/sbin`’ye yerleştirir. Taşımayın.

Manuel olarak kurulan, tüm kullanıcılar için tasarlanmış tek bir ikili dosya veya betik mi?

• Kullanıcı odaklı araç: `/usr/local/bin`
• Root/yönetici aracı: `/usr/local/sbin`

Kendi bağımlılıklarıyla birlikte gelen bağımsız bir uygulama paketi mi?

• `/opt/<vendor>/<package>/` kullanın ve ana ikili dosyayı `/usr/local/bin`’ye sembolik bağlantıyla bağlayın

Geçici veya kullanıcıya özgü bir araç mı?

• `~/bin`’ye yerleştirin (yoksa oluşturun) ve `~/.bashrc` veya `~/.profile`’daki kişisel `PATH`’nize `~/bin` ekleyin

Manuel olarak derlenen bir uygulama için paylaşılan kütüphane mi?

• `/usr/local/lib`’e kurun, ardından `ldconfig` çalıştırın

Bu çerçeve, uzun süredir çalışan sunucularda en yaygın dosya sistemi karmaşasını önler: paket yöneticisine görünmez, kurulumu yapan yönetici tarafından unutulmuş ve rastgele konumlara dağılmış ikili dosyalar.

Teknik Temel Kontrol Listesi

• Sisteminizdeki UsrMerge durumunu `ls -la /bin /sbin /lib` ile doğrulayın. Bunlar sembolik bağlantıysa `/bin` ve `/usr/bin` aynı ad alanlarıdır.
• Dosyaları doğrudan `/usr/bin` veya `/usr/sbin`’ye asla yerleştirmeyin — paket yükseltmeleri bunları sessizce üzerine yazar.
• Paylaşılan kütüphaneleri `/usr/local/lib`’e veya standart dışı herhangi bir yola kurduktan sonra her zaman `ldconfig` çalıştırın.
• Cron görevlerinde, systemd birim dosyalarında ve init betiklerinde mutlak yollar kullanın — etkileşimli olmayan bağlamlarda `PATH`’nin doğru ayarlandığına asla güvenmeyin.
• Üretim sunucularında SUID/SGID ikili dosyalarını üç ayda bir denetleyin: `find /usr /bin /sbin -perm /6000 -type f`
• `/usr/local/` ve `/opt/`’ye kurulan her ikili dosyayı sürüm, kaynak URL ve kurulum tarihi bilgileriyle birlikte bir yapılandırma yönetim sisteminde veya en azından yerel bir değişiklik günlüğünde belgeleyin.
• Birleştirilmiş-usr sistemlerinde, “temel” ikili dosyaları yol önekiyle ayırt eden tüm otomasyonları güncelleyin — bu ayrım artık yalnızca anlambilimseldir.
• Uygulamaları VPS Control Panels veya yönetilen barındırma ortamlarına dağıtırken, kontrol panelinin `PATH`’yi değiştirip değiştirmediğini veya `/opt` ya da `/usr/local` altına kendi ikili sürümlerini kurup kurmadığını doğrulayın; bu durum sistem araçlarıyla sürüm çakışmalarına yol açabilir.
• SSL ile ilgili araçlar için (`openssl`, `certbot`), hangi ikili sürümünün çağrıldığını doğrulayın — `/usr/local/bin`’deki eski manuel kurulmuş bir sürüm, paket yönetimli olanın önüne geçer ve yamalanmamış güvenlik açıkları taşıyabilir. Kriptografik araç zincirinizin uçtan uca güncel olduğundan emin olmak için bunu uygun SSL Certificates yönetimiyle birleştirin.

Sıkça Sorulan Sorular

Modern Linux’ta `/bin` ile `/usr/bin` arasındaki fark nedir?

UsrMerge’i tamamlamış modern dağıtımlarda işlevsel bir fark yoktur — `/bin`, `/usr/bin`’e sembolik bir bağlantıdır. Tarihsel olarak `/bin`, yalnızca `/usr` bağlanmadan önce gereken ikili dosyaları içerirken `/usr/bin` diğer her şeyi barındırıyordu. Bu ayrım, birleştirilmiş sistemlerde artık yalnızca anlambilimsel niteliktedir; ancak eski veya gömülü Linux kurulumlarında mimari açıdan önemini korumaktadır.

`/usr/local/bin`’e bir ikili dosya yerleştirmek neden `/usr/bin`’deki aynı ikili dosyanın önüne geçer?

Çünkü `/usr/local/bin`, varsayılan `PATH`’da `/usr/bin`’den önce yer alır. Kabuk, komutları `PATH` dizinlerinde soldan sağa arayarak bulduğu ilk eşleşmeyi çalıştırır. Bu sıralama kasıtlıdır — yöneticilerin paket yönetimli dosyaları değiştirmeden yerel geçersiz kılmalar dağıtmasına olanak tanır.

Paylaşılan kütüphane kurduktan sonra `ldconfig` çalıştırmayı unutursam ne olur?

Dinamik bağlayıcının önbelleği (`/etc/ld.so.cache`) yeni kütüphaneyi içermez ve ona bağımlı herhangi bir ikili dosya çalışma zamanında `error while loading shared libraries: libfoo.so.1: cannot open shared object file: No such file or directory` gibi bir hatayla başarısız olur. `sudo ldconfig` çalıştırmak önbelleği yeniden oluşturur ve sorunu hemen çözer.

Yazılımı `/usr/local/bin` yerine doğrudan `/usr/bin`’ye kurmak güvenli midir?

Hayır. `/usr/bin`’deki dosyalar paket yöneticisine aittir ve onun tarafından izlenir. Gelecekteki bir paket yükseltmesi veya sistem güncellemesi, o dizindeki herhangi bir dosyayı uyarı vermeksizin üzerine yazabilir, taşıyabilir veya silebilir. Paket yönetimli yazılım ile yönetici tarafından yönetilen yazılım arasında temiz bir ayrım sağlamak için manuel olarak kurulan ikili dosyalar için her zaman `/usr/local/bin` kullanın.

Bir komutun hangi dizinden çalıştırıldığını nasıl bulabilirim?

`PATH`’deki ilk eşleşmeyi hızlıca bulmak için `which <command>` kullanın; kabuk yerleşikleri, takma adlar ve tüm `PATH` dizinlerindeki her örnek dahil tüm eşleşmeleri listelemek için `type -a <command>` kullanın. Sembolik bağlantı çözümlemesi dahil kesin bir yanıt için `readlink -f $(which <command>)` kullanın.