I need to append certain JARs to CLASSPATH env variable only for managed servers and not admin server. Also need to add -D arguments for managed server only.
What would be the best place to do this? I am thinking of doing it in "setDomainEnv.sh" but I guess it is called for both admin and managed servers. Would I need to use $SERVER_NAME and add IF/ELSE logic to append to CLASSPATH and JAVA_OPTIONS selectively only for managed servers?
Regards
Jacob
The recommandation from Oracle is not to modify the setDomainEnv.sh script but create a setUserOverrides.sh in the bin directory. If you read the setDomainEnv you will see it calls the the setUserOverrides if it exists.
As you said, these scripts are called for both admin and managed server. So, you have to write if/else logic to set your system properties.
Related
I want to manage the servers in our staging pipeline with Powershell DSC (push model). The servers map to the environments as following
Development: 1 server
Test: 2 servers
UAT: 2 servers
Production: 2 servers
The server(s) within one environment do have the same configuration. But the configuration is different between the environments. I wanted to go with the push model because I do not have to setup a pull server.
Powershell DSC offers the option to manage the configuration via configuration data in a separate file But this comes with the caveat that you need to specify a node name that matches the respective server name. And that means, I need to copy the configuration data for each server in one environment. And when changing the configuration I need to remember that there is a second place where I need to update the configuration value.
Additionally, I do not really care about the server names. If the servers are exchanged tomorrow for new servers, the configuration should be just applied which is relevant to the environment.
What is the best practice approach to manage multiple servers within one environment with the same configuration?
Check the links, I think they cover scenerio
Using A Single DSC Configuration for Multiple Servers
enter link description here
DSC ConfigurationNames with multiple nodes
enter link description here
The mof file that gets produced does not contain the nodename inside it. So as long as you build a generic configuration, you can rename it after the fact at deploy time.
You can create one config for each environment with some generic name. Then enumerate the list of servers and make a copy of the config for each one with that servers name.
You can take it a step further. Have a share where you create a folder for each server that matches the server's name. Then copy the mof for that server into that folder with a name of localhost.mof. You can then run Start-DSCConfiguration -Path \\server\share\$env:computername from that machine as part of my deployment script.
In my installer i need a number of launchers, to install them as services, based on the user input. Those Launchers are all the same except for an index in their name.
I dont want to create all those launchers manually because that would be impossible to maintain.
Is there a way to copy and modify launchers at installer runtime and then install them as a service?
There is no reason to duplicate a service launcher at runtime. You can use an "Install service" action to install several services with different service names. To do that select "Other service executable" in the "Service" property of that action, then you can select and executable and a (variable) service name as well as variable arguments.
I have a Usecase too, where i want to have this Possibility of Renaming the Launcher an Runtime.
Assume you want to have a Testinfrastructure, where you want not only to test one Instance of your Programm, but several. And you want to use the Launchers from Install4J to start your Application.
Assume you have 5 Services that need to be started to provide the desired Functionality. Now think of having 10 Instances for 10 Customers, you want to test. Further you want to test it not on 10 different Machines, Docker, VM's, or what ever but on one single Machine.
This isn't possible, since you can't rename the Services at Runtime.
Wolfgang, i understand your Problem. Mine is similar.
I played a bit around with the Launcher.exe.
Perhaps there's a Solution for your Case.
Assuming your desired Launchernames are all off the same Length, like:
- Launcher_01.exe
- Launcher_02.exe
- Launcher_03.exe
- Launcher_04.exe
- Launcher_05.exe
You can then generate a Launcher once, with the Name "Launcher_xy.exe".
It's now possible to open up your favorite Hex-Editor an search for "Launcher_xy", rename it to "Launcher_01" and save the Data back to the exe-File. But be aware of not changing the Length of the Name. It won't work, if you'll change the Length.
So if you've changed the Name and afterwards execute
Launcher_xy.exe -install non-interactive
you will get a new Service called "Launcher_01.exe" under Windows-Services.
As I've explained in my other question, I'm busy setting up a PowerShell module repository in my enterprise.
My plan is to have a master repository (r/w access to a limited group of people) and slave repositories (read only access to everyone). I need multiple repositories because clients are located in different security zones and I can't have a central location reachable by all clients.
For this reason, I need to configure the PowerShell profile of the clients so that they can point to the correct repository to find the modules. I would like to define a $PowerShellRepositoryPath environment variable for this purpose.
Also, the profile needs to be customized in order for it to execute a script located in the repository (thus where $PowerShellRepositoryPath points to) when PowerShell starts (my goal here is to automatically add the latest module versions to the PSModulePath of the clients on startup).
We have a mixed environment with domain members and stand-alone servers in different network zones.
How would you proceed? Is it possible to push that variable and the profile via a GPO for domain members? Would customizing the $Profile variable via GPO be an option?
What about the standalone servers?
Edit:
I think that for creating the environment variable, I'll just use a GPO to create it and use it in PowerShell via $env:variableName. For non-domain situations, I'll probably have to use a script though..
I am not sure about pushing $profile via GPO. But, I'd simply put a logon script that copies the profile script from a network location based on the user's group/security membership.
Well if you're going to change the path to the modules, I'd have a file in the repository (say current.txt) that has the name for the current module (or current file path, whichever you are changing) in it. Then have the $profile script read the content of that file, and set the variable based on the contents. This way you don't have to screw around with updating the profile scripts, just update the central repository current.txt file with the path (or partial path, the part that changes, or filename or whatever), and when it replicates to the client repositories, all powershell profiles get updated with the latest modules when the profile script is executed.
Out of curiosity, why not just overwrite the module files in the client repositories with the latest version? If you did it that way, all clients would always have the latest versions, and you wouldn't have to update the $profile scripts.
Alternately you could always write another script to replace the $profile script on all machines. I think the first route I suggested would be the cleanest way of doing what you are after.
As far as the GPO thing goes, I don't believe you can do this. There is no GPO defined to control what is in the profile script. I would say you could maybe do it with a custom ADM file, but the profile script path is not controlled by the registry, so no go there.
We have multiple instances of JBoss 5.1.0 running on the same physical server, using multiple instances of the same VM:
<JBOSS_HOME>/server/instance1
<JBOSS_HOME>/server/instance2
with the appropriate configuration to avoid port clashes etc.
For each instance there is the tmp folder:
<JBOSS_HOME>/server/instance1/tmp
<JBOSS_HOME>/server/instance2/tmp
To keep things separate, is it ok to set the java.io.tmpdir variable to <JBOSS_HOME>/server/<INSTANCE>/tmp?
Thanks in advance
Rich
Probably, but JBoss might be assuming it has full control over the contents of that directory. It might be a good idea to create a directory under <INSTANCE>/tmp, and set java.io.tmpdir to that, it would likely reduce the risk of any collisions.
Calling the JBoss command line tool Twiddle, located in $JBOSS_HOME\bin directory, can give us the port number on which JBoss is listening for HTTP requests (see Q2366489). That's smashing :)
However, we can't rely on the fact that the system administrator has set the JBOSS_HOME path variable, and it would be useful to know if we can obtain this directory programatically from within the JBoss environment. In my case the project is deployed as a WAR file.
TIA
This, and various other path-related values, are set by JBoss as system properties, which you should use to obtain them.
For example, the system property jboss.home.dir will be set to the equivalent of $JBOSS_HOME, regardless of how the server is actually started.
The various system properties are defined in org.jboss.system.server.ServerConfig.
So:
String jbossHomeDir = System.getProperty("jboss.home.dir");