Alain M. Lafon

Integration of Databases in the Postfix SMTP server in Debian GNU/Linux

Why would somebody want to let postfix connect to a SQL-database?

• There’s no need to create a real local user for each e-mail account
• SQL-databases can be kept in RAM, so if you have excessive mailing
  on your server, there will be reduced harddisk access
• Management of mailinglists becomes real easy
• /etc/aliases is kept small and simple

Step 1
Install the package “mysql-server” and “mysql-client” if not yet installed.
Log on to your sql-server using the root account:

mysql --user root
mysql> create database postfix_database;
mysql> GRANT ALL PRIVILEGES ON postfix_database \
TO 'postfix'-AT-'localhost' IDENTIFIED BY 'postfix_password' \
WITH GRANT OPTION;
mysql> flush privileges;
mysql> create table postfix.postfix_alias (destination VARCHAR(50), \
alias VARCHAR(50));
mysql> exit;

Now we have created a database called “postfix_database” and a user called
“postfix” who has access to it using his unique password “postfix_password”.
With “flush privileges” we bring the sql-server up to date concerning user rights.
Then we create a table called “postfix_alias” in the database “postfix” with two rows:
“destination” is a text variable where the mail will be relayed to and “alias” is the name
of the mailinglist in my example.

Step 2
Install the package “postfix-mysql”. Besides the needed
library this will bring you the config file “/etc/postfix/mysql-aliases.cf” which we
will modify like this

user = postfix
password = postfix_password
table = postfix_alias
query =  SELECT destination FROM postfix_alias WHERE alias = '%s'
hosts = unix:/var/run/mysqld/mysqld.sock
select_field = destination
where_field = alias

Since postfix runs in a chroot it lacks several information it needs to have;
for example the socket to the mysql daemon. That’s why we provide it
with some bind mounts, which can be done by inserting these lines into
“/etc/fstab”.

/etc/passwd     /var/spool/postfix/etc/passwd           none bind 0 0
/etc/shadow     /var/spool/postfix/etc/shadow           none bind 0 0
/etc/group      /var/spool/postfix/etc/group            none bind 0 0
/var/run/mysqld /var/spool/postfix/var/run/mysqld       none bind 0 0

To update this information the root user has to remount all filesystems
using “mount -a”.

Step 3
We’re done already(almost). All that is still needed is some information in the database.
Single entries can be made with the mysql client like this:

mysql> insert into postfix_alias values \
('someone-AT-somewhere-DOT-de', 'mailinglistname');

Now if you send a mail to “mailinglistname-AT-yourhost-DOT-com” the mail will be relayed to
“someone@somewhere-DOT-de”. That’s it.
I wrote a JSP/Servlet combination in JavaEE to create a webpage where users can
put themselves on or off a mailinglist; you can find it
here or in the
projects folder if you’re interested.

Step 4

Note that installing the package postfix-mysql updated a line in your “/etc/postfix/main.cf”:

alias_maps = hash:/etc/aliases
...
alias_maps = mysql:/etc/postfix/mysql-aliases.cf

There are most likely many more lines in this file, but the important factor is
that the first line mapping to “/etc/aliases” is made obsolete by the second entry.
So if you were using some important relaying in this file you should migrate it.
For this reason I wrote a small
shellscript that was capable to do the job for my setup.

Solaris Express in any recent version will have out of the box NVidia support if you install the Developer Edition or the Community Release. This driver doesn’t differ (at least as far as I know) from the Linux device driver, so setting up secondary screens and tv-outs is quite the same. There even is a preinstalled tool “nvidia-settings” which might help you do the job, but it didn’t help me that much since you have to implement at least the second screen by hand in your X configuration file.
Before you begin, make a backup of your working /etc/X11/xorg.conf file.
We will now take a look at how this xorg.conf file has to be changed for TV-Out support.

• Change the “Device” section that it looks like this:

  Section "Device"
      Identifier              "Videocard0"
      Driver                  "nvidia"
      # optional (find out with "$ Xorg -scanpci")
      BusID                  "[Your BusID, e.g.: PCI:2:0:0]"
      Screen                0
  EndSection
  

• Add a new “Device” section for the TV, just like the one before, but change “Screen 0″ to “Screen 1″ and “Videocard0″ to “Videocard1″
• Change the “Monitor” section as follows:

  Section "Monitor"
     Identifier        "Monitor0"
     HorizSync      30.0 - 100.0       #adjust to your monitor
     VertRefresh   50.0 - 94.0         #adjust to your monitor
     Option            "DPMS"
  EndSection
  

• Add a new “Monitor” section for the TV, just like the one before, but change “Monitor0″ to “Monitor1″
• Now we configure the possible resolutions for CRT and TV

  You will have to adjust them to your liking. “Screen0″ deals with the CRT, “Screen1″ with the TV.

  Section "Screen"
      Identifier     "Screen0"
      Device         "Videocard0"
      Monitor        "Monitor0"
      DefaultDepth    24
      Option         "metamodes" "CRT: 1600x1200 +0+0; CRT: 1400x1050 +0+0;
      CRT: 1280x1024 +0+0; CRT: 1024x768 +0+0; CRT: 800x600 +0+0;
      CRT: 640x480 +0+0"
      SubSection     "Display"
          Depth       24
          Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
      EndSubSection
  EndSection
  Section "Screen"
      Identifier     "Screen1"
      Device         "Videocard1"
      Monitor        "Monitor1"
      DefaultDepth    24
      Option         "metamodes" "TV: 1024x768 +0+0"
      SubSection     "Display"
          Depth       24
          Modes      "1600x1200" "1280x1024" "1024x768" "800x600" "640x480"
      EndSubSection
  EndSection
  

• Now you we are physically set up and can define a Serverlayout which defines how the monitors do correspond to each other.
  In this example the CRT will be the primary monitor whereas the TV can be reached by dragging the mouse cursor out the left side of your monitor.

  Section "ServerLayout"
      Identifier     "Layout0"
      Screen      0  "Screen0" 1024 0
      Screen      1  "Screen1" LeftOf "Screen0"
      InputDevice    "Keyboard0" "CoreKeyboard"
      InputDevice    "Mouse0" "CorePointer"
  EndSection
  

Now we are all done. Save xorg.conf and restart your Xserver(in Solaris logging out and in again will do the job).
A working copy of my file as an example can be downloaded here.

Like we mentioned earlier we are in the middle of configuring a Fire 280R server for our needs. Yesterday we finally were able to patch some real Internet addresses on the NICs, as well as new local addresses, so now we finally are online^^
While configuring we figured that there are at least three potential needs to assign multiple IP addresses to a single interface.

1. To do a quick test where the configuration won’t have to survive a reboot
2. On an interface in a global zone
3. On an interface in a non-global zone

These are the solutions we used:

1

$ ifconfig abrX:Y plumb

while “abrX” is the abbreviation for an installed interface.
Now you can use the new interface abrX:Y as you want.

2
We needed it to have an an external(Internet) and an internal address. So we made an entry in /etc/hosts for the primary address in the old fashioned way(we do not yet use NWAM):

10.5.250.100    fire

while we put the other addresses in /etc/hostname.abrX:

fire
addif 141.72.100.100/24

where /24 implies: netmask ffffff00 broadcast 141.72.100.255

3
We wanted the interfaces to be visible from the global zone via a local address while being available from the Internet. Therefore we defined a local address as in 2 via /etc/hosts and /etc/hostname.abrX, but we also included the Internet address in the zone configuration:

$ zonecfg -z zone1
zonecfg:zone1> select net physical=abrX
zonecfg:zone1:net> set address= 141.72.100.101/24
zonecfg:zone1:net> end
zonecfg:zone1> commit
zonecfg:zone1> exit

We will now take a look at IP instances, because using them we can achieve to only have the non-global zones visible in the Internet, while the global zone is only vulnerable in the local subnet.