Thanks Douglas,
did not know abount "mount move" before, interesting.
But unfortunateley, it would be an impractical complicated mess to have this hundrets of extra mounts, which additionally are server specific, so at least for me this would not be a possible approach.
Additionally, reading the mount man page I doubt this would be possible, anyway. I guess /dev/log would not be available in the chroot anymore.
And it says "moving a mount residing under a shared mount is invalid and unsupported".
But as said, this is approach is impractical for me anyways.
"The move operation
Move a mounted tree to another place (atomically). The call is:
mount --move olddir newdir
This will cause the contents which previously appeared under olddir to now be accessible under newdir. The physical location of the files
is not changed. Note that olddir has to be a mountpoint.
Note also that moving a mount residing under a shared mount is invalid and unsupported. Use findmnt -o TARGET,PROPAGATION to see the cur‐
rent propagation flags."
> Gesendet: Mittwoch, 29. September 2021 um 15:34 Uhr
> Von: "Douglas E Engert" <deengert@xxxxxxxxx>
> An: openssh-unix-dev@xxxxxxxxxxx
> Betreff: Re: Howto log multiple sftpd instances with their chroot shared via NFS
>
> Thanks for the info on the single NFS volume mount.
>
> Another take on the direct bind mount:
>
>
> If server1 did:
> source s_chroot_<username> { unix-stream("/var/data/chroot/<username>/dev/log_server1" optional(yes) ); };
>
> Then for each user server1 would also do (or have in fstab):
> mount -bind /var/data/chroot/<username>/dev/log /var/data/chroot/<username>/dev/log_server1
>
> and server2 did:
> source s_chroot_<username> { unix-stream("/var/data/chroot/<username>/dev/log_server1" optional(yes) ); };
> and also do this:
> mount -move /var/data/chroot/<username>/dev/log /var/data/chroot/<username>/dev/log_server2
>
> This would allow each server to have its own /dev/log_host so they would not overwrite each others,
> but when the libc went to write to the chrooted /dev/log, the kernel would write to /dev/log_serverX because
> the direct bind is in the host's kernel.
>
>
>
> I have not tried this.
>
>
>
> On 9/29/2021 3:42 AM, Hildegard Meier wrote:
> > Hi, I tried now the following:
> >
> > Add the following line to /etc/fstab:
> >
> > /var/data/chroot /usr/local/sftp_chroot_bind_mount none bind 0 2
> >
> > Then:
> > mkdir /usr/local/sftp_chroot_bind_mount
> > mount /usr/local/sftp_chroot_bind_mount
> >
> > to bind-mount the users's chroot home to /usr/local/sftp_chroot_bind_mount
> >
> > Then replace in the syslog-ng config:
> >
> > source s_chroot_<username> { unix-stream("/var/data/chroot/<username>/dev/log" optional(yes) ); };
> > with
> > source s_chroot_<username> { unix-stream("/usr/local/sftp_chroot_bind_mount/<username>/dev/log" optional(yes) ); };
> >
> > Restart syslog-ng
> >
> > That would have been such a simple workaround.
> > But unfortunately, the problem is not solved with this.
> > The problem is the same, that there is sftp logging only on the sftp server where syslog-ng was restarted least.
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev@xxxxxxxxxxx
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> > .
> >
>
> --
>
> Douglas E. Engert <DEEngert@xxxxxxxxx>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@xxxxxxxxxxx
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
