Package Details: pure-ftpd 1.0.47-2

Git Clone URL: https://aur.archlinux.org/pure-ftpd.git (read-only)
Package Base: pure-ftpd
Description: A secure, production-quality and standard-conformant FTP server, focused on efficiency and ease of use.
Upstream URL: http://www.pureftpd.org/
Licenses: custom
Conflicts: pure-ftpd-db
Submitter: ilpianista
Maintainer: mrxx
Last Packager: mrxx
Votes: 43
Popularity: 0.000212
First Submitted: 2010-11-13 15:23
Last Updated: 2017-11-04 23:31

Latest Comments

mrxx commented on 2017-11-05 00:00

Upstream answered very quickly - they just fixed the bug in their development release.

I've updated the PKGBUILD, login of virtual users is working again.

mrxx commented on 2017-11-04 16:29

I can reproduce the crash when using virtual users, even with older versions of pure-ftpd.

I've filed a bug with upstream.

kitus commented on 2017-11-03 01:18

I've been working for couple of days in this problem, and i can't fix it, does anyone have the same problem... this problem happens only trying to work on "Virtual Users" , in the login process.


My Kernel:
Linux ktspc 4.13.9-1-ARCH #1 SMP PREEMPT Sun Oct 22 09:07:32 CEST 2017 x86_64 GNU/Linux

This is the journalctl result:

-------------------------------------------------------

nov 02 20:07:57 ktspc pure-ftpd[22608]: (?@127.0.0.1) [INFO] New connection from 127.0.0.1
nov 02 20:07:57 ktspc kernel: pure-ftpd[22608]: segfault at 0 ip 00007fe9f24fb7e8 sp 00007fff4c039c08 error 6 in libc-2.26.so[7fe9f245b000+1ae000]
nov 02 20:07:57 ktspc systemd[1]: Started Process Core Dump (PID 22610/UID 0).
nov 02 20:07:57 ktspc systemd-coredump[22611]: Resource limits disable core dumping for process 22608 (pure-ftpd).
nov 02 20:07:57 ktspc systemd-coredump[22611]: Process 22608 (pure-ftpd) of user 0 dumped core.

--------------------------------------------------------------------------

nov 02 10:50:00 ktspc systemd[1]: Started Process Core Dump (PID 17394/UID 0).
-- Subject: Unit systemd-coredump@7-17394-0.service has finished start-up
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
-- Unit systemd-coredump@7-17394-0.service has finished starting up.
--
-- The start-up result is RESULT.
nov 02 10:50:00 ktspc systemd-coredump[17395]: Resource limits disable core dumping for process 17392 (pure-ftpd).
nov 02 10:50:00 ktspc systemd-coredump[17395]: Process 17392 (pure-ftpd) of user 0 dumped core.
-- Subject: Process 17392 (pure-ftpd) dumped core
-- Defined-By: systemd
-- Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- Documentation: man:core(5)
--
-- Process 17392 (pure-ftpd) crashed and dumped core.
--
-- This usually indicates a programming error in the crashing program and
-- should be reported to its vendor as a bug.


Any idea ?

Tnks for ur comments xD

mrxx commented on 2015-11-23 16:38

spapanik21, thanks for your suggestion. I've changed the location for the pidfile.
The libsodium problem should disappear when you update/reinstall the pure-ftpd package.

kleph's info about broken clients is now mentioned at install time.

spapanik21 commented on 2015-11-20 16:46

I noticed that the default value for the PIDFile is /run/pure-ftpd/pure-ftpd.pid, both in pure-ftpd.service and pure-ftpd.conf. The problem with that is that /run/pure-ftpd does not survive the restart and the service cannot restart.

The solution I am using is to change the location in both this places, but this does not survive the updates.

Furthermore, the last update broke it for me as I was getting the error:
"error while loading shared libraries: libsodium.so.13: cannot open shared object file: No such file or directory" when I was using the pure-pw.

mrxx commented on 2015-10-08 02:55

Of course the FQDN of the host may not always be the desired one, especially if the server is in a DMZ, but exactly for cases like this a note how to re-create the certificate is displayed, as was suggested by you.

Unfortunately, there is not much documentation about the BrokenClientsCompatibility parameter, but the decision to set it to "no" by default in the latest release seems to be security related. Therefore, I think it's better to follow upstream and leave it untouched, as very few clients are affected.

In the next release I'll add a note about broken clients and how to enable the parameter in the config file.

kleph commented on 2015-10-08 01:14

Just for the reference, I had trouble with a few FTP clients since 1.0.42.
Andftp and Total Commander, to name them, but filezilla and lftp are OK.
The first connection was good, logs were OK, but clients did not see anything in the directory.
Total commander did not say anything, and andftp complained about "connection closed unexpectedly". It was for the data connection, that's why ls did not show a thing.
I found that enabling "BrokenClientsCompatibility" fixed the problem.
As you're already modifying some parts of the defaults, maybe also adding this could be useful.

Extract of the upstream's changelog for the version 1.0.42 :
- The ONLY_ACCEPT_REUSED_SSL_SESSIONS switch (introduced in Pure-FTPd
1.0.22 circa 2009, but disabled back then due to client compatibility
concerns) is now on by default, except in broken clients compatibility mode.

kleph commented on 2015-10-08 01:07

Thanks for the fast answer and fast integration :)

I do not face the FQDN problem, but that's may be due to the my config.
Pure's host is resolved as a FQDN for the local zone and I set the CN of my certificate (delivered by a local CA) to the FQDN of my external zone.
But as the forward and the reverse are resolved by a local DNS, I may miss the issue.

mrxx commented on 2015-10-07 02:20

Thanks kleph, I totally agree.
I've added an install script similar to your suggestions, but instead of only telling the user how to generate a self-signed certificate, it also generates one with matching CN=FQDN at install time if missing. (Otherwise the TLS-enabled ftp service would refuse to start.)

Updated to 1.0.42-2.

kleph commented on 2015-10-06 22:05

Hi,

The install conflicts if you already have certificates and DH params files.

Wouldn't it be better to check if certificates and DH params files already exists and generate new files rather that providing secret keys and always the same dh params with the package ?
That way the user can provide its own Common Name to match his FQDN.

I try it in my local variant built with --ldap
- removed the line "install -Dm640 -t ${pkgdir}/etc/ssl/private/ ${srcdir}/pure-ftpd.pem ${srcdir}/pure-ftpd-dhparams.pem" from the PKGBUILD

- and added a pure-ftpd.install :
post_install(){
if [ ! -e /etc/ssl/private/pure-ftpd-dhparams.pem ];then
echo "Generating new DH params"
openssl dhparam -out /etc/ssl/private/pure-ftpd-dhparams.pem 2048
chmod 0600 /etc/ssl/private/pure-ftpd.pem
fi

if [ ! -e /etc/ssl/private/pure-ftpd.pem ]; then
echo "You need to place a certificate and its key in /etc/ssl/private/pure-ftpd.pem to start TLS enabled pure-ftpd"
echo "You can generate a self signed certificate with the following command :"
echo "openssl req -x509 -nodes -newkey rsa:2048 -sha256 -keyout /etc/ssl/private/pure-ftpd.pem -out /etc/ssl/private/pure-ftpd.pem"
echo
echo "Note: The Common Name (CN) should be the same as the FQDN of the server."
echo "Note2: Remember to chmod 0600 the generated certificate."
fi
}

All comments