@Bill: thanks for the pointer. Unfortunately, I'm using bacula 9.6, so new features won't help me.
@Eric Thanks for the info. There were a couple points I didn't follow. On Wed, Feb 19, 2025 at 12:19 AM Eric Bollengier <e...@baculasystems.com> wrote: > > Hello Ross, > .... > > > > I don't think I can run the script, which needs to run as root, in a > > (server) RunAfter script since the server runs as bacula while the fd client > > runs as root. That was the only reason I didn't just use RunAfter. The > > client and server are the same machine. > > The RunAfter is done on the Director side, which is "bacula" by default. > It sounds just the right thing to do. What sounds like the right thing to do? The bacula user doesn't have the permissions the script needs, and so I don't think a server-side RunAfter script will work. ... > > > So, two questions: > > > > First, what can I assume has been completed before Client or server Run > > After scripts execute? Which of the directives for the job will have been > > acted on? What is the state of the database and the volumes being > > written? Is there a risk of a race condition in which writing a volume > > or .bsr to disk is incomplete or updating the database is incomplete? > > Using RunAfterJob on the Director side should be OK, it's done just before > the JobEnd event. As I said, I think there's a permission problem with this. Also, can I be sure that the storage daemon has finished writing before the RunAfter is triggered? Come to think of it, I really need to know that it has finished writing and that the results have landed on the disk. > > > Second, any suggestions about how to get around the sequencing problems I've > > encountered? It may be relevant that the system the script is copying to is > > a Mac. The bacula website says that is supported, but the only binaries I > > found were ancient. > > We have binaries for Mac on the web site, they are not very old but we have > only the FD. You mean here: https://www.bacula.org/bacula-binary-package-download/? > You must compile the other daemons and adjust the different > procedures to start them. If it's a recent build that's encouraging. While building from source would still be a bit ambitious, this suggests it's at least possible. I was concerned the MacOS might have changed enough that getting things to build would be a challenge. I mentioned that the "remote" system was a Mac mostly to explain why I wasn't considering strategies that involved bacula running on it. As an aside, in using rsync from Linux to Mac I've found quite a few incompatibilities; for example, neither ACLs nor extended attributes can be sent, and --fake-super, which is intended to get around file system differences, isn't supported on the Mac side. As far as I can tell, the problem isn't that the Mac filesystem lacks the features; the problem is the rsync they provide has different options (e.g., rsync on Mac has a single option to copy ACLs and extended attributes--and probably other stuff, while rsync on Debian has one option for ACLs and another for extended attributes). Ross _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
