Sarah Jelinek wrote: > Hi Ethan, >>> >>> >>> My thoughts on this were that we have not disabled the sysidtools >>> fully in any release of the installer to date. So, doing this by >>> modifying the install scripts to not run the sysidtools might be >>> problematic. >> >> But the install scripts are already *not* running the sysidtools for >> GUI mode in the existing installer (minus the keyboard and locale >> items). The GUI application itself, manually execs the sysidtools after >> having generated a complete sysidcfg file and placing it into >> /etc/sysidcfg. > > I did not realize this. I found the sysid panels for the GUI. But, can't > find in the install scripts where the sysid tools are not run if we are > in GUI mode. It looks like sysid-finish is always run. But, I may be > missing something.
Its a little buried in sysid-finish. See the if clause at line 30. If non-gui mode, it runs the individual sysidtools, else at line 132 (GUI mode), it runs the java sysid wizard. > > For Dwarf we could do what the current GUI apparently does, and not run > the sysid tools at all, without the sysidcfg file. And, then set the > default values we want as part of the perform_install. Or... we could > utilize the sysidcfg file as we have outlined to set the defaults we > want using the sysidtool mechanism, and change those values as the user > inputs data. For installation only. I agree here, but instead of placing dummy values in for the data the GUI is going to gather, why not just wait until the end, and have perform_install call each of the sysidtools - sysidnet, sysidkrb5, sysidns, sysidnfs4, sysidsys, sysidroot - after appending the gathered data for rootpw and timezone to the default sysidcfg. The user account is a new thing, so it'll likely have to be configured by the orchestrator as there is no existing sysidtool that configures this. > For upgrade, I would imagine we just > don't run the sysidtool utilities at all. Running the sysidtools wouldn't hurt. pfinstall ends up not copying over any of the configured files from the miniroot to the upgraded target anyway except the /etc/default/init file (it updates the init file with the selected default system locale chosen during the upgrade run). For Dwarf, this means that if the locale/lang in the init file is left untouched in the miniroot, then pfinstall will end up changing the init file in the upgraded target back to C from whatever it was set to before upgrade. I think we need to address this. > I realize that the existence > of a sysidcfg file implies that the sysidtools run before the Dwarf GUI The existence of a sysidcfg doesn't imply that. The install scripts and text/gui mode dictate whether they run. The existence of the file is purely ancillary to the sysidtools. > so we have to account for all sysidtool questions within this file to > suppress the sysidtools UI's. > > It would appear that the current GUI recognizes the sysidcfg file if > there is one then. Since it doesn't ask certain question in soldevx1 > based on the sysidcfg file. Is this correct? The hidden hack here is that the sysid wizard uses 'sysidget' to silently parse out the existing /etc/sysidcfg file, and feeds nv pairs to the sysid wizard in a tmp file. This is how the current GUI "recognizes" the sysidcfg file. > > In some ways it would be easier for us to allow the setting of those > things that we are setting defaults for with the sysidcfg file > mechanism. Makes the perform_install() function somewhat easier to > manage. We know we are going to have defaults for nfsv4 domains, network > interface, name service, security policy. The others we ask the user for > input, so we can set those accordingly during the installation. Barring the orchestrator tapping into sysidlib, I agree this would be the easiest way. > > Will have to think on this a bit more to figure out the best way to go > for Dwarf. >
