How do I create a mirrored system disk in Solaris 10 jumpstart?

Solaris 10 supports the use of mirror devices with the filesys keyword. This is in addition to other new features including patch installation, and package commands (when installing flash archives).
Here is an example jumpstart profile with mirroring:-

install_type initial_install
system_type standalone
cluster SUNWCall
partitioning explicit
filesys mirror:d10 c0t0d0s0 c0t1d0s0 8192 /
filesys mirror:d20 c0t0d0s1 c0t1d0s1 4096 swap
filesysmirror:d30 c0t0d0s3 c0t1d0s3 4096 /opt
filesys mirror:d40 c0t0d0s4 c0t1d0s4 8192 /usr
filesys mirror:d50 c0t0d0s5 c0t1d0s5 free /export/home
metadb c0t1d0s7 size 8192 count 3

Rather generous slice sizes, but they always seem to fill up....
The submirror devices names will be formulated automatically (e.g. d11 and d12 for the d10 mirror device)
Metastate database replicas must be on a slice separate to any metadevice (This is not a restriction other than in a jumpstart), and there must be at least three in any SVM system

How can I migrate my Solaris 10 (Update 6, 10/08 onwards) system to a ZFS-based root file system?

This is a brief example of migrating an existing UFS-based Solaris 10 system to use a ZFS storage
pool for its root, swap and dump areas.
This is only supported in Solaris 10 Update 6 (10/08) onwards.

This procedure shows the process for migrating using Live Upgrade, and is one of six Live Upgrade scenarios taken from our Solaris Live Upgrade Workshop one-day course.

Note that preparation for performing a Live Upgrade includes installation of specific patches and the correct Live Upgrade software, plus availability of disk storage. See the following link for details:-
http://sunsolve.sun.com/search/document.do?assetkey=1-61-206844-1

Migrating to ZFS has several benefits, including:-

* Using advanced ZFS facilities, with attendant performance and resilience.
* Only one pool to maintain, with simple administration and easy addition of disks to the pool if more capacity is needed.
* New Boot Environments (BE's) are created using ZFS file system snapshot clones, and are created almost instantly; these can then be upgraded, patched and modified (adding removing packages, etc) and then activated and booted from to take over from the currently running BE.

To begin, create a pool on your spare disk(s), preferably a mirror.

The pool must be created from slices on disks with an SMI disk label, rather than whole disks, in order to be bootable and upgradeable, and you must use only slices or mirrors, and not RAIDZ. (a feature of ZFS roughly equivalent to RAID 5)

A ZFS root file system is larger than a UFS root file system because swap and dump devices must be separate devices, whereas swap and dump devices are the same device in a UFS root file system.

# zpool create -f prawn_root_t2 mirror c0t2d0s0 c0t3d0s0
# zpool status
.. displays information about the ZFS pools.

Now use lucreate to create a new BE on the ZFS pool:-
# lucreate -n prawn_zfs_root -p prawn_root_t2
Analyzing system configuration.
Comparing source boot environment file systems with the file
system(s) you specified for the new boot environment. Determining which
file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Updating system configuration files.
The device is not a root device for any boot environment; cannot get BE ID.
Creating configuration for boot environment .
Source boot environment is .
Creating boot environment .
Creating file systems on boot environment .
Creating file system for in zone on .
Populating file systems on boot environment .
Checking selection integrity.
Integrity check OK.
Populating contents of mount point .
Copying.
Creating shared file system mount points.
Creating compare databases for boot environment .
Creating compare database for file system .
Creating compare database for file system .
Creating compare database for file system .
Creating compare database for file system .
Updating compare databases on boot environment .
Making boot environment bootable.
Creating boot_archive for /.alt.tmp.b-4Gc.mnt
updating /.alt.tmp.b-4Gc.mnt/platform/sun4u/boot_archive
Population of boot environment successful.
Creation of boot environment successful.
#
(Takes about 30-40 minutes.)
Note that data slices separate from those containing the Solaris OS such a /export/home will not be migrated (nor can they be, unlike BE's contained on UFS file systems); such slices will be mounted on their original mount points when the new BE is booted.
# lufslist prawn_zfs_root
.. displays file system information for the new BE
# lustatus
.. displays general BE information

You could now use luupgrade or smpatch (smpatch currently has issues...) to patch the new (ZFS-based) BE before activating it.

If the original (UFS) BE contained non-global zones in the system slices, they will be copied with the lucreate.
If they exist in a non-system slice, such as /zones mounted on a separate slice, then they will treated as a shared slice, in a similar manner to a /export/home slice as described above.

Looking to the future, when further releases are available, you could upgrade the new BE before booting it:-
# luupgrade -n prawn_zfs_root -u -s /net/yamaha/software/sol10_u8
Where /net/yamaha/software/sol10_u8 is the path to a valid Solaris 10 distribution image. (Imaginary as at March 2009!)

Now that the new ZFS BE is created, we can activate it, then boot from it:-
# luactivate prawn_zfs_root
A Live Upgrade Sync operation will be performed on startup of boot environment

.

******************************************************************
The target boot environment has been activated. It will be used when you
reboot. NOTE: You MUST NOT USE the reboot, halt, or uadmin commands. You
MUST USE either the init or the shutdown command when you reboot. If you
do not use either init or shutdown, the system will not boot using the
target BE.
******************************************************************
In case of a failure while booting to the target BE, the following process
needs to be followed to fallback to the currently working boot environment:

1. Enter the PROM monitor (ok prompt).

2. Change the boot device back to the original boot environment by typing:

setenv boot-device /pci@1f,0/ide@d/disk@0,0:a

3. Boot to the original boot environment by typing:
boot
******************************************************************
Modifying boot archive service
Activation of boot environment successful.

You can now reboot, but see the output above from luactivate on which commands to use.
# init 6


When the new ZFS root pool BE is booted and running, we can consider our next steps.
We may wish to retain the original BE in case of problems.
Have a look around to see how the system looks with various commands - you will not notice much difference, except with commands such as df.
Also, it is important to have knowledge of ZFS zpool and zfs commands in order to maintain the file systems and pool; such topics are covered on both our Solaris 10 Systems Administration Part 2, and Solaris 10 Update Workshop courses.
Note how partitions that hold user data, such as /export/home, are not included in the BE, but retain their original partitions and mount points.
You may wish to migrate these also ZFS, perhaps in a separate pool.
It is possible to place such things within the existing pool, but this would make them part of any new cloned BE's, with possible complications as a result.

Now we can create a further BE very quickly, which can then be patched or upgraded as required.

To create a new BE from our ZFS BE:-
# lucreate -n prawn_root_t2_jan_31
Analyzing system configuration.
Comparing source boot environment file systems with the
file system(s) you specified for the new boot environment. Determining
which file systems should be in the new boot environment.
Updating boot environment description database on all BEs.
Updating system configuration files.
Creating configuration for boot environment .
Source boot environment is .
Creating boot environment .
Cloning file systems from boot environment to create boot environment .
Creating snapshot for on .
Creating clone for on .
Setting canmount=noauto for in zone on .
Population of boot environment successful.
Creation of boot environment successful.

Takes about 30 seconds.....
# lustatus

A zfs list command will show the BE has been created as a clone of a ZFS snapshot.
# zfs list

Snow Leopard: Enabling the root user

By default, the root user is not enabled in Mac OS X 10.6 Snow Leopard. Enabling it takes a simple procedure by way of the Directory Utility application or via Terminal. In Mac OS X 10.5, Directory Utility was located in the Applications > Utilities folder. In Snow Leopard, this is no longer the case. You can now find Directory Utility in System > Library > CoreServices.

To enable the root user using Directory Utility:

1. Open Directory Utility.
2. Click the padlock icon to unlock the application. Enter your administrator password to authenticate.
3. From the Directory Utility menu bar, select Edit > Enable Root User.
4. Now, select Edit > Change Root Password and enter the password of your choice.

To enable the root user using Terminal:

1. Open terminal and enter: sudo passwd root
2. Enter your administrator password followed by a password for the root user and you're all set.

Keep in mind that enabling the root user significantly increases the security threats on your Mac. Users should only enable the root user if they specifically need it and know what they are doing.

Prevent the Terminal host name from changing Mac OSX Server

When you launch the terminal, the default shell "Bash" will present the last login time, followed by the command prompt. This is formatted to show the computer's name, followed by the current directory and then a dollar sign. Depending on the system and network configuration, the computer's name may change.

My hostname is "Kishore-Desktop"

The computer's host name is the one you type in the "Sharing" system preferences, and while a change in the hostname should not affect the performance of the machine, it is nice to have it be consistent. The first thing to try is to use the "hostname" command to change the hostname:

I've just changed the hostname to "TEST", but the current login session does not yet reflect the change

After running this command, the terminal name will not change until you quit the current shell and log in again:

Starting a new terminal session shows the change.

The hostname can be changed dynamically by routers and other network devices through DHCP requests, which can have the hostname keep changing every time your IP address and other DHCP information is renewed. If this is the case, you may be able to set the router to never provide hostname information, or you can set the computer to never accept a hostname change. To do this, you will need to add a line to the computer's hostconfig file using the following procedure:

1.

Open the Terminal
2.

Enter the following command:

sudo pico /etc/hostconfig
3.

Authenticate, scroll to the bottom of the file, and add the following line:

HOSTNAME=Kishore-Desktop

(Change "Kishore-Desktop" to your desired hostname--no spaces)
4.

Save the file and quit by pressing control-X, confirming the save with the "Y" key followed by "enter".

Editing the /etc/hostconfig file in "pico" so the hostname never changes

After this has been added to the file, the computer's hostname should not change even when you renew your DHCP lease.

SSH Public key based authentication

This howto covers generating and using ssh keys for automated:

a) Login

b) Make backups

c) Run commands from shell etc

Task: Generating ssh keys

1) Log on to your workstation ( for example log on to workstation called admin.fbsd.nixcraft.org as vivek user). Please refer the following sample setup - You will be log in, on your local system, AS THE USER you wish to make passwordless ssh connections.


(Click image to enlarge)

2) Create the Cryptographic Key on FreeBSD workstation, enter:

$ ssh-keygen -t rsa
Assign the pass phrase (press [enter] key twice if you don't want a passphrase). It will create 2 files in ~/.ssh directory as follows:

~/.ssh/id_rsa : identification (private) key
~/.ssh/id_rsa.pub : public key
3) Use scp to copy the id_rsa.pub (public key) to rh9linux.nixcraft.org server as authorized_keys2 file, this is know as Installing the public key to server.

$ scp .ssh/id_rsa.pub vivek@rh9linux.nixcraft.org:.ssh/authorized_keys2
4) From FreeBSD workstation login to server:

$ ssh rh9linux.nixcraft.org
5) Changing the pass-phrase on workstation (if needed):

$ ssh-keygen -p
6) Use of ssh-agent to avoid continues pass-phrase typing
At freebsd workstation type:

$ ssh-agent $BASH
$ ssh-add
Type your pass-phrase

From here, whenever connecting to server it won’t ask for password.
Above two commands can be added to ~/.bash_profile so that as soon as I login into workstation I can set the agent.

7) Deleting the keys hold by ssh-agent

a) To delete all keys

$ ssh-add -D
b) To delete specific key

$ ssh-add -d key
c) To list keys

$ ssh-add -l