Link : Top 20 Most Valued Backup Exec Articles

Symantec tarafından çeşitli değerlendirmeler sonucunda en fazla rağbet gören ve yararlı olduğu kullanıcılar tarafından en çok onaylanan 20 Backup Exec makalesi.

https://www-secure.symantec.com/connect/node/1123091

Link : My 10 UNIX Command Line Mistakes

Bir UNIX yöneticisinin gerçek hayat deneyimleri. Eğlenceli bir yazı. Dikkate alınacak çok fazla kısmı da var kesinlikle.


http://www.cyberciti.biz/tips/my-10-unix-command-line-mistakes.html

Jboss SMF hizmet delegasyonu (delegation) ve RBAC (1.kısım)

Solaris 10 üzerinde çalışan Jboss hizmetinin yönetimini (kapatmak, açmak ve askıya almak) root dışında başka bir kullanıcıya verme ihtiyacı bir süredir üzerinde konuştuğumuz bir konuydu. İlk etapta hizmeti SMF biçimine dönüştürmüştük. Şimdi de bu SMF metodunun yönetimini başkalarına delege etmek gerekiyordu.


Bu konuda ne yazık ki çok fazla kaynak yok. Sun'ın bir kaç belgesi ve bir kaç blog yazısı dışında bir şeye rastlayamadım. Ancak olanları derleyerek aşağıdaki yönteme ulaştım. Bu yöntemin çalışabilmesi için hizmetin SMF'e dönüştürülmüş olması, network/jboss olarak kayıt edilmiş olması ve hizmeti devredecek 'jboss ' adında bir hesap açmış olmanız gerekiyor.



# vi /etc/security/auth_attr
                  dosya içinde en son satıra eklenir > solaris.smf.manage.network/jboss:::Jboss servisi


# usermod -A solaris.smf.manage.network/jboss jboss
# svcprop -p general network/jboss
# svccfg -s network/jboss setprop general/action_authorization=astring: solaris.smf.manage.network/jboss
# svcadm refresh network/jboss
# svcprop -p general network/jboss


Buraya kadar olan kısımı uyguladığınızda servisi yeniden başlatma yetkisini kullanıcıyı devretmiş oldunuz. Bundan sonrasını uyguladığınızda ise servisi enable / disable etme yetkisini de devrediyorsunuz.


# svccfg -s network/jboss setprop general/value_authorization=astring: solaris.smf.manage.network/jboss

Bu yöntemi uyguladığınızda RBAC metoduna girmeden yalnızca tek bir kişi ve hizmet için delegasyonu sağlayabiliyorsunuz. Aynı işin RBAC ile nasıl yapılacağını bir sonraki yazımda anlatacağım. Bitirmeden önce bu konuda fayda sağlayacak bir iki kaynak adresi de ekte vermek istiyorum.

Restricting Service Administration in the Solaris™ 10 Operating System

http://www.sun.com/blueprints/0605/819-2887.pdf

RBAC and Privileges - Part 1: Introduction

http://www.c0t0d0s0.org/archives/4073-Less-known-Solaris-features-RBAC-and-Privileges-Part-1-Introduction.html

64bit Windows 2003, SQL 2005 ve MSXML6.0 problemi

64bit Windows 2003 server üzerine SQL 2005 yüklemek isterken MSXML 6.0 ile ilgili probleme rastlamış olabilirsiniz. Ben de karşılaştım ve deneyimledim :) 


Çözüm aşağıdaki makalede.

http://sqlblog.com/blogs/aaron_bertrand/archive/2009/02/20/the-xp-sp3-msxml6-sp2-sql-server-debacle.aspx

error 3 : bad or corrupt data while decompressing file

Solaris 10 U7 bir sunucumuzda yüksek oranda hesaplamaya dayanan tomcat ve mysql tabanlı bir uygulamamız vardı. Bu uygulama için kurulan yeni sunucuda JVM ayarlarıyla ilgili yapılan bir hata nedeniyle core dump oluşmaya başladı ve süratle sunucunun diskini doldurdu.

Kapatıp açtıktan sonra , açılış sırasında aşağıdaki nahoş hatayı almaya başladık ve işletim sistemini yükleyemez hale geldik.

error 3 : bad or corrupt data while decompressing file

Yaptığım kısa bir araştırmadan sonra bunu çözmenin basit bir yolu olduğunu öğrendim. Aşağıda paylaşıyorum.

Sunucu failsafe modda açıldıktan sonra aşağıdaki komutlar çalıştırılır.

sh> rm -f /a/platform/i86pc/boot_archive

sh> bootadm update-archive -R /a

sh> reboot

Tomcat 6 SMF servisi oluşturma (Solaris 10)

Tomcat 6.0'ı Solaris 10 üzerinde SMF servisi olarak çalıştırmak için hazırda bir kaynak bulamadım. Yaptığım araştırmalarda da net olarak bir XML dosyası elde edemedim. Dolayısıyla iş başa düştü. Sırayla tüm adımları aşağıda gönderiyorum.

1- Java 1.6 yüklenir ( /opt/jdk1.6)

2- Tomcat 6.0 yüklenir (/opt/apache-tomcat6)

3- Tomcat XML oluşturulur ve /var/svc/manifest/network altına tomcat.xml olarak kopyalanır.

4- /opt/apache-tomcat6/bin altındaki tüm çalıştırılabilir dosyalara +x (execute) hakkı verilir.

5- tomcat için bir kullanıcı hesabı ve grup oluşturulur.

6- /opt/apache-tomcat6/log klasörünün sahipliği tomcat:tomcat grubuna verilir.

7- svccfg import /var/svc/manifest/network/tomcat.xml ile servis hazırlanır.

8- Java, /usr/bin'den farklı bir yere yüklenmiş olduğu için sembolik link oluşturulur.

ln -s /opt/jdk1.6/java /usr/bin/java

9- /opt/apache-tomcat6/bin/startup.sh içine JAVA_HOME=/opt/jdk1.6 eklenir.

Aşağıda bir Jboss XML'den devşirerek oluşturduğum XML dosyasını bulabilirsiniz (Neden metin olarak yüklemediğimi sorarsanız, Blogger koda kızdığı ve ben de bunu nasıl aşacağımı bilmediğim için böyle yaptım. Tekrar yazmak zorunda kalacaklar kızabilirler ama malesef böyle.. :) )

BackupExec 12.5, Windows 2008 ve file system caching

BackupExec 12.5 kullandığımızdan bu yana en büyük sorunlarımızdan biri, BE sunucusunda 64 bit Windows 2008 kullanmamıza rağmen yüksek File Caching Service bellek tüketimiydi. Bu tüketim çoğunlukla öyle noktalara çıkıyordu ki, uygulamanın performansını etkilemesi bir yana, 0 byte serbest bellek nedeniyle korkunç miktarda sayfalama hatalarıyla (paging) sunucunun performansını bile düşürmekteydi.

Bir süre agentlarla ilgili testler vs. yaptık ancak sonuçta farkettik ki, konunun agentlarla ilgisi yoktu. Windows 2008 64bit işletim sisteminde file caching'i kontrol altına alabilmek için başka bir yöntem bulmak zorundaydık.

Bir süre araştırdıktan sonra aşağıdaki MSDN blogunu ve uygulamayı bulduk.

http://blogs.msdn.com/ntdebugging/archive/2009/02/06/microsoft-windows-dynamic-cache-service.aspx

Bu uygulamayı Windows 2008'e servis olarak kayıt ettirdikten sonra caching hizmetinin tükettiği belleğin kontrol altına girdiğini gördük. Parametrelerle oynayarak caching'in azami ne kadar bellek tüketeceğini sınırlamak mümkün. Ancak bellek talep eden uygulama olmadığı takdirde dinamik bellek yönetimi belleği caching'e bırakıyor. Şimdilik gözlemlerim bu yönde.

Uygulamayı kullandığımızdan bu yana yedekleme sisteminin performansında azımsanmayacak iyileşmeler gördük. Gerçi daha çok iyileşmeye ihtiyacı var ancak bir sorunu daha halletmiş olmaktan memnunuz.