vendredi 27 mai 2011

AIX - NIM - Type d'installation

rte

This will be either a Migration, Preservation, or New and Complete Overwrite install.

mksysb --> doit être associé au SPOT

This will be taking a mksysb image and either restoring it back to the system it came from or cloning that image to another system.
* A common problem when running a mksysb install is attempting to use a SPOT that is at a lower level than your mksysb image. NIM has a built in check now and will warn you if you are attempting to use a lower level SPOT, however it is a good idea to make it a habit to check this yourself.

SPOT

This is a very rarely used installation method. By doing this you take the SPOT that you are using for the installation, and copy it over. If you do not have the proper device support in your SPOT, the installation will complete, but the system will not boot.
*I will not be reviewing SPOT installs as they are so rarely used, however after going through the next section, you should have no problem setting one up should you wish to do so.

update_all

The last installation type we’ll cover is the update_all. This can be used to update a master, client. or SPOT with individual APARs, technology levels, or service packs.
Most commonly you will use your lpp_source resource to run an update_all to a NIM client that is at a lower technology level. In this case you do not need a matching SPOT resource, as there is no initial boot required of the client. The master simply NFS mounts over the lpp_source location to the client which ends up running his own update_all operation.

*In all cases, it is always recommended to verify that your target system is up at the latest level of firmware before running any of these installations. Trust me, this isn’t one of those, “eh I hate updating firmware, I’ll just skip it this time” sorts of situations. This is a “seriously....make sure your firmware is up to the latest level” situations.
Below is the firmware download site. Instructions on installing the firmware are also found by clicking through to your firmware level.
FixCentral Firmware Download
http://www-933.ibm.com/support/fixcentral/

If planning to run an update_all to either your NIM master or a client machine you should refer to the DCF document Updating to a New Technology Level or Service Pack to go through recommended pre/post checks.
You can also use the search function at the DCF site to run a search for the document by using the same name.

AIX - NIM - Séquence bootp

Bootp
This is the initial communication made between the NIM master and client during a boot or bosinst operation. In order for this to be successful several factors must be met :

   1. - bootpd must be running on the NIM master
   2. - the NIM client and master must have correct ip information about each other
   3. - the /etc/bootptab must be populated correctly
   4. - If the master and client systems are on separate networks, the router must be set to forward bootp packets.

There are other causes of failure, but checking/verifying those 4 will solve most bootp issues.

Tftp (Trivial File Transfer Protocol)
When the NIM client has been rebooted for a boot or bos_inst operation you don’t have access to normal TCP communication. Once bootp connection has successfully been achieved, the NIM master uses tftp to transfer over the <clientname>.info file and the boot image to the client.

Quand ça ne marche pas

lssrc -t bootps doit être actif
regarder les processes bootps et tftpd
fichier /etc/inetd.conf :

tftp     dgram  udp6    SRC     nobody  /usr/sbin/tftpd         tftpd -n
bootps  dgram   udp     wait    root    /usr/sbin/bootpd       bootpd /etc/bootptab

bid_ow
BID Ressource de forme script qui permet de customiser les installations par machine.

AIX - Script mksysb automatique avec NIM

Script mksysb sur machine dans un autre réseau (script local)

# cat /users/exploit/scripts/save_mksysb.ksh
#!/usr/bin/ksh

DATE=`date '+%y%m%d'`
HOSTNAME=`uname -n`
DIR="/Nim_Master/Ressources"

rm -f ${DIR}/mksysb_${HOSTNAME}*.old
for i in `ls mksysb_${HOSTNAME}* | grep -v log`
do
        mv ${i} ${i}.old
done

#mksysb  '-e' '-i' '-X'  '-A' ${DIR}/mksysb_${HOSTNAME}_${DATE}  > ${DIR}/mksysb_${HOSTNAME}_${DATE}.log 2>&1



Script mksysb sur machine dans un autre réseau (appel script local ci-dessus)


# cat /users/exploit/scripts/save_dmz_mksysb.ksh
#!/bin/ksh

function save
{
set -x
# Variables settings
typeset -u UMAC=$machine
typeset -l LMAC=$machine
F=`date '+%y%m%d'`
IMADIR=/Nim_Master/Ressources
DIR=/users/exploit/log
FILENAME=mksysb_${LMAC}_${F}

# Test connexion
ping -c1 $LMAC
if [ "$?" -eq 0 ]
then

# Define mksysb nim object
#   nim -o remove mksysb_$LMAC
#   nim -o define -t mksysb -a server=master -a location=$IMADIR/mksysb_$LMAC -a mk_image=yes -a source=$LMAC mksysb_$LMAC
ssh $LMAC /export/sav_mksysb.ksh
RC=$?
# On recupere la log mksysb
scp $LMAC:/export/images/log/mksysb_${LMAC}_${F} ${DIR}/mksysb_${LMAC}_${F}

# grep "Backup Completed Successfully" /export/images/log/mksysb_${LMAC}_${F}
   if [ "$RC" -eq 0 ]
   then
      echo `date '+%d/%m/%Y %H:%M:%S'` "Sauvegarde de $LMAC est OK" > $IMADIR/logs/$LMAC.log
      scp $LMAC:/export/images/mksysb_${LMAC}_${F}  $IMADIR/mksysb_${LMAC}_${F}
      $RCSCP=$?
        if [ "$RCSCP" -eq 0 ]
        then
                ssh $LMAC rm /export/images/mksysb_${LMAC}_${F}
        else
                echo "Probleme de recuperation du fichier mksysb" >> $IMADIR/logs/$LMAC.log
        fi
   else
      echo `date '+%d/%m/%Y %H:%M:%S'` "Probleme de Sauvegarde de $LMAC Return-Code : "$RC >> $IMADIR/logs/$LMAC.log
   fi


else
   echo "Probleme de connection a $LMAC " >$IMADIR/logs/$LMAC.log
fi
}

# Main
# Choix machine
if [ "$#" -eq 1 ]
then
   machine=$1
   save
else
   for machine in $(lsnim|grep standalone|awk '{print $1}')
   do
      save
      sleep 600
   done
fi

AIX - NIM - Ressources

Client (nim client) :
Any standalone machine or lpar in a NIM environment other than the NIM master. Clients use resources that reside on the NIM master to perform various software maintenance, backup, or other utility functions.
*Note that NIM resources do not always have to reside on the NIM master, but for our purposes they all will.

Groups (machine groups) :
In the spirit of convenience you can create a machine group which consists of a number of NIM clients. All NIM operations initiated from the master to that machine group subsequently are performed to all machines that are part of that group. For example, you can define a machine group and call it “Group1”. Group1 has ClientA, ClientB, ClientC, and ClientD in it. You can initiate a bos_inst operation to each individual client, or if all clients are being installed with the same image, you can initiate the bosinst operation to Group1. All client systems will be installed at the same time. The downside to this however, is that you sacrifice performance for convenience. It is best if you decide to use machine groups to test out what sort of load your network and NIM master can hold before seeing diminishing returns.

Master (nim master) :
The one and only one machine in a NIM environment that has permission to run commands remotely on NIM clients. A client can only have one master, and a master can not be a client of any other master. The NIM master must also be at an equal or higher OS/TL/SP level than any client in the NIM environment. The NIM master also can not create SPOT resources at a higher level than it is currently installed at. Finally, the NIM master can not install any clients with an OS/TL/SP higher than his own. Long story short, for all intents and purposes, for any NIM operation, make sure you master is at an equal or higher level.
The NIM master also will hold all of our NIM resources. Due to this we’ll want to make sure the NIM master has plenty of space available to it. Ideally, having a separate volume group (nimvg) is beneficial, so the rootvg does not get out of control in size.

Resource (nim resources) :
This can be a single file or up to a whole filesystem that is used to provide some sort of information to, or perform an operation on a NIM client. Resources are allocated to NIM clients using NFS and can be allocated to multiple clients at the same time. Various resource types will be explained below. I’ve decided to order them in a logical order of description rather than alphabetical order. It should make more sense to read through them in this manner.

lpp_source
When running an installation of a system outside of NIM, you use an installation CD. NIM uses resources. Two of the most important resources are made using the installation CD. First of all let’s understand what exactly is on an installation CD that allows us to install a system. There are 4 parts :
- The filesets that get installed.
- The .toc file so the system knows what filesets are on the media.
- The boot images so the CD can boot the system initially
- A /usr filesystem to run the commands needed to install the system.


The lpp_source is created from an AIX installation CD and is responsible for holding :
- The filesets that get installed.
- The .toc file so NIM knows what is available in the lpp_source to be installed to the client.

In short, the lpp_source is simply a depot. It’s just a directory that holds all of the filesets and the .toc file.

SPOT
The SPOT resource (stands for Shared Product Object Tree in case you were wondering) is responsible for the following :
- Creating a boot image to send to the client machine over the network.
- Running the commands needed to install the NIM client.

Essentially the SPOT is a /usr filesystem just like the one on your NIM master. You can think of it as having multiple “mini-systems” on your NIM master, because each SPOT is its own /usr filesystem. You can upgrade it, add fixes to it, use it to boot a client system....etc. Just like your NIM master’s /usr filesystem, going in there manually and messing around with files can easily corrupt it. The good thing about a SPOT however, is that it is easily rebuilt.
You can also create a SPOT from a NIM mksysb resource. This SPOT however is not as versatile as one created from an lpp_source and can not be upgraded with any fixes and can only be used with the mksysb resource it was created from.

mksysb
This is simply a mksysb image of a machine. The mksysb image can be of the NIM master, a NIM client, or a machine outside of the NIM environment. This resource can be defined in one of two ways.
- From an existing mksysb taken to file that resides on the NIM master.
- Creating a new mksysb image of a currently existing NIM client.
At this time there is no supported way to use a mksysb tape or mksysb on CD/DVD, as an input device to define a mksysb resource in NIM.

bosinst_data
When booting from installation media to install or upgrade a system you boot to what are known as the “BOS Menus” or Base Operating System Installation Menus. Here you select your console, what language to use, what disks to install to.....and many other options. In NIM we can create a “bosinst_data” resource that will answer these questions for us. By doing this we can perform a “non-prompted” installation. So if you have a NIM client in another building, down the road, or half way across the country, you can create this type of NIM resource which will provide the answers to those questions, so once you kick off the install from the NIM master no further interaction is required. The system should (ideally) install and reboot itself afterward.

A mksysb (as discussed above) has a “built in” bosinst.data file. If the option in that file
(PROMPT =) is set to yes, this file really does nothing as the choices you make in the BOS menus will override the options in the file. However, if the mksysb was created to have that option set to no, then we can create a new bosinst_data resource which will trump the one that is part of the mksysb.

image_data
Outside of NIM this file is responsible for knowing how your rootvg is built. It contains information like the partition size of rootvg, the disks belonging to rootvg, all of the filesystems (and their sizes) that belong to rootvg, whether the rootvg is mirrored, and other information. As with the bosinst_data file, a mksysb also has one of these “built in”. If this built in file needs to be altered in any way, we can accomplish this by creating and allocating an image_data resource.

NIM - Setup Guide

Services NIM

# lssrc -a | grep nim
 nimesis          nim              389338           actif
 nimsh            nimclient                         désactivé
 nimd                                              désactivé

AIX - NIM - Fichiers importants

/etc/bootptab
This file will exist on the NIM master. In a quiet NIM environment with no operations that require a client to boot, this file will be empty (except for the pre-existing commented section). This file gets updated automatically by the NIM master when a NIM operation is executed that requires the client machine to boot from a NIM SPOT. If this file contains incorrect information about either the master or the client, the boot operation will fail. While this file “can” be edited manually to fix a bootp issue - it should not be, as you are only applying a “band-aid” fix to an existing issue in your NIM environment....but, sometimes it’s 5pm on a Friday and you’re ready to go home, right ?
(Also note related entry ‘bootp’)

/etc/exports
This is not a “NIM specific” file, it is a NIM critical file. Any sort of installation, boot, mksysb, savevg....etc operation requires the use of NFS. This file will be updated with which locations are NFS exported from the master to the client and the permissions associated with those exports. If these entries are incorrect or incomplete you will run into boot failures, permission problems, and other errors commonly associated with NFS. This is a text file and also “can” be edited manually to sometimes “band-aid” a problem, but should only be done so with care in knowing exactly what you’re doing. The good thing is, if we mess up this file we can remove it and recycle NFS. The file can be recreated.

/etc/hosts
While not a “NIM specific” file, it is also a NIM critical file. This file is sort of like a phone book. It gives a relationship between a system’s hostname and an ip address. Much like a telephone, if you dial the wrong number you get the wrong person. In NIM, if your ip address does not match up to the correct hostname, your install fails. This is a text file and can be edited manually. There should also only be 1 entry per ip/hostname. I personally prefer to make sure my NIM master has all entries in the /etc/hosts file and are of the following format :
<ipadress> <shortname> <longname>
If the client machine is up and running, it should also have a good entry in there for the NIM master as well.

/etc/niminfo
This file should always exist on the NIM master and sometimes will exist on a NIM client.
On the Master : This file is built when you first initialize the NIM environment. This is simply a text file so feel free to ‘cat’ or ‘more’ the file and look at the entries included in there. You do not want to manually edit this file if there is a mistake in the definition of the master. In this case you will want to redefine the master, or use the feature in NIM to change the master’s attributes (hostname, gateway....etc).
On the Client : This file is “optional” depending on what sort of operations you are performing on the client. If the NIM client is up and running, and you intend to perform operations on the client (like take backups, or install maintenance) you will want to make sure this file exists. This file contains not only hostname information for the client, but tells the client who its master is.
This also should not be edited manually. If there is incorrect information in the file, it should be removed and recreated.

/tftpboot
This directory should always exist on the NIM master. The main purpose of this directory is to hold the boot images that are created by NIM when a boot or installation is initiated. This directory also holds informational files about the clients that are having a boot or installation operation performed. The file names that are generated in both cases are very descriptive file names For example :
The boot image created might be named : 53_spot.chrp.mp.ent.
The format of the file name is <spotname>.<system_architecture>.<processor>.<adapter_type>
The client info files are aptly named : <clientname>.info
The NIM master will create the <client_hostnamename> file and link it to the boot image. This boot image is what is sent over to the NIM client during a boot/installation operation.

mercredi 25 mai 2011

Shell - Variables Spéciales

Variables d'environnement
$HOME   chemin du répertoire personnel de l'utilisateur
$OLDPWD   chemin du répertoire précédent
$PATH   liste des chemins de recherche des commandes exécutables
$PPID   PID du processus père du shell
$PS1   invite principale du shell
$PS2   invite secondaire du shell
$PS3   invite de la structure shell "select"
$PS4   invite de l'option shell de débogage "xtrace"
$PWD   chemin du répertoire courant
$RANDOM   nombre entier aléatoire compris entre 0 et 32767
$REPLY   variable par défaut de la commande "read" et de la structure shell "select"
$SECONDS   nombre de secondes écoulées depuis le lancement du shell

Shell - Variables Spéciales

Variables spéciales
$$   PID du shell courant
$!   PID du dernier travail lancé en arrière plan
$?   code retour de la dernière commande

Shell - Paramètres

Paramètres positionnels et arguments
$0   nom du script
$1 $2 ... ${10}   paramètres positionnels (1, 2 et 10)
$#   nombre de paramètres positionnels
$* ou $@   ensemble des paramètres positionnels, équivalant à $1 $2 ... ${n}
"$*"   ensemble des paramètres positionnels, équivalant à "$1 $2 ... ${n}"
"$@"   ensemble des paramètres positionnels, équivalant à "$1" "$2" ... "${n}"

Shell - Tableau

tab[0]=val   affectation du premier enregistrement du tableau "tab"
${tab[0]} ou $tab   contenu du premier enregistrement du tableau "tab"
${tab[11]}   contenu du douzième enregistrement du tableau "tab"
${tab[*]}   ensemble des enregistrements du tableau "tab"
${#tab[11]}   longueur du douzième enregistrement du tableau "tab"
${#tab[*]}   nombre d'enregistrements du tableau "tab"

Shell - Manipulation de variables simples

Manipulation de variables simples
  • var=val ou var="a b"   affectation de la variable "var"
  • $var ou ${var}   contenu de la variable "var"
  • ${#var}   longueur de la variable "var"
  • export var ou declare -x var   exportation de la variable "var" vers les shells fils
  • set   affichage de l'ensemble des variables définies dans le shell
  • unset var   suppression de la variable "var"

lundi 23 mai 2011

Configuration Proxy/Reverse Apache

<VirtualHost url.domain.com>
ErrorLog /logs/HTTPServer/url.domain_error.log
CustomLog /logs/HTTPServer/url.domain_acces.log common

ProxyRequests On
ProxyPass / http://backend.domain.com/

ProxyRequests Off
ProxyPassReverse / http://backend.domain.com/

<Proxy http://url.domain.com>
        Order deny,allow
        Allow from All
</Proxy>
</VirtualHost>

jeudi 5 mai 2011

LINUX - Convertir rpm en tar sources

rpm2cpio /depot/libxml2-2.7.6-1.src.rpm | cpio -idv

libxml2-2.7.6.tar.gz
libxml2.spec
9491 blocks

mardi 3 mai 2011

AIX - KeepAlive TCP

Comment implémenter un KeepAlive TCP

Updating AIX
For an AIX client, there are three operating system keepalive parameters to change:
  • tcp_keepidle - the length of time to keep an idle TCP connection active
  • tcp_keepintvl - the interval between packets sent to validate the TCP connection
  • tcp_keepcnt - the number of keepalive probes to be sent before terminating the connection
On the AIX operating system, update these parameters using the "network option" command:
no -o tcp_keepidle=12
no -o tcp_keepintvl=2
no -o tcp_keepcnt=10

TCPDUMP

tcpdump -s 10000 -X -v -v -w tcpdump.log port 8080

Trace spécifique sur le port 8080