Directadmin Services SSL

[nlaruelle]

Make sure your working shell do have /usr/local/bin directory in the PATH environment variable.

Hello and thank you @fln !

Hopefully, I found your message that save my day.

With a brand new server, with a fresh install of Almalinux 9 (from OVHCloud template) and fresh DirectAdmin, I've experimented the same issue :

"bash: lego: command not found".

Before, echo $PATH return this output :

/root/.local/bin:/root/bin:/sbin:/bin:/usr/sbin:/usr/bin

Then I did

export PATH=$PATH:/usr/local/bin

And try again:

lego --version

Which finally give me a result:

lego version 4.14.2-SNAPSHOT-cd63b325 linux/amd64

So this command success

/usr/local/directadmin/scripts/letsencrypt.sh server_cert

So I've

nano ~/.bashrc

And just paste this line

export PATH=$PATH:/usr/local/bin

at the very end of the file to make this change permanent.

Is there any chance to release a patch that check if :/usr/local/bin is in the PATH and add it if that's note the case?

Thanks!

 

[fln]

Glad this helped finding the problem and a workaround for it.

On standard Linux systems the directory /usr/local/bin should be included in the PATH by default. The fact that it is missing hints that system configuration is changed somewhere to NOT do it. The full chain of files which could impact the final value of PATH variable is quite long and depends on the system.

Changing PATH in .bashrc is more like a workaround for the problem in system by fixing it for a single user. But it does not fix the root of the problem (somewhere in global system config that affects all the users).

It is reasonable to believe you have not changed the system to exclude /usr/local/bin from PATH manually, so my guess is that creators of OVHCloud template messed it up (or maybe it was deliberate goal for some reason). We could detect and fix it in DA installer but not by adding a workaround in .bashrc but by detecting and reverting what is different in OVHCloud template compared to clean Almalinux 8 installation. Such fix would fix it not only for the root user but for all users on the system (they might want to execute commands from /usr/local/bin). To investigate it further we would need access to such system.

 

[nlaruelle]

it is more like a workaround

Thank you so much for your precious feedback @fln !

The information you took time to provide drives me to search for additional information about this case. I found a discussion where the user "jsbillings" mentioned that on RHEL, the missing "/usr/local/bin" in the PATH is a normal behavior for sudoers... :

https://unix.stackexchange.com/ques...local-bin-in-their-path#comment1111477_595525

And I was effectively in "sudo -s" when I tried to accomplish "lego" tasks.

What do you think about that?

It seems that my users outside of sudo have the "/usr/local/bin" in the PATH as well. I just need to conduct additional tests for my second server.

But of course, I can provide full access to my DA servers by tickets if needed.

Just let me know about my last feedback here, if you would like to check my 2 servers installed from OVHCloud templates (RockyLinux 8 > CL8; and Almalinux 9 soon converted early to CL9... we will take our chance to try CL9 with DA already as an early bird).

Thanks again for the time saved today!

 

[fln]

Good catch! I think you found the root of the problem. Indeed RHEL based systems wipe-out /usr/local/bin in /etc/sudoers file by having
Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin.

Seems like this is RHEL based systems trait, quick breakdown by disto:

• Debian 10 Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
• Debian 11 Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
• Debian 12 Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
• RHEL 7 Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
• RHEL 8 Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin
• RHEL 9 Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin

This is something that could be detected and adjusted at DA install time.

 

[mrshort]

Wauw, I had the same LEGO issue setting up a new server with Rocky Linux 9 coming from CentOS. Thought it was a job for the morning...hahah. So glad you clever people are around so I can "drive the machine". Your comments in this thread are much appreciated!!