Re: [BackupPC-users] Fatal error (bad version): /sbin/nologin: invalid option

[Holger P. <wb...@pa...>]

Hi,

Les Mikesell wrote on 2015-10-28 12:56:16 -0500 [Re: [BackupPC-users] Fatal error (bad version): /sbin/nologin: invalid option]:
> On Wed, Oct 28, 2015 at 12:04 PM, fujisan
> <bac...@ba...> wrote:
> > [...]
> > So this nologin erro message does not seem to come from user backuppc.
> 
> Could it be coming from the remote side via ssh?

yes, it obviously is, and no, I don't understand that either. I went through
the BackupPC code involved yesterday, and I'm convinced the error message can
*only* come from the remote side, because no shell on the BackupPC server is
involved.

> I don't see why that would be different when starting from the server
> command line vs the web interface but maybe there is something different
> about the ssh key that is used.

Well, we're guessing here. I don't see how a different ssh key would change
the remote user's shell (and please note that '-l root' was explicitly
specified in the RsyncClientCmd), but the one difference I do see is that

# su -s /bin/bash backuppc

(from memory) doesn't force a "login environment", so you *might* be using
root's .ssh/config in one case and backuppc's in the other, which could, in
theory, map your client host name to a different machine with a

	Host foo
	  HostName bar

type directive (or to a different ssh port - e.g. for an sshd inside a chroot
- in much the same way). That is the only reason that I can think of why
root@whateverthenamewas would have /sbin/nologin as shell in one case and a
working shell in the other. Well, maybe PAM could also do that somehow.

I'm convinced it will turn out to be something completely different, though,
but I would try using

	su -s /bin/bash - backuppc

(note the '-' (or '-l') parameter) and look whether that *stops* the command
line backup from working.

> In any case, the issue seems to be something about your shell setup rather
> than in backuppc itself.

Definitely.

Regards,
Holger