usr/src/cmd/openwsman/openwsmand.8
author Cyril Plisko <cyril.plisko@grigale.com>
Tue, 06 Apr 2010 16:00:14 +0300
changeset 11 87960ed158f9
parent 0 b34509ac961f
permissions -rw-r--r--
Import sfw build 137 Bugs Fixed ---------- 6926835 Wireshark cannot open files typed into the location bar 6930214 CVE-2010-0624: Heap-based buffer overflow in GNU Tar 6933424 Various sfw manual pages need to be adjusted to use the new OpenSolaris package names. 6937764 upgrade OpenSSL to 0.9.8n (and fix CVE-2010-0740)

'\" t
.\"
.\" CDDL HEADER START
.\"
.\" The contents of this file are subject to the terms of the
.\" Common Development and Distribution License (the "License").
.\" You may not use this file except in compliance with the License.
.\"
.\" You can obtain a copy of the license at usr/src/OPENSOLARIS.LICENSE
.\" or http://www.opensolaris.org/os/licensing.
.\" See the License for the specific language governing permissions
.\" and limitations under the License.
.\"
.\" When distributing Covered Code, include this CDDL HEADER in each
.\" file and include the License file at usr/src/OPENSOLARIS.LICENSE.
.\" If applicable, add the following below this CDDL HEADER, with the
.\" fields enclosed by brackets "[]" replaced with your own identifying
.\" information: Portions Copyright [yyyy] [name of copyright owner]
.\"
.\" CDDL HEADER END
.\"
.\" Copyright 2010 Sun Microsystems, Inc.  All rights reserved.
.\" Use is subject to license terms.
.\"
.\" ident	"@(#)openwsmand.8	1.2	10/03/16 SMI"
.\"
.\" Man page for openwsmand
.TH "openwsmand" "8" "" "" "" 
.SH "NAME"
.B openwsmand
\- WS-Management Server
.SH "SYNOPSIS"
.B openwsmand
[OPTIONS] 

.SH "DESCRIPTION"
.P
The 
.B openwsmand
command is used to start the openwsman daemon service. The Openwsman project is intended 
to provide an open-source implementation of the Web Services Management specification 
(WS-Management) and to expose system management information using the WS-Management protocol. 
WS-Management is based on a suite of web services specifications and usage requirements that 
exposes a set of operations focused on and covers all system management aspects.
.P
.B openwsmand
service can be started only by a privileged user. However a normal user can invoke with debug option
to run it as a foreground process.
.P
.SS Configuring Openwsman service
Openwsman uses an ini style configuration file for all components (server, client and plugins). Currently, the following options are supported
.P
.B Server
   The example below shows a typical server configuration.
.PP
.RS
.nf
[server]
port = 5985
#ssl_port = 5986
ssl_cert_file = /etc/openwsman/servercert.pem
ssl_key_file = /etc/openwsman/serverkey.pem
digest_password_file = /etc/openwsman/digest_auth.passwd
basic_password_file = /etc/openwsman/simple_auth.passwd
min_threads = 1
max_threads = 4
#use_digest is OBSOLETED, see below.
#
# Authentication backend for BASIC authentication. Default is to 
# read a configuration file defined with 'basic_password_file'
#
#basic_authenticator = libwsman_pam_auth.so
#basic_authenticator_arg = openwsman
.fi
.RE

.B Authentication and Password Files
.PP
.RS
The password files for BASIC and DIGEST can be created with the htpasswd and htdigest utilities. Both utilities usually come with Apache packages.
.PP
The realm for openwsman has to be OPENWSMAN. An example password file for DIGEST with one entry:

   wsman:OPENWSMAN:5a659df1ac36d2f4eb84092145532919

Administrator has to make sure that one of these password files for basic or digest authentication has registered user entries as shown above. If both password files for basic and digest authentication are defined then both methods will be offered by the service. The client will automatically connect using the strongest authentication method.
.RE

.B Authentication Plugins
.PP
.RS
Authentication plug-ins support only Basic authentication. DIGEST authentication support is only available using a password file created with htdigest or similar utilities.

.B Plain Text Plugins

Is the default plug-in used in Openwsman and provides access to a password file generated with htpasswd or similar utilities.

.B PAM Plugin

To activate PAM authentication, enable the PAM authentication plug-in the openwsman configuration file and provide the name of the PAM service. The PAM service name which is used by default is 'openwsman'. After the openwsman configuration file is edited, the operating system specific PAM service configuration has to be made. 

On Linux, this could be done by the administrator by adding a PAM configuration file in the /etc/pam.d directory having the following contents:

/etc/pam.d/openwsman:

.nf
#%PAM-1.0
auth       required     pam_unix2.so    nullok
auth       required     pam_nologin.so
account    required     pam_unix2.so
password   required     pam_pwcheck.so  nullok
password   required     pam_unix2.so    nullok use_first_pass use_authtok
session    required     pam_unix2.so    none
.fi

On Solaris, this could be done by the administrator by adding below contents in to the PAM configuration file /etc/pam.conf

.nf
openwsman   auth    required        pam_unix_cred.so.1
openwsman   auth    required        pam_unix_auth.so.1
openwsman   account requisite       pam_roles.so.1
openwsman   account required        pam_unix_account.so.1
openwsman   session required        pam_unix_session.so.1
.fi
.RE

.B Client 
.PP
.RS
.nf
[client]
port = 5985
agent = openwsman 0.3.2
.fi
.RE

.B CIM Plugin
.PP
.RS
Until recently, the namespace in the resource URI (the part of the url before the class name) was very flexible. You could request something like that:
  http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ComputerSystem (valid) and 

  http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem (invalid)
.nf

and both would work.
.fi
.PP
Now this does not work anymore. For CIM base classes you should use the DMTF namespace, for others you can specify the namespace in the configuration file. Depending on your CIM providers there might be no CIM/WSMan namespace available, so you can make something up, the list of namespaces I have as an example:
.PP
.nf
  vendor_namespaces =
  OpenWBEM=http://schema.openwbem.org/wbem/wscim/1/cim-schema/2,
  Linux=http://sblim.sf.net/wbem/wscim/1/cim-schema/2,
  OMC=http://schema.omc-project.org/wbem/wscim/1/cim-schema/2,
  REEF=http:///reef.sblim.sf.net/wbem/wscim/1/cim-schema/2,
  CWS=http:///cws.sblim.sf.net/wbem/wscim/1/cim-schema/2
.fi

So the above Linux_ComputerSystem resource URI should actually be:

  http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_ComputerSystem

.nf
  [cim]
  default_cim_namespace = root/cimv2
  # The following are in part fake namespaces for some publicly 
  # available CIM implementations.
  vendor_namespaces = OpenWBEM=http://schema.openwbem.org/wbem/wscim/1/cim-schema/2,
  Linux=http://sblim.sf.net/wbem/wscim/1/cim-schema/2,
  OMC=http://schema.omc-project.org/wbem/wscim/1/cim-schema/2 
.fi
.RE

.SH "Service Management Framework (SMF)"
.B openwsmand
openwsmand service is by default disabled and it is managed by the service management facility, smf(5), under the service identifier:

   svc:/network/openwsmand

Administrative actions on this service,  such  as  enabling, disabling,  or  refreshing,  can be performed using svcadm(1M). 

  1) To start the openwsmand service
          example% svcadm enable network/openwsmand

  2) To disable or stop the openwsmand service
          example% svcadm disable network/openwsmand

By default only root user will be able to perform the administrative actions. However otherwise non-privileged user can be authorized to perform administrative actions through RBAC(5).

For example, to let a user 'wsman' change openwsmand value properties and manage openwsmand service states, assign "Openwsman Server Administration" Rights Profile to the user. This can be done by adding the following line to /etc/user_attr:

   wsman::::profiles=Openwsman Server Administration

Specific authorizations either to manage the service or change the value properties can also be assigned to the user by assigning either solaris.smf.manage.openwsmand or solaris.smf.value.openwsmand authorizations respectively to the user in /etc/user_attr.

For example, to authorize a user 'wsman1' to only manage the service state and not change the value properties, add the following line to /etc/user_attr:

   wsman1::::auths=solaris.smf.manage.openwsmand

The service's status can be queried  using  the svcs(1) command


.SH "OPTIONS"
.B openwsmand
command recognizes the following options:
.RS
.TP
.B -?, --help
Print the help message.
.TP
.B -S, --ssl
Use SSL port
.TP
.B -d, --debug
Start daemon in foreground and turn on debugging
.TP
.B -s, --syslog=0-6
Set the verbosity of syslog output.
.TP
.B -e, --enum-idle-timeout 
Enumeration Idle timeout in msecs (default = 100000)
.TP
.B -c, --config-file=<file>
Alternate configuration file (default is /etc/openwsman/openwsman.conf)
.TP
.B -p, --pid-file=<file>
PID file
.TP
.B -r, --subscription-repository-location=<uri>
Subscription Repository Location
.RE

'\" t
.\"
.\" Modified for Solaris to add the Solaris stability classification,
.\" and to add a note about source availability.
.\"
.\" Begin Sun update
.SH ATTRIBUTES
See
.BR attributes (5)
for descriptions of the following attributes:
.sp
.TS
box;
cbp-1 | cbp-1
l | l .
ATTRIBUTE TYPE	ATTRIBUTE VALUE
=
Availability	system/management/web/openwsman
=
Interface Stability	Uncommitted
.TE
.PP
.SH NOTES
Source for Openwsman is available on http://opensolaris.org.
.\" End Sun update