Jumping in late here... You might like to look at the BackupPC docker container, I recall it runs as non-root, and also will isolate itself from the rest of the os. If nothing else, it should have some helpful scripts, since also from memory,it is based on alpine linux.... I've been running it that way on two servers for a year or so with no issues so far.
Regards, Adam On 23 November 2025 3:57:49 am AEDT, "G.W. Haywood" <[email protected]> wrote: >Hello again, > >On Sat, 22 Nov 2025, daggs wrote: >> On Sun, 16 Nov 2025, G.W. Haywood wrote: >> > On Sun, 16 Nov 2025, daggs via BackupPC-users wrote: >> > > > I'm working on building backuppc from source on alpine linux on the >> > > home folder of a user ... >> > ... >> > I've just committed a change to makeDist which adds the '--verbose' >> > option. If you grab the new version and run that with --verbose added >> > to the command line you will probably see what's missing ... >> > ... >> > Please let me know how you get on. So far, you're doing famously! >> >> With the new feature, I was able to compile it and install it on the >> home folder of the user I want to run it. > >:) > >> two question if I may: > >It's what we're here for. > >> 1. Is there a way to run the perl configuration silently? so the >> installation can be automated? > >Firstly I'm not sure that it's necessary for something to be silent >just so that it can be automated. But secondly, yes, in fact several >ways. The simplest is probably to send the output to the bit-bucket, >or '/dev/null' as it's known in the Unix world. If, when you run a >command in a shell script (or at the command prompt), you put at the >end of the command line in the script (or the command at the prompt) >the characters ' 1>/dev/null 2>&1' (excluding the quotes that I've >used there) then the output from the script (or command) will be sent >to a device whose only real job is to discard all its input. This is >one example of what we call 'redirection'. In this case redirecting >the standard output and standard error output 'streams'. Standard >output is '1>' (for the 'bash' shell and some others, just '>' on its >own means the same thing) and standard error is '2>'. The part that >reads '2>&1' means "send the output from standard error to the same >place that standard output will go". > >There are other ways to use redirection. You can send the output to a >file (or files, for example '>./stdout.log 2>./stderr.log'). That's >what I usually do if I don't want to see reams of verbose output on >the screen, but I want to be able to look back later at what it said. > >You might remember that I suggested in an earlier mail that you could >delete some text from the 'makeDist' script, to make its output more >verbose. That was exactly the same thing in reverse. But I digress. > >> 2. As I use alpine linux, I've opted not to use systemd, ... > >I understand perfectly. ;) > >> which file from .../src/init.d should I select? > >Using a search engine I searched for "alpine linux" "init scripts". >Here are a few of pages that I found with a few clicks. I haven't >spent a lot of time on them but they look to be useful documentation. > >https://wiki.alpinelinux.org/wiki/Writing_Init_Scripts >https://wiki.alpinelinux.org/wiki/OpenRC >https://github.com/OpenRC/openrc > >Typical startup/shutdown scripts will do things like checking that the >resources which need to be available *are* available so that the thing >which is being started can, when started, do its job. For BackupPC, >for example, you'd normally expect at least all the filesystems to be >accessible - so that BackupPC can find its configuration files, write >backup data to the pool and so on - and the network to be functioning >so it can fetch from other systems the data that you want to back up. >The 'shutdown' part of the startup/shutdown scripts generally means a >way of stopping the thing that was started in a 'graceful' way. Some >processes are a little fussy about that, they may for example need to >close files in a particular way or make sure that when the files are >closed there's something written to the file which marks it as having >been 'safely' closed, whatever 'safely' means. BackupPC isn't fussy. > >Because you're running BackupPC in a user home directory I'm guessing >that things like that will already have been taken care of, so I'm not >sure that any of the init-style scripts will be exactly what you want. >Perhaps all you'd really need to do is type the command > >/path/to/your/BackupPC/bin/BackupPC -d > >or alternatively have a cron job check that BackupPC is running, and >if it isn't, start it (using that same command). Once it's started, >the BackupPC daemon will run until something stops it. Around here, >it will typically run for many months at a time without interruption. > >Anyway after all that it seems to me after a quick look at the docs >above that people have taken Gentoo scripts and used them as a basis >for something on Alpine. That might be a good place to start as it's >stuff you will probably want to be familiar with in future anyway. In >addition to starting the BackupPC backup server itself you might also >want the same script to start a Web server (probably Apache) or maybe >at least check that it's running, and if not warn you. If BackupPC is >configured to use an SCGI process as an intermediary between it and a >Web server, it will start it (and stop it) itself. > >Note that although a full-bells-n-whistles BackupPC installation will >run a Web server, BackupPC will run fine without one. It will still >back things up. The Web server is primarily needed for point'n'shoot >monitoring and control. After you start BackupPC you *can* control it >and get information from it by sending messages to it from the command >line. There are scripts in the archives of this Mailing List (also on >the BackupPC Wiki) which show you how you can do that sort of thing. >You might for example run a cron job which queries BackupPC each day - >perhaps at a time when you expect all the backups to be finished - and >sends you an email with the results. > >HTH > >-- > >73, >Ged. > > >_______________________________________________ >BackupPC-users mailing list >[email protected] >List: https://lists.sourceforge.net/lists/listinfo/backuppc-users >Wiki: https://github.com/backuppc/backuppc/wiki >Project: https://backuppc.github.io/backuppc/
_______________________________________________ BackupPC-users mailing list [email protected] List: https://lists.sourceforge.net/lists/listinfo/backuppc-users Wiki: https://github.com/backuppc/backuppc/wiki Project: https://backuppc.github.io/backuppc/
