Monday, April 28, 2008

Manage Linux log files with Logrotate

Log files are the most valuable tools available for Linux system security. The logrotate program is used to provide the administrator with an up-to-date record of events taking place on the system. The logrotate utility may also be used to back up log files, so copies may be used to establish patterns for system use. In this Daily Drill Down, I’ll cover the following topics:
  • The logrotate configuration
  • Setting defaults for logrotate
  • Using the include option to read other configuration files
  • Setting rotation parameters for specific files
  • Using the include option to override defaults

The logrotate program
The logrotate program is a log file manager. It is used to regularly cycle (or rotate) log files by removing the oldest ones from your system and creating new log files. It may be used to rotate based on the age of the file or the file’s size, and usually runs automatically through the cron utility. The logrotate program may also be used to compress log files and to configure e-mail to users when they are rotated.

The logrotate configuration
The logrotate program is configured by entering options in the /etc/logrotate.conf file. This is a text file, which may contain any of the configuration options listed in the table below. The options entered in /etc/logrotate.conf may be used to set configuration parameters for any log file on the system. These options may also be used to allow logrotate to read configuration parameters from other log files, by using the include parameter.


Option

Function
compress This is used to compress the rotated log file with gzip.
nocompress This is used when you do not want to compress rotated log files.
copytruncate This is used when processes are still writing information to open log files. This option copies the active log file to a backup and truncates the active log file.
nocopytruncate This copies the log files to backup, but the open log file is not truncated.
create mode owner group This rotates the log file and creates a new log file with the specified permissions, owner, and group. The default is to use the same mode, owner, and group as the original file.
nocreate This prevents the creation of a new log file.
delaycompress When used with the compress option, the rotated log file is not compressed until the next time it is cycled.
nodelaycompress This overrides delaycompress. The log file is compressed when it is cycled.
errors address This mails logrotate errors to an address.
ifempty With this, the log file is rotated even if it is empty. This is the default for logrotate.
notifempty This does not rotate the log file if it is empty.
mail address This mails log files that are cycled to an address. When mail log files are cycled, they are effectively removed from the system.
nomail When mail log files are cycled, a copy is not mailed.
olddir directory With this, cycled log files are kept in the specified directory. This directory must be on the same filesystem as the current log files.
noolddir Cycled log files are kept in the same directory as the current log files.
prerotate/endscript These are statements that enclose commands to be executed prior to a log file being rotated. The prerotate and endscript keywords must appear on a line by themselves.
postrotate/endscript These are statements that enclose commands to be executed after a log file has been rotated. The postrotate and endscript keywords must appear on a line by themselves.
daily This is used to rotate log files daily.
weekly This is used to rotate log files weekly.
monthly This is used to rotate log files monthly.
rotate count This specifies the number of times to rotate a file before it is deleted. A count of 0 (zero) means no copies are retained. A count of 5 means five copies are retained.
tabootext [+] list This directs logrotate to not rotate files with the specified extension. The default list of extensions is .rpm-orig, .rpmsave, v, and ~.
size size With this, the log file is rotated when the specified size is reached. Size may be specified in bytes (default), kilobytes (sizek), or megabytes (sizem).

The /etc/logrotate.conf file
The /etc/logrotate.conf file is the default configuration file for logrotate. The default /etc/logrotate.conf file installed with Red Hat Linux is shown below:
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# send errors to root
errors root
# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress
1
# RPM packages drop log rotation information into this directory
include /etc/logrotate.d

# no packages own lastlog or wtmp --we'll rotate them here
/var/log/wtmp {
monthly
create 0664 root utmp
rotate 1
}

/var/log/lastlog {
monthly
rotate 1
}

# system-specific logs may be configured here


Setting defaults for logrotate
Default configuration settings are normally placed close to the beginning of the logrotate.conf file. These settings are usually in effect system-wide. The default settings for logrotate on this system are established in the first 12 lines of the file.

The third line
weekly

specifies that all log files will be rotated weekly.

The fifth line
rotate 4

specifies that four copies of old log files are retained before the files are cycled. Cycling refers to removing the oldest log files and replacing them with new copies.

The seventh line
errors root

sends all logrotate error messages to root.

The ninth line
create

configures logrotate to automatically create new log files. The new log files will have the same permissions, owner, and group as the file being rotated.

The eleventh line
#compress

prevents logrotate from compressing log files when they are rotated. Compression is enabled by removing the comment (#) from this line.

Using the include option
The include option allows the administrator to take log file rotation information, which may be installed in several files, and use it in the main configuration file. When logrotate finds the include option on a line in logrotate.conf, the information in the file specified is read as if it appeared in /etc/logrotate.conf.

Line 13 in /etc/logrotate.conf
include /etc/logrotate.d

tells logrotate to be read in the log rotation parameters, which are stored in the files contained in the /etc/logrotate.d directory. The include option is very useful when RPM packages are installed on a system. RPM packages’ log rotation parameters will typically install in the /etc/logrotate.d directory.

The include option is important. Some of the applications that install their log rotation parameters to /etc/logrotate.d by default are apache, linuxconf, samba, cron, and syslog. The include option allows the parameters from each of these files to be read into logrotate.conf.

Using the include option in /etc/logrotate.conf allows the administrator to configure a rotation policy for these packages through a single configuration file.

Using include to override defaults
When a file is read by /etc/logrotate.conf, the rotation parameters specified in the include will override the parameters specified in the logrotate file. An example of /etc/logrotate.conf being overridden is shown below:
#Log rotation parameters for linuxconf
/var/log/htmlaccess.log
{ errors jim
notifempty
nocompress
weekly
prerotate
/usr/bin/chattr -a /var/log/htmlaccess.log
endscript
postrotate
/usr/bin/chattr +a /var/log/htmlaccess.log
endscript
}
/var/log/netconf.log
{ nocompress
monthly
}


In this example, when the /etc/logrotate.d/linuxconf file is read by /etc/logrotate.conf, the following options will override the defaults specified in /etc/logrotate.conf:
Notifempty
errors jim


The nocompress and weekly options do not override any options contained in /etc/logrotate.conf.

Setting parameters for a specific file
Configuration parameters for a specific file are often required. A common example would be to include a section in the /etc/logrotate.conf file to rotate the /var/log/wtmp file once per month and keep only one copy of the log. When configuration is required for a specific file, the following format is used:
#comments
/full/path/to/file
{
option(s)
}


The following entry would cause the /var/log/wtmp file to be rotated once a month, with one backup copy retained:
#Use logrotate to rotate wtmp
/var/log/wtmp
{
monthly
rotate 1
}

Although the opening bracket may appear on a line with other text or commands, the closing bracket must be on a line by itself.
Using the prerotate and postrotate options
The section of code below shows a typical script in /etc/logrotate.d/syslog. This section applies only to /var/log/messages. On a production server, /etc/logrotate.d/syslog would probably contain similar entries.
/var/log/messages
{
prerotate
/usr/bin/chattr -a /var/log/messages
endscript
postrotate
/usr/bin/kill -HUP syslogd
/usr/bin/chattr +a /var/log/messages
endscript
}


The format for this script uses the following methods:
  • The first line, /var/logmessages, declares the file for which this script will be used.
  • The curly braces,{ }, are used to enclose the entire script. All commands contained within these braces will be run on the /var/log/messages file.
  • The prerotate command specifies actions to be taken prior to the file being rotated by logrotate.
  • The command /usr/bin/chattr -a is run to remove the append-only attribute from /var/log/messages.
  • The endscript command marks the end of the prerotate portion of this script.
  • The next line, postrotate, specifies the following commands are to be run on /var/log/messages after the file has been rotated by logrotate.
  • The command /usr/bin/killall -HUPsyslogd is run to reinitiate the system logging daemon, syslogd.
  • The next command, /usr/bin/chattr +a /var/log/messages, reassigns the append-only attribute to the /var/log/messages file. This means the file may only be seen in append mode. This prevents the file from being overridden by any other program or user.
  • The endscript command appears on a line by itself and marks the end of the postrotate portion of this script.
  • The last curly brace,}, marks the end of commands to be applied to the /var/log/messages file.

Running logrotate
There are three steps involved in running logrotate:
  1. Identify the log files on your system.
  2. Create rotation schedules and parameters for the log files.
  3. Run logrotate through the cron daemon.

The code below shows the default cronjob shipped with Red Hat Linux to allow logrotate to run daily:
#/etc/cron.daily/logrotate
#! /bin/sh

/usr/sbin/logrotate /etc/logrotate.conf


This cronjob allows logrotate to run daily with the rotation parameter specified in /etc/logrotate.conf.

Conclusion
Log rotation is the first step in log file management. The logrotate utility provides the Linux administrator with the ability to maintain a log file rotation policy and to retain copies of log files to assist in establishing patterns related to system usage. In this Daily Drill Down, we looked at the installation and configuration of logrotate, used the include option to read configuration files related to RPM packages, and ran logrotate as a cronjob. We also discussed the proper methods for restarting logrotate after the log rotation procedure is completed.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

Taken from: http://articles.techrepublic.com.com/5100-6345-1052474.html?tag=rbxccnbtr1

Solaris Soft Partitioning

Solstice DiskSuite / Solaris Volume Manager

Soft Partitioning


A Primer for Understanding Soft Partitioning,
a new feature in Solstice DiskSuite (Solaris Volume Manager)

The intent of this document is to describe Soft Partitioning within Solstice DiskSuite (soon-to-be-renamed Solaris Volume Manager), and offer a short primer/tutorial on how to create, use, and delete them.

Until now, Solaris, without any volume management software, has only ever allowed a fixed number of partitions on a physical disk (seven (7) on SPARC platforms). With the increase in capacity of disks, this limitation has become a severe restriction.

SDS/SVM uses these slices for its metadevices (sub-mirrors, trans, stripes, and RAID5) and hence is faced with the same limitation, whereas Veritas Volume Manager (VxVM) allows for the logical partitioning of disks into a virtually unlimited number of subdisks.

Soft Partitioning allows for a disk to be subdivided into many partitions which are controlled and maintained by software, thereby removing the limitation of the number of partitions on a disk. A soft partition is made up of one or more "extents". An extent describes the parts of the physical disk that make up the soft partition. While the maximum number of extents per soft partition is 2147483647, the majority of soft partitions will use only one (1) extent.


What is new?

Soft Partitioning was not in the original Solstice DiskSuite 4.2.1 Release, which coincided with the release of Solaris 8. However, the soft partitioning functionality was released in patch 108693-06 for SDS 4.2.1.

When Solaris 9 gets released, the "Solstice DiskSuite" name will change to "Solaris Volume Manager" ("SVM") and it will be bundled in with Solaris 9. Soft Partitioning will, of course, be part of the base functionality of that release.

Soft Partitions are implemented by new kernel driver: md_sp.

   # modinfo | grep md_sp
228 78328000 4743 - 1 md_sp (Meta disk soft partition module)
There are new options to the metainit command:
   metainit softpart -p [-e] component size
metainit softpart -p component -o offset -b size
The metattach command has been modified to allow for growing of soft partitions:
   metattach softpart size 
There is a new command... metarecover:
   metarecover [-n] [-v] component -p [-d|-m] 

NOTE: the -p option means that the command refers to soft partitions.


Creating Soft Partitions

There are three methods to create a soft partition using the metainit command:
  1. Specifying an unused disk and size (with the -e option). For example:

       # metainit d0 -p -e c1t0d0 200m 

    The -e option requires that the name of the disk supplied be in the form c#t#d#.

    The last parameter (200m) specifies the initial size of the soft partition. The sizes can be specified in blocks, kilobytes, megabytes, gigabytes, and terabytes.

    The -e option causes the disk to be repartitioned such that slice 7 has enough space to hold a replica (although no replica is actually created on this disk) and slice 0 contains the rest of the space. Slice 2 is removed from the disk. The soft partition that is being created is put into slice 0. Further soft partitions can be created on slice 0 by the next method of creating a soft partition.

    After this command is run, the layout of the disk would like similar to this example:

       Part      Tag   Flag   Cylinders     Size           Blocks
    0 unassigned wm 5 - 2035 999.63MB (2031/0/0) 2047248
    1 unassigned wm 0 0 (0/0/0) 0
    2 unassigned wm 0 0 (0/0/0) 0
    3 unassigned wm 0 0 (0/0/0) 0
    4 unassigned wm 0 0 (0/0/0) 0
    5 unassigned wm 0 0 (0/0/0) 0
    6 unassigned wm 0 0 (0/0/0) 0
    7 unassigned wu 0 - 4 2.46MB (5/0/0) 5040

    This command (with the -e) can only be run on an empty disk (one that is not used in any other metadevice). If another metadevice or replica already exists on this disk, one of the following messages will be printed, and no soft partition will be created.

       metainit: hostname: c#t#d#s0: has appeared more than once in the specification of d#
    or
       metainit: hostname: c#t#d#s#: has a metadevice database replica
  2. Specifying an existing slice name and size (without the -e option). This will be the most common method of creation. For example:

        # metainit d1 -p c1t0d0s0 1g 

    This will create a soft partition on the specified slice. No repartitioning of the disk is done. Provided there is space on the slice, additional soft partitions could be created as required. The device name must include the slice number (c#t#d#s#).

    If another soft partition already exists in this slice, this one will be created immediately after the existing one. Therefore, no overlap of soft partitions can occur by accident.

  3. Specifying an existing slice and absolute offset and size values. For example:

       # metainit d2 -p c1t0d0s0 -o 2048 -b 1024 
    The -o parameter signifies the offset into the slice, and the -b parameter is the size for the soft partition. All numbers are in blocks (a block is 512 bytes). The metainit command ensures that extents and soft partitions do not overlap. For example, the following is an attempt to create overlapping soft partitions.

       # metainit d1 -p c1t0d0s0 -o 1 -b 2024
    d1: Soft Partition is setup
    # metainit d2 -p c1t0d0s0 -o 2000 -b 2024
    metainit: hostname: d2: overlapping extents specified

    An offset of 0 is not valid, as the first block on a slice containing a soft partition contains the initial extent header. Each extent header consumes 1 block of disk and each soft partition will have an extent header placed at the end of each extent. Extent headers are explained in more detail in the next section.

    NOTE: This method is not documented in the man page for metainit and is not recommended for manual use. It is here because a subsequent metastat -p command will output information in this format.



Extent Headers

Whenever a soft partiton is created in a disk slice, an "extent header" is written to disk. Internally to Sun, these are sometimes referred to as "watermarks".

An extent header is a consistency record and contains such information as the metadevice (soft partition) name, it's status, it's size, and a checksum. Each extent header 1 block (512 bytes) in size.

The following diagram shows an example 100MB slice (c1t0d0s0) and the extent headers (watermarks) that have been created on it. The command to make the soft partition shown was

   # metainit d1 -p c1t0d0s0 20m 
->>

There is always an extent header on the first and last blocks in the slice. Note that the 80MB of space left over from the creation of the soft partition can be used to make one or more additional soft partitions. Each additional soft partition will create an additional extent header to be created as well.


Mirroring Soft Partitions

Once you have created soft partitions, what can you do with them? Well, one thing to do is to create mirrors out of them. Unfortunately, even though a soft partition is a metadevice, they cannot serve directly as a submirror. For example:

   # metainit d10 -p c1t11d0s4 100m
d10: Soft Partition is setup
# metainit d20 -m d10
metainit: hostname: d10: invalid unit
Instead, you must first take the soft partition and create a simple concat/stripe out of it. For example:

   # metainit d10 -p c1t0d0s0 100m
d10: Soft Partition is setup
# metainit d20 1 1 d10
d20: Concat/Stripe is setup
# metainit d30 -m d20
d30: Mirror is setup

# metainit d11 -p c2t0d0s0 100m
d11: Soft Partition is setup
# metainit d21 1 1 d11
d21: Concat/Stripe is setup
# metattach d30 d21
d30: submirror d21 is attached

Once done, the resulting metastat output of the mirror will look like this:

   # metastat d30

d30: Mirror
Submirror 0: d20
State: Okay
Submirror 1: d21
State: Okay
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 204624 blocks

d20: Submirror of d30
State: Okay
Size: 204624 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
d10 0 No Okay

d10: Soft Partition
Component: c1t0d0s0
State: Okay
Size: 204800 blocks
Extent Start Block Block count
0 1 204800

d21: Submirror of d30
State: Okay
Size: 204624 blocks
Stripe 0:
Device Start Block Dbase State Hot Spare
d11 0 No Okay

d11: Soft Partition
Component: c2t0d0s0
State: Okay
Size: 204800 blocks
Extent Start Block Block count
0 1 204800


Combining Soft Partitions Together into a RAID5 Device

RAID5 devices can be made up of soft partitions directly. This example shows 4 soft partitions (from 4 separate slices) striped together to make a RAID5 device:

   # metainit d1 -p c1t0d0s0 10m
d1: Soft Partition is setup
# metainit d2 -p c2t0d0s0 10m
d2: Soft Partition is setup
# metainit d3 -p c3t0d0s0 10m
d3: Soft Partition is setup
# metainit d4 -p c4t0d0s0 10m
d4: Soft Partition is setup
# metainit d10 -r d1 d2 d3 d4
d10: RAID is setup

Once done, the resulting metastat output of the RAID5 device will look like this:

   # metastat d10

d10: RAID
State: Okay
Interlace: 32 blocks
Size: 59472 blocks
Original device:
Size: 60384 blocks
Device Start Block Dbase State Hot Spare
d1 330 No Okay
d2 330 No Okay
d3 330 No Okay
d4 330 No Okay

d1: Soft Partition
Component: c1t0d2s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 1 20480

d2: Soft Partition
Component: c1t0d4s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 1 20480

d3: Soft Partition
Component: c1t1d1s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 1 20480

d4: Soft Partition
Component: c1t1d3s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 1 20480


Using Soft Partitions for MetaTrans (UFS Logging) Devices

MetaTrans devices (UFS logging) can be built on top of soft partitions. Soft partitions can be used for the master device, the logging device, or both. In the following example, soft partitions are used for both the master and the logging device:

   # metainit d1 -p c1t0d0s0 500m
d1: Soft Partition is setup
# metainit d2 -p c2t0d0s0 50m
d2: Soft Partition is setup
# metainit d10 -t d1 d2
d1: Trans is setup

Once done, the resulting metastat output of the metatrans device will look like this:

   # metastat d10
d10: Trans
State: Okay
Size: 1024000 blocks
Master Device: d1
Logging Device: d2

d1: Soft Partition
Component: c1t1d3s0
State: Okay
Size: 1024000 blocks
Extent Start Block Block count
0 1 1024000

d2: Logging device for d10
State: Okay
Size: 102142 blocks

d2: Soft Partition
Component: c1t1d1s0
State: Okay
Size: 102400 blocks
Extent Start Block Block count
0 1 102400


Layering

Most of the time, soft partitions are made on a disk slice. However, there are certain situations where it can be beneficial to make a soft partition on top of an existing metadevice. This is referred to as layering.

For example, say you have a 90GB RAID5 device made up of 6 18GB disks. You can then take that 90GB device and "split it up" into many soft partitions. These many soft partitions then can be accessed as separate simple metadevices, although the data in them is protected by the RAID5 parity in the underlying device.

Soft partitions can be layered only on top of concat/stripes, mirrors, and RAID5 devices. Soft partitions cannot be layered on top of a metatrans device or directly on top of another soft partition.

Here is an example of layering soft partitions on top of an existing RAID5 metadevice. First, we create the RAID5 device, then soft partition that device into 3 100MB partitions (obviously, we could create more than just 3 soft partitions).

   # metainit d0 -r c1t0d2s0 c1t0d4s0 c1t1d1s0 c1t1d3s0
d0: RAID is setup

# metainit d1 -p d0 100m
d1: Soft Partition is setup
# metainit d2 -p d0 100m
d2: Soft Partition is setup
# metainit d3 -p d0 100m
d3: Soft Partition is setup

Each of the resulting soft partitions (d1, d2, and d3) can be accessed individually (i.e., newfs and mount).

Soft partitions can be built on top of an existing mirror device as well, just like we did above on the RAID5 device. In the following example, the mirror device (d0) is "carved up" into 3 smaller soft partitions.

   # metainit d10 1 1 c1t0d2s0
d10: Concat/Stripe is setup
# metainit d20 1 1 c2t0d0s0
d20: Concat/Stripe is setup
# metainit d0 -m d10 d20
d0: Mirror is setup

# metainit d1 -p d0 100m
d1: Soft Partition is setup
# metainit d2 -p d0 100m
d2: Soft Partition is setup
# metainit d3 -p d0 100m
d3: Soft Partition is setup

Soft partitions are not allowed to be parented by other soft partitions directly. For example:

   # metainit d1 -p c1t0d0s0 100m
d1: Soft Partition is setup
# metainit d2 -p d1 10m
metainit: hostname: d1: invalid unit
Soft partitions also cannot be built on top of trans (UFS logging) devices. For example:

   # metainit d1 -t d10 d20
d1: Trans is setup
# metainit d2 -p d1 100m
metainit: hostname: d1: invalid unit


Growing Soft Partitions

A soft partition can be grown by the use of the metattach command. There is no mechanism to shrink a soft partition.

   # metattach d0 10m
d0: Soft Partition has been grown

When additional space is added to an existing soft partition, the additional space is taken from any available space on the same device and might not be contiguous with the existing soft partition. Growing soft partitions must be done with free space in the same device as the current soft partition.

The following example shows how growing a soft partition will increase the size of the current extent:

   # metainit d1 -p c1t0d2s0 100m
d1: Soft Partition is setup
# metastat d1
d1: Soft Partition
Component: c1t0d2s0
State: Okay
Size: 204800 blocks
Extent Start Block Block count
0 1 204800

# metattach d1 50m
d1: Soft Partition has been grown
# metastat d1
d1: Soft Partition
Component: c1t0d2s0
State: Okay
Size: 307200 blocks
Extent Start Block Block count
0 1 307200

Note how after the metattach is run, there is still only one extent, but the (block count) has grown from 204800 (100MB) to 307200 (150MB).

In the following example, the extent cannot be grown, as it was above, because another soft partition is "in the way". Therefore, a second extent is created in the same slice.

   # metainit d1 -p c1t0d2s0 100m
d1: Soft Partition is setup
# metainit d2 -p c1t0d2s0 10m
d2: Soft Partition is setup
# metastat
d1: Soft Partition
Component: c1t0d2s0
State: Okay
Size: 204800 blocks
Extent Start Block Block count
0 1 204800

d2: Soft Partition
Component: c1t0d2s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 204802 20480

# metattach d1 50m
d1: Soft Partition has been grown
# metastat
d1: Soft Partition
Component: c1t0d2s0
State: Okay
Size: 307200 blocks
Extent Start Block Block count
0 1 204800
1 225283 102400

d2: Soft Partition
Component: c1t0d2s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 204802 20480

Note how d1 now has two non-contiguous extents that together make up the 307200 (150MB) blocks.

NOTE: Growing the metadevice does not modify the data or the filesystem inside the metadevice. If the metadevice contains a filesystem, you must use the appropriate command(s) to grow that filesystem after the metadevice has been grown.


Deleting Soft Partitions

This is achieved by using the metaclear command in the normal way:

   # metaclear d0
d0: Soft Partition is cleared
If other metadevices are using the soft partition, the metaclear will error with:

   metaclear: hostname: d0: metadevice in use


Using Soft Partitions with Disksets

There are no differences with soft partitioning in a diskset, other than having to specify the -s option on the commandline to specify the diskset name.

The only potential problem occurs when dealing with did disk devices that are in a SunCluster configuration. Unfortunately, the naming convention of the did devices is similar to that of SDS/SVM in that the disks are referred to as d#. This means that SDS/SVM could confuse a did disk with a metadevice when creating a soft partition.

The simple workaround to this problem is to use the full path to the did device on the metainint commandline in order to prevent any confusion.

For example, the following command to create a 1GB soft partition on /dev/did/rdsk/d7s0 would be invalid:

   # metainit -s set2 d0 -p d7s0 1g 
Instead, the correct command to run would be:

   # metainit -s set2 d0 -p /dev/did/rdsk/d7s0 1g 


How to list the soft partitions in a given slice

The metarecover command, with the -n and -v options, will display information about the soft partitons existing in a given slice.

The metarecover command actually scans the given slice for extent headers and prints the information that it finds about those headers.

In each slice/device, there are also 2 additional extent headers; one which preceeds the free space in the slice, and the one on the last block of the slice. These are printed as well. This is an easy way to determine how much free space is available in a slice for additional soft partitions.

   # metarecover -v -n /dev/rdsk/c1t0d0s0 -p
Verifying on-disk structures on c1t0d0s0.
The following extent headers were found on c1t0d0s0.
Name Seq# Type Offset Length
d0 0 ALLOC 0 20481
d1 0 ALLOC 20481 40961
NONE 0 END 17674901 1
NONE 0 FREE 61442 17613459
Found 2 soft partition(s) on c1t0d0s0.

In the above example, there were 2 soft partitions (d0 and d1) found on c1t0d0s0, as well as 17613458 blocks (approx 8.4GB) of unallocated free space.

IMPORTANT NOTE: The information printed by this command is relative to the extent header, not the soft partition itself. Therefore, the 'offset' is the starting location of the extent header, not the extent itself. Also, the 'length' given is the length of the extent plus the header. Therefore, in the example above, there are only 17613458 free blocks, not 17613459 blocks.

Because soft partitions can be layered above metadevices like mirrors or RAID5 devices (see layering, above), this command can also be run on them to determine the locations and sizes of the extent headers. In the example below, d0 is a RAID5 metadevice which has 4 soft partitions in it. There is no free space left in this device.

   # metarecover -v -n d0 -p
Verifying on-disk structures on d0.
The following extent headers were found on d0.
Name Seq# Type Offset Length
d1 0 ALLOC 0 204801
d2 0 ALLOC 204801 204801
d3 0 ALLOC 409602 204801
d99 0 ALLOC 614403 7573580
NONE 0 END 8187983 1
Found 4 soft partition(s) on d0.


Fragmentation

Fragmentation of free space will occur on a slice when there has been activity in creating, deleting, and possibly growing soft partitions. At this time, there is no method to defragment a disk.

For example, the following sequence of commands can result in some amount of fragmentation. First, create 2 10MB soft partitions on a slice.

   # metainit d1 -p c1t0d0s0 10m
d1: Soft Partition is setup
# metainit d2 -p c1t0d0s0 10m
d2: Soft Partition is setup

Then, remove the first 10MB soft partition and then create a 20MB soft partition.

   # metaclear d1
d1: Soft Partition is cleared
# metainit d3 -p c1t0d0s0 20m
d3: Soft Partition is setup
When the d3 metadevice was created, the 10MB of free space at the beginning of the slice is not used, because there is a contiguous 20MB space available further out that can be used instead. Therefore, the 10MB of free space is skipped over in favor of the first 20MB of contiguous space. The metarecover command will show the fragmentation (multiple free spaces):

   # metarecover -v -n c1t0d0s0 -p
Verifying on-disk structures on c1t0d0s0.
The following extent headers were found on c1t0d0s0.
Name Seq# Type Offset Length
d2 0 ALLOC 20481 20481
d3 0 ALLOC 40962 40961
NONE 0 END 2047247 1
NONE 0 FREE 81923 1965324
NONE 0 FREE 0 20481
Found 2 soft partition(s) on c1t0d0s0.


Recovering Soft Partitions

The 'metarecover' command is run when something has gone wrong. It should not be run except to recover from a catastrophic problem. There are two main functions that this command does. It can
  1. scan through the given slice and recreate the soft partitions that it finds there. this is good when moving a disk with soft partitions to a new machine. The option to use on the metarecover command is -d.
  2. reads through the current replica and creates the soft partitions on the given slice. This is good to run after a disk fails and gets replaced with a new one. The option to use on the metarecover command is -m.

Recreating Information in the Replica from the Extent Headers

Here is a very simple example showing a disk which had soft partitions created on it (in slice 0) on another host, which is being moved to a new machine. We wish to extract the soft partitions on this new machine. Currently, there are no metadevices created.

   # metastat 
This command scans the given slice (in this case, "c0t0d0s0") and, for each soft partition it finds in that slice, it puts an entry into the current replica. The data on the disk is not modified, and nothing on the slice specified is modified. All that happens is that the extent headers are read and information is written to the replica.

   # metarecover c0t0d0s0 -p -d
The following soft partitions were found and will be added to
your metadevice configuration.
Name Size No. of Extents
d1 61440 1
d2 20480 1
WARNING: You are about to add one or more soft partition
metadevices to your metadevice configuration. If there
appears to be an error in the soft partition(s) displayed
above, do NOT proceed with this recovery operation.

Are you sure you want to do this (yes/no)? yes

c0t0d0s0: Soft Partitions recovered from device.
Now, we can see the soft partition metadevices have been created for us:

   # metastat
d1: Soft Partition
Component: c0t0d0s0
State: Okay
Size: 61440 blocks
Extent Start Block Block count
0 120836 61440

d2: Soft Partition
Component: c0t0d0s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 20482 20480

Recreating Soft Partitions from Information in the Replica

This example essentially does the opposite of example 1. In this case, the actual extent headers on the disk have been lost, either because something wrote over them, or because the disk hosting the soft partitions had to be replaced with new disk drive. Although the replica shows the soft partitions to be "Okay":

   # metastat
d1: Soft Partition
Component: c0t0d0s0
State: Okay
Size: 61440 blocks
Extent Start Block Block count
0 120836 61440

d2: Soft Partition
Component: c0t0d0s0
State: Okay
Size: 20480 blocks
Extent Start Block Block count
0 20482 20480
there are no extent headers on the disk, so I/O to the disk will error out.

   # dd if=/dev/zero of=/dev/md/rdsk/d2
dd: /dev/md/rdsk/d2: open: I/O error
To check the disk to see if any extent headers exist on the disk, you can run the command

   # metarecover -n c0t0d0s0 -p
found incorrect magic number 0, expected 20000127.
No extent headers found on c0t0d0s0.
c0t0d0s0: On-disk structures invalid or no soft partitions found.
metarecover: hostname: d0: bad magic number in extent header
The above command confirms that there are no extent headers on the disk. To have the extent headers written out to the disk, according to the information currently in the replica, run the command

   # metarecover c0t0d0s0 -p -m
c0t0d0s0: Soft Partition metadb configuration is valid

WARNING: You are about to overwrite portions of c0t0d0s0
with soft partition metadata. The extent headers will be
written to match the existing metadb configuration. If
the device was not previously setup with this
configuration, data loss may result.

Are you sure you want to do this (yes/no)? yes

c0t0d0s0: Soft Partitions recovered from metadb
Now, the extent headers have been written to the disk, so I/O will work correctly now. Running the verify command again, we see

   # metarecover -n c0t0d0s0 -p
c0t0d0s0: Soft Partition metadb configuration is valid
c0t0d0s0: Soft Partition metadb matches extent header configuration

Taken from: http://www.sysunconfig.net/unixtips/soft-partitions.html

Saturday, April 26, 2008

Setuid, Setgid and Sticky Bit

setuid Permission

When setuid (set-user identification) permission is set on an executable file, a process that runs this file is granted access based on the owner of the file (usually root), rather than the user who created the process. This permission enables a user to access files and directories that are normally available only to the owner.

The setuid permission is shown as an s in the file permissions. For example, the setuid permission on the passwd command enables a user to change passwords, assuming the permissions of the root ID are the following:

castle% ls -l /usr/bin/passwd
-r-sr-sr-x 3 root sys 96796 Jul 15 21:23 /usr/bin/passwd
castle%


NOTE: Using setuid permissions with the reserved UIDs (0-99) from a program may not set the effective UID correctly. Instead, use a shell script to avoid using the reserved UIDs with setuid permissions.

You setuid permissions by using the chmod command to assign the octal value 4 as the first number in a series of four octal values. Use the following steps to setuid permissions:

1. If you are not the owner of the file or directory, become superuser.
2. Type chmod <4nnn> <filename> and press Return.
3. Type ls -l <filename> and press Return to verify that the permissions of the file have changed.

The following example sets setuid permission on the myprog file:

#chmod 4555 myprog
-r-sr-xr-x 1 winsor staff 12796 Jul 15 21:23 myprog
#

To minimize setuid problems, minimize the number of local setuid programs. If you write a setuid program, use the following guidelines to minimize security problems:

Do not write setuid shell scripts for any shell.
Do not use library routines that start slave shells.
Do not use execlp(3) and execvp() routines that duplicate the path-searching functionality of a shell.
Use full pathnames to identify files.
Only setuid to root when you need to.
Use the set effective user ID function, seteuid(2), to control setuid use.
Keep permissions on setuid programs restrictive.
Avoid secret back-door escapes in your code.

setgid Permission

The setgid (set-group identification) permission is similar to setuid, except that the effective group ID for the process is changed to the group owner of the file and a user is granted access based on permissions granted to that group. The /usr/bin/mail program has setgid permissions:

castle% ls -l /usr/bin/mail
-r-x—s—x 1 bin mail 64376 Jul 15 21:27 /usr/bin/mail
castle%

When setgid permission is applied to a directory, files subsequently created in the directory belong to the group the directory belongs to, not to the group the creating process belongs to. Any user who has write permission in the directory can create a file there; however, the file does not belong to the group of the user, but instead belongs to the group of the directory.

You can set setgid permissions by using the chmod command to assign the octal value 2 as the first number in a series of four octal values. Use the following steps to set setgid permissions:

1. If you are not the owner of the file or directory, become superuser.
2. Type chmod <2nnn> <filename> and press Return.
3. Type ls -l <filename> and press Return to verify that the permissions of the file have changed.

The following example sets setuid permission on the myprog2 file:

#chmod 2551 myprog2
#ls -l myprog2
-r-xr-s—x 1 winsor staff 26876 Jul 15 21:23 myprog2
#

Sticky Bit

The sticky bit on a directory is a permission bit that protects files within that directory. If the directory has the sticky bit set, only the owner of the file, the owner of the directory, or root can delete the file. The sticky bit prevents a user from deleting other users' files from public directories, such as uucppublic:

castle% ls -l /var/spool/uucppublic
drwxrwxrwt 2 uucp uucp 512 Sep 10 18:06 uucppublic
castle%

When you set up a public directory on a TMPFS temporary file system, make sure that you set the sticky bit manually.

You can set sticky bit permissions by using the chmod command to assign the octal value 1 as the first number in a series of four octal values. Use the following steps to set the sticky bit on a directory:

1. If you are not the owner of the file or directory, become superuser.
2. Type chmod <1nnn> <filename> and press Return.
3. Type ls -l <filename> and press Return to verify that the permissions of the file have changed.

The following example sets the sticky bit permission on the pubdir directory:

castle% chmod 1777 pubdir
castle% ls -l pubdir
drwxrwxrwt 2 winsor staff 512 Jul 15 21:23 pubdir



Taken from: Solaris Advanced System Administrator's Guide, Second Edition:Understanding System Security

Legato Networker commands and tips

List of Legato Networker commands and tips.

Copyright Avisit Solutions Limited. www.avisit.co.nz


Complete listing of legato Bullitins:
http://web1.legato.com/lefaq/bulls/
Frequently asked questions
http://www.backupcentral.com/networker-faq.html
The Networker Journal
http://www.drenpress.com/

Setup:
Schedule, Directives, retention, Browse Policy
Setup cron to check /usr/tmp

savepnpc
Check lck files in savepnpc groups (/nsr/res)
Save files to long term storage with NetWorker and performs pre and post processing
commands on a NetWorker client.
savepnpc performs pre/post-processing commands if any exists in the /nsr/res/.res file.


inquire Lists SCSI devices available.
ldunld Sends and load or unload command to the tape device.
jb_config Configure an autochanger
mminfo -m Get Media information from the Networker Database
Example :
mminfo -av -c chocbar -r "name,level,ssid,pssid" BPK678
pssid When part of a save set series, the
previous save set identifier in the series, zero for the
first or only save set in a series.
daemon.log Most usefull log
nsr_shutdown -a or -q Shutsdown networker
nsrck -m Checks media
nsrck -F | Fix client indexes. Clientname is optional
Indexes can be corrupted when stopping networker
nsrck -C Compress index
nsrck -c Rebuilds Client Indexes
nsrinfo NetWorker file index reporting command
nsrls List statistics of NetWorker index files
nsrim NetWorker index management program
nsrim -l Remove the oldest save set to decrease the size of the indexes.
nsrd Server daemon. Coordinates server operations.
nsrexecd Client/server communications daemon
savegrp -pvvv Run the probe step to backup a group (does not do anything)
savegrp Backup the specified group
nsrindexd File-index database management
nsrmmd Media Management (tape drives) daemon
nsrmmdbd Medai Database Management
nsrmm The nsrmm program provides a command line interface to manage the media
and backup devices used by NetWorker servers and storage nodes.
nsrjb Manipulate the jukeboxs
nsrjb -I To read the new tapes that are in the jukebox volumes (Inventory)
nsrjb -j DLT891 -O81 -Y -L -g -bDefault -f /dev/nrmt0h -S 1-1
To label tape in slot 1
nsrjb -j DLT891 -O84 -p -n -f /dev/nrmt0h -S 3-3
Verify volume in slot 3
nsrjb -j DLT891 -O85 -Y -L -g -bDefault -f /dev/nrmt0h -S 3-3
Label volume in slot 3
nsrjb -j DLT891 -O86 -p -n -f /dev/nrmt0h -S 4-4
Verify volume in slot 4
nsrjb -j DLT891 -O87 -Y -L -g -bDefault -f /dev/nrmt0h -S 4-4
Label tape in slot 4
nsrjb -L -S 5-19 To label the volumes in slots 5 through 19, use the -S option
This is what the manual provides.
nsrjb -u Unload volume from DLT
nsrjb -o recyclable BPK687 Set volume BPK87 to recyclable. NOTE You will never be able to recover these files
again. Not even with the scanner command.
nsrmm -d Delete a volume in the media database (when getting message duplicate name)
nsrmmdbd Media Management db daemon
nsrwatch Watch the progress of networker in a terminal mode.
nsrls list statistics of NetWorker index files
The nsrls program, when invoked without any options, prints the number of
files in client file index, the number of kilobytes that the client file index
currently requires, and the utilization of the client file index with respect to the
number of kilobytes allocated to its UNIX file.

nsrjb Juke Box manipulation and information
mmlocate Show location of media

nsradmin -s Terminal mode for nwadmin
savegrp -pvvv Run Group Group_name. If this group has several clients
then you can also specify the client name.
Run this command in cron if the group only has to be
backed up once a week. Deactivate the group in Legato.
scanner The scanner program directly reads NetWorker media (such as backup tapes,
optical disks, or files) to confirm the contents of a volume, to extract a save set
from a volume, or to rebuild the NetWorker online indexes. You can only run
this command as root. You must specify a device, which is usually one of the
device names used by the NetWorker server. If the device is a tape drive, it
must be a nonrewinding type.


Any script in the backup command must begin with nsr or save

Do not use remote user except with rman

skips in directives No more than 35 lines

Index management
--------------------
nsrls List statistics of NetWorker index files
nsrck -F Compress Indexes
nsrim NetWorker index management program

Problem Solving.
----------------
If the savegrp -pvvv Group_name does not come back with a list of filesystems then there could be
TCP/IP problem. Use the following commands and files to identify the problem.
1) Is default route correct? Use netstat -rn
2) Is the DNS correct. You might have to use resolf.conf to use the /etc/host file first.
This is done in svc.conf in Tru64 and /etc/nsswitch in Solaris.
3) Use nsrlookup
4) Use rcpinfo


Reports
-------

something like
mminfo -m -r 'volume, pool, state, volflags, location, %used, written'

will give you a E in state when the volume is recyclable(expired), an
r in volflags when its read only.

You can write querys using -q and just get tapes in the location of
"libraryname" or use grep like i do.

mminfo -m -t 'yesterday'
Will give all the backups yesterday
mminfo -m -t 'last week'
Will give all the backups last week

------------------
savepnpc

Client has savepnpc specified in the "Backup command:" field on server

/nsr/res/TEST.res file on client contains:

type: savepnpc;
precmd: /nsr/bin/precmd.sh;
pstcmd: /nsr/bin/pstcmd.sh;
timeout: "11:00pm";

When a savegroup starts the following happens (example using the group TEST):

The server starts the group. The server sees the client has savepnpc
specified as the backup command. The server contacts the client and
checks for a /nsr/res/TEST.res file. (If there is not one, a dummy res
file will be created.) The client executes the pre command/script
specified in the file (precmd: /nsr/bin/precmd.sh;). It creates a tmp
file indicating that savepnpc is running, /nsr/tmp/TEST.tmp It also
executes a process that monitors the status of the saves waiting for
completion and/or the timeout value specified in /nsr/res/TEST.res.
(timeout: "11:00pm";) After the pre script successfully completes, the
server then initiates the filesystem saves. During this time the client
is constantly checking the server to see if the saves are completed. As
soon as they have completed (or the timeout value has been reached), the
client executes the post script specified in the /nsr/res/TEST.res file.
(pstcmd: /nsr/bin/pstcmd.sh) It then removes the /nsr/tmp/TEST.tmp file.

NOTES:

The pre/post scripts need to have the necessary environment setup in
them, as savepnpc does not pass any kind of environment to the scripts.
The start/stop of the pre and post commands are recorded in
/nsr/logs/savepnpc.log If the pre command fails (exit status non-zero),
the saves for that client will abort and not be run. It will also not
start the post command process, so the post script will never run and
the /nsr/tmp/TEST.tmp file will be left. You will need to remove this by
hand. If a savegroup session is manually aborted or stopped on the
server, the /nsr/tmp/TEST.tmp file is left. (This is because the server
allows you to restart it later.) Also, because an abort does not clear
up the work list for the client,the client still thinks there are saves
to be completed and the post script will not run. If a new savegroup
session is started and there is an existing /nsr/tmp/TEST.tmp file, it
will skip the pre/post commands; however it will run the filesystem save
sessions.

Taken from: http://www.georgenet.net/oracle/files/reference/networker.txt

Crash Dump Analysis on Solaris

Crash Dump Analysis on Solaris

Introduction

This document attempts to provide a high-level introduction to handling basic crash dump analysis on Sun servers. A sample procedure is included which can be adopted to any organization for uniform handling of Sun server crashes. The term 'Crash Dump Analysis' may be a bit misleading in the context of this document. Coverage of actual analysis of the system crash dump using a debugger is not covered--Sun has an excellent instructor-led training class on this topic. Most System Administrators at most organizations will never have to use a debugger on a crash dump--this is typically a service provided by Sun with a service contract. In light of this, this document covers introductory materials regarding server crashes and preparing the necessary information to present to Sun when a service call is opened.

What Happens After a Crash?

When a panic occurs on a Solaris system, a message describing the error is usually echoed to the system console. The system will then attempt to write out the contents of the physical memory to a predetermined dump device, which is usually a dedicated disk partition, or the system swap partition. Once this is completed, the system is then rebooted.

Once the system begins rebooting, a startup script will call the savecore utility, if enabled. This command will perform a few tasks on the memory dump. First it will check to make sure that the crash dump corresponds to the running operating system. If the dump passes this test, savecore will then begin to copy the crash dump from the dedicated dump device to the directory /var/crash/`uname -n', or some other predetermined device. The dump is written out to two files, unix.n and vmcore.n, where n is an sequential integer identifying this particular crash. Finally, savecore logs a reboot using the LOG_AUTH syslog facility.

A sample memory dump of a system named testbox appears as follows:

# ls -l /var/crash/testbox
total 1544786
-rw-r--r-- 1 root root 2 Jun 15 16:02 bounds
-rw-r--r-- 1 root root 670367 Jun 15 16:00 unix.0
-rw-r--r-- 1 root root 790110208 Jun 15 16:02 vmcore.0

Various options related to performing the actual crash dump and the savecore functions can be set using the dumpadm command. This utility allows the administrator to determine the dedicated dump device, the directory savecore will write to, and whether or not savecore runs at all. In addition, the /etc/init.d/savecore initilization script is the actual script run at bootup which executes savecore.

Typical output from dumpadm for the system testbox appears as follows:

# dumpadm
Dump content: kernel pages
Dump device: /dev/dsk/c0t0d0s3 (swap)
Savecore directory: /var/crash/testbox
Savecore enabled: yes


What Causes a Crash?

Fatal operating system errors can be caused by bugs in the operating system, its associated device drivers and loadable modules, or by faulty hardware. Whatever the cause, the crash dump itself provides invaluable information to a Sun Support Engineer (if you are lucky enough to have a support contract) to aid in diagnosing the problem.

What To Do In Case of a Crash?

Any action taken when a Sun server crashes is obviously going to depend on the local policies and procedures in place at your organization. The presence of a Sun Service Agreement and its level will also affect your response to a crash.

What follows is an example of a typical procedure for dealing with a crash. This procedure was created based on real world experiences but does not reflect any particular real-world organization. For the purposes of illustration, assume that the organization in this example has a Platinum level contract with Sun.

The first step in analysing a crash is to determine if the necessary evidence is present in order to find a root cause. To begin, scan /var/adm/messages for any warnings or errors. Many crashes will leave evidence in the logs, such as which CPU caught the panic or which memory DIMM had errors. Often Sun engineers can diagnose the cause of a crash based on this information alone.

Next, check /var/crash/`uname -n` for a crash dump. If one is not present, confirm that savecore is enabled. Try running savecore -v if it was not previously enabled. It would also be a good idea to run prtdiag at this time to determine if there are any egregious hardware faults.

Armed with this information, open a call with Sun. Take note of the case ID number. For purposes of this example the case ID will be 123456. The Sun engineer may be able to diagnose the fault based on the panic strings or error messages from /var/adm/messages, or they may require the actual crash dump for analysis. Luckily there are two tools, CTEact (ACT), and explorer, which cull useful information from the crash dump and the system making it unecessary to upload the actual crash dump (which could be gigabytes in size).

Use the following steps to generate the ACT analysis of that core file to send to Sun:

Create a temporary upload directory. This directory will hold the output of these programs and will eventually be uploaded to Sun.

# mkdir /tmp/upload
# cd /var/crash/`uname -n`
# /opt/CTEact/bin/act -n unix.0 -d vmcore.0 > /tmp/upload/act_out

Install (if necessary) and run the explorer script as follows:

# ./explorer

The explorer script will prompt you for some information. Do not select email output. The script will create both a subdirectory and a uuencoded file containing the system audit. Copy the uuencoded system audit output to the /tmp/upload directory. For example:

# cp explorer.80b0c1cc.uu /tmp/upload

Tar and compress the output for upload to Sun:

# cd /tmp
# mv upload 123456
# tar -cvf 123456.tar 123456
# gzip 123456.tar

Finally, FTP the output to Sun:

# ftp sunsolve.sun.com
ftp> username: ftp
ftp> password:
ftp> bin
ftp> put 123456.tar.gz
ftp> quit

At this point you can remove the temporary upload directory:

# /bin/rm -rf /tmp/123456

Retain the original core files in /var/crash/`uname -n` until the case is closed. Once the case is closed by Sun, remove these file to free up disk space.

Conclusion

Those who wish to do more than simply upload information to Sun and let them analyse the crash dump should strongly consider taking Sun's "Core Dump Analysis" course.

For more information, particularly on self-analysis of crash dumps, see Printceton University Solaris 2.x Core Dump Analysis (www.princeton.edu/~unix/Solaris/troubleshoot/savecore.html).

Taken from :Crash Dump Analysis on Solaris
Copyright ©2008 PreciousTulips. All rights reserved.