On Thu 02 Aug 2007 at 10:35AM, Yanakiev, Vladimir wrote:
> Yes, John, that's my understanding too - zonecfg is supposed delete
> both the entry in the index file, and the xml. But, somehow we ended
> with this awkward status. It makes sense to me if zonecfg detects such
> status, to send one extra "Status missing - are you sure to
> delete?"-type of message, and remove the xml... It looks like there is
> no logic in the code of zonecfg for the cases when there is trouble
> with the index file...
I did some cleanup in this area a while back; there were a number of
cases where this could wind up happening. Forgive me for coming in late
to the thread but what revision of Solaris are you running?
The changes I made were introduced into Nevada build 24 and appear in
Solaris 10 11/06 (sometimes called "update 3").
PSARC 2005/485 Zone Rename
4963365 zonecfg is unhelpful if /etc/zones not present
4971371 zonecfg should be more paranoid when saving a zone for the first time
5022506 RFE: ability to rename zones
6231612 zonecfg messaging should be improved.
6305400 when zone metadata gets confused, removing configured zones can fail
6318536 zonecfg sometimes seen spinning during certain STC test cases
6321858 zonecfg tab completion could complete slightly more
In particular, the fix for 6305400 should have helped this situation.
The dance to make this all work right is surprisingly complicated.
Check out zonecfg_destroy() in libzonecfg:libzonecfg.c and putzoneent()
in libzonecfg:getzoneent.c if you are interested.
In the future we'll probably move the config into SMF and (I hope) utilize
the index file purely as a cache for information stored in the backend
(for speed) or just drop it altogether. Having multiple places that
this information is stored is very irritating to implement correctly.
Daniel Price - Solaris Kernel Engineering - [EMAIL PROTECTED] - blogs.sun.com/dp
zones-discuss mailing list