sshuttle – garibanın vpn’i

08 Şubat 2014 23:07 / 4 Comments /

Geçtiğimiz günlerde meclisten geçen torba yasa kapsamında oldukça(!) özgür olan internetimiz daha da “özgürleştirildi.” Hal böyle olunca DNS, VPN nedir bilmeyen çoğu kullanıcı; bir anda bu kavramlara aşina olmaya başladı.

Gelelim konuya… sshuttle ufak ama bir o kadar da kullanışlı, güzel bir araç. Yaptığı iş tüm internet bağlantınızı ssh yardımıyla başka bir makine üzerinden geçirmek. Bu haliyle bir nevi VPN görevi görüyor. Zaten kendisini “poor man’s vpn” olarak tanıtıyor. Halihazırdaki vpn çözümleri pahalı veya kompleks (ipsec vs.) yapıda olduğu için insanı oldukça uğraştırıyor. sshuttle tam bu konuda devreye giriyor ve basit bir şekilde internet bağlantınızı güvenli hale getiriyor. (kem gözlerden koruyor diyelim.)

sshuttle kurmak için size sadece şunlar lazım:

  • GNU/Linux kurulu bir makine. (MacOS veya *BSD üzerinde de çalışıyor.)
  • Tercihen (eh) yurtdışında bulunan; ssh bağlantısı kurabileceğiniz bir sunucu. (Bugünlerde ayda $1 civarı bir meblağa kiralayabiliyorsunuz)

sshuttle’ın çalışacağı GNU/Linux kurulu makinenizde root yetkilerine sahip olmanız gerekiyor; zira sshuttle arka planda iptables’ın nimetlerinden yararlanıyor. ssh bağlantısı kuracağınız makinede ise root olmanıza gerek bulunmuyor. Sıradan bir kullanıcı hesabı ve python’ın kurulu olması yeterli.

Gelelim kuruluma, sshuttle’ı sadece kendi makinenize kuruyorsunuz, sunucu tarafında kurmanız gereken bir paket bulunmuyor.

Arch Linux kullanıyorsanız, sshuttle community deposunda yer alıyor, kurmak için şu komut yetiyor:

pacman -S sshuttle

Debian/Ubuntu ve benzeri dağıtımlarda:

apt-get install sshuttle

Fedora kullanıcıları ise EPEL deposunu ekleyip şu şekilde kurabilirler:

yum install sshuttle

Çalıştırmak için ise aşağıdaki komut yetiyor (root olarak veya sudo ile):

sshuttle --dns -r kullanıcı@makine 0/0 -D

Parametrelerin neler yaptığını da açıklayalım:

-r parametresi: remote anlamı taşıyor; yani bağlanacağınız ssh sunucusu
0/0: hedef ağ, 0.0.0.0/0′ın kısaltması. 0/0 tüm internet bağlantısını ifade ediyor. Belirli bir subnete bağlanmak istiyorsanız 0/0 yerine subneti verebilirsiniz.
--dns: DNS sorgularını ssh üzerinden yapmanızı sağlıyor.
-D: sshuttle’ın arkaplanda (daemonize) çalışmasını sağlıyor.

Ne diyelim, zalimin yasakları varsa garibanın da sshuttle’ı var!

Posted in: Genel / Tagged: , ,

sslh: beşi bir yerde!

12 Mayıs 2013 02:05 / Leave a Comment /

Çoğu zaman kurumlarda çalışırken insanı zıvanadan çıkartacak, hatta tansiyonunu fırlatacak (literally) proxy yapılandırmalarıyla karşılaşmak mümkün oluyor. Hatta öyle ki, bazen bir yazılım kurmak istediğimde veya bir yere bağlanmam gerekiyorsa ilgili kurumdaki sistem yöneticisini ikna etmek için kırk takla atmam gerekiyor.

Benzer kısıtlamalardan bunalan Yves Rütschle oturmuş sslh‘ı yazmış. sslh, tek bir portu (isterseniz birden fazla ayarlamak da mümkün) kullanarak bu port üzerinden birden fazla hizmete erişebilmenizi sağlayan, katman görevinde bir yazılım. SSL ve SSH’in karışımından türetilmiş bir isim.

Genelde erişimi engelleyen yerlerde https (443) başta olmak üzere bazı portlar serbest bırakılır. Dolayısıyla bir porttan dışarı çıkabiliyorsanız, sslh yardımıyla SSH, HTTP(S), OpenVPN, XMPP hizmetlerine bağlanmanız mümkün oluyor. sslh’ı belirli bir portta -tercihen 443- dinlemeye (listening) alıp, bahsettiğim protokollere aktarmasını sağlayabiliyorsunuz.

Çoğu dağıtım için sslh’ın paketleri bulunuyor. Ben Arch Linux üzerinde nasıl yaptığımı anlatacağım. Öncelikle sslh’ı sürekli kullanacaksanız için bir ayar dosyası oluşturmanızda fayda var. Öteki türlü parametreleri kullanmak isterseniz nerden baksanız 1 paragraf bir komut girmek zorunda kalabilirsiniz.

Gelelim kuruluma, Arch Linux üzerinde kurmak için pacman kullanmanız yeterli, sslh’ın paketi Arch Linux depolarında (community) yer alıyor:

pacman -S sslh

Paket kurulduktan sonra /etc/sslh.conf dosyasını dilediğiniz gibi yapılandırabilirsiniz. Ben SSH, SSL, OpenVPN için aşağıdaki yapılandırmayı kullanıyorum.


verbose: true;
foreground: true;
inetd: false;
numeric: false;
timeout: 2;
user: "nobody";
pidfile: "/var/run/sslh.pid";

listen:
(
{ host: "0.0.0.0"; port: "443"; }
);

protocols:
(
{ name: "ssh"; service: "ssh"; host: "localhost"; port: "22"; probe: "builtin"; },
{ name: "openvpn"; host: "localhost"; port: "1194"; probe: "builtin"; },
{ name: "http"; host: "localhost"; port: "80"; probe: "builtin"; },
{ name: "ssl"; host: "localhost"; port: "8443"; probe: [ "" ]; }
);

on-timeout: "timeout";

Yapılandırma dosyasındaki ilk 6 satır öntanımlı sunucu ayarları. Ne oldukları zaten anlaşılıyor. Listen bloğundaki değer, sslh’ı hangi interface’lerde hangi portta çalıştıracağınızı belirtmek için kullanılıyor. Ben 443 portunu kullanmayı tercih ediyorum.

Daha önemlisi ise protocols kısmı. Burada 443′ten gelen taleplerin arka taraftaki hangi servise/porta gideceğini belirttiğiniz kısım. probe kısımları önemli, zira “protocol mismatch” dediğimiz protokol çakışması durumunda ne olacağına burası karar veriyor. Kaba bir tabirle, 443 numaralı porta gelen talebin hangi servise gideceğine “prober” karar veriyor. (web sunucuda https için 8443 kullanıyorum, 443′ü sslh kullanıyor çünkü)

Ben bu hizmetlerin tamamını TCP protokolünde çalıştırıyorum, UDP denemedim. OpenVPN’i eğer udp kullanıyorsanız, tcp’ye çekin veya tcp’de çalışan bir instance çalıştırın.

Gelelim çalıştırma kısmına, sslh yapılandırmasını kaydettikten sonra Arch Linux kullanıcılarının vermesi gereken tek komut şu:

systemctl start sslh-fork.service

Elle çalıştıracaklar için ise verilecek komut şu:

/usr/bin/sslh-fork -f -F /etc/sslh.conf

Bu şekilde tek bir portu kullanarak birden fazla servise ulaşmanız mümkün oluyor.

Posted in: Genel / Tagged: , , ,

JIRA 5.x’den Redmine proje yönetim sistemine geçiş

23 Nisan 2013 19:25 / 2 Comments /

Uzun zamandır blogum başıboş duruyor. Bu sessizliğe son vermek amacıyla oturup JIRA’dan Redmine’a nasıl veri aktarılır, buna ilişkin bir yazı yazayım dedim. Öncelikle TL;DR kesimi için uyarımı yapayım, bu yazıda JIRA ve Redmine karşılaştırması yer almıyor.

Çalıştığınız kurumda altyapınızı değiştirmek isteyebilirsiniz veya özgür yazılımlara doğru yelken açmak isteyebilir ve özgür yazılım dünyasının başarılı ve kaliteli ürünlerini kullanmayı da tercih edebilirsiniz. Redmine proje yönetim sistemi de bu konuda oldukça gelişmiş bir yazılım. Esnekliği ve özelleştirilebilir olması nedeniyle çoğu firma ve özgür yazılım projesi de Redmine tercih ediyor.

Gelelim yazı başlığına. Jira 5.x kurulumunuz var ve bunu Redmine 2.x serisi bir sürüme geçirmek istiyorsunuz. Bu geçiş esnasında da mümkünse en az kayıpla geçmek istiyorsunuz. Böyle bir durumda sağolsun Redmine kullanıcıları bir araya gelip meşhur #1385 işi altında tartışmaya başlamışlar ve sonuç olarak migrate_jira isimli rake task’ı yazmışlar. Ben üzerinde biraz oynayıp 5.x ile uyumlu hale getirdim.

Geçiş yapabilmek için bir ön hazırlık yapmanız gerekiyor. Öncelikle JIRA tarafında “tam” bir sistem yedeğine ihtiyacınız var. JIRA’dan yedek alabilmek için şu işlemleri gerçekleştirin:

1. Jira’ya admin hesabıyla login olun.
2. Administration menüsüne girin.
3. Administration menüsünde System sekmesinde Import & Export linkine
tıklayın.
4. Açılan sayfada Backup System isimli bir sekme bulunuyor, o sekmeye gelin.
Sizden oluşturulacak dosyanın ismini isteyecektir. Oraya herhangi bir isim
yazın. Oluşturulan yedek dosyasının konumunu gösterecektir. (zip dosyası oluşturuyor.)

Aldığınız zip dosyası içerisinde entities.xml isimli bir dosya var ve bize lazım olan dosya da bu. İçerisinde proje, kullanıcı, dosya ekleri bilgileri vb. bilgiler yer alıyor. entities.xml dosyasını alıp Redmine’ın ana dizinine backup_jira.xml ismiyle koyun.

Daha sonra şu gist‘teki kodu Redmine içerisinde yer alan lib/tasks dizini altına migrate_jira.rake ismiyle yerleştirin.

Bu işlemleri tamamladıktan sonra Redmine servisini durdurun ve aşağıdaki komutları uygulayın:

1. Öncelikle rake task dosyasını doğru yerleştirdiniz mi ondan emin olun. Bunun için şu komutu verebilirsiniz:

RAILS_ENV=production bundle exec rake -T

Komut çalıştıktan sonra uzunca bir rake task listesi verecektir. Listede şu öğelerin geçtiğinden emin olun:


rake jira_migration:do_all_migrations # Tests all parsers!
rake jira_migration:generate_conf # Generates the configuration for the map things from Jira to Redmine
rake jira_migration:migrate_attachments # Migrates Jira Issues Attachments to Redmine Attachments
rake jira_migration:migrate_comments # Migrates Jira Issues Comments to Redmine Issues Journals (Notes)
rake jira_migration:migrate_issue_priorities # Migrates Jira Issue Priorities to Redmine Priorities
rake jira_migration:migrate_issue_status # Migrates Jira Issue Status to Redmine Status
rake jira_migration:migrate_issue_types # Migrates Jira Issue Types to Redmine Trackes
rake jira_migration:migrate_issues # Migrates Jira Issues to Redmine Issues
rake jira_migration:migrate_projects # Migrates Jira Projects to Redmine Projects
rake jira_migration:migrate_users # Migrates Jira Users to Redmine Users
rake jira_migration:pre_conf # Gets the configuration from YAML
rake jira_migration:test_all_migrations # Tests all parsers!
rake jira_migration:test_parse_comments # Just pretty print Jira Comments on screen
rake jira_migration:test_parse_issues # Just pretty print Jira Issues on screen
rake jira_migration:test_parse_projects # Just pretty print Jira Projects on screen
rake jira_migration:test_parse_users # Just pretty print Jira Users on screen

Eğer bu çıktıyı almıyorsanız, bir yerde bir hata yapıyorsunuz demektir, lütfen başa dönün ve işlemleri tekrar uygulayın.

Bu çıktıyı alıyorsanız taşıma işine başlayabilirsiniz. Her şeyi tek bir seferde aktarmak için do_all_migrations task’ını çalıştırabilirsiniz.

RAILS_ENV=production bundle exec rake jira_migration:do_all_migrations

Bu arada RAILS_ENV değişkenini her seferinde vermek zorunda değilsiniz, export ederek oturum boyunca geçerli olmasını sağlayabilirsiniz. Ben zaman zaman development mode’a da aldığım için değişkenin kalıcı olmasını pek tercih etmiyorum.

do_all_migrations task’ını ilk çalıştırdığınızda map_jira_to_redmine.yml isimli bir dosya oluşacak. Burada JIRA’daki tracker, durum ve öncelik kayıtlarının Redmine karşılığı isteniyor sizden. Bu dosyayı kendi Redmine kurulumunuza göre düzenleyin. Sol taraftaki değerler JIRA’daki tracker isimlerini, sağ taraftakiler ise bunların Redmine’daki karşılıklarını ifade ediyor. Örnek bir map_jira_to_redmine.yml dosyası şu şekilde:


---
types:
Bug: Bug
New Feature: Feature
Task: Task
Improvement: Feature
Sub-task: Sub-tasks
Admin: Feature
status:
Open: New
In Progress: In Progress
Reopened: Assigned
Resolved: Resolved
Closed: Closed
priorities:
Blocker: Immediate
Critical: Urgent
Major: High
Minor: Normal
Trivial: Low

do_all_migrations çalıştığında bu dosyayı sizin yerinize zaten düzenlemiş oluyor, eksiklikleri ise sizin gidermeniz lazım.

Dosyayı düzenledikten sonra tekrar aynı task’ı çalıştırın.

RAILS_ENV=production bundle exec rake jira_migration:do_all_migrations

Bundan sonra işlem başlayacak ve sırasıyla kullanıcıları, projeleri, iş kayıtlarını, iş kaydına yapılan yorumları ve iş kaydına eklenen dosyaları Redmine’a aktaracak. (Dosyaların sadece tanımını yapıyor, jira’nın attachments dizini altındaki dosyaların hepsini Redmine dizini altındaki files dizinine koymanız yeterli. Bu işlemi elle yapmanızın nedeni jira’nın backup alırken dosya eklerini backup içerisine koymaması)

migration task’ı projenizin ölçeğine göre zaman alabilir. 4000 iş kaydına sahip bir sistemin jira’sını Redmine’a dönüştürmem 2 gb ram’i core 2 duo işlemcisi olan bir sanal makinede yaklaşık yarım saat sürdü.

Diğer taraftan, Atlassian her yeni sürümde JIRA’nın backup yapısını değiştirebiliyor (acaba neden?), bu nedenle yukarıdaki rake task en yeni sürümlerde çalışmayabilir. Bu yüzden #1385′i ve github’ta şu güzel projeyi takip etmenizde fayda var.

Not düşeyim, ben yukarıdaki bilgileri kullanarak 5.0.4 ve 5.0.6 kullanan JIRA’ları Redmine 2.2.3′e sorunsuzca geçirebildim. Henüz 2.3 serisinde denemedim ancak çalışmaması için bir engel göremiyorum.

Posted in: Genel / Tagged: , , , , ,

Redmine, SVN ve SSL Sertifikaları

13 Ağustos 2012 15:49 / Leave a Comment /

Redmine kullanıp da herhangi bir sürüm takip sistemi ile entegre kullanmayan kullanıcı çok azdır sanırım.

Redmine ile birlikte svn kullanıyorsanız ve svn sunucunuzda SSL kullanmıyorsanız ya da yetkili bir otorite tarafından sağlanmış bir SSL sertifikası kullanıyorsanız sorun yok, işler planlandığı gibi ilerliyor.

Ancak sertifika self signed ise veya yetkili otorite tarafından sağlanmamışsa biraz takla atmanız gerekiyor :).

Tabii takla atmamıza neden olan Redmine değil; SVN tahmin edebileceğiniz gibi. Çünkü Redmine’ın yaptığı tek şey svn istemcisinin verdiği xml çıktısını yorumlamak.

Eğer self signed bir sertifika kullanıyorsanız, Redmine SSS sayfasında da belirtildiği üzere yapmanız gereken işlem redmine dizinindeki lib/redmine/scm/adapters/subversion_adapter.rb dosyasında svn parametrelerine şunu dahil etmek:

--trust-server-cert

Bu şekilde svn istemcisinin self-signed sertifikaya güvenmesini sağlıyorsunuz. Ancak dikkat etmeniz gereken önemli bir husus bulunuyor. Sertifikada eğer “Common Name” kısmı svn’e bağlandığınız adres ile uyuşmuyorsa svn istemcisi maalesef işlemi gerçekleştiremiyor. (non-interactive parametresi kullanmanıza rağmen.)

Özetle, Redmine’da https üzerinden sunulan bir svn deposuna bağlanacaksanız, Common Name’in tutmasına ve –trust-server-cert kullanmasına özen gösterin.

Posted in: Genel / Tagged: ,

JBoss loglarını graylog’a göndermek

28 Temmuz 2012 22:29 / Leave a Comment /

Graylog2 oldukça kullanışlı ve tadından yenmeyen web arayüzü ile hepimizin gönlünü kazanmış bir log sunucusu. Normal syslog girdilerinin yanı sıra kendine has GELF (Graylog Extended Log Format) ile işimizi oldukça kolaylaştırıyor.

JBoss loglarını grayloga göndermek için aslında iki yöntem bulunuyor. Birincisi başlangıçta zahmetli; ancak kavradığınızda istediğiniz her türlü biçimde log aktarmanızı sağlayan logstash yöntemi. Eğer log4j’yi sysloga gönderecek biçimde ayarlamamışsanız, logstash ile jboss dizininiz altındaki server.log’u takibe almaya başlayıp çıktıları graylog sunucusuna gönderebiliyorsunuz. Ekstra bir süreç çalıştırdığınız için pek verimli bir yöntem olduğu söylenemez.

Diğer yöntem ise oldukça kolay: gelf4j kullanmak. Bu kitaplık sayesinde graylog’a GELF biçiminde log gönderebiliyorsunuz ve yapılandırması oldukça basit. gelf4j’yi kullanmak için yapacağınız işlem şunlardan ibaret:

- https://github.com/pstehlik/gelf4j/downloads adresinden gelf4j’nin en son .jar dosyasını indirip JBoss sunucunuzun server/default/lib dizinine koyun.

- server/default/conf/jboss-log4j.xml dosyanızda şu şekilde bir appender tanımlayın:

<appender name="graylog2" class="org.graylog2.log.GelfAppender">
    <param name="graylogHost" value="graylog.sunucusu"/>
    <param name="originHost" value="jboss.calistiran.sunucu.icin.host.name"/>
    <param name="extractStacktrace" value="true"/>
    <param name="addExtendedInformation" value="true"/>
    <param name="facility" value="gelf-java"/>
    <param name="Threshold" value="INFO"/>
</appender>

Daha sonra da root içerisinde ilgili appender’ı etkinleştirin:

<root>
      <appender-ref ref="CONSOLE"/>
      <appender-ref ref="FILE"/>
      <appender-ref ref="graylog2"/>
</root>

Appender ayarı içerisinde log seviyesini dilediğiniz gibi düzenleyebilirsiniz. Yapmanız gereken Threshold’u istediğiniz seviyeye çekmek. Uygulama sunucunuzu tekrar başlattığınızda artık ilgili kayıtlar graylog web arayüzü üzerinde de görüntülenmeye başlayacaktır.

Posted in: Genel / Tagged: , , ,

tık tık… kim o?

14 Temmuz 2012 18:28 / 2 Comments /

Herhangi bir sunucu üzerinde ssh sunucu kurup öntanımlı portta (22) bıraktığınızda log dosyalarında bir çok başarısız giriş denemesi olduğunu görmüşsünüzdür. SSH sunucu üzerinde herhangi ek bir yapılandırma yapmamışsanız (mesela parolalı girişi kapatmak vb.) ve basit de bir parola atamışsanız, bir sabah sunucunuza giriş yaptığınızda çalışan anlamsız onlarca, yüzlerce süreç (çoğu rootkit) ile karşılaşmanız mümkün.

SSH güvenliğini sağlamak için çeşitli yöntemler yer alıyor, bunların başında parolalı girişi kapatmak, bir honeypot kurmak ya da port knocking yapmak geliyor. Ben bu yazımda port knocking ile SSH nasıl sebil olmaz onu göstermeye çalışacağım.

Port knocking işlemi, belirli port ve protokollerden sunucuya talep gönderilmesi suretiyle bir portun kullanıma açılması işlemi, en kaba tabiriyle. Dolayısıyla ortada çalışan bir firewall (iptables diyelim) olması durumunda (ki olmaması abes) belirli portlardan sunucunuza talep göndererek, SSH’ın öntanımlı portunu değiştirmeden sunucunuza uzaktan erişebilirsiniz.

Diyelim ki, sadece belli IP’lerin 22. porta doğrudan erişimi var. Bu IP’ler haricindekilerin paketleri ise doğrudan DROP veya REJECT yiyor. Bunun haricindekilerin 22. porttan giriş yapabilmesi için knocking işlemi yapmamız gerekiyor.

Knocking yapmak için “pratik” iki çözüm bulunuyor. Knockd ve xtables_addons içerisindeki xt_pknock modülü.

xtables_addons ekstra bir çekirdek modülü yüklemenizi, derlemenizi gerektirdiği için ona değinmeyeceğim. Ancak merak eden varsa, man sayfasından inceleyebilir.

Knockd ise bana göre daha kullanışlı bir uygulama. Çoğu dağıtımın paket depolarında zaten bulunuyor, elle kurmak isteyenler için de web sayfasında nasıl kurulacağını anlatan yönergeler mevcut. (RHEL ve RHEL tabanlı dağıtımlar için source rpm’ini alıp rebuild etmeniz yeterli.)

Kurulum yaptığınızı varsayıyorum, yapılandırmaya gelince, /etc/knockd.conf dosyası yapılandırma için kullanılıyor. Örnek bir knockd.conf üzerinden gidecek olursak:


[options]
UseSyslog

[opencloseSSH]
sequence = 6021,4903,23273
seq_timeout = 10
tcpflags = syn
start_command = /sbin/iptables -I INPUT -s %IP% -p tcp --dport 22 -j ACCEPT
cmd_timeout = 10
stop_command = /sbin/iptables -D INPUT -s %IP% -p tcp --dport 22 -j ACCEPT

[options] kısmı genellikle log işlemleri için kullanılıyor. UseSyslog diyerek knockd log mesajlarınızı mevcut çalışan syslog’a gönderebileceğiniz gibi, bir log dosyası belirterek o dosyaya da yazılmasını sağlayabilirsiniz. (Logfile = /log/dosyasinin/yolu)

[opencloseSSH] kısmı ise alias tanımı aslında. Bir knockd.conf içerisinde istediğiniz kadar komut tanımlayabilirsiniz. Yukarıdaki örnekte sadece SSH için tanımlı bir kural var, opencloseSSH bu komutların tamamına karşılık geliyor. Dolayısıyla buna ne isim verdiğinizin pek önemi yok.

sequence ise knockd’nin hangi portlardan gelen işlemleri değerlendireceğini ifade ediyor. Burada sadece port numarası yazdığınızda tcp için geçerli oluyor. udp de tanımlamak isterseniz 6021:udp formatında yazmanız gerekiyor.

seq_timeout kısmı saniye cinsinden yazılan bir değer. Burada portlara kaç saniye içerisinde talep gönderilirse bunun bir knock işlemi olarak algılanacağını belirtiyorsunuz. Bağlantı problemleri vs. durumlar yaşayabileceğinizi düşünerek bu değeri çok düşük tutmamaya özen göstermenizi tavsiye ederim.

tcpflags parametresi ise knockd’nin hangi tcp bayraklarını dikkate alacağını ifade ediyor. Kullanabileceğiniz değerler: fin, syn, rst, psh, ack ve urg.

start_command ise tahmin edebileceğiniz gibi knock işlemi başarılı olursa sunucu tarafında çalıştırılacak komut. Örnek yapılandırmada INPUT zincirine 22. porttan knock talebinde bulunan IP için bir kural ekleniyor.

cmd_timeout değeri sadece stop_command tanımlanmışsa dikkate alınıyor. Yaptığı işlem start_command ile stop_command arasında geçecek zamanı belirtmek. cmd_timeout değeri de aynı seq_timeout gibi saniye cinsinden.

stop_command değeri cmd_timeout’ta belirlenen süre geçtikten sonra yapılacak işlemi ifade ediyor. Örnek yapılandırmada, INPUT zincirine daha önce girilmiş kuralı silindiğini görebilirsiniz.

Knockd yapılandırması temel olarak bunlardan ibaret. Sadece SSH için değil, aklınıza gelebilecek her komut için kullanabilirsiniz. SSH portunu dışarıya kapatıp, dilediğiniz zaman kendinize istisna tanımlamak için oldukça faydalı bir uygulama bence.

Kurulumu yaptık, knockd servisini çalıştırdık, nasıl bağlantı kuracağız? Bunun için çeşitli yöntemler ve araçlar mevcut. En başta gelen de knockd ile birlikte kurulan (dağıtıma göre ayrı paketlenmiş olabilir) knock aracı. Örnekteki portları kullanan bir sunucuya bağlantı kurmak için knock komutunu şu şekilde verebilirsiniz:

knock hostname 6021 4903 23273 && ssh hostname

Eğer farklı protokollere knock yapacaksanız, onları belirtmeniz gerekiyor:
knock hostname 6021:tcp 4903:udp 23273:udp && ssh hostname

Sadece tcp tanımlamışsanız, knock aracına hiç ihtiyaç duymadan da (telnet veya netcat ile mesela) knock işlemi yapabilirsiniz. Örneğin telnet kullarak port knock yapmak için:
telnet hostname 6021 ; telnet hostname 4903 ; telnet hostname 23273 ; ssh hostname

Bunun haricinde de kapıyı tıklamak için başka araçlar da var: sendip, packit ve hping.

Posted in: Genel / Tagged: , ,

Arch Linux (testing) glibc güncellemesi

08 Temmuz 2012 13:35 / 3 Comments /

Yakın zamanda çoğu dağıtım /lib, /bin, /lib32, /lib64 gibi dizinlerin içeriklerini /usr altına taşımaya başladı. “usrmove” olarak adlandırılan bu hareket neticesinde artık kitaplık ve uygulamaların tek konumu /usr dizini olacak. Dolayısıyla dosya hiyerarşisi bakımından bir standart olacak. (Şimdilik /bin, /sbin gibi dizinler sembolik bağ olarak kalıyor). Çekirdek modülleri de artık /usr/lib/modules altında tutulmaya başladı bile.

usrmove’un başlıkla olan alakası ise, dün akşam sistem güncelleyeyim derken Arch Linux’un testing deposundaki glibc’yi güncellerken paket yöneticisinin hata vermesi üzerine aslında hiç yapmamam gereken “-f” force bayrağını çektim ve sistemin bana olan tepkisi gecikmedi: newfags cant triforce.

glibc’nin ilgili kitaplıkları /usr/lib altına gittiği için ve mevcut /lib dizininin içeriği boş kaldığı için hiçbir uygulama çalışmamaya başladı. (kabuk dahil)

Herneyse, bu durumla karşılaşma ihtimaliniz olursa eğer chroot vs. yapmadan sisteminizi kurtarmanız mümkün. Eğer henüz reboot atmamışsanız:

/usr/lib/ld-2.16.so /bin/mv /lib /libbackup
/usr/lib/ld-2.16.so /bin/ln -s /usr/lib /lib

komutlarını vererek sisteminizi kurtarabilirsiniz.

Eğer reboot atmışsanız, init açılırken kernel panic alıyorsunuz zaten. Bu durumda sistem önyükleyicinizde Arch Linux ile ilgili satırı düzenleyerek (grub için e, syslinux için tab’a basmanız yeterli) kernel parametresi olarak şunu yazmanız gerekiyor:

init=/usr/lib/ld-2.16.so /bin/sh

Bu şekilde “single user mode” ile sisteminizi açmış oluyorsunuz. Bu aşamadan sonra öncelikle dosya sisteminizi yazılabilir (rw) olarak bağlamalı, ardından da sembolik bağ işlemini yapmanız gerekiyor:

/usr/lib/ld-2.16.so /bin/mount -o remount,rw /
/usr/lib/ld-2.16.so /bin/mv /lib /libbackup
/usr/lib/ld-2.16.so /bin/ln -s /usr/lib /lib

Bu şekilde sisteminizi kurtarabilirsiniz, ilgili işlemleri yaptıktan sonra reboot atıp tekrar pacman -S glibc demenizde fayda var tabii.

Not: Bu işlem sadece 64 bitte gerekiyor olabilir, sorunun kaynağı lib32-glibc paketi aslında. Ancak yine de herhangi bir şekilde glibc patlarsa bu şekilde kurtarabileceğinizi bilin istedim :).

Posted in: Genel / Tagged: , ,

bir saniye lütfen

01 Temmuz 2012 16:17 / 4 Comments /

Dün reddit’te (linux subreddit) dolanırken ilginç bir başlığa denk geldim. Stackoverflow’da açılmış bir konuyla ilgiliydi. “Artık saniye” yüzünden süreçlerin %100 işlemci kullanımına ilişkin ilginç bir sorun idi.

Gece yarısından sonra sunucularda ilginç bir yavaşlamaya tanık oldum, load’a baktığımda ise “ehe” demekten alıkoyamadım kendimi: load 25.00 civarındaydı. (İşletim sistemi olarak Scientific Linux 6.2 var bu arada) Sebebini öğrenmekte ise gecikmedim, java ve passenger süreçleri %100 işlemci kullanıyordu. Nitekim sistem saatine elle müdahale edip daha sonra tekrar ntp çalıştırmak yetti. Süreçler kendine gelmeye başladı tekrar çalıştırdıktan sonra. Ancak duruma göre reboot da gerekebiliyor.

Konuyla ilgili LKML’de şu konu yer alıyor. Java’da “leap second” ile ilgili de şu konuya ulaşabildim. Red Hat’in artık saniyelerle ilgili sayfasında da şu bağlantıyı gördüm yorumlarda. Java uygulaması çalıştırıyorsanız ve bu soruna denk gelmişseniz orada belirtilen çözüm saati sıfırlamak:


date; date `date +"%m%d%H%M%C%y.%S"`; date

Şimdiye kadar problemi sadece Java (jdk6) ve passenger’da tekrarlayabildim ben. Passenger (mod_rails) harici uygulama sunucularında (unicorn tercih ediyorum, test amaçlı da bir adet thin var) böyle bir soruna denk gelmedim ancak tarih sıfırlamak passenger sürecinin kendisine gelmesini sağladı.

Sonuç olarak sıradışı bir Cumartesi gecesi yaşadım. Bir saniyenin etkisi bazı durumlarda ölümcül olabiliyor :)

Posted in: Genel / Tagged: , ,

Redmine ve karşıdaki (uzaktaki, remote, whatever) git depoları

30 Haziran 2012 21:32 / 1 Comment /

Daha önce Redmine ile git deposu aynı makinedeyse bu git deposunu Redmine’a nasıl ekleyebileceğimizi yazmıştım. Bu yazıda ise Redmine ve git deposu farklı makinelerde ise depoyu Redmine üzerinde nasıl görüntüleyebileceğinizi anlatacağım. Redmine uzaktaki SVN deposunu “svn ls” yardımıyla görüntüleyebilirken git içerisinde “svn ls” muadili bir yapı olmadığı için zorunlu olarak deponun bir yansısını Redmine ile aynı sunucuda tutmanız gerekiyor.

Yansılayabilmek için yapmanız gerekenler ise oldukça basit. github, gitorious, gitolite veya gitosis kullanıyorsanız yapmanız gerekenler şunlar:

git clone --bare xyz@xyz.com:proje.git proje.git
cd project.git
git remote add origin xyz@xyz.com:proje.git
git fetch -v
git fetch origin
git reset --soft refs/remotes/origin/master

Yukarıdaki şekilde yansılama işini tamamladıktan sonra belirli aralıklarla fetch ve reset işlemlerini yapmanız gerekiyor. Bunu cron ile yapabilirsiniz:


*/5 * * * * cd /path/to/proje.git && git fetch origin && git reset --soft refs/remotes/origin/master

Bundan sonra Redmine tarafında yapmanız gereken tek işlem, Redmine içerisinde proje ayarlarında depo tanımlayıp depo yolu olarak “proje.git” deposunun tam dosya yolunu göstermek. Redmine bu şekilde deponun o anki halini görüntüleyebilecektir; ancak sonradan yaptığınız güncellemelerin de yansıması için şu şekilde bir cron tanımlamanız gerekecektir.


*/10 * * * * rake -f /path/to/redmine/Rakefile RAILS_ENV=production redmine:fetch_changesets > /dev/null 2>&1

Not: Eğer projede branch üzerinde değişiklik yapmışsanız (isim değişikliği, silmek vb.) bu branchların local branch olarak değerlendirilebilmesi için “git reset” işleminden önce şunu yapmanız gerekebiliyor (git clone yaparken –bare yerine –mirror kullanıldığında gerek kalmadığına dair rivayetler var):


git fetch origin +refs/heads/*:refs/heads/*

Posted in: Genel / Tagged: , ,

Sonatype Nexus ve “too many open files” hatası

02 Haziran 2012 19:59 / 2 Comments /

Maven depolarıyla uğraşıyorsanız ve bunu sonatype nexus üzerinden idare ediyorsanız ve zaman zaman nexus’un sistem kayıtlarına “too many open files” yazdığını ve çakıldığı gerçeğiyle yüzleşiyorsanız yapmanız gereken bazı işlemler bulunuyor.

Nexus çalıştırıldığı vakit süreç konusunda oldukça ve açtığı dosyalar bakımından oldukça bonkör davranıyor. File descriptor limitine (eğer değiştirmediyseniz çoğu sistemde öntanımlı süreç sayısı soft 1024, hard 4096) takıldığınız için de çakılıyor ve cevap veremez hale geliyor. Bu durumda yapmanız gereken işlem basit, /etc/security/limits.conf dosyasını açıp ister sistem genelinde, isterseniz kullanıcı bazında izin verilen süreç limitlerini artırma yoluna gidebilirsiniz. Bunun için limits.conf dosyasına şu satırları eklemeniz yeterli:


* soft nofile xxxxxx
* hard nofile xxxxxx

xxxxxx kısımlarını uygulamayı takip ederek artırmanızda fayda var. Başına * koyduklarınız sistem genelindeki tüm kullanıcı ve grupları ifade ediyor. Eğer belirli bir kullanıcının limitlerini değiştirmek istiyorsanız:


kullanıcı_adı soft nofile xxxxxx
kullanıcı_adı hard nofile xxxxxx

Ya da bir grubun limitlerini değiştirmek istiyorsanız:


@grup soft nofile xxxxxx
@grup hard nofile xxxxxx

şeklinde düzenlemeye gidebilirsiniz.

Diğer taraftan, sysctl ile “fs.file-max” değerleriyle de oynamanız da gerekebilir (aslında file descriptor limitleri buradan geliyor). Bunun için şu komuttan yararlanabilirsiniz:


sysctl -w fs.file-max=xxxxxxx (kalıcı olmasını istiyorsanız, /etc/sysctl.conf dosyasına fs.file-max=xxxxx yazmanız yeterli)

Yine burada xxxxxxx değerini uygulamanın davranışını ve sistemin genel davranışını izleyerek (lsof kullanarak takip edebilirsiniz) artırmanızda fayda var. Mevcut fs.file-max değerini görmek için de şu komutu uygulayabilirsiniz, sonra yanlışlıkla limiti aşağı indirmeyin :p.


sysctl fs.file-max

Tabii bu saydıklarım sadece nexus için geçerli değil, genellikle java uygulamaları süreç ve dosya açmada bonkör davranıyor. Özellikle Jenkins (veya hudson) kullanıyorsanız ve düzenli derleme aralıkları çok sık ise (ya da çok fazla projeyi günlük derliyorsanız) yine limitleri artırmakta fayda var.

Bu değerler donanıma, kullanılan dosya sistemine göre farklılık gösterebileceği için doğrudan limitleri şununla değiştirin şeklinde bir tavsiyede bulunamıyorum; ancak ilk olarak süreç limitlerinizi iki katına çıkararak gözlemeye başlamanızda ve lsof‘tan yararlanmaya başlamanızı tavsiye edebilirim. lsof ve file descriptor limitlerine ilişkin şuradaki yazı fazlasıyla iş görecektir.

Posted in: Genel / Tagged: