Saturday, May 11, 2013

How to apply ACL (Access Control List) for a file?


What is ACL (Access Control List)?


We all know that by default every file contains permissions for the owner, group and other(world). If we want to set something like read only for 1 user, read/write for a group, read/write/execute for another set of users for a particular file, then We can use ACL.


We can use the below commands to do the ACL for a file.

aclget  - To display ACL for a file
acledit - To edit the ACL for a file
aclput  - To set the ACL for a file using a ACL control file

Few examples,

Let us take file1 as the target file.

To display the current ACL values for file1,
# aclget file1

To edit the ACL for a file,  (How to apply acl for a file)
# acledit file1

This will open a editor with ACL values showing some values like below

attributes: SUID
base permissions:
   owner  (frank): rw-
   group (system): r-x
   others        : ---
extended permissions:
   disabled

If you want to enable and set ACL values, just change the stanza "extended permissions" like below

attributes: SUID
base permissions:
   owner  (frank): rw-
   group (system): r-x
   others        : ---
extended permissions:
enabled
       permit    rw-    u:user1
       deny      r--    u:user2, g:group1
       permit    rw-    g:user3, g:group2


Wednesday, May 8, 2013

How to perform the VIO Migration using NIM?


How to perform the VIO Migration using NIM? 


The key prerequisites to perform the migration are:


•        The system must be managed by HMC version 7 or later
•        The virtual IO server must be at least at version 1.3.
•        The physical volume for rootvg must be assigned to the VIO


Below steps can be done at anytime before VIOS Migration:

          #mount nim_master:/images /mnt/
          #backupios -file /mnt/<hostname>/`hostname`.mksysb_date -mksysb
          #viosbr -backup –file /mnt/<hostname>/`hostname`.viosbr
          
Take the configuration files like lsmap,lspv,lspath ....for our future reference. 


Create the resource for your VIO on NIM Server
         
          VIOS_MIG_21_lpp          resources       lpp_source
          VIOS_MIG_21_spot         resources       spot


Define the machine using ---> "smitty nim_mkmac"

Prepare the nim master for installaiton ---> "smitty nim_bosinst"


Steps to Migrate the VIOS:

Note: Make sure all the client LPAR related to the VIOS are shutdown.

Step 1: Shutdown the VIOS Partition and Activate the VIOS Partition in SMS mode via HMC.
Step 2: From the SMS menu on the console, follow this procedure:


SMS - SYSTEM MANAGEMENT SERVICES -

1. Select Language
2. Change Password Options
3. View Error Log
4. Setup Remote IPL (RIPL (Remote Initial Program Load))
5. Change SCSI Settings
6. Select Console
7. Select Boot Options


4. Setup Remote IPL (RIPL (Remote Initial Program Load))

Next you’ll have a selection of adapters to use. Select your adapter that corresponds to the adapter/host you defined in NIM. You will not see “ent0/ent1...etc” options. You will however see the hardware addresses and slots.

We then are brought to 3 options :
1. IP Parameters
2. Adapter Configuration
3. Ping Test

Chose the option 1 to set the IP Parameters

Now we need to set our IP Parameters.
1. Client IP Address [###.###.###.###]
2. Server IP Address [###.###.###.###]
3. Gateway IP Address [###.###.###.###]
4. Subnet Mask [###.###.###.###]

After setting the IP Addresses use ‘M’ to return to the main menu. You typically do not want to go into the “Adapter Parameters” (option 2 on the previous screen) to change the adapter parameters or disable spanning tree.

Also, with the Ping Test.... 

With our IP Parameters set we should now be back at the main menu.
 

SMS - SYSTEM MANAGEMENT SERVICES -
 
1. Select Language
 
2. Change Password Options
 
3. View Error Log
 
4. Setup Remote IPL (RIPL (Remote Initial Program Load))
 
5. Change SCSI Settings
 
6. Select Console
 
7. Select Boot Options
 

Now we’re ready to select our boot device.
 
7. Select Boot Options
 

The next menu should come up :
 
1. Select Install or Boot Device
 
2. Configure Boot Device Order
 
3. Multiboot Startup
 

You can take either option 1 which will make this a 1 time boot device selection,
.
1. Select Install or Boot Device

Select Device Type :
1. Diskette
2. Tape
3. CD/DVD
4. IDE
5. Hard Drive
6. Network
7. List all Devices

select : 

7. List all Devices

The system will go out for you and scan itself to determine which devices are available to boot from. All of your available boot devices will be displayed here. The menu can be a little tricky here. If you have a device pre-selected it will have a 1 next to it under the “Current Position” column. Use the “Select Device Number” listing to choose the device you want to boot from.

The next screen will offer you three choices :
1. Information
2. Normal Mode Boot
3. Service Mode Boot

Select :
2. Normal Mode Boot 

It shouldn’t really matter if you select normal or service mode, I always select normal mode.  Finally it asks if you’re sure you want to exit from SMS. Select ‘yes’ and let the boot go.

What you SHOULD see :
You’ll likely see a brief splash screen then the bootp request attempt.
Ideally you’ll see something like :
BOOTP : S=1 R=1

Which indicates it sent and received a request successfully. 


once the migration done, you will get a login prompt.  Follow the below for confirm the successful VIO migration.


$ ioslevel   
$ lsmap -all 
$ lstcpip

-------------------------------------------------------------------------------------

For updating the VIO server (For example: 2.1 to 2.2)

$ updateios –commit    (To confirm that there are no uncommitted updates)
$ updateios -accept -install -dev /vio_update_package    (To update the vio)



Tuesday, May 7, 2013

How to Setup SEA Failover on DUAL VIO servers?


How to Setup SEA Failover on DUAL VIO servers?



What needs to be done?


Each SEA must have at least one virtual Ethernet adapter with the “Access external network” flag (previously known as “trunk” flag) checked. This enables the SEA to provide bridging functionality between the two VIO servers.

Note:  SEAs has the same PVID, but will have a different priority value.

Control Channel:

An additional virtual Ethernet adapter , which belongs to a unique VLAN on the system, is used to create the control channel between the SEAs, it must be specified in each SEA when configured in ha_mode. 

The purpose of this control channel is to communicate between the two SEA adapters to determine when a fail over should take place


Limitation:


SEA Failover was introduced with Fixpack 7 (Virtual I/O server version 1.2), so both Virtual I/O Servers need to be at this minimum level.

Steps:


Create the Virtual ethernet adapter with the following option on the VIOS1.

virtual adapter a unique (Port Virtual LAN ID) VLAN ID (PVID): "1"
Check the box "access external network".
Give the virtual adapter a low trunk priority. EX: "1"
mkvdev -sea ent0 -vadapter ent2 -default ent2 -defaultid 1 -attr ha_mode=auto ctl_chan=ent3

Create the Virtual ethernet adapter with the following option on the VIOS2

virtual adapter the same VLAN ID (PVID) as VIOS1. EX: "1"
Check the box "access external network".
Give the virtual adapter a higher trunk priority. EX: "2"
mkvdev -sea ent0 -vadapter ent2 -default ent2 -defaultid 1 -attr ha_mode=auto ctl_chan=ent3


Create the Virutal ethernet adapter for control channel with the following option on the both VIOS1 and VIOS2.
Give this new virtual adapter another unique VLAN ID (PVID) EX: "99"
Do NOT check the box "access external network".
Shutdown, Activate VIOS2 or run cfgdev from VIOS command line if created with DLPAR.


Manual SEA Failover On VIO server:

Scenario 1:

$ lsdev -type adapter
or 
$ oem_setup_env 
# lsdev -Cc adapter |grep ent --> Note which ent is the SEA 
# entstat -d entX | grep State --> Check for the state (PRIMARY, or BACKUP)

Set ha_mode to standby on primary VIOS with chdev command:

# chdev -l entX -a ha_mode=standby
or
$ chdev -dev -attr ha_mode=standby

Reset it back to auto and the SEA should fail back to the primary VIOS:

# chdev -l entX -a ha_mode=auto
or
$ chdev -dev -attr ha_mode=auto


Scenario 2, Primary VIOS Shutdown

Reboot the primary VIOS for fail over to backup SEA adapter.
When the primary VIOS is up again, it should fail back to the primary SEA adapter.

Scenario 3, Primary VIOS Error

Deactivate primary VIOS from the HMC for fail over to backup SEA adapter.
Activate the primary VIOS for the fail back to the primary SEA adapter again.

Scenario 4, Physical Link Failure

Unplug the cable of the physical ethernet adapter on primary VIOS for the failover to the backup VIOS.
Replug the cable of the physical ethernet adapter on primary VIOS for the failback to the primary VIOS.

Scenario 5, Reverse Boot Sequence

Shut down both the VIO servers.
Activate the VIOS with backup SEA until the adapter becomes active.
Activate the VIOS with primary SEA. The configuration should fail back to
the primary SEA. 


Saturday, March 9, 2013

How to add a hot swappable PCI adapter to AIX server?


How to add a hot swappable PCI adapter to AIX server?

Step 1:  Login into root via the hmc or if vio server padmin, oem_setup_env to go up to root.

Log into the server you wish to add the adapters to. You will need root or padmin when adding to a VIO server. If logging in as padmin do a oem_setup_env to get to the root prompt.

Step 2:  Diag

Step 3:  Task Selection (Diagnostics, Advanced Diagnostics, Service Aids, etc.)

Step 4:  Hot Plug Task

Step 5:  PCI Hot Plug Manager

Step 6:  Add a PCI Hot Plug Adapter

Step 7:  Pick the right location verifying your serial number of the server and correct slot.

Step 8:  After picking the location of the card (as performed in above step 7), the card selected will begin to flash on the back of the server. Verify that the correct slot is linking visually.

Step 9:  If the slot is correct, hit return only once, and let onsite facilities install the card. Once they have installed the card and turn it back over to you, Hit return and let it finish, you should finish with ok.

Step 10: If you are adding more cards repeat the process 1 through 10. If you are finished you can run cfgmgr to pick up the new devices

Step 11: Verify the new devices
# lsslot –C pci

Step 12: Check errpt for any new errors





Thursday, February 28, 2013

What is the difference between hard link and soft link in aix?

What is the difference between hard link and soft link in aix?



Hard link
Soft link
inode same
inode vary
inode count increase
inode count not increased
If source file deleted means, destination file should  available
If Source file deleted then destination also deleted
If destination file deleted, souce file should be available
If destination file deleted, source will be available



Wednesday, February 27, 2013

How to move a cdrom from one lpar to another lpar?


How to move a cdrom from one LPAR to another LPAR?

1. Find the lpar which is currently holding the cdrom:


Login to the HMC, Select the Managed System and open "Properties", Look for the I/O device with the description "Other Mass Storage Controller" and read the "Owner" field. This will show the LPAR currently owning that device.


2. On the currently assigned lpar:


1. Find the parent adapter of the CD device:

$ lsdev -Cl cd0 -F parent
ide0

2. Find the slot containing the IDE bus:

$ lsslot -c slot
# Slot Description Device(s)
U787B.001.DNWG2AB-P1-T16 Logical I/O Slot pci1 ide0
U9133.55A.105C2EH-V7-C0 Virtual I/O Slot vsa0
U9133.55A.105C2EH-V7-C2 Virtual I/O Slot ent0
U9133.55A.105C2EH-V7-C3 Virtual I/O Slot vscsi0

so PCI1 is the slot containing the IDE adapter and CD drive.

3. Remove the slot from this host:

# rmdev -dl pci1 -R
cd0 deleted
ide0 deleted
pci1 deleted



3: Moving the cdrom to the target lpar using HMC:


Login to the HMC
Go to lpar 
(select) Dynamic lpar 
(select) Physical Adapters
(select) Move or remove


Now one box will open, on there you have to select the (cdrom) adapter to remove and provide the destination server details on the "Move to partition" option.



4: Verfication on the target lpar:


Now login to the target lpar and verfiy the cdrom has been moved successfully, with the help of below steps.

#cfgmgr
#lsdev -Cc cd0   ("cd0 available" -Here we have to confirm that the cdrom has been moved)
#mkdir /cdrom
#mount -v cdrfs -o ro /dev/cd0 /cdrom
#umount /cdrom


Sunday, February 24, 2013

How to upgrade the firmware level through HMC?


Steps to upgrade the firmware level through HMC


Check the existing firmware level of the servers (lpars) in the managed systems.

1. Login to the HMC with right privileges.

2. Click the managed server which you want to upgrade the firmware level.

3. Click the lpar and do shutdown, few minutes later, you can see the status as - "not activated"

4. poweroff and poweron the managed systems (To make it "STANDBY" mode)

5. Click the "change LIC for the current release "  (You can see this under the upgrade menu in the bottom of the HMC window0

start change licensed internal code wizard (press 0k)

        select ftp site (press ok)

                check the directory of the release (which is hold the package) (Also make sure the ftp site and user id and give the  passwd to proceed)  (press ok)

                        Press OK if you found no error in the next screen

                                press "Next"

                                        press "next"

                                                Accept the license (press "accept")

                                                        select the managed systems name on the check box and press finish to start the upgradation.

                                                                press "ok"  

                                                                        you can see the dialouge box of upgradation. (on that it mentioned 

In here the process automatically poweroff the managed system and prepare to install once the installation completed, the managed systems will be in the power on state.

Start the lpars which is hold by the managed systems. (That we already shutdown when we start this firmware upgradation see number:3)

Login the server and check it out the firmware level using "#lsmcode -c".


Friday, February 22, 2013

How to migrating to AIX 6.1 with nimadm?


How to migrating to AIX 6.1 with nimadm?


How to migrating to AIX 6.1 with nimadm?

Here I have provided the steps in simplest way in the Interview perspective. If you are familiar with AIX and NIM, you can understand the below steps very easily.

Ground work:

On NIM Master:

**Need Nim Master server with the 6.1 version --> #oslevel -s

** Master having alt_disk package installed  --> #lslpp -l bos.alt....'

** LPP and SPOT should be in high level (OS ver = 6.1) -->  #lsnim -c resources

** NIMADMVG should create on the NIM master server --> #lsvg -l nimadmvg

** Nim master should have the space -->  # df -gt

** Client needs to define with the master -->  #smitty nim_mkmac

** Take mksysb backup of the target client server --> "mksysb"

On NIM Client"


** Addtional disk needs to be there --> "lspv"

** Break the mirror to get the spare disk   #unmirrorvg rootvg hdisk1

**Clear the boot image on the disk   #chpv -c hdisk1

** RSH should be working --> #chsubserver -a -v shell -p tcp6 -r inetd
                                                #refresh -s inetd; cd / ; rm .rhosts;
                                                # vi .rhosts    (type + on the.rhosts file)
                                                # chmod 600 .rhosts


Implementation steps:

nimadm –j <nim volume group> -c <client name> -s <spot> -l <lpp_source> -d <disk of the client> -Y <accept>

Phase 1 Starting alt disk migration on the client
Phase 2 Creating nimadm cache file systems on volume group nimadmvg.
Phase 3 Syncing the nim client's data to cache filesystem.
Phase 4 Merging the system configuration files.
Phase 5 system configuration files are saved and the bos image is restored.
Phase 6 Migrating the system filesets to the new higher version.
Phase 7 Post migration has been checked.
Phase 8 Creating a boot image to client's alternate boot disk
Phase 9 Syncing cache data to client's alternate rootvg via rsh.
Phase 10 unmount and remove the cache filesystem on the nimadmvg
Phase 11 Boot list is set to the alt disk on the client.
Phase 12 Clean up the alt_disk_migration on nim master and nim client to end the migration.

** Reboot the server -->  shutdown -Fr 


Verfication:

** Once the system is up check the current OS level --> "oslevel -s"

** Check all the filesets are found --> instfix -i |grep -i ml

** Disable the RSH  --> "chsubserver -d -v shell -p tcp6 -r inetd"
                                          refresh -s inetd
                                          cd / ; rm .rhosts; ln -s /dev/null .rhosts


Post implementation:

# lspv | grep old_rootvg              --> Get the old_rootvg
# alt_rootvg_op -X old_rootvg   --> remove the alt vg
# extendvg –f rootvg hdisk0       --> Extend the disk to rootvg
# mirrorvg rootvg hdisk0             --> Mirror it back to the rootvg
# bosboot -ad /dev/hdisk0  /dev/hdisk1 --> create the boot image
# bootlist -m normal hdisk0 hdisk1  --> set the boot list
# bootlist -m normal -o   --> Confirm the boot sequence.

Advantage of nimadm method:

** Reduced downtime for the client.
** The migration is executed while the system is up and running as normal
** There is no disruption to any of the applications or services running on the client
** Quick recovery from migration failures. All changes are performed on the rootvg copy (altinst_rootvg).
** If there are any serious problems with the migration, the original rootvg is still available and the system has not been impacted.
** If a migration fails or terminates at any stage, nimadm is able to quickly recover from the event and clean up afterwards.



How to find vhost assigned to a particular VIO Client?


How to find vhost assigned to a particular VIO Client?


Method 1:      


Using two commands/steps we can easily find out the vhost information of the particular disk.


login to the vio client, and find out the disk's slot number ( for ex: hdisk1) 
                
         Command:>  lscfg|grep hdisk1 
        Output:>       hdisk1   U9133.55A.065040H-V21-C19  Virtual SCSI Server Adapter


login to the vio server and execute the below command to find out the vhost information of the particular disk.

                          Command:>  lsdev -slots|grep C19
                            Output:>    vhost3

Using the above output we can confirm that the vhost3 is assigned to the hdisk1.



--------------------------------------------------------------------------------------------------------------------------



Method 2:      


* Find the lpar id and convert into hexa decimal.

     For ex: if your LPAR ID is 15, then the hexadecimal value is "f"  

Using the below command we can convert decimal no to hexa-decimal.


    printf "%x\n" 15           
output is: "f"


 * Execute the below command on the VIO server to find out the vhost info.

     lsmap -all | grep vhost | grep 0x0000000f


Note: totally 6 zeros are needs to put after the "x" on the command and last two digit ("0f") is for hexa decimal number.

Advantages of this command is, if you have 6 virtual disks on the lpar from the vios, then we  will get all the 6 virtual disks associated with the vhosts name on the VIOS..

--------------------------------------------------------------------------------------------------------------------------

Method 3


Using kdb, we can easily trace the vscsi configuration in aix. This command will save much time when we compare with the old method to do the same.

In the old method, We can find out the slot number (like C13 or C14) of vscsi in the client server, after that login to the vio server and find out the appropriate vhost information for the vscsi.


#echo "cvai" | kdb | grep vscsi

read vscsi_scsi_ptrs OK, ptr = 0x59A03C0
vscsi0 0x000007 0x0000000000 0x0 vios1->vhost8
vscsi1 0x000007 0x0000000000 0x0 vios2->vhost8


Using above command from the client server to find out the appropriate VHOST information for our VSCSI and the name of the VIO servers as well.



--------------------------------------------------------------------------------------------------------------------------

Method 4:


Login to the lpar and get into the VG and make note of the PVID of the disk. Now login to the VIO Server and get the disk name using the PVID.  now we can able to get the appropriate vhost name with the corresponding disk name like below.

lpar: 

# lspv  --> To get the pvid of the disk


Vio server:

lspv|grep -i <pvid>        --> To get the disk name
lsmap -all|grep -p <disk name>   --> To get the VTD name

lsdev -dev <VTD name> -field parent   --> We can get the vhost name



--------------------------------------------------------------------------------------------------------------------------

Method 5:


As per Target's standard VTD naming convention, VTD name will contain the VIO client name & LUN ID of the disk used for backing device. So we can run a lsmap -all | more and find the VTD with VIO Client we are searching for. Below output shows that vhost3 is the Server SCSI adapter for VIO Client "testmachine"


$ lsmap -all | more
Physloc               U7311.D20.067DDBB-P1-C02-T1-L23

VTD                   esvdevcmsweb-42e
Status                Available
LUN                   0x9500000000000000
Backing device        hdiskpower16
Physloc               U7311.D20.067DDBB-P1-C02-T1-L19

SVSA            Physloc                                      Client Partition ID
--------------- -------------------------------------------- ------------------
vhost3          U9133.55A.065040H-V22-C16                    0x00000003

VTD                   testmachine-16
Status                Available
LUN                   0x8700000000000000
Backing device        hdiskpower54
Physloc               U7311.D20.067DDBB-P1-C02-T1-L113

VTD                   testmachine-15
Status                Available
LUN                   0x9200000000000000
Backing device        hdiskpower30
Physloc               U7311.D20.067DDBB-P1-C02-T1-L66