Run a Script After Unlocking a Pool

[seiichiro0185]

Hi,

I'm a happy FreeNAS-User since some months, and so far everything seems to work quite well. I run a fully encrypted RAIDZ1-Pool off 4 drives.

I have set up sftp on the server, to give some users and my vserver access for backup purposes and stuff like that. The Users are all chrooted, so they can initially only see there home directory. To give them access to specific things I bind-mount (using nullfs) the required directories to their homedirs. I do this using a simple script that does all the mounts.

At the moment I have to run the script manually after unlocking the device, which is not ideal since it involves firing up a console manually and starting the script there (Also I tend to forget this step after reboot, making the backup scripts from my vserver fail etc..). So is there a way to start the script automatically once the pool is unlocked and ready, like its done with the services? Or is there a better way to approach this?

Thanks in advance for any advice.

 

[SweetAndLow]

There is a post init section in the GUI settings that will do anything you want post startup.

 

[seiichiro0185]

Thanks for your response,

I did see this in the webgui, but this is run imideately after startup as I understand it? At this point the encrypted drive isn't unlocked since I have to put in the passphrase / key in the gui to unlock, and only after that has happened the script can be run. So it seems this setting doesn't help in my case (unless I misunderstood what it does and it actually waits for the pool unlock).

 

[SweetAndLow]

You could have acron job that executed every couple min and check the mount and if it doesn't exist just mount it.

 

[seiichiro0185]

OK, I'll try it like that, just thought there might be a less hacky way I didn't know off yet ;)

 

[Ericloewe]

OK, I'll try it like that, just thought there might be a less hacky way I didn't know off yet ;)

You could try logging a feature request. Sounds like something interesting.

 

[cyberjock]

OK, I'll try it like that, just thought there might be a less hacky way I didn't know off yet ;)

I'd say that's pretty funny considering you are already doing hacky stuff with your script...

 

[seiichiro0185]

I'd say that's pretty funny considering you are already doing hacky stuff with your script...

Well, If there is a better way to achieve the same (that is provide content from one central directory into homedirs of multiple chrooted users), then I'll be happy to hear about it.

 

[cyberjock]

Hold on. Now you confuse me more.

So you have this hacky script. You're open to hearing of ways to make it "less hacky", but you've never asked the forums if there's a better way until just now.

You have this script you want to run after mounting an encrypted pool, but when we tell you how to do it in a hacky way you wanted something less hacky.

You've already lowered your standard to accepting things that are hacky. So why not just do it again?

Not trying to be a jerk, I'm truly trying to understand the thought process. To me, the far riskier thing is to do the mounts like you are doing (I'm not aware of any alternative). Running cronjobs is not hacky at all. :P

 

[seiichiro0185]

Hold on. Now you confuse me more.

So you have this hacky script. You're open to hearing of ways to make it "less hacky", but you've never asked the forums if there's a better way until just now.

You have this script you want to run after mounting an encrypted pool, but when we tell you how to do it in a hacky way you wanted something less hacky.

You've already lowered your standard to accepting things that are hacky. So why not just do it again?

Not trying to be a jerk, I'm truly trying to understand the thought process. To me, the far riskier thing is to do the mounts like you are doing (I'm not aware of any alternative). Running cronjobs is not hacky at all. :p

I don't have a problem with the suggested solution of using cron and I know its a standard unix way of doing things (I use Linux for more than 15 years, so I've seen my share of cron jobs ;) ). But since I'm fairly new to FreeBSD and especially FreeNAS I simply thought there might be an option to do user defined stuff after unlocking an encrypted volume that I haven't discovered yet, since there might be other cases where this might be usefull except my hacky mount script.

Might I ask why you consider doing the mounts to the chroots risky? As far as I know nullfs-mounts are a standard FreeBSD feature, and I don't see how these should be a problem. I used the same approach on several linux servers for this purpose, and never had any problem with it. So it seemed to be the best (and so far only) way I know of to achieve the functionality I need.

 

[cyberjock]

nullfs-mounts are definitely a standard feature in FreeBSD. The problem is that FreeNAS is built on FreeBSD, but it is not the same as FreeBSD. The devs expect you to use FreeNAS a particular way (the way the manual explains) and they cannot guarantee they won't change something tomorrow that might have terribly dire consequences for your server and your data. We've seen lots of people do things and argue the same as you are (it's FreeBSD, how hard can it be?) and later they are like 'wtf!? my pool just vanished on upgrade and now zpool import is telling me the zpool should be restored from backup'.

I'm not saying you shouldn't do what you are doing (it's your choice and your data). But those of us that have been here for a few years have seen people do incredibly silly and simple things, argued that there was zero risk, then later are begging for someone to do a Teamviewer session and save their server because they had no backup, etc.

So as a general rule, you'll hear us experienced users tell you to use FreeNAS exactly how the manual says and to not get all innovative and inventive with new weird ways to use FreeNAS. If you want to do that, use FreeBSD, because that's why it is there. FreeNAS is for the simple guys that have simple needs and need something that is almost turnkey compared to FreeBSD.

 

[seiichiro0185]

nullfs-mounts are definitely a standard feature in FreeBSD. The problem is that FreeNAS is built on FreeBSD, but it is not the same as FreeBSD. The devs expect you to use FreeNAS a particular way (the way the manual explains) and they cannot guarantee they won't change something tomorrow that might have terribly dire consequences for your server and your data. We've seen lots of people do things and argue the same as you are (it's FreeBSD, how hard can it be?) and later they are like 'wtf!? my pool just vanished on upgrade and now zpool import is telling me the zpool should be restored from backup'.

I'm not saying you shouldn't do what you are doing (it's your choice and your data). But those of us that have been here for a few years have seen people do incredibly silly and simple things, argued that there was zero risk, then later are begging for someone to do a Teamviewer session and save their server because they had no backup, etc.

So as a general rule, you'll hear us experienced users tell you to use FreeNAS exactly how the manual says and to not get all innovative and inventive with new weird ways to use FreeNAS. If you want to do that, use FreeBSD, because that's why it is there. FreeNAS is for the simple guys that have simple needs and need something that is almost turnkey compared to FreeBSD.

Thanks for the detailed explanation. I understand that I might be doing something that is not officially supported by FreeNAS. As this System only holds personal data and nothing mission critical (and I also have a backup of the whole data including mutliple different backups of the more important stuff) I'm prepared to take the (in my opinion small) risk of damaging something with my approach. So I won't come running here asking for anyone of you rescuing my data if I screw something up. I've been on the "other side" (beeing the one the customer comes running to after trashing their data without having backups) multiple times, so I know that's not a workable option ;)