403 4.7.0 TLS handshake failed

The subject above is an error I found in my maillogs (/var/log/maillog) when trying to figure out why periodic emails from a server had stopped. I was running the default sendmail on FreeBSD 7.2, though what I've found should be broadly applicable to many versions of sendmail on many OSes.

Let there be no doubt, I'm not a mail expert. I nearly cried this weekend when I discovered I'd be troubleshooting sendmail first thing Monday morning. What follows are the essentials of the shortest path I found to solution.

In the logs, find the host(s) (the remote MTA's rejecting your mail) or domains that are causing the error. I'm not even going to try to clean-up and paste log file excerpts here. But, on the line that contains the error "403 4.7.0 TLS handshake failed" there should also be a variable called "relay" and the corresponding value will be the culprit. For example, "relay=problemhost.example.com".

For each problem host, place a line like this into the "/etc/mail/access" configuration file (which you may need to create):

Try_TLS:problemhost.example.com NO
Try_TLS:problem2.example.com NO

Now, you've got to [re-]create the "access.db" file. On FreeBSD, this is done by entering the "/etc/mail" directory and running "make maps". Now, to make it effective you just need to restart the MTA. This could be done via the start-up scripts, but is done equally well from "/etc/mail" with the command "make restart-mta". ... Here comes the mail. :)

P.s. This link was my biggest clue. Also, try reading "/etc/mail/Makefile".
P.p.s. I'd say that the admin of the problem relay had changed his config.s or software and this solution was really just working around their arbitrary [dumb] changes. C'est la vie.

An FTP error and fix

Of all the things you'd expect to "just work", the venerable ftp should be near the top of the list. But, it's been giving me some trouble lately. I've been having to upload some files to another organization's servers. and getting strange errors like this one:

425 Unable to build data connection: Invalid argument

It took a bit of digging, but in this case it turns out that the extended EPSV and EPRT commands were the issue. I don't know what those extensions are, but they are on by default in the FreeBSD client and ProFTPD 1.3.2 Server doesn't seem to like them. The solution is easy enough, from your client's 'ftp>' prompt just toggle the mode to off with this command (command portion bolded):

ftp> epsv4
EPSV/EPRT on IPv4 off.
ftp>

And notice the response. (Since it's a toggling command, you could be turning it on).

Now the trick is, if you're regularly using a server that has issues with EPSV, to get it turned off by default, so you need not type it every time and could even script your transfers. For that, we're going to need the ".netrc" file. An entry like this should do it:

machine funkyserver.example.com
macdef init
epsv4 off

default ...

I put the default in there only to make it clear that you need a blank line to terminate the "init" macro! "default" is not required; blank line at end of macro is.

Drop down link menu, script-free!

[* Almost script-free. The value of the the 'onChange' attribute is actually a one-line script.]
This is just a tidbit, but I found it a real pain to find. So, here it is to save you the trouble. I wanted a drop-down menu in a web page, filled with links, and without using JavaScript. Why no scripts? It just seems to me like it's a simple enough thing that it shouldn't need it. But, all of the sources I found in my initial search either 1) just covered the drop down menu ("select" box) and didn't mention links, or 2) used JavaScript to implement the drop down menu. But, I finally found what I was looking for here. The site even has a little "wizard" where you can choose various settings and then generate the html. And, here is a little demonstration:

Please chooseFreeBSDPC-BSDPython

The code for which looks like this:

<form name="form1">
<select name="menu" onChange="location=document.form1.menu.options[document.form1.menu.selectedIndex].value;">
<option value=''>Please choose</option>
<option value="http://www.freebsd.org/">FreeBSD</option>
<option value="http://www.pcbsd.org/">PC-BSD</option>
<option value="http://www.python.org/">Python</option>
</select>
</form>

(... For simplicity, though, I left out the "style" part of the select tag above.) The second line above runs off the viewable area, but I'll leave it like that to make copy and paste easier.

Quick enable passwords for svnserve

I sure love Subversion. What a great tool. But, I'm more a user than an administrator of it. So, when I went to set-up another of my own repositories, I couldn't remember squat about how I'd done it before. I do recall there was a lot of reading involved. (With great power comes ... longer manuals. :p) First, you must create the new repository with a command like this, "svnadmin create /svnrepos/brandnew". And, in this case, the part that's difficult to remember is how to enable net access and password protection. So, here's the short answer, diff'd from my previous effort:

# diff /svnrepos/someapp/conf/ /svnrepos/brandnew/conf/
diff /svnrepos/someapp/conf/passwd /svnrepos/brandnew/conf/passwd
6a7,8
> kace = s3cret
> jack = pr1vate
diff /svnrepos/someapp/conf/svnserve.conf /svnrepos/brandnew/conf/svnserve.conf
12,13c12,13
< # anon-access = read   < # auth-access = write   ---   > anon-access = none
> auth-access = write
20c20
< # password-db = passwd   ---   > password-db = passwd
32c32
< # realm = My First Repository   ---   > realm = main

... And, yes, it's done per repository. After making changes like the above to the configuration files for the new repository, you just need to start (or restart) svnserve. On FreeBSD, that should be as easy as "/usr/local/etc/rc.d/svnserve start" (... with "svnserve_enable='YES'" already in "/etc/rc.conf"). ... Also, you must have either created an 'svn' user or set another user to run the server as -- again using shell variables in "/etc/rc.conf", as per the appropriate variables found in the start-up script. ... Yeah, and you probably want to run something like "chown -R svn /svnrepos/brandnew" on your new repository so the svnserve process can actually make changes to it.

Details, details. Anyway, those configuration files were the part that took some research. Enjoy.

X on FreeBSD amd64

I've gotten an amd64 desktop and started running FreeBSD/amd64 on it. I've had an amd64 capable machine before, but chose to run the i386 version of FreeBSD on it so I could use Nvidia drivers and have hardware accelerated graphics. (I think the linux flash player only runs on i386 too, but am not sure.)

So, I installed without issue. I included X in the installation and it worked fine. But, as I often do on new machines, I updated the ports tree and then began to install everything else I wanted and upgrade what I had there already, including X.

Then X wouldn't start correctly anymore. I had run it the first time without creating any config file. But, now it really wasn't happy. It would kind of hang, pointer wouldn't move and even <Ctrl>-<Alt>-<Backspace> wasn't working. (But, the computer wasn't hung. <Ctrl>-<Alt>-<Delete> still worked!) So, I created a config file (using one of those utilities, maybe 'x86config'). Still didn't work right. Then I started the process of changing different, random stuff in the config file to see if it would start working. It wouldn't.

So, I resorted to Go0gle, something I should have done alot sooner. I found this config file out there and it helped solve the problem pretty quickly. These two options in the "Server Layout" section did the trick:

Option "AllowEmptyInput" "false"
Option "AIGLX" "true"

Well, the "...EmptyInput" option rings a bell. :/ I don't really know much more. Is this a quirk of the amd64 platform? (But, if so, why did the release packages work without a config file?) Is this a quirk of the newer version of X?

Answers are hard to find when it comes to X. Be happy with a working config file.

gotbsd.net: technical difficulties ... resolved

The issues with gotbsd.net have been resolved. Yay!

Waiting for box to come back

This is a quick and easy tip, for the detail-oriented! Say a computer that you're interested in is down for some reason. Maybe you've rebooted it and you want to know the second that it's back on-line. Or maybe it's someone else's box and it's down and you (again) want to know as soon as it's up. You could just run ping and watch for the responses, but that's more traffic than is needed for a box that you know is down. And, what if you know it's going to be a while?

'ping' has a lot of great options and we can use those to send fewer packets and then quit as soon as the box responds. (So, if you're getting coffee or something when it comes back on-line, you're not just pinging it all day.) Here's the solution:

$ /sbin/ping -i 4 -o 10.1.2.3 ; echo -e '\a'
PING 10.1.2.3 (10.1.2.3): 56 data bytes

--- 10.1.2.3 ping statistics ---
35 packets transmitted, 1 packets received, 97.1% packet loss
round-trip min/avg/max/stddev = 2.856/2.856/2.856/0.000 ms

The '-i' option sets the wait between packets in seconds, which would have been 1 second by default. This was for an important box that I rebooted and needed to check as soon as it came back up. If the box was going to be down for a longer and/or unknown amount of time, you could set that higher, like 30 seconds. The '-o' option is what causes ping to exit as soon as it gets one good response. Then, I added the console beep ("echo -e '\a'") after the ping so I could go about something else and still be notified. (That form works for bash and sh, at the least.)

Hey, and I saved over 100 unnecessary packets! :) I did say this was for the "detail-oriented."

Seriously, though, I don't like the default behavior of ping -- going on forever until you stop it. I use it often and get tired of pressing '<Ctrl>-c' all the time. That's why I alias 'ping' to 'ping -nc 5'. (And, also why I used the full path above, to escape my own alias.) I think people mostly use ping for two different things: to measure the network delay to another host and to check reachability or presence a host. My alias does a reasonable job for both of those cases. The present case is what I'd consider to be a special and less common usage: waiting for a host you know is normally reachable to come back on-line.