Allegedly, on or about 05 December 2016, Gour sent: > I'm interested what would be recommended way to configure my desktop > machine as localhost for web (PHP) development? > > I've few entries like: > > 127.0.0.1 foo.local bar.local > > in my /etc/hosts in order to be able to access development sites via > aliases, e.g. http://foo.local/ 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. But if you have other computers on that LAN, some of them *may* only use .local with the type of IPs and name resolution methods intended for that domain (bonjour, zeroconf, 169.254.0.0/16 IP range, non-standard DNS services, non-standard DNS clients, and non-standard name querying ports, etc). But your idea is on the right track (IP, domain name lists, in your /etc/hosts files on all computers in the LAN), just avoid using special reserved names, if they're not appropriate. > Moreover, I'd like to work on the sites under my regular user account > using my uid/gid and keep the development under VCS. 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. NB: If you don't want to change /var/www/html to be owned by you, you can create a sub-directory inside it that is, and work from inside there. 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. 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. > I admit I'm not overly familiar with Apache2 setup and certainly not on > Fedora (on Debian it is configured a bit different) to which I recently > migrated. > > As a temporary workaround to make it somehow work I configured Apache to > run under my uid/gid, put my foo/bar sites under /var/www/html as > VirtualHosts, chown-ed them as uid/gid and chmod-ed to 775. > > Finally, I symlinked them to ~/prj/www/{foo,bar}... 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. example.html -rw----r-- rw- Owner readable and writable, for you to work with your files. --- Group user permissions are generally ignored. r-- Other user's readable permissions pertinent to Apache's access. (Files can have execute bits set, and Apache treats them specially, allowing it to parse the file and insert variables, follow instructions in the HTML, etc.) Directories are similar, with the exception that you also need to add the executable bit to the other permissions. example/ drwx---r-x rwx Owner readable, writable, executable for *you* to work with your files. --- Group user permissions are generally ignored. r-x Other user's readable and directory-accessible permissions pertinent to Apache's access. By and large, suitable permissions (as noted above) are usually created by default, and won't need you to change them. You do not want to create files owned by the apache user, nor change Apache to run as the user that owns the files. This, now, gives Apache permission to write arbitrary files, which is bad security. If you do need to be able to use a webserver to create files, you don't want to let Apache directly do that. There's needs to be a handler, in between, that does this securely. 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. 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. Again, if you create the files in their usual locations, they usually get given the correct SELinux attributes for this to work. What can be a stumbling block is making files somewhere else in the directory tree, and moving them over. The original attributes (which won't allow serving), stay with the files. Copying files works fine, because when they get written to their new location, they get the appropriate (for serving) attributes written to the copies. 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 wouldn't mess with the apache users (what it runs as), the normal way it runs works fine. If your server is public facing, or accessible by untrustworthy devices on your LAN, having it run unusually will open security issues. -- [tim@localhost ~]$ uname -rsvp Linux 3.9.10-100.fc17.x86_64 #1 SMP Sun Jul 14 01:31:27 UTC 2013 x86_64 Boilerplate: All mail to my mailbox is automatically deleted, there is no point trying to privately email me, I only get to see the messages posted to the mailing list. Windows, it's enough to make a grown man cry! _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
