Tuesday, 24 April 2012

SOLVED: "This disk drive does not have a valid label" .. Revert disk label back to SMI

Whilst installing a new OS of solaris on a machine, I realised I couldn't install the OS over both disks as one of them was used as a zpool primarily, this therefore labels the disk as a EFI (Extensible Firmware Interface) which is used for logical volumes. This caused problems as I wished to mirror the OS over the two disks for redundancy. I found a fix which was to change the label back from EFI to SMI (Sun Microsystems, Inc) which is the default used to boot Solaris. Below illustrates how I solved the problem:


Procedure
Try accessing a command line from exiting out of the solaris installation or booting up your OS (if you are running a solaris installation, you can perform this procedure and simply type "install-solaris" to revert back to the installation. Perform the following commands:


# format -e

AVAILABLE DISK SELECTIONS:
       0. c2t0d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
       1. c2t1d0 <HITACHI cyl 14087 alt 2 hd 24 sec 848>
Specify disk (enter its number):

Specify which disk you wish to label (in this case its 1, as you can see its not SUN microsystems labelled). and you will see the below output, run label.



FORMAT MENU:
        disk       - select a disk
        type       - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format     - format and analyze the disk
        repair     - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect     - defect list management
        backup     - search for backup labels
        verify     - read and display labels
        save       - save new disk/partition definitions
        inquiry    - show vendor, product and revision
        scsi       - independent SCSI mode selects
        cache      - enable, disable or query SCSI disk cache
        volname    - set 8-character volume name
        !<cmd>     - execute <cmd>, then return
        quit
format> label


Specify label type as SMI (Sun Microsystems, Inc)

[0] SMI Label
[1] EFI Label
Specify Label type[0]:0
Ready to label disk, continue? y
format> q

Quit out and run format again, you will see something similar like below:

     0. c2t0d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848>
     1. c2t1d0 <SUN146G cyl 14087 alt 2 hd 24 sec 848> 

Done. Now you can carry on with the installation (if you quit the installation and have booted from disk or installation media, run install-solaris to revert back to installation).




Friday, 20 April 2012

Flashing the firmware on ILOM based Solaris Systems


This post illustrates how to flash the firmware on an ILOM based Solaris System. It is most important to keep up to date the latest firmware on your systems for many reasons e.g. bug fixes, better performance and generally getting the most out of your Solaris System.


Pre-requisites 
Make sure you have the latest version of the firmware you wish to deploy on to the systems (you 
can do this by logging into My Oracle Support and making sure the zip file is not obsolete, Oracle will give you the option to download the latest zip file). 
Make sure you have network connectivity to your ILOM console via ssh as this is used to flash the firmware once the patch has been added to the system. 
Make sure the zip file has been transferred over to the system in question (for e.g. ssh copied or using ftp). 


Procedure
Log in to your system as root and unzip the patch into a directory of your choosing 


# unzip [patch].zip
# cd [patch] 


There should be a few files in the directory such as README files and licensing etc. The files we are after sysfwdownload and the [image].pkg file which is the firmware image we intend to flash. Make sure you are in the directory of the patch by using the “pwd” command and execute sysfwdownload using the firmware image as an argument: 


# pwd
/path/to/patch/directory
# ./sysfwdownload [image].pkg


Once the download completes successfully the command prompt will return upon completion, 
shutdown the Solaris machine (run level 0) (NOTE: MAKE SURE YOU HAVE SCHEDULED DOWNTIME)


# shutdown –i –g0 –y 


Log in to the ILO vis ssh or serial and run the poweroff command to turn the server off. It would be much better if you have the ALOM compatibility shell enabled for this part of the procedure, to make a user with the ALOM shell, execute the following:


create /SP/users/admin role=Administrator cli_mode=alom
Creating user... 
Enter new password: 
Enter new password again: 
Created /SP/users/admin 


sc> poweroff 
SC Alert: Host system has been shut down 
Set the keyswitch to normal position before flashing the firmware: 
sc> setkeyswitch –y normal 
sc> showkeyswitch 


Finally, flash the firmware using the below command: 


sc> flashupdate –s 127.0.0.1 


Once the flashing procedure is complete the SC will reset, however if it does not, run the following command: 


sc> resetsc 
User Requested SC Shutdown


Wait for the SC to come back online then power on the system:
sc> poweron


Done!

Wednesday, 11 April 2012

Possible steps to convert a global host into a Solaris Zone

This post shows possible steps of converting a Global host into a Solaris zone. The point of a global host is to control and maintain its derived Solaris Zones and if you have workload on a global host you will hit problems of when maintenance needs carrying out. So the best procedure is to have all your workload and applications on a Solaris Zone for easier management. There is a procedure you can go through to perform a p2v (physical to virtual) using flarcreate and zoneadm however this is only supported on a higher release of Solaris, by all means if you have a release of solaris that can support p2v then explore the oracle documentation, but read on if you have an older release.


Pre-requisites
Take note of your network configuration on global host (e.g. IP address, Subnet, Gateway)
(NOTE: It is probably that you will need an extra IP address as you are essentially creating another system that will require an IP address)
Take note of any third party software installed on global host as you will probably have to add them on zone manually if needed (/opt etc.)
Create a backup of your /etc/passwd, /etc/group and /etc/shadow file so that they can be migrated across to zone once it has been configured
Run a "ps -ef" to see if any processes not owned by yourself that are running so you can inform whoever is running them that there will be an outage/possibly schedule an outage.
If you are migrating to another global host, make sure "PermitRootLogin" is set to yes in the sshd_config file (remember to restart the ssh service):


# vi /etc/ssh/sshd_config
PermitRootLogin yes
# svcadm restart ssh


Procedure


Firstly, lets make our zone (it would help if you had two sessions on the same box open)


# zonecfg -z [zonename]
zonecfg:[zonename]>create
zonecfg:[zonename]>set zonepath=/path/to/zonepool/[zonename]
zonecfg:[zonename]>set autoboot=true
zonecfg:[zonename]>add net
zonecfg:[zonename]:net>set address=[ipaddress]
zonecfg:[zonename]:net>set physical=[interface]
zonecfg:[zonename]>end
zonecfg:[zonename]>verify
zonecfg:[zonename]>commit
zonecfg:[zonename]>exit
# zoneadm -z [zonename] install
[DATA]
# zoneadm -z [zonename] boot
# zlogin -C [zonename]


If you haven't used the -C switch before, it is the first-boot configuration of the zone, (languages, hostname etc). It has quite a friendly interface so just run the wizard.


The next step is migrate your /export/home directory from your global host to the new zone using scp. From the global host, run this command:


# scp -r /export/home root@[newzoneipaddress}:/export
[DATA]
[DATA]


Once this is complete, the next step is to copy your users from the /etc/passwd file to your new zone (WITH CAUTION) along with the password from the /etc/shadow file and /etc/group. NOTE PLEASE TAKE CARE WITH THIS PROCEDURE). Once this has complete and you have checked several times that there are no mistakes, reboot your new zone from the global


# zoneadm -z [zonename] reboot


Test to see if your users are configured properly in terms of passwords, groups and home directories. You may find that you need to run a "chown -R" to change all the home directories in /export/home to the relevant user and group. For example:


# chown -R bob:other /export/home/bob


The last step would be to make sure you install any solaris packages located in /opt or any other third party applications, the aim would be to make a complete duplicate of your global host but in solaris zone format. Good advice would be to run "ls -l" in popular directories on each server to increase similarity


Its a long process but it should get the job done. The thing to remember is, if the zone gets mis-configured it can be deleted and recreated.

Tuesday, 10 April 2012

Migrating Solaris Zones from one Global host to another

This post illustrates how to migrate a Solaris zone from one global host to another using zfs send and receive via ssh. This procedure is very useful if you want to perform some kind of patching or upgrading on the global host and do not wish to have downtime on any of your zones.


Pre-requisites
Make sure the destination global host has some kind of file-system or zonepool to place the zone datasets (zone file-systems).
Obviously make sure you are on a release of Solaris that can support Solaris Zones. Run a "zoneadm" command for example to see if the command exists, we don't want to detach our zones and find out that we cannot attach them at the other end!!
Take note of network configuration, login credentials and 3rd party application running on zones, the aim is we want to have the zones up and running on the destination system the exact same state as they are/were on the source system. (running a "ps -ef" and a "w" (or "last -10") helps for me).
Make sure you have permitted root login on destination host by doing the following:


# vi /etc/ssh/sshd_config
PermitRootLogin yes
# svcadm restart ssh


Procedure
Log in to the global zone and shutdown and detach the zone


# zoneadm -z [zonename] halt
# zoneadm -z [zonename] detach


Create a zfs snapshot of your zone


# zfs snapshot -r /path/to/zfs/zone/filesystem/[zonename]@[zonedestination]


Example:
# zfs snapshot -r /zonepool/zones/apple@orange


To see if the snapshot has been created, run:


# zfs list


You should see something similar to this:


NAME                          USED  AVAIL  REFER  MOUNTPOINT

zonepool/zones/apple@orange     2.55M      -  1.55G  -

Send the snapshot over to the new global host using zfs send and receive via ssh:


# zfs send /zonepool/zones/apple@orange | ssh root@[destinationhost] "zfs recv /path/to/zones/apple"
Password:


To keep a check of the migration process, log in to your destination host and run the following command:


# zfs list | grep apple


You will know that the migration is complete when you have two results from that previous command; the zone filesystem and its snapshot.


Its now time to rebuild your zone on the new host:


# zonecfg -z apple
zonecfg:apple> create -a /path/to/zones/apple


Check that the configuration of that zone is the same


zonecfg:apple> info


Complete configuration:


zonecfg:apple> commit
zonecfg:apple> exit

Finally, its time to attach and boot up the zone on the new system. Using zoneadm attach you can see what inconsistencies there are in terms of version mismatches of packages and patches, this is useful to take note of what you need to install on the new zone, if you use attach -u it should automatically upgrade to new package and patch if there is a higher version on the global host. And finally if you just want to force and attachment and not bother with upgrades or list of  inconsistencies,  use attach -u -F:


# zoneadm -z apple attach
# zoneadm -z apple attach -u
# zoneadm -z apple attach -u -F
# zlogin apple

Performing Solaris Live Upgrade to install new Release/OS on a Solaris Machine


This post illustrates upgrading a Solaris machine to a later release using Live upgrade (no downtime required). Live upgrade makes a copy of the critical file systems (root, opt etc), and places it on a defined slice on your disk. The next step is to upgrade that new secondary environment, activate it and reboot to that new environment. The aim of live upgrade is to reduce downtime as much as possible (requiring one simple reboot).

Pre-requisites
Non-Global zones on machine are fully configured and functional
Define and choose a slice that has an efficient amount of memory (approximately enough to hold multiple file-systems, for a better estimate, perform a “df- h” on the primary environment to get an idea of how much storage you will need on your defined slice
Place your new release/OS image in a suitable directory on your primary environmen
Optional – backup
Create a auto registration file (using vi or another editor) on your primary environment, this tags the machine to your my oracle support account, the config file should contain the following attributes:
oracle_user=USERNAME
oracle_pw=PASSWORD
NOTE: http proxy information can be inserted but this is optional (refer to appendix)
Make sure you have the following packages and patches installed on the system you are performing live upgrade on
-   119254-82 (or higher)
-   121428-15 (or higher)
-   121430-74 (or higher)
Login to your My Oracle Support portal and click Patches and Updates to obtain these packages

Procedure
(NOTE: MAKE SURE YOU TAKE INTO CONSIDERATION THE PRE-REQUISITES BEFORE RUNNING THIS PROCEDURE)
Define a slice that has an efficient amount of memory and run this command

# lucreate -n [solenv2] -m [MOUNTPOINT]:[TARGETSLICE]:[FILESYSTEMTYPE]

The environment name will be the name of the second environment you are creating (solenv2 for e.g.).The default file system type is UFS. An example of the target slice would be /dev/dsk/c0t1d0s5.

When Enter is pressed you will see progress output similar to below:

Determining types of file systems supported
Validating file system requests
Preparing logical storage devices
Preparing physical storage devices
Configuring physical storage devices
Configuring logical storage devices
Analyzing system configuration.
Updating boot environment description database on all BEs.
Updating system configuration files.
The device </dev/dsk/c0t1d0s6> is not a root device for any boot environment; ca
Creating configuration for boot environment <solenv2>.
Source boot environment is <be0>.
Creating file systems on boot environment <solenv2>.
Creating <ufs> file system for </> in zone <global> on </dev/dsk/c0t1d0s6>.
Mounting file systems for boot environment <solenv2>.
Calculating required sizes of file systems for boot environment <solenv2>.
Populating file systems on boot environment <solenv2>.
Analyzing zones.
Mounting ABE <solenv2>.
Cloning mountpoint directories.
Generating file list.
Copying data from PBE <be0> to ABE <solenv2>.
100% of filenames transferred
Finalizing ABE.
Fixing zonepaths in ABE.
Unmounting ABE <solenv2>.
Fixing properties on ZFS datasets in ABE.
Reverting state of zones in PBE <be0>.
Making boot environment <solenv2> bootable.
WARNING: merged filesystem </opt> and merge point </>
have different mount point options <-> and <logging>.
Population of boot environment <solenv2> successful.
Creation of boot environment <solenv2> successful.

When you see the bottom two outputs, the next step is to upgrade using a image.

Make sure your chosen image is on the boot environment before using the below commands, The next step is to mount the iso so that it will be made bootable for live upgrade, a loopback file command will be used:

# mkdir /solCD
# lofiadm -a /path/to/iso/[ISOIMAGE]
  dev/lofi/1
# mount -F hsfs -o ro /dev/lofi/1 /solCD

The mounted file system type is hsfs (high sierra file system) as this is the standard logical File system used for CD-ROM. (basically making this ISO cd/dvd bootable).
The next step is to upgrade the newly created environment, specifying the auto registration file created early during the pre-requisites stage:

# luupgrade -u -k /path/to/autoregfile/[REGFILE] -n solenv2 -s /solCD/

You should see progress output similar to below:

64459 blocks
miniroot filesystem is <lofs>
Mounting miniroot at </solCD//Solaris_10/Tools/Boot>
#######################################################################
 NOTE: To improve products and services, Oracle Solaris communicates
 configuration data to Oracle after rebooting.
 You can register your version of Oracle Solaris to capture this data
 for your use, or the data is sent anonymously.
 For information about what configuration data is communicated and how
 to control this facility, see the Release Notes or
 www.oracle.com/goto/solarisautoreg.
 INFORMATION: After activated and booted into new BE <solenv2>,
 Auto Registration happens automatically with the following Information
oracle_user=
#######################################################################
Validating the contents of the media </solCD/>.
The media is a standard Solaris media.
The media contains an operating system upgrade image.
The media contains <Solaris> version <10>.
Constructing upgrade profile to use.
Locating the operating system upgrade program.
Checking for existence of previously scheduled Live Upgrade requests.
Creating upgrade profile for BE <solenv2>.
Determining packages to install or upgrade for BE <solenv2>.
Performing the operating system upgrade of the BE <solenv2>.
CAUTION: Interrupting this process may leave the boot environment unstable
or unbootable.
Upgrading Solaris: 100% completed
Installation of the packages from this media is complete.
Updating package information on boot environment <solenv2>.
Package information successfully updated on boot environment <solenv2>.
Adding operating system patches to the BE <solenv2>.
The operating system patch installation is complete.
INFORMATION: The file </var/sadm/system/logs/upgrade_log> on boot
environment <solenv2> contains a log of the upgrade operation.
INFORMATION: The file </var/sadm/system/data/upgrade_cleanup> on boot
environment <solenv2> contains a log of cleanup operations required.
WARNING: <1> packages failed to install properly on boot environment <solenv2>.
INFORMATION: The file </var/sadm/system/data/upgrade_failed_pkgadds> on
boot environment <solenv2> contains a list of packages that failed to
upgrade or install properly.

INFORMATION: Review the files listed above. Remember that all of the files
are located on boot environment <solenv2>. Before you activate boot
environment <solenv2>, determine if any additional system maintenance is
required or if additional media of the software distribution must be
installed.
The Solaris upgrade of the boot environment <solenv2> is partially complete.
Installing failsafe
Failsafe install is complete.

You can check the log files once you reboot into the new envirnonment. Once the install is complete, the next step would be to activate the environment so that we can boot into it after reboot:

# luactivate solenv2

Finally, reboot the system (make sure you take the default actions in regards to shutting down the machine, schedule downtime, save your work etc)

# shutdown –i6 –g0 –y

Once the system has been rebooted, perform the following command to see if your installation/upgrade has been successful

# cat /etc/release

Oracle Solaris 10 8/11 s10s_u10wos_17b SPARC
Copyright (c) 1983, 2011, Oracle and/or its affiliates. All rights reserved.
Assembled 23 August 2011

Optionally, Live upgrade gives the user the choice whether to fall back to the original environment perhaps if something goes wrong,

# luactivate [PRIMARYENVNAME]
# shutdown –i6 –g0 -y

Or when you are absolutely confident that the primary environment is not needed anymore you can delete it:

# ludelete [PRIMARYENVNAME]

NOTE: TO SEE THE LIST OF ENVIRONMENTS CONFIGURED ON THE MACHINE PERFORM THE FOLLOWING COMMAND:

# lustatus
Name                       Complete Now    On Reboot Delete Status
-------------------------- -------- ------ --------- ------ ----------
be0                        yes      no     no        yes    -
be3                        yes      no     no        yes    -
solenv2                    yes      yes    yes       no     -

Platform Engineering: Developer Experience

Intro The role of Platform Engineer as evolved through the ages. I’ve gone through all the names: Sys Admin, Infrastructure Engineer, DevOps...