Sponsored Content
Full Discussion: apache issues
Top Forums UNIX for Dummies Questions & Answers apache issues Post 6952 by Neo on Sunday 16th of September 2001 02:34:49 PM
Old 09-16-2001
There is a problem with the ownership (user, group) of the files in the apache distribution. You need to make sure that the user:group ownership of all files are valid system users and that the httpd.conf file is correctly configured as well.

This is outlined pretty well in the Apache book by O'Reilly. Might help to run to your local bookstore and get a copy!
 

10 More Discussions You Might Find Interesting

1. UNIX for Dummies Questions & Answers

issues involving sshd, display and apache.

I have a rather peculiar problem in the past 2 weeks. I have a network setup with a linux box acting as a gateway (It is exposed to the internet). Also, there are 2 additional machines that are connected to the gateway (and are not exposed to the outside world). (The gateway has a NAT setup to... (5 Replies)
Discussion started by: ceeeyem
5 Replies

2. Shell Programming and Scripting

SU issues

Hi, I have automated a build process that does the following activities. 1. check out code from cvs to a specific directory 2. build the revision checked out with 'ANT' 3. integrate the compiled code with the QA/UAT or new environment (/apps/QA or /apps/UAT or /apps/new directory) I... (1 Reply)
Discussion started by: yoi2hot4ya
1 Replies

3. Web Development

Using IP.Board on FreeBSD, having SQL/Apache Issues

Server: FreeBSD 7.2-RELEASE MYSQL Version: MYSQL 5.1.36 PHP Version: 5.2.10 (apache2handler) IP.Board Version: v3.0.2 Safe Mode: OFF For the most part previously IP.Board, forum software, has run fine without any issues. Regular web pages and .php pages seem to load fine without any issues.... (2 Replies)
Discussion started by: Dark Severance
2 Replies

4. Red Hat

Apache / Tomcat / APR Issues [RHEL]

Evening, I'm posting for help here, because I'll be honest I've reached the end of my tether, hopefully someone can give me some assistance and help me maintain a level of sanity... I maintain a number of webservers on RHEL 5 64Bit (Red Hat Enterprise Linux Server release 5.3 (Tikanga)), the... (2 Replies)
Discussion started by: cpickering
2 Replies

5. Emergency UNIX and Linux Support

rm -rf issues

We are using the solaris server and if i am using rm -rf to delete the directories its asking the confirmation for each and every file inside the directory.Is there any way to disable ( should not ask the confirmation) only for a particular session? (12 Replies)
Discussion started by: sureshbabuc
12 Replies

6. UNIX for Advanced & Expert Users

Vsftpd serious issues

hello mighty all there's a problem in vsftpd it allows to delete files which have 000 mode and root:root owner also 400 even with option deny_file={those_files} - still allowed i'm doing it through mc through ftp-shell it's not allowed it's not working if mother-dir have -w and not working... (3 Replies)
Discussion started by: tip78
3 Replies

7. Web Development

Apache write permission issues to another user owned directory

Hi I am trying to make a web program which is command line equivalent. i have done the coding in cgi program in perl and html for basic forms to take inputs. when i ran the program from web application i see permission denied messages. after analyzing i found apache is running as wwwrun which... (2 Replies)
Discussion started by: rakeshkumar
2 Replies

8. Web Development

Apache module development on apache 2.2

Hi, I'm new to developing modules for Apache. I understand the basics now and can develop something simple which allows a 'GET' request to happen, but what I want to do is actually 'POST' information to my site. I know the basic POST Request works and I can see that it is post by looking at... (2 Replies)
Discussion started by: fishman2001
2 Replies

9. Red Hat

Process not running: /opt/java15/jdk/bin/java -classpath /opt/apache/apache-ant-1.7.0-mod/lib/ant-la

Have no idea on what the below error message is: Process not running: /opt/java15/jdk/bin/java -classpath /opt/apache/apache-ant-1.7.0-mod/lib/ant-launcher.jar org.apache.tools.ant.launch.Launcher -buildfile build.xml dist. Any help? (3 Replies)
Discussion started by: gull05
3 Replies

10. Linux

Apache httpd configuration - Issues with APR

Hi I have tried setting up of Apache http server - httpd-2.4.25. During configuration, I understand it needs APR to be setup. Hence I have downloaded APR & APR-Util. Performed, tar xvfC apr-1.5.2.tar /root/httpd-2.4.25/srclib/apr What is happening is there is another directory... (1 Reply)
Discussion started by: videsh77
1 Replies
Apache::TestRun(3)					User Contributed Perl Documentation					Apache::TestRun(3)

NAME
Apache::TestRun - Run the test suite SYNOPSIS
DESCRIPTION
The "Apache::TestRun" package controls the configuration and running of the test suite. METHODS
Several methods are sub-classable, if the default behavior should be changed. "bug_report" The "bug_report()" method is executed when "t/TEST" was executed with the "-bugreport" option, and "make test" (or "t/TEST") fail. Normally this is callback which you can use to tell the user how to deal with the problem, e.g. suggesting to read some document or email some details to someone who can take care of it. By default nothing is executed. The "-bugreport" option is needed so this feature won't become annoying to developers themselves. It's automatically added to the "run_tests" target in Makefile. So if you repeateadly have to test your code, just don't use "make test" but run "t/TEST" directly. Here is an example of a custom "t/TEST" My::TestRun->new->run(@ARGV); package My::TestRun; use base 'Apache::TestRun'; sub bug_report { my $self = shift; print <<EOI; +--------------------------------------------------------+ | Please file a bug report: http://perl.apache.org/bugs/ | +--------------------------------------------------------+ EOI } "pre_configure" The "pre_configure()" method is executed before the configuration for "Apache::Test" is generated. So if you need to adjust the setup before httpd.conf and other files are autogenerated, this is the right place to do so. For example if you don't want to inherit a LoadModule directive for mod_apreq.so but to make sure that the local version is used, you can sub-class "Apache::TestRun" and override this method in t/TEST.PL: package My::TestRun; use base 'Apache::TestRun'; use Apache::TestConfig; __PACKAGE__->new->run(@ARGV); sub pre_configure { my $self = shift; # Don't load an installed mod_apreq Apache::TestConfig::autoconfig_skip_module_add('mod_apreq.c'); $self->SUPER::pre_configure(); } Notice that the extension is .c, and not .so. Don't forget to run the super class' c<pre_configure()> method. "new_test_config" META: to be completed Persistent Custom Configuration When "Apache::Test" is first installed or used, it will save the values of "httpd", "apxs", "port", "user", and "group", if set, to a configuration file "Apache::TestConfigData". This information will then be used in setting these options for subsequent uses of "Apache-Test" unless temprorarily overridden, either by setting the appropriate environment variable ("APACHE_TEST_HTTPD", "APACHE_TEST_APXS", "APACHE_TEST_PORT", "APACHE_TEST_USER", and "APACHE_TEST_GROUP") or by giving the relevant option ("-httpd", "-apxs", "-port", "-user", and "-group") when the "TEST" script is run. To avoid either using previous persistent configurations or saving current configurations, set the "APACHE_TEST_NO_STICKY_PREFERENCES" environment variable to a true value. Finally it's possible to permanently override the previously saved options by passing "-save". Here is the algorithm of how and when options are saved for the first time and when they are used. We will use a few variables to simplify the pseudo-code/pseudo-chart flow: $config_exists - custom configuration has already been saved, to get this setting run "custom_config_exists()", which tests whether either "apxs" or "httpd" values are set. It doesn't check for other values, since all we need is "apxs" or "httpd" to get the test suite running. custom_config_exists() checks in the following order lib/Apache/TestConfigData.pm (if during Apache-Test build) , ~/.apache-test/Apache/TestConfigData.pm and Apache/TestConfigData.pm in the perl's libraries. $config_overriden - that means that we have either "apxs" or "httpd" values provided by user, via env vars or command line options. 1 Building Apache-Test or modperl-2.0 (or any other project that bundles Apache-Test). 1) perl Apache-Test/Makefile.PL (for bundles top-level Makefile.PL will run this as well) if $config_exists do nothing else create lib/Apache/TestConfigData.pm w/ empty config: {} 2) make 3) make test if $config_exists if $config_overriden override saved options (for those that were overriden) else use saved options else if $config_overriden save them in lib/Apache/TestConfigData.pm (which will be installed on 'make install') else - run interactive prompt for C<httpd> and optionally for C<apxs> - save the custom config in lib/Apache/TestConfigData.pm - restart the currently run program modperl-2.0 is a special case in (3). it always overrides 'httpd' and 'apxs' settings. Other settings like 'port', can be used from the saved config. 4) make install if $config_exists only in lib/Apache/TestConfigData.pm it will be installed system-wide else nothing changes (since lib/Apache/TestConfigData.pm won't exist) 2 Testing 3rd party modules (after Apache-Test was installed) Notice that the following situation is quite possible: cd Apache-Test perl Makefile.PL && make install so that Apache-Test was installed but no custom configuration saved (since its "make test" wasn't run). In which case the interactive configuration should kick in (unless config options were passed) and in any case saved once configured. $custom_config_path - perl's Apache/TestConfigData.pm (at the same location as Apache/TestConfig.pm) if that area is writable by that user (e.g. perl's lib is not owned by 'root'). If not, in ~/.apache-test/Apache/TestConfigData.pm. 1) perl Apache-Test/Makefile.PL 2) make 3) make test if $config_exists if $config_overriden override saved options (for those that were overriden) else use saved options else if $config_overriden save them in $custom_config_path else - run interactive prompt for C<httpd> and optionally for C<apxs> - save the custom config in $custom_config_path - restart the currently run program 4) make install Saving Custom Configuration Options If you want to override the existing custom configurations options to "Apache::TestConfigData", use the "-save" flag when running "TEST". If you are running "Apache::Test" as a user who does not have permission to alter the system "Apache::TestConfigData", you can place your own private configuration file TestConfigData.pm under "$ENV{HOME}/.apache-test/Apache/", which "Apache::Test" will use, if present. An example of such a configuration file is # file $ENV{HOME}/.apache-test/Apache/TestConfigData.pm package Apache::TestConfigData; use strict; use warnings; use vars qw($vars); $vars = { 'group' => 'me', 'user' => 'myself', 'port' => '8529', 'httpd' => '/usr/local/apache/bin/httpd', }; 1; perl v5.12.1 2008-02-25 Apache::TestRun(3)
All times are GMT -4. The time now is 11:36 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy