Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Documentation update for SSL / Certbot support for Mango V4.5?
-
Greetings, all:
I'm trying to get my SSL certs setup according to the Mango V4 Help:
https://docs-v4.radixiot.com/sslAnd, well, that document doesn't seem quite right to me- It looks like it hasn't been updated entirely from Mango 3.7 (or an earlier version of Mango 4).
Notably:
"nano /opt/mango/mango.properties" is not where that files is anymore (it's in /opt/mango-data/mango.properties)ssl.keystore.location=/opt/mango-data/keystore.jks is no longer jks, it's now p12
/opt/mango/bin/mango-start.sh > /dev/null 2>&1 no longer works if you use 4.5 installed as a service- You need to now use "mango service stop/start"
There's many more- Can someone update this documentation? I'm having a mess of a time getting this to come up right- It feels like Mango's CERTBOT deploy script is still updating the .p12 file in /opt/mango, and then mango is starting looking for the .p12 in /opt/mango-data/, so the cert-bot updated cert never gets into the new java keystore.
Presumably, someone else already has this figured out- Can someone point me to what I'm missing?
-
Okay: I've figured something out here-
It seems (to me) like the files in /opt/mango/bin (that you use to set up certbot/ etc) don't seem to be aware of the /opt/mango-data/ files, and don't appear to be updated based on the settings in theThis just cost me a huge number of hours:
The instructions for getting the certbot set up (here)
https://docs-v4.radixiot.com/ssltalks about running "/opt/mango/bin/genkey.sh"
but Genkey doesn't seem to know where the (new) mango.properties default file is (in /opt/mango-data/ by default install from the install script).
This seems to be present in all the SSL config scripts in /opt/mango/bin- They don't seem to know what is in /opt/mango-data/mango.service (which calls out Environment="mango_config=/opt/mango-data/mango.properties")
This means if you do anything manually (like installing CertBot), it seems that the shell scripts all seem to default to /opt/mango , and put the key files there instead of in /opt/mango-data/. When you run a manual key creation ("/opt/mango/bin/genkey.sh") it doesn't appear to know what you put in for the password / etc in mango.properties.
To get us back online, I was able to get the scripts to work by just doing:
export MA_ENV_PROPERTIES=/opt/mango-data/mango.properties
then running the genkey.sh, and the files were in the right place.Without exporting the variable, the genkey.sh (and the certbot deploy) uses Something Else (not /opt/mango-data/mango.properties, which the Mango V4.5 install script creates).
I think the scripts may need some tweaking to work with the new Mango file pathnames.
I (still) don't have my certbot working, since when it runs, it puts the keystore file in /opt/mango, and not in /opt/mango-data/, which is where the service start/stop script wants to find it. I used up all my certs (you have a limit of 5 per few day time period to renew), so I'll try this again once I get this done.
I'm running this on Ubuntu 22.04 LTS, using BASH as my shell, and I'm running these scripts as superuser.
This is relevant, as I think the certbot scripting inside Mango uses the "renew" functions in /etc/letsencrypt-
and each site has a conf file that includes the renew_hook, so it's going to expect to be able to run that certbot-deploysh script. How can I make sure make the certbot stuff works now that that config file is moved to /opt/mango-data?
Or has this been addressed already?
This may be as simple as hook="EXPORT MANGO_CONFIG=/opt/mango-data/mango.properties /opt/mango/bin/certbot-deploy.sh.. But I don't know. The Mango V4.5 documentation for setting up CERTBOT seems to have very little to do with how this actually needs to be done.
Cheers,
-Greg -
@Turbo this exact reason is why I used nginx and applied the lets encrypt to that instead...
Fox
-
@MattFox I agree- If that's the standard way of doing this, there should be a nice writeup on the Manual / Docs for setting that up- I realize that's an Option, but I'm trying to keep our systems installed "per the documentation", to keep things consistent going forward- I tried the nginx approach on 3.7, and found that it didn't work well due to issues with headers and such. I've seen your posts here on this topic, but is there a nice writeup somewhere that goes step by step to get this going?
-
@Turbo I wrote this not long ago...
https://forum.mango-os.com/topic/5616/use-nginx-with-mango-as-an-ssl-reverse-proxy/1 although I should likely add the ssl bit to it!Fox
-
It looks to me the source of all your problems is that you don't have mango_paths_data and mango_paths_home set as environment variables. The scripts are very tightly dependent on those variables. The install script does not set those.
and each site has a conf file that includes the renew_hook, so it's going to expect to be able to run that certbot-deploysh script. How can I make sure make the certbot stuff works now that that config file is moved to /opt/mango-data
When you do the first request for a cert you provide the path of the renew_hook, Which is the certbot deploy script. Certbot executes this script straight after a successful renew. This script does 2 things, its creates a P12 from the bundle the letsencrypt provided. it moves the bundle to "ssl.keystore.location" defined in the mango.properties. if "ssl.keystore.location" is absolute(starting with a "/") it will place it in that location. if it is relative(not starting with a "/") it will put it in $mango_paths_data/ssl.keystore.location
if you are saying that it is landing in /opt/mango/ssl.keystore.location I suspect that you are using a relative path and that $mango_paths_data is not set and it is defaulting to mango directory
-
@CraigWeb That's correct. My confusion comes from the fact that this is a bog standard new install on raw fresh new hardware: I followed the steps in the install guide ("https://docs-v4.radixiot.com/install-script"), using the script provided, and am sort of surprised that the install script (which clearly needs to know these paths to install) didn't check or define those variables, which seems like maybe something it should do.
Also, in (https://docs-v4.radixiot.com/installation-overview), step 4, it says "Set the mango_paths_home environment variable to the where you installed Mango (recommended but not required)."- This does not mention the other variable, "mango_paths_data", and seems to be an outdated reference to the new requirement for both paths to be defined.
However, it also sounds like we have an Easy Solution:
Just set the environment variable for the path for mango_paths_home (which I assume defaults to /opt/mango) and mango_paths_data (which I assume defaults to /opt/mango-data).So, I guess:
(1) Why does the script not set those variables, if they are sort of key to everything else, when doing a Fresh install of Mango according to the documentation?
(2) Where does it say in the manual that I need to set those environment variables manually?
(3) What are the "standard" values for default mango installs for those paths above?I appreciate your help, and all I have to do is set some environment variables as mentioned above- But the fact those variables weren't set by the factory install script, and the install guide doesn't mentioned them, either, seems like something that maybe can be fixed- The manual talks all about the JAVA_HOME environment variable, and setting that, which makes a ton of sense, but no mentioned of the (2) env variables that need to be set for the scripting to work.
The install script, btw, is very nice- It sets all kinds of other things, but why not the mango paths for new install?
Cheers,
-Greg -
@Turbo
ok, the scripts of fairly long but I've tried to see what's going on. The install script creates a user and sets its home to /opt/mango-data. it always adds path.data=/opt/mango-data to the mango.properties file. These scripts work entirely as expected if executed as the mango user because they can fall back on the $HOME directory and find the mango. properties.When you execute them as another user they cannot find the mango.properties file to search for the path.data properties so the fall back on /opt/mango (this is sourced from the directory they are executed in)
So the environmental variables are required when other users execute the scripts which would be the case with certbot executing the cert-deploy script.
The paths are mentioned in the help doc altho it is not quite clear that the scripts will fail without them... I actually had some frustration myself with the scripts about 2 months ago and got them modified to echo more information so you can know what's going on but that will only be in the next release.
I will also open a ticket for the help docs to include the importance of the environmental variables. Ie without them only the mango user can execute them succesfully.
-
@CraigWeb Heya Craig. Thanks for that! That's exactly what I was thinking. It's absolutely great now that Mango runs under its own user, but that user can't be logged into (at least, at least not without a fair amount of headache). Once CertBot is deployed, Mango will (likely) have no trouble updating them, but on the first run, almost everyone using those scripts will be logging in or SUDOing into root or whatever to make that happen.
The easiest solution (I think) is to juts do something like:
export mango_paths_data=/opt/mango-data
export mango_paths_home=/opt/mangoOr something when you sudo in to do these scripts. or you have to enable the mango user account to be loggable-innable, but that's the whole point (I think) of creating a mango-user in the first place, to not have it be a login account.. Which is sound design practice.
I'm probably going to try that over the weekend again- Thanks so much for looking through those scripts. When I first was trying this, I thought I was out of my mind, but it turns out there's both an easy solution (at least temporarily) to make this work, and no problem when the certbot hook runs (since it's already running as the mango user).
This problem only popped up because the new mango install script does everything under a user it creates, and the interactive config stuff happens because users are logging in and modifying another users's (mangos) settings. It all makes pretty solid sense, but only once you sit down and think through it.
Who knew environment variables would continue to be such a headache?
