Last updated on Monday 28th of February 2022 08:52:48 PM
©XSIBackup: Ubuntu as an IP backup server
Things to take on account to use Ubuntu as a backup server for ©XSIBackup
Most of this considerations are extensible to many other distrosWe have dedicated some time to support non-root users on remote IP backup servers (version 18.104.22.168 August 2021). This could already be achieved by setting permissions manually, still we felt it was time to offer an easier way to manage this kind of operation.
Ubuntu and many other Linux distros or Unix OSs, don't allow plain root login. This is a basic security measure aimed at minimizing the possibilities to compromise your system.
What they do is that they enable some power user (user in the sudo group), usually set when installing the Operating System that has the capacity to switch to the root account once it has logged in. This used to be known as a user in the wheel group in OSs like FreeBSD which was among the first to implement this behaviour some years ago. You had to add a user to this group to be able to switch to the root user.
In modern Linux OSs like Ubuntu the user must belong to the sudo group to achieve the same. You can switch to the root user by typing sudo -i. You will then be asked for the sudo user's password to enter the shell as root.
This is a basic description of the sudo group functioning. Some other OSs like CentOS/RHEL/Fedora do allow the root user to login to the shell easing things quite a bit.
SSH ServerTo be able to operate with some fair degree of agility and use ©XSIBackup over IP you will have to enable the SSH server in your Ubuntu box. This can be done at install time or using the apt application management comand.
You can start by issuing
apt search openssh-server
This will let you know whether the ssh server is already installed. In case it's not you can install with.
apt install openssh-server
SSH Server ConfigurationThe SSH server is configured through the /etc/ssh/sshd_config file, which comes with a default configuration tuned up for each system. In Ubuntu it comes with the root user SSH login disabled. It makes sense, as it's also disabled for the console login.
Still to take advantage of ©XSIBackup to its full extent you will have to enable SSH root login. You can disable it once you have configured some alternative user.
To allow root login through SSH just edit the /etc/ssh/sshd_config file using your favourite text editor and set the line PermitRootLogin to yes.
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
#AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
You won't need to restart the service. Changes to /etc/ssh/sshd_config are read per SSH session, not by service loading.
You can easily check that the root user is enabled in SSH by just running some test command from some remote system, where 22.214.171.124 is the IP of your ubuntu backup server.
ssh firstname.lastname@example.org "echo 'HI THERE!'"
Enter the password when prompted to. If you see HI THERE! in your prompt, you're done with it.
Next is to link your ©ESXi box to the Ubuntu server by running the --add-key argument per each of the users you need to use to run commands against the Ubuntu box. You will normally want to do so for the root user and for some other user that we'll call the backup user.
./xsibackup --add-key email@example.com:22
./xsibackup --add-key firstname.lastname@example.org:22
(*) You must make sure that no firewall is blocking your SSH connection. You must ensure that SSH out rules exist where needed, apart from the SSH port being open at the remote end. This is done automatically when installing the SSH server in Ubuntu, in any case you must take this on account too.
If you are a novice and you are getting confused by too many variables to take into account and you can afford to do so (i.e. test environment), you can disable the firewalls and then re-enable them with the appropiate rules once you have configured your backup topology. Note that this is only recommended in controlled environments, like isolated LANs, it's your job to assess your risks.
Files at play and permissionsTo be able to run jobs from the ©ESXi host to the backup server over IP, you will need some binaries in the Ubuntu OS. Copying and configuring those binaries is done automatically when using the root user. You can't do it with any other user, as ©XSIBackup needs to copy files to the /bin folder and assign permissions to those files for all users in the backup server.
The files that ©XSIBackup will copy are:
You can find those files in the bin folder in the installation root folder of ©XSIBackup in your ©ESXi host.
The xsibackup binary is a plain copy of the main binary present in the root of the installation dir. It is updated every time you run ©XSIBackup, thus you don't have to worry about it being outdated.
The xsilib binary is an auxiliary executable.
base64 binary is a copy of the well known command line utility that ©XSIBackup copies to the remote end to make sure that it won't find any compatibility issue. It may overwrite any file by the same name at /bin/base64 if it's already present. That shouldn't cause any problem, as it will most probably be very similar if not the exact same binary. In any case you must know to prevent any conflict.
©XSIBackup server binaryWhen ©XSIBackup runs a job in your ©ESXi host, it makes use of the remote end binary to stablish an SSH tunnel among other things. The server binary in your Ubuntu's /bin folder must be able to write to the backup target folder, which will be storing your backups and replicas.
When you use the root user to copy data you are free to copy it anywhere you want in your FS, even to places that you should not copy it to. On the contrary, when you use a non full privileged user, you can only copy data to the directories to where this user has the right to create and write data. This is tipically its home folder at /home/backup, where backup is our Ubuntu user. You can also, of course, set your backup target to any other place in the remote Ubuntu's file system where the backup user has full access rights.
We have detected some subtle and difficult to determine inconsistencies when mixing the use of the root user and other non root users to the same folder. Per instance, if you first create a repository with the root user in some user's home dir, e.g.: /home/backup/repos/repo01 and then continue to write to it with the backup user, you can fall into permission denied errors when trying to write new blocks.
This is due to the ownership of the parent folders in the repository structure. Thus, to avoid having to fix permissions and ownership in the repos, configure your backup user and use it only to the predefined backup volume. You can of course use the root user to update the server components first and avoid having to do it manually, just make sure that the repository you write to was created by the backup user.
The log files at /var/log/xsiThe same reasoning as to the binary files above applies to the log files in the Linux server, with only one additional consideration: the log files must be created read and written to, you don't need execute permissions on these files though.
It could in fact become a security issue to assign execute permission on the /var/log/xsi dir. Thus ©XSIBackup will create these dir and the files therein contained with 0660 permissions. You may need to tweak permissions and/or ownership manually depending on who's the first user to create them, just keep this in mind.
In case of Ubuntu backends ©XSIBackup's job user should be asigned to the syslog group to make sure it has write rights on the /var/log dir.
The same applies to the files at the /etc/xsi directory, which will generally just need to be read for the configuration details.