This is more difficult than expected… Latest libxcrypt requires Perl 5.14.0, I could not make use of the 5.10.0 version we use on CentOS 5.11 to build OpenSSL. I guess we could build Perl as well, but it looks like overkill…

(Note that CentOS 6 comes with Perl 5.10.1, so we would need third-party packages to update to a newer Perl version on CentOS 6 too.)

Version 4.4.17 (from April 2020) was the latest version to build without Perl, but it requires Autoconf 2.64 (or higher). This would be present on CentOS 6 (version 2.69), but on CentOS 5 we only have version 2.13.

What do you think we should do?

1. Also include Perl 5 sources and build it for generic Linux packages. (Or use something like https://perlbrew.pl/.)
2. Start building generic Linux x64 packages on CentOS 6 with third-party Perl packages.
3. Just document that on some distros, such as Amazon Linux 2022, the libxcrypt-compat package is needed.

needs-review

Thanks for the update

Just document that on some distros, like Amazon Linux 2022, the libxcrypt-compat package is needed.

We can do that in chevah/server as a start

Maybe we can just have a separate SFTPPlus build with libxcrypt-compat include for Amazon Linux 2022

I guess that RHEL5 and RHEL6 also need libxcrypt-compat , but they already have it installed by default.

Start building generic Linux x64 packages on CentOS 6 with third-party Perl packages.

If it will also work on RHEL5, we can do it.

Also include Perl 5 sources and build it for generic Linux packages. (Or something like https://perlbrew.pl/.)

Nope to include the Perl 5 source. This repo is already too big.
Maybe perlbrew.pl

needs-changes

Thanks for the quick feedback!

[…]

Maybe we can just have a separate SFTPPlus build with libxcrypt-compat include for Amazon Linux 2022

You mean have a dedicated package for Amazon Linux 2022, like for RHEL 8?

I guess that RHEL5 and RHEL6 also need libxcrypt-compat , but they already have it installed by default.

It's part of glibc on older distributions.

Start building generic Linux x64 packages on CentOS 6 with third-party Perl packages.

If it will also work on RHEL5, we can do it.

No, it won't work. Linking to the glibc libs in CentOS 6 means RHEL 5 becomes completely unsupported.

You mean have a dedicated package for Amazon Linux 2022, like for RHEL 8?

yes. but I think for the start we should go with the docs to install the extra package for AMZ 2022.

Is strange that the code tries to load libcrypt.so.1 , not libxcrypt .

Can we just build the old libcript for Python ?

    from chevah.compat.unix_users import (
  File "/opt/sftpplus/lib/python2.7/site-packages/chevah/compat/unix_users.py", line 13, in <module>
    import crypt
ImportError: libcrypt.so.1: cannot open shared object file: No such file or directory

What I can do, is remove support for OS accounts from Amazon 2022.
So far all customers on Amazon are not using OS accounts.

I think that we should not bother with building libxcrypt

You mean have a dedicated package for Amazon Linux 2022, like for RHEL 8?

yes. but I think for the start we should go with the docs to install the extra package for AMZ 2022.

OK, I'll start with that then.

Is strange that the code tries to load libcrypt.so.1 , not libxcrypt .

Can we just build the old libcript for Python ?

Old libcrypt.so was part of glibc. This is gone from newer distros such as AMZN 2022.

Then there's libcrypt.so.1 which is from:

• libcrypt package on most distros of today, such as AMZN 2 (or Debian and its derivatives). This is built from glibc sources.
• libxcrypt-compat package on newest distros such as AMZN 2022 and current Arch. This is from https://github.com/besser82/libxcrypt, which split from glibc project some time ago, but it's now developed independently. This guide has an extensive explanation: https://fedoraproject.org/wiki/Changes/Replace_glibc_libcrypt_with_libxcrypt.

I guess we could search for the newest glibc which include libcrypt sources that would still build on CentOS 5, but… do we want that?

I would rather keep the status-quo as long as there's an easily-installable OS package that solves this issue.

What I can do, is remove support for OS accounts from Amazon 2022. So far all customers on Amazon are not using OS accounts.

I think that we should not bother with building libxcrypt

Why? It's perfectly functional as long as you install libxcrypt-compat…

OK. let's go with the docs.

Why? It's perfectly functional as long as you install libxcrypt-compat…

my plan was like this

• if you don't have libxcrypt-compat, sftpplus will not fail, but OS accounts are not available
• if you have libxcrypt-compat all is ok

my plan was like this

* if you don't have libxcrypt-compat, sftpplus will not fail, but OS accounts are not available

* if you have libxcrypt-compat all is ok

Ah, OK, that would be very graceful. Nothing against it…

Fine by me. Too much wizardry for such a small thing. You can always install libxcrypt-compat or equivalents on the latest distros.