Part I Solstice AdminSuite Overview

This part provides an overview of the Solstice AdminSuite software and contains these chapters.

Chapter 1, Introduction

Introduction provides brief descriptions of all the software included with the Solstice AdminSuite product.

Chapter 2, Using Solstice AdminSuite in a Name Service Environment

Using solstice AdminSuite in a Name Service Environment provides information on how to use the Solstice AdminSuite software in a name service environment.

Chapter 3, Security

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.

Chapter 4, Using the Solstice Launcher

Using the Solstice Launcher provides instructions on how to start the Solstice Launcher and add applications to the Solstice Launcher.

Chapter 1 Introduction

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.

• "What's New in the Solstice AdminSuite 2.3 Product"

• "When to Use Solstice AdminSuite"

• "When to Use Solstice AdminSuite"

• "Benefits of Solstice AdminSuite"

• "Solstice AdminSuite Tools and Their Command-Line Equivalents"

• "Other Solstice AdminSuite Commands"

What's New in the Solstice AdminSuite 2.3 Product

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.

• JavaStation^TM 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.

• CacheFS^TM 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.

  ---

  Note -

  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.

When to Use Solstice AdminSuite

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.

Benefits of Solstice AdminSuite

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.

Solstice AdminSuite Tools and Their Command-Line Equivalents

Table 1-1 lists the Solstice AdminSuite tools that must be run under an X Window System^TM, such as the OpenWindows^TM 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.

Starting the Solstice AdminSuite Tools

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.

Requirements for Using Solstice AdminSuite Tools

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.

  ---

  Note -

  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.

  ---

Other Solstice AdminSuite Commands

Chapter 2 Using Solstice AdminSuite in a Name Service Environment

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.

• "Available Name Service Environments"

• "The /etc/nsswitch.conf File and the Solstice AdminSuite Product"

• "Selecting a Name Service Environment"

• "Working with the Name Services Transition Kit 1.2"

• "Setting Up User Permissions to Use Solstice AdminSuite"

• "Adding Users to the sysadmin Group"

Available Name Service Environments

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.

See "Setting Up User Permissions to Use Solstice AdminSuite" for information on using Solstice AdminSuite with or without a name service environment.

The /etc/nsswitch.conf File and the Solstice AdminSuite Product

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".

Selecting a Name Service Environment

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.

Working with the Name Services Transition Kit 1.2

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.

Setting Up User Permissions to Use Solstice AdminSuite

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.

User Permissions in the NIS+ Environment

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.

User Permissions in the NIS Environment

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.

Adding Users to the sysadmin Group

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.

How to Add a User to the sysadmin Group

1. Verify that the prerequisites described in "Requirements for Using Solstice AdminSuite Tools" are met.

2. Type solstice & in a Shell or Command Tool window.

   The Solstice Launcher is displayed.

3. Click on the Group Manager icon.

   The Group Manager Load window is displayed.

4. Select the name service you wish to modify.

5. Click on OK.

   The Group Manager main window is displayed.

6. Click on the sysadmin group in the Group Manager main window.

7. Select Modify from the Edit Menu.

   The Modify window is displayed.

8. Add a comma-separated list of members to the Members List text box.

   The list must not contain spaces.

9. Click on OK.

Chapter 3 Security

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.

• "Security Information"

• "Things to Consider When Creating a Security Policy"

• "Creating a Level 2 DES Security System"

Security Information

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.

Security Levels

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.

Level 1 is the default security used by sadmind.

Changing the Security Level

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.

Name Service Information

The sadmind daemon uses information held by the name service. The three sources of information are:

• Files in the /etc directory such as passwd, group, and shadow, referred to as the keyword files

• The NIS name service referred to as the keyword nis

• The NIS+ name service referred to as the keyword nisplus

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.

Things to Consider When Creating a Security Policy

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

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.

How to Create Level 2 DES Security for Systems Using /etc Name Service

1. 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

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

3. Create credentials for all group 14 users and all of the systems that will run sadmind -S 2.

   1. Log in as root to one of the systems that will run sadmin -S 2.

   2. Run the following command for each user that will run AdminSuite.

      # newkey -u username

      ---

      Note -

      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.

      ---

   3. 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.

   4. 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.

      ---

      Note -

      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.

      ---

   5. 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.

4. Create an /etc/netid file for each user and each system; put this file on all of the systems.

   1. 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, ...

   2. 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.

   3. For each host in the publickey file, create an entry in /etc/netid that looks like the following:

      unix.hostname@domainname 0:hostname

   4. Copy this file to every system in /etc/netid.

5. Reboot all of the machines.

6. 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.

How to Create Level 2 DES Security for Systems Using NIS Name Service

1. 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

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

3. Create credentials for all group 14 users and all of the systems that will run sadmind -S 2.

   1. Log in as root on the NIS server.

   2. Run the following command for each user that will run AdminSuite.

      # newkey -u username -s files

      ---

      Note -

      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.

      ---

   3. 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.

   4. 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

4. Verify that you are a member of group 14 in the group/nis maps.

   1. Login as root.

   2. Change directories to the source file specified in /var/yp/Makefile.

   3. Manually edit the group file and add yourself to group 14, just as you did in the /etc/group file.

   4. 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.

      ---

      Note -

      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.

5. 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.

6. To ensure that the nscd gets flushed, reboot all of the workstations.

7. 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.

How to Create Level 2 DES Security for Systems Using NIS+ Name Service

1. 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

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

3. 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.

   1. Create local credentials for the user.

      # nisaddcred -p uid username.domainname. local

   2. Create des credentials for the user.

      # nisaddcred -p unix.uid@domainname -P username.domainname. des

4. 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

   ---

   Note -

   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.

   ---

5. 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.

6. On all the workstations that you intend to run the admintool, enter the following command.

   # keylogin -r

7. Reboot all of the workstations; verify that the nscd gets flushed.

8. 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.

Chapter 4 Using the Solstice Launcher

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.

• "Starting the Solstice Launcher"

• "How to Privately Register an Application in the Solstice Launcher"

• "How to Remove a Privately Registered Application"

• "How to Locally Register an Application in the Solstice Launcher"

• "How to Remove a Locally Registered Application"

• "How to Globally Register an Application in the Solstice Launcher"

• "How to Remove a Globally Registered Application"

• "How to Customize Application Properties in the Solstice Launcher"

• "How to Modify Properties of a Locally Registered Application"

• "How to Use the File Selection Window"

Starting the Solstice Launcher

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.

Registering Applications in the Solstice Launcher

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.

How to Privately Register an Application in the Solstice Launcher

The following procedure describes how to privately register an application in the user's $HOME/.solstice_registry file.

1. Select Add Application from the Launcher menu.

2. Enter the following application information in the Add Application window.

   1. Identify the application name in the Name text box.

      This name is displayed in the Launcher window.

   2. 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.

   3. Identify any command-line arguments for the application in the Arguments text box.

      These arguments are passed to the application when it is started.

   4. 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.

3. Click on Register to add the application.

Example of Registering a Private Application in the Solstice Launcher

The following example registers an application called Mail Manager.

How to Remove a Privately Registered Application

1. Select Properties from the Launcher menu.

   The Properties window is displayed.

2. Select an application from the Hide or Show lists.

3. Click on the Remove button in the Properties window.

4. Click on OK.

How to Locally Register an Application in the Solstice Launcher

1. Become root.

2. 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.

Example of Registering a Local Application in the Solstice Launcher

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

How to Remove a Locally Registered Application

1. Become root.

2. 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.

Example of Removing a Locally Registered Application

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"

How to Globally Register an Application in the Solstice Launcher

1. Become root.

2. 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.

Example of Registering a Global Application in the Solstice Launcher

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

How to Remove a Globally Registered Application

1. Become root.

2. 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.

Example of Removing a Globally Registered Application

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"

Customizing the Solstice Launcher

How to Customize Application Properties in the Solstice Launcher

1. Select Properties from the Launcher menu.

   The Properties window is displayed.

2. To disable or enable the display of applications in the Launcher window, use the Hide/Show buttons.

   1. 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.

   2. 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.

   3. Click on OK when you are finished moving applications to and from the Show and Hide lists.

3. 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.

4. 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.

5. 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.

6. Change how the tool icons are displayed in the Launcher window.

   1. Select an application in the Show list and click on the Up or Down arrow under Icon Order to change the location of an icon.

   2. Use the up/down arrows under Launcher Width to indicate the number of columns that will display in the Launcher window.

7. 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.

8. Click on OK.

Example of Customizing Application Properties in the Solstice Launcher

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.

Customizing Locally Registered Applications 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.

How to Modify Properties of a Locally Registered Application

1. Select Properties from the Launcher menu.

   The Properties window is displayed.

2. Select an application from the Hide or Show lists.

3. Click on the Application Properties button.

   The Application Properties window is displayed.

4. Modify the following application properties:

   1. The application name in the Name text box.

      ---

      Note -

      The application name must be changed in order for any application properties changes to be successful.

      ---

   2. 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.

   3. Any command-line arguments to the application in the Arguments text box.

      These arguments are passed to the application when it is started.

   4. 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.

5. Click on Register.

Example of Modifying Properties of a Locally Registered Application

The following example provides an alternative executable and icon for Host Manager.

How to Use the File Selection Window

1. 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.

2. Select a file name from the Files list to update the Open File text box.

3. 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.

Example of Using the File Selection 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.