Truncated syslog messages

This is a surprisingly easy fix to a very irritating problem. My problem was just this: I'm using the system log (syslog/syslogd/logger) for things other than just system messages. If there's a long message, it will get the end chopped off. The log message is too short. This isn't working for me.

I don't even remember where I found all of this, but the problem is that syslogd has a hard limit of 1024 characters per line logged. To raise this limit, all we have to do is find the source file, change that value, recompile, and reinstall. Of course, you must have the system sources on your system to do this. (If you don't for some reason, you could use csup to get them.) I've recently used this very technique in FreeBSD 7.x and it worked like a charm. I think it will work just as well in other versions of FreeBSD, and possibly other OS's as well.

As root, follow these simple steps:

1. This is pretty safe, but just in case: cp -p /usr/sbin/syslogd /usr/sbin/syslogd.bak
2. cd /usr/src/usr.sbin/syslogd/
3. vi syslogd.c
4. find this line in that file (line 71 for me):
   
   #define MAXLINE 1024 /* maximum line length */
   
   ... and change '1024' to the value you need (maybe 2048 or 4096).
5. make obj && make depend && make && make install
6. /etc/rc.d/syslogd restart

That's it! You're now supporting longer syslog messages.

This trick is actually old hat. I've seen this problem a long time ago and was aware of this solution. But, I doubled-checked a web search, and I found that unless you already knew some key search terms (like "syslogd.c" or "MAXLINE"), you weren't going to get many useful results. So, I went ahead and wrote this.

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.

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.

Your own web-hosting dogfood

I've had a little project going on for the last few months. It is gotbsd.net, a site for downloading FreeBSD ISO's via BitTorrent. The subject of this entire project should really be a post of its own (... one day). But, the short story is that I think BitTorrent is a great way to distribute large files and when the Project's official torrent site was taken off-line, I thought hey, FreeBSD should have a torrent site -- I'll make one! For that, I needed to run a tracker, and for that I needed a dedicated server. That costs a little bit of money.

Recently, the Project has re-started an official torrent site. Of course, I think that's a great idea, but it leaves gotbsd.net out in the cold! So, I've got this domain, I don't want to just abandon it outright, but I can't keep paying for a dedicated server either, since its last, slim hope of paying for itself is long gone. The answer is to go without the tracker and move this to an inexpensive web host, maybe with some re-purposing later.

Now the trick is this, a site dedicated to FreeBSD really needs to run on FreeBSD. So, let the search begin. First stop: Netcraft. Everyone loves to play the "my favorite OS is the most reliable" game, and Netcraft's monthly reliability reports are a favorite arena. From there, I gathered this list of FreeBSD based web-hosting providers, along with their top ten rankings (if any) of the previous three months:

Site	month 10,11,12
www.3fn.net	,3,4
www.nyi.net	4,,8
smallbusiness.yahoo.com	,,7
www.datapipe.net	1,,
www.reliableservers.com	,6,
www.swishmail.com	7,,1
www.ipowerweb.com *	,7,
www.pair.com	,,
www.globat.com	,,

"ipowerweb" is a tricky one. Like many web hosting companies, they sell services under more than one name, also selling under the name "ipower". I used Netcraft's site report (link), to validate a lot of these (granted, all that really tells you is what the company's home page is running and it doesn't guarantee that's what they're selling). "ipower.com" seems to have recently switched off of FreeBSD to the commercial F5 Big-IP operating system. "ipowerweb.com" is still on FreeBSD. But, they're definitely the same company, so are they moving away from FreeBSD?

Swishmail is an interesting company, but they provide a variety of services and their web hosting is too expensive for what I want. Globat, BTW, I didn't find on Netcraft, but I did use the site report to verify that they're FreeBSD. 3FN looks pretty darn good; they have good prices and a good selection of different plans. ... There are so many! I'm still looking at the rest, but will try to update this page with anything interesting that I find out.

The Project's main web site, I recall, also has a page that lists vendors. I wanted to check that, too. I was expecting to find a lot of the same names, but I didn't (just Swishmail). All of the below mention "web hosting" in their summary on the list of "Internet Service Providers" on freebsd.org:

• www.active-venture.com
• www.aplus.net
• www.cmagic.biz
• www.gradwell.com
• www.hostdepartment.com
• www.kionic.com
• www.kuwaitnet.net
• www.ppgnetworksolutions.com
• www.negimaki.com **
• www.s4servers.com ***

I only ran through these very quickly to see which were up, but Host Department is one that caught my eye and I'm definitely going back to check out. There was one which I left off the list as it was in an inactive state. Negimaki gets asterisks because they're doing something specialized with photo galleries it looks like. And, "s4servers" (Seiretto) gets a big asterisk because the first thing you see on their page is "Choose linux or Windows". :/ I was going to drop them entirely, but I hit them with the Netcraft site report and both of their home pages are running FreeBSD. Go and figure.

Printing from Windows to CUPS

This is too good to wait on, even though it's late and I'm a little tired. May fill in more later. I have a printer. I hate the Windows drivers that come with it, they're full of ads, obnoxious automated update pop-ups, they hog a lot of memory and CPU, etc. That's alright, I usually use FreeBSD anyway and CUPS ends up working great. I had to find the linux drivers for my particular printer in another port (hpijs or hplip (YMMV)), but was not a big deal. I'm printing over the network from FreeBSD. Everybody's happy.

But, I have a Windows machine for the kids and now they're constantly wanting to print things for school. Sometimes they can use the FreeBSD machine, but sometimes it's not convenient. What I want is for the FreeBSD machine to be a print server to the Windows machine.

So, I know!, Windows means samba and there's a port named "cups-samba". This must be just what I'm looking for. ... Well, it was kind of what I was looking for. But, it was too much trying to do things the Windows way. A little painful. What I discovered in digging around was that I didn't need cups-samba or even samba. CUPS by default leaves a port open for printing and you can use IPP to print directly to a CUPS printer via the network, even from Windows, and using generic, Windows Postscript printer drivers already on your Windows machine (probably).

My breakthrough came from a Gentoo wiki (here) where I found this great wisdom on the subject:

I don't understand why this HOWTO includes Samba functionality. It seems to me to be an inappropriate security risk, especially if your goals are simply what this HOWTO is addressing -- setting up a printer on a Gentoo box using CUPS, and using that printer natively with Windows.

Using IPP, you can axe everything in this HOWTO regarding printing via Samba. CUPS setup as per the HOWTO looks good. I use [OPTION 1] setup in my mixed-OS environment:

[OPTION 1] Generic PS Driver using MS Publisher Imagesetter driver

Windows: run Add Printer, select "Connect to a printer on the Internet..." and enter the URL for your printer (http://<computer-ip>:631/printers/<cups-printer-name>). When it asks for a printer manufacturer, select "Generic", and the printer "MS Publisher Imagesetter".

There's not much more to say. It worked perfectly. I printed out a little sudoku puzzle to test it.

Your very own caching DNS server

If you're using FreeBSD you may not realize that you already have the software on your system to run a DNS server. Why should you run a DNS server process?! Really just to tinker. Networks are so much faster and reliable than they once were, that the small amount of network traffic you could save from running your own caching DNS server is probably not worth the trouble.

For you tinkerers who are still with me, the first thing you need to do is find the configuration file. The software is called BIND (Berkeley Internet Name Domain); the actual executable is called "named". (Seems like they might have worked the letters 'dns' into one of those, but no.) The file we need is "named.conf" and it's located in the directory "/var/named/etc/namedb" (which "/etc/namedb" is linked to, by the way). (I'm doing this all in FreeBSD version 6.x incidentally, and am not sure if things differ in other versions.)

Once you've found "named.conf" back it up. I usually make a copy in the same directory suffixed ".ORIG" or something of the like. Now edit "named.conf". The main things you must take care of are to uncomment this line:

   forward only;

(delete the two slashes) and then find your ISP's DNS server address(es) (should be in "/etc/resolv.conf") and use those to replace "127.0.0.1;" in the "forwarder" block, like this, for example:

   forwarders {
      208.67.222.222; 208.67.220.220;
   };

Be careful to leave commented out all of the various "example" zones at the end of the file.

One more thing that's important is the "listen-on" statement -- for basic security if nothing else. I know you're already running a firewall. :) But, we follow the onion security paradigm and so we set this as well. If you're only going to access this DNS server from the machine that it's on, then the default that's already there is all you need:

   listen-on { 127.0.0.1; };

But, if you've got an internal network that you wish to share the DNS service with, then simply add the IP address of the internal interface. (E.g., "listen-on { 127.0.0.1; 192.168.100.1; };".)

Now you can enable this by putting a line that says 'named_enable="YES"' into "/etc/rc.conf". Then you can start the server by running the command "/etc/rc.d/named start". (It uses a system start script since it ships with the system.) Finally, edit "/etc/resolv.conf" and change whatever IP was in there to "127.0.0.1". ... And, beware, DHCP and PPP may rewrite resolv.conf when they make a new connection. I haven't decided yet if the best solution to that is to make the file unwritable (will DHCP get mad?) or just to make a script that rewrites it back to 127.0.0.1.

More fine print

There's also a small question about those two zones in the middle for the loopback addresses. I can tell you the server works fine with them commented out and it works fine with them there. Purists say that you should have those zones and have them properly configured. I'm not sure why, since localhost will get resolved via "/etc/hosts" before it even hits DNS. Anyway, if you prefer to leave them in, just go to "/var/named/etc/namedb/" and run the set-up script for the loopback zones like this: "sh make-localhost".