Server Redundancy - Clustering info

Server Redundancy

Server redundancies include failover clusters and load balancing. Failover clusters remove a
server as a single point of failure. If one node in a cluster fails, another node can take over.


Some services require a high level of availability and it’s possible to achieve 99.999 percent
uptime, commonly called five nines. It equates to less than 6 minutes of downtime a year: 60 minutes
× 24 hours × 365 days × .00001 = 5.256 minutes. Failover clusters are a key component used to
achieve five nines.

Although five nines is achievable, it’s expensive. However, if the potential cost of an outage is
high, the high cost of the redundant technologies is justified. For example, some web sites generate a
significant amount of revenue, and every minute a web site is unavailable represents lost money.
High-capacity failover clusters ensure the service is always available even if a server fails.

Failover Clusters for High Availability

The primary purpose of a failover cluster is to provide high availability for a service offered by
a server. Failover clusters use two or more servers in a cluster configuration, and the servers are
referred to as nodes. At least one server or node is active and at least one is inactive. If an active
node fails, the inactive node can take over the load without interruption to clients.
Consider Figure 9.1, which shows a two-node failover cluster. Both nodes are individual
servers, and they both have access to external data storage used by the active server. Additionally, the
two nodes have a monitoring connection to each other used to check the health or heartbeat of each
other.

Figure 9.1: Failover cluster
Imagine that Node 1 is the active node. When any of the clients connect, the cluster software
(installed on both nodes) ensures that the clients connect to the active node. If Node 1 fails, Node 2
senses the failure through the heartbeat connection and configures itself as the active node. Because
both nodes have access to the shared storage, there is no loss of data for the client. Clients may notice
a momentary hiccup or pause, but the service continues.

You might notice that the shared storage in Figure 9.1 represents a single point of failure. It’s not
uncommon for this to be a robust hardware RAID-6. This ensures that even if two hard drives in the
shared storage fails, the service will continue. Additionally, if both nodes are plugged into the same
power grid, the power represents a single point of failure. They can each be protected with a separate
uninterruptible power supply (UPS), and use a separate power grid.

Cluster configurations can include many more nodes than just two. However, nodes need to have
close to identical hardware and are often quite expensive, but if a company truly needs to achieve
99.999 percent uptime, it’s worth the expense

Disk Redundancies - RAID

Disk Redundancies

Any system has four primary resources: processor, memory, disk, and the network interface. Of
these, the disk is the slowest and most susceptible to failure. Because of this, administrators often
upgrade disk subsystems to improve their performance and redundancy.

Redundant array of inexpensive disks (RAID) subsystems provide fault tolerance for disks and
increase the system availability. Even if a disk fails, most RAID subsystems can tolerate the failure
and the system will continue to operate. RAID systems are becoming much more affordable as the
price of drives steadily falls and disk capacity steadily increases.

A redundant array of inexpensive disks (RAID) system would provide fault tolerance for disk drives and increase data availability if drives fail.
A cluster provides fault tolerance at the server level and ensures a service continues to operate even if a server fails. However, a cluster is more expensive than a RAID.

RAID-0
RAID-0 (striping) is somewhat of a misnomer because it doesn’t provide any redundancy or
fault tolerance. It includes two or more physical disks. Files stored on a RAID-0 array are spread
across each of the disks.
The benefit of a RAID-0 is increased read and write performance. Because a file is spread
across multiple physical disks, the different parts of the file can be read from or written to each of the
disks at the same time. If you have three 500 GB drives used in a RAID-0, you have 1500 GB (1.5
TB) of storage space.

RAID-1
RAID-1 (mirroring) uses two disks. Data written to one disk is also written to the other disk. If
one of the disks fails, the other disk still has all the data, so the system can continue to operate without any data loss. With this in mind, if you mirror all the drives in a system, you can actually lose half of the drives and continue to operate.

You can add an additional disk controller to a RAID-1 configuration to remove the disk
controller as a single point of failure. In other words, each of the disks also has its own disk
controller. Adding a second disk controller to a mirror is called disk duplexing.
If you have two 500 GB drives used in a RAID-1, you have 500 GB of storage space. The other
500 GB of storage space is dedicated to the fault-tolerant, mirrored volume.

RAID-2, RAID 3, and RAID-4 are rarely used.

RAID-5 and RAID-6
A RAID-5 is three or more disks that are striped together similar to RAID-0. However, the
equivalent of one drive includes parity information. This parity information is striped across each of
the drives in a RAID-5 and is used for fault tolerance. If one of the drives fails, the system can read
the information on the remaining drives and determine what the actual data should be. If two of the
drives fail in a RAID-5, the data is lost.
RAID-6 is an extension of RAID-5, and it includes an additional parity block. A huge benefit is
that the RAID-6 disk subsystem will continue to operate even if two disk drives fail. RAID-6
requires a minimum of four disks.

Remember this
RAID subsystems, such as RAID-1, RAID-5, and RAID-6, provide fault
tolerance and increased data availability. RAID-5 can survive the failure of
one disk. RAID-6 can survive the failure of two disks.

RAID-10
A RAID-10 configuration combines the features of mirroring (RAID-1) and striping (RAID-0).
RAID-10 is sometimes called RAID 1+0. A variation is RAID-01 or RAID 0+1 that also combines
the features of mirroring and striping but implements the drives a little differently.

Software Versus Hardware RAID
Hardware RAID configurations are significantly better than software RAID. In hardware RAID,
dedicated hardware manages the disks in the RAID, removing the load from the operating system. In
contrast, the operating system manages the disks in the RAID array in software RAID. Hardware
RAID systems provide better overall performance and often include extra features.
For example, a hardware RAID may include six physical disks using four in an active RAID-6
configuration and two as online spares. If one of the active disks in the RAID-6 fails, the RAID will
continue to operate because a RAID-6 can tolerate the failure.

However, a hardware RAID can logically take the failed disk out of the configuration, add one
of the online spares into the configuration, and rebuild the array. All of this happens without any
administrator intervention. Hardware RAID systems are often hot swappable, allowing
administrators to swap out the failed drive without powering the system down.

Source: Darril Gibson 

NoSQL Versus SQL Databases

NoSQL Versus SQL Databases
Server-based SQL databases are traditional relational databases using tables that relate to each
other in one way or another. They are very effective in many situations, but not all. A newer type of
database has emerged known as not only SQL (NoSQL).
NoSQL databases typically hold one or more of the following types of data: documents, keyvalue
pairs, or graphs. Documents are formatted in a specific way and each document represents an
object. This is similar to how a table holds data in rows. However, the document-based NoSQL
database gives developers much more flexibility in how they can store and query the data.
Both NoSQL and SQL databases are susceptible to command injection attacks if developers do
not implement input validation techniques. SQL databases use SQL queries and are susceptible to
SQL injection attacks. NoSQL databases use unstructured query language (UQL) queries. Although the
format of UQL queries varies with different vendors, attackers can learn them and use them when
developers do not implement input validation techniques

Buffer Overflows and Buffer Overflow Attacks

Buffer Overflows and Buffer Overflow Attacks

A buffer overflow occurs when an application receives more input, or different input, than it
expects. The result is an error that exposes system memory that would otherwise be protected and
inaccessible. Normally, an application will have access only to a specific area of memory, called a
buffer. The buffer overflow allows access to memory locations beyond the application’s buffer,
enabling an attacker to write malicious code into this area of memory.
As an example, an application may be expecting to receive a string of 15 characters for a
username. If input validation is not used and it receives more than 15 characters, it can cause a buffer
overflow and expose system memory. The following HTTP GET command shows an example of
sending a long string to the system to create a buffer overflow: GET /index.php?
username=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
The buffer overflow exposes a vulnerability, but it doesn’t necessarily cause damage by itself.
However, once attackers discover the vulnerability, they exploit it and overwrite memory locations
with their own code. If the attacker uses the buffer overflow to crash the system or disrupt its
services, it is a DoS attack.
More often, the attacker’s goal is to insert malicious code in a memory location that the system
will execute. It’s not easy for an attacker to know the exact memory location where the malicious
code is stored, making it difficult to get the computer to execute it. However, an attacker can make
educated guesses to get close.
A popular method that makes guessing easier is with no operation (NOP, pronounced as “noop”)
commands, written as a NOP slide or NOP sled. Many Intel processors use hexadecimal 90
(often written as x90) as a NOP command, so a string of x90 characters is a NOP sled. The attacker
writes a long string of x90 instructions into memory, followed by malicious code. When a computer is
executing code from memory and it comes to a NOP, it just goes to the next memory location. With a
long string of NOPs, the computer simply slides through all of them until it gets to the last one and
then executes the code in the next instruction. If the attacker can get the computer to execute code from
a memory location anywhere in the NOP slide, the system will execute the attacker’s malicious code.
The malicious code varies. In some instances, the attackers write code to spread a worm through
the web server’s network. In other cases, the code modifies the web application so that the web
application tries to infect every user who visits the web site with other malware. The attack
possibilities are almost endless.
Remember this
Buffer overflows occur when an application receives more data than it can
handle, or receives unexpected data that exposes system memory. Buffer
overflow attacks often include NOP instructions (such as x90) followed by
malicious code. When successful, the attack causes the system to execute
the malicious code. Input validation helps prevent buffer overflow attacks.
A buffer overflow attack includes several different elements, but they happen all at once. The
attacker sends a single string of data to the application. The first part of the string causes the buffer
overflow. The next part of the string is a long string of NOPs followed by the attacker’s malicious
code, stored in the attacked system’s memory. Last, the malicious code goes to work.
In some cases, an attacker is able to write a malicious script to discover buffer overflow
vulnerabilities. For example, the attacker could use JavaScript to send random data to another service
on the same system.
Although error-handling routines and input validation go a long way to prevent buffer overflows,
they don’t prevent them all. Attackers occasionally discover a bug allowing them to send a specific
string of data to an application causing a buffer overflow. When vendors discover buffer overflow
vulnerabilities, they are usually quick to release a patch or hotfix. From an administrator’s
perspective, the solution is easy: Keep the systems up to date with current patches.

Source: Darril Gibson Book Sec+

How TCP sessions use a three way handshake

How TCP sessions use a three way handshake

When establishing a session, two systems normally start a TCP session by exchanging three packets in a TCP handshake. For example, when a client establishes a session with a server, it takes the following steps:
1. The client sends a SYN (synchronize) packet to the server.
2. The server responds with a SYN/ACK (synchronize/acknowledge) packet.
3. The client completes the handshake by sending an ACK (acknowledge) packet. After
establishing the session, the two systems exchange data.

However, in a SYN flood attack, the attacker never completes the handshake by sending the
ACK packet. Additionally, the attacker sends a barrage of SYN packets, leaving the server with
multiple half-open connections.

In some cases, these half-open connections can consume a server’s resources while it is waiting
for the third packet, and it can actually crash. More often though, the server limits the number of these half-open connections. Once the limit is reached, the server won’t accept any new connections,
blocking connections from legitimate users. For example, Linux systems support an iptables command
that can set a threshold for SYN packets, blocking them after the threshold is set. Although this
prevents the SYN flood attack from crashing the system, it also denies service to legitimate clients.

Logical Volume Manager Survival Guide Martin Zahn, 05.03.2010

Overview   Logical volume management is a widely-used technique for deploying logical rather than physical storage. With LVM,«logical» partitions can span across physical hard drives and can be resized. A physical disk is divided into one or more physical volumes (PVs), and logical volume groups (VGs) are created by combining PVs. Notice the VGs can be an aggregate of PVs from multiple physical disks. Example Configuration This article describes a Linux logical volume manager by showing an example of configuration and usage. We use RedHat Linux for this example. Physical Volumes PV With LVM, physical partitions are simply called «physical volumes» or «PVs». These PVs are usually entire disks but may be disk partitions, for example /dev/sda3 in the above figure. PVs are created with pvcreate to initialize a disk or partition. Command Remarks pvcreate Initialize a disk or partition for use by LVM pvchange Change attributes of a physical volume pvdisplay Display attributes of a physical volume pvmove Move physical extents pvremove Remove a physical volume pvresize Resize a disk or partition in use by LVM2 pvs Report information about physical volumes pvscan Scan all disks for physical volumes Example: pvcreate /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 Physical Volume Groups VG The PVs in turn are combined to create one or more large virtual disks called «volume groups» or «VGs». While you can create many VGs, one may be sufficient. A VG can grow or shrink by adding or removing PVs from it. The command vgcreate creates a new volume using the block special device previously configured with pvcreate. Command Remarks vgcreate Create a volume group vgchange Change attributes of a volume group vgdisplay Display attributes of volume groups vgcfgbackup Backup volume group descriptor area vgcfgrestore Restore volume group descriptor area vgck Check volume group metadata vgconvert Convert volume group metadata format vgexport Make volume groups unknown to the system vgextend Add physical volumes to a volume group vgimport Make exported volume groups known to the system vgmerge Merge two volume groups vgmknodes Recreate volume group directory and logical volume special files vgreduce Reduce a volume group vgremove Remove a volume group vgrename Rename a volume group vgs Report information about volume groups vgscan Scan all disks for volume groups and rebuild caches vgsplit Split a volume group into two Example: vgcreate VGb1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 Logical Volumes LV Once you have one or more physical volume groups you can create one or more virtual partitions called «logical volumes» or «LVs». Note each LV must fit entirely within a single VG. The command lvcreate creates a new logical volume by allocating logical extents from the free physical extent pool of that volume group. Command Remarks lvcreate Create a logical volume in an existing volume group lvchange Change attributes of a logical volume lvdisplay Display attributes of a logical volume lvextend Extend the size of a logical volume lvmchange Change attributes of the logical volume manager lvmdiskscan Scan for all devices visible to LVM2 lvreduce Reduce the size of a logical volume lvremove Remove a logical volume lvrename Rename a logical volume lvresize Resize a logical volume lvs Report information about logical volumes lvscan Scan (all disks) for logical volumes Example: lvcreate -L 400 -n LVb1 VGb1 This creates a logical volume, named «LVb1», with a size of 400 MB from the virtual group «VGb1». Filesystems Finally, you can create any type of filesystem you wish on the logical volume, including as swap space. Note that some filesystems are more useful with LVM than others. For example not all filesystems support growing and shrinking. ext2, ext3, xfs, and reiserfs do support such operations and would be good choices. Creating the Root Logical Volume «LVa1» during Installation The physical volumes are combined into logical volume groups, with the exception of the /boot partition. The /bootpartition (/dev/sda1) cannot be on a logical volume group because the boot loader cannot read it. If the root partition is on a logical volume, create a separate /boot partition which is not a part of a volume group. In this example the swap space (/dev/sda2) is also created on a normal ext3 partition. The setup of the LVM for the root filesystem (/dev/sda3) is done during the installation of RedHat Linux. After creating the /boot filesystem and the swap space, select the free space and create the physical volume for/dev/sda3 as shown in the next figure. Select New. Select physical volume (LVM) from the File System Type pulldown menu. You cannot enter a mount point yet. A physical volume must be constrained to one drive. Enter the size that you want the physical volume to be. Select Fixed size to make the physical volume the specified size, select Fill all space up to (MB) and enter a size in MBs to give range for the physical volume size, or select Fill to maximum allowable size to make it grow to fill all available space on the hard disk. Select Force to be a primary partition if you want the partition to be a primary partition. Click OK to return to the main screen. The result is shown in the next figure, the physical volume PV is located on /dev/sda3. Once all the physical volumes are created, the volume groups can be created. Click the LVM button to collect the physical volumes into volume groups. A volume group is basically a collection of physical volumes. You can have multiple logical volumes, but a physical volume can only be in one volume group.   Change the Volume Group Name if desired.   Select which physical volumes to use for the volume group. Enter the name for the logical volume group as shown in the next figure. The result is the logical volume group VGa1 located on the physical volume /dev/sda3. Creating the Logical Volume «LVb1» manually Create Partitions For this LVM example you need an unpartitioned hard disk /dev/sdb. First you need to create physical volumes. To do this you need partitions or a whole disk. It is possible to run pvcreate command on /dev/sdb, but I prefer to use partitions and from partitions I later create physical volumes. fdisk -l .... Device Boot Start End Blocks Id System /dev/sda1 * 1 127 1020096 83 Linux /dev/sda2 128 382 2048287+ 82 Linux swap / Solaris /dev/sda3 383 2610 17896410 8e Linux LVM .... The partition type for LVM is 8e. fdisk /dev/sdb Command (m for help): n Command action e extended p primary partition (1-4)p Partition number (1-4): 1 First cylinder (1-2136, default 1): Using default value 1 Last cylinder or +size or +sizeM or +sizeK (1-2136, default 2136): Using default value 2136 Command (m for help): t Selected partition 1 Hex code (type L to list codes): 8e Changed system type of partition 1 to 8e (Linux LVM) Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. This is done for all other disks as well. Create physical volumes Use the pvcreate command to create physical volumes. pvcreate /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 Physical volume "/dev/sdb1" successfully created Physical volume "/dev/sdc1" successfully created Physical volume "/dev/sdd1" successfully created Physical volume "/dev/sde1" successfully created Create physical volume group VGb1 At this stage you need to create a physical volume group which will serve as a container for your physical volumes. To create a virtual group with the name «VGb1» which will include all partitions, you can issue the following command. vgcreate VGb1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1 Volume group "VGb1" successfully created vgdisplay  --- Volume group --- VG Name VGb1 System ID Format lvm2 Metadata Areas 4 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 4 Act PV 4 VG Size 65.44 GB PE Size 4.00 MB Total PE 16752 Alloc PE / Size 16717 / 65.30 GB Free PE / Size 35 / 140.00 MB VG UUID 2iSIeo-dw0Q-NA07-HUt0-Pjxq-m3gh-f33lAh Create Logical Volume Group LVb1 To create a logical volume, named «LVb1», with a size of 400 MB from the virtual group «VGb1» use the following command. lvcreate -L 65.3G -n LVb1 VGb1 Rounding up size to full physical extent 65.30 GB Logical volume "LVb1" created Create File system on logical volumes The logical volume is almost ready to use. All you need to do is to create a filesystem. mke2fs -j /dev/VGb1/LVb1 mke2fs 1.39 (29-May-2006) Filesystem label= OS type: Linux Block size=4096 (log=2) Fragment size=4096 (log=2) 8568832 inodes, 17118208 blocks 855910 blocks (5.00%) reserved for the super user First data block=0 Maximum filesystem blocks=0 523 block groups 32768 blocks per group, 32768 fragments per group 16384 inodes per group Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424 Writing inode tables: done Creating journal (32768 blocks): done Writing superblocks and filesystem accounting information: done This filesystem will be automatically checked every 35 mounts or 180 days, whichever comes first. Use tune2fs -c or -i to override. Edit /etc/fstab Add an entry for your newly created logical volume into /etc/fstab /dev/VGa1/LVa1 / ext3 defaults 1 1 /dev/sda1 /boot ext3 defaults 1 2 devpts /dev/pts devpts gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs defaults 0 0 proc /proc proc defaults 0 0 sysfs /sys sysfs defaults 0 0 /dev/sda2 swap swap defaults 0 0 /dev/VGb1/LVb1 /u01 ext3 defaults 1 3 mount -a You can now use the filesystem, for the maintenance use one of the above LVM commands.

How to setup an E-Mail Relay Host with Sendmail ?

Very old but still informative .. How to setup an E-Mail Relay Host with Sendmail ?  In a high security internet environment it may be necessary to put all user mailboxes behind the corporate firewall into the HSZ (High Security Zone). The mailbox server cannot be directly accessed from the internet, a mail relay host in the DMZ (Demilitarized Zone) is needed. This mail relay host provides the following tasks: All incoming SMTP-Mail will be processed by the relay host. Mail to internal recipients will be forwarded to the mailbox host. Mail from the internet to other internet recipients will not be forwarded, except for certain clearly defined domains. Mail from all hosts in the HSZ or DMZ will be sent to the relay host, which will deliver the email directly to the recipients in the internet using MX-records from the DNS Server.

In this example, we show the configuration for the well known MTA (Message Transfer Agent)sendmail on RedHat Linux 7.0. DNS Configuration on DNS-Server The relay host, the mailbox host and all hosts in DMZ must be inserted in the DNS for the domain ARKUM.CH. Besides this, it's very important to insert the Firewall (NAT Address) in the DNS, or Sendmail will complain about relay problems. As a rule of thumb, all Hosts or IP-Adresses which will use the Relay-Host must be inserted in Sendmail's DNS or you may encounter relaying problems. The configuration files for DNS can be found in /var/named for RedHat Linux. ;--------------------------------------------------------- ; arkum-ch.zone -- Name-to-Address Mapping ;--------------------------------------------------------- ; ; Start Of Authority marker, indicates that this server is ; the master for the following addresses. ; @   IN  SOA rabbit.arkum.ch. postmaster.arkum.ch. (     2000091001    ; Serial (YYYYMMDDnn)     10800         ; Refresh after 3 hours     3600          ; Retry after 1 hour     604800        ; Expire after one week     86400         ; Minimum Time to Live of 1 day     ) ; ; -------------------------------------------- ; Descriptions of Name Servers for this domain ; -------------------------------------------- ;             IN  NS  rabbit.arkum.ch.             IN  NS  opal.arkum.ch. ; ; Descriptions of Primary and Secondary Mail Servers ; (This tells sendmail where to send mail that is addressed to ; someone@arkum.ch, namely too rabbit.arkum.ch first, then ; to the secondary mail handler opal.arkum.ch) ;             IN  MX  10  ux-mail1.arkum.ch. ; ; -------------------------------------------- ; Arkum's Hosts ; -------------------------------------------- ; localhost   IN  A       127.0.0.1 ; rabbit      IN  A       193.247.121.196             IN  MX  10  ux-mail1.arkum.ch. dns         IN  CNAME   rabbit.arkum.ch.             IN  TXT     "DNS Server" ; ux-mail1    IN  A       193.247.121.205 smtp        IN  CNAME   ux-mail1.arkum.ch. mail        IN  CNAME   ux-mail1.arkum.ch.             IN  TXT     "Mail Relay Host" ; paragon     IN  A       192.168.138.20             IN  MX  10  paragon.arkum.ch.             IN  TXT     "Mailbox Server" Please note, that the MX record for the mailbox host paragon points to itself. DNS Configuration on Relay Host The sendmail MTA on the relay host needs access to the DNS Server. This must be setup in the file/etc/resolv.conf search arkum.com arkum.ch nameserver 193.247.121.196 Firewall Configuration Port 25 (SMTP) must be opened between the Relay Host on the DMZ and the Mailbox Host in the HSZ. Ask your firewall administrator to accomplish this task. Enable Relaying for all hosts in ARKUM.CH Relaying (transmission of messages from a site outside your domain to another site outside your domain) is denied by default. Note that this changed in sendmail 8.9; previous versions allowed relaying by default. Relaying is a feature (not a bug) to prevent E-Mail spamming. You have to configure relaying or you will get the error message: 550 Requested action not taken: relaying denied. Configure Relaying Using /etc/mail/relay-domains You need to add the fully-qualified host name and/or IP address of each client to class R, the set of relay-allowed domains. For version for 8.9.X, it is typically /etc/mail/relay-domains Note: if your DNS is problematic, you should list the IP address (e.g., 1.2.3.4); in general, however, this should not be necessary. Here is the content of the file relay-domains: akadia.com akadia.ch arkum.ch Using /etc/mail/access An "access'' database can be created to accept or reject mail from selected domains. For example, you may choose to reject all mail originating from known spammers. To enable such a database, use the file /etc/mail/access. Remember, since /etc/mail/access is a database, after creating the text file as described below, you must use makemap to create the database map.  For example: makemap hash /etc/mail/access < /etc/mail/access The table itself uses e-mail addresses, domain names, and network numbers as keys. For example: spammer@aol.com     REJECT cyberspammer.com    REJECT 192.168.212         REJECT would refuse mail from spammer@aol.com, any user from cyberspammer.com (or any host within the cyberspammer.com domain), and any host on the 192.168.212.* network. The value part of the map can contain: OK Accept mail even if other rules in the running ruleset would reject it, for example, if the domain name is unresolvable RELAY Accept mail addressed to the indicated domain or received from the indicated domain for relaying through your SMTP server. RELAY also serves as an implicit OK for the other checks REJECT  Reject the sender or recipient with a general purpose message DISCARD  Discard the message completely using the $#discard mailer. This only works for sender addresses (i.e., it indicates that you should discard anything received from the indicated domain). Error Text Any text where ### is an RFC 821 compliant error code and "any text" is a message to return for the command. For example: cyberspammer.com        550 We don't accept mail from spammers okay.cyberspammer.com   OK sendmail.org            OK 128.32                  RELAY Would accept mail from okay.cyberspammer.com, but would reject mail from all other hosts at cyberspammer.com with the indicated message.It would allow accept mail from any hosts in the sendmail.org domain, and allow relaying for the 128.32.*.* network. We use the following entries in /etc/mail/access, so all hosts within the domain ARKUM.CH or within the HSZ 192.168.138.x can use the Relay Host without "550 Requested action not taken: relaying denied." localhost     RELAY 127.0.0.1     RELAY arkum.com     RELAY arkum.ch      RELAY 192.168.138   RELAY Compile the entries with: makemap hash /etc/mail/access < /etc/mail/access More information can be found in the README.cf file of sendmail. How to deliver local mails if DNS- and Mail-Server is the same machine ? If your DNS-Server and E-Mail Relay Host is the same machine you may encounter the following error message: 554 MX list for akadia.ch points back to rabbit.akadia.ch 554 <root@akadia.ch> ... Local configuration error The Mail Exchanger (MX Records) in the DNS configuration is just an ordered list of destinations that tells mailers where to send messages if they want to reach a given domain. The preference value tells them how desirable it is to use that destination. That's the basic idea behind MX records and mail exchangers, but there are a few more wrinkles you should know about. Here is the output of a typical MX entry in the DNS configuration for ARKUM.CH What happens if a mailer finds itself at the highest preference, and has to discard the whole MX list as shown below ? IN MX 10 rabbit.arkum.ch. IN MX 20 opal.arkum.ch. Some mailers attempt delivery directly to the destination host's IP address, as a last-ditch effort. In most mailers however , it's an error. It may indicate that DNS thinks the mailer should be processing (not just forwarding) mail for the destination, but the mailer hasn't been configured to know that. Or it may indicate that the administrator has ordered the MX records incorrectly by using the wrong preference values. Then it will bounce the mail with the familiar error Many versions of sendmail use class w or file class w as the list of local destinations. The sendmail configuration on RedHat Linux offers the file /etc/sendmail.cw. Enter the local domains in this file and the local delivery together with MX records will work. arkum.ch arkum.com Note again, that this task must not be done, if the DNS Server and Mail Server are two different machines. Enable local Mail Forwarding from the DMZ to the HSZ Local Mail must be forwarded from the Relay Host on the DMZ to the Mailbox Host on the HSZ. Sendmail offers this feature using the Macros DR and DM in /etc/sendmail.cf. Enter the Mailbox Host for both Macros, besides this the domain name ARKUM.CH must be masqueraded with the macro DM.  Here are the necessary entries in /etc/sendmail.cf # Who I send unqualified names to (null means deliver locally) DRparagon.arkum.ch # Who gets all local email traffic # ($R has precedence for unqualified names) DHparagon.arkum.ch# Class M: domains that should be converted to $M CMarkum.com# Who I masquerade as (null for no masquerading) (see also $=M) DMarkum.ch Test the Configuration Stop and Start Sendmail Daemon /etc/rc.d/init.d/sendmail stop /etc/rc.d/init.d/sendmail start Test the internet delivery Create a testfile to_internet for internet delivery with the following content: To: martin.zahn@plenaxx.ch From: martin.zahn@arkum.ch Subject: Ein Test Dies ist ein Header Test (empty line) Test the internet delivery cat to_internet | /usr/lib/sendmail -bm -t -v martin.zahn@plenaxx.ch. Connecting to nt-mail1.plenaxx.ch. esmtp... 220 nt-portal2.plenaxx.ch ESMTP Service (Lotus Domino Release 5.0.2c (Intl)) ready at Sat, 4 Nov 2000 10:25:28 +0100 >>> EHLO rabbit.akadia.com 250-nt-portal2.plenaxx.ch Hello rabbit.akadia.com ([193.247.121.196]), pleased to meet you 250-HELP 250-SIZE 250 PIPELINING >>> MAIL From:<root@rabbit.akadia.com> SIZE=100 250 root@rabbit.akadia.com... Sender OK >>> RCPT To:<martin.zahn@plenaxx.ch> 250 martin.zahn@plenaxx.ch... Recipient OK >>> DATA 354 Enter message, end with "." on a line by itself >>> . 250 Message accepted for delivery martin.zahn@plenaxx.ch... Sent (Message accepted for delivery) Closing connection to nt-mail1.plenaxx.ch. >>> QUIT 221 nt-portal2.plenaxx.ch SMTP Service closing transmission channel If you get an output similar to the above, your internet delivery is working perfectly ! Test the Mail Forwarding Create a testfile to_arkum for local delivery with the following content: To: martin.zahn@arkum.ch From: root@plenaxx.ch Subject: Ein Test Dies ist ein Header Test (empty line) Test the local delivery cat to_internet | /usr/lib/sendmail -bm -t -v martin.zahn@arkum.ch... Connecting to paragon.arkum.ch. via relay... 220 SMTP service ready >>> EHLO ux-mail1.arkum.ch 250-Requested mail action okay, completed 250-8BITMIME 250-SIZE 250-ETRN 250 HELP >>> MAIL From:<root@ux-mail1.arkum.ch> SIZE=93 250 Requested mail action okay, completed >>> RCPT To:<martin.zahn@paragon.arkum.ch> 250 Requested mail action okay, completed >>> DATA 354 Start mail input; end with <CRLF>.<CRLF> >>> . 250 Requested mail action okay, completed martin.zahn@arkum.ch... Sent (Requested mail action okay, completed) Closing connection to paragon.arkum.ch. >>> QUIT 221 SMTP server closing transmission channel If you get an output similar to the above, your local delivery is working perfectly ! Debug the Configuration If you encounter troubles with the sendmail configuration, here are some tests to find out what happens. Show Delivery Agent (Mailer) $ /usr/lib/sendmail -d0.12 -bt < /dev/null Version 8.9.3 Compiled with: LOG MATCHGECOS MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETUNIX NEWDB NIS QUEUE SCANF SMTP USERDB OS Defines: HASFLOCK HASGETDTABLESIZE HASINITGROUPS HASLSTAT HASSETREUID HASSETRLIMIT HASSETSID HASSETVBUF HASSNPRINTF HASUNAME HASUNSETENV HASWAITPID IDENTPROTO USE_SIGLONGJMP Def Conf file: /etc/sendmail.cf Pid file: /var/run/sendmail.pid canonical name: ux-mail1.arkum.ch a.k.a.: ux-mail1 UUCP nodename: ux-mail1.arkum.ch a.k.a.: ux-mail1.arkum.ch a.k.a.: [193.247.121.205] ============ SYSTEM IDENTITY (after readcf) ============ (short domain name) $w = ux-mail1 (canonical domain name) $j = ux-mail1.arkum.ch (subdomain name) $m = arkum.ch (node name) $k = ux-mail1.arkum.ch ======================================================== Show Macros without $u, $M which will be set when mail is already delivered $ /usr/lib/sendmail -d35.9 -bt define(* as $*) define(+ as $+) define(- as $-) define(= as $=) define(~ as $~) define(# as $#) define(@ as $@) define(: as $:) define(> as $>) define(? as $?) define(| as $|) define(. as $.) define([ as $[) define(] as $]) define(( as $() define() as $)) define(& as $&) define(0 as $0) define(1 as $1) define(2 as $2) define(3 as $3) define(4 as $4) define(5 as $5) define(6 as $6) define(7 as $7) define(8 as $8) define(9 as $9) define(n as MAILER-DAEMON) define(v as 8.9.3) define(w as ux-mail1.arkum.ch) define(j as ux-mail1.arkum.ch) define(m as arkum.ch) define(k as ux-mail1.arkum.ch) define(b as Sat, 4 Nov 2000 13:44:49 +0100) define(opMode as t) redefine(w as ux-mail1) define(S as ) define(R as paragon.arkum.ch) define(H as paragon.arkum.ch) define(M as arkum.ch) redefine(n as MAILER-DAEMON) define(Z as 8.9.3) define(deliveryMode as b) define(_ as root@localhost) redefine(deliveryMode as i) Show Sendmail Queue $ /usr/lib/sendmail -bp Mail Queue (2 requests) --Q-ID-- --Size-- -----Q-Time----- ------------Sender/Recipient------------ RAA01002 27 Fri Nov 3 17:13 root (martin.zahn@plenaxx.ch... reply: read error from nt-mail1.pl) martin.zahn@plenaxx.ch RAA01088 27 Fri Nov 3 17:18 root (Deferred: Connection reset by nt-mail1.plenaxx.ch.) martin.zahn@plenaxx.ch Test the MX-Record readed by Sendmail from DNS $ /usr/lib/sendmail -bt > /mx arkum.ch   getmxrr(arkum.ch) returns 1 value(s):   ux-mail1.arkum.ch. > /mx plenaxx.ch   getmxrr(plenaxx.ch) returns 1 value(s):   nt-mail1.plenaxx.ch. > /mx glue.ch   getmxrr(glue.ch) returns 2 value(s):   ns.glue.ch.   chsun.eunet.ch. If you have still troubles consult our sendmail guide or visit http://www.sendmail.org source: http://www.akadia.com/services/sendmail_relay.html