ldom commands

1. ldm list-devices -a
2. ldm list-bindings primary
3. ldm set-mau 1 primary
4. ldm set-vcpu 8 primary
5. ldm set-memory 2g primary
6. ldm list-domain -l primary
7. ldm list-services

8. ldm add-vdiskserver primary-vds0 primary - adding disk service
9. ldm add-vconscon port-range=99-199 primary-vcc0 primary - adding console port range
10. ldm add-vswitch net-dev=nxge0 primary-vsw0 primary - adding virtual switch service
11. ldm list-services primary
12. ldm list-spconfig - see configurations
13. ldm list

Still updating.....

Running Hardware diags on Solaris and Linux

Solaris -

# prtidiag -v

Default tool which comes with Solaris.
Displays system diagnostic information

------------------------------------------------------

#/opt/FJSVmadm/sbin/hrdconf -l

Fujitsu hardware native command for sparc server. Gives details config of hardware status.
------------------------------------------------------

Interactive

#/opt/FJSVmadm/sbin/madmin

The following options will show any HW failure/alerts.

- 2. Hardware Monitoring Information

-  1. Management of Hardware Error Event

- select d 

You will get something like this -

Display abnormalities

Units detected abnormality:

No.  Date                     Unit

Select unit by number.

You can confirm details and select appropriate action.

------------------------------------------------------

'/var/adm/messages'  is a very good place to look for hardware related messages. Sun Solaris has a very good feature which logs each and every kernell event in logs.

If you there is any doubt, it is always suggested to go through the logs.

Example: The following events indicate scsi controller failure which was not visible in prtdiag.

Jan 11 23:24:19 wpsh214 scsi: [ID 107833 kern.warning] WARNING: /pci@1f,4000/scsi@5 (glm2):

Jan 11 23:24:19 wpsh214         Unexpected DMA state: WAIT. dstat=a0<DMA-FIFO-empty,bus-fault>

Jan 11 23:24:19 wpsh214 genunix: [ID 408822 kern.info] NOTICE: glm2: fault detected in device; service still available

Jan 11 23:24:19 wpsh214 genunix: [ID 611667 kern.info] NOTICE: glm2: Unexpected DMA state: WAIT. dstat=a0<DMA-FIFO-empty,bus-fault>

Jan 11 23:24:19 wpsh214 scsi: [ID 107833 kern.warning] WARNING: /pci@1f,4000/scsi@5 (glm2):

Jan 11 23:24:19 wpsh214         got SCSI bus reset

Jan 11 23:24:19 wpsh214 genunix: [ID 408822 kern.info] NOTICE: glm2: fault detected in device; service still available

Jan 11 23:24:19 wpsh214 genunix: [ID 611667 kern.info] NOTICE: glm2: got SCSI bus reset

Jan 11 23:24:27 wpsh214 scsi: [ID 107833 kern.warning] WARNING: /pci@1f,4000/scsi@5/sd@c,0 (sd48):

------------------------------------------------------

Serial

#/opt/FJSVmadm/sbin/serialid -a

Model

#/opt/FJSVhwr/sbin/getmodelcode

------------------------------------------------------

#/opt/FJSVhwr/sbin/fjprtdiag -v

------------------------------------------------------

'fmadm faulty' 

This is a very useful command which lists faults in a OS running Sparc.

One drawback of this command is that the faults are not cleared automatically. We have to do it manually. If not we may end up troubleshooting some old messages.

http://docs.oracle.com/cd/E19166-01/E20792/z40031541454621.html

------------------------------------------------------

Apart for the above, some of Sun consoles give detailed hardware info.

Eg: E & M series have domain and platform consoles. ilom and alom consoles.

_________________________________________________________________________

Linux - Most of the Linux physical servers are hosted on HP or Dell.

HP has it's own CLI HW utility and so does Dell.

HP - 

1. hpasmcli - HP Management Command Line Interface, is a scriptable command line tool to manage and monitor the HP Hardware.

2. hpacucli - HP Array Configuration Utility.

Dell -

omreport - Dell open manager. 

How to create a new file with current date stamp?

 Use `date '+%Y%m%d%H%M'` to add date stamp to a file.

Example:

#touch file.`date '+%Y%m%d%H%M'`

will give the output as 

file.201207140947

Command 'fsck ' in Solaris.

Checking and Repairing Unix File system with fsck

fsck is a Unix utility for checking and repairing file system inconsistencies . File system can become inconsistent due to several reasons and the most common is abnormal shutdown due to hardware failure , power failure or switching off the system without proper shutdown. Due to these reasons the superblock in a file system is not updated and has mismatched information relating to system data blocks, free blocks and inodes .

fsck – Modes of operation :

fsck operates in two modes interactive and non interactive :
Interactive – fsck examines the file system and stops at each error it finds in the file system and gives the problem description and ask for user response whether to correct the problem or continue without making any change to the file system.

Non interactive :fsck tries to repair all the problems it finds in a file system without stopping for user response useful in case of a large number of inconsistencies in a file system but has the disadvantage of removing some useful files which are detected to be corrupt .

If file system is found to have problem at the booting time non interactive fsck is run and all errors which are considered safe to correct are corrected. But if still file system has problems the system boots in single user mode asking for user to manually run the fsck to correct the problems in file system.

Running fsck :
fsck should always be run in a single user mode which ensures proper repair of file system . If it is run in a busy system where the file system is changing constantly fsck may see the changes as inconsistencies and may corrupt the file system .

If the system can not be brought in a single user mode fsck should be run on the partitions ,other than root & usr , after unmounting them . Root & usr partitions can not be unmounted . If the system fails to come up due to root/usr files system corruption the system can be booted with CD and root/usr partitions can be repaired using fsck.

command syntax
fsck [ -F fstype] [-V] [-yY] [-o options] special
-F fstype type of file system to be repaired ( ufs , vxfs etc)
-V verify the command line syntax but do not run the command
-y or -Y Run the command in non interactive mode – repair all errors encountered without waiting for user response.
-o options Three options can be specified with -o flag
b=n where n is the number of next super block if primary super block is corrupted in a file system .
p option used to make safe repair options during the booting process.
f force the file system check regardless of its clean flag.
special – Block or character device name of the file system to be checked/repaired – for example /dev/rdsk/c0t3d0s4 .Character device should be used for consistencies check & repair
fsck phases
fsck checks the file system in a series of 5 pages and checks a specific functionality of file system in each phase.
** phase 1 – Check Blocks and Sizes
** phase 2 – Check Pathnames
** phase 3 – Check Connectivity
** phase 4 – Check Reference Counts
** phase 5 – Check Cylinder Groups
fsck error messages & Corrective action :

1. Corrupted superblock – fsck fails to run
If the superblock is corrupted the file system still can be repaired using alternate superblock which are formed while making new file system .
the first alternate superblock number is 32 and others superblock numbers can be found using the following command :
newfs -N /dev/rdsk/c0t0d0s6
for example to run fsck using first alternate superblock following command is used
fsck -F ufs -o b=32 /dev/rdsk/c0t0d0s6

2. Link counter adjustment
fsck finds mismatch between directory inode link counts and actual directory links and prompts for adjustment in case of interactive operation. Link count adjustments are considered to be a safe operation in a file system and should be repaired by giving ‘y’ response to the adjust ? prompt during fsck.

3. Free Block count salvage
During fsck the number of free blocks listed in a superblock and actual unallocated free blocks count does not match. fsck inform this mismatch and asks to salvage free block count to synchronize the superblock count. This error can be corrected without any potential problem to the file system or files.

4. Unreferenced file reconnection
While checking connectivity fsck finds some inodes which are allocated but not referenced – not attached to any directory . Answering y to reconnect message by fsck links these files to the lost+found directory with their inode number as their name .
To get more info about the files in lost+found ‘file’ command can be used to see the type of files and subsequently they can be opened in their applications or text editors to find out about their contents. If the file is found to be correct it can be used after copying to some other directory and renaming it.

Booting Process Explained

Booting Process in Solaris

Understanding the booting process is important in the sense that you can get a clear idea when a system faces a booting problem if you are familiar with the booting sequence and steps involved. You can thereby isolate a booting phase and quickly resolve the issues.
Booting process in Solaris can be divided in to different phases for ease of study . First phase starts at the time of switching on the machine and is boot prom level , it displays a identification banner mentioning machine host id serial no , architecture type memory and Ethernet address This is followed by the self test of various systems in the machine.
This process ultimately looks for the default boot device and reads the boot program from the boot block which is located on the 1-15 blocks of boot device. The boot block contains the ufs file system reader which is required by the next boot processes.

The ufs file system reader opens the boot device and loads the secondary boot program from /usr/platform/`uname –i`/ufsboot ( uname –i expands to system architecture type)
The boot program above loads a platform specific kernel along with a generic solaris kernel
The kernel initialize itself and load modules which are required to mount the root partition for continuing the booting process.

The booting process undergoes the following phases afterwards :
1) init phase
2) inittab file
3) rc scripts & Run Level

1. INIT phase
Init phase is started by the execution of /sbin/init program and starts other processes after reading the /etc/inittab file as per the directives in the /etc/inittab file .
Two most important functions of init are
a) It runs the processes to bring the system to the default run level state ( Run level 3 in Solaris , defined by initdefault parameter in /etc/inittab )
b) It controls the transition between different run levels by executing appropriate rc scripts to start and the stop the processes for that run level.

2. /etc/inittab file
This file states the default run level and some actions to be performed while the system reaches up to that level. The fields and their explanation are as follows :
S3:3:wait:/sbin/rc3 > /dev/console 2>&1 < /dev/console
S3 denotes a identification if the line
3 is run level
wait is action to be performed
/sbin/rc3 is the command to be run.
So the fields in the inittab are
Identification : run level : action : process
The complete line thus means run the command /sbin/rc3 at run level 3 and wait until the rc3 process is complete.
The action field can have any of the following keywords :
Initdefault : default run level of the system
Respawn : start and restart the process if it stops.
Powerfail : stop on powerfail
Sysinit : start and wait till console in accessible .
Wait : wait till the process ends before going on to the next line.

3. RC scripts & Run Levels
Rc scripts performs the following functions :
a) They check and mount the file systems
b) Start and stop the various processes like network , nfs etc.
c) Perform some of the house keeping jobs.
System goes in to one of the following run level after booting depending on default run level and the commands issued for changing the run level to some other one.
0 Boot prom level ok> or > prompt in Sun.
1 Administrative run level . Single user mode
2 Multiuser mode with no resource sharing .
3 Multiuser level with nfs resource sharing
4 Not used
5 Shutdown & power off (Sun 4m and 4u architecture )
6 Reboot to default run level
S s Single user mode user logins are disabled.
Broadly speaking the running system can be in any of the folloing state
Single user – Minimum processes running , user logins disabled and root password is required to gain access to the shell .
Multiuser - All system processes are running and user logins are permitted
Run level of a desired state is achieved by a number of scripts executed by the rc program the rc scripts are located in /etc/rc0.d , /etc/rc1.d , /etc/rc2.d , /etc/rc3.d & /etc/rcS.d directories . All the files of a particular run level are executed in the alphanumeric order .Those files beginning with letter S starts the processes and those beginning with K stops the processes.
These files are hard linked to the files in /etc/init.d in order to provide a central location for all these files and eliminating the need to change the run level in case these scripts needs to be run separately . The files in /etc/init.d directory are without any S , K and numeric prefix instead a stop / start argument has to be supplied whenever these scripts are to be executed .
By default system has a number of rc scripts needed for run level transition but sometimes it becomes necessary to start some custom scripts at the booting time and turn them off at the shutdown . Custom scripts can be put in any of the required rc directory but following major considerations has to be kept in mind :
* The sequence number of the file should not conflict with other files.
* The sevices needed should be available by previously executed scripts.
* File should be hard linked to the /etc/init.d directory .
* The system looks for only those files beginning with letter K & S , any thing else is ignored , therefore, to make a file inactive simply changing uppercase K or S to lower case will cause system to ignore it .

Boot Procedure in Solaris

Booting process inside solaris SPARC architecture is done with the help of middleware layer known as firmware. This firmware is known as OBP (Open Boot Prompt), this layer is used to manage the H/W independent of Operating System. The entire information of OBP is stored inside 1 Mb Chip known as as Prom (Programmable read only memory) Chip.

                                                            The parameters stored inside the chip are known as NVRAM(Non Volatile Random access memory) parameters. We can set the parameters such as booting sequence, identifying devices, set alias names for device and also provide security for devices.

Boot Process:

-         Boot Prom

-         Boot Programme

-         Kernel  initialization

-         Init phase

-         Svc.startd (SMF)

1.     Boot Prom: In this phase it loads the primary boot block known as boot block on to the memory.

Backend:

a.     When the server is powered on the PROM run POST (Power on self test).

b.     POST identifies all the devices and boot prom identifies bootable devices with the help of NVRAM parameters “boot-device”

c.      It reads the VTOC(Volume Table of contents) of boot device and reads the slice number zero from 1-15 sectors and loads the boot on the 16^th memory.

d.     At the time of initialization, installed boot programme will load boot block into 1-15^th sector of root (/)

2.     Boot Programme:

This loads the secondary boot known as UFS book.

a.     In this phase the boot block will load the secondary boot block known as UFS boot on to memory.

b.     The location of UFS boot is stored inside bootblock by installed boot programme.

c.      UFS boot contains two parts of kernel knows as UNIX and GENUNIX which is platform dependant and independent respectfully.

d.     UFS boot combine these tow part kernel into a single running kernel.

3.     Kernel Initialization: It reads the file /etc/system to get boot parameters.

a.     In this phase the UFS boot will start the kernel and the kernel will read the file /etc/system file.

b.     The kernel cannot load by itself and hence takes the help of UFS boot till it loads the root (/) module.

c.      Once root module is loaded it starts booting by itself.

d.     In this phase the kernel will start the first phase of process known as init process with process ID 1.

4.     /etc/inittab (init phase):

a.      In this phase the first process called init process will read the file /etc/inittab.

b.     Till Solaris 9, system in this phase use to come with the help of run level.

c.      Run levels define the system state of reach.

d.     From Solaris 10 onwards this file does not contain any run leve but this will start the master starter and restarter daemon known as svcstartd. This daemon will enable the main configuration daemon svcconfigd. This will read repository database to start the services.

RUN LEVELS In Solaris 10

0          -----------        Ok Boot prompt

s or S  -----------        Single user with only critical file system.

1          -----------        Single user with all filesystems mounted.

2         -----------        Multiuser without NFS

3          -----------        Multiuser with NFS

4          -----------        Reserved

5          -----------        Shutdown or power off

6          -----------        Reboot

#init is the command to change from one run level to another . The major difference Init s and Init 1 is – when we change from run level 3 to run level s and go back to run level 3, the users will be automatically connected. But in the case of run level 1 the users will have to manually connect to the server.

To know a run level - #who –r
It has four fields

a.     Current runlevel

b.     Date and time

c.      The current runlevel

d.     The no of times at this run-level since the last reboot.

e.     Previous runlevel

/etc/inittab file contain four fields

a.     ID

b.     Rstate (One or more runlevels to which this entry applies)

c.      Action (How the process to be treated)

d.     Process ( The command or the script to be scripted)

When we change from one run level to another runlevel or while booting the system to the appropriate runlevel it executes the runlevel scripts which are stored under the /etc/ directory.

#cd /etc

#ls | grep rc

            This rc#.d directory contains scripts which start with ‘S’ knows as starting and ‘K’ known as killing scripts.

#cd rcs.d

#ls

When ever we mention the default runlevel as 3. The sysinit entry in the /etc/inittab will execute following commands

/sbin/autopush

/sbin/soconfig

/sbin/rcS

            The ‘R’ state inside the inittab will execute

                                    /sbin/rc2

                                    /sbin/rc3

            From Solaris 10 onwards the system will not boot with the help of runlevels, it boots with the help of milestone.

            A milestone is defined as a system state of reach.

A repository database is an configurations database which maintain the information of services and how to manage these services.
            Repository DB contains default milestone information with which it boots the server. It increases the performance while booting, as it starts all the services parallel.

Important points to be remembered:

Path of bootblock in X86

#cd /usr/platform/i86pc/lib/fs/ufs

In SPARC machines

# cd /usr/platform/sun4c/lib/fs/ufs

How to install boot block – Login to a system in single user mode

            Ok>    boot cdrom –s
            * Go to a location (Root ‘/’ file)

Installboot bootblk /dev/rdsk/c0t0d0s0

            The booting process of Solaris has changed from Solaris 10 2006 release onwards. It has been redesigned in such a fashion to have a common boot process between SPARC and X86 architecture. As a part of redesign the Solaris boot archives and bootadm commands are introduced in both architectures.

The primary difference between X86 and SPARC is, how the boot device and the files are selected at boot time.

The SPARC based platforms continue to use OBP as primary administrative interface with boot-options selected by using OBP commands. But in X86 architecture the options are selected through BIOS and GRUB.

In order to understand the new device we have to know bootup and shutdown terminal.

VCS Brief Notes. Veritas Cluster Service.

                                         VERITAS CLUSTER

-              Cluster is a combination of multiple nodes connected inside a network to provide high availability to the application at any point of time.

-              There are two types of configurations asymmetric and symmetric.

-              symmetric configuration is also known as active passive configuration at any point of time one node will be active and another node will be passive.

-              n symmetric configuration both nodes are active, each performing its own task if one node fails the other will take the responsibility for running all the services.

-              e Service groups inside cluster perform 1)fail over 2) parallel 3) hybrid operations,

-              e two daemons in a cluster are:

1)HAD daemon and 2)HA shadow daemon, these two daemons are always running in all the nodes of a cluster.

-              he entire configuration of the cluster is managed by HAD daemon HA shadow acts like backup and also perform load balance.

-              There are two main configuration files inside cluster

Main.cf:- which maintains the cluster id the list of users can manage cluster and the no of service groups created inside the cluster.

Types.cf:- this file maintains default attributes information

-              The primary task of HAD daemon is to maintain same copy of these files inside the cluster it also maintain backup of these file before performing any modifications to the cluster.

-              The communication between the cluster is done with the help of high priority links used for private communication, it uses LLT (low latency transfer protocol)and GAB(group membership atomic broadcast protocol) protocols to communication b/w the nodes.

-              These files are responsible in maintaining the communication information inside the node.

/etc/llthosts:- contains node ID and node name.

/etc/llttab:- contains cluster ID, node id and the no.of links used for communication b/w the nodes.

/etc/gabtab:- maintains the membership information of nodes inside the cluster.

Installation requirements for cluster:-

Min 512mb ram,NIC cards for private public communication and common storage

Appilication Requirements to install on a cluster:-

1)It should have independent stop start procedures

2)It should have ability to clear falls and individual monitoring service

3) must have capable of running on multiple nodes should support common storage

*hastatus –sum            –status of a cluster

*hagrp –list                    -list service groups

Start and stop daemons

cd /etc/rc3.d    - use to start and stop daemons

#hastatrt

#hastop   -is use to stop our local node

#hastop –all

How to stop the remote node

#hastop –sys sys1 –evacuate

Taking a snapshot of vcs configuration files:--

#hasnap –backup –m “test backup of nfssg”

Managing users inside vcs:-

#hauser –list   (will list users of vcs)

#hauser –display (will display users along vth priviliges)

#hauser –add user1 (crate a user)

#hauser –addpriv user1  Administrator (to assign a priviliges to uer)

#hauser –delpriv user1 Administrator  (to remove priviliges)

#hagrp –list

#hagrp –state  -to know the status of service group

#hagrp –resources nfssg

Quering resources types:-

#hatype  –resources ip

#hatype  –list

#haclus  –list

#haclus  –display

#haclus  -state

Creating Zones on New Disk Using Veritas

1. df -h

2. format   <-------- create root tag partition s0 = 5g    (Please create partition on empty disk )

3. newfs /dev/dsk/c1t2d0s0

#mkdir zones

4. mkdir /zones/bdxapi01

5. vi /etc/vfstab

/dev/dsk/c1t2d0s0       /dev/rdsk/c1t2d0s0      /zones/bdxapi01 ufs     2       yes     logging

6. mountall

Note: Please enable VERITAS if not enabled

vxdctl mode  ( to check the status )

vxconfigd -k  ( to disable the VERITAS )

vxdctl init ( if volboot file not exist )

vxdctl enable ( to enable the VERITAS )

vxdisk list  ( to check the VERITAS disk information )

7. Vxdiskadm option-2 (encapsulate)

- localdg ------>Specify the disk group name

- local01  .......Specify the disk name

- sliced  ......Specify the format model (by default cds format)

=====

If encapsulation fails... then

a. vxdisksetup -if c1t2d0

b. vxdiskunsetup -C c1t2d0

c. then do steps 2-7 again

=====

8. reboot

9. vxprint -ht

10. vxmksdpart -g localdg local01-01 0 0x02 0x00

vxmksdpart -g <disk group >  <sub disk>  slice tag flag

Or

vxmksdpart -g bdxapi01_dg0 bdxapi01_dg001-01 0 0x02 0x00  ( This is important step for future updates )

vxmksdpart -g bdxapi02_dg0 bdxapi02_dg001-01 0 0x02 0x00

11. A) vxedit -g localdg rename rootvol2-01 z1-01

vxedit -g <disk group> rename <plex old name>  <plex new name>

Or

vxedit -g bdxapi01_dg0 rename rootvol2-01 bdxapi01-01  (to rename plex)

vxedit -g bdxapi02_dg0 rename rootvol2-01 bdxapi02-01

 b) vxedit -g localdg rename rootvol2 z1

vxedit -g <disk group> rename <volume old name>  <volume new name>

Or

vxedit -g bdxapi01_dg0 rename rootvol2 bdxapi01   ( to rename volume )

vxedit -g bdxapi02_dg0 rename rootvol2 bdxapi02

12. vi /etc/vfstab to modify the devices   ( edit the volume name )

Note:

Please edit the new volume name in /etc/vfstab entry

From:

/dev/vx/dsk/localdg/rootvol2    /dev/vx/rdsk/localdg/rootvol2   /zones/z1       ufs     2       yes     logging

To:

/dev/vx/dsk/localdg/z1  /dev/vx/rdsk/localdg/z1 /zones/z1       ufs     2       yes     logging

 13. vxassist -g localdg make localhome 5g       ( to create volumes )

vxprint -ht

14. mkfs -F vxfs /dev/vx/rdsk/localdg/localhome       ( to create file system for VXFS )

Note: Please create directory for mount point

Example:

#cd /zones/bdxapi01

#mkdir localhome

15. vi /etc/vfstab to add all new devices/mount points             ( Please edit the /etc/vfstab file below mentioned)

#

/dev/vx/dsk/localdg/localhome /dev/vx/rdsk/localdg/localhome /zones/bdxapi01/localhome vxfs - yes -

Example:

# zone01

/dev/vx/dsk/zone1_dg/patrol /dev/vx/rdsk/zone1_dg/patrol /zones/z1/patrol vxfs - yes -

/dev/vx/dsk/zone1_dg/controlm /dev/vx/rdsk/zone1_dg/controlm /zones/z1/controlm vxfs - yes -

/dev/vx/dsk/zone1_dg/localhome /dev/vx/rdsk/zone1_dg/localhome /zones/z1/localhome vxfs - yes -

/dev/vx/dsk/zone1_dg/sbt /dev/vx/rdsk/zone1_dg/sbt /zones/z1/sbt vxfs - yes -

/dev/vx/dsk/zone1_dg/orahome /dev/vx/rdsk/zone1_dg/orahome /zones/z1/orahome vxfs - yes -

/dev/vx/dsk/zone1_dg/sbtlog /dev/vx/rdsk/zone1_dg/sbtlog /zones/z1/sbtlog vxfs - yes -

15. mountall   ( it should be mounted with above mentioned mount point)

Note: Please start to create zone

#mkdir /zones/bdxapi01/boot

#chmod 700 /zones/bdxapi01/boot

#zonecfg -z <zone name >                    (Lets assume zone name as zone1)

#zonecfg:zone1>create   (for sparse root zone )

#zonecfg:zone1>create -b ( for whole root zone )

#zonecfg:zone1>set zonepath=/zones/bdxapi01/boot

#zonecfg:zone1>set autoboot=true

#zonecfg:zone1>add net  ( to add n/w interface )

#zonecfg:zone1:net>set physical=bge0

#zonecfg:zone1:net>set address=170.137.228.250

#zonecfg:zone1:net>end

#zonecfg:zone1>info

#zonecfg:zone1>verify

#zonecfg:zone1>commit

#zonecfg:zone1>add fs

#zonecfg:zone1:fs>set dir

#zonecfg:zone1:fs>set special=/zones/bdxapi01/localhome

#zonecfg:zone1:fs>set type=lofs

#zonecfg:zone1:fs>set options=rw

#zonecfg:zone1:fs>end

#zonecfg:zone1>info

#zonecfg:zone1>verify

#zonecfg:zone1>commit

#zonecfg:zone1>exit

Note: you can specify no. of file systems using above mentioned configuration

16. zoneadm list -vc   ( Now you can find zone1 is in installed state )

Note: Please create any file name under /var/tmp for backup purpose

17. zonecfg -z zone1 -f /var/tmp/z1

18. zoneadm -z zone1 install     (after execution of this command it should be in configured state )

19. zoneadm -z zone1 boot       (after execution of this command it should be in running state)

20. zlogin -C zone1        <-- If you want  set time zone, hostname, root-password, etc

 

ZONE's in Solaris

Zone: A zone is an OS level virtualization introduced from Solaris 10 to give isolation & security to the applications on server. Main advantage is data center consolidation. We can combine multiple physical servers into one physical server and provide same environment for all the applications. From2008 release a new concept called "BRAND ZONE" has been introduced. This enables us to run Solaris 8/9/10 on Sparc servers and any Linux flavors on X86 servers. A maximum of8192 zones can be created inside one physical server independent of Hardware configuration.

PURPOSE: OS level virtualization.

TYPES: Global zone and Non global zone.

NON-Global zone: Sparc root, whole root and brand zone

FILES: /etc/vfstab , /etc/zones

PACKAGES: SUNWzoner

DAEMONS: zoneadm & zxched

COMMANDS: #zonecfg, #zoneadm & #zlogin

STATES: configured, installed, incomplete, ready, running & shutdown/halt

There are two types of zones - "global zones" and "non global zone"

Global zone: Login as first instance
Non Global zone: It is an virtualized OS in a server.

Features of Global zone: It is a default zone used for system wide configuration and control.
Zone id = 0. It provides a single bootable instance of Solaris environment.
Contains info of all the devices and full installation packages of Solaris 10 OS. Contains its own configuration :- hostname, IP address, User info.....etc
It is the only zone which is aware of Non Global Zone. It is the only zone from which all the Non Global Zone can be managed.

Features of Non Global Zone: It is created by global zone and is also managed by it. A non global zone is assigned a zone id by the system when it is booted. Whenever a Non global zone is rebooted the zone ID changes. Non global zone shares the kernell from Global zone.
A non global zone is not aware of the other non global zones and it cannot administer itself. It contains additional software which is used at installation time It contains a sub set of packages from Global zone which are required to boot and run the OS.

Zone root path:
1. Sparc root zone: In this instance only root "/" is copied and other files and shared. Minimum space required is 100mb.
2. Whole root zone: In this instance everything is copied. Minimum space required is 4Gb.

Sparce Root Zone: Sharing is optimized by implementing read only loop back filesystem from Global zone and only installs a subset of system root packages locally. Majority of Filesystem is share from Global zone. Minimum space requirement is 100 mb.

Whole Root Zone :  All required packages are copied to zone's private Filesystem and minimum size required is 4 gb.

Daemons in Zones : Two major daemons run - zoneadm & zsched


Zoneadm : This daemon starts when a zone needs to be managed. An instance of zoneadm daemon will be started for each zone. Hence it is not uncommon to have multiple instance running a single server.
This daemon is responsible for the following tasks.
- Allocates the zone id and starts Zsced process.
- Sets system wide resource controls.
- Plumbs the virtual network interface.
- Mounts the loopback Filesystem and shares the resources from Global Zone.

Zsced : Zone scheduler daemon is started by zoneadm and exists for each active zone. A zone is said to be active when it is in "ready", "running" or "shutdown" states. The job of this daemon is to keeptrack of kernell threats running within the zone.

Zone States: 


Configured: A zone in this state has completed configuration, confirmed storage and additional configuration must be done after initial reboot.

Incomplete: This state is shown during installation or un-installation process. After this task is completed the state changes to installed / uninstalled state.

Installed: Confirmed configuration state. #zoneadm command is used to verify that the zone is going to run in the specified environment. The base binaries required to run and boot the zone are copied from Global Zone to Non Global Zone. Virtual environment is not set at this stage.
Ready: Kernell creates Zsced process and virtual environment is set. Network interfaces are plumbed and Filesystem's are mount and Zone ID is assigned by the system.

Running: A zone enters this state when the first user process is created. This is a normal state of operational zone.

Shutdown: This is a transitional state, only visible when a process is being halted or cannot shutdown for any reason.

Security in Solaris

SERVER HARDENING:
This is a concept of making a server secure and to run 24/7 applications.
This is a post installation process, ies: After installing OS, based on the application need we harden the server.

The following tasks are performed :-
1. Removing unnecessary services.
2. Disable auto install scripts so that no user can install any applications.
3. Disable media drives (CD, DVD..etc) and USB.
4. Removing unnecessary user accounts.
5. Maintaining log for all services.
6. Giving permissions for all files and directories.
7. Manage space requirements.
8. Consolidate the server for better performance.

CONCEPTS USED:
- SET UID (User ID) & SET GID (Group ID)
- Stickybit
- ACL (Access control list)
- RBAC (Role based access)

FILES:
- /etc/default/login
- /etc/default/passwd
- /etc/security/policy.conf
- /etc/wtmpx
- /etc/utmpx
- /etc/adm/sulog
- /var/adm/loginlog
- /etc/nologin
- /etc/user_attr
- /etc/security/prof_attr
- /etc/security/auth_attr
- /etc/security/exec_attr

COMMANDS:

#roleadd
#rolemod
#roledel
#chmod
#chown
#newgrp
#useradd
#usermod
#su

Whenever a user logs in, permissions are verified based on UID. The OS also maintains effective UIS which represents the current environment of the user.

Denying root user login in Solaris

root is the superuser in unix and can do about everything. We need root rights to perform advanced administration in unix platforms and there are multiple users doing it. Anyone with root login can perform destructive steps (Like running "rm -rf /") which can go untraced on who did it! In order to avoid it, this step is done  and to ensures that no one log's in directly as root.

The best practice is to login as a user and perform switch user operation to root for administration rights.

Do the following steps
# vi /etc/default/login

* go to CONSOLE= /dev/console
* remove /dev/console

Save and exit

Now root cannot directly login to this system.


.

Steps to monitor failed logins in Solaris

Creating loginlog file
# touch /var/adm/loginlog


Changing permissions
# chmod 600 /var/adm/login.log


# vi /etc/default/logins
edit the following
* RETRIES=3
Note: you can change the retries as per your requirement.

# vi /etc/security/policy.conf
edit the following
* LOCK_AFTER_RETRIES=NO (Change it to YES)

The failed login tries are logged in here
# cat /var/adm/default/login

Dynamic Multipathing with VXDMP

DMP (Dynamic Multipathing):-

This is a feature available in Vxvm to provide reliability, redundancy and availability of data. DMP is automatically configured when we install veritas. With DMP we can connect multiple paths to an multiported array.

Multiported disk arrays can be connected to the host system through multiple paths. Till veritas 3.2 we can connect a max of 32 paths to a single server. From 4.x onwards the count is unlimited.

When multi paths are connected DMP uses a mechanism that is specific to each supported disk array.

Veritas will automatically identify the available paths to a single physical storage with the help of world wide unique identifier and perform IO operation to the physical device without any interruption with the help of available paths.

DMP supports following types of array types

1. Active/Active:  Allows server paths to be used concurrently for IO  operations. In this type of array DMP provides greater through put by balancing IO uniformally.  Across multiple paths. In this case if one path fails, IO operations are automatically moved to the next available paths.
2. Active/Passive: This type allows access to disk or LUN’s via primary path which is active, if primary path fails it goes secondary path.

To administer dynamic multipathing we use the following commands:

# vxdmpadm: Lists the available paths.

Displays information about HBA controllers on the host. Displays info about enclosure’s. Gaters IO statistics for DMP mode.

Set the IO policy.

Set the partition size or rename the enclosure.

# vxdisk path (To the the list of controllers & enclosures)

# vxdmpadm list ctrl all | more (To set the sub paths in a enclosure)

# vxdmpadm getsubpaths ctrl=c1 (To get the info about enclosure)

# vxdmpadm listenclosure sena0

# fcinfo hba-port

# vxdmpadm getdumpnode enclosure=sena0

To gather the IO stats of DMP

# vsdmadm iostat start

# vsdmpadm iostat show all

# vxdmpadm iostat reset

# vxdmadm iostat stop

To display the IO policy

# vxdmpadm getattr enclosure SENA0 iopolicy

# vxdmadm setattr enclosure SENA0 iopolicy=round-robin

To display the partition size

# vxdmpadm getattr enclosure SENA0 partionsize

To rename enclosure

# vxdmpadm setattr enclosure SENA0 name=SENA0

# vxdiskadm 

Veritas Volume Manager - Daemon's

Daemon’s inside vxvm

1. VXconfigd: This is a main configuration daemon inside veritas which maintains systemconfiguration in kernel and disk. If this daemon is stopped it will not disable any configured state loaded into this kernel.

This daemon has 3 states –

1. Enable: Normal State
2. Disable: Most operations cannot be used.
3. Booted: Normal startup with the help of disk group.

2. Vxrelogd: Monitors for failure events and responsible for replacing a failed disk.
3. Vxcached: Maintains the buffer for output inside veritas.
4. Vxiod: Known and Input/Output daemon which manages IO operations inside a veritas volume.
5. Vxconfigbackupd: It is responsible for takin the backup of a disk group automatically.
6. Vxnotifyd: It forwards the messages to the user to a file or to a specific location based on configuration

To get the version of veritas installed

# modinfo | grep –I vxvm

# pkginfo –l VRTSvxvm

# cd /etc/vx/bin (All veritas commands are stored in here)

# cd /opt/vrts/bin (Administration commands are stored in here)

# cd /etc/vx/license/lic (Veritas licenses are stored)

#vxlicrep (To get license info)

 To update license keys.

#  cd /etc/vx/lisence/lic

# rm –r *

# vx licinst

●        Enter license key.

# vxdctl mode (To know the state of vxconfigd)

# vxdctl disable (Stops daemon)

# vxdctl enable ( Enables daemon)

# vxdctl mode

The volboot file also contains a list of disks to scan in search of the rootdg disk group. At least one disk in this list must be both readable and a part of the rootdgdisk group, or the Volume Manager will not be able to start up correctly.

तेच वेदा

इस ब्लॉग अभी तयार हो रहा है
ఎ బ్లాగ్ తయారు అవుతుంది.