Linux'ta find komutu

Dosya aramak. Bitmez tükenmez bir ihtiyaç. Bütün işlevlerin de yıllar önce tasarlanmış bir find komutunun yetenekleri ile hala yapılabiliyor olması ilginç.

En çok kullandığım işlev, en son değişiklik tarihine göre dosya aramak; muhtemelen kısmi dosya ismi ile birlikte. Son 1 gün içinde değişen dosyaları bulmak için

find . -type f -iname '*.txt' -mtime 1

Burada en sondaki rakamın yanında artı veya eksi olmadığından tam 1 gün önce (1 ile 2 arasındakileri; yani 24 saat ve 48 saat önce değişenleri) değişenleri bul demek. 1 günden önce değişenler demek için

find . -type f -iname '*.txt' -mtime +1

Bir günden daha önce (24 saatten daha kısa süre önce) değişenleri bul demek için ise

find . -type f -iname '*.txt' -mtime -1

demek gerek.

Son 10 dakika içinde değişen (oluşan) dosyaları görmek için

find . -type f -mmin -10

Son 10 dakika ile 30 dakika arasında değişen dosyaları görmek için

find . -type f -mmin +10 -mmin -30 

Daha net bir tarih ve saat bilgisi için -newermt parametresi kullanılabilir. Örneğin 1 Ocak 2024'ten sonra değişen txt uzantılı dosyalar için

find . -type f -newermt '2024-01-01'
find . -type f -newermt 'Jan 1 2024'
find . -type f -newermt '2024-01-01 01:25 PM'

gibi komutlar kullanılabilir. En sondaki örnek diğerleri ile eşdeğer değil, saat farkı ile farklı sonuçlar üretir, sadece ISO tarih biçimindeki saat bilgisini göstermek için verdim.

Bu parametre daha esnek kullanıma da sahip. Örneğin

find . -type f -newermt 'yesterday'
find . -type f -newermt '2 weeks ago'
find . -type f -newermt '6 hours ago'

Hatta belli bir tarih aralığı için ünlem "!" işareti aralık sonu belirlenebilir. Örneğin 1 Ocak 2024 ile 31 Nisan 2024 arasını belirtmek için

find . -type f -newermt "2024-01-01" ! -newermt "2024-04-31"

Bir dosyanın oluşturulmasından daha sonra oluşturulmuş (düzenlenmiş) dosyaları bulmak da mümkün. Örnek dosyamız /home/metin/referans_dosya olsun. 

find . -type f -newer /home/metin/referans_dosya

Tüm tarih verileri sistemin yerel saatine göre yapılıyor.

Başka bir kriter de dosya boyutu. Genelde ihtiyacım olan belli bir boyutun üzerinde olan dosyalar. 2 GB'tan büyük ISO dosyaları için

find . -type f -iname '*.iso' -size +2G

Tam tersi, 2 GB'tan küçük iso dosyaları için ise, tahmin edilebileceği gibi boyut belirten 2'nin yanındaki artı '+' işaretini eksiye '-' çevirerek

find . -type f -iname '*.iso' -size -2G

find komutu sonrasında dosyanın ls ile gösterilen ayrıntılarını görmek istiyorsak iki seçenek var. -exec kullanmak, ya da find'in kendi -ls parametresini kullanmak. İki örnek

find . -type f -newermt 'yesterday' -exec ls -l {} \;
find . -type f -newermt 'yesterday' -ls

İlk örneğin sonundaki \; işareti ls komutunu bulunan her dosya için ayrı ayrı çalıştır demek. Her birini toplayıp tek seferde ls çalıştırmak için bunun yerine \+ kullanmak gerek.

İkinci örnekteki -ls parametresi, normal ls komutunun çıktısına göre 2 fazla sütun veri üretir. İlk sütun bulunan dosyanın dosya sistemindeki inode numarası. İkinci sütun ise bu dosyanın dosya sisteminde kaç blok kapladığını gösterir (sistemimizde bir blok kaç byte diye bakmak istersek sudo tune2fs -l /dev/sda). Aslında ls -li komutu ile de bu sütunlara ulaşmak mümkün.

Sadece bulunduğumuz klasördeki dosyalarla ilgileniyorsak ve en son değiştirilenleri bulmak istiyorsak

ls -ltR

Bu şekilde değiştirilme zamanlarına (-t) göre sıralar. En son değiştirilenlerin en altta yer alması için (-R) kullanılır, yoksa en son değişenler en üstte yer alır. Sadece son değişen 10 tane ile ilgileniyorsak

ls -lt | head

kullanabiliriz. Dosya boyutuna göre sıralamak için -S kullanılabilir. Bu da varsayılan olarak büyükten küçüğe sıralar. En büyük 5 dosyayı listelemek için

ls -lS | head -5

---

https://www.cyberciti.biz/faq/linux-unix-osxfind-files-by-date/

Linux güvenlik duvarı ve logları

Debian sunucu üzerinde ufw güvenlik duvarını etkinleştirmiş, 

sudo ufw enable

bazı hizmetler için port açma kuralları oluşturmuştum.

sudo ufw allow to <hizmet|port>

Ara sıra güvenlik kayıtlarını incelemek için

sudo journalctl -u <hizmet> --since "1 week ago"

gibi bir komut ile son 1 hafta içinde gerçekleşen olaylara ait kayıtları inceliyordum. Şüpheli/ısrarcı bir IP adresinden gelen istekler ile ilgili engelleme kuralları koyuyordum.

sudo ufw deny from 192.168.5.0/24 to any

Normalde /var/log/ufw.log dosyasında engellenen IP adreslerine ait kayıtlarının olması gerekir.

sudo tail /var/log/ufw.log

Bir süre sonra farkettim ki ufw ile önce istediğim hizmeti etkinleştirip altında da ufw deny komutu ile eklediğim IP engellemeleri aslında engellenmiyor. Bunun sebebi de genel olarak güvenlik duvarı kuralları içinde işlemin üstteki kuraldan başlaması ve aşağıya doğru inmesi. Trafiğe uyan bir kural bulunduktan sonra alttaki diğer kurallar işletilmiyor. Yani üstte hizmete izin veren bir kural varsa attaki engellemeler çalışmıyor. Bunun için engelleme kurallarını izin verme kurallarının üstüne koymaya başladım, aşağıdaki gibi

sudo ufw insert 1 deny from 192.168.5.0/24 to any

Bunun sonucunda da /var/log/ufw.log dosyasına artık kayıtlar düşmemeye başladı. Acaba engellemeler çalışmıyor mu diye düşündüm ama

sudo iptables -L ufw-user-input -v -n

komutuyla baktığımda ilgili engelleme kurallarının yanıdaki sayaçların arttığını gördüm. Yani engelleme kuralları çalışıyor ama log kayıtları oluşmuyordu. Arka planda iptables altyapısını kullanan ufw, izin, engelleme ve log işlemleri için karmaşık bir kural yapısına sahip. insert ile üst sıraya eklediğim kurallar log yapısını bozuyor. Buna çözüm olarak önce ufw-user-input zincirine iptables komutu ile yeni LOG kuralı eklemeyi (her IP için ayrı kural) denedim.

sudo iptables -I ufw-user-input 1 -s 192.168.5.0/24 -j LOG --log-prefix "[UFW BLOCK] "

Ama her yeni IP adresi engelleme kurallı eklediğimde ufw, iptables kurallarını sıfırlayıp kuralları tekrar baştan yazdığı için log kuralım da siliniyordu. Bu duruma çözüm olarak LOG kurallarını ufw-user-input zincirine değil de ufw-before-input zincirine eklemeyi, ekleme işlemini de /etc/ufw/before.rules dosyası aracılığıyla yapmayı buldum. Bu şekilde kuralları değiştirdiğimde eski LOG silinmiyor. before.rules dosyasında *filter anahtar kelimesi ile başlayan ve # End required lines ile biten bölümden hemen sonra

-A ufw-before-input -s 192.168.5.0/24 -j LOG --log-prefix "[UFW BLOCK] " --log-level 4

ekliyorum. Bunu da engellediğim her IP adresi için ayrı ayrı yapıyorum.

iptables altyapısı aslında /var/log/ufw.log gibi bir dosyaya log yazmıyor. ufw nasıl oluyor da buraya yazabiliyor, merak ettim. Loglar aslında

/var/log/syslog
/var/log/messages
/var/log/kern.log

yazılıyor. Bu loglar üzerinden de

grep "UFW BLOCK" /var/log/kern.log

gibi sorgular ile ufw engellemeleri görülebiliyor. Bunların ufw.log dosyasında da görünmesini sağlayan ise rsyslog sistemi. /etc/rsyslog.d/20-ufw.conf dosyasında aşağıdaki gibi bir satır var.

:msg,contains,"[UFW " /var/log/ufw.log

Bu satır sayesinde syslog kayıtlarında içinde "[UFW " geçen logların /var/log/ufw.log dosyasına yönlendirilmesi sağlanmış.

Dahası, bir süredir iptables altyapısı yerine nftables'ın kullanıldığı farkettim.

sudo iptables -V

komutu sonucunda parantez içinde nf_tables yazıyorsa evet, iptables yerine nftables kullanıyoruz demek. Bunun yerine parantez içinde legacy yazıyor veya olabilir ya da parantez içinde bir ifade olmayabilir. Bu, iptables olduğunun göstergesi. Bir süre daha uyumluluk modunda iptables komutları ile çalışabiliriz. Ama bu uyumluluk modu uzun sürmeyecek. Sistemde nftables'ın izlerini aramak için önce kurulu paketlerin içinde nftables arayabilirim. Debian tabanlı sistemlerde

dpkg -l | grep -E "(iptables|nftables|ufw)"

veya Fedora türevlerinde

rpm -qa | grep -E "(iptables|nftables|firewalld)"

Yüklü modüllerde nf_tables olup olmadığına bakabilirim

lsmod | grep nf_tables

systemd birimlerine bakabilirim

systemctl list-units --type=service | grep -E "(iptables|nftables|firewall)">

Son olarak nftables kullanan bir sistemde

nft list ruleset

ile json formatında bir çıktı kural kümesini gösterir. Diğer bazı kontroller:

update-alternatives --display iptables

ls -l /etc/alternatives/iptables

bash prompt'a en son komut çalışma süresini eklemek

bash promptumda en son çalışan komutun ne kadar süre ile çalıştığını gösteren bir alan olmasını istiyorum. Bu işi doğrudan yapmanın bir yönteminin olmadığını öğrendim. Ama dolaylı olarak yapmanın yolları var. trap ve PROMPT_COMMAND gibi yönergeler işe yarıyor. Yazdığımız komutu çalıştırmadan hemen önce çalışacak fonkisyonu trap ile bildiriyoruz. Promptu oluşturacak fonksiyonu işe PROMPT_COMMAND yönergesi ile belirliyoruz. Örneğin preexec adında bir fonksiyon oluşturup içeriğini şöyle belirledim.

function preexec() {
    export TIMER_START=(date +%s%3N) 
} 

Bu fonksiyon, TIMER_START adında bir değişken oluşturup, içeriğini 01.01.1970'ten bu yana geçen milisaniyelere eşiytleyecek. Sonra da precmd adında bir fonksiyon oluşturup içeriğini aşağıdaki gibi belirledim.

function precmd() {
    local TIMER_END=(date +%s%3N)
    local TIME_DIFF=$((TIMER_END-TIMER_START))
    if (( TIME_DIFF > 1000 )); then
        local  DURATION="$((TIME_DIFF / 1000)) s"
    else
        local DURATION="$TIME_DIFF ms" 
    fi 
    export PS1="($DURATION) $ "
}

Bundan sonra preexec'i trap ile, precmd'yi de PROMPT_COMMAND ile belirliyorum.

trap 'preexec' DEBUG 
PROMPT_COMMAND=precmd

Ancak bundan sonra farkettim ki preexec fonksiyonu birden fazla işliyor. Benim tespit ettiğim bir kez komutu çalıştırmadan önce, bir kez de komutu çalıştırdıktan sonra. Bu ilginç bir konu ama derinlerine dalmak istemedim. Basit bir şekilde bir komut için sadece 1 kez çalıştırılmasını bir değişkenle denetledim.

preexec_active=0
function preexec() {
    if [[ $preexec_active -eq 0 ]]; then
        export TIMER_START=(date +%s%3N)
        preexec_active=1
    fi
}

Benzer şekilde precmd fonksiyonunun içine de bu değişkeni eski haline döndürecek bir satır ekledim.

function precmd() {
    local TIMER_END=(date +%s%3N)
    local TIME_DIFF=$((TIMER_END-TIMER_START))
     if (( TIME_DIFF > 1000 )); then
         local DURATION="$TIME_DIFF s"
    else
         local DURATION="$TIME_DIFF ms" 
    fi 
    export PS1="($DURATION) $ "
    preexec_active=0
}

Bu şekilde herşey istediğim gibi oldu.

KDE'de 3 parmak kaydırma hareketi algılama

Touchpad'in fareye göre biraz zor olduğu doğru. Ama avantajları da var. Örneğin bir süredir standart olan iki parmak kaydırma ile sayfada gezinme güzel birşey. Son zamanlarda 3 parmak ile kaydırma işlevlerinin de Windows ve Gnome'da çok kullanışlı olmasının ardından x11 ile birlikte kullandığım KDE'ye de bu özellikleri kazandırmak için ne yapabilirim diye bakınca touchegg touche paketlerinin varlığından haberdar oldum.

sudo pacman -S touchegg touche

komutuyla kurdum. Kurduktan sonra touchegg hizmetini etkinleştirdim.

sudo systemctl enable touchegg.service --now

Sonra da bir kez yeniden başlattım, --now'a rağmen -gerekiyormuş. Açıldıntan sonra başlat menüme eklenen Touche simgesine tıklayınca Touche penceresi açıldı:

 

Buradan 3 parmak hatta 4 parmak kaydırma hareketleri için istediğim atamaları yapabildim.

Manjaro'da gerek duyulmayan paketleri silmek

Manjaro linux'umdaki root partition'ım doldu. Biraz yer açmam lazım. En büyük yer kaplayan klasör de pacman cache'i.

pacman -Qdtq

komutu ile bir sürü pakete artık ihtiacımın olmadığnı görüyorum. Ama bir ara Linus Sebastian'ın başına geldiği gibi birşeyin benim başıma da gelmemesi için öncelikle bütün paketlerin gerçekten ihtiyaç duyulmadığını görmek, hatta şüphe ettiklerimi kapsam dışında bırakmak istiyorum. Öncelikle -Qdtq ile listelenen paket listesini bir dosyaya atıyorum.

pacman -Qdtq > gereksizler.txt

Belki ilk iş olarak bu listeye bakabilir, tereddüt ettiklerimi çıkarabilirim. Sonra bu listedeki her paketin -Qi ile listelenen bilgilerine bakmak istiyorum. Örneğin electron paketi gereksiz olarak listelenmiş. -Qi ile baktığımda şöyle bir çıkış alıyorum:

pacman -Qi electron
İsim                   : electron
Sürüm                  : 1:33-1
Açıklama               : Meta package providing the latest available stable Electron
                         build
Mimari                 : any
URL                    : https://electronjs.org
Lisanslar              : MIT
Gruplar                : Hiçbiri
Sağlananlar            : Hiçbiri
Bağımlılıkları         : electron33
Tercihli Bağımlılıklar : Hiçbiri
İhtiyaç Duyulanlar     : Hiçbiri
İsteğe Bağlı           : Hiçbiri
Çakışıyor              : Hiçbiri
Değiştirilenler        : Hiçbiri
Kurulum Boyutu         : 0,00 B
Paketçi                : Caleb Maclennan <alerque@archlinux.org>
İnşa Tarihi            : Sal 15 Eki 2024 23:10:40
Yükleme Tarihi         : Paz 01 Ara 2024 09:31:58
Yükleme Sebebi         : Başka bir paketin bağımlılığı olarak kurulmuş
Kurulum Betiği         : Hayır
Doğrulayan             : İmza

Burada İhityaç Duyulanlar alanı, bu pakete ihtiyaç duyan diğer paketleri, İsteğe Bağlı alanı ise çalışmak temel işlevleri için değil de bazı ek işlevler için bu pakete ihtiyaç duyabilecek paketleri listeliyor. Görüldüğü gibi electron için bu liste boş. Dolayısıyla silinebilir. Bu listedeki 92 paket için bunu elle yapmak istemiyorum. Otomatize etmek için

xargs -r pacman -Qi < gereksizler.txt | grep -E "İhtiyaç Duyulanlar|İsteğe Bağlı"

gibi bir komutla her paket için ekrana "İhtiyaç Duyulanlar" ve "İsteğe Bağlı" alanlarını yazdırıp gerçekten gereksiz olup olmadığını görmek istiyorum.

Bu adım gereksiz, evet. Ama emin olmak istedim. Nihayet, her paket için hem ihtiyaç duyulan hem de isteğe bağlı satırda "Hiçbiri" yazdığını görünce tümünü birden silme komutunu verdim.

sudo pacman -Rsn $(pacman -Qdtq)

Dizüstü bilgisayarın bataryasının durumunu kontrol etme

Dizüstü bilgisayarların bataryaları zamanla ilk günkü kapasitelerini kaybederler. Bataryamızın fabrika çıkışındaki kapasitesi ile bugünkü kapasitesini karşılaştırmak istersek Windows'da powercfg komutunu kullanabiliriz.

powercfg /batteryreport

Bu bir htm formatında rapor dosyası üretecek, bulunduğumuz klasörde.  Tarayıcımızla açıp inceleyebiliriz. Bu dosyada "DESIGN CAPACITY" bölümünde gözüken bataryamızın fabrika çıkışındaki kapasitesi. "FULL CHARGE CAPACITY" bölümünde gözüken ise bugünkü kapasitesi.

Linux'ta ise bunu upower komutu ile yapabiliriz. Linux'ta bu iki aşamada oluyor. Önce upower ile mevcut cihazları listelemek gerek.

upower -e

Burada muhtemelen battery_BAT0 gibi bir şekilde isimlendirilen kaynağı kopyalayıp bir sonraki adımda upower'a -i parametresi ile birlikte yapıştırmak gerek:

upower -i /org/freedesktop/UPower/devices/battery_BAT0

Bu komutun çıktısında da energy-full-design bataryanın tasarlanan kapasitesini, energy-full ile bugünkü kapasitesini gösteriyor.

bugünkü kapasite / tasarlanan kapasite 'nin 0,8'den küçük olması bataryanın kapasitesinin ciddi düştüğü anlamına geliyor.

Gnome'da batarya düşük ve kritik seviyelerini belirlemek

Gnome masaüstü kullanan bir bilgisayardayım. Varsayılan düşük batarya seviyesi %20. Yani bu seviyeden sonra düşük güç harcama kipi etkinleştiriliyor. Kritik batarya seviyesi %5 ve askıya alma seviyesi de %2. Batarya yeniyken sorun yok ama batarya bir süre (~2 yıl?) kullanıldıktan sonra bu seviyeleri değiştirmek gerekebilir. Benim bilgisayarımda seviye %10'a geldikten sonra çok hızlı bir şekilde %2'ye düşüyor ve askıya alma işlemi gerçekleşiyor. Bu sebeple bu seviyeleri biraz yükseltmek gerek. Ama grafik arayüzde bunu değiştirecek bir yer bulamadım. Şu sayfada bulduğum bilgi işimi yarar. Önce uygun bir editör ile /etc/UPower/UPower.conf dosyasını (sudo ile) açıp şu satırlara geledim:

PercentageLow=10.0
PercentageCritical=5.0
PercentageAction=2.0 

Bu satırları aşağıdaki gibi değiştirdim.

PercentageLow=30.0
PercentageCritical=10.0
PercentageAction=5.0

Sonra da upower hizmetini tekrar başlattım.

sudo systemctl restart upower.service

Manjaro büyük güncelleştirmeleri

Manjaro bir rolling distro. Yani Ubuntu veya Fedora gibi yılda 2 kez yayınlanan büyük sürüm güncellemeleri ile bir sürümden diğerine geçiş yok. Onun yerine sürekli güncel tutulan bir güncelleştirme yapısı var. Pratikte son kullanıcıyı etkileyen pek birşey yok.

/var/log/pacman.log dosyasına bakarak sistemimdeki büyük güncelleştirmeler ne zaman olmuş diye bulabilmem gerektiğini düşünüyorum. Belli bir süre IT dünyasında çalışınca log dosyalarına bağımlılık oluşuyor.

Önce manjaro-keyring paketinin güncelleştirmelerine bakarak en son büyük sistem güncelleştirmesinin ne zaman olduğunu veya bu yıl kaç kere olduğunu bulmaya çalıştım. Çok net bir sonuç vermedi. Çünkü manjaro-keyring illa büyük bir güncelleştirme ile birlikte gelmiyor.

Daha sonra manjaro-release paketini bu büyük güncelletirmelerle ilişkilendirmeyi denedim. Aslında mantıklıydı ama tam olarak yine sanki doğru sonuç vermiyor gibiydi.

En son girişimim belli bir tarihte yapılan paket güncelleştirme sayısına bakarak bir sonuç çıkartmak. Yani pacman.log dosyasında aynı tarih bilgisinden kaç tane geçtiğini sayarak ne kadar fazla paketin güncelleştirildiğini bularak bir sonuca ulaşmaya çalışmak. Bunu da sistemi ilk kurduğum günden bu yana değil de sadece 2024 yılı güncelleştirmelerinin içinde aramak istedim. Kullandığım komut dizisi şöyle:

grep -E '^\[2024-' /var/log/pacman.log | awk '{print $1}' | tr -d '[]' | awk -F 'T' '{print $1}' | sort | uniq -c | awk '$1 >= 200'

Burada kısaca ilk bölüm sadece içinde [2024 geçen satırları süzüyor. Daha sonra boşluk karakteri ile satırdaki diğer bilgilerden ayrılan tarih saat bilgisini alıp bu bilgiden köşeli parantez ("[" ve "]") temizliyor. Manjaro'da bu tarih saat bilgisi 2024-12-13T16:15:23 gibi olduğu için ve burada sadece tarih bilgileriyle ilgilendiğim için "T" karakterini bir ayraç olarak kullanıp bu ayraç karakterinden önce gelen tarih alanı çıkarttım. Daha sonra her tarih bilgisinin kaç kere geçtiğini uniq -c komutuyla sayıp, bu sayının 200'den fazla olanlarını süzdüm. Fena olmadı sanki.

pacman.log dosyasında geçen her satır güncellenen bir pakete ait değil; başka bilgiler de bu kayıt dosyasına düşülüyor. Bir sebeple sadece güncellenen dosyaların sayısı ile ilgileniyorsak ilk awk komutundan önceki bölüme bir de grep 'upgraded' eklemek gerek:

grep -E '^\[2024-' /var/log/pacman.log | grep 'upgraded' | awk '{print $1}' | tr -d '[]' | awk -F 'T' '{print $1}' | sort | uniq -c | awk '$1 >= 200' 

Sanırım burada kalan soru: büyük bir güncellemede kaç paket değişir?

Çoklu masaüstünü yönetmek

Windows'da çoklu masaüstü ortamı kısayolları:

Alt + Tab: Mevcut masaüstünde açık pencereler arasında geçiş yapmak

Win + Tab: Mevcut masaüstündeki pencerelerin yanı sıra diğer açık masaüstlerini de gösteren bir görünüm. Buna "Görev Görünümü" deniyor, hatta görev çubuğunda bu görünüme ait bir öğe (buton/düğme ya da her ne dersek) var. Buradan diğer masaüstlerine geçiş yapabilir, yeni masaüstü açabilir veya açık olanları kapatabilir, hatta pencereleri masaüstleri arasında taşıyabiliriz. Masaüstlerini isimlendirebilir, arka planlarını da değiştirebiliriz.

Win + D : Masaüstünü göster (bütün pencereleri küçült).

Win + Tab : Görev görünümü (tüm pencereleri ve masaüstlerini görmek)

Win + Ctrl + D: Yeni masaüstü oluşturmak

Win + Ctrl + F4: Masaüstlerinden birini kapatmak (uygulamalar kapanmaz)

Win + Ctrl + < / > (sağ ve sol ok tuşları): Bir önceki/sonraki masaüstüne geçiş.

Win + Alt + < / > : Seçili pencereyi dikey olarak 3 bölüme ayrılmış bölümler arasında taşı.

Win + Alt + v / ^ (alt ve üst ok tuşları): Seçili pencereyi yatay olarak 2 bölüme ayrılmış bölümler arasında taşı.

Ve KDE'deki kısayollar:

Ctrl + F10: Bütün masaüstlerindeki bütün pencereleri küçük resimler halinde listele.

Ctrl + F9: Mevcut masaüstündeki pencereleri küçük resimler halinde listele.

Ctrl + F7: Mevcut uygulamaya ait bütün pencereleri küçük resimler halinde listele.

Ctrl + F12: Masaüstünü göster (bütün pencereleri küçült).

Win + Q: Etkinlikleri yönet

Ctrl + F1: İlk masaüstüne git

Ctrl + F2: İkinci masaüstüne git

Win + W: Genel görünüm (*)

Win + G: Izgara görünümü (*)

WSL ile bash veya python betiklerini çalıştırmak

WSL (Windows Subsystem for Linux) kurulu olduğunu varsayıyorum. Windows'un içinde aslında bash hatta python betikleri çalıştırmak mümkün. WSL tarafında bir linux'umuz varsa ve orada /home/metin gibi bir klasör yapısının altında betik1.sh gibi bash betik dosyamızın olduğunu varsayalım. Bu dosyanın çalıştırma yetkilerinin de olması gerek. Yani

chmod +x betik.sh

gibi. Bunu WSL Linux'a girmeden, Windows terminalden nasıl çalıştırırız?

C:\Windows\System32\wsl.exe /home/metin/betik1.sh

yeterli. Peki bir python betiğimiz varsa nasıl olur? Bunun da yine çalıştırma yetkilerinin olduğunu varsayarsak

C:\Windows\System32\wsl.exe "python3" "/home/metin/betik2.py"

şeklinde çalıştırabiliriz. Alternatif olarak hashbang (shebang) yöntemi olarak python betiklerinin ilk satırına

#!/usr/bin/env python

ve aynı şekilde bash betiklerinin ilk satırı olarak da

#!/usr/bin/sh

eklemek mümkün.

WSL'in linux ortamına ait sanal disk dosyasının konumu da

C:\Users\metin\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState

gibi bir yerde, ext4.vhdx gibi bir dosyada.

pacman ile yaşanan bazı hatalar

Manjaro'da uzun bir sürenin ardından pacman ile güncelleştirmeleri yüklemeye çalıştığımda paketlerdeki PGP imzalarının geçersiz olduğu ve doğrulanamadına dair birkaç hata aldım. Şu sayfadaki öneriler sorunu çözdü:

sudo rm -fr /etc/pacman.d/gnupg
sudo pacman-key --init
sudo pacman-key --populate archlinux manjaro
sudo pacman-key --refresh-keys

Başka bir sorun, pacman ile güncelleme yaparken kilitlenen veya başka bir sebeple beklenmedik bir şekilde kapanan/yeniden başlayan sistemlerde veritabanı kilit dosyasının silinmemesinden dolayı güncellemelerin tekrar başlayamaması. Bu durumu "unable to lock database" ya da "veritabanı dosyası kilitlenemedi" gibi hatalarla görüyoruz. Bu durumda /var/lib/pacman/db.lck konumundaki kilit dosyasını silmek işimizi görür.

sudo rm -f /var/lib/pacman/db.lck

Bazen de yüklü paketlerden birinin depodaki sürümden daha yeni olduğuna dair bir mesaj görüntülenir.

uyarı: python-pyqt5: yerel depodaki paket (5.15.6-7.1) extra deposundaki paketten 

(5.15.6-7) daha güncel

yapılacak bir şey yok

Bu durumda Manjaro Forum'da şu önerilmiş:

sudo pacman -Syyuu

nslookup kullanımı

Bir FQDN'in isim çözümlemesi için

nslookup google.com

Bu isim çözümlemesini belli bir DNS sunucunun yapması için

nslookup google.com 1.1.1.1

Bu alan adına ait özel bir tip isim çözümlemesi için

nslookup -type=ns google.com
nslookup -type=txt google.com 1.1.1.1

Alan adlarını sorgunun sonuna eklememek için (varsayılan olarak içinde en az bir nokta geçen ama nokta ile bitmeyen bütün sorgulara DNS alan adı listesindeki alan adları eklenir)

nslookup -nosearch metin

Bunlar hem Windows'da hem Linux'ta geçerli.

Linux'ta beklenmeyen kapanmalar - 2

Daha önce şu yazımda Linux'ta beklenmeyen kapanmalar ile ilgili bulduklarımı paylaşmıştım. Biraz daha farklı bir yöntem olarak systemd birim dosyası ile beklenmeyen kapanmaların tespit edilmesi yöntemine journal loglarını da dahil ettim, bu konuyu da paylaşmak istedim.

Hedefimiz şu:

1. İşletim sistemi düzgün kapatılırken /root/graceful_shutdown dosyasını yazsın. İçi boş bir dosya. Sadece varlığı, kapanmanın düzgün olduğunu gösterecek. Kapatılırken de journal'a "graceful shutdown" yazsın.

2. Açılışta ilk adımda oluşturulan /root/graceful_shutdown dosyasının varlığı kontrol edilsin. Dosya varsa silinsin (çünkü kapatılırken tekrar oluşturulacak) ve journal'a "startup found graceful shutdown" yazsın.

3. Açılışta /root/graceful_shutdown dosyası yoksa journal'a "startup did not find graceful shotdown" gibi bir mesaz yazsın.

Bu hedef doğrultusunda 3 systemd birim dosyası oluşturacağız. Konumumuz /etc/systemd/system klasörü. İlk dosyamız birinci hedefimiz ile ilgili. Aşağıdaki dosyayı /etc/systemd/system/set_gracefulshutdown.service olarak kaydedelim.

[Unit]
Description=Set flag for graceful shutdown
DefaultDependencies=no
RefuseManualStart=true
Before=shutdown.target

[Service]
Type=oneshot 

ExecStartPre=logger "graceful shutdown"
ExecStart=/bin/touch /root/graceful_shutdown

[Install]
WantedBy=shutdown.target

İkinci hedefimiz için aşağıdaki dosyayı /etc/systemd/system/check_graceful.service olarak kaydedelim.

[Unit]
Description=Check if previous system shutdown was graceful
ConditionPathExists=/root/graceful_shutdown
RefuseManualStart=true
RefuseManualStop=true

[Service]
Type=oneshot
RemainAfterExit=true

ExecStartPre=logger "startup found graceful shutdown"
ExecStart=/bin/rm /root/graceful_shutdown

[Install]
WantedBy=multi-user.target

Üçüncü hedefimiz için de aşağıdaki dosyayı /etc/systemd/system/check_notgraceful.service konumuna kaydedelim. Bunun yegane amacı sistem loglarına bir düzgün kapanma olmadığını yazabilmek.

[Unit]
Description=Detect unexpected shutdown
ConditionPathExists=!/root/graceful_shutdown
RefuseManualStart=true
RefuseManualStop=true

[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=logger "startup did not find graceful shutdown"

[Install]
WantedBy=multi-user.target

Sonra bunları etkinleştirmek için şu adımları uygulayalım:

# sudo systemctl daemon-reload
# sudo systemctl enable set_gracefulshutdown
# sudo systemctl enable check_graceful
# sudo systemctl enable check_notgraceful

İşletim sistemi açıldıktan sonra da bir önceki kapanışın beklenmeyen bir kapanış mı olduğunu anlamak için check_graceful hizmetinin başlayıp başlamadığını kontrol edebiliriz:

# systemctl is-active check_graceful

ya da journalctl ile son 3 günlük loglarda graceful geçip geçmediğine bakabiliriz:

# journalctl --since "3 days ago" -g graceful

Galiba oldu. logger yerine systemd-cat kullanılabilir. Bu komutun -p ile mesajın öncelik seviyesi de belirtilebilir:

# echo "No graceful_shutdown file found" | systemd-cat -p info

gibi.

Bu dosyaları oluşturuken yaşanabilecek muhtemel yazım hatalarını tespit edebilmek için systemd-analyze'ın verify komutunu da kullanabiliri.

# systemd-analyze verify /etc/systemd/system/check_notgraceful.service

 [12/2023]

---

[1] https://access.redhat.com/articles/2642741

[2] https://www.suse.com/support/kb/doc/?id=000020272

openssh ile ilgili xz-utils arka kapısı hakkında (CVE-2024-3094)

Hikaye uzun. Uzun lafın kısası, bir Microsoft yazılımcısı, Andres Freund, OSS-Security'ye bulduğu arka kapı ile ilgili bir eposta gönderiyor ve olay patlıyor.

Benim için önemli olan etkilenen sistemler nasıl tespit edilmeli, hangi sürümlerden korunmalı.

xz-utils paketinin sürümlerine bakmak gerek.

xz --version

ile sürüm kontrolü yapılabilir. 5.6.0 ve 5.6.1 sürümleri kaçınılması gereken sürümler. Ayrıca Debian türevlerinde:

apt list installd xz-utils

Fedora türevlerinde

rpm -q xz

ile sürüm numaraları bulunup yükseltilebilir.

Çevremdeki kurulumlardan birinde 5.6.1'e rastladım:

xz --version ile görüntülenen sürüm numarası 5.6.1 olmasına rağmen asıl sürüm numaram 5.6.1-2, ki bu da arka kapıya karşı yamalanış sürüm. Sonraki satırda pacman -Q xz ile bunu doğruladım. Benim xz güncellemelerim nasıl olmuş diye bakmak istedim:

grep "xz " /var/log/pacman.log

çıktı şöyle oldu:

[2024-03-09T23:57:14+0300] [ALPM] upgraded lib32-xz (5.4.6-1 -> 5.6.0-1)
[2024-03-31T01:08:10+0300] [ALPM] upgraded xz (5.6.0-1 -> 5.6.1-2)
[2024-03-31T01:08:13+0300] [ALPM] upgraded lib32-xz (5.6.0-1 -> 5.6.1-2)

Demek ki Manjaro, 31 Mart'ta yamayı yayınlamış. Debian ve Fedora ana dağıtımlar sorunlu paketleri depolarına dahil etmediği için hala güvenli olarak görüldüler. Ancak "bleeding edge" olarak nitelenen "rolling distro"lar için çok olumlu nitelendirmeler kullanılmadı. Rolling distro deyince de ilk akla gelen Arch Linux. Ama şu sayfada denmiş ki; Arch Linux xz paketini openssh ile ilişkilendirmediği için Arch Linux bu saldırıdan etkilenmemiş.

Eğer sistemdeki sürümü eski sürüme downgrade etmek isteseydim /var/cache/pacman/pkg altındaki paket önbelleğindeki sürümleri kullanabilirdim:

sudo pacman -U /var/cache/pacman/pkg/xz-5.4.4-1-x86_64.pkg.tar.zst

Bundan sonra bu paketin kontrolsüz olarak güncellenmesini engellemek için ise /etc/pacman.conf dosyasına şu satırı eklemem gerekecekti:

IgnorePkg = xz

Alternatif olarak manjaro-downgrade paketi ile bu işin otomatize edilmesi de anlatılmış, ama sisteme bir paket daha kurmak istemedi canım, nedense.

---
https://www.openwall.com/lists/oss-security/2024/03/29/4

https://archlinux.org/news/the-xz-package-has-been-backdoored/

https://wiki.manjaro.org/index.php?title=Downgrading_packages 

https://snyk.io/blog/the-xz-backdoor-cve-2024-3094/

https://www.logpoint.com/en/blog/emerging-threats/xz-utils-backdoor/#
https://www.reddit.com/r/linux/comments/1bqt999/backdoor_in_upstream_xzliblzma_leading_to_ssh/
https://www.youtube.com/watch?v=0pT-dWpmwhA

https://forum.manjaro.org/t/xz-package-contains-a-vulnerability/159028/20

https://boehs.org/node/everything-i-know-about-the-xz-backdoor

https://www.wired.com/story/jia-tan-xz-backdoor/

archlinux kurulumu

Benim kurulum adımlarım şöyle:

Öncelikle BIOS veya UEFI kipte mi kuracağımızı belirlememiz lazım. Sanal makineye kuruyorsak vmx dosyasının içinde firmware="efi" satırının olmasına dikkat etmek lazım.

Zamanla değişmekle birlikte bugünlerlde Archlinux CD'si (veya USB) ile boot edilen bir makinede BIOS kipinde aşağıdaki gibi bir açılış ekranı karşılar bizi.

UEFI kipinde açılan bir makinede ise Archlinux'un açılış ekranı aşağıdaki gibi olur.

Açtıktan sonra UEFI modda olup olmadığını doğrulamak için [1]

cat /sys/firmware/efi/fw_platform_size

ya da şu yazıda belirtilen yöntemler kullanılabilir. Bu satır 64 dönüyorsa sistemimiz şu anda 64 bitlik UEFI ile açılmıştır. 32 dönüyorsa 32 bitlik UEFI ile açılmıştır. Dosya bulunamadı hatası alıyorsak sistemimiz BIOS kipinde açılmıştır.

ISO dosyası (veya USB) ile sistemi açtıktan sonra Türkçe klavye alışkanlıkları olan birisi olarak öncelikle klavye düzenimi alışık olduğumuz düzene ayarlamak isterim. Çalıştırmam gereken komut şu:

loadkeys trq

Bu komut sonunda ş ve ğ gibi karakterler doğru görüntülenmeyecektir ama en azından nokta, virgül ve / karakterleri alışık olduğumuz yerlerde olacaktır.

İlk iş disk bölümlendirmesi. Önce diskimiz ne şekilde algılanmış bakmak için 

lsblk

kullanabiliriz. Eski SATA bağlantılı (SSD'ler dahil) diskler sda veya sdb gibi, NVMe diskler de nvme0n1 veya nvme0d2 gibi görüntülenir. Disk bölümlendirmesi için fdisk, gdisk veya cfdisk kullanılabilir. Ben 4 bölümden oluşan şöyle bir yapı kullanacağım (NVMe diskler için bu isimleri uygun karşılıkları ile değiştirerek diğer adımları aynen uygulayabiliriz):

sda1    EFS     512 MB             EF00     fat32
sda2    swap    1xRAM veya 2xRAM   8200     swap
sda3    boot    1 GB               8300     ext4, btrfs, xfs, jfs
sda4    root    isteğe göre        8300     ext4, btrfs, xfs, jfs

3. sütundaki değerler EFS ve boot gibi bölümler için önerilen asgari boyutlar. Swap için eski alışkanlık 2xRAM gibi bir değerdi. Ama NVMe disklerin çıkışıyla birlikte bunu 1xRAM gibi bir düzeye indirebileceğimizden bahsedilmiş. Yeni sistemlerde artık hazırda bekletme (hibernate) kullanılmıyor, s2idle (veya s0) var. Bunun için bu değerler yeterli. Ama hazırda bekletme kullanılacaksa kabaca toplam RAM miktarının 2.5 katı gibi bir alan gerekebilir. 4. sütundaki değerler daha önce bahsettiğim gibi bölüm kodları. Bir EFI bölümünün kodu EF00 olmazsa bazı linux dağıtımları kabul etmiyor.

Bu bölümlendirmeyi oluşturduktan sonra biçimlendirmeye geçelim. EFS (EFI system partition) fat olmalı.

mkfs.vfat -F32 /dev/sda1

Sırayla gidelim, swap bölümü için mkfs değil mkswap kullanmalıyız:

mkswap /dev/sda2

Boot bölümü ext4 olabilir:

mkfs.ext4 /dev/sda3

Root bölümü de ext4 olabilir.

mkfs.ext4 /dev/sda4

Şimdi bu bölümleri bağlayalım. Disk yapısını oluşturmak için arada mkdir ile gereken klasörleri oluşturuyorum:

mount /dev/sda4 /mnt
mkdir /mnt/boot
mount /dev/sda3 /mnt/boot
mkdir /mnt/boot/efi
mount /dev/sda1 /mnt/boot/efi
swapon /dev/sda2

Şimdi bir Archlinux kurulumu yapmak için gereken temel paketleri kuracağız. Bunu yapmak için Archlinux'a özel pacstrap komutunu kullanacağız.

pacstrap -K /mnt base linux linux-firmware

[1]'de temel kurulum için bu 3 paketin yeterli olduğu belirtilmiş. Bu paketlerin toplamı yaklaşık 500 MB civarında olduğu için biraz zaman alacak. (Sanal makine kurulumlarında linux-firmware paketine gerek yok, bu durumda boyut 200+ düşer) Bu komuttaki -K anahtarı linux anahtarlarını ayarlamak için. Bir sebeple bu adım atlarnırsa veya sorun olursa

pacman-key --init
pacman-key --populate

ile anahtarlar yeniden ayarlanabilir. Oluşturulan disk bölümlerimiz ile ilgili bilgiyi fstab dosyasına yazmak için şu komutu kullanabiliriz:

genfstab -U -p /mnt >> /mnt/etc/fstab

Hedef sistemimiz artık /mnt altında oluştuğu için buradaki fstab dosyasına yazıyoruz. Buradaki -U anahtarı fstab dosyasına disk bölümlerini yazarken UUID'ler ile yazmasını, -p ise pseudo bağlantı noktalarını hariç bırakmasını belirtmek için. Ancak -p anahtarının varsayılan olduğu ve açıkca belirtilmesine gerek olmadığı söylenimş [2].

Bu aşamadan sonra canlı linux ortamından hedef Archlinux kurulumuna ait diğer ayarları yapabilmek için arch-chroot ile ortamımızı değiştireceğiz.

arch-chroot /mnt

Burada yapmak isteyeceğimiz işlemlerden biri hedef sistemin zaman dilimini değiştirmek. Varsayılan kurulumlarda ABD zaman dilimleri geliyor. Bunu Türkiye zaman dilimine göre ayarlamak için /usr/share/zoneinfo/ konumundaki zaman dilimlerinden birine sembolik link oluşturmamız gerek.

ln -sf /usr/share/zoneinfo/Turkey /etc/localtime

-s sembolik link (diğer seçenek hard link), -f ise /etc/localtime varsa üzerine yazmak istediğimizi belirtiyor. Hangi koşullarda tam bilmiyorum, ama bazen bu dosya olabiliyor.

Linux'ta genel kural donanım saati UTC (merkezi saat) olarak ayarlanır. Eğer değilse bunu ayarlamak için

hwclock    --systohc --utc

kullanabiliriz. Bu aşamadan sonra bazı yerelleştirme ayarları ile devam edebiliriz. Ama kullanacağımız editörü henüz yüklemedik. Seçeneklerimiz nano, vi, vim veya neovim. Birini yükleyelim. Ben neovim ile devam ediyorum:

pacman -S neovim

Yerel ayarlarımızı Türkiye'ye göre ayarlamak için /etc/locale.gen dosyasının içindeki tr_TR ile başlayan (uygun görülen) satırların başındaki # karekterini silmemiz gerek. Ben sadece

# tr_TR.UTF-8

satırını

tr_TR.UTF-8'e

dönüştürüyorum. Sonrasında 

locale-gen

çalıştırmak gerek. Benzer şekilde /etc/locale.conf dosyasına da bir satır ekleyelim:

echo LANG=tr_TR.UTF-8 > /etc/locale.conf

Bir de yeni bir ortam değişkeni oluşturalım.

export LANG=tr_TR.UTF-8

Bu son 3 adımın her birinin gerekliliğini bilmiyorum, ama [1]'de yazılmış.

Bir sonraki adımımız makine ismimizi belirlemek.

echo "archbox" > /etc/hostname

Eğer istenirse ağ yöneticisi olarak network manager kurulabilir (ayrıca [4])

pacman -S networkmanager nm-connection-manager network-manager-applet

Kurulmadıysa aşağıdaki kurulum sonrası adımlarda bazı yöntemler var.

Hedef sistemimizdeki root kullanıcısının parolasını belirleyelim:

passwd

2 kez aynı parolayı yazmayı isteyecek. Kendimize yeni bir kullanıcı da oluşturalım. Genel eğilim, bu kullanıcının da yetkili bir kullanıcı (wheel grubu üyesi) olması. Bu amaçla aşağıdaki gibi bir komuta ihtiyacımız olacak

useradd -mg users -G wheel,power,storage -s /bin/bash metin

ve bu kullanının şifresini belirleyip (belirlemezek kullanıcı devre dışı gelir) şifre süresini sınırsız yapalım (kötü bir örnek mi?). Linux kullanıcı yönetimi için tıklayın.

passwd metin
chage -d 0 metin

Henüz sudo kurmadık. Bunun yanı sıra ihitiyaç duyulabilecek birkaç paket daha var:

pacman -S sudo grub efibootmgr intel-ucode os-prober zsh

Şimdi wheel grubuna yetkilerini verelim. Önce visudo komutunun ihtiyaç duyduğu varsayılan editörü belirleyelim:

export EDITOR=nvim

sonra

visudo

komutunu çalıştırarak gelen ekranda

#%wheel ALL=(ALL:ALL) ALL

satırının başındaki # işaretini silerek dosyayı kadedip çıkalım.

Son adımlara geldik. Önce grub'ı ayarlayalım:

grub-install --target=x86_64-efi --efi-directory=/boot/efi

Sonra grub.cfg dosyalarını oluşturalım. Gerçek yeri neresi, tam bilemiyorum ama 2 konum için de ayrı ayrı oluşturmayı tercih ediyorum.

grub-mkconfig -o /boot/grub/grub.cfg

grub-mkconfig -o /boot/efi/EFI/arch/grub.cfg

Son adım, initramfs dosyasının oluşturulması. Bunu mkinitcpio ile yapacağız. Ama bunun için bir preset'e ihtiyacımız var. pacstrap ile kurduğumuz linux paketi bize /etc/mkinitcpio.d klasörünün atında linux.preset dosyasını verdi. Bunu -p linux yazarak, veya sadece -P (bütün presetler için oluştur) diyerek yapabiliryoruz. Her rehberde bahsedildiği için bunu yapmaya alışmışım. Ama aslında initramfs dosyasının oluşturulması zaten pacstrap ile kurulan her çekirdek paketinden sonra otomatik yapıldığı için aşağıdaki adım gerekli değil.

mkinicpio -p linux # gerekli değil

İşlem tamam. arch-chroot ortamından çıkalım.

exit

Tüm bağladığımız disk bölümlerinin bağlantılarını keselim. 

umount -R /mnt

ve sistemi tekrar başlatalım.

reboot

Tekrar başlayınca oluşturduğum metin kullanıcısıyla oturum açabileceğim. Ama henüz bir masaüstü ortamı yüklemedik. Bu da başka bir yazıya kalsın.

Kurulum Sonrası adımlar

Kurulumdan sonra eğer Network Manager gibi bir ağ yöneticisi kurulmadıysa bilgisayar otomatik IP almayabilir. Bu durumda /etc/systemd/network klasörünün altında

20-wired.network
25-wireless.network

dosyaları içine DHCP için

[Match]
Name=wlp2s0

[Network]
DHCP=yes
IgnoreCarrierLoss=3s

sabit IP için

[Match]
Name=enp1s0

[Network]
Address=10.1.10.9/24
Gateway=10.1.10.1
DNS=10.1.10.1

satırları eklenebilir [3].

zsh kurduk, ama ayarlamadık. Aslında zsh kurulumunu useradd adımından önce yaparsak useradd adımında /bin/bash yerine /bin/zsh diyerek bunu doğrudan devreye alabiliriz. Ama yapmadıysak da şu yazımdaki adımlarla yapılabilir.

Tekrar başlattıkan sonra 

grub>

gibi bir ekranda kalıyorsa grub.cfg dosyasını bulamıyor olabilir. CD/USB ile canlı ortamda açarak grub-mkconfig adımını tekrarlamak gerek. UEFI sistemlerde bile /boot/grub/grub.cfg olmasına dikkat etmek gerek.

Kurulan sistemdeki klaveye düzeni Türkçe olmazsa Türkçeleştirmek için

localectl set-keymap trq

kullanılabilir.

Network Manager kurduktan sonra systemd-networkd hizmetini devre dışı bırakmak gerek. dhcpcd ve systemd-resolved hizmetleri de aynı anda çalışmamalıdır [4].

---

[1] https://wiki.archlinux.org/title/installation_guide
[2] https://man.archlinux.org/man/genfstab.8
[3] https://wiki.archlinux.org/title/Systemd-networkd

[4] https://ejmastnak.com/tutorials/arch/network-manager/

manjaro release

Manjaro'da manjaro-release adında bir paket var. Bu paketin yegane amacı /etc/lsb-release dosyasını güncellemek. lsb-release dosyasında ne var? Manjaro kurulumunun sürüm numarası. Manjaro bir rolling release olmasına rağmen yine de sürüm numaraları ve kod isimleri var. Örneğin bugün benim /etc/lsb-release dosyamın içerği şöyle

DISTRIB_ID="ManjaroLinux" 
DISTRIB_RELEASE="23.1.3" 
DISTRIB_CODENAME="Vulcan" 
DISTRIB_DESCRIPTION="Manjaro Linux"

Bu dosyanın sahibini

$ pacman -F /etc/lsb-release

core/manjaro-release 23.1.3-1 [kurulu] 
    etc/lsb-release

veya [1]

$ pacman -Qo /etc/lsb-release

ya da

$ pkgfile /etc/lsb-release

core/manjaro-release 

şeklinde sorgulayabilirim. Çıkan sonuç manjaro-release paketi. Manjaro-release paketinin sürümü de lsb-release dosyasında DISTRIB_RELEASE değişkenin değeri olan 23.1.3:

$ pacman -Qs manjaro-release
local/manjaro-release 23.1.3-1 
    Manjaro's release definition

Tam tersi sorgulama ile manjaro-release paketi sisteme hangi dosyaları getiriyor diye bakmak istersem de

$ pacman -Ql manjaro-release

manjaro-release /etc/
manjaro-release /etc/lsb-release

sadece bu dosya görünüyor.

Buna göre sistem ne zaman güncellenmiş, hangi sürümden hangi sürüme yükseltilmiş bulmak için

$ grep 'manjaro-release' /var/log/pacman.log

gibi bir komut kullanılabilir.

----

[1] https://www.reddit.com/r/archlinux/comments/dmdl6c/where_is_the_mighty_pacman_fs/

Could not open /dev/vmmon

Linux'ta VMware Workstation Player kullanırken, çekirdek güncellemeleri sonrasında aşağıdaki gibi bir hatayla karşılaşıyorum ve sanal makineler açılmıyor.

Şu adresin yardımıyla çözümü aşağıdaki gibi buldum:

$ sudo vmware-modconfig --console --install-all
$ sudo modprobe -a vmw_vmci vmmon

Bir sonraki açılışta herşey normal.

LUKS ile şifrelenmiş diskleri açmak

Linux'u boot ettiğimiz disk şifreli değil. Ancak elimizde başka bir disk var, şifreli. Bu diski nasıl açarız? Sorumuz bu.

Diski taktıktan sonra lsblk --fs ile baktığımda FSTYPE sütununda gözüken crypto, diskin bir şifreleme kullandığını gösteriyor. Benim durumumda bu sdb1 olarak gözüküyordu.

$ sudo cryptsetup open /dev/sda3 luksrecoverytarget --type luks

kullanarak şifrelenmiş diske ait bir LUKS container'i oluşturalım. Bu sonrasında bize passphrase'imizi (şifrelenmiş birime ait parolamız) sorulacak. Doğru parolanın girilmesinin ardından /dev/mapper/luksrecoverytarget adında bir container'ımız olacak. Bu container'ı da mount etmek için

$ mount /dev/mapper/luksrecoverytarget /mnt/plain

kullanabiliriz. Yukarıdaki komut /mnt/plain'in var olduğunu varsaydı. İşlemer bittikten sonra önce unmount

$ umount /mnt/plain

ardından container'ı sonlandırmak gerek:

$ sudo cryptsetup close luksrecoverytarget

 ---

https://unix.stackexchange.com/questions/445652/how-to-mount-and-de-encrypt-a-luks-encrypted-partition-to-recover-files

https://www.baeldung.com/linux/check-disk-encryption

Linux terminali öğrenmek

 Linux terminal komutlarını öğrenmek için bulduğum güzel bir site var;

https://devopschops.com/blog/games-for-learning-linux/

Bu sitenin içinde denediğim ve eğlenceli bulduğum iki bağlantı ise

Command Challenge

ve

Sad Servers (çözümler için bu ve şu siteler güzel)

boş vakitlerde denenebilir.

2025-04-17 Ek: https://explainshell.com/ Bu da terminalde çalışan gizemli komutları anlamaya yardımcı bir site.

linux'ta xargs komutu

xargs komutu, pipeline'dan veri almayı desteklemeyen komutlara bu özelliği kazandırmak için kullanılabilir. Hiçbir parametre kullanmadığımızda her biri yeni bir satıra yazılmış öğeleri boşluk ile ayrılmış şekilde aynı satıra yazar. Örnek olarak sehirler.txt dosyamızda şehir isimleri, her satırda bir tane olacak şekilde yazılmış olsun.

$ cat sehirler.txt

Bursa
Ankara
Kocaeli
Antalya
Adana

Bu şehir isimlerini tek satırda, boşluk ile ayrılmış şekilde yazmak için

$ cat sehirler.txt | xargs

kullanabiliriz. Bu elbette, xarg komutunun tüm yeteneklerini gösterecek bir örnek değil.

Mevcut klasörde dosya1.txt, dosya2.txt ve dosya3.txt adında 3 dosyamız olsun. Bunların içlerinde kaç kelime ve satır var, görmek istiyoruz.

$ ls dosya*.txt | wc

çalışmaz. Çünkü wc, pipeline input'u desteklemez. Bunu çalışır hale getirmek için

$ ls dosya*.txt | xargs wc

yapabilriz. Ya da bir log klasöründe 1 haftadan eski log dosyalarını silmek istiyoruz diyelim. Önce bu dosyaları bulalım:

$ find /var/log/ -type f -mtime +7

Bu komut ile bulunan dosyaları silmek için 

$ find /var/log/ -type f -mtime +7 | rm

işe yaramaz, çünkü rm stdin'den veri okumaz. Evet, find'in -exec parametresi ile de çözülebilir, ama örnek olması açısından şöyle bir kullanım xarg'ı açıklayabilir:

$ find /var/log -type f -mtime +7 | xargs rm

sehirler.txt dosyasının içeriğinin tek satırda yazıldığı örnekteki gibi, yukarıdaki örnek de aslında şuna eşdeğer bir işlem yapar:

$ rm log01.txt log02.txt log03.txt ...

Her log dosyasını ayrı bir rm komutuyla silmek için -n 1 kullanabiliriz

$ find /var/log/ -type f -mtime +7 | xargs -p -n 1 rm

Bu komut da şuna eşdeğer bir işlem yapar:

$ rm log01.txt
$ rm log02.txt
$ rm log03.txt
...

Bu dosyaları başka bir yere taşımak için

$ find /var/log/ -type f -mtime +7 | xargs -I % mv % /backup

Burada xargs, % yerine dosya isimlerini yerleştirir. -I parametresi, gizli -n 1 gibi davranarak aslında mv komutunun her dosya için ayrı ayrı çalıştırılmasını sağlar. Yani şuna eşdeğer bir işlem yapar:

$ mv log01.txt /backup
$ mv log02.txt /backup
$ mv log03.txt /backup
...

Dosya isimlerinde alfanümerik olmayan karakterlerin bulunması durumunda dosya isimlerini null karakteri ile ayırma şansımız var. Hem find komutunun dosya isimlerini null ile ayırt etmesini (-print0), hem de xargs komutunun bu karakterle ayrım yapmasını (-0) söyleyebiliriz:

$ find /var/log/ -type f -mtime +7 -print0 | xargs -0 rm

Paralel işlem yapılması ihtiyacı olan durumlar için xargs'ın -P gibi bir parametresi var.