I'm trying out rundeck (3.0.13) for the first time. I've followed the instructions in this web page: https://www.techrepublic.com/article/how-to-add-remote-nodes-to-rundeck/, but unfortunately it doesn't seem to create a remote node. In brief, the steps are
Add a key to key storage that has the username/password for the remote node. (I left the default storage path as "keys")
Create a project, change the ssh/scp parameters to use password au8thentication using that username/pass combo
Create a file called resources.xml in the project /etc folder, and specify the remote node in there.
Restart rundeck
Wait a few minutes and the node should be visible on the nodes page of the project
Unfortunately, this doesn't work. All I see is the default local server node. (I used the "Select All Nodes" feature, so it's not a filter problem.)
I don't see any errors in the logs; I verified that I can log into the remote node from the rundeck server node using ssh and the credentials I provided. My remote node has an IP address, but as this is a test, I didn't make a DNS entry for it. Is there anything else I can try or look at for diagnostic information? I'm not even sure it's hitting the resources.xml file.
UPDATE
I was able to get this working by using the GUI to load the resources.xml file after project creation.
In the tutorial, the author puts this file into the /etc of the project and rundeck just finds it. If instead, the same resources.xml file is specified as a "File" source of nodes, it loads.
Ironically not seeing any errors in the logs was the biggest clue.
I had the same issue that I resolved as follow:
Add a file named resources.xml in the project folder / etc folder. (if it's not there, create one). It should have the following content:
<?xml version="1.0" encoding="UTF-8"?>
<project>
<node name="somename" description="Rundeck 1" tags="" hostname="xx.xx.xx.xx" osArch="amd64" osFamily="unix" osName="Linux" osVersion="3.10.0-514.el7.x86_64" username="xyz"/>
</project>
go to project setings via UI --> edit nodes
Add a source from type 'File'.
format: select the resourcexml.
file path: use pwd and get the path, it should also include the /resources.xml file name at the end, like /home/xxx/rundeck/projects/test/etc/resources.xml
select generate
save and restart the rundeck
Related
If you want to configure your VS "Load Tests" to write the results to a database server, you use the following instructions.
If you want to run your "Load Tests" through powershell on a separate machine(think TFS 2018 release step), you use the following instructions.
I would like to do both, on multiple machines, in a automated manner, but there's not a great deal of documentation on this, I can run my tests like this:
.\mstest /testcontainer:"C:\XXX\ABC.loadtest"
But the results are kicked out to a "TRX" file rather than being placed into a database(there is some discussion on this). How do I put the results into a external database like when I run it locally(per instructions above)?
Note: #AdrianHHH points out that the "TRX" file is only a summary and that most of the info is stored locally(MDF/LDF file) in the user folder of current user running the load tests.
Update 1
Hmm I wonder where this is persisted:
(Curious, also click on the "?" icon in the "Manage Test Controller" box, nothing...)
It's not in the saved XML:
<RunConfigurations>
<RunConfiguration Name="Run Settings1" Description="" ResultsStoreType="Database" TimingDetailsStorage="AllIndividualDetails" SaveTestLogsOnError="true" SaveTestLogsFrequency="0" MaxErrorDetails="200" MaxErrorsPerType="1000" MaxThresholdViolations="1000" MaxRequestUrlsReported="1000" UseTestIterations="false" RunDuration="10" WarmupTime="0" CoolDownTime="0" TestIterations="100" WebTestConnectionModel="ConnectionPerUser" WebTestConnectionPoolSize="50" SampleRate="5" ValidationLevel="High" SqlTracingConnectString="" SqlTracingConnectStringDisplayValue="" SqlTracingDirectory="" SqlTracingEnabled="false" SqlTracingFileCount="2" SqlTracingRolloverEnabled="true" SqlTracingMinimumDuration="500" RunUnitTestsInAppDomain="true" CoreCount="0" ResourcesRetentionTimeInMinutes="0" AgentDiagnosticsLevel="Warning">
<CounterSetMappings>
<CounterSetMapping ComputerName="[CONTROLLER MACHINE]">
<CounterSetReferences>
<CounterSetReference CounterSetName="LoadTest" />
<CounterSetReference CounterSetName="Controller" />
</CounterSetReferences>
</CounterSetMapping>
<CounterSetMapping ComputerName="[AGENT MACHINES]">
<CounterSetReferences>
<CounterSetReference CounterSetName="Agent" />
</CounterSetReferences>
</CounterSetMapping>
</CounterSetMappings>
<LoadGeneratorLocations>
<GeoLocation Location="Default" Percentage="100" />
</LoadGeneratorLocations>
</RunConfiguration>
</RunConfigurations>
They're not persisted in my default "testsettings" file either:
<?xml version="1.0" encoding="UTF-8"?>
<TestSettings name="Local" id="02cad612-043b-447d-993e-a9b9b0547c9d"
xmlns="http://microsoft.com/schemas/VisualStudio/TeamTest/2010">
<Description>These are default test settings for a local test run.</Description>
<Deployment enabled="false" />
<Execution hostProcessPlatform="MSIL">
<TestTypeSpecific />
<AgentRule name="Execution Agents">
</AgentRule>
</Execution>
<Properties>
<Property name="TestSettingsUIType" value="UnitTest" />
</Properties>
</TestSettings>
So I need to find where ever this configuration information is being persisted, then maybe I can find a way to feed it to MSTest. Does anyone else understand how this works?
Update 2
My TRX file does contains a "connection string" but I don't think it's to my database, my database is empty, on running via powershell it completes, but all I see is the "TRX" file.
Update 3
This one is tricky, I keep trying various ways to determine where this "Manage Test Configuration" data/credentials is being stored. One of the ways I did this was to use Microsoft's Process Monitor. You can actually see where it initially is being populated from:
It's from a Application Hive, of course that's begs the question where did the "Application Hive" get populated from, that's where things get a bit murky, there's allot of different calls to many files. A common trend is that the "Temp\Local" folder is often referenced.
I deleted the entire "Temp" folder for my user account(in the process losing all my VS configuration) and upon reopening my solution it appears as though this had an effect. When I pull up my "LoadTest" file, the "Load test results store" line is now empty. In fact the entire "Manage Test Controller" window has been restored back to default(empty).
I know believe that the configuration for this "Manage Test Controller" window is persisted in the temp folder. However, I've yet to locate where it is and/or how to change/automatically populate that information with a powershell script.
Finally figured this out. Basically I used several tools to check what files were being modified when I changed the connection string, the results made it obvious:
privateregistry.bin
Once I found this it was pretty obvious that VS was maintaining it's own little registry hive. It's clearly stated in this post, so I opened it in the way described in the article and found the connection string:
This indicated that:
"The SQL Connection String is NOT stored in the loadtest files. The
setting seems to be PC specific so I had to change it on the build
server - in one loadtest file (address.loadtest) as shown, then all
the other loadtests adopt the same connection string."
So that's basically what I did, I logged into each build server and configured them so that they write all there results to my database rather than locally.
Load tests are clearly not designed to make this process easy, I don't think many people have attempted to do what I've done. All the articles just tell you to use their cloud service. I'm pretty sure that only covers web tests. If your using load testing to test unit tests you pretty much out of luck(without this work around). I really hope this gets official support in the future, it would be really nice to both run/view all types of load tests from TFS. For now though I'm going to have to keep using this work around.
Going through MSDN and various other posts on line, I understand that we can very well do away with the older method of ini files for writing and retrieving configuration details so as to be able to change database path/connection string. (refer)
I am able to get the connection string data from an external file ("abcConnStr.config") and am able to read and write from / to the database tables as normally one would expect to.
However I am unable to crack the way I would be able to change / update the connection string value in the external file ("abcConnStr.config"). If I try to pass the value manually through a text box I get a message saying "Your step-into request resulted in an automatic step-over of a property or operator.....". When I click "Yes" the sub is completed without any further message or error. However when I open the config file ("abcConnStr.config"), I find that the value of the connection string has not changed.
May I request you to guide me as to how can I change the connection string parameter in the external config file ("abcConnStr.config").
Addl.info:
Here is the external config file that I am using:
File name: connStr.config
<?xml version="1.0" encoding="utf-8" ?>
<connectionStrings>
<add name="NewConStr"
connectionString="Provider=Microsoft.ACE.OLEDB.12.0;Data Source=&
quot;D:\CATALOG\CATALOG_DB\CAT_DB.accdb""
providerName="System.Data.OleDb" />
</connectionStrings>
I am using the following code line in appication.exe.config (app.config) file to access the database:
<connectionStrings configSource="connStr.config" />
I am able to connect to the database if it resides in the file location as defined in the external config file. However, when I change the database location (put in another folder or change the name) as expected, the connection to the DB fails. At this point I am catching the exception and trying to call the sub to effect a change to the path value assigned to the "connectionString".
In the sub I want to call code/s to change the DB file path as selected by the user thru'"OpenFileDialog".
Kindly advise a possible way to achieve this.
I got the solution on here.
However, I will have to do away with external config file (for now, till I get a solution on it) and have ended up making changes to the application.exe.config file. It is working seamlessly.
I am using VB 2010 Pro.
Thanks.
In JBoss 7.1.1 in standalone mode all JNDI bindings are configured in standalone.xml file in jboss:domain:naming:1.1 subsystem. According to documentation standalone.xml cannot be modified when server is running. I've tried to use JBoss CLI but I don't know how to write/modify resource.
How to change value in JNDI without restarting jboss?
Should help you: https://docs.jboss.org/author/display/AS71/JNDI+Reference
Topic - Binding entries to JNDI:
An example standalone.xml might look like:
<subsystem xmlns="urn:jboss:domain:naming:1.1" >
<bindings>
<simple name="java:global/a" value="100" type="int" />
<object-factory name="java:global/b" module="com.acme" class="org.acme.MyObjectFactory" />
<lookup name="java:global/c" lookup="java:global/b" />
</bindings>
</subsystem>
To add these entries via the CLI:
/subsystem=naming/binding=java\:global\/mybinding:add(binding-type=simple, type=long, value=1000)
To see all all options that are taken by the add command (this can
actually be used to get the description of any CLI command):
/subsystem=naming/binding=*:read-operation-description(name=add)
Have not tried, but i hope this helps!
UPDATE - with tested examples:
Add JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:add(value=10,binding-type=simple,type=java.lang.Integer)
Read existing JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:read-resource(include-defaults=true)
Modify JDNI name binding value java:global/a:
/subsystem=naming/binding=java\:global\/a:write-attribute(name=value, value=20)
Remove JDNI name binding java:global/a:
/subsystem=naming/binding=java\:global\/a:remove()
Executing command directly from shell:
./jboss-cli.sh --connect --command="/subsystem=naming/binding=java\:global\/a:read-resource(include-defaults=true)"
The question has a lot of views so I'll answer to it. Inspired by #mik response I've figured out that to change value of some JNDI key e.g. java:jboss/api/key to newApiKey run JBoss CLI and execute:
connect
/subsystem=naming/binding=java\:jboss\/api\/key/:write-attribute(name=value,value=newApiKey)
The change will be immediately visible on server and also stored (updated) in standalone.xmlso it won't get lost after server restart.
I was looking exactly for how to add or modify a JNDI binding at runtime, but I needed to to do this in a Wildfly 9 domain (cluster) configuration (not standalone), which is pretty much the same configuration as JBoss 7. However, I couldn't figure out a way to effectively apply changes without restarting all servers.
To start with, enter the JBoss command line interface and connect to your server domain controller:
./jboss-cli.sh
connect
First, you need to find which profile is active on the server group, so as, on the server root /, enter the following commands:
cd server-group=
ls
Afterwards, you should enter the only server group shown in the listing command (ls) by typing cd {{your_server_group_name}}, then type ls again and look for an entry named profile to check which one is active. Let's consider full-ha as an active profile for our example.
Next, go back to the root configuration folder / by typing cd .. and enter the following commands to navigate and view all JNDI bindings available with their current values:
cd profile=full-ha/subsystem=naming/binding=
:read-resource(recursive=true)
By doing this, you'll be able to see all available JNDI bindings and their attributes, if you want to list only binding names, type ls instead of the last command.
In order to modify a binding, type cd and the name of the binding listed in the previous command. Let's suppose you want to change the value of a binding named java:/webservice.url, then you should enter
cd java\:\/webservice.url
Notice that is necessary to quote some characters in your binding name such as : (colon) and / (slash) with a backslash (\).
To modify an attribute within this binding you should use the :write-attribute command. In this example, let's suppose you want to modify (or add) an attribute named "value" with its content as "this is a value":
:write-attribute(name=value,value="this is a value")
So as to apply this change, you'll need to restart all servers in the cluster by typing the following command:
/server-group={{server-group-name}}:restart-servers
If you want to know more commands to add or remove JNDI bindings check this jboss-cli snippets page
This configuration has been tested successfully in Wildfly 9.0.1
When I add "" to my ServiceDefinition.csdef, it fails to start when publishing:
<WebRole name="xxx" vmsize="Small" enableNativeCodeExecution="true">
<Runtime executionContext="elevated" />
<Sites>...
Everything works with it gone. Need to add it to specify machine key in Azure SDK 1.3, as described here: http://msdn.microsoft.com/en-us/library/gg494983.aspx
Anyone else run into this?
Would running under admin privileges cause other code to break? When I RDP in, the error I find when I run on localhost is not related to this, but it's code that works when this runtime line is removed.
I just checked the Service Definition Schema and the Runtime
element does not exist inside WebRole.
Actually it does.
<WebRole name="<web-role-name>" vmsize="[ExtraSmall|Small|Medium|Large|ExtraLarge]" enableNativeCodeExecution="[true|false]">
...
<Runtime executionContext="[limited|elevated]">
I just checked the Service Definition Schema and the Runtime element does not exist inside WebRole.
If you would like to have Full Trust, you should go to yor CloudService project properties and set it there. But i really don't know if you need that to specify the machine key.
Best regards
I need to run multiple(more than 4) instances of JBoss server on a single machine.
I am using JBoss 4.2.3 GA.
I found the answer. We have to configure the jboss-service.xml to run multiple instances in the same machine.
We may need to keep the same "default" instance same as it is under the JBOSS_HOME\Server.
We have to create another folder say "instance2" under JBOSS_HOME\Server.
Copy all the contents from JBOSS_HOME\Server\default to this newly created folder.
Now goto conf folder under JBOSS_HOME\Server\instance2 directory.
Edit the jboss-service.xml.
Search for mbean code="org.jboss.services.binding.ServiceBindingManager" in this configuration file.
By default this xml tag is commented. We have to un comment it and change the value ports-00 to ports-01.
Then start this instance2 jboss instance. We can access this application by using the port number 8180.
We can go for at maximum of 3 instances with this way.
To run more than this we have to add some more running tags in
JBOSS_HOME\docs\examples\binding-manager\sample-bindings.xml.
You can make things a lot simpler by simply changing the IP that the server is bound to.
You will need to copy the entire jboss folder several times and configure run.bat to use the -b parameter on startup.
If this is a Windows server and you're running jboss as a service, you might want to edit the service.bat for each instance too so that the servers all have different names in the services control panel.
Part of the problem we ran into when trying to use different HTTP ports was that jboss uses 'lots' of ports for different purposes and it was a pain to edit all of these port numbers to be unique on each instance. By changing the bind address you can avoid this problem entirely.
Create multiple loopback adapters and bind each ip address to different instance.
No need of changing port.
RK
1) Copy the default folder with new name: instance name
2) In jboss-service.xml Uncomment the ServiceBindingManager mbean and change the ServerName to ports-01 or 02 or 03 e.g:ports-01 and ports-01/02/03 configuration should be there in sample-bindings.xml(present in docs/examples/binding-manager) And make the changes in all the ports mentioned under ports-01/02/03 tags, So that ports will not get conflict. Remember the server will run on the binding port like 8080/8180/8182.
from cmd promt go to the bin folder and run the instances with cmd:
run -c instancename
Running multiple instances of JBoss on the same server:
We should keep the "default" instance same as it is under the **JBOSS_HOME\Server
Copy the default folder with new name (instance name) say default2 under JBOSS_HOME\Server. Copy all the contents from JBOSS_HOME\Server\default to this newly created folder.
The binding service manager needs to be enabled in conf/jboss-service.xml for instances that are not using the default ports.
a. (i.e.) In the copied instance, go to conf folder under JBOSS_HOME\Server\default2 directory. Edit the jboss-service.xml.
b. Search for mbean code="org.jboss.services.binding.ServiceBindingManager" in this configuration file.
c. By default this xml tag is commented. We have to uncomment it and change the value ports-00 to ports-01.
In the same file, Under "Socket transport Connector", in the "Configuration" section, serverBindPort must be changed to another value or it will conflict with the default (4446).
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:service=Connector,transport=socket"
display-name="Socket transport Connector">
...
<attribute name="Configuration">
...
<attribute name="serverBindPort">25447</attribute>
...
In default2/deploy/ejb3.deployer/META-INF/jboss-service.xml, for the remoting.transport.Connector mbean, port 3873 must be changed to another value or it will conflict with the default.
<mbean code="org.jboss.remoting.transport.Connector"
name="jboss.remoting:type=Connector,name=DefaultEjb3Connector,handler=ejb3">
<depends>jboss.aop:service=AspectDeployer</depends>
<attribute name="InvokerLocator">socket://${jboss.bind.address}:25874</attribute>
...
In default2\deploy\jboss-web.deployer\server.xml
set redirect port value to the one configured in step 4
<Connector port="8180" address="${jboss.bind.address}"
maxThreads="250" maxHttpHeaderSize="8192"
emptySessionPath="true" protocol="HTTP/1.1"
enableLookups="false" redirectPort="25447" acceptCount="100"
connectionTimeout="20000" disableUploadTimeout="true" />
Also, the port value configured in step 5
<!-- Define an AJP 1.3 Connector on port 8009 -->
<Connector port="25010" address="${jboss.bind.address}" protocol="AJP/1.3" //change the connector port value to avoid conflict
emptySessionPath="true" enableLookups="false" redirectPort="25874" /> // port value configured in step 5
In summary, the directory structure for setting up two other instances would be something
like the below with modifications in the filenames in bold.
$JBOSS_HOME/server/default
$JBOSS_HOME/server/default2
$JBOSS_HOME/server/default2/conf/jboss-service.xml
$JBOSS_HOME/server/default2/deploy/ejb3.deployer/META-INF/jboss-service.xml
$JBOSS_HOME/server/default2/deploy/jboss-web.deployer/server.xml**
$JBOSS_HOME/server/default3
$JBOSS_HOME/server/default3/conf/jboss-service.xml
$JBOSS_HOME/server/default3/deploy/ejb3.deployer/META-INF/jboss-service.xml
$JBOSS_HOME/server/default3/deploy/jboss-web.deployer/server.xml**
7.From command prompt go to the bin folder and run the instances with cmd:
run -c instancename
In this case, it is: run -c default2
And applications accessed with url’s like:
http://localhost:8080/myapp/
http://localhost:8180/myapp/
http://localhost:8280/myapp/
Note: We can go for maximum of 3 instances with this way.
To run more than this we have to add some more running tags in JBOSS_HOME\docs\examples\binding-manager\sample-bindings.xml.
I used this article to install mine.
http://wiki.adempiere.net/Setup_2_Adempiere_JBoss_server_in_1_physical_server
You should create different services to control the adempiere servers.
Also if you work with jasper report, use unique file names for reports or you will face permission denied exception.
Ex : if you attach "report.jrxml" to two servers. Server will create /tmp/report.jrxml tmp file.
The second server will also try to create the same file and get crashed
Copy complete JBOSS setup to new location, and start new server with offset option, which will start server on existing ip and changing port to previously_configured_port+offset
standalone.bat -c standalone-full.xml -Djboss.socket.binding.port-offset=100
This command will make default jboss console 9990 to 10090
Now you can add your war file in new deployments folder and start deployment on new port
The quickest and easiest way that comes into mind is simply configuring multiple IP addresses to the hosting machine. Then you can use the different IP addresses to bind to each instance. Doing this means you don't have to change any default ports and allows for an easier environment to manage.
We can easily do this on JBOSS EAP
For first instance, just start the JBOSS as it is.
for the second instance,
Copy the JBOSS home folder to a different location.
go to standalone/configuration/standalone.xml. go to the section(at bottom of the file) and set port-offset value to some value(EX: 10000) which doesn't have any port binding issue on currently running application. Here the default port-offeset value is 0.
start the second instance as usual .