Home » Eclipse Projects » Eclipse Titan » The Titan runtime configuration file
| The Titan runtime configuration file [message #1735829] |
Thu, 23 June 2016 07:01  |
|
Greetings.
Parts of the configuration file have been discussed earlier; the aim of this post to offer an overview that can be used as a quick reference.
Initializing the data for the code itself can be done in two ways in Titan:
some values are generated during compilation, but there's also the possibility to attribute values to module parameters at the start of execution from a configuration file. Likewise, some parameters controlling the behaviour of Titan during test execution can be read from an external configuration file.
The config file used by Titan is a text file, structured in sections , each section having a particular header.
Sections may come in random order. We'll briefly go through each section and describe them broadly.
Further details about the config file can be found in the reference guide Ch.7 The Run-time Configuration File
[MODULE_PARAMETERS]
This was discused in detail in https://www.eclipse.org/forums/index.php/t/1077635/
Essential to remember is that module parameters in the config will override module parameters in the code,
and their value is set at the start of execution, when Titan reads the config file;
this permits quickly changing values without the need to recompile the code.
[LOGGING]
Again, there's a separate forum post for this: https://www.eclipse.org/forums/index.php/t/1073933/
Logging can be configured with fine granularity using config file options.
[TESTPORT_PARAMETERS]
In this section one can specify parameters that are passed to test ports.
For example:
[TESTPORT_PARAMETERS]
mtc.*.LocalIPAddress := "10.48.161.146" //all ports of mtc will have the given local address
*.HTTPPort.RemoteAddress := "10.48.161.147" // any port named HTTPPort in any component will be passed the given value of RemoteAddress
mtc.RADIUS[0].LocalUDPPort := "12345" //The first port of the RADIUS port array will have a LocalUDPPort value of "12345"
mtc.RADIUS[1].LocalUDPPort := "12346" //The second port of the RADIUS port array will have a LocalUDPPort value of "12346"
Each test port has its' own set of significant port parameters which are documented in the ports' description.
[DEFINE]
In this section one can create macro definitions that can be used in other configuration file sections except [INCLUDE].
Useful when a value appears in multiple sections, as when a change is needed, this has to be done in one location only.
[INCLUDE]
Other configuration files can be included.
The [INCLUDE] directives of included files are processed recursively.
Each referenced configuration file is processed exactly once even if it is included from several places.
Relative pathnames are resolved based on the directory of the referring configuration file.
Example
[INCLUDE]
"base_definitions.cfg"
"../additional_parameters.cfg"
[ORDERED_INCLUDE]
Same as include, except that inlcuded config files are sequentially processed.
[EXTERNAL_COMMANDS]
This section defines external commands ( shell scripts)
to be executed by the ETS whenever a control part or test case is started or terminated.
Using this feature one can control external monitor programs
(like tcpdump in case of IP testing) automatically during test execution.
Example
[EXTERNAL_COMMANDS]
BeginTestCase := "/usr/local/tester/bin/StartTcpdump"
EndTestCase := "/usr/local/tester/bin/StopTcpdump"
[EXECUTE]
In this section you have to specify what parts of your test suite you want to execute.
In single mode the configuration file is useless without this section.
Example
[EXECUTE]
IPv6Demo.tc_send_echo
IPv6Demo.tc_send_echo // run it twice
IPv6BaseSpecification.control //execute the control part
IPv6NeighborDiscovery.* //execute all test cases
[GROUPS]
In this section one can specify groups of hosts.
These groups can be used inside the [COMPONENTS] section to restrict the creation of certain PTCs to a given set of hosts.
Example
[GROUPS]
HeintelAndPauler := heintel, pauler.ez.domain.hu
myGroup := 10.44.87.34, test-host.123.com
AllHosts := *
[COMPONENTS]
This section consists of rules restricting the location of created PTCs. These constraints are useful when distributed tests are executed in a heterogeneous environment.
The participating computers may have different hardware setup, computing capacity or operating system.
Example
[COMPONENTS]
MyComponentType := HeintelAndPauler
CPComponentType := 10.44.87.34
* := AllHosts
[GROUPS] and [COMPONENTS] can be used to control execution of Titan over an array of computers, physical or virtualized/cloud based.
Binaries will have to be distributed and launched manually. As a result , Host Controllers will be created on each host,
and they will connect to the Main Controller. For details see user guide 4.4 Running Parallel Test Suites.
[MAIN_CONTROLLER]
These options control the behavior of the main controller(MC).
Options LocalAddress and TCPPort determine the IP address and TCP port on which the MC application will listen for incoming HC connections.
LocalAddress can be useful on multi-homed hosts.If omitted MC will accept connections on all local IP addresses.
TCPPort is a port number between 0 and 65535, recommended value being 9034.
Using a port number less than 1024 requires super-user (root) privileges.
The MC will listen on an ephemeral port chosen by the kernel when TCPPort is omitted or set to zero.
The KillTimer option tells the MC to wait some seconds for a busy test component (MTC or PTC) to terminate when it was requested to stop .
The MC in co-operation with the local HC kills the UNIX process if the component did not terminate properly before KillTimer expiry.
The purpose of this function is to prevent the test system from deadlocks.
Please note that when the UNIX process of MTC is killed all existing PTCs are destroyed at the same time.
[PROFILER]
The settings in this section control the behavior of the TTCN-3 Profiler and Coverage measurement.
This section will be treated in detail in a separate post.
Best regards
Elemer
[Updated on: Thu, 23 June 2016 07:12] Report message to a moderator |
|
| | | |
| Re: The Titan runtime configuration file [message #1829106 is a reply to message #1829103] |
Thu, 25 June 2020 09:16  |
|
Hi Salva,
the answer is yes and no :)
when starting execution, the config file is being read and then the execution continues with the values ( including test port parameters) from it until the end of the lifetime of the executable.
This is the behavior as provisioned by the standard.
However, some of our test ports can be reconfigured dynamically during execution using special messages from the test suite;
this comes with the drawback of some extra code needed to be added to the TTCN-3 code, and also , as this behavior is specific to Titan, will render the code non-compliant to the language standard, decreasing portability between tools.
As an example of dynamic port reconfiguration, pls. check the below test port:
https://github.com/eclipse/titan.TestPorts.TCPasp
see included documentation
Now the above is valid only for test port parameters; module parameters in the config file will only supply an initial value for e.g. a variable, and
this variable can be overwritten at any moment of the execution.
I'd imagine that a password is more like a module parameter, I don't see why it would belong to a test port. But I assume that depends
on the exact circumstances.
Best regards
Elemer
|
|
| |
| Re: The Titan runtime configuration file [message #1829124 is a reply to message #1829120] |
Thu, 25 June 2020 13:26 |
|
Hi Salva,
it is possible to read from a file during runtime;
pls check the functions in https://github.com/eclipse/titan.Libraries.TCCUsefulFunctions;
however it's probably simpler to read content from the configuration file, as this does not require anything extra, and store it in a variable
that can be used during execution;
mind that any kind of structure can be initialized from the config file, a large record of charstring for example:
{''password0",password1","password2","password3",.......,"password1999999"}
this structure can be accessed by referring to it's indexes
BR
Elemer
|
|
| |
| Re: The Titan runtime configuration file [message #1832217 is a reply to message #1832191] |
Sat, 12 September 2020 15:21 |
|
Hi Salva,
no, this does not look right.
Again, configuration file, as it is read at the beginning of the execution only, permits only static configuration; that is, configuration cannot be changed on the fly.
Dynamic configuration is possible only with dedicated messages sent from the user to the test port.
Each test port has a specific set of such messages that can be found in the code and documentation.
I see you want to dynamically change the password for a TELNET connection, possibly to brute-force user access. This cannot be done from the configuration file, you will need dynamic reconfiguration for that. ( I will assume that you are aware of local laws and regulations referring to gaining unauthorized access to computer systems, and you are not pursuing any malicious usage.)
First , you need to declare a structure that will hold your password list:
type record of charstring Password_list;
the password list can be stored in a module parameter , so you can quickly change it in the config file, with no need to recompile:
modulepar {
Password_list tsp_pass_list := {"password0",password1","password2","password3",.......,"password1999999"}
}
I will assume the you want to use the TELNET test port as in
https://github.com/eclipse/titan.TestPorts.TELNETasp
Please read the attached documentation. This test port is somewhat special in that it will attempt to establish connection immediately when mapped.
So now, you need to do the following:
-use a cycle variable say i starting from 0
-send a message of type ASP_TelnetPortParameters with ctrl_password:=tsp_pass_list[i]
-map the test port
(send an ASP_TelnetConnection(CONNECT) )
-if connection is established (prompt is received) your password guess was right
-if not , send an ASP_TelnetClose
-unmap the port
-increment i
-go back to setting the password
Now there was some time I worked with this test port so exact details, like order of execution might slightly differ but you get the idea. Important is that you need to use ASP_TelnetPortParameters to change the connection configuration on the fly.
I hope this makes it clearer
Best regards
Elemer
[Updated on: Sat, 12 September 2020 15:37] Report message to a moderator |
|
|
Goto Forum:
Current Time: Mon Dec 30 14:43:57 GMT 2024
Powered by FUDForum. Page generated in 0.04361 seconds |
] 
Search
Help
Register
Login
Home
