On Saturday 15 December 2007, Randy Barlow wrote: > It's not too hard to start a separate instance of apache. You just > copy /etc/init.d/apache2 to, say, /etc/init.d/backuppcApache2. > Likewise copy the /etc/conf.d scripts, and change in the backuppc one > the reference to the httpd.conf to, say, /etc/BackupPC/httpd.conf. > Then, in that .conf file, make sure that you change the things to be > suitable for BackupPC (in particular, get rid of the lines that > include *.conf's from certain directories because these will cause > apache to try and use the same PID! Make sure you specify a new PID > file, among a few other related things) I really don't think the > ebuild should let you use the same instance of apache that > /etc/init.d/apache2 starts, because this would be a security risk.
Well, if you want the setuid behavior (vs. having a separate instance), you have to use the already-existing apache. > For example, I use BackupPC to back up three machines, in their > entirety. That means that backuppc has the rights to change any files > on those three machines. I've also got a webserver running, open to > the internet, on my backuppc machine. If people on the internet can > access backuppc, they can pretty much access all three of those other > machines. But if I run on port 8080, and have that port blocked by a > firewall, this is no longer a concern. Ideally, the box running backuppc does not offer public services and thus should not be exposed to the Internet, so I think that the configuration should not be thought as if it were. Rather, I'd assume that the backuppc box is on the trusted internal lan, with no direct exposure to internet, and configure accordingly (and see below). > The other option is to install password protection by default, but > then you have to have competent users who can change the httpd > passwords. I suppose you could write this as an instruction at the > end of the ebuild. But, are htaccess passwords sent in plaintext? If > so, that's also a major security risk. If you use plain text authentication, yes they are sent as clear text. If you use digest authentication, they are not cleartext but are very easily decoded. Again, the backuppc box is supposed to be inside the trusted lan and not exposed to public internet access. AFAICT, the ebuilds that install files into apache documentroot do not concern themselves with authentication (if nothing else because apache supports zillions of authentication methods, so what the user wants cannot be anticipated), thus apache access control configuration should imho be left out of the ebuild and performed as a subsequent step by the administrator (in some cases it should not even be needed, eg if the only user is the administrator). -- [EMAIL PROTECTED] mailing list
