Gregory Shaw wrote: > I finally made it through the strategy review. It's really good stuff.
Thanks! > > A couple of points regarding the mock-up: > > - A button to skip the creation of a new user should exist. If you > choose to skip, it should pop up with a warning dialog, but it should > allow you to skip. This is for users that will add the client to NIS or > some other directory services solution. This is how most of the Linux > distros work today. Yeah, there are definitely details in the mock-up that aren't correct (that's why I tell people it's a "concept car"), and you're right, this is one of them. We might just not ask if we can join a directory service automatically (see below). > - There was discussion about 'supported hardware' via the 'try' option. > A slightly different view would be to have a hardware browser as an > option. That would allow you to see immediately what Solaris has found > and what it might not have found. There are a lot of details to be designed there - this would probably be an evolution of the Install Check tool, see http://www.sun.com/bigadmin/hcl/hcts/install_check.html Certainly, what we have in the mock-up isn't sufficient, though. Our UI designer will have a lot to think about here. > - A dialog to ask for directory information (ldap, nis, etc.) would be > useful. That's where I think we start back on the slippery slope to questions about 3-headed dogs. We might end up providing it on some path or another, but really, we want this to be auto-configuring for the common case, and that should be possible in most of the environments where a directory is being used. Ultimately, it depends to a great extent what the Sparks, Duckwater, and Network Automagic projects produce, because they basically own this particular problem. I essentially intend to get Installation Engineering mostly out of the business of system configuration - the current sysidtool discontinuity with the rest of the system is a historical smash up caused by too many re-organizations and shifting of responsibilities. It wasn't supposed to be that way. > - DHCP has the ability to set the NTP server automatically. It would be > good to present that in the NTP/time dialog. > Or not at all. My expectation is that in most cases, if we can automatically determine these things, we won't ask, we'll just do it; there will be sufficient tools integrated into the system to adjust these settings later. > > In the doc, one thing that I didn't agree with: Protection of the root > password via remote install/boot. (e.g. making it so a user can't reset > the password via a boot CD) > > I don't think this should be attempted, as it will only cause > problems. In security, if you have physical access to the box, > software security is irrelevant. > That was a suggestion from one of my early reviewers, which I thought deserved recording for further investigation. I agree, physical access is exceptionally difficult to defend against, but there's a defense-in-depth argument that leaves me sympathetic to the thought that someone should at least investigate the question more. It's not actually carried into the requirements at present (I only used the adjective "desirable" in that discussion) , and it's not a high priority in my view until I get more data points saying it's important or useful. We need to have some alignment discussions with the security team anyway, this'll be a topic we can kick around with them. Thanks for your comments! Dave
