Ghost, bir içerik yönetim sistemi. Modern ve oldukça hızlı. Benim için en büyük cazibesi ise Markdown ile makale yazabilme kolaylığı.

Uzun zamandır bir arayışın içindeydim. Wordpress artık beni bunaltmaya başladı çünkü bir çok temel eksiklikleri mevcut. Bunları tamamlamak için pluginler deryasında boğulmaktan kaçamıyorsunuz. Qmail patch çılgınlığı gibi...

Basit, hızlı, hafif ve kolay kullanılabilir bir şeye ihtiyacım vardı. Grav ilk durağım oldu ve işin doğrusu hoşuma da gitti. Üzerinde epeyce zaman harcadım ve hatta bir süre sitemi yayınladım. Neticede kendisi ile de yollarımızı ayırdık malesef. Çok detaya girmek istemiyorum.

Ghost hali hazırda zaten oldukça hızlı çalışan bir CMS. Fakat Express'i olduğu gibi yayınlamak fikrine pek sıcak bakmıyorum. Bu nedenle önüne bir NGINX yerleştirmeye karar verdim.

Bu sayede NGINX ile bir çok numara yapabilirim. Proxy Cache de bunlardan yalnızca bir tanesi.

Proxy Cache ile tüm çıktıyı cacheleyeceğim ve böylelikle arkadaki Ghost servisini bir nevi maskelemiş olacağım. Ayrıca Lua ve Ghost'un Webhooklarını kullanarak, sitede değişikiller oldukça, cachein tazelenmesini de sağlayacağım.

Tüm yaptıklarımı adım adım anlatacağı ancak bir parça NGINX biliyor olmak işi kolaylaştıracaktır.

Altyapı Senaryosu

Elimde bir Ghost olacak ve https://www.gokhangeyik.net ile erişebileceğim. Ancak önünde bir NGINX olacak ve ilk olarak trafiği karşılayacak. İsteğe bağlı olarak, Ghost backend ne cevap verirse, ziyaretçiye iletirken aynı zamanda da bir sonraki istekler için 2 saat boyunca cache yapacak.

Cache purge için son derece basit bir Lua script kullanacağım. Çünkü sitenin içeriği güncellendiğinde tüm cache içeriğinin temizlenmesi büyük bir problem değil. Ancak daha kompleks purge isteklerini elbette kendiniz de yazabilirsiniz. Tabi bu minvalde kendi webhooklarınızı düzenlemeniz gerekir.

Kuruluma Başlayalım

Tüm bunlar için Docker kullanacağım. Ancak bu bare metal kurulum yapanlar için de bir fark yaratmaz. Neticede odaklandığımız konu NGINX ve Ghost olacak.

Ghost Kurulumu

docker run --name ghost -p 2368:2368 ghost:3-alpine

Ghost ilk kez çalıştığı için, gerek duyduğu bir takım işlemler gerçekleştirecek ve neticede https://www.gokhangeyik.neterişilebilir hale gelecek.

Bunu curlile test edebiliriz.

➜ curl -I https://www.gokhangeyik.net
HTTP/1.1 200 OK
X-Powered-By: Express
Cache-Control: public, max-age=0
Content-Type: text/html; charset=utf-8
Content-Length: 29518
ETag: W/"734e-9ZdP5ZYyAQqraAJyQref33AByfQ"
Vary: Accept-Encoding
Date: Wed, 06 Jan 2021 21:16:43 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Ghost çalışıyor ve isteklere yanıt veriyor. Artık devam edebiliriz.

NGINX Kurulumu

Bunun için de Docker kullanacağım. Basit tutmak için, contaier temelini Alpine tercih ediyorum.

docker run --name nginx --rm -it -p 80:80 alpine:latest sh

Artık bir Alpine containerım var ve gerekli paketleri kurabilirim. İhtiyacım olan paketler:

• nginx
• nginx-mod-http-lua
• lua-resty-core

apk update
apk add --no-cache nginx nginx-mod-http-lua lua-resty-core

Amacıma ulaşmaya hemen hemen hazırım ancak burada kısa bir bilgi vermem gerekiyor. Herşeyi cache etmek akıllıca olmayacaktır. Çünkü Ghost'un bazı lokasyonları tam tersine cache edilmemeli. Çünkü bu lokasyonlar, giriş yapmış kullanıcılara ait araçları içeriyor. Burada proxy_cache_bypass kullanabilirdim ve cookie bunun için harika bir belirleyici olabilirdi, ancak ben biraz daha net olmak istiyorum ve bu nedenle location konteksti ile bu özel alanları ayrı tutacağım.

proxy_cache_path /var/cache/nginx/ levels=1:2 keys_zone=ghost_cache:10m max_size=512m inactive=2h;
proxy_cache_key "$request_method$host$request_uri";
proxy_cache_methods GET HEAD;

Yukarıdaki direktifler http kontekstinin içinde olmalı. Şimdi tek tek ne yaptığımı anlatacağım.

proxy_cache_path, yapacağım işlem için oldukça kritik. Cache edilmiş isteklere ait dosyaların, nerede, ne şekilde ve ne kadar süreyle tutulmasını istediğimi belirtebilmemi sağlar. Ayrıca bu dosyaların byte cinsinden kaplayabileceği en fazla alanı da limitleyebilirim.

Örneğimden gidecek olursam, cache istekleri /var/cache/nginx dizininde depolanacak.

level=1:2 ise bu cache çıktılarının hiyerarşik olarak düzenini belirtiyor. NGINX, cache çıktılarını MD5 ile isimlendirir. Yani günün sonunda aşağıdaki gibi dosya isimlerine sahip olacağım.

bash-5.1# ls -Al
total 32
drwx------    3 nginx    nginx         4096 Jan 10 08:40 3
drwx------    3 nginx    nginx         4096 Jan 10 08:41 4
drwx------    3 nginx    nginx         4096 Jan 10 08:40 6
drwx------    4 nginx    nginx         4096 Jan 10 08:41 8
drwx------    3 nginx    nginx         4096 Jan 10 08:40 9
drwx------    3 nginx    nginx         4096 Jan 10 08:40 d
drwx------    3 nginx    nginx         4096 Jan 10 08:41 e
drwx------    3 nginx    nginx         4096 Jan 10 08:40 f

Örnek olarak 8 dizininin içeriğine bakalım.

bash-5.1# cd /var/cache/nginx/8/
bash-5.1# find .
.
./ca
./ca/31b4504a91cc38c996e2dff211e59ca8
./2e
./2e/b999904f61cd8ade87149edef72dd2e8

Yani NGINX, oluşturduğu bu dosya isimlerinden sonran 1. karakteri ilk seviye dizin olarak oluşturuyor. Bundan sonra gelen 2 karakteri de -ki bizim çıktımızda bu ca ve 2e- bir alt dizin olarak oluşturup, cache çıktısını burada saklıyor.

keys_zone bir çeşit index olarak düşünülebilir. Cache dosyalarının anahtarları burada tutuluyor. NGINX dökümanına göre 1 Mbyte boyutundan bir zone 8.000 anahtar saklayabiliyor. Aslında 10 Mbyte dahi benim için büyük bir alan.

max_size ise adı üzerinde, cache dosyalarının belirtilen dizin içerisinde kaplayabileceği maksimum disk alanı.

inactive ise bir pasif cache anahtarının maksimum süresini belirtiyor. Eğer cache edilmiş bir dosyaya, bu süre zarfında hiç erişilmemiş ise, cache durumu ne olursa olsun NGINX silecektir.

proxy_cache_key, keys_zone içerisinde tutulacak anahtarları isimlendirmek için bir şablon. Bu yönerge bir çok amaç için kullanılabilir. Eğer responsive bir web  uygulaması kullanmıyorsanız, mobil ve masa üstü istemcileri için farklı cacheler üretebilirsiniz.

Ve son olarak proxy_cache_methods ise istediğim HTTP istek metodlarını cache için seçmeme yardımcı oluyor.

Devamında artık cache yapmak istediğim ve cache dışında tutmak istediğim lokasyonları belirleyip yayınlamaya başlayabilirim.

location / {
            proxy_hide_header x-powered-by;
            proxy_hide_header Etag;
            proxy_redirect off;

            proxy_pass http://ghost:2368;

            proxy_cache ghost_cache;
            proxy_cache_valid 200 60m;
            proxy_cache_valid 404 3m;
            proxy_cache_revalidate off;
            proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
            add_header X-NGINX-Cache $upstream_cache_status;
        }

Tek tek parametreleri tanıtmak ve anlatmak istemiyorum o nedenlen buradan sonrasını biraz daha hızlı devam edeceğim. location / Hemen her yeri kapsayan bir cache tanımı oldu. HTTP 200 60 dakika boyunca, HTTP 404 ise 3 dakika boyunca cache olacak. Bir takım HTTP başlıklarını gizlemeyi tercih ettim.

Buraya gelen tüm istekler, eğer keys_zone içerisinde değilse proxy_pass marifetiyle ghost ismine sahip containera gidecek. Son olarak da bir belirleyici ekledim ki cache işe yarıyor mu görebileyim.

Önemli iki alan var ki onları cache etmemeliyim. Bunlardan biri Ghost'un yönetim ara yüzü, diğeri ise gönderileri ön izleme yapmama yarayan alan. Aşağıdaki kontekst işime yarayacaktır.

location ~* ^(/ghost/|/p/) {
            proxy_hide_header x-powered-by;
            proxy_hide_header Etag;
            proxy_redirect off;

            proxy_pass http://ghost:2368;
            break;
        }

Şimdi bunları bir araya getirip ilk testlere başlayayım. Testlerimde curl ve httpstat kullanacağım ve konfigürasyonum şu şekilde görünecek.

proxy_cache_path /var/cache/nginx/ levels=1:2 keys_zone=ghost_cache:75m max_size=512m inactive=2h;
proxy_cache_key "$request_method$host$request_uri";
proxy_cache_methods GET HEAD;

server {
    listen 80;

    location ~* ^(/ghost/|/p/) {
        proxy_hide_header x-powered-by;
        proxy_hide_header Etag;
        proxy_redirect off;

        proxy_pass http://ghost:2368;
        break;
    }

    location / {
        proxy_hide_header x-powered-by;
        proxy_hide_header Etag;
        proxy_redirect off;

        proxy_pass http://ghost:2368;

        proxy_cache ghost_cache;
        proxy_cache_valid 200 60m;
        proxy_cache_valid 404 3m;
        proxy_cache_revalidate off;
        proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
        add_header X-NGINX-Cache $upstream_cache_status;
    }
}

İlk olarak Ghost'u direk erişim ile test edeceğim. Söylediğim gibi aslında Ghost oldukça hızlı çalışan bir içerik yönetim sistemi.

➜ httpstat https://www.gokhangeyik.net
Connected to ::1:2368 from ::1:56947

HTTP/1.1 200 OK
X-Powered-By: Express
Cache-Control: public, max-age=0
Content-Type: text/html; charset=utf-8
Content-Length: 29518
ETag: W/"734e-7qGhBLEw4KHXjVrEObfphnPgXMc"
Vary: Accept-Encoding
Date: Sun, 10 Jan 2021 10:14:37 GMT
Connection: keep-alive
Keep-Alive: timeout=5

  DNS Lookup   TCP Connection   Server Processing   Content Transfer
[     1ms    |       0ms      |       57ms        |        1ms       ]
             |                |                   |                  |
    namelookup:1ms            |                   |                  |
                        connect:1ms               |                  |
                                      starttransfer:58ms             |
                                                                 total:59ms

Test blogunun ana sayfası 58ms içerisinde erişilir hale geldi. Bu oldukça iyi. Tabi httpstat maalesef javascript çalıştırmıyor. Bu süre reel değil. Yalnızca çıkarım yapmama yardım edecek.

Şimdi aynı isteği NGINX proxy üzerinden yapacağım. İlk isteğim cache edilmemiş olacağından 58ms'den daha uzun olma ihtimali var.

➜ httpstat http://localhost
Connected to ::1:80 from ::1:57112

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 10 Jan 2021 10:19:06 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 29532
Connection: keep-alive
Cache-Control: public, max-age=0
Vary: Accept-Encoding
X-NGINX-Cache: MISS

  DNS Lookup   TCP Connection   Server Processing   Content Transfer
[     2ms    |       0ms      |       68ms        |        0ms       ]
             |                |                   |                  |
    namelookup:2ms            |                   |                  |
                        connect:2ms               |                  |
                                      starttransfer:70ms             |
                                                                 total:70ms

Beklediğim gibi oldu ve gayet makul. İlk istek 70ms kadar sürdü ve X-NGINX-Cache: MISS headerı henüz cache edilmediğini gösteriyor. Bundan sonraki isteğim direk olarak NGINX cache olacak ve arada ciddi bir hız farkı olmasını bekliyorum.

➜ httpstat http://localhost
Connected to ::1:80 from ::1:57190

HTTP/1.1 200 OK
Server: nginx
Date: Sun, 10 Jan 2021 10:21:21 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 29532
Connection: keep-alive
Cache-Control: public, max-age=0
Vary: Accept-Encoding
X-NGINX-Cache: HIT

  DNS Lookup   TCP Connection   Server Processing   Content Transfer
[     1ms    |       0ms      |        3ms        |        0ms       ]
             |                |                   |                  |
    namelookup:1ms            |                   |                  |
                        connect:1ms               |                  |
                                      starttransfer:4ms              |
                                                                 total:4ms

Toplam süre 4ms. Mükemmel bir sonuç. X-NGINX-Cache: HIT Artık cevabın Ghost'tan değil NGINX'ten geldiğini biliyorum.Öte yandan artık Ghost'u dert etmek zorunda değilim. Cache olduğu müddetçe, yüksek bir trafik ile karşılaşmayacak.

Şimdi sıra bu cache içeriğini temizlemekte. İştiyorum ki sitemde bir değişiklik yaptığımda, bu cache tamamen silinsin ve ben de değişiklikleri görebileyim. Bunun için iki şeye ihtiyacım var.

1. NGINX purge lokasyonu
2. Ghost içerisinde bunu tetikleyebilecek bir mekanizma.

Bunların hepsine sahibim. NGINX konfigürasyonumu aşağıdaki şekilde güncelliyorum.

proxy_cache_path /var/cache/nginx/ levels=1:2 keys_zone=ghost_cache:75m max_size=512m inactive=2h;
proxy_cache_key "$request_method$host$request_uri";
proxy_cache_methods GET HEAD;

server {
    listen 80;

    location ~* ^(/ghost/|/p/) {
        proxy_hide_header x-powered-by;
        proxy_hide_header Etag;
        proxy_redirect off;

        proxy_pass http://ghost:2368;
        break;
    }

    location / {
        proxy_hide_header x-powered-by;
        proxy_hide_header Etag;
        proxy_redirect off;

        proxy_pass http://ghost:2368;

        proxy_cache ghost_cache;
        proxy_cache_valid 200 60m;
        proxy_cache_valid 404 3m;
        proxy_cache_revalidate off;
        proxy_ignore_headers X-Accel-Expires Expires Cache-Control;
        add_header X-NGINX-Cache $upstream_cache_status;
    }
location /purgethecache {
        content_by_lua_block {
            os.execute("/bin/rm -rf /var/cache/nginx/*")
        }
    }
}

purgethecache isminde bir lokasyon ekledim ve oldukça basit bir lua direktifi çalıştırıyorum. Buraya gelen her istek ile birlikte /var/cache/nginx dizininin içeriği temizlenecek ve böylece cache yok edilmiş olacak.

Her Ghost blog bir yönetim arayüzüne sahip. Bu arayüzde Integrations bölümü mevcut. Bu bölümden bir Custom Integration ekleyeceğim.

Şimdi de bu entegrasyona bir Webhook ekleyeceğim. Yani Ghost, sitede herhangi bir değişiklik olunca, gidip purgethecache lokasyonunu ziyaret edecek. NGINX de tanımlandığı gibi cache içeriğini silecek.

Hedefime ulaştım. Artık calışan bir cache mekanizmam ve purge mekanizmam mevcut. Bu konfigurasyon elbette geliştiriebilir ve ben elimden geldiğince sadeleştirerek anlatmak istedim.

Türkiye'de birçok bilişim çalışanının aklının bir köşesinde, yeteneklerini yurt dışında değerlendirmek olduğunu biliyorum. Ancak sayısız gerekçelerle bunu erteliyoruz. Türkiye'de 2003 yılında başlayan bilişim hayatımın 2019'un Ağustos'unda Almanya'ya taşınmasının adımlarını anlatmaya karar verdim. Değişiklik yapmak için asla geç değildir!

Hikayenin tamamını bir yazıda anlatmak yerine, farklı bölümlere ayırıp bir çok soruya detaylı yanıtlar verebilmeyi amaçlıyorum. İlk yazıda Türkiye'de bilişimci olmak ile Almanya'da bilişimci olmayı kıyaslamak istiyorum.

Türkiye'de bilişimci olmak

Bilişim sektöründeki ilk profesyonel iş tecrübem 2003 yılında başladı. Ben bir sistem yöneticisiyim ve bu kararı son derece bilinçli olarak aldım. Tercihimde herhangi bir rastgelelik olmadığından, ne istediğimi ve ne yapmam gerektiğini bilir bir şekilde ilk işime atıldım.
İlkokul yıllarımdan bu yana bilgisayarlarla hep iç içe oldum ve bir bilişim meraklısı klasiği olarak ilk BASIC kodlarımı ortaokul yıllarımda, örnek kodları deneyerek tamamladım.
Bu benim için bambaşka bir tecrübeydi ve büyülenmiş hissettim. O andan itibaren bilgisayarlara dair her şeyi öğrenmeye ve bilgisayarlarla ilgili bir iş sahibi olmaya karar verdim.

Birkaç programlama dili öğrendikten sonra işletim sistemleri ve ağ teknolojileri ile de ilgilenmeye başladım. Günün sonunda, kendimce edindiğim amatör tecrübeler, bir teknoloji şirketinde sistem yöneticisi olmamı sağladı.

2003'ten 2019 yılına kadar Türkiye'de tam zamanlı olarak 2 farklı şirkette çalıştım. İlk işimde 12 yıl, 2. işimde ise 3 yıl çalıştım. Bununla birlikte sayısı 200'e yaklaşan ve freelance olarak adlandırılan ek işlerde de bulundum.
Bütün bunlar, Türkiye'de bilişimci olmanın nasıl olduğuna dair bir fikir edinmemi sağladı.

Türkiye'de beklentiler

Çalışanların, yöneticilerin ve işverenlerin birbirlerinden beklentileri farklıdır. Ancak yazımdaki perspektif çalışan tarafı olacak.
Biz bilişimciler genellikle sessiz, konforlu bir çalışma ortamından hoşlanıyoruz. Yaptığımız çoğu iş yüksek dikkat gerektirdiği için, dikkat dağıtıcı öğeler tüm performansımızı kökünden etkiler. Malesef Türkiye'de hiçbir işimde ya da projemde bu kısmı kavrayabilmiş bir yönetici ya da işverene rastlayamadım.
Bir kısmı biraz daha özenli, bir kısmı biraz daha özensiz... Ancak neticesinde sonuç hiç optimum olmadı. Buraya dikkatinizi çekmek istiyorum. Maksimum demiyorum, optimum dahi olamadı.

Kişilerin özel hayatlarının, iş hayatlarından çok daha önemli olduğu gerçeğinin idrak edilemeyişi bir çok sorunun ana nedenidir.
Üç aşağı beş yukarı haftalık 40 saat çalışma süresinin bedelinin ödendiği bir iş hayatında, bundan 1 saniye daha fazlasını talep etmenin büyük bir cüret olduğunu bilmek gerekir. Bu cüretin çalışana makul bir fayda sağlaması gerekir ve bu fayda iki tarafın da onayını gerektirir.

Karşılıksız fazla mesai sömürüsü, bireyleri isteği dışında hürriyetinden yoksun bırakmaktan çok farklı değildir. Fazla mesai yapmalısınız yoksa işinizden olabilirsiniz. Karşılık beklemeniz ise yüzsüzlük olarak dahi nitelendirilebilir.
Bu zamana kadar edindiğim tecrübeye göre, hayatınızın zerre kadar kıymeti yoktur. Zaten kazandığınız para ile de en iyi ihtimalle orta halli bir hayat sürersiniz.

Genel olarak yöneticilerle sorun çözmek, Türkiye şartlarında gereksiz bir efordur. Bir kısım yöneticinin sorun çözebilecek kabiliyeti olmadığı gibi bir kısım yöneticinin de sorun çözebilecek yetkisi bulunmuyor. Hatta bir çoğu düşüncelerini ifade edebilecek ölçüde iletişim becerisine dahi sahip değil.
Bunun neticesinde sürekli olarak sızlanan bir çalışan kitlesi olarak yaftalanmaktan kaçamıyorsunuz. Halbuki ortada çözülemeyen bir sorun varsa, yarın da çözülmemiş olacak ve aynı rahatsızlığı yaratan bir sorun olarak varlığına devam edecektir.
Çözümlenmemiş sorunların kendiliğinden ortadan kalkmadığını anlatabilmenin bir yolu olduğunu sanmıyorum.

Netice olarak halen Türkiye'de emeğini bilişim sektöründe akıtan meslektaşlarıma tavsiyemdir. Beklentilerinizi mümkün olduğunca düşük tutun. Böylece daha az yıpranırsınız.

Türkiye'de iş hayatı ve özel hayat dengesi

Bu dengenin Türkiye'de bulunduğuna inanmak için bir nedemin yok diyerek, tekmeyle kapıyı kırmak suretiyle konuya gireyim. Bireylerin birbirine saygı düzeylerinin çok aşağıda olduğu bir toplumda, şirket gibi hiyerarşik bir oluşum içerisinde bu saygıyı aramak fazlasıyla komik olur.
Elbette iş hayatınız, özel hayatınıza saygı duymayacaktır. Elbette mesai sonunda gitmek istediğiniz konser şirketinizin umrunda bile değil. Yahu elbette yöneticiniz sizin haftasonu planınızı duymak istemiyor.
İş olduğu müddetçe çalışmalısınız. Çünkü iş, hayatta kaldığınız müddetçe sizden daha önemli. İş yapabilecek sağlıktaysanız, kah tatlı sert tavırlarla, kah gönül alarak ya da kah küçük vaatler verilerek çalıştırılacaksınız.

Türkiye'de ücretlerin belirlenme süreci

Teknik olarak her şirket çalışanı, bulunduğu şirkete kendi iş gücünü satan bir satıcıdır. Ancak bu ilişki asla iki şirketin bir biririne ürün ya da hizmet satması eşitliğinde değildir.
Çalışan, kazanmak istediği parayı kısmen belirler ya da hiç belirleyemez. Genellikle sunulana kabul gösterir ya da biraz daha fazlasını elde edebilir. Çalışanın kendi iş gücünü tanıtma ve pazarlama olanağı olmadığı gibi, mevcut durum üzerinde de pek fazla kontrolü bulunmaz. Belirli dönemlerde yapılan maaş zamları süreci de aşağı yukarı aynı şekilde devam eder.
Halbuki sahip olduğumuz yegane para kazama aracı olan iş gücümüz üzerinde hak sahibi olamamak tuhaf değil mi? Yahut bu iş gücü üzerinde değer belirleyici taraflardan biri olmaya çalışmak neden eğreti durur?
Neden zam dönemleri yalnızca çok az şirkette çalışan ve iş veren arasında bir pazarlık sürecine dönüşebiliyor? Neden çok az şirkette zam dönemleri çalışan ve iş verenin birbirleri hakkında planlarını ve vaatlerini paylaşabilecekleri bir diyaloğa dönüşebiliyor?
Bunları cevaplayarak konuyu daha fazla uzatmak istemiyorum.

Türkiye kısmını burada bitirip asıl konumuz olan Almanya'da bilişimci olmak kısmına geçmek istiyorum. Ancak kıyas yapabilmek için önce Türkiye'de bilişim sektörü hakkındaki fikirlerimi paylaşmam gerekiyordu.

Almanya'da bilişimci olmak

Almanya'ya 2019'un Ağustos ayında taşındım. Aşağı yukarı 1 yıl oldu diyebiliriz. Burada çalıştığım şirketle aslında 2019'un Mayıs ayında uzaktan çalışmaya başladım. Vize sürecimi beklerken de şirketin çalışma şeklini öğrenmem için güzel bir fırsat oldu. Elbette Almanya'nın çalışma hayatını tanıdığımı söyleyemem. Henüz çok az tecrübem var. Fakat söyleyecek şeyler biriktirdim.

Almanya'da beklentiler

Tıpkı ülkemizde olduğu gibi, Almanya'da da çalışaların, yöneticilerin ve iş verenlerin farklı beklentileri var birbirlerinden. Fakat beklentiler son derece net bir şekilde ifade ediliyor. Bu beklentiler için plan belirleniyor ve her taraf bekleneni karşılamak için gereken çalışmayı yapıyor. Bu noktada açıkta kalan hiç bir madde olmuyor.
Zaman içerisinde gelişen ihtiyaçlarınız ya da değişiklik istekleriniz olabilir elbette. Bunu basit bir örnekle anlatalım.

• Çalışan: "Yeni bir koltuğa ihtiyacım var, benimkinden memnun değilim. Yenisini alabilir miyiz?"
• Yönetici: "Evet, yeni bir koltuğu bir sonraki hafta Pazartesi günü sipariş edebiliriz." Ya da
• Yönetici: "Arızalı koltuklar dışında, önümüzdeki yıla kadar mobilya satın almayı planlamıyoruz."

Görüldüğü üzere diyalog gayet net.

"Ben bunu bir konuşayım.",  "Şu işi bir halledelim, sonra çözeriz.", "İşi insan yapar, masa koltuk değil." Gibi anlamsız cümleler işitmezsiniz.

İş mülakatlarının bir evresinde, kesinlikle maaşınız üzerine bir oturum yapılır. Bu noktada eğer talep ettiğiniz maaş ödemek istediklerinden fazlaysa, ödemek istedikleri miktarı belirtip, bunun yanında size bir ek fayda paketi sunabilirler. Bunun içerisinde farklı tipte sağlık sigortaları, yıllık tatil masrafları için bonuslar, elektrikli bisiklet ya da spor salonu aboneliği gibi birçok şey olabilir.
Aynı oturumda önünüzdeki bir kaç yılın gelir planını dahi birlikte yapabilirsiniz. İlk yılın sonunda alacağınız zam oranı bir kaç farklı kalemde belirlenebilir. Örneğin projenizin ya da işinizin belli başlı kilometre taşları için farklı maaş zamları dahi görebilirsiniz.
Almanya ve Hollanda şirketleri ile iş görüşmeleri yaptım ve süreçler hemen hemen aynı sayılırdı. Tıpkı bir iş insanının, şirketindeki bir ürün ya da hizmeti başka bir şirkete satmaya çalıştığı gibi adil ve eşit bir pazarlık sürecinin içerisine giriyorsunuz.

Almanya'da yöneticiniz ile bir sorunu çözüme kavuşturmak son derece kolaydır. Elbette sonuç hep istediğiniz gibi olmayacaktır. Ancak süreç nettir ve netice kalıcıdır. Esnemez, gevşemez.
İş arkadaşlarınızın, yöneticilerinizin talepleri nettir. Anlamsız imalar, savsaklamalar ile yorulmazsınız.

Almanya'da iş hayatı ve özel hayat dengesi

Özel hayatınız kesinlikle iş hayatınızın önünde. Bu durum kanunlar ile korunduğu gibi yönetici ve iş verenler de konuya son derece hassas yaklaşıyorlar. Her ne kritere bağlı çalışıyor olursanız olun(mesai saati, görevlendirme v.b) günlük çalışma kriterinizi tamamladığınızda işiniz bitmiş demektir. Çantanızı alıp gidersiniz.

Zaman zaman elbette fazla mesai yapmanız gerekebilir. Ancak bu durumun üst sınırlarını, fazla mesai neticesinde edineceğiniz faydaları daha işin başında sözleşmenizde görürsünüz. Bu maddeler sizin takip etmenize gerek kalmadan uygulanır. Edineceğiniz faydalar her ne ise, belirlenen zamanda elinize ulaşır.
Fazladan çalışma süreci de genellikle 1 hafta önceden belirlenir ve sizin onayınız istenir. Eğer uygun değilseniz yeni bir planlama talep edebilme özgürlüğünüz de bulunur. Elbette bu durum şirketten şirkete küçük farklılıklar gösterecektir.

Fazla mesai dışında kalan tüm görevlerinizde de tam söz hakkı sahibisiniz. Çünkü burada uzman sizsiniz ve sizin uzmanlığınıza saygı duyulur. Bahsi geçen işin yapılacağı süreyi değiştirmeyi tartışmaya açabilirsiniz. İşin yapılma şeklini ve kabul kriterlerini de. Kısacası işin her noktasında fikir beyan edebilirsiniz. Beyan ettiğiniz fikirlerin ne kadar dikkatle ele alındığına inanmakta ilk başlarda zorlanabilirsiniz.
Özel hayatınız size aittir ve bundan feragat etmenizi bekleme haklarının olmadığı bilinciyle sizinle iletişim kurulur. Karşılığında bir fayda sağlayacak olmanıza rağmen, fazla mesai durumunu kabul etmeniz, yöneticileriniz tarafından kıymetli bir özveri olarak değerlendirilecektir.
İşte tam bu bilinç nedeniyle, Almanya'da çalıştığım aşağı yukarı 1 yıllık süreçte, toplam fazla mesaim 2 ya da 3 saati geçmemiştir. Türkiye tecrübemde ise her çalışma haftasının en az 3 gününün fazla mesai ile geçtiğini üzülerek hatırlıyorum.

Almanya'da genellikle 30 iş günü yıllık izne sahip olursunuz. Bu 30 iş gününe hafta sonunun herhangi bir günü dahil edilmez. Yani dolu dolu koca 6 hafta tatile çıkabilirsiniz her yıl. Bazı şirketlerin bu tatilleri en fazla  3'er hafta olarak 2'ye bölünmesini istediğini biliyorum. Elbette isterseniz daha küçük parçalar olarak da kullanabilrisiniz. Tabi bu durum siz işe daha başlamadan sözleşmenizde ya da şirketinizin tanıtım dökümanlarında size belirtilir. Yıllık izin tarihlerinize herhangi bir resmi tatil denk geliyorsa şanslısınız. O günler yıllık izninizden düşülmeyecektir. Öte yandan herhangi bir resmi tatil ile yıllık izninizin birkaç gününü birleştirmenizde hiç bir sakınca yoktur.

Ben Almanya'da yaşamaya yeniden başladığımı hissediyorum. Mesai bittikten sonra pikniğe gidebilecek vaktim oluyor. Bisikletlerimize atlayıp doğada saatler geçirebiliyoruz. Bunu yapmak için vaktimizin kalması bir yana, o gün işimin bittiğini ve kimsenin beni rahatsız etmeyeceğini biliyorum. Bunun içsel rahatlığını tarif etmeyi denedim ama edemiyorum.

Almanya'da ücretlerin belirlenme süreci

Daha önce de söylediğim gibi. Bu süreç hem Almanya hem de Hollanda için hemen hemen aynıydı benim tecrübelerime göre. İş görüşmesi sürecinin bir oturumu olarak değerlendiriliyor ücretin belirlenme süreci. Genel olarak son aşamada yapılan bir oturum olmasının yanında, en çok hazırlanılması gereken oturum olduğunu düşünüyorum.
Almanya'da maaşlar yıllık brüt olarak sunulur. Bu maaş teklifini hesaplamak için bir çok araç bulunuyor. En popülerlerden birtanesine buradan ulaşılabilir.
Bu oturumda eşit iki taraf olarak yeteneklerinizin maddi değerini belirlersiniz. Yalnızca maaş teklifi sunulmaz, coğu zaman size sağlanacak yan haklar da sunulur. Bu adaydan adaya değişiklik gösterir. Daha değerli görülen adaya daha fazla yan fayda teklif edilebilir. Bu noktada değerinizi iyi bilmeli ve kendinizi iyi tanıtabilmelisiniz.
Ayrıca ileriye dönük anlaşmalar da bu oturumda yapılabilir. Örneğin önünüzdeki 3 yılın gelir planı size yine tartışılabilir koşullar karşılığında sunulabilir.
Bunu yine örnek bir diyalog ile somutlaştıralım.

Bardak üretmek üzerine bir iş yaptığınızı düşünelim.

• Şirket temsilcisi: "Önümüzdeki 12 ay boyunca size 50.000 Euro teklif ediyoruz. 13. ay ise yıllık ücretinizde %5'lik bir artış yapacağız."
• Aday: "12 aylık teklifiniz uygundur. Fakat 12 ayın sonunda yalnızca bardak değil, aynı zamanda kupa da üretebileceğimden eminim. Bu nedenle 13. ay artışının %8 olması benim açımdan daha uygun."
• Şirket temsilcisi: "Bu hedefe ulaştığınız takdirde %8'i kabul ediyoruz. Aksi halde %5'lik artışta anlaşmalıyız."

Bu örnek konuşma, hiç şüpheniz olmasın sözleşmenizde maddeleştirilip size sunulacaktır. Hedefinizi yakaladığınızda da kimseye gidip bunu beyan etmenize gerek kalmadan söz verilen oranda artışınız yapılacaktır.
Bu tip anlaşmaları, yıllık dönemlerle sürekli yineleyebileceğiniz iş ortamları bulmak hiç de zor değildir. Gördüğünüz gibi siz bir birey olarak kendinizi rahatlıkla temsil edebilir ve emeğinizin ederi üzerinde özgürce konuşabilirsiniz.

Bu yazıyı daha fazla uzatmadan neticeye bağlamak isterim. Ben 36 yaşında yaşadığı ülkeyi değiştirmiş biriyim. Yaşınızın hiç önemi yok ve asla değişiklik yapmak için geç değil.
Almanya ile ilgili yazılarım devam edecek, bu yazılara yön vermek ve katkıta bulunmak için aşağıdaki yorum bölümünü kullanmaktan çekinmeyin lütfen.

Almanya'da haftasonlarını değerlendirmek için Bayern Ticket alıp Bavyera'yı geziyoruz. Muhteşem bir doğa ve çok etkileyici bir şato.

Ludwig II of Bavaria, inşaata merakıyla bilinen bir kralmış. Ancak bu şato yaptırdığı en ihtişamlısı. Gezilerimizi takip etmeyi unutmayın.

UNIX tipi işletim sistemlerinde zamanlanmış görevler için cron kullanılır. Bu daemon çok küçük farklılıklar ile tüm UNIX tipi sistemler içerisinde bulunur. Cron ismini Chronos'tan almıştır.

UNIX'lerde bu tip alıntılara çokça rastlanır. Zaman temelli bir daemon olan cron için oldukça uygun bir isim. Cron servisinin en küçük zaman aralığı 1 dakikadır. Yani tekrar eden işlemleri en kısa 1 dakikalık aralıklarla çalıştırabilir. Fakat bu yazıda, 1 dakikadan kısa sürelerde işlemleri nasıl çalıştırabileceğimizi de göreceğiz.

Crontab

Cron servisi crontab(Cron Table) ile işletilir. Çok karmaşık olmayan bir ifade dizgisine sahiptir.
Sistem çapında bir crontab dosyası genellikle /etc altında bulunur ve root erişimi ile müdahale edilebilir. Ancak bununla birlikte diğer kullanıcılar da kendi crontab dosyalarını oluşturabilirler. Bu dosya içerisindeki her bir satır, bir görev veya komut anlamını taşımaktadır.

Örnek bir crontab satırı şöyle olabilir;

*/1 * * * * /usr/scripts/test.sh > /dev/null 2>&1

Yukarıdaki dizgi test.sh ismindeki shell scrpiti her 60 saniyede yani her 1 dakikada calıştıracaktır.

Bu satırı daha iyi anlamak için aşağıdaki tabloya göz atın. Satır sonunda görülen > /dev/null 2>&1 ifadesini ve açıklamasını yazının ilerleyen satırlarında bulabilirsiniz.

* * * * * /yol/komut arguman 
┬ ┬ ┬ ┬ ┬ 
│ │ │ │ │ 
│ │ │ │ │ 
│ │ │ │ └───── Haftanın Günü. (0 = Pazar) 
│ │ │ └────────── Ay (1-12) 
│ │ └─────────────── Ayın Günü (1 - 31) 
│ └──────────────────── Saat (0 - 23) 
└───────────────────────── Dakika (0 - 59)

Her satırın başında bulunan # ifadesini görmezden gelin. Zaten aşağı yukarı işlevi bu. Başında bulunduğu her ifadenin bir yorum olduğu ve işlenmemesi gerektiğini ifade ediyor.

!!! Crontab içerisinde pasif hale getirmek istediğiniz bir görevin ilk satırına # koymanız yeterli

İlk örnekte olduğu gibi cron ifadeleri içerisinde birtakım operatörler kullanabiliriz. Bu operatörlerden bazıları gruplanmış halde modern UNIX tipi sistemlerde bulunabilirler. Cron birçok farklı şekilde türemiştir. Anacron, dcron ve fcron bunlardan birkaçıdır. Bu operatörlerin bir kısmı kullandığınız cron türevinde bulunmayabilir. Ancak elimden geldiğince genel geçer anlatmaya çalışacağım.

Cron Operatörler

Asterisk ( * )

Asterisk operatörü bulunduğu kolonun her aldığı değeri kapsar. Yani Eğer haftanın her gününü ifade etmek istiyorsanız, 5. kolona tek tek hafta günlerini yazmak yerine * kullanabilirsiniz.

Örnek:

* * * * * /usr/scripts/test.sh > /dev/null 2>&1

Yukarıdaki örnekte ifade aslında her dakika çalışacak şekildedir. Çünkü cron cycle 60 saniyede bir çalışır.

Tire ( - )

Bu operatör bir değer aralığı belirtmek için kullanılır. Her saatin 10. dakikasından 20. dakikasına kadar bir işleme ihtiyacınız olabilir.

Örnek:

10-20 * * * * /usr/scripts/test.sh > /dev/null 2>&1

Virgül ( , )

Bu operatör tıpkı AND kapısı veya birçok C kökenli dildeki && operatörüne denk gelir. Her saatin 10. ve 20. dakikasını ifade edebiliriz.

Örnek:*

10,20 * * * * /usr/scripts/test.sh > /dev/null 2>&1

Slash ( / )

Kelimelerle ifade etmenin biraz kafa karıştırıcı olduğu bir operatör. Daha önce her saatin 10. dakikasından 20. dakikasına kadar çalışan bir ifade yazmıştık. Cron her 60 saniyede bir tetiklendiği için ifademizin bu zaman aralığında her dakikada bir çalışacağını biliyorduk. Peki her 2 dakikada bir çalışmasını istiyorsak?

Örnek:

10-20/2 * * * * /usr/scripts/test.sh > /dev/null 2>&1

Bu operatörlerin yanında, bazı önceden belirlenmiş ifadelerde söz konusudur. Bu ifadeleri fazla detaylandırmadan bir tablo halinde göstermek daha iyi olacaktır.

Çıktı Kontrolü

Cron ifadelerimiz çalışırken, mümkün olduğunca çıktı vermemeleri iyidir. Çünkü bu çıktı tipine göre stdout veya stderr streamlerine gidecektir. Bu streamleri bazı sistemler e-posta ile(ki çoğunlukla local-delivery) ulaştırmaya çalışır. Cron scriptlerimizin yahut komutlarımızın doğru çalıştığından emin olup bu gereksiz çıktıları engellemek en doğru harekettir.

UNIX tipi ve birçok diğer işletim sisteminde > operatörü çıktı yönlendirmek için kullanılır.

Örnek:

echo "Kodzilla" > kodzilla.txt

Yukarıdaki örnekte eksik bir ifadeyle ekrana, doğru bir ifadeyle stdout'a Kodzilla stringini gönderiyoruz. Çünkü echo tam olarak bunu yapar. Ancak bu çıktıyı > operatörü ile kodzilla.txt dosyasına yönlendirdik.

Bazı özel ifadeler yardımıyla, stdout ve stderr kontrole sahip olmadığımız zamanlarda ve öngöremediğimiz çıktıları elimine edebilir ve /dev/null  aygıtına yönlendirebiliriz. /dev/null UNIX tipi ve birçok farklı işletim sisteminde bulunur. Kara delik veya dibi olmayan çöp kovası gibi isimleri vardır.

File descriptorlar bu yazının konusu olmadığı için detaylarına girmeden geçeceğim. Burada kullandığımız iki farklı file descriptor var. 2, stderr anlamına gelir. 1 ise stdout. Yazının başındaki ilk örneğe tekrar bakalım.

*/1 * * * * /usr/scripts/test.sh > /dev/null 2>&1

2> ifadesi ile stderr 1'e yani stdouta yönlendirilmiş. Sonraki > operatörü ile stdout /dev/null aygıtına yönlendirilmiş. Böylelikle scrpitimizin tamamen sessizlik içerisinde çalışmasını sağlıyoruz.

Cron ve Saniyeler

Artık bildiğiniz üzere, cron saniyeler değil dakikalar bazında çalışıyor. Yani saniyeler gereken işlerinizde sizi yalnız bırakacaktır. Cron hakkında en çok sorulan sorulardan biri 1 dakikadan daha kısa zaman dilimlerinde çalıştırılıp çalıştırılamayacağıdır.

Hayır. Cron dakikada bir tetiklenebilir. Ancak çözümsüz değil.

Bunu bir senaryo ile örneklendirerek yapalım. Kullanıcılarımızın dönüşlerini aldığımız bir veri tabanımız var. Bu veri tabanındaki tüm veriler bir cron işlemi tarafından dakikada bir kontrol ediliyor ve yeni gelen kayıtlar elimize e-posta şeklinde ulaşıyor. Ancak bu süreyi 30 saniyeye indirmek istiyoruz.

Cron'un 60 saniyede bir tetikleneceği gerçeğini göz önünde bulundurarak, istediğimiz işlemi çalıştırıldığı anda bir kez yapıp 30 saniye uyuyan ve işlemi tekrar yapan sonra kendin sonlandıran bir script işimize yarayacaktır.

Crontab satırı

*/1 * * * * /usr/scripts/test.sh > /dev/null 2>&1

test.sh

#!/bin/bash
echo "Mesaj Icerigi" | mail -s "Mesaj Basligi" eposta@adresi
sleep 30
echo "Mesaj Icerigi" | mail -s "Mesaj Basligi" eposta@adresi

Bu zamanı daha kısaltabilir veya uzatabiliriz elbette. Ancak dikkat edilmesi gereken shell scrpitin işini ne kadar sürede bitirdiğidir. Bu zamanlamayı aksatabilecek en önemli değişkendir.

Güncel olarak çok kullanılmıyor olsa da cron.allow ve cron.deny dosyaları da mevcuttur. İsimlerinden anlaşılacağı üzere bu dosyalar ile sistem yöneticisi bazı kullanıcılar için izin verebilir veya izin vermeyebilir. Fakat güncel olarak pek kullanıldığına tanık olmadım.

Bazen tuhaf tuhaf işlere ihtiyaç duyuyorum. Bu script de onlardan bir tanesi. Yaptığı iş son derece basit. Belki bunu yapamanın daha doğru bir yolu vardır ama aramak için vakit bulamadım ve bu scripti yazdım.

İki farklı router mevcut ve biri ortadan kaybolursa sunucunun diğeri ile devam etmesi gerekliliği ortaya çıktı. Aşağıdaki script Ubuntu 16.04 üzerinde çalışıyor ve herhangi bir problem çıkarmadı. Bir cron ile çalıştırabilirsiniz.

import os
import subprocess
import re

def pingGW (gw):
	try:
		output = subprocess.check_output("ping -c 3 "+gw, shell=True)
	except Exception, e:
		return False
	return True
def findIP (routing_table, ip):
	result = re.findall('\\b'+ip+'\\b', routing_table, flags=re.IGNORECASE)
	if len(result) > 0:
		return True
	else:
		return False

# Check maingw
maingw = "172.22.25.1"
maingw_response = pingGW(maingw)

# Check backupgw
backupgw = "172.22.25.2"
backupgw_response = pingGW(backupgw)

# Fetch routing table
route_table = os.popen("/sbin/ip route show").read()

# If maingw is down and backupgw is up, switch to backupgw
if (maingw_response == False ) and (backupgw_response == True):
	# Switch to backupgw
	if findIP(route_table,backupgw) == False:
		os.system("/sbin/ip route del default")
		os.system("/sbin/ip route add default via %s" % backupgw)
if maingw_response == True:
	# Switch to maingw
        if findIP(route_table,maingw) == False:
		os.system("/sbin/ip route del default")
		os.system("/sbin/ip route add default via %s" % maingw)

Bu konuda yazılmış binlerce makale olduğu aşikar. Ancak herkesin kendince bir nedeni olduğu da ortada. Bu nedenle hemen hemen tüm projelerde Ubuntu kullanmamın nedenini anlatmaya karar verdim.

Aşağı yukarı 13 yıldır sistemler yönetiyorum. Dolayısıyla bir çok projenin içerisinde bulundum ve bulunmaya devam ediyorum. Etrafımda bir çok arkadaşım Ubuntu'ya olan düşkünlüğüme şaşırıyor. Özellikle 10 yıl gibi bir süre FreeBSD ile çalışmış birinin Ubuntu tercihini yadırgıyorlar.

Çoğunluğun tercihi doğru olmak zorunda degildir.

Aynı zamanda piyasadaki CentOS düşkünlüğü ortada. Önceden yapılandırılmış ve çalışan bir çok projede karşılaştığım dağıtım CentOS. Bu yazıyı dağıtım ya da farklı işletim sistemlerini çarpıştırmak niyetinden uzak tutarak bitirmeye çalışacağım. Ancak muhtemelen bazı noktalarda olacak olan bu.

Çalışmaya başladığım ilk şirkette FreeBSDler ile karşılaştım. O sıralarda FreeBSD tecrübem yok denecek kadar azdı. Zaman içerisinde elbette haşır neşirliğim arttı ve 10 yılım geçti. Bir sürü farklı servisi üzerinde geliştirdik ve yayınladık. Elimizdeki sunucular şimdi ile kıyaslanamayacak kadar küçük donanımlardı. Hepi topu 512MB RAMi bulunan Pentium 3 sunucular ile bir çok iş başarılmıştı. Zamanına göre FreeBSD oldukça önemli avantajlar sağlıyordu. Bunların en başında da süphesiz ports tree geliyor. Mümkün olan hemen herşeyi biraz daha optimize olarak yeniden derlemek performans anlamında uçurum kenarında olan bu sunuculara oldukça iyi geliyordu.

Fakat yıllar geçti ve donanım daha ucuza ulaşılabilir bir hal almaya başladı. Yatırım konusunda cimri davranan şirketi buna ikna etmek ne kadar zor oluyorsa da eskisi kadar sefalet içinde değildik. Donanım kaynağım genişleyince uzun suren compiling partilerine daha az ihtiyaç duymaya başladım. Hiç bir CFLAG biraz daha RAMin ve CPU'nun verdiği hazzı sağlayamadı elbette. Dolayısıyla binary packed daha çekici bir hal almaya başladı. Hele ki sanallaştırma teknolojileri ile birlikte işin rengi iyiden iyiye FreeBSD ekseninden kaydı.

Elbette tek nedeni bu değil ama konuyu sündürmek istemiyorum. İlk olarak Open SUSE ile ilgilenmeye başladım. Bunun tek nedeni SUSE Studio denen harika araca sahip olması. Ancak özellikle OS upgradelerde yaşattığı anlamsız çile ve istediğim paket çeşitliliğini bulamadığım için kısa sürede kendisi ile yollarımızı ayırdık.

Archlinux pişmanlıktır!

Kısa bir süre çok da istemediğim Archlinux ile önemli bir proje yaptık ve anında ağzımızın payını aldık. Bela isteyen productionda kullanabilir.

Debian bir tercih olabilirdi ancak katı özgür yazılım gestapoluğu beni hep rahatsız etmiştir. Ne kadar rahatsız olsam da Debian Package Manager hep mükemmeldi. Bu sıralar Redhat furyası yüzünden CentOS göz önüne çıkmaya başlamıştı. Hatta yer yer Scientific de aynı şekilde.

Redhat ile 98'de tanışmıştım. O zamandan bu zamana özellikle paket yöneticisinde devrimsel bir değişiklik göremiyorum açıkçası. Halen bağımlılık yönetimini geriye dönük yapamıyor bu RPM tabanlı dağıtımlar. Kaldırdığım bir paketin bin adet kullandığı kütüphaneyi diskimde görmek istemiyorum. Ancak ne CentOS ne de diğer RPM tabanlılar bunu asla yönetemedi. Bildiğim kadarıyla da halen yönetemiyorlar.

Özellikle en popüler olan CentOS'un bu konuda bir hamle yapmasını beklerdim ama maalesef. Öte yandan paket sürümlerinin olukça eski olması da itici taraflarından biridir benim için.

Araya bir bilgi vermek gereği ile konuyu ilgili olarak böleceğim. Bu bahsettiğim dağıtımlar ve daha fazlasıyla ilk kez tanışıyor değildim. Yıllar içerisinde 10larca dağıtımı gerek kişisel bilgisayarımda gerekse projelerde zaten kullandım. Bu kararları alırken de tüm bu tecrübelerin birikimlerinden faydalandım.

Sonunda zaman zaman kullandığım, hemen hemen hiç başıma bela olmayan Ubuntu'ya eğilmeye karar verdim. Ubuntu'nun çıkışı onu sunucularda kullanmak isteyecek insanları ürkütüyordu. Sanki o hep basit, pek işe yaramaz ve genellikle son kullanıcıyı hedefleyen bir dağıtım gibiydi. Fakat kullanımı kolaylaştırmak için gösterdikleri çabayı, sunucu sürümlerinde de gerçekleştirmeyi başardılar.

Tüm bağımlılık yönetimini yapabilen bir paket yönetim sistemi mevcut. Aynı zamanda son derece geniş paket çeşitliliği sistem yöneticisini yalnız bırakmıyor.

LTS sürümlerinin güncelliği, herhangi bir CentOS sürümünden bile daha güncel. LTS ya da ara sürümlere upgrade inanılmaz kolay. Öte yandan 3. parti geliştiricilerin kesinlikle Ubuntu repositoryleri mevcut. Artık yavaş yavaş standartları koymaya başladı diye düşünüyorum.

Tüm dağıtımları inceledim diyemem ancak systemd dönüşümünü oldukça hızlı yapmış ve geriye dönük uyumluluğu oldukça iyi sağlamış bir dağıtım Ubuntu. Stock paketlerinin ön tanımlı konfigürasyon dosyalarının zenginliği ve maintainerlar tarafından yapılan minik konfigurasyon araçları... Gerçekten hayatı kolaylaştırıyor.

Üzerinde neredeyse 100 Gbite varan trafikler döndüren web servislerinden tutun da videoları işleyen CPU/GPU kümelerine kadar bir çok alanda Ubuntu tercih ediyorum. CentOS kullanan ve Ubuntuya göçen çok kişi gördüm ancan Ubuntu'tan göçe hiç rastlamadım.

Uzun lafın kısası, Ubuntu kullanmamak için bir neden göremiyorum.

Yazının içinde bazı teknik terimler olabilir, hemen sıkılmayın. Asıl amacım diziden bahsetmek. Spoiler başladığında haber vereceğim.

Yeni ve güzel bir diziden bahsetmek için niyetlendiğim bu yazıda, yeni yine yeniden bir Hollywood Computer vakasıyla karşı karşıya kaldığım için çok üzgünüm.

Hollywood Computer Nedir?

İçerisinde Hacking v.b bilgisayar teknilojileri unsurlarını konu edinen dizi veya filmlerde bolca karşılaştığımız kurgu bilgisayarlardır. Her ne hikmetse bu bilgisayarlar asla bizim kullandıklarımıza benzemezler.

Mütemadiyen ses çıkarırlar. Öte yandan, henüz 4-5 yıldır Compositing Desktop Managerlar işlerini hakkıyla yapabilmeye ilk adımı atmış olsalar da, bu dizi ve filmlerde kullanılan Hollywood bilgisayarları çılgındır. Koca bir firmanın verisini taşıyan bir veritabanı sunucusunun arayüzünde, neden 3D pencere efektleri olmalı diye kimse sormamıştır.

Böylesine gürültücü bilgisayarları günlük hayatınızda kullanabilir misiniz? Mümkün değil! Bu yalnızca gürültü kirliliği. İşin bir de gerçek hayata uygunsuzluğu söz konusu ki son yıllarda daha da rahatsız edici hale gelmeye başladı.

Uzunca bir süre ekranlarda gördüğümüz bilgisayarlar tamamiyle hayal ürünü ve tuhaf şeylerdi. Gayet kullanıcı düşmanı arayuzleri ve gürültücü speakerlarıyla beynimizi tırmaladılar. Matrix Reloaded filminde bu iş biraz farklı bir boyut aldı. Bu kez filmde kullanılan bir bilgisayarda, gerçek hayatta kullandığımız bir yazılım yer alıyordu.

Bu filmde Trinity, nmap kullandı. Nmap için özetle bir port tarayıcısı diyebiliriz. Bir IP adresinin online olup olmadığından, üzerinde çalışan portları öğrenebilmeye ve hatta bazı finger printler yardımıyla, karşıdaki cihazın işletim sistemini tahmin etmeye bile yardım eden, harika bir yazılımdır.

Konuyu Mr. Robot ekseninden çıkarmadan devam etmek istediğim için nmap faslını burada kapatıyorum.

Matrix'te cereyan eden bu gerçeğe yakın durum çok ilgi çekmişti. Özellikle bilgisayar geekleri bundan çok hoşlanmıştı. Artık filmlerde tamamıyla gerçeğe aykırı senaryolar ve durumlar üzerinden yürümüyorlar, hali hazırda varolan popüler yazılımların kendilerini de ekran karşısına çıkarıyorlardı.

Bu kez de şöyle bir durum oluştu. Gerçeğe yaklaşmak amacıyla, gerçek sektör terimleri ve durumları yaratılmaya çalışılırken daha çok mantık hataları yapılmaya başlandı.

İlk bölümü yayınlanan Mr. Robotu kesinlikle takip edecek olmam ve diziyi ilk bölümünden beğenmem bir yana, malesef gerçek durumların saçmalaması girdabına girmiş bulunuyor.

Yazının buradan sonrası, tatlı tatlı, minik ve sevimli spoilerlar içerir.

Dizideki ana karakterimiz bir security expert. Bordro mahkumu olarak bir şirkette çalışıyor. Ancak aynı zamanda geceleri anonim oluyor ve çılgın hackler yapıyor. Eğer çok iyiyseniz kesin iletişim sorunlarınız olmalıdır klişesini de pas geçmemişler. Karakterimiz, insanlarla iletişim sorunları yaşıyor.

Velhasıl gün geliyor ve ana karakterimizin çalıştığı firmanın müşterisi bir saldırı alıyor. Aslında saldırı senaryosunu sevdim. Saldırgan önce DDoS yapıyor ve dikkati başka noktaya çekiyor. Bu esnada o ağda bulunan bir server, saldırgan tarafından rootlanıyor (ele geçiriliyor).

Tabi ortalık bu denli karışıkken, rootlandığının farkına varmak pek kolay değil. Fakat ana karakterimiz cevval. Bunu anlıyor ve sunucuları kapatmamız gerek, temizleyip tekrar açarız fikrini ortaya atıyor.

İşveren bu duruma sıcak bakmıyor ve sunucuların kapanmasının imkansız olduğunu söylüyor. A benim canım! Zaten down değil misiniz? Fiziksel olarak kapatsan ne olacak? Zaten sen ofisine gelene kadar 3 saat geçmiş.

Cevval adamımız o sırada neler olduğunu anlamaya çalışıyor ve ekranından bir görüntü yansıyor.

Tuhaf bir çıktı. Bir sunucuda neden Xorg çalışır? Hadi ihtiyaç hasıl oldu çalıştırdın. Niye root ile çalıştırdın? Öte yandan, PIDlerin tutarsızlığını farkettiniz mi? Özellikle terminal ve websrv1FF1 processlerine göz atın. Farkeden buyursun yorumlarda konuşalım.

Aman neyse, belki de saldırgan yaptı onu diye düşündüm. Rootkitinin adını Xorg yapmıştır dedim. Her ne kadar salaklık olsa da olsun. Gerçeğe yakın senaryolar ürettikleri için mutlu olmaya başladım yeniden.

Çok geçmeden 2. bomba geldi. Sunuculara uzaktan erişim yapamamaya başladıklarını farkettiler. Mecburen ilk duruma döndüler. Sunucuları kapatıp temizleyecekler ve tek tek online hale getirecekler.

Patron dedi ki:

"Bize jet lazım! Veri merkezine gidiyoruz."

Ne  Lazım? Pardon?

Yahu sene 2015. Jet kiralamayı biliyorsunuz ama 100$'a bir tane KVM Switch alamadınız mı? Çok saçma bir işti. Velhasıl gece yarısı kalktılar gittiler.

Veri merkezinde ise özlenen görüntü karşımızdaydı. Bu kez olayı biraz değiştirmişler.

Karşınızda Hollywood Network Monitoring!

Öyle havalı birşey ki! İşveren yalnızca bu ekrana bakarak, hackerın tam olarak nerede olduğunu görebiliyor ve bağırıyor "Neredeyse yedeklere ulaştı!" Merakınızı hemen gidereyim. Evet bu monitoring yazılımı da doyurucu oranda bipliyor.

Senaryoları gerçek hayata yaklaştırmak, özellikle konuyla alakalı izleyicileri oldukça meraklandırıyor. Ancak inanıyorum ki zaman içerisinde bu bariz mantık hataları ve gereksiz abartılar da normalleşecektir.