libcrypt.so.1 is missing on Fedora 41

[EricB1978]

Bug reporting acknowledgment

Yes, I read it

Professional support

None

Describe the bug

Hello, Fedora 41 has done some cleanup and now only provides libcrypt.so.2

ldconfig -p | grep libcrypt
libcryptsetup.so.12 (libc6,x86-64) => /lib64/libcryptsetup.so.12
libcrypto.so.3 (libc6,x86-64) => /lib64/libcrypto.so.3
libcrypt.so.2 (libc6,x86-64) => /lib64/libcrypt.so.2

Do you plan to update glpi-agent to version libcrypt.so.2 ?
I'm using glpi-agent-1.12-x86_64.AppImage with the script glpi-agent-portable.sh on Fedora 41, and I absolutely cannot install libxcrypt-compat on the system.

To reproduce

create portable edition of Agent.

go in the agent-portable directory :

sudo ./glpi-agent --full --scan-homedirs --scan-profiles --local= /home/user/Desktop/ScanHost.xml

/tmp/.mount_glpi-aMJ59Rj/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory

Expected behavior

create portable edition of Agent.

go in the agent-portable directory :

sudo ./glpi-agent --full --scan-homedirs --scan-profiles --local= /home/user/Desktop/ScanHost.xml

[info] target local0: local /home/user/Desktop/ScanHost.xml
[info] running task RemoteInventory
[info] running task Inventory
[info] New inventory from localhost-2025-02-02-23-33-22 for local0
[info] Inventory saved in /home/user/Desktop/ScanHost.xml

Operating system

Linux

GLPI Agent version

v1.12

GLPI version

10.0.x (See additional context below)

GLPIInventory plugin or other plugin version

No response

Additional context

No response

[g-bougard]

Hello @EricB1978

Do you plan to update glpi-agent to version libcrypt.so.2 ?

No, as this is not really the good question. The question would better be: Can you fix AppImage packaging so it would work on Fedora 41 ?

Indeed, the problem is not glpi-agent, but the packaging. Here AppImage is intended to work on most linux platforms, but I know this is not always the case. This packaging format is always evolving and maybe Fedora Devs made a decision for Fedora 41 which makes our AppImage packaging unreadable there.
I'll try anyway to figure out why this doesn't work for you on Fedora 41.

Fortunately, as Fedora 41 is a recent system, you should better use standard rpm packaging we also provides. The best is probably the linux perl installer which is handy for installation and configuration at the same time as it embed all the rpm packages.

Can I ask you to try the AppImage manual installation process ?
I would like to know if even this installation way is broken. And maybe this can give some clues to work on a fix or work-around.

[EricB1978]

Hello @EricB1978

Do you plan to update glpi-agent to version libcrypt.so.2 ?

No, as this is not really the good question. The question would better be: Can you fix AppImage packaging so it would work on Fedora 41 ?

Indeed, the problem is not glpi-agent, but the packaging. Here AppImage is intended to work on most linux platforms, but I know this is not always the case. This packaging format is always evolving and maybe Fedora Devs made a decision for Fedora 41 which makes our AppImage packaging unreadable there. I'll try anyway to figure out why this doesn't work for you on Fedora 41.

Fortunately, as Fedora 41 is a recent system, you should better use standard rpm packaging we also provides. The best is probably the linux perl installer which is handy for installation and configuration at the same time as it embed all the rpm packages.

Can I ask you to try the AppImage manual installation process ? I would like to know if even this installation way is broken. And maybe this can give some clues to work on a fix or work-around.

user@localhost:/media/sf_Shared/glpi-AppImage$ ./glpi-agent-1.12-x86_64.AppImage --install
/tmp/.mount_glpi-aq2hYpr/usr/bin/perl: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
user@localhost:/media/sf_Shared/glpi-AppImage$

[g-bougard]

You probably didn't read the link I provided as you're using a command with the wrong argument for the explained manual installation.