WLSDM ile WebLogic ve Datasource Şifrelerinin Şifresini Çözme / Şifreleme (Decrypt/Encrypt)

WLSDM ile weblogic admin console kullanıcı adı ve şifresini veya data source ların şifrelerini encyrpt halden çözebiliriz.

Bu işleme admin console kullanıcı adını veya şifresinin unuttuğumuz durumlarda veya data source larımızı başka bir domaine taşıdığımız zaman ihtiyaç duyarız.

Şimdi bir örnekle hash li kullanıcı adımızı ve şifremizi çözecek olursak;

  • Öncelikle wlst’i çalıştırırız bunun için $WL_HOME/oracle_common/common/bin dizinine gidip wlst.sh dizinini çalıştırırız.

NOT : MiddlewareHome dizininin nasıl bulacağımıza geçmeden önce kısaca weblogic’deki directory yapısından bahsetmek istiyorum.

  • MW_HOME : Bu değişken ve ilgili dizin yolu, Oracle Fusion Middleware’in bulunduğu konumu belirtir. Bir MW_HOME’da bir WL_HOME, bir ORACLE_COMMON_HOME ve bir veya daha fazla ORACLE_HOME var.
  • WL_HOME: Bu değişken ve ilgili dizin yolu, bir WebLogic Sunucusunu barındırmak için gereken yüklü dosyaları içerir, örneğin .MW_HOME/wlserver_10.3
  • ORACLE_HOME: Bu değişken, Oracle HTTP Sunucusu, Oracle SOA Suite veya Oracle Internet Directory gibi bir Oracle Fusion Middleware ürününün kurulu olduğu ve o ürünün binary’lerinin güncel bir prosedürde kullanıldığı yere işaret eder. Örneğin: MW_HOME/iam
  • ORACLE_COMMON_HOME: Bu değişken ve ilgili dizin yolu, Oracle Fusion Middleware Ortak Java Required Files (JRF) Kütüphanelerinin ve Oracle Fusion Middleware Enterprise Manager kütüphanelerinin kurulu olduğu yere işaret eder. Örnek: MW_HOME/oracle_common

Bende MW_HOME dizinimi bulmak için WL_HOME değişkenini kullanacağım. WL_HOME’u bulmak için çalışan bir JVM’niz varsa aşağıdaki komutu kullanarak WLS_HOME’u buluruz buradan da WL_HOME ‘u buluruz ve daha sonrasında MW_HOME’u buluruz;

ps -eaf|grep -i AdminServer| fmt |grep -i "\-Dweblogic.home" --color
-Dweblogic.home=/oracle/product/Middleware12.1.3/wlserver/server

Yukarıdaki WLS_HOME’dan anlıyorum ki benim WL_HOME’um aşağıdaki gibi (WLS_HOME ile WL_HOME aynı şeyler değildir, WL_HOME dizini WLS_HOME dizininin bir altındaki dizindir);

-Dweblogic.home=/oracle/product/Middleware12.1.3/wlserver

WL_HOME danda MW_HOME dizinini buluyorum;

 -Dweblogic.home=/oracle/product/Middleware12.1.3 

Eğer çalışan bir JVM’niz yoksa ikinci bir yöntem ise weblogic.jar dosyasını aratarak MW_HOME dizinini bulabiliriz.

find /oracle -name "weblogic.jar"| sed 's/\/server\/lib\/weblogic.jar//g'
./product/Middleware12.1.3
  • Tamamdır artık $WL_HOME/oracle_common/common/bin dizinine gidip, wlst.sh dizinini çalıştırabiliriz.

(devamı..)

Loading


Weblogic’de Client IP adresini Görme (X-Forwarded-For)

Internet erişimlerinde bir proxy sunucusu kullanıldığı durumlarda, hedef web sunucusu orjinal isteği yapan kullanıcıya ait gerçek IP adresini göremez. Bunun yerine proxy cihazının IP adresi hedef sisteme bağlanıyor olarak gözükecektir.

Günümüz web uygulamaları birden fazla uygulama sunucusu ve veri tabanı sistemleri üzerinde çalışır. Temel anlamda tamamiyle aynı kaynak kodu paylaşan iki adet uygulama sunucusu düşünün. Kullanıcıdan gelen istekler, yük durumuna göre bu iki sunucudan herhangi birisi tarafından karşılanmak üzere hazırdır. Hangi talebin hangi uygulama sunucusuna aktarılacağının kararını, HTTP taleplerini uygulama sunucularının önünde karşılayan yük dengeleyici -load balancer- mekanizma yapar. Buda bizi, probleme sürükler. Kullanıcının gerçek IP adresi nedir ?

Proxy kelime olarak vekil sunucu anlamına gelir. Yani iki sistem arasındaki iletişimi taşımaktan sorumlu vekillerdir. Yukarıdaki resme bakıldığında da vekil(proxy) görevini load balancer’ın yüklendiği görülmektedir. Yani hem kullanıcı hemde uygulama sunucusu ile konuşan tek bir sistem mevcuttur. Ağ trafiği anlamında baktığımızda da web1 veya web2 sunucuları her zaman load balancer’ın IP adresi ile konuşmaktadır. Aynı durum kullanıcılar içinde geçerlidir pek tabi.

Proxy  sunucular  X-Forwarded-For HTTP başlığını, web isteğini yapan istemciye ait gerçek IP adresinin hedef sunucuya  iletmek için kullanmaktadırlar. Bu başlık RFC’lerde geçen bir standart olmamasına rağmen, genel kabul görmüş bir standarttır. İlk olarak Squid proxy geliştiricileri  tarafından  implemente  edilen  bu  başlık,  diğer  bir  çok  proxy  cihazında  da kullanılmaktadır. X-Forwarded-For HTTP başlığından kısaca XFF olarak da bahsedilmektedir.Bazı  cache  ve  proxy  cihazları  ise  X-Request-Client-IP,    X-Client-IP  HTTP  başlıklarını kullanmaktadırlar.

Yukarıdaki şekilde proxy sunucularının istemcilerin yaptığı web isteklerine “X-Forwarded-For: kullanıcının_ip_adresi” şeklinde bir satır eklemesinin detayı görülebilir. Bu sayede şekildeki proxy  sunucusu,  hedef  web  sunucusuna  bu  HTTP  isteğini  yapan  gerçek  istemciyi iletmektedir.X-Forwarded-For nerelerde kullanılır?X-Forwarded-For  (XFF)  HTTP  başlığı genelde log’lama amacıyla kullanılmaktadır. Bu şekilde siteyi ziyaret eden gerçek kullanıcının IP adresi log kayıtlarına aktarılmaya çalışılır. Bu kayıtlar, oluşan bir olay sonrası inceleme amaçlı kullanılabildiği gibi, web erişim log’larını analiz eden yazılımlar tarafından da kullanılabilir.

Weblogic Uygulama sunucularında X-Forwarded-For Enable Edilmesi

X-Forwarded-For ‘a değindikten sonra asıl amacımız olaran weblogic sunucularında gerçek client ip’yi nasıl görebiliriz ona odaklanalım;

Öncelikle bizim ortamda bulunan f5 tarafında yapmamız gereken bir takım değişiklikler var, yaptığımız bu değişiklik http header’ına X-Forwarded-For  diye yeni bir alan ekleyip bu alanın karşısınada gerçek kullanıcının ip’sini ekleyecektir. Bu konu f5’in konusu olduğu için bu konu ile ilgili detayları linkten görebilirsiniz.

Burada iki tane önemli gördüğüm konuda not düşmek istiyorum;

NOT 1 : Client X-Forwarded-For değeri manipule edebilir, mesela mozzilladaki bir plugin ile çok basit şekilde var olanın dışında bir ip’yi gönderebilir, bu tarz manipulasyonu önlemek için f5’e kural yazıp gelen X-Forwarded-For değerini en başta sildirip sonra source ip’sini X-Forwarded-For’a atayabiliriz. Kısaca aşağıdaki gibi bir kural;

when HTTP_REQUEST {
HTTP::header remove X-Forwarded-For    
HTTP::header insert X-Forwarded-For [IP::remote_addr]
}

NOT 2 : Genelde X-Forwarded-For konusunda sistemciler ve orta katmancılar ortak çalışırlar, sistemciler f5 gibi load balancer/proxy konfigurasyonunu halleder, orta katmancılar weblogic gibi uygulama sunucu kısmını halleder, işte bu noktada şöyle sıkıntılar olabiliyor; sistemciler ben sana X-Forwarded-For gönderdim sen yanlış konfigurasyon yapmışsın yada tam tersi orta katmancılar sen X-Forwarded-For göndermiyorsun yanlış konfigure yapmışsın gibisine sistemcileri suçlayabiliyor işte bunun önüne geçmek için X-Forwarded-For değerinin gelip gelmediğini tcpdump veya wireshark gibi bir araçla kontrol etmek işlerimizi kolaylaştıracaktır. Mesela aşağıda örnek bir sorgulama ve sonucu görebilirsiniz.

tcpdump -i bond1 -A -s 10240 | grep -v IP | egrep --line-buffered "..(GET |\.HTTP\/|POST |HEAD )|^[A-Za-z0-9-]+: " |sed -r 's/..(GET |HTTP\/|POST |HEAD )/\n\n\1/g'
HTTP/1.1^M
Content-Type: application/x-www-form-urlencoded^M
Cache-Control: no-cache^M
Pragma: no-cache^M
User-Agent: Java/1.8.0_141^M
Host: sbbups.dtm.gov.tr^M
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2^M
Connection: keep-alive^M
Content-Length: 166^M
Cookie: JSESSIONID=xxxxxxxxxxxxxxxxxxxxxxxxxxx;
JSESSIONID=xxxxxxxxxxxxxxxxxxxxxxxxxxx;
X-Forwarded-For: 188.149.xxx.xxx^M

Gelelim ikinci adım olan weblogic kısmında yapacaklarımıza;

  • Admin Console’a giriş yapalım (http://server:port/console)
  • “Environment > Servers > My Server > Logging > HTTP” seçerek ilerleyelim,
  • Daha sonra “Lock & Edit” seçelim,
  • “HTTP access log file enabled” checkbox’ını seçelim,
  • “Advanced” diyerek seçenekleri genişletelim,
  • Formatı “Extended” olarak seçelim
  • Daha sonra “Extended Logging Format” kutusuna “cs(X-Forwarded-For)” parametresini ekleyelim
  • Daha sonra “Log File Buffer” seçeneğini 0 olarak ayarlayalım böylece loglar direk yazılır,
  • Sonra “Save” yapalım,
  • Sonrasında “Activate Changes” i seçeriz
  • Son olarak değişiklik yaptığmız manager serverı kapatıp açarız.

NOT : Burada “Extended Logging Format” kısmından access.log’umuza yazılacak logu istediğimiz gibi güncelleyebiliriz.Yandaki linkten bütün detayları linkten görebilirsiniz. Ben ayarı aşağıdaki yapıyorum bu arada.

 

date time cs-method cs-uri sc-status cs(user-agent) c-ip time-taken bytes cs(X-Forwarded-For)

Mustafa Bektaş Tepe
İyi Çalışmalar

Referanslar;

https://psadmin.io/2016/11/24/load-balancers-and-client-ip-addresses/
https://www.mehmetince.net/yuk-dengeleyiciler-ve-gercek-ip-adresi-karmasasi/
https://docs.oracle.com/middleware/1221/wls/CNFGD/web_server.htm#CNFGD207

Loading


Oracle Database Security Assessment Tool (DBSAT)


Database Security Assessment tool / Veritabanı Güvenliği Değerlendirme Aracı (DBSAT), yaygın veritabanı güvenliği sorunlarını kontrol etmenize yardımcı olacak bir yardımcı program olarak Oracle tarafından sağlanmaktadır.
DBSAT ile, kısa vadeli güvenlik risklerini ortadan kaldırmak ve kapsamlı bir güvenlik stratejisi uygulamak için gerekli bulguları raporlayabilirsiniz. Oracle support’dan “Doc ID 2138254.1” dökümanı ile indirebiliriz.
DBSAT aracı üç modül içerir:

  • Collector : Erişim sağlanan sistemden , sql cümlecikleri ve işletim sistemi komutlarının çalıştırılması suretiyle veri toplar. Bunu öncelikle data dictionary viewlerı sorgulayarak yapar. Toplanan veri , DBSAT Reporter tarafından analiz aşamasında kullanılmak üzere bir JSON dosyaya yazılır.
  • Reporter  : Toplanan verileri analiz eder ve HTML, Excel, JSON veya txt formatlarından bir veritabanı güvenliği değerlendirme raporu oluşturur.
  • Discoverer : Mantıklı verileri bulmak ve raporlamak için kullanılan tek başına bir modüldür. Database Sensitive Data Assessment report / Veritabanına Duyarlı Veri Değerlendirme raporunu hazırlar.

Ayrıca DBSAT birkaç tamamlayıcı yardımcı program içerir (Reporter JSON çıkış formatı), bunlar:

  • DBSAT Extract – Bulguları kimlikleriyle çıkarmanızı sağlayan Python programı
  • DBSAT Diff – İki raporu karşılaştırmanıza ve farkları bulmanıza olanak sağlayan Python programı

Yukarıdaki DBSAT tamamlayıcı modüllerini, DBSAT aracını indirmek için kullandığınız aynı My Oracle Support dökümanından indirebilirsiniz [Doc ID 2138254.1]

DBSAT Kullanmak İçin Gereken Önşartlar

  • DBSAT’ın yalnızca aşağıdaki işletim sistemlerinde çalıştırılmak üzere onaylandığını unutmayın:
    • Solaris x64 and Solaris SPARC64
    • Linux x86-64
    • Windows x64
    • HP-UX IA (64-bit)
    • IBM AIX (64-bit) & Linux on zSeries (64-bit)
  • DBSAT aracını herhangi bir Oracle Database 10.2.0.5 veya sonraki sürümlerinde çalıştırabilir
  • Zip, unzip ve python yazılımının sunucuya kurulması gerekir. Aşağıdaki komutu vererek bunları kolayca yükleyebilirsiniz:
yum install -y zip unzip python

(devamı..)

Loading


Network File System (NFS)

NFS  (Network  File  System),  1984  yılında  Sun  Microsystems  tarafından  geliştirilmişbir protokoldür. Uzaktaki makine üzerinde bulunan dosya sistem(lerin)i, farklı bir işletim sistemine  bağlayabilmeniz  (mount)  için  geliştirilmiştir.  Ve  bunu  yaparken,  kullanıcının sanki yerel bir dosya sistemi üzerindeymiş gibi çalışmasını sağlar.

TCP / IP’nin evriminin başlarında, kullanıcının ağ üzerinden başka bir makineye erişmesine izin vermek için bazı araçlar oluşturulmuştu. Telnet gibi remote access protocols (uzaktan erişim protolleri), kullanıcının başka bir bilgisayarda oturum açmasına ve buradaki kaynakları kullanmasına izin verdi. File Transfer Protocol  (FTP), birinin uzak bir makineden bir dosyayı kendi dosyasına kopyalamasına ve düzenlemesine izin verdi.

Ancak, bu çözümlerin hiçbiri, bir kullanıcının uzak bir makinedeki bir dosyaya, yerel bir dosyanın kullanıldığına benzer bir şekilde erişmesine izin verme kurallarına uymuyordu. Sun bu ihtiyacı karşılamak için Network File System (Ağ Dosya Sistemi)’i (NFS) yarattı. NFS, yerel ve uzak bir dosya arasındaki ayrımı ortadan kaldırmak amacıyla özel olarak tasarlanmıştır. Bir kullanıcı için, uygun kurulum yapıldıktan sonra, uzak bilgisayardaki bir dosya, kullanıcının yerel bilgisayarındaki bir sabit disk üzerindeymiş gibi kullanılabilir. Sun ayrıca, hem Sun tarafından hem de diğer şirketler tarafından yapılan donanımların birlikte çalışabilmesini sağlamak için NFS’yi özellikle satıcıdan/üreticiden bağımsız olacak şekilde üretti.

NFS, klasik TCP / IP client/server modelini izler. Bir sabit disk veya belirli bir bilgisayarın depolama aygıtındaki dizin, yönetici tarafından paylaşılan bir kaynak olarak ayarlanabilir. Bu kaynağa daha sonra paylaşılan sürücü(shared drive) veya directory denir ve client makinede yerel bir dizin gibi görünmesini sağlayarak bilgisayarlardan erişilebiliriz.

NFS, çalışmasını tanımlayan üç ana bileşen içeren bir mimari kullanır. External Data Representation (XDR) standardı, verilerin client ve server arasındaki değişimlerde nasıl temsil edildiğini tanımlar. Remote Procedure Call (RPC) protokolü, uzak makinelerde procedure çağırma yöntemi olarak kullanılır. Ardından, bir dizi NFS prosedürü ve işlemi çeşitli istekleri yerine getirmek için RPC kullanarak çalışır. Mount protokolü, kaynakları yukarıda belirtildiği gibi bağlamak için kullanılır.

NFS’nin en önemli tasarım hedeflerinden biri performanstı. Açıkçası, uzaktaki bir makineye yerelmiş gibi bir dosya ayarlasanız bile, gerçek okuma ve yazma işlemleri bir ağ üzerinde ilerlemek zorunda. Genellikle bu sadece bir bilgisayar içerisine veri göndermekten daha fazla zaman alır, bu yüzden protokolün kendisinin mümkün olduğunca “yalın ve ortalama” olması gerekiyordu. Bu karar, çoğu dosya aktarım protokolünün yaptığı gibi güvenilir TCP yerine TCP / IP’de aktarım için güvenilir olmayan User Datagram Protocol’nün (UDP) kullanılması gibi bazı ilginç kararlara yol açmıştır. Bu da protokolün bir bütün olarak nasıl çalıştığı üzerinde ilginç sonuçlara sahiptir.

NFS için bir diğer önemli tasarım amacı basitti (elbette performansla ilgili). NFS sunucularının durumsuz olduğu söyleniyor, bu protokolün hangi sunucuların hangi clientler tarafından hangi dosyaların açıldığını takip etmesine gerek kalmayacak şekilde tasarlandığı anlamına geliyor. Bu, isteklerin birbirinden bağımsız olarak yapılmasına izin verir ve bir sunucunun karmaşık kurtarma prosedürlerine ihtiyaç duymadan çökmeler gibi olaylarla incelikle başa çıkmasını sağlar. Protokol ayrıca, isteklerin kaybolması veya çoğaltılması durumunda dosya bozulması yaşanmayacak şekilde tasarlanmıştır.
(devamı..)

Loading


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ı..)

Loading


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

Loading


  • Sertifikasyon



  • Etiketler

  • Topluluklar

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