Created attachment 205698 [details]
backuppc-3.1.0.ebuild (new version)
Created attachment 205700 [details]
ChangeLog
Created attachment 205701 [details, diff]
this fixes the configure.pl build system
Created attachment 205703 [details, diff]
this fixes the indentation in the master config file
Created attachment 205704 [details, diff]
this sets some reasonable defaults in the new config file
Created attachment 205706 [details, diff]
this replaces the default install location with a marker, so it can be replaced with the real documentation location during the installation
Created attachment 205707 [details]
this is a conf.d file for apache2-backuppc
Created attachment 205708 [details]
this is a init.d file for apache2-backuppc
Created attachment 205710 [details]
this is a configuration file for apache2 to run the BackupPC CGI interface
There has been a vulnerability report for backuppc: Name: CVE-2009-3369 URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-3369 Published: 2009-09-24 Severity: High Description: CgiUserConfigEdit in BackupPC 3.1.0, when SSH keys and Rsync are in use in a multi-user environment, does not restrict users from the ClientNameAlias function, which allows remote authenticated users to read and write sensitive files by modifying ClientNameAlias to match another system, then initiating a backup or restore. The initial commiter to gentoo-x86 is required to verify that this issue is resolved before adding the package. Thanks. *** Bug 249441 has been marked as a duplicate of this bug. *** *** Bug 141018 has been marked as a duplicate of this bug. *** Hey! Thanks for noticing the potential security issue. I read the referenced Debian bug entry on http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=542218 and it appears that this threat can be neutralized when we disable the unpriviledged users from editing this. At least the bug in the Debian tracker was closed with this outcome + patch. To verify this, I changed 'ClientNameAlias' => '1' on my home installation and logged in with one user that didnt have administrator rights. I was able to change the ClientNameAlias for that host. When the permission was removed, the editbox did not appear anymore. However, I also tried to load the host edit form with the permission enabled, then removing the permission in the config and then submitting the form with two changed config options. The system filtered out the ClientNameAlias (when there was no permission to change it), but changed PingMaxMsec (which was allowed). Based on this, I'd say we can disable editing ClientNameAlias in the default configuration file and then users should be safe. BackupPC already displays some warnings in the Admin interface next to the settings of permissions for unpriviledged users. I will post an updated patch for the config file ASAP. Created attachment 205734 [details, diff]
This patch updates a few default settings to more reasonable values. Additionally prevents unpriviledged users from editing ClientNameAlias, fixing security issue CVE-2009-3369.
Created attachment 206036 [details, diff]
Reasonable defaults for the config.pl file
Besides all the previous fixes, this revision of the config.pl patch also includes a performance improvement suggested by the backuppc manual itself - caching of the rsync checksums.
Created attachment 207428 [details, diff]
Add support for setting the nice level of the BackupPC daemon.
I had the problem that many times that BackupPC drains the resources of the server when starting up a new backup. Obviously, the problem was that rsync was creating a list of files, causing very heavy HDD activity.
Since other people might also run BackupPC along with higher-priority services (ie. MythTV video recording), setting a nice level is a good way how to keep BackupPC under control. I set the default nicelevel change to zero and it's configurable via the conf.d file.
Created attachment 207429 [details]
backuppc-3.1.0-r1.ebuild (new version)
I created a new revision for this ebuild so it contains one additional patch (05-nicelevel.patch) and fixes a small issue where the documentation path didn't include the package revision (changed ${P} to ${PF}).
In case there are people who wish to follow the development of this ebuild more closely or to install/update it more easily on their servers, you can contact me by mail for subversion access to a portage overlay that I set up for this. Created attachment 207504 [details]
backuppc-3.1.0-r1.ebuild (new version)
Fixed another ${P} -> ${PF} in the postinstall notes.
Thanks to Giacomo Bagnoli for reporting.
In the last couple of week I've done a new install and an update from 2.1.2-r1 in portage using Lenno's ebuild and I must say everything is working very well (amd64). Seems much better than version 2.x. Giacomo am I correct, that this httpd.conf will not work with an apache server already running on port 80? would it make sense to check for an existing apache on port 80 and use another port in this case? Yep, you are correct - port 80 is written in the config file as a constant. I don't think that it would make much sense to check for already running web servers, since it's probably not so easy to always have the script make the right decision. For example, if it would detect port 80 being busy, how would it know if this is a real web server, an unneccessarly started service or a previous backuppc installation that this install will replace? I think that the safest method is to always have the ebuild write out a standard config for port 80 and then have the user edit the config file. It's not too hard for the admin to keep this setting around using etc-update properly. In that case I suggest a standard port other than 80 (e.g. 28000) since the way it is configured now, backuppc will break an existing apache configuration. The install message should then name the port. This is especially true, since backuppc starts its own instance of apache (which is the right thing to do for security reasons). This instance should not be considered a webserver as such but a frontend for the backup software. Also, using a non standard port will increase security, since attack scripts will not expect an apache (with a possible vulnerability) on that port. Also firewalls are often open on port 80 which is probably not desirable for a backup server (and if it is, the admin should know what he is doing and be able to open the port in the firewall). I think these are all good reasons for using a non standard port as default (also not 8080 or 8000 since these are also semi-standard (i.e. often used) for apache). Created attachment 212994 [details]
a more secure httpd.conf
I just tried this ebuild and it works nicely
As mentioned before, i recommend a more secure apache setup:
-adding -D SSL to apache2-backuppc.conf (otherwise authentication would not be encrypted)
-only allowing connections over the local network (192.168.x.x)
-both for security and for compatibility reasons I recommend using a non standard port like 28000
I attached an updated httpd.conf
Created attachment 212995 [details]
more secure httpd.conf with the redirect to the admin script enabled
Created attachment 212998 [details]
more secure httpd.conf fixed placeholders for htdocsdir and authuser
@app-backup team: What would be required for this ebuild to enter the official (unstable) portage tree? This ebuild does work nicely on my server for 2 months now. both upgrading and fresh installs were no problem. Would it be possible to make the suexec use-flag of the apache package optional? It may be unnecessary as soon as a setuid apache mpm is used. Maybe there is may to do this easily. Thanks Interesting thought. It would be cool if you could provide examples and/or patches showing how to use this feature. I could test this as well on my servers, then. (In reply to comment #24) > Created an attachment (id=212994) [details] > a more secure httpd.conf > > I just tried this ebuild and it works nicely > > As mentioned before, i recommend a more secure apache setup: > -adding -D SSL to apache2-backuppc.conf (otherwise authentication would not be > encrypted) > > -only allowing connections over the local network (192.168.x.x) > > -both for security and for compatibility reasons I recommend using a non > standard port like 28000 > > I attached an updated httpd.conf Personally, I think that these modifications are too specific to your installation and thus perhaps should not be the default. There are many cases where such setups are not desireable and I don't see a reason why force these upon the users.. For example, I have 6 servers in different offices, connected together via openvpn to a central server. By using the same VPN connection, I can browse all the BackupPC interfaces remotely at the same time. So in this case, it simply wouldn't make to have too restrictive defaults: * SSL by default wouldn't make it more secure, since it's not possible to verify the authencity of them anyway. In my case, the connections are already authenticated & encrypted as well. * Having a predefined limit to a certain subnet would probably cause many headaches to first-time installers, in the case that they are not using such networks, or global access is required * Changing to a non-standard port would only mean that users have to type more numbers to the address bar While your proposals make sense in some setups, I'm not sure that they should be the defaults, since it's very easy to add those parameters after the install. Created attachment 221417 [details]
httpd.conf: updated the path of SSL certificates/keyfiles to /etc/ssl/apache2
> For example, I have 6 servers in different offices, connected together via > openvpn to a central server. By using the same VPN connection, I can browse all > the BackupPC interfaces remotely at the same time. So in this case, it simply > wouldn't make to have too restrictive defaults: > > * SSL by default wouldn't make it more secure, since it's not possible to > verify the authencity of them anyway. In my case, the connections are already > authenticated & encrypted as well. To me, this seems to be a very specific setup on your side. And even if you use an encrypted vpn, other clients on the local network might not. Therefore an attacker on the local network might listen in on the communication and sniff passwords etc. this is especially troublesome, when users use the same password for backuppc and their login, which is probably quite common. On the other hand, ssl encryption doesn't really hurt, even in your case. While self signed certificates cannot prevent a man-in-the-middle attack, the attack is much more difficult than just throwing on a network sniffer. > * Having a predefined limit to a certain subnet would probably cause many > headaches to first-time installers, in the case that they are not using such > networks, or global access is required Agreed, we should comment out that line and make a remark in the post-install message that enabling this can improve security. > * Changing to a non-standard port would only mean that users have to type more > numbers to the address bar I absolutely disagree on that point. As pointed out before, it is unacceptable that the backuppc package breaks an existing apache webserver. Apache is much more widely used than backuppc and therefore I am sure, that this package will never make it into portage if it breaks such an important package as apache. The security issue is in this case just an added bonus (In reply to comment #32) > > * SSL by default wouldn't make it more secure, since it's not possible to > > verify the authencity of them anyway. In my case, the connections are already > > authenticated & encrypted as well. > > To me, this seems to be a very specific setup on your side. And even if you use > an encrypted vpn, other clients on the local network might not. Therefore an > attacker on the local network might listen in on the communication and sniff > passwords etc. this is especially troublesome, when users use the same password > for backuppc and their login, which is probably quite common. On the other > hand, ssl encryption doesn't really hurt, even in your case. While self signed > certificates cannot prevent a man-in-the-middle attack, the attack is much more > difficult than just throwing on a network sniffer. Of course my setup is quite unique, but nevertheless, everyone is free to configure it as they please, and IMO a simple non-SLL is the most foolproof. You can enable SSL with "-D SLL", it is optional. It can also be added to the post-install notes as a recommendation. > > * Changing to a non-standard port would only mean that users have to type more > > numbers to the address bar > > I absolutely disagree on that point. As pointed out before, it is unacceptable > that the backuppc package breaks an existing apache webserver. Apache is much > more widely used than backuppc and therefore I am sure, that this package will > never make it into portage if it breaks such an important package as apache. I think an admin should know what he is running on his web server, and adopt the config files before starting any service. This is exactly the same for other web server packages that you can install - all of them have port 80 set as default. I don't see absolutely any reason why to make the setup more complicated for the user. > The security issue is in this case just an added bonus I don't think that running a web server on a different port makes any difference to the security of it. Package capture will work equally well and besides, security by obscurity.. is not really security in the first place. > Of course my setup is quite unique, but nevertheless, everyone is free to > configure it as they please, and IMO a simple non-SLL is the most foolproof. > You can enable SSL with "-D SLL", it is optional. It can also be added to the > post-install notes as a recommendation. Of course, everyone can configure as they please, but the defaults should be what is best for most users. In case of a backup server that has root access to every machine on the network, what most users need is imho a setup that is as secure as possible. While I agree, that self signed ssl encryption is not ideal, it is much better than transmitting the passwords unencrypted over a the network (even if it is a local network). What would you think if one morning your boss booted his computer just to find that someone has restored his backups from two weeks ago? Also, I still don't get your argument against ssl. It works out of the box, the only inconvenience is that the browser won't accept the self-signed certificate by default, but that is just a few mouse clicks the first time you accesses the server. > I think an admin should know what he is running on his web server, and adopt > the config files before starting any service. This is exactly the same for > other web server packages that you can install - all of them have port 80 set > as default. I don't see absolutely any reason why to make the setup more > complicated for the user. Could you please make an example of another web server package that starts a separate instance of apache on port 80? afaik, all other web server packages (e.g. webmin phpmyadmin etc.) simply install into a subdirectory of an existing web server (example.com/webmin) and therefore do not break anything. > I don't think that running a web server on a different port makes any > difference to the security of it. Package capture will work equally well and > besides, security by obscurity.. is not really security in the first place. Actually you probably misunderstood my reasoning. I do not mean to increase security by hiding behind a hard to guess port. I mean to increase security because many firewalls are open on port 80, while they are very unlikely to be open on other ports. Created attachment 221423 [details, diff]
Add support for apache itk and peruser mpm
Add apache mpms itk and persuer to setuid options.
Created attachment 221425 [details, diff]
Add itk MPM Support to virtualhost
> Actually you probably misunderstood my reasoning. I do not mean to increase
> security by hiding behind a hard to guess port. I mean to increase security
> because many firewalls are open on port 80, while they are very unlikely to be
> open on other ports.
I am definitely not an expert, and it may depend on the network the
backup-server is installed, but when someone sets up a machine that's
critical to the network security like a backup server may be,
then security should be defined explicitly for it.
I think these type of servers should not be publicly available at all and
the the firewall configuration should have explicit rules that protect
these type of servers.
The expectation "port 80 statistically is more often unprotected than
unlikely ports" may be true but doesn't seem to be much more secure than
the "this port is hard to guess" strategy.
But that's just my point of view.
(In reply to comment #37) > > Actually you probably misunderstood my reasoning. I do not mean to increase > > security by hiding behind a hard to guess port. I mean to increase security > > because many firewalls are open on port 80, while they are very unlikely to be > > open on other ports. > > I am definitely not an expert, and it may depend on the network the > backup-server is installed, but when someone sets up a machine that's > critical to the network security like a backup server may be, > then security should be defined explicitly for it. > > I think these type of servers should not be publicly available at all and > the the firewall configuration should have explicit rules that protect > these type of servers. > > The expectation "port 80 statistically is more often unprotected than > unlikely ports" may be true but doesn't seem to be much more secure than > the "this port is hard to guess" strategy. > > But that's just my point of view. I couldn't agree more! (In reply to comment #34) > > Of course my setup is quite unique, but nevertheless, everyone is free to > > configure it as they please, and IMO a simple non-SLL is the most foolproof. > > > You can enable SSL with "-D SLL", it is optional. It can also be added to the > > post-install notes as a recommendation. > > Of course, everyone can configure as they please, but the defaults should be > what is best for most users. In case of a backup server that has root access to > every machine on the network, what most users need is imho a setup that is as > secure as possible. > While I agree, that self signed ssl encryption is not ideal, it is much better > than transmitting the passwords unencrypted over a the network (even if it is a > local network). What would you think if one morning your boss booted his > computer just to find that someone has restored his backups from two weeks ago? > > Also, I still don't get your argument against ssl. It works out of the box, the > only inconvenience is that the browser won't accept the self-signed certificate > by default, but that is just a few mouse clicks the first time you accesses the > server. > > > > I think an admin should know what he is running on his web server, and adopt > > the config files before starting any service. This is exactly the same for > > other web server packages that you can install - all of them have port 80 set > > as default. I don't see absolutely any reason why to make the setup more > > complicated for the user. > > Could you please make an example of another web server package that starts a > separate instance of apache on port 80? > > afaik, all other web server packages (e.g. webmin phpmyadmin etc.) simply > install into a subdirectory of an existing web server (example.com/webmin) and > therefore do not break anything. > > > I don't think that running a web server on a different port makes any > > difference to the security of it. Package capture will work equally well and > > besides, security by obscurity.. is not really security in the first place. > > Actually you probably misunderstood my reasoning. I do not mean to increase > security by hiding behind a hard to guess port. I mean to increase security > because many firewalls are open on port 80, while they are very unlikely to be > open on other ports. I guess your preferences for defaults and security are just diferent from mine. In this cases, I would propose that you submit patches that ultimately give the power to decide to the actual user, without introducing unneccessary complexity into the base install. > I guess your preferences for defaults and security are just diferent from mine. I think our use cases are just different. > > In this cases, I would propose that you submit patches that ultimately give the > power to decide to the actual user, without introducing unneccessary complexity > into the base install. Well, since the problem is not the configurability, but the default settings, there seems not to be much I can do. But try to state my argument one last time: ssl does not make the base system more complicated, it makes it more secure. changing the default port prevents the base install from breaking a previous apache configuration which I consider to be a major compatibility issue. You are right, changing the port does not improve security substantially. It may help to prevent misconfigurations but that is not my main point - the compatibility with apache is! Created attachment 221443 [details, diff]
changes the default port to 28000 to improve compatibility with apache
Created attachment 221445 [details, diff]
enables ssl
Created attachment 226995 [details] this is a conf.d file for apache2-backuppc Remove -D SUEXEC, since suexec isn't used anywhere in the config. Thanks to Daniel Biro <danman@danman.hu> for reporting. Created attachment 226997 [details]
backuppc-3.1.0-r3.ebuild (new version)
* removed USE="suexec" dependency from apache, since it wasn't used.
* changed default homedir to /var/lib/backuppc so that it's easier to set up SSH keys
Thanks to Daniel Biro for reporting!
Created attachment 226999 [details]
ChangeLog
Updated the ChangeLog
Created attachment 227001 [details]
ChangeLog
Fixed my email address in the echangelog-generated ChangeLog
Any hope for backuppc-3.1.0 appearing in a tree ? Any hope for backuppc-3.2.0 appearing in the tree? One Question: Does this ebuild exist in an overlay? And if yes, which? And one small note, BackupPC Version 3.2.0 was released on July 31st, 2010. -- Dan For the overlay, I don't think it's published anywhere. I only keep an overlay for my own and business use, but in case you need, I can also give you access to that. Just drop me an e-mail. Created attachment 247515 [details]
backuppc-3.2.0.ebuild
Created attachment 247517 [details, diff]
this fixes the configure.pl build system
Created attachment 247519 [details, diff]
this fixes the indentation in the master config file
Created attachment 247521 [details, diff]
Reasonable defaults for the config.pl file
Created attachment 247523 [details]
ChangeLog
The last ebuild is missing a "dev-perl/libwww-perl" RDEPEND. (In reply to comment #56) > The last ebuild is missing a "dev-perl/libwww-perl" RDEPEND. > May I ask, what leads you to this conclusion? Could you point out how exactly is this package used by BackupPC? BPC failed for me when trying to run any backup, missing the File::Locate module. Also, IUSE is missing "rss", or RDEPEND should not check for that USE flag. (In reply to comment #58) > BPC failed for me when trying to run any backup, missing the File::Locate > module. > I don't think that libwww-perl is providing this module, at least not according to http://search.cpan.org/dist/libwww-perl/ Also, I haven't found any references to the File::Locate module inside BackupPC 3.2.0's source code, so I don't currently see how it could be affected. Could you perhaps provide an error message/log? > Also, IUSE is missing "rss", or RDEPEND should not check for that USE flag. > Good point, will fix that. Thanks! Created attachment 249957 [details]
backuppc-3.2.0.ebuild
Added 'rss' flag to IUSE since it was missing.
(In reply to comment #59) > (In reply to comment #58) > > BPC failed for me when trying to run any backup, missing the File::Locate > > module. > > > > I don't think that libwww-perl is providing this module, at least not according > to http://search.cpan.org/dist/libwww-perl/ > > Also, I haven't found any references to the File::Locate module inside BackupPC > 3.2.0's source code, so I don't currently see how it could be affected. Could > you perhaps provide an error message/log? Actually that's File::Listing, sorry... (In reply to comment #61) > Actually that's File::Listing, sorry... > Thanks for reporting! Adding dev-perl/libwww-perl to RDEPEND since the new FTP module introduced in BackupPC 3.2.0 needs the File::Listing package. Created attachment 250117 [details]
backuppc-3.2.0.ebuild
Adding dev-perl/libwww-perl to RDEPEND since the new FTP module introduced in BackupPC 3.2.0 needs the File::Listing package.
Since many people have been asking for the repository, I've finally moved it to a public location and I've also created the suitable source file that you can feed to layman, so it should be easy. Add this URL to /etc/layman/layman.cfg under 'overlays' parameter: http://masendav.net/layman/repositories.xml After you've set up layman, sync and add the overlay: # layman -S # layman -a portage-backup The repository containing the ebuilds: Github page: http://github.com/lnagel/portage-backup Git source: git://github.com/lnagel/portage-backup.git I've also understood that it's possible to easily send me patches and new ebuilds using Github, so feel free to experiment with it, and I can merge your work in this repository and make available to everyone. Thanks for your contribution and interest! The layman repository source file has been moved here for stable hosting: https://github.com/lnagel/portage-backup/raw/master/layman-repository.xml (In reply to comment #64) > Add this URL to /etc/layman/layman.cfg under 'overlays' parameter: > http://masendav.net/layman/repositories.xml I tried to install and start backuppc. I've noticed that backuppc ebuild is missing some apache dependencies. It needs APACHE2_MODULES="autoindex cgi" also. I'm getting "Segmentation fault" in apache error_log. They appear when i enter in e.g. "EditConfig" and then clik at any menu "Hosts" or "Xfer" or... I have no idea how to debug cgi/perl script. (In reply to comment #66) > I tried to install and start backuppc. I've noticed that backuppc ebuild is > missing some apache dependencies. It needs APACHE2_MODULES="autoindex cgi" > also. > (In reply to comment #67) > I'm getting "Segmentation fault" in apache error_log. They appear when i enter > in e.g. "EditConfig" and then clik at any menu "Hosts" or "Xfer" or... > I have no idea how to debug cgi/perl script. > I'm sorry, I've been unable to reproduce these issues. Could you perhaps provide more details of your experiences with these ebuilds? I would very much like to validate these issues so that we would have a proper fix for it, not simply a first-hand workaround. Thanks! I didn't ever use backuppc, it's not easy to debug it. I don't know which information could be usefull. I paste emerge info as first step: emerge --info Portage 2.1.9.26 (default/linux/x86/10.0/server, gcc-4.5.1, glibc-2.12.1-r3, 2.6.36-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.36-gentoo-r1-i686-Intel-R-_Core-TM-2_CPU_4300_@_1.80GHz-with-gentoo-2.0.1 Timestamp of tree: Mon, 27 Dec 2010 20:45:03 +0000 ccache version 3.1.3 [enabled] app-shells/bash: 4.1_p9 dev-lang/python: 2.7.1, 3.1.3 dev-util/ccache: 3.1.3 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.6.8 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.68 sys-devel/automake: 1.5-r1, 1.11.1 sys-devel/binutils: 2.21 sys-devel/gcc: 4.1.2, 4.5.1-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 1.5.26-r1, 2.4-r1 sys-devel/make: 3.82 virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="x86 ~x86" ACCEPT_LICENSE="* -@EULA" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -mfpmath=sse -pipe -fpeel-loops -ftracer -floop-block -ftree-loop-distribution -floop-interchange -floop-strip-mine -floop-strip-mine" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -march=native -mfpmath=sse -pipe -fpeel-loops -ftracer -floop-block -ftree-loop-distribution -floop-interchange -floop-strip-mine -floop-strip-mine" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs ccache collision-protect distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://trumpetti.atm.tut.fi/gentoo" LC_ALL="pl_PL.utf-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="en pl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_EXTRA_OPTS="-6" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/steev /usr/portage/local/layman/portage-backup /usr/portage/local/layman/sunrise /usr/local/portage/miro-overlay/staging /usr/local/portage/miro-overlay/portage" SYNC="rsync://trumpetti.atm.tut.fi/gentoo-portage/" USE="a52 aac acl acpi adns aio aspell async audiofile automount bash-completion bcmath bittorrent bzip2 caps chroot clamav clamdtop cli cracklib crypt curl cxx daemon dhcp domainkeys dri dts dvd embedded exif exiscan exiscan-acl extras faac faad fam flac ftp gd gmp gnutls gpm graphite hash iconv idn ieee1394 iproute2 ipv6 javascript jpeg justify logrotate logwatch lto lzo maildir mmap mmx mmxext modules mouse mp3 mp4 mpeg mudflap nagios-dns nagios-ntp nagios-ping nagios-ssh ncurses netpbm network-cron nls nntp nptl nptlonly ogg openmp openssl optimization optimized-qmake pam pcre png pop3d posix pppd prelude profile quotas rar readline samba session sharedmem shorten slang smp sockets spell spf sse sse2 sse3 ssl ssse3 stats subtitles svg swat sysfs syslog theora threads tiff tokenizer tools tordns tos transcode unicode unzip urandom usb uudeview vcd vdpau vhosts vim vim-pager vim-syntax visibility vorbis wifi x86 xattr xfs xml xmlreader xmlrpc xmlwriter xorg xsl xvid xvmc zip zlib" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1 emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="mouse keyboard" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en pl" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="account tarpit" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LANG, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS perl-5.12.2-r5 Hmm, it's odd. Apache compiled with USE=debug works without any problem, any segfault... (In reply to comment #70) > Hmm, it's odd. Apache compiled with USE=debug works without any problem, any > segfault... > I couldn't help but to notice that you have very heavily customized your CFLAGS/CXXFLAGS - I'd suggest to try make it simpler on that side, too many custom optimizations can be a likely source for segfaults IMO. Anyway, Apache segfaults aren't relevant at all to this bug for new ebuilds, so please try to ask this question of Apache crashing elsewhere. This is not problem with extra CFLAGS;) This is bug described here: http://forums.gentoo.org/viewtopic-t-855112.html I've compiled apache using gcc-4.3.5 and gcc-4.4.5 and backuppc work correctly. So... i'm starting to use backuppc:) I just upgraded from 3.1.0-r1 to 3.2.0 and everything went smoothly. question to the gentoo guys: what would be required to get this into the official tree? Thanks to the Gentoo Overlays team, the overlay for BackupPC is now included in the main Layman overlays list, so for getting the ebuilds, you only need to do the following: (In reply to comment #64) > After you've set up layman, sync and add the overlay: > # layman -S > # layman -a portage-backup (In reply to comment #74) > Thanks to the Gentoo Overlays team, the overlay for BackupPC is now included in > the main Layman overlays list, so for getting the ebuilds, you only need to do > the following: > > (In reply to comment #64) > > After you've set up layman, sync and add the overlay: > > # layman -S > > # layman -a portage-backup Hi, I am using backuppc from portage-backup. I have a question: Does the password entry have to be like this ? backuppc:x:119:104:added by portage for backuppc:/var/lib/backuppc:/sbin/nologin I can't su or su- backuppc , Error : This account is currently not available. Now I guess that error is because of default shell assigned to that user. I wonder why a shell is not assigned because if one has to use 'tar' based backup with ssh, backuppc will need to be able to setup ssh key-pair for connecting to client, correct? Or, it needs to be done differently ? Kindly correct me if I am wrong. Thanks, Upen (In reply to comment #75) > I am using backuppc from portage-backup. I have a question: Does the password > entry have to be like this ? > backuppc:x:119:104:added by portage for > backuppc:/var/lib/backuppc:/sbin/nologin > > I can't su or su- backuppc , Error : This account is currently not available. > > Now I guess that error is because of default shell assigned to that user. I > wonder why a shell is not assigned because if one has to use 'tar' based backup > with ssh, backuppc will need to be able to setup ssh key-pair for connecting to > client, correct? Or, it needs to be done differently ? > Thanks for reporting, the shell/homedir issue is now fixed in this commit: https://github.com/lnagel/portage-backup/commit/c5da2dc0551e1d233f37a8bbd5ec987e07f6cc35 (In reply to comment #76) > (In reply to comment #75) > > I am using backuppc from portage-backup. I have a question: Does the password > > entry have to be like this ? > > backuppc:x:119:104:added by portage for > > backuppc:/var/lib/backuppc:/sbin/nologin > > > > I can't su or su- backuppc , Error : This account is currently not available. > > > > Now I guess that error is because of default shell assigned to that user. I > > wonder why a shell is not assigned because if one has to use 'tar' based backup > > with ssh, backuppc will need to be able to setup ssh key-pair for connecting to > > client, correct? Or, it needs to be done differently ? > > > > Thanks for reporting, the shell/homedir issue is now fixed in this commit: > > https://github.com/lnagel/portage-backup/commit/c5da2dc0551e1d233f37a8bbd5ec987e07f6cc35 > Thanks much Lenno I just tried to emerge the recent ebuild from the overlay but the link to the BackupPPC archive on sourceforge seems to be broken. Downloading the file from http://sourceforge.net/projects/backuppc/files/backuppc/3.2.0/BackupPC-3.2.0.tar.gz/download and moving it to the files folder of the ebuild seems to fix the problem. Can someone approve this? Regards, Stefan (In reply to comment #78) > I just tried to emerge the recent ebuild from the overlay but the link to the > BackupPPC archive on sourceforge seems to be broken. > > Downloading the file from > http://sourceforge.net/projects/backuppc/files/backuppc/3.2.0/BackupPC-3.2.0.tar.gz/download > and moving it to the files folder of the ebuild seems to fix the problem. > > Can someone approve this? > > Regards, Stefan Sorry, cannot confirm -- for me, the ebuild downloads the files from SF.net just fine. (In reply to comment #79) > (In reply to comment #78) > > I just tried to emerge the recent ebuild from the overlay but the link to the > > BackupPPC archive on sourceforge seems to be broken. > > > > Downloading the file from > > http://sourceforge.net/projects/backuppc/files/backuppc/3.2.0/BackupPC-3.2.0.tar.gz/download > > and moving it to the files folder of the ebuild seems to fix the problem. > > > > Can someone approve this? > > > > Regards, Stefan > > Sorry, cannot confirm -- for me, the ebuild downloads the files from SF.net > just fine. Hi, again. I can now approve that it works again. I have had the problem yesterday and the day before on two systems. Today I retried with two machines and I can confirm that the installation is working again. Hello, it's me again and I unfortunately have an other problem with the 3.2.0 ebuild from the overlay that i cannot solve by myself. I was able to install the ebuild and backuppc starts fine, excellent work. Now I want to use the apache instance but starting leads to the following problem: /etc/init.d/apache2-backuppc start * Starting apache2-backuppc ... [ !! ] * ERROR: apache2-backuppc failed to start I switched the logging to debug but get no more messages in the apache error_log than: [Wed Apr 13 14:44:00 2011] [info] mod_unique_id: using ip addr 127.0.0.1 [Wed Apr 13 14:44:01 2011] [info] mod_unique_id: using ip addr 127.0.0.1 [Wed Apr 13 14:44:02 2011] [notice] Apache/2.2.17 (Unix) mod_perl/2.0.4 Perl/v5.12.2 configured -- resuming normal operations [Wed Apr 13 14:44:02 2011] [info] Server built: Mar 29 2011 12:36:01 [Wed Apr 13 14:44:02 2011] [debug] worker.c(1757): AcceptMutex: sysvsem (default: sysvsem) However, the servers seems to be started and is reachable on port 80 (no other apache instances are running) and I can see the following processes: backuppc 8301 0.0 0.2 63708 11620 ? S 12:06 0:00 /usr/bin/perl /usr/bin/BackupPC -d backuppc 8304 0.2 0.1 45720 7160 ? SN 12:06 0:00 /usr/bin/perl /usr/bin/BackupPC_trashClean root 8316 0.3 0.2 161260 11320 ? Ss 12:06 0:00 /usr/sbin/apache2 -D LANGUAGE -D PERL -D BACKUPPC_VHOST backuppc 8318 0.0 0.2 160992 8484 ? S 12:06 0:00 /usr/sbin/apache2 -D LANGUAGE -D PERL -D BACKUPPC_VHOST backuppc 8319 0.0 0.2 384692 9276 ? Sl 12:06 0:00 /usr/sbin/apache2 -D LANGUAGE -D PERL -D BACKUPPC_VHOST backuppc 8323 0.0 0.2 384692 9276 ? Sl 12:06 0:00 /usr/sbin/apache2 -D LANGUAGE -D PERL -D BACKUPPC_VHOST After checking all relevant configs and init scripts I have no idea how to solve the problem. I also tried to change the port to 28000 but while the problem is the same I can beyond that no more connect from other hosts than localhost. Maybe it is a problem with an apache module? I use apache 2.2.17 and my module configuration is: apache2_modules_actions apache2_modules_alias apache2_modules_auth_basic apache2_modules_authn_alias apache2_modules_authn_anon apache2_modules_authn_dbm apache2_modules_authn_default apache2_modules_authn_file apache2_modules_authz_dbm apache2_modules_authz_default apache2_modules_authz_groupfile apache2_modules_authz_host apache2_modules_authz_owner apache2_modules_authz_user apache2_modules_autoindex apache2_modules_cache apache2_modules_cgi apache2_modules_cgid apache2_modules_dav apache2_modules_dav_fs apache2_modules_dav_lock apache2_modules_deflate apache2_modules_dir apache2_modules_disk_cache apache2_modules_env apache2_modules_expires apache2_modules_ext_filter apache2_modules_file_cache apache2_modules_filter apache2_modules_headers apache2_modules_include apache2_modules_info apache2_modules_log_config apache2_modules_logio apache2_modules_mem_cache apache2_modules_mime apache2_modules_mime_magic apache2_modules_negotiation apache2_modules_rewrite apache2_modules_setenvif apache2_modules_speling apache2_modules_status apache2_modules_unique_id apache2_modules_userdir apache2_modules_usertrack apache2_modules_vhost_alias ldap ssl threads -apache2_modules_asis -apache2_modules_auth_digest -apache2_modules_authn_dbd -apache2_modules_cern_meta -apache2_modules_charset_lite -apache2_modules_dbd -apache2_modules_dumpio -apache2_modules_ident -apache2_modules_imagemap -apache2_modules_log_forensic -apache2_modules_proxy -apache2_modules_proxy_ajp -apache2_modules_proxy_balancer -apache2_modules_proxy_connect -apache2_modules_proxy_ftp -apache2_modules_proxy_http -apache2_modules_proxy_scgi -apache2_modules_reqtimeout -apache2_modules_substitute -apache2_modules_version -apache2_mpms_event -apache2_mpms_itk -apache2_mpms_peruser -apache2_mpms_prefork -apache2_mpms_worker -debug -doc -selinux -static -suexec Stefan, which version of gcc was used to build apache? Sorry, disregard my comment. Marcin, the idea was not wrong, here are a few more infos. When I start the other apache2 instance I have no trouble. Portage 2.1.9.42 (default/linux/amd64/10.0, gcc-4.4.5, glibc-2.11.3-r0, 2.6.36-gentoo-r8 x86_64) ================================================================= System uname: Linux-2.6.36-gentoo-r8-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_3800+-with-gentoo-2.0.1 Timestamp of tree: Wed, 13 Apr 2011 09:45:01 +0000 ccache version 2.4 [enabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.6-r2, 2.7.1-r1, 3.1.3-r1 dev-util/ccache: 2.4-r9 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1-r1 sys-apps/openrc: 0.7.0 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.5 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.36.1 (sys-kernel/linux-headers) ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="*" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/openvpn/easy-rsa /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.2/ext-active/ /etc/php/apache2-php5.3/ext-active/ /etc/php/cgi-php5.2/ext-active/ /etc/php/cgi-php5.3/ext-active/ /etc/php/cli-php5.2/ext-active/ /etc/php/cli-php5.3/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="assume-digests binpkg-logs ccache distlocks fixlafiles fixpackages news parallel-fetch protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="" GENTOO_MIRRORS="ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo " LANG="de_DE.UTF-8@euro" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LINGUAS="de en" MAKEOPTS="-j6" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/var/lib/layman/vdr-devel /var/lib/layman/portage-backup /var/lib/layman/local-overlay" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X acl acpi adns ads alaw alsa amd64 apache2 apm ares async avahi bash-completion bcmath berkdb bonjour branding bri bzip2 cairo caps cgi checkpath chroot clamav clamd cli client cpudetection cpufreq cracklib crypt cups curl cxx dahdi dbus deflate derby device-mapper dhcp dri dvb extras fastcgi filter florz fortran ftp fuse g722 g729 gcrypt gd gdbm gdu geoip gif gnutls gpm grub gtk hddtemp html iconv imagemagick inotify ipv6 ithreads java java6 jpeg json ldap lm_sensors lock logrotate lua managesieve math mdnsresponder-compat mmx modules mudflap multilib mysql ncurses nforce2 nls nptl nptlonly nvidia opengl openmp opensslcrypt pam pcre perl php pkcs11 pmu png policykit pppd python qt3support qt4 quotas rdesktop readline rewrite rss samba sensord server session sftp sieve slp smi snmp soap softquota speex sse sse2 ssl startup-notification svg sysfs tcpd threads thunar tiff toolbar truetype udev ulaw unicode v4l vhosts vnc wav webdav xml xorg xorgmodule xscreensaver zapnet zapras zeroconf zip zlib zsh-completion" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" FRITZCAPI_CARDS="hfcpci" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en" MISDN_CARDS="hfcpci" PHP_TARGETS="php5-3" RUBY_TARGETS="ruby18" USERLAND="GNU" VIDEO_CARDS="nvidia" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS +*backuppc-3.2.1 (29 Aug 2011) + + 29 Aug 2011; Patrick Lauer <patrick@gentoo.org> + +files/3.2.0/01-fix-configure.pl.patch, + +files/3.2.0/02-fix-config.pl-formatting.patch, + +files/3.2.0/03-reasonable-config.pl-defaults.patch, + +files/3.2.0/04-add-docdir-marker.patch, +files/3.2.0/05-nicelevel.patch, + +files/apache2-backuppc.conf, +files/apache2-backuppc.init, + +backuppc-3.2.1.ebuild, +files/httpd.conf: + Bump for #287133, ebuild from the portage-backup overlay. Thanks to Lenno + Nagel. Excellent :) (Now I just need to change the patches a bit as one of them is over 20kB, but that's cosmetics ...) (In reply to comment #85) > Excellent :) > (Now I just need to change the patches a bit as one of them is over 20kB, but > that's cosmetics ...) Thank you! Lenno Does that mean the ebuild is going to show up in the tree? Thanks, too, for all the work. |
Hey! I'm submitting a fresh ebuild for BackupPC-3.1.0 (current stable version). Please note that this is not a simple version bump from the 2.1-series (like bugs #141018 and #249441), but a completely rewritten ebuild which fixes many issues that I have found with the other submitted ebuilds. I have been working quite hard to get this ebuild running smoothly on all the servers I admin and with this process, I think it's quite stable now :) It installs and runs cleanly on 8 amd64 servers (a recent hardened install, a few older non-multilib hardened installs, two regular amd64 installs on xen-sources kernels) and also on a freshly installed x86 system. So far so good, all my servers are running on this version now. :) == Included files == * backuppc-3.1.0.ebuild * ChangeLog * files/01-fix-configure.pl.patch * files/02-fix-config.pl-formatting.patch * files/03-reasonable-config.pl-defaults.patch * files/04-add-docdir-marker.patch * files/apache2-backuppc.conf * files/apache2-backuppc.init * files/httpd.conf == Most important fixes == * Complete rewrite of the old ebuilds, cleaning out the mess ** Fixed a LOT of build/install failures ** Removed any attempts for moving old config - leave that for etc-update ** Converted the install to use the ebuild standard tools (epatch/dodoc/..) ** Fixed the dependencies, added correct USE deps for apache2 ** keyworded for amd64, x86 ** removed unused IUSE flags rsync & doc ** Wrote some useful post_install comments :) ** fixed the stuff that repoman pointed out * Build system patches ** Patched ./configure.pl to not mess around with existing configuration ** Fixed the install locations to match Gentoo's ** Patched the CGI to find the docs in /usr/share/doc/${P}/ * Fixed the httpd.conf so it's not fragile anymore ** removed unneccessary LoadModule statements ** detection for old non-multilib amd64 installs, fixing apache2 modules dir ** find if apache is compiled with mod_cgi/mod_cgid and use the one available ** default port 80, redirection to the BackupPC_Admin script from web root ** generate an admin user/pass if no current auth file found * Patched the default configuration file ** Patched the indentation in config.pl to match the one written by CGI \ so that etc-update can make a clean diff for the new version ** Fixed broken settings in config.pl to use reasonable defaults