PDA

View Full Version : serwer wide applications


nenad
3rd December 2005, 00:35
....with web-interface. How to install them?

Eg.

monitorix http://www.monitorix.org/ (I manged this to work on previos installation of ISPConfig, now I can't do that again..?)

cacti http://www.cacti.net/

nagois http://www.nagios.org/

all of them are installed by default in var/www/...

falko
3rd December 2005, 01:16
Simply create a new web site in ISPConfig and install these applications in the new web site.

nenad
4th December 2005, 18:51
OK, but when I install "monitorix" it places html files and cgi files into default directories:
(/var/www/html and /var/www/cgi).

Yum or apt-get don't ask me for location to install new applications.
So, I have to manually move them into
/var/www/web7/www directories
(and of course change everything in config files)
# Pathnames
our $BASE_URL="http://noc.homelinux.com" . $ENV{HTTP_HOST};
our $BASE_WWW="/var/www/web7/web";
our $BASE_CGI="/var/www/web7/cgi-bin/";
our $BASE_CGIM="/var/www/web7/cgi-bin/monitorix/";
our $BASE_DIR="/var/lib/monitorix/";


And even after that it won't work.
CGI part. Internal 500 server error.
http://noc.homelinux.com/monitorix/
http://noc.homelinux.com/cgi-bin/monitorix.cgi

I tested application on another pc (there's no ISPConfig installed) and applicatiopn works good.

nenad
4th December 2005, 19:03
For "cacti" server can't find any file, and all of them are there (and php enabled)
http://noc.homelinux.com/cacti/

themachine
4th December 2005, 20:31
For "cacti" server can't find any file, and all of them are there (and php enabled)
http://noc.homelinux.com/cacti/


You need to look in your error logs to see what file it is looking for, and not finding. That will point you in a direction as to where the configuration is jacked.

What version of Debian are you using? Generally when I install webapps through apt it installs to "/usr/share/<app_name>" and then I will need to add something to the apache configuration to find these files... something like:

Alias /cacti "/usr/share/cacti/htdocs"
<Directory "/usr/share/cacti/htdocs">
[insert standard directory babble here]
</Directory>

but I haven't installed cacti through apt...

falko
4th December 2005, 20:40
OK, but when I install "monitorix" it places html files and cgi files into default directories:
(/var/www/html and /var/www/cgi).

Yum or apt-get don't ask me for location to install new applications.

Don't use FC4's packages! They will always be installed in default locations which doesn't work for you.
Use the source packages you can download from the respective web sites, and install them manually.

nenad
4th December 2005, 21:17
I am using FC3 on server (and FC4 and Mandriva on other PC's)

You need to look in your error logs to see what file it is looking for, and not finding. That will point you in a direction as to where the configuration is jacked.

I think that files are found (if I delete them - cgi files - then there is File not found error)

Anyway, in which logs should I look for log errors for "Internal Server Error 500" ?

Apache logs? Where?

(4 days ago I installed this application , and it worked, and now I can't set it up again -- aarrghhh)

when I do:

perl -wc monitorix
it shows me that the script syntax is fine., I guess then that the error is not in perl, and that application works on another PC.

nenad
4th December 2005, 21:26
BTW Which package sources are not compatible?
livna against dag or fresh rpm or...?

falko
4th December 2005, 23:09
BTW Which package sources are not compatible?
livna against dag or fresh rpm or...?
It doesn't have anything to do with the repositories. It's just that the precompiled packages are installed to default directories like /var/www which isn't suitable for you because your web site is in /var/www/web1/web. Therefore you should use the source packages, e.g. for Monitorix: http://www.monitorix.org/monitorix-0.7.12.tar.gz

nenad
4th December 2005, 23:19
BTW Which package sources are not compatible?
livna against dag or fresh rpm or...?

Ok, I will use source package, I just remebered that there is some issue with repositories, and I was wondering do you know in between which two of them. The question is not related to monitorix.

nenad
4th December 2005, 23:48
Again the same:

"Internal 500 server error".files are there where they have to be
It's not File not found error.

How to investigate what causes internal 500 error?

nenad
5th December 2005, 01:29
When I create sample first.pl ---> first.cgi

#!/usr/bin/perl
print "Content-type: text/html\r\n\r\n";
print "Hello, World.";
(which can be executed on another machine, of course, and put him in same directory where is monitorix.cgi (/var/www/web7/cgi-bin/)

it is also NOT executing, and the error is the same:
Internal server error: 500

It seems that Apache do not won't to execute cgi scripts?
(In ISPCOnfig , cgi is ENABLED):eek:

If I try toput that simple script in ANY other web directory -- it's the same: Internal Server Error: 500

nenad
5th December 2005, 03:20
If I do:
tail -f /var/www/web7/log/error.log
output is: ...[client 10.40.242.186] Premature end of script headers: first.cgi

Now, if I delete
#!/usr/bin/perl
from Hello, world script, then output is the same?

tail -f /var/www/web7/log/error.log
output is: ...[client 10.40.242.186] Premature end of script headers: first.cgi

Does that really means that apache don't call perl for executing the cgi scripts?

permissions are set to 755 as they should be, user is apache as it should be...
perl is located in /usr/bin/perl and it is working (if not called from apache)

falko
5th December 2005, 09:53
When I create sample first.pl ---> first.cgi


(which can be executed on another machine, of course, and put him in same directory where is monitorix.cgi (/var/www/web7/cgi-bin/)

it is also NOT executing, and the error is the same:
Internal server error: 500

It seems that Apache do not won't to execute cgi scripts?
(In ISPCOnfig , cgi is ENABLED):eek:

If I try toput that simple script in ANY other web directory -- it's the same: Internal Server Error: 500
Did you try the test files? http://www.howtoforge.com/forums/showthread.php?t=171

Have you made you cgi/pl script executable (chmod 755 or chmod 775)?

Make sure it has Unix linebreaks instead of Windows linebreaks!

You must put cgi/pl scripts in the cgi-bin directory, no other directory will work!

nenad
5th December 2005, 10:21
Did you try the test files? http://www.howtoforge.com/forums/showthread.php?t=171
Yes, I did. Same result. "Premature end of script"

Have you made you cgi/pl script executable (chmod 755 or chmod 775)?
Yes, I tried both 755 and 775

Make sure it has Unix linebreaks instead of Windows linebreaks!
No, there are Unix linebreaks (file was created on FC4 os, using putty and joe editor inside of it. There was no even "W" from windows.

You must put cgi/pl scripts in the cgi-bin directory, no other directory will work!
Yes, of course they were in cgi-bin directory. Otherwise there would be "File not found error" instead of "Internal Server Error", and there wouldn't be "premature end of script" in log files.

I even set up script for "apache user" and "apache group", just in case that suexec directives are set not to execute "root" user group etc.

It is pretty obious that Apache DO NOT execute scripts in cgi-bin.
I can put inside any script, at the begening of the file next line:
"mickey mouse and donald duck are big friends" instead of #!/usr/bin/perl,
and there will be the same error in httpd log file : "premature end of script"

when I chechk each perl script with perl -wc syntax is OK.
when I do perl -w hello_world.pl output is displayed
in my script first.pl there was also print "Content-type: text/html\n\n"; to avoid STDOUT (anyway that's not the case, because there will be a log about STDOUT)

The interesting part is that PHP script won't execute???
In /web directory it is executing with no flaws...

P.S. mod_perl is loaded into apache

info.php and ssi.shtml work in /web directory
*.pl scrpits work inside cgi-bin if they are invoked with "./" or "perl -w"

nenad
6th December 2005, 17:42
Help, please?

Anyone?:confused:

falko
6th December 2005, 18:55
The interesting part is that PHP script won't execute???
In /web directory it is executing with no flaws...


PHP aren't executed in cgi-bin, so that's ok.

Is Perl in /usr/bin/perl? Please post the output of which perl

nenad
6th December 2005, 19:31
[root@noc cgi-bin]# which perl
/usr/bin/perl
[root@noc cgi-bin]#

PHP info is located at: http://noc.homelinux.com/phpinfo.php

(ISPConfig is located also at https://noc.homelinux.com:81)

nenad
6th December 2005, 22:05
I found what is problem.
And I found solution :)
---------------------------------------
tail -f /var/log/httpd/suexec.log
Informed me that there is:
target uid/gid (10005/10007) mismatch with directory or program (48/48)
So, I chechked who is owner of files (user or group) and I found out that it is root, or apache or some '506' (for test files that I downloaded from this forum.

I didn't used built-in ISPConfig FTP or any standalone FTP , so probably because of that owbership was not set to web7_nenad & web7 user/group.

I downloaded files using wget, and I was loged as user 'root' through SSH (putty)
few days ago I used FTP to download/upload monitorix etc., so that's why there was no this kind of problems.

And I login using 'root' instead of username (web7_nenad).
That caused all of the problems becuse of improper file ownership.

-------------------------------------------
So,
in /var/www/html/ is located monitorix (by default rpm installation)

files and direcories from /var/www/cgi-bin/ are moved to
var/www/web7/cgi-bin directory

for all files and directories in var/www/web7/cgi-bin (monitorix.cgi, monitorix) file owbership are changed from root and apache to web7_nenad and web7 (user& group)

I lost few days with this issue, but I learned a LOT about apache, suexec, 500 Internal Server Error etc.

And...
Thanks a lot for your support

Regards,
Nenad

P.S.
test ssi.shtml is now at: http://www.web-hosting-solutions.biz/ssi.shtml
test env.pl is at: http://www.web-hosting-solutions.biz/cgi-bin/env.pl
test phpinfo.php is at: http://www.web-hosting-solutions.biz/phpinfo.php
Monitorix is at: http://www.web-hosting-solutions.biz/monitorix/
(there are still some unresolved issues with creating of images for Monitorix, but that's the problem of Monitorix, and I think I am going to resolve that this night).
update: directory var/www/web7/web/monitorix/imgs also needs to be set as same user/group, in my case: web7_nenad and web7 . So everything works fine now :) :)

cnlnetworks
19th January 2006, 22:27
Install it like normal.

Copy all cgi and web files to the virt user directory you are useing to access it.


then edit the cron file like so: ( this is for me you will have to adjust the rsync line to fit your system. )

vi /etc/cron.d/monitorix


#!/bin/bash
#
# @(#) Fibranet NSP, SL
# Copyright (C) 2005 by Jordi Sanfeliu <admin@fibranet.com>
#

* * * * * root ps -C monitorix.pl --no-headers || /usr/sbin/monitorix.pl update
* * * * * /usr/bin/rsync -av /var/www/html/monitorix/imgs/ /home/www/Dashboard.cnl-networks.net/web/monitorix/imgs
00 00 * * * root /usr/sbin/monitorix.pl collect
01 00 1 * * root /usr/sbin/monitorix.pl report

exit 0

#################################



And so it updates like it wants to and then I rsync the directories.

;)

nenad
26th March 2006, 15:13
What this mean:

Cron <root@web-hosting-solutions> ps -C monitorix.pl --no-headers >/dev/null || /usr/sbin/monitorix.pl update

Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.
Usage: grep [OPTION]... PATTERN [FILE]...
Try `grep --help' for more information.

falko
26th March 2006, 20:59
Maybe the /usr/sbin/monitorix.pl script doesn't make proper usage of the grep command?

nenad
27th March 2006, 08:51
"This is a knowed problem on LVM-based systems not using LVM at all. It
is already fixed on the Monitorix internal version and it will be fixed
as well on the next Monitorix version that I plan to release today Monday."