smartmontools in the jail?

[svartalf]

I'm trying to use that amazing fan controller script by Stux here. It works great by itself, but I thought that it would be nice to put it into a jail, just in case.
The thing is: smartctl is unable to access /dev/ada* disks from the jail.
Right now I ended with a custom devfs ruleset, but smartctl still not able to read data from disk. Is it even possible? I'm mostly a linux user and feeling kind dumb here.

FreeNAS 11.2-BETA1:

freenas# uname -a
FreeBSD freenas.local 11.1-STABLE FreeBSD 11.1-STABLE #0 r325575+b31fa24ea5b(freenas/11-stable): Thu Jul 5 16:57:13 EDT 2018 root@nemesi
s.tn.ixsystems.com:/freenas-11.2-releng/freenas/_BE/objs/freenas-11.2-releng/freenas/_BE/os/sys/FreeNAS.amd64 amd64



freenas# cat /etc/devfs.rules
..
[devfsrules_jail_fan=6]
add include $devfsrules_jail_dhcp
add path 'ada*' unhide
add path 'ada*' mode 0777


0777 mode is too permissive, I know, just tried to get to the point.

UI changes for jail:

Code:

devfs_ruleset=6
mount.devfs=1  # it is a checkbox in UI actually, but I assume it is mapped to 1
mount.fdescfs=1  # checkbox too
enforce_statfs=0
allow_mount=1  # checkbox too
allow_mount.devfs=1  # checkbox too

After devfs.rules file editing and UI changes:

service devfs restart
iocage restart fan # fan is a jail name here


Inside the jail:

root@fan:~ # ls -la /dev/ada*
crwxrwxrwx 1 root operator 0x5b Jul 15 16:27 /dev/ada0
crwxrwxrwx 1 root operator 0x5c Jul 15 16:27 /dev/ada0p1
crwxrwxrwx 1 root operator 0x62 Jul 15 16:27 /dev/ada0p1.eli
crwxrwxrwx 1 root operator 0x5f Jul 15 16:27 /dev/ada0p2
crwxrwxrwx 1 root operator 0x5e Jul 15 16:27 /dev/ada1
crwxrwxrwx 1 root operator 0x61 Jul 15 16:27 /dev/ada1p1
crwxrwxrwx 1 root operator 0x75 Jul 15 16:27 /dev/ada1p2
crwxrwxrwx 1 root operator 0x73 Jul 15 16:15 /dev/ada2
crwxrwxrwx 1 root operator 0x76 Jul 15 16:15 /dev/ada2p1
crwxrwxrwx 1 root operator 0x77 Jul 15 16:15 /dev/ada2p2


And smartctl in the jail:

root@fan:~ # smartctl -a /dev/ada0
smartctl 6.6 2017-11-05 r4594 [FreeBSD 11.1-STABLE amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

/dev/ada0: Operation not permitted
Please specify device type with the -d option.

Use smartctl -h to get a usage summary


Is it possible to pass ada* disks into a jail in that way so smartctl can access them?

 

[Jailer]

Is it possible to pass ada* disks into a jail in that way so smartctl can access them?

That would kind of defeat the purpose of the isolation that jails provide.

 

[svartalf]

That would kind of defeat the purpose of the isolation that jails provide.

Yes, it is and I fully understand that.
Basically in this case it does not matter where to put that script - either in the root system or in jail it will have an access to ada disks and can do anything (with all respect to Stux, I'm all about abstract things here).
As far as I see, the only thing why jail is better: it will hide all script-related stuff from the root system: there are perl, smartmontools and rc.d service script. And since there is a devfs with jail rules, it seems to be possible, so why not?

 

[jbondhus]

Any luck getting this to work? I'm struggling with it myself, I need to use telegraf to feed smart data to another system for tracking, but all packages need to be installed in jails, which now don't support passing through SMART data apparently.

UPDATE 2018-10-19 12:06 AM CDT:
Apologies, didn't realize I necro'd this thread.

 

[Rocco83]

FYI, this can be solved as described in

Moving bacula-sd into a FreeBSD jail – Dan Langille's Other Diary

meaning,
setting
securelevel=0 (at maximum) on the jail setting.

Please note that i have added also in /dev/devfs.rules

Code:

[devfsrules_disks=104]
add include $devfsrules_hide_all
add include $devfsrules_unhide_basic
add include $devfsrules_unhide_login
add path 'da*' unhide
add path 'pass*' unhide
add path 'ada*' unhide
add path 'xpt*' unhide

xpt is needed for camcontrol.

finally set

Code:

iocage set devfs_ruleset=104 <jail>

and

Code:

/etc/rc.d/devfs restart

Finally, please take note that the following error may happens (i suggest to execute iocage from commandline to catch it):

Code:

* Ruleset 104 does not exist, using defaults

Which seems that has been solved in v12 (nevertheless, i have not tested it)

Ruleset exists but iocage does not find it · Issue #952 · iocage/iocage

This worked before upgrading iocage today and upgrading the jail to 12.0-RELEASE-p5 Make sure to follow and check these boxes before submitting an issue! Thank you. $ iocage --version Version 1.2 R...

github.com

Based on rough test, restarting devfs is needed before executing the jail.

 

[sretalla]

Coming back to this as I wanted to use it today, a little testing shows that this will work (TrueNAS CORE 13.0 U5):

iocage create -n "smartmon" -r 13.1-RELEASE dhcp="on" vnet="on" boot="on" securelevel=0 devfs_ruleset=0

Then in the jail, pkg install smartmontools

Works fine for smartctl -a /dev/ada0 or whatever...

I would not suggest enabling the SMART service in the jail though (even if the install of smartmontools suggests it), as that would conflict with the host.