Howto log multiple sftpd instances with their chroot shared via NFS

[Jochen Bern]

On 29.09.21 02:04, Douglas E Engert wrote:
> On 9/28/2021 6:29 PM, Peter Stuge wrote:
>> Hildegard Meier wrote:
>>> But the problem is that the last started syslog-ng aquires the lock
>>> for the NFS shared /var/data/chroot/<username>/dev/log so the other
>>> server cannot read it anymore
>>
>> Is it known what kind of lock this is? Was it investigated? Maybe on
>> the NFS server?
> 
> I suspect it is not a lock, but the "struct sockaddr_un" used with bind 
> and connect or
> some index into the server's kernal unix-stream  like process and fd 
> used in the bind is stored in the chrooted /dev/log when
> the syslog-ng creates it. The would match the statement:
>        > So, if a user logs in on the first server, where syslog-ng was 
> started least(last?), 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.
>      >
>      > If the syslog-ng is then restarted on the second server, the sftp 
> user's activity is exclusively logged only on the second server and only 
> for logins on the second server.

Somewhat different thought: If a newly-started syslogd on server A does 
indeed REMOVE AND RECREATE the /dev/log sockets, then any user logging 
into server B afterwards would find and open a socket that is not the 
same (inode number) as the one server B's syslogd (created and) opened 
when *it* started. Presto, implicit disconnect.

(The difference being that the socket itself would not have to store any 
additional state about the open FDs pointing to it, which I doubt it has 
any capacity for.)

If that theory holds, then all we'd need to do is to force both 
syslogd's to use *pre-existing* sockets instead ... (And add a little 
housekeeping background job that detects new users / chroots, creates 
the matching socket, and HUP's both syslogd's so as to reopen them all.)

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/20210929/bacd4349/attachment-0001.p7s>