This issue should cover a few possible problems related to the deployment process.
Since they are closely interconnected, I will put them in one single issue.
The description will be quite a long, but I didn't manage to shorten it, and I think it is better to be more detailed, especially given that the main issue it really strange.
The main problem is that Bacularis is unable to create additional repository lists on a remote machine, despite the fact that it can access the remote machine.
The Bacularis version is latest 3.0.1 and both server and client are using Debian 12 Bookworm. The OS profile was created with appropriate Bookworm repository links and paths were corrected for deploy from bacula.org, along with package names.
These are the steps I used to reproduce the issue:
- create the key on system, by using
ssh-keygen utility
- paste the private key content inside
Deployment > SSH keys > Add new SSH key option
- Bacularis then create the key inside
/etc/bacularis/Web/ directory
- Create new SSH config by using
Deployment > SSH configs > Add new SSH config option, select the key previously created, username of remote user with sudo privileges and remote host
- Open
Deploy API host option and select authentication method Use username and SSH key from SSH config for host, after entering necessary details about username, hostname, password, and check Use sudo box
After those steps, Bacularis shows that the first four steps are complete, although, they are not:

After logging in to the client machine, there are no additional repository files inside /etc/apt/sources.list.d/ where they should be, but surprisingly, the /tmp/bacularis-deploy/ folder is created, along with two files:
bacularis-api with 2.7K bytes of text. It seems that these are some sudo settings for www-data user
bacularis.pub.gpg with 1.3K byte GPG key
At the step 4 from the image, the deployment obviously fail, because there are no repository files added on client machine.
Looking at the Bacularis log from Raw output tab, everything seems to be normal (full log is in the attachment).
Along with the main issue described, there are three additional things that might need to be fixed or modified:
- If repository files are not created, Bacularis should detect that, and fail at the first step. It might be also beneficial for overall user experience if the deployment option would have "Connect to client" as a first step, where the connection will be tested first, before any other steps. This can be even added as separate option on Deployment page, and not just as one of deployment steps.
- When
Use username and password auth method is selected, the ssh.conf file is still provided to the SSH command that Bacularis execute, which is probably not what user want, along with the Use username and SSH key from SSH config for host option that should be the only one to add ssh.conf to the command.
- The permissions and ownership on private keys added via Bacularis interface are not suitable for use by additional scripts that might use them, because the Bacularis set
www-data user and group, and if the user, for an example, try to use that private key to be executed by some bash script defined inside RunScript block, the Job will fail, because it is executed as Bacula user, which is not able to access that file. For some users, adding bacula user to www-data group might solve the issue, but for me, the Jobs I configured in this manner would not work, until the permissions on file (the private key) were set to be www-data user and bacula group. Just to be clear, I am not saying that there is a problem here, because this might be very specific to the server environment; I am, however, saying that this should be at least mentioned in the troubleshooting section in documentation, because there are probably many users that would simply try to use one key as "backup server key" and try to use it for everything, just to find out that with the default settings the key can not be used by the Bacularis and the Bacula Jobs the same time.
The Highlight
To make sure the main issue is not buried in the already long description, I will point it out once again:
The main problem is that Bacularis obviously succeed in making connection and uploading two files to remote host with scp, but fail to create the repository lists.
Furthermore, by inspecting the executed commands and the client machine, I found out the following:
The Bacularis create a file /tmp/bacularis-deploy/bacularis.pub.gpg at client machine, but fail to move it to /usr/share/keyrings/bacularis-archive-keyring.gpg. The same thing is with bacularis-api.
I didn't manage to find out why simple mv command fail, but the state of the files is as described.
Also, by looking at the log, there is not anything related to the repositories like with the archive keyring and the bacularis-api file.
At this point, I have no idea why deployment process it not executing the important step and why the scp command succeed and simple mv fail.
The workaround for the problem is manually adding keys and repositories and let the deployment process complete installing and configuring Bacularis API host and bacula file daemon, but it certainly is not intended to be done this way, and the errors encountered might be the sign of possible flaws in deployment process, so I am certain it would be beneficial for the project to have this mentioned.
As a small side note, I have replaced the real domain from the log in attachment with "redacted.domain" string to be as a placeholder, but on its place was actually the real FQDN, it was just replaced in the log file after downloading.
bacularis-fail.txt
This issue should cover a few possible problems related to the deployment process.
Since they are closely interconnected, I will put them in one single issue.
The description will be quite a long, but I didn't manage to shorten it, and I think it is better to be more detailed, especially given that the main issue it really strange.
The main problem is that Bacularis is unable to create additional repository lists on a remote machine, despite the fact that it can access the remote machine.
The Bacularis version is latest
3.0.1and both server and client are using Debian 12 Bookworm. The OS profile was created with appropriate Bookworm repository links and paths were corrected for deploy from bacula.org, along with package names.These are the steps I used to reproduce the issue:
ssh-keygenutilityDeployment>SSH keys>Add new SSH keyoption/etc/bacularis/Web/directoryDeployment>SSH configs>Add new SSH configoption, select the key previously created, username of remote user with sudo privileges and remote hostDeploy API hostoption and select authentication methodUse username and SSH key from SSH config for host, after entering necessary details about username, hostname, password, and checkUse sudoboxAfter those steps, Bacularis shows that the first four steps are complete, although, they are not:

After logging in to the client machine, there are no additional repository files inside
/etc/apt/sources.list.d/where they should be, but surprisingly, the/tmp/bacularis-deploy/folder is created, along with two files:bacularis-apiwith 2.7K bytes of text. It seems that these are some sudo settings forwww-datauserbacularis.pub.gpgwith 1.3K byte GPG keyAt the step 4 from the image, the deployment obviously fail, because there are no repository files added on client machine.
Looking at the Bacularis log from
Raw outputtab, everything seems to be normal (full log is in the attachment).Along with the main issue described, there are three additional things that might need to be fixed or modified:
Use username and passwordauth method is selected, thessh.conffile is still provided to the SSH command that Bacularis execute, which is probably not what user want, along with theUse username and SSH key from SSH config for hostoption that should be the only one to addssh.confto the command.www-datauser and group, and if the user, for an example, try to use that private key to be executed by some bash script defined insideRunScriptblock, theJobwill fail, because it is executed asBaculauser, which is not able to access that file. For some users, addingbaculauser towww-datagroup might solve the issue, but for me, the Jobs I configured in this manner would not work, until the permissions on file (the private key) were set to bewww-datauser andbaculagroup. Just to be clear, I am not saying that there is a problem here, because this might be very specific to the server environment; I am, however, saying that this should be at least mentioned in the troubleshooting section in documentation, because there are probably many users that would simply try to use one key as "backup server key" and try to use it for everything, just to find out that with the default settings the key can not be used by the Bacularis and the Bacula Jobs the same time.The Highlight
To make sure the main issue is not buried in the already long description, I will point it out once again:
The main problem is that Bacularis obviously succeed in making connection and uploading two files to remote host with
scp, but fail to create the repository lists.Furthermore, by inspecting the executed commands and the client machine, I found out the following:
The Bacularis create a file
/tmp/bacularis-deploy/bacularis.pub.gpgat client machine, but fail to move it to/usr/share/keyrings/bacularis-archive-keyring.gpg. The same thing is withbacularis-api.I didn't manage to find out why simple
mvcommand fail, but the state of the files is as described.Also, by looking at the log, there is not anything related to the repositories like with the archive keyring and the bacularis-api file.
At this point, I have no idea why deployment process it not executing the important step and why the
scpcommand succeed and simplemvfail.The workaround for the problem is manually adding keys and repositories and let the deployment process complete installing and configuring Bacularis API host and bacula file daemon, but it certainly is not intended to be done this way, and the errors encountered might be the sign of possible flaws in deployment process, so I am certain it would be beneficial for the project to have this mentioned.
As a small side note, I have replaced the real domain from the log in attachment with "redacted.domain" string to be as a placeholder, but on its place was actually the real FQDN, it was just replaced in the log file after downloading.
bacularis-fail.txt