Tim,
Tim Spriggs wrote:
> Hi,
>
> I want to file an RFE but I thought I should discuss a little before
> I do: I would like a way to run a script in the global zone when a
> non-global zone boots. My use case is:
We actually have a way to get this information. This is described
in the following ARC case:
PSARC/2005/607 Zone Events for Sun Cluster
Because this case is fairly old, it is not open but we could go back
and try to open it if you are interested.
To summarize, this case just created a contract between the zones
project and sun cluster project for using the following APIs:
zonecfg_notify_bind
zonecfg_notify_unbind
zonecfg_notify_critical_enter
zonecfg_notify_critical_exit
zonecfg_notify_critical_abort
A contract is needed because zones doesn't really have a public,
stable API. This is something we are currently looking at and
ties in to the following RFE.
6302213 RFE: 3rd party developers need API for getting zone state
Since all of the zones code is open, you could probably start playing
with the interfaces above. If this is something you want to pursue,
we should continue talking about this off-line so that we can make
sure that we don't break you with any changes to these interfaces (that
is what the contract with SC is for) and so that we get your input into
the API work we are looking at.
Thanks,
Jerry
> I'm a developer for NexentaCP and I would like to make an autobuilder
> using zones. In particular I want to have a zone that will always come
> back in the same state on reboot so that I have minimal packages
> installed and everything gets pulled as defined by source package
> dependencies. The process might look like:
>
> (global zone)
> zone_hook(pre-boot, ...)
> -> a script/action occurs for the zone
> zone_boot(...)
>
> (non-global zone)
> init (the autobuilder will have a svc that builds packages and reports
> status to a server)
> reboot (perhaps with specific args that the hook script can grab)
>
> (global zone)
> zone_halt(...)
> zone_hook(post-halt, ...)
>
>
> I think it would make sense to configure the hooks via a zonecfg section:
> ---
> add hook
> set type=[pre-boot | post-boot | pre-halt | post-halt]
> set action=script
> set path=/path/to/zone_hook.sh
> end
> ---
>
> In my particular use-case I would have a pre-boot hook that rolled the
> zone filesystem to a particular snapshot. This way the zone would always
> come back in the same state:
> ---
> add hook
> set type=pre-boot
> set action=script
> set path=/path/to/zone_scripts/pre-boot.sh
> end
> ---
>
> For a decent interface we would need to pass information to the scripts
> about the zone name, boot args, previous state, ... which might be done
> through the environment? An example script might hackishly look like:
> ---
> #!/bin/sh
>
> # Check for fs reset condition
> echo "$ZONE_BOOT_ARGS" | grep -w 'reset_zone_fs=yes' > /dev/null
> if [ $? != 0 ]; then
> exit 0
> fi
>
> # get fs to reset
> path=`zonecfg -z $ZONE_NAME info zonepath | cut -d: -f2`
> zfs_dataset=`zfs list -H -t filesystem -o mountpoint,name | grep
> ^"$path" | awk '{print $2}'`
>
> # If no fs then exit with an error status
> if [ X$zfs_dataset = X ]; then
> echo Danger Will Robinson... Danger:
> exit -1
> fi
>
> # make sure the snapshot exists and rollback
> zfs list -H -o name -t snapshot -r $zfs_dataset | grep @snapshot_name$ >
> /dev/null
> if [ $? != 0 ]; then
> echo Error: required snapshot does not exist
> exit -1
> fi
> zfs rollback [EMAIL PROTECTED]
>
> exit 0
> ---
>
>
> Comments/criticisms/flying chunkules appreciated.
>
> -Tim
> _______________________________________________
> zones-discuss mailing list
> zones-discuss@opensolaris.org
_______________________________________________
zones-discuss mailing list
zones-discuss@opensolaris.org
