sandip's blog

1. Edit /etc/mail/sendmail.mc and add the below lines replacing domain.tld with the actual domain name:
   dnl # BEGIN: Rewriting Sender addresses for Entire Domain
dnl #
dnl # Process login names through the genericstable
FEATURE(`genericstable', `hash -o /etc/mail/genericstable.db')dnl
dnl # Interpret the value in G as a domain name
FEATURE(generics_entire_domain)dnl
dnl # masquerade not just the headers, but the envelope as well
FEATURE(masquerade_envelope)dnl
dnl # Load domain.tld into G
GENERICS_DOMAIN(domain.tld)dnl
dnl #
dnl # END: Rewriting Sender addresses for Entire Domain

2. Create /etc/mail/genericstable, which is very similar to an /etc/aliases, two columns separated by whitespace:
   web1_user1    user1@domain.tld
web1_user2    user2@domain.tld
web1_user3    user3@domain.tld

3. Create the db:
   # makemap -hash /etc/mail/genericstable < /etc/mail/genericstable

4. Restart sendmail.

Feature "genericstable" tells sendmail to use the generics table.

Feature "generics_entire_domain" allows to add hosts to genericstable without having to rebuild sendmail.cf.

Feature "masquerade_envelope" applies the rewriting process to the mail envelope as well as to the mail header.

"GENERICS_DOMAIN" defines the domains to which you wish to apply the generics table.

vzpkgcache seems to have been broken with latest CentOS-5.3 upgrade. Below is notes to fix:

Edit the file /usr/share/vzpkg/cache-os line 154, append:

Edit the file /usr/share/vzpkg/functions line 20, change to:

Run to updatee the cached template:

To check is user or group exist in passwd and group file:

You could also grep the corresponding files, but this is a much cleaner way of getting entries from administrative database where database is one of aliases, ethers, group, hosts, netgroup, networks, passwd, protocols, rpc, services or shadow.

To allow custom mailbox folder for individual user:

Add/Edit "/etc/c-client.cf":

Add/Edit "~/.imaprc" for corresponding user:

All corresponding email files will now reside in the ~/mail folder for the corresponding user.

Ftp can be secured using ftps to connect. Below outlines a configuration to support such a setup using TLS/SSL.

I usually use the epel repository to install proftpd:

Configure for tls/ssl connection:

chroot and bindsocket to listen to single IP:

Setup passive ftp ports:

Create the certs:

Create /etc/pam.d/ftp so PAM can authenticate for proftpd:

Add "/bin/false" to "/etc/shells" file and use it as the shell type when creating new users:

Usually, if a client is behind firewall, they can only trasfer files via a passive ftp connection.

Edit /etc/proftpd.conf and specify the passive ports range. Place it in the 'Global' container:

Reference: proftpd.org

Load the ip_conntrack_ftp module and iptables rules, so the ports automatically open to the connected client:

Add the below iptables rules:

If the server is beind NAT, ip_nat_ftp module also should be loaded:

When a process exits (normally or abnormally), it enters a state known as “zombie”, which in top appears as "Z". Its process ID stays in the process table until its parent waits on or "reaps" it. Under normal circumstances, when the parent process fully expects its child processes to exit, it sets up a signal handler for SIGCHLD so that, when the signal is sent (upon a child process's exit), the parent process then reaps it at its convenience.

As long as the parent hasn't called wait(), the system needs to keep the dead child in the global process list, because that's the only place where the process ID is stored. The purpose of the "zombies" is really just for the system to remember the process ID, so that it can inform the parent process about it on request.

If the parent "forgets" to collect on its children, then the zombie will stay undead forever. If the parent itself dies, then "init" (the system process with the ID 1) will take over fostership over its children and catch up on the neglected parental duties. If the init process is stalled, then you have much bigger problem than child processes not being reaped. In fact, a crashed init process will usually cause a kernel panic.

When submitting mail by using sendmail as a mail submission program, sendmail copies all messages to "/var/spool/clientmqueue" first. Sendmail is a setgid smmsp program and thus gives any user the permission to do so (/var/spool/clientmqueue belongs to user and group smmsp). Later, another sendmail process, the sendmail mail transfer agent (MTA) copies the messages from /var/spool/clientmqueue to /var/spool/mqueue and sends them to their destination.

/var/spool/clientmqueue is thus the holding area used by the MSP (Mail Submission Protocol) sendmail instance before it injects the messages into the main MTA (Mail Transport Agent) sendmail instance.

Sendmail will save the message in /var/spool/clientmqueue for safe keeping before trying to connect to the MTA to get the message delivered. Normally there would be a 'queue runner' MSP sendmail instance which every half hour would retry sending any message that couldn't be sent immediately. Each message will generate a 'df' (message routing info) and 'qf' (message headers and body) file. You can list out all of the messages and their status by:

When files accumulate in /var/spool/clientmqueue, this is probably due to sendmail localhost MTA not running, and thus the mails don't get send.

In cPanel WHM, Main > Service Configuration > Exim Configuration Editor:

Under Filters, check "System Filter File" location, usually at "/etc/cpanel_exim_system_filter".

Edit the file:

Just below (this should already exist):

Add the filter:

Save changes and restart exim:

I was caught by this when upgrading CentOS servers from 5.2 to 5.3. Should make it a habit to atleast read the release notes!!

When upgrading from an earlier version of Red Hat
Enterprise Linux to 5.3, you may encounter the following
error:

Updating : mypackage ################### [
472/1655]rpmdb: unable to lock mutex: Invalid argument

The cause of the locking issue is that the shared futex
locking in glibc was enhanced with per-process futexes
between 5.2 and 5.3. As a result, programs running against
the 5.2 glibc can not properly perform shared futex locking
against programs running with the 5.3 glibc.

This particular error message is a side effect of a package
calling rpm as part of its install scripts. The rpm
instance performing the upgrade is using the prior glibc
throughout the upgrade, but the rpm instance launched from
within the script is using the new glibc.

To avoid this error, upgrade glibc first in a separate run,
ie

# yum update glibc
# yum update

You will also see this error if you downgrade glibc to an
earlier version on an installed 5.3 system.