I have a shell script that looks for new lets-encrypt certs pushed from my server that does LE for the rest of the network and copies from pem_filename.new to just the .pem filenames they need to be in /ssl.
If I run the script from the SSH add-on from a prompt manually, that works.
but I’ve tried adding the shell_command to both configuration.yaml and a shell_commands.yaml file in /config.
When you say “run in manually”, are you going into the Actions (or Service Calls) tab of Developer Tools? If so, when You click on “Perform Action” (or whatever it was in older updates), does the button turn green with a tick? And then you’re getting no Response result? Maybe look in the logs?
You shouldn’t have to call /bin/bash first, you should have that already in the first line of your script:
#!/bin/bash
But even that isn’t totally needed in most cases today, but it covers all your bases just in case. If you did that then your shell command could simply be:
Sorry for the delay - I thought I had notifications on.
Tried with and without the /bin/bash in the yaml line. I’ll try again without.
I tried to follow Shell Command - Home Assistant but it’s kind of a hot mess. The examples there list “bash” in the YAML config line. But looking around online, some people leave it out. I was trying everything.
I’m also used to writing shell scripts calling which shell I want with the 1st line of the script.
The script was originally set to rwxr–r–, I made it 755 just now (rwxr-x-r-x) and that didn’t fix things.
the script is owned by root/root
the files in /ssl/ are also owned by root/root
So the question is: Who runs this? when I look in /etc/passwd, I see several contenders.
root?
operator?
guest?
nobody?
The docs (last I looked) didn’t discuss anything about who was running the script to make sure file perms on the script were correct or SUID had to be set somehow.
I was running it from the automations page both under automations for the one I made running at a certain time.
but I also tried running it from the scripts page.
with your suggestion, I ran it from the developer->actions page and get a green check-mark. Nothing happens. (should anything I throw to stdout be shown as a response? because the script has some output - but I don’t see it in the response field)
That script should work indeed. Would write it differently but ahwel
the script is owned by root/root
the files in /ssl/ are also owned by root/root
With:
rwxr-x-r-x
So that should allow any user om the system to at least execute the script. Good start .
The answer is simple
Your system complains that it cannot write to the /ssl directory and with 755 that sure is the case. You would need to make it writable too. Ideally 775 But as you dont know the user and what group it belongs to you can do this:
#make directory 777
chmod -R 777 /ssl
# Add this to your script:
echo $(whoami) >> /ssl/user
# read the file and try to figure out what group that user belongs to:
cat /ssl/user | id
# You can now make the folder group owned:
chown -R root:GROUPNAMEHERE /ssl
# Reduce rights:
chmod -R 775 /ssl
the addons environment is basically totally different than the actual HA environment: both runs in 2 different docker container; that “/ssl” exists in the SSH addon doesn’t mean it exists in HA (and actually it doesn’t), and that a binary exists in an addon doesn’t mean it exists in HA
The only directory that is the same in both environment is “/config”
So it sounds like I should change my configuration.yaml to point to my certs in (say) /config/certs (or something) and then have my script operate out of there.
