Re: Timing of Run After

@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 <[email protected]> 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
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-users