With JBOSS it's possible to zip up the installation directory and send
it off to a client site where the client can unzip the archive and get
JBOSS and the application up and running in five minutes. We would
like to achieve the same with WebSphere using profiles.
It's just a few hostnames (assuming no SSL certs) in some XML.
I think rename node is only needed for nodes that are federated to the
deployment manager. I am going to try a straight forward copy of a
profile directory from one machine to another. Will let you know how
I get on.
We do this for the whole dir structure (binaries as well), so would be
interested to know the out come.
If it is a stand alone server you could work with CAR (Configuration
Archive files).
You could wsadmin to export the CAR and import it back in another
machine.
This would not work in a ND Environment.
Refer to this URL for detailed instructions:
http://www-1.ibm.com/support/docview.wss?uid=swg21207526
The note talks about RAD but do not worry about that and look at the
wsadmin commands that do the import/export job for you.
There used to be a developerworks article that was available a few
years ago but i can' find it to provide you the links. You could
search for the same if you have the time and energy but the link above
should provide you with relevant info to do what you want (replicate
the config from one machine to another)
HTH
Cheers,
Manglu
http://www.ibm.com/developerworks/websphere/techjournal/0505_wang/0505_wang.html
Look for hte section:
Replicate your profile configuration
HTH
Cheers,
Manglu
The profile replication process works, well almost.
We copied two WebSphere unmanaged Application Server profiles to new
machines.
One profile hosted a JMS application using the built in WAS Service
Information
bus. The other profile hosted a JMS application using MQ as an
external
messaging provider. The target profiles on the new machines were
vanilla
application server profiles. Replication exports all the Was metadata
including the activation specs, j2c connection factory, jms queue
definitions,
jdbc and jvm configurations and any deployed applications. It does
not export
the SIB or SIB destination information. So if the profile makes use
of the WAS
SIB message provider then the BUS and destinations need to be created
on the
target profiles before the import takes place. Everything else was
copied
over. The whole exercise took half an hour versus the half a day it
usually
takes to manually set up a new environment if there are no scripts
available.
This is a remarkable simplification of the normally complex WebSphere
build and
deployment process. I can see why IBM opted for the planetary theme.
It's
takes more effort to roll out WebSphere infrastructure than send a man
to the
moon.
The only "gotcha" is that the default WAS soap time out is
insufficient for the
export/import and should be modified on both the source and target
servers.
2.6 Modify the profile soap timeout.
The profile import can take a long time and may
require that the profile client soap timeout parameter is set to zero
i.e. no timeout.
Backup then change the soap.client.props file.
wasadmin@:/opt/IBM/WebSphere/AppServer/profiles/
AppSrv01/properties> cp soap.client.props soap.client.props_10072008
Change the timeout from 180 seconds to zero.
#com.ibm.SOAP.requestTimeout=180
com.ibm.SOAP.requestTimeout=0
Save the file and exit.