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