Mısır İletişim Bakanlığı Açık Kaynak Yazılım Stratejisini Benimsedi

Atef Helmy
Mısır İletişim ve Bilgi Teknolojileri Bakanı Atef Helmy bakanlığın özgür ve açık kaynaklı  yazılımları (FOSS) destekleme stratejisini benimsediğini duyurdu.


Helmy, yayınlanan strateji belgesinde “Özgür yazılım, temelinde yazılım kodları özgürce erişilebilen, değiştirilebilen ve dağıtılabilen bir yazılımdır” diyor ve ekliyor; Mısır’daki açık kaynak yazılım endüstrisinin gelişimi bağımsız teknolojilerin başarısına, yeni iş alanları sağlanmasına ve kamu ve özel sektör tüketicilerinin internet ve iletişim teknolojilerinden faydalanmasına yardım edecek.

Mısır’daki Açık Bilgi Vakfı (OKF) gönüllüsü Tarek Amr ise iş ve devlet kuruluşlarının açık kaynak yazılımları kullanma stratejisinin  bireylerin bu yazılımları denemesini sağlayacağını bu yolla onları cesaretlendireceğini söylüyor.

Amr bir yazılım mühendisi, ayrıca bu stratejinin devletin özgür yazılımlar sağlayan firmalardan teknoloji hizmeti satın almasına yardım edeceğini ve bunun yazılım lisansı masraflarını kısacağını ekliyor. “Açık kaynak Mısır için çok uygun, GSYH’nın büyümesini hızlandıracak, ulusal güvenlik seviyesini yükseltecek ve bireysel sermayenin gelişmesine yardım edecek ” diyor.

Bakanın açıklamasına göre, özgür yazılım stratejisini harekete geçirecek olan strateji uygulama komitesi, bakanlık danışmanları, kamu kurumları ve sivil organizasyonlar arasında süreç koordinasyonunu sağlamak üzere  Yazılım Mühendisliği Yeterlilik Merkezi (SECC) görevlendirildi.

Süreç SECC yönetiminin FOSS komitesinden uzmanları da kapsayacak ve ilgili girişim ve programları izleyecek şekilde yeniden yapılanmasını da içeriyor.

Bakanın belirttiğine göre bu stratejinin hedefleri vatandaşlara ucuz bilgi hizmetleri sunmak, kamu sektörünün şeffaflığını arttırmak, internet ve bilgi teknolojileri sektörünün gelişimini desteklemek, teknoloji çözümlerinin maliyetini düşürmek ve küçük-orta işletmeleri desteklemek olarak sıralanıyor.

2012 Yılı başlarında bir grup eylemci  hükümetin Microsoft ile 44 Milyon Dolar’lık bir anlaşma imzalamasının ardından Mısır’da açık kaynaklı yazılım kullanılması için çağrı yapmıştı.

(Çeviridir, yazının kaynağı: http://www.dailynewsegypt.com/2014/03/19/ministry-communication-adopts-open-source-software-strategy/)

20 Mart 2014

Posted In: lkd_gezegen, Özgürlük için

NetFlow Analysis using ElasticSearch & Kibana

Kibana dashboard showing various NetFlow metrics 
I've heard a lot about ElasticSearch lately, was trying to create some time to get a lab set up for the new trio on the block : ELK. For those who hasn't heard about the term ELK, it is an acronym for ElasticSearch + Logstash and Kibana. ELK stack is continuing tradition LAMP stack created a while ago by tightly integrating to each other, albeit on a completely different dimension, and becoming new invaluable tool for DevOps people.
Over the course of years, I've developed a lot of tools/guis, both small and big, to make metrics and data meaningful for my pleasure/business/troubleshooting purposes. But none was as much fun and as quick as I had with ElasticSearch and Kibana.

One of the most important advices I can give to anyone who is building, maintaining or operating an IT infrastructure is having situational awareness on every single angle possible. This means collecting a lot of metrics from all systems, including IPfix/NetFlows from network. Main focus of this tutorial is to show how ES and Kibana can be a valuable tool in assessing issues at network layer using Netflow on a real life scenario: On February 4th, 2014 a network issue caused 1 hour disruption to the services provied to a customer, an RCA requested by management. All logs gathered in one place, with very few reliable explanation as to what really happened. We've started looking at the issue deeper, this time utilizing NetFlows captured at various devices and using ES & Kibana to do analytics & drill down. ES & Kibana helped a lot to better understand and grasp what happened during the disruption and nailing down root cause.

I won't be going into details of setting up ElasticSearch and Kibana, as there are a lot of blog posts on the net on how to perform those steps. You'll see steps to get NFdump data ready, importing into ElasticSearch using ElasticSearch's Python & Bulk API, preparing Kibana for analytics, and discovering what NetFlow records show about the issue I'm after.
In addition to explaining steps to setup similar NFdump/ES/Kibana environment for yourself, I've also provided some analysis/benchmark on storage requirement of ES and explained different approaches on how to reduce foot print of ES while increasing performance.

First, some background information.

At our customer sites, we deploy various collectors and probes to collect and store network traffic metadata, namely NetFlow, for forensic/security and troubleshooting purposes. Probes are deployed at critical network edges to record and analyze activity passing through by using SPAN/RSPAN/ERSPAN, emmitting NetFlow metadata to collectors which save and store NetFlows on hard drive for later use. NetFlows can be costly to generate and store, especially if you're trying to capture traffic on outside/untrust/public interfaces, which face traffic/flows, both in and out, from all around the globe. Probing outside interfaces means recording traffic from spoofed IPs, ICMP pings, BGP announcements and every other bits that travels on Layer 3. For this blog post, I've used 3 flows collected at the same device, one from outside/public interface on the firewal, one for traffic filtered by firewall corresponding to the traffic passing through outside interface, and one for internal VLAN relevant to the issue I'm analysing for. All flows corresponding to the same 24 hour period, differed in size and characteristics widely:


  1. FNF1 : Corresponding to an internal VLAN traffic, have 4.6 million flows, 228MB in size
  2. FNF2 : Corresponding to the internal/trust interface on the firewall, having 8.6 million flows, 426MB in size.
  3. FNF3 : Corresponding to the public facing interface on the firewall, having 33.7 million flows, 1.671MB in size.


Netflow captures following fields that can be used to analyze various aspects of the network :
  • Timestamp
  • Duration
  • Protocol
  • Source IP
  • Source port
  • Destination IP
  • Destination port
  • Bytes
  • Packets
  • TCP Flags
  • Interface

There are a lot of other information that can be captured and shown, a sample 5 line output from FNF1 dump file is shown below :
1:  # nfdump -r fnf1.dump -oextended -c5  
2: Date flow start Duration Proto Src IP Addr:Port Dst IP Addr:Port Flags Tos Packets Bytes pps bps Bpp Flows
3: 2014-01-01 00:04:23.980 25.000 TCP 172.16.0.156:33510 -> 172.16.0.94:58781 .AP... 0 296 237484 11 75994 802 1
4: 2014-01-01 00:04:23.980 34.000 TCP 192.168.0.133:20022 -> 172.16.0.121:64327 .AP... 0 375 24206 11 5695 64 1
5: 2014-01-01 00:04:23.980 25.000 TCP 172.16.0.156:5910 -> 172.16.0.132:63880 .AP... 0 319 173587 12 55547 544 1
6: 2014-01-01 00:04:23.980 21.000 TCP 172.16.0.22:39621 -> 172.16.2.135:80 .AP... 0 35 9504 1 3620 271 1
7: 2014-01-01 00:04:23.980 11.000 TCP 172.16.0.99:65192 -> 172.16.9.132:80 .AP..F 0 39 6800 3 4945 174 1

Step 1) Prepare NFdump files

NFdump rotates dump files every 5 minutes by default. Instead of dealing with multiple NFdump files, I've converted all dump files in each collector's directory to a single file, while sorting by timestamp using following command :

# nfdump -mR ./nfdump -zw fnf1.dump

For the sake of performance and analytics I'm after, I'm only interested in timestamp, source IP, source port, destination IP, destination port, bytes, packets, interface and protocol. To do this, I've used following nfdump command to dump data into CSV file for later use :

# nfdump -Nqr fnf1.dump -o "fmt:%ts, %sa, %sp, %da, %dp, %byt, %pkt, %out, %pr" > fnf1.csv

Step 2) Prepare ElasticSearch Mapping

After having all 3 files dumped into respective CSV files, I've crafted a Python script utilizing ElasticSearch's official Python API to index each flow record in ElasticSearch. ElasticSearch provides schemaless storage and indexing, however just throwing Netflow data without providing a mapping (a schema or DDL some sort) is not smart for storage perspective. Before importing CSV into ElasticSearch, I've experimented with different schemas, one of which using IP mapping for source and destination IP addresses, however it didn't work well for some reason. I've switched storing IP information in string field using following schema definition :
1:  {  
2: "fnf1x": {
3: "_all" : {"enabled" : false},
4: "_source" : {"enabled" : false},
5: "properties": {
6: "ts": {"type": "date", "format" : "YYYY-MM-dd HH:mm:ss"},
7: "sa": {"type": "string", "index": "not_analyzed"},
8: "sp": {"type": "integer", "index": "not_analyzed"},
9: "da": {"type": "string", "index": "not_analyzed"},
10: "dp": {"type": "integer", "index": "not_analyzed"},
11: "byte": {"type": "long"},
12: "pkt": {"type": "long"},
13: "out": {"type": "integer", "index": "not_analyzed"},
14: "pr": {"type": "string", "index" : "not_analyzed"}
15: }
16: }
17: }

For those who are not familiar with ElasticSearch's mapping definition, here is a short definition of what this schema does. First, I didn't want to store NetFlow records in both index and in "_source" field as a JSON document, so it is disabled. For drilling down and analytics purposes, complete document, NetFlow record in this case, is rarely needed. Also, since NetFlow records are well defined and structured, I only search/filter using field names ie : protocol = TCP or destination port = 80. "_all" field is used for searching multiple fields at the same time, when no field name provided. Eliminating "_all" field also saves unnecessary I/O to disk and storage. I chose 'not_analyzed' for string fields, as there is no need to tokenize or stem any of the strings stored. IP information along with protocol fields can be stored and indexed as a whole. Please duplicate above mapping for each of the NetFlow collectors after changing "fnf1x" to the appropriate name you choose.

Step 3) Import CSV files into ElasticSearch

After this map is PUT on ElasticSearch, we can have our Python script to import CSV file created on step 1. Python script code is c/p here, as it is less than 30 lines :
1:  #!/usr/bin/python  
2: import csv, sys, time, json, elasticsearch
3: from elasticsearch import helpers
4: es = elasticsearch.Elasticsearch()
5: source = 'fnf1'
6: csvfile = source + '.csv'
7: jdata = dict()
8: actions = list()
9: i = 0
10: proto = {'0': '0', '1': 'ICMP', '2': 'IGMP', '6': 'TCP', '17': 'UDP', '112': 'VRRP', '3': 'GGP', '50': 'ESP'}
11: with open(csvfile, 'rb') as file :
12: line = csv.reader(file, delimiter = ',', skipinitialspace = True)
13: for row in line :
14: ptime = time.strptime(row[0][0:19], "%Y-%m-%d %H:%M:%S")
15: ctime = time.strftime('%Y-%m-%d %H:%M:%S', ptime)
16: jdata = { 'ts': ctime, 'byte': int(row[5]), 'sa': row[1], 'sp': int(float(row[2])), 'da': row[3], 'dp': int(float(row[4])), 'pkt': int(row[6]), 'out': int(row[7]), 'pr': proto[row[8].strip()] }
17: action = { '_index': 'netflowlab', '_type': 'fnf1x', '_source': json.dumps(jdata, separators=(',', ':'))}
18: actions.append(action)
19: i += 1
20: if i % 100000 == 0:
21: elasticsearch.helpers.bulk(es, actions)
22: print "Indexed %d, working on next 100000" %(i)
23: actions = list()
24: elasticsearch.helpers.bulk(es, actions)
25: print "Indexed %d, finishing." %(i)


Please change 'source' and '_type' fields above to reflect file names and "_type" in ElasticSearch index. Uploading total of 47 million rows, in 3 different CSF files took about 2 hours on my i7-3770 (QC 3.4GHz CPU). Most of the time spent was on Python parsing CSV file and converting into JSON format, I didn't have time to optimize code or profile it for performance tuning. I've used SSD drive to store ElasticSearch data files, which makes upload and analytics faster than traditional drives. Also after inserting 47 million rows, into 3 different types, there will be a lot of segments in ElasticSearch index directories. I suggest optimizing them by reducing number of segments to 1 using (netflowlab is the name of index I've used for this blog post) :

http://localhost:9200/netflowlab/_optimize?max_num_segments=1
This resulted in 3.8GB of Index directory under /var/lib/elasticsearch/

Step 4) Using Kibana to analyze NetFlow data

After everything is ready, use enclosed Kibana dashboard schema file. Once you have uploaded dashboard schema, you'll have something similar to the image on the right. With my ElasticSearch Index, dashboard shows high level information about 46 million flows, accounting for 5.8TB of transferred data in 24 hours. In the next image, we see histograms showing both byte and PPS values :


Histogram shows some anomaly started happening around 14:30 and 20:00, especially around 14:30 and 15:30


Once we started zooming into the timeframe when the anomaly occured, we can see all other graphs updated according to the window we selected. In the mid section of the dashboard I have source IP, source address, destination IP and destination address pie charts, showing flow itself. In destination port pie chart, I immediately noticed that port 12201 is accounting for roughly 20% of the trafffic/flows happened at that time, which is way above normal characteristic of the traffic :


When I click 12201 on the destination port pie chart, Kibana re filters and re graphs data according to the selection I made. I immediately can see that, TCP traffic nearly diminished, and only UDP traffic is hitting port 12201, which happened to be the GrayLog server's default port listening for logs send by the various app servers.


When I changed histogram properties to show data with 1s resolution, I can see that PPS values went up to 250K alone for FNF1x collector, congesting network switch with both PPS and Throughput (MBit/sec). If I want, I can also drill down to the Interfaces and see how much traffic passed through each interface on the switch. This information showed us that the root cause of the issue we were investigating, was actually app servers pumping huge amounts of logs towards GrayLog server. Whole issue was triggered by another issue, but it was start of chain reaction, causing apps to go crazy with logs, making log pumping the root cause, and trigger itself a contributing factor.

Storage Perspective

I've also captured some information on how much data is required for NetFlow storage when different file formats are in use. JSON, obviously, being one of the least storage efficient file formats requires most storage when it comes to NetFlow data with 46 millon flows. After disabling "_all" and "_source" fields in ElasticSearch, its storage requirements also went down. 900MB of gzip compressed Nfdump data consumes about 3.8 GB of Index space on ElasticSearch. I should add that, I didn't store all Netflow fields in this test scenario, only included ones that are relevant to my use case. To make comparison a little more accurate, I've also added uncompressed Nfdump storage requirements below. Once I compress ElasticSearch's Index directory with .tar.gz (default gzip compression level), same 3.8GB becomes 2.7GB. This tells me that I can also store same Index files on ZFS with LZ compression turned on to save some space without sacrificing too much performance.

RowsNfdump (bz2)NfdumpNfdump (-j)CSVJsonES Index SizeTar.gz
FNF14,616,89538.33228.9685.77484.33781.21
FNF28,598,76674.02426.43146.18902.051,424.96
FNF333,710,008402.991,671.73667.573,536.325,854.58
Total46,925,669515.352,327.12899.524,922.708,060.743,805.682,711.24


I'll continue experimenting with ElasticSearch and post my notes about using ElasticSearch for Netflow analytic purposes. Please send in your questions and comments.
All files required to set up this proof of concept environment are located here : https://github.com/bulutsal
Please contribute back your changes to this location.

11 Mart 2014

Posted In: ElasticSearch, Gezegen, NetFlow

Bir SYN-FLOOD Hikayesi

Syn FloodYönetmekte olduğum bir sisteme sürekli olarak SYN paketleri gönderildiğini farketmemin üzerine çalışmalara başladım. Paketlerin gönderilme hızı değişkenlik gösteriyordu; çoğunlukla 1 paket/saniye hızında seyreden trafik zaman zaman saniyede 100 SYN paketi geçiyordu. Yavaş ulaşan paketler gerçek IP’lerden gelirken, hızlı gönderilenler değiştirilmiş kaynak IP sine (IP Spoofing) sahipti -ulaşan paketlerin TTL Time To Live değerlerindeki farklılıktan bunu tespit etmek mümkün-.

Evvelce etkinleştirdiğim SYNCookie özelliği sayesinde kaynak israfı çok artmıyor, sistemim cevap veremez hale gelmiyordu. (yoğun bir saldırıda SYNCookie CPU kullanımını sature edebilir)

netstat -ant|grep SYN_REC

SYNCookie özelliği sayesinde yukarıdaki komutu çalıştırdığımda SYN_REC durumunda bağlantı görmüyordum. Fakat SYNCookie gelen her SYN paketine SYN+ACK cevabı dönüyordu. Bunun önüne geçmeliydim. SYNCookie önlemine ek olarak, aynı IP’den gelen çok fazla SYN paketi olduğunda, bu IP lere SYN+ACK cevabı dönülmeyerek kara listeye alınmasının uygun olacağına karar verdim.

iptables -N SYNFLOOD
iptables -A INPUT -p tcp --syn -j SYNFLOOD
iptables -A SYNFLOOD -m recent --set --name KARALISTE
iptables -A SYNFLOOD -m recent --update --seconds 10 --hitcount 20 --name KARALISTE -j DROP

İki günlük çabanın ve trafik incelemesinin ardından yukarıdaki satırları iptables üzerine tanımladım. Bu satırlar sayesinde dışarıdan sunucuya doğru gelen, 20paket/10saniye oranı aşan tüm tekil IP adresleri kara listeye alınacak ve bu oranın üzerinde kaldıkları süre boyunca gönderdiği SYN paketleri DROP edilecek. Bu orana karar verirken sunucunun trafiğini bir süre incelemem ve ona göre karar vermem gerekti. Bazı sistemler için bu oran agresif sayılabilir

İşlem tamamlandı, öncesinde sunucuyu sürekli meşgul edenler, bu çalışma sonrasında kısa süreli ziyaretler dışında uğramaz oldular.

Bana gelen saldırının odaklı bir saldırı olduğunu düşünmüyorum. Büyük bir bütünün, bir parçası olarak sistemin üzerinden trafik geçiriliyor olma ihtimali yüksek. Daha odaklı bir saldırı karşısında farklı savunma yöntemleri geliştirmek gerekeceği açık.

Gelelim izleme kısmına. Kimler bu filtreye takılıyor, anlık takılanların paket akışı, filtre kuralına takılan paket sayısı gibi bilgileri alalım şimdide;

cat /proc/net/xt_recent/KARALISTE

Ubuntu tabanlı sistemlerde yukarıdaki komut ile iptables filtresinde tanımladığımız isme göre oluşan dosyayı görüntülüyoruz. Bu dosyanın içinde, belirtilen hitcount oranın üzerine çıkan kaynak IP adresleri listeleniyor ve istenmeyen davranışı tekrarladıklarında zaman bilgisi güncelleniyor. Ayrıca TTL bilgisi gibi ek bilgiler de yeralıyor.

tcpdump -nni eth0 'tcp[13] = 2'

Yukarıdaki komut ile saldırı anında veya normal izleme sırasında sadece SYN bayraklı TCP paketlerini izleyebiliyoruz.

watch -n 0.5 'iptables -vL'

Yukarıdaki komut ile iptables üzerinde tanımladığımız kurallardan geçen trafik bilgisi anlık olarak izlenebiliyor.

Eklemek istedikleriniz veya farklı önerileriniz için çekinmeden yorum bırakabilirsiniz.

Hamdi ÖZCAN – ozcan.com

5 Mart 2014

Posted In: hitcount, iptables, lkd, SYN, syn-flood, syncookie, synflood, teknik, tr

Bir SYN-FLOOD Hikayesi

Syn FloodYönetmekte olduğum bir sisteme sürekli olarak SYN paketleri gönderildiğini farketmemin üzerine çalışmalara başladım. Paketlerin gönderilme hızı değişkenlik gösteriyordu; çoğunlukla 1 paket/saniye hızında seyreden trafik zaman zaman saniyede 100 SYN paketi geçiyordu. Yavaş ulaşan paketler gerçek IP’lerden gelirken, hızlı gönderilenler değiştirilmiş kaynak IP sine (IP Spoofing) sahipti -ulaşan paketlerin TTL Time To Live değerlerindeki farklılıktan bunu tespit etmek mümkün-.

Evvelce etkinleştirdiğim SYNCookie özelliği sayesinde kaynak israfı çok artmıyor, sistemim cevap veremez hale gelmiyordu. (yoğun bir saldırıda SYNCookie CPU kullanımını sature edebilir)

netstat -ant|grep SYN_REC

SYNCookie özelliği sayesinde yukarıdaki komutu çalıştırdığımda SYN_REC durumunda bağlantı görmüyordum. Fakat SYNCookie gelen her SYN paketine SYN+ACK cevabı dönüyordu. Bunun önüne geçmeliydim. SYNCookie önlemine ek olarak, aynı IP’den gelen çok fazla SYN paketi olduğunda, bu IP lere SYN+ACK cevabı dönülmeyerek kara listeye alınmasının uygun olacağına karar verdim.

iptables -N SYNFLOOD
iptables -A INPUT -p tcp --syn -j SYNFLOOD
iptables -A SYNFLOOD -m recent --set --name KARALISTE
iptables -A SYNFLOOD -m recent --update --seconds 10 --hitcount 20 --name KARALISTE -j DROP

İki günlük çabanın ve trafik incelemesinin ardından yukarıdaki satırları iptables üzerine tanımladım. Bu satırlar sayesinde dışarıdan sunucuya doğru gelen, 20paket/10saniye oranı aşan tüm tekil IP adresleri kara listeye alınacak ve bu oranın üzerinde kaldıkları süre boyunca gönderdiği SYN paketleri DROP edilecek. Bu orana karar verirken sunucunun trafiğini bir süre incelemem ve ona göre karar vermem gerekti. Bazı sistemler için bu oran agresif sayılabilir

İşlem tamamlandı, öncesinde sunucuyu sürekli meşgul edenler, bu çalışma sonrasında kısa süreli ziyaretler dışında uğramaz oldular.

Bana gelen saldırının odaklı bir saldırı olduğunu düşünmüyorum. Büyük bir bütünün, bir parçası olarak sistemin üzerinden trafik geçiriliyor olma ihtimali yüksek. Daha odaklı bir saldırı karşısında farklı savunma yöntemleri geliştirmek gerekeceği açık.

Gelelim izleme kısmına. Kimler bu filtreye takılıyor, anlık takılanların paket akışı, filtre kuralına takılan paket sayısı gibi bilgileri alalım şimdide;

cat /proc/net/xt_recent/KARALISTE

Ubuntu tabanlı sistemlerde yukarıdaki komut ile iptables filtresinde tanımladığımız isme göre oluşan dosyayı görüntülüyoruz. Bu dosyanın içinde, belirtilen hitcount oranın üzerine çıkan kaynak IP adresleri listeleniyor ve istenmeyen davranışı tekrarladıklarında zaman bilgisi güncelleniyor. Ayrıca TTL bilgisi gibi ek bilgiler de yeralıyor.

tcpdump -nni eth0 'tcp[13] = 2'

Yukarıdaki komut ile saldırı anında veya normal izleme sırasında sadece SYN bayraklı TCP paketlerini izleyebiliyoruz.

watch -n 0.5 'iptables -vL'

Yukarıdaki komut ile iptables üzerinde tanımladığımız kurallardan geçen trafik bilgisi anlık olarak izlenebiliyor.

Eklemek istedikleriniz veya farklı önerileriniz için çekinmeden yorum bırakabilirsiniz.

Hamdi ÖZCAN – ozcan.com

5 Mart 2014

Posted In: hitcount, iptables, lkd, SYN, syn-flood, syncookie, synflood, teknik, tr

Hızlandırılmış PING

Ping komutunun alışılagelmiş hızı içinizi baymaya başladıysa;

Linux tabanlı sistemlerde -i parametresi ile hız arttırılabiliyor. 0.2 saniyeden daha hızlı olsun istiyorsanız root yetkilerini kullanmanız gerekiyor.

sudo ping -i 0.1 localhost

Windows tabanlı sistemlerde üçüncü parti uygulamalar kullanılması gerekiyor. hrPING hızlı ping atabilme yeteneğine sahip.

hrping -s 100 -t localhost

Artık ping komutundan nasıl performans alınacağını biliyorsunuz, hızlı vızıldamalar.

2 Mart 2014

Posted In: hız, hrping, linux, lkd, ping, speed, teknik, tr

Hızlandırılmış PING

Ping komutunun alışılagelmiş hızı içinizi baymaya başladıysa;

Linux tabanlı sistemlerde -i parametresi ile hız arttırılabiliyor. 0.2 saniyeden daha hızlı olsun istiyorsanız root yetkilerini kullanmanız gerekiyor.

sudo ping -i 0.1 localhost

Windows tabanlı sistemlerde üçüncü parti uygulamalar kullanılması gerekiyor. hrPING hızlı ping atabilme yeteneğine sahip.

hrping -s 100 -t localhost

Artık ping komutundan nasıl performans alınacağını biliyorsunuz, hızlı vızıldamalar.

1 Mart 2014

Posted In: hız, hrping, linux, lkd, ping, speed, teknik, tr

Linux’ta zamanlanmış görevlerde (cronjob) iş çakışmasını önlemek

Bir crontab girdisi belirli zaman diliminde çalışması için ayarlanmışsa (örneğin dakikada bir) ve bir sebepten yapılan işlemin belirtilen zaman diliminden fazla sürme ihtimali var ise, aynı komut bir öncekinin bitmesini beklemeden, zamanı geldiğinde tekrar çalışmak isteyeceğinden çakışma gerçekleşebilir.

Örneğin dakikada bir belirtilen kaynaktaki dosyaları işleyip veritabanına atan ve sonrasında kaynak dizini boşaltan bir uygulamamız için zamanlanmış görevimiz var. Diyelim ki gün için de öyle bir dakikaya geldik ki, o an tahmin edemediğimiz, öncesinde kestiremediğimiz şekilde, kaynağımıza fazladan dosyalar geldi. Yani o dakikada çalışan zamanlanmış görevin dosyaları işleyip veritabanına yollama işlemi 1 dakikadan fazla sürecek. Henüz program işlemini bitirmemişken 1. dakikanın sonunda aynı zamanlanmış görev, zamanı geldiği için tekrar çalışacak. Bu da veritabanında aynı verilerin tekrar etmesine sebep olacak.

Bu durumdan sakınmak için flock komutundan yararlanabiliriz.

flock'un basitçe kullanımı şu şekilde
flock -w 5 /herhangi/bir/yol komut
-w 5: eğer komut kullanımdaysa, belirtilen saniye kadar bekle. belirtilen sürede komut boşa çıkar ise, komutunu çalıştır.
/herhangi/bir/yol: Var olan herhangi bir dizinin altına belirleyeceğiniz yol. flock belirttiğiniz yola boş dosya oluşturacak.
komut: Çalıştırmak istediğiniz komut. mv, cp, wget, rm vs gibi.

flock kullanımını bir örnek ile göstereyim.

Görevimiz /dizin/kaynak/ yolu altındaki tüm dosyaları /dizin/hedef/ yoluna kopyalamak olsun.

Bunun için komut satırına şu şekilde bir girdi giriyoruz.

flock -w 0 /space/deneme cp /dizin/kaynak/* /dizin/hedef/

/dizin/kaynak/ yolunun altına büyük dosyalar atarak, kopyalama işlemi gerçekleştiren komutu çalıştırın.
Kopyalama işlemi devam ederken, aynı komutu terminal'de başka bir sekmede girmeyi deneyerek neler olduğunu görebilirsiniz.

Kaynak: http://www.elevatedcode.com/2013/05/07/flock-for-cron-jobs.html

1 Mart 2014

Posted In: Gezegen, linux

Twitter Auto Publish Powered By : XYZScripts.com