Adding my own wiki to webserver on B3

[Cheeseboy]

Hmm,

I think it should look like this:

Code: Select all

-rw-r--r-- 1 www-data users ...

That is the user should be 'www-data' and the group should be 'users'.
The permissions should be set to 644 (as above).

Not sure if this is what is causing your problems but the current settings are definitively weird.

Best regards,

Cheeseboy

[spaceuser]

I wonder, could wrong permissions on home folder be the problem? Just now it is:

Code: Select all

drwxrwx---  13 root users  4096 Sep  7 22:15 home

What should it be?

I have now set /home/web and below to 644, to "www-data" in the group "users", That alone, didn't change anything about the problem to reach http://<mydomain>/index.html or http://<mydomain>/dokuwiki/index.html.

The main focus now should be to have it as it was in the beginning when surfing to http://b3.local or http://<mydomain> was redirected to http://b3.local/admin/ or http://<mydomain>/admin/, as it showed the text "Redirecting ..." for a few seconds. When that work, I think it will work with my subfolder, dokuwiki as well. Until then I'm stuck.

If anyone have any thoughts, please let me know.

[Ubi]

peoples, three things

1) do NOT mess around with permissions in home. It will come back to haunt you
2) do NOT place a DocumentRoot of a webserver in /home. You are certain to get permissions error. If you do not get permissions error, you ignored rule #1 and you also weakened the security of your system
3) If you want to know if your webserver cannot access the file because of system settings or because of settings inside httpd.conf, do not randomly mess with permissions until it works. TEST for it to work.
It's really simple: become the webserver and see if you have access

Code: Select all

su -s /bin/bash www-data
cd /location/of/documentroot/
ls
cat index.html

If you manage to read index.html as the www-data user within the shell system, then the system permissions are OK. However, there's also limitations in the apache config. Work on those.

[spaceuser]

Interresting!

I use the default DocumentRoot, which is /home/web

I did follow your example above, but it failed on:

cd /home/web/

Received;

Code: Select all

bash: cd: /home/web/: Permission denied

It's strange though, since a ls -l /home gives:

Code: Select all

drw-rwSr-- 3 www-data  users  4096 Sep 19 09:27 web

Now I'm even more lost...

LATER:
Now it works!
At first I did try the four steps from Ubi above but on the /var/www/ folder and the index.html file that was there already, and it works. The www-data user have access to that file and folder and below. But that's also strange since the owner is root and the group is root as well. But I'm glad that it works. So now I have changed the DocumentRoot in /etc/apache2/sites-available/@bubba file to /var/www/.

Many thanks Ubi for the tip!

[ryz]

The web dir is missing the execution bit for the www-data user. To be able to access stuff in an directory you need to have execution permission on that directory read permission is not enough. The execution bit is set for the group users or rather the "set user or group ID on execution" bit . It seems that the use www-data does not belong to the group users. At least it does not do that on my B2 system.

[Ubi]

apache should not belong to users. Users are a private bunch. Apache is fore-front public and should be isolated as much as possible. If you want to mingle, create a special group to preserve security.

[ryz]

Yes sorry I should have stated that it is a good thing that the www-data user does not belong to the users group to make sure that they fix the problem correctly that is give the user execute permission on the directories rather then doing something stupid and adding the group users to the www-data user.

[Cheeseboy]

Hmm,
Interesting. I have always had the ownership of of vnstat, roundcube, etc. set to www-data:users
Should the group be root instead?

Cheers,

Cheeseboy

[Ubi]

yes
(except for some temp stuff)

if you make something writable to the webserver, it means that ANY php script on the server (even those in another virtualhost!!) can alter and destroy your files. In a shared hosting environment this means everyone with an FTP account can modify your files. The good news is that this is a great way to get around tight quota limitations on s shared hosting site...