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

Hallo all, thank You all very much for your answers and suggestions.
Since the discussion has been shared between several mails now, I would like to
try to summarize all up in one mail again here
and fill in the informations that where missing before.

We have 800 (eight hundred) sftp customers, each sftp customer has the same
simple local Linux account on both sftp servers (simple entry in /etc/passwd and
/etc/shadow etc.).
(Before we had only one sftp server, but for higher availability we want now to
run two or more sftp servers parallel, accessed via TCP (sftp) load balancer)

Each customer account is in the group "sftp-cust", and only members of
that group are allowed to login via sftp.
Each customer has it's chrooted home dir in
/var/data/chroot/<username>/.

Here the (relevant part) of the sftpd config:

---------------------------------------------------------------
AllowGroups sftp-cust
Subsystem sftp internal-sftp -f LOCAL5 -l INFO
Match Group sftp-cust
    ChrootDirectory %h
    ForceCommand internal-sftp -u 0002 -f LOCAL5 -l INFO
    AllowTcpForwarding no
---------------------------------------------------------------

Each sftp customer's sftp activity needs to be available in a dedicated log
file for each sftp customer, for our support to be able to look into it. Here is
an example of this log file:

Sep 28 15:54:25 myhostname internal-sftp[1618]: session opened for local user
<username> from [1.2.3.4]
Sep 28 15:55:52 myhostname internal-sftp[27918]: remove name
"/in/file.dat"
Sep 28 15:55:52 myhostname internal-sftp[27918]: sent status No such file
Sep 28 15:55:52 myhostname internal-sftp[27918]: open "/in/file.dat"
flags WRITE,CREATE,TRUNCATE mode 0666
Sep 28 15:55:52 myhostname internal-sftp[27918]: close "/in/file.dat"
bytes read 0 written 2966
Sep 28 15:55:52 myhostname internal-sftp[27918]: set "/in/file.dat"
modtime 20210928-15:55:46

If one does not use the /dev/log in the chroot environment (that is
/var/data/chroot/<username>/dev/log absolute), you have a global sftpd log
(I think in /var/log/messages on the server or something like that).
So a solution for the log problem would be, to not use the chroot logging, but
to parse the global sftpd log (which is available on both sftpd servers locally
for all local logins separated).
But I think this is not trivial to make this reliable and robust, since we need
to parse the process id (sftpd session), check which username that session
belongs to and write that log lines in the username specific log file.
Of course, process IDs are reused for different sessions, we have overlapping
sessions etc. But if there is no other solution, than we need to try that. Maybe
someone has already written such a session tracking parser.
Does somebody know of a log analyzer that can do this? A problem would be e.g.
if the user never logs out, and the log file rotates daily, so after one day,
the parser could not find any "session opened for local user xxx" log
lines anymore.

If we want to try to keep using the available session chroot logging, man (8)
sftp-server says:

"For logging to work, sftp-server must be able to access /dev/log.  Use of
sftp-server in a chroot configuration therefore requires that
     syslogd(8) establish a logging socket inside the chroot directory."

As Peter has written here
https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-September/039669.html

as I understand it is hard coded in the system C library that the log devices
name is /dev/log, so this cannot be changed (e.g. to log to chrooted
/dev/log_hostname1 on hostname1 and chrooted /dev/log_hostname2 on hostname2).

With the syslog-ng we use, we only need to create the directory
/var/data/chroot/<username>/dev for each user once we create a new
account.

We have the following syslog-ng config snippet file for each sftp user:

source s_chroot_<username>    {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes)
); };
destination d_sftp_<username> {
file("/var/log/app/sftp/<username>.log"); };
log                           { source(s_chroot_<username>);
destination(d_sftp_<username>); };

When starting syslog-ng the unix stream file
/var/data/chroot/<username>/dev/log is created automatically by syslog-ng.
If you delete it it gets recreated upon syslog-ng restart.

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 and so there is no sftp log for the sessions on the other server.

I guess this is because syslog-ng creates /dev/log in the user's chroot
directories as Unix stream socket (see
https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.22/administration-guide/28#TOPIC-1209171).
 This seems also to be called IPC socket (inter-process communication socket)  
or AF_UNIX socket.
"It is used in POSIX operating systems for inter-process communication. The
correct standard POSIX term is POSIX Local IPC Sockets. Unix domain connections
appear as byte streams, much like network connections, but all data _remains
within the local computer_."

"It means that if you create a AF_UNIX socket on a NFS disk which is shared
between two machines A and B, you cannot have a process on A writing data to the
unix socket and a process on B reading data from that socket.
The communication happens at kernel level, and you can only transfer data among
processes sitting in the same kernel."
(see source:
https://stackoverflow.com/questions/783134/af-unix-domain-why-use-local-file-names-only
)

Since we have 800 users, it would be impractical unrobust to use user-specifc
e.g. bind) mounts (e.g. 800 bind-over-mounts). To keep it simple, clear and
coherent, all user's homes must be on the same one singular NFS-Share.

We need to stick with Ubuntu Linux as we have established management process
only for this operating systems.

I hope I did not forget some information that was missing before. Thanks 
Hildegard


> Gesendet: Mittwoch, 22. September 2021 um 09:19 Uhr
> Von: "Damien Miller" <djm at mindrot.org>
> An: "Hildegard Meier" <daku8938 at gmx.de>
> Cc: openssh-unix-dev at mindrot.org
> Betreff: Re: Howto log multiple sftpd instances with their chroot shared
via NFS
>
> On Tue, 21 Sep 2021, Hildegard Meier wrote:
>
> > OpenSSH 5.9p1 + 7.6p1
> >
> > syslog-ng 3.3.4 + 3.13.2
> >
> > Hello, having an Ubuntu server with sftpd running where
/var/data/chroot/ is an NFS mount from a remote central NFS server,
> > and each sftpd user's chroot home is
/var/data/chroot/<username>/
> > and every user has a log device
/var/data/chroot/<username>/dev/log which I read in successfully with
syslog-ng:
> >
> > source s_chroot_<username> {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes)
); };
> > destination d_sftp_<username> {
file("/var/log/sftp/<username>.log"); };
> > log { source(s_chroot_<username>);
destination(d_sftp_<username>); };
> >
> > 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.
> >
> > 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.
> >
> > How can I get the sftp user's activity be logged on each sftp
server, when a user logs in to that server, while the user's home is shared
on both servers via NFS?
>
> Right now there is no solution for this inside OpenSSH. There have been
> some proposals for post-auth logging to be proxied via the priviledged
> sshd monitor process but we haven't pursued them yet.
>
> Maybe someone with more Linux/NFS wit could suggest an OS-side solution
> for you?
>
> -d
>

Hallo Hildegard,

thanks for the summary.

Hildegard Meier wrote:
> ---------------------------------------------------------------
> AllowGroups sftp-cust
> Subsystem sftp internal-sftp -f LOCAL5 -l INFO
> Match Group sftp-cust
>     ChrootDirectory %h
>     ForceCommand internal-sftp -u 0002 -f LOCAL5 -l INFO
>     AllowTcpForwarding no
> ---------------------------------------------------------------
This is very sensible configuration but it unfortunately makes the
LD_PRELOAD approach a bit less desirable. It will still work though.

> So a solution for the log problem would be, to not use the chroot
> logging, but to parse the global sftpd log
..
> But I think this is not trivial to make this reliable and robust,
Agreed. If going the log analysis path I would add -e to the
internal-sftp command line and run sshd with stderr connected to that
parser, to be able to keep track of events in a sensible way.
Log rotation would happen only after (or in) the parser.

> If we want to try to keep using the available session chroot
> logging, man (8) sftp-server says:
> 
> "For logging to work, sftp-server must be able to access /dev/log. 
Use of sftp-server in a chroot configuration therefore requires that
>      syslogd(8) establish a logging socket inside the chroot
directory."
> 
> As Peter has written here
>
https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-September/039669.html
> 
> as I understand it is hard coded in the system C library that the log
> devices name is /dev/log, so this cannot be changed (e.g. to log to
> chrooted /dev/log_hostname1 on hostname1 and chrooted /dev/log_hostname2
> on hostname2).
Using LD_PRELOAD e.g. with the code I attached to that email allows
replacing the C library syslog functionality. My attachment does
indeed log to /dev/log_hostname1 on hostname1 instead of /dev/log.

However because of internal-sftp (which I still prefer over the alternative;
maintaining an sftp-server binary and possibly libraries in every homedir)
the entire sshd would have to be run with LD_PRELOAD.

Note that LD_PRELOAD is only neccessary on n-1 servers; the first
server can still use /dev/log and the full C library syslog() code.

If the second server where LD_PRELOAD is used does not need to
support anything besides SFTP, or if you can mandate that, then
it could be okay to run the entire sshd with LD_PRELOAD. Your IT
security colleagues may well object and they're not wrong; it's not
much code but still quite a mighty hammer.

> > Maybe someone with more Linux/NFS wit could suggest an OS-side
solution
> > for you?
Before going down the LD_PRELOAD path I considered an overlayfs solution.

It would be nice, but the writable (upper) directory can't be NFS
with overlayfs so it can not work on the SFTP servers.

But using overlayfs can work on the NFS server. There would then be
one export for each SFTP server, all of them reaching the same
homedir contents except for different (empty) <homedir>/dev/ subdirs.

This requires maintaining a second homedir structure on the NFS server,
but that structure only needs to contain a homedir with one empty dev
subdir under and nothing else, so it may be doable. Homedirs need
correct permissions and only one of the two directory inodes for the
homedir itself will be changed by the respective SFTP server, but on
the plus side it requires only a single overlay mount, nothing per-user
and no LD_PRELOAD stuff on the SFTP servers.


On the NFS server, assuming that /home is where real homedirs exist
(this gets mounted directly by one SFTP server), that /var/home2 is
the second homedir structure with only homedirs and an empty dev subdir
in each, that /var/home2_work is an empty directory on the same filesystem
as /var/home2 and that /nfs/home2 is the second export mounted by the
second SFTP server, then set it up like so:

mount -t overlay overlay
-olowerdir=/home,upperdir=/var/home2,workdir=/var/home2_work /nfs/home2


Then export /home and /nfs/home2 via NFS.

The SFTP server mouting /home will access /home/<user>/dev/log
(both syslog-ng and internal-sftp) and the SFTP server mouting
/nfs/home2 will instead access /var/home2/<user>/dev/log but
everything else within the homedir is to and from /home/<user>.

If this change can be done on the NFS server I think it's what I'd
prefer.


Kind regards

//Peter

I like Peter's overlay concept. Ubuntu has aufs-tools to use builtin kernal
code. These add mount.aufs

But here is another proposal.

You already have 800 NFs volumes and they are all mounted on each server.
(This is based on the syslog-ng configure which create a unix-stream in every
volume when started.)

I assume that the only difference between these volumes is the user's home
directory with
files they transfer to and from. And the user has only read access to whatever
else is in the volume.
I assume they must have a /etc/passwd file with only one user.

Create 800 duplicate volumes on each server (not in NFS), but without the
user's home directory.
for example /var/data/sftp/<username>/chroot/


modify the current 800 NFS volumes so they can be NFS mounted as the user's
home in the above
new volumes.

Thus each sftp server uses the  /var/data/sftp/<username>/chroot/dev/log
which is on the same host
rather then a shared /dev/log. Its more complicated, but no local modifications.


On 9/28/2021 10:00 AM, Hildegard Meier wrote:
> Hallo all, thank You all very much for your answers and suggestions.
> Since the discussion has been shared between several mails now, I would
like to try to summarize all up in one mail again here
> and fill in the informations that where missing before.
> 
> We have 800 (eight hundred) sftp customers, each sftp customer has the same
simple local Linux account on both sftp servers (simple entry in /etc/passwd and
/etc/shadow etc.).
> (Before we had only one sftp server, but for higher availability we want
now to run two or more sftp servers parallel, accessed via TCP (sftp) load
balancer)
> 
> Each customer account is in the group "sftp-cust", and only
members of that group are allowed to login via sftp.
> Each customer has it's chrooted home dir in
/var/data/chroot/<username>/.
> 
> Here the (relevant part) of the sftpd config:
> 
> ---------------------------------------------------------------
> AllowGroups sftp-cust
> Subsystem sftp internal-sftp -f LOCAL5 -l INFO
> Match Group sftp-cust
>      ChrootDirectory %h
>      ForceCommand internal-sftp -u 0002 -f LOCAL5 -l INFO
>      AllowTcpForwarding no
> ---------------------------------------------------------------
> 
> Each sftp customer's sftp activity needs to be available in a dedicated
log file for each sftp customer, for our support to be able to look into it.
Here is an example of this log file:
> 
> Sep 28 15:54:25 myhostname internal-sftp[1618]: session opened for local
user <username> from [1.2.3.4]
> Sep 28 15:55:52 myhostname internal-sftp[27918]: remove name
"/in/file.dat"
> Sep 28 15:55:52 myhostname internal-sftp[27918]: sent status No such file
> Sep 28 15:55:52 myhostname internal-sftp[27918]: open
"/in/file.dat" flags WRITE,CREATE,TRUNCATE mode 0666
> Sep 28 15:55:52 myhostname internal-sftp[27918]: close
"/in/file.dat" bytes read 0 written 2966
> Sep 28 15:55:52 myhostname internal-sftp[27918]: set
"/in/file.dat" modtime 20210928-15:55:46
> 
> If one does not use the /dev/log in the chroot environment (that is
/var/data/chroot/<username>/dev/log absolute), you have a global sftpd log
(I think in /var/log/messages on the server or something like that).
> So a solution for the log problem would be, to not use the chroot logging,
but to parse the global sftpd log (which is available on both sftpd servers
locally for all local logins separated).
> But I think this is not trivial to make this reliable and robust, since we
need to parse the process id (sftpd session), check which username that session
belongs to and write that log lines in the username specific log file.
> Of course, process IDs are reused for different sessions, we have
overlapping sessions etc. But if there is no other solution, than we need to try
that. Maybe someone has already written such a session tracking parser.
> Does somebody know of a log analyzer that can do this? A problem would be
e.g. if the user never logs out, and the log file rotates daily, so after one
day, the parser could not find any "session opened for local user xxx"
log lines anymore.
> 
> If we want to try to keep using the available session chroot logging, man
(8) sftp-server says:
> 
> "For logging to work, sftp-server must be able to access /dev/log. 
Use of sftp-server in a chroot configuration therefore requires that
>       syslogd(8) establish a logging socket inside the chroot
directory."
> 
> As Peter has written here
>
https://lists.mindrot.org/pipermail/openssh-unix-dev/2021-September/039669.html
> 
> as I understand it is hard coded in the system C library that the log
devices name is /dev/log, so this cannot be changed (e.g. to log to chrooted
/dev/log_hostname1 on hostname1 and chrooted /dev/log_hostname2 on hostname2).
> 
> With the syslog-ng we use, we only need to create the directory
/var/data/chroot/<username>/dev for each user once we create a new
account.
> 
> We have the following syslog-ng config snippet file for each sftp user:
> 
> source s_chroot_<username>    {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes)
); };
> destination d_sftp_<username> {
file("/var/log/app/sftp/<username>.log"); };
> log                           { source(s_chroot_<username>);
destination(d_sftp_<username>); };
> 
> When starting syslog-ng the unix stream file
/var/data/chroot/<username>/dev/log is created automatically by syslog-ng.
If you delete it it gets recreated upon syslog-ng restart.
> 
> 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 and so there is no sftp log for the sessions on the other
server.
> 
> I guess this is because syslog-ng creates /dev/log in the user's chroot
directories as Unix stream socket (see
https://www.syslog-ng.com/technical-documents/doc/syslog-ng-open-source-edition/3.22/administration-guide/28#TOPIC-1209171).
>   This seems also to be called IPC socket (inter-process communication
socket)   or AF_UNIX socket.
> "It is used in POSIX operating systems for inter-process
communication. The correct standard POSIX term is POSIX Local IPC Sockets. Unix
domain connections appear as byte streams, much like network connections, but
all data _remains within the local computer_."
> 
> "It means that if you create a AF_UNIX socket on a NFS disk which is
shared between two machines A and B, you cannot have a process on A writing data
to the unix socket and a process on B reading data from that socket.
> The communication happens at kernel level, and you can only transfer data
among processes sitting in the same kernel."
> (see source:
https://stackoverflow.com/questions/783134/af-unix-domain-why-use-local-file-names-only
)
> 
> Since we have 800 users, it would be impractical unrobust to use
user-specifc e.g. bind) mounts (e.g. 800 bind-over-mounts). To keep it simple,
clear and coherent, all user's homes must be on the same one singular
NFS-Share.
> 
> We need to stick with Ubuntu Linux as we have established management
process only for this operating systems.
> 
> I hope I did not forget some information that was missing before. Thanks 
Hildegard
> 
> 
> 
>> Gesendet: Mittwoch, 22. September 2021 um 09:19 Uhr
>> Von: "Damien Miller" <djm at mindrot.org>
>> An: "Hildegard Meier" <daku8938 at gmx.de>
>> Cc: openssh-unix-dev at mindrot.org
>> Betreff: Re: Howto log multiple sftpd instances with their chroot
shared via NFS
>>
>> On Tue, 21 Sep 2021, Hildegard Meier wrote:
>>
>>> OpenSSH 5.9p1 + 7.6p1
>>>
>>> syslog-ng 3.3.4 + 3.13.2
>>>
>>> Hello, having an Ubuntu server with sftpd running where
/var/data/chroot/ is an NFS mount from a remote central NFS server,
>>> and each sftpd user's chroot home is
/var/data/chroot/<username>/
>>> and every user has a log device
/var/data/chroot/<username>/dev/log which I read in successfully with
syslog-ng:
>>>
>>> source s_chroot_<username> {
unix-stream("/var/data/chroot/<username>/dev/log" optional(yes)
); };
>>> destination d_sftp_<username> {
file("/var/log/sftp/<username>.log"); };
>>> log { source(s_chroot_<username>);
destination(d_sftp_<username>); };
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> How can I get the sftp user's activity be logged on each sftp
server, when a user logs in to that server, while the user's home is shared
on both servers via NFS?
>>
>> Right now there is no solution for this inside OpenSSH. There have been
>> some proposals for post-auth logging to be proxied via the priviledged
>> sshd monitor process but we haven't pursued them yet.
>>
>> Maybe someone with more Linux/NFS wit could suggest an OS-side solution
>> for you?
>>
>> -d
>>
> _______________________________________________
> 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 28.09.21 17:00, Hildegard Meier wrote:
> Each sftp customer's sftp activity needs to be available in a
> dedicated log file for each sftp customer, for our support to
> be able to look into it. Here is an example of this log file:
> 
> Sep 28 15:54:25 myhostname internal-sftp[1618]:
>     session opened for local user <username> from [1.2.3.4]
(General warning from me: There are log messages from the user's session 
*earlier* than that, from before the client successfully authenticated 
for the login as <username>. Having those messages go into a per-account 
log(file) is nontrivial because sshd *does not yet know* what username 
it will be, and if your support staff cannot see those lines, they will 
not be able to debug *failed* connection attempts.)

At this point, I'd say that the best approach would be to have the 
post-auth sftp-server process log to a *file* within the chroot, with 
the filename set to the server's hostname (in the ForceCommand statement 
of the server's /etc/ssh/sshd_config). Unfortunately, while sftp-server 
has command line options for logging to syslog and for logging to 
stderr, it does *not* have a command line option to log to a *file* (or, 
for that matter, to set/change the "ident" parameter of openlog(3) to 
include the username) ...
> you have a global sftpd log (I think in /var/log/messages on the
> server or something like that)
(RHEL, Centos, Fedora etc. tend to have a /var/log/messages . Ubuntu, in 
my experience, uses /var/log/syslog instead.)
> But I think this is not trivial to make this reliable and robust,
> since we need to parse the process id (sftpd session), check which
> username that session belongs to and write that log lines in the
> username specific log file.
That's essentially what tools like opentelemetry.io are talking about 
when they make a difference between "logs" and "traces", but
I suppose
that throwing one of those at your problem could easily prove to be 
overkill ...

https://opentelemetry.io/docs/concepts/data-sources/
> A problem would be e.g. if the user never logs out, and the log file
> rotates daily, so after one day, the parser could not find any
> "session opened for local user xxx" log lines anymore.
That's why log-parsing utilities that are worth their salt (logwatch, 
ConSol's check_logfiles, etc.) can be configured to find and include the 
rotated-away previous logfile instances ...
> as I understand it is hard coded in the system C library that the
> log devices name is /dev/log, so this cannot be changed
Well, not on Linux, at least ...

[still fondly remembers AIX "softlinks" where you could "ln
-s"
something to "/foo/$BAR/baz" and the value of the env var BAR would be
taken into account at access/expansion time]
> 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 and so there is no sftp log for the
> sessions on the other server.
(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 ...)

Kind 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/20210928/5cad1cbe/attachment-0001.p7s>

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?


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

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.

> Von: "Hildegard Meier" <daku8938 at gmx.de>
> If one does not use the /dev/log in the chroot environment (that is
/var/data/chroot/<username>/dev/log absolute), you have a global sftpd log
(I think in /var/log/messages on the server or something like that).
Sorry I think this is not true, I think I confused this with the first situation
when I did not fetch each sftp chrooted user's /dev/log with a specific
syslog-ng source config,
but just the whole sftp session logs from all users wnet to facility LOCAL5 and
I fetched facility LOCAL5 into one log file. But /dev/log in each sftp
user's chroot dir was required for that, though.