Re: [Proftpd-user] migrating from proftp on RH7 to proftp on RH8
Tim McIntire <[email protected]> Fri, 21 Jan 2022 19:15:45 +0000
| Newsgroups | gmane.network.proftpd.user |
|---|---|
| Message-ID | <BMXPR01MB47415A631CF08B8AE49A6E32F65B9@BMXPR01MB4741.INDPRD01.PROD.OUTLOOK.COM> |
Thanks TJ. Am thinking about taking a different approach. The desired config is actually more important to replace ftp with sftp than getting it work on RH8. Was thinking about staying on RH7 as that seems to work ok for ftp with proftpd. When I upgrade proftpd on this server the epel for 7 only goes to 1.3.5e. Are there any prebuild rpms for newer versions or do I have to build it all from scratch? Does this approach make sense? Tim -----Original Message----- From: TJ Saunders [mailto:[email protected]] Sent: Thursday, January 20, 2022 6:13 PM To: ProFTPD Users <[email protected]> Subject: Re: [Proftpd-user] migrating from proftp on RH7 to proftp on RH8 > : dispatching CMD command 'PASS (hidden)' to mod_auth > : retrieved UID 10002 for user '[email protected]' > : no supplemental groups found for user '[email protected]' > : USER [email protected] (Login failed): No such user found > > Was curious about the no supplemental groups. This shouldn't be an issue. A Unix process has a UID (which maps to a textual user name, usually via /etc/passwd), a GID (which maps to a textual group name, usually via /etc/group), and then a list of additional/supplemental GIDs. It is not *required* that the process be a member of more than one group, of course. But it's sometimes handy, depending the permissions of the files that that process/user should (or should not) have access to. That said, my current suspicion is that this is a contributing factor: 2022-01-19 14:54:10,653 mod_sql/4.3[86691]: checking password using SQLAuthType 'Backend' 2022-01-19 14:54:10,653 mod_sql/4.3[86691]: entering mysql cmd_checkauth 2022-01-19 14:54:10,653 mod_sql/4.3[86691]: password mismatch 2022-01-19 14:54:10,653 mod_sql/4.3[86691]: exiting mysql cmd_checkauth 2022-01-19 14:54:10,653 mod_sql/4.3[86691]: 'Backend' SQLAuthType handler reports failure The "SQLAuthType Backend" feature only exists for MySQL -- and it relies on a MySQL-specific password implementation that only exists in the client library (vs in the database server). Later and later MySQL client libraries changed, then removed, that functionality altogether -- which can lead to issues with newer client libraries pointed at older databases, with the application expecting the "SQLAuthType Backend" support to work. I'm not sure if the MariaDB client libraries also have removed this functionality. For more details, see: http://bugs.proftpd.org/show_bug.cgi?id=4281 The above changes were done in ProFTPD 1.3.7rc1 -- but it sounds like your RH8 installation is used a ProFTPD version before then. Hmm. Still, it might be worth double-checking that "password mismatch", to see what might be different between the RH7 and RH8 MySQL client libraries. Hope this helps, TJ _______________________________________________ ProFTPD Users List <[email protected]> Unsubscribe problems? http://www.proftpd.org/list-unsub.html _______________________________________________ ProFTPD Users List <[email protected]> Unsubscribe problems? http://www.proftpd.org/list-unsub.html