Install weblogic 9.2
Installed under
/usr/local/bea
Admin console:
http://localhost:7001/console
Start / stop
By default weblogic
comes with some preinstalled examples:
/usr/local/bea/weblogic92/samples/domains/wl_server
To start/stop a
weblogic domain:
bin/startWebLogic.sh
bin/stopWebLogic.sh
You can also stop
weblogic by killing the pid.
Also in the admin
console, environment, servers.
Quick start
/usr/local/bea/weblogic92/common/bin/quickstart.sh
Domains
Create domain
Create a new domain
with the configuration wizard
/usr/local/bea/weblogic92/common/bin/config.sh
create a new
domain
generate
automatically for weblogic server
username/password
weblogic/weblogic
development mode,
sun sdk 1.5
additional
configuration: yes
Adminserver
defaults: 7001
Add managed
server: name ms1, 7001
No clusters
No specific
machines
domain name
domain_oraxe, location /usr/local/bea/user_projects/domains
Delete a domain
Delete the directory
/usr/local/bea/user_projects/domains/<domain>
Configure
Configure wl92 for
xxx
Start administration
server for domain_oraxe
/usr/local/bea/user_projects/domains/domain_oraxe/bin/startWebLogic.sh
Jdbc
Jdbc - datasources
- new
name AuditTrail
jndi
AuditTrail.DataSource
type Oracle
driver Default
weblogic Oracle XA driver
connection pool
database xe
server localhost
username/password
xxx/xxx
test configuration
assign to
administration server
open properties
connection pool
maximum capacity
50
Save, activate
changes
Another datasource for
jms messages storage.
Make sure you do not
use a xa-enabled jdbc driver.
Jdbc - datasources
- new
oracleJmsStorageDS
oracleJmsStorageDS
Oracle bea type 4
(not xa)
Do not support
global transactions
Assign to
administration server
open properties
connection pool
maximum capacity
25
Save, activate
changes.
JMS Server
Services, Messaging,
jms server
Create new jms
server
Jms-server-0
New jdbc store
JDBCStore-Jms
AdminServer
oracleJmsStorageDS
prefix name jms
Persistent store -
JDBCStore-Jms
Target AdminServer
Jms Modules
Services,
Messaging, jms modules
New system module:
JmsModulexxx
default descriptor
and location
Target adminserver
Add resources: no
(doing later).
Save, activate.
Subdeployment
Add a subdeployment to the created jms module.
This will link the jms module to the jms server.
Edit
JmsModulexxx
Tab
subdeployments: New
Name JmsServer0
Target
Jms-Server-0
Save, activate
Queues and connectionfactory
Connection factory
xxxConnectionFactory,
jndi: xxxConnectionFactory
Advanced targets:
subdpeloyment JmsServer0
Edit
xxxConnectionFactory: Transactions: xa enabled
Save, activate
Queues
xxxApplicationQueue
xxxDaemonQueue
xxxSystemQueue
TestJMSQueue
All with same name
and jndi.
All with
subdeployment JmsServer0.
After creating
each queue, open its properties again and go to the delivery failure
tab; set redelivery delay override to 1000 and redelivery limit to
10.
Save, activate
Save configuration
Create template
/usr/local/bea/weblogic92/common/bin/config_builder.sh
Saves template under
/usr/local/bea/user_templates
Client setup
java.home must be
a jdk 1.5
Add
server/lib/weblogic.jar to the client's classpath.
It seems that wl92 does
not recognise a client's jndi.properties, so add jndi properties
hard-coded in a hash-table:
Hashtable
ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFactory");
ht.put(Context.PROVIDER_URL,
"t3://localhost:7001");
Context
ctx = new InitialContext(ht);
Setting up a different authentication provider
Ldap
In security realm,
myrealm, providers tab, authentication
Add a new openldap
provider.
Edit the properties
Name
openldap-provider
Control flag:
optional
Group base dn:
ou=groups, dc=de, dc=xxx, dc=ag, dc=test
User name
attribute: uid
Static group
object class: groupOfnames
Port: 389
User base dn:
ou=people, dc=de, dc=xxx, dc=ag, dc=test
User object class:
person
Static group name
attribute: cn
Principal:
cn=Manager, dc=de, dc=xxx, dc=ag, dc=test
Host: localhost
Credential:
carldap
Static Group DNs
from Member DN Filter: (&(member=%M)(objectclass=groupofnames))
Static Member DN
Attribute: member
User from name
filter: (&(uid=%u)(objectclass=person))
Group from name
filter: (&(cn=%g)(objectclass=groupofnames))
This is based on an
openldap with rootdn cn=Manager, dc=de, dc=xxx, dc=ag, dc=test and
password carldap.
To get this working,
load a ldif into ldap that contains following:
dn:
dc=de,dc=xxx,dc=ag,dc=test
objectclass:
top
objectclass:
dcObject
objectclass:
organization
dc:
de
o:
xxx
dn:
ou=People,dc=de,dc=xxx,dc=ag,dc=test
objectclass:
top
objectclass:
organizationalUnit
ou:
People
dn:
uid=weblogic,ou=People,dc=de,dc=xxx,dc=ag,dc=test
objectClass:
top
objectclass:
uidObject
objectclass:
person
sn:
Weblogic
cn:
Weblogic System Account
uid:
weblogic
userpassword:
weblogic
dn:
ou=Groups,dc=de,dc=xxx,dc=ag,dc=test
objectclass:
top
objectclass:
organizationalUnit
ou:
Groups
dn:
cn=Administrators,ou=Groups,dc=de,dc=xxx,dc=ag,dc=test
objectClass:
groupOfNames
objectClass:
top
cn:
Administrators
description:
Administrators group for weblogic
member:
uid=weblogic,ou=People,dc=de,dc=xxx,dc=ag,dc=test
That is, make sure you
have at least the admin weblogic user defined (the user you defined
when setting up the domain), and that this admin user belongs to a
group called Administrators.
When weblogic server
boots, it will read the file <domain>/servers/AdminServer/security/
boot.properties.If you
want to use a different user, make sure you adapt this file too.
To load the above file
(myldap.ldif)
/etc/init.d/ldap
stop && rm /var/lib/ldap/* && /etc/init.d/ldap start
ldapadd
-xv -D 'cn=Manager,dc=de,dc=xxx,dc=ag,dc=test' -w carldap -f
myldap.ldif
Test optional ldap authentication provider
We put the control flag
on OPTIONAL first. If configuration is not right, we should still be
able to login into the admin console.
The easiest is to add
an extra group to the ldif file, and make weblogic member of it:
dn:
cn=TestGroup,ou=Groups,dc=de,dc=xxx,dc=ag,dc=test
objectClass:
groupOfNames
objectClass:
top
cn:
TestGroup
description:
TestGroup for weblogic
member:
uid=weblogic,ou=People,dc=de,dc=xxx,dc=ag,dc=test
In the security realm
providers now add a audit provider that audits all security related
information. It will create a logfile under server/AdminServer/logs.
Now reboot the server.
In the audit log file
you can find the principals that get assigned to a successful login.
If all is well, you should also see a principal TestGroup now ( the
Administrators principal was already created by the default
authentication).
If you do not see then
you will need to debug the ldap connection. If all is well, you can
set the ldap authentication provider to required and the default to
optional.
Debug ldap problems
Under environment,
servers, adminserver you can set debugs.
Set debugs for
weblogic.security.adjudicator
weblogic.security.atn
weblogic.security.atz
weblogic.security.rolemap
debug security
This is the same as
adding a section to the config/config.xml file:
<server>
<name>AdminServer</name>
<server-debug>
<debug-scope>
<name>weblogic.security.adjudicator</name>
<enabled>true</enabled>
</debug-scope>
<debug-scope>
<name>weblogic.security.atn</name>
<enabled>true</enabled>
</debug-scope>
<debug-scope>
<name>weblogic.security.atz</name>
<enabled>true</enabled>
</debug-scope>
<debug-scope>
<name>weblogic.security.rolemap</name>
<enabled>true</enabled>
</debug-scope>
<debug-security>true</debug-security>
</server-debug>
<listen-address></listen-address>
</server>
Now restart the server,
and you will find a ldap trace file and extensive log files.
Deploying xxx
Settings for weblogic 92
Client:
<wsp>/lib:
weblogic.jar
<wsp>/etc/xxx.properties
JNDI.InitialContextFactory
= weblogic.jndi.WLInitialContextFactory
JNDI.URL
= t3://localhost:7001
JNDI.User
= weblogic
JNDI.Password
= weblogic
JNDI.PackagePrefixes
= -
Server:
xxx-engine.jar/xxx.properties
EJB.ServerVendor
= WEBLOGIC
JMS.MessageListener.ProcessingFailure.Pause
= 1000
Client.ServiceFactory
= ag.xxx.workflow.ejb.EjbEnvServiceFactory
Settings for weblogic 92 with ldap
Client:
<wsp>/lib:
weblogic.jar
weblogic-auth.jar
(this jar holds the xxx specific weblogic authentication classes
from xxx_HOME/examples/weblogic-auth)
<wsp>/etc/xxx.properties
JNDI.InitialContextFactory
= weblogic.jndi.WLInitialContextFactory
JNDI.URL
= t3://localhost:7001
JNDI.User
= weblogic
JNDI.Password
= weblogic
JNDI.PackagePrefixes
= -
Credential.Provider
=
Secure.Session.Factory
=
ag.xxx.examples.authentication.weblogic.WeblogicSecureSessionFactory
Security.Authentication.ConfigurationName
=
server
xxx.ear/ldap-sync.jar
(from xxx_HOME/examples/ldap-sync)
xxx.ear/xxx-engine.jar/xxx.properties
EJB.ServerVendor
= WEBLOGIC
JMS.MessageListener.ProcessingFailure.Pause
= 1000
Security.Authentication.Mode
= principal
Security.Authorization.SynchronizationProvider
= ag.xxx.examples.authorization.ldap.LDAPSynchronizationProvider
LDAPSynchronization.ServerName
= localhost
LDAPSynchronization.ServerPort
= 389
LDAPSynchronization.RootDN
= dc=de,dc=xxx,dc=ag,dc=test
LDAPSynchronization.UserFilter
= (&(uid=%v)(objectclass=inetOrgPerson))
LDAPSynchronization.ParticipantFilter
=
(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=%v,ou=People,dc=de,dc=xxx,dc=ag,dc=test))
Client.ServiceFactory
= ag.xxx.workflow.ejb.EjbEnvServiceFactory
Problem with cleanup runtime / synchronization
caches
Currently some tests fail as the synchronization
between ldap and audittrail occurs too late. Timerbasedstrategy is
set at 10s.
If your run a cleanup, but cache is still there,
the engine might think audittrail is uptodate, where in fact it is
empty.
Comments