Alan: > Brian Cameron wrote: >> 4.1.1 Detail About ConsoleKit Database >> # Device associated with Xserver running session (if any). >> x11_display_device=/dev/console >> 4.1.5 Environment Variables >> CK_SESSION_X11_DISPLAY_DEVICE - The device associated with the >> Xserver. > > As previously explained to the project team before ARC, in our current X > server > implementations, there may be anywhere from 0 to 16 device files in /dev > representing the display devices on which X is displaying - and there is no > guarantee of uniqueness, nor that the same device file represents the same > physical device. It seems highly unlikely that any client is going to be > able > to do anything useful with this string, so I still don't understand what the > point of reporting it is.
The onepager explains that these environment variables are only used by the scripts described in section 4.1.4. In other words, the scripts that ConsoleKit runs when a session starts. These environment variables simply pass along the information associated with the session. Since the display device indicates what VT is being used on the console, this could be useful for the session startup script to do special work based on which VT is being used, if desired. >> # Boolean. Set to "true" if the active session, "false otherwise" >> is_active=false > > "the" active session? On a multi-seat or Sun Ray system, is it okay that > there are multiple active sessions? The description of this field is not very good. I need to update the onepager tomorrow anyway when Halton provides some updates to better highlight how multi-seat works with the new ConsoleKit (e.g. details on how the /etc/ConsoleKit/displays.d and /etc/ConsoleKit/sessions.d files work). I will improve this comment when I make those changes. Anyway, this field specifies the "active" session for a given seat. On a Sun Ray display you can only have a single session on a seat, and it would always be active. This field is more useful on a seat that supports VT where you can have multiple sessions, but where only one is active at a time. That said, if Sun Ray wanted to integrate more tightly with ConsoleKit, they could use this field to indicate whether a given session is actually mapped to a display or not. With the current Sun Ray implementation, ConsoleKit would not be aware of displays that are not actually running on a display (or seat). >> /var/svc/manifest/system/consolekit.xml Uncommitted SMF >> >> integration >> file. > > The SMF manifest (*.xml file) should be a Project Private implementation > detail. > The public interface you're missing here is the FMRI - that's the interface > the > rest of the system needs to use to control your service, and thus the one you > need to include in your interface table. Okay, I will also make this change to the onepager tomorrow. >> /usr/lib/ck-collect-session-info Private See 4.1.2. >> /usr/lib/ck-get-x11-display-device Volatile See 4.1.2. >> /usr/lib/ck-get-x11-server-pid Private See 4.1.2. >> /usr/lib/ConsoleKit/scripts/ck-system-restart Private See 4.1.6. >> /usr/lib/ConsoleKit/scripts/ck-system-stop Private See 4.1.6. > > Why are the first three not in /usr/lib/ConsoleKit with the rest? The first three are libexec programs, but since Solaris doesn't support libexec, they get installed to /usr/lib. If you think it would be cleaner, we could set libexecdir to /usr/lib/ConsoleKit when building ConsoleKit to move the libexec programs into /usr/lib/ConsoleKit. >> + /usr/lib/ck-collect-session-info --uid UID --pid PID >> >> This program is passed the UID and PID of a process, and it >> returns >> the following information from the ConsoleKit database about that >> process. >> >> + /usr/lib/ck-get-x11-server-pid >> >> Returns the PID of the Xserver process running on the current >> $DISPLAY environment variable. > > What happens if the X server is running in a different zone/label than the > client? (For instance, on a Trusted Extensions system, the X server runs > in the global zone, labeled clients in non-global, per-label zones.) > Is there a ConsoleKit daemon per zone? In this case, parts of the ConsoleKit framework would not work, including this program. However, since the parts of the ConsoleKit framework which would break are only used to support VT switching on the console, I do not believe this would be a problem. Clients in a trusted environment would not be using VT switching, or using the console. >> GDM uses the ck-get-x11-display-device application to get the >> x11-display-device value. When a display is running via graphical >> VT, >> ConsoleKit uses the following mechanism to get the TTY value. This >> mechanism works on other operating systems, such as Linux, and also >> works on Solaris when VT is being used. When VT is used, these >> programs make use of proc interfaces to collect some of this >> information, as follows: >> >> The ConsoleKit ck-get-x11-display-device, ck-get-x11-server-pid, and >> ck-collect-session-info programs call XOpenDisplay on a given >> $DISPLAY, >> and then calls ConnectionNumber to get the socket associated with >> that display. getpeerucred is used to get the UID and PID of the >> process. > > This still seems highly silly, given that gdm can get the pid of the Xserver > by simply checking the variable into which it put the return value from the > fork() call it made to start the X server. I will touch base with the upstream ConsoleKit maintainers and get a more official response to this design choice before responding. >> ConsoleKit manages stopping and restarting the system. On Solaris, >> when >> the display manager informs ConsoleKit that such an action is >> requested, >> the chkauthattr function is called to see if the calling user has >> RBAC >> permissions for the "solaris.system.shutdown" key. If yes, then the >> /usr/lib/ConsoleKit/scripts/ck-system-restart script is run if a >> restart >> action was requested. If a shutdown action was requested, then the >> /usr/lib/ConsoleKit/scripts/ck-system-stop script is run. >> >> On Solaris, the ck-system-stop script runs "/sbin/init 5" and the >> ck-system-restart script runs "/sbin/init 6". > > Do provisions need to be made for choosing between fast reboot& slow reboot? That could be a useful enhancement to ConsoleKit. As long as only GDM uses ConsoleKit for these features, and as long as the GDM "Shutdown" and "Reboot" options are turned off by default (as Glenn said is a requirement), I am not sure it is needed, though. Brian
