npm-uname knowingly fails on OSX, and Archlinux. I’m looking to replace/remove the uname dependency altogether, because it feels unclean to keep up with an npm package that is decidedly no longer supported.
Unfortunately, as the author of node-uname also states, some fields from uname cannot be retrieved any way other than from uname, so it also means that I’ll lose some nice extra data points. Well, I’ll live.
There is currently no config file. I suppose I just forgot about it!
Thanks for following up with it; I’ll start looking at it today; not altogether too amped up for parsing and error-handling config files, but it’ll pay off in the end.
Let me know if there’s any other aspects you see getting in the way of plugin-izing this; as with the Python version, having easy installation on FreeNAS has greatly improved adoption!
one thing that I would recommend for freenas/freebsd is not relying on bash for the generate-sslcert.sh
maybe at some point you or I could look at the script at make sure it runs on a POSIX compliant shell. freebsd doesn’t ship with bash by default, and I’d prefer not to add the dependency if not needed.
I saw you added the config file to mineos-node.
are you still planning on adding the base_directory or will this always be hardcoded as /var/games/minecraft?
when you’re done I can finish up packaging the freenas plugin.
Thanks!
Thanks for reminding me! Yeah, I’ve been trying to diligently scour all the posts and github issues for things I’ve left until way too late, and I definitely intend to do base_directory–I see no reason why it shouldn’t be much easier now that the config is actually up and running.
The config parsing was way easier to implement, after all. My main concern was that so many current installs don’t have it, and I didn’t want it to fail when they just git pulled but didn’t copy over mineos.conf, but being able to operate without it, and just overwrite it with the conf (if present) worked nicely (and without code smell).
Off tangent…alright, yes, I do intend to work on the base_directory.
that was quick! I’ll work on getting something built this weekend.
actually in the freenas plugin’s case most things are installed to /usr/pbi/mineos-amd64 since it’s a PBI installer. any chance you could make the config file an argument of the node startup command? if it’s a hassle, I can just write the config to /usr/local/etc
Actually I am really unsure that mineos.conf will often be provided as an argument to the webui–with the exception of this freenas plugin. So I think that maybe I can just add a third path to check and that would satisfy it?
What do you think would be the full path mineos.conf would exist at within the environment of the FreeNAS plugin?
var mineos_config = read_ini('/etc/mineos.conf') || read_ini('/usr/local/etc/mineos.conf') || {};
It would be /usr/pbi/mineos-amd64/etc/mineos.conf
But that would change depending on architecture, and PBI name. you van just leave it as is and I’ll link it to /usr/local/etc
One downside, is I don’t know a simple way to get the error checking that “bash -e” offers with sh. But I’m not sure how necessary this is for this script anyway as all the commands seem pretty atomic.