systemctl

systemd, Linux için bir sistem ve servis yöneticisidir ve SystemV ve Upstart’ın yerini almaktadır. systemd, servis yapılandırmasını ve davranışını Linux dağıtımları arasında birleştirmeyi amaçlar.
Systemd’nin amacı; bilgisayardaki sistem ve servislerin çalışmasını organize etmektir. Yani modern linux işletim sisteminde başlama (startup) ve sunucu (server) proseslerini yöneten sistem olarak systemd sistem kaynaklarının, arkaplan (daemon) ve diğer süreçlerin (process) etkinleştirilmesi için bir mekanizma sağlar. Bu yönetimi, systemctl, journalctl, notify, analyze, cgls, cgtop, loginctl ve nspawn olarak adlandırılan araçlar sayesinde gerçekleştirir.

Arkaplan süreçleri (daemons) adından da anlaşılabileceği gibi başlatıldıklarında görevlerini yürütmek üzere arka planda bekler veya çalışırlar. Bu süreçler tipik olarak işletim sistemi yüklenirken (boot) başlatılırlar ve sistem kapatılana ya da manuel olarak durdurulana kadar arkaplanda (background) çalışmayı sürdürürler. Genel bir ilke olarak arkaplan süreç adları genellikle d harfi ile sonlanır (sshd – ssd deamon gibi).

Systemd ortamında aşağıdaki kavramlar yaygın olarak kullanılır:
• Daemon: başlatıldıklarında görevlerini yürütmek üzere arka planda bekleyen veya çalışan süreçler.
• Socket: Bağlantıları dinlemek için arkaplan süreçleri tarafından kullanılır. Yerel ve uzak istemciler için ana iletişim kanalıdır. Süreçler tarafından yaratılırlar.
• Service: Genellikle bir ya da daha çok sayıda arkapan sürecine işaret eder Servisi başlatma/durdurma işlemi genellikle sistem durumunda (state) kalıcı bir değişikliğe neden olur.

Eskiden init dediğmiz ve işletim sistemi kernel yüklemesinden sonra çalışan ve PID (Process ID) 1 olan süreçlerle yönetilmekte idi. Çekirdek kendini başlattığı (belleğe yüklendiği, çalışmaya başladığı ve aygıt dosyaları, veri yapıları ve benzeri şeyleri başlattığı zaman) ve kullanıcı seviyeli bir program olan initsürecini başlattığında, kendi üstüne düşen açılış işlemlerini bitirmiş olur. Bundan dolayı init her zaman için ilk süreçtir ve süreç numarası da daima 1’dir. init süreci /etc/inittab dosyasını okuyup sistemin hangi Run Level’dan başlayacağına karar verirdi. Aşağıda /etc/inittab dosyasından bir kesit sunulmaktadır.

# Default runlevel. The runlevels used by RHS are:
# 0 – halt (Do NOT set initdefault to this)
# 1 – Single user mode
# 2 – Multiuser, without NFS (The same as 3, if you do not have networking)
# 3 – Full multiuser mode
# 4 – unused
# 5 – X11
# 6 – reboot (Do NOT set initdefault to this)
#
id:3:initdefault:

Buradaki id:3:initdefault: satırı bizim işletim sistemimizin RunLevel 3 ‘den başlayacağını göstermektedir. Red Hat sistemlerde RunLevel’lar

• 0 – halt (Sistemi kapatmak –poweroff veya halt- için kullanılan runlevel)
• 1 – Single user mode (Sistemi kurtarmak için kullanılan ve network ayarlarının aktive edilmediği tekli kullanıcı mode’u. Bazı yerlerde S veya s olarak da adlandırılır.
• 2 – Multiuser NFS olmadan çoklu kullanıcı mode’u (Bu runlevel 3. Runlevel ile genel olarak aynıdır. Tek fark network ayarlarını içermemesidir.)
• 3 – multiuser mode (Network ayarlarını nda aktive edildiği ve genellikle kullanılan RunLevel’dır.
• 4 – kullanılmıyor.
• 5 – X11 (Runlevel 3 e ek olarak görsel ekranın- ki biz buna X veya X11 de deriz- da başlatıldığı runlevel. Runlevel 3’den sonra en çok tercih edilen runlevel’dır.)
• 6 – reboot (Sistemin kapatılıp tekrar açıldığında kullanılan RunLevel’dır.

İnit süreci ön tanımlı runlevel’ı ayarladıktan sonra sistemde /etc/rc.d/init.d/ altında bulunan ve rpm paketleri içinde gelen servis scriptlerini (bunlar bir shell scripttir!) çalıştırır. Örnek olarak eğer runlevel 3 de isek ve sshd servisi çalışacaksa bunun başlangıç scripti /etc/rc.d/init.d/sshdaltında yer almakta. Bunun runlevel 3 de çalışmasını da /etc/rc.d/rc3.d/S55sshd scripti sağlamakta idi. Buradaki S harfi bunun start edilleceği, 55 ise başlangıç sırasını belirtmektedir.

# ls -la /etc/rc.d/rc3.d/S55sshd lrwxrwxrwx 1 root root 14 Jun  6  2011 /etc/rc.d/rc3.d/S55sshd -> ../init.d/sshd

(devamı..)

2,189 total views, 3 views today


Weblogic Log Yapısı

WebLogic Server instance, kendileri hakkındaki bilgileri loglara yayımlar.

Log Açıklama
Server log Server alt sistemleri tarafından eventleri kaydetmek için kullanılır
Standart log Bazı server günlük logları için standart out yazdırılır.
Domain log Bazı server iletileri, domain çapında loga dahil edilmek üzere Admin Server tarafından toplanır.
Access log HTTP alt sistemi tarafından HTTP iletişimini izlemek için kullanılır
Audit log Güvenlik isteklerini izler. Auditing providerın yapılandırılmasını gerektirir (varsayılan olarak yapılandırılmamıştır).
Transaction log • WebLogic Server tarafından yönetilen transactionlar hakkında bilgi içerir

• Server tarafından çökmelerden kurtulurken kullanılır

• Binary biçimdedir

JMS Server log • JMS Server oluşturulduğunda etkinleştirilir

• Mesaj hedefleri özel olarak etkinleştirilmelidir.

 

Her WebLogic Server instance’ı, alt sistemlerinden ve uygulamalarından gelen iletileri lokal ana bilgisayarda bulunan bir server log dosyasına yazar.

Her server instance log dosyasına ileti yazmanın yanısıra iletilerin bir alt kümesini standar out dosyasına yazar. Varsayılan olarak, bir server instance, standart çıkışa yalnızca NOTICE önem düzeyine veya daha fazla önem düzeyne sahipi yüksek iletileri yazdırır.

İletilen iletilerin türünü değiştirebilmenize rağmen, sunucular hiçbir zaman DEBUG sevirity düzeyindeki iletileri iletemez.

HTTP alt sistemi, tüm HTTP transactionların logunu tutar. HTTP access log için varsayılan konum ve rotate ilkesi server log ile aynıdır. Her sunucu için HTTP accessloglarının davranışını tanımlayan öznitelikleri ayarlayabilirsiniz.

WebLogic Auditing provider, WebLogic Security Framework tarafından dahili olarak belirlenen bir dizi güvenlik talebindeki bilgileri kaydeder. WebLogic Auditing provider ayrıca bu güvenlik istekleriyle ilişkili olay verilerini ve isteklerin sonucunu da kaydeder. Varsayılan güvenlik alanında bir Auditing provider yapılandırılmamışdır.

Her serverın, server tarafından yönetilen tamamlanmamış transactionlar hakkında bilgi depolayan bir transaction logu vardır. WebLogic Server, sistem çökmelerinden veya ağ hatalarından kurtarırken transaction logu kullanır.

Weblogic Log Lokasyonu

  • Admin server’ında access logu mevcuttur.
  • Audit log’da yapılandırılırsa varsayılan olarak “domainpath/domainname/servers/servername/logs/DefaultAuditRecorder.log” dosyasında tutulur.
  • Transaction logun varsayılan yeri ise “domainpath/domainname/servers/servername/data/store/default/_WLS_SERVERNAMExxxxxx.DAT” dosyasıdır.

Log Mesajlarının Önem Düzeyleri

Düşükten yüksek etkiye logların önem düzeyleri aşağıdaki gibidir;

Severity Açıklama
TRACE Used for messages that are part of WebLogic Diagnostic Framework
DEBUG Debug etkinken debug flags’dan gelen iletiler
INFO Normal çalışma bilgileri
NOTICE Daha önemli operasyonel bilgiler
WARNING Şüpheli bir şey oluştuğunda gelen iletiler her zaman normal çalışmayı etkilemebilir
ERROR Kullanıcı düzeyinde bir hata oluştu, ancak sistem veya uygulama herhangi bir kesinti ve sınırlı hizmet bozulması olmadan bu sorunu çözebilir.
CRITICAL Sistem veya servis düzeyinde hata oluştu. Sistem iyileşebilir, ancak anlık kayıp veya hizmette kalıcı bozulma olabilir.
ALERT Belirli bir servis kullanılamazken, sistemin diğer bölümleri hala çalışır. Otomatik kurtarma mümkün değildir. Hemenbir yönetici gerekir.
EMERGENCY Sunucu kullanılamıyor. Bu ciddi bir sistem arızasını gösterir.

 

Log Dosya Verilerini Anlama

Tüm WebLogic Server instanceler için iletiler tutarlı attribute kümesi içerir. Ayrıca, uygulamanız iletiler oluşturmak için WebLogic log kaydı hizmetlerini kullanıyorsa, iletileri bu attribute içerir.

Attribute Description
Timestamp İletinin, yerel ayara özgü bir biçimde oluşturulduğu saat ve tarih. Her WebLogic Server instance çalıştıran Java Sanal Makinesi (JVM), yerel saat dilimi ve biçimi hakkında bilgi için ana bilgisayar işletim sistemine başvurur.
Severity Mesaj tarafından bildirilen olayın etki derecesini veya ciddiyetini belirtir.
Subsystem İletinin kaynağı olan WebLogic Server’ın alt sistemini belirtir; örneğin, Enterprise Java Bean (EJB) container veya Java Messaging Service (JMS).
Server Name

Machine Name

Thread ID

Transaction Id

Mesajın kökenini tanımlar:

·         Server Name, iletinin oluşturulduğu WebLogic Sunucusu instance’ın adıdır.

·         Machine Name, sunucu instance’ını barındıran bilgisayarın DNS adıdır.

·         Thread ID, JVM’nin iletinin kaynaklandığı iş parçacığına atadığı kimliktir.

·         Yalnızca transaction bağlamında loga kaydedilen iletiler için sunulur.

User ID İlişkili olayın altında yürütüldüğü kullanıcı kimliği.
Message ID Eşsiz altı haneli bir tanımlayıcı. WebLogic Server sistem mesajlarının oluşturduğu tüm mesaj kimlikleri BEA- ile başlar ve 0-499999 sayısal aralığında kalır.
Message Text Olayın veya koşulun açıklaması.

 

Server Logunu Yapılandırma

Log rotation, yeni log dosyaları oluşturma ve eski log dosyalarına zaman damgası ekleme işlemidir. Bu, bir log dosyasının çok büyük büyümesini önlemeye yardımcı olur. Log rotation, bir log dosyası belirli bir boyuta ulaştığında veya belirli bir zaman aralığından sonra veya belki de her ikisinde birden yapılabilir. Log rotation, belirli miktarda döndürülmüş log dosyası oluşturulduktan sonra eski log dosyalarının yeni log dosyalarıyla değiştirilmesini sağlayacak şekilde de yapılandırılabilir.

Varsayılan olarak, WebLogic sunucularının log rotation ayarlarının sınırsız sayıda log dosyası döndürülecek şekilde ayarlanmıştır. Loglar, yaklaşık 5000 KB’a ulaştıktan sonra log dosyası yenilenir.

  1. Log rotate değiştirmek için WebLogic Admin Console’nda oturum açın.
  2. Daha sonra Environment -> Servers seçeceğiz
  3. Buradan ayar yapmak istediğmiz serverı seçeceğiz
  4. Sol üst köşedeki ” Lock & Edit” yi tıklayacağız
  5. Logging -> General seçeceğiz
  6. Rotation bölümünde Rotation type göreceksiniz. “By size (Boyuta Göre)” veya “By time (Zamana Göre)” isteyip istemediğinizi seçebilirsiniz.
  7. By size (Boyuta Göre) : Döndürme dosyası boyutu parametresi, log dosyası döndürülmeden önce dosyanın ne kadar büyük olabileceğini belirtir (KB cinsinden). “Döndürme dosyası boyutu” parametresi, bir günlük dosyasının döndürülmeden önce ne kadar büyük olabileceğini belirtir (KB cinsinden)
  8. By time (Zamana Göre) : Rotasyona başlama zamanı parametresi, günlük dosyasının döndürülmesini belirtir (günün SS: DD cinsinden). Bir günlük dosyasının ne sıklıkta döndürüleceğine ilişkin bir Döndürme aralığı da (saat olarak) belirleyebilirsiniz.
  9. Dizindeki log dosyalarının sayısını sınırlamak için “Limit number of retained files” yı seçebilirsiniz (varsayılan olarak işaretli değildir).

Diğer önemli paramtrelerden bazıları;

 

  • Severity level : Log için günlük iletilerinin minimum önem düzeyleriniayarlar. Varsayılan olarak tüm iletiler günlük dosyasına gider.
  • Filter : Sunucu log dosyası için filtre yapılandırması. Filtre yapılandırması, log dosyasına yazılan günlük iletilerinin hacmini sınırlamak için basit filtreleme kuralları tanımlar.
  • Log file Buffer : Temel log buffer boyutu kilobayt olarak alır.

NOT: Aynı paramterelerin hemen hepsi bütün log tiplerinde vardır.

Mustafa Bektaş Tepe
İyi Çalışmalar

48 total views, no views today


Weblogic Versiyonlu Deploy

Weblogic server side-by-side (çalışan bir kod varken, aynı kodun farklı bir versiyonunu deploy etme)  adı verilen son derece faydalı bir deployment seçeneği sağlamaktadır. Bir uygulamanın yeni bir versiyonunu devreye almak ve aynı zamanda eksi versiyondaki uygulamanın çalışır durumda kalmasını istiyorsanız side-by-side deployment tam da sizin aradığınız bir çözüm olacaktır. Eski versiyonu kullanan sessionlar expired olduğunda weblogic bunu anlayarak eski versiyonlu uygulamayı deaktif duruma getirecektir. Aynı anda, yeni versiyona sahip olan uygulama aktif olacak ve tüm yeni sesionlar da bu uygulamaya bağlanacaktır.

Bir uygulamaya versiyon tanımlayıcısı atamak için, uygulamanın bir parçası olan MANIFEST.MF dosyasına sürüm adını veren bir satır ekleyebilirsiniz. Alternatif olarak sürüm adı, dağıtım sırasında weblogic.Deployer komut satırı aracının -appversion argümanı veya WLST komutlarının deploy () ve updateApplication () ‘nin archiveVersion argümanı kullanılarak belirtilebilir.

Eğer aşağıdaki gibi bir manifest dosyasını uygulama içerisine META-INF/MANIFEST.MF dosyası olarak daha ilk deployment aşamasında uygulama versiyonlanmış olacaktır.

cat /u01/deploy/deployversion1/simple/META-INF/MANIFEST.MF
Manifest-Version: 1.0
Class-Path:
Created-By: Bill Bell
Weblogic-Application-Version: v1

Eğer aşağıdaki gibi bir sonraki güncel uygulamada (Yani bu örnek için ‘v2’) versiyon bilgisi değişirse, Weblogic bu durumdan da haberdar olacak ve hem mevcuttaki uygulamanın hem de güncel uygulamanın admin kontrolünde birlikte yaşamasına imkan tanıyacaktır.

cat /u01/deploy/deployversion2/simple/META-INF/MANIFEST.MF
Manifest-Version: 1.0
Class-Path:
Created-By: Bill Bell
Weblogic-Application-Version: v2

Bilinen yöntemlerle bu uygulamanın deploymentı yapılır.

Bu aşamada daha önce karşımıza çıkmayan ‘Archive Version’ etiketi ile de artık karşılaşmış oluyoruz. Weblogic, uygulama içerisine gömmüş olduğumuz manifest dosyası içerisindeki versiyon bilgisini okuyarak uygulamayı versiyonlamış oldu.

 

Aslında versiyon bilgisinin alınması dışında şu aşamaya kadar farklı birşey ile karşılaşmadık. İlgili IP:Port üzerinden uygulamayı çağıracak olursak mavi görüntülü ilk versiyon ile uygulamayı açmış oluruz.

Bu aşamada artık mevcutta var olan uygulamayı yeni versiyon ile update etmeye başlıyoruz.

 

Yeni versiyonu deploy ederken dikkat edilmesi gereken bir önemli nokta eski ve yeni versiyon uygulamaların disk sistemi üzerinde ayrı ayrı path’lerde aynı isimle bulunmalarıdır. Eğer yeni versiyon, mevcut uygulamanın üzerine yazılacak olursa update sonrası rollback imkanımız kalmamış olur ve update özelliğinden faydalanılamaz.

Yeni versiyon algılandı.

 

Tam bu aşamada daha önce görmeye alışık olmadığımız bir görüntü ile karşılaşıyoruz. Aynı hedef (Managed server, cluster, …) üzerinde aynı isimli iki farklı uygulama aynı anda bulunuyor.

 

Test edersek;

Deployment tamamlandıktan kısa bir süre sonra ilk eski versiyonun state’inin artık ‘stop Running’ olarak işaretlendiği görülür.

Artık yeni uygulama ‘Active’ olmuştur. Fakat her iki versiyon da halen ekranda görülmeye devam eder.

Bu aşamada yeni versiyonu yalnızca admin isteklerine açabilir testlerinizi yaptıktan sonra tüm kullanıcıların hizmetine sunabilirsiniz. Ya da eğer testleriniz başarısız olduysa eski pakete dönme imkanınız da halen mevcut. Eski pakete dönülmesi için yapılması gereken yalnızca ilk versyonun kendisi üzerinden update/re-deploy edilmesidir.

NOT: Weblogic server maksimum 2 farklı versiyonu deploy etmenize izin verir.

war dosyalarını indirmek için bağlantıya tıklayabilirsiniz.

Mustafa Bektaş Tepe
İyi Çalışmalar

51 total views, no views today


Weblogic Instance Açılışında Performans Artışı

Weblogic üzerinde bazen servislerimizin beklenenden yavaş açıldığını , açılsa dahi ” 7001/console ”(Admin Console) ekranın beklettiğine şahit olmuşsunuzdur.

Managed server ları restart edip log akışını izlerken bazı platformlarda logumuzun uzun süre aşağıdaki satırda beklediğinide görebiliriz:

#### < xapp-1-7003> <[ACTIVE] ExecuteThread: '0' for queue: 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1329309449456>

Bunun nedeni, rasgele sayı üretimi için kullanılan JVM librarysi UNIX platformları için varsayılan olarak /dev/random’a dayanmaktadır. Bu, bir sonuç döndürmeden önce başlatmayı yavaşlatabilir. Bu da genelde servislerin açılmasında gecikmelere sebep olabilmektedir. “dev/random” komutu daha güvenli olmasına karşın unix platformlarda gecikmeye sebep oluyorsa, bunun yerine “dev/urandom” komutunun kullanılması önerilmektedir.

Platformumuzda bu performans probleminin olup olmadığını test etmek için, shell prompt da aşağıdaki komutun çıktısı kontrol edilir.

[root@test ~]# time head -1 /dev/urandom
±›Zµ3cİ©ŠÔ‹i91D¹

real 0m0.002s
user 0m0.000s
sys 0m0.002s
[root@test ~]# time head -1 /dev/random
.......

real 2m50.623s
user 0m0.002s
sys 0m0.003s

Gördüğümüz gibi, /dev/urandom hemen sonucu döndürürken, /dev/random neredeyse 3 dakika sürdü.

Weblogic sunucusunu başlanamasını hızlandırmak için ise JVM’in java.security ayarını değiştiririz.

[root@admin ~]$ vi $JAVA_HOME/jre/lib/security/java.security
...
securerandom.source=file:/dev/urandom

Yada sadece belirli bir domain için java.security parametresini değiştirmek istersek, startWebLogic.sh scriptini güncelleriz;

[oracle@test ~]$ vi $DOMAIN_HOME/bin/startWebLogic.sh
#!/bin/sh
export JAVA_OPTIONS=-Djava.security.egd=file:/dev/./urandom
...

Mustafa Bektaş Tepe
İyi Çalışmalar

54 total views, no views today



Veritabanında Denetleme (Audit)

Veritabanında standart denetleme audit_trail parametresine değer (os, db, db extended, xml, xml extended) atanması ile başlar. Eğer denetlemeyi durdurmak istersek parametre NONE yapılmalıdır. Bu parametrenin none yapılması ile beraber veritabanı kapatılıp açıldığında tüm denetleme durmuş olur.

Denetlemeler komut, yetki, obje ve network aktiviteleri bazında tanımlanır. Denetleme başlatmak için AUDIT, durdurmak için NOAUDIT komutu kullanılmalıdır.

Bir kullanıcı kendine ait tüm kullanıcılar üzerinde AUDIT başlatabilir. Başka kullanıcıların objeleri üzerinde AUDIT başlatmak için ise AUDIT ANY yetkisi olmalıdır. Sistem yetkileri üzerinde AUDIT tanımlamak için AUDIT SYSTEM yetkisi olmalıdır. NOAUDIT komutunun çalıştırılması için ise özel bir yetkiye gerek yoktur.

O7_DICTIONARY_ACCESSIBILITY parametresi FALSE ise denetim izleri yalnızca SYSDBA yekili kullanıcılar tarafında silinebilir. DELETE ANY TABLE yetkisine sahip kullanıcılar dahi silemezler.

Tüm denetim kayıtları herhangi bir transaction’ın tanımlanmasını beklemeden, denetlenecek komutun çalışma anında yazılır.

Komutların Denetlenmesi

Komut bazında denetleme yapılması, kullancıların çalıştırdığı,

  • DML(INSERT, UPDATE, DELETE, SELECT)
  • DDL(CREATE, DROP….)

gibi veritabanı komutlarının denetlenmesi işlemidir. Denetleme yaparken denetleyeceğimiz obje türünü girmemiz yeterlidir. AUDIT komutunda yazdığınız obje türüne türüne göre istenilen komutlar denetlenir. Obje türüne göre denetleyebileceğimiz komutlar aşağıdaki gibidir.

Oracle Audit System

 

 

 

 

 

 

 

Bu tür komut bazlı denetlemeyi başlatmak için AUDIT SYSTEM yetkisine sahip olunması gerekir. (dba_sys_privs viewi sorgulanarak yetki sahipleri bulunabilir) Komut bazında denetleme yeni session açıldığında aktif olur.

Örneğin tablo objesi DELETE komutunun tüm veritabanında denetlenmesi için aşağıdaki komutu çalıştırabiliriz.

audit delete table by access;

Yada sadece SYSTEM kullanıcısında çalıştırılan SELECT TABLE komutunu denetlemek istersek aşağıdaki komutu çalıştırabiliriz.

audit select table by system;

Verilen audit leri görmek için DBA_STMT_AUDIT_OPTS viewini sorgulayabiliriz.

Oracle Audit Privilege

 

 

Yukarıdaki resimdede görüldüğü gibi;

  • SYSTEM kullanıcısında çalışan tüm SELECT TABLE komutları
  • SYSTEM kullanıcısının çalıştırdığı tüm komutların
  • EXEMPT ACCESS POLICY yetkisini veren GRANT komutlarının
  • Bütün kullanıcılarda olmak üzere DELETE TABLE komutlarının denetlendiğini görmekteyiz.

(devamı..)

7,954 total views, no views today


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress
    Takip Et

    Her yeni yazı için posta kutunuza gönderim alın.

    Diğer takipçilere katılın: