Mustafa Bektaş Tepe

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.

(continue reading…)

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

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

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;

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.

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

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

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

Weblogic, Admin Console için lokal kullanıcılara ait şifre bilgilerini lokal LDAP yapısı içerisinde tutmaktadır. Console üzerinde yeni bir kullanıcı oluşturduğunuzda bu kullanıcı Weblogic’e gömülü LDAP üzerinde saklanmaktadır ve bu LDAP yapısı üzerinden yönetilmektedir.
Weblogic yönetim panellerine ait domain’in sahibi bir ana kullanıcı bulunmaktadır. Genellikle de bu kullanıcının varsayılan ismi ‘weblogic’ olarak verilmektedir. Farklı nedenlerden dolayı bu kullanının şifresini değişitirmek isteyebilirsiniz. Ya da bu kullanıcının şifresini resetlemek de isteyebilirsiniz. Bu tür durumlarda aşağıdaki yol haritasını izleyerek şifre değişikliği işlemini başarıyla gerçekleştirebilirsiniz.

1. ‘Middleware home’ ve ‘Domain home’ değişkenleri aşağıdaki gibi export edilmelidir;

export MW_HOME=/u01/app/oracle/middleware 
export DOMAIN_HOME==/u01/app/oracle/domain/test

2. Weblogic Admin Console’u kapatırız.

$DOMAIN_HOME/bin/stopWebLogic.sh

3. Data dizininin yedeğini alırız.

mv $DOMAIN_HOME/servers/AdminServer/data $DOMAIN_HOME/servers/AdminServer/data-old

4. Ortam değişkenleri aşağıdaki script yardımıyla set edilmelidir;

. $DOMAIN_HOME/bin/setDomainEnv.sh

5. Admin server altındaki ‘security’ dizini altında ‘DefaultAuthenticatorInit.ldift’ dosyasının yedeği alınmalıdır;

cd $DOMAIN_HOME/security
mv DefaultAuthenticatorInit.ldift DefaultAuthenticatorInit.ldift_backup

6. Aşağıdaki komut yardımıyla yeni şifre belirlenmelidir. Burada varsayılan domain sahibi kullanıcının ‘weblogic’ olduğu düşünülerek yazılmıştır. yeni şifre yazıldıktan sonra bir boşluk ve nokta karakteri unutulmamalıdır. Bu komut koşturulduktan sonra yeni ldift dosyası oluşacaktır.

cd $DOMAIN_HOME/security
java weblogic.security.utils.AdminAccount weblogic yeni_sifre .

7. Eğer boot.properties dosyası daha önceden set edilmişse ve kullanılıyorsa bu dosya içerisinde de yeni kullanıcı adı ve şifre yedeği alındıktan sonra güncellenmelidir;

$DOMAIN_HOME/servers/AdminServer/security
cp boot.properties boot_old.properties
cat boot.properties
username=weblogic
password= yeni_sifre

8. Son adım olarak domain varsayılan start komutu yardımıyla ayağa kaldırılarak yeni kullanıcı adı ve şifre ile login olunabilir;

$DOMAIN_HOME
nohup ./startWebLogic.sh >> startWebLogic.out &
tail -f startWebLogic.out

Hata oluşma ihtimali mevcut ve hata oluşması durumunda en azından yeni yapı çalışmıyor olsa bile eskiye geri dönebiliyor olmamız gerekir. Eğer bir hata ile karşılaşılırsa aldığımız backup dosyalarına geri dönülerek domain değişiklik öncesi hali ile çalıştırılabilir.

Mustafa Bektaş Tepe

İyi Çalışmalar