How I got sendmail to work......

As is well documented sendmail is tricky to get to work the way you want it to.....
So when I finally got it to work as required, it documented the process for my colleagues.....

biggest issue was how to make root mail look like it comes from a reverse lookup DNS entry on teh public network. each machine has address like <sitecode>ux123.<sitecode>.company.com which is fine. we masquerade all outbount mail as if it comes from user@company.com, again this is fine no problems. However, root is specifically restricted from teh masquerade and still comes out as root@<sitecode>ux123.<sitecode>.company.com THis makes sense as I do want to know which machine a root mail comes from. the problem is that many ( soo will be most ) external mail gateways and recipient machines will do a reverse DNS lookup to ensure that the sender is not being spoofed as a spam prevention.

We do have company.com with valid forward, reverse and MX DNS entries in the public internet. Most of our machines are in provate ip space 10.x.x.x, so these have to be NAT'd which is fine, but without a valid reverse lookup DNS on the internet, valid recipients of mail from root ( or any services started under the root user ) can be blocked.

So, in short, need to masquerade root as something other than root@company.com.

To achieve this we need to use sendmails genericstable. It is like an alias table four outbound mail ( aliases only take care of inbvound ). Just like aliases it needs to be compiled into a db format.

here is the procedure for Solaris and Aix ( will come back to HP/UX version....






Solaris 10



1. Create and edit a mc file in /etc/mail/cf/cf e.g. sendmail.mc and insert the following text:

VERSIONID(`@(#)sendmail.mc 1.11 (Sun) 06/21/04')
OSTYPE(`solaris8')dnl
DOMAIN(`solaris-generic')dnl
define(`confFALLBACK_SMARTHOST', `mailhost$?m.$m$.')dnl
define(`SMART_HOST', `smtprelay.site.compnany.com')dnl
FEATURE(`masquerade_envelope')dnl
MASQUERADE_AS(`company.com')dnl
FEATURE(genericstable)dnl
GENERICS_DOMAIN(`host.site.company.com')dnl
FEATURE(generics_entire_domain)
MAILER(`local')dnl
MAILER(`smtp')dnl


2. Compile the sendmail.mc file into a useable sendmail.cf file
/usr/ccs/bin/m4 ../m4/cf.m4 sendmail.mc >sendmail.cf

3. backup existing sendmail.cf and replace with new cf file
cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.
cp /etc/mail/cf/cf/sendmail.cf /etc/mail/sendmail.cf

4. Create /etc/mail/genericstable with list of userids to translate to other name e.g.
root superuser.host@company.com
jdoe dada@anothercompany.com

5. Change permissions on /etc/mail/genericstable to 600
6. Compile /etc/mail/genericstable into /etc/mail/genericstable.db
cd /etc/mail
makemap hash genericstable <genericstable
7. Change permissions on /etc/mail/genericstable.db to 600
8. restart sendmail service
svcadm restart svc:/network/smtp:sendmail



AIX Setup

1. Create and edit a mc file in /usr/samples/tcpip/sendmail/cf e.g. sendmail.mc and insert the following text:

include(`/usr/samples/tcpip/sendmail/m4/cf.m4')
OSTYPE(`aixsample')dnl
DOMAIN(`generic')dnl
define(`confFALLBACK_SMARTHOST', `mailhost$?m.$m$.')dnl
define(`SMART_HOST', `smtprelay.site.company.com')dnl
FEATURE(`masquerade_envelope')dnl
MASQUERADE_AS(`company.com')dnl
FEATURE(genericstable)dnl
GENERICS_DOMAIN(`host.site.company.com')dnl
FEATURE(generics_entire_domain)
MAILER(`local')dnl
MAILER(`smtp')dnl


2. Compile the sendmail.mc file into a useable sendmail.cf file
/usr/bin/m4 sendmail.mc >sendmail.cf

3. backup existing sendmail.cf and replace with new cf file
cp /etc/mail/sendmail.cf /etc/mail/sendmail.cf.<datestring>
cp usr/samples/tcpip/sendmail/cf/sendmail.cf /etc/mail/sendmail.cf

4. Create /etc/mail/genericstable with list of userids to translate to other name e.g.
root hostname.superuser@company.com
myusern first.last@anothercompany.com
5. touch /etc/mail/local-host-names
6. Change permissions on /etc/mail/genericstable to 600
7. Compile /etc/mail/genericstable into /etc/mail/genericstable.db
cd /etc/mail
makemap hash genericstable < genericstable

8. Change permissions on /etc/mail/genericstable.db to 600
9. restart sendmail service
stopsrc -s sendmail
startsrc -s sendmail -a "-bd -q30m"

Why SAN is rubbish...or how to make a Solaris host see new stuff WITHOUT having to reboot

I noticed that SAN admins like to say, just reboot the host and it will see the new WWN's and devices.......

Well guess what, Unix hosts ( and linux too I guess) should need to be rebooted about once a decade if they are set up right. (Microsoft are making efforts in this area too.....)

I should not need to reboot for something as trivial as adding a new bit of storage. This is supposed to be enterprise equipment after all.

I get pretty cut up about SAN's fibre channel lack of what I would consider pretty basic functionality.

Basically, evey san device has a unique ID right, just like ethernet. SAN is a packet based network for Storage......so why cannot it be used like ethernet?

Imagine if your server vendors told you that every time you added another device on the IP network, you had to reboot every machine you wantted to talk to it?

I am not talking 2bit SAN here either. I have the same problems with HDS USPV, EMC Symmetrix, EMC Clariion, Cisco MDS 9513 Directors ( Director sounds so much classier than switch, lets double the price...) Multi-million dollar equipment.

Ok, rant over......here come the useful bit.....apologies if my tech terms are a bit off....only the SAN guys really care about Front end ports, back end directors, WWNs etc. Most Unix admins just want to know how to get to the point where the host sees the disk so they can start building volumes and filsystems.

Option 3 below has worked for me every time, I have yet to find a solaris 10 box that it didnt work on.

I came to the conclusion that a reboot should not be necessary, all I needed to do was find out what the server did when initializing the HBA ( host bus adaptor, { again, just a classy name for a SAN network card, which costs about $4k })

So here are some Solaris 10 commands that I have used to detect new SAN equipment that is zoned to the host. ( i have been mostly working on Solaris for the last year. Not because of preference but because of commercial issues, where my employer decided to use Sun rather than another vendor. ) I guess there should be similar functionality on Aix and HP/UX but I havent yet had a need to find out .....

I assume you are root for all the below. If you dont know what that means, then I cant help you much.....Reboot the server ( gently ) like the SAN folks told you.
Also, I use ksh, and am too lazy to port to other shells.

There are 3 basic scenarios:

1. Adding a lun from the same SAN and front end ports (WWN ) and SCSI target that is already hosting some LUNs you are using on the Solaris server:

In this case you have already established the hba<->SAN communication and you are just registering a new LUN.

just running "devfsadm" should be enough to allow you see the new LUN(s)

2. Adding new LUNs from a same SAN and front end ports but different SCSI target:

Here you need to probe the controllers to see if they can register new devices

#! /bin/ksh
fcinfo hba-port | grep "^HBA"| awk '{print $4 }' | while read ln
do
fcinfo remote-port -p $ln -s >/dev/null 2>&1
done

devfsadm

3. Lastly for new SAN arrays you have to find all the hba's and force them to do a link initialization protocol so that they start talking to whatever is out there. This is what the host does on re-boot. I have dont this on production hosts with no ill effects but it ti possible it could cause some interruption to existing data flow so use with care and only if you need to MUST.  From experience there is a medium risk of File System corruption

Find which controllers are present:
cfgadm -la | grep fc-fabric
Force Link Initialisation Protocal for each controller you find:
luxadm -e forcelip /dev/cfg/c2
****Stop, wait 5 mins, get a coffee, it can take time for the hba to come back up and mpathadm to recover the paths via the controller you reset.  If you dont wait you will likely lose all good paths to the LUN, which gives an IO error and likely corrupts your filesystem.  Very BAD****
luxadm -e forcelip /dev/cfg/c4
Check what the hba's can see ( if you want to ):
luxadm -e dump_map /dev/cfg/c2
luxadm -e dump_map /dev/cfg/c4
Go check the newly discovered WWNs for LUNs:
#! /bin/ksh
fcinfo hba-port | grep "^HBA"| awk '{print $4 }' | while read ln
do
fcinfo remote-port -p $ln -s >/dev/null 2>&1
done
Configure the LUNs onto your server:
cfgadm -c configure c2
cfgadm -c configure c4

Check if you got them:

cfgadm -la | grep c2
cfgadm -la | grep c4

Install the disk devices into Solaris:
devfsadm

You can then do what you need via format / Solaris Volume manager / Veritas or whatever