Hello Joerg, I've made some additional tests and I would like to clear out the unclear state of where the job will be run in the following scenario.

If defined like

  # Update stats run them on server.
  RunScript {
    Console = "prune stats yes"
    Console = "update stats days=3"
    Console = ".bvfs_update"
    RunsWhen = After
    RunsOnClient = no
  }

With this PR It will output the following

  RunScript {
    Console = "prune stats yes"
    RunsWhen = "after"
    RunsOnClient = No
  }
  RunScript {
    Console = "update stats days=3"
    RunsWhen = "after"
    RunsOnClient = No
  }
  RunScript {
    Console = ".bvfs_update"
    RunsWhen = "after"
    RunsOnClient = No
  }

Which is what we decide is correct.

Now if we don't specify Where it run like

  # with no runsonclient
  RunScript {
    Console = "prune stats yes"
    Console = "update stats days=3"
    Console = ".bvfs_update"
    RunsWhen = After
  }

It shows

  RunScript {
    Console = "prune stats yes"
    RunsWhen = "after"
  }
  RunScript {
    Console = "update stats days=3"
    RunsWhen = "after"
  }
  RunScript {
    Console = ".bvfs_update"
    RunsWhen = "after"
  }

Which let undetermined if yes or no it will run on client, the operator can check the documentation and will find that by default RunOnClient = Yes.
If it is easy to agree that console command will never been run on client, it is more complicated to determine if a command will be yes or no RunOnClient = yes.
To explain a bit more the uncertain state we can use the following example with 1 Console and 1 Command:

  RunScript {
    Console = "prune stats yes"
    Command = "systemctl start tralala"
    RunsWhen = After
  }

The resulting show form look like:

  RunScript {
    Console = "update stats days=3"
    RunsWhen = "after"
  }
  RunScript {
    Command = "systemctl start tralala"
    RunsWhen = "after"
  }

Here we can eventually deduce that console will never be run on client.
But the last command is again undetermined and operator can't have an idea, without opening the text configuration file to see that the block is written in condensed form and maybe will not be executed on client.

The resulting show form look like:

  RunScript {
    Console = "update stats days=3"
    RunsWhen = "after"
  }
  RunScript {
    Command = "systemctl start tralala"
    RunsWhen = "after"
  }

Here we can eventually deduce that console will never be run on client. But the last command is again undetermined and operator can't have an idea, without opening the text configuration file to see that the block is written in condensed form and maybe will not be executed on client.

I even expect, that systemctl start tralala will be executed on the client, as the default of RunOnClient is yes.
Anyway, not printing the default value is the default behavior for all directives. It will be not consistent to only change this for the RunOnClient directive.
To let the show command also display the default value, there is the show verbose command. However, this is currently not working for Runscript sections. If you think, this is required, I can add that.

My concern is that for the moment any console or command if the RunOnClient = No is not specified are run on client and show verbose doesn't confirm that.

so yes we need to fix this. and maybe also fixing console to never be run on client (or there's a use case, that I'm not aware of?)

10-Aug 09:38 localhost-fd JobId 1: shell command: run ClientAfterJob "prune stats yes"
10-Aug 09:38 localhost-fd JobId 1: Error: Runscript: ClientAfterJob returned non-zero status=208. ERR=No such file or directory

log use shell command also for console command :-(

@bruno-at-bareos I updated the PR to cover the problems you described.

Now, it warns only once the misconfigured Runscript resource.

In my last manual testing I found that we emit a warning about console command without a RunOnClient=No.
As we change the behaviour (Console command will be always run on Dir) maybe we can disable this warning.
Here the configuration example to trigger the warning

  # Only Console command, no warning should be emitted
  RunScript {
    Console = "prune stats yes"
    Console = "update stats days=3"
    Console = ".bvfs_update"
    RunsWhen = After
  }

There are configuration warnings:

• RunScripts with Console commands are not intended to run on clients. Setting 'RunOnClients' to 'no'. Please adapt the RunScript resource in config file /usr/local/etc/bareos/bareos-dir.d/job/BackupCatalog.conf ending in line 24.

  # Mixed command then the warning should be shown.
  RunScript {
    Console = "prune stats yes"
    Console = "update stats days=3"
    Command = "systemctl stop mysql"
    RunsWhen = After
  }

I'm asking for that because if operator now use the show command the RunOnClient = no is automatically added.

  RunScript {
    Console = "prune stats yes"
    RunsWhen = "after"
    RunsOnClient = No
  }
  RunScript {
    Console = "update stats days=3"
    RunsWhen = "after"
    RunsOnClient = No
  }
  RunScript {
    Console = ".bvfs_update"
    RunsWhen = "after"
    RunsOnClient = No
  }

What's your opinion on this ?

I intentionally added the warning, as the behavior is somehow changed now.
Before you could configure

RunScript {
    Console = "prune stats yes"
    RunsWhen = After
}

but as Bareos then tries to execute "prune stats yes" on the client as a shell script (this might work for some commands, that also exists in the OS or if you create /usr/local/bin/prune).
You had to configure it as

RunScript {
    Console = "prune stats yes"
    RunsWhen = After
    RunsOnClient = No
}

And this is still true, just that specifying a Console runscript implicietly sets RunsOnClient = No (even if you explicitly set it to Yes !).
This is not behavior we like to have, therefore we issue the Warning, so that the Administrator sets it to the correct value.