Continuing.
I’ve really grown to appreciate the way XigmaNAS does things. They could use some more devs.
But my question is this. What’s the CORE differences between an API middleware type OS and a PHP implementation like Xigma?
The API would be harder to maintain but offers more sales opportunities (like HexOS).
That’s my take. PHP makes it easier to fix bugs and such when you have a community driven project IMO.
Pegasus that’s where our efforts would be better suited. Especially with their extension options.
No, not necessarily easier to fix. You have a greater chance of ending up refactoring your code to address an issue. The PHP solution is easier to code with a smaller dev team. An API needs a system arch to plan out. Well, I suppose if you plan out what you want then you do an API.
Plugins (and scripts) need a user config file. So, if you take Dan’s scripts as an example (I only glanced at them) but they:
- are run from the host (which is probably the best)
- prompt for user input (this is what a user config file would fix)
I think a JSON style config would be good. Docker compose uses yaml which is garbage. …Actually, we should support a bunch of different styles. We can use tools like grep to parse the file. If we go C then we’d have some work to do and build an actual parser. Ideas a flooding
What is pegasus?
It took a few minutes but I googled my idea and I found a similar idea from someone else. I grabbed a nice little line of shell code that uses grep (like I was thinking) and I did a quick proof of concept. …the idea isnt bomb proof but it’s certianly better then what we currently have (using grep like this is not really a “true parser” but this will work for now). I need to spend some time and write down my idea and develop some skeleton code I can share.
Perhaps…typo
I assembled another quick test. I can now “parse” a config file in either STD config or JSON style format so I’m fairly confident in that bit of skeleton code to parse a config file for information.
-i.e.
username="john"
or
config {
username = "john"
}
I’ll need to figure out the structure of these scripts but for the moment the config question is sort of dealt with. I have a ton of things on my plate at the moment (full time job, kids, TN Replacement server, weekend-programming-things), so I really need to pause and build some documentation/notes so I don’t loose track of these concepts. And I really should log into my NAS and play around to verify what you can and cannot do (what core features of FreeBSD has been stripped away).
On the topic of TrueNAS CORE plugins.
I found the github repo for the iX Plugins and I took another look at Dan’s Nextcloud plugin (looks like you spent some time on that, Dan. Good work). My question is what is wrong with iX’s iocage plugin scheme?
raw.githubusercontent.com/freenas/iocage-ix-plugins/master/nextcloud.json
I mean, why write that whole script (like what Dan did) when you can just write out that JSON file?
Here is Dan’s script for reference (Sorry, not picking on you, just trying to understand why you choose to write the script instead of writing the JSON file):
raw.githubusercontent.com/danb35/freenas-iocage-nextcloud/master/nextcloud-jail.sh
Whoa?! There’s a template iocage plugin.
This is professionally done. Why not just use this? I have some usage questions (like “how is ‘post_install.sh’ copied in?”) but this good stuff.
iocage-ix-plugins/template at master · freenas/iocage-ix-plugins · GitHub
EDIT:
There is even documentation!
13. Plugins — FreeNAS®11.2-U3 User Guide Table of Contents (ixsystems.com)
Now, I’m thinking about ditching my BSDPot for this setup.
Looks like @Kris was the author of this template scheme.
Kris, If you have a moment; if I wanted to use your template system for iocage on FreeBSD what are the bottle necks you came across that I should be aware of?
From what little I’ve read, I’m not sure how mountings are done with the templates (it appears as though you use the jails fstab) is that correct, or did I miss something?
I also assume I can ditch some of the fields (I’m not quite sure I understand the ‘fingerprints’ section), especially if these templates are local.
I hope to find some time to set up a test and play around a bit (maybe, I’d have a few questions then) but these were just ones that came to mind when looking at the docs.
Thank you.
Reading up on docker, and docker is essentially like a jail manager. It has the Dockerfile (similar to templates and bastillefile) that can be used in containers.
And a docker image looks very similar to creating jail templates (no difference really) and having users just pull the templates.
That’s the theory. Jails on FreeBSD have a longer (much longer) development life cycle so all the bugs have been worked out (security, etc.) but in a sense they are the same as “jails” on Linux with Docker. However, I do not think docker (and the like), on Linux, can do all the different types of jails (thin, thick, and service). I’ve never run docker on freebsd so…grain of salt (this is just gibberish).
Also (warning) Dockerfile uses YAML, which is sort of a pain…but so can JSON and XML.
There is also a OCI kind of thing (open container initiative) and people are doing some cool things with that. For example:
runj: a new OCI Runtime for FreeBSD Jails (karp.dev)
These movements are sometimes cool to watch.