From sacadmin Mon Nov 1 18:36:37 2004 Date: Mon, 1 Nov 2004 18:36:37 -0800 (PST) From: Alan Coopersmith Message-Id: <200411020236.iA22abvv003454@almas.sfbay.sun.com> To: PSARC@sac.sfbay.sun.com Cc: Alan.Coopersmith@Sun.COM Subject: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] Content-Length: 16709 Subject: PSARC FastTrack [11/08/2004]: X Consolidation conversion to SMF I am sponsoring the following fasttrack for myself, with a timeout of next Monday, 11/8/2004. -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering Template Version: @(#)sac_nextcase 1.55 08/11/04 SMI 1. Introduction 1.1. Project/Component Working Name: X Consolidation conversion to SMF 1.2. Name of Document Author/Supplier: Author: Alan Coopersmith 1.3 Date of This Document: 01 November, 2004 4. Technical Description X Consolidation conversion to SMF ================================= This project converts the X consolidation deliverables to SMF/Greenline and creates a X server configuration mechanism built on the Greenline registry. It aims to solve three problems at once: - conversion of the X consolidation to SMF, to further the SMF integration and coherence of Solaris service administration - providing a mechanism to define a "default" X server on Solaris and to allow programs to check & change that service easily in the face of the range of methods for starting the X server - providing a mechanism to specify default options for the X server, given the variety of places X server command line options are specified, and the differences in the Xsun and Xorg command line syntaxes This project was designed with many current and upcoming users/projects in mind, including GNOME Accessibility, Secure By Default, Solaris x86 X server configuration (kdmconfig et al.), and several others. It establishes two new subdirectories in the FMRI service namespace: svc:/application/x11 - for X11-specific services svc:/application/font - for non-X11-specific font services It delivers manifests for these FMRI's, more fully described in the noted sections below: svc:/application/x11/x11-server X Server Configuration svc:/application/x11/xfs X Font Server svc:/application/font/fc-cache FontConfig Cache Updater svc:/application/font/stfsloader STSF Font Server Loader All of these services and their properties are declared to be Unstable interfaces at this time. A new shell script is provided with Evolving stability level to shield other projects from possible changes in those Unstable interfaces. This project is declared suitable for integration into a Micro/Patch release of Solaris, though it intends to integrate into the upcoming Minor release of Solaris 10 FCS. The "meat" of this project is in the x11-server service - the rest are straightforward conversions of the existing X Consolidation init.d scripts and inetd.conf entries and border on architectural self-review. X Server Configuration ====================== This project is not as much a traditional service as a means to use the Greenline repository to store service information. It is an attempt to centralize the configuration of the command line used to start the X server in an OS with 4 provided applications to start the X server (dtlogin, gdm2, xdm, & xinit), 3 X servers to choose from (Xsun, Xorg & Xvfb), and a proliferation of configuration files to change in order to change which X server is used by default or what options are used to configure it. FMRI's & instances ------------------ This project creates the FMRI svc:/application/x11/x11-server for storing X server configuration. Instances of this FMRI will be used to store configuration options for different situations. A new script /lib/svc/method/x11-server will be provided to generate the desired X server command line from this configuration data. Default options will be set in the service properties. They may be overridden by a variety of instance names matched to the situation. The script used to start the X server will look for configuration options in the instances in this order, stopping at the first match for the given property: 1) :displayN (where N is the display number of the X server, i.e. :display0 for :0) 2) any "class" names provided via the -c options to the script. Multiple -c options may be provided, they are searched in the order found on the command line. 3) if any XDMCP options are provided to open a remote display connection, ":remote", otherwise ":local" 4) the default properties for the service Class names may be any valid FMRI instance name. Sun reserves all class names beginning with lowercase letters for it's own use - customers wishing to create their own class names may use names beginning with an uppercase letter. Properties ---------- These properties may be set in any instance: "options/server" (type astring - absolute path to Xserver binary, currently must be "/usr/openwin/bin/Xsun", "/usr/openwin/bin/Xvfb", or "/usr/X11/bin/Xorg") "options/tcp_listen" (type boolean - false disables listening for incoming TCP/IP connections) "options/default_depth" (type int - default depth) "options/server_args" (type astring - additional arguments to pass to X server, server dependent) The default options provided in the manifest for the service will be: server=/usr/openwin/bin/Xsun (on sparc), /usr/X11/bin/Xorg (on x86) default_depth=24 server_args="" tcp_listen=true (for now - see "Future Projects" below for upcoming Secure-by-Default project changes) No instances will be configured in the provided manifest, but may be added later. Xserver script ----------------- /usr/X11/bin/Xserver is provided as a way to start the system default X server with the system default options, plus any additional options specified by the user. It's syntax is: Xserver [-c ] : [] must be a unsigned integer that is a valid X display id. -c : Class to use for configuration data, may be specified multiple times (see above for details). All arguments after display are simply passed to the X server being started. This script calls 'exec' to start the X server to preserve the parent/child relationship required by display managers & xinit. This behaviour and the CLI syntax were chosen to make it a drop-in compatible replacement for existing X server startup procedures. For compatibility with other systems, a symbolic link /usr/X11/bin/X -> Xserver will be provided. Integration with other programs ------------------------------- dtlogin, gdm & xdm will be modified to set their default X server to: /usr/X11/bin/Xserver :0 xinit currently starts the first program named X it finds in its path, unless an X server is specifically named on the command line. No modifications will be made to it, preserving the current behavior of starting Xsun for those who run with a PATH containing /usr/openwin/bin ahead of /usr/X11/bin (or without /usr/X11/bin). Those who want the new behavior can either set their path or specify /usr/X11/bin/Xserver in the xinit command line. Running as an actual service ---------------------------- Some sites want an X server started at boot without the benefit of a display manager/requirement for manual login. One common example is servers running Java servlets or other applications that require an X server to render graphics that they then save to a file or serve via the web instead of displaying directly (see http://developers.sun.com/solaris/articles/solaris_graphics.html for an example rc script to start either Xsun or Xorg for this purpose). The x11-server service will support this - "enabling" an instance of the service will cause it to start the X server by itself, via the script /lib/svc/method/x11-server. This script is not intended/supported for direct use, but only for use an SMF service method program. It's syntax is simple: x11-server [-d ] [-c ] [-- ] -d : display must be a unsigned integer that is a valid X display id. If not specified, a default of 0 is used. -c : Class to use for configuration data, may be specified multiple times (see above for details). : SMF method - currently only "start" is supported Any arguments after -- are passed on unmodified to the X server command line. x11-server service status ------------------------- The status of the x11-server service may be a bit confusing at first glance. "Enabled" means that the X server is started directly, without the benefit of any display manager. This is not useful in most cases, since it does not start a desktop environment session or any clients, but is useful in certain limited cases as noted in the solaris_graphics.html article. Most machines will show the service as "disabled" even when the Xserver is running, since it will instead have been started by a display manager or xinit. The current X architecture unfortunately requires a parent/child relationship between the display manager and X server, so independent startup via SMF is not possible. A project is suggested below in the future projects section to convert the display managers to become SMF delegated restarters to deal with this issue, but for now the solution to this confusion will have to be documentation and education.) X Font Server (xfs) =================== This project converts the X Font Server startup from an inetd.conf entry to a Greenline svc.inetd service. It replaces the automatically generated conversion currently produced by inetconv at OS install time. This project assigns an FMRI of svc:/application/x11/xfs to the X Font Server service. (The inetconv-generated FMRI was svc:/network/fs/tcp6:default.) Supported user-configurable options: - enabled or disabled - - the exec string may be changed to specify xfs arguments previously provided on the command line in inetd.conf (see xfs man page) fsadmin ------- Solaris has traditionally provided a simple script, /usr/openwin/bin/fsadmin, to enable and disable the X Font Server and to query if it is currently enabled or disabled. This script does not edit inetd.conf, but simply makes and/or removes the symbolic link /usr/openwin/lib/fs.auto -> /usr/openwin/bin/xfs (inetd.conf contains the /usr/openwin/lib/fs.auto for the path to xfs, so if the link is removed, it can't find it to run and generates an error. The link is contained in the SUNWxwfs package manifest so is always restored on system upgrade or package re-installation.) Unfortunately, no ARC record can be found for this, and it's believed to pre-date ARC reviews, so stability levels are inferred from documentation. Since the fsadmin command is documented with no stability warnings, it is presumed to be Stable. The fs.auto link is not documented anywhere (though visible to those who read the shell script or look at inetd.conf), so is presumed to be Project Private. This project converts the fsadmin tool to use inetadm to enable and disable the service. It does not preserve compatibility with the undocumented functionality of removing fs.auto to disable the service. FontConfig Cache Updater (fc-cache) =================================== This project replaces the /etc/rc2.d/S98fc-cache script with a a transient Greenline service named svc:/application/font/fc-cache:default . It simply runs /usr/bin/fc-cache as root at system startup to ensure the fontconfig font caches are up-to-date and exits as soon as that is complete (normally within seconds on a system that has had no fonts installed or changed since the last run of fc-cache). The only supported configuration of this service by users/admins is enabling and disabling the service. No user-servicable parts are found inside any of the properties. STSF Font Server Loader (stfsloader) ==================================== This project converts the STSF Font Server loader stfsloader from an inetd.conf entry to a Greenline svc.inetd service. It replaces the automatically generated conversion currently produced by inetconv at OS install time. It continues to be an rpc/ticotsord service that is not exposed to the network, but serves only to allow the service to be started on demand by another local program without priviledges. This project assigns an FMRI of svc:/application/font/stfsloader:default to this service. (The inetconv-generated FMRI had the quite unfriendly name svc:/network/rpc-100424_1/rpc_ticotsord:ticotsord.) The only supported configuration of this service by users/admins is enabling and disabling the service. No user-servicable parts are found inside any of the properties. Future Projects =============== (*NOT* part of this case - provided for informational purposes only) - Solaris x86 Xserver configuration: A project which will follow very very soon will use the svc:/application/x11/x11-server property options/server to determine which X server to configure when running the Xserver configuration commands (kdmconfig et al). - Secure-by-Default & hardening tools such as JASS: It is expected these projects will change the svc:/application/x11/x11-server property options/tcp_listen to be false. A project wanting to completely lock down the system at the expense of the "Login to remote host" capability in dtlogin would also set that property false in svc:/application/x11/x11-server:remote but it is expected that most configurations will leave that set to true since it would only open network connections at user request. - svc:/application/x11/xprint-server: A planned project for a future release would provide an additional X11 service to control starting of the Xprt server used for printing by Mozilla, mp, and other programs. - Display Configuration Management tool (DCMtool - LSARC 2003/031): An RFE will be raised with the DCMtool team suggesting that modifying their tool to set Xsun command line arguments via the svc:/application/x11/x11-server property options/server_args would ease many of the problems the current implementation faces in trying to modify /etc/dt/config/Xservers directly, including compatibility with Sun Ray & gdm2. - Additional options: Currently any command line options beyond -nolisten tcp and the default depth have to be specified via the server_args option. As we gain experience with this and find more options that may need to be user settable or settable in a X-server-independent manner, additional properties may be added. For instance, one potential use is adding properties to configure options required for accessibility technology and then providing an application that uses RBAC to allow users to set only those properties themselves to remove the need for sysadmin intervention when users need to use those technologies. - Display Managers as delegated restarters: Future projects could convert one or more of the display managers (dtlogin, gdm2, xdm) into designated restarters so that X server status information could be monitored via the Greenline framework as well - this could be particularly interesting on Sun Ray servers. However, these potential projects are not yet funded nor on any project team's dashboard. Interface Tables ================ Imported Interfaces: -------------------- assorted SMF interfaces Evolving PSARC 2002/547 svc:system/filesystems/local Unstable PSARC 2002/547 svc.inetd & inetadm Evolving PSARC 2003/544 dtlogin configuration files ? (presumed Standard) ASARC 1994/437 gdm.conf Unstable LSARC 2003/261 Xsun server CLI ? (presumed Standard/Stable) mostly pre-ARC Xsun -nolisten tcp Stable PSARC 2001/535 Xorg server CLI External PSARC 2004/187 Xorg as default on x86 Unstable PSARC 2004/661 Default depth of 24-bit Evolving PSARC 2004/490 /usr/openwin/lib/fs.auto ? (assumed Project Private) pre-ARC fsadmin ? (assumed Stable) pre-ARC xfs ? (assumed Standard) pre-ARC /etc/rc2.d/S98fc-cache Project Private LSARC 2003/273 /etc/init.d/fc-cache Project Private LSARC 2003/273 Exported Interfaces: -------------------- svc:/application/x11/x11-server Unstable x11-server properties Unstable /lib/svc/method/x11-server Project Private /usr/X11/bin/Xserver Evolving /usr/X11/bin/X -> Xserver link Evolving svc:/application/x11/xfs Unstable svc:/application/font/fc-cache Unstable svc:/application/font/stfsloader Unstable /usr/openwin/lib/fs.auto Removed /etc/rc2.d/S98fc-cache Removed /etc/init.d/S98fc-cache Removed 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: X Consolidation (Desktop C-Team) 6.5. ARC review type: FastTrack From sacadmin Tue Nov 2 04:51:34 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16775.33477.633441.493225@gargle.gargle.HOWL> Date: Tue, 2 Nov 2004 07:51:17 -0500 From: James Carlson To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-Reply-To: Alan Coopersmith's message of 1 November 2004 18:36:37 References: <200411020236.iA22abvv003454@almas.sfbay.sun.com> Content-Length: 1212 Alan Coopersmith writes: > - Secure-by-Default & hardening tools such as JASS: It is expected these > projects will change the svc:/application/x11/x11-server property > options/tcp_listen to be false. A project wanting to completely lock down [...] > - Display Configuration Management tool (DCMtool - LSARC 2003/031): An RFE > will be raised with the DCMtool team suggesting that modifying their tool > to set Xsun command line arguments via the svc:/application/x11/x11-server > property options/server_args would ease many of the problems the current > implementation faces in trying to modify /etc/dt/config/Xservers directly, > including compatibility with Sun Ray & gdm2. [...] > svc:/application/x11/x11-server Unstable > x11-server properties Unstable If the required properties to do the above are Unstable, are those projects expected to take out contracts while doing that GL-porting work? Why is the intentional configuration interface made Unstable? -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Tue Nov 2 06:14:47 2004 Date: Tue, 02 Nov 2004 09:14:34 -0500 From: "Glenn M. Brunette, Jr." Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-reply-to: <16775.33477.633441.493225@gargle.gargle.HOWL> To: James Carlson Cc: Alan Coopersmith , PSARC@sac.sfbay.sun.com Message-id: <4187964A.4090803@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040726 References: <200411020236.iA22abvv003454@almas.sfbay.sun.com> <16775.33477.633441.493225@gargle.gargle.HOWL> Content-Length: 1835 James Carlson wrote: >Alan Coopersmith writes: > > >>- Secure-by-Default & hardening tools such as JASS: It is expected these >> projects will change the svc:/application/x11/x11-server property >> options/tcp_listen to be false. A project wanting to completely lock down >> >> >[...] > > >>- Display Configuration Management tool (DCMtool - LSARC 2003/031): An RFE >> will be raised with the DCMtool team suggesting that modifying their tool >> to set Xsun command line arguments via the svc:/application/x11/x11-server >> property options/server_args would ease many of the problems the current >> implementation faces in trying to modify /etc/dt/config/Xservers directly, >> including compatibility with Sun Ray & gdm2. >> >> >[...] > > >>svc:/application/x11/x11-server Unstable >>x11-server properties Unstable >> >> > >If the required properties to do the above are Unstable, are those >projects expected to take out contracts while doing that GL-porting >work? > >Why is the intentional configuration interface made Unstable? > > To echo James' concern, I would argue that the x11-server properties should be Evolving in order to better support customer security and configuration requirements. While the SBD project and JASS tools will most certainly make use of the tcp_listen property, I can also safely say that external security recommendation guides such as those published by the Center for Internet Security and the NSA will also need to use this configuration interface in order to support the security requirements of their constituencies. Consequently, the interface should be provided at a higher level of stability, IMHO. g -- Glenn M. Brunette, Jr. Distinguished Engineer, Chief Security Architect Client Solutions, Global Data Center Practice CTO Sun Microsystems, Inc. From sacadmin Tue Nov 2 08:36:56 2004 Date: Tue, 02 Nov 2004 08:36:54 -0800 From: Alan Coopersmith Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-reply-to: <16775.33477.633441.493225@gargle.gargle.HOWL> To: James Carlson Cc: Alan Coopersmith , PSARC@sac.sfbay.sun.com Message-id: <4187B7A6.7030202@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 References: <200411020236.iA22abvv003454@almas.sfbay.sun.com> <16775.33477.633441.493225@gargle.gargle.HOWL> Content-Length: 629 James Carlson wrote: > Why is the intentional configuration interface made Unstable? To be honest, simply because that's what all the FMRI's & properties I saw in the previous greenline cases I looked at were labeled as. I have no objection to raising the stability to Evolving if that's more appropriate. (I suppose the alternative is to create a quick Xserver-cfg script that everyone else calls to set the properties and leave the properties themselves hidden behind the pair of Xserver & Xserver-cfg.) -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Tue Nov 2 09:09:31 2004 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16775.48969.826064.781169@gargle.gargle.HOWL> Date: Tue, 2 Nov 2004 12:09:29 -0500 From: James Carlson To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-Reply-To: Alan Coopersmith's message of 2 November 2004 08:36:54 References: <200411020236.iA22abvv003454@almas.sfbay.sun.com> <16775.33477.633441.493225@gargle.gargle.HOWL> <4187B7A6.7030202@sun.com> Content-Length: 999 Alan Coopersmith writes: > James Carlson wrote: > > Why is the intentional configuration interface made Unstable? > > To be honest, simply because that's what all the FMRI's & properties > I saw in the previous greenline cases I looked at were labeled as. OK; that's what I was really getting at. I wanted to understand the motivation. > I have no objection to raising the stability to Evolving if that's > more appropriate. > > (I suppose the alternative is to create a quick Xserver-cfg script that > everyone else calls to set the properties and leave the properties > themselves hidden behind the pair of Xserver & Xserver-cfg.) Either approach sounds fine to me for the intended consumers, though I think just raising the stability of the smf bits is simpler. -- James Carlson, IP Systems Group Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677 From sacadmin Wed Nov 3 13:41:04 2004 Date: Wed, 3 Nov 2004 13:39:22 -0800 (PST) From: Gary Winiger Message-Id: <200411032139.iA3LdMCW008201@marduk.eng.sun.com> To: PSARC@sac.sfbay.sun.com, alanc@almas.sfbay.sun.com Cc: Alan.Coopersmith@Sun.COM Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] Content-Length: 2679 IMO, this project is a good step forward and I'm glad to see it. > Class names may be any valid FMRI instance name. Sun reserves all class names > beginning with lowercase letters for it's own use - customers wishing to create > their own class names may use names beginning with an uppercase letter. Perhaps an aside from the architecture here, but I believe it goes to the overall architecture presented here: I don't see the uppercase/lowercase distinction documented (at least where I would expect it -- smf(5) or service_bundle(5)). Is this just a documentation bug that needs to get fixed before FCS, or is it not the case that such a distinction exists? If it is a docs, bug, please file. If it is documented, please correct my lack of a complete search. > Properties > ---------- What is the agreed taxonomy? Did the team agree to a stable taxonomy? How does the administrator configure these properties and create new instances? If with svc{adm,cfg}, it seems appropriate for a Rights Profile to contain some specific authorization(s) of the form "solaris.smf.manage." or perhaps if there is a class of auths, "solaris.smf.manage..{,, ...}" What becomes of dtconfig(1) -- should really be (1M)? In particular -inetd and -inetd.ow. I presume the rest is easilly enforced by authorization. Is that another project? > Running as an actual service > ---------------------------- > The x11-server service will support this - "enabling" an instance of the How is this to be managed? (Presumably svcadm) Where will the administration be documented? What authorization is needed for this? Shouldn't this auth be in a Desktop Management Rights Profile? > X Font Server (xfs) > =================== > This project converts the X Font Server startup from an inetd.conf entry to > a Greenline svc.inetd service. It replaces the automatically generated > conversion currently produced by inetconv at OS install time. > fsadmin > ------- Same set of questions for fsadmin/xfs. > FontConfig Cache Updater (fc-cache) > =================================== Same set of questions for fc-cache > Future Projects > =============== > - Display Configuration Management tool (DCMtool - LSARC 2003/031): An RFE > will be raised with the DCMtool team suggesting that modifying their tool > to set Xsun command line arguments via the svc:/application/x11/x11-server > property options/server_args would ease many of the problems the current > implementation faces in trying to modify /etc/dt/config/Xservers directly, > including compatibility with Sun Ray & gdm2. What happens if this isn't converted? Gary.. From sacadmin Wed Nov 3 13:58:09 2004 Date: Wed, 03 Nov 2004 13:58:07 -0800 From: Alan Coopersmith Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-reply-to: <200411032139.iA3LdMCW008201@marduk.eng.sun.com> To: Gary Winiger Cc: PSARC@sac.sfbay.sun.com, alanc@almas.sfbay.sun.com Message-id: <4189546F.4030407@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041004 References: <200411032139.iA3LdMCW008201@marduk.eng.sun.com> Content-Length: 3549 Gary Winiger wrote: > IMO, this project is a good step forward and I'm glad to see it. > > >>Class names may be any valid FMRI instance name. Sun reserves all class names >>beginning with lowercase letters for it's own use - customers wishing to create >>their own class names may use names beginning with an uppercase letter. > > > Perhaps an aside from the architecture here, but I believe it > goes to the overall architecture presented here: > I don't see the uppercase/lowercase distinction documented (at least > where I would expect it -- smf(5) or service_bundle(5)). This distinction is specific to the x11-server service, so wouldn't appear in smf(5) or service_bundle(5), but Xserver(1). > What is the agreed taxonomy? Did the team agree to a stable > taxonomy? Unstable. > How does the administrator configure these properties and create > new instances? svcadm & svccfg. > If with svc{adm,cfg}, it seems appropriate for a > Rights Profile to contain some specific authorization(s) of the > form "solaris.smf.manage." or perhaps if there is a class of > auths, "solaris.smf.manage..{,, ...}" I've been too overwhelmed learning greenline to try to tackle figuring out how rights profile definitions - we've just got too many new levels of complexity to learn here. If you can provide simple instructions in plain english, I'll follow them. Otherwise, we'll have to defer rights profiles until later or cancel this project. > What becomes of dtconfig(1) -- should really be (1M)? Not part of the X consolidation, so not included in this project. Ask the CDE team, if/when they come forward to convert. >>Running as an actual service >>---------------------------- >>The x11-server service will support this - "enabling" an instance of the > > > How is this to be managed? (Presumably svcadm) Yes. > Where will the administration be documented? Xserver(1m) is where I'm planning to put it. (And since I'm the closest thing X has to a documentation team right now, that's it.) > What authorization is needed for this? Shouldn't this auth be > in a Desktop Management Rights Profile? Root. I have no idea - you tell me. (See above comments on rights profiles.) > >>X Font Server (xfs) >>=================== >>This project converts the X Font Server startup from an inetd.conf entry to >>a Greenline svc.inetd service. It replaces the automatically generated >>conversion currently produced by inetconv at OS install time. > > >>fsadmin >>------- > > > Same set of questions for fsadmin/xfs. fsadmin. fsadmin & xfs man pages. root. > >>FontConfig Cache Updater (fc-cache) >>=================================== > > > Same set of questions for fc-cache svcadm fc-cache man page root. >>- Display Configuration Management tool (DCMtool - LSARC 2003/031): An RFE >> will be raised with the DCMtool team suggesting that modifying their tool >> to set Xsun command line arguments via the svc:/application/x11/x11-server >> property options/server_args would ease many of the problems the current >> implementation faces in trying to modify /etc/dt/config/Xservers directly, >> including compatibility with Sun Ray & gdm2. > > > What happens if this isn't converted? Then it continues to be incompatible with Sun Ray and gdm2, but should still work with dtlogin on any system that doesn't have Sun Ray software installed. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Wed Nov 3 14:00:49 2004 Date: Wed, 03 Nov 2004 14:00:47 -0800 From: Alan Coopersmith Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-reply-to: <4189546F.4030407@Sun.COM> To: Alan Coopersmith Cc: Gary Winiger , PSARC@sac.sfbay.sun.com, alanc@almas.sfbay.sun.com Message-id: <4189550F.9020308@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041004 References: <200411032139.iA3LdMCW008201@marduk.eng.sun.com> <4189546F.4030407@Sun.COM> Content-Length: 323 Alan Coopersmith wrote: >> What is the agreed taxonomy? Did the team agree to a stable >> taxonomy? > > > Unstable. Whoops - I meant Evolving as specified in the earlier e-mail exchange with Jim. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Mon Nov 8 20:42:08 2004 Date: Mon, 08 Nov 2004 20:42:03 -0800 From: Alan Coopersmith Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-reply-to: <200411020236.iA22abvv003454@almas.sfbay.sun.com> To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com Message-id: <41904A9B.2030802@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.4) Gecko/20040414 References: <200411020236.iA22abvv003454@almas.sfbay.sun.com> Content-Length: 685 Alan Coopersmith wrote: > Subject: PSARC FastTrack [11/08/2004]: X Consolidation conversion to SMF > > I am sponsoring the following fasttrack for myself, with a timeout of next > Monday, 11/8/2004. The timer has expired, but the question of rights profiles remains outstanding. I'm working this offline with Gary and have set the status to "need spec" until that's worked out. I believe all other issues raised are resolved, and the only other change to the original spec is to raise the stability of the services and their properties from Unstable to Evolving. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Wed Nov 10 14:13:01 2004 Date: Wed, 10 Nov 2004 14:12:56 -0800 From: Alan Coopersmith Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/08/2004] In-reply-to: <4189546F.4030407@Sun.COM> To: Gary Winiger Cc: PSARC@sac.sfbay.sun.com, alanc@almas.sfbay.sun.com Message-id: <41929268.4060604@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041004 References: <200411032139.iA3LdMCW008201@marduk.eng.sun.com> <4189546F.4030407@Sun.COM> Content-Length: 572 Alan Coopersmith wrote: >> What becomes of dtconfig(1) -- should really be (1M)? > > Not part of the X consolidation, so not included in this project. Ask the > CDE team, if/when they come forward to convert. Just for informational purposes, that project is now on the table for S10 U1, so should be coming forward (though possibly to LSARC instead) in the next few months. Stephen Hahn & the Greenline team are working with the CDE team on this. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From sacadmin Wed Nov 10 14:17:57 2004 Date: Wed, 10 Nov 2004 14:17:51 -0800 From: Alan Coopersmith Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/12/2004] In-reply-to: <41904A9B.2030802@sun.com> To: Alan Coopersmith Cc: PSARC@sac.sfbay.sun.com Message-id: <4192938F.2080509@Sun.COM> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_dSanRrY/KsXDV4AWYcvPIA)" X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041004 References: <200411020236.iA22abvv003454@almas.sfbay.sun.com> <41904A9B.2030802@sun.com> Content-Length: 4648 This is a multi-part message in MIME format. --Boundary_(ID_dSanRrY/KsXDV4AWYcvPIA) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT Alan Coopersmith wrote: > The timer has expired, but the question of rights profiles remains > outstanding. I'm working this offline with Gary and have set the > status to "need spec" until that's worked out. I've worked this out with Gary and am now resetting the timer to expire at the end of Friday, 11/12/2004. The revised spec containing the change to stability level (Unstable->Evolving) and RBAC rights profiles & authorizations has been put into the case directory at: http://sac.eng/arc/PSARC/2004/752/spec.txt Diffs against the old version of the spec are attached for easier review. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering --Boundary_(ID_dSanRrY/KsXDV4AWYcvPIA) Content-type: text/plain; name=spec-diffs.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=spec-diffs.txt --- orig-spec.txt Mon Nov 1 18:33:17 2004 +++ spec.txt Wed Nov 10 14:15:06 2004 @@ -30,10 +30,9 @@ svc:/application/font/fc-cache FontConfig Cache Updater svc:/application/font/stfsloader STSF Font Server Loader -All of these services and their properties are declared to be Unstable -interfaces at this time. A new shell script is provided with Evolving -stability level to shield other projects from possible changes in those -Unstable interfaces. This project is declared suitable for integration +All of these services and their properties are declared to be Evolving +interfaces at this time. A new shell script is also provided with Evolving +stability level. This project is declared suitable for integration into a Micro/Patch release of Solaris, though it intends to integrate into the upcoming Minor release of Solaris 10 FCS. @@ -78,6 +77,11 @@ beginning with lowercase letters for it's own use - customers wishing to create their own class names may use names beginning with an uppercase letter. +A new authorization name is defined in auth_attr, solaris.smf.manage.x11. +This authorization will be assigned by default to a new rights profile named +"Desktop Configuration." The x11-server manifest will grant management rights +via this authorization. + Properties ---------- These properties may be set in any instance: @@ -190,6 +194,9 @@ exec string may be changed to specify xfs arguments previously provided on the command line in inetd.conf (see xfs man page) +The xfs manifest will grant rights via the above mentioned +solaris.smf.manage.x11 authorization. + fsadmin ------- @@ -226,6 +233,11 @@ enabling and disabling the service. No user-servicable parts are found inside any of the properties. +A new authorization name is defined in auth_attr, solaris.smf.manage.font. +This authorization will be assigned by default to the "Desktop +Configuration" rights profile introduced above. The fc-cache manifest will +grant management rights via this authorization. + STSF Font Server Loader (stfsloader) ==================================== This project converts the STSF Font Server loader stfsloader from an @@ -241,6 +253,9 @@ configuration of this service by users/admins is enabling and disabling the service. No user-servicable parts are found inside any of the properties. +The stfsloader manifest will grant management rights via the above mentioned +solaris.smf.manage.font authorization. + Future Projects =============== @@ -314,16 +329,20 @@ Exported Interfaces: -------------------- -svc:/application/x11/x11-server Unstable -x11-server properties Unstable +svc:/application/x11/x11-server Evolving +x11-server properties Evolving /lib/svc/method/x11-server Project Private /usr/X11/bin/Xserver Evolving /usr/X11/bin/X -> Xserver link Evolving -svc:/application/x11/xfs Unstable -svc:/application/font/fc-cache Unstable -svc:/application/font/stfsloader Unstable +svc:/application/x11/xfs Evolving +svc:/application/font/fc-cache Evolving +svc:/application/font/stfsloader Evolving +solaris.smf.manage.font authorization Evolving +solaris.smf.manage.x11 authorization Evolving +"Desktop Configuration" role Evolving + /usr/openwin/lib/fs.auto Removed /etc/rc2.d/S98fc-cache Removed --Boundary_(ID_dSanRrY/KsXDV4AWYcvPIA)-- From sacadmin Fri Nov 12 17:53:07 2004 Date: Fri, 12 Nov 2004 17:53:00 -0800 From: Alan Coopersmith Subject: Re: X Consolidation conversion to SMF [PSARC/2004/752 Timeout: 11/12/2004] In-reply-to: <4192938F.2080509@Sun.COM> To: PSARC@sac.sfbay.sun.com Cc: Alan Coopersmith Message-id: <419568FC.5060409@Sun.COM> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20041004 References: <200411020236.iA22abvv003454@almas.sfbay.sun.com> <41904A9B.2030802@sun.com> <4192938F.2080509@Sun.COM> Content-Length: 590 Alan Coopersmith wrote: > I've worked this out with Gary and am now resetting the timer to expire > at the end of Friday, 11/12/2004. The revised spec containing the > change to stability level (Unstable->Evolving) and RBAC rights profiles & > authorizations has been put into the case directory at: > http://sac.eng/arc/PSARC/2004/752/spec.txt As there have been no more comments, and Friday is now over (it's done! go home!), I'm closing this fasttrack as approved. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering