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

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.

http://manpages.ubuntu.com/manpages/focal/man7/unix.7.html

Says: "The  AF_UNIX  (also  known  as  AF_LOCAL)  socket  family  is  used
to communicate between
        processes on the same machine efficiently.

The "same machine" is the key.

netstat should show what sockets are in use.
> 
> 
> Douglas E Engert wrote:
>> You already have 800 NFs volumes and they are all mounted on each
server.
> 
> AIUI there's only one NFS export with all homedirs mounted on each
server,
> and avoiding per-user runtime setup such as mounts is a requirement.
> 
> 
> Jochen Bern wrote:
>> I *still* suspect that if only you could configure the syslogd's to
use
>> a file locking method that just does *not* work across NFS shares -
>> there's about half a dozen different methods available, see, e.g.,
>>
>> https://dovecot.org/pipermail/dovecot/2011-July/060149.html
>>
>> -, you could circumvent that effect from the get-go ...
> 
> Looking through the afsocket module in syslog-ng it does no file locking.
> 
> 
> I'm curious what kind of locking it is. Maybe the contention is
> all within the NFS layer and could be overcome by setting a nolock
> or local_lock mount option on the SFTP servers, if either option is
> acceptable for the use case.
> 
> 
> Kind regards
> 
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
-- 

  Douglas E. Engert  <DEEngert at gmail.com>

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>