Kategori arşivi: Linux

Sistem Yöneticisi ve Hata Ayıklama Deneyimleri

Her sistem yöneticisinin başlıca yetilerinden biri olan “Hatayı Bulma, anlama ve düzeltme” yaptığımız işin en önemli kısımlarından biridir. Herkes bir konuda çok iyi seviyede bilgi sahibi olabilir ancak herkes her konuda ileri seviye bilgi sahibi olamaz. Ne demek istediğimi biraz daha detaylı anlatmaya çalışayım; zaten çok bilgili olduğumuz bir konuda muhtemel hataları ve sebepleri tahmin etmemiz mümkün olduğu için bu problemlerle karşılaşmadan önlemlerimizi alırız. Ancak hepimizin bildiği gibi verdikleri ilanlarda açıkça Voltran arayan firmalar olduğu sürece hepimizin bir çok konuya bölünmesi gerekiyor ve zaman zaman hiç bilmediğimiz deryalarda dahi kendimizi bulabiliyoruz. Böyle durumlarda karşılaştığımız problemleri çözebilmek için hepimizin sahip olması gereken skill kesinlikle az önce yazmış olduğum “Hatayı Bulma, anlama ve düzeltme” adımlarından ilk ikisidir.  Aslında bu üçlüyü “Hatayı bulmak ve ayıklamak” olarak iki parçaya ayırabiliriz, zira bir kez hatayı bulduğumuzda artık çözüm sürecine geçmiş oluruz ki yeterli imkan ile çözülemeyecek problem olmadığını düşünmekteyim.

Bu konuda interneti talan ettiğimizde bir çok methodun varlığından haberdar oluruz, kimileri uzun uzun bunları detaylandırır, kimileri kısa ve sonuç odaklı çözümler önerir, benim de kendimce uyguladığım adımlar mevcut, bunları paylaşmakta herhangi bir sıkıntı görmüyorum;

  1. Problemle karşılaşma

Problemin sonuçları ile karşılaşıncaya kadar problemden haberdar değilsek bu noktada bir hatamız olduğunu bilmeli ve bunu bir kenara ders niyetine yazmalıyız. Zira tecrübelerimizden ders almanın birçok konuda faydalı olduğu inancını taşıyorum. Problemi önceden tespit edebilmenin bazı methodları mevcut, örneğin monitoring araçları. Bu araçları ve raporlarını düzenli kontrol etmek olasık bottleneckleri ve gelebilecek sorunları erken görmemizi sağlar. Ben bunun için şu tooları kullanıyorum;

MuninZabbixMmonit, ek olarak son kullanıcıya verdiğiniz servisleri bir son kullanıcı gibi deneyimleyecek perl, python veya ne ile yazabiliyorsanız bir bot çok makbule geçer.

Problemin sonuçları ile karşılaştığımız andan itibaren olası etki alanını (etkilenen ve devamında etkilenebilecek servisleri, kullanıcıları vb.) belirlemeli ve bu doğrultuda aksiyon almalıyız.

2. Problemi anlama

Problemi anlamak için öncelikle güncel logları (işletim sistemine ait olan, servislere ait olan mümkünse IPMI üzerinden donanıma ait olan loglar) sonrasında ise geçmişe dönük logları incelemek, monitor toollarının grafiklerinden faydalanmak, linux için var olan diğer araçları kullanmak öncelikli hareketler olmalıdır. Etkilenen server, service vb. ürün/programları mümkünse production seviyesinden çıkartıp arka planda daha rahat hareket edebileceğimiz bir ortama taşımalıyız. Sorunun donanım, network veya program seviyesinde olup olmadığını anlamak yine önceliklerimiz arasında yer almalıdır. Örnek olarak; storage üzerinde I/O sorunu görüyor olabiliriz, muhtemelen disklerden bir veya fazlası arızalanmış olabilir öte yandan çalışan program alakasız bir şekilde I/O’u tüketiyor olabilir. Burada anlık çözüm yerine sorunun gerçek sebebini bulmanın ne kadar önemli olduğunu görebilirsiniz.

Bu adım için en çok kullandığım ürünler;

iotophtopatop, ntop, iftop, ethtool, free, df, dmesg ve diğer logları detaylı incelemek

3. Problemi tanımlama

Takip ettiğimiz log dosyaları, grafikler ve diğer araçlar bize o an ve geçmişte sistemimiz üzerinde neler olup bittiğine dair detaylı bilgiyi vereceklerdir. Bu noktada bir dedektif gibi çalışarak iplerin uçlarını birbirine doğru bağlamalı ve hataya sebep olan gerçek sebebi net bir şekilde tanımlayabilmeliyiz. Yoksa daha öncede söylediğim gibi restart ettim düzeldi cümlesi aynı sorunun ileride tekrarlayacağına ve belkide daha kötü sonuçlara yol açabileceğiniz unutmamalıyız.

Bu noktada kullandığım araçlar;

perf-tools

3. Problemin çözümü

Bu noktada artık çok konuşulacak birşey kalmıyor.

Yukarıda günlük hayatta sürekli kullandığım program ve komutları paylaştım, herhangi birine faydamız dokunursa ne mutlu.

Sevgiler,

Fikri DAL

Sistem Yöneticisi Olmak!

Gün geçmiyor ki yeni bir hacker filmi-dizisi çıkmasın. Son yılların trendi hacker olmak, dolayısıyla TV ekranlarına yansımasını çok normal buluyorum. Kötü olan yanı ise berbat senaryoları, aptalca hacking sahneleri, gerçeklikten çok uzaklaşmış olmaları. Bu tip filmleri artık neredeyse Sci-Fi kategorisine  sokabiliriz çünkü çoğumuzun bildiği üzere gerçeklik kavramını yitirmiş durumdalar. Nadiren güzel yapımlar çıkıp heyecanlanmama sebep olabiliyorlar, örneğin Mr.Robot… Eleştirilebilecek bir çok yanı olmasına rağmen bugüne kadar gördüğüm en iyi Hacker/Hacking dizisi diyebilirim. Günlük hayatta kullandığım bir çok komutun/ekranın senaryoda yer alması ve gerçekliğe son derece yakın olması benim ilgimi çeken ve övgümü alan başlıca kısımlarıdır. Her ne kadar Hacking methodları biraz geride kalmış olsa da diziyi son derece gerçekçi buluyorum fakat bu nasıl bir tezattır ki dizinin kahramanı gerçeklikten son derece uzak durumda 🙂 Dizide ilgimi çeken başka bir konuda Sistem/Güvenlik Yöneticileri’nden oluşan şirketlerin varlığı. Aslında hemen hemen her sistem yöneticisi piyasada danışmanlık ve destek hizmetleri vermiştir. Fakat sadece sistem yöneticilerinden oluşan bir şirketin varlığını düşünmek bile çok hoş. Öte yandan yapılan işi standartlaştırmış olması da yaratıcılığı öldürebileceği gibi yakın süreçte bir takım aksaklıklar ortaya çıkartacağı ve kötü niyetli insanlara karşı sistemini koruma işinde hatalar yapılacağınım belirtisidir.

Birçoklarına göre bilgisayar ile geçirilen vakit iyi bir sistem/network adamı olmak ile doğru orantılıdır, bana kalırsa bilgisayar ile yatıp bilgisayar ile kalkmak, yani “asosyal” olmanın işimizle hiçbir alakası yok. Dizide de Eliot karakteri asosyalliğin üst sınırlarını zorlamanın yanı sıra bir kaç ağır psikolojik rahatsızlığa sahiptir. Ve şirketin en iyi personeli odur, çünkü sürekli bilgisayarı ile beraberdir, öte yandan diğer karakterler normal insanlar gibi yaşadıklarından hiçbir zaman Eliot kadar iyi olamayacaklardır! Asosyallik ile dahiliği de karıştıran bu güruh için söylenebilecek sözler belirli aslında; Eğer topla yatıp kalkan Tsubasa gerçek olsaydı belki bu söylediğiniz gerçek olurdu.

Bu ütopik ortamdan çıkalım gerçek hayatta neler oluyor, biraz da buna bakalım isterim.

Linux, bilinenin aksine çok güvenli bir işletim sistemi değildir. Herhangi bir işletim sistemini daha güvenli hale getiren o sistemin yöneticisidir. Hepimizin hemfikir olduğunu düşündüğüm “Hacklenemeyecek sistem yoktur” düsturu ile sistem yöneticisinin sürekli kendini ve sistemlerini yenilemesi, kontrol altında tutması ve takip etmesi çok önemlidir.   Mükemmel sistemi yarattığınızı hayal edin, dünyanın bilinen tüm ünlü isimlerinden de %100 güvenlidir teyidini aldığınızı farz edin(imkansız), tebrikler başardınız. Fakat unutmayın hedefinize ulaştığınız andan itibaren artık daha büyük bir hedefsiniz. Yani faydadan çok zararı olacağı kesin.

Daha güvenli bir sistem oluşturmak için bir çok teknik ayrıntımız mevcut fakat birde literatürümüz var;

Daha güvenli bir sistem oluşturmanın başında gelen kurallardan biri de sessiz olmaktır. Mümkün olduğu kadar sunucularınızı, yaptığınız işleri, çevirdiğiniz trafiği saklayın. Ne kadar iyi bir güvenlikçi olursanız olun insanlara ulu orta meydan okumayın! Sonunun çok kötü bittiğini gördüğümüz bir kaç hikaye mevcut 🙂

Nereye, hangi konuma, hangi firmaya geldiğinizin bir önemi yok, burnunuzu büyütüp rutin kontrolleri atlarsanız sonunuz yine çok iyi olmayacaktır.

Hepsinden önemlisi amatör olmak bir sistemcinin en önemli vasfıdır. Amatör ruhunuzu kaybetmeyin ve bunu; güçleriyle, paralarıyla almalarına izin vermeyin! Bir amatör gibi düşünmeyi bıraktığınızda artık sisteminizi çok iyi koruyamayacaksınız. Bunu sakın unutmayın! 9-6 kafasına giren sistemci çok kısa sürede topu diker, düşman uyumuyor unutmayın! Parisa ablamızın, sevgi pıtırcığımızın, baş tacımızın dediğini unutmayın; Dont be evil.. but do know  evil….

Gündelik yoğunluklar arasında prensiplerinizden taviz vermeyin, prensibinizi çiğnemeniz için size baskı yapıp size zorluk çıkartan adam, sizin prensibinizi çiğnemenizden doğacak ilk problemde sizi eleştirme densizliğinden geri kalmayacaktır.

İnsanlar ne söylerse söylesin, risk almaktan çekinmeyin, ha bir de fikirlerinizi ulu orta söylemeyin. Sizin fikrinizi kendi fikri gibi lanse etmeye meraklı canlı türleri biyoloji kitaplarına girdiler!

Sunucularınıza başkalarının müdahale etmesine izin vermeyin, bir sunucuya ne kadar çok adam girerse o kadar çok sorun çıkar, sadece kendi ekibinizin sunucuya erişmesine müsaade edin.

Bunlar olmadı mı ne olur derseniz, Kaos olur, gözyaşı sel olur, arkandan gülen bol olur..

Sevgiler,

fd

 

 

 

 

(squid): failed to find or read error text file

Proxyniz bir anda böyle bir hata vermeye başladı ve çalışmıyorsa sebebi kesinlikle yanlış yere eklenen yanlış bir bilgidir.
Yanlışın nerede olduğunu ister tek tek bütün squid dosyalarını gezerek bulursunuz ya da ;
tail -f /var/log/squid3/cache.log
komutunu çalıtırır ve hatalı satırı görürsünüz.
(cache.log başka bir dizinde olabilir.)

dovecot: Fatal: Time just moved backwards by 12 seconds. This might cause a lot of problems, so I’ll just kill myself now.

Dovecot ile bu sorunu yaşıyorsanız çözüm için aşağıdaki adımları uygulayabilirsiniz;

Dovecot sorundan kendi sayfasinda bahsetmis;

http://wiki2.dovecot.org/TimeMovedBackwards

Bu sorunu benim yaşama sebebim 1. seçenekti. Yani ntpdate. Herseyi manual kontrol etmek hiç işime gelmediğinden mümkün olduğu kadar otomasyona kaçmayı seviyorum. Crontab’a eklediğim ntpdate komutu ile her saat başı zaman kontrolu yapıyorum. Olası bir zaman sorununda loglarım maksimum 59 dakika yanlış süreyle işlenmiş olabilirler.

Şimdi Dovecot bana ntpdate kullanma diyor evet bu bir çözüm ancak ne kullanıp kullanmayacağıma bir başkası karar verecekse keyfim kaçıyor.

Bunun icin ufak bir dovecot kontrol servisi yazdım ve sizinle paylaşıyorum, script son derece yalın ama benim işimi görüyor isterseniz geliştirip burada paylaşın.

Servisi debian için yazdım, diğer dağıtımlarda durum nedir denemedim.

Yeni baslayanlar icin ufak bir not;

asagidaki scripti /usr/bin/kontrolet diye bir dosya olusturup icine yapistirin,

chmod +x /usr/bin/kontrolet     komutu ile calisitirma yetkisi verin,

/usr/bin/kontrolet &

komutu ile calistirin ve ssh dan ayrilmadan once 60 saniye bekleyin.

#!/bin/bash
# fd 02/09/2011
if [ `ps aux | grep dovecot | grep -c -v grep` -gt 0 ]
        then
                echo "active"
                sleep 60
                /usr/bin/kontrolet &
                exit
        else
                echo "not active"
                /etc/init.d/dovecot restart
                sleep 60
                /usr/bin/kontrolet &
                exit
        fi

 

 

Telnet Kullanimi

Telnet, uzak baglanti yapmamizi saglayan bir protokoldur. Bundan yaklasik 10 yil once henuz ssh kavrami ile tanismamis oldugumuzdan linux sunucularimiza telnet vasitasiyla baglanirdik.  Telnet kullandigimiz donemlerde hackinge daha fazla maruz kaldirdik cunku telnet, verileri text formatinda yani sifrelemeden gonderir. Bulundugunuz agi dinleyen biri bu verilere cok rahat ulasabilir ve herhangi baska bir seyede ihtiyac duymaz. Daha sonralari ssh ile tanistik, artik serverlarimiza telnet serveri neredeyse hic kurmaz olmustuk. Ama telnet ile bagimiz hic bir zaman kopmadi ve hala gunde bir kac kullandigimi net bir sekilde dile getirebilirim. Bugun size telneti hangi amaclarla kullanabilecegimize dair bir kac ornek sunarak bilgi aktarmaya calisacagim.

Telnet Kullanimi yazısına devam et

Debian 4.0 – Postfix Kurulumu – 2

4. Postfix/Courier için MySQL Database’ i oluşturma

Öncelikle MySQL root userı için bir şifre belirleyelim bu güvenliğimiz için gerekli;

mysqladmin -u root password dinopsys

yukarıdaki komut ile birlikte artık mysql root userinin şifresi “dinopsys” tir.

mysqladmin -u root -p create mail

bu komut ile de mail isimli bir database oluşturalım.

Debian 4.0 – Postfix Kurulumu – 2 yazısına devam et

Debian 4.0 – Postfix Kurulumu – 1

Postfix bildiğiniz üzere son zamanların en moda mail sunucusu… Yıllardır Qmail kullanmama rağmen artık modasının geçtiğini söylemekten çekinmiyorum. Bu yazımızdan Virtual User ve Virtual domain oluşturabileceğimiz bir postfix kuracağız. İşletim sistemimizde Debian 4.0 Etch olacak… Daha önceki makalelerimizde debian 4.0 Etch kurulumunu vermiştik dilerseniz önce o yazıları ziyaret edip Debian 4.0 kurun…

Debian 4.0 – Postfix Kurulumu – 1 yazısına devam et