Package Details: proftpd 1:1.3.6-4

Git Clone URL: https://aur.archlinux.org/proftpd.git (read-only)
Package Base: proftpd
Description: High-performance, scalable FTP server
Upstream URL: http://www.proftpd.org/
Licenses: GPL
Submitter: xyproto
Maintainer: migrev
Last Packager: migrev
Votes: 51
Popularity: 0.786213
First Submitted: 2013-05-16 15:03
Last Updated: 2019-01-21 08:22

Latest Comments

1 2 3 Next › Last »

archtom commented on 2019-01-21 08:41

@migrev: Thanks a lot for the fast response und the update ;)

migrev commented on 2019-01-21 08:24

@eomain: Sorry I didn't address this earlier, your messages just went by without noticing. Just saw them today while addressing the mariadb stuff. Patches from 1.3.7 applied and bumped to release 4 with them. Hope it helps.

migrev commented on 2019-01-21 08:10

@archtom: Thanks! PKGBUILD updated per your indications.

archtom commented on 2019-01-21 07:44

Thanks for maintaining the package.

After updating mariadb to the latest version please rebuild this package (and update the pkgbuild) against mariadb-libs instead of libmariadbclient.

Otherwise starting will fail with /usr/bin/proftpd: error while loading shared libraries: libmysqlclient.so.18: cannot open shared object file: : No such file or directory.

Thanks

eomanis commented on 2018-07-15 12:54

Regarding mod_facl, there seems to be a bug around that crashes proftpd when it receives a SIGHUP in certain configurations:

2018-07-15 00:00:19,948 myserver proftpd[670] myserver: received SIGHUP -- master server reparsing configuration file
2018-07-15 00:00:20,130 myserver proftpd[670] myserver: XXX.XXX.XXX.XXX:NNNN masquerading as YYY.YYY.YYY.YYY
2018-07-15 00:00:20,131 myserver proftpd[670] myserver: error: duplicate fs paths not allowed: '/'
2018-07-15 00:00:20,131 myserver proftpd[670] myserver: mod_facl/0.6: error registering 'facl' FS: File exists

The bug is apparently fixed upstream and has been backported to 1.3.6.
Unfortunately, as of now, no bugfix release seems to have been published.

I suspect the SIGHUP was sent by logrotate.

I do not wish to use logrotate; it seems superfluous to me. Rather, I want systemd to be exclusively responsible for logging, and systemd by default grabs and logs everything that is written to stdout and stderr.
Therefore I am running proftpd in non-forking mode using a custom systemd .service file, which has this simplified [Service] section:

[Service]
Type=simple
ExecStart=/usr/bin/proftpd --nodaemon --config /etc/proftpd.conf

proftpd(8) states:

-n, --nodaemon
  Runs the proftpd in standalone mode (...) but does not background the process (...).
  Additionally, all output (log or debug messages) are sent to stderr, rather than the
  syslog mechanism. (...)

Do we really need logrotate? Apart from having --nodaemon, proftpd(8) also states that proftpd logs to syslog if it uses the historic forking-with-PIDFile mode of operation. I guess this means that proftpd does not create any log files of its own that need rotating.

EDIT
Yes, we do need logrotate if we want to have an xferlog-format transfer log, because said transfer log is a special kind of beast that does not go to syslog, nor to stdout/stderr for that matter if running with --nodaemon.
So if we use mod_facl, currently we have to disable the transfer log using the TransferLog none directive and delete /etc/logrotate.d/proftpd.conf if we neither want crashes nor overblown transfer log files.

eomanis commented on 2018-07-09 17:07

@migrev: Would it be possible to add --with-modules=(...):mod_facl, along with --enable-facl?

This would make ProFTPD aware of file/directory access granted by Access Control Lists (ACLs), see also the documentation of mod_facl.

I control user access with supplemental groups and ACLs.
For example, I have a directory for a specific event, /some-event, and I want only people that attended that event to be able to read or maybe write to that directory. Think photo sharing or something the like.

To that end I'd create two groups some-event_r and some-event_rw, set up that directory's ACL to allow read/read-write access for those groups, and just go ahead and slap the groups on the desired users as I see fit.
This is very convenient.

mod_facl is actually not required for this kind of access control to work.
What it is required for though are the "HideNoAccess" and "IgnoreHidden" directives, where ProFTPD hides files and directories from users that lack access rights for them, which is arguably a very cool feature.

migrev commented on 2017-04-18 12:53

@lod: Certainly! There you go. Cheers.

lod commented on 2017-04-18 12:30

can you add mod_sftp to --with-modules?

sl1pkn07 commented on 2017-01-16 13:45

.install not need anymore. now systemd-tmpfiles is handled by pacman hooks

greetings

alienvenom commented on 2015-08-05 21:08

Any way we can get this to compile/install the modules?