Hi everybody, i am trying to upload perldesk to one of my subdomains. after setting it up, it dosent work. after beating my head over the server found that "if i disable suexec it works but if i enable, it dosent"

So, when i browse my suexe_log i have these lines repeated all over..what does this mean and how do i get over installing perldesk with suexec enabled ?

My server is Linux 7.3 WHM/Cpanel ver 5

error: file is writable by others: (/home/test/public_html/helpdesk/cgi-bin/install.cgi)

[2002-09-14 10:57:46]: error: target uid/gid (32004/32004) mismatch with directory (32009/529) or program (32009/529) or trusted user (0/10)

[2002-09-14 10:57:51]: info: (target/actual) uid: (test/test) gid: (test/testl) cmd: install.cgi

Set the .cgi files to 755 chmod and make sure the right user name and group for the .cgi script.

Hi,
All the .cgi files have permissions 755, and user name and group names are also correct !!

but no luck !!

For some reason I have found that suEXEC doesn't like when scripts are run from the root cgi bin directory. So what I would do is put the perldesk files in a helpdesk directory which is in your cgi-bin.

For example
/home/test/public_html/cgi-bin/helpdesk/install.cgi

-Steven

error: file is writable by others:

I don't think it's 755.

Try to execute the .cgi file through shell using 'perl' and see if it gives any errors. Also make sure you got the MD module installed for Perl.

All the .cgi files have permissions 755, and user name and group names are also correct !!


"test" is your username for your scripts?

yeh test is the user name for the script
"/home/test/ "

and how do i test it with Perl ..what is the sytax for it ?

Thanks

perl /home/test/public_html/cgi-bin/helpdesk/install.cgi

In the terminal.

perl /home/test/public_html/cgi-bin/helpdesk/install.cgi

what is it that i should see after i have punched in those lines ?

Thanks

What the error message is telling you is that the script is owned by a different user than the owner of the directory that it resides in.

As insiderhosting suggests, it's easier to get Perldesk working if the cgi scripts are NOT in the cgi-bin directory - but the real reason for this is that the scripts need to load all the images that come with Perldesk, and suexec will not allow images or html code to be loaded from the cgi-bin directory.

To run cgi scripts from outside the cgi-bin directory requires you to set the AddHandler cgi directive in httpd.conf and restart Apache.

Your other error messages are very explanatory; cgi scripts should be chmod 755 (a world writable cgi script could be modified to do something entirely different from its intended purpose - big security hole!). And the uid:gid MUST match that of the site and the directory in which they reside, and the suexec_log is telling you that this is not the case:

uid: (test/test) gid: (test/testl)
uid/gid (32004/32004) mismatch with directory (32009/529) or program (32009/529)

The uid:gid have nothing to do with the name of the directory, but rather its ownership. Try the shell command ls -l and it will show you ownership (example from my Perldesk install):

-rwxr-xr-x 1 outsourc psacln 3772 Sep 11 22:03 install.cgi

You really have to run the install "for real" from a browser, but if it runs from the shell, what you'll see is a bunch of generated html code dumped to stdout.

Getting around the allowing images in suExec executable directories is easy once install.cgi has been ran, as the images location is defined in the mySQL database...
Just log into mySQL with the user you use for Perldesk, and issue the following update statement after opening the database:
UPDATE settings SET imgbase ="http://www.domain.com/images";
or something similar.

Make sure you have the correct User and Group directives in your VirtualHost setup, also.

Mine installed with suEXEC enabled, and is working great. I didn't put perldesk in my regular cgi-bin though. I put perldesk in its own directory like so

/home/user/public_html/perldesk

and left everything in the sub-directories just like they were.

Did you create a database with mySQL?

Did you add a user to that database?

Did you add that same user to your access list?

Just mentioning some things to check. Hope it helps ya!