Apache/websites

[Dungeon-Dave]

Joomla probably needs write access to some directories, so you'll need to "chmod -R g+w public_html" the dir so that Apache can write to it (unless you've set up suPHP)

 

Note: It's not a good idea to delete your DocumentRoot directory - Apache will fail to start if it can't locate this dir. A safer method is to move the content into another dir but leave the DocumentRoot there, then drop a basic index.html placeholder to check Apache is working right.

 

Also: consider downloading and extracting as a non-root user, so you don't have to keep changing permissions/ownership over.

[inittux]

Joomla probably needs write access to some directories, so you'll need to "chmod -R g+w public_html" the dir so that Apache can write to it (unless you've set up suPHP)

 

Note: It's not a good idea to delete your DocumentRoot directory - Apache will fail to start if it can't locate this dir. A safer method is to move the content into another dir but leave the DocumentRoot there, then drop a basic index.html placeholder to check Apache is working right.

 

Also: consider downloading and extracting as a non-root user, so you don't have to keep changing permissions/ownership over.

 

Thanks for the tip will do that next time. Yeah I figured that one out today too after I saw that everything was owned by root lol. Have a normal user account now too.

I gave gave apache(group) 755 rights and then in my mail webfolder where joomla is at. I left the folders at 755 and I change the files to 644 and I think that should be fine.

It's what Joomla-documentation advised.

[Dungeon-Dave]

That will only apply if the directory is apache-owned (gets 7). If it's apache-group, then it'll get 5, meaning it will be unable to write to directories, causing the original problem as before.

[inittux]

That will only apply if the directory is apache-owned (gets 7). If it's apache-group, then it'll get 5, meaning it will be unable to write to directories, causing the original problem as before.

 

Yeah I think I see what you are saying now. so it should be chmod -R 775 /home/username/public_html/example.com When username is in the group apache?

I get what you mean now. When DocumentRoot is in the apache group and you only have 755 permissions apache can only read/execute so when installing a template

cannot move file. As soon as I change it to 775 I can install a template meaning apache can write because the DocumentRoot being in the apache group

and giving apache group(being others) r/w/x permissions. Right?

[inittux]

Just another point, glancing through your files...

 

On my server I have several users what own websites, so I create them a localised webroot area. In everyone's home directory is a "webroot" dir, containing the following:

• htdocs - website content
  
  
  
• etc - any possible additional site-specific config files
  
  
  
• logs - logfiles for this site
  
  
  
• php_temp and php_session - intended for session info and temporary area, set via suPHP, so that any stuff from THIS site doesn't interfere with others'
  
  
  

This way, every user has their website completely isolated from others, and it takes me a matter of minutes to set up additional sites just by duplicating a skeleton directory containing those subdirectories.

 

What would be a smart way to set it up then for multiple/websites/users. Then I would think in apache I would have to make DocumentRoot /home?

I think you mean like this?:

 

/home/user1/public_html/: /htdocs /etc /logs /php_temp /php_session

/home/user2/public_html/: /htdocs /etc /logs /php_temp /php_session

 

But if you place your logs and config files in here can't the outside world get to your this file if your DocumentRoot is /home?

and read these files? or would it be better to setup DocumentRoot in a different way in httpd.conf? Just trying to figure out

how I would be able to do it for multiple users and what would be a smart way. How you said it makes sense but still trying

to figure out if the outside world can read the /logs /etc.... and maybe have to set my DocumentRoot up differently for

multiply users. or would it be best to set the permissions for seperately for these folders /log /etc /php_temp /php_session as 770

and then chmod -R 775 /htocs and leaving user1 and public_html at 775? Just trying to make sense out of so that it's a safe setup.

so that apache can write in /htocs and in /etc /logs/ php_temp /php_session and others can't r/w/x these seperate folders?Sounds logical....in a way

[Dungeon-Dave]

no, DocumentRoot should be /home/user1/htdocs for the first vhost, /home/user2/htdocs for the second,etc

 

The DocumentRoot is set per-vhost.

[inittux]

no, DocumentRoot should be /home/user1/htdocs for the first vhost, /home/user2/htdocs for the second,etc

 

The DocumentRoot is set per-vhost.

 

ah ok. Then it would mean I could comment out this part if you set it for each vhost seperately because it being set in the virtualhost?:

 

# DocumentRoot: The directory out of which you will serve your

# documents. By default, all requests are taken from this directory, but

# symbolic links and aliases may be used to point to other locations.

#

#DocumentRoot "/var/www/html"

 

I did try and comment it out and restart apache, apache restarts with no problems.

So seems if it's set under the vhost itself I can comment out the Main DocumentRoot?

 

<virtualhost yourip:80></virtualhost>

ServerName example.nl

ServerAlias example.net www.example.net

ServerAdmin admin@example.net

DocumentRoot /home/username/htdocs

ErrorLog /var/log/httpd/websites/website1/error.log

CustomLog /var/log/httpd/websites/website1/access.log combined

 

<directory></directory>

AllowOverride None

order allow,deny

allow from all

Options Indexes Includes FollowSymLinks

DirectoryIndex index.php





 

and then place /etc /var etc.. under username?

[Dungeon-Dave]

Yup - that's basically it.

 

Essentially, all Apache directives live in one of four places:

<ol style="list-style-type: decimal">
[*]server-specific (like ServerRoot)


[*]vhost-specific (like ServerName)


[*]directory-specific (like DirectoryIndex)


[*]htaccess - like Allow, Deny - depending upon dir-specific directives.


</ol>


 

Any directive that's "promoted" to a higher level means it's a default for lower down, so if in your main server level you have "DirectoryIndex default.php" then that becomes the default for ALL vhosts, unless it's overridden lower down.

 

This can be a time saver in that it saves having to repeat all identical directives in each and every vhost. However, it can cause problems when someone changes something at server level and causes unexpected behaviour when it propagates down (vhosts relying on default behaviour).

 

This is also the reason why if you don't specify ErrorLog or CustomLog in any vhost, it picks up all the settings from the main config file and EVERY site visit is logged into one big file. I split things out strictly for each vhost, then look at consolidating some things higher up once I have each setting - but that's just me (I'm paranoid at having incorrect settings in Apache, for I know how vulnerable a default state can be!)

 

Note that some directives are Server level ONLY - ServerRoot is one example - it can't exist lower down.

 

All of these directives are explained in the Apache docs. There's a column to the right showing which levels they are permitted/banned.

 

Good to hear you've got it all working!

 

nb: I have a default index page that I tend to pop into directories just to show that a site is working - I'll upload it if you want to use it.

[inittux]

Yup - that's basically it.

 

Essentially, all Apache directives live in one of four places:

<ol style="list-style-type: decimal">
[*]server-specific (like ServerRoot)


[*]vhost-specific (like ServerName)


[*]directory-specific (like DirectoryIndex)


[*]htaccess - like Allow, Deny - depending upon dir-specific directives.


</ol>


 

Any directive that's "promoted" to a higher level means it's a default for lower down, so if in your main server level you have "DirectoryIndex default.php" then that becomes the default for ALL vhosts, unless it's overridden lower down.

 

This can be a time saver in that it saves having to repeat all identical directives in each and every vhost. However, it can cause problems when someone changes something at server level and causes unexpected behaviour when it propagates down (vhosts relying on default behaviour).

 

This is also the reason why if you don't specify ErrorLog or CustomLog in any vhost, it picks up all the settings from the main config file and EVERY site visit is logged into one big file. I split things out strictly for each vhost, then look at consolidating some things higher up once I have each setting - but that's just me (I'm paranoid at having incorrect settings in Apache, for I know how vulnerable a default state can be!)

 

Note that some directives are Server level ONLY - ServerRoot is one example - it can't exist lower down.

 

All of these directives are explained in the Apache docs. There's a column to the right showing which levels they are permitted/banned.

 

Good to hear you've got it all working!

 

nb: I have a default index page that I tend to pop into directories just to show that a site is working - I'll upload it if you want to use it.

 

Sure that would be great :) cuz I'll be playing with apache for a while still go so much more to learn about apache:

 

suPHP

Mod_security

htaccess

 

Mod_proxy

Mod_SSL

Mod_cgi

mod_suexec

etc.

 

But will need to take my time to figure those out. cuz I took a glance at apache documentation but

seems kind of tricky/complicated to understand.

[Dungeon-Dave]

suEXEC works like suPHP, but for cgi-bin executables. I don't allow cgi-bin on my servers (am wary of permitting mod_perl in many cases) so don't use it.

 

mod_ssl is for SSL-enabling sites. Once you've got one working, it's a simple matter to duplicate the template for other sites. Just note that you can't SSL-enable vhosts, you can only ssl-enable the IP.

 

mod_proxy I don't use, unless I'm using mod_rewrite (which requires mod_proxy). Again, I found this fairly easy to set up, but it helped me going through the rigmarole of suPHP first so all files apache were writing were user-owned, not apache-owned.