Hi,

on CentOS 6 I don't have this problem with psa-proftpd-1.3.4a-1.el6.art.x86_64, but on 5 I can't load modules.

uname -rmv
2.6.18-028stab079.1 #1 SMP Sat Nov 27 00:29:50 MSK 2010 x86_64

psa-proftpd-1.3.4a-1.el5.art

/usr/sbin/proftpd -l| sort
Compiled-in modules:
mod_auth.c
mod_auth_file.c
mod_auth_pam.c
mod_auth_unix.c
mod_cap.c
mod_core.c
mod_delay.c
mod_facts.c
mod_ident.c
mod_lang.c
mod_log.c
mod_ls.c
mod_quotatab.c
mod_quotatab_file.c
mod_ratio.c
mod_readme.c
mod_site.c
mod_tls.c
mod_xfer.c

/usr/sbin/proftpd -V
Compile-time Settings:
Version: 1.3.3e (maint)
Platform: LINUX [Linux 2.6.18-028stab079.1 x86_64]
Built: Tue Nov 22 2011 13:49:51 NOVT
Built With:
configure '--with-modules=mod_ratio:mod_readme:mod_quotatab:mod_quotatab_file:mod_tls' '--enable-nls' '--enable-auth-pam' '--enable-ncurses' '--enable-ipv6' '--enable-buffer-size=8192' '--prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--libexecdir=/usr/lib64' '--datadir=/usr/share' '--sysconfdir=/etc' '--sharedstatedir=/usr/com' '--localstatedir=/var/run/proftpd' '--libdir=/usr/lib64' '--includedir=/usr/include' '--infodir=/usr/share/info' '--mandir=/usr/share/man' '--build=x86_64-redhat-linux' '--host=x86_64-redhat-linux' 'build_alias=x86_64-redhat-linux' 'host_alias=x86_64-redhat-linux' 'CC=gcc' 'CFLAGS=-O2 -g -m64 -mtune=generic' 'LDFLAGS=' 'CPPFLAGS=-O2 -g -m64 -mtune=generic'

CFLAGS: -O2 -g -m64 -mtune=generic -Wall
LDFLAGS: -L$(top_srcdir)/lib
LIBS: -lssl -lcrypto -L$(top_srcdir)/lib/libcap -lcap -lssl -lcrypto -lpam -lsupp -lcrypt -ldl -ldl

Files:
Configuration File:
/etc/proftpd.conf
Pid File:
/var/run/proftpd/proftpd.pid
Scoreboard File:
/var/run/proftpd/proftpd.scoreboard

Features:
- Autoshadow support
- Controls support
+ curses support
- Developer support
- DSO support
+ IPv6 support
+ Largefile support
- Lastlog support
+ ncursesw support
+ NLS support
+ OpenSSL support
- POSIX ACL support
+ Shadow file support
+ Sendfile support
+ Trace support

Tunable Options:
PR_TUNABLE_BUFFER_SIZE = 8192
PR_TUNABLE_DEFAULT_RCVBUFSZ = 8192
PR_TUNABLE_DEFAULT_SNDBUFSZ = 8192
PR_TUNABLE_GLOBBING_MAX_MATCHES = 100000
PR_TUNABLE_GLOBBING_MAX_RECURSION = 8
PR_TUNABLE_HASH_TABLE_SIZE = 40
PR_TUNABLE_NEW_POOL_SIZE = 512
PR_TUNABLE_SCOREBOARD_BUFFER_SIZE = 80
PR_TUNABLE_SCOREBOARD_SCRUB_TIMER = 30
PR_TUNABLE_SELECT_TIMEOUT = 30
PR_TUNABLE_TIMEOUTIDENT = 10
PR_TUNABLE_TIMEOUTIDLE = 600
PR_TUNABLE_TIMEOUTLINGER = 30
PR_TUNABLE_TIMEOUTLOGIN = 300
PR_TUNABLE_TIMEOUTNOXFER = 300
PR_TUNABLE_TIMEOUTSTALLED = 3600
PR_TUNABLE_XFER_SCOREBOARD_UPDATES = 10

No answers yet. Is this package actively maintained? Any idea why DSO support is missing?

It definitely is using DSO's now, the clamav module for example is one. I'm not sure what you're running into yet but if you want to take a look at the src.rpm its here:

www4.atomicorp.com/channels/source/psa-proftpd/

Scott,

I looked in the spec file and looks alright. However, on my CentOS 5 installation running psa-proftpd-1.3.4a-1.el5.art and psa-proftpd-mod_sftp-1.3.4a-1.el5.art I get this:

/usr/sbin/proftpd -vv
- Fatal: unknown configuration directive 'LoadModule' on line 2 of '/etc/proftpd-sftp.conf'

It looks like, for some reason, my installation is missing dso support, after looking at my initial post also. Suggestions?

L.E. I found the source of the problem. On all my Plesk 10.4 servers running on CentOS 5 I have psa-proftpd-1.3.4a-1.el5.art installed. All the installed binaries are identical with what's in psa-proftpd-1.3.4a-1.el5.art.x86_64.rpm rpm package, except for one and that's /usr/sbin/proftpd. Looks like, for whatever reason, Parallels overwrites this binary with one that's missing dso support. Once I reinstalled psa-proftpd package the problem went away. Sorry for the noise.

You know it just clicked with me on that too. I think I had started working on a self healing module for that, I know older ASL installs can already do this because they did not use ifmodule directives around the the Clamav DSO. It detects that and runs a yum reinstall psa-proftpd event. That ifmodule code was removed I think in .19 to bring turn that bug into a feature

I think all you'd need to do to get this in place on your sytem is to remove /etc/proftp-asl.conf and run asl -s -f

Ah. This makes sense now. Breun flagged this up a while ago. I didn't know the guys had added some code to deal with it - great stuff Scott! I'll be sure to remove that config file and asl -s -f on all my systems, just in case.

The trigger is if /etc/proftp-asl.conf just says:
ClamAV on
ClamServer 127.0.0.1
ClamPort 3310

if it has the if_module (or whatever, I forget the syntax) around that, it wont trigger the error message which then triggers the self-healing rule. For a few versions of ASL, we had those stanzas in there (up to 3.0.19 I think) so new installations would have created the config that way.

This is one of those situations where doing it the wrong way is really the right way

scott, we're not using ASL (should we, perhaps? ), just stock CentOS. I described the Parallels stuff-up here: http://forum.parallels.com/showthread.php?t=257843 and they're working on fixing that botched binary.
OTOH, given Parallels record, file integrity checks are a must.

Without ASL.... You...Are....The.....Self-healing module!