I'm writing an Apache module and want to get a string with the Apache name version and other details. Much like what gets added to outgoing headers, e.g.:
Server: Apache/2.2.13 (Win32)
I've tried code like this:
apr_table_get(request_rec->headers_out,"Server")
But that doesn't seem to work. Is there an API call I haven't found or am I doomed to get version resource data from httpd.exe?
try this command
apache2 -v
should print out something like this
Server version: Apache/2.2.11 (Ubuntu)
Server built: Mar 9 2010 21:05:51
most unix commands have a -v option
it looks like you are trying to get it from php, the exec command in php will let you run the command on the server
Found it: ap_get_server_version, my HTTPD2 API wrapper was missing this declaration
I'm not sure about Apache modules, but for CGI scripts, the name of the current web server is stored in the SERVER_SOFTWARE environment variable. In Perl, for example, you would use $ENV{SERVER_SOFTWARE} to read it. In C you would use getenv ("SERVER_SOFTWARE").
In order to find out the server software, why not just grep through the Apache source codes to find where this is defined.
Doing this with Apache 1.3.41, I find that it is defined in a file called util_script.c on line 240 as follows:
ap_table_addn(e, "SERVER_SOFTWARE", ap_get_server_version());
It looks like there is a function called ap_get_server_version which returns the value as a string.
Related
I need to configure WireGuard to bring up a VPN on boot on an Embedded Linux device.
My recipe installs a /etc/wireguard/wg0.conf pretty much like the examples found through the Internet.
Then I try to enable the service on SystemD like this on my wireguard.bb:
SYSTEMD_SERVICE = "wg-quick#wg0.service"
SYSTEMD_AUTO_ENABLE = "enable"
But bitbake throws me an error:
ERROR: Function failed: SYSTEMD_SERVICE_my-conf value wg-quick#wg0.service does not exist
I checked the temporary directory and file wg0.conf appears in the correct places but it seems that bitbake's SYSTEMD_SERVICE doesn't know how to expand the "wg0" after # sign.
If I try without the interface name (wg0):
SYSTEMD_SERVICE = "wg-quick#.service"
Bitbake is happy and finalizes my recipe, but it is not what systemd is expecting. Starting a service without an interface makes no sense...
Then I tried another approach and split the "wireguard" package itself from the configuration ("wireguard-conf" package) and added DEPENDS and RDEPENDS on "wireguard".
This got even worse since my wireguard-conf.bb recipe does not contain a "wg-quick#.service" file (it comes from the dependency "wireguard").
Well,
I don't know how to properly fix it and any suggestions will be highly appreciated.
Additional Info
I am using Yocto 2.0.3 in this project (with no hope of updating it).
Thanks to #TomasNovotny comments I managed to compare my "systemd.bbclas" against Github and noticed a change in systemd_populate_packages() that seems to solve the problem.
It works in newer OpenEmbedded (looks like in krogoth, version 2.1 released Apr 2016) and it is introduced by this commit. It works for me in rocko (version 2.4 released Oct 2017). According to j4x's comment, it doesn't work in jethro (version 2.0, Nov 2015).
For older (and currently unsupported OpenEmbeddeds) you can try to backport the patch or handle the symlinks for enabling the service in do_install().
Also please note that SYSTEMD_SERVICE_${PN} variable is package specific, so the _${PN} suffix has to be added (see manual).
I've also tried to enable OpenVPN with my profile (in Yocto rocko) without success.
Finally, I've made it working by providing OpenVPN recipe extension instead of custom one. So, the openvpn_%.bbappend file looks like:
inherit systemd
SYSTEMD_SERVICE_${PN} = "openvpn#clientprofile.service"
SYSTEMD_AUTO_ENABLE = "enable"
do_install_append() {
install -d ${D}${sysconfdir}/openvpn/
ln -sf /data/etc/openvpn/clientprofile.conf ${D}${sysconfdir}/openvpn/clientprofile.conf
}
As you can see, I'm using a symlink to my profile instead of the normal file. You can install a normal OpenVPN profile file instead of making symlink and it also works fine.
I'm able to start the HipHop VM to use a unix socket. I can accomplish this via:
/usr/bin/hhvm --config /etc/hhvm/server.ini --mode daemon -vPidFile=/var/run/hhvm/pid -vServer.Type=fastcgi -vServer.FileSocket=/var/run/hhvm/hhvm.sock
However, I can't find a reference anywhere with how to set this in the ini file I'm specifying for my config. To use a TCP port the line in server.ini is:
hhvm.server.port = 9000
I've tried both
hhvm.server.filesocket=/var/run/hhvm/hhvm.sock
hhvm.server.socket=/var/run/hhvm/hhvm.sock
Both fail. Anyone know the file setting or where a reference for these settings can be found?
Although I can't find any documentation--they haven't yet written the updated version for the ini file format (as of 2014-05-01): https://github.com/hhvm/hack-hhvm-docs/issues/156
Regardless I figured it out and they confirmed it should be:
hhvm.server.file_socket=/var/run/hhvm/hhvm.sock
It looks like you take the camel case command line argument -vServer.FileSocket and drop the v, lowercase it, split it with underscores instead of camel case.
If y ou follow the above rewrite rules you can convert the old format to the new.
I'm searching to figure out what to put on the the next line of code on https://github.com/jarib/browsermob-proxy-rb:
server = BrowserMob::Proxy::Server.new("/path/to/download/browsermob-proxy")
so what to put on /path/to/download/browsermob-proxy and where is it or how to download and put it there? I'm on windows xp trying to setup and make har file.
path can be found in folder of gems and in my case it is:
'C:/Ruby193/lib/ruby/gems/1.9.1/gems/browsermob-proxy-0.1.3/lib/browsermob-proxy.rb'
The Ruby Browsermob gem is a wrapper to control the proxy written in Java from your Ruby script.
You need to provide the path to the proxy executable, so that the gem can start the server for you.
Example:
browsermob_bin = "/path/to/browsermob-proxy-2.1.4/bin/browsermob-proxy"
server = BrowserMob::Proxy::Server.new browsermob_bin
server.start
You can dowload the proxy binary from here: https://github.com/lightbody/browsermob-proxy/releases
I'm attempting to set up mod_lua module for Apache, but have encountered difficulty regarding accessing third party Lua modules. Say I have a hello_world.lua in Apache's htdocs folder that has something like this:
require "apache2"
function handle(r)
r.content_type = "text/html"
r:write "Hello World from <strong>mod_lua</strong>."
return apache2.OK
end
And I go to "http://localhost/hello_world.lua", that will function as expected. But if I try to add a line such as:
require "socket"
Or
require "cgilua"
I get the following output:
Error!
attempt to call a nil value
However, some modules do work, such as:
require "base"
That functions as expected.
If I navigate to base.lua in the filesystem (c:\program files\lua\5.1\lua\base.lua) and remove this file, then attempt to run my script I get the same error as stated above. So this must be the directory that mod_lua is checking for modules. Modules dlls are not in this folder, instead they are in c:\program files\lua\5.1\clibs\, which I set up the environment variable LUA_CPATH to point to.
Luasocket and cgilua are both present in this folder, yet they cause an error when I try to require them in my script.
From what I can gather, it works fine with any pure lua modules, but anything that has cmodules as well (socket, etc) causes problems.
Additional info:
OS: Windows 7 Home Premium
LUA_PATH = c:\program files\lua\5.1\lua\
LUA_CPATH = c:\program files\lua\5.1\clibs\
Apache version: 2.2.22
mod_lua version: http://www.corsix.org/content/mod-lua-win32#comment-3214
What needs to be done to be able to require modules in scripts run by mod_lua?
It looks like you need to add LuaPackageCPath and/or LuaPackagePath directives to your site configuration (in the global configuration file, or .htaccess, ...).
In your case, I'd assume that
LuaPackagePath c:\program files\lua\5.1\lua\
LuaPackageCPath c:\program files\lua\5.1\clibs\
should do the trick.
Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.