You are here

The Trouble with Tribbles... - Peter Tribble

Subscribe to The Trouble with Tribbles... - Peter Tribble feed
Peter Tribblehttp://www.blogger.com/profile/09363446984245451854noreply@blogger.comBlogger509125
Updated: 1 week 3 days ago

Selecting relay smarthosts and using SMTP AUTH on illumos

Mon, 11/06/2017 - 21:47
A problem I looked at recently involved configuring a system to send (relay) email via a customer's own SMTP servers. There are 2 parts to this:

  • Select the relay host depending on some condition
  • Authenticate with the remote relay using SMTP AUTH

Search for SMTP AUTH with sendmail on illumos or Solaris, and you invariably end up with advice on how to build Cyrus SASL and sendmail from scratch.

For example, Andrew has some good instructions.

However, if you look at the sendmail we ship on illumos you'll find that it's already been built with SASLv2 support:

# /usr/lib/sendmail -bt -d0.1 < /dev/null
Version 8.14.4+Sun
 Compiled with: DNSMAP LDAPMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8
        MIME8TO7 NAMED_BIND NDBM NETINET NETINET6 NETUNIX NEWDB NIS
        PIPELINING SASLv2 SCANF STARTTLS TCPWRAPPERS USERDB
        USE_LDAP_INIT XDEBUG
And, if you telnet to port 25 and look at the EHLO response it includes:

250-AUTH GSSAPI DIGEST-MD5 CRAM-MD5
However, that's not actually the part we want here (but I'll come back to that later). I don't want to authenticate against my own server, I need my system to authenticate against a remote server.

Back to the problem at hand.

The first part - selecting the right smarthost - can be achieved using smarttable. All you need is the smarttable.m4 file, and then build a configuration using it by enabling the smarttable feature.

The second part, SMTP AUTH, should also be very simple. Again, it's all documented, and just involves enabling the authinfo feature. But wait - on illumos, there is no authinfo.m4 file, so that won't work.

In fact, it does. So what you need to do is to download the sendmail source, unpack it, and there in the cf/feature directory you'll find the authinfo.m4 file.

OK, so copy both files - smarttable.m4 and authinfo.m4 - into the /etc/mail/cf/feature directory on a server. Copy and edit the sendmail.mc file (i'm going to copy it to /tmp and edit it there) to add the 2 feature lines, like this fragment of the file here:

...
define(`confFALLBACK_SMARTHOST', `mailhost$?m.$m$.')dnl
FEATURE(`authinfo')dnl
FEATURE(`smarttable')dnl
MAILER(`local')dnl
...
Basically, just add the features above the MAILER line. Then compile that:

cd /etc/mail/cf/cf
m4 ../m4/cf.m4 /tmp/sendmail.mc > /tmp/sendmail.cf
That's your new sendmail.cf ready. It uses 2 databases in /etc/mail, to create these (initially empty):

cd /etc/mail
touch smarttable
touch authinfo
makemap hash smarttable < smarttable
makemap hash authinfo < authinfo
then copy your new sendmail.cf into /etc/mail and restart sendmail

cp /tmp/sendmail.cf /etc/mail
svcadm restart sendmail
So far so good, but what should those files look like?

First the smarttable file, which is just a map of sender to relay host. For example, it might just have:

my.name@gmail.com smtp.gmail.com
Which means that if I want my home system to send out mail with my address on it, it should route it through gmail's servers rather than trying to deliver it direct (and likely getting marked as spam).

Then the authinfo file, which looks like

Authinfo:smtp.gmail.com "U:root" "I:my.name@gmail.com" "P:mypassword" "M:LOGIN PLAIN"
Authinfo:smtp.gmail.com:587 "U:root" "I:my.name@gmail.com" "P:mypassword" "M:LOGIN PLAIN"(There are just 2 lines there, starting with Authinfo:, even if the blog shows it wrapped.)

Basically, for gmail, you need to supply your email address as the identifier and your password as, well, the password. (Note: if you've got two-factor authentication set up, you'll need to set up an app key.)

Of course, the authinfo files ought to to readable only by root, otherwise anyone one your system can read your password in the clear.

There are a couple of non-standard tweaks you'll need for gmail to work. First, you need to go to your gmail account settings and allow less secure apps. Second, you will need the "M:LOGIN PLAIN" entry in the authinfo file, else you'll get an "available mechanisms do not fulfill requirements" error back.

Redo the two makemap commands above and you're good to go.

That's SMTP AUTH the one way. At which point you're probably thinking, can we authenticate against an illumos sendmail using SMTP AUTH?

The answer, sadly, is no. At least as far as I can tell. While our sendmail is built correctly against SASLv2, illumos doesn't seem to ship enough supporting bits of the SASL infrastructure to make this work. You should be able to create the file /etc/sasl/Sendmail.conf to configure it. Unfortunately the only pwcheck_method available is auxprop (using shadow, which would allow you to authenticate against local system accounts, isn't available; neither is saslauthd, and there's no saslauthd anyway). Worse, illumos has no auxprop plugins, so the whole thing is rather useless. Note that rebuilding sendmail alone won't fix this, as the problem is in the underlying sasl implementation.

The above notes were developed on Tribblix, but ought to apply to any illumos distribution using the vanilla illumos sendmail+sasl combination.
Categories: Personal Blogs

Building illumos-gate on AWS

Wed, 11/01/2017 - 22:59
Having talked about running Tribblix on AWS, one of the things that would be quite neat would be to be able to build illumos-gate.

This is interesting because it's a relatively involved process, and might require proper resources - it's not really possible to build illumos inside VirtualBox, for instance, and many laptops don't run illumos terribly well. So it's hard for the average user to put together a decent - most likely dedicated - rig capable of building or developing illumos, which is clearly a barrier to contribution.

Here's how anyone can build illumos, using Tribblix.

Build yourself an EC2 instance as documented here, with 2 changes:

  1. The instance type should be m4.large or bigger - m4.xlarge or c4.xlarge would be better. The bigger the instance, the quicker the build, but m4.large is pretty much the minimum size.
  2. Attach an EBS volume to the instance, at least 8G in size. If you want to do multiple builds, or do lint or debug builds, then it has to be larger. I attach the volume as /dev/sdf, which is assumed below. (You could keep the volume around to persist the data, of course.)
Once booted, log in as root. You then need to set up the zfs pool (the disk showing up as c2t5d0 below matches the /dev/sdf attachment point) and create a couple of file systems that can be used to host the build zone and store the build.

zpool create storage c2t5d0
zfs set compression=lz4 storage
zfs destroy rpool/export/home
zfs create -o mountpoint=/export/home storage/home
zfs create -o mountpoint=/export/zones storage/zones
You should then do an update to ensure packages are up to date, and install the develop overlay to get you some useful tools.

zap refresh
zap update-overlay -a
zap install-overlay develop
Then create a user, which you're going to use to do the build. For me, that is:

groupadd -g 10000 it
useradd -g it -u 11730 -c "Peter Tribble" -s /bin/tcsh \
  -d /export/home/ptribble ptribble
mkdir -p /export/home/ptribble
chown -hR ptribble:it /export/home/ptribble
passwd ptribble
Then create a build zone. It has an IP address, just pick any unused private address (I simply use the address above that of the global zone, which you can get with ifconfig or from the AWS console - note that it's the private address, not the public IP that you ssh to).

zap create-zone -z illumos-build -t whole \
  -i 172.xxx.xxx.xxx -o develop \
  -O java -O illumos-build -U ptribble
What does this do? It creates a new zone, called illumos-build. It's a whole root zone, with its own exclusive set of file systems. The IP address is 172.xxx.xxx.xxxx. The develop overlay is installed (in this case, copied from the global zone); the java and illumos-build overlays are added to this new zone (note the upper-case -O here). Finally, the user account ptribble is shared with the zone.

Give that a few seconds to boot and log in to it, then a couple of tweaks that are necessary for illumos to build without errors.

zlogin illumos-build
rm /usr/bin/cpp
cd /usr/bin ; ln -s ../gnu/bin/xgettext gxgettext
Now log out and log back in to the instance as your new user. We're going to create somewhere to store the files, and check out the source code.

mkdir Illumos
cd Illumos
git clone git://github.com/illumos/illumos-gate.git
wget -c \
  https://download.joyent.com/pub/build/illumos/on-closed-bins.i386.tar.bz2 \
  https://download.joyent.com/pub/build/illumos/on-closed-bins-nd.i386.tar.bz2
Now we set up the build.

cd illumos-gate
bzcat ../on-closed-bins.i386.tar.bz2 | tar xf -
bzcat ../on-closed-bins-nd.i386.tar.bz2 | tar xf -
cp usr/src/tools/scripts/nightly.sh .
chmod +x nightly.sh
There are two more files we need. Go to the tribblix-build repo and look in the illumos directory there. Grab one of the illumos.sh files from there and put it into your illumos-gate directory with the name illumos.sh. If you need to change how the build is done, this is the file to edit (but start from one of those files so you get one appropriate for Tribblix as the host). Also, grab Makefile.auditrecord and use it to replace usr/src/cmd/auditrecord/Makefile.

Now log in to the zone and start the build.

pfexec zlogin -l ptribble illumos-build
cd Illumos/illumos-gate
time ./nightly.sh illumos.sh
On an m4.xlarge instance, this took me just under 75 minutes. Look in the log directory and check that the mail_msg looks clean without errors, and you'll have the built files in the proto directory and an IPS repo under packages.

For more behind the scenes details on the illumos build process itself, look at the how to build illumos page.

Categories: Personal Blogs

Public Tribblix AMI now available

Tue, 10/31/2017 - 21:12
There's now a public Tribblix AMI available to run on AWS.

This was built according to the notes I gave earlier. And is part of making Tribblix the illumos for everyone.

This is to be considered slightly experimental, and there are a couple of constraints:

First, the AMI is only available in the London region for now (I'm in the UK, so that's where I'm running things). I could make it available elsewhere, but there are costs associated with doing so and, as everything related to Tribblix comes out of my own pocket, I'm not going to incur costs unless there's a demonstrable need. If you want to run in a different region, then you can always copy the AMI.

Second, the size of the image is quite small. Again, there's a constraint on cost. But the idea here is that you wouldn't store any non-trivial data in the image itself - you would create an appropriately sized EBS volume, attach that and create a zfs pool for your data. The Tribblix repo server does just that - the package repo lives on the second pool.

So, how to use this? I'm going to assume some level of AWS familiarity, that you have an account and know basically how to use AWS, and that your account is set up with things like an ssh key pair.

Go to the AWS console, and navigate to the EC2 dashboard. Unless you've copied the AMI to the region of your choice, make sure you're working in London - the dropdown is in the top right:


Then hit the launch instance button:


Now you get to choose an Amazon Machine Image (AMI). Click on "Community AMIs" and enter "Tribblix" or "illumos" into the "Search community AMIs" search box. At the time of writing, you'll only get one result, but more may appear in future:



OK, go and select that one. Then you can Choose an Instance Type. A great thing about Tribblix is that it's pretty lightweight, so the t2.micro - available on the free tier - is a good choice.



Click on "Review and Launch". On the next screen you can edit the storage to add an additional volume, but the one thing you must do is edit the security group.



If you leave it like that, you'll have no way to access it. So Edit it, and the simplest thing to do at this point is to create a new security group that allows ssh only, with the source being your own IP address, which you can get by selecting "My IP" from the source dropdown.



(I've got a saved security group that does just that, to let me straight in from home.)

Click on "Review and Launch" to go back to the main screen, and then "Launch". The is when you get to choose which key pair you can use to log in to your instance:



It will take a little while to start (although it's usually ready before the status checks say so), and you should then be able to ssh in to it (as root, with the key pair you set up).

ssh -i peter1-london.pem \
root@ec2-35-176-237-204.eu-west-2.compute.amazonaws.com
And you're good to go. What you do then is up to you; I'll cover some scenarios in upcoming posts. Be aware that the base AMI has a pretty minimalist set of packages installed, so you probably want to add some more packages or overlays to do anything useful.

Categories: Personal Blogs