Pages

Wednesday, 4 July 2012

Difference between prefork MPM and worker MPM in apache


Difference between prefork MPM and worker MPM in apache

What are MPM? 
'Multi Processing Modules' aka MPM are modules that extends apache's capability to implement a hybrid multi-process multi-threaded server.

The default MPM for Unix is the Prefork module.
The Worker MPM was introduced in Apache2.

MPM uses a multi-process and multi-threaded structure.
Multi-process
--> multi PIDs (use 'ps -aef' to find out)
Multi-thread --> more connections per PID. (use 'lsof' to find out. 'netstat -an' don't really see everything.)

The parent process (the one belonging to root) is started up which in turn start up the child processes.

Each child process creates a fixed number of threads as specified in the ThreadsPerChild directive.

Apache always try to maintain a pool of spare threads, which stand ready to serve incoming requests. The number of processes that will initially launched is set by the StartServers directive. Apache will try to keep the number of spare threads within the boundaries specified by MinSpareThreads and MaxSpareThreads.

The maximum number of clients that may be served simultaneously will equal to the maximum total number of threads in all processes. This is set using MaxClients directive.

Therefore, no of processes or PIDs you can have is

no of processes = MaxClients / ThreadsPerChild

Comparing Worker MPM and Prefork MPM,

Worker MPM
- worker MPM uses multiple child processes with many thread each.
- Each thread handle one connection at a time.
- Good for high-traffic, smaller memory footprint.

Prefork MPM
- prefork MPM uses multiple child processes with one thread each.
- Each process handle one connection at a time. uses more memory.
- Good for non-thread-safe third party modules.

Prefork MPM is prefered for better compatibility with older softwares or for better stability although it uses more memories.

Note that we can have one and only MPM module loaded in apache at any one time.

How to check which MPM is compiled?

# httpd -l
Compiled in modules:
core.c
prefork.c
http_core.c
mod_so.c

Reference: http://httpd.apache.org/docs/2.0/mod/worker.html

How to install and configure sendmail?


How to install and configure sendmail?

1. Install :

#yum install sendmail*
#yum install m4*

2.
vi /etc/mail/sendmail.mc

Make commented like to accept all network :

----
dnl # DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl
----

save this file.

3. Execute following command :

#m4 /etc/mail/sendmail.mc > /etc/mail/sendmail.cf

4. Dont forget to add the following line to your /etc/hosts.allow file:

----
sendmail: ALL
----

5. Set DAEMON to yes in /etc/sysconfig/sendmail

----
DAEMON=yes
QUEUE=1h
----

5. Do following :

#chkconfig sendmain on
#service sendmail start

Testing :

1. Check whether port listens :

#netstat -tulpn | grep 25
#telnet localhost 25
#telnet IP 25

2. Above are fine then send a mail :

#echo test | mail -s test-subject -v


Note : sendmail configurations files are inside /etc/mail/. Log is inside /var/log/maillog.

Tuesday, 3 July 2012

How sendmail works?

How sendmail works?
Outbound email :

1. MUA passes the email to sendmail , which creates in the /var/spool/mqueue (mail queue) directory two files that hold the message while sendmail processes it.
2. To create a unique filename for a particular piece of email, sendmail generates a random string and uses that string in filenames pertaining to the email.
3. The sendmail daemon stores the body of the message in a file named df (data file) followed by the generated string.
4. It stores the headers and other information in a file named qf (queue file) followed by the generated string.
5. If a delivery error occurs, sendmail creates a temporary copy of the message that it stores in a file whose name starts with tf (temporary file) and logs errors in a file whose name starts xf .
6. Once an email has been sent successfully, sendmail removes all files pertaining to that email from /var/spool/mqueue .

Incoming email :

1. By default, the MDA stores incoming messages in users' files in the mail spool directory, /var/spool/mail , in mbox format. Within this directory, each user has a mail file named with the user's username. Mail remains in these files until it is collected, typically by an MUA. Once an MUA collects the mail from the mail spool, the MUA stores the mail as directed by the user, usually in the user 's home directory hierarchy.

mbox versus maildir :

1. The mbox format stores all messages for a user in a single file. To prevent corruption, the file must be locked while a process is adding messages to or deleting messages from the file; you cannot delete a message at the same time the MTA is adding messages. A competing format, maildir , stores each message in a separate file. This format does not use locks, allowing an MUA to read and delete messages at the same time as new mail is delivered. In addition, the maildir format is better able to handle larger mailboxes

Mail logs :

# cat/var/log/maillog
...
Mar 3 16:25:33 MACHINENAME sendmail[7225]: i23GPXvm007224:
to=, ctladdr=
(0/0), delay=00:00:00, xdelay=00:00:00, mailer=local, pri=30514,
dsn=2.0.0, stat=Sent


Each log entry starts with a timestamp, the name of the system sending the email, the name of the mail server ( sendmail ), and a unique identification number. The address of the recipient follows the to= label and the address of the sender follows ctladdr= . Additional fields provide the name of the mailer and the time it took to send the message. If a message is sent correctly, the stat= label is followed by Sent .

Aliases and Forwarding :

Three files can forward email: .forward (page 634), aliases (discussed next ), and virtusertable (page 640). Table 20-1 on page 640 compares the three files.
Table 20-1. Comparison of forwarding techniques


.forward aliases virtusertable

Controlled by non root user root root

Forwards email
addressed to "non root user" "Any real or virtual user on the local system" "Any real or virtual user on any domain recognized by sendmail"

Order of precedence Third Second First

/etc/aliases

Most of the time when you send email, it goes to a specific person; the recipient, user@system , maps to a specific, real user on the specified system. Sometimes you may want email to go to a class of users and not to a specific recipient. Examples of classes of users include postmaster , webmaster , root , and tech_support . Different users may receive this email at different times or the email may be answered by a group of users. You can use the /etc/aliases file to map inbound addresses to local users, files, commands, and remote addresses.

Each line in /etc/aliases contains the name of a local pseudouser, followed by a colon , whitespace, and a comma-separated list of destinations. The default installation includes a number of aliases that redirect messages for certain pseudousers to root . These have the form

system: root


Sending messages to the root account is a good way of making them easy to review. However, because root 's email is rarely checked, you may want to send copies to a real user. The following line forwards mail sent to abuse on the local system to root and alex :

abuse: root, alex


You can create simple mailing lists with this type of alias. For example, the following alias sends copies of all email sent to admin on the local system to several users, including Zach, who is on a different system:

admin: sam, helen, mark, zach@redhat.com


You can direct email to a file by specifying an absolute pathname in place of a destination address. The following alias, which is quite popular among less conscientious system administrators, redirects email sent to complaints to /dev/null where they disappear:

complaints: /dev/null


You can also send email to standard input of a command by preceding the command with a pipe character ( | ). This technique is commonly used with mailing list software such as Mailman. For each list it maintains, Mailman has entries, such as the following entry for mylist , in the aliases file:

mylist: "|/usr/lib/mailman/mail/mailman post mylist"


newaliases

After you edit /etc/aliases , you must either run newaliases as root or restart sendmail to recreate the aliases.db file that sendmail reads.

praliases

You can use praliases to list aliases currently loaded by sendmail :

# /usr/sbin/praliases| head-5
postmaster:root
daemon:root
adm:root
lp:root
shutdown:root


~/.forward

Systemwide aliases are useful in many cases, but non root users cannot make or change them. Sometimes you may want to forward your own mail: Maybe you want mail from several systems to go to one address or perhaps you just want to forward your mail while you are working at another office for a week. The ~/.forward file allows ordinary users to forward their email.

Lines in a .forward file are the same as the right column of the aliases file explained previously: Destinations are listed one per line and can be a local user, a remote email address, a filename, or a command preceded by a pipe character ( | ).

Mail that you forward does not go to your local mailbox. If you want to forward mail and keep a copy in your local mailbox, you must specify your local username preceded by a backslash to prevent an infinite loop. The following example sends Sam's email to himself on the local system and on the system at tcorp.com :

$ cat ~sam/.forward
sams@tcorp.com
\sam


Related Programs

sendmail

The sendmail package includes several programs. The primary program, sendmail , reads from standard input and sends an email to the recipient specified by its argument. You can use sendmail from the command line to check that the mail delivery system is working and to email the output of scripts.

mailq

The mailq utility displays the status of the outgoing mail queue and normally reports there are no messages in the queue. Messages in the queue usually indicate a problem with the local or remote sendmail configuration or a network problem.

# /usr/bin/mailq
/var/spool/mqueue is empty
Total requests: 0


mailstats

The mailstats utility reports on the number and sizes of messages sendmail has sent and received since the date it displays on the first line:

# /usr/sbin/mailstats
Statistics from Sat Dec 24 16:02:34 2005
M msgsfr bytes_from msgsto bytes_to msgsrej msgsdis Mailer
0 0 0K 17181 103904K 0 0 prog
4 368386 4216614K 136456 1568314K 20616 0 esmtp
9 226151 26101362K 479025 12776528K 4590 0 local
============================================================
T 594537 30317976K 632662 14448746K 25206 0
C 694638 499700 146185


In the preceding output, each mailer is identified by the first column, which displays the mailer number, and by the last column, which displays the name of the mailer. The second through fifth columns display the number and total sizes of messages sent and received by the mailer. The sixth and seventh columns display the number of messages rejected and discarded respectively. The row that starts with T lists the column totals, and the row that starts with C lists the number of TCP connections.

Setting Up a Backup Server

You can set up a backup mail server to hold email when the primary mail server experiences problems. For maximum coverage, the backup server should be on a different connection to the Internet from the primary server.

Setting up a backup server is easy. Just remove the leading dnl from the following line in the backup mail server's sendmail.mc file:

dnl FEATURE('relay_based_on_MX')dnl


DNS MX records (page 726) specify where email for a domain should be sent. You can have multiple MX records for a domain, each pointing to a different mail server. When a domain has multiple MX records, each record usually has a different priority; the priority is specified by a two-digit number, where lower numbers specify higher priorities.

When attempting to deliver email, an MTA first tries to deliver email to the highest-priority server. If that delivery attempt fails, it tries to deliver to a lower-priority server. If you activate the relay_based_on_MX feature and point a low-priority MX record at a secondary mail server, the mail server will accept email for the domain. The mail server will then forward email to the server identified by the highest-priority MX record for the domain when that server becomes available.


Other Files in /etc/mail :

The /etc/mail directory holds most of the files that control sendmail . This section discusses three of those files: mailertable , access , and virtusertable .
mailertable : Forwards Email from One Domain to Another

When you run a mail server, you may want to send mail destined for one domain to a different location. The sendmail daemon uses the /etc/mail/mailertable file for this purpose. Each line in mailertable holds the name of a domain and a destination mailer separated by whitespace; when sendmail receives email for the specified domain, it forwards it to the mailer specified on the same line. Red Hat enables this feature by default: Put an entry in the mailertable file and restart sendmail to use it.

The following line in mailertable forwards email sent to tcorp.com to the mailer at bravo.com :

$ cat /etc/mail/mailertable
tcorp.com smtp:[bravo.com]


The square brackets in the example instruct sendmail not to use MX records but rather to send email directly to the SMTP server. Without the brackets, email could enter an infinite loop.

A period in front of a domain name acts as a wildcard and causes the name to match any domain that ends in the specified name. For example, .tcorp.com matches sales.tcorp.com , mktg.tcrop.com , and so on.

The sendmail init script regenerates mailertable.db from mailertable each time you run it, as when you restart sendmail .
access : Sets Up a Relay Host

On a LAN, you may want to set up a single server to process outbound mail, keeping local mail inside the network. A system that processes outbound mail for other systems is called a relay host . The /etc/mail/access file specifies which systems the local server relays email for. As configured by Red Hat, this file lists only the local system:

$ cat /etc/mail/access
...
# by default we allow relaying from localhost...
localhost.localdomain RELAY
localhost RELAY
127.0.0.1 RELAY


You can add systems to the list in access by adding an IP address followed by whitespace and the word RELAY . The following line adds the 192.168. subnet to the list of hosts that the local system relays mail for:

192.168. RELAY


The sendmail init script regenerates access.db from access each time you run it, as when you restart sendmail .
virtusertable : Serves Email to Multiple Domains

When the DNS MX records are set up properly, a single system can serve email to multiple domains. On a system that serves mail to many domains, you need a way to sort the incoming mail so that it goes to the right places. The virtusertable file can forward inbound email addressed to different domains ( aliases cannot do this).

As sendmail is configured by Red Hat, virtusertable is enabled. You need to put forwarding instructions in the /etc/mail/virtusertable file and restart sendmail to serve the specified domains. The virtusertable file is similar to the aliases file (page 633), except the left column contains full email addresses, not just local ones. Each line in virtusertable starts with the address that the email was sent to, followed by whitespace and the address sendmail will forward the email to. As with aliases , the destination can be a local user, an email address, a file, or a pipe symbol ( | ), followed by a command.

The following line from virtusertable forwards mail addressed to zach@tcorp.com to zcs , a local user:

zach@tcorp.com zcs


You can also forward email for a user to a remote email address:

sams@bravo.com sams@tcorp.com


You can forward all email destined for a domain to another domain without specifying each user individually. To forward email for every user at bravo.com to tcorp.com , specify @bravo.com as the first address on the line. When sendmail forwards email, it replaces the %1 in the destination address with the name of the recipient. The next line forwards all email addressed to bravo.com to tcorp.com , keeping the original recipients' names :

@bravo.com %1@tcorp.com


Finally you can specify that email intended for a specific user should be rejected by using the error namespace in the destination. The next example bounces email addressed to spam@tcorp.com with the message 5.7.0:550 Invalid address :

spam@tcorp.com error:5.7.0:550 Invalid address

firmware of Ethernet(NIC) and firmware that comes along with Linux kernel

I would like to just clarify about the firmware of Ethernet(NIC) and firmware that comes along with Linux kernel. Both are two different but their aim is same. Hardware vendor deploys firmware(certain amount of code or program to interact with hardware) in NVRAM (non-volatile RAM not normal RAM). Once we attach the NIC with machine it'll be automatically activated. We can view its version like :

#ethtool -i eth0

Now kernel also contains firmware. This will be loaded in RAM and will override on vendor provided firmware. So, this firmware will be taking care of NIC now. Most of the kernel contains such firmware for NIC. Only difference is that it won't show in "ethtool -i eth0" output.

How to check details of the rpm pacakge which is yet not installed?


How to check details of the rpm pacakge which is yet not installed?
Pass "-qpil" to rpm command. As an example :

#rpm -qpil tftp-0.49-7.el6.x86_64.rpm

Name : tftp Relocations: (not relocatable)
Version : 0.49 Vendor: Red Hat, Inc.
Release : 7.el6 Build Date: Mon 18 Jul 2011 03:10:21 PM EDT
Install Date: (not installed) Build Host: x86-002.build.bos.redhat.com
Group : Applications/Internet Source RPM: tftp-0.49-7.el6.src.rpm
Size : 46554 License: BSD
Signature : (none)
Packager : Red Hat, Inc.
URL : http://www.kernel.org/pub/software/network/tftp/
Summary : The client for the Trivial File Transfer Protocol (TFTP)
Description :
The Trivial File Transfer Protocol (TFTP) is normally used only for
booting diskless workstations. The tftp package provides the user
interface for TFTP, which allows users to transfer files to and from a
remote machine. This program and TFTP provide very little security,
and should not be enabled unless it is expressly needed.
/usr/bin/tftp
/usr/share/doc/tftp-0.49
/usr/share/doc/tftp-0.49/CHANGES
/usr/share/doc/tftp-0.49/README
/usr/share/doc/tftp-0.49/README.security
/usr/share/doc/tftp-0.49/README.security.tftpboot
/usr/share/man/man1/tftp.1.gz

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

To check details of installed package :

#rpm -qi tftp-0.49-7.el6.x86_64

Name : tftp Relocations: (not relocatable)
Version : 0.49 Vendor: Red Hat, Inc.
Release : 7.el6 Build Date: Mon 18 Jul 2011 03:10:21 PM EDT
Install Date: Fri 19 Aug 2011 06:02:18 PM EDT Build Host: x86-002.build.bos.redhat.com
Group : Applications/Internet Source RPM: tftp-0.49-7.el6.src.rpm
Size : 46554 License: BSD
Signature : (none)
Packager : Red Hat, Inc.
URL : http://www.kernel.org/pub/software/network/tftp/
Summary : The client for the Trivial File Transfer Protocol (TFTP)
Description :
The Trivial File Transfer Protocol (TFTP) is normally used only for
booting diskless workstations. The tftp package provides the user
interface for TFTP, which allows users to transfer files to and from a
remote machine. This program and TFTP provide very little security,
and should not be enabled unless it is expressly needed
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Show dependencies of a RPM package : 

#rpm -qp -requires .rpm

Friday, 22 June 2012

Kdump Configuration


Kdump Configuration 
Configure kdump to analyse Linux kernel crash and kernel panics.

Linux kernel crash and panics and the reason behind it is analyzed with the help of kdump utility.
Kdump is a crash dumping mechanism and it uses the context of another kernel at boot time to capture the crash and core dump. The context of the kernel reserves a small amount of memory, and its only purpose is to capture the core dump of the crashed kernel.

Following are the steps to configure kdump from command prompt.

Login as a user root and edit /boot/grub/grub.conf file, and add the crashkernel=M parameter to the list of kernel options. After editing grub.conf file looks like as follows:

# grub.conf generated by anaconda
#
# Note that you do not have to rerun grub after making changes to this file
# NOTICE: You have a /boot partition. This means that
# all kernel and initrd paths are relative to /boot/, eg.
# root (hd0,0)
# kernel /vmlinuz-version ro root=/dev/sda3
# initrd /initrd-version.img
#boot=/dev/sda
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.18-194.8.1.el5)
root (hd0,0)
kernel /vmlinuz-2.6.18-194.8.1.el5 ro root=/dev/sda3 crashkernel=128M
initrd /initrd-2.6.18-194.8.1.el5.img

Now configure the target location in /etc/kdump.conf file. The default file location to store dump file i.e. vmcore files in the /var/crash/ directory of the local system.
It is also possible to save the file on remote location using NFS and SCP, but these techniques are not written here.

Edit /etc/kdump.conf file:
To change the local directory in which the core dump is to be saved, remove the hash sign (“#”) from the beginning of the #path /var/crash line, and replace the value with a desired directory path.

ext3 /dev/sda4
path /usr/local/cores

To write the dump directly to a device, remove the hash sign (“#”) from the beginning of the #raw /dev/sdc5 line, and replace the value with a desired device name. For example:
raw /dev/sdb1

Also possible to configure dump core using core collector. To reduce the size of the vmcore we can use makedumpfile utility.
To enable core collector search for core_collector directive in /etc/kdump.conf file and uncomment it if it is not.

core_collector makedumpfile –c

To remove the unwanted pages from the dump file we can pass –d option to core_collector.

core_collector makedumpfile -d –c
where Numeric value is a sum of values of pages we want to omit.

Option Page type to omit
1 Zero Pages
2 Cache Pages
4 Cache Private
8 User Pages
16 Blank Pages

Now all we need is to start the kdump service on boot time.

#chkconfig kdump on
Start the kdump service.

# service kdump start
No kdump initial ramdisk found. [WARNING]
Rebuilding /boot/initrd-2.6.18-194.8.1.el5kdump.img
Starting kdump: [ OK ]

Test the kdump configuration.
To test the configuration, reboot the system with kdump enabled, and make sure that the service is running:

# service kdump status
Kdump is operational
Then type the following commands at a shell prompt:
# echo 1 > /proc/sys/kernel/sysrq
# echo c > /proc/sysrq-trigger

The above command makes Linux kernel to crash, and the YYYY-MM-DD-HH:MM/vmcore file will be copied to the location we have selected in the configuration.

Analyze the core dump:
To analyze the crash kernel we need to packages and they are crash and kernel-debuginfo.

Now all we need to start the crash utility.

crash /var/crash/timestamp/vmcore /usr/lib/debug/lib/modules/kernel/vmlinux.

At the crash prompt we can run several commands like
Crash> log ## Display the mesg buffer
Crash>bt ## backtrace
Crash>[ps | vm | files] ## Refer man page for more options.

Sunday, 17 June 2012

Repairing File Systems with fsck in AIX V5 (LED 517 or 518)

Question
Repairing File Systems with fsck in AIX V5 or V6 (LED 517 or 518)

Answer
This document covers the use of the fsck (file system check) command in Maintenance mode to repair inconsistencies in file systems. The procedure described is useful when file system corruption in the primary root file systems is suspected or, in many cases, to correct an IPL hang at LED value 517, 518, or LED value 555.

This document applies to AIX version 5.x, 6.x, and VIOS LPAR. 

Recovery procedure 

Boot your system into a limited function maintenance shell (Service, or Maintenance mode) from AIX bootable media to perform file system checks on your root file systems.

With bootable media of the same version and level as the system, boot the system. If this is a VIOS LPAR, use the correct VIOS media. The bootable media can be any ONE of the following: 

Bootable CD-ROM
NON_AUTOINSTALL mksysb
Bootable Install Tape

Follow the screen prompts to the following menu: 

Welcome to Base Operating System 
Installation and Maintenance

Choose Start Maintenance Mode for System Recovery (Option 3).
The next screen displays the Maintenance menu.


Choose Access a Root Volume Group (Option 1).
The next screen displays a warning that indicates you will not be able to return to the Base OS menu without rebooting.


Choose 0 continue.
The next screen displays information about all volume groups on the system.


Select the root volume group by number.
Choose Access this volume group and start a shell before mounting file systems (Option 2).

If you get errors from the preceding option, do not continue with the rest of this procedure. Correct the problem causing the error. If you need assistance correcting the problem causing the error, contact one of the following:
local branch office
your point of sale
your AIX support center

If no errors occur, proceed with the following steps.

Run the following commands to check and repair file systems.
NOTE: The -y option gives fsck permission to repair file system corruption when necessary. This flag can be used to avoid having to manually answer multiple confirmation prompts, however, use of this flag can cause permanent, unnecessary data loss in some situations. 

fsck /dev/hd4 
fsck /dev/hd2 
fsck /dev/hd3 
fsck /dev/hd9var 
fsck /dev/hd1

To format the default jfslog for the rootvg Journaled File System (JFS) file systems, run the following command:

 /usr/sbin/logform /dev/hd8 

Answer yes when asked if you want to destroy the log.


If your system is hanging at LED 517 or 518 during a Normal mode boot, it is possible the /etc/filesystems file is corrupt or missing. To temporarily replace the disk-based /etc/filesystems file, run the following commands: 

mount /dev/hd4 /mnt 
mv /mnt/etc/filesystems /mnt/etc/filesystems.[MMDDYY] 
cp /etc/filesystems /mnt/etc/filesystems 
umount /mnt


MMDDYY represents the current two-digit representation of the Month, Day and Year, respectively.


Type exit to exit from the shell. The file systems should automatically mount after you type exit. If you receive error messages, reboot into a limited function maintenance shell again to attempt to address the failure causes.


If you have user-created file systems in the rootvg volume group, run fsck on them now. Enter:

 fsck /dev/[LVname]


LVname is the name of your user-defined logical volume.


If you used the preceding procedure to temporarily replace the /etc/filesystems file, and you have user-created file systems in the rootvg volume group, you must also run the following command: 

imfs -l /dev/[LVname]



If you used the preceding procedure to temporarily replace the /etc/filesystems file, also run the following command: 

imfs [VGname]


The preceding commands can be repeated for each user-defined volume group on the system.


If your system was hanging at LED 517 or 518 and you are unable to activate non-rootvg volume groups in Service mode, you can manually edit the /etc/filesystems file and add the appropriate entries.

The file /etc/filesystems.MMDDYY saved in the preceding steps may be used as a reference if it is readable. However, the imfs method is preferred since it uses information stored in the logical volume control block to re-populate the /etc/filesystems file.


If your system has a mode select key, turn it to the Normal position.


Reboot the system into Normal mode using the following command:

sync;sync;sync;reboot 
Twitter Bird Gadget