vi colors
When I edit a text file in vi, I find it much easier to read if the syntax is color highlighted. There are 2 steps to enabling this. First, add an alias for vi (or vim) to your ~/.bashrc file as follows:
#
# Enable color support for vi
#
alias vi='TERM=xtermc vim'
You can read the gory details about why this needs to be done in bug 1641 - xterm terminfo entry doesn't support color.
You also need to tell vi to use syntax coloring. Adding the following to your ~/.vimrc file (create one if it doesn't yet exist):
syntax on
Monday, November 9, 2009
Tuesday, October 13, 2009
Is it possible to designate a node as the primary node for the file system mounted at mount_point?
Is it possible to designate a node as the primary node for the file system mounted at mount_point?
--------------------------------------------------------------------------------
Details:
Yes, it is possible to set a node as the primary node.
# /opt/VRTSvxfs/sbin/fsclustadm setprimary /mount_point
The setprimary option designates the local node (that is, the node on which fsclustadm is issued) as the primary node for the file system mounted at mount_point. Please refer to the fsclustadm man pages for more information.
Example:
Burger:/#fsclustadm -v showprimary /sharevol
fries
Burger:/#fsclustadm setprimary /sharevol
Burger:/#fsclustadm -v showprimary /sharevol
burger
Courtesy: http://seer.entsupport.symantec.com/docs/239466.htm
--------------------------------------------------------------------------------
Details:
Yes, it is possible to set a node as the primary node.
# /opt/VRTSvxfs/sbin/fsclustadm setprimary /mount_point
The setprimary option designates the local node (that is, the node on which fsclustadm is issued) as the primary node for the file system mounted at mount_point. Please refer to the fsclustadm man pages for more information.
Example:
Burger:/#fsclustadm -v showprimary /sharevol
fries
Burger:/#fsclustadm setprimary /sharevol
Burger:/#fsclustadm -v showprimary /sharevol
burger
Courtesy: http://seer.entsupport.symantec.com/docs/239466.htm
Thursday, September 10, 2009
Monday, August 24, 2009
Solaris Patches on Veritas Encapsulated Root disk
How to apply Solaris Patches on Encapsulated Root disk..
--------------------------------------------------------------------------------
Details:
Note: the following are used in the following procedures.
a) Root Disk - c1t0d0s2
b) Root Mirror Disk - c1t0d1s2
Procedure :
1) Make sure that you also have full system backup either on tape or other disk. The VRTSexplorer can also be run before installing the patch.
2) If the rootdisk is mirrored, break and remove the mirror and plexes from 'rootdg' disk group using following steps. In steps below, c1t0d1 device is the mirror disk.
#vxplex -g rootdg dis var-02
#vxplex -g rootdg dis usr-02
#vxplex -g rootdg dis swapvol-02
#vxplex -g rootdg dis rootvol-02
#vxplex -g rootdg dis opt-02
To remove these plexes as follows..
#vxedit -g rootdg rm var-02
#vxedit -g rootdg rm usr-02
#vxedit -g rootdg rm swapvol-02
#vxedit -g rootdg rm rootvol-02
#vxedit -g rootdg rm opt-02
Verify that the root disk is not mirrored from "vxprint -htg rootdg", and that the root-mirror disk and sub-sequent plexes/subdisks are removed from configuration.
3) Manually unencapsulate the root device and boot it on standard Solaris slices.
Boot the system now using CDROM (#boot cdrom -s)
a) mount /dev/dsk/c1t0d0s0 /a (rootdisk)
b) cp -p /a/etc/vfstab.prevm /a/etc/vfstab
Make a backup of /a/etc/system and then edit it:
c) cp -p /a/etc/system /a/etc/system.orig
d) vi /a/etc/system and remove the two VxVM lines "rootdev:/pseudo/vxio@0:0" & "set vxio:vol_rootdev_is_volume=1"
Note: You may put a "*" in front of the VXFS related entries as well in "/etc/system" file.
e) Now make sure Volume Manager does not start on the next boot.
# touch /a/etc/vx/reconfig.d/state.d/install-db
f) # umount /a
g) Reboot (Make sure here you boot without any error and can mount all the OS partitions like /opt, /var, /usr etc as per VFSTAB.
4) Install/upgrade Solaris patches as per procedure given by SUN.
5) After successful installation and once the system is rebooted in multi-user mode using root partitions/slices, undo changes made in step #3 to start Volume Manager.
#rm /etc/vx/reconfig.d/state.d/install-db
# vxiod set 10
# vxconfigd -m disable
# vxdctl enable
6) Note that one can also re-encapsulate the boot drive. The prtvtoc for root disk must be verified to make sure the "private region" (tag 14 and 15) do not exist. Note that you may have to get rid of the old rootdg by using the
following:
# vxdg destroy rootdg
7) Encapsulate the root disk(c1t0d0) using #vxdiskadm option 2 System will reboot 2 times in this process.
8) Once system is up, check #vxprint -htg rootdg (you should view the volumes for partitions like rootvol, opt, var etc..
9) #/etc/vx/bin/vxdisksetup -i c1t1d0 format=sliced (Initializing the disk for mirror)
10) #vxdiskadm - option 6 - to mirror the volumes on disk.
( in the above, select/enter source disk(root disk) first and then the destination (root-mirror)
11) Once the mirror is completed, you may check the reboot of the server using both the devices.
Reference: http://support.veritas.com/docs/317858
--------------------------------------------------------------------------------
Details:
Note: the following are used in the following procedures.
a) Root Disk - c1t0d0s2
b) Root Mirror Disk - c1t0d1s2
Procedure :
1) Make sure that you also have full system backup either on tape or other disk. The VRTSexplorer can also be run before installing the patch.
2) If the rootdisk is mirrored, break and remove the mirror and plexes from 'rootdg' disk group using following steps. In steps below, c1t0d1 device is the mirror disk.
#vxplex -g rootdg dis var-02
#vxplex -g rootdg dis usr-02
#vxplex -g rootdg dis swapvol-02
#vxplex -g rootdg dis rootvol-02
#vxplex -g rootdg dis opt-02
To remove these plexes as follows..
#vxedit -g rootdg rm var-02
#vxedit -g rootdg rm usr-02
#vxedit -g rootdg rm swapvol-02
#vxedit -g rootdg rm rootvol-02
#vxedit -g rootdg rm opt-02
Verify that the root disk is not mirrored from "vxprint -htg rootdg", and that the root-mirror disk and sub-sequent plexes/subdisks are removed from configuration.
3) Manually unencapsulate the root device and boot it on standard Solaris slices.
Boot the system now using CDROM (#boot cdrom -s)
a) mount /dev/dsk/c1t0d0s0 /a (rootdisk)
b) cp -p /a/etc/vfstab.prevm /a/etc/vfstab
Make a backup of /a/etc/system and then edit it:
c) cp -p /a/etc/system /a/etc/system.orig
d) vi /a/etc/system and remove the two VxVM lines "rootdev:/pseudo/vxio@0:0" & "set vxio:vol_rootdev_is_volume=1"
Note: You may put a "*" in front of the VXFS related entries as well in "/etc/system" file.
e) Now make sure Volume Manager does not start on the next boot.
# touch /a/etc/vx/reconfig.d/state.d/install-db
f) # umount /a
g) Reboot (Make sure here you boot without any error and can mount all the OS partitions like /opt, /var, /usr etc as per VFSTAB.
4) Install/upgrade Solaris patches as per procedure given by SUN.
5) After successful installation and once the system is rebooted in multi-user mode using root partitions/slices, undo changes made in step #3 to start Volume Manager.
#rm /etc/vx/reconfig.d/state.d/install-db
# vxiod set 10
# vxconfigd -m disable
# vxdctl enable
6) Note that one can also re-encapsulate the boot drive. The prtvtoc for root disk must be verified to make sure the "private region" (tag 14 and 15) do not exist. Note that you may have to get rid of the old rootdg by using the
following:
# vxdg destroy rootdg
7) Encapsulate the root disk(c1t0d0) using #vxdiskadm option 2 System will reboot 2 times in this process.
8) Once system is up, check #vxprint -htg rootdg (you should view the volumes for partitions like rootvol, opt, var etc..
9) #/etc/vx/bin/vxdisksetup -i c1t1d0 format=sliced (Initializing the disk for mirror)
10) #vxdiskadm - option 6 - to mirror the volumes on disk.
( in the above, select/enter source disk(root disk) first and then the destination (root-mirror)
11) Once the mirror is completed, you may check the reboot of the server using both the devices.
Reference: http://support.veritas.com/docs/317858
Friday, August 21, 2009
Amanda Backup - Restore / Recover
Some Useful Commands
amrecover To recover files & directory inside the dataset
amrestore To restore the entire diskset
Status of the Tape Library,
#/usr/local/sbin/mtx -f /dev/changer status
To know the last taken backup details for the server bsma02 & the file system /opt,
# amadmin Full find bsma02 /opt/bmc/Datastore/oradata/.zfs/snapshot/today/
To know the status of most recent backup run,
#/opt/sfw/sbin/amstatus Full
Move a Tape from one slot [10] to another slot [65]
#/usr/local/sbin/mtx -f /dev/changer transfer 10 65
To label & enable the tape [ILO612L1] in Slot [10]
# /opt/sfw/sbin/amlabel Full ILO612L1 slot 10
Recover using amrecover utility
amrecover is the interactive utility in Amanda to recover the files and directories.
Valid amrecover utility sub commands are:
add path1 ... - add to extraction list (shell wildcards)
addx path1 ... - add to extraction list (regular expressions)
cd directory - change cwd on virtual file system (shell wildcards)
cdx directory - change cwd on virtual file system (regular expressions)
clear - clear extraction list
delete path1 ... - delete from extraction list (shell wildcards)
deletex path1 ... - delete from extraction list (regular expressions)
extract - extract selected files from tapes
exit
help
history - show dump history of disk
list [filename] - show extraction list, optionally writing to file
lcd directory - change cwd on local file system
ls - list directory on virtual file system
lpwd - show cwd on local file system
mode - show the method used to extract SMB shares
pwd - show cwd on virtual file system
quit
listdisk [diskdevice] - list disks
setdate {YYYY-MM-DD|--MM-DD|---DD} - set date of look
setdisk diskname [mountpoint] - select disk on dump host
sethost host - select dump host
settape [host:][device|default] - select tape server and/or device
setmode smb|tar - select the method used to extract SMB shares
Steps need to be followed:
Note: Compare the given steps with below given example which would help you to understand easily.
1. Initiate the amrecover command where the restore has to be performed.
Better create directory called ‘restore’ and from there try to recover which would help you not to overwrite files if any.
2. Even you can set this restore directory by command “lcd directory” at amrecover prompt & verify via “lpwd” command.
3. You can set the host where the recover is needed by, “sethost hostname” command.
4. List the disk sets configured on the hosts via “listdisk” command
5. Set the disk via “diskset dir” command
6. Using add & delete command add the files & directories which need to be recovered.
7. You can see the required Tape detail to restore by “list” command after adding the files & directories.
Note the Tape which should be required to recover the data. If required tape is not in tape library, bring it from offsite & load.
8. Extract the data by “extract” command and quit.
Example:
bash-2.05# /opt/sfw/sbin/amrecover Full
AMRECOVER Version 2.5.0p2. Contacting server on amanda ...
220 amanda AMANDA index server (2.5.0p2) ready.
200 Access OK
Setting restore date to today (2009-08-20)
200 Working date set to 2009-08-20.
Scanning /opt/amanda/Full...
Scanning /data0/amanda/Full...
Scanning /data1/amanda/Full...
Scanning /data2/amanda/Full...
200 Config set to Full.
200 Dump host set to amanda.
Trying disk / ...
$CWD '/' is on disk '/' mounted at '/'.
200 Disk set to /.
/
amrecover> sethost bsma02
200 Dump host set to bsma02.
amrecover> setdate ---05
200 Working date set to 2009-08-05.
amrecover> listdisk
200- List of disk for host bsma02
201- /
201- /usr
201- /var
201- /opt
201- /export/home
201- /opt/bmc/Datastore/oradata/.zfs/snapshot/today/
200 List of disk for host bsma02
amrecover> setdisk /opt/bmc/Datastore/oradata/.zfs/snapshot/today/
200 Disk set to /opt/bmc/Datastore/oradata/.zfs/snapshot/today/.
amrecover> ls
2009-08-04 rod/
2009-08-04 BMCPDS/
2009-08-04 .
amrecover> cd BMCPDS
/opt/bmc/Datastore/oradata/.zfs/snapshot/today//BMCPDS
amrecover> ls
2009-08-04 users01.dbf
2009-08-04 undotbs01.dbf
2009-08-04 tools01.dbf
2009-08-04 temp01.dbf
2009-08-04 system01.dbf
2009-08-04 sysaux01.dbf
2009-08-04 redo3b.log
2009-08-04 redo3a.log
2009-08-04 redo2b.log
2009-08-04 redo2a.log
2009-08-04 redo1b.log
2009-08-04 redo1a.log
2009-08-04 TESTSPACE01.dbf
2009-08-04 PV02_01.dbf
2009-08-04 PV01_01.dbf
2009-08-04 PSDP01_01.dbf
2009-08-04 PE01_02.dbf
2009-08-04 PE01_01.dbf
2009-08-04 NSDP01_01.dbf
2009-08-04 INDEX04_01.dbf
2009-08-04 INDEX03_01.dbf
2009-08-04 INDEX02_01.dbf
2009-08-04 INDEX01_01.dbf
2009-08-04 DATA04_01.dbf
2009-08-04 DATA03_01.dbf
2009-08-04 DATA02_01.dbf
2009-08-04 DATA01_01.dbf
2009-08-04 CONTROL2.CTL
2009-08-04 CONTROL1.CTL
2009-08-04 ARTMPF.dbf
2009-08-04 ARSYS.dbf
2009-08-04 .
amrecover> add users01.dbf
Added /BMCPDS/users01.dbf
amrecover> list
TAPE ILO617L1:65 LEVEL 0 DATE 2009-08-04
/BMCPDS/users01.dbf
amrecover> extract
Extracting files using tape drive chg-zd-mtx on host amanda.
The following tapes are needed: ILO623L1
Restoring files into directory /bsma02/opt/bmc/Datastore/oradata/restore
Continue [?/Y/n]? y
Extracting files using tape drive chg-zd-mtx on host amanda.
Load tape ILO617L1 now
Continue [?/Y/n/s/t]? y
. users01.dbf
amrecover>quit
200 Good bye.
bash-2.05#
Restore using amrestore command
You can not recover the whole disk set using amrecover utility. You can only recover directories & files inside the disk set.
But using amrestore you can restore the entire disk set.
Use the amadmin command åRun by Amanda user¨to find out the Tape, Backup Level & file information to restore as below.
$ /opt/sfw/sbin/amadmin Full find bsma02 /var
Warning: no log files found for tape ILO626L1 written 2009-08-21
Scanning /opt/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data0/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data1/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data2/amanda/Full...
20090821000900: found Amanda directory.
Warning: no log files found for tape ILO626L1 written 2009-08-21
Scanning /opt/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data0/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data1/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data2/amanda/Full...
20090821000900: found Amanda directory.
date host disk lv tape or file file part status
2009-01-02 bsma02 /var 0 ILO624L1 16 -- OK
2009-02-04 bsma02 /var 1 ILO606L1 18 -- OK
2009-07-25 bsma02 /var 1 ILO600L1 7 -- OK
2009-07-26 bsma02 /var 1 ILO600L1 31 -- OK
2009-07-27 bsma02 /var 0 ILO600L1 118 -- OK
2009-07-29 bsma02 /var 1 ILO622L1 2 -- OK
2009-07-31 bsma02 /var 1 ILO602L1 10 -- OK
2009-08-01 bsma02 /var 1 ILO602L1 123 -- OK
2009-08-02 bsma02 /var 0 ILO607L1 11 -- OK
2009-08-03 bsma02 /var 1 ILO603L1 57 -- OK
2009-08-04 bsma02 /var 1 ILO617L1 10 -- OK
2009-08-05 bsma02 /var 1 ILO615L1 4 -- OK
2009-08-07 bsma02 /var 1 ILO625L1 40 -- OK
2009-08-08 bsma02 /var 0 ILO620L1 16 -- OK
2009-08-09 bsma02 /var 1 ILO613L1 11 -- OK
2009-08-10 bsma02 /var 1 ILO612L1 11 -- OK
2009-08-11 bsma02 /var 1 ILO611L1 4 -- OK
2009-08-12 bsma02 /var 1 ILO616L1 4 -- OK
2009-08-13 bsma02 /var 1 ILO601L1 2 -- OK
2009-08-14 bsma02 /var 1 ILO619L1 59 -- OK
2009-08-15 bsma02 /var 0 ILO623L1 42 -- OK
2009-08-16 bsma02 /var 1 ILO621L1 10 -- OK
2009-08-17 bsma02 /var 1 ILO605L1 5 -- OK
2009-08-18 bsma02 /var 1 ILO618L1 5 -- OK
2009-08-19 bsma02 /var 1 ILO609L1 13 -- OK
2009-08-20 bsma02 /var 1 ILO608L1 4 -- OK
$
Restore the disk set using amrestore command.
You can mount the remote host if any using NFS and try restore.
# /opt/sfw/sbin/amrestore –f42 ILO623L1 bsma02 /var
The above command would create the file bsma02._var.20090815.0 in the current directory.
Using tar command, extract the data in the destination directory.
#tar xvBf –
Your data is restored now!!
amrecover To recover files & directory inside the dataset
amrestore To restore the entire diskset
Status of the Tape Library,
#/usr/local/sbin/mtx -f /dev/changer status
To know the last taken backup details for the server bsma02 & the file system /opt,
# amadmin Full find bsma02 /opt/bmc/Datastore/oradata/.zfs/snapshot/today/
To know the status of most recent backup run,
#/opt/sfw/sbin/amstatus Full
Move a Tape from one slot [10] to another slot [65]
#/usr/local/sbin/mtx -f /dev/changer transfer 10 65
To label & enable the tape [ILO612L1] in Slot [10]
# /opt/sfw/sbin/amlabel Full ILO612L1 slot 10
Recover using amrecover utility
amrecover is the interactive utility in Amanda to recover the files and directories.
Valid amrecover utility sub commands are:
add path1 ... - add to extraction list (shell wildcards)
addx path1 ... - add to extraction list (regular expressions)
cd directory - change cwd on virtual file system (shell wildcards)
cdx directory - change cwd on virtual file system (regular expressions)
clear - clear extraction list
delete path1 ... - delete from extraction list (shell wildcards)
deletex path1 ... - delete from extraction list (regular expressions)
extract - extract selected files from tapes
exit
help
history - show dump history of disk
list [filename] - show extraction list, optionally writing to file
lcd directory - change cwd on local file system
ls - list directory on virtual file system
lpwd - show cwd on local file system
mode - show the method used to extract SMB shares
pwd - show cwd on virtual file system
quit
listdisk [diskdevice] - list disks
setdate {YYYY-MM-DD|--MM-DD|---DD} - set date of look
setdisk diskname [mountpoint] - select disk on dump host
sethost host - select dump host
settape [host:][device|default] - select tape server and/or device
setmode smb|tar - select the method used to extract SMB shares
Steps need to be followed:
Note: Compare the given steps with below given example which would help you to understand easily.
1. Initiate the amrecover command where the restore has to be performed.
Better create directory called ‘restore’ and from there try to recover which would help you not to overwrite files if any.
2. Even you can set this restore directory by command “lcd directory” at amrecover prompt & verify via “lpwd” command.
3. You can set the host where the recover is needed by, “sethost hostname” command.
4. List the disk sets configured on the hosts via “listdisk” command
5. Set the disk via “diskset dir” command
6. Using add & delete command add the files & directories which need to be recovered.
7. You can see the required Tape detail to restore by “list” command after adding the files & directories.
Note the Tape which should be required to recover the data. If required tape is not in tape library, bring it from offsite & load.
8. Extract the data by “extract” command and quit.
Example:
bash-2.05# /opt/sfw/sbin/amrecover Full
AMRECOVER Version 2.5.0p2. Contacting server on amanda ...
220 amanda AMANDA index server (2.5.0p2) ready.
200 Access OK
Setting restore date to today (2009-08-20)
200 Working date set to 2009-08-20.
Scanning /opt/amanda/Full...
Scanning /data0/amanda/Full...
Scanning /data1/amanda/Full...
Scanning /data2/amanda/Full...
200 Config set to Full.
200 Dump host set to amanda.
Trying disk / ...
$CWD '/' is on disk '/' mounted at '/'.
200 Disk set to /.
/
amrecover> sethost bsma02
200 Dump host set to bsma02.
amrecover> setdate ---05
200 Working date set to 2009-08-05.
amrecover> listdisk
200- List of disk for host bsma02
201- /
201- /usr
201- /var
201- /opt
201- /export/home
201- /opt/bmc/Datastore/oradata/.zfs/snapshot/today/
200 List of disk for host bsma02
amrecover> setdisk /opt/bmc/Datastore/oradata/.zfs/snapshot/today/
200 Disk set to /opt/bmc/Datastore/oradata/.zfs/snapshot/today/.
amrecover> ls
2009-08-04 rod/
2009-08-04 BMCPDS/
2009-08-04 .
amrecover> cd BMCPDS
/opt/bmc/Datastore/oradata/.zfs/snapshot/today//BMCPDS
amrecover> ls
2009-08-04 users01.dbf
2009-08-04 undotbs01.dbf
2009-08-04 tools01.dbf
2009-08-04 temp01.dbf
2009-08-04 system01.dbf
2009-08-04 sysaux01.dbf
2009-08-04 redo3b.log
2009-08-04 redo3a.log
2009-08-04 redo2b.log
2009-08-04 redo2a.log
2009-08-04 redo1b.log
2009-08-04 redo1a.log
2009-08-04 TESTSPACE01.dbf
2009-08-04 PV02_01.dbf
2009-08-04 PV01_01.dbf
2009-08-04 PSDP01_01.dbf
2009-08-04 PE01_02.dbf
2009-08-04 PE01_01.dbf
2009-08-04 NSDP01_01.dbf
2009-08-04 INDEX04_01.dbf
2009-08-04 INDEX03_01.dbf
2009-08-04 INDEX02_01.dbf
2009-08-04 INDEX01_01.dbf
2009-08-04 DATA04_01.dbf
2009-08-04 DATA03_01.dbf
2009-08-04 DATA02_01.dbf
2009-08-04 DATA01_01.dbf
2009-08-04 CONTROL2.CTL
2009-08-04 CONTROL1.CTL
2009-08-04 ARTMPF.dbf
2009-08-04 ARSYS.dbf
2009-08-04 .
amrecover> add users01.dbf
Added /BMCPDS/users01.dbf
amrecover> list
TAPE ILO617L1:65 LEVEL 0 DATE 2009-08-04
/BMCPDS/users01.dbf
amrecover> extract
Extracting files using tape drive chg-zd-mtx on host amanda.
The following tapes are needed: ILO623L1
Restoring files into directory /bsma02/opt/bmc/Datastore/oradata/restore
Continue [?/Y/n]? y
Extracting files using tape drive chg-zd-mtx on host amanda.
Load tape ILO617L1 now
Continue [?/Y/n/s/t]? y
. users01.dbf
amrecover>quit
200 Good bye.
bash-2.05#
Restore using amrestore command
You can not recover the whole disk set using amrecover utility. You can only recover directories & files inside the disk set.
But using amrestore you can restore the entire disk set.
Use the amadmin command åRun by Amanda user¨to find out the Tape, Backup Level & file information to restore as below.
$ /opt/sfw/sbin/amadmin Full find bsma02 /var
Warning: no log files found for tape ILO626L1 written 2009-08-21
Scanning /opt/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data0/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data1/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data2/amanda/Full...
20090821000900: found Amanda directory.
Warning: no log files found for tape ILO626L1 written 2009-08-21
Scanning /opt/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data0/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data1/amanda/Full...
20090821000900: found Amanda directory.
Scanning /data2/amanda/Full...
20090821000900: found Amanda directory.
date host disk lv tape or file file part status
2009-01-02 bsma02 /var 0 ILO624L1 16 -- OK
2009-02-04 bsma02 /var 1 ILO606L1 18 -- OK
2009-07-25 bsma02 /var 1 ILO600L1 7 -- OK
2009-07-26 bsma02 /var 1 ILO600L1 31 -- OK
2009-07-27 bsma02 /var 0 ILO600L1 118 -- OK
2009-07-29 bsma02 /var 1 ILO622L1 2 -- OK
2009-07-31 bsma02 /var 1 ILO602L1 10 -- OK
2009-08-01 bsma02 /var 1 ILO602L1 123 -- OK
2009-08-02 bsma02 /var 0 ILO607L1 11 -- OK
2009-08-03 bsma02 /var 1 ILO603L1 57 -- OK
2009-08-04 bsma02 /var 1 ILO617L1 10 -- OK
2009-08-05 bsma02 /var 1 ILO615L1 4 -- OK
2009-08-07 bsma02 /var 1 ILO625L1 40 -- OK
2009-08-08 bsma02 /var 0 ILO620L1 16 -- OK
2009-08-09 bsma02 /var 1 ILO613L1 11 -- OK
2009-08-10 bsma02 /var 1 ILO612L1 11 -- OK
2009-08-11 bsma02 /var 1 ILO611L1 4 -- OK
2009-08-12 bsma02 /var 1 ILO616L1 4 -- OK
2009-08-13 bsma02 /var 1 ILO601L1 2 -- OK
2009-08-14 bsma02 /var 1 ILO619L1 59 -- OK
2009-08-15 bsma02 /var 0 ILO623L1 42 -- OK
2009-08-16 bsma02 /var 1 ILO621L1 10 -- OK
2009-08-17 bsma02 /var 1 ILO605L1 5 -- OK
2009-08-18 bsma02 /var 1 ILO618L1 5 -- OK
2009-08-19 bsma02 /var 1 ILO609L1 13 -- OK
2009-08-20 bsma02 /var 1 ILO608L1 4 -- OK
$
Restore the disk set using amrestore command.
You can mount the remote host if any using NFS and try restore.
# /opt/sfw/sbin/amrestore –f42 ILO623L1 bsma02 /var
The above command would create the file bsma02._var.20090815.0 in the current directory.
Using tar command, extract the data in the destination directory.
#tar xvBf –
Your data is restored now!!
uname & showrev shows different patch levels - Why?
The uname(1M) command queries the running kernel to find the patch revision. The showrev(1M) command reads through the patch logs. What happens is that the patch logs are updated with the new patch, but the in-memory image of the kernel is not updated.
When the system is booted, the revision string that uname uses is loaded with the unix module, which can be found in the various platform directories depending on the architecture.
For Example:
32 bit SPARC - /platform/sun4u/kernel/unix
64 bit SPARC - /platform/sun4u/kernel/sparcv9/unix
intel - /platform/i86pc/kernel/unix
The following identifies the architecture for your machine:
$ uname -m
VERIFY THE FOLLOWING
1. Was the system rebooted after installing the patch, or patches?
When you reboot the machine after applying the patch, or patches, be sure to run the init 6 command. Do not simply exit single-user mode and proceed up to multi-user mode. When the run level is changed from single-user to multi-user in that manner, the kernel module is not reloaded; only the run state is changed. The init 6 command performs a complete reboot and reload the kernel.
2. Does this machine use Volume Manager or Solstice Disksuite[TM]?
If so, your issue could be caused from a failing/out-of sync-mirror (stale mirror).
Physically disconnect one side of the mirror. The volume management system looks after the failure, but it will stop alternating reads with a possible bad mirror.
3. Review what the output from the following command produces:
$ strings /platform/`uname -m`/kernel/sparcv9/unix | grep Generic
The command should show a result that is similar to the following:
Generic_117350-05
4. Check what the kernel binary shows:
$ /usr/ccs/bin/what /platform/`uname -m`/kernel/sparcv9/unix
The kernel binary should show a result similar to the following:
SunOS 5.8 Generic 117350-05 Jun 2004
5. Review what the output from the following command produces:
Note: For the Solaris[TM] 8 Operating System (Solaris 8 OS) and above, use mdb. For earlier OS versions, use adb. Be sure to run this command as root:
# echo "$
utsname: sys SunOS
utsname+0x101: node maniac
utsname+0x202: release 5.8
utsname+0x303: version Generic_117350-05
utsname+0x404: machine sun4u
6. Was the patch or patch cluster installed in single user mode?
If not, then the system could be corrupted and it might have to be restored from backup or reinstalled.
As a last resort, before having to re-install the OS, try backing out the patch and re-applying it while in single user mode.
If for some reason the patch does not backout, try re-adding the patch with the -u option.
# patchadd -u
Re-adding the patch with the -u option forces the patch to be re-applied even though the system believes that it has already been applied and might also solve the problem. This will force it to overwrite the patch that was just installed and might solve the problem.
This problem will also be seen with Solaris[TM] 2.6 patched with KJP 105181-38 running on an E10000 domain. The E10000 kenel binary in the patch contains the wrong version string :
# strings ./SUNWcar.u1/reloc/platform/SUNW,Ultra-Enterprise-10000/kernel/unix | grep 105181
Generic_105181-37
Friday, August 7, 2009
Saving and Restoring ZFS Data
Saving and Restoring ZFS Data
The zfs send command creates a stream representation of a snapshot that is written to standard output. By default, a full stream is generated. You can redirect the output to a file or to a different system. The zfs receive command creates a snapshot whose contents are specified in the stream that is provided on standard input. If a full stream is received, a new file system is created as well. You can save ZFS snapshot data and restore ZFS snapshot data and file systems with these commands. See the examples in the next section.
The following solutions for saving ZFS data are provided:
Saving ZFS snapshots and rolling back snapshots, if necessary.
Saving full and incremental copies of ZFS snapshots and restoring the snapshots and file systems, if necessary.
Remotely replicating ZFS file systems by saving and restoring ZFS snapshots and file systems.
Saving ZFS data with archive utilities such as tar and cpio or third-party backup products.
Consider the following when choosing a solution for saving ZFS data:
File system snapshots and rolling back snapshots – Use the zfs snapshot and zfs rollback commands if you want to easily create a copy of a file system and revert back to a previous file system version, if necessary. For example, if you want to restore a file or files from a previous version of a file system, you could use this solution.
For more information about creating and rolling back to a snapshot, see ZFS Snapshots.
Saving snapshots – Use the zfs send and zfs receive commands to save and restore a ZFS snapshot. You can save incremental changes between snapshots, but you cannot restore files individually. You must restore the entire file system snapshot.
Remote replication – Use the zfs send and zfs receive commands when you want to copy a file system from one system to another. This process is different from a traditional volume management product that might mirror devices across a WAN. No special configuration or hardware is required. The advantage of replicating a ZFS file system is that you can re-create a file system on a storage pool on another system, and specify different levels of configuration for the newly created pool, such as RAID-Z, but with identical file system data.
Saving ZFS Data With Other Backup Products
In addition to the zfs send and zfs receive commands, you can also use archive utilities, such as the tar and cpio commands, to save ZFS files. All of these utilities save and restore ZFS file attributes and ACLs. Check the appropriate options for both the tar and cpio commands.
For update-to-date information about issues with ZFS and third-party backup products, please see the Solaris Express release notes.
Saving a ZFS Snapshot
The simplest form of the zfs send command is to save a copy of a snapshot. For example:
# zfs send tank/dana@040706 > /dev/rmt/0
You can save incremental data by using the zfs send i option. For example:
# zfs send -i tank/dana@040706 tank/dana@040806 > /dev/rmt/0
Note that the first argument is the earlier snapshot and the second argument is the later snapshot.
If you need to store many copies, you might consider compressing a ZFS snapshot stream representation with the gzip command. For example:
# zfs send pool/fs@snap | gzip > backupfile.gz
Restoring a ZFS Snapshot
When you restore a file system snapshot, the file system is restored as well. The file system is unmounted and is inaccessible while it is being restored. In addition, the original file system to be restored must not exist while it is being restored. If a conflicting file system name exists, zfs rename can be used to rename the file system. For example:
# zfs send tank/gozer@040706 > /dev/rmt/0
.
.
.
# zfs receive tank/gozer2@today < /dev/rmt/0
# zfs rename tank/gozer tank/gozer.old
# zfs rename tank/gozer2 tank/gozer
You can use zfs recv as an alias for the zfs receive command.
When you restore an incremental file system snapshot, the most recent snapshot must first be rolled back. In addition, the destination file system must exist. In the following example, the previous incremental saved copy of tank/dana is restored.
# zfs rollback tank/dana@040706
cannot rollback to 'tank/dana@040706': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
tank/dana@now
# zfs rollback -r tank/dana@040706/
# zfs recv tank/dana < /dev/rmt/0
During the incremental restore process, the file system is unmounted and cannot be accessed.
Remote Replication of ZFS Data
You can use the zfs send and zfs recv commands to remotely copy a snapshot stream representation from one system to another system. For example:
# zfs send tank/cindy@today | ssh newsys zfs recv sandbox/restfs@today
This command saves the tank/cindy@today snapshot data and restores it into the sandbox/restfs file system and also creates a restfs@today snapshot on the newsys system. In this example, the user has been configured to use ssh on the remote system.
Courtesy: http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch06s03.html#gbimy
The zfs send command creates a stream representation of a snapshot that is written to standard output. By default, a full stream is generated. You can redirect the output to a file or to a different system. The zfs receive command creates a snapshot whose contents are specified in the stream that is provided on standard input. If a full stream is received, a new file system is created as well. You can save ZFS snapshot data and restore ZFS snapshot data and file systems with these commands. See the examples in the next section.
The following solutions for saving ZFS data are provided:
Saving ZFS snapshots and rolling back snapshots, if necessary.
Saving full and incremental copies of ZFS snapshots and restoring the snapshots and file systems, if necessary.
Remotely replicating ZFS file systems by saving and restoring ZFS snapshots and file systems.
Saving ZFS data with archive utilities such as tar and cpio or third-party backup products.
Consider the following when choosing a solution for saving ZFS data:
File system snapshots and rolling back snapshots – Use the zfs snapshot and zfs rollback commands if you want to easily create a copy of a file system and revert back to a previous file system version, if necessary. For example, if you want to restore a file or files from a previous version of a file system, you could use this solution.
For more information about creating and rolling back to a snapshot, see ZFS Snapshots.
Saving snapshots – Use the zfs send and zfs receive commands to save and restore a ZFS snapshot. You can save incremental changes between snapshots, but you cannot restore files individually. You must restore the entire file system snapshot.
Remote replication – Use the zfs send and zfs receive commands when you want to copy a file system from one system to another. This process is different from a traditional volume management product that might mirror devices across a WAN. No special configuration or hardware is required. The advantage of replicating a ZFS file system is that you can re-create a file system on a storage pool on another system, and specify different levels of configuration for the newly created pool, such as RAID-Z, but with identical file system data.
Saving ZFS Data With Other Backup Products
In addition to the zfs send and zfs receive commands, you can also use archive utilities, such as the tar and cpio commands, to save ZFS files. All of these utilities save and restore ZFS file attributes and ACLs. Check the appropriate options for both the tar and cpio commands.
For update-to-date information about issues with ZFS and third-party backup products, please see the Solaris Express release notes.
Saving a ZFS Snapshot
The simplest form of the zfs send command is to save a copy of a snapshot. For example:
# zfs send tank/dana@040706 > /dev/rmt/0
You can save incremental data by using the zfs send i option. For example:
# zfs send -i tank/dana@040706 tank/dana@040806 > /dev/rmt/0
Note that the first argument is the earlier snapshot and the second argument is the later snapshot.
If you need to store many copies, you might consider compressing a ZFS snapshot stream representation with the gzip command. For example:
# zfs send pool/fs@snap | gzip > backupfile.gz
Restoring a ZFS Snapshot
When you restore a file system snapshot, the file system is restored as well. The file system is unmounted and is inaccessible while it is being restored. In addition, the original file system to be restored must not exist while it is being restored. If a conflicting file system name exists, zfs rename can be used to rename the file system. For example:
# zfs send tank/gozer@040706 > /dev/rmt/0
.
.
.
# zfs receive tank/gozer2@today < /dev/rmt/0
# zfs rename tank/gozer tank/gozer.old
# zfs rename tank/gozer2 tank/gozer
You can use zfs recv as an alias for the zfs receive command.
When you restore an incremental file system snapshot, the most recent snapshot must first be rolled back. In addition, the destination file system must exist. In the following example, the previous incremental saved copy of tank/dana is restored.
# zfs rollback tank/dana@040706
cannot rollback to 'tank/dana@040706': more recent snapshots exist
use '-r' to force deletion of the following snapshots:
tank/dana@now
# zfs rollback -r tank/dana@040706/
# zfs recv tank/dana < /dev/rmt/0
During the incremental restore process, the file system is unmounted and cannot be accessed.
Remote Replication of ZFS Data
You can use the zfs send and zfs recv commands to remotely copy a snapshot stream representation from one system to another system. For example:
# zfs send tank/cindy@today | ssh newsys zfs recv sandbox/restfs@today
This command saves the tank/cindy@today snapshot data and restores it into the sandbox/restfs file system and also creates a restfs@today snapshot on the newsys system. In this example, the user has been configured to use ssh on the remote system.
Courtesy: http://docs.huihoo.com/opensolaris/solaris-zfs-administration-guide/html/ch06s03.html#gbimy
Backing up ZFS file systems
Original post.
This is one of the good things ZFS has brought us. Backing up a file system is a ubiquitous problem, even in your home PC, if you're wise and care about your data. As many things in ZFS, due to the telescoping nature of this file system (using words of ZFS' father, Jeff Bonwick), backing up is tightly connected to other ZFS' concepts: in this case, snapshots and clones.
Snapshotting
ZFS lets the administrator perform inexpensive snapshots of a mounted filesystem. Snapshots are just what their name implies: a photo of a ZFS file system in a given point in time. Since that moment, the file system from which the snapshot was generated and the snapshot itself begin to branch and the space required by the snapshot will roughly be the space occupied by the differences between these two entities. If you delete a 1 GB file from a snapshotted filesystem, for example, the space accounted for that file will go in charge of the snapshot which, obviously, must keep track of it because that file existed when the snapshot was created. So far, so good (and easy). Creating snapshot is also incredibly easy: provided that you have a role with the required privileges you just issued the following command:
$ pfexec zfs snapshot zpool-name/filesystem-name@snapshot-name
Now you have a photo of the zpool-name/filesystem-name ZFS file system in a given point in time. You can check about its existence by issuing:
$ zfs list -t snapshot
which in this moment, in my machines, gives me:
$ zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
rpool/export/home/enrico@20081231 71.3M - 14.9G -
[...]
This means that the ZFS file system which hosts my home directory has been snapshotted and there's a snapshot named 20081231.
Cloning
Cloning is pretty much like snapshotting with the difference that the result of the operation is another ZFS file system, obviously mounted in another mount point, which can be used like whichever file system. Like snapshots, the clone and the originating file system will begin to diverge and differences will begin to occupy space in the clone. The official ZFS administration documentation has detailed and complete information about this topic.
Backing up
This isn't really how documentation calls it: they just refer to it with ZFS send and receive operations. As seen, we've got a mean to snapshot a file system: there's no need to unmount a file system or run the risk of getting a set of inconsistent data because a modification occurred during the operation. This alone is worth switching to ZFS, in my opinion. Now there's more: a snapshot can be dumped (serialized) to a file with a simple command:
$ pfexec zfs send zpool-name/filesystem-name@snapshot-name > dump-file-name
This file contains the entire ZFS file system: files and all the rest of metadata. Everything. The good thing is that you can receive a ZFS file system just doing:
$ pfexec zfs receive another-zpool-name/another-filesystem-name <>
This operation creates the another-filesystem-name on pool another-zpool-name (it can even be the same zpool you generated the dump from) and a snapshot called snapshot-name will also be created. In the case of full dumps, the destination file system must not exist and will be created for you. Easy. Full back up with just two lines, a bit of patience and sufficient disk space.
There are the usual variations on the theme. You don't really need store the dump in a file, you could just pipe send into receive and do it in just one line with no need of extra storage for the dump file:
# zfs send zpool-name/filesystem-name@snapshot-name | zfs receive another-zpool-name/another-filesystem-name
And if you want to send it to another machine, no problems at all:
# zfs send zpool-name/filesystem-name@snapshot-name | ssh anothermachine zfs receive another-zpool-name/another-filesystem-name
Incredibly simple. ZFS is really revolutionary.
Incremental backups
ZFS, obviously, lets you do incremental send and receive with the -i option which lets you send the differences between one snapshot and another. These differences will be loaded and applied at the receiver side: in this case, obviously, the source snapshot must already exist. You start with a full send and then you go on with increments. It's the way I'm backing up our machines and it's fast, economic and reliable. A great reason to switch to ZFS, let alone Solaris.
Courtesy: http://thegreyblog.blogspot.com/2009/01/backing-up-zfs-file-systems.html
This is one of the good things ZFS has brought us. Backing up a file system is a ubiquitous problem, even in your home PC, if you're wise and care about your data. As many things in ZFS, due to the telescoping nature of this file system (using words of ZFS' father, Jeff Bonwick), backing up is tightly connected to other ZFS' concepts: in this case, snapshots and clones.
Snapshotting
ZFS lets the administrator perform inexpensive snapshots of a mounted filesystem. Snapshots are just what their name implies: a photo of a ZFS file system in a given point in time. Since that moment, the file system from which the snapshot was generated and the snapshot itself begin to branch and the space required by the snapshot will roughly be the space occupied by the differences between these two entities. If you delete a 1 GB file from a snapshotted filesystem, for example, the space accounted for that file will go in charge of the snapshot which, obviously, must keep track of it because that file existed when the snapshot was created. So far, so good (and easy). Creating snapshot is also incredibly easy: provided that you have a role with the required privileges you just issued the following command:
$ pfexec zfs snapshot zpool-name/filesystem-name@snapshot-name
Now you have a photo of the zpool-name/filesystem-name ZFS file system in a given point in time. You can check about its existence by issuing:
$ zfs list -t snapshot
which in this moment, in my machines, gives me:
$ zfs list -t snapshot
NAME USED AVAIL REFER MOUNTPOINT
rpool/export/home/enrico@20081231 71.3M - 14.9G -
[...]
This means that the ZFS file system which hosts my home directory has been snapshotted and there's a snapshot named 20081231.
Cloning
Cloning is pretty much like snapshotting with the difference that the result of the operation is another ZFS file system, obviously mounted in another mount point, which can be used like whichever file system. Like snapshots, the clone and the originating file system will begin to diverge and differences will begin to occupy space in the clone. The official ZFS administration documentation has detailed and complete information about this topic.
Backing up
This isn't really how documentation calls it: they just refer to it with ZFS send and receive operations. As seen, we've got a mean to snapshot a file system: there's no need to unmount a file system or run the risk of getting a set of inconsistent data because a modification occurred during the operation. This alone is worth switching to ZFS, in my opinion. Now there's more: a snapshot can be dumped (serialized) to a file with a simple command:
$ pfexec zfs send zpool-name/filesystem-name@snapshot-name > dump-file-name
This file contains the entire ZFS file system: files and all the rest of metadata. Everything. The good thing is that you can receive a ZFS file system just doing:
$ pfexec zfs receive another-zpool-name/another-filesystem-name <>
This operation creates the another-filesystem-name on pool another-zpool-name (it can even be the same zpool you generated the dump from) and a snapshot called snapshot-name will also be created. In the case of full dumps, the destination file system must not exist and will be created for you. Easy. Full back up with just two lines, a bit of patience and sufficient disk space.
There are the usual variations on the theme. You don't really need store the dump in a file, you could just pipe send into receive and do it in just one line with no need of extra storage for the dump file:
# zfs send zpool-name/filesystem-name@snapshot-name | zfs receive another-zpool-name/another-filesystem-name
And if you want to send it to another machine, no problems at all:
# zfs send zpool-name/filesystem-name@snapshot-name | ssh anothermachine zfs receive another-zpool-name/another-filesystem-name
Incredibly simple. ZFS is really revolutionary.
Incremental backups
ZFS, obviously, lets you do incremental send and receive with the -i option which lets you send the differences between one snapshot and another. These differences will be loaded and applied at the receiver side: in this case, obviously, the source snapshot must already exist. You start with a full send and then you go on with increments. It's the way I'm backing up our machines and it's fast, economic and reliable. A great reason to switch to ZFS, let alone Solaris.
Courtesy: http://thegreyblog.blogspot.com/2009/01/backing-up-zfs-file-systems.html
Tuesday, July 28, 2009
Sample ZFS commands and usage
Sample ZFS commands and usage
What You Do and See Why
$ man zpool
$ man zfs
Get familiar with command structure and options
$ su
Password:
# cd /
# mkfile 100m disk1 disk2 disk3 disk5
# mkfile 50m disk4
# ls -l disk*
-rw------T 1 root root 104857600 Sep 11 12:15 disk1
-rw------T 1 root root 104857600 Sep 11 12:15 disk2
-rw------T 1 root root 104857600 Sep 11 12:15 disk3
-rw------T 1 root root 52428800 Sep 11 12:15 disk4
-rw------T 1 root root 104857600 Sep 11 12:15 disk5
Create some “virtual devices” or vdevs as described in the zpool documentation. These can also be real disk slices if you have them available.
# zpool create myzfs /disk1 /disk2
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
myzfs 191M 94K 191M 0% ONLINE -
Create a storage pool and check the size and usage.
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Get more detailed status of the zfs storage pool.
# zpool destroy myzfs
# zpool list
no pools available
Destroy a zfs storage pool
# zpool create myzfs mirror /disk1 /disk4
invalid vdev specification
use '-f' to override the following errors:
mirror contains devices of different sizes
Attempt to create a zfs pool with different size vdevs fails. Using -f options forces it to occur but only uses space allowed by smallest device.
# zpool create myzfs mirror /disk1 /disk2 /disk3
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
myzfs 95.5M 112K 95.4M 0% ONLINE -
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
/disk3 ONLINE 0 0 0
errors: No known data errors
Create a mirrored storage pool. In this case, a 3 way mirrored storage pool.
# zpool detach myzfs /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Detach a device from a mirrored pool.
# zpool attach myzfs /disk1 /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: resilver completed with 0 errors on Tue Sep 11 13:31:49 2007
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
/disk3 ONLINE 0 0 0
errors: No known data errors
Attach device to pool. This creates a two-way mirror is the pool is not already a mirror, else it adds another mirror, in this case making it a 3 way mirror.
# zpool remove myzfs /disk3
cannot remove /disk3: only inactive hot spares can be removed
# zpool detach myzfs /disk3
Attempt to remove a device from a pool. In this case it’s a mirror, so we must use “zpool detach”.
# zpool add myzfs spare /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
spares
/disk3 AVAIL
errors: No known data errors
Add a hot spare to a storage pool.
# zpool remove myzfs /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Remove a hot spare from a pool.
# zpool offline myzfs /disk1
# zpool status -v
pool: myzfs
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning
in a degraded state.
action: Online the device using 'zpool online' or replace the device
with 'zpool replace'.
scrub: resilver completed with 0 errors on Tue Sep 11 13:39:25 2007
config:
NAME STATE READ WRITE CKSUM
myzfs DEGRADED 0 0 0
mirror DEGRADED 0 0 0
/disk1 OFFLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Take the specified device offline. No attempt to read or write to the device will take place until it’s brought back online. Use the -t option to temporarily offline a device. A reboot will bring the device back online.
# zpool online myzfs /disk1
# zpool status -v
pool: myzfs
state: ONLINE
scrub: resilver completed with 0 errors on Tue Sep 11 13:47:14 2007
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Bring the specified device online.
# zpool replace myzfs /disk1 /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: resilver completed with 0 errors on Tue Sep 11 13:25:48 2007
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk3 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Replace a disk in a pool with another disk, for example when a disk fails
# zpool scrub myzfs
Perform a scrub of the storage pool to verify that it checksums correctly. On mirror or raidz pools, ZFS will automatically repair any damage.
WARNING: scrubbing is I/O intensive.
# zpool export myzfs
# zpool list
no pools available
Export a pool from the system for importing on another system.
# zpool import -d / myzfs
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
myzfs 95.5M 114K 95.4M 0% ONLINE -
Import a previously exported storage pool. If -d is not specified, this command searches /dev/dsk. As we’re using files in this example, we need to specify the directory of the files used by the storage pool.
# zpool upgrade
This system is currently running ZFS pool version 8.
All pools are formatted using this version.
# zpool upgrade -v
This system is currently running ZFS pool version 8.
The following versions are supported:
VER DESCRIPTION
--- --------------------------------------------------------
1 Initial ZFS version
2 Ditto blocks (replicated metadata)
3 Hot spares and double parity RAID-Z
4 zpool history
5 Compression using the gzip algorithm
6 pool properties
7 Separate intent log devices
8 Delegated administration
For more information on a particular version, including supported
releases, see:
http://www.opensolaris.org/os/community/zfs/version/N
Where 'N' is the version number.
Display pools format version. The -v flag shows the features supported by the current version. Use the -a flag to upgrade all pools to the latest on-disk version. Pools that are upgraded will no longer be accessible to any systems running older versions.
# zpool iostat 5
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
myzfs 112K 95.4M 0 4 26 11.4K
myzfs 112K 95.4M 0 0 0 0
myzfs 112K 95.4M 0 0 0 0
Get I/O statistics for the pool
# zfs create myzfs/colin
# df -h
Filesystem kbytes used avail capacity Mounted on
...
myzfs/colin 64M 18K 63M 1% /myzfs/colin
Create a file system and check it with standard df -h command. File systems are automatically mounted by default under the /zfs location. See the Mountpoints section of the zfs man page for more details.
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 139K 63.4M 19K /myzfs
myzfs/colin 18K 63.4M 18K /myzfs/colin
List current zfs file systems.
# zpool add myzfs /disk1
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool uses mirror and new vdev is file
Attempt to add a single vdev to a mirrored set fails
# zpool add myzfs mirror /disk1 /disk5
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk3 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk5 ONLINE 0 0 0
errors: No known data errors
Add a mirrored set of vdevs
# zfs create myzfs/colin2
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 172K 159M 21K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin2 18K 159M 18K /myzfs/colin2
Create a second file system. Note that both file system show 159M available because no quotas are set. Each “could” grow to fill the pool.
# zfs set reservation=20m myzfs/colin
# zfs list -o reservation
RESERV
none
20M
none
Reserve a specified amount of space for a file system ensuring that other users don’t take up all the space.
# zfs set quota=20m myzfs/colin2
# zfs list -o quota myzfs/colin myzfs/colin2
QUOTA
none
20M
Set and view quotas
# zfs set compression=on myzfs/colin2
# zfs list -o compression
COMPRESS
off
off
on
Turn on and verify compression
# zfs set sharenfs=on myzfs/colin2
# zfs get sharenfs myzfs/colin2
NAME PROPERTY VALUE SOURCE
myzfs/colin2 sharenfs on local
Share a filesystem over NFS. There is no need to modify the /etc/dfs/dfstab as the filesystem will be share automatically on boot.
# zfs set sharesmb=on myzfs/colin2
# zfs get sharesmb myzfs/colin2
NAME PROPERTY VALUE SOURCE
myzfs/colin2 sharesmb on local
Share a filesystem over CIFS/SMB. This will make your ZFS filesystem accessible to Windows users.
# zfs snapshot myzfs/colin@test
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.2M 139M 21K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin@test 0 - 18K -
myzfs/colin2 18K 20.0M 18K /myzfs/colin2
Create a snapshot called test.
# zfs rollback myzfs/colin@test
Rollback to a snapshot.
# zfs clone myzfs/colin@test myzfs/colin3
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.2M 139M 21K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin@test 0 - 18K -
myzfs/colin2 18K 20.0M 18K /myzfs/colin2
myzfs/colin3 0 139M 18K /myzfs/colin3
A snapshot is not directly addressable. A clone must be made. The target dataset can be located anywhere in the ZFS hierarchy, and will be created as the same type as the original.
# zfs destroy myzfs/colin2
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.1M 139M 22K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin@test 0 - 18K -
myzfs/colin3 0 139M 18K /myzfs/colin3
Destroy a filesystem
# zfs destroy myzfs/colin
cannot destroy 'myzfs/colin': filesystem has children
use '-r' to destroy the following datasets:
myzfs/colin@test
Attempt to destroy a filesystem that had a child. In this case, the snapshot filesystem. We must either remove the snapshot, or make a clone and promote the clone.
# zfs promote myzfs/colin3
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.1M 139M 21K /myzfs
myzfs/colin 0 159M 18K /myzfs/colin
myzfs/colin3 18K 139M 18K /myzfs/colin3
myzfs/colin3@test 0 - 18K -
# zfs destroy myzfs/colin
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 147K 159M 21K /myzfs
myzfs/colin3 18K 159M 18K /myzfs/colin3
myzfs/colin3@test 0 - 18K -
Promte a clone filesystem to no longer be a dependent on it’s “origin” snapshot. This now associates makes the snapshot a child of the cloned filesystem. We can then delete the original filesystem.
# zfs rename myzfs/colin3 myzfs/bob
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 153K 159M 21K /myzfs
myzfs/bob 18K 159M 18K /myzfs/bob
myzfs/bob@test 0 - 18K -
# zfs rename myzfs/bob@test myzfs/bob@newtest
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 146K 159M 20K /myzfs
myzfs/bob 18K 159M 18K /myzfs/bob
myzfs/bob@newtest 0 - 18K -
Rename a filesystem, and separately rename the snapshot.
# zfs get all
NAME PROPERTY VALUE SOURCE
myzfs type filesystem -
myzfs creation Tue Sep 11 14:21 2007 -
myzfs used 146K -
myzfs available 159M -
myzfs referenced 20K -
[...]
Display properties for the given datasets. This can be refined further using options.
# zpool destroy myzfs
cannot destroy 'myzfs': pool is not empty
use '-f' to force destruction anyway
Can’t destroy a pool with active filesystems.
# zfs unmount myzfs/bob
# df -h
myzfs 159M 20K 159M 1% /myzfs
Unmount a ZFS file system
# zfs mount myzfs/bob
# df -h
myzfs 159M 20K 159M 1% /myzfs
myzfs/bob 159M 18K 159M 1% /myzfs/bob
Mount a ZFS filesystem. This is usually automatically done on boot.
# zfs send myzfs/bob@newtest | ssh localhost zfs receive myzfs/backup
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 172K 159M 20K /myzfs
myzfs/backup 18K 159M 18K /myzfs/backup
myzfs/backup@newtest 0 - 18K -
myzfs/bob 18K 159M 18K /myzfs/bob
myzfs/bob@newtest 0 - 18K -
Create a stream representation of the snapshot and redirect it to zfs receive. In this example I’ve redirected to the localhost for illustration purposes. This can be used to backup to a remote host, or even to a local file.
# zpool history
History for 'myzfs':
2007-09-11.15:35:50 zpool create myzfs mirror /disk1 /disk2 /disk3
2007-09-11.15:36:00 zpool detach myzfs /disk3
2007-09-11.15:36:10 zpool attach myzfs /disk1 /disk3
2007-09-11.15:36:53 zpool detach myzfs /disk3
2007-09-11.15:36:59 zpool add myzfs spare /disk3
2007-09-11.15:37:09 zpool remove myzfs /disk3
2007-09-11.15:37:18 zpool offline myzfs /disk1
2007-09-11.15:37:27 zpool online myzfs /disk1
2007-09-11.15:37:37 zpool replace myzfs /disk1 /disk3
2007-09-11.15:37:47 zpool scrub myzfs
2007-09-11.15:37:57 zpool export myzfs
2007-09-11.15:38:05 zpool import -d / myzfs
2007-09-11.15:38:52 zfs create myzfs/colin
2007-09-11.15:39:27 zpool add myzfs mirror /disk1 /disk5
2007-09-11.15:39:38 zfs create myzfs/colin2
2007-09-11.15:39:50 zfs set reservation=20m myzfs/colin
2007-09-11.15:40:18 zfs set quota=20m myzfs/colin2
2007-09-11.15:40:35 zfs set compression=on myzfs/colin2
2007-09-11.15:40:48 zfs snapshot myzfs/colin@test
2007-09-11.15:40:59 zfs rollback myzfs/colin@test
2007-09-11.15:41:11 zfs clone myzfs/colin@test myzfs/colin3
2007-09-11.15:41:25 zfs destroy myzfs/colin2
2007-09-11.15:42:12 zfs promote myzfs/colin3
2007-09-11.15:42:26 zfs rename myzfs/colin3 myzfs/bob
2007-09-11.15:42:57 zfs destroy myzfs/colin
2007-09-11.15:43:23 zfs rename myzfs/bob@test myzfs/bob@newtest
2007-09-11.15:44:30 zfs receive myzfs/backup
Display the command history of all storage pools. This can be limited to a single pool by specifying its name on the command line. The history is only stored for existing pools. Once you’ve destroyed the pool, you’ll no longer have access to it’s history.
# zpool destroy -f myzfs
# zpool status -v
no pools available
Use the -f option to destroy a pool with files systems created
Courtesy: http://www.lildude.co.uk/zfs-cheatsheet/
What You Do and See Why
$ man zpool
$ man zfs
Get familiar with command structure and options
$ su
Password:
# cd /
# mkfile 100m disk1 disk2 disk3 disk5
# mkfile 50m disk4
# ls -l disk*
-rw------T 1 root root 104857600 Sep 11 12:15 disk1
-rw------T 1 root root 104857600 Sep 11 12:15 disk2
-rw------T 1 root root 104857600 Sep 11 12:15 disk3
-rw------T 1 root root 52428800 Sep 11 12:15 disk4
-rw------T 1 root root 104857600 Sep 11 12:15 disk5
Create some “virtual devices” or vdevs as described in the zpool documentation. These can also be real disk slices if you have them available.
# zpool create myzfs /disk1 /disk2
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
myzfs 191M 94K 191M 0% ONLINE -
Create a storage pool and check the size and usage.
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Get more detailed status of the zfs storage pool.
# zpool destroy myzfs
# zpool list
no pools available
Destroy a zfs storage pool
# zpool create myzfs mirror /disk1 /disk4
invalid vdev specification
use '-f' to override the following errors:
mirror contains devices of different sizes
Attempt to create a zfs pool with different size vdevs fails. Using -f options forces it to occur but only uses space allowed by smallest device.
# zpool create myzfs mirror /disk1 /disk2 /disk3
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
myzfs 95.5M 112K 95.4M 0% ONLINE -
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
/disk3 ONLINE 0 0 0
errors: No known data errors
Create a mirrored storage pool. In this case, a 3 way mirrored storage pool.
# zpool detach myzfs /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Detach a device from a mirrored pool.
# zpool attach myzfs /disk1 /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: resilver completed with 0 errors on Tue Sep 11 13:31:49 2007
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
/disk3 ONLINE 0 0 0
errors: No known data errors
Attach device to pool. This creates a two-way mirror is the pool is not already a mirror, else it adds another mirror, in this case making it a 3 way mirror.
# zpool remove myzfs /disk3
cannot remove /disk3: only inactive hot spares can be removed
# zpool detach myzfs /disk3
Attempt to remove a device from a pool. In this case it’s a mirror, so we must use “zpool detach”.
# zpool add myzfs spare /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
spares
/disk3 AVAIL
errors: No known data errors
Add a hot spare to a storage pool.
# zpool remove myzfs /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Remove a hot spare from a pool.
# zpool offline myzfs /disk1
# zpool status -v
pool: myzfs
state: DEGRADED
status: One or more devices has been taken offline by the administrator.
Sufficient replicas exist for the pool to continue functioning
in a degraded state.
action: Online the device using 'zpool online' or replace the device
with 'zpool replace'.
scrub: resilver completed with 0 errors on Tue Sep 11 13:39:25 2007
config:
NAME STATE READ WRITE CKSUM
myzfs DEGRADED 0 0 0
mirror DEGRADED 0 0 0
/disk1 OFFLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Take the specified device offline. No attempt to read or write to the device will take place until it’s brought back online. Use the -t option to temporarily offline a device. A reboot will bring the device back online.
# zpool online myzfs /disk1
# zpool status -v
pool: myzfs
state: ONLINE
scrub: resilver completed with 0 errors on Tue Sep 11 13:47:14 2007
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Bring the specified device online.
# zpool replace myzfs /disk1 /disk3
# zpool status -v
pool: myzfs
state: ONLINE
scrub: resilver completed with 0 errors on Tue Sep 11 13:25:48 2007
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk3 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
errors: No known data errors
Replace a disk in a pool with another disk, for example when a disk fails
# zpool scrub myzfs
Perform a scrub of the storage pool to verify that it checksums correctly. On mirror or raidz pools, ZFS will automatically repair any damage.
WARNING: scrubbing is I/O intensive.
# zpool export myzfs
# zpool list
no pools available
Export a pool from the system for importing on another system.
# zpool import -d / myzfs
# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
myzfs 95.5M 114K 95.4M 0% ONLINE -
Import a previously exported storage pool. If -d is not specified, this command searches /dev/dsk. As we’re using files in this example, we need to specify the directory of the files used by the storage pool.
# zpool upgrade
This system is currently running ZFS pool version 8.
All pools are formatted using this version.
# zpool upgrade -v
This system is currently running ZFS pool version 8.
The following versions are supported:
VER DESCRIPTION
--- --------------------------------------------------------
1 Initial ZFS version
2 Ditto blocks (replicated metadata)
3 Hot spares and double parity RAID-Z
4 zpool history
5 Compression using the gzip algorithm
6 pool properties
7 Separate intent log devices
8 Delegated administration
For more information on a particular version, including supported
releases, see:
http://www.opensolaris.org/os/community/zfs/version/N
Where 'N' is the version number.
Display pools format version. The -v flag shows the features supported by the current version. Use the -a flag to upgrade all pools to the latest on-disk version. Pools that are upgraded will no longer be accessible to any systems running older versions.
# zpool iostat 5
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
myzfs 112K 95.4M 0 4 26 11.4K
myzfs 112K 95.4M 0 0 0 0
myzfs 112K 95.4M 0 0 0 0
Get I/O statistics for the pool
# zfs create myzfs/colin
# df -h
Filesystem kbytes used avail capacity Mounted on
...
myzfs/colin 64M 18K 63M 1% /myzfs/colin
Create a file system and check it with standard df -h command. File systems are automatically mounted by default under the /zfs location. See the Mountpoints section of the zfs man page for more details.
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 139K 63.4M 19K /myzfs
myzfs/colin 18K 63.4M 18K /myzfs/colin
List current zfs file systems.
# zpool add myzfs /disk1
invalid vdev specification
use '-f' to override the following errors:
mismatched replication level: pool uses mirror and new vdev is file
Attempt to add a single vdev to a mirrored set fails
# zpool add myzfs mirror /disk1 /disk5
# zpool status -v
pool: myzfs
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
myzfs ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk3 ONLINE 0 0 0
/disk2 ONLINE 0 0 0
mirror ONLINE 0 0 0
/disk1 ONLINE 0 0 0
/disk5 ONLINE 0 0 0
errors: No known data errors
Add a mirrored set of vdevs
# zfs create myzfs/colin2
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 172K 159M 21K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin2 18K 159M 18K /myzfs/colin2
Create a second file system. Note that both file system show 159M available because no quotas are set. Each “could” grow to fill the pool.
# zfs set reservation=20m myzfs/colin
# zfs list -o reservation
RESERV
none
20M
none
Reserve a specified amount of space for a file system ensuring that other users don’t take up all the space.
# zfs set quota=20m myzfs/colin2
# zfs list -o quota myzfs/colin myzfs/colin2
QUOTA
none
20M
Set and view quotas
# zfs set compression=on myzfs/colin2
# zfs list -o compression
COMPRESS
off
off
on
Turn on and verify compression
# zfs set sharenfs=on myzfs/colin2
# zfs get sharenfs myzfs/colin2
NAME PROPERTY VALUE SOURCE
myzfs/colin2 sharenfs on local
Share a filesystem over NFS. There is no need to modify the /etc/dfs/dfstab as the filesystem will be share automatically on boot.
# zfs set sharesmb=on myzfs/colin2
# zfs get sharesmb myzfs/colin2
NAME PROPERTY VALUE SOURCE
myzfs/colin2 sharesmb on local
Share a filesystem over CIFS/SMB. This will make your ZFS filesystem accessible to Windows users.
# zfs snapshot myzfs/colin@test
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.2M 139M 21K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin@test 0 - 18K -
myzfs/colin2 18K 20.0M 18K /myzfs/colin2
Create a snapshot called test.
# zfs rollback myzfs/colin@test
Rollback to a snapshot.
# zfs clone myzfs/colin@test myzfs/colin3
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.2M 139M 21K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin@test 0 - 18K -
myzfs/colin2 18K 20.0M 18K /myzfs/colin2
myzfs/colin3 0 139M 18K /myzfs/colin3
A snapshot is not directly addressable. A clone must be made. The target dataset can be located anywhere in the ZFS hierarchy, and will be created as the same type as the original.
# zfs destroy myzfs/colin2
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.1M 139M 22K /myzfs
myzfs/colin 18K 159M 18K /myzfs/colin
myzfs/colin@test 0 - 18K -
myzfs/colin3 0 139M 18K /myzfs/colin3
Destroy a filesystem
# zfs destroy myzfs/colin
cannot destroy 'myzfs/colin': filesystem has children
use '-r' to destroy the following datasets:
myzfs/colin@test
Attempt to destroy a filesystem that had a child. In this case, the snapshot filesystem. We must either remove the snapshot, or make a clone and promote the clone.
# zfs promote myzfs/colin3
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 20.1M 139M 21K /myzfs
myzfs/colin 0 159M 18K /myzfs/colin
myzfs/colin3 18K 139M 18K /myzfs/colin3
myzfs/colin3@test 0 - 18K -
# zfs destroy myzfs/colin
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 147K 159M 21K /myzfs
myzfs/colin3 18K 159M 18K /myzfs/colin3
myzfs/colin3@test 0 - 18K -
Promte a clone filesystem to no longer be a dependent on it’s “origin” snapshot. This now associates makes the snapshot a child of the cloned filesystem. We can then delete the original filesystem.
# zfs rename myzfs/colin3 myzfs/bob
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 153K 159M 21K /myzfs
myzfs/bob 18K 159M 18K /myzfs/bob
myzfs/bob@test 0 - 18K -
# zfs rename myzfs/bob@test myzfs/bob@newtest
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 146K 159M 20K /myzfs
myzfs/bob 18K 159M 18K /myzfs/bob
myzfs/bob@newtest 0 - 18K -
Rename a filesystem, and separately rename the snapshot.
# zfs get all
NAME PROPERTY VALUE SOURCE
myzfs type filesystem -
myzfs creation Tue Sep 11 14:21 2007 -
myzfs used 146K -
myzfs available 159M -
myzfs referenced 20K -
[...]
Display properties for the given datasets. This can be refined further using options.
# zpool destroy myzfs
cannot destroy 'myzfs': pool is not empty
use '-f' to force destruction anyway
Can’t destroy a pool with active filesystems.
# zfs unmount myzfs/bob
# df -h
myzfs 159M 20K 159M 1% /myzfs
Unmount a ZFS file system
# zfs mount myzfs/bob
# df -h
myzfs 159M 20K 159M 1% /myzfs
myzfs/bob 159M 18K 159M 1% /myzfs/bob
Mount a ZFS filesystem. This is usually automatically done on boot.
# zfs send myzfs/bob@newtest | ssh localhost zfs receive myzfs/backup
# zfs list
NAME USED AVAIL REFER MOUNTPOINT
myzfs 172K 159M 20K /myzfs
myzfs/backup 18K 159M 18K /myzfs/backup
myzfs/backup@newtest 0 - 18K -
myzfs/bob 18K 159M 18K /myzfs/bob
myzfs/bob@newtest 0 - 18K -
Create a stream representation of the snapshot and redirect it to zfs receive. In this example I’ve redirected to the localhost for illustration purposes. This can be used to backup to a remote host, or even to a local file.
# zpool history
History for 'myzfs':
2007-09-11.15:35:50 zpool create myzfs mirror /disk1 /disk2 /disk3
2007-09-11.15:36:00 zpool detach myzfs /disk3
2007-09-11.15:36:10 zpool attach myzfs /disk1 /disk3
2007-09-11.15:36:53 zpool detach myzfs /disk3
2007-09-11.15:36:59 zpool add myzfs spare /disk3
2007-09-11.15:37:09 zpool remove myzfs /disk3
2007-09-11.15:37:18 zpool offline myzfs /disk1
2007-09-11.15:37:27 zpool online myzfs /disk1
2007-09-11.15:37:37 zpool replace myzfs /disk1 /disk3
2007-09-11.15:37:47 zpool scrub myzfs
2007-09-11.15:37:57 zpool export myzfs
2007-09-11.15:38:05 zpool import -d / myzfs
2007-09-11.15:38:52 zfs create myzfs/colin
2007-09-11.15:39:27 zpool add myzfs mirror /disk1 /disk5
2007-09-11.15:39:38 zfs create myzfs/colin2
2007-09-11.15:39:50 zfs set reservation=20m myzfs/colin
2007-09-11.15:40:18 zfs set quota=20m myzfs/colin2
2007-09-11.15:40:35 zfs set compression=on myzfs/colin2
2007-09-11.15:40:48 zfs snapshot myzfs/colin@test
2007-09-11.15:40:59 zfs rollback myzfs/colin@test
2007-09-11.15:41:11 zfs clone myzfs/colin@test myzfs/colin3
2007-09-11.15:41:25 zfs destroy myzfs/colin2
2007-09-11.15:42:12 zfs promote myzfs/colin3
2007-09-11.15:42:26 zfs rename myzfs/colin3 myzfs/bob
2007-09-11.15:42:57 zfs destroy myzfs/colin
2007-09-11.15:43:23 zfs rename myzfs/bob@test myzfs/bob@newtest
2007-09-11.15:44:30 zfs receive myzfs/backup
Display the command history of all storage pools. This can be limited to a single pool by specifying its name on the command line. The history is only stored for existing pools. Once you’ve destroyed the pool, you’ll no longer have access to it’s history.
# zpool destroy -f myzfs
# zpool status -v
no pools available
Use the -f option to destroy a pool with files systems created
Courtesy: http://www.lildude.co.uk/zfs-cheatsheet/
What can I do if ZFS file system panics on every boot?
What can I do if ZFS file system panics on every boot?
ZFS is designed to survive arbitrary hardware failures through the use of redundancy (mirroring or RAID-Z). Unfortunately, certain failures in non-replicated configurations can cause ZFS to panic when trying to load the pool. This is a bug, and will be fixed in the near future (along with several other nifty features, such as background scrubbing). In the meantime, if you find yourself in the situation where you cannot boot due to a corrupt pool, do the following:
boot using '-m milestone=none'
# mount -o remount /
# rm /etc/zfs/zpool.cache
# reboot
This will remove all knowledge of pools from your system. You will have to re-create your pool and restore from backup.
If a ZFS root file system panics, then you must boot from alternate media, import the root pool, resolve the issue that is causing the failure, export the root pool, and reboot the system. For more information, see the ZFS Troubleshooting Guide.
ZFS is designed to survive arbitrary hardware failures through the use of redundancy (mirroring or RAID-Z). Unfortunately, certain failures in non-replicated configurations can cause ZFS to panic when trying to load the pool. This is a bug, and will be fixed in the near future (along with several other nifty features, such as background scrubbing). In the meantime, if you find yourself in the situation where you cannot boot due to a corrupt pool, do the following:
boot using '-m milestone=none'
# mount -o remount /
# rm /etc/zfs/zpool.cache
# reboot
This will remove all knowledge of pools from your system. You will have to re-create your pool and restore from backup.
If a ZFS root file system panics, then you must boot from alternate media, import the root pool, resolve the issue that is causing the failure, export the root pool, and reboot the system. For more information, see the ZFS Troubleshooting Guide.
Monday, July 27, 2009
Remote Login Tip
Subject : Remote Login Tip
Description :
. Tip Sheet for Remote Login Programs
Including telnet, rlogin, rsh, rcp, rdist, rcmd
. Section
1.0: About Remote Login Programs
2.0: Debugging Remote Login Problems
2.1: General Debugging Advice
2.2: Performance Analyis
3.0: Common How Tos
3.1: How to Increase ptys on a SunOS Machine
3.2: How to Increase ptys on a Solaris Machine
3.3: How to Allow/Disallow Remote root Logins under SunOS
3.4: How to Allow/Disallow Remote root Logins under Solaris
3.5: How to Add a Banner to a SunOS telnet Login
3.6: How to Add a Banner to a Solaris telnet Login
3.7: How to Grant rsh/rdist/rcp Permissions
3.8: How to rdist a Directory
4.0: Some Frequently Asked Questions
4.1: General Remote Login Problems
4.2: General R-command Problems
4.3: rcp and rdist Specific Problems
5.0: Patches
5.1: Remote Login Patches for SunOS
5.2: Remote Login Patches for Solaris
. Content
1.0: About Remote Login Programs
This Tip Sheet documents a wide variety of information concerning the
various remote login programs supported under SunOS and Solaris. This
includes telnet, rlogin, rsh and the related r-commands, rcmd, rcp and
rdist. This Tip Sheet is intended as a guide to the most common remote
login problems. Other references which contain some documentation on
the remote login programs are noted in Section 7.0.
2.0 Debugging Remote Login Problems
2.1: General Debugging Advice
The remote login programs very rarely experience problems other than
those outlined in this Tip Sheet. If you are experiencing additional
problems, the commands etherfind (SunOS) or snoop (Solaris) may be
used to discover exactly what is occuring on the network, and the
commands trace (SunOS) or truss (Solaris) may be used to discover
exactly what the commands are doing when they fail. However, the
information that these commands provide is very technical, and not
always easy to interpret.
2.2: Performance Analysis
Problems involving remote login performance are beyond the scope of
service that SunService can provide. If you having problems with
remote login performance, consult Section 8.0 or 9.0 for where you can
get assistance from within Sun.
3.0 Common How Tos
3.1: How to Increase ptys on a SunOS Machine
You may want to increase your number of ptys to allow more people to
make remote logins to your machine at one time. The below example
increases the number of ptys to 128.
First, create a kernel with 128 ptys, by editing your kernel
configuration file (ie, /sys/sun4c/conf/GENERIC). Change the
pseudo-device line, as follows:
pseudo-device pty128
Afterwards, compile and run this kernel.
Second, go to the /dev directory and create the new pty devices:
# cd /dev
# MAKEDEV pty0 pty1 pty2 pty3 pty4 pty5 pty6 pty7
Each pty# creates 16 master-slave pairs. Thus, making 8 sets, as shown
above, results in 8 * 16 = 128 ptys.
Third, add the new pty names to /etc/ttytab, following the examples
already present. The names are tty[pqrstuvw] [0123456789abcdef],
i.e., ttyp0 - ttypf, ttyq0 - ttyqf, ..., ttyw0 - ttywf.
3.2: How to Increase ptys on a Solaris Machine
You may want to increase your number of ptys to allow more people to
make remote logins to your machine at one time.
To increase the number of ptys (pseudo-terminal devices) under
Solaris 2.3, 2.4, and 2.5, two parameters MUST be entered into, or
modified in, the /etc/system file:
set pt_cnt=
set npty=
We also recommend at 2.4and 2.5, that you also add or modify the following
two parameters in the /etc/system file:
set sad_cnt=<2x number specified in pt_cnt>
set nautopush=
Then do a reconfiguration reboot for the changes to take effect (e.g. boot -r
at the boot "OK" prompt).
For example to set to allowing 128 ptys:
set pt_cnt=128
set npty=128
set sadcnt=256
set nautopush=128
pt_cnt sets the number of pty's for System V, while npty sets the number
of pty's for BSD. sadcnt and nautopush are STREAMS parameters and
are needed to support additional users and network resources (in particular
when using NTS terminal server rtelnet).
sadcnt is the number of streams addressable devices nautopush is the
number of streams autopush entries
In general:
nautopush should be the same as pt_cnt.
sadcnt should be 2x number of nautopush.
3.3: How to Allow/Disallow Remote root Logins under SunOS
root login permissions are controlled by the /etc/ttytab file under
SunOS. To change root login permissions, you must modify every single
'network' line in the /etc/ttytab files.
Root access over the network is granted, if all of the network ttys
are labeled secure:
ttyp0 none network off secure
Root access over the network is denied if all of the network ttys are
labelled unsecure:
ttyp0 none network off unsecure
After making changes to the ttytab, you must HUP process 1:
# kill -HUP 1
Alternatively, you can reboot the machine.
3.4: How to Allow/Disallow Remote root Logins under Solaris
In the file /etc/default/login, there is a CONSOLE line.
If this line is commented out, then root access over the network is
granted:
#CONSOLE=/dev/console
If there is no comment in front of the CONSOLE line, root can only
login from the console.
CONSOLE=/dev/console
Changes to this file will take effect at once.
3.5: How to Add a Banner to a SunOS telnet Login
The best way to have a banner displayed before the telnet login: is to
write a wrapper program:
main ()
{
system("/bin/cat /etc/telnetbanner")
execl("/usr/etc/in.telnetd.real","/usr/etc/in.telnetd.real",(char *)0)
}
This wrapper would be compiled and installed as /usr/etc/in.telnetd, a
message would be installed into /etc/telnetbanner, and the original
in.telnetd would then be moved to in.telnetd.real.
Although this setup should work, it is not officially supported by
SunService.
3.6: How to add a Banner to a Solaris telnet Login
Under Solaris 2.4 and higher, you can add a banner by utilizing the
/etc/issue file. Edit this file to contain your banner, and it will be
read and displayed before the login prompt.
%% cat /etc/issue
** USE THIS MACHINE AT YOUR OWN RISK **
%% telnet localhost
...
UNIX(r) System V Release 4.0 (psi)
** USE THIS MACHINE AT YOUR OWN RISK **
login:
This functionality is not available in versions of Solaris earlier
than 2.4 for those cases, you might want to try the workaround
described in Section 3.5, but it is not officially supported, and may
not work.
3.7: How to Grant rsh/rdist/rcp Permissions
If an individual user wants to be able to rsh into his account without
password, or rdist or rcp into his account, he must create a .rhosts
file. This file should simply contain the name of the remote machine
which should have the rsh/rdist/rcp permissions, and also the name of
the user's account on that machine. For example:
%% cat ~/.rhosts
psi appel
The above .rhosts file would allow me to rsh, rdist or rcp to my
account from the account 'appel' on the machine 'psi'.
Root can also grant global permissions with the hosts.equiv file. This
file simply contains a list of remote machines:
%% cat /etc/hosts.equiv
psi
If a machine is listed, all users on that machine will be able to rsh,
rcp or rdist to the local machine, as long as they have accounts on
both machines with the same login name.
The above would grant this permission to the remote machine 'psi'.
The hosts.equiv man page lists other options available in that
configuration file.
3.8: How to rdist a Directory
The most common usage of rdist is to copy an entire directory
structure from one machine to another. This can be done with the
following command:
%% rdist -c directory remotemachine:/directory
In order for the above to work, rdist must be granted remote
permissions, as described in Section 3.7 above. This command may also
be set up in a distfile script, as is described in the rdist man page.
4.0 Some Frequently Asked Questions
4.1: General Remote Login Problems
Q: Why do I get one of the following errors when I try and log in to
my machine? This only occurs when many people are already logged in:
"xxx: could not grant slave pty."
"xxx: open /dev/ptmx: No such device"
A: These errors occur because your machine has run out of ptys. The
default number of ptys is 48, which will usually allow somewhere
around 30-35 users to log in. You simply need to increase the number
of ptys, and then rebuild your kernel. Sections 3.1 and 3.2 outline
how to increase the number of ptys.
Q: Why do I get the following message when I try and log in to my
Solaris machine:
"xxx: open /dev/logindmux: No such file or directory"
A: This is due to a bug in a Solaris patch which implements in-kernel
telnet. It can be corrected by adding the following line to the file
/etc/name_to_major:
logindmux 114
Afterwards, reboot the machine with the reconfigure option:
# touch /reconfigure
# reboot
When the machine comes back up, you should be able to log in
correctly.
Q: Why do I get a core dump from telnet/rlogin when I try and connect
to certain remote machines from my SunOS machine?
A: This is a known bug that occurs when a remote machine has multiple
addresses. It is fixed in the libc patch for 4.1.3 and 4.1.3_u1. See
section 5.1.1 below.
Q1: Why do the r-commands hang forever?
Q2: why do telnet/rlogin give the following error:
"connect: Connection refused"
A: in.telnetd or in.rlogind are not being started up correctly on the
machine you are trying to connect to. Make sure that inetd is running
on that machine, and make sure that the following two lines are
uncommented in the /etc/inetd.conf:
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind
(Locations will be slightly different on a SunOS machine).
If you have to make changes to inetd.conf, because the above lines are
missing, or commented out, you must restart inetd:
# kill -HUP inetd-pid
Q: Why do I get the following errors when I try and execute a remote
login:
"Network Unreachable"
"Host Unreachable"
A: These errors imply that routing is set up incorrectly to the
machine that you are trying to access. SunService has a seperate Tip
Sheet dedicated to Routing problems.
4.2: General R-command Problems
Q1: Why do I get a 'Password:' prompt when I rsh or rlogin?
Q2: Why do I get 'Permission Denied' when I rcp or rdist?
A1: You do not have a .rhosts file on the remote machine, correctly
listing your local machine. Section 3.7 explains how to set up a
.rhosts file.
A2: You are given explicit permissions to log in to the remote
machine, but the .rhosts file does not list your correct machine name.
For example, the .rhosts might mention your local machine's long host
name (ie, psi.corp.sun.com), while the remote machine actually
indentifies it by the short name (ie, psi) alternatively, your
.rhosts might read machine-le0, while the login request actually comes
from machine-le1. You can test this by logging in to the remote
machine (supplying your password), and then examining the .rhosts
file:
%% cat .rhosts
psi.corp.sun.com appel
Afterwards, run "who", look for your own login, and see what name your
local machine is identified as:
%% who
appel pts/10 Oct 6 09:59 (psi)
In the above case, my .rhosts file reads 'psi.corp.sun.com' while the
remote machine identifies me as 'psi'. These names must match for rsh,
rcp or rdist to work. After I change my .rhosts file to reflect the
who, the logins will work correctly:
%% cat .rhosts
psi appel
(It should be noted that the remote machine determines the name for
your local machine by looking in the first entry of files, NIS, NIS+
or DNS, depending on how you have your name services set up. If you do
not like the way your remote machine is identifying your local
machine, you will need to determine which of these name services is
providing the incorrect information, and correct it.)
Q: Why do some remote sites refuse to let me connect to them via the
r-commands, complaining that they can't lookup my name?
A: This is probably because the machine you are connecting from does
not have a DNS PTR record. You should consult your DNS maps, and
verify that both A and PTR records are being propagated for the
machine in question. SunService has a document on DNS which explains
this all more in depth.
Q: Why do I get the following error when I connect to a machine via
the r-commands:
"protocol error. Connection Closed."
A: This typically occurs because the permissions on in.rlogind are
incorrectly set on the machine you are trying to connect to.
On a SunOS machine, make sure in.rlogind has the following perms:
-rwxr-xr-x 1 root staff 16384 Jan 20 1994 /usr/etc/in.rlogind
On a Solaris machine, make sure in.rlogind has the following perms:
-r-xr-xr-x 1 bin bin 10848 Jul 15 1994 /usr/sbin/in.rlogind
4.3: rcp and rdist Specific Problems
Q1: Why does rcp/rdist fail, even though permissions are set up right?
Q2: Why do I get one of the following errors when I rcp/rdist:
"stty: TCGETS: operation not supported on socket"
"stty: : Invalid argument"
A: rcp and rdist will fail if certain types of commands exist in the
.cshrc of the account on the remote machine. You can temporarily fix
this by simply moving the .cshrc on the remote machine:
%% mv ~/.cshrc ~/.cshrc.DONOTUSE
Alternatively, you can correct the .cshrc so that rcp and rdist will
work right. You must surround all stty and echo statements in the
.cshrc with an if ($?prompt) endif combination. For example, if the
following line is in your .cshrc:
stty dec
Change it to the following:
if ($?prompt) then
stty dec
endif
If this is done to all stty and echo commands, you should be able to
rcp and rdist to that account correctly.
5.0: Patches
The following is the list of all of the remote login related patches
for 4.1.3, 4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having remote
login problems, installing the patches is a good place to start,
especially if you recognize the general symptoms noted below.
In order for a machine to be stable, all of the recommended patches
should be installed as well. The list of recommended patches for your
operating system is available from sunsolve1.sun.com.
5.1: Remote Login Patches for SunOS
100383-06 SunOS 4.0.3 4.1 4.1.1 4.1.2 4.1.3: rdist security and hard link
Fixes a security bug which could cause rdist to create setuid root
programs. Also fixes an rdist problem related to hard links.
100468-03 SunOS 4.1.1 4.1.2 4.1.3: rcp/rsh should use setsockopt to detec
Corrects a bug in rcp's behavior when a remote machine crashed, and
also a bug in rsh regarding processes with lots of open file
descriptors.
101673-01 SunOS 4.1.3 Point Patch: rsh hangs, talking to a heavily loaded
This point patch adds a -T (timeout) flag to rsh that can be used
when logging in to a heavily loaded machine.
101488-01 SunOS 4.1.1 4.1.2 4.1.3: TTY settings change when rlogin into a
101561-05 SunOS 4.1.3_U1: TTY settings change when rlogin into a 4.x syst
Corrects an error regarding flow control that showed up when logging
in to SunOS machine from a Solaris machine.
5.1.1: Related Patches for SunOS
100891-13 SunOS 4.1.3: international libc jumbo patch
100890-12 SunOS 4.1.3: domestic libc jumbo patch
101558-07 SunOS 4.1.3_U1: international libc jumbo patch
101759-03 SunOS 4.1.3_U1: domestic libc jumbo patch
Correct a problem where telnet, rlogin and other internet connection
programs coredump if they try and connect to a machine with multiple
A records. Please be sure to install the domestic version, and not
the international version, if you are in the US, because the
international version does not include encryption, which is
necessary for login to work correctly.
5.2: Remote Login Patches for Solaris
101494-01 SunOS 5.3: rdist will not remove remote directories
Fixes a bug where rdist -R would not remove remote directories that
no longer existed on the master.
101681-01 SunOS 5.3: telnet patch
Corrects bugs regarding pipes, and Sun/Dec interaction.
101318-75 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
101945-36 SunOS 5.4: jumbo patch for kernel
101946-29 SunOS 5.4_x86: telnetd performance improvement
Improves telnet and rlogin performance by incorporating them into
the kernel.
Reference: http://stone.backrush.com/sunfaq/lmh005.html
Description :
. Tip Sheet for Remote Login Programs
Including telnet, rlogin, rsh, rcp, rdist, rcmd
. Section
1.0: About Remote Login Programs
2.0: Debugging Remote Login Problems
2.1: General Debugging Advice
2.2: Performance Analyis
3.0: Common How Tos
3.1: How to Increase ptys on a SunOS Machine
3.2: How to Increase ptys on a Solaris Machine
3.3: How to Allow/Disallow Remote root Logins under SunOS
3.4: How to Allow/Disallow Remote root Logins under Solaris
3.5: How to Add a Banner to a SunOS telnet Login
3.6: How to Add a Banner to a Solaris telnet Login
3.7: How to Grant rsh/rdist/rcp Permissions
3.8: How to rdist a Directory
4.0: Some Frequently Asked Questions
4.1: General Remote Login Problems
4.2: General R-command Problems
4.3: rcp and rdist Specific Problems
5.0: Patches
5.1: Remote Login Patches for SunOS
5.2: Remote Login Patches for Solaris
. Content
1.0: About Remote Login Programs
This Tip Sheet documents a wide variety of information concerning the
various remote login programs supported under SunOS and Solaris. This
includes telnet, rlogin, rsh and the related r-commands, rcmd, rcp and
rdist. This Tip Sheet is intended as a guide to the most common remote
login problems. Other references which contain some documentation on
the remote login programs are noted in Section 7.0.
2.0 Debugging Remote Login Problems
2.1: General Debugging Advice
The remote login programs very rarely experience problems other than
those outlined in this Tip Sheet. If you are experiencing additional
problems, the commands etherfind (SunOS) or snoop (Solaris) may be
used to discover exactly what is occuring on the network, and the
commands trace (SunOS) or truss (Solaris) may be used to discover
exactly what the commands are doing when they fail. However, the
information that these commands provide is very technical, and not
always easy to interpret.
2.2: Performance Analysis
Problems involving remote login performance are beyond the scope of
service that SunService can provide. If you having problems with
remote login performance, consult Section 8.0 or 9.0 for where you can
get assistance from within Sun.
3.0 Common How Tos
3.1: How to Increase ptys on a SunOS Machine
You may want to increase your number of ptys to allow more people to
make remote logins to your machine at one time. The below example
increases the number of ptys to 128.
First, create a kernel with 128 ptys, by editing your kernel
configuration file (ie, /sys/sun4c/conf/GENERIC). Change the
pseudo-device line, as follows:
pseudo-device pty128
Afterwards, compile and run this kernel.
Second, go to the /dev directory and create the new pty devices:
# cd /dev
# MAKEDEV pty0 pty1 pty2 pty3 pty4 pty5 pty6 pty7
Each pty# creates 16 master-slave pairs. Thus, making 8 sets, as shown
above, results in 8 * 16 = 128 ptys.
Third, add the new pty names to /etc/ttytab, following the examples
already present. The names are tty[pqrstuvw] [0123456789abcdef],
i.e., ttyp0 - ttypf, ttyq0 - ttyqf, ..., ttyw0 - ttywf.
3.2: How to Increase ptys on a Solaris Machine
You may want to increase your number of ptys to allow more people to
make remote logins to your machine at one time.
To increase the number of ptys (pseudo-terminal devices) under
Solaris 2.3, 2.4, and 2.5, two parameters MUST be entered into, or
modified in, the /etc/system file:
set pt_cnt=
set npty=
We also recommend at 2.4and 2.5, that you also add or modify the following
two parameters in the /etc/system file:
set sad_cnt=<2x number specified in pt_cnt>
set nautopush=
Then do a reconfiguration reboot for the changes to take effect (e.g. boot -r
at the boot "OK" prompt).
For example to set to allowing 128 ptys:
set pt_cnt=128
set npty=128
set sadcnt=256
set nautopush=128
pt_cnt sets the number of pty's for System V, while npty sets the number
of pty's for BSD. sadcnt and nautopush are STREAMS parameters and
are needed to support additional users and network resources (in particular
when using NTS terminal server rtelnet).
sadcnt is the number of streams addressable devices nautopush is the
number of streams autopush entries
In general:
nautopush should be the same as pt_cnt.
sadcnt should be 2x number of nautopush.
3.3: How to Allow/Disallow Remote root Logins under SunOS
root login permissions are controlled by the /etc/ttytab file under
SunOS. To change root login permissions, you must modify every single
'network' line in the /etc/ttytab files.
Root access over the network is granted, if all of the network ttys
are labeled secure:
ttyp0 none network off secure
Root access over the network is denied if all of the network ttys are
labelled unsecure:
ttyp0 none network off unsecure
After making changes to the ttytab, you must HUP process 1:
# kill -HUP 1
Alternatively, you can reboot the machine.
3.4: How to Allow/Disallow Remote root Logins under Solaris
In the file /etc/default/login, there is a CONSOLE line.
If this line is commented out, then root access over the network is
granted:
#CONSOLE=/dev/console
If there is no comment in front of the CONSOLE line, root can only
login from the console.
CONSOLE=/dev/console
Changes to this file will take effect at once.
3.5: How to Add a Banner to a SunOS telnet Login
The best way to have a banner displayed before the telnet login: is to
write a wrapper program:
main ()
{
system("/bin/cat /etc/telnetbanner")
execl("/usr/etc/in.telnetd.real","/usr/etc/in.telnetd.real",(char *)0)
}
This wrapper would be compiled and installed as /usr/etc/in.telnetd, a
message would be installed into /etc/telnetbanner, and the original
in.telnetd would then be moved to in.telnetd.real.
Although this setup should work, it is not officially supported by
SunService.
3.6: How to add a Banner to a Solaris telnet Login
Under Solaris 2.4 and higher, you can add a banner by utilizing the
/etc/issue file. Edit this file to contain your banner, and it will be
read and displayed before the login prompt.
%% cat /etc/issue
** USE THIS MACHINE AT YOUR OWN RISK **
%% telnet localhost
...
UNIX(r) System V Release 4.0 (psi)
** USE THIS MACHINE AT YOUR OWN RISK **
login:
This functionality is not available in versions of Solaris earlier
than 2.4 for those cases, you might want to try the workaround
described in Section 3.5, but it is not officially supported, and may
not work.
3.7: How to Grant rsh/rdist/rcp Permissions
If an individual user wants to be able to rsh into his account without
password, or rdist or rcp into his account, he must create a .rhosts
file. This file should simply contain the name of the remote machine
which should have the rsh/rdist/rcp permissions, and also the name of
the user's account on that machine. For example:
%% cat ~/.rhosts
psi appel
The above .rhosts file would allow me to rsh, rdist or rcp to my
account from the account 'appel' on the machine 'psi'.
Root can also grant global permissions with the hosts.equiv file. This
file simply contains a list of remote machines:
%% cat /etc/hosts.equiv
psi
If a machine is listed, all users on that machine will be able to rsh,
rcp or rdist to the local machine, as long as they have accounts on
both machines with the same login name.
The above would grant this permission to the remote machine 'psi'.
The hosts.equiv man page lists other options available in that
configuration file.
3.8: How to rdist a Directory
The most common usage of rdist is to copy an entire directory
structure from one machine to another. This can be done with the
following command:
%% rdist -c directory remotemachine:/directory
In order for the above to work, rdist must be granted remote
permissions, as described in Section 3.7 above. This command may also
be set up in a distfile script, as is described in the rdist man page.
4.0 Some Frequently Asked Questions
4.1: General Remote Login Problems
Q: Why do I get one of the following errors when I try and log in to
my machine? This only occurs when many people are already logged in:
"xxx: could not grant slave pty."
"xxx: open /dev/ptmx: No such device"
A: These errors occur because your machine has run out of ptys. The
default number of ptys is 48, which will usually allow somewhere
around 30-35 users to log in. You simply need to increase the number
of ptys, and then rebuild your kernel. Sections 3.1 and 3.2 outline
how to increase the number of ptys.
Q: Why do I get the following message when I try and log in to my
Solaris machine:
"xxx: open /dev/logindmux: No such file or directory"
A: This is due to a bug in a Solaris patch which implements in-kernel
telnet. It can be corrected by adding the following line to the file
/etc/name_to_major:
logindmux 114
Afterwards, reboot the machine with the reconfigure option:
# touch /reconfigure
# reboot
When the machine comes back up, you should be able to log in
correctly.
Q: Why do I get a core dump from telnet/rlogin when I try and connect
to certain remote machines from my SunOS machine?
A: This is a known bug that occurs when a remote machine has multiple
addresses. It is fixed in the libc patch for 4.1.3 and 4.1.3_u1. See
section 5.1.1 below.
Q1: Why do the r-commands hang forever?
Q2: why do telnet/rlogin give the following error:
"connect: Connection refused"
A: in.telnetd or in.rlogind are not being started up correctly on the
machine you are trying to connect to. Make sure that inetd is running
on that machine, and make sure that the following two lines are
uncommented in the /etc/inetd.conf:
telnet stream tcp nowait root /usr/sbin/in.telnetd in.telnetd
login stream tcp nowait root /usr/sbin/in.rlogind in.rlogind
(Locations will be slightly different on a SunOS machine).
If you have to make changes to inetd.conf, because the above lines are
missing, or commented out, you must restart inetd:
# kill -HUP inetd-pid
Q: Why do I get the following errors when I try and execute a remote
login:
"Network Unreachable"
"Host Unreachable"
A: These errors imply that routing is set up incorrectly to the
machine that you are trying to access. SunService has a seperate Tip
Sheet dedicated to Routing problems.
4.2: General R-command Problems
Q1: Why do I get a 'Password:' prompt when I rsh or rlogin?
Q2: Why do I get 'Permission Denied' when I rcp or rdist?
A1: You do not have a .rhosts file on the remote machine, correctly
listing your local machine. Section 3.7 explains how to set up a
.rhosts file.
A2: You are given explicit permissions to log in to the remote
machine, but the .rhosts file does not list your correct machine name.
For example, the .rhosts might mention your local machine's long host
name (ie, psi.corp.sun.com), while the remote machine actually
indentifies it by the short name (ie, psi) alternatively, your
.rhosts might read machine-le0, while the login request actually comes
from machine-le1. You can test this by logging in to the remote
machine (supplying your password), and then examining the .rhosts
file:
%% cat .rhosts
psi.corp.sun.com appel
Afterwards, run "who", look for your own login, and see what name your
local machine is identified as:
%% who
appel pts/10 Oct 6 09:59 (psi)
In the above case, my .rhosts file reads 'psi.corp.sun.com' while the
remote machine identifies me as 'psi'. These names must match for rsh,
rcp or rdist to work. After I change my .rhosts file to reflect the
who, the logins will work correctly:
%% cat .rhosts
psi appel
(It should be noted that the remote machine determines the name for
your local machine by looking in the first entry of files, NIS, NIS+
or DNS, depending on how you have your name services set up. If you do
not like the way your remote machine is identifying your local
machine, you will need to determine which of these name services is
providing the incorrect information, and correct it.)
Q: Why do some remote sites refuse to let me connect to them via the
r-commands, complaining that they can't lookup my name?
A: This is probably because the machine you are connecting from does
not have a DNS PTR record. You should consult your DNS maps, and
verify that both A and PTR records are being propagated for the
machine in question. SunService has a document on DNS which explains
this all more in depth.
Q: Why do I get the following error when I connect to a machine via
the r-commands:
"protocol error. Connection Closed."
A: This typically occurs because the permissions on in.rlogind are
incorrectly set on the machine you are trying to connect to.
On a SunOS machine, make sure in.rlogind has the following perms:
-rwxr-xr-x 1 root staff 16384 Jan 20 1994 /usr/etc/in.rlogind
On a Solaris machine, make sure in.rlogind has the following perms:
-r-xr-xr-x 1 bin bin 10848 Jul 15 1994 /usr/sbin/in.rlogind
4.3: rcp and rdist Specific Problems
Q1: Why does rcp/rdist fail, even though permissions are set up right?
Q2: Why do I get one of the following errors when I rcp/rdist:
"stty: TCGETS: operation not supported on socket"
"stty: : Invalid argument"
A: rcp and rdist will fail if certain types of commands exist in the
.cshrc of the account on the remote machine. You can temporarily fix
this by simply moving the .cshrc on the remote machine:
%% mv ~/.cshrc ~/.cshrc.DONOTUSE
Alternatively, you can correct the .cshrc so that rcp and rdist will
work right. You must surround all stty and echo statements in the
.cshrc with an if ($?prompt) endif combination. For example, if the
following line is in your .cshrc:
stty dec
Change it to the following:
if ($?prompt) then
stty dec
endif
If this is done to all stty and echo commands, you should be able to
rcp and rdist to that account correctly.
5.0: Patches
The following is the list of all of the remote login related patches
for 4.1.3, 4.1.3_u1, 4.1.4, 5.3 and 5.4. If you are having remote
login problems, installing the patches is a good place to start,
especially if you recognize the general symptoms noted below.
In order for a machine to be stable, all of the recommended patches
should be installed as well. The list of recommended patches for your
operating system is available from sunsolve1.sun.com.
5.1: Remote Login Patches for SunOS
100383-06 SunOS 4.0.3 4.1 4.1.1 4.1.2 4.1.3: rdist security and hard link
Fixes a security bug which could cause rdist to create setuid root
programs. Also fixes an rdist problem related to hard links.
100468-03 SunOS 4.1.1 4.1.2 4.1.3: rcp/rsh should use setsockopt to detec
Corrects a bug in rcp's behavior when a remote machine crashed, and
also a bug in rsh regarding processes with lots of open file
descriptors.
101673-01 SunOS 4.1.3 Point Patch: rsh hangs, talking to a heavily loaded
This point patch adds a -T (timeout) flag to rsh that can be used
when logging in to a heavily loaded machine.
101488-01 SunOS 4.1.1 4.1.2 4.1.3: TTY settings change when rlogin into a
101561-05 SunOS 4.1.3_U1: TTY settings change when rlogin into a 4.x syst
Corrects an error regarding flow control that showed up when logging
in to SunOS machine from a Solaris machine.
5.1.1: Related Patches for SunOS
100891-13 SunOS 4.1.3: international libc jumbo patch
100890-12 SunOS 4.1.3: domestic libc jumbo patch
101558-07 SunOS 4.1.3_U1: international libc jumbo patch
101759-03 SunOS 4.1.3_U1: domestic libc jumbo patch
Correct a problem where telnet, rlogin and other internet connection
programs coredump if they try and connect to a machine with multiple
A records. Please be sure to install the domestic version, and not
the international version, if you are in the US, because the
international version does not include encryption, which is
necessary for login to work correctly.
5.2: Remote Login Patches for Solaris
101494-01 SunOS 5.3: rdist will not remove remote directories
Fixes a bug where rdist -R would not remove remote directories that
no longer existed on the master.
101681-01 SunOS 5.3: telnet patch
Corrects bugs regarding pipes, and Sun/Dec interaction.
101318-75 SunOS 5.3: Jumbo patch for kernel (includes libc, lockd)
101945-36 SunOS 5.4: jumbo patch for kernel
101946-29 SunOS 5.4_x86: telnetd performance improvement
Improves telnet and rlogin performance by incorporating them into
the kernel.
Reference: http://stone.backrush.com/sunfaq/lmh005.html
Friday, July 24, 2009
How to upgrade VERITAS Volume Manager (VxVM)
How to upgrade VERITAS Volume Manager (VxVM) and Solaris from an older version of Solaris and SUNWvxvm.
--------------------------------------------------------------------------------
Details:
Update both VxVM and Solaris as follows:
Note: It is important to follow these steps in the specified order.
1.Obtain and install a VxVM 3.0.x license key. If currently running version 2.X or higher, there will be a valid key.
2. If any of the file systems /, /usr, /var,or /opt are defined on volumes, make sure that at least one plex for each of those
volumes is formed from a single subdisk that begins on a cylinder boundary. This is necessary because part of the upgrade process involves temporarily converting file systems on volumes back to using direct disk partitions and Solaris requires that disk partitions start on cylinder boundaries.
The upgrade scripts automatically convert file systems on volumes back to using regular disk partitions as necessary. If the upgrade scripts detect any problems (such as lack of cylinder alignment), they display an explanation of the problem
and the upgrade does not proceed.
3.Load and mount the CD-ROM or change to the directory into which the packages were downloaded. The CD-ROM
should then be visible as the file system mounted on /CD_path. If the CD-ROM is mounted automatically, its path
should be /cdrom/CD_name; if mounted manually, the path should be /mnt.
4.Run the upgrade_start script to prepare the previous release of the Volume Manager for its removal:
# CD_path/scripts/upgrade_start
or
scripts/upgrade_start (from the directory where the packages are located)
The upgrade_start script looks for volumes containing file systems. If certain key file systems must be converted back to using partitions, the script will indicate that a reboot is necessary. If so, reboot to single-user mode before proceeding to the next step. If any volumes are in use, they must either be unmounted or it is necessary to reboot to single-user mode.
5.Reboot to single-user mode (using a command such as /etc/shutdown).
6.Remove all SUNWvxvm and SUNWvxva patches and packages.Refer to Sun documentation for this procedure.
7.Shut down and halt the machine by using a command such as /etc/shutdown.
8.Boot from the Solaris CD-ROM to upgrade Solaris. Refer to Sun documentation for correct upgrade procedures.
9.Reboot the machine to single-user mode (using a command such as /etc/shutdown). It is now necessary to remount the CD-ROM manually or change into the directory where the packages have been downloaded.
10. Add the VxVM 3.0.x package by typing:
# pkgadd -d CD_path/OS_version/pkgs VRTSvxvm (from the cdrom)
or
# pkgadd -d . VRTSvxvm (from the directory where the packages are located)
If this returns warnings that include the string /etc/vx, they can be ignored and it can be continued.
11. Complete the upgrade by entering:
# CD_path/scripts/upgrade_finish (from the cdrom)
or
scripts/upgrade_finish (from the directory where the packages are located)
12.To disable the hot-relocation feature, comment out the vxrelocd line in the startup file /etc/rc2.d/S95vxvm-recover, as
follows:
#vxrelocd root &
13. Reboot to multi-user mode. At this point, the pre-upgrade configuration should be in effect and any file systems previously defined on volumes should be defined and mounted.
14.Using pkgadd, install any or all of the additional packages VRTSvmsa, VRTSvmdoc, VRTSvmman and VRTSvmdev.
15. Check the VERITAS support website for the latest patches for the Volume Manager version installed: http://support.veritas.com/
16.Importing a pre-3.x Volume Manager disk group does not automatically upgrade the disk group version to the VxVM 3.x level. It may be necessary to manually upgrade each of the disk groups following a VxVM upgrade:
vxdg upgrade
Reference: http://seer.entsupport.symantec.com/docs/230184.htm
--------------------------------------------------------------------------------
Details:
Update both VxVM and Solaris as follows:
Note: It is important to follow these steps in the specified order.
1.Obtain and install a VxVM 3.0.x license key. If currently running version 2.X or higher, there will be a valid key.
2. If any of the file systems /, /usr, /var,or /opt are defined on volumes, make sure that at least one plex for each of those
volumes is formed from a single subdisk that begins on a cylinder boundary. This is necessary because part of the upgrade process involves temporarily converting file systems on volumes back to using direct disk partitions and Solaris requires that disk partitions start on cylinder boundaries.
The upgrade scripts automatically convert file systems on volumes back to using regular disk partitions as necessary. If the upgrade scripts detect any problems (such as lack of cylinder alignment), they display an explanation of the problem
and the upgrade does not proceed.
3.Load and mount the CD-ROM or change to the directory into which the packages were downloaded. The CD-ROM
should then be visible as the file system mounted on /CD_path. If the CD-ROM is mounted automatically, its path
should be /cdrom/CD_name; if mounted manually, the path should be /mnt.
4.Run the upgrade_start script to prepare the previous release of the Volume Manager for its removal:
# CD_path/scripts/upgrade_start
or
scripts/upgrade_start (from the directory where the packages are located)
The upgrade_start script looks for volumes containing file systems. If certain key file systems must be converted back to using partitions, the script will indicate that a reboot is necessary. If so, reboot to single-user mode before proceeding to the next step. If any volumes are in use, they must either be unmounted or it is necessary to reboot to single-user mode.
5.Reboot to single-user mode (using a command such as /etc/shutdown).
6.Remove all SUNWvxvm and SUNWvxva patches and packages.Refer to Sun documentation for this procedure.
7.Shut down and halt the machine by using a command such as /etc/shutdown.
8.Boot from the Solaris CD-ROM to upgrade Solaris. Refer to Sun documentation for correct upgrade procedures.
9.Reboot the machine to single-user mode (using a command such as /etc/shutdown). It is now necessary to remount the CD-ROM manually or change into the directory where the packages have been downloaded.
10. Add the VxVM 3.0.x package by typing:
# pkgadd -d CD_path/OS_version/pkgs VRTSvxvm (from the cdrom)
or
# pkgadd -d . VRTSvxvm (from the directory where the packages are located)
If this returns warnings that include the string /etc/vx, they can be ignored and it can be continued.
11. Complete the upgrade by entering:
# CD_path/scripts/upgrade_finish (from the cdrom)
or
scripts/upgrade_finish (from the directory where the packages are located)
12.To disable the hot-relocation feature, comment out the vxrelocd line in the startup file /etc/rc2.d/S95vxvm-recover, as
follows:
#vxrelocd root &
13. Reboot to multi-user mode. At this point, the pre-upgrade configuration should be in effect and any file systems previously defined on volumes should be defined and mounted.
14.Using pkgadd, install any or all of the additional packages VRTSvmsa, VRTSvmdoc, VRTSvmman and VRTSvmdev.
15. Check the VERITAS support website for the latest patches for the Volume Manager version installed: http://support.veritas.com/
16.Importing a pre-3.x Volume Manager disk group does not automatically upgrade the disk group version to the VxVM 3.x level. It may be necessary to manually upgrade each of the disk groups following a VxVM upgrade:
vxdg upgrade
Reference: http://seer.entsupport.symantec.com/docs/230184.htm
Veritas VxVM & VxFS 3.2 – 5.0 upgrade procedure
Veritas VxVM & VxFS 3.2 – 5.0 upgrade procedure(this procedure should work for upgrading pre-4.0 versions to 4.1 and above)
** prior to starting, create the file: /etc/vx/reconfig.d/state.d/install-db
SUMMARY:
o if using EMC arrays/Powerpath for external storage, configure appropriately (see DETAILS below)
o break root mirror & unencapsulate
** (if any additional volumes have been created in the rootdg diskgroup, they should be backed up
as they will go away when the root drive is unencapsulated; it is never a good idea to
define data volumes on the boot drive in rootdg diskgroup) **
o uninstall 3.2 (remove pkgs & kill processes)
o install Storage Foundation 5.0 (and Maintenance Patch; MP1)
o if data disks are connected, verif the output of vxdisk list (the TYPE column)
o encapsulate & mirror root drive
o upgrading data disks
DETAILS:
o if using EMC arrays/Powerpath for external storage, configure appropriately
- decide if PowerPath should be upgraded or leave uninstalled to use Volume Manager DMP
(DMP will be automatically configured)
o if PowerPath will be upgraded, check with EMC for current compatible version of PowerPath
- see installation guide page 71 (Unsuppressing DMP for EMC PowerPath disks).
(http://support.veritas.com/docs/283887)
o break root mirror & unencapsulate
- … deport data disk groups …
(command: vxdg deport datadg (diskgroup)
(if the root drive is not mirrored, skip to “Unencapsulate boot drive” below)
- vxplex -g rootdg -o rm dis
(do this for each of the mirror drive plexes)
- vxdg -g rootdg rmdisk
- /usr/lib/vxvm/bin/vxdiskunsetup
- cd /etc
- ls *.prevm
(verify that vfstab & system exist, if so)
mv system system-
mv vfstab vfstab-
cp system.prevm system
cp vfstab.prevm vfstab
** (the mounts in the vfstab.prevm should match the slices in the output of:
prtvtoc /dev/rdsk/s2) **
o unencapsulate boot drive
- vxunroot (yes to reboot)
(returns boot drive to booting from native slices)
o uninstall 3.2 (remove pkgs & kill processes)
- … kill vx processes if they exist (ps -aef|grep vx) …
- cp -r /etc/vx/licenses/elm /var/tmp
- pkgrm (ls /opt/VRTS*|grep -v VRTS)
- rm -r /opt/VRTS*
- rm -r /etc/vx /var/vx
- reboot
o install SF 5.0 (and MP2 or latest release)
- … verify that no vx processes have started …
- uncompress & untar installation archive
(5.0 base release; must be downloaded from Customer Care; serial # require via license upgrade)
- run installsf
(or install ; ie … installvm for Volume Manager)
- uncompress & untar MP1 archive
(http://support.veritas.com/docs/288505)
- run installmp
(see included README and release notes)
o if data disks are connected, verify the output of vxdisk list (the TYPE column)
- auto:none (new uninitialized disks)
- auto:sliced (encapsulated disks containg slices)
o encapsulate & mirror root drive
- use vxdctl bootdg rootdg to create default rootdg disk group
- use vxdiskadm to encapsulate and mirror boot drive
(a spare drive must be initialized as sliced and belong to rootdg; vxdiskadm option 1)
(options 2 & 6)
- reboot
o upgrading data disks
- … import data disk groups …
- vxdg import datadg
- use “vxdg upgrade” to upgrade diskgroup versions
command: vxdg upgrade
- mount all data volumes
- use vxupgrade to upgrade vxfs filesystem versions one version at a time if appropriate
o use ‘fstyp | grep version’ to determine starting version
- use fsck (-o full) then vxupgrade to next version
(command: vxupgrade [-n new_version] mount_point )
(repeat until version 7 is reached)
(repititious fsck -o full can be timely but is best practice)
** prior to starting, create the file: /etc/vx/reconfig.d/state.d/install-db
SUMMARY:
o if using EMC arrays/Powerpath for external storage, configure appropriately (see DETAILS below)
o break root mirror & unencapsulate
** (if any additional volumes have been created in the rootdg diskgroup, they should be backed up
as they will go away when the root drive is unencapsulated; it is never a good idea to
define data volumes on the boot drive in rootdg diskgroup) **
o uninstall 3.2 (remove pkgs & kill processes)
o install Storage Foundation 5.0 (and Maintenance Patch; MP1)
o if data disks are connected, verif the output of vxdisk list (the TYPE column)
o encapsulate & mirror root drive
o upgrading data disks
DETAILS:
o if using EMC arrays/Powerpath for external storage, configure appropriately
- decide if PowerPath should be upgraded or leave uninstalled to use Volume Manager DMP
(DMP will be automatically configured)
o if PowerPath will be upgraded, check with EMC for current compatible version of PowerPath
- see installation guide page 71 (Unsuppressing DMP for EMC PowerPath disks).
(http://support.veritas.com/docs/283887)
o break root mirror & unencapsulate
- … deport data disk groups …
(command: vxdg deport datadg (diskgroup)
(if the root drive is not mirrored, skip to “Unencapsulate boot drive” below)
- vxplex -g rootdg -o rm dis
(do this for each of the mirror drive plexes)
- vxdg -g rootdg rmdisk
- /usr/lib/vxvm/bin/vxdiskunsetup
- cd /etc
- ls *.prevm
(verify that vfstab & system exist, if so)
mv system system-
mv vfstab vfstab-
cp system.prevm system
cp vfstab.prevm vfstab
** (the mounts in the vfstab.prevm should match the slices in the output of:
prtvtoc /dev/rdsk/
o unencapsulate boot drive
- vxunroot (yes to reboot)
(returns boot drive to booting from native slices)
o uninstall 3.2 (remove pkgs & kill processes)
- … kill vx processes if they exist (ps -aef|grep vx) …
- cp -r /etc/vx/licenses/elm /var/tmp
- pkgrm
- rm -r /opt/VRTS*
- rm -r /etc/vx /var/vx
- reboot
o install SF 5.0 (and MP2 or latest release)
- … verify that no vx processes have started …
- uncompress & untar installation archive
(5.0 base release; must be downloaded from Customer Care; serial # require via license upgrade)
- run installsf
(or install
- uncompress & untar MP1 archive
(http://support.veritas.com/docs/288505)
- run installmp
(see included README and release notes)
o if data disks are connected, verify the output of vxdisk list (the TYPE column)
- auto:none (new uninitialized disks)
- auto:sliced (encapsulated disks containg slices)
o encapsulate & mirror root drive
- use vxdctl bootdg rootdg to create default rootdg disk group
- use vxdiskadm to encapsulate and mirror boot drive
(a spare drive must be initialized as sliced and belong to rootdg; vxdiskadm option 1)
(options 2 & 6)
- reboot
o upgrading data disks
- … import data disk groups …
- vxdg import datadg
- use “vxdg upgrade” to upgrade diskgroup versions
command: vxdg upgrade
- mount all data volumes
- use vxupgrade to upgrade vxfs filesystem versions one version at a time if appropriate
o use ‘fstyp
- use fsck (-o full) then vxupgrade to next version
(command: vxupgrade [-n new_version] mount_point )
(repeat until version 7 is reached)
(repititious fsck -o full can be timely but is best practice)
Wednesday, July 8, 2009
Sed Tips
sed (Stream EDitor) refers to a Unix utility for parsing text files and the programming language it uses to apply textual transformations to a sequential stream of data. It reads input files line by line, applying the operation which has been specified via the command line (or a sed script), and then outputs the line. Getting started with sed can be a real pain if you are unfamiliar with perl for regular expressions.
FILE SPACING:
Double space a file
sed '/^$/d;G'
Undo double-spacing (assumes even-numbered lines are always blank)
sed 'n;d'
NUMBERING:
Number each line of a file (number on left, right-aligned)
sed = filename | sed 'N; s/^/ /; s/ *(.{6,})n/1 /'
Number each line of file, but only print numbers if line is not blank
sed '/./=' filename | sed '/./N; s/n/ /'
Count lines (emulates “wc -l”)
sed -n '$='
TEXT CONVERSION AND SUBSTITUTION:
Convert DOS newlines (CR/LF) to Unix format.
sed 's/.$//'
Convert Unix newlines (LF) to DOS format.
sed 's/$'"/`echo r`/"
Delete leading whitespace (spaces, tabs) from front of each line aligns all text flush left
sed 's/^[ t]*//’
Delete trailing whitespace (spaces, tabs) from end of each line
sed 's/[ t]*$//’
Delete BOTH leading and trailing whitespace from each line
sed 's/^[ t]*//;s/[ t]*$//’
Substitute (find and replace) “foo” with “bar” on each line
sed 's/foo/bar/' # replaces only 1st instance in a line
sed 's/foo/bar/4' # replaces only 4th instance in a line
sed 's/foo/bar/g' # replaces ALL instances in a line
Change “scarlet” or “ruby” or “puce” to “red”
sed 's/scarlet/red/g;s/ruby/red/g;s/puce/red/g'
SELECTIVE PRINTING OF CERTAIN LINES:
Print first 10 lines of file (emulates behavior of “head”)
sed 10q
Print first line of file (emulates “head -1″)
sed q
Print the last 10 lines of a file (emulates “tail”)
sed -e :a -e '$q;N;11,$D;ba'
Print the last 2 lines of a file (emulates “tail -2″)
sed '$!N;$!D'
Print the last line of a file (emulates “tail -1″)
sed -n '$p'
Print section of file based on line numbers (lines 8-12, inclusive)
sed -n '8,12p'
Print only lines which match regular expression (emulates “grep”)
sed '/regexp/!d'
Grep for AAA and BBB and CCC (in any order)
sed '/AAA/!d; /BBB/!d; /CCC/!d'
Grep for AAA and BBB and CCC (in that order)
sed '/AAA.*BBB.*CCC/!d'
SELECTIVE DELETION OF CERTAIN LINES:
Delete duplicate, consecutive lines from a file (emulates “uniq”).
sed '$!N; /^(.*)n1$/!P; D'
Delete duplicate, nonconsecutive lines from a file.
sed -n 'G; s/n/&&/; /^([ -~]*n).*n1/d; s/n//; h; P’
Delete all lines except duplicate lines (emulates “uniq -d”).
sed '$!N; s/^(.*)n1$/1/; t; D'
Delete the first line of a file
sed '1d'
Delete the first 10 lines of a file
sed '1,10d'
Delete the last line of a file
sed '$d'
Delete the last 2 lines of a file
sed 'N;$!P;$!D;$d'
Delete the last 10 lines of a file
sed -n -e :a -e '1,10!{P;N;D;};N;ba'
Delete lines matching pattern
sed '/pattern/d'
Delete ALL blank lines from a file (same as “grep ‘.’ “)
sed '/^$/d'
Remove most HTML tags (accommodates multiple-line tags)
sed -e :a -e 's/<[^>]*>//g;/
FILE SPACING:
Double space a file
sed '/^$/d;G'
Undo double-spacing (assumes even-numbered lines are always blank)
sed 'n;d'
NUMBERING:
Number each line of a file (number on left, right-aligned)
sed = filename | sed 'N; s/^/ /; s/ *(.{6,})n/1 /'
Number each line of file, but only print numbers if line is not blank
sed '/./=' filename | sed '/./N; s/n/ /'
Count lines (emulates “wc -l”)
sed -n '$='
TEXT CONVERSION AND SUBSTITUTION:
Convert DOS newlines (CR/LF) to Unix format.
sed 's/.$//'
Convert Unix newlines (LF) to DOS format.
sed 's/$'"/`echo r`/"
Delete leading whitespace (spaces, tabs) from front of each line aligns all text flush left
sed 's/^[ t]*//’
Delete trailing whitespace (spaces, tabs) from end of each line
sed 's/[ t]*$//’
Delete BOTH leading and trailing whitespace from each line
sed 's/^[ t]*//;s/[ t]*$//’
Substitute (find and replace) “foo” with “bar” on each line
sed 's/foo/bar/' # replaces only 1st instance in a line
sed 's/foo/bar/4' # replaces only 4th instance in a line
sed 's/foo/bar/g' # replaces ALL instances in a line
Change “scarlet” or “ruby” or “puce” to “red”
sed 's/scarlet/red/g;s/ruby/red/g;s/puce/red/g'
SELECTIVE PRINTING OF CERTAIN LINES:
Print first 10 lines of file (emulates behavior of “head”)
sed 10q
Print first line of file (emulates “head -1″)
sed q
Print the last 10 lines of a file (emulates “tail”)
sed -e :a -e '$q;N;11,$D;ba'
Print the last 2 lines of a file (emulates “tail -2″)
sed '$!N;$!D'
Print the last line of a file (emulates “tail -1″)
sed -n '$p'
Print section of file based on line numbers (lines 8-12, inclusive)
sed -n '8,12p'
Print only lines which match regular expression (emulates “grep”)
sed '/regexp/!d'
Grep for AAA and BBB and CCC (in any order)
sed '/AAA/!d; /BBB/!d; /CCC/!d'
Grep for AAA and BBB and CCC (in that order)
sed '/AAA.*BBB.*CCC/!d'
SELECTIVE DELETION OF CERTAIN LINES:
Delete duplicate, consecutive lines from a file (emulates “uniq”).
sed '$!N; /^(.*)n1$/!P; D'
Delete duplicate, nonconsecutive lines from a file.
sed -n 'G; s/n/&&/; /^([ -~]*n).*n1/d; s/n//; h; P’
Delete all lines except duplicate lines (emulates “uniq -d”).
sed '$!N; s/^(.*)n1$/1/; t; D'
Delete the first line of a file
sed '1d'
Delete the first 10 lines of a file
sed '1,10d'
Delete the last line of a file
sed '$d'
Delete the last 2 lines of a file
sed 'N;$!P;$!D;$d'
Delete the last 10 lines of a file
sed -n -e :a -e '1,10!{P;N;D;};N;ba'
Delete lines matching pattern
sed '/pattern/d'
Delete ALL blank lines from a file (same as “grep ‘.’ “)
sed '/^$/d'
Remove most HTML tags (accommodates multiple-line tags)
sed -e :a -e 's/<[^>]*>//g;/
Tuesday, June 30, 2009
SVM Mirror
An SVM Mirror is good for a couple of reasons ...
1. Faster reads (Data gets pulled off either drive to fulfill a READ request)
2. Redundancy, (If one drive fails, you don't lose data; make sure you replace it quick though, right?)
There are CONS too ...
1. Slower WRITE transactions
2. Two drives yields one drive of capacity
... but like the old saying goes, "Fast, reliable, inexpensive. Pick any two!"
When setting up SVM you need to do a number of things:
1. Setup the partitions on each drive (with the "# format" command)
2. Setup the State Database Replicas (SDR)
3. Create the Mirrors and Submirrors
4. Link them
5. Sync them
6. Test
Our example here will assume this ...
- DRIVE 0 = c1d0 = 2 SDR's
- DRIVE 1 = c2d0 = 2 SDR's
Now there are two issues with this SDR setup ...
CASE 1. During operation, what happens when a drive "fails".
CASE 2. During a reboot, What happens with "one" failed drive.
For CASE 1 ...
During operation, if either drive fails, the system will auto fail-over to the operating drive and continue normal operation. A message will likely be posted in syslog, and "SysAdmin intervention" will be required to fix the problem. Fixing can happen at your leisure, but during this time there is "NO REDUNDANCY". Search this document for "SysAdmin intervention" and you can find out what you need to do.
For CASE 2 ...
During a reboot, with either drive in a "Failed" status, "Sysadmin intervention" is required to fix things.
NOTE: SysAdmin intervention required means to delete references to SDR's on the bad disk to make the system bootable.
(This is the best we can do with a 2 drive setup. To understand why, read "Understanding the Majority Consensus Algorithm" and "Administering State Database Replicas" in the SVM manual. The best setup is an "ODD drive SVM array". (Example: 3 drives, 3 SDR's with one per drive, or 6 SDR's with 2 per disk for further redundancy.)
OVERVIEW
STEP #1 -> Repartition Drives to accommodate State Database Replica partitions
For a 320GB drive each cylinder is about 8MB. I chose 2 cylinders for each SDR. (Slice 6; size = 2 cyl = 16MB; UFS requires minimum 10MB per partition)
Here is the partition table of DRIVE 0 (320GB) ...
Volume: DRIVE0 Current partition table (original): Total disk cylinders available: 38910 + 2 (reserved cylinders)
Partition Tag Flag Cylinders Size Blocks
0 root wm 526 - 5750 40.03GB (5225/0/0) 83939625 -> / (ROOT)
1 swap wu 3 - 525 4.01GB (523/0/0) 8401995 -> /swap
2 backup wm 0 - 38909 298.07GB (38910/0/0) 625089150 -> ENTIRE DRIVE (Leave this alone)
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 38906 - 38907 15.69MB (2/0/0) 32130 -> SDR
6 unassigned wm 38908 - 38909 15.69MB (2/0/0) 32130 -> SDR
7 home wm 5751 - 38905 253.98GB (33155/0/0) 532635075 -> /export/home
8 boot wu 0 - 0 7.84MB (1/0/0) 16065 -> GRUB Stage 1?
9 alternates wu 1 - 2 15.69MB (2/0/0) 32130 -> GRUB Stage 2?
Here is the partition table of DRIVE 1 (320GB) ...
Volume: DRIVE1 Current partition table (original): Total disk cylinders available: 38910 + 2 (reserved cylinders)
Partition Tag Flag Cylinders Size Blocks
0 root wm 526 - 5750 40.03GB (5225/0/0) 83939625 -> / (ROOT)
1 swap wu 3 - 525 4.01GB (523/0/0) 8401995 -> /swap
2 backup wm 0 - 38909 298.07GB (38910/0/0) 625089150 -> ENTIRE DRIVE (Leave this alone)
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 38906 - 38907 15.69MB (2/0/0) 32130 -> SDR
6 unassigned wm 38908 - 38909 15.69MB (2/0/0) 32130 -> SDR
7 home wm 5751 - 38905 253.98GB (33155/0/0) 532635075 -> /export/home
8 boot wu 0 - 0 7.84MB (1/0/0) 16065 -> GRUB Stage 1?
9 alternates wu 1 - 2 15.69MB (2/0/0) 32130 -> GRUB Stage 2?
NOTE: Both drives are setup identical
STEP #2 -> Confirm Boot Order in BIOS = Boot from Disk 0 (On fail, Boot from Disk 1)
(NOTE: Don't worry if your BIOS doesn't support skipping a FAILED drive and auto-booting the next drive in ORDER. Solaris may do this automatically for you. It does for me. Remove one of the drives and boot to test it out on your system.)
STEP #3 -> Specify the master boot program for DRIVE 1
# fdisk -b /usr/lib/fs/ufs/mboot /dev/rdsk/c2d0p0 -> This means make sure the drive is "Active"
STEP #4 -> Make the Secondary Disk Bootable!
# /sbin/installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d0s0
STEP #5 -> Create the SDR's
# metadb -a -f c1d0s5 -> Create State Database Replica (slice 5 must be unmounted File system)
# metadb -a -f c1d0s6 -> Create State Database Replica (slice 6 must be unmounted File system)
# metadb -a -f c2d0s5 -> Create State Database Replica (slice 5 must be unmounted File system)
# metadb -a -f c2d0s6 -> Create State Database Replica (slice 6 must be unmounted File system)
# metadb -i -> Check your handy work
NOTE: Yes, I know, you can create SDR's as part of an existing partition because the first portion of the partition is reserved for SDR's BEFORE you actually create the partition and put data on it. If you know how to do this, go for it. In my opinion separate partitions has it's own benefits and I personally recommend it.
STEP #6 -> MIRROR BOOT(/) Partition
At this point we need to understand the nomenclature we are about to use.
d10 = this is the name we are arbitrarily assigning to DRIVE 0 / slice 0 (the root slice or partition) d20 = this is the name we are arbitrarily assigning to DRIVE 1 / slice 0 (the root slice or partition)
NOTE: You can use your own numbering scheme. I set up one that makes sense to me, and allows me to track "what's, what"! NOTE: Nevada supports "friendly names for metadevices". (Ex. Instead of "d0" you can use "Drive-1" or "whatever".)
d0 = this represents the NEW virtual drive we are creating that represents the SVM array for the "ROOT" partition.
Graphically this is what we are creating ...
D0
/ \
D10 D20
Before SVM, you would access partitions on the D10 (or D20) drive directly like this ... /dev/dsk/c1d0s0
After SVM, you will have a 'virtual' drive in place that you will access instead. (Meaning, you won't access the drives directly anymore. Get it?)
NOTE: All references in (/etc/vfstab) will be updated to point to this new drive (d0). When SVM is active, we don't want to communicate with "/dev/dsk/c1d0s0" anymore. We want to communicate with the new VIRTUAL drive "/dev/md/dsk/d0". The metaroot command updates (/etc/vfstab) for us automatically for the "ROOT" partition. For the other partitions we need to edit (/etc/vfstab) manually.
Let's get started ...
# metainit -f d10 1 1 c1d0s0 -> d10: Concat/Stripe is setup (Note: -f= force, 1 = one stripe, 1 = one slice)
# metainit d20 1 1 c2d0s0 -> d20: Concat/Stripe is setup
# metainit d0 -m d10 -> d0: Mirror is setup
# metaroot d0 -> DO THIS ONLY for "root" partition
# metastat d0 -> View current status (View your handy work!)
# reboot -> Need to reboot to effect changes
# metattach d0 d20 -> d0: submirror d20 is attached (and Sync'ing begins magically!)
# metastat d0 -> Check the Sync'ing (See?)
NOTE: Wait for Sync'ing to finish before rebooting, otherwise I think it restarts. You can test it and tell me!
STEP #7 -> MIRROR (/SWAP) Partition
# metainit -f d11 1 1 c1d0s1 -> d11: Concat/Stripe is setup
# metainit d21 1 1 c2d0s1 -> d21: Concat/Stripe is setup
# metainit d1 -m d11 -> d1: Mirror is setup
# vi /etc/vfstab -> (Edit the /etc/vfstab file so that /swap references the mirror)
"/dev/md/dsk/d1 - - swap - no -" -> Add this line to /etc/vfstab and comment out the old line. Remember, no quotes, right?
# reboot
# metattach d1 d21 -> d1: submirror d21 is attached (and Sync'ing begins magically!)
STEP #8 -> MIRROR (/export/home) partition
# umount /dev/dsk/c1d0s7 -> First umount the partition you want to mirror (-f to force)
# metainit d17 1 1 c1d0s7 -> d17: Concat/Stripe is setup
# metainit d27 1 1 c2d0s7 -> d27: Concat/Stripe is setup
# metainit d7 -m d17 -> d7: Mirror is setup
# vi /etc/vfstab -> (Edit the /etc/vfstab file so that /export/home references the mirror)
"/dev/md/dsk/d7 /dev/md/rdsk/d7 /export/home ufs 2 yes -" -> Add this line to /etc/vfstab and comment out the old line. Again, no quotes.
# mount /dev/md/dsk/d7 /export/home -> Remount this partition
# metattach d7 d27 -> d7: submirror d27 is attached (and Sync'ing begins magically!)
STEP #9 -> TIPS
# metastat d0 -> Check Status of "d0" Mirror
# metadb -d -f c1d0s6 -> If there is trouble, you can delete an SDR
EXAMPLE: Failed DRIVE 1 and "Sysadmin intervention" required ...
To Fix the problem temporarily ...
1. Power down
2. Remove Bad Drive 1
3. Boot into single user mode
4. Remove the "bad" SDR's on the 'Failed drive", Drive 1
5. Reboot (And the System should run fine, a little slow)
When you get a replacement drive ...
1. Power down
2. Insert the replacement drive (Same size, or bigger, right?)
3. Boot into multi-user mode
4. Repartition "NEW DRIVE 1" as per specs above
5. Make sure you create the SDR's as well
6. Build and link Mirrors together as per docs above
7. Resync drives as per these 3 commands ...
# metareplace -e d0 c1d0s0 -> d0: device c1d0s0 is enabled (SYNC ONE AT A TIME!)
# metareplace -e d1 c1d0s1 -> d1: device c1d0s1 is enabled (SYNC ONE AT A TIME!)
# metareplace -e d7 c1d0s7 -> d7: device c1d0s7 is enabled (SYNC ONE AT A TIME!)
NOTE: Additional commands that are handy!
# metadetach mirror submirror -> Detach a Mirror
# metaoffline mirror submirror -> Puts Submirror "OFFLINE"
# metaonline mirror submirror -> Puts Submirror "ONLINE"; Resync'ing begins immediately
# newfs /dev/rdsk/c1d0s1 -> newfs a Filesystem
NOTE SPECIAL FILES:
# pico /etc/lvm/mddb.cf -> (DO NO EDIT) records the locations of state database replicas
# pico /etc/lvm/md.cf -> (DO NO EDIT) contains auto generated config info for the default (unspecified or local) disk set
# /kernel/drv/md.conf -> (DO NO EDIT) contains the state database replica config info and is read by SVM at startup
# /etc/lvm/md.tab -> contains SVM config info that can be used to reconstruct your SVM config (Manually)
# metastat -p > /etc/lvm/md.tab -> This file created manually (just a dump to view info; save it!)
# metainit -> This commands can use the md.tab file as input to do their thing!! Like, RECOVER DATA!
# metadb -> This commands can use the md.tab file as input to do their thing!! Like, RECOVER DATA!
# metahs -> This commands can use the md.tab file as input to do their thing!! Like, RECOVER DATA!
1. Faster reads (Data gets pulled off either drive to fulfill a READ request)
2. Redundancy, (If one drive fails, you don't lose data; make sure you replace it quick though, right?)
There are CONS too ...
1. Slower WRITE transactions
2. Two drives yields one drive of capacity
... but like the old saying goes, "Fast, reliable, inexpensive. Pick any two!"
When setting up SVM you need to do a number of things:
1. Setup the partitions on each drive (with the "# format" command)
2. Setup the State Database Replicas (SDR)
3. Create the Mirrors and Submirrors
4. Link them
5. Sync them
6. Test
Our example here will assume this ...
- DRIVE 0 = c1d0 = 2 SDR's
- DRIVE 1 = c2d0 = 2 SDR's
Now there are two issues with this SDR setup ...
CASE 1. During operation, what happens when a drive "fails".
CASE 2. During a reboot, What happens with "one" failed drive.
For CASE 1 ...
During operation, if either drive fails, the system will auto fail-over to the operating drive and continue normal operation. A message will likely be posted in syslog, and "SysAdmin intervention" will be required to fix the problem. Fixing can happen at your leisure, but during this time there is "NO REDUNDANCY". Search this document for "SysAdmin intervention" and you can find out what you need to do.
For CASE 2 ...
During a reboot, with either drive in a "Failed" status, "Sysadmin intervention" is required to fix things.
NOTE: SysAdmin intervention required means to delete references to SDR's on the bad disk to make the system bootable.
(This is the best we can do with a 2 drive setup. To understand why, read "Understanding the Majority Consensus Algorithm" and "Administering State Database Replicas" in the SVM manual. The best setup is an "ODD drive SVM array". (Example: 3 drives, 3 SDR's with one per drive, or 6 SDR's with 2 per disk for further redundancy.)
OVERVIEW
STEP #1 -> Repartition Drives to accommodate State Database Replica partitions
For a 320GB drive each cylinder is about 8MB. I chose 2 cylinders for each SDR. (Slice 6; size = 2 cyl = 16MB; UFS requires minimum 10MB per partition)
Here is the partition table of DRIVE 0 (320GB) ...
Volume: DRIVE0 Current partition table (original): Total disk cylinders available: 38910 + 2 (reserved cylinders)
Partition Tag Flag Cylinders Size Blocks
0 root wm 526 - 5750 40.03GB (5225/0/0) 83939625 -> / (ROOT)
1 swap wu 3 - 525 4.01GB (523/0/0) 8401995 -> /swap
2 backup wm 0 - 38909 298.07GB (38910/0/0) 625089150 -> ENTIRE DRIVE (Leave this alone)
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 38906 - 38907 15.69MB (2/0/0) 32130 -> SDR
6 unassigned wm 38908 - 38909 15.69MB (2/0/0) 32130 -> SDR
7 home wm 5751 - 38905 253.98GB (33155/0/0) 532635075 -> /export/home
8 boot wu 0 - 0 7.84MB (1/0/0) 16065 -> GRUB Stage 1?
9 alternates wu 1 - 2 15.69MB (2/0/0) 32130 -> GRUB Stage 2?
Here is the partition table of DRIVE 1 (320GB) ...
Volume: DRIVE1 Current partition table (original): Total disk cylinders available: 38910 + 2 (reserved cylinders)
Partition Tag Flag Cylinders Size Blocks
0 root wm 526 - 5750 40.03GB (5225/0/0) 83939625 -> / (ROOT)
1 swap wu 3 - 525 4.01GB (523/0/0) 8401995 -> /swap
2 backup wm 0 - 38909 298.07GB (38910/0/0) 625089150 -> ENTIRE DRIVE (Leave this alone)
3 unassigned wm 0 0 (0/0/0) 0
4 unassigned wm 0 0 (0/0/0) 0
5 unassigned wm 38906 - 38907 15.69MB (2/0/0) 32130 -> SDR
6 unassigned wm 38908 - 38909 15.69MB (2/0/0) 32130 -> SDR
7 home wm 5751 - 38905 253.98GB (33155/0/0) 532635075 -> /export/home
8 boot wu 0 - 0 7.84MB (1/0/0) 16065 -> GRUB Stage 1?
9 alternates wu 1 - 2 15.69MB (2/0/0) 32130 -> GRUB Stage 2?
NOTE: Both drives are setup identical
STEP #2 -> Confirm Boot Order in BIOS = Boot from Disk 0 (On fail, Boot from Disk 1)
(NOTE: Don't worry if your BIOS doesn't support skipping a FAILED drive and auto-booting the next drive in ORDER. Solaris may do this automatically for you. It does for me. Remove one of the drives and boot to test it out on your system.)
STEP #3 -> Specify the master boot program for DRIVE 1
# fdisk -b /usr/lib/fs/ufs/mboot /dev/rdsk/c2d0p0 -> This means make sure the drive is "Active"
STEP #4 -> Make the Secondary Disk Bootable!
# /sbin/installgrub -m /boot/grub/stage1 /boot/grub/stage2 /dev/rdsk/c2d0s0
STEP #5 -> Create the SDR's
# metadb -a -f c1d0s5 -> Create State Database Replica (slice 5 must be unmounted File system)
# metadb -a -f c1d0s6 -> Create State Database Replica (slice 6 must be unmounted File system)
# metadb -a -f c2d0s5 -> Create State Database Replica (slice 5 must be unmounted File system)
# metadb -a -f c2d0s6 -> Create State Database Replica (slice 6 must be unmounted File system)
# metadb -i -> Check your handy work
NOTE: Yes, I know, you can create SDR's as part of an existing partition because the first portion of the partition is reserved for SDR's BEFORE you actually create the partition and put data on it. If you know how to do this, go for it. In my opinion separate partitions has it's own benefits and I personally recommend it.
STEP #6 -> MIRROR BOOT(/) Partition
At this point we need to understand the nomenclature we are about to use.
d10 = this is the name we are arbitrarily assigning to DRIVE 0 / slice 0 (the root slice or partition) d20 = this is the name we are arbitrarily assigning to DRIVE 1 / slice 0 (the root slice or partition)
NOTE: You can use your own numbering scheme. I set up one that makes sense to me, and allows me to track "what's, what"! NOTE: Nevada supports "friendly names for metadevices". (Ex. Instead of "d0" you can use "Drive-1" or "whatever".)
d0 = this represents the NEW virtual drive we are creating that represents the SVM array for the "ROOT" partition.
Graphically this is what we are creating ...
D0
/ \
D10 D20
Before SVM, you would access partitions on the D10 (or D20) drive directly like this ... /dev/dsk/c1d0s0
After SVM, you will have a 'virtual' drive in place that you will access instead. (Meaning, you won't access the drives directly anymore. Get it?)
NOTE: All references in (/etc/vfstab) will be updated to point to this new drive (d0). When SVM is active, we don't want to communicate with "/dev/dsk/c1d0s0" anymore. We want to communicate with the new VIRTUAL drive "/dev/md/dsk/d0". The metaroot command updates (/etc/vfstab) for us automatically for the "ROOT" partition. For the other partitions we need to edit (/etc/vfstab) manually.
Let's get started ...
# metainit -f d10 1 1 c1d0s0 -> d10: Concat/Stripe is setup (Note: -f= force, 1 = one stripe, 1 = one slice)
# metainit d20 1 1 c2d0s0 -> d20: Concat/Stripe is setup
# metainit d0 -m d10 -> d0: Mirror is setup
# metaroot d0 -> DO THIS ONLY for "root" partition
# metastat d0 -> View current status (View your handy work!)
# reboot -> Need to reboot to effect changes
# metattach d0 d20 -> d0: submirror d20 is attached (and Sync'ing begins magically!)
# metastat d0 -> Check the Sync'ing (See?)
NOTE: Wait for Sync'ing to finish before rebooting, otherwise I think it restarts. You can test it and tell me!
STEP #7 -> MIRROR (/SWAP) Partition
# metainit -f d11 1 1 c1d0s1 -> d11: Concat/Stripe is setup
# metainit d21 1 1 c2d0s1 -> d21: Concat/Stripe is setup
# metainit d1 -m d11 -> d1: Mirror is setup
# vi /etc/vfstab -> (Edit the /etc/vfstab file so that /swap references the mirror)
"/dev/md/dsk/d1 - - swap - no -" -> Add this line to /etc/vfstab and comment out the old line. Remember, no quotes, right?
# reboot
# metattach d1 d21 -> d1: submirror d21 is attached (and Sync'ing begins magically!)
STEP #8 -> MIRROR (/export/home) partition
# umount /dev/dsk/c1d0s7 -> First umount the partition you want to mirror (-f to force)
# metainit d17 1 1 c1d0s7 -> d17: Concat/Stripe is setup
# metainit d27 1 1 c2d0s7 -> d27: Concat/Stripe is setup
# metainit d7 -m d17 -> d7: Mirror is setup
# vi /etc/vfstab -> (Edit the /etc/vfstab file so that /export/home references the mirror)
"/dev/md/dsk/d7 /dev/md/rdsk/d7 /export/home ufs 2 yes -" -> Add this line to /etc/vfstab and comment out the old line. Again, no quotes.
# mount /dev/md/dsk/d7 /export/home -> Remount this partition
# metattach d7 d27 -> d7: submirror d27 is attached (and Sync'ing begins magically!)
STEP #9 -> TIPS
# metastat d0 -> Check Status of "d0" Mirror
# metadb -d -f c1d0s6 -> If there is trouble, you can delete an SDR
EXAMPLE: Failed DRIVE 1 and "Sysadmin intervention" required ...
To Fix the problem temporarily ...
1. Power down
2. Remove Bad Drive 1
3. Boot into single user mode
4. Remove the "bad" SDR's on the 'Failed drive", Drive 1
5. Reboot (And the System should run fine, a little slow)
When you get a replacement drive ...
1. Power down
2. Insert the replacement drive (Same size, or bigger, right?)
3. Boot into multi-user mode
4. Repartition "NEW DRIVE 1" as per specs above
5. Make sure you create the SDR's as well
6. Build and link Mirrors together as per docs above
7. Resync drives as per these 3 commands ...
# metareplace -e d0 c1d0s0 -> d0: device c1d0s0 is enabled (SYNC ONE AT A TIME!)
# metareplace -e d1 c1d0s1 -> d1: device c1d0s1 is enabled (SYNC ONE AT A TIME!)
# metareplace -e d7 c1d0s7 -> d7: device c1d0s7 is enabled (SYNC ONE AT A TIME!)
NOTE: Additional commands that are handy!
# metadetach mirror submirror -> Detach a Mirror
# metaoffline mirror submirror -> Puts Submirror "OFFLINE"
# metaonline mirror submirror -> Puts Submirror "ONLINE"; Resync'ing begins immediately
# newfs /dev/rdsk/c1d0s1 -> newfs a Filesystem
NOTE SPECIAL FILES:
# pico /etc/lvm/mddb.cf -> (DO NO EDIT) records the locations of state database replicas
# pico /etc/lvm/md.cf -> (DO NO EDIT) contains auto generated config info for the default (unspecified or local) disk set
# /kernel/drv/md.conf -> (DO NO EDIT) contains the state database replica config info and is read by SVM at startup
# /etc/lvm/md.tab -> contains SVM config info that can be used to reconstruct your SVM config (Manually)
# metastat -p > /etc/lvm/md.tab -> This file created manually (just a dump to view info; save it!)
# metainit -> This commands can use the md.tab file as input to do their thing!! Like, RECOVER DATA!
# metadb -> This commands can use the md.tab file as input to do their thing!! Like, RECOVER DATA!
# metahs -> This commands can use the md.tab file as input to do their thing!! Like, RECOVER DATA!
Monday, June 29, 2009
Different ways to count the number of lines in a file
-bash-3.00$ awk 'END{print NR}' file
16
-bash-3.00$ wc -l file
16 file
-bash-3.00$ sed -n '$=' file
16
-bash-3.00$
16
-bash-3.00$ wc -l file
16 file
-bash-3.00$ sed -n '$=' file
16
-bash-3.00$
awk one-liner Tips
Print column1, column5 and column7 of a data file or output of any columns list
$awk ‘{print $1, $5, $7}’ data_file
$cat file_name |awk ‘{print $1 $5 $7}’
$ls –al |awk ‘{print $1, $5, $7}’ -- Prints file_permissions,size and date
Syntax of running an awk program
Awk ‘program’ input file(s)
List all files names whose file size greater than zero.
$ls –al |awk ‘$5 > 0 {print $9}’
List all files whose file size equal to 512bytes.
$ls –al |awk ‘$5 == 0 {print $9}’
print all lines
$awk ‘{print }’ file_name
$awk ‘{print 0}’ file_name
Number of lines in a file
$awk ‘ END {print NR}’ file_name
Number of columns in each row of a file
$awk ‘ {print NF’} file_name
Sort the output of file and eliminate duplicate rows
$awk ‘{print $1, $5, $7}’ |sort –u
List all file names whose file size is greater than 512bytes and owner is "oracle"
$ls –al |awk ‘$3 == "oracle" && $5 > 512 {print $9}’
List all file names whose owner could be either "oracle" or "root"
$ls –al |awk ‘$3 == "oracle" || $3 == "root" {print $9}’
list all the files whose owner is not "oracle
$ls –al |awk ‘$3 != "oracle" {print $9}’
List all lines which has atlease one or more characters
$awk ‘NF > 0 {print }’ file_name
List all lines longer that 50 characters
$awk ‘length($0) > 50 ‘{print }’ file_name
List first two columns
$awk ‘{print $1, $2}’ file_name
Swap first two columns of a file and print
$awk ‘{temp = $1; $1 = $2; $2 = temp; print }’ file_name
Replace first column as "ORACLE" in a data file
$awk ‘{$1 = "ORACLE"; print }’ data_file
Remove first column values in a data file
$awk ‘{$1 =""; print }’ data_file
Calculate total size of a directory in Mb
$ls –al |awk ‘{total +=$5};END {print "Total size: " total/1024/1024 " Mb"}’
Calculate total size of a directory including sub directories in Mb
$ls –lR |awk ‘{total +=$5};END {print "Total size: " total/1024/1024 " Mb"}’
Find largest file in a directory including sub directories
$ls –lR |awk ‘{print $5 "\t" $9}’ |sort –n |tail -1
$awk ‘{print $1, $5, $7}’ data_file
$cat file_name |awk ‘{print $1 $5 $7}’
$ls –al |awk ‘{print $1, $5, $7}’ -- Prints file_permissions,size and date
Syntax of running an awk program
Awk ‘program’ input file(s)
List all files names whose file size greater than zero.
$ls –al |awk ‘$5 > 0 {print $9}’
List all files whose file size equal to 512bytes.
$ls –al |awk ‘$5 == 0 {print $9}’
print all lines
$awk ‘{print }’ file_name
$awk ‘{print 0}’ file_name
Number of lines in a file
$awk ‘ END {print NR}’ file_name
Number of columns in each row of a file
$awk ‘ {print NF’} file_name
Sort the output of file and eliminate duplicate rows
$awk ‘{print $1, $5, $7}’ |sort –u
List all file names whose file size is greater than 512bytes and owner is "oracle"
$ls –al |awk ‘$3 == "oracle" && $5 > 512 {print $9}’
List all file names whose owner could be either "oracle" or "root"
$ls –al |awk ‘$3 == "oracle" || $3 == "root" {print $9}’
list all the files whose owner is not "oracle
$ls –al |awk ‘$3 != "oracle" {print $9}’
List all lines which has atlease one or more characters
$awk ‘NF > 0 {print }’ file_name
List all lines longer that 50 characters
$awk ‘length($0) > 50 ‘{print }’ file_name
List first two columns
$awk ‘{print $1, $2}’ file_name
Swap first two columns of a file and print
$awk ‘{temp = $1; $1 = $2; $2 = temp; print }’ file_name
Replace first column as "ORACLE" in a data file
$awk ‘{$1 = "ORACLE"; print }’ data_file
Remove first column values in a data file
$awk ‘{$1 =""; print }’ data_file
Calculate total size of a directory in Mb
$ls –al |awk ‘{total +=$5};END {print "Total size: " total/1024/1024 " Mb"}’
Calculate total size of a directory including sub directories in Mb
$ls –lR |awk ‘{total +=$5};END {print "Total size: " total/1024/1024 " Mb"}’
Find largest file in a directory including sub directories
$ls –lR |awk ‘{print $5 "\t" $9}’ |sort –n |tail -1
Sunday, June 28, 2009
Year 2038 bug
What is the year 2038 bug?
In the first month of the year 2038 C.E. many computers will encounter a date-related bug in their operating systems and/or in the applications they run. This can result in incorrect and grossly inaccurate dates being reported by the operating system and/or applications. The effect of this bug is hard to predict, because many applications are not prepared for the resulting "skip" in reported time - anywhere from 1901 to a "broken record" repeat of the reported time at the second the bug occurs. Also, leap seconds may make some small adjustment to the actual time the bug expresses itself. I expect this bug to cause serious problems on many platforms, especially Unix and Unix-like platforms, because these systems will "run out of time". Starting at GMT 03:14:07, Tuesday, January 19, 2038, expect to see lots of systems around the world breaking magnificently: satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system failures, phone system interruptions (including 911 emergency services), banking system crashes, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in the year 2038! Consider the year 2000 just a dry run. In case you think we can sit on this issue for another 30 years before addressing it, consider that reports of temporal echoes of the 2038 problem are already starting to appear in future date calculations for mortgages and vital statistics!.
What causes it?
What makes January 19, 2038 a special day? Unix and Unix-like operating systems do not calculate time in the Gregorian calendar, they simply count time in seconds since their arbitrary "birthday", GMT 00:00:00, Thursday, January 1, 1970 C.E. The industry-wide practice is to use a 32-bit variable for this number (32-bit signed time_t). Imagine an odometer with 32 wheels, each marked to count from 0 and 1 (for base-2 counting), with the end wheel used to indicate a positive or negative integer. The largest possible value for this integer is 2**31-1 = 2,147,483,647 (over two billion). 2,147,483,647 seconds after Unix's birthday corresponds to GMT 03:14:07, Tuesday, January 19, 2038. One second later, many Unix systems will revert to their birth date (like an odometer rollover from 999999 to 000000). Because the end bit indicating positive/negative integer may flip over, some systems may revert the date to 20:45:52, Friday, December 13, 1901 (which corresponds to GMT 00:00:00 Thursday, January 1, 1970 minus 2**31 seconds). Hence the media may nickname this the "Friday the Thirteenth Bug".
Sources:
http://en.wikipedia.org/wiki/Year_2038_problem
http://www.2038bug.com/
http://computer.howstuffworks.com/question75.htm
In the first month of the year 2038 C.E. many computers will encounter a date-related bug in their operating systems and/or in the applications they run. This can result in incorrect and grossly inaccurate dates being reported by the operating system and/or applications. The effect of this bug is hard to predict, because many applications are not prepared for the resulting "skip" in reported time - anywhere from 1901 to a "broken record" repeat of the reported time at the second the bug occurs. Also, leap seconds may make some small adjustment to the actual time the bug expresses itself. I expect this bug to cause serious problems on many platforms, especially Unix and Unix-like platforms, because these systems will "run out of time". Starting at GMT 03:14:07, Tuesday, January 19, 2038, expect to see lots of systems around the world breaking magnificently: satellites falling out of orbit, massive power outages (like the 2003 North American blackout), hospital life support system failures, phone system interruptions (including 911 emergency services), banking system crashes, etc. One second after this critical second, many of these systems will have wildly inaccurate date settings, producing all kinds of unpredictable consequences. In short, many of the dire predictions for the year 2000 are much more likely to actually occur in the year 2038! Consider the year 2000 just a dry run. In case you think we can sit on this issue for another 30 years before addressing it, consider that reports of temporal echoes of the 2038 problem are already starting to appear in future date calculations for mortgages and vital statistics!.
What causes it?
What makes January 19, 2038 a special day? Unix and Unix-like operating systems do not calculate time in the Gregorian calendar, they simply count time in seconds since their arbitrary "birthday", GMT 00:00:00, Thursday, January 1, 1970 C.E. The industry-wide practice is to use a 32-bit variable for this number (32-bit signed time_t). Imagine an odometer with 32 wheels, each marked to count from 0 and 1 (for base-2 counting), with the end wheel used to indicate a positive or negative integer. The largest possible value for this integer is 2**31-1 = 2,147,483,647 (over two billion). 2,147,483,647 seconds after Unix's birthday corresponds to GMT 03:14:07, Tuesday, January 19, 2038. One second later, many Unix systems will revert to their birth date (like an odometer rollover from 999999 to 000000). Because the end bit indicating positive/negative integer may flip over, some systems may revert the date to 20:45:52, Friday, December 13, 1901 (which corresponds to GMT 00:00:00 Thursday, January 1, 1970 minus 2**31 seconds). Hence the media may nickname this the "Friday the Thirteenth Bug".
Sources:
http://en.wikipedia.org/wiki/Year_2038_problem
http://www.2038bug.com/
http://computer.howstuffworks.com/question75.htm
Error : "Error in Semaphore Operation - No space left on device"
NBU Error:
"Error in Semaphore Operation - No space left on device"
Solution: Refer Symantec TechNote.
http://support.veritas.com/docs/238063 (Requires reboot).
"Error in Semaphore Operation - No space left on device"
Solution: Refer Symantec TechNote.
http://support.veritas.com/docs/238063 (Requires reboot).
Explanation of semaphore, message queue and shared memory settings in /etc/system
Details:
This TechNote gives a brief explanation about the shared memory, message queue and semaphore settings used in /etc/system.
Shared memory
set shmsys:shminfo_shmmin = minimum shared memory segment size
set shmsys:shminfo_shmmax = maximum shared memory segment size
set shmsys:shminfo_shmseg = maximum attached shared memory segments per process
set shmsys:shminfo_shmmni = number of shared memory identifiers
Message queues
set msgsys:msginfo_msgmap = number of entries in message map
set msgsys:msginfo_msgmax = maximum message size
set msgsys:msginfo_msgmnb = maximum number of bytes on queue
set msgsys:msginfo_msgmni = number of message queue identifiers
set msgsys:msginfo_msgssz = message segment size (multiple of word size)
set msgsys:msginfo_msgtql = number of system message headers
set msgsys:msginfo_msgseg = number of message segments
Semaphores
set semsys:seminfo_semmap = number of entries in semaphore map
set semsys:seminfo_semmni = number of semaphore identifiers
set semsys:seminfo_semmns = number of semaphores in system
set semsys:seminfo_semmnu = number of undo structures in system
set semsys:seminfo_semmsl = maximum number of semaphores per id
set semsys:seminfo_semopm = maximum number of operations per semop call
set semsys:seminfo_semume = maximum number of undo entries per process
More information about suggested default values can be found in TechNote 238063, which can be found in the Related Section of this TechNote. Sun Microsystems SunSolve document ID 2270 available at http://sunsolve.sun.com also provides more detail about each of these kernel tuning parameters.
This TechNote gives a brief explanation about the shared memory, message queue and semaphore settings used in /etc/system.
Shared memory
set shmsys:shminfo_shmmin =
set shmsys:shminfo_shmmax =
set shmsys:shminfo_shmseg =
set shmsys:shminfo_shmmni =
Message queues
set msgsys:msginfo_msgmap =
set msgsys:msginfo_msgmax =
set msgsys:msginfo_msgmnb =
set msgsys:msginfo_msgmni =
set msgsys:msginfo_msgssz =
set msgsys:msginfo_msgtql =
set msgsys:msginfo_msgseg =
Semaphores
set semsys:seminfo_semmap =
set semsys:seminfo_semmni =
set semsys:seminfo_semmns =
set semsys:seminfo_semmnu =
set semsys:seminfo_semmsl =
set semsys:seminfo_semopm =
set semsys:seminfo_semume =
More information about suggested default values can be found in TechNote 238063, which can be found in the Related Section of this TechNote. Sun Microsystems SunSolve document ID 2270 available at http://sunsolve.sun.com also provides more detail about each of these kernel tuning parameters.
Subscribe to:
Posts (Atom)