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.

"Call to undefined function preg_replace()"

I was trying to run/install a PHP site and I was getting blank pages and found this error in my web server logs: "PHP Fatal error: Call to undefined function preg_replace() in /path/to/file.php" This is not a terribly difficult problem and people with PHP experience are probably already yelling: "PCRE!" at the screen. :) (That stands for Perl Compatible Regular Expressions.") I only write this post because the web search of this error did not give an obvious answer in the first couple of hits.

If you're in FreeBSD, the solution is simple: install the port "devel/php5-pcre" (or "devel/php4-pcre" as appropriate). Do that from the ports tree by changing to the directory "/usr/ports/devel/php5-pcre" and typing "make install" as root. Or, you could just run "pkg_add -r php5-pcre" (as root). If it's already installed, then reinstall it from the ports tree. Then you'll probably have to restart your web server as well.

While I usually try to avoid editorializing, it seems to me like the PCRE extension ought to be part of the standard library in PHP by now! (Does PHP have a standard library? I tend to think in python. :) )

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.