Randy: > On Wed, 26 Aug 2009, Brian Cameron wrote: > >> >> Jedy/Sherry: >> >>> Sherry gave us the whole story. The logic you mentioned will be >>> implemented in ConsoleKit which will be integrated after b128. So >>> currently, we have 2 options. The first one is to wait ConsoleKit's >>> integration. The second one is to integrate the current fast reboot >>> support of GNOME restart dialog at b124 and then update it after >>> ConsoleKit's integration after b128. >> >> Note that ConsoleKit currently does not support the ability to respond >> to different types of reboot options. So, I assume part of the plan to >> use ConsoleKit in the future is to enhance it so it can support doing >> this. > > IMHO, it is sufficient for the restart dialog to only have > 'Restart", as other choices are effectively TMI. The majority of > users will gladly take the default policy as to what restart() means > (fast, through BIOS, whatever). Users that have a clue as to the > difference between 'reboot -f' and 'reboot -p' will be happy to do > that on a CLI. And as long as there is a decent API to select what > the default reboot properties should be, I don't really see that the > added complexity is worth it.
Yes, perhaps ConsoleKit could be modified to check an SMF property to determine what the default boot preference is, and call the right command, whether it is "reboot -f" or "reboot -p" instead of calling init. This would eliminate the need for the ConsoleKit D-Bus interfaces needing to be expanded so that reboot options can be passed in. >>>> 2. Options for GDM >>>> >>>> 2.1 With unmodified HAL >>>> >>>> Currently GDM uses the interfaces provided by HAL. hald runs >>>> as a privileged process and checks for required >>>> authorizations. If the caller has sufficient authorization to, >>>> say reboot, it will invoke hal-system-power-reboot-sunos.sh. >> >> GDM and ConsoleKit do not use HAL at all today. GDM/ConsoleKit support >> shutdown/reboot as follows today: > > This gets to my original issue: there is no common methodology for > handling system services. They should be using D-Bus (or something > like D-Bus), and let the backend services be whatever. I am not sure what "they" you are talking about. GDM and ConsoleKit do use D-Bus for all IPC. >> - The new GDM rewrite has a login GUI which checks the >> solaris.system.shutdown RBAC key directly. If the "gdm" user has >> this authorization, then GDM will present the "Shutdown" and "Reboot" >> buttons in the dialog. If they are pressed, a message is passed to >> ConsoleKit via D-Bus. >> >> - ConsoleKit checks to see if the user who passed the D-Bus message has >> the solaris.system.shutdown RBAC key defined. If so, it will call a >> script. One script for shutdown and another script for reboot. >> The shutdown script calls "/sbin/init 5" and the reboot script calls >> "/sbin/init 6". > > (Not sure I like this at all) Although ConsoleKit does support some ability to shutdown and restart the system, there is no reason we need to make use of it if there are other, better interfaces available to use. Perhaps ConsoleKit isn't the best interface to use to manage shutdown and restart? In the ConsoleKit ARC case, it was never proposed that ConsoleKit should be the "one true" restart and shutdown mechanism on Solaris. Instead, the Desktop team just made a reasonable effort to make sure that if the ConsoleKit interfaces are called that it does something reasonable. That said, ConsoleKit is an option we can consider. If a project team at Sun wants to enhance ConsoleKit so that it does this job, there is no reason we can not do that. I just recommend that if we do this, we work with the upstream community to design a solution that is designed to work well across different platforms that ConsoleKit supports. However, if we decide that Solaris should not use ConsoleKit for shutdown and reboot, then it probably makes more sense to disable these ConsoleKit interfaces and make the GDM GUI instead use whatever interfaces make the most sense on Solaris. Note I am talking about the "Shutdown" and "Reboot" buttons that can appear on the GDM GUI if the "gdm" user has the solaris.system.shutdown authority, which is not the case on Solaris by default. >> Note that any user can call ConsoleKit with a message to request >> shutdown or reboot. If it was passed in from the GDM GUI by clicking >> on the associated button, then the user would be the "gdm" user. But >> ConsoleKit will only call the shutdown/reboot script if the calling >> user has the solaris.system.shutdown authority. >> >> In GDM 2.20 and earlier (currently used in Nevada and OpenSolaris), it >> works much the same, with the following differences: >> >> - ConsoleKit is not used at all, GDM does all the work. >> - The shutdown/reboot commands are defined to be "/sbin/init 5" and >> "/sbin/init 6" in the GDM configuration. >> - The new GDM uses D-Bus messages for IPC while the old GDM uses a >> private socket which can be accessed directly or via the >> gdmflexiserver program. See "man gdmflexiserver" to see the >> commands used to trigger reboot or shutdown. > > Are these D-Bus messages directed towards the ConsoleKit daemon, to > hald, or something that happens to be listening? The D-Bus messages are directed to ConsoleKit, which takes care of shutting down or restarting the system. > As I understand the description, the ConsoleKit daemon is waiting > for D-Bus messages and will respond to a 'restart' request. What if > hald also responds? init(1m) does audit, but will we get the desired > information (this is what I seem to be wrestling with suspend right > now)? I would much rather see a single service (possibly a merge of > ConsoleKit, HAL, and powerd) that will (among other things) respond to > D-Bus requests, audit the actual requesting user/application, and > perform the proper action, hopefully based on some larger policy that > might determine that ConsoleKit Manager sessions are not allowed to > stop/restart the system. I agree that it would be best to manage this with one solution and set of interfaces. If we decide that ConsoleKit is not the best daemon to manage this, then it makes sense to disable this feature. That would simply be a matter of making the ConsoleKit scripts for reboot and shutdown no-ops, so that any requests are ignored. >> I am sure the existing D-Bus messages could be augmented to allow more >> flexibility in specifying how the system should reboot. Likewise, the >> GDM login GUI could be augmented to allow users to specify what kind of >> reboot they want to do if the "gdm" user has the >> solaris.system.shutdown key defined. > > Here, I believe that D-Bus needs some extension to support a larger > variety of controls, including platform-private controls. But > certainly it is beyond this case. This is not a limitation of D-Bus. You can use D-Bus to pass any information you like to any process, assuming that the interfaces are defined. We could enhance ConsoleKit's D-Bus interface to support passing in additional options if we want. Or we could use some other program to manage this, which could use D-Bus. >> In other words, I did not have any serious problems with your proposal. >> More of a concern that we are trying to design new ConsoleKit features >> without including the upstream community in the design process. > > A place where I do agree, we should be working with the upstream > community to provide these controls. If we decide to solve this problem using an external module, such as ConsoleKit, then we should work with the upstream community in adding the needed features. If we use our own home-built solution, then that obviously requires less coordination and negotiation. Brian
