Name

smc– start the Solaris Management Console

Synopsis

smc [ subcommand] [ args]

smc [ subcommand] [ args] -T tool_name 
     [ - - tool_args]

Description

The smc command starts the Solaris Management Console. The Solaris Management Console is a graphical user interface that provides access to Solaris system administration tools. It relies on Solaris Management Console servers running on one or more computers to perform modifications and report data. Each of these servers is a repository for code which the console can retrieve after the user of the console has authenticated himself or herself to the server.

The console can also retrieve toolboxes from the server. These toolboxes are descriptions of organized collections of tools available on that and possibly other servers. Once one of these toolboxes is loaded, the console will display it and the tools referenced in it.

The console can also run in a terminal (non-graphically), for use over remote connections or non-interactively from a script.

For information on the use of the graphical console, and for more detailed explanations of authentication, tools, and toolboxes, please refer to the Solaris Management Console online help available under the “Help” menu in the Solaris Management Console. To enable an NIS map to be managed from the Solaris Management Console, you must use the smc edit command to create a new toolbox for that map and enter the information about your NIS server where necessary. For instructions on creating a new toolbox, in the Solaris Management Console Help menu, select “Contents,” then “About the Solaris Management Console Editor,” then “To Create a Toolbox.”

Subcommands

The smc subcommands are:

open

The default subcommand for the Solaris Management Console is open. This will launch the console and allow you to run tools from the toolboxes you load. It does not need to be specified explicitly on the command line.

edit

The edit subcommand will also launch the console, like the open subcommand. However, after loading a toolbox, you will not be able to run the referenced tools. Instead, you will be able to edit that toolbox, that is, add, remove, or modify any tools or folders in that toolbox.

SMF Administration

The Solaris Management Console is implemented as a method that is managed by the service management facility (SMF) (see smf(5)), under the fault management resource identifier (FMRI):

svc:/application/management/wbem:default

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

The configuration properties of this service can be modified with svccfg(1M).

Through svcadm, the Solaris Management Console supports the following actions:

start

Starts the CIM Object Manager (CIMOM) and Solaris Management Console server on the local host.

stop

Stops the CIMOM and Solaris Management Console server on the local host.

status

Gets the status of the CIMOM and Solaris Management Console server on the local host.

Controlling Remote Access

The Solaris Management Console supports an SMF property that controls remote access to WBEM-based applications, which include the Solaris Management Console. The property, options/tcp_listen, has default value of false, which disallows remote access. The value true allows remote access. See EXAMPLES.

Options

The following options are supported. These letter options can also be specified by their equivalent option words preceded by a double dash. For example, you can use either -D or - -domain with the domain argument.

If tool_args are specified, they must be preceded by the - - option and separated from the double dashes by a space.

- -auth-data 13;file

Specifies a file which the console can read to collect authentication data. When running the Solaris Management Console non-interactively, the console will still need to authenticate itself with the server to retrieve tools. This data can either be passed on the command line using the -u, -p, -r, and -l options (which is insecure, because any user can see this data), or it can be placed in a file for the console to read. For security reasons, this file should be readable only by the user running the console, although the console does not enforce this restriction.

The format of file is:

hostname=host name username=user name password=password for user name rolename=role name rolepassword=password for role name

Only one set of hostname-username-password-rolename-rolepassword may be specified in any one file. If the rolename is not specified, no role will be assumed.

-B | - -toolbox 13;toolbox

Loads the specified toolbox. toolbox can be either a fully-qualified URL or a filename. If you specify an HTTP URL as, for example,

http://host_name:port/. . .

it must point to a host_name and port on which an Solaris Management Console server is running. If you omit port, the default port, 898, is used. This option overrides the -H option.

-D | - -domain 13;domain

Specifies the default domain that you want to manage. The syntax of domain is type:/host_name/domain_name, where type is nis, dns, ldap, or file; host_name is the name of the machine that serves the domain; and domain_name is the name of the domain you want to manage. This option applies only to a single tool run in the terminal console.

If you do not specify this option, the Solaris Management Console assumes the file default domain on whatever server you choose to manage, meaning that changes are local to the server. Toolboxes can change the domain on a tool-by-tool basis; this option specifies the domain for all other tools.

-h | - -help

Prints a usage statement about the smc command and its subcommands to the terminal window. To print a usage statement for one of the subcommands, enter -h after the subcommand.

-H | - -hostname 13;host_name:port

Specifies the host_name and port to which you want to connect. If you do not specify a port, the system connects to the default port, 898. If you do not specify host_name:port, the Solaris Management Console connects to the local host on port 898. You may still have to choose a toolbox to load into the console. To override this behavior, use the -B option (see above), or set your console preferences to load a “home toolbox” by default.

-Jjava_option

Specifies an option that can be passed directly to the Java runtime (see java(1). Do not enter a space between -J and the argument. This option is most useful for developers.

-l | - -rolepassword 13;role_password

Specifies the password for the role_name. If you specify a role_name but do not specify a role_password, the system prompts you to supply a role_password. Passwords specified on the command line can be seen by any user on the system, hence this option is considered insecure.

-p | - -password 13;password

Specifies the password for the user_name. If you do not specify a password, the system prompts you for one. Passwords specified on the command line can be seen by any user on the system, hence this option is considered insecure.

-r | - -rolename 13;role_name

Specifies a role name for authentication. If you are running the Solaris Management Console in a terminal and you do not specify this option, no role is assumed. The GUI console may prompt you for a role name, although you may not need to assume a role.

-s | - -silent

Disables informational messages printed to the terminal.

-t

Runs the Solaris Management Console in terminal mode. If this option is not given, the Solaris Management Console will automatically run in terminal mode if it cannot find a graphical display.

- -trust

Trusts all downloaded code implicitly. Use this option when running the terminal console non-interactively and you cannot let the console wait for user input.

-T | - -tool 13;tool_name

Runs the tool with the Java class name that corresponds to tool_name. If you do not specify this option and the Solaris Management Console is running in terminal mode, the system prompts you. If the Solaris Management Console is running in graphical mode, the system either loads a toolbox or prompts you for one (see options -H and -B).

-u | - -username 13;user_name

Specifies the user name for authentication. If you do not specify this option, the user identity running the console process is assumed.

-v | - -version

Prints the version of the Solaris Management Console to the terminal. In the graphical console, this information can be found in the About box, available from the Help menu.

-y | - -yes

Answers yes to all yes/no questions. Use this option when running the terminal console non-interactively and you cannot let the console wait for user input.

Examples

---

Example 1 Printing a Usage Statement




The following prints a usage statement about the smc command to the terminal window:

smc --help

---

---

Example 2 Using SMF Property to Allow Remote Access




The following sequence of commands allows remote access to WBEM-based applications, including the Solaris Management Console.

# svccfg -s svc:/application/management/wbem \ setprop options/tcp_listen = true # svcadm refresh svc:/application/management/wbem

---

---

Example 3 Passing an Option to Java




The following passes an option through to the Java VM, which sets the com.example.boolean system property to true. This system property is only an example; the Solaris Management Console does not use it.

smc -J-Dcom.example.boolean=true

---

Environment Variables

See environ(5) for a description of the following environment variable that affects the execution of the smc command:

JAVA_HOME

If you do not specify this environment variable, your PATH is searched for a suitable java. Otherwise, the /usr/j2se location is used.

Exit Status

The following exit values are returned. Other error codes may be returned if you specify a tool (using -T tool_name) that has its own error codes. See the documentation for the appropriate tool.

0

Successful completion.

1

An error occurred.

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWmcc

See Also

auths(1), java(1), profiles(1), roles(1), smcconf(1M), svcadm(1M), svccfg(1M), attributes(5), environ(5), smf(5), X(7)

http://dlc.sun.com/zip/47.16.zip

SCSA를 준비하기 위한 EBook

출처 : Sun Microsystems

Name

svc.startd– Service Management Facility master restarter

Synopsis

/lib/svc/bin/svc.startd 

svc:/system/svc/restarter:default 

Description

svc.startd is the master restarter daemon for Service Management Facility (SMF) and the default restarter for all services. svc.startd starts, stops, and restarts services based on administrative requests, system failures, or application failures.

svc.startd maintains service state, as well as being responsible for managing faults in accordance with the dependencies of each service.

svc.startd is invoked automatically during system startup. It is restarted if any failures occur. svc.startd should never be invoked directly.

See smf_restarter(5) for information on configuration and behavior common to all restarters.

svcs(1) reports status for all services managed by the Service Configuration Facility. svcadm(1M) allows manipulation of service instances with respect to the service's restarter.

Environment Variables

Environment variables with the “SMF_” prefix are reserved and may be overwritten.

svc.startd supplies the “SMF_” environment variables specified in smf_method(5) to the method. PATH is set to “/usr/sbin:/usr/bin” by default. By default, all other environment variables supplied to svc.startd are those inherited from init(1M).

Duplicate entries are reduced to a single entry. The value used is undefined. Environment entries that are not prefixed with “<name>=” are ignored.

Restarter Options

svc.startd is not configured by command line options. Instead, configuration is read from the service configuration repository. You can use svccfg(1M) to set all options and properties.

The following configuration variables in the options property group are available to developers and administrators:

boot_messages

An astring (as defined in scf_value_is_type; see scf_value_create(3SCF)) that describes the default level of messages to print to the console during boot. The supported message options include quiet and verbose. The quiet option prints minimal messages to console during boot. The verbose option prints a single message per service started to indicate success or failure. You can use the boot -m option to override the boot_messages setting at boot time. See kernel(1M).

logging

Control the level of global service logging for svc.startd. An astring (as defined in scf_value_is_type; see scf_value_create(3SCF)) that describes the default level of messages to log to syslog (see syslog(3C) and svc.startd's global logfile, /var/svc/log/svc.startd.log. The supported message options include quiet, verbose, and debug. The quiet option sends error messages requiring administrative intervention to the console, syslog and svc.startd's global logfile. The verbose option sends error messages requiring administrative intervention to the console, syslog and svc.startd's global logfile, and information about errors which do not require administrative intervention to svc.startd's global logfile. A single message per service started is also sent to the console. The debug option sends svc.startd debug messages to svc.startd's global logfile, error messages requiring administrative intervention to the console, syslog and svc.startd's global logfile, and a single message per service started to the console.

milestone

An FMRI which determines the milestone used as the default boot level. Acceptable options include only the major milestones:

svc:/milestone/single-user:default svc:/milestone/multi-user:default svc:/milestone/multi-user-server:default

or the special values all or none. all represents an idealized milestone that depends on every service. none is a special milestone where no services are running apart from the master svc:/system/svc/restarter:default. By default, svc.startd uses all, a synthetic milestone that depends on every service. If this property is specified, it overrides any initdefault setting in inittab(4).

system/reconfigure

Indicates that a reconfiguration reboot has been requested. Services with actions that must key off of a reconfiguration reboot may check that this property exists and is set to 1 to confirm a reconfiguration boot has been requested.

This property is managed by svc.startd and should not be modified by the administrator.

Configuration errors, such as disabling svc.startd are logged by syslog, but ignored.

SERVICE STATES

Services managed by svc.startd can appear in any of the states described in smf(5). The state definitions are unmodified by this restarter.

SERVICE REPORTING

In addition to any logging done by the managed service, svc.startd provides a common set of service reporting and logging mechanisms.

Reporting properties svc.startd updates a common set of properties on all services it manages. These properties are a common interface that can be used to take action based on service instance health. The svcs(1) command can be used to easily display these properties.

restarter/state
restarter/next_state

The current and next (if currently in transition) state for an instance.

restarter/auxiliary_state

A caption detailing additional information about the current instance state. The auxiliary state available for services managed by svc.startd is:

maintenance

fault_threshold_reached stop_method_failed administrative_request

restarter/state_timestamp

The time when the current state was reached.

restarter/contract

The primary process contract ID, if any, that under which the service instance is executing.

Logs

By default, svc.startd provides logging of significant restarter actions for the service as well as method standard output and standard error file descriptors to /var/svc/log/service:instance.log. The level of logging to system global locations like /var/svc/log/svc.startd.log and syslog is controlled by the options/logging property.

SERVICE DEFINITION

When developing or configuring a service managed by svc.startd, a common set of properties are used to affect the interaction between the service instance and the restarter.

Methods

The general form of methods for the fork/exec model provided by svc.startd are presented in smf_method(5). The following methods are supported as required or optional by services managed by svc.startd.

refresh

Reload any appropriate configuration parameters from the repository or config file, without interrupting service. This is often implemented using SIGHUP for system daemons. If the service is unable to recognize configuration changes without a restart, no refresh method is provided.

This method is optional.

start

Start the service. Return success only after the application is available to consumers. Fail if a conflicting instance is already running, or if the service is unable to start.

This method is required.

stop

Stop the service. In some cases, the stop method can be invoked when some or all of the service has already been stopped. Only return an error if the service is not entirely stopped on method return.

This method is required.

If the service does not need to take any action in a required method, it must specify the :true token for that method.

svc.startd honors any method context specified for the service or any specific method. The method expansion tokens described in smf_method(5) are available for use in all methods invoked by svc.startd.

Properties

An overview of the general properties is available in smf(5). The specific way in which these general properties interacts with svc.startd follows:

general/enabled

If enabled is set to true, the restarter attempts to start the service once all its dependencies are satisfied. If set to false, the service remains in the disabled state, not running.

general/restarter

If this FMRI property is empty or set to svc:/system/svc/restarter:default, the service is managed by svc.startd. Otherwise, the restarter specified is responsible (once it is available) for managing the service.

general/single_instance

If single_instance is set to true, svc.startd only allows one instance of this service to transition to online or degraded at any time.

Additionally, svc.startd managed services can define the optional properties listed below in the startd property group.

startd/duration

The duration property defines the service's model. It can be set to transient, child also known as “wait” model services, or contract (the default).

startd/ignore_error

The ignore_error property, if set, specifies a comma-separated list of ignored events. Legitimate string values in that list are core and signal. The default is to restart on all errors.

startd/need_session

The need_session property, if set to true, indicates that the instance should be launched in its own session. The default is not to do so.

startd/utmpx_prefix

The utmpx_prefix string property defines that the instance requires a valid utmpx entry prior to start method execution. The default is not to create a utmpx entry.

SERVICE FAILURE

svc.startd assumes that a method has failed if it returns a non-zero exit code or if fails to complete before the timeout specified expires. If $SMF_EXIT_ERR_CONFIG or $SMF_EXIT_ERR_FATAL is returned, svc.startd immediately places the service in the maintenance state. For all other failures, svc.startd places the service in the offline state. If a service is offline and its dependencies are satisfied, svc.startd tries again to start the service (see smf(5)).

If a contract or transient service does not return from its start method before its defined timeout elapses, svc.startd sends a SIGKILL to the method, and returns the service to the offline state.

If three failures happen in a row, or if the service is restarting more than once a second, svc.startd places the service in the maintenance state.

The conditions of service failure are defined by a combination of the service model (defined by the startd/duration property) and the value of the startd/ignore_error property.

A contract model service fails if any of the following conditions occur:

• all processes in the service exit

• any processes in the service produce a core dump

• a process outside the service sends a service process a fatal signal (for example, an administrator terminates a service process with the pkill command)

The last two conditions may be ignored by the service by specifying core and/or signal in startd/ignore_error.

Defining a service as transient means that svc.startd does not track processes for that service. Thus, the potential faults described for contract model services are not considered failures for transient services. A transient service only enters the maintenance state if one of the method failure conditions occurs.

“Wait” model services are restarted whenever the child process associated with the service exits. A child process that exits is not considered an error for “wait” model services, and repeated failures do not lead to a transition to maintenance state.

LEGACY SERVICES

svc.startd continues to provide support for services invoked during the startup run level transitions. Each /etc/rc?.d directory is processed after all managed services which constitute the equivalent run level milestone have transitioned to the online state. Standard init scripts placed in the /etc/rc?.d directories are run in the order of their sequence numbers.

The milestone to run-level mapping is:

milestone/single-user

Single-user (S)

milestone/multi-user

Multi-user (2)

milestone/multi-user-server

Multi-user with network services (3)

Additionally, svc.startd gives these legacy services visibility in SMF by inserting an instance per script into the repository. These legacy instances are visible using standard SMF interfaces such as svcs(1), always appear in the LEGACY-RUN state, cannot be modified, and can not be specified as dependencies of other services. The initial start time of the legacy service is captured as a convenience for the administrator.

Files

/var/svc/log

Directory where svc.startd stores log files.

/etc/svc/volatile

Directory where svc.startd stores log files in early stages of boot, before /var is mounted read-write.

EXAMPLE

---

Example 1 Turning on Verbose Logging




To turn on verbose logging, type the following:

# /usr/sbin/svccfg -s system/svc/restarter:default svc:/system/svc/restarter:default> addpg options application svc:/system/svc/restarter:default> setprop options/logging = \ astring: verbose svc:/system/svc/restarter:default> exit

This request will take effect on the next restart of svc.startd.

---

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

See Also

svcs(1), svcprop(1), kernel(1M), init(1M), svcadm(1M), svccfg(1M), svc.configd(1M), setsid(2), syslog(3C), libscf(3LIB), scf_value_create(3SCF), contract(4), init.d(4), process(4), inittab(4), attributes(5), smf(5), smf_method(5)

Name

setfacl– modify the Access Control List (ACL) for a file or files

Synopsis

setfacl [-r] -s acl_entries file

setfacl [-r] -md acl_entries file

setfacl [-r] -f acl_file file

Description

For each file specified, setfacl either replaces its entire ACL, including the default ACL on a directory, or it adds, modifies, or deletes one or more ACL entries, including default entries on directories.

When the setfacl command is used, it can result in changes to the file permission bits. When the user ACL entry for the file owner is changed, the file owner class permission bits are modified. When the group ACL entry for the file group class is changed, the file group class permission bits are modified. When the other ACL entry is changed, the file other class permission bits are modified.

If you use the chmod(1) command to change the file group owner permissions on a file with ACL entries, both the file group owner permissions and the ACL mask are changed to the new permissions. Be aware that the new ACL mask permissions can change the effective permissions for additional users and groups who have ACL entries on the file.

A directory can contain default ACL entries. If a file or directory is created in a directory that contains default ACL entries, the newly created file has permissions generated according to the intersection of the default ACL entries and the permissions requested at creation time. The umask(1) are not applied if the directory contains default ACL entries. If a default ACL is specified for a specific user (or users), the file has a regular ACL created. Otherwise, only the mode bits are initialized according to the intersection described above. The default ACL should be thought of as the maximum discretionary access permissions that can be granted.

Use the setfacl command to set ACLs on files in a UFS file system, which supports POSIX-draft ACLS (or aclent_t style ACLs). Use the chmod command to set ACLs on files in a ZFS file system, which supports NFSv4-style ACLS (or ace_t style ACLs).

acl_entries Syntax

For the -m and -s options, acl_entries are one or more comma-separated ACL entries.

An ACL entry consists of the following fields separated by colons:

entry_type

Type of ACL entry on which to set file permissions. For example, entry_type can be user (the owner of a file) or mask (the ACL mask).

uid or gid

User name or user identification number. Or, group name or group identification number.

perms

Represents the permissions that are set on entry_type. perms can be indicated by the symbolic characters rwx or a number (the same permissions numbers used with the chmod command).

The following table shows the valid ACL entries (default entries can only be specified for directories):

ACL Entry	Description
u[ser]::perms	File owner permissions.
g[roup]::perms	File group owner permissions.
o[ther]:perms	Permissions for users other than the file owner or members of file group owner.
m[ask]:perms	The ACL mask. The mask entry indicates the maximum permissions allowed for users (other than the owner) and for groups. The mask is a quick way to change permissions on all the users and groups.
u[ser]:uid:perms	Permissions for a specific user. For uid, you can specify either a user name or a numeric UID.
g[roup]:gid:perms	Permissions for a specific group. For gid, you can specify either a group name or a numeric GID.
d[efault]:u[ser]::perms	Default file owner permissions.
d[efault]:g[roup]::perms	Default file group owner permissions.
d[efault]:o[ther]:perms	Default permissions for users other than the file owner or members of the file group owner.
d[efault]:m[ask]:perms	Default ACL mask.
d[efault]:u[ser]:uid:perms	Default permissions for a specific user. For uid, you can specify either a user name or a numeric UID.
d[efault]:g[roup]:gid:perms	Default permissions for a specific group. For gid, you can specify either a group name or a numeric GID.

For the -d option, acl_entries are one or more comma-separated ACL entries without permissions. Notice that the entries for file owner, file group owner, ACL mask, and others can not be deleted.

Options

The options have the following meaning:

-d acl_entries

Deletes one or more entries from the file. The entries for the file owner, the file group owner, and others can not be deleted from the ACL. Notice that deleting an entry does not necessarily have the same effect as removing all permissions from the entry.

-f acl_file

Sets a file's ACL with the ACL entries contained in the file named acl_file. The same constraints on specified entries hold as with the -s option. The entries are not required to be in any specific order in the file. Also, if you specify a dash (-) for acl_file, standard input is used to set the file's ACL.

The character # in acl_file can be used to indicate a comment. All characters, starting with the # until the end of the line, are ignored. Notice that if the acl_file has been created as the output of the getfacl(1) command, any effective permissions, which follow a #, are ignored.

-m acl_entries

Adds one or more new ACL entries to the file, and/or modifies one or more existing ACL entries on the file. If an entry already exists for a specified uid or gid, the specified permissions replace the current permissions. If an entry does not exist for the specified uid or gid, an entry is created. When using the -m option to modify a default ACL, you must specify a complete default ACL (user, group, other, mask, and any additional entries) the first time.

-r

Recalculates the permissions for the ACL mask entry. The permissions specified in the ACL mask entry are ignored and replaced by the maximum permissions necessary to grant the access to all additional user, file group owner, and additional group entries in the ACL. The permissions in the additional user, file group owner, and additional group entries are left unchanged.

-s acl_entries

Sets a file's ACL. All old ACL entries are removed and replaced with the newly specified ACL. The entries need not be in any specific order. They are sorted by the command before being applied to the file.

Required entries:

• Exactly one user entry specified for the file owner.

• Exactly one group entry for the file group owner.

• Exactly one other entry specified.

If there are additional user and group entries:

• Exactly one mask entry specified for the ACL mask that indicates the maximum permissions allowed for users (other than the owner) and groups.

• Must not be duplicate user entries with the same uid.

• Must not be duplicate group entries with the same gid.

If file is a directory, the following default ACL entries can be specified:

• Exactly one default user entry for the file owner.

• Exactly one default group entry for the file group owner.

• Exactly one default mask entry for the ACL mask.

• Exactly one default other entry.

There can be additional default user entries and additional default group entries specified, but there can not be duplicate additional default user entries with the same uid, or duplicate default group entries with the same gid.

Examples

---

Example 1 Adding read permission only




The following example adds one ACL entry to file abc, which gives user shea read permission only.

setfacl -m user:shea:r-- abc

---

---

Example 2 Replacing a file's entire ACL




The following example replaces the entire ACL for the file abc, which gives shea read access, the file owner all access, the file group owner read access only, the ACL mask read access only, and others no access.

setfacl -s user:shea:rwx,user::rwx,group::rw-,mask:r--,other:--- abc

Notice that after this command, the file permission bits are rwxr-----. Even though the file group owner was set with read/write permissions, the ACL mask entry limits it to have only read permission. The mask entry also specifies the maximum permissions available to all additional user and group ACL entries. Once again, even though the user shea was set with all access, the mask limits it to have only read permission. The ACL mask entry is a quick way to limit or open access to all the user and group entries in an ACL. For example, by changing the mask entry to read/write, both the file group owner and user shea would be given read/write access.

---

---

Example 3 Setting the same ACL on two files




The following example sets the same ACL on file abc as the file xyz.

getfacl xyz | setfacl -f - abc

---

Files

/etc/passwd

password file

/etc/group

group file

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu

See Also

chmod(1), getfacl(1), umask(1), aclcheck(3SEC), aclsort(3SEC), group(4), passwd(4), attributes(5)

Name

grep– search a file for a pattern

Synopsis

/usr/bin/grep [-bchilnsvw] limited-regular-expression 
     [filename]...

/usr/xpg4/bin/grep [-E | -F] [-c | -l | -q] [-bhinsvwx] -e pattern_list... 
     [-f pattern_file]... [file]...

/usr/xpg4/bin/grep [-E | -F] [-c | -l | -q] [-bhinsvwx] 
     [-e pattern_list]... -f pattern_file... [file]...

/usr/xpg4/bin/grep [-E | -F] [-c | -l | -q] [-bhinsvwx] pattern 
     [file]...

Description

The grep utility searches text files for a pattern and prints all lines that contain that pattern. It uses a compact non-deterministic algorithm.

Be careful using the characters $, *, [, ^, |, (, ), and \ in the pattern_list because they are also meaningful to the shell. It is safest to enclose the entire pattern_list in single quotes ´...´.

If no files are specified, grep assumes standard input. Normally, each line found is copied to standard output. The file name is printed before each line found if there is more than one input file.

/usr/bin/grep

The /usr/bin/grep utility uses limited regular expressions like those described on the regexp(5) manual page to match the patterns.

/usr/xpg4/bin/grep

The options -E and -F affect the way /usr/xpg4/bin/grep interprets pattern_list. If -E is specified, /usr/xpg4/bin/grep interprets pattern_list as a full regular expression (see -E for description). If -F is specified, grep interprets pattern_list as a fixed string. If neither are specified, grep interprets pattern_list as a basic regular expression as described on regex(5) manual page.

Options

The following options are supported for both /usr/bin/grep and /usr/xpg4/bin/grep:

-b

Precedes each line by the block number on which it was found. This can be useful in locating block numbers by context (first block is 0).

-c

Prints only a count of the lines that contain the pattern.

-h

Prevents the name of the file containing the matching line from being prepended to that line. Used when searching multiple files.

-i

Ignores upper/lower case distinction during comparisons.

-l

Prints only the names of files with matching lines, separated by NEWLINE characters. Does not repeat the names of files when the pattern is found more than once.

-n

Precedes each line by its line number in the file (first line is 1).

-s

Suppresses error messages about nonexistent or unreadable files.

-v

Prints all lines except those that contain the pattern.

-w

Searches for the expression as a word as if surrounded by \< and \>.

/usr/xpg4/bin/grep

The following options are supported for /usr/xpg4/bin/grep only:

-e pattern_list

Specifies one or more patterns to be used during the search for input. Patterns in pattern_list must be separated by a NEWLINE character. A null pattern can be specified by two adjacent newline characters in pattern_list. Unless the -E or -F option is also specified, each pattern is treated as a basic regular expression. Multiple -e and -f options are accepted by grep. All of the specified patterns are used when matching lines, but the order of evaluation is unspecified.

-E

Matches using full regular expressions. Treats each pattern specified as a full regular expression. If any entire full regular expression pattern matches an input line, the line is matched. A null full regular expression matches every line. Each pattern is interpreted as a full regular expression as described on the regex(5) manual page, except for \( and \), and including:

1. A full regular expression followed by + that matches one or more occurrences of the full regular expression.

2. A full regular expression followed by ? that matches 0 or 1 occurrences of the full regular expression.

3. Full regular expressions separated by | or by a new-line that match strings that are matched by any of the expressions.

4. A full regular expression that is enclosed in parentheses () for grouping.

The order of precedence of operators is [ ], then * ? +, then concatenation, then | and new-line.

-f pattern_file

Reads one or more patterns from the file named by the path name pattern_file. Patterns in pattern_file are terminated by a NEWLINE character. A null pattern can be specified by an empty line in pattern_file. Unless the -E or -F option is also specified, each pattern is treated as a basic regular expression.

-F

Matches using fixed strings. Treats each pattern specified as a string instead of a regular expression. If an input line contains any of the patterns as a contiguous sequence of bytes, the line is matched. A null string matches every line. See fgrep(1) for more information.

-q

Quiet. Does not write anything to the standard output, regardless of matching lines. Exits with zero status if an input line is selected.

-x

Considers only input lines that use all characters in the line to match an entire fixed string or regular expression to be matching lines.

Operands

The following operands are supported:

file

A path name of a file to be searched for the patterns. If no file operands are specified, the standard input is used.

/usr/bin/grep

pattern

Specifies a pattern to be used during the search for input.

/usr/xpg4/bin/grep

pattern

Specifies one or more patterns to be used during the search for input. This operand is treated as if it were specified as -e pattern_list.

Usage

The -e pattern_list option has the same effect as the pattern_list operand, but is useful when pattern_list begins with the hyphen delimiter. It is also useful when it is more convenient to provide multiple patterns as separate arguments.

Multiple -e and -f options are accepted and grep uses all of the patterns it is given while matching input text lines. Notice that the order of evaluation is not specified. If an implementation finds a null string as a pattern, it is allowed to use that pattern first, matching every line, and effectively ignore any other patterns.

The -q option provides a means of easily determining whether or not a pattern (or string) exists in a group of files. When searching several files, it provides a performance improvement (because it can quit as soon as it finds the first match) and requires less care by the user in choosing the set of files to supply as arguments (because it exits zero if it finds a match even if grep detected an access or read error on earlier file operands).

Large File Behavior

See largefile(5) for the description of the behavior of grep when encountering files greater than or equal to 2 Gbyte ( 2³¹ bytes).

Examples

---

Example 1 Finding All Uses of a Word




To find all uses of the word “Posix” (in any case) in the file text.mm, and write with line numbers:

example% /usr/bin/grep -i -n posix text.mm

---

---

Example 2 Finding All Empty Lines




To find all empty lines in the standard input:

example% /usr/bin/grep ^$

or

example% /usr/bin/grep -v .

---

---

Example 3 Finding Lines Containing Strings




All of the following commands print all lines containing strings abc or def or both:

example% /usr/xpg4/bin/grep 'abc def' example% /usr/xpg4/bin/grep -e 'abc def' example% /usr/xpg4/bin/grep -e 'abc' -e 'def' example% /usr/xpg4/bin/grep -E 'abc|def' example% /usr/xpg4/bin/grep -E -e 'abc|def' example% /usr/xpg4/bin/grep -E -e 'abc' -e 'def' example% /usr/xpg4/bin/grep -E 'abc def' example% /usr/xpg4/bin/grep -E -e 'abc def' example% /usr/xpg4/bin/grep -F -e 'abc' -e 'def' example% /usr/xpg4/bin/grep -F 'abc def' example% /usr/xpg4/bin/grep -F -e 'abc def'

---

---

Example 4 Finding Lines with Matching Strings




Both of the following commands print all lines matching exactly abc or def:

example% /usr/xpg4/bin/grep -E '^abc$ ^def$' example% /usr/xpg4/bin/grep -F -x 'abc def'

---

Environment Variables

See environ(5) for descriptions of the following environment variables that affect the execution of grep: LANG, LC_ALL, LC_COLLATE, LC_CTYPE, LC_MESSAGES, and NLSPATH.

Exit Status

The following exit values are returned:

0

One or more matches were found.

1

No matches were found.

2

Syntax errors or inaccessible files (even if matches were found).

Attributes

See attributes(5) for descriptions of the following attributes:

/usr/bin/grep

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWcsu
CSI	Not Enabled

/usr/xpg4/bin/grep

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWxcu4
CSI	Enabled
Interface Stability	Committed
Standard	See standards(5).

See Also

egrep(1), fgrep(1), sed(1), sh(1), attributes(5), environ(5), largefile(5), regex(5), regexp(5), standards(5)

Notes

/usr/bin/grep

Lines are limited only by the size of the available virtual memory. If there is a line with embedded nulls, grep only matches up to the first null. If the line matches, the entire line is printed.

/usr/xpg4/bin/grep

The results are unspecified if input files contain lines longer than LINE_MAX bytes or contain binary data. LINE_MAX is defined in /usr/include/limits.h.

해커들의 리눅스 로그 삭제법

침입자들이 쉘을얻어내어 루트권한을 따내고 자취를 감출때 해커들이 하는 방법을 알아보자 ..

/etc/syslog.conf 에서 로그상태를 분석해서 로그를 찾아나간다.
/var/adm/messages 에서 자신의 흔적을 지운다.
/var/adm/sulog 에서 su 명령어를 쓴 자신의 흔적을 지운다.
/.history 에서 자신이 쳤던 명령어 리스트를 지운다.
/var/log/syslog 에서 자신의 흔적을 지운다.
/var/log/authlog 에서 자신의 흔적을 지운다.
/var/adm/utmp 에서 자신의 흔적을 지운다.
/var/adm/wtmp 에서 자신의 흔적을 지운다.
/tmp/ 에서 자신의 흔적을 지운다.

위의 내용은 보통 로그에서 자신의 흔적을 살며시 지우는 행위이다.
zap3을 이용해서 utmp 와 wtmp 에서 자신을 훔치고 로그를 조작한다네요..

출처 : http://hackeracademy.tistory.com/

How the ufsdump Command Works

The ufsdump command makes two passes when it backs up a file system. On the first pass, this command scans the raw device file for the file system and builds a table of directories and files in memory. Then, this command writes the table to the backup media. In the second pass, the ufsdump command goes through the inodes in numerical order, reading the file contents and writing the data to the backup media.

Determining Device Characteristics

The ufsdump command needs to know only an appropriate tape block size and how to detect the end of media.

Detecting the End of Media

The ufsdump command writes a sequence of fixed-size records. When the ufsdump command receives notification that a record was only partially written, it assumes that it has reached the physical end of the media. This method works for most devices. If a device is not able to notify the ufsdump command that only a partial record has been written, a media error occurs as the ufsdump command tries to write another record.

DAT devices and 8-mm tape devices detect end-of-media. Cartridge tape devices and 1/2-inch tape devices do not detect end-of-media.

The ufsdump command automatically detects the end-of-media for most devices. Therefore, you do not usually need to use the -c, -d, -s, and -t options to perform multivolume backups.

You need to use the end-of-media options when the ufsdump command does not understand the way the device detects the end-of-media.

To ensure compatibility with the restore command, the size option can still force the ufsdump command to go to the next tape or diskette before reaching the end of the current tape or diskette.

Copying Data With the ufsdump Command

The ufsdump command copies data only from the raw disk slice. If the file system is still active, any data in memory buffers is probably not copied. The backup done by the ufsdump command does not copy free blocks, nor does it make an image of the disk slice. If symbolic links point to files on other slices, the link itself is copied.

Purpose of the /etc/dumpdates File

The ufsdump command, when used with the -u option, maintains and updates the /etc/dumpdates file. Each line in the /etc/dumpdates file shows the following information:

• The file system backed up

• The dump level of the last backup

• The day, date, and time of the backup

For example:

# cat /etc/dumpdates
/dev/rdsk/c0t0d0s0               0 Wed Jul 28 16:13:52 2004
/dev/rdsk/c0t0d0s7               0 Thu Jul 29 10:36:13 2004
/dev/rdsk/c0t0d0s7               9 Thu Jul 29 10:37:12 2004

When you do an incremental backup, the ufsdump command checks the /etc/dumpdates file to find the date of the most recent backup of the next lower dump level. Then, this command copies to the media all files that were modified since the date of that lower-level backup. After the backup is complete, a new information line, which describes the backup you just completed, replaces the information line for the previous backup at that level.

Use the /etc/dumpdates file to verify that backups are being done. This verification is particularly important if you are having equipment problems. If a backup cannot be completed because of equipment failure, the backup is not recorded in the /etc/dumpdates file.

If you need to restore an entire disk, check the /etc/dumpdates file for a list of the most recent dates and levels of backups so that you can determine which tapes you need to restore the entire file system.

The /etc/dumpdates file is a text file that can be edited. However, edit it only at your own risk. If you make changes to the file that do not match your archive tapes, you might be unable to find the tapes (or files) you need.

Backup Device (dump-file) Argument

The dump-file argument (to the -f option) specifies the destination of the backup. The destination can be one of the following:

• Local tape drive

• Local diskette drive

• Remote tape drive

• Remote diskette drive

• Standard output

Use this argument when the destination is not the default local tape drive /dev/rmt/0. If you use the -f option, then you must specify a value for the dump-file argument.

The dump-file argument can also point to a file on a local disk or on a remote disk. If done by mistake, this usage can fill up a file system.

Local Tape or Diskette Drive

Typically, the dump-file argument specifies a raw device file for a tape device or diskette. When the ufsdump command writes to an output device, it creates a single backup file that might span multiple tapes or diskettes.

You specify a tape device or a diskette on your system by using a device abbreviation. The first device is always 0. For example, if you have a SCSI tape controller and one QIC-24 tape drive that uses medium-density formatting, use this device name:

/dev/rmt/0m

When you specify a tape device name, you can also type the letter “n” at the end of the name to indicate that the tape drive should not rewind after the backup is completed. For example:

/dev/rmt/0mn

Use the “no-rewind” option if you want to put more than one file onto the tape. If you run out of space during a backup, the tape does not rewind before the ufsdump command asks for a new tape. For a complete description of device-naming conventions, see Backup Device Names.

Remote Tape or Diskette Drive

You specify a remote tape device or a remote diskette by using the syntax host:device. The ufsdump command writes to the remote device when superuser on the local system has access to the remote system. If you usually run the ufsdump command as superuser, the name of the local system must be included in the /.rhosts file on the remote system. If you specify the device as user@host:device, the ufsdump command tries to access the device on the remote system as the specified user. In this case, the specified user must be included in the /.rhosts file on the remote system.

Use the naming convention for the device that matches the operating system for the system on which the device resides, not the system from which you run the ufsdump command. If the drive is on a system that is running a previous SunOS release (for example, 4.1.1), use the SunOS 4.1 device name (for example, /dev/rst0). If the system is running Solaris software, use the SunOS 5.9 convention (for example, /dev/rmt/0).

Using Standard Output With the ufsdump Command

When you specify a dash (-) as the dump-file argument, the ufsdump command writes to standard output.

The -v option (verify) does not work when the dump-file argument is standard output.

You can use the ufsdump and ufsrestore commands in a pipeline to copy a file system by writing to standard output with the ufsdump command and reading from standard input with the ufsrestore command. For example:

# ufsdump 0f - /dev/rdsk/c0t0d0s7 | (cd /home; ufsrestore xf -)

Specifying Files to Back Up

You must always include filenames as the last argument on the command line. This argument specifies the source or contents of the backup.

For a file system, specify the raw device file as follows:

/dev/rdsk/c0t0d0s7

You can specify the file system by its mount point directory (for example, /export/home), as long as an entry for it exists in the /etc/vfstab file.

For a complete description of device-naming conventions, see Backup Device Names.

For individual files or directories, type one or more names separated by spaces.

When you use the ufsdump command to back up one or more directories or files (rather than a complete file system), a level 0 backup is done. Incremental backups do not apply.

Specifying Tape Characteristics

If you do not specify any tape characteristics, the ufsdump command uses a set of defaults. You can specify the tape cartridge (c), density (d), size (s), and number of tracks (t). Note that you can specify the options in any order, as long as the arguments that follow match the order of the options.

Limitations of the ufsdump Command

The ufsdump command cannot do the following:

• Automatically calculate the number of tapes or diskettes that are needed for backing up file systems. You can use the dry run mode (S option) to determine how much space is needed before actually backing up file systems.

• Provide built-in error checking to minimize problems when it backs up an active file system.

• Back up files that are remotely mounted from a server. Files on the server must be backed up on the server itself. Users are denied permission to run the ufsdump command on files they own that are located on a server.

Name

ftpusers– file listing users to be disallowed ftp login privileges

Synopsis

/etc/ftpd/ftpusers

Description

The ftpusers file lists users for whom ftp login privileges are disallowed. Each ftpuser entry is a single line of the form:

name

where name is the user's login name.

The FTP Server, in.ftpd(1M), reads the ftpusers file. If the login name of the user matches one of the entries listed, it rejects the login attempt.

The ftpusers file has the following default configuration entries:

root
daemon
bin
sys
adm
lp
uccp
nuucp
smmsp
listen
nobody
noaccess
nobody4

These entries match the default instantiated entries from passwd(4). The list of default entries typically contains the superuser root and other administrative and system application identities.

The root entry is included in the ftpusers file as a security measure since the default policy is to disallow remote logins for this identity. This policy is also set in the default value of the CONSOLE entry in the /etc/default/login file. See login(1). If you allow root login privileges by deleting the root entry in ftpusers, you should also modify the security policy in /etc/default/login to reflect the site security policy for remote login access by root.

Other default entries are administrative identities that are typically assumed by system applications but never used for local or remote login, for example sys and nobody. Since these entries do not have a valid password field instantiated in shadow(4), no login can be performed.

If a site adds similar administrative or system application identities in passwd(4) and shadow(4), for example, majordomo, the site should consider including them in the ftpusers file for a consistent security policy.

Lines that begin with # are treated as comment lines and are ignored.

Files

/etc/ftpd/ftpusers

A file that lists users for whom ftp login privileges are disallowed.

/etc/ftpusers

See /etc/ftpd/ftpusers. This file is deprecated, although its use is still supported.

/etc/default/login

/etc/passwd

password file

/etc/shadow

shadow password file

Attributes

See attributes(5) for descriptions of the following attributes:

ATTRIBUTE TYPE	ATTRIBUTE VALUE
Availability	SUNWftpr
Interface Stability  /etc/ftpd/ftpusers	External
Interface Stability  /etc/ftpusers	Obsolete

See Also

login(1), in.ftpd(1M), ftpaccess(4), ftphosts(4), passwd(4), shadow(4), attributes(5), environ(5)

Synopsis

useradd [-c comment] [-d dir] [-e expire] [-f inactive]
[-g group] [-G group [, group...]] [-m [-k skel_dir]]
[-u uid [-o]] [-s shell] [-A authorization [,authorization...]]
[-P profile [,profile...]] [-R role [,role...]]
[-p projname] [-K key=value] login
useradd -D [-b base_dir] [-e expire] [-f inactive]
[-g group] [-A authorization [,authorization...]]
[-P profile [,profile...]] [-R role [,role...]]
[-p projname] [-K key=value]

Options

-A authorization
One or more comma separated authorizations defined in auth_attr(4). Only a user or role
who has grant rights to the authorization can assign it to an account.
-b base_dir
The default base directory for the system if -d dir is not specified. base_dir is concatenated
with the account name to define the home directory. If the -m option is not used, base_dir
must exist.
-c comment
Any text string. It is generally a short description of the login, and is currently used as the
field for the user's full name. This information is stored in the user's /etc/passwd entry.

-d dir
The home directory of the new user. It defaults to base_dir/account_name, where base_dir
is the base directory for new login home directories and account_name is the new login
name.
-D
Display the default values for group, base_dir, skel_dir, shell, inactive, expire, proj,
projname and key=value pairs. When used with the -g, -b, -f, -e, -A, -P, -p, -R, or -K
options, the -D option sets the default values for the specified fields. The default values are:
group other (GID of 1)
base_dir /home
skel_dir /etc/skel
shell /bin/sh
inactive 0
expire null
auths null
profiles null
proj 3
projname default
key=value (pairs
defined in
user_attr(4)
not present
roles null
-e expire
Specify the expiration date for a login. After this date, no user will be able to access this
login. The expire option argument is a date entered using one of the date formats included
in the template file /etc/datemsk. See getdate(3C).
If the date format that you choose includes spaces, it must be quoted. For example, you can
enter 10/6/90 or "October 6, 1990". A null value (" ") defeats the status of the expired
date. This option is useful for creating temporary logins.
-f inactive
The maximum number of days allowed between uses of a login ID before that ID is
declared invalid.Normal values are positive integers. A value of 0 defeats the status.

-g group
An existing group's integer ID or character-string name. Without the -D option, it defines
the new user's primary group membership and defaults to the default group. You can reset
this default value by invoking useradd -D -g group. GIDs 0-99 are reserved for allocation
by the Solaris Operating System.
-G group
An existing group's integer ID or character-string name. It defines the new user's
supplementary group membership. Duplicates between group with the -g and -G options
are ignored.No more than NGROUPS_MAX groups can be specified. GIDs 0-99 are reserved
for allocation by the Solaris Operating System.
-K key=value
A key=value pair to add to the user's attributes.Multiple -K options may be used to add
multiple key=value pairs. The generic -K option with the appropriate key may be used
instead of the specific implied key options (-A, -P, -R, -p). See user_attr(4) for a list of
valid key=value pairs. The “type” key is not a valid key for this option. Keys may not be
repeated.
-k skel_dir
A directory that contains skeleton information (such as .profile) that can be copied into a
new user's home directory. This directory must already exist. The system provides the
/etc/skel directory that can be used for this purpose.
-m
Create the new user's home directory if it does not already exist. If the directory already
exists, it must have read, write, and execute permissions by group, where group is the user's
primary group.
-o
This option allows a UID to be duplicated (non-unique).
-P profile
One or more comma-separated execution profiles defined in prof_attr(4).
-p projname
Name of the project with which the added user is associated. See the projname field as
defined in project(4).
-R role
One or more comma-separated execution profiles defined in user_attr(4). Roles cannot
be assigned to other roles.
-s shell
Full pathname of the program used as the user's shell on login. It defaults to an empty field
causing the system to use /bin/sh as the default. The value of shell must be a valid
executable file.

-u uid
The UID of the new user. This UID must be a non-negative decimal integer below MAXUID
as defined in <sys/param.h>. The UID defaults to the next available (unique) number
above the highest number currently assigned. For example, if UIDs 100, 105, and 200 are
assigned, the next default UID number will be 201. UIDs 0-99 are reserved for allocation by
the Solaris Operating System.