I am working on URL-rewrite module of Apache web server. To start with I am not able to configure the same for Windows7. Moving forward, my exact problem statement is -
I have a webapp for which i need to set a cookie everytime a user visits my app. Once the cookie is set I need to read it next time the user visits and modify my URL according to that. I need to set/read the cookie in perl.
I am completely new to perl and Apache Web server.
Well, it depends.
Here are a few ways:
Plain old CGI
CGI::Cookie
If using mod_perl under Apache 1.3.x: Apache::Cookie
If using mod_perl2 under Apache 2.x: Apache2::Cookie
Related
I am trying to integrate Nagios with SimpleSAMLPHP for SingleSignOn company wide.
I have installed simplesaml and Nagios on apache.
Looking out for configuration settings wherein I can specify SAML settings for Nagios.
Has anyone worked on it?
I don't think it's possible to do this without setting the Apache REMOTE_USER variable. The Nagios server is rendered by php and cgi scripts. The php scripts have a user variable attached to the Apache server's REMOTE_USER, and this can be removed to substitute for any other php variable. BUT, most of the functionality and restrictions are being processed in the cgi scripts.
Based on this issue on the Nagios Core GitHub repo, it doesn't look like they are planning on offering any other methods of passing information to the cgi scripts. Nagios X doesn't appear to offer any options either based on this forum post
For authentication in Nagios Core these may be the best options:
Continue using Htaccess Authentication
Wrap the entire application within another to protect it (but you lose per-user privileges)
Manually change the Apache REMOTE_USER variable when someone logs in (maybe a security risk if at all possible)
Migrate to Icinga, which does offer more authentication options
At my place of employment, we will likely be using #3 or #4 based on what's possible and more secure.
Hello I experimenting some small things with Mojolicious and I have the following question:
What happens when a request is received ?
Is there some caching like in modperl or is the code compiled each time ?
It depends on the server it runs under.
If you use a pre-forking app server or fastcgi server then you'll get one or more processes re-used for multiple requests.
You can run a simple CGI, launching the script for each request, but it wouldn't be common.
Deployment options are in the manual.
Can someone explain the live cycle for a request in a Perl Dancer application starting from the server accepting the request. Does the application stay in memory like FCGI or does it have to be loaded for every request?
When using CGI, the application must be loaded with each request. FCGI, like you said, will keep the application running. Here's the lifecycle for CGI:
loads the perl runtime
loads necessary modules
configures the application
sets up all routes (not just the one needed)
finds the correct route and handles the request.
exits
When using FCGI steps 1-4 are done at load time. So if you are running with apache, when apache is started so is the perl runtime for your application. You are left with just step 5. Requests respond much faster when using FCGI.
Nowadays, many web shared webhosts support FastCGI, it's just a matter of configuring it correctly.
I host my Catalyst web application with Apache2 and ModPerl. The web application uses the Log4perl modul to generate logfiles.
The problem is that only log entries are generated when the apache service is starting. Afterwards no new entries were generated.
If I use the integrated development server of catalyst instead, log entries are generated normaly.
I already checked the access rights and these seem ok: the apache process is owner and can write.
Anyone a idea what causes this problem???
This is my log4perl config:
log4perl.logger.myapp=INFO, LOGFILE
log4perl.appender.LOGFILE=Log::Log4perl::Appender::File
log4perl.appender.LOGFILE.filename=myapp.log
log4perl.appender.LOGFILE.mode=append
log4perl.appender.LOGFILE.layout=PatternLayout
log4perl.appender.LOGFILE.layout.ConversionPattern=[%d] [%p] %m%n
I setup a test application running on Apache2 and mod_perl and I got this to work. Here were the notes that I took about it.
I used Log::Log4perl::Catalyst to do the logging within Catalyst. You mentioned using Log4perl, but I didn't know if you were using the Catalyst extension or not. In my main package, I had these lines:
use Log::Log4perl::Catalyst;
...
__PACKAGE__->log(Log::Log4perl::Catalyst->new('/full/path/to/l4p.conf'));
I did have to specify the full path to the log configuration file. I added a few logging statements to make sure that worked.
I used your sample above, but I did change one thing. I had to specify a full path to the log location again:
log4perl.appender.LOGFILE.filename=/full/path/to/myapp.log
Once I did those things, hitting the main site updated the log file.
I am trying to connect to an external SOAP service using PHP and have written a small php test script that just connects to the service and performs a simple request to check everything is working.
This all works correctly but when I run via a browser request, it is very slow taking somewhere in the region of 40s to establish the initial connection. When I do the same request using the exact same script on the command line, it goes through straight away.
Does anyone have any ideas as to why this might be?
Cheers
PHP caches the wsdl in /tmp. If you run from the command line first, the cache file will be owned by whatever user you're running the script as, and apache won't be able to read the cache. The wsdl will have to be downloaded and parsed every time which will be slow.
Check the permissions of /tmp/wsdl*.
Maybe external SOAP service trying to check your IP, and your server has ICMP allowed, when your local network - not.
Anyway, this question might be answered more clearly by administrator of external SOAP service :)
Is there a difference between the php.inis that are being used?
On a standard ubuntu server installation:
diff /etc/php5/apache2/php.ini /etc/php5/cli/php.ini
//edit:
Another difference might be in the include paths. Had this trouble myself on a local test server, it didn't actually use the soap class that was included (it didn't include anything, because the search paths weren't valid), but it included the built-in soap_client class.