openwsmand(8) openwsmand(8) NAME openwsmand - WS-Management Server SYNOPSIS openwsmand [OPTIONS] DESCRIPTION The openwsmand command is used to start the openwsman daemon service. The Openwsman project is intended to provide an open-source implementa tion of the Web Services Management specification (WS-Management) and to expose system management information using the WS-Management proto col. 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. 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 pro cess. Configuring Openwsman service Openwsman uses an ini style configuration file for all components (server, client and plugins). Currently, the following options are sup ported Server The example below shows a typical server configuration. [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 Authentication and Password Files The password files for BASIC and DIGEST can be created with the htpasswd and htdigest utilities. Both utilities usually come with Apache packages. 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. Authentication Plugins Authentication plug-ins support only Basic authentication. DIGEST authentication support is only available using a password file created with htdigest or similar utilities. Plain Text Plugins Is the default plug-in used in Openwsman and provides access to a password file generated with htpasswd or similar utilities. 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: #%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 On Solaris, this could be done by the administrator by adding below contents in to the PAM configuration file /etc/pam.conf 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 Client [client] port = 5985 agent = openwsman 0.3.2 CIM Plugin 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_Comput erSystem (valid) and http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/Linux_Com puterSystem (invalid) and both would work. 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 some thing up, the list of namespaces I have as an example: 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 So the above Linux_ComputerSystem resource URI should actually be: http://sblim.sf.net/wbem/wscim/1/cim-schema/2/Linux_Computer System [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 Service Management Framework (SMF) openwsmand openwsmand service is by default disabled and it is managed by the service management facility, smf(5), under the service identi fier: 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 Adminis tration" 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 autho rizations 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 services status can be queried using the svcs(1) command OPTIONS openwsmand command recognizes the following options: -?, --help Print the help message. -S, --ssl Use SSL port -d, --debug Start daemon in foreground and turn on debugging -s, --syslog=0-6 Set the verbosity of syslog output. -e, --enum-idle-timeout Enumeration Idle timeout in msecs (default = 100000) -c, --config-file= Alternate configuration file (default is /etc/openws man/openwsman.conf) -p, --pid-file= PID file -r, --subscription-repository-location= Subscription Repository Location ATTRIBUTES See attributes(5) for descriptions of the following attributes: +--------------------+-----------------+ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | +--------------------+-----------------+ |Availability | SUNWopenwsmanu | +--------------------+-----------------+ |Interface Stability | Uncommitted | +--------------------+-----------------+ NOTES Source for Openwsman is available on http://opensolaris.org. openwsmand(8)