23.05.2017

Fedora, h.264 ve Firefox'ta bazı videoların oynatılamaması

Stackskills.com'da bazı videoların Fedora'da oynatılamaması üzerine nelerin yanlış olabileceğine dair bir dizi araştırma yaptım. Oynatılmayan videolarım için ekranda hiçbir resim veya video kontrolleri görünmediği gibi hiçbir hata da almıyordum. Başka videoların oynatılıp oynatılmadığını denemek için Youtube ve Dailymotion'a girdim, sorun yoktu.

Sonra aynı videoları Windows üzerinde Firefox'ta oynatmayı denedim, sorun çıkmadı. Videoların flash ile değil de HTML5 ile oynatıldığını test etmek için youtube.com/html5 adresine gittim. Burada Windows ve Linux için farklı sonuçlar elde ettim.



Görülen o ki Fedora'da h.264 kodeği yoktu. Bunu nasıl kurmalı acaba diye düşünürken şu sayfaya denk geldim. Buna göre öncelikle varsayılan olarak etkinleştirilmemiş durumda gelen bir depoyu etkinleştirmek gerekiyordu:
sudo dnf config-manager --set-enabled fedora-cisco-openh264
Ardından da mozilla entegrasyonu ve Gstreamer eklentisini kurmak önerilmiş. Ama bende fayda etmedi:

sudo dnf install mozilla-openh264 gstreamer1-plugin-openh264
Bu aşamada hala Firefox youtube.com/html5 sayfasında h.264 için mavi onay işaretini vermiyordu. Bu sayfanın altındaki yorumlarda Martin Stransky Firefox'un artık gstreamer desteğini bıraktığını, rpmfusion.org'tan ffmpeg-libs paketine ihtiyacımızın olduğunu yazmış. Bu durumda ffmpeg-libs paketinin kurulu olduğundan emin olmak lazım.
sudo dnf list installed ffmpeg-libs
Kurulu değilse kurmak için yine aynı sayfada Tom G. çözüm için şu satırları yazmış:

sudo rpm -Uvh http://ftp.riken.jp/Linux/rpmfusion/free/fedora/rpmfusion-free-release-24.noarch.rpm
sudo rpm -Uvh http://ftp.riken.jp/Linux/rpmfusion/nonfree/fedora/rpmfusion-nonfree-release-24.noarch.rpm
sudo dnf install -y ffmpeg-libs
Bu noktadan sonra sorun giderildi.

NOT: Alternatif olarak doğrudan rpmfusion.org kurulumu yöntemi de uygulanabilir. Bunun için şu sayfasındaki adımlar uygulanabilir.

16.01.2017

Fedora'da i ve ı harflerini basamamak

Fedora'yı 24'ten 25'e yükseltince i ve ı harflerini (küçüç/büyük) basamadığımı farkettim. Arama yaptığımda bu sorunun aslında 22'den beri olduğunu, ancak bazı donanımlarda ortaya çıktığını gördüm. Gerçi benim makinemde birkaç sürümdür kuruluydu Fedora ama nedense 25. sürümde ortaya çıkmaya karar vermiş. Çözüm olarak Wayland'i GDM için devre dışı bırakmaktan bahsedilmiş. Bunun için tercih edilen metin editörünüzü root ile çalıştırdıktan sonra
/etc/gdm/custom.conf 

dosyasını açarak
#WaylandEnable=false
satırının başındaki # işaretini kaldırarak
WaylandEnable=false
haline getirip kaydetmek ve sistemi tekrar başlatmak gerek. i harfine basamadan favori metin editörümü root ile başlatmak için biraz yaratıcılığımı kullanmam gerekti :)

Bunun uzun vadede ne gibi sonuçları olacak, bilmiyorum. Gelecekte bir ara bunu değiştirmek gerekebilir ama sürüm 22'de bile aynı hataların alındığını görünce bunun pek kısa vadede olacağını da sanmıyorum.

5.01.2017

Windows ve Bellek

Windows'da bellek kullanımı konusu oldukça karmaşık bir konudur. Görev Yöneticisinde yer alan sanal bellek, çalışan küme, takas dosyası gibi terimler kafaları karışabilir. En basitinden bir programın işletim sisteminden ne kadar bellek talebinde bulunduğunu nasıl anlayabiliriz?

Windows'da genel olarak bellek konusu sadece fiziksel bellek (RAM) ile sınırlı değildir. Ana kartın bellek yuvalarına takılan RAM ünitelerinden bağımız olarak, çalışan her süreç için geniş bir sanal adres alanı sunulur. 32-bitlik sistemlerde bu 2 GB, yeni 64-bitlik sistemlerde ise bu çok daha fazladır (128 GB gibi). Bu sanal bellek elbette. Her çalışan program 128 GB bellek kullanabilir demek değil.

İşletim sisteminde ise belli bir sınıra kadar çalışan süreçlere bellek tahsisi yapılabilir. Bu sınır da makinedeki RAM ile takas dosyası boyutunun toplamı kadardır. Bu değere kaydetme sınırı (commit limit) denir.

Diyelim ki Word'ü açtık ve uzunca bir belge hazırladık. İçine de bir sürü resim ekledik, tablolar falan... Derken sayfalarca uzunluğunda bir belge oluştu. Bunu yaparken uzun bir süre harcadık. Nihayetinde Word yazdığımız tüm içeriği kaybetmememk için işletim sisteminden sürekli bellek talebinde bulundu, bunları hafızada tuttu. Bunu yaparken de arka planda diyelim ki müzik dinliyorduk, Firefox'ta bir sürü sekme açıktı, ayrıca bir sürü başka program da açıp kapattık, bellek ihtiyacı sadece Word ile sınırlı kalmadı. Bu sürede bilgisayar Word için ayrılan bellek miktarının bir kısmını boşaltarak diğer uygulamalara verir. Ancak Word'ün verilerini de kaybetmemek için onları takas dosyasına yazar. Bu işi yaparken de en eski oluşturulmuş, en uzun süre önce üzerinde işlem yapışmış bellek alanlarını seçer. Word tekrar bu verilere ihtiyaç duyduğu anda ise bu bellek alanı takas dosyasından okunarak tekrar belleğe alnır; muhtemelen başka programların uzun süredir kullanılmayan verilerini yine takas dosyasına kaydederek.

Burada şu ayrımı yapmak gerek; Word ile çalışırken verilerin bir kısmı bellekte tutuluyordu, diğer bir kısmı da takas dosyasında tutuluyordu. Başka programlar için de aynı şey geçerli. Firefox yeni açtığım sekmeye ait verileri bellekte tutarken, ilk açtığım sekmedeki verileri takas dosyasına atmıştı. Bu süreçlerden her biri sanal bellek alanında 2 GB'a kadar adresleme yapıyor olabilir, ancak her süreç için bellekte ayrılabilecek o kadar alan olmayabilir. Bu durumda bu 2 GB'lık sanal bellek alanındaki verilerin bir kısmı bellekte değil, takas dosyasında tutuluyor olabilir.

Ayrıca Word bazı sistem özellikerini kullanabilmek için (pencereyi çizebilmek, yapılandırma diyaloglarını görüntüleyebilmek, yazıcıdan çıktı alabilmek vs) bazı sistem dll dosyalarını yükleyecek ve kullanacaktır. Bu veriler diğer süreçlerle paylaşılan bir bellek alanı oluşturur.

Bu noktada bazı bellek terimlerini isimlendirelim:

Çalışma kümesi (working set) : Süreç tarafından işletim sisteminden talep edilen ve henüz bellekte tutulan (takas dosyasına gönderilmemiş) alan ile paylaşılan (dll dosyaları gibi) veriler. Bu alanda hem sürece özel üretilen veriler hem de paylaşılan kodlar depolanır.

Ayırma boyutu (commit size) : Bu ise programa tahsis edilen tüm sanal bellek miktarını gösterir. Bu veriler paylaşılmış veriler değil, diğer süreçler tarafından erişilemeyen, bu süreç tarafından üretilen özel verilerdir. Çalışma kümesinden farklı olarak bu rakama dahil olan bellek alanlarının tümünün RAM'de tutulduğunun garantisi yoktur. Eski verilerin bir kısmı takas dosyasına gönderilmiş olabilir. Bu alanda paylaşılan kodlar depolanmaz.


Yukarıdaki ekran görüntüsünde de notepad.exe sürecinin kullandığı bellek alanını inceleyelim. Bu resimde bellek ile ilgili iki sütun görüntüleniyor; Çalışma Kümesi ve Ayırma Boyutu. Notepad.exe için Çalışma Kümesi sütununda gösterilen 12.744 KB veri doğrudan RAM üzerinde tutulan not defteri verisi. Ancak buna paylaşılmış bellek (dll gibi) de dahil. Ayırma Boyutu sütununda gösterilen rakam ise not defteri tarafından ihtiyaç duyulan tüm veri miktarını gösterir. Bunun bir kısmı takas dosyasında olabilir, ancak bu rakama paylaşılan bellek miktarı dahil değildir.

Bu alanlara ek olarak Windows 7 ve sonrası sürümlerde gelen "Özel Çalışma Kümesi" alanı var. Bu alana paylaşılan bellek miktarı dahil değil. RAM'de saklanan sürecin özel verilerini gösteriyor. Bu alanı görebilmek için menüden Görünüm>Sütun Seç ile Bellek-Özel Çalışma Kümesi'ne ait kutuya işaret koymamız gerek.


Görüldüğü gibi not defteri için özel çalışma kümesi de 7.947 KB. Çalışma Kümesi alanından bu veriyi çıkartarak 4.797 KB'lık veri paylaşılan bellek miktarı oluyor. Not defterin ayrılan toplamda 8.216 KB'lık verinin ne kadarı takas dosyasına atılmış olabilir? 8216'dan 7948'i çıkararak bulabileceğimiz 268 KB da "muhtemelen" takas dosyasına atılan miktar olabilir. Muhtemelen diyorum, süreçlere ait uzun süredir kullanılmayan alanlar hemen takas dosyasına gönderilmez. Bir süre daha belleğin bekleme alanında bekletilir, tekrar ihtiyaç duyulma ihtimaline karşı. Bir süre sonraki durak elbette takas dosyası olacaktır.

Bellekteki bu işlemler "sayfa" denen 4 KB'lık bölümler üzerinden yapılır. Tüm bellek 4 KB'lık sayfalara bölünmüştür. Süreç, işletim sisteminden her yeni bellek talep ettiğinde bu sayfaların katı miktarda alan tahsis edilir. Bellekten takas dosyasına veya tam tersi yöndeki taşıma işlemlerinin tümü bu 4 KB'lık sayfa boyutu üzerinden yapılır. Bellekte en uzun süredir kullanılmayan alanlar yine bu sayfa boyutları üzerinden belirlenir. Yani 1 byte'lık bir alan bile talep edilse 4 KB'lık bir sayfa ayrılır. Bu sebeple yukarıdaki bellek verilerinin tümü 4'e bölünebilen sayılardır.

Bir sürecin erişmek istediği veri doğrudan çalışma kümesi içindeyse o verilere doğrudan erişir, veriler veya kodlar farketmez. Ancak veriler ayırma boyutu alanına taşınmışsa onlara doğrudan erişeyecek, erişim bir sayfa hatasına (page fault) sebep olacaktır. Söz konusu sayfa henüz bekleme alanındaysa (standby memory) bu bir yazılımsal sayfa hatası (soft page fault), aksi takdirde veri takas dosyasına gönderildiyse bir donanımsal sayfa hatasına (hard page fault) sebep olur. Görüldüğü gibi sayfa hatalarının aslında bir hatayla ilgisi yok, tamamen normal bir işleyiş.

Örneğin Word ile hazırladığımız belgenin yazıcıdan çıktısını almak istiyoruz. Menüden yazdır komutunu verdikten sonra sistem yazıcı ile ilgili sistem dosyalarına ihtiyaç duyacaktır. Bu sistem dosyaları bilgisayar açıldığından beri hiç kullanılmadıysa (veya kullanıldıysa bile üzerinden yeteri kadar uzun bir süre geçtiyse ve artık hafızada değillerse) bir donanımsal sayfa hatası oluşur. Veriler diskten okunur, işlevlerin kullanılabilmesi için gereken yordamlar belleğe alınır. Bu miktar çalışma kümesi alanına eklenir. Aradan bir süre geçtikten sonra bu sistem dosyaları için ayrılan alan önce bekleme alanına gider. Tam bu anda tekrar çıktı almak istersek bu sistem dosyalarına yapılan referans için bir yazılımsal sayfa hatası oluşur, diske hiç ihtiyaç duyulmadan işlem tamamlanır. Ama yeteri kadar uzun süre geçtikten sonra tekrar çıktı almak istersek bu bir donanımsal sayfa hatası oluşur. Veriler tekrar diskten okunur. Ama bu veriler paylaşılan sistem dosyalarına ait olduğu için bu veriler hiçbir zaman takas dosyasına yazılmaz, doğrudan diskten tekrar okunur.


Windows sanal bellek miktarı üzerindek çalışan bir işletim sistemi olduğundan, her bir sürece yapılan sanal bellek atamalarının (ayırma boyutu / committed bytes) toplamı ile çekirdek (kernel) işlemleri için yapılan bellek ayırmaların sayfalanmış (paged) miktarının toplamı sistem toplam kaydetme miktarı (commit charge) ile ifade edilir. Eğer bu miktar sistem ayırma sınırına (system commit limit, yukarıda açıkladığım gibi sistem RAM'i ile takas dosyasının boytunun toplamı) ulaşırsa bellek problemi uyarıları ile karşılaşırız. Takas dosyası otomatik olarak (eğer öyle ayarlandıysa) büyütülmeye çalışılır. Çok nadir de olsa bu gibi durumlarla karşılaşıldığında hangi sürecin bu durumda aşırı bellek kullandığını incelemek gerekebilir.

Çok uzun oldu. Evet, anlaşılması da kolay olmadı, Türkçe terimleri de işin içine katınca. Üzgünüm.

30.11.2016

ICMP ve TTL değerleri

Bugüne kadar ping sonuçlarını incelerken farklı TTL (Time To Live) değerleri hiç ilgimi çekmemişti. Geçilen her düğümde bu değerin bir düşürüldüğü ve 0'a ulaştığında ise paketin artık daha fazla yönlendirilmediği temel bilgisine sahiptim, ama neden bazen 50-60'lı değerler görürken bazen bu 200+ oluyordu? Acaba arada bu kadar fazla düğüm olması ihtimali mi vardı?

Bugün bu konuya biraz zaman ayırdım. Gördüm ki bu farklılık hedef sistemin yapısıyla ilgilymiş. Ping request işlemini başlatan tarafla hiç ilgilsi yokmuş. Karşı taraftaki işletim sisteminin belirlediği bir değermiş. Farklı işletim sistemlerinin farklı TTL seviyeleri oluyormuş. Şu sayfada ayrıntılı bir liste verilmiş.

Device / OS Version Protocol TTL
AIX TCP 60
AIX UDP 30
AIX 3.2, 4.1 ICMP 255
BSDI BSD/OS 3.1 and 4.0 ICMP 255
Compa Tru64 v5.0 ICMP 64
Cisco ICMP 254
DEC Pathworks V5 TCP and UDP 30
Foundry ICMP 64
FreeBSD 2.1R TCP and UDP 64
FreeBSD 3.4, 4.0 ICMP 255
FreeBSD 5 ICMP 64
HP-UX 9.0x TCP and UDP 30
HP-UX 10.01 TCP and UDP 64
HP-UX 10.2 ICMP 255
HP-UX 11 ICMP 255
HP-UX 11 TCP 64
Irix 5.3 TCP and UDP 60
Irix 6.x TCP and UDP 60
Irix 6.5.3, 6.5.8 ICMP 255
juniper ICMP 64
MPE/IX (HP) ICMP 200
Linux 2.0.x kernel ICMP 64
Linux 2.2.14 kernel ICMP 255
Linux 2.4 kernel ICMP 255
Linux Red Hat 9 ICMP and TCP 64
MacOS/MacTCP 2.0.x TCP and UDP 60
MacOS/MacTCP X (10.5.6) ICMP/TCP/UDP 64
NetBSD ICMP 255
Netgear FVG318 ICMP and UDP 64
OpenBSD 2.6 & 2.7 ICMP 255
OpenVMS 07.01.2002 ICMP 255
OS/2 TCP/IP 3.0 64
OSF/1 V3.2A TCP 60
OSF/1 V3.2A UDP 30
Solaris 2.5.1, 2.6, 2.7, 2.8 ICMP 255
Solaris 2.8 TCP 64
Stratus TCP_OS ICMP 255
Stratus TCP_OS (14.2-) TCP and UDP 30
Stratus TCP_OS (14.3+) TCP and UDP 64
Stratus STCP ICMP/TCP/UDP 60
SunOS 4.1.3/4.1.4 TCP and UDP 60
SunOS 5.7 ICMP and TCP 255
Ultrix V4.1/V4.2A TCP 60
Ultrix V4.1/V4.2A UDP 30
Ultrix V4.2 – 4.5 ICMP 255
VMS/Multinet TCP and UDP 64
VMS/TCPware TCP 60
VMS/TCPware UDP 64
VMS/Wollongong 1.1.1.1 TCP 128
VMS/Wollongong 1.1.1.1 UDP 30
VMS/UCX TCP and UDP 128
Windows for Workgroups TCP and UDP 32
Windows 95 TCP and UDP 32
Windows 98 ICMP 32
Windows 98, 98 SE ICMP 128
Windows 98 TCP 128
Windows NT 3.51 TCP and UDP 32
Windows NT 4.0 TCP and UDP 128
Windows NT 4.0 SP5- 32
Windows NT 4.0 SP6+ 128
Windows NT 4 WRKS SP 3, SP 6a ICMP 128
Windows NT 4 Server SP4 ICMP 128
Windows ME ICMP 128
Windows 2000 pro ICMP/TCP/UDP 128
Windows 2000 family ICMP 128
Windows Server 2003 128
Windows XP ICMP/TCP/UDP 128
Windows Vista ICMP/TCP/UDP 128
Windows 7 ICMP/TCP/UDP 128
Windows Server 2008 ICMP/TCP/UDP 128
Windows 10 ICMP/TCP/UDP 64

Bu konunun özetini de sayfanın altında çıkarmış. Buna göre hedef bir Linux ise TTL'i 64'ten, bir Windows ise 128'den, bunun yanısıra bir Cisco cihazı / Solaris ise 254'ten başlıyormuş geriye sayım.

21.11.2016

VMware'de Linux sanal makineler ve dosya paylaşımı

Linux sanal makineler için eskiden VMware Workstation'da vmtools kurulumu başarılı sonuçlar verirdi, ama artık olmuyor. Bunun yerine artık open-vm-tools paketi öneriliyor. Paylaşım için yapılacaklar; linux kurumu bittikten sonra hiç VMware Tools kurulumuna girmeden, eğer kurulu değilse open-vm-tools paketini kurmak. Birçok dağıtımda zaten kurulu geliyor. Gelmezse
sudo dnf install open-vm-tools
sudo apt install open-vm-tools
ile kurulum yapılabilir. Bu aşamadan sonra VMware Workstation'da evsahibi makinede (host) klasör paylaştırılabilir. Sanal makineden paylaştırılan klasörü görüntülemek için vmware-hgfsclient kullanılabilir.
vmware-hgfsclient
share
Ardından vmhgfs-fuse ile mount etme yapılır
vmhgfs-fuse .host:/share /home/username/folder
Elbette /home/username/folder yolu var olan bir klasör ile değiştirilmeli.

2.09.2016

Windows'da bilimum dosya hash'lerini hesaplama

Download edilen bir dosyanın doğru bir şekilde download edildiğini bilmek bazen hayati önem taşıyor. Linux'ta hash'leri

$ md5sum dosya-adı
$ sha1sum dosya-adı
$ sha256sum dosya-adı
$ sha51sum dosya-adı
gibi komut satırı programları aracılığıyla hesaplayabiliyoruz. Ama Windows'da bu yoktu (fciv vardı ama sha256 hesaplamıyordu mesela). Ben de üçüncü parti yazılımlarla bunu çözmeye çalışıyordum. Ama PowerShell'de bunu yapan bir cmdlet olduğunu öğrenince çok hoşuma gitti. Aşağıdaki gibi çok sayıda hash hesaplaması yapmak mümkün:
PS> Get-FileHash dosya-adi -Algorithm md5
md5 yerine aşağıdaki hash algoritmalarını kullanabiliriz. Burada da tab tuşu ile tamamlama mümkün.
  • SHA1
  • SHA256
  • SHA384
  • SHA512
  • MACTripleDES
  • MD5
  • RIPEMD160
Çevrim içi yardım için şu link kullanılabilir.

Bir klasörde birden fazla dosyanın hash'lerini hesaplatmak için ise şöyle bir komut uygun olur:
PS>Get-ChildItem E:\ISO\*.iso | Get-FileHash

9.04.2015

Log Parser Studio (LPS)

Çok sevdiğim bir araç vardı: Log Parser. Her türlü log formatını okuyabilen, SQL sorguları ile logların üzerinde işlem yapılmasını sağlayan Microsoft aracı olan Log Parser, artık Log Parser Studio (LPS) olarak görsel bir arayüze kavuştu.

LPS'nin babası olan Log Parser, Exchange Server geliştiricileri tarafından logların incelenmesi amacıyla tasarlanmış bir araç. LPS de bu amaçla büyük işler başarıyor. Ama bununla sınırlı değil. Web server logları, Windows Evet Log'ları hatta başka log formatlarını kolayca okuyabiliyor. Dahası grafikler çizebiliyor.


Varsayılan olarak üzerinde bir çok örnek sorgu ile geliyor. Tek yapmak gereken logları nereden okuyacağını seçmek. Örnek olarak Exchange protokol loglarını (RECEIVE) incelemekle başlayalım. Server üzerinden ilgili loglara ister doğrudan erişebilir, istersek de bu dosyaları sabit diskinizin içindeki bir klasöre kopyalayıp devam edebiliriz. D:\Logs klasörüne kopyaladığımızı düşünelim. Araç çubuğundaki Log butonuna (soldan 5. buton) basarak loglarımızın yerini gösterelim.


Arından yeni bir sorgu yaratma butonuna (en soldaki) basarak pencerenin alt bölümündeki sorgu ekranına şu satırları yazarak başlayalım:
SELECT *
FROM '[LOGFILEPATH]'
WHERE (context LIKE '%LogonDenied%')
Bu şekilde SMTP receive logları üzerinden gelen yanlış kullanıcı adı / parola hatasına sebep olan LogonDenied kayıtlarına ulaşabiliriz. Log tipini seçmeyi unttum. Bunun için de sorgu ekranının hemen üzerinde kalan Log Type bölümünden EELLOG'u seçmek gerek. İstenirse SELECT * yerine daha net alanlar belirtilebilir. Örneğin şöyle bir sorgu sonuçları güzel oluyor:

SELECT ADD(TO_TIMESTAMP(EXTRACT_PREFIX([#Fields: date-time],0,'.'),'yyyy-MM-ddTHH:mm:ss'),SYSTEM_UTCOFFSET()) AS LocalDateTime,
session-id, connector-id, [sequence-number] AS SeqNum, [remote-endpoint] AS RemoteIP, event, data, context FROM '[LOGFILEPATH]'
WHERE (context LIKE 'User Name:%')
Burada SELECT'ten sonra gelen ilk alanda log satırındaki tarih ve saat alanı uygun TIMESTAMP'e çevrilip yerel saate göre ayarlanıyor.

Başka bir örnek olarak WEB sunucu üzerindeki muhtemel SQL injection denemeleri görülebilir:

SELECT TO_TIMESTAMP(date,time) as DateTime, cs-uri-stem as page, cs-uri-query as query, c-ip as RemoteIP, sc-status as StatCode, cs(User-Agent) as UserAgent
FROM '[LOGFILEPATH]'
WHERE ((query LIKE '%--%') or (query LIKE '%@@%') or (query LIKE '%version%') or (query LIKE '%exec%') or (query LIKE '%declare%') or (query LIKE '%cast%') or (query LIKE '%select%') or (query LIKE '%union%') or (query LIKE '%update%')) and (StatCode=200)
ORDER BY DateTime ASC
Burada adres satırıından gönderilen bazı anahtar kelimelerin varlığı denetleniyor. Bu tam bir SQL injection varlığı belirlemesi olmayabilir, ama yine de faydalı bilgiler verir.

Ve en sevdiklerimden biri, domain controller'lar üzerinde oluşan account lockout olaylarının takibi için Security log'da 4625 (hatalı kullanıcı adı/parola) ve 4740 (lockout) olayları aranıyor.
SELECT TOP 100 TimeGenerated, EventID, ComputerName,
EXTRACT_TOKEN(Strings,0,'|') AS Field_0,
EXTRACT_TOKEN(Strings,1,'|') AS Field_1,
EXTRACT_TOKEN(Strings,4,'|') AS Field_4,
EXTRACT_TOKEN(Strings,5,'|') AS Field_5,
EXTRACT_TOKEN(Strings,19,'|') AS Field_19
FROM \\server1\security,\\server2\security
WHERE (EventID=4740 OR EventID=4625)
ORDER BY TimeGenerated DESC
Bu sorgu için Log Type kısmından EVTLOG seçilmeli. Burada FROM'dan sonra '[LOGFILEPATH]' yazmaya gerek yok. Field_0'dan Field_19'a kadar olan alanlar 4625 ve 4740 olayları için önemli olabilecek bazı alanlar içeriyor.

Son olarak bir de FileZilla FTP server logları için olan sorgusu var. FileZilla FTP Server nedense garip bir log formatı seçmiş. Örneğin satırlar şöyle:

(000233) 19.09.2014 23:01:14 - (not logged in) (xxx.xxx.xxx.xxx)> Connected, sending welcome message...
(000233) 19.09.2014 23:01:14 - (not logged in) (xxx.xxx.xxx.xxx)> disconnected.
(000234) 19.09.2014 23:01:22 - (not logged in) (xxx.xxx.xxx.xxx)> Connected, sending welcome message...
(000234) 19.09.2014 23:01:24 - (not logged in) (xxx.xxx.xxx.xxx)> USER zxin10
(000234) 19.09.2014 23:01:24 - (not logged in) (xxx.xxx.xxx.xxx)> 331 Password required for zxin10
(000235) 19.09.2014 23:01:25 - loggedinuser (xxx.xxx.xxx.xxx)> 200 Type set to I
(000235) 19.09.2014 23:01:25 - loggedinuser (xxx.xxx.xxx.xxx)> TYPE A
(000234) 19.09.2014 23:01:26 - (not logged in) (xxx.xxx.xxx.xxx)> QUIT
(000234) 19.09.2014 23:01:26 - (not logged in) (xxx.xxx.xxx.xxx)> 221 Goodbye
(000234) 19.09.2014 23:01:26 - (not logged in) (xxx.xxx.xxx.xxx)> disconnected.

Log dosyaları günlük olarak tutuluyor. Bu durumda yukarıdaki veriyi bir CSV (virgülle ayrılmış değerler) dosyasına yazmak için şu sorgu kullanılabilir:

SELECT SUBSTR(EXTRACT_TOKEN(Text,0,' - '),1,6) as order,
TO_TIMESTAMP(SUBSTR(EXTRACT_TOKEN(Text,0,' - '),9),'dd.MM.yyyy HH:mm:ss') as datetime,
EXTRACT_TOKEN(EXTRACT_TOKEN(EXTRACT_TOKEN(Text,1,' - '),0,'> '),0,' (') as user,
REPLACE_STR(EXTRACT_TOKEN(EXTRACT_TOKEN(EXTRACT_TOKEN(Text,1,' - '),0,'> '),1,' ('),')','') as ip,
EXTRACT_TOKEN(EXTRACT_TOKEN(Text,1,' - '),1,'> ') as message
INTO 'D:\Log\Filezilla.csv'
FROM '[LOGFILEPATH]'

EXTRACT_TOKEN() ve diğer fonksiyonlar hakkında yardım için şu sayfadan yararlanılabilir. Sayfa aslında Log Parser Plus için, ama LPS'ye de uygulanabilir.

Yetenekleri bununla kısıtlı değil. Biraz yaratıcılık, biraz da  deneme yanılmayla herşey mümkün.

15.07.2016 ekleme:
Log Parser Studio'nun bir sürü klavye kısayolu varmış; yeni keşfediyorum. Örneğin her seferinde FROM'dan sonra gelecek ve ayarlanmış log dosyası konumunu belirten '[LOGFILEPATH]' yazmak yerine F7 tuşuna basabilir ve eğer sonuçları bir CSV dosyası olarak export etmek isterseniz F8'e basabilir ve '[OUTFILEPATH]\Output.CSV' ekleyebilirsiniz. Klavye kısayollarının tam listesi için şu sayfa çok faydalı olabilir diye düşünüyordum ama sayfanı sonuna kadar okuyunca farkettim ki aslında Ctrl+K kombinasyonu klavye kısayolları sayfasını görüntülüyormuş :)