Sunucu Sıkılaştırma (Server Hardening)

Sunucu sıkılaştırması [1] siber güvenlik şemsiyesinin altında “sistem yöneticilerinin” mutlaka üzerine düşünmesi ve vakit kaybetmeden uygulamaya başlaması gereken bir kavramdır. O halde önce ne olduğunu açıklayalım;

Sunucu sıkılaştırması, sunucuların “daha” güvenli olması için gereken tüm önlemlerin standart olarak uygulanması ve ihtiyaçlara göre geliştirilmesi sürecidir.

İşletim sistemleri genel olarak güvenliği ön plana koyuyor gibi görünse de pek çok sıkı güvenlik önlemini aslında “kullanıcı inisiyatifine” bırakır. Bunun temel sebebi de “kullanıcı dostu” olabilmektir. Ancak özellikle “sunucu işletim sistemleri” için risk düşünülenden daha büyük olur. Ufak bir risk analizi yapıldığında bile bu ortaya çıkacaktır.

Öyleyse, bu işe nerden başlamalıyız?

Öncelikle bütüncül bir yaklaşımla tüm sistemlerdeki minimum güvenlik gereksinimlerini ortaya çıkarılmalıdır. Olmazsa olmaz gereksinimler harici elbette her sektörün, kurumun ve hatta kullanıcı grubunun farklı güvenlik ihtiyaçlarının olduğunu görülecektir.

Ardından hızlıca bir kontrol listesi çıkarmak da ilk adımlardan biridir. Kontrol listesi daha önce de belirttiğim gibi her ihtiyaca göre farklılık gösterse de genel kabul görmüş “olmazsa olmaz” listelerden başlamak en iyisidir. Elbette kontrol listesi Windows ve Linux sunucular için farklı olacaktır. En temel kabul edilen ve listenin başına eklenmesi gereken sıkılaştırma adımlarını ayrı ayrı inceleyelim;

Genel Sıkılaştırma Kuralları:

İşletim sistemlerinden bağımsız olarak tüm sistemlerde mutlaka olması gereken sıkılaştırma adımlarından birkaç tanesini sıralayabiliriz;

· Mutlaka kullanıcı parolalarının belli sıklıkla değiştirilmesi, kompleks olması gibi genel kural zorunlu tutulmalıdır.

· Kullanılmayan kullanıcılar etkisizleştirilmelidir. Bu madde için belli bir süre logon olmayan kullanıcıların otomatik olarak disable olması sağlanabilir.

· Backup/restore süreçleri planlamalı ve düzenli olarak test edilmelidir.


Windows Sunucu Sıkılaştırma:

Windows sunucuların bir Active Directory domainine bağlı olduğunu öngörerek pek çok sıkılaştırma özelliği Group Policy’ler aracılığı ile tüm domaine yollanabilir ve kolayca tüm sistem aynı seviyeye ulaştırılabilir. Bunun için zaten Active Directory ile gelen kurallardan da faydalanılabilirken, kendi kurallarınızın yazılabilmesi de mümkündür.

Windows sunucular için yazılabilecek temel sıkılaştırma kontrol listesi yaklaşık olarak aşağıdaki şekilde başlayabilir;

Kullanıcı İşlemleri;

* Guest hesabı mutlaka disable edilmiş olmalıdır. (Genelde yeni nesil Windows Sunucularda zaten disable durumdadır. Daha çok bakış açısı hakkında fikir vermesi için ekledim bu maddeyi J)

* Local Administrator hesabı disable edilmelidir İhtiyaç varsa da bir local kullanıcı oluşturulmalı ve Administrators grubuna eklenmeli.

* Mutlaka UAC (User Account Control) aktifleştirilmelidir.

Network;

* Windows Firewall etkinleştirilmelidir. Sadece gerekli portlar/uygulamalara izin verilmelidir. (Eğer 3 parti bir firewall kullanılmıyorsa)

* RDP Servisi sadece local erişime mümkünse belli IP’lere tanımlanmalıdır.

* İhtiyaç yoksa mutlaka internet çıkışı engellenmeli. İhtiyaç için bile kontrollü olmasına dikkat edilmelidir.

* NTP (Network Time Protocol) aracılığı ile mutlaka tüm sunucuların saatleri senkron olmalıdır.

* IPv6 kullanılmıyorsa disable edilmeli

Uygulama ve Servisler

* Antivirüs & Antispyware mutlaka kurulu olmalı ve merkezi bir antivirüs & antispyware sunucu tarafından denetlenip, güncellenmelidir.

* Kullanılmayan Windows Servisleri mutlaka kapatılmalı & kaldırılmalı (File share, printer vs.)


Windows update

* Sunucular mutlaka Windows güncellemelerini otomatik almalı ve mümkün olan en kısa zamanda yeniden başlatılmalıdır.


Linux Sunucu Sıkılaştırma:

Linux sunucular genel görüşte büyük bir önyargı olarak “güvenli” kabul edilirler. Hatta işletim sistemi güncellemelerinin bile önemsenmediği görülebilir. Ancak bu önyargı çok büyük zararlara sebep olabilir. Bu yüzden başta işletim sistemi düzenli güncellemelerinin planlaması ve uygulanması düşünülmelidir. Ayrıca kontrol listesi için de aşağıdaki maddeler ele alınabilir;

* SELinux mutlaka aktif olmalıdır.

* Root login disable edilmelidir. Gerekli kullanıcılar için sudo yetkisi tanımlanmalıdır.

* İhtiyaç yoksa mutlaka XWindow silinmelidir. Dağıtıma göre eğer izin veriyorsa en başta kurulmamalıdır.

* /usr, /home, /var, /var/log, /tmp dizinleri farklı disk bölümlerine (partition) tanımlanmalıdır.

* Disk Kotaları belirlenmelidir.

* IPv6 kullanılmıyorsa disable edilmeli

* SSH için password tabanlı login yerine public key tabanlı login düşünülmelidir.

* SSH için ek güvenlik önemleri düşünülmelidir. SSH Linux sunucuların dışarıya açılan kapısı olduğu için bu konu belki başlı başına bir makale konusu olabilir. Ancak vekil sunucu üzerinden bağlanmak vs. gibi yöntemler araştırılmalı ve uygulanmalıdır.

* Official repository dışından uygulama kurulumları&güncellemeleri engellenmeli

 

Uygulama Sıkılaştırma:


Uygulama sıkılaştırılması (Application Hardening) ise daha çok yazılım geliştirme süreçlerinde dikkate alınması gereken ve mutlaka uygulanması gereken bir kısımdır. Güvenlik tek bir açıdan bakılamayacak kadar geniş ve bir anlamda şemsiye gibi kaplayan bir konu olduğu için bu makalede yol gösterici bir başlık olarak bulundurmak istedim. Özellikle uygulama geliştirme yapanlar mutlaka bu konuyu araştırıp üzerine çalışmalıdır.

 

Sonuç:

Sunucu (veya sistem) Sıkılaştırılması, bir kez yapılıp bırakılabilecek bir işlem değil, yaşayan, değişen ve sürekli iyileştirilip geliştirilmesi gereken bir süreçtir. Ayrıca sadece kurum için güvenlik ekibinin değil, aslında tüm çalışanların da katkı sağladığı bir kavramdır. Bu sebepledir ki, son cümlede mutlaka belgelendirmenin de önemine işaret etmek gerekir. Bu uzun ömürlü bir süreç olduğundan sıkılaştırma kontrol listeleri, adımları, önceki ve sonraki versiyonları açık ve erişilebilir olmalıdır.



Emre Karaoğlu

Nisan 2021 [2]


[1] İngilizce karşılığı “Server Hardening” diye sabitlense de Türkçe karşılığı birkaç farklı şekilde söylenebiliyor. Ben kendi adıma en uygun bulduğum “sıkılaştırma” karşılığını kullanmayı tercih ediyorum.

[2] Bu yazıyı Nisan 2021 yılında Arka Kapı Dergisinde yayınlanması için hazırlamıştım. Bu sebeple de hiç bir mecrada yayınlamadım. Dergi yayın hayatını bitirdiğine göre, emeğimi yayınlamakta sakınca görmedim. :)  

OPS Dünyasında 2021 trendleri :-)

Muhammed (Muhammed Hilmi Koca, twitter: @mhk_developer ), sanırım benden yaşça daha küçük (bu yüzden ismiyle hitap etmemden rahatsız olacağını sanmam) ve yaptığı işleri takip ettiğim kadarıyla başarılı, sevdiğim bir arkadaşımız. Tesadüfen twitter’da karşılaşıp takip etmeye değer buldum. Geçen yıl keyifle okuduğum “yazılımcılar için 2020trendleri” yazısının yenisini geçen günlerde yayınladı.(Yazılım Dünyasında 2021 Trendleri) Bir eksikle; bana sormamış benim fikrimi almamıştı.:p Şaka bir yana da yazıyı okurken aklımda “acaba bana sorsaydı, sistemci gözüyle 2021 trendleri ne yazardım?” diye düşündüm. Sistemci dediğime de bakmayın, eski tabirle öyle diyorum. Aslında “sistem/network/alt yapı” (kısaca OPS diyelim) tarafını düşünelim. Kabaca aşağıdaki gibi bir şeyler çiziktirdim; (tıkırdattım daha doğru olabilir gerçi)

2020 herkes için değişik bir yıl olunca 2021 beklentilerini de aynı oranda etkilediğini düşünüyorum. Tabi ki uzaktan çalışma modeli, kurumların da hızlıca bazı konulara entegre olmasını sağladı. Ancak bu önceden de uzaktan çalışmayı deneyen kurumların “eksiklerini, ihtiyaçlarını” ortaya çıkarırken, yeni başlayanlara da bir tecrübe geliştirdi. İşte bu tecrübeler 2021 yılına geçen yıldan daha çok ışık verecek gibi görünüyor. Uzaktan çalışma konusunda temel ihtiyacımız VPN tabi ki. Ancak çoğu kurumun hızlıca VPN sorununu zaten çözdüğünü düşünüyorum. Ancak gördüğüm kadarıyla çözülmesi gereken artık VPN güvenliği olacak. VPN aracılığı ile kuruma bağlanan cihazlar (notebooklar, cep telefonları vs) hem fiziksel hem de sanal saldırılara çok açık durumda. İlk adımda çözülmesi gereken konu bu olacak. Tabi ki “canı yanmadan” hareket eden kurumlar şanslı olacaklar.

Bunun dışında aklıma gelen bir diğer konu cloud entegrasyonu olacak gibi. Özellikle Office 365, Google GSuite gibi SaaS çözümleri hem hız, hem de esneklik açısında uzaktan çalışmaya destek sağlıyor. Kurumların sadece Office için değil, ERP gibi yazılımlar için de, artık cloud desteğini arayacağını düşünüyorum.

Buradan çıkan sonuçla cloud artık kurumlar için “tü kaka” olmaktan çıkıp, ajandalarda ciddi yer alan bir sonuç olduğunu göreceğiz. Zincirleme olarak tabi ki Server/Storage kullanımında da public cloud artış gösterecek. Zaten cloud kullanan kurumlara sözüm yok ancak, evden çalışmaya mesafeli davranan kurumlara, yaşadığı covid krizinin etkisi gibi, cloud’a da mesafeli çok kurum, çalışan ve yönetici biliyorum. İşte bu direnç de bu sayede kırılmış olacak. Tabi ki OPS çalışanları -halen cloud’a geçmedilerse- hızlıca uyum sağlamaya çalışacaklar. Bu da pek çok OPS çalışanı için bir fırsata dönecektir.

Ancak bence yılın kazananı yine “hybrid cloud” olur. Pek çok could provider da zaten “on-prem’de nasıl oluruz?” sorusunun yanıtını arayıp çözümler üretiyor. Amaç daha da çok “on-prem’i öldürmeyelim, cloud gibi yönetelim” mantığına gidiyor.

Bir diğer kısım ise Devops olacak mutlaka. Artık daha çok kurum Infrastructure as Code çözümlerine kafa yormaya başladı bile. Evet bu konular yeni değil ve gündeme de yeni gelmiyor. Ancak üstte de yazdığım tüm itici güçler, bu konuların popülerliğini ve zorunluluğunu daha da artıracak. Bu yıl OPS tarafı daha da çok yazılıma yaklaşacak ve en azından Phyton, Powershell ve/veya Bash konularına daha çok kafa yoracaklar. Özellikle Powershell’in Linux desteği ile belki popülerliği daha da artabilir diye düşünüyorum. Python hakkında ise fazladan bir şey yazmaya gerek dahi duymuyorum.

Tüm bunları yazarken işletim sistemi tarafında yeni gelen haberlere göre Windows’u daha çok 2021’de değil, iyisiyle kötüsüyle 2022’de konuşacak gibiyiz. Linux ise son yıllarda hızla artan popülerliğini artırmaya devam edecektir. Linux dünyasındaki Centos projesinin bitip yerine Rocky Linux geleceği duyulunca sular biraz durulsa da, sonuçlarını bu yıl görmeyi bekliyorum. 

Network tarafında ise SDN patlama yapacak gibi. Artık SDN yatırımlarının gerekliliğini anlatmak network uzmanları için daha kolay olmaya başladı. Tabi bu da başta Python olmak üzere, network uzmanlarını daha çok “yazılım okur yazarı” olmaya yaklaştıracak bu yıl.

Kendi küçük dünyamdan bakınca, hayat daha çok böyle göründü bana. Kısa kısa, sıkıcı olmamaya çalışarak. Umarım faydalı olur.

Sevgiyle…

Mülakat sorularından derleme

Aklıma biraz geç geldi aslında ancak hem aklımda kalanlardan hem de her yerde bulunanlardan değil de, daha özel olanlardan yazmak istedim. İster mülakat sorusu deyin, ister sınav sorusu, güzel soruları biriktirmeye karar verdim. (Bu sorular (sorulanlar) bana İngilizce soruldu genelde, ama blog konseptim Türkçe içerik olduğu için ben yine Türkçe paylaşmak istedim.) Bu sorular zamanla artacak, hatta ben de "bu güzel olur" dediklerimi ekleyeceğim. Ayrıca aklınıza gelen soruları, varsa hatalarımı da yorumlara eklerseniz çok sevinirim.

Yanıtlar o konu hakkında kısa bir bilgi içeriyor. Ancak buradaki kısa bilginin detaylarını araştırıp öğrenmeyi tavsiye ederim. Çünkü eğer bir mülakattaysanız muhtemelen yanıtınızdan yeni sorular, konuyu üstün körü mü, yoksa detaylı mı biliyorsunuz diye yoklamalar olacaktır ;-) 

Ayrıca ufak ufak yorumlar da sorunun sonunda yıldızlı olacak.

Linux Soruları

1) LVM nedir?

- Logical Volume Management (LVM)kısa halidir. LVM, modüler disk kümeleri oluşturulmasını, böylece ihtiyaç halinde disk alanı üzerinde istenilen boyutlandırmanın yapabilmesini sağlar. 

* Evet bu soru çok klasikti. Ancak aslında aşağıdaki soruya giriş için bir olta diyebiliriz. Aslında bir çok soru böyle. Birbirini tamamladığını fark edeceksiniz :)

2)  LVM disk configuration nasıl yapılır?

- Aşağıdaki adımlar izlenmelidir. 
1. Fiziksel Volume oluştur:
    - pvcreate ile, yeni eklenen bir diski veya bir partition'ı veya SAN üzerindeki bir LUN'u sisteme fiziksel bir disk olarak tanıtıyoruz. 
     Örnek: 
     #pvcreate /dev/sdb
   * pvdisplay ve  pvs komutları ile disklerin durumu görülebilir

2. Volume Group oluştur:
    -  İçine logical volume'ler oluşturabilmek için Fiziksel volume'lerden bir grup oluşturuyoruz. 
   Örnek:

  # vgcreate vg-01 /dev/sdb /dev/sdc

 * vgdisplay ile volume grup'lar görülebilir. 

3. Logical Volume oluştur:
  - Logical Volume ile ihtiyacınız olan alanı mevcut volume grup içine oluşturmuş oluyoruz. 3 farklı şekilde oluşturulabilir.

• Linear Volume
• Striped Volume
• Mirrored Volume

  Örnek:  
     # lvcreate -L 1G -n lv_linear vg-01

4. LVM'yi etkinleştir:
  - Volume group ve Logical Volume oluşturulduğunda LVM otomatik olarak etkinleşir. Ancak herhangi bir sebeple etkinleşmemişse lvchange veya vgchange ile etkinleştirme yapılabilir.

* Detay için bkz: https://linoxide.com/linux-how-to/lvm-configuration-linux/


3. DNS sorgusu nasıl çalışır?

Kullanıcı bir DNS sorgusu yolladığında, IP-İsim dönüşümünü sırasıyla buralarda arama yapar;

  1. Local Cache
  2. Hosts  dosyası kayıtları
  3. Local DNS Server kayıtları ( tip: Linux için resolv.conf altında)
  4. Root DNS
  5. TLD (Top Level Domain-Üst Düzey Alan Adları)
  6. SLD-Second Level Domain -  İkinci Seviye Alan Adı) 
  7. Alt alan sunucuları

 * Not: Bu seviyelerden herhangi birinde kayda erişilirse client-server arası doğrudan iletilir. DNS yolu ters giderek sonucu iletmez. Bu da sorulabilir :-)


4.  Root DNS nasıl çalışır/Özellikleri nelerdir?

IANA tarafından yönetilen toplam 13 tane DNS IP'si vardır. (Bu 13 IP'nin bağlı olduğu dünya üzerinde binden fazla sunucu (doğrusu instances) vardır) Gelen istekleri TLD(Top Level Domain – Üst düzey Etki Alanı) sunucularına yönlendirir. TLD bir domainde gördüğümüz son kısımdır. Örneğin, .....com.tr domanin'de tr TLD'dir ancak .....com adresinde TLD com'dur.

5. dig nedir? Nasıl kullanılır? 

Dig(domain information groper) komutu, linux sistemlerde DNS sorgusu yapmak için kullanılır. Ancak nslookup'a oranla çok daha detay bilgiler sunar. Dig ile o sunucu için MX kaydı, NS kaydı gibi diğer kayıt bilgilerine de ulaşılabilir.

# dig google.com 
# dig google.com -t MX

6. DNS Kayıtlar tipleri nelerdir?

A  (Host address)
AAAA (IPv6 host address)
ALIAS (Auto resolved alias)
CNAME (Canonical name for an alias)
MX (Mail eXchange)
NS (Name Server)
PTR (Pointer)
SOA (Start Of Authority)
SRV (location of service)
TXT (Descriptive text)

7. What is the functions of /opt, /proc, /sys folders?
 
/opt : Üçüncü parti kullanıcı programlarının kurulması içindir.

/proc : Süreçler, sistem belleği, bağlı aygıtlar, donanım yapılandırmalarıyla ilgili bilgileri içeren özel bir “sanal” dosya sistemidir. Bildiğimiz anlamda fiziksel dosyalar bulundurmaz; sistem durumuna dair bilgi içeren sanal dosyaları vardır. Windows'taki görev yöneticisi gibi düşünülebilir.

/sys : Çekirdek modüllerinin sanal bir yansımasının oluşturulduğu bir dizindir. Burada yapılan değişikliklerin bazıları çekirdeğe yazılır bazıları yazılmaz.

8. /sys dizinini yedekleyip, geri döndürülür mü?

Hem / proc hem de / sys, sistemin durumunu yansıtan ve çeşitli çalışma zamanı parametrelerini değiştirmenize izin veren (ve bazen doğrudan belleğe veya bir aygıta yazma gibi daha tehlikeli şeyler yapmanızı sağlayan) sanal dosya sistemleridir. Asla yedeklememeli veya geri yüklememelisiniz.

* Tavsiye: Hazır el atmışken Linux dizin yapısını öğrenmekte fayda var. :-) 


9. MTA nedir?

MTA, "Message (veya Mail) Transfer Agent" (Mail Aktarım Ajanı) kısaltmasıdır. Bir elektronik postanın gönderen sunucudan, alıcı sunucuya, SMTP protokolünü kullanarak aktarmak ve yönlendirmekten sorumludur. TCP/25 Portunda çalışır. Linux için Postfix, Qmail, sentmail, exim, zimbra sayılabilir.

10. Bir sunucuda çalıştırdığınız bir servis ve o servisin iletişim portu var. Bu portun çalışıp çalışmadığını nasıl (hangi araçla) test edersiniz?

Telnet

* Bu basit sorunun yeri bende ayrı. Bilememiştim. Daha doğrusu çok iyi bildiğim bu yanıt aklıma gelmemişti. Genelde daha spesifik düşünüyoruz. Netstat vs. demiştim. Ancak netstat portun açık olup olmadığını test eder, çalışmasını test ederken telnet kullanıyoruz. O yüzden yazmak istedim :-) 

11. Block based backup (Blok tabanlı yedekleme) ile File based backup (Dosya tabanlı yedekleme) arasında ne fark vardır?

Blok tabanlı yedekleme ile bir disk bloğunun yedeği bütün olarak alınır. İçinden tek bir dosya çıkarmak da mümkündür ancak uygun programı kullanılması gerekir. Daha kompleks ancak daha sağlıklı bir yedekleme sağlar.
Dosya tabanlı yedeklemede ise, sadece dosya veya dizin yedeklenir. Bir anlamda farklı bir ortama kopyalanır. Daha basittir, küçük sistemlerde az yatırım ile çözüm için tercih edilebilir. (rsync, dar, dump, tar, vs kullanılabilir) 

12.Bir kritere göre dosya bulan ve silen komut nasıldır?

find [aranacak dizin] -type f -name [dosya adı] -exec rm -rf {} \;

veya


find [aranacak dizin] -type f -name [dosya adı] | xargs rm -rf

* Kolay bir örnek. Ancak bu şekilde ufacık script örnekleri olabilir demek için yazdım bu soruyu da. Özellikle xargs, grep, awk gibi komutlara bir göz atmakta fayda var ;-)


13. Dosya sistemlerinde günlükleme (journaling) nedir? Avantajı nedir?


Günlükleme (journaling), dosya sistemi üzerinde yapılan işlemlerin loglarının başka bir yerde tutulmasınına denir. Bu özellik sayesinde yapılan son işlemlere ulaşılabilir. Bir sorun halinde sistem/dosya kurtarması için işe yarar.

14. Linux'ta en bilinen günlüklü dosya sistemleri hangileridir? 

Ext3, ext4, ReiserFS (günlüklemeyi ilk kullanan), XFS (en kararlı kabul edilen)

* Ext3'ün Ext2'den en önemli farkı budur. 

15. "kill -9" ile "kill -15" arasında ne fark vardır?

Kill komutu ile bir process sonlandırılabilir. Kill komutuna gelen sayılar signal değerleridir. -9 ile beliritilen sinyal process'i öldürür (zorla durdurur), -15 ile belirtilen sinyal ise, process'in kapanmaya zorlar (kibarca :) ) Eğer aksi bir sinyal belirtilmezse kill komutu -15 sinyalini almış gibi hareket eder.

# kill -9 [PID] --> Zorla PID numaralı process öldürülür.
# kill [PID] --> # kill -15 [PID] yazmak ile aynıdır.

16. ip ile ifconfig arasında ne fark var? 

17. 

Sanallaştırma (Vmware) Soruları

16. (Senaryo) Bir ESX Host Vcenter ile iletişimi kopardı. SSH ile bağlandın ve hostd çalışmıyor. Fakat üzerinde çalışan VM'ler olduğu için restart edemiyorsun. Hangi komut ile işlem yapmalısın?

Kısa yanıt: localcli. 

Uzun Yanıt: host.d çalışmadığında esxcli komutu da iş görmez. Ancak bu durumda localcli komutu ile işlem yapıp vm'lere müdahale edilebilir. 

Açıklama: Bu soru çok farklı şekilde sorulabilir tabi. Senaryo'da sorudan soru üretilebilir. "VCenter ile iletişim koptu ne yaparsın?" "Host'a SSH ile bağlanırım". "Bağlandın hangi komutu kullanırsın?" "esxcli genelde iş yapar". "esxcli çalışmıyor, neden?" "Çünkü hostd çalışmıyor". Son olarak da üstteki haline gelebillir. 

Tabi bir de localcli üzerine bakmakta fayda var. 

ESXCLI	LOCALCLI
esxcli komutu ile esxi host yönetilebilir.	localcli komutu ile aynı esxcli komutu gibi çalışır. Ancak hostd prosesi bypass olur.
Sadece hostd çalışırken iş görür	hotsd çalışmıyorsa ve sunucu restart edilemiyorsa kullanılır.
	Localcli komutu ile işlem yapıldıktan sonra hostd restart edilmeli ve ardından esxcli kullanılmalıdır.
	Diğer durumlarda localcli komutu kullanmak sistem durumunu riske sokar ve potansiyel risk barındırır
Vmware tarafından desteklenir.	Sadece Vmware Support tarafından tavsiye edildiği durumda kullanılmalıdır.

IT Altyapı'da agile kullanılmaz! (mı?)

Tamamen konu dışı birşeyler yazmak istiyorum bugün. Aslında ilişkisini de en sonda biraz kuracağım.

Son günlerde her yerde IT çalışanları için bir Agile (Çevik) dönüşüm furyası gidiyor. Çalıştığım şirkette de dahil olmak üzere, herkes "Agile"ı cümle içinde kullanmak için gereğinden fazla (ve çoğu zaman gereksiz) bir çaba içine giriyor. :-) Bir diğer çokça duyduğum ve asıl yazmama sebep olan kısım ise "Agile, -sadece- bir yazılım metodolojisi". Aslında epeyce bir süre ben de bu fikre sahiptim ve inceden de gıcık olmuyor değildim. :-) Yıllarca "IT Altyapı" hizmeti vermiş biri olarak neredeyse "oyun dışı" kalmak gibi geliyordu. Fakat itiraz etmek, yok saymak, her zamanki gibi bizi uçuruma süreklerdi. Önce ne olduğunu araştırmaya başladım. Biliyorum, öğrendim kesinlikle demiyorum ancak öğrendiklerimi birleştirdikçe de işin sadece "yazılım" ile bitmeyeceğini de gördüm. Demek ki artık inceden "sinir olmak" değil "içine de girmek" zamanı gelmişti. Ayrıca metodolojinin "uygulaması" kısmı ile hiç ilgilenmedim. Kanban, scrum vs. bambaşka konular.

Hikayenin ardından biraz da neleri anlatmaya çalışacağımın girişini yapıp başlayayım; Amacım konunun anlaşılması olduğu için önce kısaca benim agile'dan anladığım ile başlayacağım. Agile koçu olmadığım, özel hiç bir eğitim de almadığımı* düşünürsek sanırım epeyde düşük seviyede bir tanımlama olacak. Sonra da bu "metodoloji" içinde "IT Altyapı" hizmetleri neden gerekli, nasıl kullanılıyor (benim bildiklerim tabi) ve nasıl kullanılabilir üzerine biraz kafa yormayı düşünüyorum. Yanlışlarımı, eklenmesini düşündüklerinizi lütfen yorumlara ekleyin ki gelişsin bu yazı da...

"Agile nedir?" diyerek başlayacağız dedim. Benim öğrendiklerim ve anladıklarım çerçevesinden bakarsak, Agile (çevik), aslında bir çeşit proje yönetim metodolojisi. Daha önceleri "waterfall" denen metodoloji tercih edilirken, son yıllarda daha hızlı çözüm üretmek temeli üzerine kurulmuş bir metodoloji. (Bu açısından bakarsak özellikle Türklerin yadırgamayacağı bir model :-) ,

Üstteki şema için uğraşamadım ve internetten buldum. İngilizce bu sebeple. Ancak,iki modeli kıyaslamak için çok öğretici. Kısaca üstünden geçersek, waterfall modelinde bir amaca ulaşmak için (bu ürün de olabilir, bir işin tamamlanması da aslında projeden bahsediyorsak) önce planlıyoruz, hazırlıyoruz, testini vs yapıp, mükemmele ulaştığından emin olduğumuzda sonuca erdiriyoruz. Bu da günümüz "sabırsız" insanı veya Y-Z kuşağı için kabul edilemez görünüyor. Aslında işte Agile Metodolojisi de tam burada farklılaşıyor. "Sabırsızları tatmin etme ve adım adım en iyiye..." Agile süreçlerinde ise mükemmel ürünü çıkarmadan önce veya projeyi mükemmel sonuca erdirmeden önce ufak ufak alıştırma sürümleri ile hem geri dönüş alabiliyor (bu dönüşler sayesinde aslında mükemmele daha da doğru yaklaşılabiliyor), hem de "baba adamlar birşeyler yapıyor" dedirtmiş oluyor ve az önce bahsettiğim o "sabırsızlar" biraz törpülemiş oluyor. (Hatta aslında dolaylı olarak test sürecine de dahil olmuş oluyorlar.)

Daha da uzakmadan, kısaca süreç nasıl olmalı diyerek girişi kapatıp asıl konuya geleceğim. (Bu resim de internetten bulduğum bir alıntı) Agile süreçlerini de planlarken de, hızlı olacağız derken, ara ürünlerin amaçsız, işe yaramaz ve tatmin etmez olmamasına da dikkat etmek gerek. Üstteki örnek her ne kadar "agile" gibi görünse de "işe yarar" ürün en sonda çıkıyorsa, hiç bir anlamı kalmıyor. Ancak alt örneği incelersek, kaykay ile pek tatmin olunmasa da, adım adım işe yarar ürünler çıktıkça memnuniyet artıyor ve aslında tam da istendiği gibi ilerliyor. (Bu arada yolcunun  da yolda kalmadığına, başlangıçta zor da olsa hedefine bir araç ile gidebildiğine dikkat etmek gerek)

Aslında bu çerçeve ile bakmaya başlarsak, ilk başta da dediğim gibi, sanki hep bir hedefe yönelim var. IT için ürün "yazılım" hedef "müşteri/kullanıcı" ise "Agile IT Altyapı için gerekli değil" gibi bir sonuç akla geliyor. Ancak, altyapı, -adı üstünde- sağlam olmadığında  (kış lastiğin yoksa), hızlı gitmeye uygun değilse (F1 lastikleri gibi değilse) istenildiği kadar agile (hızlı/çevik) olmaya çalışılsın çakılmaya mahkumdur. İşte tam da bu noktada aslında F1'deki "pilot mu otomobil mi?" tartışması açılır ki gerçek yanıt "ikisi de" olmalı galiba. Sadece bu sebeple, "Hayır Agile sadece yazılım için değil, tüm IT (aslında tüm çalışma birimleri de denebilir) içindir."

Ana fikrimizi çürüttük (en azından öyle sanıyorum :-), peki altyapı olarak agile dönüşüme nasıl destek veriyoruz şu an? İşte burada da en çok "Devops" kavramı çıkıyor karşımıza. Aslında bu kavram da bizi yıllardır kopuk yaşayan (veya yaşadığı sanılan demek daha doğru olur) yazılımcılar ile altyapıcıları birbirine daha çok yaklaştırıyor. Bu da kısaca şöyle anlatılıyor; Yazılım tamam, siz kendi geliştirme ortamınızda işleri bitirdiniz, ancak canlı ortama sürmek için altyapı kısmından destek istiyorsunuz. Eğer altyapıyı anlayan bir yazılımcı varsa veya yazılım gereksinimleri üzerine kafa yormuş bir sistem yöneticisi, o zaman şanslısınız. Ancak bu durumda bile "deployment" süreci çok can sıkıcı ve uzun zaman alabiliyor. Sadece işletim sisteminin update versiyonu bile bazen günler alabiliyor veya bir Java versiyonu. Bir yanda sabırsız müşteri ve yönetici, diğer yanda yazılımcı ve sistem yöneticisi birbirlerini yiyorken, agile veya kanban kimsenin aklına gelmiyor. İşte devops (DEV-eloper OP-eration-S) süreçleri sizin daha hızlı ürün ortaya koyabilmenizi sağlıyor. İşte buradaki OPS aslında altyapı oluyor. (Yani biz :-) )

Deployment (yazılımı canlı ortama taşıma) sürecini daha hızlandırabilmek için de gelişen bir çok otomasyon teknolojileri var. Container teknolojileri (örnek Docker) , versiyon takip sistemleri (örnek git), yazılım dağıtım otomasyonları vs.İşte bu konular da "IT Altyapı çalışanları" için yeni bir yol haritası olmalı. Tabi aynı zamanda "Agile" olacağım diyen şirketler için de...

Sonuç olarak bakarsak, Agile olmamış bir altyapı ile isteseniz de agile proje çıkaramazsınız. Tam da bu sebeplerle "Agile sadece yazılımcılar için kullanılan bir metodoloji değildir..."

* Bu yazının %95'ini yazdığımda hiç eğitim almamıştım ancak yakın zamanda 2 günlük keyifli bir agile eğitim aldık. :-)

"ChromeCast Stream with mkChrome" Python app

Bir önceki post'ta bahsettiğim Phyton uygulamasını da aşağıda paylaşıyorum. Aklımda uygulamanın tam halini koymak vardı aslında. Çünkü "webcast" ve "filecast" seçenekleri de var. Ancak en basit haliyle paylaşmak daha anlaşılır olması için mantıklı geldi.

Uygulamanın çalışması için mkChrome kurulu olmalı.

from tkinter import *
window = Tk()
window.geometry('450x300')
window.title("ChromeCast Stream with mkChrome")


def stream():
    link = txt.get()
    tik = Label('window,text=link')
    tik.grid(column=0, row=4)
    command = "mkchromecast -y " + link + " --video"
    import os
    os.system(command)

lbl = Label(window, text="Youtube Link:")
txt = Entry('window,width=20')
btn = Button(window, text="Stream to ChromeCast", command=stream)

lbl.grid(column=0, row=0)
txt.grid(column=1, row=0)
btn.grid(column=0, row=1)

window.mainloop()

Egemen, Ubuntu ve Chromecast hikayesi

Merhaba,

Ne kadar çok zamandır ara vermişim. Kendimden de utandım desem yeri var.

Aslında, bunca yıllık ölü toprağını üstümden atmamı sağlayan, yeniden nefes aldım dedirten hikayeyi yazmaya geldim.

Blog adı Aylin-ux ama galiba artık burada "Egemen" hikayeleri olacak gibi. Eski laptopa merak saldı son günlerde. Pek de kullanmadığımdan içinde yarım yamalak çalışan bir Windows vardı, Madem merak saldın adam gibi birşey kullan/öğren diyerek geçenlerde Ubuntu kurduk. Kurduk diyorum çünkü "kuralım" dedikten sonra günlerce "baba ne zaman kuracağız?" diye gezindi çevremde. Eski laptop olunca da çeşitli donanımsal sorunlar da yaşadık iş biraz uzadı. Ancak sonunda kurduk ve artık Linux kullanmaya başladı. (Aklıma geldi; yıllar önce SDÜ'de İnternet Haftası için yaptığımız bir etkinliğe rahmetli Mustafa Akgül Hoca gelmişti ve bir Linux sunumum vardı. "Linux zor diyorlar, ne alakası var.." diyerek sahneye İsmail Hoca'nın oğlu Şerif Ali'yi çıkarmıştım. (O da şimdi Bilgisayar Mühendisliği okuyor) o zamanlar okuma bile bilmiyordu. 5-6 yaşında. Birkaç şey yapmıştı sahnede.) Neyse ya amma uzattım. Yazacak anlatacak ne çok şey var. (Yaşlanma belirtileri vol:1)

Ubuntu kurduk, Egemen hayatından memnun, "Ubuntu Software"  ile istediği programları indiriyor, hatta bazen alakasız birşey indiriyor anlayamıyor çünkü oyun değil. Ama inatla ne olduğunu çözmek için başımın etini yiyor. Minecraft'a kadar hemen herşeyi bulduk alışık olduğu.

Ancak ip geçen hafta sonu koptu. En sevdiği şeylerden birisi evdeki "chromecast" ile youtube'da bulduğu videoyu TV'ye aktarmak. Ancak ubutu software içinde chrome yok. Başta hiç aklıma da gelmedi gidip sayfasına bakmak. (Bazen basit şeyler için gözümüz kör oluyor ve zora yöneliyoruz çok teknik düşünmekten**). Google'dan "how to stream from ubuntu to chromecast" diye aradım. Oradan da (doğal olarak) başka bir uygulama  buldum. "mkchromecast" diye python ile yazılmış bir uygulama. Ancak sorun şu; uygulama komut satırında. Çok basit bir komut ama Egemen'e öğretmek zor. (Anında ezberler gerçi o da ayrı konu). Bir süredir ben de phyton ile uğraşıyorum, aklıma bunun için bir GUI uygulama yazmak geldi. Kabaca, Egemen istediği bir videonun linkini kopyalasın, yapıştırsın ve TV'ye aktarılsın.

Daha önce hiç python'da GUI yazmamıştım. Hemen onu araştırdım. Çok zor değil zaten. Bir kaç saat içinde basit programım hazırdı. Böylece GUI dünyasına da el atmış oldum. Ama asıl paylaşmak istediğim; suyun altında durup (ben en fazla 4-5 sn. durabiliyorum gerçi)  kafanı çıkardığında deriin bir nefes alırsın ya, işte tam da öyleyim. OOoohhhhhhh....

Uygulama hakkında detayları ayrı bir post olarak atacağım. Hem biraz elden geçirmek de istiyorum yayınlamadan önce. Zaten eksikleri de çok. Ama şu an çalışıyor. Heyecanımı paylaşmak için yazdım. Ancak bir ekran görüntüsü ile bu yazı bitsin. ;-)

** Not: Bu arada yazmayı unutmayayım, Ubuntu için Chrome var. Chrome web sayfasından download diyerek kolayca kurulabiliyor. (deb paketi indirilerek) Ayrıca chromecast ile de bağlantı kurabiliyor. Benin uygulamam hem öğrenme/proje amaçlı oldu, hem de dediğim gibi nefes içindi... ;-)

CentOS 5.5 ile DC yapmak

Sonunda CentOS 5.5 ile Domain kontroller yapmak makalesini bitirdim. Çok uzun süründü elimde garibim ancak dökümanı yazmak için yeniden kurulum yeninden ayar yaptım. Çalıştığından eminim hatta config dosyalarını da ekledim.

Herkese hayırlı olsun.

Not: Bu belge kaynak göstermek kaydıyla kullanılabilir.


CentOS 5.5 ile Domain kontrol yapmak [pdf dosya indirmek için tıklayın]

Ayar dosyaları [rar dosya indirmek için tıklayınız]