I have an Upstart service that can run multiple instances. Two dynamic parameters can be specified in any combination.
Is there a way to convert that into a systemd .service file?
start on (net-device-up and local-filesystems and runlevel [2345])
stop on runlevel [016]
instance $C,$B
exec [...] $C $B
respawn
systemd supports templates which can be used to launch multiple instances of a service using a single template. From the docs in man systemd.unit:
Optionally, units may be instantiated from a template file at runtie. This allows creation of
multiple units from a single configuration file. If systemd looks fora unit configuration file, it
will first search for the literal unit name in the file system. If tat yields no success and the unit name contains an "#" character, systemd will look for a unittemplate that shares the same name but
with the instance string (i.e. the part between the "#" character an the suffix) removed. Example: if
a service getty#tty3.service is requested and no file by that names found, systemd will look for
getty#.service and instantiate a service from that configuratin file if it is found.
To refer to the instance string from within the configuration file you may use the special "%i" specifier in many of the configuration options.
In your case, starting a service for dynamic parameters "c" and "b" might look like:
systemctl start myservice#b-c.service
Since systemd only supports one variable in the instance name, you may need to write wrapper shell script that unpacks an instance name of "b-c" to separate values of "b" and "c" to pass to your underlying service.
Related
Adding Property in Scala Environment Properties
val sysProps = System.getProperties
sysProps.setProperty("current.date.time", LocalDateTime.now().toString())
i'm able to save this property.
I tried accessing this property(current.date.time) in log4j.properties like below
log4j.appender.file.File=C:/Users/vsami/Desktop/Demo_${current.date.time}.log
log4j.appender.file.File=C:/Users/vsami/Desktop/Demo_${env:current.date.time}.log
Log file is getting generated in above location like Demo_.log, Expected :- Demo_2019/11/27T13:21:00.log
Above implementation is not helping me in accessing variable from environment properties and generate log file with expected naming convention.
JVM has properties that can be passed via -D parameter at VM boot. -Dprop=value.
These properties can be read via System.getProperties API call. See docs for more info.
Environment variables are not specified on JVM boot and managed independently from VM by your boot environment (it can be shell, bash etc). You cannot change environment variables in already running VM. These variables can be read via System.getenv()
$ is a look up operator in log4j and can be used to resolve env variables with env: prefix or Main Arguments Lookup with prefix main:.
You could use main:current.date.time and initialise your value as following
MainMapLookup.setMainArguments(Array("--current.date.time", LocalDateTime.now().toString()));
Make sure that MainMapLookup is called before logging is initialised.
I am trying to script an openam deployment using ssoadm, and want to know what will be the fastest and fool proof way to get the attribute names for ssoadm?
Right now, i login to the console and "view html source" for the attribute i am interested in, and use that via ssoadm. But, this approach is time consuming, plus with openam13 the attribute names are not available in the source.
Are you interested in any configuration or service in particular?
For most configurations and services (such as datastores, auth modules, server properties, etc...) there is an ssoadm command that will give you the current values from where you can grab the property names and use the in your script.
For example if you have a Datastore called OpenDJ in your top-level realm you can get the current configuration values using the following command:
ssoadm show-datastore -u amadmin -f /tmp/amadmin.pwd -e / -m OpenDJ
Typically it's just a matter of finding the right ssoadm command. Another option will be to look at the service definition. All these definitions are kept in xml format in your configuration store inside ou=Services.
Hope this helps.
I think the easiest approach is probably to look up the service XML files. At the time of the configuration, the service XML files are all copied over to ~/<OPENAM_HOME>/config/xml folder, so normally you can just try to grep for certain strings (like dynamic), but even then that may not work well.
If you know what service you are dealing with, then things get a bit easier. Are you trying to change an Authentication configuration? It must be defined in amAuth.xml then. The service name to be used for the ssoadm command is defined in the <Service> element under the "name" attribute. The service attribute names are defined under <AttributeSchema> elements with "name" attribute.
Yet another alternative would be to just read the documentation as most of the property names are already documented:
http://openam.forgerock.org/doc/bootstrap/admin-guide/index.html#auth-core-realm-attributes
I have been trying to use Rundeck to send powershell commands to windows boxes.
I am using "rundeck-winrm-plugin"
https://github.com/rundeck-plugins/rundeck-winrm-plugin
It says to configure it in either project.properties or framework.properties file.
Here is how my /var/rundeck/projects/SecureCloud/etc/project.properties file looks like.
project.name=Cloud
project.ssh-authentication=privateKey
project.ssh.user=Domain\\rundeck-user
service.NodeExecutor.default.provider=jsch-ssh
project.ssh-keypath=/var/lib/rundeck/.ssh/id_rsa
resources.source.1.config.url=http\://localhost\:4567/puppetdb
resources.source.1.config.timeout=30
service.FileCopier.default.provider=jsch-scp
resources.source.1.type=url
resources.source.1.config.cache=true
service.NodeExecutor.default.provider=overthere-winrm
winrm-user=Domain\\rundeck-user
winrm-password-storage-path=keys/ldap-rundeck-user-pass
I can't figure out how to define username and password according to this document:
https://github.com/rundeck-plugins/rundeck-winrm-plugin
I already have winrm-user already defined so I don't know if I still have to define rundeck-user#Domain if yes, then how (I am using kerberos) ?
project.username=rundeck-user#Domain ?
How to define hostname here ?
project.hostname=machine-name ?
Should I even use /var/rundeck/projects/SecureCloud/etc/project.properties file when I already declared there:
service.NodeExecutor.default.provider=jsch-ssh
and this doc says to put this line there:
service.NodeExecutor.default.provider=overthere-winrm
If no, then where should I put my configuration ?
Username and password
There are two ways you can define authentication
Basic:
You can use a Secure option in the rundeck job and an option name that matches your node definition name for that option. You can set the username in the node definition as well
Kerberos:
This is how you define the username (Make sure you use Caps for the domain as defined in the krb5.conf file)
username="user#YOUR_DOMAIN.COM"
Hostname is defined in the node definition. To define a node you can do it under /var/rundeck/projects/SecureCloud/etc/resources.xml For example:
node name="YOURSERVER" connectionType="WINRM_NATIVE" node-executor="overthere-winrm" winrm-password-option="winrmPassword" winrm-protocol="https" winrm-auth-type="basic" username="YOURUSER" winrmPassword="winrmPassword" hostname="YOURHOSTNAME:PORT"
You don't need to define the node executor in your node definition if overthere-winrm is already set as the default node executor in the Configuration/Plugins/NodeExecutor section of the project in the Rundeck GUI
you can follow Rundeck Windows Nodes Configuration for the steps to follow for overthere winrm configurations.
I have REST API, that is developed using Scala and Spray framework. I am able to execute and launch my Api from localhost. The API is connected to the database. The IP Address(localhost) and port of Database is read from the "application.conf" file under the resources.
Everything works fine till I start using Docker. In Docker I have :
1. One Docker container of Rest API
2. One Docker container of Database.
The IP address of Database changes for each docker instance, therefore I need to update my "application.conf" file. Although I can use the hostname of Db instance that remains the same.
My issue is : Can I have two "application.conf" files , one for localhost and one for Docker instance? IS there a way to change the "application.conf" file at the run time.
P.s I am using "sbt run" to run the application and as per documentation it does not support java system properties or environment variables
Yes, you can choose the config at runtime. spray & akka use the typesafe config library which allows setting single settings or the whole configuration using JVM properties.
From the documentation of config:
For applications using application.{conf,json,properties}, system
properties can be used to force a different config source:
config.resource specifies a resource name - not a basename, i.e. application.conf not application
config.file specifies a filesystem path, again it should include the extension, not be a basename
config.url specifies a URL
These system properties specify a replacement for
application.{conf,json,properties}, not an addition. They only
affect apps using the default ConfigFactory.load() configuration. In
the replacement config file, you can use include "application" to
include the original default config file; after the include statement
you could go on to override certain settings.
Are there any simple ways to see what wars have been deployed in Jboss AS and undeploy some of them? I want to do this from the command line.
I tried using jmx but I keep getting exception saying "org.jboss.util.NestedRuntimeException: jmx not bound;" I'd prefer to do it in a way where I don't have to stop and start the application server.
You can approach this in three ways in JBoss Application Server 7:
Management Console
Management CLI
Deployment folder
Management Console
Being a GUI, the Management Console is the most visual of the three, and you can see the list of deployed applications under the Deployment window. You have the option to Disable and Remove the deployed applications listed here. This screenshot is from AS7.0.2, and some windows have and will change with the addition of tabs, but the general functionality remains the same.
Management CLI
The Management Command Line Interface is a new addition to AS7. The CLI exposes a lot of low-level functionality, and is a powerful tool once you get familiar with the commands and operations. As you might expect, you can run help to show the commands, or run <commandname> --help for more information on a specific command. Two useful commands are deploy and undeploy, so let's look at their help information. I'll give Linux examples, but you can insert your flavour of OS as required.
Here's deploy:
[standalone#localhost:9999 /] deploy --help
SYNOPSIS
deploy (file_path [--name=deployment_name] [--runtime_name=deployment_runtime_name] [--force] | --name=deployment_name) [--server-groups=group_name (,group_name)* | --all-server-groups]
DESCRIPTION
Deploys the application designated by the file_path or enables an already existing
but disabled in the repository deployment designated by the name argument.
If executed w/o arguments, will list all the existing deployments.
ARGUMENTS
file_path - the path to the application to deploy. Required in case the deployment
doesn't exist in the repository.
The path can be either absolute or relative to the current directory.
--name - the unique name of the deployment. If the file path argument is specified
the name argument is optional with the file name been the default value.
If the file path argument isn't specified then the command is supposed to
enable an already existing but disabled deployment, and in this case the
name argument is required.
--runtime_name - optional, the runtime name for the deployment.
--force - if the deployment with the specified name already exists, by default,
deploy will be aborted and the corresponding message will printed.
Switch --force (or -f) will force the replacement of the existing deployment
with the one specified in the command arguments.
--server-groups - comma separated list of server group names the deploy command should apply to.
Either server-groups or all-server-groups is required in the domain mode.
This argument is not applicable in the standalone mode.
--all-server-groups - indicates that deploy should apply to all the available server groups.
Either server-groups or all-server-groups is required in domain mode.
This argument is not applicable in the standalone mode.
-l - in case none of the required arguments is specified the command will
print all of the existing deployments in the repository. The presence of the -l switch
will make the existing deployments printed one deployment per line, instead of
in columns (the default).
And here's undeploy:
[standalone#localhost:9999 /] undeploy --help
SYNOPSIS
undeploy name [--server-groups=group_name (,group_name)* | --all-relevant-server-groups] [--keep-content]
DESCRIPTION
Undeploys the deployment with the given name and, depending on the arguments, removes
its content from the repository.
If the deployment name isn't specified, prints the list of all the existing deployments.
ARGUMENTS
name - the name of the deployment to undeploy.
--server-groups - comma separated list of server group names the undeploy command should apply to.
Either server-groups or all-relevant-server-groups is required in the domain mode.
This argument is not applicable in the standalone mode.
--all-relevant-server-groups - indicates that undeploy should apply to all the server groups
in which the deployment is enabled.
Either server-groups or all-relevant-server-groups is required in domain mode.
This argument is not applicable in the standalone mode.
--keep-content - by default undeploy, besides disabling the deployment, also removes its
content from the repository. The presence of --keep-content will only disable
the deployment w/o removing its content from the repository.
This argument can be used in both standalone and domain modes.
-l - in case the deployment name isn't specified, the presence of the -l switch
will make the existing deployments printed one deployment per line, instead of
in columns (the default).
The CLI In Action
Running the deploy or undeploy command without any arguments will list all the applications available. So your workflow to log in to the CLI and undeploy an application would be like this (simplified):
Change directory from EAP_HOME to the bin folder:
[user#home EAP_HOME]$ cd bin
Run the CLI logon script:
[user#host bin]$ ./jboss-admin.sh
You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.
Instruct the API to connect (this can also be passed at runtime as ./jboss-admin.sh --connect).
[disconnected /] connect
Connected to standalone controller at localhost:9999
Run the undeploy command to display available applications.
[standalone#localhost:9999 /] undeploy
test.ear
Run the undeploy command to undeploy the application. In this case, the test.ear.
[standalone#localhost:9999 /] undeploy test.ear
Successfully undeployed test.ear.
Deployment Folder
If you are running an instance of AS7 as a development tool, and are using the deployment folder, you can simply delete the application. You will notice that a marker file is created, such as test.ear.failed, to signify the status of the application deployment.
With JBoss Application Server it's possible handle deployment with plain file operations on wars/ears in deploy dir.
Just ls to enumerate, delete to undeploy, copy to deploy and touch to redeploy. No server restart required.
Also for the newest version of JBoss Application Server 7 you can use CLI.
You can also try CLI GUI. The Deployments-->Undeploy menu option provides a pick list of deployments. A couple of clicks and you are done.
See https://community.jboss.org/wiki/AGUIForTheCommandLineInterface
You dont have to restart the JBOSS server if you remove the WAR and EAR the application gets undeployed .
The article (http://docs.jboss.org/jbossas/docs/Clustering_Guide/4/html/clustering-intro-farm.html ) gives the perfect explanation of how it works.
Let all know if you have any questions about it .
We have been doing the development on Jboss the same way in our DEV , QA and Prod environment and have not faced any issues with it so-far.