- - wrote: > it's the first time I am not using Debian packages and > I have several questions regarding the correct use of > paths and permissions. Cherokee runs under www-data:www-data. I have no experience with Cherokee but let me try to help with the issues and questions in general. > I build Cherokee Web Server from source and there are > some differences between that and the package installation: Sure. > - Package: Uses /etc/cherokee/cherokee.conf and /var/www > - Source: Uses /usr/local/etc/cherokee.conf and /usr/local/var/www > - Question: While somehow the path of the config file looks > reasonable, I am not sure if it's common practice > to have the www-dir in /usr/local? It is general practice that packaged things go in /etc and /usr such as /etc/$pkgname, /usr/bin and /usr/lib while locally compiled software would go into /usr/local such as /usr/local/etc/$pkgname, /usr/local/bin and /usr/local/lib. That is the general default values for 99.44% of all configuration scripts. If you grab the source to almost any package and compile it then a location down /usr/local is what you would expect to get from a self-compiled package. That is okay. But you as the local administrator for your system are allowed to make your own decisions about the location for the installation. You may choose to put it elsewhere. That is okay too. You could choose to install it in /etc and /usr for your own package. That is okay. But it is also a little bit harder to keep local stuff separate from system stuff and so many people will choose a different location. A different location like the default /usr/local to keep them separate but if that isn't desired then some people would put these in the /opt and /var/opt trees. Others would put it in the /srv/ (services) tree. Those locations would be okay too. It is an arbitrary choice and you are okay if you choose something unique to your system. It is your system to craft as you wish. On Debian the /usr/local tree is nice because it is group writable by the 'staff' user. If you put yourself in the staff group then you can read, write, modify files in that directory tree as the group staff and then you do not need root to work there. I think that is safer when compiling and installing software from source. (I also find 'adm' to be useful to be able to view system logs so I will suggest it here too even if it isn't related to 'staff' nor /usr/local.) # adduser USER staff # replace USER with your account name # adduser USER adm Then make sure to log out and log back in again. Groups are only assigned to your process at login time. If you have already logged in then you won't get the additional groups. Log out and then log back in again after making the above change. Then you will have the permissions to do this with most software packages that use a standard configure-make process. $ ./configure $ make $ make check $ make install $ make uninstall And if you are not root at those times then you can be assured that if there is a bug in the Makefile then it won't be able to damage the rest of your system because it won't have permissions for any file outside of /usr/local. Therefore I believe it to be safer. > - Package: Had access to some graphs in /var/lib/somewhere. > Can't remember but it just worked. Too vague. Could be anything. But /var/lib/pkgname is the standard system location for writable data from packages. > - Source: Now accesses /usr/local/var/lib/cherokee/graphs > but has no permission. You would be expected to give it permission there. > - Question: I am confused because of the permissions in > /usr/local (2775 root:staff). I would simply change > the permissions of /usr/local/var/lib/cherokee > recursively to root:www-data and chmod it to g+w. > I am not sure if this is common practice or wrong! It is okay. The combination of user:group will depend upon how you wish to work with those files. If you are setting those files up with you as root then what you suggest is okay. If you took my advice above and are setting it up as yourself (or as a specially created non-root user to hold those files) then chown to yourself:www-data. Then the program running as www-data:www-data will have access to the files as the www-data group. Or the reverse where you would chown the files to www-data and the program running as www-data:www-data will have access to the files as the www-data user. User versus group. Similar but different access parts. In summary: Yes! Do 'chown -R root:www-data /usr/local/var/lib/cherokee' and that is okay. Also: 'chmod -R g+ws /usr/local/var/lib/cherokee' too. Note the 's' to keep the set-gid bit set. Working like that with the set-gid bit set would be consistent with UPG (user private groups) and is very commonly done. The /usr/local tree is the root of your local sysadmin tree. You would set it up fully to handle your installed software. That includes setting file owner, group, mode as needed. > 3) Then I have one last question before I press "Send": Shouldn't the > compilation process configure the permissions of folder > that it needs to write in? (looking to question #2.) Perhaps. But local system installation might be different on different systems. Red Hat for example does not implement (by default) the 'staff' UPG process for /usr/local. On RH they set things up where by default you need root everywhere. (Not as nice IMNHO.) The package install script won't know enough about your local system. So some of that you will probably need to set up yourself. It really all depends. And some install scripts will know a very many things about a lot of systems but it is a maintenance burden for the maintainers to keep that data current. Hope this helps, Bob
Attachment:
signature.asc
Description: Digital signature