Plugins_v2 development workflow

[GaroRobe]

Hi guys!

For the past year I more or less managed to create a basic usable environment on my FreeNAS by creating a set of useful (for me of course!) jails.
I even formed them into shell scripts for autodeployment in case of disaster recovery.
Next logical step is to pack them into a more portable and accessible form - which is a plugin.

New plugin system is nice. But, AFAIK, plugins repository is hard-wired to official one.
Which is not only rubs me the wrong way (where is my freedom of choice!!! :)), but also is not very nice from developers position.
I'd much prefer to make personal branch with my own new plugin, connect to it and then, after debugging and testing, offer it to official rep. But currently I just can't.

Or could it be that in reality I'm a bit slow, plugins rep switching can be done in an obvious and natural way and everyone here knows how to do it to the point that it's not to be even mentioned?:D

 

[Jurgen Segaert]

You can develop your own plugins and them install them in your FreeNAS system. If you want to share your work with the community, you can submit them to be included as a community plugin into the official iX repo, but you don't have to.

Here's some reading:
https://forums.freenas.org/index.php?resources/create-an-unofficial-iocage-plugin.99/
https://doc.freenas.org/11.2/plugins.html#create-a-plugin

There's also UI support coming to install your own plugins, but for now you have to use the command line as per the resource above.
https://redmine.ixsystems.com/issues/29058

 

[GaroRobe]

Thanks for the info! That's not what I imagined this functionality should be like (namely, set of custom repositories), but described feature is quite good for development, so will do... when will be implemented :)

 

[diskdiddler]

Thanks for the info! That's not what I imagined this functionality should be like (namely, set of custom repositories), but described feature is quite good for development, so will do... when will be implemented :)

I managed to create one with Jurgens help and I literally don't know how to code. It seems like a pretty good system, I think you'll like it.

 

[GaroRobe]

I managed to create one with Jurgens help and I literally don't know how to code. It seems like a pretty good system, I think you'll like it.

I managed as well and no longer have any pure jails - only plugins. And yes, the system overall is quite good - much more manageable than what I had before. Still much to improve though - like settings/ui. But as I see, those features are simply not ready.

 

[Zwck]

You can develop your own plugins and them install them in your FreeNAS system. If you want to share your work with the community, you can submit them to be included as a community plugin into the official iX repo, but you don't have to.

Here's some reading:
https://forums.freenas.org/index.php?resources/create-an-unofficial-iocage-plugin.99/
https://doc.freenas.org/11.2/plugins.html#create-a-plugin

There's also UI support coming to install your own plugins, but for now you have to use the command line as per the resource above.
https://redmine.ixsystems.com/issues/29058

I have a question to the resource?

you write sudo iocage fetch -P -n tetris.json ip4_addr="em0|192.168.0.220/24" doing a direct attachment to the em interface, which is nice.
Can you explain to me, as a noob, why i would use this instead of a vnet like configuration. most of the plugins create a vnet and bridge0 directly. what would be the recommended way?

https://iocage.readthedocs.io/en/latest/networking.html#vimage-vnet

 

[Jurgen Segaert]

I was going to refer you to the iocage documentation, but you linked to it yourself. :)
It states:

• The Shared IP networking option is rock solid, with over a decade of heavy use and testing. It has no specific system requirements, as everything needed is built directly into the default GENERIC kernel.
• VNET is considered experimental. Unexpected system crashes can occur.

Not all jails/plugins require a full network stack (VNET). Also, there are a few FreeNAS versions that had issues with iocage & VNET and needed some manual workarounds. I didn't wan't to cover all this in the resource nor open the door to a flood of distractions because "network in the jail isn't working", so for the example I chose to use "Shared IP".

"VNET" provides much better network isolation between your FreeNAS host and the jail, where "Shared IP" basically creates an IP address alias. You'll notice that the IP addresses of your running "Shared IP" jails will show on the console menu and that (by default) you may be able to access the FreeNAS web UI using the jail's IP as per this thread.

 

[Zwck]

I was going to refer you to the iocage documentation, but you linked to it yourself. :)
It states:

• The Shared IP networking option is rock solid, with over a decade of heavy use and testing. It has no specific system requirements, as everything needed is built directly into the default GENERIC kernel.
• VNET is considered experimental. Unexpected system crashes can occur.

Not all jails/plugins require a full network stack (VNET). Also, there are a few FreeNAS versions that had issues with iocage & VNET and needed some manual workarounds. I didn't wan't to cover all this in the resource nor open the door to a flood of distractions because "network in the jail isn't working", so for the example I chose to use "Shared IP".

"VNET" provides much better network isolation between your FreeNAS host and the jail, where "Shared IP" basically creates an IP address alias. You'll notice that the IP addresses of your running "Shared IP" jails will show on the console menu and that (by default) you may be able to access the FreeNAS web UI using the jail's IP as per this thread.

Well, the resource I linked and you quoted state this, however it was written during the alpha phase of iocage. So not sure how much that means now. Prior freenas version (<11.2) had problems because bridging was not properly implemented. All of which have been fixed with the close to stable beta 3 release.

So what network functions don't work on shared ip, (I only run into igmp multicast issues with shared ip)

 

[Jurgen Segaert]

The experimental status reflects on vnet/vimage itself, upstream in FreeBSD. I believe most of the issues with it have been solved.
https://wiki.freebsd.org/VIMAGE/TODO

Anything that relies on a MAC address (OSI layer 2 networking) will need VNET. It seems that plex is another example:
https://forums.freenas.org/index.ph...ying-problem-in-11-2-beta3.69960/#post-482947