TrueNas Core - plugin

[spz2k9]

Hi,

I made tonight a plugin that automate the scripts download and jellyfin pkg install. It's not available in the community plugins, but I can give the file and command to test it out.

It's not perfect, but for now it setups a jail with dhcp, throw a link for the portal in the menu and add a documentation link to this github.

Like this :

It still lacks a updater and the jail is actually hardcoded for jellyfinserver-10.8.9.pkg.... might be possible to automate the package version upgrade without updating the json file.

[spz2k9]

If you want to try it out download this file and unzip it on the TrueNas Core server : DELETED Use the newer file at the bottom.

*had to zip the file... GitHub doesn't allow json file in comment.

The open a ssh shell and run this command... with the wanted #jailname# and the #pathjson# pointing to the file on your Dataset :

iocage fetch -P #pathjson# --name #jailname#

example : iocage fetch -P /mnt/Storage/jellyfin.json --name jftest

[Thefrank]

You can make a PR here: https://github.com/ix-plugin-hub/iocage-plugin-index for community plugins

[spz2k9]

Will do eventually... but it's still in beta so once my install / update script is working i'll check to add it to the community list. I'll just leave this thread open while it's in testing phase.

[Thefrank]

If you are taking feedback:

---

Looks like a good start!

You can make a test repo and have iocage use that. iocage defaults to https://raw.githubusercontent.com/freenas/iocage-ix-plugins/master/INDEX when activating it and pulling down a plugin list but you can still manually use:

when fetching the plugin you can use iocage fetch --git_repository URL (NOTE: in the past this overwrote the default repo!) when setting up the repo to use iocage set plugin_repository='https://github.com/GHUser/nameofrepo.git' NAMEOFJAIL

As for its layout:

branch names should follow FreeBSD naming (e.g., 13.2-RELEASE, 14.0-CURRENT) so when you do go to update/upgrade the jail iocage will look for the correct branch. patch level is not used.

the SOMETHING.json file should have an exhaustive list of all packages, and, most importantly, their dependencies; this will be apparent later. Properties set using iocage set can be used here. Devfs can be established here too; even manually adding rules. It can, and likely should, use existing rulesets instead of having the user make them on their own.

optionally: pre-install.sh

• rarely used as the json file can set even obscure iocage settings

post-install.sh

• where the main package can be installed
  • pkg add PATHORURL/TO/PKG as pkg install PKG never worked for me,
  • any other setup is done (e.g., sysrc),
  • initial bring-up (e.g., service NAME start)

ui.json (TrueNAS only).

• ip and port of a UI for the jail (e.g., a web admin portal)

---

If not: The "readthedocs" for iocage is very limited and has broken links. You will get much better information from iocage COMMAND --help

[spz2k9]

Yes I am taking feedback. I've made the json file available for others to test... but I need to update it since it lacks python and it is required for the post_install.sh.

Well I didn't know TrueNas had the possibility to change the plugin_repository... I did all my test with a local json file pointing to a git repo like in the iocage readme... but their documentation is patchy at best.

I used the 13.1-RELEASE as it's the most recent TrueNas team is allowing us.

I finally made a /usr/local/bin/jellyfin_updater... it's a python script. It's job is to check if jellyfin is installed (with a marker file) then install it if it is not installed... if it is installed it check for update and only update if the version mismatch.

The jellyfin.json file only include theses 3 packages : libva / intel-media / python... the reason is... it's easyer to install those packages without the need of pkg.

I didn't use the pre-install.sh... but I did use a post-install for :

• calling /usr/local/bin/jellyfin_updater (to install the base package)
• do a groupmod to add jellyfinserver user to video (in case of hardware encoding)
• do the sysrc commands to enable service startup and start the service

I also added in the overlay The files lffmpeg and lffmpeg_advanced (the new one in the pullrequest for hardware decoding).

I thought adding a crontab like every two weeks do a call to /usr/local/bin/jellyfin_updater... but I thought maybe people would prefer to update manually since it's so new.

Oh ui.json works also... for the web admin and the documentation.

The plugin installation works without any problem... there's one thing I just thout that is essential that I notify you about... my updater script search for a .pkg file in the latest release. If there would be either no .pkg or more than one .pkg the download would probably fail... and the method I use would need to be updated.

I decided to make the pull request this afternoon since the updater works you can check it out here : pull request

Their automated process has been able to install and plugins without problem, it's waiting for approuval.

[spz2k9]

The new json file compatible with the updated plugin github : jellyfin.zip

[Thefrank]

Downloaded just the json file from zip: iocage fetch -P jellyfin.json

---

Issues, one breaking, others can be ignored:

• for iocage jails it should either be dashed ("jail-name-here") or just one word ("jailnamehere"). I am partial to the later as the ports system does not allow dashes in names. iocage can't use a jail with a space and will give nonsensical errors if you try as it does not sanity check json files.
• nitpick: might want to mention that hw support is only for gen8+ intel graphics
• nitpick: it leaves the plugin name as "jellyfi" and I have no clue why (plugin_name:jellyfi)
• nitpick: the pkg python is meta port and should not be used for direct dependencies. HOWEVER, it is typically fine to do so and even nicely makes symlinks for things like /bin/python so users don't have to fix shebangs in scripts full of linux-isms.
• nitpick hardcoded device /dev/dri/renderD128. If gen8+ intel always produces that under FreeBSD then its fine.
• nitpick: some formatting between displaying the pkg install output and the rest of the script: (maybe a new line?)
• future nitpick: branch names to match FreeBSD releases.
  • note to self: actually build jellyfinserver for more than one FreeBSD release

---

Something to consider: If allowed by ix-systems, you might want to make two script plugins. One that just handles jellyfinserver on its own and another for a jellyfin install supporting hwaccel. I have found people like their plugins to be "brain off" for setup/install (The devfs setup can be handled inside the json script)

---

list of packages on the plugin jail: pkginfo.txt everything works for me, but I don't have anything that can do hwaccel

---

safe to ignore rant: I would prefer scripts to be shell (/bin/sh) scripts as they don't require additional dependencies, but they are also harder to write, can be tricky to debug, and are harder to read. Now if you used bash scripts I would 100% require a rewrite as bash <-> sh is much easier than py<->sh.

[spz2k9]

Downloaded just the json file from zip: iocage fetch -P jellyfin.json

Issues, one breaking, others can be ignored:

* for iocage jails it should either be dashed ("jail-name-here") or just one word ("jailnamehere"). I am partial to the later as the ports system does not allow dashes in names. `iocage` can't use a jail with a space and will give nonsensical errors if you try as it does not sanity check json files.

Not sure about which jail-name? From your above command iocage fetch -P jellyfin.json there was no --name jailname maybe it's a default name where none are given? The documentation seems to indicate that the plugin cannot have name or dashes only underscores. But the name itself will be handled by the UI anyway... I honestly doubt the users will use the command line.

* nitpick: might want to mention that hw support is only for gen8+ intel graphics

Oh... that means the documentation is wrong then... I wrote 4th gen and newer in the hardware section and not 8th gen... well... yeah I suppose I could mention this somewhere... don't really know where tho... maybe in the README... but it's probably not gonna be displayed anywhere.

* nitpick: it leaves the plugin name as "jellyfi" and I have no clue why (`plugin_name:jellyfi`)

Not too sure where the name "jellyfi" is displayed... maybe you could try to add "--name jftest001" to the iocage command see if it fixes the name.

* nitpick: the pkg `python` is meta port and should not be used for direct dependencies. HOWEVER, it is typically fine to do so and even nicely makes symlinks for things like /bin/python so users don't have to fix shebangs in scripts full of linux-isms.

Yeah... I didn't really know which one to choose from so I took the generic one and since it works well I kept it as is... maybe I should do a change to the python 3... or 3.9... not too sure.

* nitpick hardcoded device `/dev/dri/renderD128`. If gen8+ intel always produces that under FreeBSD then its fine.

That's meant to be a little temporary and it's only required for hardware decoding. Ideally the device should be taken from the json file from the Jellyfin configuration (as it's an option in the UI). I didn't have much time to find the file and make a readout.

* nitpick: some formatting between displaying the pkg install output and the rest of the script:
  ![image](https://user-images.githubusercontent.com/1910378/218285808-ca1bf544-fde9-4600-bcd8-942d1d35f59b.png)
  (maybe a new line?)

Yeah could use some newlines here and there... not sure I should leave the debug displayed tho... for now all commands are printing since I never made python and really needed those to be displayed to know where it was going. Anyway if users are installing it from the UI thoses output will never be seen.

* future nitpick: branch names to match FreeBSD releases.

branch names? Is it in the debug output? If it's the "release": "13.1-RELEASE" in the jellyfin.json, it's the ix way they ask the plugins to be formatted... all the plugins I checked have the same tag. I mostly did mine by cut and paste.

  * note to self: actually build jellyfinserver for more than one FreeBSD release

That might be a problem if there's more than one release... depending on how it's done... since the /usr/local/bin/jellyfin_updater get the json for the latest release and look for the file ending with ".pkg"... if there's more than one, the install / update will break.

Something to consider: If allowed by ix-systems, you might want to make two script plugins. One that just handles jellyfinserver on its own and another for a jellyfin install supporting hwaccel. I have found people like their plugins to be "brain off" for setup/install (The devfs setup can be handled inside the json script)

I think they'd allow it since they have Emby and Emby-Beta. The actual script already have hwaccel enabled... but it's missing a script on the host and requires the user to change the jail devfs to 10 manually... I don't think they have a way to automate it since Plex with is a ix plugin has to do those two config manually. Also, It might get tricky to like enable new intel vs old intel... vs amd... to load the correct modules.

list of packages on the plugin jail: pkginfo.txt everything works for me, but I don't have anything that can do hwaccel

That's great.

safe to ignore rant: I would prefer scripts to be shell (/bin/sh) scripts as they don't require additional dependencies, but they are also harder to write, can be tricky to debug, and are harder to read. Now if you used bash scripts I would 100% require a rewrite as bash <-> sh is much easier than py<->sh.

It was my first time with python but like you I'd prefer a sh script... but I'm not well verse in csh... actually hate it. I'd rather use Bash, but it would require also jq and curl to do the processing... which I guess isn't impossible on BSD actually didn't check if they were available as I rarely use BSD and it seemed to me that python was already available in the base jail (which I found out wasn't the case... hense I has to include it in the dependency). I'll probably rewrite everything to bash next week if I get some spare time.

[spz2k9]

Oh and... /dev/dri/renderD128 is actually the first GPU with hardware acceleration (not sure why they start at 128)... so if a GPU is actually detected it will exists.

And I forgot to say but the documentation will actually be needed anyway since the user will have to setup lffmpeg or lffmpeg_advance (on their taste of adventure) to enable hardware at all... unless the jellyfin Team adds a IfBSD to actually output the correct parameter sequence which will render lffmpeg and lffmpeg_advance useless (I hope they do... less work to make a stable jail).

[Thefrank]

Not sure about which jail-name? From your above command iocage fetch -P jellyfin.json there was no --name jailname maybe it's a default name where none are given? The documentation seems to indicate that the plugin cannot have name or dashes only underscores. But the name itself will be handled by the UI anyway... I honestly doubt the users will use the command line.

if no name is defined it will use name: from the json file.

Oh... that means the documentation is wrong then... I wrote 4th gen and newer in the hardware section and not 8th gen... well... yeah I suppose I could mention this somewhere... don't really know where tho... maybe in the README... but it's probably not gonna be displayed anywhere.

4th gen CPUs have 8gen graphics. oh yes, it is VERY confusing. https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units

Yeah... I didn't really know which one to choose from so I took the generic one and since it works well I kept it as is... maybe I should do a change to the python 3... or 3.9... not too sure.

Leave it unless there are "actual" issues with it. The only major one would be if python4 suddenly came out and a bunch of stuff didn't work with it. python would likely install python4 leaving you with broken scripts.

Anyway if users are installing it from the UI thoses output will never be seen.

They can be the one person that pushes the "console" button on the popup but 99/100 people won't even bother unless something fails during the install

branch names? Is it in the debug output? If it's the "release": "13.1-RELEASE" in the jellyfin.json, it's the ix way they ask the plugins to be formatted... all the plugins I checked have the same tag. I mostly did mine by cut and paste.

iocage will try and match the branch name in the repo with the release name that it is installing. This is somewhat important if installing an app that requires different packages based on what version of FreeBSD is being used. This is also important for symbol versions (https://wiki.freebsd.org/SymbolVersioning). As there is only one version of jellyfin that I build and its only for one version of FreeBSD, this can safely be ignored for now :)

The actual script already have hwaccel enabled... but it's missing a script on the host and requires the user to change the jail devfs to 10 manually...

As an example, this hypothetically should work in json

    "devfs_ruleset": {
        "paths": {"bpf*": null},
        "includes": [11]
    },

(null = unhide) (includes should be a devfs ruleset number or numbers)

There is almost no information on how this actually works. Looking for information lead to this: https://github.com/iocage/iocage/issues/1289 . I am not quite sure how much longer ix-systems will actually keep TrueNAS CORE around with plugins

[spz2k9]

Not sure about which jail-name? From your above command iocage fetch -P jellyfin.json there was no --name jailname maybe it's a default name where none are given? The documentation seems to indicate that the plugin cannot have name or dashes only underscores. But the name itself will be handled by the UI anyway... I honestly doubt the users will use the command line.

if no name is defined it will use name: from the json file.

Oh, okay I'd have to do some tests but I think they use the name for the UI in the community plugin.

Oh... that means the documentation is wrong then... I wrote 4th gen and newer in the hardware section and not 8th gen... well... yeah I suppose I could mention this somewhere... don't really know where tho... maybe in the README... but it's probably not gonna be displayed anywhere.

4th gen CPUs have 8gen graphics. oh yes, it is VERY confusing. https://en.wikipedia.org/wiki/List_of_Intel_graphics_processing_units

Okay, Good to know.

Yeah... I didn't really know which one to choose from so I took the generic one and since it works well I kept it as is... maybe I should do a change to the python 3... or 3.9... not too sure.

Leave it unless there are "actual" issues with it. The only major one would be if python4 suddenly came out and a bunch of stuff didn't work with it. python would likely install python4 leaving you with broken scripts.

Okay.

Anyway if users are installing it from the UI thoses output will never be seen.

They can be the one person that pushes the "console" button on the popup but 99/100 people won't even bother unless something fails during the install

Yep. Anyway I'll think about if I completely disable the ouput or update it to be more inline... it all depends on if the plugin is accepted.

branch names? Is it in the debug output? If it's the "release": "13.1-RELEASE" in the jellyfin.json, it's the ix way they ask the plugins to be formatted... all the plugins I checked have the same tag. I mostly did mine by cut and paste.

iocage will try and match the branch name in the repo with the release name that it is installing. This is somewhat important if installing an app that requires different packages based on what version of FreeBSD is being used. This is also important for symbol versions (https://wiki.freebsd.org/SymbolVersioning). As there is only one version of jellyfin that I build and its only for one version of FreeBSD, this can safely be ignored for now :)

Yeah, I've had jails that failed install unless I update 'em... seem to be shore on BSD vs Linux.

The actual script already have hwaccel enabled... but it's missing a script on the host and requires the user to change the jail devfs to 10 manually...

As an example, this hypothetically should work in json

    "devfs_ruleset": {
        "paths": {"bpf*": null},
        "includes": [11]
    },

(null = unhide) (includes should be a devfs ruleset number or numbers)

Interresting, I'll do some test to add the various required path.

There is almost no information on how this actually works. Looking for information lead to this: iocage/iocage#1289 . I am not quite sure how much longer ix-systems will actually keep TrueNAS CORE around with plugins

Okay... that's not great news.

[spz2k9]

I did a quick test with :

  "devfs_ruleset": {
    "paths": {
      "bpf*": null,
      "dri*": null,
      "dri/*": null,
      "drm*": null,
      "drm/*": null
    },
    "includes": [

    ]
  },

and it works... the /dev/dri and /dev/drm are present... will with a ffmpeg call later to be sure nothing else is missing. Funny thing is if includes has a value it crashes with an error that it should be an os.object... anyway, as long as it works.

[Thefrank]

TL;DR: if it works then its fine. not worth spending more time on something that is likely dead and already poorly documented

and it works... the /dev/dri and /dev/drm are present... will with a ffmpeg call later to be sure nothing else is missing. Funny thing is if includes has a value it crashes with an error that it should be an os.object... anyway, as long as it works.

what little is for docs says that include is executed as devfs rule -s ruleset_number add include include_value ruleset_number is a number (I think for iocage it defaults to 4 which is actually its way of saying "none listed, making my own") include_value is also a number matching a rulesset but it also won't resolve other rulesets.

This should be done against a mountpoint (-m) but the iocage docs don't say that it will be. The manpage for devfs is very well documented and includes examples.

[spz2k9]

Well, it's been added in the 13.0-U4 release. Did a quick test everything seems to work perfectly.

[Thefrank]

There is now this too :)

https://www.freshports.org/multimedia/jellyfin/

edit: this is a new port so it will be about a week or so for it to appear on the pkg mirrors

[spz2k9]

Okay, that's good news. Updating will be easier and the python script won't be needed for the install.

[Thefrank]

It should be on pkg mirrors for latest now

[spz2k9]

Yes it is. I've made a couple install test... works well, Haven't tried to configure it but I guess it's gonna be okay. The only thing is Truenas only install from Quaterly... unless you configure it. So I might hold the current config while it gets in the Quaterly.

[Thefrank]

@spz2k9 good to close this?

[spz2k9]

Yes.