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.

Sysinternals handle

Birçok Sysinternals aracının içinde en az kullandığım olabilir, handle. Çünkü daha çok process explorer içinden aynı işi yapıyordum. Son zamanlarda daha fazla handle kullanmaya başladım.

İşletim sistemleri, uygulamaların dosya sistemi, portlar vs gibi kaynaklar üzerinde kullandıkları kaynakları bir kimlik numarası (buna handle denir, sanıyorum Türkçe'ye tutamaç/kulp gibi çevrilebilecek ama teknik olarak işleç olarak ifade edilen bir terim) ile takip eder. Bir dosya bir uygulama tarafından açıldığında, aynı anda bu dosyaya ihtiyaç duyabilecek başka programlarında dosyaya yazıp bozmaması için bu dosyayı kilitler ve ikinci gelene "bu dosya abc programı tarafından kullanılıyor" diye bir mesaj görüntüler. Çoğu zaman çok faydalı olan bu işleyiş bazen sorunlara yol açabilir. Dosyayı normal yollardan açan uygulama beklenmedik bir şekilde sonlanırsa ona ayrılan erişim yetkisi hiç sonlanmamış olabilir ve diğer uygulamaların (hatta tekrar başlatılan uygulamanın kendisinin) o dosyaya erişimi engellenebilir.

Böyle durumlarda bir "aracı"nın müdahale etmesi gerekebilir. İşte handle, bu amaçla açık kalan erişimleri sorgulamaya ve sonlandırmaya yarayan küçük ama faydalı bir uygulamadır. handle ve handle64 olarak 2 farklı mimari için sürümleri mevcuttur. 2024'ün sonlarına doğru artık 32-bitlik sistemler görmek pek mümkün değil, ama 32-bitlik sürüm olan handle.exe'yi, bütün 32-bitlik uygulamalar gibi 64-bitlik bir Windows'da çalıştırmak mümkün. Lakin bazı dezavantajları olur; sadece 32-bitlik süreçlerin açtığı dosyaları sorgulayabilmek, sadece 32-bitlik süreçlerin erişebileceği 4 GB bellek adres alanına erişebilmesi gibi. Bu sebeple sadece 64-bitlik sürümü kullanıyorum.

Genellikle yükseltilmiş ayrıcalıklar ile çalışmayı sever, bu arkadaş. Bu sebeple açtığım terminal penceresinin yükseltilmiş ayrıcalıklara sahip olduğunu varsayıyorum. Tek başına çalıştırınca her süreç için açık kaynakların işleçlerini tek tek listeler. Bu çoğu zaman yapmamamız gereken bir şey. Onun yerine hedefimiz hakkında biraz daha bilgi vermek gerek. Örneğin, işleci (handle) oluşturan uygulamanın adı, süreç numarası veya erişimde sorun yaşadığımız dosyanın adı veya yolu olabilir.

handle64 winword
handle64 -p 11483
handle64 C:\Users\metin\Documents\Liste.docx

Bunların sonucunda bir veya birkaç tane işleç listelenir. Bu işleçlerin bir veya daha fazlasını kapatmak için ise hem işleç numarasını (-c ile) hem de süreç numarasını (-p ile) kullanmak gerekir.

handle64 -c 22AC -p 11483

Bu gibi araçlar eski günlerde daha çok USB belleklerin "çıkarılamaması" gibi sorunların çözümü için işe yarardı.

Tabi henüz geçerliliğini kaybetmemiş bir sürece ait işlev(ler)i zorla kapatmak en azından sürecin artık ilgili kaynağa erişememesine, bazen veri kaybına hatta sistem süreçlerine ait işleçlerin kapatılması durumunda sistem kararsızlığına (mavi ekranlar, beklenmedik sonlanmalar vs) sebep olabilir.

DHCP sunucu ve Powershell

Çalışan bir DHCP sunucuya rezervasyon (ayırma) ve policy (ilke) eklemek istiyorum. Etkin bir havuz var ve kiralamalar da düzgün çalışıyor. Bununla birlikte DHCP'den yapılacak rezervasyonlarla ilgili elimde CSV dosyasından alınmış şöyle bir liste var:

$rsv = Import-Csv -Path .\reservations.csv
$rsv
MAC               HOST           IPAd
---               ----           ----
xx-xx-xx-yy-yy-yy bilgisayar01  192.168.22.150
xx-xx-xx-yy-yy-yy bilgisayar02  192.168.22.151
... 

Öncelikle bu MAC-IP ilişkisi için birer rezervasyon oluşturalım.

$rsv | % { Add-DhcpServerv4Reservation -ComputerName dhcpserver 

    -ScopeId "192.168.22.0" -IPAddress $_.IPAd -ClientId $_.MAC 

    -Name $_.HOST -Description -$_.HOST -Type Dhcp }

Daha sonra da aynı $rsv dizisini kullanarak bir politika oluşturalım.

Add-DhcpServerv4Policy -ComputerName dhcpserver -Name "WifiPolicy" -ScopeId "192.168.22.0" 

    -Condition OR -MacAddress EQ,xx-xx-xx-yy-yy-yy,...

Buraya bütün MAC adreslerini en sona tek seferde ekleyebilir, ya da WifiPolicy altına birden fazla koşul girebiliriz. Bu komut sonunda ilke etkin olarak oluşturulur. Oluşturduktan sonra devre dışı kalmasını istersek -Enabled $false ile bunu belirtmeliyiz.

DhcpServer modülü ile gelen 100'den fazla cmdlet var. DHCP sunucuyu sadece powershell'den yönetmek ve izlemek bile mümkün. Tüm komut listesi için

Get-Command -Module DhcpServer

Sonrasında DHCP olaylarını incelemek istersek

Get-WinEvent -Computername DhcpServer 

    -FilterhashTable @{Logname="Microsoft-Windows-Dhcp-Server/Operational";StartTime=(Get-Date).AddHours(-8)}

Bir filter'ımız varsa izin verilmeyen istemciler ile ilgili olay kayıtları "Microsoft-Windows-Dhcp-Server/FilterNotifications" günlüğüne düşer. Görmek için

Get-WinEvent -Computername DhcpServer

    -FilterHashtable @{Logname="Microsoft-Windows-Dhcp-Server/FilterNotifications";StartTime=(Get-Date).AddHours(-8)}

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.