On Tue, 06 Dec 2016 07:47:34 +1030 Tim <ignored_mailbox@xxxxxxxxxxxx> wrote: > You may strike problems using .local as a domain name. If you're just > doing it on the same machine, it'll probably be fine. My machine is not in the LAN, iow. single desktop machine, but this part is anyway easily solvable by using some other aliases... > I do that all the time, but with flat HTML files. As the super-user I > set up initial directory permissions for the web server directory root > that let me create files in there, as myself. Then, I can make files > and directories inside it as my own user ID. That works for me for flat HTML files - /var/www/html is owned by my uid/gid, but have problems serving PHP files. > When using applications to create your files, instead of hand-carving > HTML, you need to configure *those* applications to create files with > the right IDs. It's that middle process (your PHP VCS) that you need > to adjust, not the web server. I see... > On that note, it's not necessary that it creates files owned by you, > it could have its own IDs. > It is, however, very important not to have the files owned by the user > the webserver runs as. OK. Now I've reverted web server to run as apache:apache, but have to solve PHP-related problem... > Generally speaking, files to be served from /var/www/html are served > as files owned by the author, with world-readable permissions (Apache > reads files as "other" users. That was it...In the meantime I also discovered 'official' docs in regard: https://learn.getgrav.org/basics/requirements Now, everything is OK: :-) > While experimenting on an isolated LAN it's easy to think that this > doesn't really matter. But you're learning a bad habit, and not > learning what needs to be done to do this properly in the real world. I agree. > SELinux, if you're using it, is another consideration. Suitable > contexts need to be attributed to the directories and files for Apache > to be able to serve them. I did get some alerts and fixed them. > And again, while it may seem easier to disable SELinux, it's an > important tool for safety of a system, and it's far better to learn > how to do security properly, than abandon it. Especially when you're > playing with dynamically generated content that can be controlled by > outsiders through their webbrowser or malicious robots. I also do not want to disable it. > I wouldn't mess with the apache users (what it runs as), the normal > way it runs works fine. It runs now as apache:apache and everything is good. Thank you for assistance! Sincerely, Gour -- As the ignorant perform their duties with attachment to results, the learned may similarly act, but without attachment, for the sake of leading people on the right path. _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
