sandip's blog

Rewriting Sender addresses for Entire Domain in Sendmail

  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.

OpenVZ x86_64 Custom Config

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

cd /usr/share/vzpkgtools/vzrpm44/lib/python2.4/site-packages/rpm
cp /usr/lib64/python2.4/site-packages/rpm/_rpmmodule.so .

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

mkdir -p $VE_ROOT/var/lib/yum/ || abort "Can't create /var/lib/yum"

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

VZLIB_SCRIPTDIR=/usr/lib64/vzctl/scripts

Run to updatee the cached template:

vzpkgcache centos-5-x86_64-minimal

getent to check user and group

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

getent passwd <user_name>
getent group <group_name>

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.

uw-imap custom mail folder configuration

To allow custom mailbox folder for individual user:

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

set allow-user-config 1

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

set mail-subdirectory mail

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

Setup secure ProFTPd

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:

yum --enablerepo=epel install proftpd

Configure for tls/ssl connection:


<IfModule mod_tls.c>
TLSEngine                       on
TLSRequired                     off
TLSRSACertificateFile           /etc/pki/tls/proftpd/server.cert.pem
TLSRSACertificateKeyFile        /etc/pki/tls/proftpd/server.key.pem
TLSVerifyClient                 off
TLSRenegotiate                  required off
TLSLog                          /var/log/proftpd/tls.log
</IfModule>

chroot and bindsocket to listen to single IP:


SocketBindTight                 on
DefaultRoot                     ~

Setup passive ftp ports:

</Global>
...
...
PassivePorts 50000 51000
</Global>

Create the certs:

mkdir -p /etc/pki/tls/proftpd
cd /etc/pki/tls/proftpd
openssl req -new -x509 -days 9999 -nodes -out server.cert.pem -keyout server.key.pem

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

#%PAM-1.0
auth    required        pam_unix.so     nullok
account required        pam_unix.so
session required        pam_unix.so

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

useradd -s /bin/false <ftp_user>

Configure passive ports range for ProFTPd

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:

</Global>
...
...
# Use the IANA registered ephemeral port range
PassivePorts 49152 65534
</Global>

Reference: proftpd.org

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

# /sbin/modprobe ip_conntrack_ftp
#  lsmod | grep conntrack_ftp
ip_conntrack_ftp       41489  0
ip_conntrack           91237  4 xt_state,xt_conntrack,ip_conntrack_ftp,ip_conntrack_irc

Add the below iptables rules:

iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

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

# /sbin/modprobe ip_nat_ftp

defunct processes

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.

sendmail use of clientmqueue and mqueue folders

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:

# mailq -v -Ac

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.

Monitor outgoing emails in cPanel exim

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):

if not first_delivery
then
  finish
endif

Add the filter:

# Monitor outgoing emails from domain.tld
if first_delivery
   and ("$h_from:" contains "@domain.tld")
   and ("$h_from:" does not contain "youremail@")
then
   unseen deliver "monitor@domain.tld"
endif

Save changes and restart exim:

# /etc/init.d/exim restart

rpmdb: unable to lock mutex: Invalid argument

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.

Syndicate content
Comment