openssh unix dev - Sep 2021 - Howto log multiple sftpd instances with their chroot shared via NFS

Hi Hildegard,

On Tue, 21 Sep 2021, Hildegard Meier wrote:
> Now I have a second sftpd server in parallel, with the same user 
> database and also mounts /var/data/chroot/ via NFS, and has the same 
> syslog-ng config,
> so every user can login on the one server or on the other. This is for 
> high availability. This works so far.
>
> What is not working now is the sftpd logging: The sftp user's log is 
> only available on one sftp server exclusively, and that is the one 
> where syslog-ng was started least, because as I understand it takes 
> the exclusive unix socket file lock for each user's /dev/log.
>
> So, if a user logs in on the first server, where syslog-ng was started 
> least, the user's sftp activity is logged on the first server.
> But if the user logs in on the second server, it's sftp activity is 
> not logged, neither on the second nor on the first server.
Forward the log entries on both machines to a log host.? E.g.

    destination d_tcp {
         network("log_host" port(1999));
    };

Regards,

David

On 22.09.21 11:18, David Newall wrote:
> On Tue, 21 Sep 2021, Hildegard Meier wrote:
>> So, if a user logs in on the first server, where syslog-ng was started 
>> least, the user's sftp activity is logged on the first server.
>> But if the user logs in on the second server, it's sftp activity is
>> not logged, neither on the second nor on the first server.
> 
> Forward the log entries on both machines to a log host.
Considering that server B is not logging *at all* right now, I doubt 
that it'll have anything to forward to a log host, either.

The problem *presumably* is that the syslogd on server A has put some 
sort of file lock on the device that propagates through the NFS server 
and interferes with syslogd on server B using it.

One solution might be to reconfigure the syslogd's to use a method of 
locking that does *not* propagate through NFS. I'm afraid I don't know 
syslog-ng well enough to advise on that.

Then there's the possibility of reconfiguring *NFS* to stop the 
forwarding, but "breaking" file locking on NFS is, of course, a can of
worms of possible side effects ...

(Bind) mounting a local .../dev over the NFS-shared chroot dirtree ... 
ought to work, but complicates unmounting/remounting, which was already 
enough of a hair-puller in failure scenarios when I last worked with NFS.

What do the chrooted users have for a homedir *within* the chroot? Would 
it be possible to have /var/data/chroot be a local FS and mount only 
/var/data/chroot/home from the NFS server? (If there are files that you 
need to keep identical on both servers, e.g., under 
/var/data/chroot/etc, you can still symlink those to some special subdir 
like /var/data/chroot/home/ETC to put the actual data onto the NFS share.)

Regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3449 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20210922/b8e64b32/attachment.p7s>