Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]
Hans de Graaff wrote: A possible solution would be for you (or someone) to become a proxy maintainer, meaning that you'd get the bug reports and provide new ebuilds, and a developer (most likely someone from the backup herd) would review it and put it in the tree. Hi Hans, thanks for the reply! Being a student, I will soon have some time to help out, so this might be a good thing for me to do. How does one become a proxy maintainer? Should I just write [EMAIL PROTECTED] One of the challenging things about the BackupPC ebuild is that the program needs to be configured to work with its own instance of apache (run as user backuppc), and I think none of the ebuild contributors are all too sure of the standard Gentoo way of doing this. I'd be happy to try and make an ebuild that is a good compromise of the ideas listed in the bug. -- Randy Barlow http://electronsweatshop.com -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]
On Saturday 15 December 2007, Randy Barlow wrote: One of the challenging things about the BackupPC ebuild is that the program needs to be configured to work with its own instance of apache (run as user backuppc), and I think none of the ebuild contributors are all too sure of the standard Gentoo way of doing this. I'd be happy to try and make an ebuild that is a good compromise of the ideas listed in the bug. (Apologies if this has already been mentioned) Another (maybe less intrusive, although slightly less efficient) option is to install the BackupPC_Admin CGI as setuid so that it runs as user backuppc (this is how I run BackupPC-2.1.2-r1). This does not require a different instance of apache, nor it requires to use mod_perl. It does, however, require USE=perlsuid, but this is already supported by gentoo. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]
Etaoin Shrdlu wrote: (Apologies if this has already been mentioned) Another (maybe less intrusive, although slightly less efficient) option is to install the BackupPC_Admin CGI as setuid so that it runs as user backuppc (this is how I run BackupPC-2.1.2-r1). This does not require a different instance of apache, nor it requires to use mod_perl. It does, however, require USE=perlsuid, but this is already supported by gentoo. Yes, I am aware of that. The BackupPC ebuild should support either way, as there is a speedup of about 15x (according to the BackupPC author) when running the webserver as user backuppc. There should be a USE variable controlling this. Also, it is wise to not put backuppc on the same instance of apache so that it can run on a non-standard port. The ebuild by default would not install any password control to backuppc, and so the web interface would be open. -- Randy Barlow http://electronsweatshop.com -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]
On Saturday 15 December 2007, Randy Barlow wrote: Yes, I am aware of that. The BackupPC ebuild should support either way, as there is a speedup of about 15x (according to the BackupPC author) when running the webserver as user backuppc. There should be a USE variable controlling this. Also, it is wise to not put backuppc on the same instance of apache so that it can run on a non-standard port. The ebuild by default would not install any password control to backuppc, and so the web interface would be open. Ah ok, I just thought it would be easier, to get things going and catch up with upstream, to release an ebuild that only supports the suid mode of operation, and then, taking the necessary time, improve it in future releases, rather than supporting all the features right from the beginning. But of course this is just my personal opinion. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]
Etaoin Shrdlu wrote: Ah ok, I just thought it would be easier, to get things going and catch up with upstream, to release an ebuild that only supports the suid mode of operation, and then, taking the necessary time, improve it in future releases, rather than supporting all the features right from the beginning. But of course this is just my personal opinion. Yeah, that's the kinds of differences of opinion that are in the bug report, which is part of what makes this a more difficult ebuild to write. Things like libraries are really easy because it's just a configure make make install, but here you have a lot of configuration files and differences of opinion. I was thinking that a USE variable could be in order here, to support suid and a separate apache instance. Perhaps the variable could be suid? -- Randy Barlow http://electronsweatshop.com -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]
On Saturday 15 December 2007, Randy Barlow wrote: Yeah, that's the kinds of differences of opinion that are in the bug report, which is part of what makes this a more difficult ebuild to write. Things like libraries are really easy because it's just a configure make make install, but here you have a lot of configuration files and differences of opinion. I was thinking that a USE variable could be in order here, to support suid and a separate apache instance. Perhaps the variable could be suid? First, my opinion is that BackupPC, while being a wonderful application, should be split in two parts (by upstream): the daemon, and the web interface, so that they don't have to run on the same machine. Last time I checked, this was not supported, even if the config file seemed to allow for such a config. If this was the architecture, then it could be split into two distinct ebuilds, like eg zabbix or other apps. That said, and things being the way they are now, I'd make the suid behavior the default, since it requires less changes in a running system (a perl reemerge at most - assuming of course apache is already installed). If the user wants the separate apache instance, then he can set, say, USE=private-apache to get it. (btw, do gentoo initscripts support starting multiple instances of a daemon, perhaps under different users and using different parameters? I'd not bet on it, but I may be wrong. If it's not supported, waiting for baselayout to support this may take a long time, so it would be better to release the easier suid version in the meanwhile.) But again, there might be better arguments for doing the opposite. I'll take a look at the b.g.o. page where the ebuild is discussed (last time I checked was long ago, and things have surely evolved by now). -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] Re: [Fwd: Re: Gentoo Rules]
Etaoin Shrdlu wrote: (btw, do gentoo initscripts support starting multiple instances of a daemon, perhaps under different users and using different parameters? I'd not bet on it, but I may be wrong. If it's not supported, waiting for baselayout to support this may take a long time, so it would be better to release the easier suid version in the meanwhile.) 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. 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. 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. -- Randy Barlow http://electronsweatshop.com -- [EMAIL PROTECTED] mailing list
