cbsd / cbsd

Yet one more wrapper around jail, bhyve, QEMU and XEN
https://bsdstore.ru
BSD 2-Clause "Simplified" License
677 stars 76 forks source link

jail remount with cbsd configured settings (minor, non urgent feature request) #729

Closed dirkx closed 1 year ago

dirkx commented 1 year ago

Mandatory info for bug reports:

FreeBSD version ( uname -a ): FreeBSD cbsd.test.local 13.1-RELEASE-p6 FreeBSD 13.1-RELEASE-p6 GENERIC amd64

CBSD version ( cbsd version ): 13.1.23

Currently one can use the command cbd mountfstab (i.e. without the 'j') to do a post start re/unmount with a specially created fstab file.

We have a common situation where some encrypted ZFS datasets only become available much later than jstart of the jail that needs them at boot time (but usually exist during normal jail restarts).

So these are in the normal jails-fstab/NAME/fstab.local file as /local-enc-at-rest/xxx /var/xxx nullfs rw 0 0.

So it would be useful to be able to do something like cbdd mountfstab NAME without any argument; or even cbsd mountfstab foo-* without arguments. And have this rely on the default files in prefix/jails-fstab/NAME.

As opposed to us building a hardcoded dependency to the naming structure inside prefix/jails-fstab and abusing the API.

With kind regards,

Dw.

PS: Thanks for all the excelent work !

olevole commented 1 year ago

sounds reasonable

olevole commented 1 year ago

@dirkx you can try 'fast solution' ^^, to check:

mv /usr/local/cbsd/tools/mountfstab /tmp/
fetch -o /usr/local/cbsd/tools/mountfstab https://raw.githubusercontent.com/cbsd/cbsd/develop/tools/mountfstab
chmod +x /usr/local/cbsd/tools/mountfstab

then try to re-mount: cbsd mountfstab NAME where NAME is $jname.

On the other hand, if you are decrypting a directory manually, you may want to turn off container autostart (cbsd jset astart=0 jname=NAME) and trigger the launch of jails in a script that unlocks the decrypted directory.

If you are decrypting a directory a little late after the server has started, then you can use CBSD hooks directories to add 'wait' script. E.g. real sample. Create in ~cbsd/jails-system/NAME/master_prestart.d/test-src-var-db.sh with follow content:

#!/bin/sh

max_retry=60
cur_retry=0
check_for_source="/local-enc-at-rest/xxx"

while [ ${cur_retry} -lt ${max_retry} ]; do

        # available
        [ -r "${check_for_source}" ] && exit 0

        echo "${0} for ${jname}: source encrypted dir is not available yet/not mounted, waiting: ${cur_retry}/${max_retry}: ${check_for_source}" 1>&2
        sleep 1
        cur_retry=$(( cur_retry + 1 ))

done

Where /local-enc-at-rest/xxx - real path to some resource on encrypted data ( e.g. file or directory )

Don't forget to executable flags: chmod +x ~cbsd/jails-system/**NAME**/master_prestart.d/test-src-var-db.sh

This will give you pause before jail start.

Also due to CBSD starts jail in parallel, this should not block other containers from running.

any feedback is welcome!

dirkx commented 1 year ago

Yes - this works really rather splendidly & integrates well with PKCS#11 and what not.

I did notice that it does not seem to include the equally useful wildcard that other j* cbsd commands have (which is totally fine; as a cbsd jls/egrep will mimic this just fine).

As to your example -while-wait script - think it would be useful to have this in the documentation as a very general useful thing (e.g. we have a similar situation where this would help us with waiting for the 90-100 seconds of a pair of DB containing jails to have done their tx-log replays).

But in our case - we prefer the jail to be up without the decrypted data set under it - as to allow the daemons serving the public to emit an error / reject request actively with a reason-code (as opposed to being mysteriously down & triggering things like failover). As it happens - things like Cyrus-imap, postfix and apache-https all give rather sensible errors that can easily be customised into some sort of descriptive error.

Thanks again !

olevole commented 1 year ago
  • think it would be useful to have this in the documentation as a very general useful thing

In fact, there is some information about 'CBSD hooks': https://www.bsdstore.ru/en/13.0.x/wf_jconfig_ssi.html#execscript How to use 'CBSD hooks' dirs - you are only limited by your imagination ;-)

But I know that the documentation is a weak point of the cbsd. Besides, we have to move it into GitHub Wiki pages: https://github.com/cbsd/cbsd/wiki

I hope @kraileth will finish the CBSD book ASAP :smiley: https://eerielinux.wordpress.com/2023/02/08/exploring-the-cbsd-virtual-environment-management-framework-part-3-jails-i/