This part provides an overview of the Solstice AdminSuite software and contains these chapters.
Introduction provides brief descriptions of all the software included with the Solstice AdminSuite product.
Using solstice AdminSuite in a Name Service Environment provides information on how to use the Solstice AdminSuite software in a name service environment.
Security describes security issues and provides suggestions on how to use the Solstice AdminSuite software in a manner that conforms to your site security policies.
Using the Solstice Launcher provides instructions on how to start the Solstice Launcher and add applications to the Solstice Launcher.
Solstice AdminSuite is a collection of graphical user interface tools and commands used to perform administrative tasks such as managing users, groups, hosts, system files, printers, disks, file systems, terminals, and modems.
This is a list of the overview information in this chapter.
The Solstice AdminSuite 2.3 product provides the following new features:
Printer Manager network printer functionality
Printer Manager now has the ability to add a printer to your network. For more information about Printer Manager, see its online help and Chapter 9, Setting Up SunSoft Print Client Software With Printer Manager.
Password capability
Using Group Manager, you can set group or database passwords. In addition, you can set the system's root password using Host Manager.
Multihomed host alias support
Host Manager now enables you to add additional IP addresses for hosts that have multiple network interfaces. Refer to Chapter 6, Managing Server and Client Support With Host Manager for more information about creating multihomed hosts.
JavaStationTM support
To accommodate JavaStation clients, Host Manager now enables you to add JavaStations to your network. Refer to Chapter 6, Managing Server and Client Support With Host Manager for more information.
OS services removal support
Host Manager now allows you to remove OS services from an OS server. Refer to Chapter 6, Managing Server and Client Support With Host Manager for more information.
High Sierra File Systems support
Storage Manager supports the creation of a High Sierra file system mount point. Refer to Chapter 11, Managing Disks and File Systems With Storage Manager for more information.
Script enabler support
The Host Manager and User Manager tools have been updated with the ability to run scripts that you have created to customize your operations. For example, you may have scripts that you run when you add a user to your system. Using the script feature, you can add a user from User Manager and also run the script at the same time by using the Scripts Enabled feature.
CacheFSTM boot for Solaris 2.6-based AutoClients
A new booting process for Solaris 2.6-based AutoClients creates a cache during the intial boot. Refer to Solstice AutoClient 2.1 Administration Guide for more information about the CacheFS boot process.
The Solstice AutoClient 2.1 product is part of the Solstice AdminSuite 2.3 product. Even though Host Manager has the ability to add AutoClient systems, you should first obtain an AutoClient license to add and run an AutoClient system.
Updated root user handling
Previous versions of AdminSuite had limited root capabilities; that is, when running AdminSuite as root, very few functions could be performed. AdminSuite 2.3 has been updated to allow root more flexibility in running AdminSuite applications.
The Solstice AdminSuite software enables you to locally or remotely manage:
Important system database files, such as aliases and hosts
User accounts and groups
File systems
Disk slices and fdisk partitions
Terminals and modems
Diskless and dataless clients
AutoClient systems
Standalone systems
JavaStations
Servers
Printers
See Chapter 2, Using Solstice AdminSuite in a Name Service Environment, for information on controlling access to the Solstice AdminSuite software.
Using the Solstice AdminSuite software to perform system administration tasks has these benefits:
The tools and commands are faster than using numerous Solaris commands to perform the same tasks.
System files are updated automatically without the risk of making errors by editing important system files manually.
You can manage systems remotely from one system.
Table 1-1 lists the Solstice AdminSuite tools that must be run under an X Window SystemTM, such as the OpenWindowsTM environment. Table 1-1 also lists the commands that provide the same functionality as the Solstice AdminSuite tools and can be used without running an X Window System. The chapters in Part 2 for each tool provide corresponding examples for the AdminSuite command-line equivalents in each procedure.
The command-line equivalents are available only after AdminSuite has been installed.
AdminSuite Tool |
AdminSuite Command-Line Equivalents |
Helps You Manage ... |
Described In ... |
---|---|---|---|
Host Manager |
admhostadd.1m admhostdel.1m admhostmod.1m admhostls.1m |
System information and server support for AutoClient and standalone systems, diskless and dataless clients, and JavaStations |
Chapter 6, Managing Server and Client Support With Host Manager |
Group Manager |
admgroupadd.1m admgroupdel.1m admgroupmod.1m admgroupls.1m |
UNIX group information |
Chapter 7, Managing Users With User Manager and Group Manager |
User Manager |
admuseradd.1m admuserdel.1m admusermod.1m admuserls.1m |
User account information |
Chapter 7, Managing Users With User Manager and Group Manager |
Serial Port Manager |
admserialdel.1m admserialmod.1m admserialls.1m |
Serial port software for terminals and modems |
Chapter 8, Managing Terminals and Modems With Serial Port Manager |
Printer Manager |
- none - |
Printer software for print servers and clients |
Chapter 9, Setting Up SunSoft Print Client Software With Printer Manager |
Database Manager |
- none - |
Network-related system files such as aliases and hosts |
Chapter 10, Managing Network Service Files With Database Manager |
Storage Manager (consists of Disk Manager and File System Manager) |
- none - |
Disk slices and fdisk partitions on a single disk or a group of equivalent disks (Disk Manager) and file systems for a server or for a group of clients on a server (File System Manager) |
Chapter 11, Managing Disks and File Systems With Storage Manager |
The Solstice Launcher must be used to start the Solstice AdminSuite tools. Enter the following command to start the Solstice Launcher, which must be run on an X Window System:
$ solstice & |
The Solstice Launcher is displayed.
You can also start the Solstice Launcher by using the -display option to display on a big-mapped remote host running the X Window system.
From the Solstice Launcher, you can:
Click on an icon in the Launcher to start a tool.
You can also use the Tab key to move from icon to icon, and press the Space bar to start a tool.
Close the Launcher (and each tool) to an icon by clicking on the Window menu in the top left corner of each tool's main window.
See Chapter 4, Using the Solstice Launcher, for more information about using the Launcher.
To use the Solstice AdminSuite tools, you must have:
A bit-mapped display monitor. The Solstice AdminSuite tools can be used only on a system where the console is a bit-mapped screen such as a standard display monitor that comes with a Sun® workstation.
If you want to perform administration tasks on a system with an ASCII terminal as the console, use the command-line equivalents of the Solstice AdminSuite tools.
X Window System software, such as the OpenWindows environment.
Root privilege or membership in the sysadmin group (group 14) and the required access privileges for managing the NIS or NIS+ database. See Chapter 2, Using Solstice AdminSuite in a Name Service Environment, for more information.
AdminSuite has some limitations as to what you can or can not do as root; you should use the Solstice AdminSuite tools as a regular user who has membership in the sysadmin group (group 14) rather than as root.
Command |
Enables You To ... |
Described In ... |
---|---|---|
admclientpatch(1m) |
Provide a centralized way to add patches to AutoClient systems and diskless clients. Host Manager then automatically adds the patches when you add an AutoClient system or a diskless client. |
Solstice AutoClient 2.1 Administration Guide |
admtblloc(1m) |
Set a customized name service policy for Host Manager. | |
admhalt(1m) |
Halt one or more remote systems. |
admhalt(1m) man page |
admreboot(1m) |
Reboot one or more remote systems. |
admreboot(1m) man page |
cachefspack |
Provides a way to set up and maintain files in your cache; with this command, you can pack the cache on an AutoClient system. |
cachefspack man page |
filesync |
Record the names of all the files that are to be kept in sync with the filesync command. |
filesync man page |
The Solstice AdminSuite software can be used in different name service environments. When you use each application or AdminSuite command-line equivalent, you must specify the name service environment data you wish to modify.
This is a list of the overview information in this chapter.
Solstice AdminSuite can be used to manage information on the local system or across the network using a name service. The sources of information that can be managed by Solstice AdminSuite are described in Table 2-1.
When using AdminSuite with a name service, you can only modify information found in the local domain. AdminSuite does not support NIS+ or NIS subdomain modifications. If you wish to change entries in NIS or NIS+ in a subdomain, you must log in and run AdminSuite on a system within the subdomain.
Name Service |
Select This Name Service to Manage ... |
---|---|
NIS+ table information. This requires sysadmin group (group 14) membership and the appropriate ownership or permissions on the NIS+ tables to be modified. |
|
NIS map information. You must be a member of the sysadmin group. If the NIS master server is running the Solaris 1.x OS Release, you must have explicit permissions on the NIS master server to update the maps. This means an entry for your host name and user name must reside in root's .rhosts file on the NIS master server. This entry is not required if the NIS master server is running the Solaris 2.x OS Release and the Name Services Transition Kit 1.2 software and Solstice AdminSuite is installed. |
|
None |
The /etc files on the local system. You must be a member of the sysadmin group on the local system. |
See "Setting Up User Permissions to Use Solstice AdminSuite" for information on using Solstice AdminSuite with or without a name service environment.
The Solstice AdminSuite software allows you to select which name service databases will be updated (written to) when you make modifications with one of the tools. However, the /etc/nsswitch.conf file on each system specifies the policy for name service lookups (where data will be read from) on that system.
It is up to the user to make sure that the name service they select from one of the tools is consistent with the specifications in the /etc/nsswitch.conf file. If the selections are not consistent, the tools may behave in unexpected ways, resulting in errors or warnings. See "Selecting a Name Service Environment" for an example of the window from which you select a name service.
The /etc/nsswitch.conf file has no effect on how the system configuration files get updated. In the /etc/nsswitch.conf file, more than one source can be specified for the databases, and complex rules can be used to specify how a lookup can be performed from multiple sources. There is no defined syntax for using the rules in the /etc/nsswitch.conf file to perform updates.
Because of this, updates are controlled by the name service selection that is made when the tools are started. The administrator must decide where the update is to take place.
When using the tools, administrative operations can take place on multiple systems with a single operation. It is possible that each of these systems could have a different /etc/nsswitch.conf configuration. This situation can make it very difficult to administer your network. It is recommended that all of the systems have a consistent set of /etc/nsswitch.conf files and that the Solstice AdminSuite software is used to administer the primary name service specified in the standard /etc/nsswitch.conf file.
With this release of the Solstice AdminSuite product, you can define a more complex update policy for the tools by using the admtblloc command. For more information on this command, refer to the admtblloc(1M) man page and see "The admtblloc Command".
After you start the Solstice Launcher and click on a Solstice application icon, a window is displayed prompting you to select a name service. Select the name service that is appropriate for your environment.
This example is from Host Manager's Load window.
The NIS and NIS+ environments are not available for Serial Port Manager.
The Name Services Transition Kit 1.2 is designed to allow you to support a NIS server running Solaris 2.x. Installing the software and setting up the Solaris 2.x NIS servers is described in the Name Services Transition Kit 1.2 Administrator's Guide. Solstice AdminSuite can manage information using the NIS name service supported by Solaris 2.x NIS servers installed with the Name Services Transition Kit 1.2 software.
On NIS servers installed with the Solaris 2.x OS Release, the Name Service Transition Kit 1.2, and Solstice AdminSuite, the configuration files stored in the /etc directory are modified by Solstice AdminSuite applications (these files are in turn automatically converted to NIS maps). If the NIS server is not installed with Solstice AdminSuite, then the directory location specified by the $DIR variable in the /var/yp/Makefile is used.
To use Solstice AdminSuite, membership in the sysadmin group (group 14) is required. See "Adding Users to the sysadmin Group" for more information.
Following are additional requirements to use Solstice AdminSuite for each name service.
The requirements for using Solstice AdminSuite are:
Membership in the NIS+ admin group.
Modify permissions on the NIS+ tables to be managed. These permissions are usually given to the NIS+ admin group members.
See Solaris Naming Administration Guide for information on adding users to a NIS+ group and granting permissions on NIS+ tables.
The requirements for using Solstice AdminSuite are:
An entry for your host name and user name in root's .rhosts file on the NIS master server if the server is running the Solaris 1.x OS Release. If the NIS master server is running the Solaris 2.x OS Release and Name Services Transition Kit 1.2 software, this entry is not required as long as Solstice AdminSuite is also installed.
Running ypbind with the -broadcast option, which is the default form, if you want to manage NIS map information in domains other than your own.
In order to manager NIS map information in domains other than your own, the other NIS domain masters need to be on directly attached networks.
The following procedure describes how to add users to the sysadmin group using Group Manager, a tool within the Solstice AdminSuite software. To use this tool, you must be already be a member of the sysadmin group and meet the requirements for each name service listed in "Setting Up User Permissions to Use Solstice AdminSuite".
If you do not have access to a user account that is a member of the sysadmin group to run Group Manager, see the procedure to add users to the sysadmin group described in the Solstice AdminSuite 2.3 Installation and Product Notes.
Verify that the prerequisites described in "Requirements for Using Solstice AdminSuite Tools" are met.
Type solstice & in a Shell or Command Tool window.
The Solstice Launcher is displayed.
Click on the Group Manager icon.
Select the name service you wish to modify.
Click on OK.
The Group Manager main window is displayed.
Click on the sysadmin group in the Group Manager main window.
Select Modify from the Edit Menu.
The Modify window is displayed.
Add a comma-separated list of members to the Members List text box.
The list must not contain spaces.
An important part of using the Solstice AdminSuite software is understanding its security features and setting up security policies to protect your administrative data.
This is a list of the step-by-step instructions in this chapter.
Solstice AdminSuite uses the distributed system administration daemon (sadmind) to carry out security tasks when you perform administrative tasks across the network. The sadmind daemon executes the request on the server on behalf of the client process and controls who can access Solstice AdminSuite.
Administering security involves authentication of the user and authorization of permissions.
Authentication means that the sadmind daemon must verify the identity of the user making the request.
Authorization means that sadmind verifies that the authenticated user has permission to execute Solstice AdminSuite on the server. After the user identity is verified, sadmind uses the user identity to perform authorization checks.
If you have permission to use Solstice AdminSuite, you also need to have create, delete, or modify permission before you can change an NIS+ map. See NIS+ and DNS Setup and Configuration Guide for a description of NIS+ security.
User and group identities are used for authorization checking as follows:
Root identity - The root identity has privileges (to access and update data) only on the local system. If the server is the local system (in other words, if the user has logged in as root on the server), the user will be allowed to perform Solstice AdminSuite functions on the server under the root identity.
User who is a member of sysadmin group (group 14) - Solstice AdminSuite permissions are granted to users who are members of the sysadmin group (group 14). This means that a user modifying administration data must be a member of the sysadmin group on the system where the task is being executed.
Each request to change administration data contains a set of credentials with a UID and a set of GIDs to which the user belongs. The server uses these credentials to perform identity and permission checks. Three levels of authentication security are available.
The security levels are described in Table 3-1.
Table 3-1 Solstice AdminSuite Security Levels
Level |
Level Name |
Description |
---|---|---|
0 |
NONE |
No identity checking is done by the server. All UIDs are set to the nobody identity. This level is used mostly for testing. |
1 |
SYS |
The server accepts the original user and group identities from the client system and uses them as the identities for the authorization checks. There is no checking to be sure that the UID of the user represents the same user on the server system. That is, it is assumed the administrator has made the UIDs and GIDs consistent on all systems in the network. Checks are made to see if the user has permission to execute the request. |
2 |
DES |
Credentials are validated using DES authentication, and checks are made to be sure that the user has permission to execute the request. The user and group identities are obtained from files on the server system by mapping the user's DES network identity to a local UID and set of GIDs. The file used depends on which name service is selected on the server system. This level provides the most secure environment for performing administrative tasks and requires that a publickey entry exists for all server systems where the sadmind daemon is running, and for all users accessing the tools. |
Level 1 is the default security used by sadmind.
You can change the security level from Level 1 to Level 2 by editing the /etc/inetd.conf file on each system, and adding the -S 2 option to the sadmind entry. If you do this, make sure that the servers in the domain are set up to use DES security.
You do not need to maintain the same level of security on all systems in the network. You can run some systems, such as file servers requiring strict security, at security Level 2, while running other systems at the default Level 1 security.
See the description of how to set up security for NIS+ in NIS+ and FNS Administration Guide.
The sadmind daemon uses information held by the name service. The three sources of information are:
On each system, the /etc/nsswitch.conf file lists several administrative files, followed by a list of one or more keywords that represent the name services to be searched for information. If more than one keyword is listed, they are searched in the order given. For example, the entry
group: files nisplus |
indicates that the security mechanism looks first in the local /etc/group file for an entry. If the entry exists, the security mechanism uses the information in this entry. If the entry doesn't exist, the NIS+ group file is searched.
By default, systems running the Solaris 2.4 and higher OS release have an entry for group 14 in the local /etc/group file. If you want to set up your system to use network-wide information, do not add members to the sysadmin group on the local system. Instead, update the group14 entry found in the group table stored in the name service.
When running under Level 2 security, the security mechanisms use the public/private key information. Make sure that the entry for publickey is followed by either nis or nisplus (depending on which name service you are using), and remove the files designation. See NIS+ and FNS Administration Guide for more information about the nsswitch.conf file.
Consider the following when creating a security policy for using Solstice AdminSuite in a name service environment.
Determine how much trust is needed.
If your network is secure and you do not need to use authentication security, you can use Solstice AdminSuite applications with the default Level 1 security.
If you need to enforce a higher level of security, you can set the security level of sadmind to Level 2.
Determine which name service will be used.
The name service determines where the security methods get information about user and group identities. The name services are designated in the /etc/nsswitch.conf file (see "Name Service Information").
Decide which users have access to Solstice AdminSuite.
Decide which users will perform administrative functions over the network with Solstice AdminSuite. List these users as members of group 14 accessed by the server system. The group 14 must be accessible from each system where administration data will be updated by Solstice AdminSuite. The group 14 can be established locally on each system or can be used globally within a name service domain, depending upon the policy established by the administrator.
Determine global and local policies.
The global policy affects all hosts in the network. For example, you can add members to group 14 in the NIS or NIS+ group file. Members of this group will have permission to perform administrative tasks on all server systems that list the network name service as the primary source of information. The name services are listed in the /etc/nsswitch.conf file. For more information about the nsswitch.conf file, see "Name Service Information".
A user can establish a local policy that is different from the global policy by creating a group 14 in the local /etc/group file and listing the users who have access to the local system. The members of this group will have permission to manipulate or run Solstice AdminSuite methods on the user's local system.
Setting up a local policy does not disable a global policy. Name service access is determined by the nsswitch.conf file.
Set up permissions for NIS+ management.
You need the proper permissions when using Solstice AdminSuite to modify or update the NIS+ files. In addition to the permissions required by Solstice AdminSuite, the NIS+ security mechanisms impose their own set of access permissions. The NIS+ security mechanisms are described in NIS+ and FNS Administration Guide.
Set up access for NIS management.
If the NIS master server is running the Solaris 1.x operating system, a user must have a .rhosts entry on the NIS master server to modify the NIS files. If the NIS master server is running the Solaris 2.x operating system and the Name Services Transition Kit 1.2, then no entry is required if AdminSuite is already installed. The NIS updates will be authorized using the standard group 14 mechanism.
Creating a Level 2 DES security system requires a number of steps that depend upon your system configuration. The following sections describe how to set up your system to have level 2 DES security for systems using /etc, NIS, and NIS+ name services.
On each system that runs the sadmind daemon, edit the /etc/inetd.conf file.
Change this line (or one similar to this):
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind |
to:
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2 |
On each system that runs the sadmind daemon, set the /etc/nsswitch.conf entry for publickey to files.
Change this entry (or one similar to this):
publickey: nis [NOTFOUND=return] files |
to:
publickey: files |
Create credentials for all group 14 users and all of the systems that will run sadmind -S 2.
Log in as root to one of the systems that will run sadmin -S 2.
Run the following command for each user that will run AdminSuite.
# newkey -u username |
You must run this command even for users who are not in group 14. If you are not in group 14 and do not have credentials, you are not a user according to sadmind; you will not be able to run any methods, even those that do not require root. You will have to supply the user's password to the newkey program.
Run the following command for every host that you have configured to run secure sadmind.
# newkey -h hostname |
You will have to provide the root password for each of these hosts to the newkey program.
Copy the /etc/publickey file on this system to each of the hosts (put this file in /etc/publickey).
This file contains all the credentials for each user and each host.
Do not run newkey on each of the systems. This seems to create a different public/private key pair, and the public key will not be valid across the network. You must create this file on one machine and then copy it to all the others.
As root, enter the following command on each system to put root's private key in /etc/.rootkey.
# keylogin -r |
By doing this, you will not have to keylogin as root on every system every time you want to run admintool; this creates an automatic root keylogin at boot time.
Create an /etc/netid file for each user and each system; put this file on all of the systems.
For each user in the publickey file, create an entry in /etc/netid that looks like the following:
unix.uid@domainname uid: uid: gid,gid, ... |
List every group that this user is a member of; sadmind -S 2 and files look to netid rather than /etc/group to determine group 14 membership.
For each host in the publickey file, create an entry in /etc/netid that looks like the following:
unix.hostname@domainname 0:hostname |
Copy this file to every system in /etc/netid.
Reboot all of the machines.
On each system that you want to run the application on, log in and then keylogin. (You must be a member of group 14.)
After the keylogin, you can safely log out; your key is stored in the keyserv daemon until you explicitly keylogout or the system reboots.
On each system that runs the sadmind daemon, edit the /etc/inetd.conf file.
Change this line (or one similar to this):
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind |
to:
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2 |
On each system that runs the sadmind daemon, set the /etc/nsswitch.conf entry for publickey to nis.
Change this entry (or one similar to this):
publickey: nis [NOTFOUND=return] files |
to:
publickey: nis |
Create credentials for all group 14 users and all of the systems that will run sadmind -S 2.
Log in as root on the NIS server.
Run the following command for each user that will run AdminSuite.
# newkey -u username -s files |
You must run this command even for users who are not in group 14. If you are not in group 14 and do not have credentials, you are not a user according to sadmind; you will not be able to run any methods, even those that do not require root. You will have to supply the user's password to the newkey program.
Run the following command for every host that you have configured to run secure sadmind.
# newkey -h hostname |
You will have to provide the root password for each of these hosts to the newkey program.
Copy the /etc/publickey file on this system to the source file that is specified in /var/yp/Makefile; remake and push the nis maps.
# cd /var/yp; make |
Verify that you are a member of group 14 in the group/nis maps.
Login as root.
Change directories to the source file specified in /var/yp/Makefile.
Manually edit the group file and add yourself to group 14, just as you did in the /etc/group file.
Change directories to /var/yp and run make.
# cd /var/yp; make |
You should see the group map pushed; a message appears indicating that this action has occurred.
The security system looks in the NIS maps for your group 14 access and will fail if you do not have group14 specified there, regardless if your /etc/nsswitch.conf file has group files nis.
When sadmind is running in -S 2 mode, it uses the publickey entry to determine which name service to look at for user credentials. When the entry in /etc/nsswitch.conf is nis, it looks in the nis group map to ensure that the user is a member of group 14.
As root, enter the following command on each system to put root's private key in /etc/.rootkey.
# keylogin -r |
By doing this, you will not have to keylogin as root on every system every time you want to run AdminSuite; this creates an automatic root keylogin at boot time.
To ensure that the nscd gets flushed, reboot all of the workstations.
On each system that you want to the application to run on, log in and then keylogin. (You must be a member of group 14.)
After the keylogin, you can safely log out; your key is stored in the keyserv daemon until you explicitly keylogout or the system reboots.
On each system that runs the sadmind daemon, edit the /etc/inetd.conf file.
Change this line:
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind |
to:
100232/10 tli rpc/udp wait root /usr/sbin/sadmind sadmind -S 2 |
On each system that runs the sadmind daemon, set the /etc/nsswitch.conf entry for publickey to nisplus.
Change this entry (or one similar to this):
publickey: nisplus [NOTFOUND=return] files |
to:
publickey: nisplus |
Log in as root on the NIS+ master server; create credentials for all group 14 users and all of the systems that will run sadmind -S 2.
Log in as root on the NIS+ master server; add all of the users for the AdminSuite to the NIS+ group 14 using the following command.
# nistbladm -m members=username,username...[name=sysadmin],group.org_dir |
The use of this function replaces the current member list with the one that is input; therefore, you must include all members you wish to be a part of group 14.
As root, add all of the users for the AdminSuite to the NIS+ admin group.
# nisgrpadm -a admin username |
Verify that the NIS_GROUP environmental variable is set to admin.
On all the workstations that you intend to run the admintool, enter the following command.
# keylogin -r |
Reboot all of the workstations; verify that the nscd gets flushed.
On each system that you want to the application to run on, log in and then keylogin. (You must be a member of group 14.)
After the keylogin, you can safely log out; your key is stored in the keyserv daemon until you explicitly keylogout or the system reboots.
The Solstice Launcher provides access to the Solstice product family of administration tools. The tools that appear in the Launcher depend on what Solstice products you have installed on your system.
This is a list of the topics and step-by-step instructions in this chapter.
"How to Privately Register an Application in the Solstice Launcher"
"How to Locally Register an Application in the Solstice Launcher"
"How to Globally Register an Application in the Solstice Launcher"
"How to Customize Application Properties in the Solstice Launcher"
"How to Modify Properties of a Locally Registered Application"
Start the Solstice Launcher from a window as follows:
$ solstice & |
The Solstice Launcher is displayed.
The Solstice Launcher menus are described in Table 4-1.
Table 4-1 Solstice Launcher Menus
Use This Menu ... |
To Access This Command ... |
That Performs This Function ... |
---|---|---|
Launcher |
Add Application |
Adds and registers applications with the Launcher. |
|
Properties |
Provides ability to customize the launcher by showing, hiding, or removing applications; reordering the icons; changing the Launcher window width; modifying application properties; adding applications. |
|
Exit |
Stops running the Solstice Launcher. Does not affect open or iconified applications. |
Applications that display in the Solstice Launcher are registered. This means that you can add and remove applications, including custom applications, to and from the Launcher main window.
Applications are registered in three ways:
Private registry - Registered applications are private to the user. Applications are registered privately with the Add Application command from the Launcher menu. See "How to Privately Register an Application in the Solstice Launcher" for instructions on registering applications privately.
Privately registered applications can be added, removed, and their properties can be modified from the Solstice Launcher.
Local registry - Registered applications are local to the system. Applications registered locally are available to all local users of the system. Applications can only be registered locally with the /usr/snadm/bin/soladdapp command. See "How to Locally Register an Application in the Solstice Launcher" for information on using the soladdapp command to register applications locally.
Locally registered applications can only be added or removed using the soladdapp and soldelapp commands. Their properties cannot be modified from the Solstice Launcher.
Global registry - Registered applications are shared by all local and remote users using the Solstice Launcher in a particular /opt directory. Applications can only be registered globally with the /usr/snadm/bin/soladdapp command.
See "How to Globally Register an Application in the Solstice Launcher" for information on using the soladdapp command to register applications globally.
Globally registered applications can only be added or removed using the soladdapp and soldelapp commands. Their properties cannot be modified from the Solstice Launcher.
If the user has a local registry file, and both a local registry and global registry file are in place, then the applications from all files are displayed.
The following procedure describes how to privately register an application in the user's $HOME/.solstice_registry file.
Enter the following application information in the Add Application window.
Identify the application name in the Name text box.
This name is displayed in the Launcher window.
Identify the application path name in the Application Path text box.
If you are not sure of the application path name, click on the ellipsis (...) button, which displays the Application Path Selection window. See "How to Use the File Selection Window" for information on using this window.
Identify any command-line arguments for the application in the Arguments text box.
These arguments are passed to the application when it is started.
Identify the application icon path name in the Icon Path text box.
If you are not sure of the icon path name, click on the ellipsis (...) button, which displays the Application Path Selection window. See "How to Use the File Selection Window" for information on using this window.
Click on Register to add the application.
The following example registers an application called Mail Manager.
Select Properties from the Launcher menu.
The Properties window is displayed.
Select an application from the Hide or Show lists.
Click on the Remove button in the Properties window.
Click on OK.
Become root.
Register an application with the soladdapp command.
# /usr/snadm/bin/soladdapp \ -r /etc/.solstice_registry \ -n "Tool Name" \ -i /opt/pkgname/etc/tool.icon \ -e /opt/pkgname/bin/command args |
In this command,
/usr/snadm/bin/soladdapp |
Is the Solstice command for registering applications. |
-r /etc/.solstice_registry |
Specifies the path name of the Solstice local registry file. |
-n "Tool Name" |
Specifies the name of the tool to be registered. |
-i /opt/pkgname/etc/tool.icon |
Specifies the path name of the tool icon. |
-e /opt/pkgname/bin/command |
Specifies the path name of the tool executable. |
args |
Specifies optional arguments to use with the executable. |
The following example uses the soldaddapp command to locally register an application called Mail Manager.
# /usr/snadm/bin/soladdapp \ -r /etc/.solstice_registry \ -n "Mail Manager" \ -i /opt/SUNWdsk/etc/diskmgr.xpm \ -e /opt/SUNWdsk/bin/diskmgr |
Become root.
Remove an application with the soldelapp command.
# /usr/snadm/bin/soldelapp \ -r /etc/.solstice_registry \ -n "Tool Name" |
In this command,
/usr/snadm/bin/soldelapp |
Is the Solstice command for removing applications from the local registry file. |
-r /etc/.solstice_registry |
Specifies the path name of the Solstice local registry file. |
-n "Tool Name" |
Specifies the name of the tool to be removed. |
The following example uses the soldelapp command to remove an application called Mail Manager.
# /usr/snadm/bin/soldelapp \ -r /etc/.solstice_registry \ -n "Mail Manager" |
Become root.
Register an application with the soladdapp command.
# /usr/snadm/bin/soladdapp \ -r /opt/SUNWadm/etc/.solstice_registry \ -n "Tool Name" \ -i /opt/pkgname/etc/tool.icon \ -e /opt/pkgname/bin/command args |
In this command,
/usr/snadm/bin/soladdapp |
Is the Solstice command for registering applications. |
-r /opt/SUNWadm/etc /.solstice_registry |
Specifies the path name of the Solstice global registry file. |
-n "Tool Name" |
Specifies the name of the tool to be registered. |
-i /opt/pkgname/etc/tool.icon |
Specifies the path name of the tool icon. |
-e /opt/pkgname/bin/command |
Specifies the path name of the tool executable. |
args |
Specifies optional arguments to use with the executable. |
The following example uses the soldaddapp command to globally register an application called Mail Manager.
# /usr/snadm/bin/soladdapp \ -r /opt/SUNWadm/etc/.solstice_registry \ -n "Mail Manager" \ -i /opt/SUNWdsk/etc/diskmgr.xpm \ -e /opt/SUNWdsk/bin/diskmgr |
Become root.
Remove an application with the soldelapp command.
# /usr/snadm/bin/soldelapp \ -r /opt/SUNWadm/etc/.solstice_registry \ -n "Tool Name" |
In this command,
/usr/snadm/bin/soldelapp |
Is the Solstice command for removing applications from the global registry file. |
-r /opt/SUNWadm/etc/ .solstice_registry |
Specifies the path name of the Solstice global registry file. |
-n "Tool Name" |
Specifies the name of the tool to be removed. |
The following example uses the soldelapp command to remove an application called Mail Manager.
# /usr/snadm/bin/soldelapp \ -r /opt/SUNWadm/etc/.solstice_registry \ -n "Mail Manager" |
Select Properties from the Launcher menu.
The Properties window is displayed.
To disable or enable the display of applications in the Launcher window, use the Hide/Show buttons.
To hide an application, select an application from the Show list and click on the Hide button.
The application is moved to the Hide list.
To show an application, select an application from the Hide list and click on the Show button.
The application is moved to the Show list.
Click on OK when you are finished moving applications to and from the Show and Hide lists.
To remove an application from a local registry file, use the Remove button.
See "How to Remove a Privately Registered Application" for information on removing a locally registered application.
To add an application to the Launcher window, click on the Add Application button.
The Add Application window is displayed. This window is equivalent to the Add Application command from the Launcher menu.
See "How to Privately Register an Application in the Solstice Launcher" for information on adding applications to the Launcher.
If you select an application from the Hide or Show lists and click on the Application Properties button, the Application Properties window is displayed.
See "How to Modify Properties of a Locally Registered Application" for information on modifying the properties of a locally registered application.
Change how the tool icons are displayed in the Launcher window.
If you increase the number of icons to be wider than the width of the Launcher window, use the scrollbar at the bottom of the Launcher to view any icons that moved off the window.
Click on OK.
The following example shows that Database Manager has been moved to the Hide list. This means it will not be displayed in the Solstice Launcher.
Locally registered applications can be customized in the following ways:
Applications can be hidden or redisplayed by using the Hide/Show feature.
The number of columns in the Launcher window can be expanded and contracted, which affects how the applications are displayed.
The application icons can be moved up or down to change the order in which the application icons are displayed.
See "How to Customize Application Properties in the Solstice Launcher" for more information on customizing applications.
Select Properties from the Launcher menu.
The Properties window is displayed.
Select an application from the Hide or Show lists.
Click on the Application Properties button.
Modify the following application properties:
The application name in the Name text box.
The application name must be changed in order for any application properties changes to be successful.
The application path name in the Application Path text box.
If you are not sure of the application path name, click on the ellipsis (...) button, which displays the Application Path Selection window. See "How to Use the File Selection Window" for information on using this window.
Any command-line arguments to the application in the Arguments text box.
These arguments are passed to the application when it is started.
The icon path name in the Icon Path text box.
If you are not sure of the icon path name, click on the ellipsis (...) button, which displays the Application Path Selection window. See "How to Use the File Selection Window" for information on using this window.
Click on Register.
The following example provides an alternative executable and icon for Host Manager.
Use the Filter text box in the Application Path Selection window to specify a path name using a regular expression, such as the wildcard character (*).
When a new value is entered, the Directories and File lists are updated appropriately.
Select a file name from the Files list to update the Open File text box.
Click on OK to place the Open File text box value into the field from which the File Selection window was invoked.
The application file name is displayed in the Application Path text box in the Application window.
The following example of the Application Path Selection window uses a filter to search the /opt/SUNWadm/2.3/bin directory for application tool executables, which are displayed under the Files list.