Generating packed template from Weblogic Admin Server Dynamically fails - weblogic

I have a weblogic domain (i.e. server1) that manages multiple managed servers (i.e. server2) on remote machines on which the admin server does not reside. I am trying to use WLST in online mode to dynamically pack the domain on the Admin Server into a JAR and transfer it to the managed server, but it fails due to CIE ConfigHelper service not being availble. I've tried to find a reference to this service with no lunck.
Here is the log of the output:
Initializing WebLogic Scripting Tool (WLST) ...
Welcome to WebLogic Server Administration Scripting Shell
Type help() for help on available commands
Connecting to t3://admin:7001 with userid admin ...
Successfully connected to Admin Server "wladmin_server" that belongs to domain "qa".
Warning: An insecure protocol was used to connect to the
server. To ensure on-the-wire security, the SSL port or
Admin port should be used instead.
Location changed to serverRuntime tree. This is a read-only tree with DomainMBean as the root.
For more help, use help('domainConfig')
CIE ConfigHelper online service is not available.
Disconnected from weblogic server: wladmin_server
I'm doing this based on the following link https://docs.oracle.com/middleware/1212/wls/WLSTG/domains.htm#WLSTG406 , but it just doesn't seem to work.
I am using Weblogic 12c (12.1.3) running on RH Linux.
Thanks.

pack and unpack scripts are working for us in similar scenario.
On admin server machine where domain is already created ,You can use this to pack/create managed server template :
$WL_HOME/common/bin/pack.sh -domain=${DOMAIN_HOME} \
-template=${DOMAIN_NAME}_managed_template.jar \
-template_name="${DOMAIN_NAME}" \
-template_author="YOU" \
-template_desc="${DOMAIN_NAME}-managed-template" \
-managed="true" \
-log=logs/pack_managed_${DOMAIN_NAME}.log
Then copy managed server template to different machines and unpack there:
$WL_HOME/common/bin/unpack.sh \
-domain=$DOMAIN_HOME \
-template=${DOMAIN_NAME}_managed_template.jar \
-overwrite_domain="true" \
-app_dir=$DOMAIN_HOME/../applications \
-log=logs/${DOMAIN_NAME}_creation.log

I have also encountered the same problem on my weblogic (ver 12.1.3). The problem seems to appear only when the weblogic server is started using wlst.
When I started the weblogic using startWeblogic.sh file and run the domain template wlst script the error(CIE ConfigHelper online service is not available.) has disappeared, and I can see that the template is created successfully.
It seems like a bug in weblogic wlst.

Related

Webseal runtime component configuration

Hello
i am working on the IBM webseal authentication. i want to implement the webseal authentication into my application.
while configuring the runtime component i am getting the following error.
Unable to verify the management domain location DN in the
LDAP server: (secAuthority=Default).
If the location does not exist on the server, create it,
otherwise specify a different location that does exist.
Error: DPWAP0003I An error occurred while executing the command: /opt/PolicyDirector/sbin/PDMgr_config -s TRUE -y no -v TRUE -d CN=jony mittal,OU=dev,DC=dgad,DC=com -w XXXX -L 389 -C fips -D Default -m XXXX -l 1460 (0x1)
anyone please help me to resolve this issue.
thanks
When you are configuring ISAM/ISVA PD runtime, PDMgr_config will deploy its registry into your LDAP directory server. This requires modifying the schema of the LDAP server. To do this, it requires administrator rights on the directory. Commonly this will be an account such as cn=root, cn=admin, cn=DM, etc. depending on your directory server.
I believe what may work better for you, if you are configuring ISAM from scratch, is likely deploy using the internal/embedded LDAP. When configuring the runtime choose the local LDAP server option. You can set the credentials on the local/embedded LDAP server on the tab where you configure the runtime. Just set a password on it, then feed that password into the runtime configuration.
Then, if you are needing to tie into another directory, which I expect is the case since you are trying to do this now, then use basic user mode with a "federated registry" so you don't have to deploy the ISAM "registry" and hence do not have to modify the existing directory. This way you can authenticate and authorize users off an existing directory without having to modify that directory specifically to support ISAM.
Additional information here:
Embedded (local) LDAP server instructions
Configuring PD runtime
Basic user mode instructions
Setup federated repository

Weblogic server won’t start, because a bad.jar was deployed in it. But I can’t start the admin console, in order to remove the .jar

My Weblogic server was running fine inside my Eclipse. But then I accidentally deployed an .ear into my Weblogic server (using the server's Admin Console) which conflicts with another .ear, and now my Weblogic server won't start up. I know how to remove the .ear. The way to remove it is to go to the Admin Console, choose Deployments, checkmark the offending .ear and then choose stop and delete. But I can't get to the Admin Console because the Weblogic server won't start up.
I want to undeploy it, but I can't, because I can't start up the Admin Console. I also tried undeploying it with the command line, but the command requires communicating with a running server.
The error message in the Eclipse console says: "Failed to initialize the application 'EILoggingSharedLib [LibSpecVersion=2.22,LibImplVersion=2.22]" due to error weblogic.application.library.LibraryDeploymentException: [J2EE:160145]Failed to deploy library Extension-Name: EILoggingSharedLib, Specification-Version: 2.9, Implementation-Version: 2.9, because of conflicting library Manifest values, and library information registered with the server: [Specification-Version: 2.9 vs. 2.22, Implementation-Version: 2.9 vs. 2.22]. Check the library MANIFEST.MF file and correct version information there to match server settings, or undeploy the misconfigured library."
This is the command line command I used:
C:\bea12c\wlserver\server\lib>java -cp weblogic.jar weblogic.Deployer -verbose -noexit -adminurl http://localhost:7016 -username (myusername) -password (mypassword) -name Dev12c -undeploy EILoggingSharedLib -timeout 300
weblogic.Deployer invoked with options: -verbose -noexit -adminurl http://localhost:7016 -username weblogic -name Dev12c -undeploy EILoggingSharedLib -timeout 300
Unexpected Error Initializing Deployer: weblogic.Deployer$DeployerException: weblogic.deploy.api.tools.deployer.DeployerException: Unable to connect to 'http://localhost:7016': Destination 0:0:0:0:0:0:0:1, 7016 unreachable; nested exception is:
java.net.ConnectException: Could not connect to /0:0:0:0:0:0:0:1; No available router to destination. Ensure the url represents a running admin server and that the credentials are correct. If using http protocol, tunneling must be enabled on the admin server.
I also tried starting the server with startweblogic.sh with the following command, using the same ID and password that I use to log into the admin console (when it was running). But it didn't help:
startweblogic.sh username=(myusername) password=(mypassword)
Thank you!
First, try to remove your application from deployed applications with Eclipse. If it does not work, edit the ${DOMAIN_HOME}/config/config.xml file and remove the declaration of your application. Then start your server.
I found a solution. My Weblogic server that had the problem was at http://localhost:7016. Since it's a localhost server, all the libraries and apps deployed to that localhost are in a directory in my C: drive where my Weblogic server installation is. I deleted the offending .ear using File Explorer, then the Weblogic server started up fine. I was able to go into the Admin Console and delete them again from there. After that, all was good. Thank you, Emmanuel and Wesley.

How to Test DataSource connection in JBoss EAP 6.2 Managed Domain

I am trying to port an application from WebLogic to JBoss EAP 6.2.
When running the standalone server in JBoss, in the admin console there is a button and in the command line interface there is a command line option to check the data source connection.
/subsystem=datasources/data-source=myds:test-connection-in-pool
These options do not appear to exist in either place when running the "domain" server. Am I missing something? Is there some further setting I must make to enable it? I tried a technique which is sometimes an analog in the domain server and it doesn't work here.
/profile=full/subsystem=datasources/data-source=myds:test-connection-in-pool
JBoss docs are much weaker for "domain" model than for "standalone".
You are absolutely correct that while running the standalone server in JBoss, in the admin console there is a button and in the command line interface there is a command line option to check the data source connection butThese options do not appear to exist in either place when running the "domain" server.
You still can use the command line of jboss-eap-6.x to test the configured data source connection in domain server. You need to navigate to $JBOSS_HOME/bin/ and execute script: jboss-cli.sh
Connect to the domain server controller with: connect :PORT_NO and execute the following commands:
For XA-DataSource:
/host=$Host_Controller_Name/server=$Server_Name/subsystem=datasources/xa-data-source=DataSource_JNDI_Name:test-connection-in-pool
For Non-XA-DataSource:
/host=$Host_Controller_Name/server=$Server_Name/subsystem=datasources/data-source=DataSource_JNDI_Name:test-connection-in-pool

Why is WLST not recognizing the user/password in the key and config file in connect() call?

I'm trying to connect to an admin server in WLST using config and key files. There are no error messages but I am prompted for a username and password. These files were created (by another developer who is long gone[1]) with the storeUserConfig() command. My call to connect looks something like this: connect(userConfigFile=configFile, userKeyFile=keyFile, url='t3://somehost:7031')).
Is there some restriction in using these files, such as it can only be used on the host where created, or it needs access to the domain's boot.properties file?
Note: I'm trying to connect to an admin server on a different host and non-standard port (e.g. not 7001). The server I am running WLST on and the remote host are the same version of Weblogic.
Some of the things I have tried:
verified that these files appear correct, the key file being binary data and the config file having a line for "weblogic.management.username={AES}..." and "weblogic.management.password={AES}...".
verified that there is a server on the specified port by entering a known login and password that is successful
specified the admin server in the connect parameter
turn on debug(true); the only output is <wlst-debug> connect : Will check if userConfig and userKeyFile should be used to connect to the server and another line giving the path to the userConfig file
turn on Python logging in jython with -Dpython.verbose=debug; nothing relevant to decryption operation
Munging the key or the config files generates no error messages and behaviour as above
[1]: These files are still used today by other existing WLST scripts. However, these scripts are so convoluted and deliberately obfuscated that they are very difficult to reverse-engineer how connect() is being called.
You do not need to access to the domain's boot.properties file. You just need to make sure the configFile and keyFile pointing to the right files. FYI, here is one of the commands we are using:connect(userConfigFile='./user.secure',userKeyFile='./key.secure',url='t3://somehost:7001')
Have you check the network connectity that might be having a firewall in between that troubling you, check the traceroute from the script machine to the Remote machine. Recently I have faced simalar issue. once the routing table updated with allow the WL admin server port everything got set.
Hope this could helps you!
I had this problem too. In a script, I exported the Linux variables userConfigFile and userKeyFile. Then I connected by running:
url='t3://localhost:7002'
userConfigFile='$userConfigFile'
userKeyFile='$userKeyFile'
connect(userConfigFile=$userConfigFile, userKeyFile=#userKeyFile, url=url)
That all worked in a script, but would not work interactively. I changed to doing the following:
url='t3://localhost:7002'
userConfigFile='/users/me/weblogic-2014/weblogic-admin-WebLogicConfig.properties'
userKeyFile='/users/me/weblogic-2014/weblogic-admin-WebLogicKey.properties'
connect(userConfigFile=userConfigFile, userKeyFile=userKeyFile, url=url)
And that worked interactively.

Use GAE remote api with local (dev) installation

Has anyone find to use the GAE remote api but instead of connecting to AppEngine to connect to localhost?
For dev purposes of course
i was able to get this working by adding the following to the app.yaml file
builtins:
- remote_api: on
and then from the command line you can access the db, users, urlfetch or memcache modules
remote_api_shell.py -s localhost:8080
This will prompt you for the email and password but this is not important right now. the remote_api_shell.py is on my path from the google app engine directory
Have you tried the development console? To access it, go to this URL: http://localhost:8080/_ah/admin.
If you really want to use the remote API, have a look at this article. I believe you can use the dev_server by passing the local host url to the interactive console script.
For Java see this document which explains both local and remote access
https://developers.google.com/appengine/docs/java/tools/remoteapi#Configuring_Remote_API_on_the_Client
If there are some like me who prefer to execute from a python script rather than a shell:
from google.appengine.ext.remote_api import remote_api_stub
remote_api_stub.ConfigureRemoteApiForOAuth('localhost:8081', '/_ah/remote_api', secure=False)
os.environ['SERVER_SOFTWARE'] = 'Development'
os.environ['HTTP_HOST'] = 'localhost:8080'
... do stuff ...
I run the dev server with the option "--api_port 8081" otherwise just look at the port used in the dev server logs ("Starting API server at ...").
The environ tweaks are to be able to use cloudstorage api against the dev server too.