Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deployment process incomplete #46

Closed
sitemapxml opened this issue May 21, 2024 · 3 comments
Closed

Deployment process incomplete #46

sitemapxml opened this issue May 21, 2024 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@sitemapxml
Copy link

sitemapxml commented May 21, 2024

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:

  1. create the key on system, by using ssh-keygen utility
  2. paste the private key content inside Deployment > SSH keys > Add new SSH key option
  3. Bacularis then create the key inside /etc/bacularis/Web/ directory
  4. 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
  5. 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:
image

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:

  1. bacularis-api with 2.7K bytes of text. It seems that these are some sudo settings for www-data user
  2. 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:

  1. 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.
  2. 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.
  3. 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

@ganiuszka ganiuszka self-assigned this May 22, 2024
@ganiuszka ganiuszka added the bug Something isn't working label May 22, 2024
@ganiuszka
Copy link
Member

Hello @sitemapxml,

Thank you for your excellent report and for describing us all your problems with the deployment function. It is really piece of very good job. Thank you.

Your steps to deploy Bacularis are correct. I did re-test on my side and I am seeing that you found a bug in the deployment function. It happens if there is used SSH key without passphrase together with SUDO option. I prepared a fix for that. The patch you can find here. It is for version 3.0.1:

bugfix_bacularis_issue_46_deploy_with_ssh_key_and_sudo.patch.txt

If you want you can try it. To apply it, you need to do the following steps on the host with Bacularis Web:

# cp bugfix_bacularis_issue_46_deploy_with_ssh_key_and_sudo.patch.txt /usr/share/bacularis/protected/Web/
# cd /usr/share/bacularis/protected/Web/
# patch -p2 < bugfix_bacularis_issue_46_deploy_with_ssh_key_and_sudo.patch.txt
# rm bugfix_bacularis_issue_46_deploy_with_ssh_key_and_sudo.patch.txt

Here you can find my answers on your questions:

For 1)
Yes, I fully agree that if repository file is not created, we should report an error. Bacularis deployment process relies on exitcodes from commands. In this case problem with sudo the process was waiting on typing password for sudo and timed out with exit code 0. So, normally it reports errors but the command needs to return exit code != 0. I think this is very specific case.

For your idea about adding connectin test command, I think it is really good idea. I will add to task to do. Thank you.

For 2)
The ssh.conf file is provided even for user/password authentication because in the ssh file user can define SSH connection options specific for given host. Currently it is mainly username and port setting, but in the future there can be more options. I mean that this ssh.conf file is for all SSH connections. For the Use username and SSH key from SSH config the key is used from SSH file, but all other options work for all SSH connections.

For 3)
Yes, SSH key permissions are very restrictive in this case. You are right that because of this fact nobody else can use this key. As a workaround we can use sudo -u in other SSH commands or add user go the web server group, that you have already mentioned. For adding this point to the documentation, we will add it. Thanks for this idea.

If you try this patch, please let us know if it helped.

This change will be added to repository soon, after performing more detailed tests.

Best regards,
Marcin Haba (gani)

ganiuszka added a commit to bacularis/bacularis-web that referenced this issue May 22, 2024
…h sudo option

This bug has been reported by @sitemapxml in bacularis-app repository.

bacularis/bacularis-app#46
@ganiuszka
Copy link
Member

Hello @sitemapxml

I am letting know that I added to the troubleshooting chapter in Bacularis docs information about how to use the deployment SSH keys to other purposes than Bacularis.

https://bacularis.app/doc/brief/troubleshooting.html#how-to-use-deployment-ssh-key-to-other-purposes

I also created a feature request for your idea about the connection test function:

#47

At the end I am glad to let know that the fix for this current issue has been tested with success and the patch (in unmodified form) has been added to the bacularis-web repository.

Thank you again.

Best regards,
Marcin Haba (gani)

@sitemapxml
Copy link
Author

Hello @ganiuszka
Thank you for your response, and for the patch provided. I can confirm it is working now.
Best wishes,

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants