There's quite a bit more we could do here, but this hits my basic usage
with vnets. Future work here would be things like ipv6 support or trying
to infer what a custom `interfaces` setting means.
I think these are the same concept, but with slightly different execution.
The main idea is to have a central base system that is shared (readonly) among
multiple jails. When this base system is updated, all the jails that reference
it immediately see the new system files.
This is implemented in iocage as a set of individual zfs mounts, one per
system directory. In Bastille, each system directory is symlinked into a
subdirectory of a single zfs mount.
My test plan here was to import an exported iocage basejail and verify that
its Bastille version has the right fstab and symlink changes:
```
Validating file: ssl_2021-11-19.zip...
File validation successful!
Importing 'ssl' from foreign compressed .zip archive.
Archive: ssl_2021-11-19.zip
extracting: ssl_2021-11-19
extracting: ssl_2021-11-19_root
Receiving ZFS data stream...
Generating jail.conf...
Updating symlinks...
ln: usr/src: Directory not empty
Warning: directory usr/src on imported jail was not empty and will not be updated by Bastille
Container 'ssl' imported successfully.
```
This property is not set by default on all iocage jails. By default, iocage assumes this value is 4. Confusingly, if you query this value from iocage while the jail is running, it will give a dynamically generated value. However, a jail must be stopped to be exported, so we can trust the value in config.json.
This makes it much easier to understand `ifconfig` when run on the jail host. Not sure how to test this, but manually appyling this via `bastille edit` to an existing vnet jail had the right effects when I restarted the jail.
In general and knowing what role will play bastille in the system, has more sense to require networking than login.
This can also helps speeding up boot time if for instance some jails in bastille provide some kind of networking role like acting as a DNS server.
