Mirror Edilmiş Slave SQL Server Üzerinden DB Snapshot Almak

Mirror edilmiş SQL serverlardan slave servera select,insert gibi benzeri sql statementlar gönderilmiyor.Eğer slave server(mirror) üzerinde bir db snapshot alınırsa bu durum tersine çevrilebilir.

CREATE DATABASE db_name_snap_shoot ON ( NAME = AirAvansDB, FILENAME = ‘C:\Program Files\Microsoft SQL Server\MSSQL10_50.MSSQLSERVER\MSSQL\Data\db_name_snap_shoot.ss’ )
AS SNAPSHOT OF db_name;
GO

Yukarıdaki sql sorgusunu, dilediğiniz zaman diliminde proses eden bir job tanimlamaniz yeterli olur.Böylece açık olmayan bir veritabanına sorgu yazılabileceği gibi, artık expand edilebilir bir hale de gelecektir.

Not: Sanırım, Microsoft sınıfı ile ilgili girdiğim en ciddi entry bu oldu.
Ne de olsa ilkler her zaman önemlidir.

Share on Facebook

Sudoers ile Grup Bazlı Yetki Yükseltimleri

groupadd localadmin
useradd -m -r -s /bin/bash -G localadmin penguen
passwd penguen

vi /etc/sudoers dosyası açılır ya da  visudo komutu çalıştırılarak dosya üzerinde arzu edilen yetki düzenlemeleri yapılmak üzere istenilen grup ya da kullanıcı eklenir. Nitekim yukarıdaki komut istemleri ile localadmin isminde bir grup ve yeni bir kullanıcı oluşturduk.Aşağıdaki satırlar, localadmin grubuna ait kullanıcıların sistem üzerinde tüm komutları çalıştırma hakkına sahip olduğunu ifade etmesi için eklendi.Bir alt kısmında tanımlanan satır ise, sudo ile yetki almış kullanıcıların home environment’ini belirtmek üzere sonradan ilave edildi.

%localadmin     ALL=(ALL)       ALL
Defaults    secure_path = /usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin

“sudo su” ile yetki yükselttikten sonra, mevcut environment path’leri aşağıdaki komut istemiyle görülebilir.

echo $PATH
/usr/kerberos/sbin:/usr/kerberos/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin

Artık, 0 nolu uid  kullanıcısının sahip olduğu kalıcı bir root environment tanımladık.Böylece; service,ifconfig,route gibi benzeri komutlar uzunca bir path yazmadan çalışabilecek.Sudoers dosyası, bir çok nix sistem dağıtımı için gayet geniş yetkiler barındıran bir policy konumuna sahip.Özellikle grup ve kullanıcı hakları üzerinde efektif  yetkiler vermek mümkün.Ayrıca session alan her kullanıcı veya grup için spesifik güvenlik etkileri sağlayacak çeşitli policy’ler de mevcut.

Ek olarak , env_check,env_delete ve env_keep gibi diğer environment argümanları  hakkında detaylı bilgi “man sudoers” ile alınabilir.

Share on Facebook

Güvenlik TV’de Bilişim Hukuku

Türkiye’de, bilişim sistemleri alanında çeşitli dallarda faaliyet gösterip bilişim sistemlerinin hukuki boyutunu araştıranlar, konuyla ilgili yeterli bilgi sahibi olamayan teknik kişiler ve/veya tez yazan arkadaşlara özellikle taviye edeceğim bir konu; geçtiğimiz günlerde güvenlik TV isimli yep yeni bir platform üzerinde, Doç. Dr. Leyla Keser ile konuşulmuş.Üniversite tarafında bu dönem, Bilişim Hukuku isimli bir dersim var ve önümüzdeki hafta görmeye başlayacağım.Bu söyleşi şimdiden harika oldu.Umarım konuyla alakadar olmak isteyen herkese faydalı olur.

Share on Facebook

Shell session gecmisinin her logout esnasinda temizlenmesi

Komutlar:

echo history -c >> .bash_logout && echo $? ; tail -n 1 .bash_logout

echo history -c >> .bash_logout && cat /dev/null > .bash_history |echo $? ; tail -n 1 .bash_logout

Çıktı:
0
history -c

Artık, bash session her kapatıldığı esnada, açık session içerisinde çalıştırılan komut istemleri de silinecektir.

Referans:

http://ipucu.enderunix.org/index.php?tip_id=4&lang=tr

Share on Facebook

Nohup Kullanımı 2

Burada nohup kullanımı ile ilgili bir giriş yapmıştım.Fakat üzerine eklenmesi gereken bir kaç ufak detayın ve disown gibi aynı işleve sahip farklı bir komut’un da anlatılması gerektiğini fark ettim.Çalıştırılacak uygulama veya komuta ait proses, tıpkı açılan her bir proses gibi yüksek seviyeli bir öncelik ile çalışır.(” high priority number “0″)

Bu durumda nohup içerisine nice -n argumanı eklenerek  açılacak yeni proses’in en düşük seviyede(19)  veya daha farklı seviyelerde çalışması sağlatılabilir.Aşağıda, bu durumu irdeleyen örnek bir komut kullanılarak sonucu hemen alt kısmına eklendi.

nohup nice -n 19 seq 1 9999999999 > /tmp/out &

 PID    USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
28544
root      36  19    61496  616   540 R    45.3    0.1           0:11.32    seq

NI: Proses çalışma önceliği(Process priority)

Bu durumda, 1 numaralı parent proses’e migrate olan 28544 nolu yeni proses’in çalışma önceliği 19 ile set edilerek en alt seviyede çalışması sağlandı.Artık bu proses, cpu kullanımını minumum seviyede tutacağı gibi yoğun bir sistem üzerinde diğer proses’lerin altında çalışarak sistem kaynaklarını da yormayacaktır.

Bu arada, nohup belirtilen amaçlar için tek çözüm değildir.Bash kabuğu üzerinde desteklenen “disown”  isimli bir komut daha vardır ki çalıştırılan proses’e ait job number’a göre hareket eder ve yine nohup ile aynı işlevi yapar.Fakat disown ile çalıştırılacak komut veya script betiği, bir sh dosyasına  eklenerek çalıştırılmalıdır.

Örnek:

touch test.sh && echo “nice -n 19 seq 1 9999999999 > /tmp/out”  > test.sh && ls -l test.sh && echo $?
-rw-r–r– 1 root root 39 Jan  29 23:44 test.sh
0

Yukarıdaki komut ile “nice -n 19 seq 1 9999999999 > /tmp/out” tırnak içerisinde belirtilmiş olan komutu; string bir ifade gibi, test.sh isimli yeni bir dosya oluşturularak içerisine yazılmasını sağlıyoruz.Bu işlem esnasında dosya kontrolü ve herhangi bir hata dönecek mi diye de “$?” ifadesi ile kontrol ediyoruz.

test.sh isimli dosyanın disown edilme aşaması ve ps ile proses kontrolü.
sh test.sh &
[1] 28978
[root@matrix tools]# disown -h

ps -aux | grep seq
Warning: bad syntax, perhaps a bogus ‘-’? See /usr/share/doc/procps-3.2.7/FAQ
root     28979 87.9  0.1  61496   612 pts/0    RN   06:30   0:49 seq 1 9999999999

Şuanda disown edilen script, en tepede bulunan 1 numaralı parent proses’e migrate edilerek arka planda çalışmaya başladı.Artık shell session kapatılsa dahi işlemler arka planda çalışmaya devam ediyor olacaktır.

Detaylar:

“man bash”

Share on Facebook

Nohup Kullanımı

Kabuk üzerinde yapılan işlemler, bir parent proses altında kendine ait bir child proses içerisinde çalışır.Örneğin bash kabuğunda bir oturumunuz var ve bir script çalıştırıyorsunuz oturum kapandığı esnada çalışır durumda olan ilgili script de sonlanır.Teorik olarak kapanma sebeplerini açıklamak istiyorum.Oturum açıldığı esnada bir parent proses açılır ve yapılan ek işlemler bu proses’e child proses olarak bağlanır.Dolayısıyla oturum kapatıldığı esnada herhangi bir script çalışır durumda olsa bile parent proses, 1 numaralı “SIGHUP” sinyalini alacağı için kısa bir süre içerisinde kendine bağlı olan child proses’leri de sonlandıracaktır.Ancak “nohup” gibi hareket eden bir araç ile scriptler çalıştırılır ise durum tam anlamıyla farklı bir hal alır ve oturum kapansa bile proses sonlanmaz.

Nohup, çalıştırılan işlemlere ait child proses’leri, en yukarıda bulunan 1 numaralı parent prosese migrate eder ve gelebilecek hup sinyallerinden child prosesleri korur. Dolayısıyla oturum kapansa bile çalışan işleme ait proses, 1 nolu parent proses altına migrate edilerek arka planda sonlanana kadar çalışması sağlanır.

Nohup kullanım örneği:

 nohup seq 0 9999990000000 1>/tmp/out < /dev/null &

Yukarıdaki komut ile ulaşmak istenilen asıl amaç, “seq” komutu  ile belirtilen doğal sayılar arasında ramdom sayılar üretip, /tmp klasörü altında bulunan out isimli dosyaya sonucu yazdırmaktır.Komut sonuna dahil edilen “/dev/null” ise klavye davranışları önlemek adına kullanılır.Nohup ile çalıştırma işlemi başladıktan hemen sonra, shell oturumu kapatılıp yeni bir oturum açılarak proses’in o anki durumu “ps” komutuna verilecek çeşitli direktifler ile detaylıca veya top komutu ile basitce gözlemlenebilir.

Nohup edilen programa ait 25571 nolu proses’in 1 numarali parent proses altında çalıştığı, “pstree -p 1″ komutu ile görülmek istenirse , aşapıdaki gibi bir görüntü ortaya çıkar.


Yukarıdaki ekran görüntüsü 25571 nolu child proses’in  1582 > 24634 > 25547 > 25549 nolu parent prosesler dizisi altında olduğunu ifade ediyor.Zira zaten her proses, bir üst seviyede bulunan diğer bir parent prosese bağlıdır.

Not: Ancak işletim sistemi kabuğunun çeşitli özelliklerine göre bu tür proses korumaları yapılabilir.

Share on Facebook

First Process “/sbin/init”

/sbin/init isimli başlangıç prosesi her zaman 1 nolu pid numarayi alır.Burada enteresan olan durum: bu proses’e ait herhangi bir parent prosess olmayışıdır.Dolayısıyla her zamana “0″ olarak değerlendirilir.

Not: Init isimli prosess, linux açıldığı esnada devreye girer. İlk etapta “/etc/inittab” isimli dosyada set edilmiş olan runlevel numarasını okur ve  işletim sistemini bu doğrultuda açar.

Aşağıda bulunan kütüphaneler ile entegre çalışır.

libsepol.so.1 => /lib64/libsepol.so.1 (0x0000003900c00000)
libselinux.so.1 => /lib64/libselinux.so.1 (0×0000003900800000)
libc.so.6 => /lib64/libc.so.6 (0x00000038ff400000)
libdl.so.2 => /lib64/libdl.so.2 (0x00000038ff800000)
/lib64/ld-linux-x86-64.so.2 (0x00000038ff000000)

Share on Facebook