Apparently iX can’t make up their mind. It’s been /api/current through 24.10. Starting in 25.04, /websocket is the “official” URL, but /api/current still works (at least in -RC1). Presumably in some future release /api/current will cease to work. But I’d like to keep it at that path for as long as I can for the sake of backward compatibility.[1]
That will definitely cause authentication failures under 25.04.
Edit: The strikethrough has the paths reversed and is thus incorrect, except for the part about iX not being able to make up their minds.
I could grab the version number using the API, and adjust the endpoint accordingly, but that presents a chicken-and-the-egg problem. ↩︎
The truenas_ws.sh or truenas.sh hooks would not need to verify the cert because you’d have to assume acme.sh did that verification already; In other words, it (sh/w)ould not be truenas_ws.sh’s responsibility to verify. The only reason you would verify is in a script like yours which is I assume is totally independent from the acme script.
I don’t have an aversion to Python or your script or anything. That doesn’t make any sense. I have an aversion to unverified tools, dependencies, and chasing your tail around every other Tuesday, etc. in programming; and a perfect example is that shell script code you quoted (I suspect it was from truenas_ws.sh because I think you may think I wrote it or something). It has a dependency to jq. -i.e. Does it assert jq? Basically, assumptions in programming are bugs.
Monolithic programs or a massive/giant function with a series of intertwined function calls, is what programmers call spaghetti code. We don’t like programs like that. We’ve all made programs like that and we don’t like them (because we’ve all had to maintain them). …if you have ‘garbled code’, so what. Fix it. That operation can be a lot of fun. And that operation will help you build a library of code. Last month I goofed around with some of my code and I created 5 lean, memory safe libraries.
Sure, fine, okay, whatever you say, but I’m pretty sure I said before (but I don’t care if I did, really, now, anymore) I think you should make your script part of the acme tools–and I even offered my coding services. You obviously have a chip on your shoulder or something.
If I were you, I’d go read SICP or see if MIT still offers a free online class; it will teach you a lot (and the lisp language is huge fun). I think Stanford used to offer free programming courses too (I think I took a Swift course once).
Not the point. It doesn’t, mine does, and that’s the reason for the additional Python dependency of my script. This was not a criticism of truenas_ws.sh; it was simply an observation of a difference.
And I think this is the fundamental problem–you’re assuming things rather than taking even the slightest effort to ascertain the facts. A moment of reviewing the README, the link to which was in my first post in this thread, would have cleared this up for you. Your assumption is correct, but your lack of effort to confirm it is telling.
Your comments in the other thread,[1] where you repeatedly advised against using Python despite one script being completed, and another mostly so, in that language, paint a different picture.
It was indeed. I didn’t suggest, and don’t believe, that you wrote it, but if you’d compared the code enough to form the opinion that the one was better, I’d expect you to have recognized it.
That was your claim, not mine. I’ll happily consider PRs, and willingly look into any specific issues you (or anyone else) note. As far as I can tell–and I’ll freely admit I’m no expert in Python–the code is pretty straightforward. Error handling could no doubt still be improved. As for other issues, as I said, I’m open to suggestions.
No, but it’s kind of frustrating when you drop into a thread to post something that isn’t really relevant to it, as you did here. The truenas_ws.sh script just isn’t relevant to OP’s question:
It can’t be used on a different system than the NAS to deploy a cert to the NAS (the truenas.sh script can, but the truenas_ws.sh script can’t), which is how OP is currently handling the cert (though deploying it manually), and
There’s simply no need for it if you’re getting a cert through the NAS interface (which is what OP asked about).
…and when you double and triple down on your incorrect claim that the link you give documents how to use truenas_ws.sh, well…
@dan, I have two NAS machines that I need to load the certs to. I created two separate deploy_config files, and use the -c option to select the one I wish to update. I thought since the config file is an INI file, why not have a single config file that instead of having a [deploy] section, the sections could be by hostnames ie, [host1], [host2], etc … Then on the command line you specify the hostname to match a section to get the parameters needed. Just a thought. I’ll play with that here and maybe send you a PR.
…and an interesting one at that. I hadn’t really considered that use case, but I can see how it’d be useful. Another possibility would be to have the script automatically deploy to all the hostnames identified in the config file. I’ll look forward to seeing what you come up with.
@dan, here is the script with my changes. Your -c config_file option still works but, the command line now requires a name, ie host, that is referenced in the INI config file. I changed .py to .txt so I could upload it here. You can define multiple hosts in the config file and this is how I’ll use it.
I didn’t add in an all hosts option, I’ll look into that later.
Looking over the code and the sample config, though, the blocks are really just labels, right? They don’t have any necessary relationship with the system’s hostname or FQDN; they can be any arbitrary (and unique) string. Right? There’s obviously a certain logic in having the label equal the hostname.
I think I’d want to come with a way to have it default to [deploy] for the sake of backward compatibility.
@dan, I didn’t think of that. Just remove the positional command line parameter and add a “-h host” option where “host” would match a label in the config file. If the option isn’t used, it defaults to “label”.
@dan I modified the script again so that the default behavior uses “deploy” in the config file. Here is the Usage:
usage: deploy_truenas.py [-h] [-c CONFIG] [label]
Import and activate a SSL/TLS certificate into TrueNAS.
positional arguments:
label Use the specified config section, default is "deploy"
options:
-h, --help show this help message and exit
-c CONFIG, --config CONFIG
Path to config file, defaults to deploy_config.
I’ve pushed this change into a new multihost branch of the repo and will merge it shortly. I’ve reverted the change to the API path though; I’ll be including logic to determine which path to use based on the TrueNAS version.
@dan, I have a question. I don’t see the API call “certificate.create” documented in the API docs. What do you know about it? Is that an RPC call or is it an http post endpoint?
