Package Details: proftpd 1:1.3.6-5

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: 52
Popularity: 0.465713
First Submitted: 2013-05-16 15:03
Last Updated: 2019-01-21 15:50

Latest Comments

1 2 3 Next › Last »

holterdipolter commented on 2019-04-11 09:54

Maybe add support for armv7l and aarch64 CPUs. I had no issues compiling for both.

migrev commented on 2019-02-18 13:30

@mikefarmer01: Looks like it is working for me:

$ LANG=C wget ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.6.tar.gz --2019-02-18 14:29:57-- ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.6.tar.gz => 'proftpd-1.3.6.tar.gz.1' Resolving ftp.proftpd.org (ftp.proftpd.org)... 86.59.114.198 Connecting to ftp.proftpd.org (ftp.proftpd.org)|86.59.114.198|:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done. ==> PWD ... done. ==> TYPE I ... done. ==> CWD (1) /distrib/source ... done. ==> SIZE proftpd-1.3.6.tar.gz ... 20251898 ==> PASV ... done. ==> RETR proftpd-1.3.6.tar.gz ... done. Length: 20251898 (19M) (unauthoritative)

proftpd-1.3.6.tar.gz.1 100%[====================================================================================================================>] 19.31M 3.90MB/s in 10s

2019-02-18 14:30:08 (1.92 MB/s) - 'proftpd-1.3.6.tar.gz.1' saved [20251898]

mikefarmer01 commented on 2019-02-18 12:44

First source link (ftp://ftp.proftpd.org/distrib/source/proftpd-1.3.6.tar.gz) is down.

migrev commented on 2019-01-21 15:51

@eomanis: Done :)

eomanis commented on 2019-01-21 14:46

@migrev: Yeah, thanks a bunch for the quick package fix and even more for mod_facl AND backporting the patches. You rock!

Uh, while I have your attention, could you also add mod_dynmasq? :-)

It is just a matter of appending it to the --with-modules= list:

--with-modules=...:mod_dynmasq \

Turns out you need it if your IP address changes each day and people want to access your FTP server over IPv4.

Without it, the server tells the clients to open PASV connections to invalid IPv4 addresses. The symptom is that the IPv4 clients can connect all right, but then listing directories or downloading files always fails, because that is when the PASV connections start.

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.