BackupPC 3.0.0beta0 released on July 11th, 2006
... and BackupPC 3.0.0beta1 released on July 30th, 2006.
... and BackupPC 3.0.0beta2 released on November 18th, 2006
And BackupPC 3.0.0beta3 released also
And BackupPC 3.0 final was also released on January 29th, 2007.
I opened a bug as an ebuild request for 3.0.0 http://bugs.gentoo.org/show_bug.cgi?id=164415
*** Bug 164415 has been marked as a duplicate of this bug. ***
I have been working this morning on an ebuild for BackupPC-3.0.0 and it is very close to working. However, I am not a Gentoo-dev (this is my second e-build ever, and way more complicated than the last!) and so I'm sure there will be many things that need fixing. For one, I am requiring net-www/apache as opposed to some virtual similar to virtuals/mta (is there a virtuals/webServer or some such?). Another problem I perceive with BackupPC is what about upgrades? Typically, if one is upgrading BackupPC, you would tell the script the location of the current config.pl and it will do the rest for you. How do you know in an ebuild if this is an upgrade or a new install, and how do you take appropriate action?
Created attachment 120083 [details] An almost working ebuild with two patches. The ebuild in this archive almost works correctly. Something is still wrong in the configs or the init script, or possibly in backuppc itself (am working with the backuppc mailing list on it!). When you call /etc/init.d/backuppc start, you will see: * Starting BackupPC ... No language setting BackupPC::Lib->new failed [ !! ] This is an issue that another packager for BSD seems to have run into in the past week or two, and so we may be able to work together...
A quick web search gives the following possible answer: http://backuppc.sourceforge.net/faq/debugCGI.html#i_get_the_error_error__unable_to_read_config_pl_or_language_strings____how_do_i_fix_this My recollection from installing 3.0.0 is that file permissions _are_ likely to cause a problem. I've got an install script that encapsulates what I learned while tweaking my install til it worked. I'll upload it in a moment.
Created attachment 120140 [details] script to set permissions after ebuild
Created attachment 120152 [details] ebuild for BackupPC-3.0.0 This ebuild seems to work properly, though I do have some testing to do. I would appreciate any criticisms of my ebuild writing form too as I am new to this! Many thanks to Relson for his help!
Randy, A couple of questions on your ebuild: src_install() has: dodir /etc/backuppc pkg_postinst() has: chown -Rf backuppc:backuppc "${ROOT}/etc/BackupPC" Why $(ROOT) is one but not the other? Why capital letters in one bug not the other? If I recall, backuppc-2.x.y defaults to /etc/backuppc and backuppc-3.0.0 defaults to /etc/BackupPC. For updating from 2 to 3, /etc/backuppc is proper and for a new install /etc/BackupPC is proper. Also src_install() references ${myconf} which appears not to be defined. Can the "$(myconf) || die" be on a separate line from ./configure.pl ???
Created attachment 120166 [details] ebuild for BackupPC-3.0.0 Mr. Relson, thanks for your comments! I fixed the descrepencies with /etc/backuppc and ${ROOT}/etc/BackupPC, making them both ${ROOT}/etc/BackupPC. As for the problem of BackupPC 2.x.y using /etc/backuppc and newer versions using /etc/BackupPC, I'm not sure how to handle that. Is there a test in an ebuild for whether someone is upgrading or not? Can we just not worry about it since 2.x.y never went stable in portage anyway? Another solution is to have BackupPC use /etc/backuppc always, but due to a bug in the configure.pl script this will require patchine the Lib.pm file - not impossible, but just seems like not the optimal route for us to go. Your thoughts? I defined myconf for sure now, and made it so it is not on a separate line from the ./configure.pl; let me know what you think!
Another thought: In order to use the web interface for backuppc, the user will have to do a lot of additional setup work. I personally use a separate instance of apache running on a different port to handle backuppc, just because that makes it easier to have apache running as user backuppc. What I did was to make new init.d and conf.d scripts, as well as another httpd.conf for backuppc. I also setup some htaccess stuff for authentication. How much of this should be left to the user and how much should be done by the ebuild maintainer? Is what the ebuild I've submitted so far does enough? I personally wouldn't mind it adding these additional scripts as a user, because it's less for the user to figure out. We could set up everything and then tell the user to edit the htaccess password file and start the backuppcApache service (or whatever we want to call it) and then they would be on their merry way. Thoughts?
My recollection is that the configure script determines if it's an upgrade or a new installation, hence doesn't need to be told /etc/backuppc or /etc/BackupPC. However, since the ebuild refers to /etc/..., the ebuild needs to test, i.e. if [ -d $(ROOT)/etc/backuppc ] ; then # update ETC="$(ROOT)/etc/backuppc" else # install ETC="$(ROOT)/etc/BackupPC" fi Automatically configuring the web interface would be a good thing. The web interface is a major feature and is needed (at least for restoring files). As the process is also detail oriented it can be difficult for someone unfamiliar with BackupPC and apache. I should be able to some testing of the ebuild this evening.
(In reply to comment #12) > src_install() has: > dodir /etc/backuppc > > pkg_postinst() has: > chown -Rf backuppc:backuppc "${ROOT}/etc/BackupPC" > > Why $(ROOT) is one but not the other? Because you are not supposed to use ${ROOT} in src_* functions; so that was entirely correct. P.S. Please, don't attach tarballs w/ ebuilds, ever. http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3#doc_chap2
Alright, after some time I think I have a decent working ebuild. I am sure though that there are things that should be fixed to be more "Gentooized". There isn't a good way to make it totally "install and use" without the user having to do some configuration, but this is a pretty good shot at it I think. I have several files that go along with the ebuild for the "files" folder too. So here come a bunch of attachments (not in a tarball!)
Created attachment 121984 [details] A proposed backuppc ebuild.
Created attachment 121986 [details] An http password file This files allows the default username of backuppc and password of backuppc to be used to log in to the web interface. Of course, the user can change these passwords after installation, as explained in the postinstall-en.txt.
Created attachment 121988 [details] A conf.d file for a separate instance of Apache for BackupPC's web interface
Created attachment 121989 [details] An init.d script for a separate instance of Apache for BackupPC's web interface
Created attachment 121990 [details] The configuration file for the separate instance of Apache for the BackupPC web interface
Created attachment 121991 [details, diff] A patch to fix the location of the perl interpreter used by the install script
Created attachment 121992 [details] Instructions to the user after the install
Created attachment 122086 [details] An ebuild which dosnt require a seperate instance of apache running Ive written another ebuild that seems to be working nicely for me, which uses the method described here http://gentoo-wiki.com/BackupPC to run the cgi interface on the normal apache server. Its based off the ebuild from a few weeks ago, as i didn't see the new one until just now.
Thomas, a solution using a single instance of Apache would certainly be quite elegant, but the wiki page you referenced still proposed using a separate instance of Apache, and I didn't catch how your ebuild does it with just one (though I admittedly only browsed through it quickly). Does your ebuild automatically set up basic authentication as well so that not just anybody can log on to the backuppc server web interface? If not, perhaps we can combine forces to make a nice ebuild that uses a single instance of apache while also offering basic authentication. Also, my ebuild puts the backuppc data into a new directory, /data/BackupPC, which admittedly is for my own purposes. Is the proper "Gentoo" way of doing it to put it under /var/lib/backuppc? Thanks for submitting your ebuild!
It compiles a little c program which is run by apache as root with the suid bit. The program will then change to the backuppc user and run the cgi perl script. My ebuild does not do authentication. Lets combine, if you want I'll take a look at your new one and merge it with mine. As to where to put the data... No idea, but I don't really like the sound of /var/lib/backuppc as it's not really the first place I'd think to look for it. But I definitely don't like the idea of creating new folders in /. Also generally the folders in my /var/lib don't exceed a few MB, is it going to be a good idea to put several GB in there? And thanks for submitting your ebuild ;-)
Created attachment 122492 [details] New ebuild for backuppc on a single instance of apache So heres the new ebuild, I changed the way the permissions were handled and added a .htaccess (included in next post) for some security and some other stuff. I'm not sure if the .htaccess is working as my apache is a bit fubar atm, so could some one please test it.
Created attachment 122493 [details] A webapp hook to change the premissions of of the backuppc files This is files/fixperms and just sets the suid bit on index.cgi and makes sure the files installed into htdocs have the right permissions.
Created attachment 122494 [details] .htaccess file for the backuppc directory This is files/.htaccess I'm not sure if this is working or not so could someone please look at it, I think it should work but I don't like .htaccess files and they don't like me.
Hi, Just a few comments on how I have BackupPC setup using the existing 2.1.2-r1 ebuild * Apache (single instance) runs as 'apache' and BackupPC runs as 'backuppc'. I use sudo to allow Apache to execute /usr/bin/BackupPC. The relevant configs are : - from /etc/sudoers Defaults !env_reset root ALL=(ALL) ALL apache ALL = (backuppc) NOPASSWD: /var/www/localhost/cgi-bin/BackupPC_Admin - from /etc/apache2/vhosts.d//etc/apache2/vhosts.d/01_backuppc.conf ScriptAlias /BackupPC_Admin /etc/backuppc/backuppc_sudo_wrapper.pl - from /etc/backppc/backuppc_sudo_wrapper.pl #!/usr/bin/perl # exec '/usr/bin/sudo', '-u', 'backuppc', '/var/www/localhost/cgi-bin/BackupPC_Admin' * I'm not too sure about the security merits of this setup up, all I can vouch for is that is works for me. The idea/approach was adopted from the setup instructions for Sympa * For authentication I point Apache to my ldap server - AuthLDAPURL ldaps://ldap.naturesoft.net/dc=naturesoft,dc=net?uid?sub?(objectClass=inetOrgPerson) * Lastly I got caught out by these two bugs : http://bugzilla.padl.com/show_bug.cgi?id=273 http://bugzilla.padl.com/show_bug.cgi?id=309 BackupPC would fail to fork because of a bug in nss_ldap (the server that BackupPC is on is configured with pam_ldap and nss_ldap). My work around was to install stunnel and point /etc/ldap.conf to the unencrypted 127.0.0.1:389 connection. Maybe some of this info is relevant to this ebuild. Regards, Warren.
Thomas, I have tested your ebuild (2007-06-19). First, I think the line 47 is wrong. It should be : if [ "$found" == "" ] ; then and not if [ "$found" != "" ] ; then (Your ebuild never goes out of the while loop). Then, I think there are permission problems, because /usr/local/BackupPC belongs to root. When I start backuppc, I have an error : # /etc/init.d/backuppc start * Starting BackupPC ... Can't create LOG file /var/log/BackupPC/LOG at /usr/local/BackupPC/bin/BackupPC line 1792. And I think the postinstall-en.txt file should be updated. Thanks !
(In reply to comment #32) > Then, I think there are permission problems, because /usr/local/BackupPC > belongs to root. No ebuild should touch /usr/local.
Created attachment 124020 [details] Updated ebuild The permissions on /var/log/BackupPC should now be correct, and I changed the if statement. The ebuild now installs into /usr/BackupPC, is this correct? Also I changed the data dir to /var/lib/BackupPC.
Created attachment 124022 [details] New postinstall-en.txt
Hi, Thanks ! Now backuppc is running, but not the CGI interface. Isn't mod_perl required ? Could you post an example of what you added in httpd.conf ?
(In reply to comment #33) > (In reply to comment #32) > > Then, I think there are permission problems, because /usr/local/BackupPC > > belongs to root. > > No ebuild should touch /usr/local. > You are right ! The problem was that the /var/log/BackupPC directory did not exist.
(In reply to comment #37) > You are right ! The problem was that the /var/log/BackupPC directory did not > exist. So is the backuppc cgi interface working for you now? As I understand it mod_perl shouldn't be needed as its a cgi script so it should fire up what ever is specified in the file, in this case /usr/bin/perl. If you are having problems with the cgi interface I suspect its the .htaccess file I'm not sure if it worked to begin with as I couldn't test it on my server, its a bit fubar. So could someone look at it please to if it works or not. Thanks.
so i'm trying to work out the kinks of this "perlInterpreter.patch" # emerge backuppc -vp These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] app-backup/backuppc-3.0.0 USE="doc samba vhosts" 0 kB [1] Total: 1 package (1 new), Size of downloads: 0 kB Portage overlays: [1] /usr/local/portage localhost work # emerge backuppc Calculating dependencies... done! >>> Verifying ebuild Manifests... >>> Emerging (1 of 1) app-backup/backuppc-3.0.0 to / * BackupPC-3.0.0.tar.gz MD5 ;-) ... [ ok ] * BackupPC-3.0.0.tar.gz RMD160 ;-) ... [ ok ] * BackupPC-3.0.0.tar.gz SHA1 ;-) ... [ ok ] * BackupPC-3.0.0.tar.gz SHA256 ;-) ... [ ok ] * BackupPC-3.0.0.tar.gz size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking BackupPC-3.0.0.tar.gz ;-) ... [ ok ] * Using 102 as the UID for the backuppc user >>> Unpacking source... >>> Unpacking BackupPC-3.0.0.tar.gz to /var/tmp/portage/app-backup/backuppc-3.0.0/work * Applying perlInterpreter.patch ... * Failed Patch: perlInterpreter.patch ! * ( /usr/local/portage/app-backup/backuppc/files/perlInterpreter.patch ) * * Include in your bugreport the contents of: * * /var/tmp/portage/app-backup/backuppc-3.0.0/temp/perlInterpreter.patch-11221.out !!! ERROR: app-backup/backuppc-3.0.0 failed. Call stack: ebuild.sh, line 1621: Called dyn_unpack ebuild.sh, line 753: Called qa_call 'src_unpack' ebuild.sh, line 44: Called src_unpack backuppc-3.0.0.ebuild, line 65: Called epatch '/usr/local/portage/app-backup/backuppc/files/perlInterpreter.patch' eutils.eclass, line 304: Called die !!! Failed Patch: perlInterpreter.patch! !!! If you need support, post the topmost build error, and the call stack if relevant. !!! A complete build log is located at '/var/tmp/portage/app-backup/backuppc-3.0.0/temp/build.log'. AND PATCH COMMAND: patch -p4 -g0 -E --no-backup-if-mismatch < /usr/local/portage/app-backup/backuppc/files/perlInterpreter.patch ================================= missing header for unified diff at line 3 of patch can't find file to patch at input line 3 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |--- configure.pl.old 2007-05-23 06:35:26.000000000 -0500 |+++ configure.pl 2007-05-23 05:51:51.000000000 -0500 -------------------------- No file to patch. Skipping patch. 1 out of 1 hunk ignored I'm thinkin it *might* have something to do with the new capitilization of BackupPC (not backuppc) OR the fact that in the /work directory there is another sub of 'BackupPC' instead of the tar.gz dump. I'm new'ish at ebuilds, still trying to hack out the details, just wanted to post this in-case someone else was seeing this and or working out a fix...
perlInterpreter.patch was a quick patch I made to fix the installer scripts. It was trying to use /bin/perl (doesn't exist in Gentoo) instead of /usr/bin/perl, so my patch just changed the first line from #!/bin/perl to #!/usr/bin/perl. It may not work with ebuilds that others have submitted, but it does work with mine...
ahh, I didn't even see that the last two ebuilds were from diff authors... I'll check the differences between the two and see if I can update the last posted ebuild into working with this patch. I do understand _what_ the patch is doing, i was about 10secs from just deleting it and ln -sf .... perl ;-) figured i'd try to do it the right way for future use... thanks for the postback.
I have installed backuppc using the last submitted ebuild (thanks!). Some small problems i encountered: - net-www/apache ebuild does not exist on my system, changed that dependency to www-servers/apache - in the .htaccess file: <Files ... > does not support multiple arguments for apache 2.0 (I just changed that to two files blocks for both files, there is probably a better way) - i had to make an authUser file, but placing it in /etc/BackupPc as suggested makes it unreadable for the apache server (world permissions on that dir are none). I placed them into another dir (/var/www/localhosts/passwords). - had to change the handler in the .htaccess file to .cgi instead of index.cgi to get it to execute the file - something I didnt know (these ebuild and .htaccess files are somewhat new to me too): i had to set AllowOveride in /etc/apache/vhosts.d/00_default_vhost.conf to 'All' to get the .htaccess file to work ('All' is probably a bit overdone, but you get the idea). Maybe this should be included in the postinstall instructions. the perlinterpreter patch worked for me.
Could the perlinterpreter patch be replaced with a simple sed script?
I have a problem with the ebuild from attachment 120166 [details]. emerge: there are no ebuilds to satisfy "net-www/apache". (dependency required by "app-backup/backuppc-3.0.0" [ebuild]) What's wrong?
Hi Hendrik, net-www/apache changed to www-servers/apache, so just make that change in the ebuild and you will be good to go!
(In reply to comment #45) > Hi Hendrik, net-www/apache changed to www-servers/apache, so just make that > change in the ebuild and you will be good to go! ?? That does not sound like a very smart idea?? But well, I'm not an ebuild expert, so never mind. The install does not really run through, though: * Running //usr/sbin/webapp-config -I -h localhost -u root -d /backuppc backuppc 2.1.2-r1 * Fatal error: Your configuration file sets the server type "Apache" * Fatal error: but the corresponding package does not seem to be installed! * Fatal error: Please "emerge >=net-www/apache-1.3" or correct your settings. * Fatal error(s) - aborting There's net-www again... but anyway: Apache(2!) is installed and running... so there shouldn't be any need to install it... Greetings, Hendrik
Please upgrade your webapp-config and don't clutter this bug with irrelevant stuff.
Created attachment 128335 [details] New backuppc ebuild Ive updated the ebuild to work with the new apache name, changed some permissions and changed the perlInterpreter.patch to a sed command, so perlInterpreter.patch is no longer needed.
Created attachment 128338 [details] New postinstall-en.txt
Created attachment 128339 [details] New .htaccess These are the changes that Marc suggested, Thanks Marc!
Hi, i tried to install the ebuild from 2007-08-16 22:07 with the vhosts use flag set. Accessing http://localhost/backuppc/, I get a Directory listing: [ ] BackupPC_Admin 19-Aug-2007 16:20 3.9K [DIR] backuppc/ 19-Aug-2007 16:21 - [DIR] image/ 19-Aug-2007 16:21 - [ ] index.cgi 19-Aug-2007 16:20 3.2K Accessing BackupPC_Admin, I get You don't have permission to access /backuppc/BackupPC_Admin on this server. The apache log says: (13)Permission denied: file permissions deny server access: /var/www/localhost/htdocs/backuppc/BackupPC_Admin, referer: http://192.168.178.24/backuppc/ Greetings, Hendrik
Created attachment 128674 [details] Updated files/postinstall-en.txt Hi, You need to change the AllowOverride option in /etc/apache2/vhosts.d/00_default_vhost.conf from None to all. I've updated the post-install instructions to say this as well.
(In reply to comment #26) > Thomas, a solution using a single instance of Apache would certainly be quite > elegant, but the wiki page you referenced still proposed using a separate Hi Randy - I have just got backuppc 2.1.2 working at my house and work without realising that someone was getting 3.0.0 ebuild working. Would you like the details of what I found wrong with 2.1.2 ebuild or should i post a separate bug?
I'm not a Gentoo developer, but my guess would be that it would make the most sense to post that in a separate bug report. It might be relevant to this bug anyway though, since the 3.0.0 ebuild was made from the 2.1.2! Honestly though, I've kind of given up on the ebuild route to BackupPC for now and just installed it manually on my machines. I'll probably come back to it in December, but it's just a bit of an odd package and I had trouble deciding how much the ebuild should do, especially with all the apache configuration...
Trying to uninstall the ebuild gives me the following error, any ideas: app-backup/backuppc selected: 3.0.0-r1 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. >>> Waiting 5 seconds before starting... >>> (Control-C to abort)... >>> Unmerging in: 5 4 3 2 1 >>> Unmerging app-backup/backuppc-3.0.0-r1... * WARNING: suid/sgid file(s) with suspicious hardlink(s): * WARNING: '/usr/share/webapps/backuppc/3.0.0-r1/htdocs/index.cgi' * WARNING: See the Gentoo Security Handbook guide for advice on how to proceed. A removal phase of the 'app-backup/backuppc-3.0.0-r1' package has failed with exit value 1. The problem occurred while executing the ebuild located at '/var/db/pkg/app-backup/backuppc-3.0.0-r1/backuppc-3.0.0-r1.ebuild'. If necessary, manually remove the ebuild in order to skip the execution of removal phases.
reassign to maintaier
BackupPC was updated to 3.1.0 on 11-27-2007
(In reply to comment #51) > i tried to install the ebuild from 2007-08-16 22:07 with the vhosts use flag > set. > Accessing http://localhost/backuppc/, I get a Directory listing: You need to install and enable mod_perl
Created attachment 162045 [details] app-backup/backuppc-3.1.0 This is the ebuild for 3.1.0 ... based on 3.0.0 plus few extra dependencies and repoman warnings fixed.
# emerge backuppc-3.1.0 ... * Install completed - success * Running /usr/sbin/webapp-cleaner -p -C backuppc /usr/sbin/webapp-cleaner: line 14: /sbin/functions.sh: No such file or directory /usr/sbin/webapp-cleaner: line 95: einfo: command not found * Adjusting ownership of various things... ... [ ok ] * Please read the documentation * It is important to know that the webserver and the backuppc user * *must* be one and the same # qfile /usr/sbin/webapp-cleaner =app-admin/webapp-config-1.50.16-r1 BTW. Great work! I don't know Gentoo's policy concerning dot files within the "/files" folder, but it might be wise to push ".htaccess" to "htaccess" and then rename the file on install. However, doins might not have any flexibility in this case. <shrugs> feedback?
Following bug is still present in backuppc-3.1.0.ebuild: # emerge -g backuppc ... >>> Installing app-backup/backuppc-3.1.0 * suid/sgid file(s) with suspicious hardlink(s): * * /usr/share/webapps/backuppc/3.1.0/htdocs/index.cgi
backuppc-3.1.0.ebuild # /etc/init.d/backuppc start backuppc | * Caching service dependencies ... [ ok ] backuppc | * No /etc/backuppc/config.pl exists! backuppc | * ERROR: backuppc failed to star
Strike my Comment #62. ... etc-update notice got hidden among backuppc ebuild stdout! Here's current debug output: # /etc/init.d/backuppc start backuppc | * Caching service dependencies ... [ ok ] backuppc | * Starting BackupPC ... backuppc |/usr/BackupPC/bin/BackupPC: Wrong user: my userid is 124, instead of () backuppc |Please su first backuppc |BackupPC::Lib->new failed backuppc | * start-stop-daemon: failed to start `/usr/BackupPC/bin/BackupPC' [ !! ] backuppc | * ERROR: backuppc failed to start
The newest ebuild works is working for me except for a problem with vhosts To enable webapp configuration, I added "app-backup/backuppc -vhosts" to /etc/portage/package.use. http://localhost/cgi-bin/BackupPC_Admin used to be my link for accessing backuppc. Unfortunately file /var/www/localhost/cgi-bin/BackupPC_Admin isn't part of the new installation. Instead, files index.cgi and BackupPC_Admin are in directory /var/www/localhost/htdocs/backuppc When I browse to http://localhost/backuppc, I'm shown a directory listing, i.e. Index of /backuppc Icon Name Last modified Size Description [DIR] Parent Directory [TXT] BackupPC_Admin 04-Oct-2008 10:54 3.9K [DIR] backuppc/ 04-Oct-2008 10:56 - [DIR] image/ 04-Oct-2008 10:56 - [ ] index.cgi 04-Oct-2008 10:54 5.9K Clicking on BackupPC_Admin shows the script, rather than executing it. Clicking on index.cgi gives a dialog saying: You have chosen to open which is a: from: (but without any names filled in). What is the proper URL for accessing BackupPC for my localhost machine ???
I like the newest ebuild! It's working well for me, though I've noticed a tweak or two that might be useful. Observation #1: in pkg_postins() is: chown -Rf backuppc:backuppc /var/lib/BackupPC since this directory has _all_ the backup files and they likely number thousands, if not millions, this could take a long, long, long time to run. Right? Seems like this line should be deleted ... Observation #2: looking at my current ebuild, RDEPEND includes app-arch/unzip and www-apache/mod_perl. I'm not sure whether they're actually necessary. Can someone more knowledgeable say? Observation #3: In src_compile() the set of "echo ... >> backuppc.c" commands can be replaced with a single "cat >> ..." command. Using cat is probably a bit quicker and, IMHO, more readable. Here's what I have: cat > backuppc.c <<EOF #include <stdlib.h> #include <sys/types.h> #include <unistd.h> int main(){ setuid( ${backuppcuseridG} ); system( "./BackupPC_Admin" ); return 0; } EOF
I've tryed to emerge last ebuild (2008-08-02) on x86 and on amd64. I've the following error # emerge -av backuppc These are the packages that would be merged, in order: Calculating dependencies \ emerge: there are no ebuilds to satisfy "dev-perl/Compress-Zlib". (dependency required by "app-backup/backuppc-3.1.0" [ebuild]) It seems that dev-perl/Compress-Zlib doesnt exist anymore it's now located on perl-core/Compress-Zlib. I've change it on my ebuild and emerge goes find.
emerge perfectly once u change it to dev-perl/Compress-Zlib when i try to start the backuppc init it gives me this error. 2008-12-21 19:31:35 $Conf{SendmailPath} = '/usr/sbin/sendmail' is not a valid executable program [ !! ] I have ssmtp installed so that is what it belongs to "mail-mta/ssmtp-2.62-r3 (/usr/sbin/sendmail -> /usr/sbin/ssmtp)" and i can send mail using the program " sendmail soccer5232@gmail.com test " Received in inbox any ideas
maybe change $Conf{SendmailPath} to /usr/sbin/ssmtp ?
This is an installation problem. If you are using mod_perl then it appears that Apache is not running as user backuppc. If you are not using mod_perl, then most like setuid is not working properly on BackupPC_Admin. Check the permissions on /usr/share/BackupPC/sbin//BackupPC_Admin and look at the documentation.
Works fine.(*) Thanks! Why don't I find this in the official portage tree? 2.1.* is so outdated! ---------------- * after this change: It seems that dev-perl/Compress-Zlib doesnt exist anymore it's now located on perl-core/Compress-Zlib. I've change it on my ebuild and emerge goes find.
Created attachment 185117 [details] Minor but necessary correction on rdepend This new ebuild for backuppc 3.1.0 works fine on amd64 and x86 The RDEPEND dev-perl/Compress-Zlib becomes perl-core/Compress-Zlib due to portage changes Easy.... Philippe
(In reply to comment #68) > maybe change $Conf{SendmailPath} to /usr/sbin/ssmtp ? > For me the problem is solved when changing the modes of the mail transfert (in my case ssmtp) : chmod o+rx /usr/sbin/ssmtp
Created attachment 194073 [details] New ebuild takes care of upgrading This new ebuild takes great care to properly upgrade from a previous install. This is especially tricky since 2.x used different directory names. Also it installs and configures a separate apache instance for the web frontend. no manual reconfiguration needed just start the daemons. I prefer the separate instance over the setuid method for security reasons. The backuppc user has a lot of power in the network (i.e. can write to any host that is being backed up) therefore I would not risk getting compromised by reusing the standard apache webserver. httpd conf and other needed files follow.
Created attachment 194074 [details] httpd.conf for the backuppc-apache instance This is derived from the standard gentoo httpd.conf I removed some modules already. The Idea is to keep this as slim as possible. If someone has ideas how to make this more secure (or less insecure). that would be greatly appreciated
Created attachment 194075 [details] apache config file for the apache instance
Created attachment 194077 [details] init script for the apache instance the ebuild uses this file only as a fallback solution. Normally it just makes a copy of /etc/init.d/apache2. The idea is to always get a new file. don't know if this is the gentoo way, though.
Created attachment 194078 [details] an updated postinstall.txt
Created attachment 195552 [details] updated ebuild that requires perl-core/IO-Compress which replaces perl-core/Compress-Zlib It would be great if someone with more experience in writing ebuilds could have a look at this. Especially if for the dependencies the directory names are really necessary. I guess if we left those out, portage could more easily resolve blocks like the one for Compress-Zlib and IO-Compress. I would really like to see this ebuild integrated into the official portage tree, since the version 2.1 in portage is over two years old now!!! For this I think the following steps are necessary: * testing: as many people as possible should test this ebuild, both upgrading and fresh installs. (it did work flawlessly for me without any trouble with backup data created by version 2.1) * evaluation: experienced ebuilders should provide a sanity check
Created attachment 195553 [details] fixed a minor bug. forgot to reset the IFS after moving the per-host config files to the new location.
Guys I'm having problems with this and www-servers/apache-2.2.11-r2, the httpd.conf requires a 'cgi' module which isn't available in the apache mentioned... Where do I get the mod_cgi.so module from?
The same with mod_suexcec.cgi?
Hey, I just submitted my own attempt at creating a good ebuild for BackupPC. I rewrote your ebuilds and tested them quite hard. Check out bug #287133 and see if it works for you as well. :)
Let's just use one bug for this. *** This bug has been marked as a duplicate of bug 287133 ***
