Running plugins as nobody.wheel?

[Tsaukpaetra]

So... I'm trying to run certain plugins that write files (such as btsync and transmission) as the user nobody.wheel (so it can write to my shares in a manner that anyone can open and subsequently modify resultant files).
By default each of the apps mentioned (and likely almost all others) are configured to run as their own user (for example, user 817 aka btsync for btsync).

That's nice, except of course the default permissions mean that only that particular app can write/modify the files! Practically useless because I can only manage files within that app... maybe (most apps don't provide the level of usability I typically require).

Now, I can usually tell the program to run as another user in the rc.conf file (for example,

Code:

btsync_user="nobody"
btsync_group="wheel"

However, this totally breaks the plugin-ness of the plugin, because now the control process apparently can't see the pid? I dunno, hard to figure out why, but the server just returns 500 (internal server error) when I do it.

Anyways, it seems like it should be fairly straightforward to properly add support for setting and managing these rc variables.

How can I get this properly implemented? It just gets tiring having to regularly

Code:

find Games/ -type f -print0 | xargs -0 chmod 777

 

[Joshua Parker Ruehlig]

you can set user and group that way, then just change the ownership of the btsync datadirecotry and it should work.

Code:

chown -R nobody:wheel /var/db/btsync

 

[Tsaukpaetra]

I do, but somehow this inevitably breaks the plugin's capability of refreshing in the GUI.
Essentially, the plugin's python interface doesn't get started for whatever reason when starting the jail, but if I start it manually, it works as expected:

Code:

usr/pbi/btsync-amd64/bin/python2.7 /usr/pbi/btsync-amd64/control.py start 192.168.1.186 12351

The problem is that it's impossible to determine why such a simple rc.conf change breaks the plugins api. Is it because multiple btsync lines are unexpected, and gets interpreted as "not enabled"? But then, since the jail is seen as running, it tries to get the status of it and (obviously) fails due to the control daemon not running (since it wasn't started by the plugin's api when the jail started).

Does that make sense? Am I on the right track?

 

[Joshua Parker Ruehlig]

I do, but somehow this inevitably breaks the plugin's capability of refreshing in the GUI.
Essentially, the plugin's python interface doesn't get started for whatever reason when starting the jail, but if I start it manually, it works as expected:

Code:

usr/pbi/btsync-amd64/bin/python2.7 /usr/pbi/btsync-amd64/control.py start 192.168.1.186 12351

The problem is that it's impossible to determine why such a simple rc.conf change breaks the plugins api. Is it because multiple btsync lines are unexpected, and gets interpreted as "not enabled"? But then, since the jail is seen as running, it tries to get the status of it and (obviously) fails due to the control daemon not running (since it wasn't started by the plugin's api when the jail started).

Does that make sense? Am I on the right track?

Sounds like some of the stuff you are saying almost makes sense but as I recall how the btsync plugin works changing the user btsync runs as shouldn't break anything. All the freenas API does for btsync is write the config and start/stop/status by using the rc.d file.

Please try this..

1. install latest btsync, do not start it
   
2. add the following to /etc/rc.conf.local (/etc/rc.conf gets overwritten by the curent version of the plugin)
   • btsync_user="nobody"
   • btsync_group="wheel"
3. start btsync from the FreeNAS WebUI

 

[Joshua Parker Ruehlig]

so in conclusion, try using /etc/rc.conf.local
most plugins currently clobber /etc/rc.conf, but I did fix this by using sysrc(8). that fix will be in the next release of btsync

 

[Tsaukpaetra]

/etc/rc.conf.local seemed to work! Awesome!