If you put xdm_flags=”" in your /etc/rc.conf.local, xdm will start automatically during the boot process. This is probably what you want nine times out of ten. But, that tenth time, it’s annoying when X starts and you didn’t want it to.

I put the following in my /etc/rc.local instead of putting xdm_flags=”" in my /etc/rc.conf.local:

echo "Press any key within 10 seconds to bypass xdm..."
old_tty=`stty -g`
stty -echo -icanon min 0 time 100
_KEY=$(dd count=1 bs=1 2>/dev/null)
stty "${old_tty}"

if [ "${_KEY}" = "" ]; then
   echo “starting xdm…”
   /usr/X11R6/bin/xdm
else
   echo Bypassing xdm
fi

The first stty command waits 10 seconds for you to press any key. The value of that key is stored in ${_KEY}. If you pressed a key (${_KEY} != “”), rc.local does not start xdm and boots to a normal non-X login prompt. If you do not press a key, xdm starts and you’re greeted with the xdm login screen.

I hope that helps someone.

## OpenLDAP Server
if [ "$1" = "" -o "$1" = "openldap" ]; then
slapd_flags=”-u _openldap”
if [ "$slapd_flags" != "NO" -a -x /usr/local/libexec/slapd ]; then
      install -d -o _openldap /var/run/openldap
      /usr/local/libexec/slapd $slapd_flags
      echo -n ‘ slapd’
fi
fi

That way, I can stop OpenLDAP by running `sudo pkill slapd` and restart it with `sudo sh /etc/rc.local openldap`. The boot process is not affected because $1 == “” so, all daemons in my rc.local are started.

The cumulative sparc64 binpatch for Errata up to and including 002_openssh2 for OpenBSD 4.3 is also available.

I was honored that Mark chose to send the articles to me to publish. It was truly a pleasure to work with Mark and share these summaries with the OpenBSD Journal audience.

For the yaifo release accompanying OpenBSD 4.3, I decided to match OpenBSD’s version number. From this point forward, only one version of yaifo will be active. I will not backport updates for older versions of OpenBSD… who is “upgrading” to older versions anyway? So the current OpenBSD release and some recent version of -current will be supported.

You can download Yaifo 4.3 from SourceForge.

I will continue for a while to create binpatches for both 4.2 and 4.3 until it becomes too much work.
At some point soon, I’ll start supporting sparc64 4.3 binpatches.

It is a SECURITY fix. The description is:

Avoid possible hijacking of X11-forwarded connections with sshd(8) by refusing to listen on a port unless all address families bind successfully.

I’ve made binpatches for i386, amd64 and sparc64.

Both are SECURITY fixes.

For 009_ppp, the description is:

Buffer overflow in ppp command prompt parsing.

For 010_openssh, the description is:

sshd(8) would execute ~/.ssh/rc even when a sshd_config(5) ForceCommand directive was in effect, allowing users with write access to this file to execute arbitrary commands. This behaviour was documented, but was an unsafe default and an extra hassle for administrators.

I’ve made binpatches for i386, amd64 and sparc64.

Fighting spam takes a ridiculous amount of my time. I employ several methods of preventing the delivery of spam to this list and to the mailboxes on my server. Among these are blacklisting and greylisting.

With blacklisting, I use several methods to obtain lists of known spammers and tarpit those hosts. (See OpenBSD’s
spamd(8) for more info) If you have having problems sending emails to this list, the list manager (to un/subscribe) or me, perhaps your server landed on a blacklist.

With greylisting, if my server hasn’t recently “talked” to your server, your server gets a temporary failure message. If your server retries in 30 minutes (the standard), your message will be accepted. Many large email providers use broken methods to deliver mail. They use a pool of SMTP servers that rotate on retries. Since greylisting uses the IP address of the sending server (along with the sender email address and the recipient email address) to determine when a message should be delayed or delivered and these pools use different IP addresses for each host, it is theoretically possible that the message NEVER gets delivered if the pool doesn’t retry with the same IP address within the timeout period. For large known providers, I make an effort to whitelist their pools, but not all providers make that information easily accessible. Usually the downside to greylisting is that your message takes ~30 minutes to be delivered. It sucks when I place an online food order and don’t get the confirmation email for ~30 minutes (and their system ate the order and we assumed it was on the way).

When all else fails

If you are trying to contact me and my server is simply not receiving your messages, leave a comment to a post on my site. Comments are moderated and I’m a clever guy and should be able to figure out that you don’t actually mean for that comment to be made public. But if you’re concerned that I may not understand, put in the comment that you tried to email me and it didn’t work, please don’t publish this comment, …

Quote from the henning@’s commit message:

MFC (mcbride)
Correctly check that we have a complete rthdr before trying to do m_copydata()
on it.

I’ve made binpatches for i386, amd64 and sparc64.