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

Latest Comments

1 2 3 Next › Last »

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.

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.