[HOWTO] mod_ruid2

Ooops, I have a stupid warning !

One customer uses ZenCart, and I have this message

attention : il est possible d'écrire dans le fichier de configuration : /home/username/domains/userdomain.com/public_html/zen-cart/includes/configure.php. C'est un risque potentiel de sécurité- Indiquez les bonnes permissions sur ce fichier ! (Lecture seule, souvent avec un CHMOD 644 ou 444). Vous devrez peut-être utiliser votre panneau/gestionnaire de fichiers ou FTP pour changer les permissions efficacement. Entrez en contact avec votre hébergeur pour de l'aide.
Click to expand...

Sorry, it's in french ! But 644 is too high for zencart.
I put it to 444, and warning disappears.

Is it possible, from admin panel in zencart, to overwrite config file, even if 444 instead of 644 ?
 
444 is just read, panel would not be able in any way to write config.php with those permission.

usually is used cause the config.php file once "set" is not needed to edit anymore.. so, use 644 during install for let it write on it, and move to 444 once install done...

Regards
 
Worked flawlessly however, as I said in this thread - folders are changed to 711, however, most scripts recommend 755 - this is a bit confusing to the client.

Also, did/does anyone else get the same error from mod_security?
 
seoguru said:
Any sense to use it if I have Apache configured as MPM -worker?
Click to expand...
Doesn't matter I don't think, but I would recommend using mod_php and mod_ruid2 though, my client is as happy as Larry now he can now install Wordpress stuff without errors.
 
2 things :

1- I try to reach : http://IP/~username/ (http://87.98.153.75/~bob/)
Forbidden

You don't have permission to access /~bob/ on this server.

Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request.
Apache/2 Server at 87.98.153.75 Port 80
Click to expand...

2- there is a small problem, when we change permission.
All files are checked and move to 644

But some files have to stay in 755 (like cgi)
I have some files, without extension (like request or answer) that required to stay in 755.
So I think all files with 755 must stay in 755. And no be turned to 644.

Thanks if someone has a solution for my 1st problem

Some new details
/home/username is chmod 710
if I modify to 711, I can access to http://IP/~username/

In another server, without mod_ruid2, I can access to http://IP/~username/ even with chmod 710
 
Last edited:
Can someone explain why this is added to the config:

RGroups apache

This means apache has access to the dir/files? or..

Thanks in advance for reply
 
Hello Guys,

Just one little question, what about restore of users backups from non mod_ruid servers ?

EG : I have a lot of legacy accounts on a Apache1.3 / PHP4 servers, I want to move them to the new server but I wonder if the httpd.conf of the virtualhosts will be rewritten
 
Hello,

All httpd.conf files are written based on the templates.
If you're using apache 2, the templates are:
virtual_host2.conf

If apache 1.3:
virtual_host.conf

Related:
http://help.directadmin.com/item.php?id=244

If you've got any custom settings in:
/usr/local/directadmin/data/users/username/domains/domain.com.cust_httpd

then that file is inserted into the |CUSTOM| token of the above template.
The cust_httpd file is maintained over restores, if done at the Admin Level.

Note that the templates are taken from the data/templates/custom folder, if they exist there. The custom templates override the default ones, if they exist.

John
 
I hav problems with this part:

Code: 
cd /usr/local/directadmin/scripts && ./set_permissions.sh user_homes
find /home/*/domains/*/public_html -type d -print0 | xargs -0 chmod 711
find /home/*/domains/*/public_html -type f -print0 | xargs -0 chmod 644
find /home/*/domains/*/public_html -type f -name '*.cgi*' -exec chmod 755 {} \;
find /home/*/domains/*/public_html -type f -name '*.pl*' -exec chmod 755 {} \;
find /home/*/domains/*/public_html -type f -name '*.pm*' -exec chmod 755 {} \;
cd /usr/local/directadmin/data/users && for i in `ls`; do { chown -R $i:$i /home/$i/domains/*/public_html;}; done;


exact to mean with

find /home/*/domains/*/public_html -type f -name '*.cgi*' -exec chmod 755 {} \;
find /home/*/domains/*/public_html -type f -name '*.pl*' -exec chmod 755 {} \;
find /home/*/domains/*/public_html -type f -name '*.pm*' -exec chmod 755 {} \;

a get error like -exec needs an argument.


p.s. I`m running on Debian 5.0
 
adding mod_ruid2 to custom build?

i read on page 6 idea's to add mod_ruid2 to the custom build.. is this still the plan?

Thx

soul:confused:
 
soulshepard said:
i read on page 6 idea's to add mod_ruid2 to the custom build.. is this still the plan?

Thx

soul:confused:
Click to expand...

Since mod_ruid2 can be used only on Linux, and Directamin supports FreeBSD (mod_ruid2 can not be used on FreeBSD), I guess, custombuild won't support mod_ruid2.
 
Mod Ruid outside of document root

Hi all,
I am quite new to Mod_Ruid2. I have a working server and need to migrate a suPHP enviroment into a Mod_Ruid enviroment.

The problem I encounter is the following:
Code: 
Warning: require_once(/home/user1/domains/domain1.com/JPA/dbsettings.php) [function.require-once]: failed to open stream: Permission denied in /home/user2/domains/domain2.com/private/configuration.php on line 30

Now I tried the permision fix, and this seems to fix the issue for a single pageload. However after that it falls back into the permission denied error.

I don't get it why this is happening.
First guess was some sort of custom caching by the script doing a wrong chmod.
This is however not part of the "cross domain webapplication".

Now is my second guess that it happend because a lot of the files are located in a directory that is on the domain root directory (so not under the public_html directory. )
These files are prepanded by htaccess in the main document root.

Can anyone explain me how mod ruid is handled in this case?
Is there perhaps an rights issue and is per requests changing rights outside the public_html directory?

Hope someone can give me an insight.
 
In the end I made the following (ugly) fix.
Chmod the domain directories for the target user (main application user) with read all access, and this did the trick.
 
post a ls -l of the directory, with mod_ruid it should be owned by user:user with 755 permission (directory) and 644 (files).

Regards
 
You must log in or register to reply here.
Back
Top