Hi Clay, Yes, that looks like it will work. The 'bug' I was alluding to is actually somewhat different in that the auto_sc_params structure, being passed to auto_parse_sc_manifest() in install_from_manifest() is not initialized. So if you have an SC manifest which does not contain all the expected properties, the code which subsequently validates the SC data produces erroneous results.
--Jens Clay Baenziger wrote: > Hi Jens, > Yes there is a bug. I've included a potential fix in the bug, > however, perhaps there's another, so let me walk though this with you: > > The SC manifest is validated. Yes, that's not obvious that we strip it > out of its comment block if presented in a combined form. It is believed > that most admins will prefer to keep separate SC and AI manifests from > the criteria manifest so one will have a criteria manifest where the SC > is free standing in a normal XML file: > root at opensolaris:~# cat /tmp/test.xml > <ai_criteria_manifest> > <ai_criteria name="Arch"> > <value> > sun4u > </value> > </ai_criteria> > <ai_manifest_file URI="/tmp/ai.xml"/> > <sc_manifest_file name="AI" URI="/tmp/sc.xml"/> > </ai_criteria_manifest> > > root at opensolaris:~# cat /tmp/sc.xml > <?xml version='1.0'?> > <!DOCTYPE service_bundle SYSTEM > "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> > <service_bundle type="profile" name="name"> > <service name="ai_properties" version="1" type="service"> > <instance name="default" enabled="true"> > <property_group name="ai" type="application"> > <propval name="username" type="astring" > value="jack"/> > <!-- Test --> <propval name="userpass" type="astring" > value="9Nd/cwBcNWFZg"/> > <propval name="description" type="astring" > value="default_user"/> > <propval name="rootpass" type="astring" > value="$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/> > <propval name="timezone" type="astring" > value="US/Pacific"/> > </property_group> > </instance> > </service> > </service_bundle> > > This is the desired way for an admin to cleanly interact with the XML > files (and sadly where the bug you've pointed me to exists). The "test" > comment will get passed into the smushed format which it should not. > > The way the AI webserver stores files is in a smushed format where the > criteria are stripped off and the AI and SC manifests are in one file. > It is also possible for an admin to use this format. The SC manifest is > stored as a comment due to being DTD based in a RelaxNG defined XML > file. As such, if one has a comment in the SC manifest comment block it > will fail validation as there will be "extra" content in the file -- the > reset of the SC manifest -- e.g.: > [...] > </ai_manifest> > </ai_embedded_manifest> > <sc_embedded_manifest name = "AI"> > <!-- <?xml version='1.0'?> > <!DOCTYPE service_bundle SYSTEM > "/usr/share/lib/xml/dtd/service_bundle.dtd.1"> > <service_bundle type="profile" name="name"> > <service name="ai_properties" version="1" type="service"> > <instance name="default" enabled="true"> > <property_group name="ai" type="application"> > <propval name="username" type="astring" > value="jack"/> > <!--Fail Validation --> > <propval name="userpass" type="astring" > value="9Nd/cwBcNWFZg"/> > <propval name="description" type="astring" > value="default_user"/> > <propval name="rootpass" type="astring" > value="$5$VgppCOxA$ycFmYW4ObRRHhtsGEygDdexk5bugqgSiaSR9niNCouC"/> > <propval name="timezone" type="astring" > value="US/Pacific"/> > </property_group> > </instance> > </service> > </service_bundle> > --> > </sc_embedded_manifest> > </ai_criteria_manifest> > > For a potential fix for the first case which is a bug from what was > intended see my e-mail for a code review on bug 7503. > > Thank you, > Clay > > > On Wed, 18 Mar 2009, Jens Deppe wrote: > >> Hi, >> >> I'm wanting to submit a bug and a related RFE against the parsing of >> the SC manifest data. The RFE relates to the fact that the SC manifest >> is parsed as plain text and not as XML, thus XML comments end up being >> ignored. >> >> I've seen some comments stating that the parsing may eventually be >> done by an actual XML parser so my question is whether this work is >> already covered by an existing RFE. Depending on the state of that >> work, would also make submitting a bug moot. >> >> --Jens >> _______________________________________________ >> caiman-discuss mailing list >> caiman-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/caiman-discuss >>
