Yesterday, I stumbled over an interesting problem with Wine: If a ServerName directive exists in /usr/local/etc/cups/client.conf, i.e., if you are connecting to a shared server for printing services, programs started with Wine seem to hang.

This problem is caused by non-reachable servers. It might occur when you change your network or when the shared server is unavailable. In this case, Wine will seem to hang. More precisely: If you wait long enough, the application will run eventually. But nobody likes waiting very much.

So, if you have a similar problem, abort the "hanging" application and check the console output. My output contained the line

module:attach_process_dlls "winspool.drv" failed to initialize, aborting

and to solve the problem, I simply changed client.conf by adding

ServerName localhost

in the first line and restarting CUPS via /usr/local/etc/rc.d/cupsd restart.

Since the blog seems to be the entry point for most of my visitors, it makes sense to announce new content. Be it hereby known that there is a new HOWTO online. It explains how to use the Microsoft Windows 7 boot manager to boot FreeBSD.

Enjoy.

If you cannot trust your local network for some reason, SSH tunneling can help you. All you need is:

• A machine outside your current local network, for example a server with a static IP address in some data centre.
• ssh (on your local machine)
• A proxy server (on the remote machine)

My remote machine runs Debian, and I decided to install tinyproxy, a tiny HTTP proxy server. Configuration is done quickly by adding the following lines to /etc/tinyproxy/tinyproxy.conf:

	Port 	8888
	Listen  127.0.0.1

I would recommend commenting out any other Listen lines. Assuming you do not want to run an open proxy, you only want tinyproxy to listen locally. After editing the configuration file, restart the proxy via /etc/init.d/tinyproxy restart.

On your local machine, execute the following command:

	ssh user@server.example.net -L 1234:localhost:8888 -N

This forwards all traffic from your local port 1234 to the remote machine's port 8888 (localhost is needed because we configured the server to listen only to the loopback interface), which is where tinyproxy waits for inputs.

You may now tell your cool browser to use localhost:1234 as a proxy server—congratulations, your web traffic is now securely tunnelled to your remote machine.

Addendum: In the command string from above, you can also use -f to request ssh to go into the background.

The last update of my local ports collection was most annoying and unnerving. Here are some notes to dodge 3 of the bullets.

Xorg 7.4: Either disable HAL at compile time or add the following to your xorg.conf (assuming your keyboard is configured properly etc.):

Option	"AutoAddDevices"	"OFF"

Else, you would have to configure your keyboard settings (such as layout, rules etc.) in some obscure HAL configuration file that is hard to find. And to be frank, I was unwilling to create some XML files in a directory pretty well hidden on my hard disk just to get my X server to accept input from German keyboards. Seriously, what is wrong with the InputDevice section in Xorg.conf?

libxine: Don't compile it with pulseaudio support if you don't need it. I did compile it with that option and my reward was that programs such as Xine or Amarok would hang. Using the last of their strength, they would utter cryptic messages on the command-line:

caps.c: Dropping root privileges.

Since I did not need pulseaudio, I recompiled libxine, Xine, and Amarok and successfully resurrected them.

CUPS: Be sure to install print/gutenprint from the ports collection. Your applications and printers will thank you for it. And as a boon, you will not get any Unsupported format 'application/postscript' messages because all necessary dependencies will be available.

That's it. FreeBSD FTW!

Having used GnuCash for a long time, I was quite startled when the € symbol was not displayed properly anymore (after a make buildworld odyssey). Instead, all I got was "Eu". Ironically, every other currency seemed to work properly.

A vicious attack on the currency of many countries? Probably led by a cabal trying to undermine the world's economics?

No.

Just a glitch in the locale settings: Changing the second line in /usr/share/locale/de_DE.UTF-8/LC_MONETARY to "€" brought the currency back. Keep in mind that you might have other locale settings; find them out by entering locale in your terminal and change the appropriate file.

Back to managing money. By the way, did you know that Thursdays are really, really bad? According to GnuCash, these are the days where I tend to spend more money than usual. Interesting.

Unicode is really nice: Less meddling with codepages, less display problems etc. Here are some notes explaining how to enable this functionality for FreeBSD.

On my system, two steps were required. Step one involved changing .login_conf (in my home directory). I added the following lines:

me:\
        :charset=UTF-8:\
	:lang=de_DE.UTF-8:

After logging off and on again, locale settings should work properly. Step two involved changing .gvimrc in my home directory because the fonts listed there had the wrong charset. Instead of ISO8859-15 I used ISO10646-1. This convinced vim to work properly, too.

Filenames:

For those of you who do have files with filenames in the "old encoding" the tool convmv might prove invaluable. FreeBSD users get it from /usr/ports/converters/convmv and might want to take a look at the man page.

Conclusion:

There is only one drawback: Unfortunately, if you are trying to use the console (without X running), things might get ugly. Apart from that problem (which can be fixed by temporarily resetting the input locale), all things "just work". My, my. Isn't that something?

After updating my system to FreeBSD 7.0, I received the following error from Opera:

Opera encountered a problem during plug-in setup.
Plug-ins will not work properly.
Check your installation.

Could not locate plug-in 'libnpp.so'.
This executable is included in the install package.


This executable is included in the install package.

Could not start plug-in executable 'operapluginwrapper'
/usr/local/share/opera/plugins/operapluginwrapper

Plug-in path
(Path can be modified in Preferences dialog)

/usr/local/share/opera/plugins

Some searching brought me upon a post in the offical Opera forums. For reference purposes, I will archive it here. To solve the problem, follow these steps:

Close Opera. Use the root user to edit the file /etc/libmap.conf (create it if it does not exist). Add the following lines:

[operapluginwrapper]
libXThrStub.so.6 libXtst.so.6

After a restart, Opera should work fine now. Apparently, only the wrong library is used to start the plugin wrapper, the lines above should fix this.

According to its man-page, ssmtp is a "send-only sendmail emulator", hence allowing your machine to send, say, status reports via mail without the need for sendmail or any other MTA.

ssmtp is simple to use, simple to install and works very well. I use it on my file-server: Without further ado, several scripts and programs (such as smartmoontools) can now send me their reports directly to a given mail address.

FreeBSD users just cd to /usr/ports/mail/ssmtp and do the usual make install clean. Afterwards, this is how your ssmtp.conf (located in /usr/local/etc/ssmtp/) should look like:

root=catchall@example.net
mailhub=smtp.gmail.com:587

rewriteDomain=example.net
hostname=mail.example.net

FromLineOverride=YES

UseSTARTTLS=YES
AuthUser=your_gmail_account@gmail.com
AuthPass=swordfish

No, my password is not "swordfish". The above settings work very well for my gmail account, providing an easy and secure way to get status reports. To let the script send you mails, just add a "MAILTO=me@example.net" statement to your crontab, for example.