schtasks.exe ile zamanlanmış görevler

Bir RDP oturum açması sırasında çalışacak bir görev oluşturmak

    schtasks /Create 
        /TN "MyEventTask" 
        /SC ONEVENT 
        /EC "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" 
        /MO "*[System[Provider[@Name='Microsoft-Windows-TerminalServices-RemoteConnectionManager'] and (EventID=1149)]]" 
        /TR "powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\1149.ps1"

Kullanıcı oturum açsa da açmasa da çalışacak bir görev için

    schtasks /Create 
        /TN "MyEventTask" 
        /SC ONEVENT
        /EC "Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational" 
        /MO "*[System[Provider[@Name='Microsoft-Windows-TerminalServices-RemoteConnectionManager'] and (EventID=1149)]]" 
        /TR "powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\1149.ps1" 
        /RU SYSTEM 
        /NP

Mevcut görevlerin hepsini export etmek için

schtasks /Query /XML /TN "*"

Sonra bu xml dosyalarından tekrar görevler oluşturmak için

dir *.xml | % { schtasks /Create 
    /XML $_.FullName 
    /TN "$_.Name.replace('.xml','')"
    /RU "new_username"
    /RP "new_password"

Bir görev nesnesini parola kaydetmeden oluşturmak için /NP anahtarı,

Tam tersi, parolayı belirlemek için /RP <parola>

Görevin yetki seviyesini belirlemek için /RL <LIMITED|HIGHEST>

ONSTART, ONLOGON, ONEVENT olayları için rastgele bir gecikme ayarlamak için ise /DELAY mmmm:ss kullanılabilir.

---

https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/schtasks-query

Powershell ile ileri seviye zamanlanmış görevler

Zamanlanmış görevler sadece belli periyotlarda değil, belli olayların ardından çalışacak şekilde de oluşturulabiliyor. Ama bunu Powershell ile yapmak biraz meşakkatli. Oturum açma sonrasında ve bilgisayarın başlangıcında çalıştırılacak görevler için trigger nesneleri aşağıdaki gibi oluşturulabiliyor:

$trig1 = New-ScheduledTaskTrigger -AtLogon

$trig2 = New-ScheduledTaskTrigger -AtStartup

Ancak örneğin uzakmasaüstü bağlantısı ardından (TerminalServices-RemoteConnectionManager/Operational / Id:1149) çalışacak bir trigger'ın oluşturulması şu şekilde:

$class = Get-CimClass -Class "MSFT_TaskEventTrigger" -ClassRoot "Root/Microsoft/Windows/TaskScheduler"

$trig3 = $class | New-CimInstance -ClientOnly

$trig3.Subscription = "<QueryList>`

<Query>`<Select Path='Microsoft-Windows-TerminalServices-RemoteConnectionManager/Operational'>`

    *[System[Provider[@Name='Microsoft-Windows-TerminalServices-RemoteConnectionManager'] `

    and (EventID=1149)]]</Select></Query></QueryList>"

(satırlar ` karakteri ile bölünmüştür) ile, ve görev oluşturulması/değişikliğinde çalışacak görevin trigger'ı

$trigger1 = Get-CimClass -ClassName "MSFT_TaskRegistrationTrigger" -Namespace "Root/Microsoft/Windows/TaskScheduler"

ile yapılabiliyor.

Bir powershell görevinin gizli oluşturulması için

$settings = New-ScheduledTaskSettings -Hidden

kullanılabilir. Belli bir kullanıcının masaüstü ile etkileşime geçebilmesi için

$principal = New-ScheduledTaskPrinciple -UserId "makine\kullanidi" -LogonType Interactive

seçilmeli. LogonType alanı için Group, Interactive, InteractiveOrPassword, None, Password, S4U, ServiceAccount gibi değerler var. Bir görevin kullanıcı oturum açsın ya da açmasın çalışmasını sağlamak için S4U kullanılabilir.

$principal = New-ScheduledTaskPrinciple -UserId "makine\kullanidi" -LogonType S4U

Çalışacak görevin yetkileri RunLevel ile belirtilebilir (Limited/Highest):

$principal = New-ScheduledTaskPrinciple -UserId "makine\kullanidi" -LogonType Interactive -RunLevel Highest

LocalService veya System kullanıcıları ile bir görev çalıştırmak için

$principal = New-ScheduledTaskPrincipal -UserId "LOCALSERVICE" -LogonType ServiceAccount
$principal = New-ScheduledTaskPrincipal -UserId "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount 

ve hatta bir grup yetkileriyle görev planlamak için

$principal = New-ScheduledTaskPrincipal -GroupId "BUILTIN\Administrators" -RunLevel Highest

kullanılabilir. Mevcut bir zamanlanmış görevin trigger'larından birini değiştirmek için aşağıdaki yöntem kullanılabilir:

$task = Get-ScheduledTask -TaskName "Gorev1"

$trig = $task.Triggers

$trig.Repetition.Duration = $null

$trig.Repetition.StopAtDurationEnd=$false

Set-ScheduledTask -InputObject $task

Birden fazla trigger eklemek için iki trigger bir dizi olarak atanabilir:

$task.Triggers = ($trigger1, $trigger2)

gibi. Bir dizüstü bilgisayardaki görevin bataryadan çalışıldığı anda bile çalışmasını sağlamak veya uyku kipindeki bilgisayarları uyandırmak için için New-ScheduledTaskSettingsSet'in seçenekleri kullanılabilir.

Tekrarlayacak görevler için RepetitionInterval'a aşağıdaki gibi New-TimeSpan cmdlet'i ile zaman aralığı atanabilir.

$trig1 = New-ScheduledTaskTrigger -At 13:30 -Once -RepetitionInterval (New-TimeSpan -Hours 1)

benzer şekilde -RandomDelay parametresine de bir New-TimeSpan ile zaman aralığı verilmeli

$trig1 = New-ScheduledTaskTrigger -AtLogon -RandomDelay (New-TimeSpan -Minutes 5)

gibi. Sonradan değiştirmek için ise

$task.Triggers[0].Repetition.RepetitionInterval = New-TimeSpan -Hours 1

"No mapping between account names and security IDs was done" gibi bir hata, var olmayan bir kullanıcı belirtildiğini gösterir. Runlevel için Highest seçilecekse Powershell penceresi de yüksek yetkilerle açılmış olmalı. Varsayılan ayarlara sahip bir görev için New-ScheduledTaskSettings ve New-ScheduledTaskPrincipal kullanmak gerekli değil.

Bir olay sonrasında çalıştırılacak görev oluşturduğumuzda çalışmıyorsa yapılabilecek şey göreve ait trigger'ı kontrol etmek olabilir. Genelde provider name yanlış yazdığımda yaşadığım bir hataydı. Kontrol etmek için trigger'ı açtığımda aşağıdaki gibi bir ekranla karşılaştım:

Source (ya da provider) kısmında "Microsoft-Windows-TerminalServices-TaskScheduler" ve "TaskScheduler" seçenekleri var. TaskScheduler gibi Uygulama ve Hizmet Günlüklerinde genelde birden fazla Source olmıyor. Bunlardan üstteki yanlış yazılmış. Ama gerek schtasks.exe gerek powershell ile görev oluştururken sadece TaskSheduler yazmak da yetmiyor. Bunun yerine tam yolu "Microsoft-Windows-TaskScheduler" olarak yazmak gerek, burada o sadece TaskScheduler olarak kısaltılabilir.

Zamanlanmış görevin en son çalıştığı zamanı, döndüğü durum/hata kodu gibi bilgilerini görmek için ise

Get-ScheduledTask -Taskname "gorev-1" | Get-ScheduledTaskInfo 

kullanılabilir. Dönülen hata/durum kodları ile ilgili şu bilgiler var:

0 => "Görev başarıyla çalıştırıldı",
1 => "Yanlış veya bilinmeyen görev",
2 => "Dosya bulunamadı.",
a => "Ortam yanlış.",
00041300 => "Bir sonraki döngüde çalışmaya hazır",
00041301 => "Görev şu anda çalışıyor",
00041302 => "Görev devre dışı",
00041303 => "Görev henüz hiç çalışmadı",
00041304 => "Bu görev için başka çalışma zamanı planlanmamış",
00041305 => "Görevin çalışması için bir veya daha fazla özellik atanmamış",
00041306 => "Görevin çalışması kullanıcı tarafından sonlandırıldı",
00041307 => "Ya trigger yok, ya da trigger'lar devre dışı",
00041308 => "Trigger'larda zaman belirtilmemiş",
80010002 => "Call was canceled by the message filter",
80041309 => "Görevin trigger'ı bulunamadı",
8004130A => "One or more of the properties required to run this task have not been set.",
8004130B => "There is no running instance of the task.",
8004130C => "The Task Scheduler service is not installed on this computer.",
8004130D => "The task object could not be opened.",
8004130E => "The object is either an invalid task object or is not a task object.",
8004130F => "No account information could be found in the Task Scheduler security database for the task indicated.",
80041310 => "Unable to establish existence of the account specified.",
80041311 => "Corruption was detected in the Task Scheduler security database",
80041312 => "Task Scheduler security services are available only on Windows NT.",
80041313 => "The task object version is either unsupported or invalid.",
80041314 => "The task has been configured with an unsupported combination of account settings and run time options.",
80041315 => "The Task Scheduler Service is not running.",
80041316 => "The task XML contains an unexpected node.",
80041317 => "The task XML contains an element or attribute from an unexpected namespace.",
80041318 => "The task XML contains a value which is incorrectly formatted or out of range.",
80041319 => "The task XML is missing a required element or attribute.",
8004131A => "The task XML is malformed.",
0004131B => "The task is registered, but not all specified triggers will start the task.",
0004131C => "The task is registered, but may fail to start.Batch logon privilege needs to be enabled for the task principal.",
8004131D => "The task XML contains too many nodes of the same type.",
8004131E => "The task cannot be started after the trigger end boundary.",
8004131F => "An instance of this task is already running.",
80041320 => "The task will not run because the user is not logged on.",
80041321 => "The task image is corrupt or has been tampered with.",
80041322 => "The Task Scheduler service is not available.",
80041323 => "The Task Scheduler service is too busy to handle your request. Please try again later.",
80041324 => "The Task Scheduler service attempted to run the task, but the task did not run due to one of the constraints in the task definition.",
00041325 => "The Task Scheduler service has asked the task to run.",
80041326 => "The task is disabled.",
80041327 => "The task has properties that are not compatible with earlier versions of Windows.",
80041328 => "The task settings do not allow the task to start on demand.",
80070002 :  The system cannot find the file specified - (https://itexperience.net/0xfffd0000-in-task-scheduler-when-running-powershell-script/, 800070002 yaziyordu)
800710e0 :  Operator refures the request. Check permissions. see https://windowsreport.com/0x800710e0/
8007010b :  Start in folder is incorrect
C000013A => "The application terminated as a result of a CTRL+C.",
C0000142 => "The application failed to initialize properly.",
FFFD0000 :  Path error, possibly for powershell scripts

---

https://xplantefeve.io/posts/SchdTskOnEvent

https://richardspowershellblog.wordpress.com/2014/09/12/multiple-triggers-on-a-scheduled-task/

https://www.pdq.com/powershell/set-scheduledtask/

https://lazyadmin.nl/powershell/how-to-create-a-powershell-scheduled-task/

Bilgisayar hata mesajları ve kullanıcılar

Genelde yaklaşım "erkanda bişey çıktı ama tamama bastım"dan ibaret olan durumlar. Bu konuda her gördüğümde güldüğüm Jonathan Nightingale imzalı aşağıdaki karikatürize hata mesajını paylaşmaya değer buluyorum.

PSReadline ve komut geçmişinde aramalar yapmak

Linux'ta (bash veya zsh) Ctrl+R aracılığıyla geçmişte arama yapmak mümkün. Powershell'de de benzer bir işlev var. Ctrl+R'ye bastığımda yazdığım anahtar kelime ile geçmişte geriye doğru bir arama yapabiliyorum. İlk çıkan sonuçtan sonra aramayı devam ettirerek bir öncekine ulaşmak için Ctrl+R'ye basmaya devam edebiliyorum. Ctrl+S ise aramanın yönünü değiştirerek ileriye doğru aramaya geçiyor. Arama geçmiş komutların içinde geçen herhangi bir parçaya göre yapılıyor.

Benzer bir işlev de F8 ile mümkün. Bu ise aramayı sadece yazdığım anahtar kelime ile başlayanlar ile kısıtlıyor. F8'e basmaya devam ederek geçmişte bir adım geriye gidebiliyor veya Shift+F8 ile arama yönünü çevirerek ileriye doğru gidebiliyorum.

Bu işlevleri bana sunan PSReadLine'ın kısayol tuşlarının listesini aşağıdaki komutla almak mümkün [1]:

Get-PSReadlineKeyHandler | ? {$_.function -like '*hist*'}

PSReadLine'ın bütün klavye kısayolları atamalarını görmek için

Get-PSReadLineKeyHandler

ve henüz atanmamış işlevleri görmek için ise

Get-PSReadLineKeyHandler -Unbound

kullanabiliriz. Yeni bir işlev ataması yapmak da mümkün. Örneğin henüz bir klavye ataması yapmadığım CaptureScreen işlevini Ctrl+Alt+p klavye kısayoluna atamak için

Set-PSReadLineKeyHandler -Chord 'Ctrl+Alt+p' -Function CaptureScreen

 yapabiliriz. Herhangi bir klavye kısayolunun bir atamada kullanılıp kullanılmadığını sorgulamak için Shift+Alt+* (İngilizce kaynaklarda Alt+? denmiş ama Türkçe klavyelerde bu sıfır (0)'ın yanındaki asteriks (*)'e Shift ve Alt ile basmak demek) bastıktan sonra istenen klavye kısayoluna basmak yeterli. Klavyelerin sağ bölümünde bulunan keypad'deki tuşlar gibi sıradışı tuşların isimlerini öğrenmek için ise aşağıdaki komutu yazdıktan sonra istenen tuşa basmak yeterli:

[System.Console]::ReadKey()

 ---

[1] https://serverfault.com/questions/891265/how-to-search-powershell-command-history-from-previous-sessions

[2] https://learn.microsoft.com/en-us/powershell/scripting/learn/shell/using-keyhandlers?view=powershell-7.4

Windows'da betikleri bekletmek

Powershell'in Start-Sleep cmdlet'i betiklerde gerekli süre boyunca beklemek için ideal.

Start-Sleep -Seconds 5

Peki bunu komut satırındaki bat dosyalarında nasıl yaparız? Eskiden sleep gibi bir komut vardı, Windows'da, ama artık yok.

İlk yöntem belki de bat dosyasının içinden powershell komutu çalıştırmak olabilir.

powershell "start-sleep -seconds 5"

Bazı yaratıcı beyinler 5 kere ping atmanın ve çıkışı nul'a göndermenin işe yarayacağını söylemiş:

ping 1.1.1.1 -c 5 > nul

Güzel. Daha güzeli timeout:

timeout 5

Bir tuşa basana kadar beklemesi için pause olabilir:

pause
Press any key to continue...

Bunun eşdeğeri powershell'de Read-Host olabilir

Read-Host "Bir tuşa basın..."

Ayrıca [1] ve [2]'de choice ve waitfor komutlarından da bahsedilmiş:

waitfor /t 5 pause

choice /c AB /N /T 5 /D A /M "5 sn bekliyorum"

---

[1] https://www.wikihow.com/Delay-a-Batch-File

[2] https://stackoverflow.com/questions/1672338/how-to-sleep-for-five-seconds-in-a-batch-file-cmd

Batch dosyalarında değişkenler

Powershell'de tarih ve saati bir değişkene atmak basit:

$tarih_saat = Get-Date -Format "yyyy-MM-dd HH:mm:ss"

Ancak bunun eşdeğeri batch dosyalarında bu şekilde olmuyor. Ben şöyle bir yol buldum:

echo @off
for /f "tokens=*" %%a in ('date /t') do set tarih=%%a
for /f "tokens=*" %%b in ('time /t') do set saat=%%b
set tarih_saat=%tarih%- %saat%

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/

Windows Time

Zaman eşitlemesi önemli bir iş. Windows sunucularda da bu amaçla çalışan bir hizmet var; "Windows Time".

PS> gsv w32Time
Status   Name               DisplayName
------   ----               -----------
Running  w32time            Windows Time

NTP protokolü de, bilindiği gibi, UDP 123 üzerinden çalışıyor. Bu portun açık olması, arka planda bir zaman sunucusunun etkin olduğunu düşünebilmek için ilk koşul.

ncat -z -v -u 192.168.1.1 123

Yerel ağımızda çalışan bir Windows sunucuyu, linux makinalar tarafından güvenilir bir zaman sunucusu olarak kullanabilir, veya tam tersi linux sunucuyu da Windows makinalar tarafından güvenilir bir zaman sunucusu (NTP) ayarlayabiliriz; teknik olarak mümkün.

Bu hizmetin çalışmasını komut satırından yapabilmek için w32tm komutu var. Örnek olarak bizim bilgisayarımızın saati senkronize edeceği kaynak NTP sunucusu olarak hangi adresi kullandığını bulmak için

w32tm /query /source

kullanabiliriz. Windows Time hizmeti ve zaman eşitleme durumu ile ilgili ayrıntılı bilgi için ise

w32tm /query /status

kullanılabilir. Yerel bilgisayarda NTP sunucumuzu bulmak için regisry kullanmak istersek okumamız gereken alan HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters altındaki NtpServer değeri:

(gp -Path HKLM:\SYSTEM\CurrentControlSet\Services\W32Time\Parameters -Name NtpServer).NtpServer

Bu değeri komut satırından değiştirmek ve uygulamaya geçirmek için aşağıdaki komutlar gerekli:

gsv w32time | spsv
w32tm /config /syncfromflags:manual /manualpeerlist:"192.168.1.1 192.168.1.2"
gsv w32time | sasv
w32tm /config /update
w32tm /resync /rediscover

Bundan sonra herhangi bir anda zaman kaynak sunucumuzdan zaman eşitlemesi yapmak için

w32tm /resync

yeterli.

---

https://learn.microsoft.com/en-us/windows-server/networking/windows-time-service/windows-time-service-tools-and-settings?tabs=config
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/ff799054(v=ws.11)

Windows API'lerinde ~256 karakterlik tam yol adı sınırlaması

Kullanıcıların dosyalarına neden uzun uzun isimler vermeyi tercih etmeleri üzerine yazılan tezleri araştırmadan önce böyle bir yol izlemiş kişilerin dosyalarını kopyalarken karşılaşılan hataların çözümüne kafa yordum. Microsoft'un niye böyle bir kısıtlamaya ihtiyacı var diye düşündüm. Sonra öğrendim ki Windows 10 1607 sürüm ve üstünde bu kısıtlamayı kaldırmayı seçebiliyormuşuz [1]. Bilmeden bu kısıtlamaya takıldığım için üzüldüm.

İkinin sekizinci kuvveti olması sebebiyle 256 olarak hafızalarda yer etmesine rağmen aslında 260 karakterlik bir sınır söz konusu. Çünkü sürücü adı, iki nokta üst üste, bir ters bölü ve en sondaki NUL karakterini de sayarsak aslında 256 karakterlik klasör  ve dosya isimlerinin toplamına 4 daha ilave ederek 260'a ulaşıyoruz.

Yerel bilgisayarda çalışırken mutlu mesut +260 karakterlik isimler ile klasör oluşturup dosya kaydedebilen, bunları tekrar açabilen kullanıcı, aslında bu dosyaları kopyalayamıyor, yeniden adlandıramıyor hatta silemiyor (ortalama bir kullanıcının robocopy kullanmadığını varsayarak [3]). Ta ki bir gün bu verilerin başka bir diske veya başka bir bilgisayara kopyalanması gerekene kadar. Bunu da yaparken ya eksik kopyalanıyor, ya da bir bilenden yardım isteniyor. Kopyalama sırasında Windows kullanıcıya çok yardımcı olmadığı için o anda ekranda görüntülenen mesajda tam olarak hangi dosya veya klasörün 260 sınırından daha fazla isme sahip olduğunu göremiyor. Bu durumda görüntülenen hata mesajında "Atla" tuşuna basıp işlem bittikten sonra aslında işlemin bitmediğini, eksik kalan dosyaları aramak zorunda olduğumuz ikinci aşamaya geçtiğimizi farkediyoruz. Böyle bir durumda hangi dosyaların kopyalanmadığını bulabilmek için Powershell ile aşağıdaki gibi bir komut ile dosyalar tespit edilerek bir dosyaya yazılabilir [2].

dir -recurse | where {$_.Fullname.Length -gt 260} | select Name | out-file uzun-dosya-isimleri.txt

Ya da doğrudan cmd.exe ile

dir /s /b | sort /r /+261 /o longpaths.txt

Öngörülü insanların kullanacağı yöntem ise [1]'de belirtildiği gibi:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
"LongPathsEnabled"=dword:00000001

---

[1] https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry

[2] https://www.mindgems.com/article/find-long-paths-long-file-names/

[3] https://it.cornell.edu/shared-file/windows-file-name-or-destination-path-you-specified-not-valid-or-too-long

Powershell'de USB cihazları listeleme

Linux'taki lsusb komutuna benzer bir şey arıyorum, uzak makinelere Enter-PSSession ile bağlandığımda kullanabileceğim. Şu adresteki çözüm hoşuma gitti:

Get-PnpDevice -PresentOnly | Where-Object { $_.InstanceId -match '^USB' }

 ---

https://learn.microsoft.com/tr-tr/powershell/module/pnpdevice/get-pnpdevice?view=windowsserver2022-ps&wt.mc_id=ps-gethelp

Uzak bilgisayarlardaki günlükleri etkinleştirmek

Vista ve sonrası sürümlerde Sistem, Uygulama, Güvenlik ve Kur olay günlüklerine ek olarak bir sürü Uygulama ve Hizmet Günlüğü geldi. Örnek, "Microsoft-Windows-PrintService/Operational". Ancak bu günlüklerin bir kısmı varsayılan olarak devre dışı geliyor. Bu kadar olay günlüğünü açarsak disk kısa sürede dolacaktır. İsteğe göre bir kısmını açmakta bir sakınca yok, geriye doğru çok yüksek sayıda olayı hatırlamak zorunda değilsek.

Örneğimiz "Microsoft-Windows-PrintService/Operational" varsayılan olarak kapalı geliyor. Açmak için şu yazımda anlattığım yöntemi kullanabiliriz. Önce uzak bilgisayardaki bu günlüğe ait bir değişken oluşturalım:

$PrintLog = Get-WinEvent -ListLog "Microsoft-Windows-PrintService/Operational"
$PrintLog.IsEnabled = $true
$PrintLog.SaveChanges()

Birkaç bilgisayarda durumu kontrol etmek için

$bilgisayarlar | 

ForEach-Object {

    Invoke-Command -Computername $_ -ScriptBlock {

        Get-WinEvent -Logname "Microsoft-Windows-PrintService/Operational"} | 

            Format-Table LogName, IsEnabled, RecordCount, MaximumSizeInBytes -AutoSize

gibi birşey kullanılabilir.

Powershell ile anlık olarak en fazla işlemci kullanan süreci bulmak

Her konuda olduğu gibi bilişimde de kavram karmaşaları oluyor. Bellekte olduğu gibi işlemci kullanımında da bir kavram karışıklığı var. En çok işlemci kullanan süreci belirlememiz gerekseydi anlık olarak mı bir ölçüm yapardık yoksa bilgisayarın açıldığı tarihten itibaren mi?

Poweshell'in Get-Process cmdlet'i bize sadece toplam işlemci kullanım süresini veriyor. Anlık olarak en çok işlemci kullanan süreci bulmak istersek Get-Process işimizi görmez.

Get-Process * | 

    Sort-Object -Property CPU -Descending | 

        Select-Object -First 10

Bu amaçla yaptığım kısa bir araştırmada Windows'un sayaçlarının (counter) kullanılabileceğini gördüm. Performans İzleyicisi (Performance Monitor) ile görüntülenen verilerin kaynağı olan sayaçlar, powershell ile Get-Counter cmdlet'i ile okunabiliyor. Yüzlerce sayaca sahip Windows'da hangi sayacı kullanacağımızı seçmek için şöyle bir arama yapabiliriz:

Get-Counter -ListSet *Process*

Ya da doğrudan performans izleyiciyi açarak buradan istediğimiz sayacı seçebiliriz. Dikkat edilmesi gereken bir konu, Türkçe Windows sürümlerinde sayaç isimlerinin de Türkçe olması. Script'i bir makinede geliştirip sunucuda çalıştırınca hatalar üretebilir. Ben tüm komutları İngilizce sayaç isimleri ile kullanacağım.

Benim bu amaçla kullanacağım sayaç "\İşlemci(*)\% İşlemci Zamanı" (ya da İngilizce işletim sistemlerinde "\Process(*)\% Processor Time". Ama bu şekilde Get-Counter tüm süreçlerin toplam anlık yüzdesini veriyor.

Get-Counter -Counter "\Process(*)\% Processor Time"

Ayrı ayrı süreçlerın anlık işlemci kullanım oranlarını görebilmek için ise bu komutun döndüğü [PerformanceCounterSampleSet] nesnesinin CounterSamples dizisini genişletmek gerek. Bu dizinin içinde her sürecin işlemci kullanımı CookedValue değeri içinde geliyor. Sonra bu değere göre dizmeli (Sort-Object -Property CookedValue -Descending) ve en çok değere sahip 10 (Select-Object -First 10) tanesini listelemeliyim:

Get-Counter -Counter "\Process(*)\% Processor Time" | 

    Select-Object -ExpandProperty CounterSamples |

        Sort-Object -Property CookedValue -Descending |

            Select-Object -First 10 

Bu en çok işlemci kullanımına sahip ilk 10. Ama burada görmek istemeyeceğimiz değerleri süzmek için Where-Objet {$_.InstanceName -notin ("_total","idle","system") kullanabiliriz.

Get-Counter -Counter "\Process(*)\% Processor Time" | 

    Select-Object -ExpandProperty CounterSamples |

        Where-Object {$_.InstanceName -notin ("_total","idle","system")} | 

            Sort-Object -Property CookedValue -Descending |

                Select-Object -First 10

Bu bize anlık olarak en fazla işlemci kullanım oranına sahip 10 süreci verir. İlgilendiğimiz bir süreç varsa ve bu sürecin anlık işlemci kullanım oranıyla ilgileniyorsak, örneğin yazdırma biriktiricisi (print spooler) için şöyle bir script olabilir:

Get-Counter '\Process(*)\% Processor Time' | 
    Select-Object -ExpandProperty CounterSamples | 
        where {$_.InstanceName -eq "spoolsv"}

Bu işler daha kolay olamaz mıydı?

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ınız (veya USB) ile sistemi açtıktan sonra Türkçe klavye alışkanlıkları olan birisi için öncelik klavye düzenini alışık olduğumuz düzene ayarlamaksa çalıştırmamız 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ş. 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 kuralım:

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

İş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. Bunu da başka bir yazıda yazacağım.

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/

uBlock sebebiyle görüntülenemeyen sayfalar

uBlock Origin olmazsa olmaz. Ama bazı sayfalarda bileşenlerden bir veya birkaç tanesini engellediği için sayfa ya hiç görüntülenemiyor ya da bozuk görüntüleniyor. Bu durumda -muhtemelen- araç çubuğunda bulunan uBlock'un kırmızı simgesinin üzerinde engellenen içeriğın sayısı yazıyor. Bugüne kadar bu gibi sorunları çözmek için görüntülenemeyen sitelerde uBlock'u tamamen kapatarak yapıyordum. Bu nasıl yapılır; araç çubuğundaki kırmızı kalkan sembülünü tıklayarak açılan küçük penceredeki mavi aç/kapat simgesini tıklayarak rengini griye çevirdikten sonra hemen sağında çıkan sayfayı yeniden yükle simgesine tıklayarak.

Ama daha iyi bir yolu var. Öncelikle yaşanan sorunun uBlock Origin'le mi ilgili olduğunu anlayabilmek için geliştirici araçlarından "Ağ" sekmesine geçerek burada (muhtemelen sayfayı yeniden yükledikten sonra) en soldaki "Durum" sütununda örneğin kırmızı bir 🚫 sembolü olan satırların "Aktarılan" sütununda "uBlock tarafından engellendi" yazanlara bakmalıyız. Bu şekilde soruna yol açabilecek bir bileşenin mi engellendiğini hakkında bir fikir sahibi olabiliriz. Ama bu engellemeye hangi kural sebep oldu? Daha da önemlisi şu anda görüntüleyemediğimzi sayfa için nasıl bir istisna kuralı oluşturabiliriz?

 

Yukarıdaki görselde sağ alt köşede yer alan "Daha az" etiketinin üstündeki dişlilerin hemen solundaki simge uBlock Origin'in işlem kaydını tutan günlükçüye ait. Geliştirici araçlarının ağ sekmesindeki satırlar genel olarak Firefox'un her bir öğenin (resim, html sayfası veya script gibi) aktarımı ile ilgili sonuçları listeliyor. Aktarılamayanlar ile ilgili sorumlu uBlock gösteriliyor. Ama günlükçüde ise hangi kural sebebiyle aktarılamadığı, hatta bu sorunu gidermek için nasıl istisna oluşturulabileceği gösteriliyor. Örnek olarak aşağıdaki ekranda kırmızı satırlar uBlock Origin tarafından engellenen içeriğe ait. Fare ile kırmızı satırlardan birine tıkladığımız ne sebeple engellendiği gösteriliyor. Aşağıdaki örnekte en alttaki cloudflareinsights.com'a tıkladığımda açılan küçük pencerede ise daha ayrıntılı bir şekilde hangi filtrenin (||cloudflareinsights.com^) ve hatta hangi listede (Peter Lowe's Ad and tracking server list) yer alan kuralın bu sonuca yol açtığı gösterilmiş. URL satırında ise sorun yaşadığımız sayfanın adresindeki eşleşme vurgulanmış.

Sorunun ne olduğunu, hangi filtre veya hangi listeyle ilgili olduğunu bulduk. Yapılabilecek şeylerden birisi listeyi devreden çıkarmak. Yukarıdaki görselde Peter Lowe's Ad and tracking server list'i devreden çıkarmak için uBlock Origin'in ayarlarından "Filtre Listeleri" sekmesine geçerek altlara doğru "Çok amaçlı" başlığının altında yer alan Peter Lowe's öğesinin başındaki kutunun işaretini kaldırarak yapabiliriz.

Bu en fazla yan etkiye sahip çözüm. Bu şekilde bundan sonra gireceğimiz bütün sitelerde, Peter Lowe'nin bütün çalışmalarını devre dışı bırakıyoruz. Daha az yan etkiye sahip bir çözüm için bir önceki resimde yer alan "Peter Lowe's Ad and tracking server list" bağlantısını tıklayarak açıkan pencerede bizim konumuzla ilgili olan filtreyi bulup (||cloudflareinsights.com^) bunu silebiliriz (aşağıda sarı ile işaretlenmiş tüm satır).

Ancak bu çözüm de bazı yan etkilere sahip. cloudflareinsight.com bir sebeple bu listeye alındığına göre bence bu listede kalmalı. Sadece bu sitede bu adrese erişebilmek için ise yapılabilecek daha farklı bir şey var. Yine günlükçünün ekran görüntüsünde görülen küçük pencerenin statik filtre sekmesine geçtiğimizde bize bir filtre oluşturmayı öneriyor, sadece seçili olan öğe ve bulunduğumuz site ile ilgili.

Bizim ihtiyacımız olan sondaki açılır kutuyu "Engelle" olarak değil, "İzin ver" olarak ayarlamak. Oluştura bastığımızda yeni filtre oluşturulmuş olacak. Bir sebeple bu filtreyi silmek veya değiştirmek istersek konumu uBlock Origin'in ayarlar sayfasında Filtrelerim sayfasında. Eğer çok filtre varsa orada oluşturduğumuz filtrenin aramasını yukarıdaki küçük kutuya yazarak yapabiliriz.

Kurallar oluşturmak hakkında bilgi için şu adres tıklanabilir.

Virüs temizleme araçları

Antivirüs yüklü olmayan (hadi Windows Defender da) Windows bilgisayarımız var. Ve bu bilgisayara bazı kötü niyetli (malicious) yazılımlar yüklenmiş. Bu tür kötü niyetli yazılımlar antivirüs yüklenmesi de dahil olmak üzere birçok şeyi engelleyebilirler. Bu tür kötü niyetli yazılımlardan kurtulmak için antivirüs geliştiricilerinin bazı araçları var; şu videoda da bahsedildiği gibi. Bu araçlar şunlar:

• Norton Power Eraser
• Kaspersky Virus Removal Tool
  
• Hitman Pro (Sophos)
  
• Malware Bytes
  

Windows Server sanal makinesindeki C: bölümünü büyütmek

Eskiden böyle olmuyordu. Aşağıdaki resimde 524 MB'lık diskin en sonunda yer alan Recovery Partition diskin başında yer alıyordu. Ama şu 1 yaşındaki Standart Windows Server 2022 kurulumunda diskim şöyle bölümlenmiş:

Bu bir sanal makine. Ekran görüntüleri gerçek sunucumun değil; işlemi yapmadan aynı ortamı oluşturarak işlemleri denediğim bir sanal makineden. C: sürücüme ayrılan alan bir süre sonra kurulumlar, log dosyaları, güncellemeler vs sebeplerle artık yetmemeye başladı. Sanal diskimi büyüttüm. Sonuçta aşağıdaki gibi bir disk yapım oluştu.

Burada görüldüğü gibi C: sürücümü büyütmem için sonrasında genel Recovery Partition'ımı taşımam gerek. Ama standart Windows araçlarının içinde taşıma diye bir işlev yok. Önerilen bu disk bölümünü silerek C:'yi genişletmek ve sonrasında tekrar yeni bir recovery partition oluşturmak.

Ama herşeyden önce reagentc komut satırı aracını kullanarak mevcut recovery partition'ın durumunu sorguladım.

reagent /info

İlk yapmak gereken recovery partition'ı silmek. Ancak bunu Disk Yönetimi (Disk Management) arayüzünden yapmak mümkün değil. Komut satırı araçlarından diskpart'a girip ilgili partition'ı seçtikten sonra delete partition derken override (force) parametresini kullandım:

delete partition override

Daha sonra C: sürücüsünü genişlettim (diskpart ile veya Disk Yönetimi arayüzünden de olabilir). Ama C: sürücüsünü genişlettikten sonra diskin sonunda hala yaklaşık 550 MB boyutunda bir alanın yeniden oluşturacağım recovery partition için kalması gerekecek.

Diskime tam olarak 40 GB yer ilave etmiştim. 40x1024 = 40960 MB yapar. Ben de diskimi tam olarak bu miktarda büyüttüm ki sonrasında hala eski boyut 524 MB yer kalsın.

Bundan sonraki aşama biraz sıradışı. Yeni partition oluşturdum, en sonda kalan 524 MB'lık alanda. Ama bunu da diskpart'tan yaptım, çünkü oluştururken bir grafik arayüzden belirtilemeyecek bir id ataması yapmak gerekiyor. Sonrasında da gpt attribute olarak 0x8000000000000001 verdim:

create partition primary size=560 id=de94bba4-06d1-4d40-a16a-bfd50179d6ac
gpt attributes=0x8000000000000001

Orijinal kurulumda da bu disk bölümünün dosya sistemi NTFS'ti, yine aynı şekilde NTFS dosya sistemi oluşturdum:

format fs=ntfs quick label=WinRE

Sonrasında detail partition ile sonucu görmek istedim.

Buraya kadar geldiysek iyi. Şu aşamada recovery partition durumumuzu kontrol ettiğimizde çalışmıyor olarak gözükecek:

Şimdi sıra geldi bu disk bölümünün içini doldurmaya. Bu disk bölümümüze diskpart'tan bir harf ataması yapmamız gerek. Bunu da

assign letter=Z

şeklinde yapabiliriz. Disk bölümümüzün içini doldurmak için Windows kurulum medyasının içindeki install.wim dosyasına ihtiyacımız var. Nasıl olsa C: sürücümüzü artık genişlettik, içinde yer var. Kurulum medyasında \Sources klasörünün içinde yer alan ve 4 GB'tan büyük olan install.wim dosyasını C:\ kök klasörüne kopyalayalım. Bu dosyayı bir klasöre bağlayacağız. Bu amaçla da C:\Temp gibi bir klasör oluşturalım. Bu klasörün içinin boş olması gerek.

mkdir C:\Temp
copy D:\Sources\install.wim C:\

Ve bu install.wim dosyasını DISM kullanarak C:\Temp klasörüne bağlayalım:

DISM /Mount-wim /Wimfile:"C:\install.wim" /index:1 /MountDir:"C:\temp" /ReadOnly

Bu adımdan sonra boş olan C:\Temp klasörünün altında bir yapı oluşacak. Ama aslında bu yapı install.wim dosyasının içinde.

Recovery Parititon içinde bir klasör yapısı oluşturalım:

mkdir "Z:\Recovery\WindowsRE"

C:\Temp klasörünün altında oluşan yapıdan winrm.wim dosyasını Z: sürücümüze kopyalayalım:

copy "C:\Temp\Windows\System32\Recovery\winre.wim" "Z:\Recovery\WindowsRE"

Ve bu dosyanın konumunu kaydedelim.

reagentc /SetREimage /Path "Z:\Recovery\WindowsRE"

Bu adım "Operation Successful" mesajı verirse artık reagentc /enable yapabiliriz:

reagentc /enable

Bu adım da başarılı sonuç verdi. Nihayet durumu bir de info parametresi ile kontrol edelim:

reagentc /info

Olmuş gibi. Başka nasıl kontrol edebilirim?

Bağlanmış wim dosyası hala bağlı. Durum kontrolü:

dism /Get-MountedImageInfo
Deployment Image Servicing and Management tool
Version: 10.0.20348.1

Mounted images:

Mount Dir : C:\Temp
Image File : C:\install.wim
Image Index : 1
Mounted Read/Write : No
Status : Needs Remount

The operation completed successfully.

En son bunun da bağlantısını keselim:

Dism /Unmount-Image /MountDir:C:\Temp /Discard

-Fin-

Kullanımdan kalkan picasaweb yerine

Blog'uma eklediğim resimleri yönetmek için eskiden picasaweb'i kullanıyordum. Ama bu hizmet artık yok. Onun yerine Google Albüm Arşivi'ne yönlendirdi. O da nihayet şu sayfaya. Burası daha derli toplu bir sayfa olmuş. Herşeyden önce resimler en yeniden en eskiye doğru sıralandığı içn en son eklediğim resimler en üstte çıkıyor.

Güneş patlamaları ve tahmin edilebilirlik

Bugünlerde yoğun olarak Güneş'teki lekeler ve güneş patlamaları hakkında konuşuyoruz. Güneş'te meydana gelebilecek patlamaların Dünya üzerindeki etkileri nasıl olur, bunlar bilişim sistemleri başta olmak üzere hayatı nasıl etkiler gibi konuları merak ediyordum. Yaptığım kısa araştırma ve bu patlamaların önceden tahmin edilmesi ile ilgili buluklarımı paylaşacağım.

Güneş üzerinde meydana gelen reaksiyonlar yıllara göre bir değişim gösteriyor. Bu değişim periyodik bir yapıda. Bu periyoda Güneş Döngüsü (Solar Cycle) deniyor. Döngümüzün periyodu 11 yıl ve bu süre içinde bir en düşük nokta (Solar Minimum) ve bir de en yüksek noktaya (Solar Maximum) ulaşıyor.

Şu anda içinde bulunduğumuz zaman diliminde Güneş'in maksimum dönemindeyiz. Ayrıca Güneş üzerinde de normalin üzerinde büyüklükte bir leke var. Bu leke de patlama riski olan bir olgu. Ne kadar büyürse o kadar büyük bir patlama riski taşıyor. Bu patlamalara taçküre kütle atımı (Coronal Mass Ejection) deniyor. Patlamalarda çok fazla yüklü parçacık uzaya saçılıyor. Bu parçacıklar eğer Dünya'ya doğru savrulmuşlar ise Dünya'nın manyetik alanı başta olmak üzere bazı şeyleri etkileyebiliyorlar.

Dünya'nın bir manyetik küresi var. Bu küre Dünya'yı normal bir günde Güneş'ten gelen zararlı ışınlara karşı koruyor. Ancak Güneş Patlaması ya da Güneş Fırtınası denen durumlarda uzaya saçılan bu yüklü parçacıklar Dünya'nın manyetik küresini geçici olarak bozarak korumayı zayıflatıyor. Böyle bir durumda Dünya'da manyetik kutuplara göre yönünü bulan sistemlerde geçici işlev kayıpları oluşabiliyor, hayvanların yönlerin bulması zorlaşabiliyor.

Ayrıca hareket halindeki yüklü parçacıklar elektrik hatlarında ve devrelerde indüksiyon akımlarına sebep olabiliyor. Patlamanın büyüklüğüne bağlı olarak trafolar zarar görebiliyor veya iletişim devrelerinde büyük gürültüler iletişimi imkansız hale getirebiliyor.

1859 yılında meydana gelen Güneş Patlaması sonucunda telgraf hatlarındaki akımlar bazı donanımlara zarar vermiş, telgraf iletişimi kesintiye uğramış. 1989 yılında meydana gelen patlama ise Kanada'da elektrik kesintilerine sebep olmuş.

Daha büyük patlamalar meydana gelebilir mi? Bunların Dünya'daki etkileri nasıl olur? İnsanlık tekrar taş devrine döner mi? Bu patlamaları öncesinde görüp önlem alabilir miyiz?

Öncelikle ABD ve Avustralya'da bu tip olayları gözlemleyen merkezler var. ABD'deki gözlem merkezinin adı Space Weather Protection Center (SWPC). Bu merkezin hizmetlerine ücretsiz abone olunarak haberdar olunabiliyor. Peki ne kadar öncesinde haberdar olabiliriz? Güneş'te meydana gelen herhangi bir olayı görebilmemiz için, ışık hızından dolayı, 8 dakika  geçmesi gerekiyor. Patlamalar sonrasında uzaya saçılan parçacıkların hızı patlamanın şiddetine göre değişiyor ama genelde 12 saat ile 48 saat arasında bir zamanımız olabiliyor. İşte SWPC'nin gönderdiği bilgilendirme mesajları bu amaca hizmet ediyor. Umuyoruz ki patlamalar sonrasında önlem alabilecek vaktimiz olacak.

SWPC'nin mesajları ve web sistesinde kullandığı birkaç kavramdan bahsetmek istiyorum. Öncelikle K endeksi denilen bir değer var. Bunun gezegenimiz özelinde ifade edilmesi Kp şeklinde oluyor (Planetary K-Index). Bu değer 0-9 aralığında oluyor. Ne kadar büyükse o kadar ciddi bir jeomanyetik fırtına ile karşı karşıyayız demektir.

0 - 3 : Sessiz veya çok az jeomanyetik aktivite
4 - 6 : Orta seviye aktivite
7 - 9 : Ciddi aktivite 

Bir de A endeksi var. Bu da 0 ile 400 arasında olan bir değer. Geriye doğru 24 saatlik dönemdeki jeomanyetik bozulmanın bir ölçüsü.

0 - 7 : Sessiz veya çok düşük aktivite
8 - 15 : Hafif aktivite
16 - 29 : Hafif-ciddi arası güneş fırtınası
30 - 49 : Ciddi güneş fırtınası
50 + : Çok ciddi güneş fırtınası

Dünya'ya etkiler 3 başlıkta toplanmış; Jeomanyetik etkiler (G), Güneş radyasyonu etkileri (S) ve Radyo sinyalleri etkileri (R). Her başlık da 1 ile 5 arasında ölçeklenmiş. Her 3 başlıktan en yüksek ölçekte olabilecekler şöyle listlenmiş:

G5: Elektrik hatlarında yaygın bir şekilde görülebilecek voltaj kontrol sorunları, trafo hasarları. Uçak ve diğer hava araçları yön bulma ve iletişim sorunları yaşayabilir. Araçlarda yüzey gerilimleri artabilir. Boru hatlarında yüzlerce amperlik akımların oluşabilir. Yüksek frekanslı iletişim günlerce mümkün olmayabilir, kutup ışıkları 40 derece boylamlarda bile görülebilir. Trafolar hasar görebilir. Kablosuz iletişim sistemleri çalışmaz.

S5: Uluslararası Uzay İstasyonu gibi konumlarda korunmasız olarak çalışan astronotlar, yüksek irtifada yolculuk eden uçak yolcuları ve mürettebatı yüksek seviye Güneş radyasyonuna maruz kalabilir. Güneş panellerinde kalıcı hasarlar oluşabilir. HF iletişiminde kesintiler oluşur. GPS sistemleri çalışmaz.

R5: Dünya'nın güneşe bakan yarısında yüksek frekans kablosuz iletişiminde kesinti yaşanabilir, düşük frekanslı navigasyon sinyallerine erişilemeyebilir.

Bir de Güneş Akısı (Solar Flux) seviyeleri var. Bunun birimi SFU (Solar Flux Unit). Güneş'in minimum seviyesinde bu 70 SFU'lara kadar düşüyor, maksimumlarda 200 SFU'nun üzerine çıkabiliyor.

SWPC'dan gelen 3 günlük alarm mesajlarından bir alıntı aşağıdaki gibi:

The greatest observed 3 hr Kp over the past 24 hours was 4 (below NOAA
Scale levels).
The greatest expected 3 hr Kp for Jan 02-Jan 04 2024 is 5.00 (NOAA Scale
G1).

NOAA Kp index breakdown Jan 02-Jan 04 2024

        Jan 02    Jan 03   Jan 04
00-03UT 3.00      3.33     2.00
03-06UT 3.33      3.67     2.67
06-09UT 5.00 (G1) 3.67     2.00
09-12UT 4.67 (G1) 3.00     2.00
12-15UT 4.00      2.33     2.00
15-18UT 3.67      2.00     2.00
18-21UT 3.33      2.00     2.00
21-00UT 3.67      2.33     2.33

Rationale: G1 (Minor) geomagnetic storms are expected in response to the
passage of a transients solar wind features.

B. NOAA Solar Radiation Activity Observation and Forecast

Solar radiation, as observed by NOAA GOES-16 over the past 24 hours, was
below S-scale storm level thresholds.

Solar Radiation Storm Forecast for Jan 02-Jan 04 2024

Jan 02 Jan 03 Jan 04
S1 or greater 25% 25% 25%

Rationale: No S1 (Minor) or greater solar radiation storms are expected.
No significant active region activity favorable for radiation storm
production is forecast.

C. NOAA Radio Blackout Activity and Forecast

Radio blackouts reaching the R1 levels were observed over the past 24
hours. The largest was at Jan 01 2024 1225 UTC.

Radio Blackout Forecast for Jan 02-Jan 04 2024

              Jan 02 Jan 03 Jan 04
R1-R2         60%    60%    60%
R3 or greater 25%    25%    25%

Rationale: R1-R2 (Minor - Moderate) radio blackouts are expected, with a
chance for strong or greater radio blackouts.

İlk satırda geçtiğimiz 24 saatlik dönemde 3 saatlik dilimlerde gözlemlenen Kp seviyesinin en yüksek değeri 4 olarak belirtilmiş. Bu da belirtilen ölçekte ortanın düşüğü. Bir sonraki gün (02-Jan) için beklenen en yüksek seviyenin 5 olduğu ve bunun da G1 seviyesine denk geldiği belirtilmiş. Bir sonraki bölümde 3 saatlik dilimlerde beklenen seviyeler listelenmiş. Saatler UTC olarak. Türkiye saatine çevirmek için 3 eklemek gerek. Daha sonraki bölümlerde G1 ve S1 gibi seviyelerin beklendiği belirtilmiş, radyo frekansı iletişiminde de R1-R2 seviye kesinti beklentisinin 2,3 ve 4 Ocak'ta %60 olduğu, R3 beklentisinin ise %25 olduğu belirtilmiş.

Buna ilave olarak bir de her gün 3 saatte bir (3,6,9... gibi 3'ün katları saatlerde, merkezi saat) gelen Geophysical Alert Message (WWV) mesajları var. Bunların içeriği de şöyle:

Solar-terrestrial indices for 01 January follow.
Solar flux 136 and estimated planetary A-index 10.
The estimated planetary K-index at 1200 UTC on 02 January was 2.00.

Space weather for the past 24 hours has been minor.
Radio blackouts reaching the R1 level occurred.

Space weather for the next 24 hours is predicted to be moderate.
Geomagnetic storms reaching the G1 level are likely.
Radio blackouts reaching the R2 level are likely.

Burada da ilk bölümde bir önceki gün (1 Ocak) Güneş akısı 136 olarak ölçülmüş ve A endeksi 10 (düşük) olarak belirlenmiş. 2 Ocak'ta (bugün) merkezi saatle 12:00'de K endeksi 2.00 (düşük) olarak tahmin edilmiş. Son 24 saatte kablosuz iletişim kesintileri R1 seviyesinde (düşük) görülmüş, sonraki 24 saatte yaşanabilecek hadiseler orta seviyede tahmin edilmiş. G1 seviyesinde (düşük) Güneş fırtınaları ve R2 (düşük) seviyesinde kablosuz iletişim kesintileri beklendiği belirtilmiş.

Abonelik sayfasında Forecast and Summaries bölümünden erişilen bir Geoalert mesajı var, aşağıdaki gibi ve şu web sayfasında da yayınlanan gibi.

Geoalert WWA003
UGEOA 20401 40103 0330/ 9930/ 
12031 20031 30031
99999
UGEOE 20401 40103 0330/ 02/01
18022 1830/ 18562 21199 01302 0//// ///// 9////
99999
UGEOI 20401 40103 0330/ 02///
10059 21420 3008/ 4///0 50100 67807 71405 80104 90300
99999
UGEOR 20401 40103 0330/ 02/24 03104
13534 20000 30000 42012 50010 60004 32212 00000
13535 20000 30500 41001 50010 60002 38908 00000
13536 20000 30510 45323 50240 60011 14905 29622
13537 20000 30000 43312 50040 60002 14818 02000
99999

Bu kodlanmış bir mesaj ve sadece gözle inceleyerek anlam çıkartmak zor, bu gibi bir mesajı ancak bir program aracılığıyla çözebiliriz. Ne olduğunu bilmeden seçtiğim ama sonradan aboneliğinden çıktığım bir mesaj türü.

Umuyoruz ki bir sonraki patlamaya hazırlıklı oluruz, çok büyük hasarlar yaşanmaz.