UNIX tricks and treats

DECEMBER 2008:


Operating systems:

Windows				745		93%
Linux				42		5.2%
Macintosh				12		1.5%
SunOS				2		0.2%

Browsers:

Explorer				302			40%
Firefox				263			34.8%
Explorer x.x				137			18.1%
Opera				21			2.8%
Safari				15			2%
Explorer 5.x				8			1.1%
Other Mozilla				6			0.8%
Explorer 4.x				2			0.3%
Konqueror				1			0.1%

Tested on: IBM AIX 5.2

Sendmail processes may run wild, due to huge process loads, or even badly configured applications sending automatized mails.

When sendmail processes are overloaded, they may clog up the mailqueue and spawn multiple sendmail processes to treat the mailqueue, ultimately consuming most of your server's swap area, degrading performance, or even prevent other applications from running.

Here are the steps needed to stop rogue sendmail processes, and cleanly purge the sendmail mailqueue on IBM AIX 5.2. The process is similar on other UNIXes, except for the sendmail stop and start commands, which vary, depending of your OS. On Solaris, for example, you would use your own stop and start scripts in /etc/rcX.d/ or in /etc/init.d/.

First, find and kill the multiple sendmail processes if they have gone havoc.

# ps -ef | grep sendmail
 
# kill -9 SENDMAIL_PIDS

Then, stop sendmail cleanly (the commands depend of your OS. This one works only on IBM AIX).

# stopsrc -s sendmail  

You may check the number of messages that are in the queue, which will give you an idea of the time it will take to process the queue:

# sendmail -bp 


Check that there are no longer any sendmail processes running:

# ps -ef | grep sendmail
 
# kill -9 SENDMAIL_PIDS

Rename the current mailqueue to another directory:

# mv /var/spool/mqueue /var/spool/omqueue 

Restart sendmail

# startsrc -s sendmail
0513-059 The sendmail Subsystem has been started. Subsystem PID is 62118
 

Now process the old queue (may take time, depending upon the number of messages to process):

# /usr/sbin/sendmail -oQ/var/spool/omqueue -q -v

Running /var/spool/omqueue/m7HKkOM60666 (sequence XXXX of XXXXX)
Running /var/spool/omqueue/m7HKkOM60666 (sequence XXXX+1 of XXXXX)...
etc... 

Now, you may safely delete all messages in the old queue:

# rm -rf /var/spool/omqueue

Create a new mailqueue directory.

# mkdir /var/spool/mqueue

Stop and start sendmail:

# stopsrc -s sendmail


# startsrc -s sendmail

You're done!

Happy computing.

Drop me a comment if this post has been useful to you, or if you see any reason for add-on or modification.

Nixman

Sur les serveur Sunfire disposant d'une interface ALOM en NetMGMT (SunFire V210, V240, T1000, T2000...), il est possible d'accéder au LOM au travers du réseau, via un port RJ45 spécifique, exactement comme via un port série. Il suffit d'activer la prise en charge réseau via les commandes suivantes du LOM:

setsc if_network true
setsc netsc_ipaddr ADRESSE_IP
setsc netsc_ipnetmask NETMASK
setsc netsc_ipgateway ADRESSE_PASSERELLE
resetsc

Ou bien vous pouvez utiliser la commande interactive setupsc.

Note: Il semble qu'il soit impossible de déterminer un mask différent de 255.255.255.0.

Note 2: Pour des questions de sécurité, il est bien entendu préférable d'accéder à l'ALOM via un sous-réseau spécifique.

Ensuite, il suffit de telneter l'adresse ADRESSE_IP précédemment renseignée.

Pour basculer entre le mode terminal et le mode LOM, il faut utiliser les commandes suivantes:

#.               --> bascule en mode LOM

console -f   --> bascule en mode terminal en rw en déconnectant les autres sessions.

Laissez-moi un commentaire si cet article vous a été utile.

Bonne journée.

Nixman

Fonctionne sous: IBM AIX 5.2

Le serveur ftp historique d'IBM AIX étant relativement limité dans ses capacités de configuration, notamment dans l'utilisation d'environnements chrootés, il est parfois utile d'installer un daemon ftpd alternatif.

1 ) Télécharger coreutils et proftpd depuis le site d’IBM :

http://www-03.ibm.com/systems/p/os/aix/linux/toolbox/download.html


2 ) Installer coreutils-5.2.1-2.aix5.1.ppc.rpm et  proftpd-1.2.8-1.aix5.1.ppc.rpm :

rpm –Uvh coreutils-5.2.1-2.aix5.1.ppc.rpm
rpm –Uvh proftpd-1.2.8-1.aix5.1.ppc.rpm


3 ) Modifier /etc/proftpd.conf

####################################################
# This is a basic ProFTPD configuration file (rename it to
# 'proftpd.conf' for actual use.  It establishes a single server
# and a single anonymous login.  It assumes that you have a user/group
# "nobody" and "ftp" for normal operation and anon.

# Modif Nixman: on ne veut pas que le serveur affiche la version de proftpd
# On remplace ServerName par ServerIdent
ServerIdent     on      "Serveur FTP NIXBLOG.ORG"
# ServerName                    "Serveur FTP NIXBLOG.ORG"
# Modif Nixman:  Mettre ServerType a inetd au lieu de StandAlone
ServerType                      inetd
DefaultServer                   on

# Port 21 is the standard FTP port.
Port                            21

# Umask 022 is a good standard umask to prevent new dirs and files
# from being group and world writable.
Umask                           022

# To prevent DoS attacks, set the maximum number of child processes
# to 30.  If you need to allow more than 30 concurrent connections
# at once, simply increase this value.  Note that this ONLY works
# in standalone mode, in inetd mode you should use an inetd server
# that allows you to limit maximum number of processes per service
# (such as xinetd).
MaxInstances                    30

# Set the user and group under which the server will run.
# Modif Nixman: Mettre Group a nobody, car le groupe par defaut n'existe pas
# sous AIX
User                            nobody
Group                           nobody

# To cause every FTP user to be "jailed" (chrooted) into their home
# directory, uncomment this line.
# Modif Nixman: Tous les utilisateurs du groupe ftpjail sont chrootes
DefaultRoot ~ ftpjail

# Normally, we want files to be overwriteable.
<Directory />
  AllowOverwrite                on
</Directory>

# Ajout Nixman: on veut un log des transfert
Transferlog     /var/adm/xferlog.proftpd

## A basic anonymous configuration, no upload directories.  If you do not
## want anonymous users, simply delete this entire <Anonymous> section.
## Modif Nixman: On ne veut pas de compte ftp anonyme, donc on commente tout
## le paragraphe
#<Anonymous ~ftp>
#  User                         ftp
#  Group                                ftp
#
#  # We want clients to be able to login with "anonymous" as well as "ftp"
#  UserAlias                    anonymous ftp
#
#  # Limit the maximum number of anonymous logins
#  MaxClients                   10
#
#  # We want 'welcome.msg' displayed at login, and '.message' displayed
#  # in each newly chdired directory.
#  DisplayLogin                 welcome.msg
#  DisplayFirstChdir            .message
#
#  # Limit WRITE everywhere in the anonymous chroot
#  <Limit WRITE>
#    DenyAll
#  </Limit>
#</Anonymous>
####################################################

4) modifier /etc/inetd.conf

#ftp     stream  tcp6    nowait  root    /usr/sbin/ftpd         ftpd
ftp     stream  tcp    nowait  root    /usr/sbin/proftpd         proftpd


5) Relancer inetd:

refresh –s inetd


6) Modifier ftpusers:

Enlever les utilisateurs qui ont droit de se connecter dans /etc/ftpusers, si le fichier a été créé à l’installation.


7) Créer le groupe ftpjail et y ajouter les utilisateurs à chrooter:

mkgroup ftpjail
vi /etc/group et y ajouter les utilisateurs qui doivent être chrootées.


8) Retour en arrière possible:

Il suffit de remettre /etc/inetd.conf à l’état d’origine :

ftp     stream  tcp6    nowait  root    /usr/sbin/ftpd         ftpd
#ftp     stream  tcp    nowait  root    /usr/sbin/proftpd         proftpd

Ensuite, refresh –s inetd.

Pour désinstaller coreutils et proftpd:
rpm –e proftpd-1.2.8-1
rpm –e coreutils-5.2.1-2

Laissez-moi un commentaire si cet article vous a été utile.

Vous pouvez également suivre quelques liens pour m'assurer un peu de revenu ;-).

Nixman

Suppose you're a Paris-based firm that has several databases spread across different locations.

For example:
a) several Oracle databases listening on port 1521 on your own network, on addresses 10.75.75.1 - 10,
b) one Oracle database listening on port 1521 in Turku, Finland linked by a VPN  tunnel, on address 172.16.2.2,
c) one oracle database listening on port 1521 in Toulouse linked by a leased line, on address 172.31.31.31,
d) one Oracle database listening on port 21521 on a public internet WAN port in Tanger, with just source-address filtering as security, on address 212.66.66.66,
e) plus about a dozen other databases in different parts of the world at your clients' sites.

You have a partner providing an extra service to your clients, and he has to connect in real time on all of your databases. He doesn't want to spend money on a network connection to each and everyone of your clients. He proposes to pay a leased line to your Paris site, and you will do the dispatching.
Of course, you don't want him to know too much about your network, so you will restrict his access to only one address, which will be a firewall at your end of the line between your two sites .

Let's suppose the outside interface address of your firewall is 192.168.15.100, and the inside address (the one on your network) 10.75.75.254.

Providing  connectivity to the (a) databases on your local  network is pretty easy: you just have to give a port-forwarding rule and an access list to your router.

For example:
port 2001 on the outside interface ---> port 1521 on server1 at  10.75.75.1,
port 2002 on the outside interface ---> port 1521 on server2 at 10.75.75.2,
port 2003 on the outside interface ---> port 1521 on server3 at 10.75.75.3,
and so on...
Then, you just tell your partner to configure his tnsnames.ora to point at address 192.168.15.100 and port 2001 for server1, address 192.168.15.100 and port 2002 for server2, and so on...

However, forwarding the ports to the external (b), (c) and (d) databases is another affair.

Luckily, Pen is there for you. It was designed as load-balancing piece of software for server farms, but its features allow it to be used as a port-forwarding proxy, which is what we need in this case. It is available prepackaged for rpm- as well as deb-based Linux  distros, or as GPL'ed source code. You may learn more on its numerous features on its website: http://siag.nu/pen/

All you need is is a standard PC on your network, with a Linux Distro, let's say Debian, installed on it , as well as one (yes, only one) NIC.

Do an apt-get install pen (or an rpm-Uvh pen on an rpm-based distro).

Let's suppose you've given address 10.75.75.75 to this computer.
It has to know the routes to reach the Turku, Toulouse, and Tanger based servers, and of course the route to reach your partner who wants to connect to them. It has also to be allowed to reach them on the ports on which they are listening (i.e 1521, 1521 and 21521 respectively).

All you need now is to write a little snippet of shell code in a file that you would call for example port-fwrd.sh:

###############
#!/bin/bash

# This is for the Turku-based database
pen 10.75.75.75:2011 172.16.2.2:1521

# This is for the Toulouse-based database
pen 10.75.75.75:2012 172.31.31.31:1521

# This is for the Tanger-based database
pen 10.75.75.75:2013 212.66.66.66:21521

exit
###############

Make port-fwrd.sh executable by a chmod, and launch it: ./port-fwrd.sh
Have it start in your init scripts at rc3 level, so that it will get executed upon reboot of your machine.

All you have to do now on your firewall is to forward:
port 2011 on the outside interface ---> port 2011 on 10.75.75.75
port 2012 on the outside interface ---> port 2012 on 10.75.75.75
port 2013 on the outside interface ---> port 2013 on 10.75.75.75

and tell your partner to configure his tnsnames.ora to reach:
Turku on address 192.168.15.100 and port 2011,
Toulouse on address 192.168.15.100 and port 2012,
Tanger on address 192.168.15.100 and port 2013.

Beautiful and simple, ain't it?

Note: of course, if the server on one of the locations doesn't support shared sockets (as it is the case with for example a Windows 2000 Server failsafe cluster), you won't be able to use portforwarding, since the answering port on the target server will a dynamic one, and thus unpredictable.

Happy computing.

Drop me a comment if this post has been useful to you, or if you see any reason for add-on or modification.

Nixman

Works on: AIX

AIX relies mostly on its own error reporting tools like errpt in order to keep track of incidents.

Thus, by default, AIX doesn't have a working configuration of syslog server, even though syslogd is installed. It simply lacks the proper configuration files.

Here are the steps to create a working configuration file and activate the service.

First, you have to create and edit the /etc/syslog.conf file. For example like this:

########
kern.debug;mail.none      /var/adm/messages       rotate size 2m files 3 compress
*.emerg;mail.none /var/adm/messages       rotate size 2m files 3 compress
*.alert;mail.none /var/adm/messages       rotate size 2m files 3 compress
*.crit;mail.none  /var/adm/messages       rotate size 2m files 3 compress
*.warning;mail.none       /var/adm/messages       rotate size 2m files 3 compress
*.err;mail.none   /var/adm/messages       rotate size 2m files 3 compress
*.notice;mail.none        /var/adm/messages       rotate size 2m files 3 compress
*.info;mail.none  /var/adm/messages       rotate size 2m files 3 compress
auth.notice     /var/adm/authlog        rotate size 2m files 3 compress
mail.info       /var/adm/mailerrors     rotate size 2m files 3 compress
########

This configuration allows you to rotate the logs on three files of 2MB each, and compress them.

Then, all you have to do is to run the following commands in order to create the log files, and restart the syslog service.
 
# touch /var/adm/messages
# touch /var/adm/authlog
# touch /var/adm/mailerrors
# refresh -s syslogd
 
If the configuration is successful, you will see a line resembling the following:
Nov 26 15:53:06 SERVER_NAME syslogd: restart
in the /var/adm/messages file right after running refresh -s syslogd

Happy computing.

Drop me a comment if this post has been useful to you, or if you see any reason for add-on or modification.

Nixman

Works on: Sun Solaris

Solaris disables disk cache by default, which has debatable advantages of data integrity, and definitive disadvantages in terms of I/O performance.

Here are the steps needed to enable the functionality:

# init 1
# format -e
format> cache
format> write_cache
format> display
format> enable  (if disabled)

Happy computing.

Drop me a comment if this post has been useful to you, or if you see any reason for add-on or modification.

Nixman

(The english version of this post is here)

Fonctionne sous: Sun Solaris

Dans un souci intégriste ... d'intégrité des données, Solaris désactive par défaut le cache d'écriture des disques durs, au détriment de la performance entrée/sortie des disques.

Voici les étapes permettant de restaurer cette fonctionnalité:

# init 1
# format -e
format> cache
format> write_cache
format> display
format> enable  (si disablé)

Attention! Effectuer cette manipulation de préférence avant que le serveur ne soit en production, dans la mesure où il faut passer par le niveau d'exécution single user.


Laissez-moi un commentaire si cet article vous a été utile.

Bonne journée.

Nixman

Works on : AIX

Let's suppose you're getting permanent hardware errors on hdisk0  when running the errpt -a command on an IBM AIX server.

In order to check that both disks are really assigned to the volume group, you should start with:
lsvg -p rootvg
You should see both hdisk0 and hdisk1 under the PV name.

A second thing to check would be that the re really are copies:
lsvg -l rootvg
Just check that there is a 1:2 relationship between LPs and PPs, and that PVs is equal to 2. Otherwise, you should check that the volume that's not copied doesn't reside on the failing disk with:
lslv -l LV_NAME

Once you've done these preliminary checks, you can start detaching hdisk0 from the volume:
unmirrorvg rootvg hdisk0

After running the command, I've sometimes had these messages, which are mostly informational:
0516-1246 rmlvcopy: If hd5 is the boot logical volume, please run 'chpv -c <diskname>'
        as root user to clear the boot record and avoid a potential boot
        off an old boot image that may reside on the disk from which this
        logical volume is moved/removed.
0301-108 mkboot: Unable to read file blocks. Return code: -1
0516-1132 unmirrorvg: Quorum requirement turned on, reboot system for this
        to take effect for rootvg.
0516-1144 unmirrorvg: rootvg successfully unmirrored, user should perform
        bosboot of system to reinitialize boot records.  Then, user must modify
        bootlist to just include:  hdisk0.

Then we reduce the volume:
reducevg rootvg hdisk0

And remove the device from configuration:
rmdev -dl hdisk0

Then, we will have to power down the machine, as we're dealing with a rootvg disk. However, before doing so, it's preferable to check whether we will boot of from the right drive:
bootinfo -b will tell you which drive was last booted up.
If it's the failed drive (hdisk0 in our case), we should change it to the drive still usable (hdisk1 in our case) by creating the boot image on hdisk1 and recrcreating the fixed ipldevice link, which was deleted by the previous rmdev command  :
bosboot -ad /dev/hdisk1
ln /dev/rhdisk1 /dev/ipldevice

Then, we can check bootlist:
bootlist -m normal -o

... And now, we can finally power down our server, replace the failed drive, and power it back on...

Once the server has booted up, we should run:
cfgmgr
so that the OS will recognize the new disk.

To check that AIX really has done its job, run:
lsdev -Cc disk
which should list both disks hdisk0 and hdisk1

Now, we can assign the new disk to the rootvg volume group:
extendvg rootvg hdisk0

Then we mirror the group:
mirrorvg rootvg
Wait for hdisk1 to complete copying on hdisk0 (it can take some time, as you can imagine). You can check activity with iostat.

You should check that both disks are really assigned to rootvg by typing:
lsvg -p rootvg

An lsvg -l rootvg will show you whether mirroring has worked OK. You should once again have a 1:2 relationship between LPs and PPs.

Then, create the boot image on the new disk:
bosboot -a -d hdisk0

Finally, modify the bootlist to take into account both disks:
bootlist -m normal hdisk0 hdisk1
Check with:
bootlist -m -normal -o
 
And you're finally done!

Happy computing.

Drop me a comment if this post has been useful to you, or if you see any reason for add-on or modification.

Nixman

Works with: Solaris, Linux, AIX

Let us start with something easy and frequently used on sites with badly written PL/SQL code.

Let's suppose that you have an Oracle process that has gone astray, or even worse, is generating a lock on your database, preventing other users from making updates on a table.

The first step would be to find the Oracle session that's causing the lock (not the ones that are suffering from the lock, which you would find easily by quering the V$SESSION table).

It's as easy as:

SELECT * FROM dba_blockers;

You might have to wait for a while before getting the magic serial# and sid (not to be mistaken with ORACLE_SID of course) needed to run your ALTER SYSTEM KILL SESSION 'sid , serial#' command.

Note: on Oracle 8i and earlier, you would first have to run the catblock.sql script in $ORACLE_HOME/rdbms/admin/ directory in order to create the DBA_BLOCKERS table.

However, sometimes killing the session simply won't work. In that case, you could have to kill the session, or an Oracle proces gone astray through UNIX system utilities.

For that purpose, on UNIX systems, Oracle has the V$PROCESS table, which can be joined with the V$SESSION table to find the UNIX process ID matching your Oracle session ID (the sid field of DBA_BLOCKERS).

The following query will yield you the needed system process ID (spid), among other useful information about your rogue process or session:

SELECT s.sid, s.serial#, s.username, s.osuser, p.spid, s.machine, p.terminal, s.program
FROM v$session s, v$process p
WHERE s.paddr = p.addr;

All you need to do now is to run a kill -9 spid  on your UNIX machine upon the process number given by the spid column of the above query.

Note: On a windows box, you would use the orakilll.exe utility located in $ORACLE_HOME/bin. Like this:
orakill $ORACLE_SID spid

Happy computing.

Drop me a comment if this post has been useful to you.
Alternatively, you could also visit a few links to keep me in business ;-)


Nixman