JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Sun ZFS Storage 7000 System Administration Guide
search filter icon
search icon

Document Information

Preface

1.  Introduction

2.  Status

3.  Configuration

4.  Services

Services

Introduction

Data

Directory

System

Remote Access

BUI

Selecting a Service

Enabling a Service

Disabling a Service

Setting Properties

Viewing Service Logs

CLI

Selecting a Service

Viewing Service State

Enabling a Service

Disabling a Service

Setting Properties

Viewing Service Logs

Service Help

NFS

Introduction

Properties

Kerberos realms

Logs

Analytics

CLI

Tasks

NFS Tasks

iSCSI

Introduction

Properties

Authentication

Authorization

Targets and Initiators

CLI

Tips

Troubleshooting

SMB

Introduction

Properties

Share Properties

NFS/SMB Interoperability

DFS Namespaces

Autohome Rules

Local Groups

MMC Integration

Event Viewer

Share Management

Users, Groups and Connections

Services

CLI

Adding autohome rules

Adding a user to a local group

Tasks

SMB Tasks

FTP

Introduction

Properties

FTP Properties

General Settings

Security Settings

Logs

Tasks

FTP Tasks

HTTP

Introduction

Properties

Authentication and Access Control

Logs

Tasks

HTTP Tasks

NDMP

Introduction

Local vs. Remote Configurations

Backup Formats and Types

Backing up with "dump" and "tar"

Backing up with "zfs"

Incremental backups

Properties

Logs

SFTP

Introduction

Properties

SFTP Port

Logs

Tasks

SFTP Tasks

Virus Scan

Introduction

Properties

File Extensions

Scanning Engines

Logs

Tasks

Virus Scan Tasks

NIS

Introduction

Properties

Logs

Tasks

NIS Tasks

LDAP

Introduction

Properties

Custom Mappings

Logs

Tasks

LDAP Tasks

Active Directory

Introduction

Properties

Join Domain

Join Workgroup

Domains and Workgroups

LDAP Signing

Windows Server 2008 Support

Section A: Kerberos issue (KB951191)

Section B: NTLMv2 issue (KB957441)

Section C: Note on NTLMv2

BUI

CLI

Tasks

Active Directory Tasks

Identity Mapping

Concepts

Identity Mapping Concepts

Mapping Modes

IDMU

Directory-based Mapping

Identity Mapping Directory-based Mapping

Properties

Name-based Mapping

Identity Mapping Name-based Mapping

Name-based Mapping Rules

Case Sensitivity

Mapping Persistence

Domain-Wide Rules

Deny Mappings

Mapping Rule Directional Symbols

Ephemeral Mapping

Best Practices

Testing Mappings

Examples

Tasks

Identity Mapping Tasks

DNS

Introduction

Properties

CLI

Logs

Active Directory and DNS

Non-DNS Resolution

DNS-Less Operation

IPMP

Introduction

Properties

Logs

Tasks

NTP

Introduction

Properties

Validation

Authentication

BUI

CLI

BUI Clock

Tips

Tasks

NTP Tasks

Remote Replication

Introduction

Dynamic Routing

RIP and RIPng Dynamic Routing Protocols

Logs

Phone Home

Introduction

Sun Online Account

Properties

Web Proxy

Registration

Status

Service state

Logs

SNMP

Introduction

Properties

MIBs

Sun FM MIB

Sun AK MIB

Tasks

SNMP Tasks

SMTP

Introduction

Properties

Logs

Service Tags

Introduction

Properties

System Identity

Introduction

Properties

Logs

SSH

Introduction

Properties

Logs

Tasks

SSH Tasks

Shadow Migration

Introduction

Properties

Managing Shadow Migration

Syslog

Introduction

Properties

Classic Syslog: RFC 3164

Updated Syslog: RFC 5424

Message Format

Alert Message Format

Receiver Configuration Examples

Configuring a Solaris Receiver

Configuring a Linux Receiver

5.  Shares

6.  Analytics

7.  Application Integration

Glossary

Index

Syslog

Introduction

The Syslog Relay service provides two different functions on the appliance:

A syslog message is a small event message transmitted from the appliance to one or more remote systems (or as we like to call it: intercontinental printf). The message contains the following elements:

Syslog receivers are provided with most operating systems, including Solaris and Linux. A number of third-party and open-source management software packages also support Syslog. Syslog receivers allow administrators to aggregate messages from a number of systems on to a single management system and incorporated into a single set of log files.

The Syslog Relay can be configured to use the "classic" output format described by RFC 3164, or the newer, versioned output format described by RFC 5424. Syslog messages are transmitted as UDP datagrams. Therefore they are subject to being dropped by the network, or may not be sent at all if the sending system is low on memory or the network is sufficiently congested. Administrators should therefore assume that in complex failure scenarios in a network some messages may be missing and were dropped.

Properties

Property
Description
Protocol Version
The version of the Syslog protocol to use, either Classic or Modern
Destinations
The list of destination IPv4 and IPv6 addresses to which messages are relayed.

Changing services properties is documented in the BUI and CLI sections of services. The CLI property names are shorter versions of those listed above. After changing properties, restart the Syslog service.

Classic Syslog: RFC 3164

The Classic Syslog protocol includes the facility and level values encoded as a single integer priority, the timestamp, a hostname, a tag, and the message body.

The tag will be one of the tags described below.

The hostname will be the canonical name of the appliance as defined by the System Identity configuration.

Updated Syslog: RFC 5424

The Classic Syslog protocol includes the facility and level values encoded as a single integer priority, a version field (1), the timestamp, a hostname, a app-name, and the message body. Syslog messages relayed by the Sun Storage systems will set the RFC 5424 procid, msgid, and structured-data fields to the nil value (-) to indicate that these fields do not contain any data.

The app-name will be one of the tags described below.

The hostname will be the canonical name of the appliance as defined by the System Identity configuration.

Message Format

The Syslog protocol itself does not define the format of the message payload, leaving it up to the sender to include any kind of structured data or unstructured human-readable string that is appropriate. Sun Storage appliances use the syslog subsystem tag ak to indicate a structured, parseable message payload, described next. Other subsystem tags indicate arbitrary human-readable text, but administrators should consider these string forms unstable and subject to change without notice or removal in future releases of the Sun Storage software.

Facility
Tag Name
Description
daemon
ak
Generic tag for appliance subsystems. All alerts will be tagged ak, indicating a SUNW-MSG-ID follows.
daemon
idmap
Identity Mapping service for POSIX and Windows identity conversion.
daemon
smbd
SMB Data Protocol for accessing shares.
Alert Message Format

If an alert is configured with the Send Syslog Message action, it will produce a syslog message payload containing localized text consisting of the following standard fields. Each field will be prefixed with the field name in CAPITAL letters followed by a colon and whitespace character.

Field Name
Description
SUNW-MSG-ID
The stable Sun Fault Message Identifier associated with the alert. Each system condition and fault diagnosis that produces an administrator alert is assigned a persistent, unique identifier in Sun's Fault Message catalog. These identifiers can be easily read over the phone or scribbled down in your notebook, and link to a corresponding knowledge article found at sun.com/msg/.
TYPE
The type of condition. This will be one of the labels: Fault, indicating a hardware component or connector failure; Defect indicating a software defect or misconfiguration; Alert, indicating a condition not associated with a fault or defect, such as the completion of a backup activity or remote replication.
VER
The version of this encoding format itself. This description corresponds to version "1" of the SUNW-MSG-ID format. If a "1" is present in the VER field, parsing code may assume that all of the subsequent fields will be present. Parsing code should be written to handle or ignore additional fields if a decimal integer greater than one is specified.
SEVERITY
The severity of the condition associated with the problem that triggered the alert. The list of severities is shown below.
EVENT-TIME
The time corresponding to this event. The time will be in the form "Day Mon DD HH:MM:SS YYYY" in UTC. For example: Fri Aug 14 21:34:22 2009.
PLATFORM
The platform identifier for the appliance. This field is for Sun Service use only.
CSN
The chassis serial number of the appliance.
HOSTNAME
The canonical name of the appliance as defined by the System Identity configuration.
SOURCE
The subsystem within the appliance software that emitted the event. This field is for Sun Service use only.
REV
The internal revision of the subsystem. This field is for Sun Service use only.
EVENT-ID
The Universally Unique Identifier (UUID) associated with this event. Sun's Fault Management system associates a UUID with each alert and fault diagnosis such that administrators can gather and correlated multiple messages associated with a single condition, and detect duplicate messages. Sun Service personnel can use the EVENT-ID to retrieve additional postmortem information associated with the problem that may help Sun respond to the issue.
DESC
Description of the condition associated with the event.
AUTO-RESPONSE
The automated response to the problem, if any, by the Fault Management software included in the system. Automated responses include capabilities such as proactively offlining faulty disks, DRAM memory chips, and processor cores.
REC-ACTION
The recommended service action. This will include a brief summary of the recommended action, but administrators should consult the knowledge article and this documentation for information on the complete repair procedure.

The SEVERITY field will be set to one of the following values:

Sun Severity
Syslog Level
Description
Minor
LOG_WARNING
A condition occurred that does not currently impair service, but the condition needs to be corrected before it becomes more severe.
Major
LOG_ERR
A condition occurred that does impair service but not seriously.
Critical
LOG_CRIT
A condition occurred that seriously impairs service and requires immediate correction.

Receiver Configuration Examples

Most operating systems include a syslog receiver, but some configuration steps may be required to turn it on. Some examples for common operating systems are shown below. Consult the documentation for your operating system or management software for specific details of syslog receiver configuration.

Configuring a Solaris Receiver

Solaris includes a bundled syslogd(1M) that can act as a syslog receiver, but the remote receive capability is disabled by default. To enable Solaris to receive syslog traffic, use svccfg and svcadm to modify the syslog settings as follows:

# svccfg -s system/system-log setprop config/log_from_remote = true
# svcadm refresh system/system-log

Solaris syslogd only understands the Classic Syslog protocol. Refer to the Solaris syslog.conf(4) man page for information on how to configure filtering and logging of the received messages.

By default, Solaris syslogd records messages to /var/adm/messages and a test alert would be recorded as follows:

Aug 14 21:34:22 poptart.sf.fishpong.com poptart ak: SUNW-MSG-ID: AK-8000-LM, \
TYPE: alert, VER: 1, SEVERITY: Minor\nEVENT-TIME: Fri Aug 14 21:34:22 2009\n\
PLATFORM: i86pc, CSN: 12345678, HOSTNAME: poptart\n\
SOURCE: jsui.359, REV: 1.0\n\
EVENT-ID: 92dfeb39-6e15-e2d5-a7d9-dc3e221becea\n\
DESC: A test alert has been posted.\n\
AUTO-RESPONSE: None.\nIMPACT: None.\nREC-ACTION: None.
Configuring a Linux Receiver

Most Linux distributions include a bundled sysklogd(8) daemon that can act as a syslog receiver, but the remote receive capability is disabled by default. To enable Linux to receive syslog traffic, edit the /etc/sysconfig/syslog configuration file such that the -r option is included (enables remote logging):

SYSLOGD_OPTIONS="-r -m 0"

and then restart the logging service:

# /etc/init.d/syslog stop
# /etc/init.d/syslog start

Some Linux distributions have an ipfilter packet filter that will reject syslog UDP packets by default, and the filter must be modified to permit them. On these distributions, use a command similar to the following to add an INPUT rule to accept syslog UDP packets:

# iptables -I INPUT 1 -p udp --sport 514 --dport 514 -j ACCEPT

By default, Linux syslogd records messages to /var/log/messages and a test alert would be recorded as follows:

Aug 12 22:03:15 192.168.1.105 poptart ak: SUNW-MSG-ID: AK-8000-LM, \
TYPE: alert, VER: 1, SEVERITY: Minor EVENT-TIME: Wed Aug 12 22:03:14 2009 \
PLATFORM: i86pc, CSN: 12345678, HOSTNAME: poptart SOURCE: jsui.3775, REV: 1.0 \
EVENT-ID: 9d40db07-8078-4b21-e64e-86e5cac90912 \
DESC: A test alert has been posted. AUTO-RESPONSE: None. IMPACT: None. \
REC-ACTION: None.