Ref : System Administration Guide : Basic administration (Part No : 817-1985-17 April 2008)

Working With Solaris Management Console (Tasks)

p42 Start the console as yourself

Launch --> Application --> Utilities --> Terminal

% /usr/sadm/bin/smc &

Roles + Users

p48 Management Scope

refers to name service environment that you want to use with selected management tool.

--> /etc/nsswitch.conf File

file on each system specifies the policy for name service lookups (where data is read from ) on
that system.

p48 How to Create Toolbox for a Specific Environment

Applications for administrating the Solaris OS is called Tools. Stored collection --> Toolboxes

Launch --> Application --> Utilities --> Terminal

% /usr/sadm/bin/smc edit &

Stop/Start/Status the console Server

# /etc/init.d/init.whem stop

# /etc/init.d/init.whem start

# /etc/init.d/init.whem status

p57 What is Java Web Console

https://hostname.domain:6789

e.g. https://172.0.0.1:6789 or https://gwwpcSOLARIS:6789

P61 Run Web Application

https://gwwpcSOLARIS:6789/zfs/zfsmodule/index

--List of deployed web applications --> wcadmin list -a

Managing the Console Service

Java Web Console managed Service Management Facility (SMF)

Start Console Service --> #smcwebserver start
Enable Console Service at System Start --> #smcwebserver enable

# svcadm enable system/webconsole:console

Stop Console Service --> #smcwebserver stop

Status Console Service --> #smcwebserver status
Disable Server --> #smcwebserver disable

Configuring Java Web Console

How to Change Java Web Console Properties

wcadmin command to change properties

---console session timeout

# wcadmin add -p -a console session.timeout.value=5

---Logging level
# wcadmin add -p -a console logging.default.level=all
#wcadmin remove -p -a console logging.default.level

console log files --> /var/log/webconsole/console

syslog log file --> /var/adm/mesaages
log --> /var/log/webconsole/console/console_debug_log --> writtendebug service
enabled

---Auditing Implementation
# wcadmin add -p -a console audit.default.type=None

Java Web Console User Identity

Web console runs under identity, noaccess

Some sites disable it....

Result, web server console cannot be started so alternative user used.

#smcwebserver start -u Username

#wcadmin add -p -a console com.sun.web.console.user=username

Using the Console Debug Trace Log

1-Severe errors
2-Important messages + 1
3-all possible messages with full message

#wcadmin add -p -a console debug.trace.level=3

or
#smreg add -p -c debug.trace.level=3

--Check Status Debug level

#wcadmin list -p | grep "debug.trace.level"
or
#smreg list -p | grep "debug.trace.level"

Troubleshooting the Java Web Console (Task Map)

1.Check Server status --> # smcwebserver status
2.Check console status --> # svcs -l system/websonsole:console
3.List console resources --> # wcadmin list or # smreg list

Problems with Application Registration

1.View application app.xml

--located in WEB-INF directory

2.List deployed applications

# wcadmin list -a or #smreg list -a

How to Register a Legacy Application with Java Web Console

1.Stop server --> # smcwebserver stop

2.Register Application --> # smreg add -a /directory/containing/application-files
3.Start server --> # smcwebserver start

legacy application files located --> /usr/share/webconsole/example

Registering a Legacy Application

1.Stop server --> # smcwebserver stop

2.Register Application --> # smreg add -a /usr/share/webconsole/example
3.Start server --> # smcwebserver start

Unregister Legacy Application

1.Unregister --> # smreg remove -a app-name

Unregistering Legacy Application From Java Web Console

1.Unregister --> # smreg remove -a com.sun.web.admin.example

How to Register a Current Application With the Java Web Console

1.Register/Deploy --> wcadmin deploy -a app-name -x app-context-name/full

path/to/app-name

--> wcadmin deploy -a newexample_1.0 -x newexample

/apps/webconsole/newexample

2.Unregister --> wcadmin undeploy -a newexample_1.0 -x newexample

Java Web Console Reference Information

Several security considerations need to be aware of.

-->Access Java Web Console

-->Access to Applications
-->Application Permissions

Access Java Web Console

Restrict access to console by using authTypes Tag app.xml file

--> /usr/share/webconsole/webapps/console/WEB-INF

Some systems are very secure, remote access denied

https://hostname.domain:6789, brower displays

Connect to hostname.domain:6789 failed (connection refused)

Using SMF profile

Access to Applications in Java Web Console

Restrict access application, specify rights authTypes Tag app.xml file

/usr/share/webconsole/webapps/app-context-name/WEB-INF

Application files not found : Use

wcadmin list --detail -a

Application Prilvileges

If u can see applications link on Java Web Console, u can run it.

Web Console detemines if user authorized to seee a application, based on authorization

requirements in app.xml.

see p82 tags.

Enabling Remote Acces to Java Web Console

Set property to allow console server to respond to network requests and restart console server

# svccfg -s svc:/system/webconsole setprop options/tcp_listen = false

# smcwebserver restart

Cannot use proxy in browser

Changing Internal Passwords for Java Web Console

Change admin password --> # wcadmin password -a

Change key store password --> # wcadmin password -k
Change trust store password --> # wcadmin password -t

Managing User Accounts and Groups

User Account Components

User (Login) Names - let users access their systems

User ID Numbers - Associated with each user is UID

0 - 99 - Solaris OS
100 - 2147483647 - Regular Users
60001 - 65534 - nobody and nobody4
60002 - noaccess

UNIX group - collection of users GID

User Password

2 files important - Password length (/etc/default/passwd file)

PASSLENGTH set 6

- Increase length /etc/policy.conf

Home Directories (User)

- /export/homen/name where n=1,2,3,

- always /export/home/name
- $HOME

Name Services - Managing User accounts LDAP, NIS or NIS+

Users Work Environment (User)

- Need environment gives them access to

tools and resources
- When user logs on system, determined by
initialization files. Defined by users tartup shell,
c or korn or borne shell

- best solution
custom user initialization files (.login, .cshrc,
.profile) user $HOME

Fields in the passwd File

username:password:uid:gid:comment:home-directory:login-shell

e.g.#

kryten:x:101:100:Kryten Series 4000 Mechanoid:/export/home/kryten:/bin/csh

Default passwd File

The default Solaris passwd file contains entries for standard daemons.Daemons are
processes
that are usually started at boot time to perform some system-wide task, such as
printing,
network administration, or port monitoring.
root:x:0:1:Super-User:/:/sbin/sh
daemon:x:1:1::/:
bin:x:2:2::/usr/bin:
sys:x:3:3::/:
adm:x:4:4:Admin:/var/adm:
lp:x:71:8:Line Printer Admin:/usr/spool/lp:
uucp:x:5:5:uucp Admin:/usr/lib/uucp:
nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uucico
smmsp:x:25:25:SendMail Message Submission Program:/:
listen:x:37:4:Network Admin:/usr/net/nls:
gdm:x:50:50:GDM Reserved UID:/:
webservd:x:80:80:WebServer Reserved UID:/:
nobody:x:60001:60001:NFS Anonymous Access User:/:
noaccess:x:60002:60002:No Access User:/:
nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/:

TABLE 4–5 Default passwd File Entries

User Name User ID Description
root 0 Superuser account
daemon 1 Umbrella system daemon associated with routine system
tasks
bin 2 Administrative daemon associated with running system
binaries to perform some routine system task
sys 3 Administrative daemon associated with system logging
or updating files in temporary directories
adm 4 Administrative daemon associated with system logging
lp 71 Line printer daemon
uucp 5 Daemon associated with uucp functions
nuucp 6 Another daemon associated with uucp functions
smmsp 25 Sendmail message submission program daemon
webservd 80 Account reserved for WebServer access
gdm 50 GNOME DisplayManager daemon

listen 37 Network listener daemon

nobody 60001 Account reserved for anonymous NFS access.
noaccess 60002 Assigned to a user or a process that needs access to a
system through some application but without actually
logging in.
nobody4 65534 SunOS 4.0 or 4.1 version of the nobody user account

Fields in the Shadow File

The fields in the shadow file are separated by colons and contain the following
information:
username:password:lastchg:min:max:warn:inactive:expire
For example:
rimmer:86Kg/MNT/dGu.:8882:0::5:20:8978

Fields in the group File

The fields in the group file are separated by colons and contain the following
information:
group-name:group-password:gid:user-list
For example:
bin::2:root,bin,daemon

Default group File

The default Solaris group file contains the following system groups that support some
system-wide task, such as printing, network administration, or electronic mail.Many
of these
groups having corresponding entries in the passwd file.

root::0:
other::1:
bin::2:root,daemon
sys::3:root,bin,adm
adm::4:root,daemon
uucp::5:root
mail::6:root
tty::7:root,adm
lp::8:root,adm
nuucp::9:root
staff::10:
daemon::12:root
smmsp::25:
sysadmin::14:
gdm::50:
webservd::80:
nobody::60001:
noaccess::60002:
nogroup::65534:

TABLE 4–6 Default group File Entries

Group Name Group ID Description
root 0 Superuser group
other 1 Optional group
bin 2 Administrative group associated with running system
binaries
sys 3 Administrative group associated with system logging or
temporary directories
adm 4 Administrative group associated with system logging
uucp 5 Group associated with uucp functions
mail 6 Electronic mail group
tty 7 Group associated with tty devices
lp 8 Line printer group
nuucp 9 Group associated with uucp functions
staff 10 General administrative group.
daemon 12 Group associated with routine system tasks
sysadmin 14 Administrative group associated with legacy Admintool
and Solstice AdminSuite tools
smmsp 25 Daemon for Sendmail message submission program
webservd 80 Group reserved for WebServer acces
gdm 50 Group reserved for theGNOME DisplayManager
daemon
nobody 60001 Group assigned for anonymous NFS access
noaccess 60002 Group assigned to a user or a process that needs access
to
a system through some application but without actually
logging in
nogroup 65534 Group assigned to a user who is not a member of
a
known group

ManagingUsers and ResourcesWith Projects

users and groups can be members of a project, an identifier

that indicates a workload component that can be used as the basis of system usage
or resource
allocation chargeback. Projects are part of the Solaris resource management feature
that is used
to manage system resource

Users need to be a member of a project to successfully log in to a system running the

Solaris 9
release. By default, users are a member of the group.staff project when the Solaris 9
release is
installed and no other project information is configured.

User project information is stored in the /etc/project file, which can be stored on the
local
system (files), the NIS name service, or the LDAP directory service. You can use the
Solaris
Management Console to manage project information.

The /etc/project file must exist for users to log in successfully, but requires no
administration
if you are not using projects

Customizing a User'sWork Environment

TABLE 4–14 User Initialization Files for Bourne, C, and Korn Shells
Shell User Initialization File Purpose
Bourne $HOME/.profile Defines the user's environment at login
C $HOME/.cshrc Defines the user's environment for all C shells and is
invoked after login shell
$HOME/.login Defines the user's environment at login
Korn $HOME/.profile Defines the user's environment at login
$HOME/$ENV Defines user's environment at login in the file and is
specified by the Korn shell's ENV environment variable

The Solaris environment provides default user initialization files for each shell in the
/etc/skel
directory on each system, as shown in the following table.
TABLE 4–15 Default User Initialization Files
Shell Default File
C /etc/skel/local.login
/etc/skel/local.cshrc
Bourne or Korn /etc/skel/local.profile

You can use these files as a starting point and modify them to create a standard set
of files that
provide the work environment common to all users. Or, you can modify these files to
provide
the working environment for different types of users.

Although you cannot create customized user initialization files with the Users tool,
you can populate a user's home directory with user initialization files located in a
specified “skeleton” directory.
You can do this by creating a user template with the User Templates tool and
specifying a skeleton directory from which to copy user initialization files.

When you use the Users tool to create a new user account and select the create
home directory
option, the following files are created, depending on which login shell is selected.

TABLE 4–16 Files Created by Users Tool WhenAdding a User

Shell Files Created
C The /etc/skel/local.cshrc and the /etc/skel/local.login files are
copied
into the user's home directory and are renamed .cshrc and .login,
respectively.
Bourne and Korn The /etc/skel/local.profile file is copied into the user's
home directory
and renamed .profile.
If you use the useradd command to add a new user account and specify the /etc/skel
directory by using the -k and -m options

-->all three /etc/skel/local* files and the

/etc/skel/.profile file are copied into the user's home directory.

At this point, you need to rename them to whatever is appropriate for the user's login
shell

Using Site Initialization Files

The user initialization files can be customized by both the administrator and the user.

This important feature can be accomplished with centrally located and globally
distributed user
initialization files, called site initialization files.

Site initialization files enable you to continually introduce new functionality to the
user's work environment, while enabling the user to customize the user's initialization
file.

To reference a site initialization file in a C-shell user initialization file, place a line
similar to the
following at the beginning of the user initialization file:

source /net/machine-name/export/site-files/site-init-file

To reference a site initialization file in a Bourne-shell or Korn-shell user initialization

file, place
a line similar to the following at the beginning of the user initialization file:

. /net/machine-name/export/site-files/site-init-file

Avoiding Local SystemReferences

You should not add specific references to the local system in the user initialization
file.

To make a user's home directory available anywhere on the network, always refer to
the
home directory with the variable $HOME. For example, use $HOME/bin instead of
/export/home/username/bin. The $HOME variable works when the user logs in to
another
system and the home directories are automounted.

To access files on a local disk, use global path names, such as

/net/system-name/directory-name. Any directory referenced by /net/system-name
can be
mounted automatically on any system on which the user logs in, assuming the
system is
running AutoFS.
Shell Features
The following table lists basic shell features that each shell provides, which can help
you
determine what you can and can't do when creating user initialization files for each
shell.
TABLE 4–17 Basic Features of Bourne, C, and Korn Shells
Feature

Bourne

Korn
Known as the standard shell in UNIX Applicable N/A N/A
Compatible syntax with Bourne shell - N/A Applicable
Job control Applicable Applicable Applicable
History list N/A Applicable Applicable
Command-line editing N/A Applicable Applicable
Aliases N/A Applicable Applicable
Single-character abbreviation for login
directory
N/A Applicable Applicable
Protection from overwriting (noclobber) N/A Applicable Applicable
Setting to ignore Control-D (ignoreeof) N/A Applicable Applicable
Enhanced cd command N/A Applicable Applicable
Initialization file separate from .profile N/A Applicable Applicable
Logout file N/A Applicable N/A

A shell maintains an environment that includes a set of variables defined by

the login program, the system initialization file, and the user initialization
files. In addition, some variables are defined by default.*******************

shell can have two types of variables

Environment variables – Variables that are exported to all processes spawned by

the shell.
Their settings can be seen with the env command. A subset of environment
variables, such
as PATH, affects the behavior of the shell itself.

■Shell (local) variables – Variables that affect only the current shell. In the C shell,
a set of
these shell variables have a special relationship to a corresponding set of
environment
variables. These shell variables are user, term, home, and path. The value of the
environment
variable counterpart is initially used to set the shell variable.

In the C shell,
lowercase names with the set command to set shell variables
uppercase names with the setenv command to set environment variables
set a shell variable, the shell sets the corresponding environment variable

In Bourne and Korn shells,

use the uppercase variable name equal to some value to set both shell and
environment variables.
use the export command to activate the variables for any subsequently executed
commands.

All Shells
refer to shell and environment variables by their uppercase names

user initialization file, you can customize a user's shell environment by changing the
values

ShellType Line to Add to the User Initialization File

C shell setenv VARIABLE value
Example:
setenv MAIL /var/mail/ripley
Bourne or Korn shell VARIABLE=value; export VARIABLE
Example:
MAIL=/var/mail/ripley;export MAIL

The following table describes environment variables and shell variables that you
might want to
customize in a user initialization file

Shell and Environment VariableDescriptions

Variable Description
CDPATH, or cdpath in
the C shell
Sets a variable used by the cd command. If the target directory of the cd
command is
specified as a relative path name, the cd command first looks for the target
directory
in the current directory (“.”). If the target is not found, the path names
listed in the
CDPATH variable are searched consecutively until the target directory is
found and the
directory change is completed. If the target directory is not found, the
current
working directory is left unmodified. For example, the CDPATH variable is
set to
/home/jean, and two directories exist under /home/jean, bin, and rje. If you
are in
the /home/jean/bin directory and type cd rje, you change directories to
/home/jean/rje, even though you do not specify a full path.
history Sets the history for the C shell.
HOME, or home in the C
shell
Sets the path to the user's home directory.
LANG Sets the locale.
LOGNAME Defines the name of the user currently logged in. The default value of
LOGNAME is set
automatically by the login program to the user name specified in the
passwd file. You
should only need to refer to, not reset, this variable.
LPDEST Sets the user's default printer.
MAIL Sets the path to the user's mailbox.
MANPATH Sets the hierarchies of man pages that are available

PATH, or path in the C

shell
Specifies, in order, the directories that the shell searches to find the
program to run
 when the user types a command. If the directory is not in the search path,
users must
type the complete path name of a command.
As part of the login process, the default PATH is automatically defined and
set as
specified in .profile (Bourne or Korn shell) or .cshrc (C shell).
The order of the search path is important. When identical commands exist
in
different locations, the first command found with that name is used. For
example,
suppose that PATH is defined in Bourne and Korn shell syntax as
PATH=/bin:/usr/bin:/usr/sbin:$HOME/bin and a file named sample resides in
both /usr/bin and /home/jean/bin. If the user types the command sample
without
specifying its full path name, the version found in /usr/bin is used.
prompt Defines the shell prompt for the C shell.
PS1 Defines the shell prompt for the Bourne or Korn shell.

SHELL, or shell in the C

shell
Sets the default shell used by make, vi, and other tools.
TERMINFO Specifies the path name for an unsupported terminal that has been added
to the
terminfo file. Use the TERMINFO variable in either the /etc/profile or
/etc/.login
file.
When the TERMINFO environment variable is set, the system first checks
the TERMINFO
path defined by the user. If the system does not find a definition for a
terminal in the
TERMINFO directory defined by the user, it searches the default directory,
/usr/share/lib/terminfo, for a definition. If the system does not find a
definition
in either location, the terminal is identified as “dumb.”
TERM, or term in the C
shell
Defines the terminal. This variable should be reset in either the /etc/profile
or
/etc/.login file. When the user invokes an editor, the system looks for a file
with
the same name that is defined in this environment variable. The system
searches the
directory referenced by TERMINFO to determine the terminal
characteristics.
TZ Sets the time zone. The time zone is used to display dates, for example,
in the ls -l
command. If TZ is not set in the user's environment, the system setting is
used.
Otherwise, GreenwichMean Time is used.

The PATH Variable

When the user executes a command by using the full path, the shell uses that path to
find the
command

when users specify only a command name, the shell searches the directories for the
command in the order specified by the PATH variable. If the command is found in one
of the directories, the shell executes the command

A default path is set by the system.

However, most users modify it to add other command directories.

Setting aUser's Default Path

This is an example of how to set a user's default path.

The following examples show how to set a user's default path to include the home
directory and
other NFS mounted directories. The current working directory is specified first in the
path. In a
C-shell user initialization file, you would add the following:

set path=(. /usr/bin $HOME/bin /net/glrr/files1/bin)

In a Bourne-shell or Korn-shell user initialization file, you would add the following:

PATH=.:/usr/bin:/$HOME/bin:/net/glrr/files1/bin
export PATH

LocaleVariables

Values for LANG and LC Variables

Value Locale
en_US.UTF-8 American English (UTF-8)

EXAMPLE 4–1 Setting the Locale Using the LANG Variables

The following examples show how to set the locale by using the LANG environment
variables. In
a C-shell user initialization file, you would add the following:

setenv LANG de_DE.ISO8859-1

In a Bourne-shell or Korn-shell user initialization file, you would add the following:

LANG=de_DE.ISO8859-1; export LANG

Default File Permissions (umask)

When you create a file or directory, the default file permissions assigned to the file or
directory
are controlled by the user mask. The user mask is set by the umask command in a
user
initialization file. You can display the current value of the user mask by typing umask
and
pressing Return.

■ The first digit sets permissions for the user

■ The second digit sets permissions for group
■ The third digit sets permissions for other, also referred to as world

Note that if the first digit is zero, it is not displayed. For example, if the user mask is
set to 022, 22
is displayed.
To determine the umask value you want to set, subtract the value of the permissions
you want
from 666 (for a file) or 777 (for a directory). The remainder is the value to use with
the umask
command. For example, suppose you want to change the default mode for files to
644
(rw-r--r--). The difference between 666 and 644 is 022, which is the value you would
use as an
argument to the umask command.

You can also determine the umask value you want to set by using the following table.
This table
shows the file and directory permissions that are created for each of the octal values
of umask.

umask OctalValue File Permissions Directory Permissions

0 rw- rwx
1 rw- rw-
2 r-- r-x
3 r-- r--
4 -w- -wx
5 -w- -w-
6 --x --x
7 --- (none) --- (none)