Showing posts with label solaris. Show all posts
Showing posts with label solaris. Show all posts

INFO: What is a "Sticky Bit"?

At a recent job interview, I was asked this question. I was able to satisfactorily answer the question but failed to answer the follow-up question -- what is the difference between the sticky bit "t" (small letter) and the sticky bit "T" (bold letter)? This experience led me to improve my knowledge further. This post is dedicated to the experience I had, and to share the knowledge to those who quest for it.

What is the "Sticky Bit"? ("t" and "T"). The sticky bit is primarily used on shared directories with open permissions, such as /var/tmp and /tmp. Directories with open permissions (or publicly writable) present a lot of problems because users **CAN CREATE** files, **READ/EXECUTE** files owned by other users, and at the same time are **ALLOWED EDIT/REMOVE** privileges to files owned by other users.

With sticky bit set on publicly writable directories, users **CAN CREATE** files, **READ/EXECUTE** those files as well as files owned by other users, but are **NOT ALLOWED EDIT/REMOVE** privileges to files they don't own. The only exception to this is the super-user root which can edit or remove files.

In simple terms, sticky bit is used to indicate special treatment of certain directories. A directory for which the sticky bit is set restricts deletion or modification of files it contains. A file in a sticky bit set directory may only be removed, modified or renamed by a user who has write permission on the directory, and either owns the file, owns the directory, or is the super-user. This is useful for directories such as /tmp, which must be publicly writable, but should deny users permission to arbitrarily delete or rename the files of others.

It is worthy to note here that the directories with open permissions (or publicly writable) can be any arbitrary directory, not just limited to /tmp and /var/tmp. Its just that /tmp and /var/tmp exist by default on the system.

Which directory has sticky permissions? How do you identify a directory that has sticky bit set? To illustrate further see the example below.

user@host# ls -ld /sticky/directory
drwxrwxrwt  2   user   group   512   Jun 20 11:02  /sticky/directory

On the output of the "ls" command, see the "t" (on drwxrwxrwt)? That tells us that the sticky bit is set.
A "T" refers to when the execute permissions are OFF.
A "t" refers to when the execute permissions are ON.

How to set sticky bit permissions. The leading "1" in the "chmod" command sets the sticky bit.
user@host# chmod 1777 /sticky/directory (permissions for "other" have execute bit ON) 
drwxrwxrwt
user@host# chmod 1776 /sticky/directory (permissions for "other" have execute bit OFF)
drwxrwxrwT

The equivalent of the above commands in another syntax.
user@host# chmod o+t /sticky/directory
user@host# chmod o+x /sticky/directory
drwxrwxrwt        
user@host# chmod o+t /sticky/directory
user@host# chmod o-x /sticky/directory
drwxrwxrwT
Or..
user@host# chmod o=rwxt /sticky/directory
drwxrwxrwt        
user@host# chmod o=rwt /sticky/directory
drwxrwxrwT

There you go, more information regarding sticky bit. To my knowledge, sticky bit for files are not supported by any modern implementation of Unix or Linux. It is only significant and applicable to directories.

Share:

HOW-TO: Tabbed Putty with PuttyCM (Windows 7)

If you work as a system administrator and your workstation has windows (particularly Windows 7), chances are you connect to the Linux, Solaris, AIX or whatever flavor of *nix using putty. If by any chance you don't you might want to try putty, instead of the current program you're using.

I have used putty since I started working as a Unix sysad. And I can tell that putty in itself is a superb and versatile tool. But work starts getting complicated once you have several putty sessions open. And it becomes even challenging once you open more putty sessions. PuttyCM (or Putty Connection Manager) organizes putty sessions into tabs or split windows (by dragging a tab). This way, working becomes organized and much faster. You may want to download PuttyCM to try it out.

However, PuttyCM doesn't work out-of-the-box in Windows 7. So here's a pimp-my-rig feature designed to guide you in configuring PuttyCM to make it work in Windows 7. To give you a better understanding of what I mean by it doesn't work, here is the screenshot of PuttyCM connecting to my Popcorn Hour C-200 NMJ.

Tabbed Putty with PuttyCM (Windows 7)

As you can see, it doesn't work well. You are able to use the connection manager or putty sessions but it doesn't display the connection properly. And you can't do your job with PuttyCM. So it is just back to plain Putty or so it seems.

Here's how to make PuttyCM work in Windows 7.

Explore to the directory containing the PuttyCM executable (its filename is: puttycm.exe). Right-click the executable file and go to Compatibility tab. Choose compatibility for Windows Vista. You may choose Vista SP1 or SP2 as these work as well. Toward the bottom of the Compatibility tab, tick "Run this program as an administrator". You will be seeing a window similar to the one below.

Tabbed Putty with PuttyCM (Windows 7)

Now try to launch PuttyCM and connect to a host.

How sweet it is to see the terminal connection display.

Tabbed Putty with PuttyCM (Windows 7)

So there you go folks, working tabbed putty with PuttyCM in Windows 7. As of this writing, PuttyCM version 0.7.1 build 136 (beta) works. And the current alpha 0.7.1 build 233 works in Windows 7 and Windows 7 SP1.

Share:

FAQ: Error with Update on Attach of Solaris Zone

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

Q. A fellow sysad phoned me a couple of days ago to ask if I experienced patching Solaris zones. When he was attaching the local zones to the global zone he got errors. As advised, he detached the local zones from the global zone before patching. This is what I used to call the detach-patch-attach method in patching Solaris hosts with zones. He was indeed very fortunate that I experienced this same error before and below is how we resolved his issue. Just to give a brief background, the error he got when attaching the local zones was:

root@global> zoneadm -z vhost1 attach -u
zoneadm: zone 'vhost1': ERROR: attempt to downgrade package SUNWlur, the source had patch 121430-25 but this system only has 121430-14
zoneadm: zone 'vhost1': ERROR: attempt to downgrade package SUNWluu, the source had patch 121430-25 but this system only has 121430-14
...
(other output truncated)
...

The above scenario happened after he detached the zones from the global zone (zoneadm -z vhost1 detach), then he applied the latest bundle patch for Solaris 10 (in single-user mode). After reboot, he allowed the server to boot to full multi-user mode.

And when he attached the zones with the update flag (zoneadm -z vhost1 attach -u), boom.. Errors!

A. This scenario happened because the package SUNWlur and SUNWluu (packages for Solaris LiveUpgrade) do not get patched by the Solaris patch bundle. Instead it has its own "special" set of patches. And unfortunately for him, the local zones have a more updated patch for LiveUpgrade than the global zone. Thus the attach with update failed.

I got the solution to the problem from a now non-existent forum -- this link. Too bad, that very informative thread has been removed. But I was glad to have gleaned something from it before it was expunged.

The solution is to append the patch IDs of every SUNWlur and SUNWluu package that would fail when trying to attach the local zones.
root@global> echo 121430 >> /usr/lib/brand/native/bad_patches
root@global> tail /usr/lib/brand/native/bad_patches
...
...
121430

After adding every patch ID entry for "special" patches required by LiveUpgrade, the local zones attach with update was successful.
root@global> zoneadm -z vhost1 attach -u
Getting the list of files to remove
Removing 1568 files
Remove 13 of 13 packages
Installing 18014 files
Add 340 of 340 packages
Updating editable files The file </var/sadm/system/logs/update_log> within the zone contains a log of the zone update.

As seen above, the local zone attached and was updated. It booted with the same kernel as the global zone and the had same patch levels. The other zones attached without errors after performing this procedure.

There are other packages that would fail when doing the upgrade on attach, not just packages for Solaris LiveUpgrade. The other ones that I know of are SUNWvts and SUNWvtss. There are others still. And this same solution is applicable to them.

I was surprised to see that the forum where this solution was shared no longer exists. It contained a wealth of information, and it will probably make the job of new sysads a bit toughter without those shared knowledge and other threads on that forum.

Share:

HOW-TO: Create an Aggregated Link in Solaris

Nowadays, servers ship with multiple network interface cards (NIC). The rationale behind this, is you will use them for high availability implementations or utilize the other NIC as a private lan for backup. If the box is not designed this way, it doesn't usually get deployed in the enterprise.

Previously, we featured a procedure in deploying IPMP or IP Multipathing. Starting with Solaris 10, there is this feature that is much more robust than IPMP. It is called link aggregation; others call it trunking, but they pertain to the same technology. The equivalent in Linux is NIC bonding.

Link aggregation only works on full-duplex, point-to-point links that operate at identical speeds. Make sure that the interfaces in your aggregation conform to this foremost requirement. If you are using a switch in your aggregation topology, make sure that you have configured the ports to be used as an aggregation. Modern switches can support Link Aggregation Control Protocol or LACP. If so, have it configured in either active mode or passive mode.
[1] Assume the Primary Administrator role, or become superuser.

[2] Determine which interfaces are currently installed on your system.
# dladm show-link 
bge0         link: up        speed: 1000  Mbps       duplex: full
bge1         link: up        speed: 1000  Mbps       duplex: full

The command dladm show-dev can also be used here. However, this command will not only show the NIC but also the HBAs (host bus adapters) that are installed on the host. Seasoned veterans know the prefixes of Solaris NIC naming convention so this should not pose an issue.

[3] Determine which interfaces have been plumbed.
# ifconfig -a

[4] Create an aggregation. Syntax is:
# dladm create-aggr -d interface key
interface
  represents the device name of the interface to become part of the aggregation.
key
  the number that identifies the aggregation. The lowest key number is 1. Zeroes are not allowed as keys.
# dladm create-aggr -d bge0 -d bge1 1

The above command is not limited to two (2) NICs. As many NICs can be used as there are physical NICs on the server. Just separate each NIC with -d to join them in the aggregate creation.

[5] Configure and plumb the newly created aggregation.
# ifconfig aggr[key] plumb IP-address up
# ifconfig aggr1 plumb 192.168.0.11 netmask + broadcast + up

[6] Check the status of the aggregation you just created.
# dladm show-aggr
key: 1 (0x0001) policy: L4      address: 0:3:ba:77:84:e (auto)
       device   address           speed         duplex  link    state
       bge0     0:3:ba:77:84:e    1000  Mbps    full    up      attached
       bge1     0:3:ba:77:84:e    1000  Mbps    full    up      attached
# ifconfig aggr1
aggr1: flags=2008843 mtu 1500 index 5
inet 192.168.0.11 netmask ffffff00 broadcast 192.168.0.255
ether 0:3:ba:77:84:e
The above configuration is not yet persistent across reboots. To make it persistent, create a file in this manner: /etc/hostname.aggr[key]. In this example, that translates to /etc/hostname.aggr1.

Add the IP address (192.168.0.11) to the file /etc/hostname.aggr1. Another option is to add the hostname of the server as the content of /etc/hostname.aggr1, but the IP address has to be added to the hosts file. The approach of adding the IP address is simpler and very straight forward.

Do a reboot to test if the aggregation persists across reboots.

Link Aggregation is very picky on both the hardware, driver, speed, duplex and on the switch port. So in most cases where aggregation doesn't work, IPMP is being deployed. To know more about the advantages and disadvantages of each, check out this comparison betweek Link Aggregation vs IPMP.

Share:

INFO: IPMP or IP Multipathing to Improve Resiliency

High availability (HA) is a system design approach and associated service implementation that ensures a prearranged level of operational performance will be met during a contractual measurement period. (source: wikipedia).

Tweaks about high availability are not taught in school. Either you learn it on the job or seek knowledge from sites on the net. Then, you will have to try it out and see for yourself how it gets implemented. High availability ensures minimal downtime or impact from outage. Others define it as elimination of single points of failure.

HA can be very costly but if implemented right, tweaking for HA may not be as expensive. This is where a simple tweak like IPMP (short for IP Multipathing) comes in. It is not as expensive. And just covers the single point of failure on the network part.

I found this tweak from Sun Blueprints a long while ago, but it seems that site is no longer in existence, I'm putting up a similar procedure.

Solaris supports IPMP right out of the box. And implementation is not as complex as one might think. Only basic knowledge of Solaris network configuration is required. In this example, implementation of IPMP is for a failover of a public IP with two private IPs.

Let's assume your server has two network interfaces (NICs). In Solaris, the network interface is recognized as ce0 and ce1 (for copper ethernet).

[1] Ensure that each network card has a unique MAC address flag set to true.
On the OBP: setenv local-mac-address?=true
On the CLI: eeprom "local-mac-address?=true"

[2] Reserve three IP addresses on the same subnet or VLAN. Add them to /etc/hosts.
root@host# cat /etc/hosts
#
# Internet host table
#
127.0.0.1       localhost       
192.168.0.10   host-name  loghost 
192.168.0.11   host-priv1 
192.168.0.12   host-priv2

[3] Configure the individual interfaces with the corresponding IP addresses assigned (assuming ce0 and ce1, could be any NIC of your choice).

root@host# cat /etc/hostname.ce0
host-priv1 netmask + broadcast + group production deprecated -failover up \
addif host-name netmask + broadcast + up
root@host# cat /etc/hostname.ce1
host-priv2 netmask + broadcast + group production deprecated -failover up

There are many variations to this configuration. But what this particular configuration does is sets up two private IP addresses that are fixed to each interface (host-priv1 and host-priv2); it sets the interfaces under a group named production; and, it adds an IP (host-name) that is assigned to ce0 but migrates between interfaces in cases of failure.

In the above configuration, receiving of packets is done by the active host-name but transmission is shared by each, thereby "doubling" the uplink bandwidth.

root@host# ifconfig -a
...
ce0: flags=1000843 mtu 1500 index 3
inet 192.168.0.11 netmask ffffff00 broadcast 192.168.0.255
ether 00:14:4f:2e:94:43
groupname production
ce0:1: flags=21000843 mtu 1500 index 4
inet 192.168.0.10 netmask ffffff00 broadcast 192.168.0.255
ce1: flags=29040843 mtu 1500 index 4
inet 192.168.0.12 netmask ffffff00 broadcast 192.168.0.255
groupname production
ether 00:14:4f:62:51:3b

Administration best practice is to try out the failover to test resiliency to failure. To simulate failure, use the command below. Execute tail -f /var/adm/messages to view the informative and error messages.

root@host# if_mpadm -d ce0
Oct 10 16:28:23 host in.mpathd[428]: Successfully failed over from NIC ce0 to NIC ce1
root@host# if_mpadm -r ce0
Oct 10 16:37:45 host in.mpathd[428]: Successfully failed back to NIC ce0

With the configuration tried and tested, the single point of failure on the network is eliminated. To further improve resiliency, it is recommended to plug each NIC connection to different switches.

NOTE: The secondary network card can also be setup in standby mode with only one data address between the cards. However, by assigning a data address for each card, the outbound load is spread by IPMP. But using only one shared IP address, if the card with a single data address fails during boot up, the address may not be failed over, leaving both interfaces inactive.

Share:

FAQ: Change NIC Speed in AIX

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

Experience in administering a Solaris Unix box made me think changing the speed of a network interface can be a simple execution of a series of commands -- but not in AIX. My experience was not so simple.

Recently while trying to change the speed of a NIC in an AIX box, I got into errors. Errors which I discovered to be a common discussion among system administrators in the web. The error is below:

Method error (/usr/lib/methods/chgent):
0514-062 Cannot perform the requested function because the
specified device is busy.


This was after the interface was "down"-ed and "detach"-ed, executing "chdev -l ent0 -a media_speed=1000_Full_Duplex". Being an AIX sysad amateur myself, I came to consult a colleague who has more in-depth knowledge and experience in AIX. I am grateful for his insight into the matter and here is the outline of what he did.

Here is a brief background of our objective -- change the NIC speed from Auto_Negotiation to 1000_Full_Duplex in an AIX box. And the workplan in place is:

[1] ifconfig en0 down detach

[2] chdev -l ent0 -a state=detach

[3] chdev -l ent0 -a media_speed=1000_Full_Duplex

[4] smit chinet >> (select interface) and change Current STATE to "up"
(NOTE: using "ifconfig en0 up" here sometimes assigns IP address of 0.0.0.0, so use smit instead)

[5] mkdev -l en0


I never got to execute beyond step [3] due to the error. So I sought for help.

What we did was to modify step [3] and inserted another step in the procedure : rmdev -l ent0. Which when executed outputs:
# rmdev -l ent0
ent0 Defined


After which, succeeding steps in the procedure above went smoothly.

To verify the change, execute entstat on the interface:
# entstat -d ent0 | grep Speed

Media Speed Selected: 1000 Mbps / 1 Gbps, Full Duplex
Media Speed Running: 1000 Mbps / 1 Gbps, Full Duplex


Another remarkable point to note here is that in step [4] of the original procedure, executing ifconfig to change the state of the device to "up" sometimes assigns it an IP address of 0.0.0.0.

As a Solaris sysad, this change in AIX was very much new to me. But hey, it is not bad to learn something new. And I hope that by sharing the inserted step in the above procedure, this little experience might be able to help other sysads stuck in the same error.


Share:

FAQ: C Compiler Cannot Create Executables

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

FAQ: A friend came to me to ask for help trying to troubleshoot a configure error that he had trying to build a package for Solaris. The error was:

configure: error: installation or configuration problem: C compiler cannot create executables.


Luckily for him, I have experienced this problem before and the solution is below..

Make sure you have the following packages installed on your system:

[1] for tools (sccs, lex, yacc, make, nm, truss, ld, as):
SUNWbtool, SUNWsprot, SUNWtoo, SUNWcpp

[2] for libraries & headers:
SUNWhea, SUNWarc, SUNWlibm, SUNWlibms
SUNWdfbh, SUNWcg6h, SUNWxwinc, SUNWolinc,
SUNWxglh, SUNWlibC, SUNWzlib, SUNWscpu

[3] for 64 bit development (in Solaris 10 these have all been merged into their non-"x" versions):
SUNWarcx, SUNWbtoox, SUNWdplx, SUNWscpux, SUNWsprox,
SUNWtoox, SUNWlmsx, SUNWlmx, SUNWlibCx, SUNWzlibx

[4] for ucb compat:
SUNWsra, SUNWsrh

To know if the package is installed, you may run this command:

root@host# pkginfo


Installing the above packages will alleviate the problem.

If you have encountered this problem before and have a different solution, pls let us know.

Share:

HOW-TO: Reset Root Password (addendum)

It can happen to me.. to you.. or to one of your clients, where a machine will have to be worked on but the root password is somehow lost or forgotten. Pretty basic you might think, but you might be faced with this hurdle sooner than you think.

The above statements might already sound familiar to you. It is mentioned in the post tackling how to reset a forgotten root password. Still in the x86 realm, let us discuss how to reset the root password using a rescue CD (or DVD, if one exists).

As always, the best advice to give is: Do not panic. If the host has an optical drive, a good option is to use a rescue CD to reset the root password.

Reboot the host and set the BIOS to boot from the CD-ROM drive, save the settings and exit the BIOS. Make sure that the rescue disc in the drive as well.

Once the host is up, mount the root partition of the host. And edit the shadow file and leave root with a blank password.
# mount /dev/sda1 /mnt
# vi /mnt/etc/shadow

.. before:
root:$2a$10$Gw/SYEjxGEXnZESeW07sb.XdWB9VxDAnXC3SRUtpSwitb6EzkDwS.:14145::::::

.. after:
root::14145::::::


On some systems this works. And when you login as root, you will not be prompted for a password at all. So the best thing to do is set a root password as soon as the system reboots.

Another recommendation after mounting the root partition is to chroot to the mount point.
# mount /dev/sda1 /mnt
# chroot /mnt /bin/bash
# passwd
Changing password for root
New password:
Reenter New Password:
#


However, this does not work at all times. One of the errors encountered is like the message below:
# passwd
Changing password for root
New password:
Reenter New Password:
Cannot open /dev/urandom for reading: No such file or directory
Cannot create salt for blowfish crypt
Error: Password NOT changed.
passwd: Authentication token manipulation error


The above happens because the special file /dev/urandom (which is created at boot-up) does not exist in the chrooted environment. You may create the file using other binaries large enough to generate entropy for the crypt algorithms. And even a plain text file will do.
(execute this in the chrooted environment still)
# cp /etc/default/passwd /dev/urandom
# passwd
Changing password for root
New password:
Reenter New Password:
Password changed.


There you go. Two more ways to reset a forgotten root password. But with a rescue CD this time. If your distribution does not have a rescue CD, the first CD (or CD#1, the bootable CD) can be used instead. Boot to single-user or select rescue mode if available.

Share:

HOW-TO: Reset a Forgotten Root Password

It can happen to me.. to you.. or to one of your clients, where a machine will have to be worked on but the root password is somehow lost or forgotten. Pretty basic you might think, but you might be faced with this hurdle sooner than you think.

With the number of hosts to administer, the burgeoning problem of recalling passwords escalate. Discipline would entail putting passwords in a vault. But then again, human error factors in and this quick step was skipped. There are a number of different reasons to point to, but when faced with this scenario, what can one do?

Traditional wisdom will beckon you to reboot and go to the single-user mode. Let us discuss first how this is done.

In LILO, pass the parameter "single":
LILO: linux single


In GRUB, at the boot screen select the kernel and press "e" (to edit the entry) and select the second line containing the word kernel. Press "e" again to edit the line and append "single" to that line:
grub edit> kernel /boot/vmlinuz-x.x.x-x root=/dev/sda1 ro single


On many flavors of linux, the system will happily present you with a root shell to do your thing and change the root password. However, not all will happily oblige and still ask for the root password:
Give the root password for maintenance
(or type Control-D for normal startup):


When this happens, it is again back to square one. However, all is not lost. You may try to use a live CD (the steps to which we will discuss in another post). Assuming the host does not have an optical drive, try the procedure below.

A word of WARNING before proceeding. If you want to experiment on this, try it out on a development box or a virtual machine first. As a rule of thumb, when working on a production machine, have another pair of eyes on board.

Try passing the parameter "init=/bin/bash" instead of "single". What then does this do? It instructs the linux kernel to execute the shell bash (/bin/bash) instead of executing init. It does not give you much to work on as there services/daemons executed during startup were not executed, but it does give you a shell where the password can be reset.
LILO: linux init=/bin/bash

.. likewise, in grub:
grub edit> kernel /boot/vmlinuz-x.x.x-x root=/dev/sda1 ro init=/bin/bash


So if you have noticed, you get a root shell right out of boot-up. Unfortunately that is not yet enough to change the root password, as the filesystem is mounted read-only. Remedy this situation first.
# mount -o remount,rw /


Executing the above command will remount the root partition (/) read-write. We can now proceed in changing the root password. Now is the time to for proper discipline to kick in and note the new password in the vault.

Once done with the above, DO NOT REBOOT just yet. There are no safeguards in place to properly take the system down and the root partition was mounted read-write. Return it to its original state when it booted up -- a read only root partition.
# mount -o remount,ro /


Now the system can be rebooted or the reset button pressed.

Share:

FAQ: More Secure Password-less SSH -- Windows to Linux

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

The password-less SSH procedure previously posted outlined the establishment of trusted logins from a Windows machine to a _nix machine. The set-up works and is very convinient to implement. However, it comes at the expense of security.

FAQ: Many would agree that an unprotected private key -- a private key with empty passphrase -- is less secure and thus exposes the account to a security threat. Not that this set-up is totally unsecure but once the private key is compromised, the account is completely vulnerable as access to it is open. Can we make the set-up a more secure then?

Protecting the private key with a passphrase is a very logical thing to do. Not only that, it is highly recommended especially on platforms or systems where security is a major concern. The private key then becomes useless without the passphrase to unlock it.

In order to accomplish this stunt, a similar set of software for the previous Windows to _nix password-less setup is required: putty.exe, puttygen.exe and pscp.exe, with the addition of pageant.exe. The tools mentioned can be downloaded off the author's website. Download the binaries enumerated.

Start off by launching puttygen.exe. This tool will generate the public and private key pairs needed for the password-less setup. This was done previously but this time, protect the private key with a passphrase. Press "Generate" and put a passphrase in the fields where it is required. Then, save the private and public keys.


Open putty.exe. Scroll down to Connection --> Data.. fill in the field "Auto-login username". For this example, the username used is "user" (fill this field with your username).


Scroll up to Session, fill up the necessary fields and save.

Open a command tool and using pscp.exe, copy the public key over to the home directory of user. The public key has to be translated to OpenSSH format, then has to be added to authorized_keys file.
user@host:~ > ssh-keygen -i -f PUBLIC_KEY >> $HOME/.ssh/authorized_keys


Now launch pageant.exe (or PuTTY authentication agent). No window will be opened but instead another icon will appear in the system tray. Right-click on this icon and select "Add Key" (see below).


Browse over to the path where the private key was saved. Key in the passphrase when prompted to do so.


(Skipping the above step will prompt the user for the password. When this happens, use the the password to the unix account not the passphrase to the private key.)

Right-click, again, on the pageant icon in the system tray and choose the session saved earlier in this guide. An ssh login will be initiated with the host without asking for a password.


There you go, a more secure password-less ssh from Windows to your _nix workstation. Access to the saved private key does not compromise security as it requires the passphrase to unlock the key. However, this introduces the dependence to pageant, where the passphrase is asked only once but password-less still.

Pageant will be void of keys each time it is launched. And, consequently, each time the private key is "added" to pageant, the passphrase will be asked to unlock the key.

Compare the password-less implementations and select which is easier, applicable and better suited for your use. Each has its own set of advantages and disadvantages.

Share:

FAQ: Password-less SSH -- Windows to Linux

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

Password-less SSH setups save time and hassle. It plays an important role especially when triggering scripts or copying files to a remote machine. Previous posts have outlined a few of the scenarios where the set-up can apply -- for the same account and for establishing trust between distinct accounts.

FAQ: There is another scenario where password-less ssh can apply. This scenario is very typical in support teams, as I have experienced, whereby a system administrator administers machines remotely from his Windows desktop. Can password-less ssh still apply?

Start off by downloading the necessary tools. For this trick to work, you will be needing the following software binaries: putty.exe, puttygen.exe and pscp.exe. The tools mentioned can be downloaded off the author's website. If you have them readily available, let us proceed.

Start off by launching puttygen.exe. This tool will generate the public and private key pairs needed for the password-less setup, similar to ssh-keygen.


Press "Generate" and help the software do its thing. Afterward, save the private and public keys. And when prompted with a warning for empty passphrase, confirm the save. As always, save the private key to a secure location, where only you can access it (as much as possible).


Open putty.exe. Scroll down to Connection --> Data.. fill in the field "Auto-login username". For this example, the username used is "user".


Scroll further down.. Under Connection --> SSH --> Auth. Point it to the path where the private key file was saved. This will be the private key to be used for password-less authentication.


Scroll up to Session, fill up the necessary fields and save.

Open a command tool and with pscp.exe, copy the public key over to the home directory of user. The public key has to be translated to OpenSSH format, then has to be added to authorized_keys file.
user@host:~ > ssh-keygen -i -f PUBLIC_KEY >> $HOME/.ssh/authorized_keys

Go back to putty.exe, load the saved session (double click the saved session) or click Open and see password-less ssh in action.


There you go. Password-less ssh from Windows to your _nix workstation. Give it a go and save yourself the hassle of presenting credentials again and again.

Share:

FAQ: Password-less SSH -- Two Distinct Accounts

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

FAQ: The previous FAQ outlined password-less ssh setup for a single account. Another scenario where password-less ssh can be set-up is on two distinct accounts. In this scenario, trust can be established one-way or two-way. Again, the question is: How can you set-up password-less ssh?

One-Way Trust. A very good application for this kind of set-up is one user account (username: user) and one application account (username: appl), where the user account is "trusted" by the application account.

Begin by generating the public and private key pair. Use ssh-keygen to generate keys. Just the same, do not use a passphrase for completely password-less logins to work.
user@host:~ > ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
e8:3a:ad:11:d5:c5:89:7c:32:d6:3f:62:61:12:43:df user@host

You should be seeing the following files inside the .ssh directory (take note of the permissions):
user@host:~/.ssh > ls -la
total 17
drwx------ 2 user users  168 2008-09-09 14:42 .
drwxr-xr-x 9 user users  688 2008-09-09 14:34 ..
-rw-r--r-- 1 user users  622 2008-09-09 14:34 authorized_keys
-rw------- 1 user users 1675 2008-09-09 08:40 id_rsa
-rw-r--r-- 1 user users  396 2008-09-09 08:40 id_rsa.pub

With the public and private key pair generated, the contents of the public key (id_rsa.pub) need to be placed inside the authorized_keys file of the application account. First copy the public key over to the home directory of the application account (key in appl's password when asked):
user@host:~/.ssh > scp id_rsa.pub appl@remote:/home/appl
Password:
id_rsa.pub                                 100%  396     0.4KB/s   00:00

As user "appl", create the .ssh directory with permission 700 (drwx------). A safer and easier way to accomplish this is to generate the public and private key pair as well.

Then save the contents of user's public key to the authorized keys file.
appl@remote:~ > cat id_rsa.pub >> $HOME/.ssh/authorized_keys

On an initial set-up of password-less ssh the file id_rsa.pub can be copied to the file authorized_keys.
user@host:~ > cp id_rsa.pub $HOME/.ssh/authorized_keys

After doing the above steps, subsequent logins for user to appl (at host remote) will not ask for credentials. It will be password-less. One-way trust is established.

Two-Way Trust. As seen above one-way trust can be established by adding the contents of the user's public key to appl's authorized keys. To establish the two-way trust, appl's public key needs to be added to user's authorized keys -- the "reverse".

Generate a public and private key pair, if this has not been generated yet. Assuming that this was done in one of the steps above, all that needs to be done is to copy the public key to the home directory of user.
appl@remote:~/.ssh > scp id_rsa.pub user@host:/home/user
Password:
id_rsa.pub                                 100%  396     0.4KB/s   00:00

Likewise, save the contents of appl's public key to the authorized keys file.
user@host:~ > cat id_rsa.pub >> $HOME/.ssh/authorized_keys

Accomplishing the above steps establishes two-way trust between user and appl. If the accounts are in NIS (auto_home) or a centralized network share for home directories, trust between the accounts can be established from any machine.

In the next FAQ, the steps on password-less ssh from your Windows machine to your _nix machine will be outlined.

Share:

FAQ: Setup Password-less SSH

"There’s No Such Thing As A Silly Question" -- does the cliche sound familiar? In this part of pimp-my-rig reloaded, technical questions are answered. Mail them to me and I will post the answers here. If you have a better answer, by all means share it with us.

FAQ: The age of the use of telnet has gone past. Although it is still used in some applications, ssh seems to have become standard in remotely accessing hosts. However, trying to remotely access another machine (as yourself), you will be asked to present your credentials. This happens again and again. How then can you set-up password-less ssh?

There are several scenarios for password-less ssh. But this FAQ will only cover password-less remote access as the same user (or as yourself).

Begin by accessing a host using your own credentials. Check if the directory $HOME/.ssh already exists. If it exists, ensure that the directory permission is 700 (dwrx------). Otherwise, there is no need to worry as the directory will be created later with the proper permission.

Use ssh-keygen to generate your very own public and private key pair. Do not use a passphrase for completely password-less logins to work.
user@host:~ > ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
e8:3a:ad:11:d5:c5:89:7c:32:d6:3f:62:61:12:43:df user@host

The above command "ssh-keygen -t rsa" initiated the creation of the key pair. The private key was saved in .ssh/id_rsa. This file is read-only and only for you. No one else must see the content of that file, as it is used to decrypt all correspondence encrypted with the public key, which is aptly named .ssh/id_rsa.pub.

NOTE: Generate the key pair file only once. Otherwise, subsequent re-generations of the key pair will invalidate other password-less set-ups already working for you.

With the public and private key pair generated, the contents of the public key (id_rsa.pub) need to be placed inside the authorized_keys file.
user@host:~/.ssh > cat id_rsa.pub >> authorized_keys

On an initial set-up of password-less ssh the file id_rsa.pub can be copied to the file authorized_keys.
user@host:~/.ssh > cp id_rsa.pub authorized_keys

After doing the above steps, subsequent logins will not ask for credentials. It will be password-less.

Aside from sparing yourself from the hassle of being asked a password for each login, password-less ssh can be deployed and has proven to be advantageous in a lot of situations.

In the next FAQ, the steps on password-less ssh for different users and/or different machines will be outlined.

Share:

HOW-TO: Mount ISO Images

There are a million reasons (perhaps exaggerated, but you get the point) why you should mount an ISO file. To name one, access to the harddrive is way faster than access to the optical drive. Another would be, not all hosts have optical drives or access to the physical host is restricted. Or perhaps, the device can read optical media but could not "burn" or write to it. And the list goes on but the fact of the matter is: the optical drive is rarely used, if at all.

Windows has virtual CD/DVD drives and most of these add-on software(s) are free. How about in the _nix platforms? Do the machines need virtual devices? Are the software(s) free as well? How are they installed? These questions are only a few that need answers. Perhaps discussing the process will, in turn, directly address the questions.

Linux. In Linux, ISO images are mounted via the loop device. It makes possible to specify transfer functions like encryption or decryption, compression or other purposes using loop device driver.

As super-user or root, create the directory to be used as mount point.
root@host # mkdir /SOME/PATH

Mount the ISO image like below.
root@host # mount -o loop /PATH/TO/IMAGE.iso /SOME/PATH

The ISO image (IMAGE.iso) can now be accessed under /SOME/PATH.

To unmount the image, the usual unmount command can be run.
root@host # umount /SOME/PATH


Solaris. Solaris, just like linux has a loopback device "lofi" - the loopback file driver. The lofi file driver exports a file as a block device, making it possible for the system to read and write to the device (or to the underlying file related to the device).

With the ISO image exported as a block device, the lofi file driver allows normal system utilities like mount to operate on the image. The exported block device of the ISO image can now be mounted, accessing the ISO image.

From Sun online documentation:
  The tool lofiadm administers lofi(7D), the loopback file driver. lofi(7D) allows a file to be associated with a block device. That file can then be accessed through the block device. This is useful when the file contains an image of some filesystem (such as a floppy or CD-ROM image), because the block device can then be used with the normal system utilities for mounting, checking or repairing filesystems. See fsck(1M) and mount(1M).

Use lofiadm to add a file as a loopback device, remove such an association, or print information about the current associations.

The lofi(7D) driver is not available and will not work inside a zone.

First, create the block device using lofiadm.
root@host # lofiadm -a /PATH/TO/IMAGE.iso
/dev/lofi/1

In running the above command, lofiadm picks the device and prints the device name to the standard output. The absolute path to IMAGE.iso must be given -- /PATH/TO/IMAGE.iso. Otherwise, lofiadm will return an error.

You can run lofiadm alone to list the devices.
root@host # lofiadm
Block Device File Options
/dev/lofi/1 /PATH/TO/IMAGE.iso -

With the block device (/dev/lofi/1) created, it could now be mounted.
root@host # mount -F hsfs -o ro /dev/lofi/1 /mnt

The above creation and mouting can be executed in a single command.
root@host # mount -F hsfs -o ro `lofiadm -a /PATH/TO/IMAGE.iso` /SOME/PATH

Unmounting the device is similar to unmounting in Linux. Very straightforward. After unmount has executed, the lofi block device still exists and, if desired, can be deleted. Execution of standalone lofiadm on the command line will show which block device to delete. In this example, there is only one block device /dev/lofi/1.
root@host # lofiadm -d /dev/lofi/1

There are a lot of advantages in mounting an ISO image in both Solaris and Linux. And best of all, there is no need to install additional software as the system itself has the necessary tools to make it possible. There goes the answer.

Share:

HOW-TO: Mount USB Thumbdrives in Solaris

USB thumbdrives have become mainstream. And most of the portable tools and utilities are stored in them. This is true for both Windows and Unix/Linux. But I recently was asked a question on how to mount USB thumbdrives in Solaris. Indeed, how is a thumbdrive mounted in Solaris?

Aside from the knowledge of mounting the USB thumbdrive, a more important question arises -- where is it mounted? These questions presume that Solaris supports thumbdrives and indeed it does, as we shall see in a bit.

Mount the USB thumbdrive. USB thumbdrives are emulated as SCSI hot-plug devices. They are under the control of the Solaris Volume Management daemon "vold". The same daemon is responsible for the floppy and CD/DVD optical devices.

Plug the drive to the USB port. Become super-user (root) or a privileged user (via sudo). The rest of the commands need elevated privileges. To check if the USB thumbdrive is detected, use cfgadm.
root@host # cfgadm
...
...
usb0/2.0 usb-storage connected configured ok
...
...

The output above confirms that the USB thumbdrive is properly detected by the system.

The directory /rmdisk does not exist on a Solaris system by default. So it needs to be created.
root@host # mkdir /rmdisk

With the /rmdisk directory existing vold needs to be restarted, if it is started.
root@host # pkill -HUP vold

.. or started, if disabled.
» for Solaris 10
root@host # /etc/init.d/volmgt start

» for older Solaris versions
root@host # /etc/init.d/vold start


Verify that the device is found by vold.
root@host # volcheck -v
media was found

The USB thumbdrive is now mounted in /rmdisk/rmdisk0.

Unmount the USB thumbdrive. Just like in Windows, the thumbdrive needs to be unplugged or unmounted properly.

To unmount the thumbdrive, run the command below:
root@host # volrmmount -e rmdisk0

Verify that the device is no longer detected by the system.
root@host # volcheck -v
no media was found

There you go, the mounting and unmounting of a USB thumbdrive in Solaris. I hope this post answers the questions you may have about thumbdrives in Solaris.

Thumbdrives can be useful in Solaris as well.

Share:

HOW-TO: Replace Failed Drives Under SDS

In order to protect the operating system, avoid serious downtime, and most of all save previous man-hours, implementing RAID 1 (or mirror) using SDS was a very viable solution. Not only that, the solution is quick to execute and with considerable success at that.

There are a lot of reasons disks and partitions fail. But when this happens, it should be attended as risks for possible catastrophic downtime mounts. Before replacing disks suspected of failure, that failure has to be verified. What are the symptoms? How are they diagnosed? Answers to the two important questions are equally as important.

Symptoms of Disk Failure. There are several indications of a failing or failed disk. More often than not, a combination of the following logs, errors or outputs may confirm the disk failure.

» Utilities such as iostat can confirm the failure.
root@host # iostat -En cxtxdx

The parameter to watch out would be "Hard Errors". On a failing disk the count on this parameter would be greater than 0 (and increasing).

» Log files should also the failure symptoms. Messages such as ones below should be in the /var/adm/messages.
md_stripe: [ID 641072 kern.warning] WARNING: md: d5: read error on /dev/dsk/c0t1d0s5
md_mirror: [ID 104909 kern.warning] WARNING: md: d5: /dev/dsk/c0t1d0s5 needs maintenance

» The format output can confirm the failure. As seen below, the disk could not be recognized by the system.
AVAILABLE DISK SELECTIONS:
0. c0t0d0 <SUN72G cyl 14087 alt 2 hd 24 sec 424>
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@0,0
1. c0t1d0 <drive type unknown>
/pci@1e,600000/pci@0/pci@a/pci@0/pci@8/scsi@1/sd@1,0

» The SDS binary metastat can show the symptom as well.
root@host # metastat d5
d5: Mirror
Submirror 0: d15
State: Okay
Submirror 1: d25
State: Needs maintenance
...
d25: Submirror of d5
State: Needs maintenance
Invoke: metareplace -e d25 c0t1d0s5
...

There could be several scenarios that may arise. Assuming the worst possible scenario the failed disk has to be replaced. Follow along as the following procedure tackes just that.

Partial Disk Failure. Partial disk failure is characterized by a combination of Hard Errors, logged messages and metastat maintenance flag.

[1] Delete any state database replicas from the failed disk. A "W" in metadb output indicates replica device write errors.
root@host # metadb
flags first blk block count
a m p luo 16 8192 /dev/dsk/c0t0d0s7
a p luo 8208 8192 /dev/dsk/c0t0d0s7
W p l 16 8192 /dev/dsk/c0t1d0s7
W p l 8208 8192 /dev/dsk/c0t1d0s7

root@host # metadb -d /dev/dsk/c0t1d0s7
root@host # metadb
flags first blk block count
a m p luo 16 8192 /dev/dsk/c0t0d0s7
a p luo 8208 8192 /dev/dsk/c0t0d0s7

[2] The metadevice that is still in "okay" state should be detached from the mirror. (Assuming metadevice d0 is still in "okay" state.)
root@host # metadetach d0 d20
d0: submirror d20 is detached

[3] Replace the failed disk. In this example, the secondary disk at c0t1d0.

[4] Replicate the partition table of the primary disk to the secondary disk.
root@host # prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t1d0s2

[5] Re-create the state databases. The state database has to exist in the new secondary disk as well.
root@host # metadb -a -c2 /dev/dsk/c0t1d0s7

[6] Run metareplace on the partitions that the "Needs Maintenance" flag (as shown above).
root@host # metareplace -e d21 c0t1d0s1
root@host # metareplace -e d24 c0t1d0s4
...

[7] Re-attach the detached mirror.
root@host # metattach d0 d20

Full Disk Failure. Full disk failure is confirmed by the output of format. The other characteristics would also be present.

[1] Delete the state databases of the failed disk.

[2] Replace the failed disk.

[3] Duplicate the partition table to the new disk.

[4] Re-create the state databases.

[5] Synchronize the mirrors using metareplace.

Monitor the Re-Synchronization. Re-synchronization of the mirrors can be monitored via metastat.

For Solaris 10, an extra step needs to be executed. The OS needs to be notified of the disk change.

root@host # metadevadm -u c0t1d0
Updating SLVM device relocation information for c0t1d0.

A variation of the preceding command can be done using the full pathname. It achieves the same purpose.
root@host # metadevadm -u /dev/dsk/c0t1d0
Updating SLVM device relocation information for c0t1d0.


Share:

HOW-TO: Mirror Boot Drives Using SDS

Making use of RAID (Redundant Array of Independent Disks) is a logical thing to do, especially in implementation of architectures for data sensitive systems, especially servers. Another reason is avoid downtime in the event of a failure of a boot disk or the disk that stores the operating system. The latter is what this post wants to outline -- mirroring boot drives using SDS.

RAID 1 or mirroring can be cheaply implemented using software mirroring. That is built into the operating system and will not require additional hardware. Solaris used to call this software the Solaris Disk Suite (or SDS) and is now built into the latest Solaris 10 as Solaris Volume Manager (or SVM). Regardless of whichever name, it refers to the same thing. Let us discuss the same implementation of SDS/SVM.

Prepare the Drives. SDS uses metadevice state databases to store information on disk about the state of your DiskSuite configuration. The metadevice state database records and tracks changes made to your configuration. These databases must reside on a dedicated slice (in the case of a boot drive). I typically leave a small amount of unused space on the boot drive when installing Solaris for these databases. That is, I leave at least one unused slice with approximately 5 MB of free space available for SDS when installing Solaris.

If you do not have any unused space and you have an unused slice, then you may borrow space from swap. See documentation from Sun to perform this step. I recommend using this procedure in single user mode. However, I have been able to successfully perform these steps on idle systems (multi-user but not running applications) where there is no swapping being performed. In abbreviated terms:
* lists the swap devices configured on the system:
root@host # swap -l
swapfile dev swaplo blocks free
/dev/dsk/c0d0d0s1 29,0 8 1638608 1638608

* Disable the swap:
root@host # swap -d /dev/dsk/c0t0d0s1

* repartition swap device to exclude at least 5 MB of sector space. Partition these sectors on an unused slice using the format command:
root@host # format

Use format command to select the boot disk and create the slice that will hold the state database. The output from format of my boot disk looks like the following. I have the following filesystems carved: /, swap, /var, /opt, and /export/home
Part      Tag    Flag     Cylinders        Size            Blocks
0 root wm 0 - 1392 3.13GB (1393/0/0) 6563816
1 swap wu 1393 - 3131 3.91GB (1739/0/0) 8194168
2 backup wm 0 - 7505 16.86GB (7506/0/0) 35368272
3 var wm 3132 - 4870 3.91GB (1739/0/0) 8194168
4 unassigned wm 4871 - 5740 1.95GB (870/0/0) 4099440
5 home wm 5741 - 7479 3.91GB (1739/0/0) 8194168
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 0 0 (0/0/0) 0

Notice that slice 6 and 7 are unassigned and also there are 26 unused cylinders (7480 to 7505).

* create the dedicated slice for the state databases (common convention uses slice 7):
partition> 7
Part Tag Flag Cylinders Size Blocks
7 unassigned wm 7480 - 7504 57.52MB (25/0/0) 117800

Enter partition id tag[unassigned]:
Enter partition permission flags[wm]:
Enter new starting cyl[0]: 7480
Enter partition size[117800b, 25c, 57.52mb, 0.06gb]: 57.52mb
partition> p
Current partition table (unnamed):
Total disk cylinders available: 7506 + 2 (reserved cylinders)

Part Tag Flag Cylinders Size Blocks
0 root wm 0 - 1392 3.13GB (1393/0/0) 6563816
1 swap wu 1393 - 3131 3.91GB (1739/0/0) 8194168
2 backup wm 0 - 7505 16.86GB (7506/0/0) 35368272
3 var wm 3132 - 4870 3.91GB (1739/0/0) 8194168
4 unassigned wm 4871 - 5740 1.95GB (870/0/0) 4099440
5 home wm 5741 - 7479 3.91GB (1739/0/0) 8194168
6 unassigned wm 0 0 (0/0/0) 0
7 unassigned wm 7480 - 7505 57.52MB (26/0/0) 122512

partition> label
Ready to label disk, continue? y

* after partitioning, re-enable Swap
root@host # swap -a /dev/dsk/c0t0d0s1

* format the mirror drive in the same manner as the primary. There is no need to run format to make this happen as there is a much faster way.
root@host # prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t8d0s2
fmthard: New volume table of contents now in place

In this case c0t0d0s2 is the boot drive and c0t8d0s2 is the mirror. Notice that it is on the same controller. You should try to mirror drives across different controllers if at all possible. Basically, the fmthard command takes the partition table of the boot disk and replicates it to the mirror drive. Use the format command to verify that the partitions are exactly identical.

Configure Solstice Disk Suite. With the drives properly sliced or partitioned, it is time to configure SDS.

[1] Create at least 2 state database replicas on each disk. A state database replica stores DiskSuite configuration and state information. Before you can use DiskSuite, you must create state database replicas.
root@host # metadb -a -f -c2 /dev/dsk/c0t0d0s7 /dev/dsk/c0t8d0s7

Where -a means adding; -f means force because this is the first time creating databases; and -c 2 means create 2 databases in each slice.

[2] Create the mirror for / filesystem. Here, we are creating a one-way mirror which for the time being is composed of 1 drive. Later we will attach the second drive to the mirror. The metainit command defines the metadevices that the mirror will use. The device numbers (d##) are arbitrary.
root@host # metainit -f d10 1 1 c0t0d0s0
root@host # metainit d20 1 1 c0t8d0s0
root@host # metainit d0 -m d10

Take a look at your /etc/vfstab and notice that the / filesystem will be mounted on /dev/md/dsk rather than /dev/dsk.

[3] Update the /etc/vfstab for / filesystem and /etc/system. Do not try to edit /etc/vfstab or /etc/system manually. Use the metaroot command:
root@host # metaroot d0

Solstice Disk Suite has the following rules with respect to the use of database replicas:
» The system will not boot unless more than half of the replicas are available
» The system will panic if more than half of the replicas are corrupt

In other words, if one of your drives fail, and the system is rebooted for any reason (hardware/software/human error), the system will not automatically boot in a two disk mirror configuration. The system will have to be brought to single user mode where the broken replicas can be removed to pass the quorum rule (more than half the replicas must be available). Fortunately, you can disable the feature by setting the following system parameter:
root@host # echo "set md:mirrored_root_flag=1" >> /etc/system

It is recommended to set this parameter in a 2 disk mirror configuration to ensure that the system boots with a failed drive.

[4] Create the mirror for all other filesystems:
» for swap:
root@host # metainit -f d11 1 1 c0t0d0s1
root@host # metainit d21 1 1 c0t8d0s1
root@host # metainit d1 -m d11
» for /var filesystem:
root@host # metainit -f d12 1 1 c0t0d0s3
root@host # metainit d22 1 1 c0t8d0s3
root@host # metainit d2 -m d12
» for /opt filesystem:
root@host # metainit -f d13 1 1 c0t0d0s4
root@host # metainit d23 1 1 c0t8d0s4
root@host # metainit d3 -m d13
» for /export/home filesystem:
root@host # metainit -f d14 1 1 c0t0d0s5
root@host # metainit d24 1 1 c0t8d0s5
root@host # metainit d4 -m d14

[5] Edit the /etc/vfstab to mount the new mirrors on boot. In order to put safeguards in place, make sure to take a backup copy of the file /etc/vfstab.
The /etc/vfstab prior to edits:
#device         device          mount           FS      fsck    mount   mount
#to mount to fsck point type pass at boot options
#
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes -
fd - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/dsk/c0t0d0s1 - - swap - no -
/dev/md/dsk/d30 /dev/md/rdsk/d30 / ufs 1 no -
/dev/dsk/c0t0d0s3 /dev/rdsk/c0t0d0s3 /var ufs 1 no -
/dev/dsk/c0t0d0s5 /dev/rdsk/c0t0d0s5 /export/home ufs 2 yes -
/dev/dsk/c0t0d0s4 /dev/rdsk/c0t0d0s4 /opt ufs 2 yes -
swap - /tmp tmpfs - yes -

The /etc/vfstab after edits:
#device         device          mount           FS      fsck    mount   mount
#to mount to fsck point type pass at boot options
#
#/dev/dsk/c1d0s2 /dev/rdsk/c1d0s2 /usr ufs 1 yes -
FD - /dev/fd fd - no -
/proc - /proc proc - no -
/dev/md/dsk/d1 - - swap - no -
/dev/md/dsk/d0 /dev/md/rdsk/d0 / ufs 1 no -
/dev/md/dsk/d2 /dev/md/rdsk/d2 /var ufs 1 no -
/dev/md/dsk/d4 /dev/md/rdsk/d4 /export/home ufs 2 yes
-
/dev/md/dsk/d3 /dev/md/rdsk/d3 /opt ufs 2 yes -
swap - /tmp tmpfs - yes -

[6] (OPTIONAL) Suppress harmless warning messages
Typically, after a SDS install, you will receive the harmless but annoying messages on boot-up: "WARNING: forceload of misc/md_hotspares failed". This is a nuisance, so I typically suppress them by creating an empty hot spare pool:
# metainit hsp001

[7] Reboot and allow the system to mount the mirrors.
root@host # init 6


Ignore the following errors on boot. Suns reason for these errors: "These warnings are harmless, and may be ignored. They are an artifact of the way drivers are loaded during the boot process when you have a mirrored root or /usr file system."
WARNING: forceload of misc/md_trans failed
WARNING: forceload of misc/md_raid failed
WARNING: forceload of misc/md_hotspares failed

[8] Attach the second submirror to the mirror. This will cause the data from the boot disk to be synchronized with the mirrored drive.
# metattach d0 d20
# metattach d1 d21
# metattach d2 d22
# metattach d3 d23
# metattach d4 d24

Use metastat to track progress
# metastat d0

d0: Mirror
Submirror 0: d10
State: Okay
Submirror 1: d20
State: Resyncing
Resync in progress: 21 % done
Pass: 1
Read option: roundrobin (default)
Write option: parallel (default)
Size: 6563816 blocks
...

[9] Notify the system of the change in the dump device.
root@host # dumpadm -d /dev/md/dsk/d1

[10] Enable the mirror disk to be bootable:
# installboot /usr/platform/`uname -i`/lib/fs/ufs/bootblk /dev/rdsk/c0t8d0s0

Set nvram and reboot system to verify system will boot
# eeprom "boot-device=disk0 disk1"
# eeprom use-nvramrc?=false

NOTE: You can set this at the boot prom if you like. Use the devalias and setenv command. In case of primary boot disk failure, boot from the alternate disk:
ok  boot mirror

Stay tuned for the next guide on how to replace a failed mirror drive.

Share:

Subscribe for Latest Update

Popular Posts

Post Labels

100gb (1) acceleration (1) acrobat (1) adblock (1) advanced (1) ahci (1) airdrop (2) aix (14) angry birds (1) article (21) aster (1) audiodg.exe (1) automatic (2) autorun.inf (1) bartpe (1) battery (2) bigboss (1) binance (1) biometrics (1) bitcoin (3) blackberry (1) book (1) boot-repair (2) calendar (1) ccleaner (3) chrome (5) cloud (1) cluster (1) compatibility (3) CPAN (1) crypto (3) cydia (1) data (3) ddos (1) disable (1) discount (1) DLNA (1) dmidecode (1) dns (7) dracut (1) driver (1) error (10) esxi5 (2) excel (1) facebook (1) faq (36) faucet (1) firefox (17) firewall (2) flash (5) free (3) fun (1) gadgets (4) games (1) garmin (5) gmail (3) google (4) google+ (2) gps (5) grub (2) guide (1) hardware (6) how (1) how-to (45) huawei (1) icloud (1) info (4) iphone (7) IPMP (2) IPV6 (1) iscsi (1) jailbreak (1) java (3) kodi (1) linux (28) locate (1) lshw (1) luci (1) mafia wars (1) malware (1) mapsource (1) memory (2) mikrotik (5) missing (1) mods (10) mouse (1) multipath (1) multitasking (1) NAT (1) netapp (1) nouveau (1) nvidia (1) osmc (1) outlook (2) p2v (2) patch (1) performance (19) perl (1) philippines (1) php (1) pimp-my-rig (9) pldthomedsl (1) plugin (1) popcorn hour (10) power shell (1) process (1) proxy (2) pyspark (1) python (13) qos (1) raspberry pi (7) readyboost (2) reboot (2) recall (1) recovery mode (1) registry (2) rename (1) repository (1) rescue mode (1) review (15) right-click (1) RSS (2) s3cmd (1) salary (1) sanity check (1) security (15) sendmail (1) sickgear (3) software (10) solaris (17) squid (3) SSD (3) SSH (9) swap (1) tip (4) tips (42) top list (3) torrent (5) transmission (1) treewalk (2) tunnel (1) tweak (4) tweaks (41) ubuntu (4) udemy (6) unknown device (1) updates (12) upgrade (1) usb (12) utf8 (1) utility (2) V2V (1) virtual machine (4) VirtualBox (1) vmware (14) vsphere (1) wannacry (1) wifi (4) windows (54) winpe (2) xymon (1) yum (1) zombie (1)

RANDOM POSTS