Hi,
Bhaskar S. Manda wrote on 2014-02-17 15:56:59 -0600 [[BackupPC-users] Need
run-time variable substitution for SSH username]:
> It should be easier to run as a non-root user on the client.
it is :-).
> It is confusing now because we specify a username on the client in the host
> configuration, however the SSH session to the client is not using this
> username.
While in your case the user name specified in the 'hosts' file configuration
of BackupPC might coincide with the user account name on the backup client
under which backups should be run, this is not a general concept. Until now,
this user name has two distinct meanings:
1.) the web user which has administrative privileges for managing the host's
BackupPC configuration via the web interface and
2.) the email account name of the user receiving notifications for the host,
relative to $Conf {EMailUserDestDomain}.
Generally, the web user name can be chosen arbitrarily to match the email
account name. Requiring all users to share a single email domain can be
somewhat awkward - this can usually be overcome by using local (unqualified)
adresses and setting up aliases for them on the BackupPC server. It could
probably also be fixed by adding a configuration option for specifying an
email address per host (say $Conf{EMailUserAddress}). Strictly speaking, the
web user name and the email user name - even if this is a local address on the
BackupPC server - may be in different administrative domains, meaning you
might not have the power to chose both of them freely.
The account name *on the backup client*, under which the backup is to be run,
is yet within a third administrative domain. If you are lucky, these three
domains overlap, you get to chose all three user names, and you can set them
up to match and be unique for each backup definition (i.e. 'host' within
BackupPC). In the general case, though, you don't get to chose the account on
the machine to be backed up, meaning there may be collisions between clients,
or the values may be unsuited for mailing (say 'root' ...).
> Instead, the suggested RsyncClientCmd and RsyncClientRestoreCmd
> use the username 'root' , as follows.
> $Conf{RsyncClientCmd} = '$sshPath -q -x -l root $host $rsyncPath
> $argList+';
The important word here is "suggested". This setting is a suggestion, that is
meant to work for "most people" with simple setups. If you change the user
name, it generally will not work, because you either need to add (and
configure!) a 'sudo' invocation or something similar for privilege escalation,
or define your backup set to be completely readable by the user of choice. In
this sense, running backups under non-root users is an advanced setup requiring
manual consideration and configuration. This does not become in any way easier
by adding a means to substitute the "backup owner name" somewhere in the command
- this would merely allow making *some* configurations a bit cleaner.
> Several variable substitutions are being done, but not for client username.
> Instead we can hard-code it in place of 'root'. This however means that the
> username on the client has to be specified in multiple places - in the file
> hosts, and 2 times in each client's config.pl.
That is not necessarily true. As I have pointed out, the name in the 'hosts'
file is not identical with the user name to be used with ssh, though it
*might* coincidentally take the same value for you. You might just as well
chose the *host name* as user name for ssh (i.e. 'ssh -l machine1 machine1');
then the substitution you are suggesting would be possible without any change.
Or you could chose 'backuppc' as user name and would have an identical command
for all hosts without substition (of the user name).
Of course, if you are doing backups of *user home directories* under the
users' account names, you will need to get these names from somewhere. Even in
this case, I would suggest naming the backups after the users and using
$Conf {ClientNameAlias} to point at the hosts hosting the home directories.
This would make the case where one host hosts several home directories more
natural to handle, where you would need aliases pointing to the same host
anyway.
Actually, I would suggest *not* to do that at all, because giving password-
less access to user accounts does not seem a good idea. You can limit it to
the backup command, and the user can break things inadvertantly, e.g. by
making his home directory writable for others or fiddling with his
.ssh/authorized_keys. A dedicated backup account and privilege escalation with
sudo seem much cleaner and more robust.
The more I think about this, the more I get the impression that your attempt
at using the email user name as client backup user name means that you are
doing something wrong. It's your decision, but since you're asking, I'll point
it out.
All of that said, you *can* configure the user name to be used in
~backuppc/.ssh/config (on the BackupPC server), e.g.
Host backup-client-1
User backup-user-name-1
Host backup-client-2
User backup-user-name-2
Host backup-client-n
User backup-user-name-n
HostName 1.2.3.4
Port 2222
IdentityFile ~/.ssh/id_%h_rsa
Host *
User root
ForwardAgent no
ForwardX11 no
StrictHostKeyChecking yes
You would then leave out the '-l' switch in the RsyncClient*Cmd settings
altogether. This still means that you have to set up the host name to user
name mapping somewhere, and it can be somewhat confusing to have it hidden in
.ssh/config, but on the other hand, 'ssh backup-client-x' will work
consistently from BackupPC and the command line, and you can set up a lot of
things you might need or want to, like different identity files, different
port numbers, compression and encryption options, keep alives for firewalls
and so on, and you can have identical RsyncClient*Cmd settings for all hosts.
> I request that things be simplified by doing a variable substitution for
> $sshLogin [...]
If at all this is considered, it should *not* be called $sshLogin, because
that's not what the value means. It's $emailUserName or perhaps $backupOwner.
If we provide a substitution $sshLogin, we need a setting $Conf {SshLogin},
and we don't really gain much, except that we specify the user name once
instead of once or twice (if you explicitly disable direct restores, you don't
even have it in RsyncClientRestoreCmd). Sure, you'd get one centralized
setting of RsyncClient*Cmd, but I honestly don't expect that to be changed
(for all hosts) all that often ...
Hope that helps.
Regards,
Holger
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
