Joerg Zinke writes:
> On Sat, 25 Nov 2006 15:30:26 +0100
> [EMAIL PROTECTED] (Andreas Vögele) wrote:
>
>> On the other hand, I don't want the BackupPC port to depend on gtar
>> and samba, since most people will probably use rsync to backup
>> their hosts.
>
> Yeah thats true. I only use ssh for example.
>
>> I can think of several solutions to this problem:
>>
>> 1. By default, the BackupPC port could depend on all packages. But we
>> could add flavors like no_gtar and no_samba that disable the
>> dependencies [...]
>>
>> 2. We could set the path names of the optional executables to the
>> empty string so that BackupPC doesn't look for these executables on
>> startup. [...]
>>
>> 3. We could disable the checks for the executables. [...]
>
> I think a mix of 1. + 2. could be the way to go. If the user decides
> for no_gtar or no_samba as flavor, the port should not install them
> as dependency _and_ should leave the config string empty.
Yes, that's actually what I meant and that's why I wrote that the bug
with the empty string also applies to solution 1.
> Just disabling the checks as suggested in 3. would work and would
> keep the port simple...
I don't know whether it's better to provide a package that pulls in
all the packages that BackupPC may use (which includes Samba) or if
it's better to provide a minimal package that leaves it to the user to
install additional packages.
>> Unfortunately, there's a bug in BackupPC's configure.pl. If a path
>> is set to the empty string, configure.pl will output the default
>> path, e.g. '/usr/bin/smbclient', instead of the empty string. I
>> haven't decided yet how to fix this bug. This bug affects
>> solutions 1 and 2.
>
> Since 3.0.0 is beta it should not be too hard to get the bug fixed
> in the upstream before final is released?
I don't think that the final version of BackupPC 3 will be released
before the end of the year.
I just haven't decided where to fix the bug. The script configure.pl
handles empty strings given on the command line properly. It seems
that the problem arises when the configuration is written to disk.
Changing that code may have unwanted side effects. I have to look
closer at the code and come up with a simple solution.
>> There's another issue I'm not happy with.
>>
>> I used to keep the files for the second httpd instance in
>> /var/backuppc/www/{conf,htdocs,logs}. I now decided to put httpd.conf
>> into /etc/backuppc alongside the BackupPC configuration files. The
>> httpd log files are kept in /var/log/backuppc alongside the BackupPC
>> log files. [...]
>>
>> But OpenBSD's httpd insists on creating the file logs/etag-state in
>> the ServerRoot directory that I have set to /etc/backuppc. Since the
>> path name logs/etag-state cannot be configured I have to create a
>> symbolic link called /etc/backuppc/logs that points to
>> /var/log/backuppc. This also means that I have to add an @exec
>> statement to PLIST. Not nice, but I can't think of a better solution.
>
> Mhmm... what about this: keep webserver root in /var/backuppc/www/ and
> put /etc/backuppc in /var/backuppc/www/etc/ and set a symbolic link (for
> whole directory or maybe better for every single file in it from
> /etc/backuppc -> /var/backuppc/www/etc/
The /etc/backuppc directory isn't strictly required by BackupPC. But
I'd like to keep the config and log files separate from the
directories cpool, pc, pool and trash, where the backups are stored.
I usually store cpool, pc, pool and trash on a separate disk that
powers down if no backups are in progress. The config and log files
must not be stored on the backup disk since the BackupPC daemon
regularly reads the config files and may write to the log files.
Also, it's safer to keep the configuration files and the backups on
different disks. If the backup disk breaks down the configuration
files aren't lost and it's easy to setup a new backup disk. On the
other hand, if the disk with the configuration files breaks down it's
possible to retrieve the configuration files from the backup disk.
In practice, I use a cron job to backup the configuration files, but
nevertheless I think it's a good idea to keep the configuration files
and the backups separate.
> I think it is not a good idea to have the webserver root in etc.
Well, that's what Debian does :-)
>> The contents of /var/backuppc/conf needs to be moved to /etc/backuppc.
>
> Why not a symbolic link from /etc/backuppc -> /var/backuppc/conf/ as
> suggested above?
> Or just ignore the /etc/backuppc idea?
> For example /etc/bind or /etc/ apache do not exists on openbsd
> too... it is no problem to have config files under /var/...
There's another reason not to put the config files into /etc. In
version 3, BackupPC's web frontend can be configured to write to the
config directory. It's rather strange to have a web frontend write to
/etc, which after all may be mounted read-only.
What about the following directory structure?
/var/backuppc/ (home directory of the _backuppc user)
/var/backuppc/.ssh/
/var/backuppc/conf/
/var/backuppc/data/cpool/
/var/backuppc/data/pc/
/var/backuppc/data/pool/
/var/backuppc/data/trash/
/var/backuppc/log/
/var/backuppc/www/conf/
/var/backuppc/www/htdocs/ (by default an empty directory)
/var/backuppc/www/logs/
The only difference to the old structure is that cpool, pc, pool and
trash are below /var/backuppc/data/ so that these directories can
easily be put onto a separate hard disk. A single mount point can
also easily be kept out of the backup.
BTW, do you prefer /var/backuppc or /var/db/backuppc as the base
directory?
>> Make sure to set the home
>> directory of the user _backuppc to /var/db/backuppc.
>
> PLIST suggest that your port does this already.
Yes, but Siju George has got my port for BackupPC 2 that uses
/var/backuppc as home directory.
Thanks a lot for your comments.
Regards,
Andreas
