In Apache I am trying to emulate the RewriteLog behaviour with a sub-request pointing to a simple cgi script
According to Apache 2.2 documentation:
%{LA-U:variable} can be used for look-aheads which perform an internal
(URL-based) sub-request to determine the final value of variable. This
can be used to access variable for rewriting which is not available at
the current stage, but will be set in a later phase.
%{LA-F:variable} can be used to perform an internal (filename-based)
sub-request, to determine the final value of variable. Most of the
time, this is the same as LA-U above.
According to a mail archive conversation in the case of using %{LA-F:variable} the request is passed directly to the next processing stage:
usr/local/webserver/doc_root/some/dir/som_file
cat /dev/world | perl -e "while (<>) {(/(^.*? \?) 42 \!/) && (print $1)}"
errors->(c)
but how to implement %{LA-U:variable} or %{LA-F:variable} in .htaccess?
Related
How can I run a binary cgi file on the command line and provide GET parameters to it?
I understand this task may be straightforward for perl or php files, but I've got a binary cgi file and no documentation for it. I'd like to run it without a web server so that I can evaluate certain problems on some co-workers' machines.
I've tried the following, but to no avail:
QUERY_STRING="foo=bar" ./myfile.cgi
foo=bar ./myfile.cgi
./myfile.cgi foo=bar
./myfile.cgi <<< "foo=bar"
In each case, the script outputs Error in form found<br>Missing foo<br><b></b><br>. (When executed through apache on our server, it returns no error message, only the intended results.)
Specifying the environment variable REQUEST_METHOD=GET in addition to QUERY_STRING=... makes the difference.
Among the tokens output by strings myfile.cgi, there were a number of cgi-related variables which the web server might be expected to set, such as REMOTE_ADDR, SERVER_SOFTWARE, and SERVER_PROTOCOL, but the two aforementioned variables proved enough to get this executable to produce a non-error output.
(For a POST, I've read that the body/params are read from stdin, but I haven't substantiated that personally.)
When defining a Bamboo plan variable, the page has this.
For task configuration fields, use the syntax
${bamboo.myvariablename}. For inline scripts, variables are exposed as
shell environment variables which can be accessed using the syntax
$BAMBOO_MY_VARIABLE_NAME (Linux/Mac OS X) or %BAMBOO_MY_VARIABLE_NAME%
(Windows).
However, that doesn't work in my Linux inline script. For example, I have the following defined a a plan variable
name: my_plan_var value: some_string
My inline script is simply...
PLAN_VAR=$BAMBOO_MY_PLAN_VAR
echo "Plan var: $PLAN_VAR"
and I just get a blank string.
I've tried this
PLAN_VAR=${bamboo.my_plan_var}
But I get
${bamboo.my_plan_var}: bad substitution
on the log viewer window.
Any pointers?
I tried the following and it works:
On the plan, I set my_plan_var to "it works" (w/o quotes)
In the inline script (don't forget the first line):
#/bin/sh
PLAN_VAR=$bamboo_my_plan_var
echo "testing: $PLAN_VAR"
And I got the expected result:
testing: it works
I also wanted to create a Bamboo variable and the only thing I've found to share it between scripts is with inject-variables like following:
Add to your bamboo-spec.yaml the following after your script that will create the variable:
Build:
tasks:
- script: create-bamboo-var.sh
- inject-variables:
file: bamboo-specs/vars.yaml
scope: RESULT
# namespace: plan
- script: echo ${bamboo.inject.GIT_VERSION} # just for testing
Note: Namespace defaults to inject.
In create-bamboo-var.sh create the file bamboo-specs/vars.yaml:
#!bin/bash
versionStr=$(git describe --tags --always --dirty --abbrev=4)
echo "GIT_VERSION: ${versionStr}" > ./bamboo-specs/vars.yaml
Or for multiple lines you can use:
SW_NUMBER_DIGITS=${1} # Passed as first parameter to build script
cat <<EOT > ./bamboo-specs/vars.yaml
GIT_VERSION: ${versionStr}
SW_NUMBER_APP: ${SW_NUMBER_DIGITS}
EOT
Scope can be local or result. Local means it's only available for current job and result means it can be used in subsequent stages of this plan and releases that are created from the result.
Namespace is just used to avoid naming collisions with other variables.
With the above you can use that variable in later scripts with ${bamboo.inject.GIT_VERSION}. The last script task is just to see that it is working in other scripts. You can also see the variables in the web app as build meta data.
I'm using the above script before the build (in my case compiling C-Code) takes place so I can also create a version.h file that can be used by the source code.
This is still a bit cumbersome but I'm happy with it and I hope it will help others to configure Bamboo. Bamboo documentation could be better. (Still a lot try and error)
I have a simple Jmeter test where I have a property to set the URL. The PATH in the Jmeter test is set to the following.
${__P(GET_URL,)}
This works well for all URLs that I have been working with, except for the ones where I need to pass a variable in the URL component.
For example, it works for http://server:port/getemployeelist when I run the test with -JGET_URL=/getemployeelist
Then I created a CSV config element to populate the variable EMP_ID.
Then if I run the test with -JGET_URL=/getemployee/${EMP_ID}, the EMP_ID variable is not getting substituted. Jmeter test gives me an error as follows:
java.net.URISyntaxException: Illegal character in path at index xx: https://://getemployee/${EMP_ID}
Appreciate any help/pointers.
It will not work this way, JMeter doesn't know anything about ${EMP_ID} at the time it is being started, you need to append this ${EMP_ID} to HTTP Request sampler "Path" in the runtime
Start JMeter as:
jmeter -JGET_URL=/getemployee/
Use CSV Data Set Config to read the EMP_ID from the CSV File
In the HTTP Request sampler use construction like /${__P(GET_URL,)}/${EMP_ID} to combine JMeter Property specified via -J command line argument and JMeter Variable originating from the CSV file.
If anything goes wrong first of all check jmeter.log file - it normally contains enough troubleshooting information. If there is nothing suspicious - use Debug Sampler and View Results Tree listener combination to inspect requests and response details, variables and properties names and values, etc.
Had asked this question a while back. Thought of posting the solution which I eventually ended up implementing. In the solution, I created a template jmx with a substitution variable for the HttpSampler.path and then replace the path at runtime. Following are the key points from the scripting done.
This turned out to be a simpler solution that worked for all kinds of API call patterns.
Created a template jmx (jmeter_test_template) with the following line.
<stringProp name="HTTPSampler.path">#PATH#</stringProp>
This jmx has CSV config element to populate variable "EMP_ID". To create this file, just create a new test with any URL and then save it as a template and replace the URL with substitution variable #PATH#.
Created a wrapper script like run_any_api.sh with usage,
sh run_any_api.sh URL=http://server:port/myapp/employees/${EMP_ID}
In the wrapper script, this URL is replaced in place of the token.
sed "s/#PATH#/$URL" jmeter_test_template.jmx > jmeter_test_template.current_test.jmx
jmeter -t jmeter_test_template.current_test.jmx
Last but not the least, please remember to cleanup the temporary jmx,
rm jmeter_test_template.current_test.jmx
Can someone concisely explain what the differences between the three variables below are? Because in all honesty, when I create a Jenkins job, I randomly guess between the three types until something works, but I'd love to understand rather than blindly picking.
${ENV,var="BUILD_USER"}
${BUILD_USER}
$BUILD_USER
Also, are there other ways of writing variables in Jenkins that I missed other than the 3 ways above?
When used in a statement:
${ENV,var="BUILD_USER"}--evaluates the system environment variables and returns the value for the variable BUILD_USER.
example: curl ${ENV,var="BUILD_USER"}/api/xml
${BUILD_USER} --returns the value of the BUILD_USER variable in the current script memory space.
example: curl ${BUILD_USER}/api/xml
$BUILD_USER--used to assign values to the BUILD_USER variable.
example: $BUILD_USER = "BUILD_USER"
In general, variable expansion is up to the plugin that interprets a configuration value.
For example, if you set up a job parameter GIT_REPOSITORY and use it to configure an address where git clone should go by putting $GIT_REPOSITORY into the git repository field, it works, but only because the Jenkins git plugin has implemented variable expansion support.
Many plugins do implement it but you cannot know it unless you test it. However, these days the support is so common it is safe to assume it should work.
Both forms of reference, $VAR and ${VAR}, work and are equivalent. The latter form is useful if you need to use the variable in a place where it is surrounded by other characters that could be interpreted as part of variable, like $VARX (Jenkins would be looking for variable named VARX) and ${VAR}X (Jenkins understands the variable is named VAR).
These rules have been modeled after variable expansion rules in Unix shells. Indeed, the job variables are made available as environment variables to build steps and in the Unix shell build step the variables are used the same way as above.
In a Windows CMD build step the variables are again used like any Windows environment variable: %VAR%.
I am trying a bit of experiments with airmon-ng script in Linux. Meanwhile i want to redirect output of a process "airodump-ng mon0" to a file. I can see the instantaneous output on the screen. The feature of this process is that it won't stop execution(actually it is a script to scan for AP and clients, it will keep on scanning) unless we use ctrl+c.
Whenever i try
airodump-ng mon0 > file.txt
i won't get the output in the file.
My primary assumption is that the shell will write it to the file only after completing the execution. But in the above case i stopped the execution(as the execution won't complete).
So to generalize i can't pipe the output of a running process to a file. How can i do that?
Or is there any alternative way to stop the execution of the process(for example after 5 seconds) and redirect the current output to a file?
A process may send output to standard output or standard error to get it to the terminal. Generally, the former is for information and the latter for errors, but in some cases, a process may mix them up.
I'm supposing that in your case, the standard error is being used. To get both of these to the output file, you can use:
airmon-ng mon0 > file.txt 2>&1
This says to send standard output to file.txt and to reroute 2 (which is the file id for standard error) into 1 (the file id for standard output) so that it also goes to the file.