Wednesday, 9 May 2018

TOGAF foundation exam tips and experience



I passed my TOGAF 9.1 foundation exam on 06th May 2018. In this article i am going to talk about my experience of the exam and how anyone looking to clear the TOGAF foundation exam should plan their study.

Preparation time and style

It took me about 2 months to prepare for TOGAF foundation exam. I read the TOGAF Foundation study guide cover to cover (its about 200 pages), the first time to slowly digest the information and the second time to quickly write down and memorize the key terminology. After the first reading i was not having much confidence and it all seemed like a deep blue sea. Thankfully after second reading and writing down the key concepts and terminolgy in my notes, it all started to sink in. Then i took the 2 practice exams which are part of the official study guide and consistently started scroing within range of 32-35 out of 40.

Honestly the content seemed boring during the first read but it got interesting after that and i started to visualize the Architecture development method. Also my work experience as a technical product owner helped in visualizing all this. Moreover, i am a visual learner so i guess that kicked in once i became familiar with the terms of EA.

Exam pattern

The exam is a MCQ based with 40 questions in total and duration of the exam is 1 hour. I got 31 out of 40 in the exam. Questions are not very lengthy and it took me about 25 minutes to complete the exam. The sentence and wording of the exam is quite simple and easy to understand even if you are not a native english speaker. I found it helpful to quickly scan through the questions at the same time answering those which i was 100% sure of. You can visit the questions later so that is not a problem.

Resources for practice

I found the TOGAF Foundation study guide to be more than enough for preparation. There was nothing out of this book and if you read it cover to cover you are likely to pass. There is no need to spend humongous amount of money on training or any other preparatory material apart from the official study guide.

Real exam experience

I found the questions on the real exam just a little bit more tricky than those in the study guide.
Also there were 2 or 3 tricky questions where i was confused. All in all, it is easy to pass if you have the ADM phases fully digested into your head.

Do not try for rote learning, rather try to understand logically why you should do a particular activity in a given phase of ADM. Ironically, it helps if you do not have much experience into EA as you come with little baggage of your own. That way, you follow TOGAF recommendation almost as a religion and because the exam expects you to answer the questions based on exactly how things will be handled in TOGAF.

Results

Exams are conducted by Pearson VUE and the results are not immediately available , unlike other Computer based tests (CBT). The test administrator told me it is due to security reasons and score card is shared by Pearson VUE with Open group and they validate the results , process it and then will trigger a mail to your registered email id. I got the final results within a day so no worries there.

Sunday, 12 April 2015

How to add a new node in a running Veritas Cluster instance



Steps for adding a new node in a running Veritas Cluster

1) Install the VCS depots on the new node with ‘-installonly’ option

# ./installvcs –installonly

2) Rename the startup scripts on all nodes as a precaution:

# mv /etc/rc2.d/S70llt /etc/rc2.d/s70llt
# mv /etc/rc2.d/S92gab /etc/rc2.d/s92gab
# mv /etc/rc3.d/S99vcs /etc/rc3.d/s99vcs

3) Modify /etc/llthosts, /etc/gabtab, /etc/llttab and /etc/VRTSvcs/conf/config/main.cf as required to show the new node. These modifications should be done on all nodes.

#vi /etc/llthosts
0 ggnqinta1
1 ggnqinta2

2 ggnqinta3


#vi /etc/llttab

Node1
set-node ggnqinta1
set-cluster 13
link lan1 /dev/lan:1 - ether - -
link lan2 /dev/lan:2 - ether - -

Node2
set-node ggnqinta2
set-cluster 13
link lan1 /dev/lan:1 - ether - -
link lan2 /dev/lan:2 - ether - -

Node3
set-node ggnqinta3
set-cluster 13
link lan1 /dev/lan:1 - ether - -

link lan2 /dev/lan:2 - ether - - 


# vi /etc/gabtab

/sbin/gabconfig -c -n 3

Caution : make sure the number of nodes is correctly reflected in the gabtab and 'set-node' is correct in /etc/llttab of each host or you will have problems.

4) Start GAB and LLT on the new node

# /sbin/rc2.d/S70llt start
# /sbin/rc2.d/S92gab start

5) Start the cluster on new node

# hastart

6) Add the new added system into configuration

 # hasys –add ggnqinta3

7) Save the configurtion

# haconf –dump makero

8) Move back the start scripts


# mv /etc/rc2.d/s70llt /etc/rc2.d/S70llt
# mv /etc/rc2.d/s92gab /etc/rc2.d/S92gab
# mv /etc/rc3.d/s99vcs /etc/rc3.d/S99vcs

9) The newly added node needs to be added in servicegroup configuration


# hagrp -modify SG SystemList -add ggnqinta3
# hagrp -modify SG SystemList -add ggnqinta3
# hagrp -modify SG SystemList -add ggnqinta3
# hagrp -modify SG AutoStartList -add ggnqinta3
# hagrp -modify SG AutoStartList -add ggnqinta3
# hagrp -modify SG AutoStartList -add ggnqinta3


Saturday, 10 January 2015

How to recover from a I/O error in VxVM



While working as a Unix Admin , many a times i have experienced critical issues with Veritas Volume Manager. Most of the times its a heart stopping moment when you hear something is wrong with your disk Storage subsystem. After all , your data sits on Veritas. I am sure any Unix Admin worth his salt will agree with me.

But the beauty of Veritas is its simplicity. It stores objects in a very structured and systematic fashion and if you work out the problem logically you can solve it.

Here i present a typical issue which is encountered with Veritas Volumes i.e filesystems becoming stale or unmountable after a sudden power-off or a sudden loss of connectivity from SAN or HBA card. Moreover this is a very useful question for interviews as well.

Veritas throws I/O error , dont worry vxmend comes to your rescue ...... just unmount the filesystem forcefully with a '-f' and run below commands in sequence.

Vxmend......
Force the plex to go off ( its already stale)

# vxmend -o force off <plex>

Bring it on again ....

# vxmend on <plex>

Clean the plex of any errors as shown below:-

# vxmend fix clean <plex>

Start the volume.

# vxvol start<volume>

Run a fsck as usual

# fsck -F vxfs/dev/vx/rdsk/<diskgroup>/<volume>

Now mount the filesystem, it should be back up in a sane manner.

# mount -F vxfs /dev/vx/dsk/<diskgroup>/<volume> /mountpoint

I have always found Veritas to be very robust and powerful. Just keep learning without fear and worries. Cheers ............................

Thursday, 20 March 2014

Nagios Remote Host Configuration



Nagios, as you might be knowing is an open source Host monitoring solution. The Nagios core is free and open source. If you need professional services and support you can go for Nagios XI.  You can check more details at 
Nagios website . 

The Basic Architecture is like this, we have a Nagios Remote Host and a Nagios Server. The Remote host has some services running on it which are to be centrally monitored from Nagios server and alert generated in case of any failure or impending failure. The Remote Host ( also known as Nagios Client) sends its service status to the Nagios Server via NRPE.(Nagios Remote Plugin Executer). NRPE lets you monitor variety of services like status of Oracle, HTTP website URL status, free disk space, CPU load among others.

Here i describe the method for setting up a Nagios Remote Host to be monitored from a Nagios Host. I assume you already have a running setup with Nagios Server properly configured and want to monitor the different services running on your Nagios Remote Hosts.

Lets begin .....

Steps to be performed on Nagios server:-

1. Go to the Nagios configuration directory and edit hosts.cfg file and enter the hostname and ip address of nagios remote host. This will make an entry for the particular host and is used to identify the remote host.

2. Most Nagios Administrators classify their Remote Hosts in various groups based on OS type (i.e Solaris, Linux,Windows etc) or based on Datacenter location name (i.e DC-US, DC-EU, DC-APAC). For this purpose, we need to edit hostgroup.cfg file and enter the hostname of the remote host (declared in previous step) in a particular hostgroup we want it to be (e.g Solaris-Group, Linux-Group or DC-APAC )

3. For the purpose of monitoring the various services, we need to edit services.cfg file and input the hostname of remote host to the corresponding service type. For example to monitor Oracle instance on a Database server, we need to enter the hostname of the server in Oracle-check service type definitions as shown below:-

define service{
        use                             generic-service
        host_name                       ggndb01, chndb02, hydoradb
        service_description             Oracle-Check
        is_volatile                     0
        check_period                    24x7
        max_check_attempts              10
        normal_check_interval           5
        retry_check_interval            3
        contact_groups                  nagios-admins,nagios-sms
        notification_interval           3600
        notification_period             24x7
        notification_options            w,u,c
        check_command                   check_nrpe!check_oracle



4. After making all required changes in the three files mentioned above, we need to reload the nagios service for the changes to take effect.

   #/usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
   #/etc/rc.d/init.d/nagios reload

The new configuration will be active on web interface now. Login to nagios and verify that the changes are reflected.

Steps to be performed on Remote Host (for NRPE)


Installation and configuration of NRPE on Nagios client (also called remote host) is a little tricky and involved procedure. Before proceeding further with the steps, please download nrpe and nagios plugins source code from Nagios website.

1. Create a nagios user who will communicate with Nagios server for sending service status details

 # useradd -c “nagios system user” -d /usr/local/nagios -m nagios
 # chown nagios:nagios /usr/local/nagios/

2. Extract the plugin and nrpe source code.

 # gunzip nagios-plugins-1.3.8.tar.gz
 # tar -xvf nagios-plugins-1.3.8.tar
 # gunzip nrpe-2.12.tar.gz
 # tar -xvf nrpe-2.12.tar

3. Compile the nagios plugins. These plugins can also be executed locally to check service status

 # cd nagios-plugins-1.3.8
 # ./configure
 # make
 # make install

4. Check whether the plugin are working fine or not. Remember this is a local check only and at this point of time, communication with Nagios server is not yet established.

 # /usr/local/nagios/libexec/check_disk -w 10 -c 5 -p /var

5. Compile the NRPE

 # cd nrpe-2.12
 # ./configure
 # make
 # make install

6. After compilation of NRPE on remote host is completed, nrpe.cfg file be generated. Modify the nrpe.cfg  file as per your needs. Remember this needs to located on the remote host and not on the Nagios server. All the checks which will be performed from Nagios server need to be entered into the remote host nrpe.cfg file. Example below:-

command[check_users]=/usr/local/nagios/libexec/check_users -w 5 -c 10
command[check_load]=/usr/local/nagios/libexec/check_load -w 15,10,5 -c 30,25,20
    
Enter all the checks to be performed like for check_disk, check_load, check_http and check_users into this file. Also we need to allow the nagios server to communicate with remore host in this file.
To enable the remote execution of NRPE add the IP address of Nagios server in nrpe.cfg :-
  
allowed_hosts=127.0.0.1,10.237.93.68

7. Configure the NRPE as a service in normal framework so that it can be started or stopped like other Unix services. Add the below line in /etc/services

 nrpe 5666/tcp # NRPE

8. Add the following line in /etc/inet/inetd.conf

   On Solaris
   nrpe stream tcp nowait nagios /usr/sfw/sbin/tcpd /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg -i
   On Linux
   nrpe stream tcp nowait nagios /usr/sbin/tcpd /usr/local/nagios/bin/nrpe -c /usr/local/nagios/etc/nrpe.cfg --inetd

9. On Linux systems we can start the nrpe service as follows
   # service nrpe start
   On Solaris systems
   # svcadm enable svc:/network/nrpe
   # svcadm restart svc:/network/nrpe


That's it. You can start monitoring your Remote hosts services from Nagios Server.


Monday, 17 March 2014

VCS Interview questions answers

1) What is split brain and amnesia prevention in cluster ?

2) Suppose one of the high-priority heartbeat connection between nodes is lost, what will be the condition of the cluster known as ? What action VCS will take in such a scenario ?

When one of the high-priority heartbeat connectivity between nodes is lost and there is only one remaining heartbeat link, VCS will place the node in a special membership category known as jeopardy membership.
In such case, VCS will autodisable the SG amd the servicegroup state will not change i.e offline or online servicegroups continue to be in that state. VCS  prevents any failover from happening to prevent data corruption.
3) During patching if we want to stop a servicegroup from failover, what actions we will take ?
It is a best practice to freeze a servicegroup during server patching activity. When you freeze a Group, VCS will take no action on that Group or its Resources. It will not try to bring the servicegroup online on any other node.  After the maintenance is over, you can bring the resources online and VCS will refresh its view at that time.

4) How do you check logs of a servicegroup and a resource in VCS ? How will you troubleshoot if a resource has faulted ?
The default VCS log directory is /var/VRTSvcs/log
The main event log of VCS is /var/VRTSvcs/log/engine_A.log. This file is the best place to begin troubleshooting for a failed resource.
Individual agent types have their own log files e.g Mount_A.log , Apache_A.log or Weblogic_A.log. These log files contain more  detailed info than the engine_A.log.

Checking for the word 'clean' can provide clues related to the cause of failure.

5) What is the main purpose of llt and had daemons ?
LLT is the transport mechanism of VCS and is responsible for load balancing of cluster communications and maintaining heartbeat. HAD is the main VCS deamon and is responsible for taking operator input and performing the relevant actions. HAD also takes all types of corrective actions required.

6) What are the difference between LLT and GAB ?
LLT and GAB purpose and differences
LLT is the layer 2 protocol developed by Veritas. It takes care of the heartbeat connection and is a carrier.
GAB distributes the cluster config among nodes. GAB uses LLT as its tranport mechanism for distributing cluster configuration changes.
HAD communicates with GAB and maintains / tracks all cluster configuration. Uses main.cf file to build cluster config. HAD also takes all types of corrective actions required.

7) What is the difference between high priority and low priority link in VCS ?
High priority link is used for transmitting cluster communication and configuration information between nodes and to GAB as well as for heartbeat communications.
Low priority link is used only for heartbeat in normal scenario, but in case of failure of high priority link it can take over the task of transmitting cluster communication also.

8) What are the components in VCS i/o fencing setup ?
Following are the components required for IO fencing in VCS
i)    Coordinator diskgroup with 3 disks
ii)    Data diskgroup
iii)    Dynamic multipathing software (VXDMP)

9) What is a Jeopardy condition in VCS ? What happens to the ServiceGroup and Resources running on a system which is under Jeopardy condition ?
Jeopardy membership condition occurs when a node in a cluster is having only one heartbeat connection remaining with the rest of the cluster. At this point, VCS cannot reliably distinguish between a node failure or network failure if the last heartbeat interconnect also fails. Hence under jeopardy condition, VCS prevents the ServiceGroup from failover. The Applications and ServiceGroup running on the node keep on running as usual and will not be failed over in case of a Node failure. But in case of a resource or group fault, the ServiceGroup fails over to available systems in the cluster. This is a safety mechanism to prevent data corruption.

10) During RACE condition for membership arbitration in case of a node or link failure, how VCS will determine the eligible host for aquiring the lock on co-ordinator disks ? Which sub-cluster will win the RACE and based on what logic ?
During a RACE condition, the partitioned nodes will form a sub-cluster and try to acquire the co-ordinatore disks. Among the nodes in the sub-cluster , the node with the lowest LLT ID will run for the RACE on behalf of itself and other nodes in sub-cluster. If it is successful it will eject keys of other systems (i.e nodes which are not part of the newly formed sub-cluster) from the co-ordinator disks and send a WON_RACE communication to nodes in its sub-cluster. Other nodes which fail to acquire the disks will panic.

Sunday, 24 November 2013

VxVM interview questions

1)    Can you reduce a FS in VxVM ? What is the risk involved ?
There are a few risks and issues involved while reducing a Filesystem in VxVM.
1.1)    UFS volumes  cannot be shrunk, only grow operation is permitted.
1.2)    VxFS volumes  must be mounted for grow and shrink operation, if it is unmounted no operation can be performed
1.3)    You cannot resize a volume that contains plexes with different layout types ( e.g concat and stripe). Attempting to do so results in the following error message:
              VxVM vxresize ERROR V-5-1-2536 Volume volume has different
               organization in each mirror
 

To resize such a volume successfully, you must first reconfigure it so that each data plex has the same layout type.

2)    What is the role of vxconfigd daemon ?
vxconfigd daemon handles all configuration management tasks for VxVM objects. It maintains disk and disk group configuration details, communicates configuration changes to the kernel, and modifies the persistent configuration information stored on disks
 vxconfigd provides the interface between VxVM commands and the kernel device drivers.
 vxconfigd handles   configuration change requests from VxVM utilities, communicates the change requests  to the VxVM kernel, and modifies configuration information stored on disk.
 vxconfigd also initializes VxVM when the system is booted.
 

So practically any command which changes the configuration of VxVM objects (plexes, volumes) interact with vxconfigd daemon.

3)    Where is the diskgroup configuration information is stored in VxVM ?
The DG configuration info is stored in /etc/vx/cbr/bk directory. Last 5 configuration changes are stored.


4)    What is stored in privlen of a VxVM disk ? Do all the disks of a diskgroup have the same information in their private region ?
The private region of a vxvm disk stores disk header label and configuration information about vxvm objects such as volumes,plexes and sub disks.
 

Yes, each  disk in a diskgroup stores an entire copy of the configuration information.

5)    Can you import a DG with incomplete set of disks ?
Yes, If some of the disks in a Diskgroup have failed , you can import the DG using –f option
# vxdg –f import diskgroup


6) How will you replace a faulty disk in VxVM ?
A disk which has failed can be seen from the output of vxdisk list command. The disk device ctd will be missing from the output and it can be seen as failed was :c#t#d#. This confirms that the disk has indeed failed.
We can use vxdiskadm menu options to replace the faulted disk. Choose option 5 from the men , then list the failed disk using 'list' option. We would have to choose an alternate disk for the replacement. The list of available disks is also shown by vxdiskadm. Press 'y' and complete the replacement activity.

Tuesday, 19 November 2013

Solaris Interview Questions

1) Can you reduce a FS in VxVM ? What is the risk involved ?
2) What are branded zones in solaris ?
3) What is the main enhancement in NFS v4 over v3 ?
4) How can we refresh automount config without affecting connected users ?
5) How many types of automount maps are there ?
6) How can you patch a solaris zone which is a sparse root ?

7) What is the difference between zone and container in Solaris ?
8) How can we assign zpool to NGZ ?
9) How thin provisioning / sparse volume is created in ZFS ?


10) Suppose after a power outage or a mistake by storage admin, one of your LUN in VxVM was unavailable and now it has become available again. But your mountpoint is throwing I/O error. How will you resolve this situation ?
11) What are the advantages of using ZFS instead of UFS ?
12) Which is better hardware  RAID or software RAID ? why ?
13) After a power outage or kernel panic ZFS pool is not getting imported ? What are the steps for troubleshooting this ?
14) Which virtualization solution would you recommend to customer LDOM or zones ? under what scenario and considerations ?
15) Suppose you have a low memory condition on solaris server . How will you troubleshoot further ?
16) What is the change in regards to network configuration in Solaris 10 over Solaris 8 ?

17) How can you restore LDOM configuration ?
18) How can we clone LDOM ?
19) Which field of iostat indicates a IO bottleneck ? What are the important metrics to be looked at in iostat output ?
20) In maintaining Solaris security what are the common steps / procedures followed by System Admins ?
21) In Solaris we have resource pools ( rpool ). We can assign rpools to zones as well to set cpu shares. Then why do we need resource controls in zones ( add rctl ) . What is the advantage of using resource controls when resource pooling is already there ?
22) How to install multiple patches in a single patchadd invocation ?   

Monday, 18 November 2013

VCS VXVM DiskGroup switchover example



Step 1:- Start the desired haagent ( DiskGroup) on both the machines.

client1: /tmp/vcs> haagent -start DiskGroup -sys client1
client1: /tmp/vcs> haagent -start DiskGroup -sys client2

Step 2:- Add the servicegroup and populate the SystemList.

client1: /tmp> haconf -makerw
client1: /tmp> hagrp -add DG_servicegroup
VCS NOTICE V-16-1-10136 Group added; populating SystemList and setting the Parallel attribute recommended before adding resources
client1: /tmp> hagrp -modify VG_servicegroup SystemList client1 1 client2 2

Step 3:- Add the resource, specify the type of the resource and assign it to a servicegroup, enable the resource, specify the Disk Group name etc and bring the resource online.

client1: /tmp> hares -add VXVMDG DiskGroup DG_servicegroup
VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
client1: /tmp> hares -modify VXVMDG Enabled 1
client1: /tmp> hares -modify VXVMDG DiskGroup clusterdg
client1: /tmp> hares -modify VXVMDG StartVolumes 1
client1: /tmp> hares -online VXVMDG -sys client1

Step 4:- Add a ‘Mount’ resource type named clustervol ( or whichever name it is easy to identify with ), specify the correct blockdevice name, FS type, mountpoint and fsck option. Enable and bring the resource online.

client1: /tmp> hares -add clustervol Mount DG_servicegroup
VCS NOTICE V-16-1-10242 Resource added. Enabled attribute must be set before agent monitors
client1: /tmp> hares -modify clustervol BlockDevice /dev/vx/dsk/clusterdg/clustervol
client1: /tmp> hares -modify clustervol FSType vxfs
client1: /tmp> hares -modify clustervol MountPoint /clustervol
client1: /tmp> hares -modify clustervol FsckOpt %-y
client1: /tmp> hares -modify clustervol Enabled 1
client1: /tmp> hares -online clustervol -sys client1

Step 5 :- Link the two resources i.e “DiskGroup and Mount” and enable resources contained with the servicegroup.

client1: /tmp> hares -link clustervol VXVMDG
client1: /tmp> hagrp -enableresources DG_servicegroup
client1: /tmp> hagrp -online DG_servicegroup -sys client1
client1: /tmp> haconf -dump –makero
client2: /tmp> mkdir /clustervol
client1: /tmp> hagrp -switch DG_servicegroup -to client2

Friday, 15 November 2013

Extended process list in Solaris 10 and HPUX, without truncated lines



Some processes typically have a very long list (more than 1000 characters) with command line arguements  and ps –ef | grep <pid> will show only one line (max 80 characters). Both solaris and hpux have extensions through which we can view the full command line, without truncation.


To retrieve the full process list for a process by running ps

on Solaris :-
/usr/ucb/ps –agxuwwwww PID

On HPUX :-
ps –exx

Tuesday, 12 November 2013

Installing HP-UX clients from Golden Image

      


A Golden Image is a compressed archive of a current system. It contains all the software and hardware configurations on the existing system. This can be deployed to clients on the network who have similar hardware configurations.

Steps to clone a client using Golden Image.

 1. Edit the .rhosts file of the Ignite-UX server as well as client so that we can directly store the archive onto the server and reboot the client from the server directly for installation later on.

[ignite-server]# cat /.rhosts
10.237.93.112               root


2. Use the following directory for storing archives

[ignite-server]#pwd
/var/opt/ignite/archives


3. Add the following directories to the list of NFS-exported directories

[ignite-server]# vi /etc/exports

/var/opt/ignite/clients -anon=2
/var/opt/ignite/archives –anon=2
 
 
[ignite-server]#exportfs –av
 
 
 
4. From the client machine we will be running make_sys_image script so that the archive is stored on Ignite server at /var/opt/ignite/archives
 
[client]# pwd
/opt/ignite/data/scripts
[client]#./make_sys_image –s 10.237.93.115 –d /var/opt/ignite/archives 
 
    - where 10.237.93.115 is IP of Ignite server.
 
 
5. Once the archive creation is complete, from the Ignite-UX server we can edit our configuration file to reflect the changes we want to make.
We will copy the example file provided by HP to the directory where we will store our other configuration files.
 
[ignite-server]# cd /opt/ignite/data/examples
[ignite-server]# cp core11.cfg /var/opt/ignite/data/Rel_B.11.31/archive11.cfg
 
 
6. While creating Golden Image we need to manully calculate the archive_impact and the output will help us in deciding the size of mountpoints.
 
[ignite-server]#pwd
/var/opt/ignite/archives
[ignite-server]#ls
ggntest1.gz
[ignite-server]#/opt/ignite/lbin/archive_impact –t –g /var/opt/ignite/archives/ggntest1.gz > /tmp/GOLDEN.impacts
 
 
 
7. We can use the impact statements generated to edit our config files. The  file archive11.cfg is very critical and edit it very carefully.
 
[ignite-server]# vi /var/opt/ignite/data/Rel_B.11.31/archive11.cfg
 
........
 
 things to note here in this file are
 
 nfs_source = “10.237.93.115:/var/opt/ignite/archives”
 archive_path = “ggntest1.gz”
 
  - the archive_path is relative to the nfs_source specified earlier in the file. This file will be transferrd via nfs to the client. Also check the permissions on the archive file (755) otherwise ignite will throw a lot of errors.
 
post_load_script = "/opt/ignite/data/scripts/os_arch_post_l"
post_config_script = "/opt/ignite/data/scripts/os_arch_post_c"
 
These two scripts are also run to ensure that installation is complete.
 
All the impacts have to be filled up using the file generated previously.
 
impacts=”/” 2048000Kb
impacts=”tmp” 6144000Kb
.
.
 
 
 
8. Use the save_config command to create a configuration file for disks and hardware configuration (e.g hardware paths ). 
 
[client]# save_config -f /tmp/save_config.out vg00
 
Copy this over to the ignite server.
 
[client]#rcp /tmp/save_config.out 10.237.93.115:/var/opt/ignite/data/Rel_B.11.31/archive_disk.cfg
 
The file archive_disk.cfg contains hardware paths and entire volume group related information. Edit this file to reflect all the required customizations. If the client being installed is not of similar hardware configuration , then installation might fail.
 
 
 
9. In the INDEX file we need to create an entry for Golden Image so that it shows up at client config window and we can point to it while booting the client. We need to add the path to our custom configuration files so that these files are read while booting clients.
 
 Add the following lines below the default entries.
 
[ignite-server]#vi /var/opt/ignite/INDEX
.
.
cfg "Golden Image" {
 
        description "HP-UX B.11.31 Golden Image"
 
        "/var/opt/ignite/data/Rel_B.11.31/archive11.cfg"
 
        "/var/opt/ignite/data/Rel_B.11.31/archive_disk.cfg"
 
        "/var/opt/ignite/config.local"
 
}
 
 
 
 
 
10. Check the files for syntax errors as follows
 
[ignite-server]# instl_adm –T
       * Checking file: /opt/ignite/data/Rel_B.11.11/config
       * Checking file: /opt/ignite/data/Rel_B.11.11/hw_patches_cfg
       * Checking file: /var/opt/ignite/config.local
       .
       * Checking file: /opt/ignite/data/Rel_B.11.31/config
       * Checking file: /opt/ignite/data/Rel_B.11.31/hw_patches_cfg
       * Checking file: /var/opt/ignite/data/Rel_B.11.31/archive11.cfg
       * Checking file: /var/opt/ignite/data/Rel_B.11.31/archive_disk.cfg
 
[ignite-server]#manage_index –l
HP-UX B.11.11 Default
HP-UX B.11.23 Default
HP-UX B.11.31 Default
Golden Image
 
As our Golden Image is showing up in the index, we can boot the client and point it to install from the configuration.
 
11. Boot the client from the ignite server by using the following command.
 
[ignite-server]#bootsys –i “Golden Image” –f client
 

  
  
  
  
  
  
  
  
  
  
  
 
 
 

 
 
 
 
 
 
 
 


Procedure for installing Ignite-UX clients over the network




1. For setting up the ignite server, the Ignite-UX server should have the following entry

    in /etc/exports file.

     /var/opt/ignite/clients –anon=2

2.  Check the config files with this command.

      instl_adm –T

    The config files should be world readable. If they are not instl_adm –T will notify the

      error.

     The config files required are as follows:

      /opt/ignite/data/Rel-B.11.11/config

      /opt/ignite/data/Rel-B.11.11/hw_patches_cfg

      /var/opt/ignite/config.local


 3.  The /etc/inetd.conf file should have the following settings for tftp and instl_boots.


      tftp        dgram  udp wait   root /usr/lbin/tftpd    tftpd\
        /opt/ignite\
        /var/opt/ignite

       à  The tftp service should have access to /opt/ignite and /var/opt/ignite so that it can

              tranfer files using tftp during installation.

    
      instl_boots dgram udp wait root /opt/ignite/lbin/instl_bootd instl_bootd


  4.    The /etc/opt/ignite/instl_boottab file should have the following entry

         corresponding to each host that we want to boot using Ignite-UX server.

           <IP-address>:<Mac-address(with leading 0x)>::


   The last field should be left blank as it is automatically updated by Ignite-UX server

   when it receives a request for installation from the client corresponding with the MAC

   - address mentioned in the file.




Note -  The tftpd and instl_bootd deamon are started by the Ignite-UX server when it

              receives a request for installation. Do not try to start these deamons manually.


5.  After this reboot the client and interrupt the boot process to stop it at BCH> prompt.

    From the BCH> prompt type sea lan install to search for the ignite server.

     The o/p will be similar to the following.



Main Menu: Enter command or menu > sea lan install

 Searching for potential boot device(s) - on Path 0/1/2/0
     This may take several minutes.

To discontinue search, press any key (termination may not be immediate).


                                                                                                                 IODC
   Path#  Device Path (dec)  Device Path (mnem)         Device Type        Rev
   -----  -----------------  ------------------  -----------               ----
   P0            0/1/2/0                      lan.10.237.93.115      LAN Module         4          


  

   This means that the server is giving a valid offer for installation.


6.   Next type the following command to boot from the server.

     BCH> boot lan.10.237.93.115 install

   After this the installation procedure is similar to normal procedure for HP-UX

    installation . Carefully select the recovery archive from which OS needs to be installed

   if there are more than one image.



      

Procedure for creating Ignite-UX recovery archive over the network




1.  Determine the archive server and archive path where you want to store your Ignite recovery archive. This server can be different from the Ignite-UX server used for booting clients over the network or it can be the same server as well.
                  The archive path should be NFS exported before executing the make_net_recovery command because it is NFS mounted on the Ignite-UX client before archive creation. The archive is then tranferred via tar to the NFS mounted directory of archive server.

 For example, if the archive path on archive server is /u01/my_archives/<Hostname> then the /etc/exports file on archive server should have the following entry.

/u01/my_archives/<Hostname> -anon=65534,async,root=<Hostname>

  where <Hostname> denotes the hostname of the ignite client.


2.  After editing /etc/exports file , run exportfs –av .

3.  Run the following command on archive server.

     chown bin:bin /u01/my_archives/<Hostname>

4.  To create the network recovery archive, run the following command on  Ignite-UX client.

make_net_recovery –Av –a <archive-server>:<archive-path> -s <Ignite-UX_server>

where  A = for including all the files from the PV/disk that contains  root Volume Group.

            v = for verbose mode.

            a = for specifying the archive server.

            s = for specifying the Ignite-UX server.


5.  The log file of archive creation can be found at

/var/opt/ignite/clients/<Hostname>/recovery/<Date,Time>/recovery.log










                       

Tuesday, 24 September 2013

Vskills certification on Cloud Computing

Recently completed a certification on cloud computing from Vskills. It is a vendor neutral certification and gives a good overview of all available cloud offerings. The study material starts by explaining the evolution of Cloud computing.right from Mainframes , Distributed and Virtualization eras.

As you might already know, over the last decade virtualization techniques have come of age and commodity hardware has also matured. Customers whose main focus is not IT, feel burdened by IT overhead costs like manpower requirements, Datacenter up keep, power requirements etc. They wish they could offload these tasks and focus on main business. Organisations also typically want quick deployment and QA times and do not want to go through the whole process of requirement gathering from teams, discussing with vendors sales team , placing order , server delivery and installation. They want to use IT as a utility.

Given below are common cloud service models:-
IaaS – Infrastructure as a Service , refers to offerings from cloud vendors providing Compute, Network and Storage. It is customer's responsibility to install OS, Database or Apps, Manage security and patching. Customer has full flexibility in this model.
PaaS – Platform as a Service, where cloud vendor provides  pre-installed OS images along with Database / Apps, Security Tools etc. Customer installs own software and starts using the instance.
SaaS – Software as a Service, where end product softwares are provided by vendor like E-mail / messaging, Sales Dashboard, Blog Hosting, HR Payroll, Training Module etc. Customer has least flexibility in doing customization under this model.

The certification also introduces you to popular cloud offerings which are listed below:-

Commercial Cloud offerings
Amazon AWS – The market leader in Cloud space, offers IaaS and PaaS services like Amazon EC2, S3, Redshift, Beanstalk.
Google – Provides PaaS as Google App Engine and SaaS in form of Google Apps.
Microsoft Azure – Offers PaaS and IaaS services.
Salesforce – Popular as a SaaS service, provides sales collaborative tool known as The Sales Cloud.
Microsoft Office 365 – Provides MS office and other business productivity tools. It is a SaaS service.



Open source cloud offerings
Cloud Foundry – Developed by and hosted on VMware platform, offers MongoDB , MYSQL etc as PaaS offering.
OpenStack – IaaS project under Apache License, supported by companies like AMD, Brocade, SUSE Linux, Red Hat, Vmware, Yahoo, HP, IBM,Intel, Rackspace, Cisco, EMC among others.
Eucalytus – AWS compatible open source software for building private and public clouds.
Ubuntu One – File Synchronisation and backup platfrom.

The exam also had some scenario based questions on Amazon AWS. There were total 50 questions to be answered in 60 minutes timeframe.

Overall it was a good experience and i strongly recommend this certification for beginners and those who do not have any cloud experience and those who want to learn more about cloud computing. Clearing this exam would give you the confidence to study more on Amazon AWS and will act as a baby step for future accomplishments.
The certification cost is 3000/- INR. You can visit the vskills website at www.vskills.in/certification/

















Thursday, 13 June 2013

Unix / Solaris Password Expiration Automated email notification

I have been entrusted with setting up a mail alert system for user password expiration. The user should automatically get intimated through mail a few days before his password expiration date. I wrote a small script by taking help from www.unix.com and other forums.
Below is the script for checking the age of the password and alert the user if password is going to expire in next 15 days.

Script Name  :- /usr/bin/solchage

---script start here----

#!/usr/bin/bash
umask 0022
PATH=/usr/bin:/usr/sbin
SHADOW=/etc/shadow
DSHADOW=/etc/shadow.dummy
USER=$1


# Copy the contents of /etc/shadow to a dummy file and make sure the entries for system  
# users are not there in the dummy file. Also replace the encrypted password field with      
# *LK* to make sure passwords are not visible or cannot be copied by someone else.

cat ${SHADOW} | egrep -v "root|daemon|etc" | awk -F: '{print $1,"*LK*",$3,$4,$5,$6,$7,$8}' | sed 's/ /:/g' > ${DSHADOW}

PASSWDFILE=/etc/passwd

# Specify the mail domain of your company here.
DOMAIN=xyz
.com

# The next line extracts the users email id from GECOS field of /etc/passwd file. So as a pre # requisite to running this script, you must enter the email id of the user, without the            # domain name, in GECOS field as i have assumed here. Let me know if you can think of a
# more elegant way of extracting this information.

EMAIL=`grep ^${USER} ${PASSWDFILE} | awk -F: '{print $5}'`

# Save the message in a file.
FILE=/tmp/msg.$$


# Set the password policy here, i.e the number of days after which user must change              # password.
PWPOLICY=90

# Set the warning period here.
WARN=15


# Calculate the number of seconds elapsed since Jan 1 ,1970 i.e Unix epoch.

EPOCH=`perl -e 'print time;'`


# Convert the number of seconds into days.

DAYSEPOCH=`expr ${EPOCH} / 86400`


# Calculate the number of days since password was changed for the last time for a particular # user. This info can be extracted from 3rd field of /etc/passwd file. This is expressed as
# the number of days between January 1,  1970, and  the  date  that  the  password was last
# modified.


LASTCHG=`grep ^${USER} ${DSHADOW} | awk -F: '{print $3}'`



# Subtract the above value from the number of days since epoch to arrive at the number    #  of days since last password change. 

PASSWDCHANGE=`expr ${DAYSEPOCH} - ${LASTCHG}`


EXPIRED=`expr ${PWPOLICY} - ${PASSWDCHANGE}`


if [ "${EXPIRED}" -lt "${WARN}" ]; then

cat > ${FILE} <<EOF
Dear ${USER},

Your password will expire in ${EXPIRED} days. Please change it as soon as possible.
EOF


mailx -s "Password expiring soon." ${EMAIL}@${DOMAIN} < ${FILE}

fi--- script end here---

To run the above main script, you have to run another small script which i produce below.
Copy the above script and place it under /usr/bin and name it solchage. Ofcourse you can give it another name, its upto you but make corresponding changes in below script as well if you do so.

Lets name the second script as /var/pwexpire.sh. So put this script in crontab for execution once everyday. It will run for all users, and send them a mail if their password is going to expire within 15 days.

Script Name:- /var/pwexpire.sh

--- script begin here ---


cat /etc/passwd | egrep -v "root|daemon|etc|sys|adm|lp|uucp|nuucp|smmsp|listen|gdm|webservd|postgres|svctag|nobody|noaccess|nobody4" | awk -F: '{print $1}' | egrep -v "bin" | xargs -I {} /usr/bin/solchage {}

---script end here---


What the above script does ? Let us examine step by step.

1) It reads /etc/passwd file and cuts out system users from the list
2) Then prints the remaining usernames using awk and removes all other entries except first filed from the output.
3) Then xargs executes our script /usr/bin/solchage one by one for every listed user. This is required because the our script takes username as argument ( see USER=$1 above ) and runs for that particular user.

You will have to give execute permissions to both the scripts.