Jan Damborsky wrote: > Hi Ethan, > > (CCing c-d, since we have started to discuss design) > > > On 02/ 9/10 06:58 PM, Ethan Quach wrote: >> >> >> On 02/09/10 06:58, Jan Damborsky wrote: >>> Hi Sarah, >>> >>> >>> On 02/ 9/10 03:20 PM, Sarah Jelinek wrote: >>>> Hi Jan, >>>> >>>> The answer is yes and no :-). >>> >>> I like that one :-) >>> >>>> I need you and your team to define the relevant tags/data/attributes >>>> that are required to specify system configuration in the AI sysconfig >>>> manifest. However, it is partly in the scope of my work since I am >>>> looking at possibly changing the schema we use from relaxNG to another >>>> type that might help us more with extensibility and versioning. So, >>>> the decisions I make will affect how we specify the sysconfig data. >>> >>> I see - it is good to know that nothing is set to stone at this point. >>> We have relatively good vision what configuration parameters >>> we would like to support for purposes of the installers: >>> >>> * user account >>> * network configuration >>> - static IP >>> - DNS naming service >>> - hostname >>> * locale >>> * timezone >>> * keyboard layout >>> >>> There are dependences which might affect the final list (e.g. zones), >>> but I assume those might be addressed later when we come to agreement >>> on requirements, since I assume that the design will allow to extend >>> list of supported config parameters (mapped as XML entities) once >>> new requirement is identified. >>> >>> >>>> >>>> I do have a question for you.. would using DTD as our schema language >>>> help you at all in defining and implementing the system configuration >>>> functionality in AI? >>> >>> The answer is yes and no :-) It depends on how much we would like to >>> involve the Automated Installer in processing the system configuration >>> manifest. >>> The extreme which we were initially considering was just to take >>> sysconfig manifest and directly apply it as an SMF profile without >>> any processing. In that case, we would need to use DTD, since >>> SMF profiles use DTD XML schema. >> >> This was my assumption of what we were going to do. With this >> approach, the set of possible configuration is automatically >> extensible based on whatever is supported as configuration in >> SMF service properties going forward. >> >>> I am in process of thinking about this and I feel we would like to have >>> installer involved in this process - e.g. for syntactic and semantic >>> validation. In this case, chosen XML schema is less important. >> >> We had requested the ability to syntactically validate a given SMF >> profile, and they'd already provided that -- "svccfg apply -n >> <profile>" -- >> with the eSMF profiles work PSARC 2009/371 >> >> There are still limitations to this because if we try to validate the >> file >> on the server, it is perhaps incomplete since a server could be >> running a different release of Osol than what is being installed. >> However, the install environment should be able to syntactically >> validate the file as well. >> >> These were just my thoughts/assumption on the matter. Jan/John, >> if you've thought about other reasons/aspects regarding this, lets >> discuss. I haven't really thought through the possible negative >> consequences of just making the "sysconfig manifest" an SMF profile. > > Thinking about this, I can see there might be some disadvantages > of this approach - however, it is to be determined if they are important. > > * since the client would apply given SMF profile without being > involved in > processing it, I agree that it would easily allow to extend set of > supported > properties without need to modify the installer. > On the other hand it would means that any SMF property (not only those > considered as Sysconfig parameters) might be unconditionally set > on installed system via Sysconfig manifest. Not sure if this might be > considered as potential security issue.
For network based AI, you're already installing over the network so there is already some sort of ultimate trust being placed in the server. I can't see the delivery of a collection of system settings via the sysconfig manifest being a larger security issue than must already be accepted. > * Only syntactic validation of sysconfig parameters would be done before > first boot. If any parameter is semantically invalid or not applicable > to the installed system (e.g. invalid NIC name), it would be recognized > during first boot when particular SMF services would apply the > configuration > which might not be considered as good user experience. > Not sure how much we would like to involve the installer into this - > in current installer we at least validate settings for user account, > I can see more validation might be possible. I don't want an automated install to fail because a network interface name is wrong - it's a relatively trivial detail that can be corrected after the reboot. The only situation in which this becomes a problem is when you don't have remote console capability and you get the primary network interface name wrong and on reboot, you fail to bring up any network interfaces. However ensuring that at least one network interface will be brought up when it reboots after an automated install is worthwhile. > * user would need to remember appropriate services & SMF properties to > configure > particular things which might not be considered as user friendly. > Also, since some > of those properties will be private to the installer, it might not > be appropriate > to expose them to the end user. I disagree with the first part of this being a problem. On the one hand, you can use exisiting names for service and properties, thereby allowing any existing property to be configured and on the other, you need to create a whole new namespace and make sure that you can correctly map a name in it to the correct service and property. > > * Support for dynamic/derived manifests might not be possible on client > side. For instance, some network parameters might be dynamically > determined by client - e.g. > - NIC name set to name of boot NIC > - static IP set to the one obtained from DHCP, ... As far as I know, we currently do not do the latter. I would also argue that solving these problems requires input from NWAM. > Based on this, I am thinking about alternate approach > > - unify AI & Sysconfig XML schemas and define new set of XML > tags for supported Sysconfig parameters > > - installer then would transform parameters obtained from sysconfig > manifest to appropriate SMF profile. During that operation, it could > > * derive some parameters if desired > * semantically validate Sysconfig portion of manifest (syntactic > validation > would be common for AI & Sysconfig if provided in unified XML file). > > The disadvantage of this approach is that whenever new Sysconfig > parameter > would be introduced, installer would need to be modified accordingly - > at least new entry added to the dictionary which would serve to transform > particular Sysconfig parameter to SMF profile. Correct. So if I introduce a new service and I want to allow someone to specify a property for it in the Sysconfig manifest, then the Sysconfig manifest needs to be updated too. I think a much more powerful solution is to design the Sysconfig manifest's DTD such that you can include an arbitrary SMF manifest inside it (excluding itself, of course :) But this begs the question, how many services and the properties should be configured via Sysconfig's manifest vs creating specific manifests and applying them to the system by installing them into the right directory as part of the AI process? If everything and anything can be configured by the Sysconfig manifest, are individual SMF manifests therefter redundent? Darren
