Admin Aquatic

Solaris Kernel Tuning for Security

admin — Tue, 23 Mar 2010 15:16:41 +0000

Introduction
The Solaris kernel provides a great deal of user-configurable control over the system TCP/IP stack. Everything from cache table lifetimes to the number of TCP connections that the system can address are controllable. However, without understanding the underlying need for tuning these kernel parameters many system administrators choose to ignore them – thereby leaving their systems vulnerable to a resourceful assailant.
Solaris Kernel Tools
The only tool available to Solaris system administrators for tuning kernel parameters is ndd. Currently, ndd only supports the TCP/IP kernel drivers. It can be used to both show and set the values of parameters for these drivers.
Solaris Kernel Parameters
In general to show a particular parameter the command format is:
# ndd /dev/ where is one of the following: ARP, IP, TCP, and UDP. To view all parameters for a particular driver the command is:
# ndd /dev/ \?
To set a kernel parameter using ndd, the format of the command is:
# ndd -set /dev/
Unfortunately, changes to the Solaris kernel parameter values using ndd are not permanent. The values for these parameters return to default upon system reboot. To make these changes more permanent a system administrator needs to put these changes into a shell script that is run at system boot (one possible location would be /etc/init.d/inetinit or in a separate shell script). One of the primary problems with setting these parameters into a shell script is that the parameters are implementation-specific and may change from one Solaris release to another.
ARP
ARP (Address Resolution Protocol) is used to dynamically map layer-3 network addresses to data-link addresses. When one system wants to communicate with another system on a network it first sends an ARP packet to the broadcast address, FF:FF:FF:FF:FF:FF. The packet asks the simple question: “who has network address A?…tell network address B”. Since all hosts on a network receive these broadcast packets, system A receives the ARP request and sends back a response. The originating host then uses the responses to its ARP broadcasts to build a table, or cache, mapping the 32-bit IP addresses to Layer-2 hardware, or MAC, addresses. A second table is maintained by the network layer. This table is built from information provided by the data-link layer and contains network-routing information for active connections. The network layer requests MAC addresses from the data-link layer and inserts these addresses into a network routing table. Network routing entries expire after 20 minutes.
When a network host prepares to communicate with another the IP layer checks the ARP cache first. If an entry for the network peer does not exist in the cache, an ARP request is broadcasted. ARP cache entries expire after five minutes.
The ARP cache is susceptible to two types of attacks: ARP cache poisoning and ARP spoofing. ARP cache poisoning involves “inserting” either a non-existent ARP address or an incorrect ARP address into a system’s ARP cache. This results in a denial of service since the target system will send packets to the peer’s IP address but the MAC address will be incorrect.
ARP spoofing can result in system compromise. Just like IP spoofing, ARP spoofing relies on, first, disabling a host on the network so that it cannot reply to any ARP request broadcasts. Once that is done the attacker can configure the disabled host’s IP address on the attacking host. When the victim host tries to communicate with the disabled host the attacker’s system responds to any ARP request broadcasts, thereby inserting its MAC address in the victim’s ARP cache. Communication between the two hosts can then proceed normally.
It is very difficult to defend against ARP attacks. One defence against ARP attacks is to reduce the lifetime of cache entries. The cache lifetime is determined by the kernel parameter arp_cleanup_interval. The IP routing table entry lifetime is controlled by the kernel parameter ip_ire_flush_interval
# ndd -set /dev/arp arp_cleanup_interval # ndd -set /dev/ip ip_ire_flush_interval
where is in milliseconds. Reducing the ARP cache timeout interval and the IP-routing table timeout interval will slow down an attacker but not stop them.
Another option could be to create static ARP addresses for some systems. Static ARP cache entries are permanent and therefore do not expire. These entries can be deleted using the command arp -d. A third option would be to disable ARP processing on the system interface(s) altogether and add static ARP entries.
IP Parameters
The Solaris kernel also provides for control of various characteristics of the IP network protocol. This functionality is provided through several parameters:
ip_forwarding ip_strict_dst_multihoming ip_forward_directed_broadcasts ip_forward_src_routed
IP forwarding involves routing IP packets between two interfaces on the same system. Typically this is a job that a router performs, however, a Solaris system can perform this task as well. By default a system installed with Solaris will perform IP forwarding. This can be disabled by setting the kernel parameter ip_forwarding to 0:
# ndd -set /dev/ip ip_forwarding 0
Another avenue of attack would be for an intruder to create packets that are destined onnly for networks that are connected to a multihomed server that does not forward IP packets. By setting the parameter ip_strict_dst_multihoming to 0 the system drops any packets that appear to originate from a network attached to another interface:
# ndd -set /dev/ip ip_strict_dst_multihoming 0
Directed broadcasts are packets that are sent from one system on a foreign network to all systems on another network. Directed broadcasts are the basis for the “smurf” attack where forged ICMP packets are sent from a host to the broadcast address of a remote network. The source address in the ICMP packets is forged to contain the address of the victim host. The systems on the remote network receive the ICMP packet and then reply back to the victim host thereby flooding the host with traffic. Any Solaris system that has IP forwarding enabled will forward directed broadcasts as well. To disable the forwarding of directed broadcasts set ip_forward_directed_broadcasts to 0:
# ndd -set /dev/ip ip_forward_directed_broadcasts 0
When packets travel between one host and another on a network their path is determined by either dedicated routers or hosts providing routing services. However, IP has the ability to specify the route between the source and destination. This ability comes in one of two forms: strict and loose. With a strict source route, the sender specifies the address of every intermediate hop between it and the destination. With loose source routing the sender only specifies some of the intermediate hops leaving routers free to choose any path between the two systems. Source routing may be used to bypass security measures in the network topology. There is no reason to see source-routed packets in a network. Any host that does allow IP-forwarding should silently drop source-routed packets by setting the Solaris kernel parameter ip_forward_src_routed to 0:
# ndd -set /dev/ip ip_forward_src_routed 0
TCP Parameters
In September 1996, Phrack Magazine published an article titled “Project Neptune”. This article described a type denial of service attack known as a SYN flood. The goal of this attack is not necessarily to break into a system but to render the system unusable from the perspective of the internet or intranet. The attack exploits the basic way a TCP connection works. When a system attempts to connect to a server using TCP the sender a TCP/IP packet to the destination with the SYN bit set. This SYN packet is then acknowledged by the destination with a packet with both the SYN and ACK bits set in the TCP header. The sender then replies to SYN-ACK packet from the destination by sending its an ACK packet back. This “3-way” handshake looks something like:
Sender(client) Destination(server) SYN ——————————-> (Sequence #: X) <------------------------------ SYN-ACK (Sequence #: X+1, Sequence #: Y) ACK -------------------------------> (Sequence #: Y+1)
The abuse can occur when the destination host has responded to the sender with a SYN-ACK but does not receive an ACK back from the sending host. This then leaves the destination host connection in a “half-open” state. The source host then opens a new TCP connection with the destination host and repeats the process. This process continues until all possible TCP socket connections that the destination host can handle are in the “half-open” state. Once this happens, no further TCP SYN packets can be processed by the target until the “half-open” connections are removed from the TCP connection queue.
One way to determine if a Solaris system is under a TCP SYN attack would be to monitor the number of TCP connections in a SYN_RCVD state:
# netstat -an -f inet | grep SYN_RCVD | wc -l
This value can be compared to a baseline value taken when the machine is running under normal circumstances. Solaris provides another way to determine if a machine is under a TCP SYN attack. By running the command:
# netstat -s -P tcp
and inspecting the values of the parameters tcpTimRetransDrop and tcpListenDrop a TCP SYN attack can be identified. The parameter tcpTimRetransDrop shows the number of aborts since boot time due to abort time expirations. This value includes both the SYN requests as well as established TCP connections.
The parameter tcpListenDrop shows the number of SYN requests that have been refused since the system was booted because of a TCP queue backlog. There is a high probability that the system is under a TCP SYN attack if the tcpListenDrop value increases quickly along with the value of tcpTimRetransDrop.
To offset such an attack the administrator must do two things:

a) shorten the value of the abort timer, and
b) lengthen the TCP connection queue.

To shorten the abort timer the kernel parameter: tcp_ip_abort_cinterval can be used. The value for this parameter is given in milliseconds. By default the abort timer interval is 180 seconds. To set the abort time to 60 seconds the system administrator can use the command:
# ndd -set /dev/tcp tcp_ip_abort_cinterval 60000
The kernel parameter tcp_conn_req_max_q0 controls the queue size for unestablished TCP connections in Solaris 2.6 and above (or in Solaris 2.5.1 w ith patch 103581-11). The default value for tcp_conn_req_max_q0 is 1024. To increase the queue size the following command can be used:
# ndd -set /dev/tcp tcp_conn_req_max_q0 2048
Another type of SYN attack involves exhausting the TCP established connection queue. This attack is not as desirable as the TCP SYN attack mentioned above because of the fact that the connection can be traced back to its source, however, it still presents a problem. Solaris 2.6 and above (as well as Solaris 2.5.1 with patch 103582-11) provide control over the size of the established TCP connection queue. This control is provided by the kernel parameter tcp_conn_req_max_q. By default it is set at 128. To increase the established TCP connection queue, the command is:
# ndd -set /dev/tcp tcp_conn_req_max_q
where is the total number of active, established, TCP connections allowed to the host. Increasing either the TCP queue for unestablished connections or the TCP queue for established connections will require more memory. Without sufficient memory the server’s performance will be affected. Also, while this provides some measure of relief against TCP SYN attacks and TCP established connection exhaustion attacks these types of attacks depend on which side has more resources. If the attacker can produce more TCP connections (whether “half-open” or established) than the server can possibly handle this denial of service will succeed.
Conclusion
The Solaris kernel has many configurable parameters that are security related. These parameters can be adjusted to strengthen the security posture of a system. The parameters cover such things as ARP timeouts, IP forwarding of packets, IP source routing of packets, TCP connection queue sizes, and many other factors governing network connections. By tuning the kernel properly a system administrator can even prevent OS fingerprinting of a Solaris system as provided by such tools as queso and nmap.

Using vxmend to change plex status. from recover to Active

admin — Fri, 19 Mar 2010 16:58:23 +0000

Status=recover…… How to get it to active again ??

#vxmend –o force off plexname
Status=offline

#vxmend on plexname
Status=disabled / stale

#vxmend –g oracledg fix clean plexname
Status=disabled / clean

#vxvol start volname
Status=enabled / active

#fsck mountpoint
Verify status each time with #vxprint –rth

Adding Net-appliances disk to veritas

admin — Fri, 19 Mar 2010 16:55:56 +0000

1. Configure LUNS ont the Netapplicances device

2. Make sure solaris can see the disk
# format
3. Make sure veritas can see the disks
# vxdctl enable

4. When these type of disk is new for veritas

# vxddladm addjbod vid=NETAPP
# vxddladm listjbod
# vxdiskadm
18 allow multipathing
yes to continue
5 allow multipathing on all disks
all
yes
q
q need to do this …now he execute the correct commands.

# vxdisk list

Load balancing to active/active disk arrays.

admin — Fri, 19 Mar 2010 16:54:45 +0000

Solaris sees two paths to the same disk ( c2t8d0 and c3t8d0 )

To see both disk paths in solaris

# ls -las /dev/dsk/*t8do

Veritas creates only one metanode per LUN, this means that a disk with multipathing is seen as a single disk by the vxvm software.
To see the disk unique identifier (=serial number)

# /etc/vx/diag.d/vxdmpinq /dev/rdsk/c1t0d0s2

List the disks seen by veritas

# vxdisk list

To enable or disable paths use

# vxdiskadm

option 17. prevent multipathing

option 18. Allow multipathing

To list all controllers

# vxdmpadm listctlr all

To list the paths that are excluded

# vxdmpadm listexclude

To list subpaths to a specific controller to find out which devices are not functioning

# vxdmpadm getsubpaths ctrl=c1

To list all the paths for a disk

# vxdmpadm getsubpaths dmpnodename=c1t1d0s2

you will see that this disk is connected via c1 and c2

To see the disks names, how many paths there are, how many are disabled

# vxdmpadm getdmpnode enclosure=SENA0

To disable a paths

# vxdmpadm disable ctrl=c1

To verify status of all controllers

# vxdmpadm listctrl all

To enable a path again

# vxdmpadm enable ctrl=c1

To verify status do again

#vxdmpadm listctrl allow

! It will take 5 minutes before you see it is enabled again !

To speed this up do

# vxdctl enable

Adding disks to existing diskgroup and creating new volume

admin — Fri, 19 Mar 2010 16:53:15 +0000

1. Make sure solaris can see the disk.

# format
make sure the new disks are labeled by solaris ( use type “0″ = autodetect size , and label the disk !)

2. Make sure Veritas can see the new attached disk.

# vxdctl enable
(allow VxVM to discover newly added disks — DISKS NEED TO BE FORMATTED FIRST using the “format” COMMAND !!)

# vxdisk list
(will list disks detected, disks marked as “error” have not been initialized for use by VxVM)

3. Intitialise the disk in a specific diskgroup.

# vxdiskadm
1. option one to initialiase the disks in the oracledg diskgroup
make sure to use the list option so you can see that the disk is in error ( not yet initialised by veritas)

Or use the following commands:

( # /usr/lib/vxvm/bin/vxdisksetup -i c2t32d8 )
(# vxdg -g oracledg adddisk oracled01=c2t32d8 oracled02=c2t32d9)

4. Find out how much space is available on these new disks.

# vxassist -g oracledg maxsize oracled01 oracled02
`
(gets maximum size available for creating volume on specific disks )
( suppose resulting number is 28000000 )

# vxassist -g oracledg make newvol 28000000 stripeunit=48k columns=2 oracled01 oracled02
(creates volume u01vol of 28GB size using only oracled01 and oracled02 disks in a stripe layout)

# mkfs -F vxfs -o largefiles,bsize=8192 /dev/vx/rdsk/oracledg/u01vol
(create filesystem with largefile option necessary to create datafiles bigger than 2g)

# vi /etc/vfstab
(add filesystem so it is auto-mounted)

# mount /newvol

# df -k
verify new filesystem size.

Expand a volume in VxVM from command line

admin — Fri, 19 Mar 2010 16:51:59 +0000

1. Make sure solaris can see the disk.

# df -k
verify the current size of the filesystem /u11 you want to grow
# format
make sure the new disks are labeled by solaris ( use type “0″ = autodetect size , and label the disk !)

2. Make sure Veritas can see the new attached disk.

# vxdctl enable
(allow VxVM to discover newly added disks — DISKS NEED TO BE FORMATTED FIRST using the “format” COMMAND !!)

# vxdisk list
(will list disks detected, disks marked as “error” have not been initialized for use by VxVM)

3. Intitialise the disk in a specific diskgroup.

# vxdiskadm
1. option one to initialiase the disk in the oracledg diskgroup
make sure to use the list option so you can see that the disk is in error ( not yet initialised by veritas)

Or use the following commands:

( # /usr/lib/vxvm/bin/vxdisksetup -i c2t32d8 )
(# vxdg -g oracledg adddisk oracled01=c2t32d8 oracled02=c2t32d9)

4. Find out how much space is available on these new disks.

# vxassist -g oracledg maxgrow vol_u11 oracled01 oracled02
` Volume vol_u12 can be extended by 57675776 to 314105856 (153372Mb)
(gets maximum size available for resizing volume on specific disks)

# vxassist -g oracledg growby vol_u11 57675776 oracled01 oracled02
(extends the volume as a stripe on these 2 extra disks)

NOTE sometimes you get error
vxvm:vxassist: WARNING: dm:oracle16: No disk space matches specification
vxvm:vxassist: WARNING: dm:oracle17: No disk space matches specification

(I believe this to be some sort of rounding error, because afterward the volume is extended !)

# vxresize -g diskgroup volumename +2g

This will make the filesystem 2 g bigger

# vxprint -vt
Disk group: oracledg

V NAME RVG KSTATE STATE LENGTH READPOL PREFPLEX UTYPE

v backupvol – ENABLED ACTIVE 135254016 SELECT – fsgen
v ftpvol – ENABLED ACTIVE 6291456 SELECT – fsgen
v swapvol – ENABLED ACTIVE 28444672 SELECT – fsgen
v vol_u01 – ENABLED ACTIVE 55078912 SELECT – fsgen
v vol_u11 – ENABLED ACTIVE 314109952 SELECT vol_u11-01 fsgen
v vol_u12 – ENABLED ACTIVE 314105856 SELECT vol_u12-01 fsgen
v vol_u13 – ENABLED ACTIVE 58720256 SELECT – fsgen

# /opt/VRTSvxfs/sbin/fsadm -b 314109952 /u11
File system will be increased.

# df -k
verify new filesystem size.

Server Configuration for Solaris JumpStart Software

admin — Fri, 19 Mar 2010 16:50:04 +0000

The Solaris 9 Operating System offers an automatic installation process, Solaris JumpStart software. The Solaris JumpStart procedure enables you to install the Solaris OS automatically and configure it differently, depending on the characteristics of client systems. These identifying characteristics are used to select the correct configuration for each client system.
The following tasks are required to configure a single JumpStart server to provide basic software installation services using the JumpStart procedures:
1. Spool the operating system image.
2. Edit the sysidcfg file.
3. Edit the profile and rules.
4. Run the check script.
5. Run the add_install_client script.
6. Boot the client.

Step #1
To spool the Solaris 9 boot and installation images to a local disk, complete the following steps:
Create a directory with at least 800 Mbytes of space available to hold the Solaris OS image. Usually the /export/install directory is used.
# mkdir /export/install
Insert the Solaris 9 Software 1 of 2 CD-ROM in the CD-ROM drive or the Solaris 9 DVD in the DVD drive.
Change the directory to the location of the setup_install_server script.
# cd /cdrom/cdrom0/s0/Solaris_9/Tools
Run the setup_install_server script to copy the Solaris 9 OS installation images to the local disk.
#./setup_install_server /export/install
When the setup_install_server script finishes, change the directory to root (/), and eject the CD-ROM or DVD.
#cd /
#eject cdrom
If you use CD-ROM media, insert the Solaris 9 Software 2 of 2 CD-ROM in the CD-ROM drive.
Change the directory to the location of the add_to_install_server script.
# cd /cdrom/cdrom0/Solaris_9/Tools
Run the add_to_install_server script to copy the remainder of the installation image to the local disk.
#./add_to_install_server /export/install
When add_to_install_server finishes, change the directory to root (/), and eject the CD-ROM.
# cd /
# eject cdrom

Step #2
The sysidcfg file keeps the various types of system information such as locale, time_zone, and so on, and supplies the information to the client at the booting time.
Create a directory to hold the sysidcfg file. Typically the /export/config directory holds the sysidcfg file.
# mkdir /export/config
Change the directory to /export/config, and create a file called sysidcfg using a text editor.
# cd /export/config
# vi sysidcfg
In the sysidcfg file, add the following lines. Substitute values that are appropriate for your systems, location, and network.
network-interface=primary {protocol-ipv6=no
netmask=255.255.255.0}

security_policy=none
name_service=none
time_zone=US/Mountain
system_locale=en_us
Save the sysidcfg file, and exit your edit session.

Step #3
a. Rules
Create a directory to hold the rules file if this directory does not already exist. Usually, the /export/config directory holds the rules file.
# mkdir /export/config
Change the directory to /export/config, and create a file called rules using a text editor.
# cd /export/config
# vi rules
In the rules file, add the following line:
hostname client_name – profile1 -
For client_name, substitute the name of your JumpStart client. For example:
hostname sun1 - profile -
Save the rules file, and exit your edit session.
b. Profiles
Usually, the /export/config directory holds the profile file.
Change the directory to /export/config, and create a file called profile using a text editor.
# cd /export/config

# vi profile1
Add the following lines to the profile1 file:
install_type initial_install
system_type standalone
partitioning explicit
filesys c0t0d0s0 free /
filesys c0t0d0s1 128 swap
cluster SUNWCXall
Save the profile1 file, and exit your edit session.

Step #4
Before a JumpStart client can use a configuration provided by a JumpStart server, you must run the check script to produce a file called rules.ok. The check script validates the syntax of the rules file and the profile files. If the validation completes successfully, the check script creates the rules.ok file.
Change the directory to the location of the check script.
# cd /export/install/Solaris_9/Misc/JumpStart_sample
Copy the check script to the /export/config directory.
# cp check /export/config
Change the directory to /export/config, and run the check script.
# cd /export/config
#./check
Validating rules…
Validating profile profile1…
The custom JumpStart configuration is ok.

Step #5
a. Add a host entry.
Edit the /etc/ethers file, and add an entry for the JumpStart client.
#vi /etc/ethers

00-C0-26-84-34-A1 sun1
Save and exit from the ethers file.
Edit the /etc/inet/hosts file, and add an entry for the JumpStart client.
#vi /etc/inet/hosts

192.168.1.1 sun1
Save and exit from the hosts file.
b. Add a client.
Change the directory to the location of the add_install_client script on the server.
# cd /export/install/Solaris_9/Tools
Run the add_install_client script, and specify server and client information as follows. (Note: The following line of code should all be entered on one line.)
#./add_install_client -c server_name:/export/config \
-p server_name:/export/config client_name platform_group
For example:
#./add-install-client -c sun:/export/config -p sun:/export/config sun1 sun4u
Edit the /etc/dfs/dfstab file to add the following line:
#vi /etc/dfs/dfstab

share -F nfs -o ro, anon=0 /export/install

share -F nfs -o ro, anon=0 /export/config
Save and exit from the dfstab file.
Run the shareall command to share the /export/config and /export/install directories.
#shareall
Verify that the /export/config and /export/install directories are currently shared.
#share

Step #6
Booting the JumpStart Client
After the JumpStart server has been configured to provide all of the required services, you can initiate the installation process on the JumpStart client. To boot the JumpStart client, perform the following steps:
a. Bring the JumpStart client to run state 0.
# init 0
b. Boot the client to initiate the software installation using the JumpStart procedure.
ok boot net – install

Solaris SPARC Boot Sequence

admin — Fri, 19 Mar 2010 16:48:51 +0000

The following represents a summary of the boot process for a Solaris 2.x system on Sparc hardware.
Power On: Depending on the system involved, you may see some output on a serial terminal immediately after power on. This may take the form of a Hardware Power ON message on a large Enterprise server, or a “‘” or “,” in the case of an older Ultra system. These indications will not be present on a monitor connected directly to the server.
POST: If the PROM diag-switch? parameter is set to true, output from the POST (Power On Self Test) will be viewable on a serial terminal. The PROM diag-level parameter determines the extent of the POST tests. (See the Hardware Diagnostics page for more information on these settings.) If a serial terminal is not connected, a prtdiag -v will show the results of the POST once the system has booted. If a keyboard is connected, it will beep and the keyboard lights will flash during POST. If the POST fails, an error indication may be displayed following the failure.
Init System: The “Init System” process can be broken down into several discrete parts:
• OBP: If diag-switch? is set, an Entering OBP message will be seen on a serial terminal. The MMU (memory management unit) is enabled.
• NVRAM: If use-nvramrc? is set to true, read the NVRAMRC. This may contain information about boot devices, especially where the boot disk has been encapsulated with VxVM or DiskSuite.
• Probe All: This includes checking for SCSI or other disk drives and devices.
• Install Console: At this point, a directly connected monitor and keyboard will become active, or the serial port will become the system console access. If a keyboard is connected to the system, the lights will flash again during this step.
• Banner: The PROM banner will be displayed. This banner includes a logo, system type, PROM revision level, the ethernet address, and the hostid.
• Create Device Tree: The hardware device tree will be built. This device tree can be explored using PROM monitor commands at the ok> prompt, or by using prtconf once the system has been booted.
Extended Diagnostics: If diag-switch? and diag-level are set, additional diagnostics will appear on the system console.
auto-boot?: If the auto-boot? PROM parameter is set, the boot process will begin. Otherwise, the system will drop to the ok> PROM monitor prompt, or (if sunmon-compat? and security-mode are set) the > security prompt.
The boot process will use the boot-device and boot-file PROM parameters unless diag-switch? is set. In this case, the boot process will use the diag-device and diag-file.
bootblk: The OBP (Open Boot PROM) program loads the bootblk primary boot program from the boot-device (or diag-device, if diag-switch? is set). If the bootblk is not present or needs to be regenerated, it can be installed by running the installboot command after booting from a CDROM or the network. A copy of the bootblk is available at /usr/platform/`arch -k`/lib/fs/ufs/bootblk
ufsboot: The secondary boot program, /platform/`arch -k`/ufsboot is run. This program loads the kernel core image files. If this file is corrupted or missing, a bootblk: can’t find the boot program or similar error message will be returned.
kernel: The kernel is loaded and run. For 32-bit Solaris systems, the relevant files are:
• /platform/`arch -k`/kernel/unix
• /kernel/genunix
For 64-bit Solaris systems, the files are:
• /platform/`arch -k`/kernel/sparcV9/unix
• /kernel/genunix
As part of the kernel loading process, the kernel banner is displayed to the screen. This includes the kernel version number (including patch level, if appropriate) and the copyright notice.
The kernel initializes itself and begins loading modules, reading the files with the ufsboot program until it has loaded enough modules to mount the root filesystem itself. At that point, ufsboot is unmapped and the kernel uses its own drivers. If the system complains about not being able to write to the root filesystem, it is stuck in this part of the boot process.
The boot -a command singlesteps through this portion of the boot process. This can be a useful diagnostic procedure if the kernel is not loading properly.
/etc/system: The /etc/system file is read by the kernel, and the system parameters are set.
The following types of customization are available in the /etc/system file:
• moddir: Changes path of kernel modules.
• forceload: Forces loading of a kernel module.
• exclude: Excludes a particular kernel module.
• rootfs: Specify the system type for the root file system. (ufs is the default.)
• rootdev: Specify the physical device path for root.
• set: Set the value of a tuneable system parameter.
If the /etc/system file is edited, it is strongly recommended that a copy of the working file be made to a well-known location. In the event that the new /etc/system file renders the system unbootable, it might be possible to bring the system up with a boot -a command that specifies the old file. If this has not been done, the system may need to be booted from CD or network so that the file can be mounted and edited.
kernel initialized: The kernel creates PID 0 ( sched). The sched process is sometimes called the “swapper.”
init: The kernel starts PID 1 (init).
init: The init process reads the /etc/inittab and /etc/default/init and follows the instructions in those files.
Some of the entries in the /etc/inittab are:
• fs: sysinit (usually /etc/rcS)
• is: default init level (usually 3, sometimes 2)
• s#: script associated with a run level (usually /sbin/rc#)
rc scripts: The rc scripts execute the files in the /etc/rc#.d directories. They are run by the /sbin/rc# scripts, each of which corresponds to a run level.

Moving populated disks out of rootdg or moving rootdg to another system

admin — Fri, 19 Mar 2010 16:39:19 +0000

First, moving populated disks between diskgroups.
Get a list of disks in the diskgroup that you intend to move the populated disks out of.
# vxdisk list | grep rootdg

Get the configuration of the diskgroup.
# vxprint -ht -g rootdg

Determine which disks contain the volumes that are to be moved.

Save the configuration of the desired volumes in a format that can be used later by vxmake to recreate the volumes. Specify all volumes on the disks in question, plus any unassociated plexes and their child subdisks, plus any unassociated subdisks.
# vxprint -hmQq -g rootdg vol01 vol02 vol03 > /tmp/volinfo

Unmount the appropriate filesystems, and/or stop any processes holding the volumes open.

Stop all the volumes.
# vxvol -g rootdg stop vol01 vol02 vol03

Remove from the configuration database the definitions of the structures ( (volumes, plexes, subdisks) to be moved. NOTE that this does not affect your data.
# vxedit -g rootdg -r rm vol01 vol02 vol03

Remove the disks from the original diskgroup.
# vxdg -g roodg rmdisk rootdg01 rootdg02 rootdg03 rootdg04

If you are moving the disks to a preexisting diskgroup, SKIP THIS STEP. If not, initialize the diskgroup using one of your disks. It is simplest to keep the old disk names until a later step.
# vxdg init newdg rootdg01=c1t2d0s2

Add the disks to their new disk group. It is simplest to keep the old disk names until a later step.
# vxdg -g newdg adddisk rootdg02 rootdg03 rootdg04

Verify that the disks are in their new diskgroup.
# vxdisk list | grep newdg

Reload the object configuration into the new diskgroup.
# vxmake -g newdg -d /tmp/volinfo

Verify the configuration of the new diskgroup.
# vxprint -ht -g newdg

Test your data.

Second, moving rootdg between systems.

Get the diskgroup ID (dgid) of rootdg from the old host.
# vxdisk -s list
(example)

Disk: c1t5d0s2type: slicedflags: online ready private autoconfig autoimport importeddiskid: 824180434.4523.csclust2dgname: rootdgdgid: 824180442.4528.csclust2hostid: csclust1 Disk: c1t9d0s2type: slicedflags: online ready private autoconfig autoimport importeddiskid: 824180440.4525.csclust2dgname: rootdgdgid: 824180442.4528.csclust2hostid: csclust1 Disk: c1t13d0s2type: slicedflags: online ready private autoconfig autoimport importeddiskid: 830532975.3418.csclust1dgname: rootdgdgid: 824180442.4528.csclust2hostid: csclust1

Shutdown the old host, remove the disks, and connect the disks to the new host.

Import the diskgroup with its new name, assigning ownership of the diskgroup to the new host, using the dgid for the diskgroup name.
# vxdg -C -n newdg import 824180442.4528.csclust2

Perform the necessary steps to make the new host and VxVM recognize the new disks. I.e. perform the steps necessary to make the OS see the disks, and then perform a ‘vxdctl enable’ to restart vxconfigd so that VxVM also recognizes the disks.

Start all volumes in the diskgroup.
# vxrecover -g newdg -sb

Configuring rootdg on a slice

admin — Mon, 25 Jan 2010 17:37:30 +0000

Use this procedure if you want to create a rootdg diskgroup on a single slice.

Remember that rootdg is needed for Volume Manager to start the daemons.

After this procedure vxinstall is no longer needed. Use vxdiskadm to create other diskgroups.

1. Install the software packages for Veritas Volume Manager.

2. Configure the slice as a virtual disk in the diskgroup rootdg
# vxconfigd -m disable (to kill the vxconfigd)
# vxdctl init (to initialise VxVm database)
# vxdg init rootdg (to create rootdg)
# vxdctl add disk c0t0d0s7 type=simple (IGNORE THE WARNING : Not in configuration database)
# vxdisk -f init c0t0d0s7 type=simple (to add a disk record)
# vxdg adddisk c0t0d0s7 (make a slice into a virtual disk)
# vxdctl enable (reread config in memory)
# rm /etc/vx/reconfig.d/state.d/install-db (remove placeholder file for vxinstall)

3. Reboot or restart daemons manually.

# init 6

4.Create other diskgroups with vxdiskadm

# vxdiskadm