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 anymoreIs 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 whenthe 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
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
