Hi andreas,
first: great work, your port looks good to me, nearly finished.
On Sat, 25 Nov 2006 15:30:26 +0100
[EMAIL PROTECTED] (Andreas Vögele) wrote:
> > did you managed it to get the cgi running in chroot? or did you just
> > disable the chroot for the cgi?
>
> I run another non-chrooted httpd instance that only listens on
> 127.0.0.1 and runs with the privileges of the _backuppc user.
> Connections can be forwarded with ProxyPass from the chrooted httpd
> instance. Alternatively, SSH port forwarding can be used to access
> the BackupPC web frontend.
>
Running another httpd instance sounds like a good compromise to me. I
think it would be really hard to get it working in chroot, too much
dependencies...
> On the one hand, I'd like to keep the port simple.
Good idea!
> 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 so that people can easily build their own packages
> that don't depend on samba etc.
>
> 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. But then users would have to set the path names manually
> in the configuration when an optional package is installed.
>
> 3. We could disable the checks for the executables. The changes in
> BackupPC would be rather small, but I'd like to avoid changes to
> the upstream sources if possible.
>
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.
Just disabling the checks as suggested in 3. would work and would keep
the port simple...
> 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?
> Personally, I'd go for solution 1. What do you think?
>
I prefer 1. + 2.
> 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. IMHO it makes sense to keep these files together -
> especially the configuration files. Also, I don't expect the file
> names that are used by BackupPC and httpd to ever clash.
>
> 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/
I think it is not a good idea to have the webserver root in etc.
> 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/...
> Make sure to set the home
> directory of the user _backuppc to /var/db/backuppc.
>
PLIST suggest that your port does this already.
Regards,
Joerg
