Archive for the ‘Debian/Ubuntu’ Category

Compiling a KDE 3.5 app on Ubuntu 10.04

Tuesday, June 15th, 2010

I was trying to compile an old KDE 3.5 application this weekend because no port to KDE 4 has yet been made. Judging by the activity on the site, it is doubtful that it ever will be. For the curious, I was trying to get SchafKopf [1] up and running. I am running Ubuntu 10.04 (Lucid) which has long since ditched the KDE 3.x line for the shiny 4.x line.

While some of the KDE 3 libraries still ship, some key ones for this particular application were missing. Namely, libkdegames. The solution turned out to be the KDE/Trinity project [2]. This project attempts to continue development and maintenance on the 3.x line.

As a sidenote, this is what is so beautiful about open source software. The vendor threw out a line that was beloved of some and replaced it with something they did not like so well. Rather than being stuck, they can maintain the software themselves.

Back to the problem. All that I needed to do was install the libkdegames-kde3-dev package and run:

% ./configure --without-arts --includedir=/opt/kde3/include/kde
% make
% sudo make install

and everything was cool. --without-arts may or may not have been necessary after installing the trinity libraries. It was earlier. /opt/kde3/include/kde is where the includes were placed, instead of the standard path.

Have fun.

Living with Info

Tuesday, April 13th, 2010

Since my previous rant on Info
files
, I have
had yet another run in with GNU’s documentation system. This has
brought a couple of things to the forefront. First, that I have
some more random ramblings on the subject of GNU. Secondly, that
this time I couldn’t take it, and decided to find some things
that would make life livable with Info.

In my googlings, I found a discussion of
Info
in which the
Info-lovers seemed to be at a genuine loss to understand why the
rest of us despise Info with a passion. Almost without fail, you
find that the Info-apologist, at some point, says that they love
being able to navigate Info from Emacs. There is Info’s sweet
spot. If you are one of those poor souls who lives in Emacs (I
look up man and info alike from the commandline), Info will seem
pretty sweet. Bindings similar to the main editor (less bends
more towards the vi side of things), and the documentation
browser embedded in the editor. Not half bad. They also maintain
that the hyperlinks are an awesome part of it. As if text
browsers don’t exist or haven’t been fully integrated into Emacs
(everything is in Emacs, except a good text editor).

Fortuantely, there is hope. There are ways to avoid interacting
with info proper. The first option, on Server
Fault
,
is to convert them to plain text with info itself. Just run:

info --subnodes --output=output.txt infopage

And all of the nodes on the info page will be dumped into the
given output file. This can then be viewed with the pager of your
choice.

Another option, posited by the denizens of
reddit
is an application named
pinfo. It is a
nice little info page browser with lynx/vi/less like bindings.

I have tried both, but I tend to find myself dumping Info files
out to text more often and viewing them with less. It is much
more manly.

When You Need the Bleeding Edge

Monday, March 15th, 2010

For most applications that I use on a day-to-day basis, I am quite happy with the current version in my distro de jeur’s (Ubuntu, of late) repositories. Sure, a little more cutting edge would be nice, but good enough is good enough. I had technical writing professor once who bemoaned the fact that most people, students, professors, and professionals alike, only know about 10% of what their word processor could do. His facts were right. In non-technical fields, most people are probably only aware of 1% of what Microsoft Word could do. The same thing is true with command line apps. My most typical use of find is probably

find . -name 'foo'

Find has tons of options, but this one is the one I use the most. So, it is true that the versions in a given distro are not the bleeding edge, but, normally, I don’t need the bleeding edge–and I don’t have the time to care intimately about everything (I’m looking at you Gentoo–you’re a lot of fun if I’ve got a lot of time, but I don’t).

But there are a few applications that I use where it pays to be, or at least sit closer to, the bleeding edge. For me, those applications are:

  • sup–simply the greatest CLI mail program in human history. The best of mutt, pine, and Gmail in one easy to use application. I started using it version 0.8 or 0.9 (I forget which) and am using the current release, 0.11.
  • tmux–this upstart to GNU Screen offers lots of goodies to the discerning user. The first and most obvious is the ability to slice either horizontally or vertically, a much friendlier configuration file (I don’t use standard bindings on either GNU screen or tmux), UTF-8 support, and plenty of little technical details (true client/server being not the least of these).

The commonality is that, in both cases, we are talking about relatively young applications and projects that offer a nice set of changes to existing software. The features are the main mover, here. I would not go through the hassle of manually upgrading (through a manually-installed gem system for sup or from manually downloaded sources for tmux) and maintaining either of these applications if their corresponding old and stable projects had what I wanted. In the case of tmux, the biggest thing was horizontal and vertical splitting. The only way to get this in GNU screen is to download an unofficial patch and keep it up yourself. In my opinion, this is even more obnoxious than keeping a separate app, because GNU won’t breakdown and just add support.

What applications, if any, do you run on the bleeding edge? Or do you think the bleeding edge is a complete waste of time?

Setting up Mendelson AS2 HOWTO

Monday, February 8th, 2010

Overview

AS2 is a wire protocol for transferring files between two organizations. This guide explains how to get the mendelson open source as2 server up and running. The instructions are slanted towards set up on a Debian box, though set up on any *NIX system or Windows should be very similar.

The goal in this guide will be to set up two independant machines, one for test and one for production, and get them talking to one another.

Finally, this guide was developed and tested with mendelson AS2 version 1.1 and Debian 5.0.

Installation

Get the zip file from the Mendelson AS2 sourceforge page. No installation is needed (though an installer is provided for Microsoft Windows boxen), just unpack the files in some location. What I did, was:

  • create a separate user to run the AS2 software (named, cleverly enough, as2user)
  • Unpack the software in a directory in the as2user's home directory.
  • Run the software in a GNU Screen session
  • For the GUI portion, run a lightweight window manager (IceWM was my choice) and a VNC server.

As always, your mileage may vary. Out of the box, the mendelson as2 server is configured to interact with the mendelson test server, and nothing else. The next step is to set up the keys.

Configuring Keys

This process can be done with Portecle, keyman, or the OpenSSL toolchain. The most user-friendly of these is Portecle, which is also the one that Mendelson recommends. Because Portecle is pretty straightforward (and, if you choose one of the other tools, you almost certainly know what you are doing anyway), we will skip the exact sequence of clicks or commands needed for this.

Mendelson AS2 stores its keys in the certificates.p12 file in the root of the install directory. The password for this store is, incidentally, test. The first thing we need to do is recreate the private keys. What we do is delete the keys (or delete the store and create it afresh with new keys with this name) and create new ones. The names of the keys are Key1 and Key2.

After creating the private keys on both machines, we need to export certificates for each, then exchange them. If mendelson AS2 is running, the certificates and keys can always be reloaded by clicking File → reload key store.

Patching the Scripts

Mendelson AS2 comes with DOS Batch files and Bash scripts to launch the AS2 server on Windows and *nix machines, respectively. Not to be degrading or anything, but the bash scripts do not appear to have been well tested. I had to make the following changes to them:

  • Both the mendelson_as2_start.sh and mendelson_as2_stop.sh files used Windows line endings, instead of UNIX. The dos2unix script (available in the Debian and Ubuntu package managers) fixed this problem.
  • Make both of the aforementioned files executable
  • At the top of the mendelson_as2_start.sh file, there is a line setting the CLASSPATH. I had to modify it to CLASSPATH=as2.jar:jetty/start.jar:jetty/lib/servlet-api-2.5-6.1.1.jar

Once the appropriate changes have been made to the start scripts, just run:

./mendelson_as2_start.sh

from the install directory.

Configuring the Local Station

Before the server can receive messages, it must be configured as a local station. By default, a local station will already be set up. The parameters just need to be adapted to match the actual environment. Pretty much, all you will have to change right off the bat is the MDN (URI), which is set to a mendelson domain. While here, you will also need to select the keys you generated above for the local station under the Security tab.

Configuring Partners

After a minute or two, the GUI will pop up. It is here that the AS2 partners must be set up before files can be exchanged. Take the following steps:

  1. Click the button labeled “Partner” (or go to File → Partner).
  2. Fill out the forms. The rest of this should be fairly obvious, but to go over it:
    • Misc
      • Name
      • AS2 ID
      • email address – a contact
      • comments
    • Keys – if you imported the keys above, the certificate for the trading partner should be available from the drop down. Select it or bad things will happen—I promise.
    • MDN – the URI of the recipient.
  3. Click Ok

Sending Messages

This part is easy. Copy a file to the intended recipient’s directory on the server. By default, mendelson is set to poll for new files every 10s (a little inotify support here would rock). In general, from the mendelson install directory, the location will look like:

/messages/<partner name>/outbox

Conversely, the messages will be received on:

/messages/<local station name>/inbox

Copy and run. The main windows on client and server will show their respective progresses.

Configuring HTTPS

At this point, if everything has gone according to plan, messages can be exchanged in plain HTTP. In many situations, however, we want to exchange messages over HTTPS for added security. To do this, we must:

  • Configure Mendelson AS2 to use HTTPS
  • Generate new keys for the HTTPS store
  • On the sender, import the certificates for the recipient

This may sound a little confusing, given that we discussed generating keys above. It turns out that Jetty (the HTTP server & client that Mendelson AS2 uses) has its own separate, independent keystore for sending over HTTPS. Moreover, the keys are expired, which is probably just as well because it makes us generate fresh ones.

Under the main Mendelson AS2 directory, there is a directory named jetty/etc containing Jetty’s configuration files. Jetty itself uses jetty.xml and an example configuration for SSL is in jetty-ssl.xml. Copy the following code from jetty-ssl.xml into jetty.xml:

<Call name="addConnector">
  <Arg>
    <New>
      <Set name="Port">8443</Set>
      <Set name="maxIdleTime">30000</Set>
      <Set name="keystore"><SystemProperty name="jetty.home" default="." />/etc/keystore</Set>
      <Set name="password">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
      <Set name="keyPassword">OBF:1u2u1wml1z7s1z7a1wnl1u2g</Set>
      <Set name="truststore"><SystemProperty name="jetty.home" default="." />/etc/keystore</Set>
      <Set name="trustPassword">OBF:1vny1zlo1x8e1vnw1vn61x8g1zlu1vn4</Set>
    </New>
  </Arg>
</Call>

You’ll notice that it references the defunct keystore. Create a new keystore, populated with two keys from the following commands:

keytool -genkey -alias Key1 -keypass changeit -keysize 1024 -keystore my.keystore -keyalg RSA -storepass changeit

keytool -genkey -alias Key2 -keypass changeit -keysize 1024 -keystore my.keystore -keyalg RSA -storepass changeit

where my.keystore is the filename of the new keystore and changeit is the password for the store.

For password, keyPassword, and trustPassword, put the values corresponding to those used in the keytool commands.

From the destination, export a certificate and import it into the keystore that was just created.

Conclusion

Once you have the AS2 server up and running, the process of adding real life partners is fairly similar. The only other parting tip I can offer (thanks to the forums) is that if, at any step, something goes wrong the start up script can be patched to provide a lot more debugging information by changing the last line of mendelson_as2_start.sh to read:

java -Xmx192M -Xms92M -classpath $CLASSPATH -Djavax.net.debug=all de.mendelson.comm.as2.AS2

the addition is -Djavax.net.debug=all. As implied this will dump all sorts of goodies to the terminal.

Appendix – Signed MDNs

As of Mendelson AS2 1.1 – build 29, there is a bug that causes verifcation errors with signed MDNs sent by mendelson AS2 to non-mendelson AS2 servers. The solution is to get the b29 source module from CVS (on Sourceforge), change all occurrences of “\n” in the message strings to “\r\n” in MDNText.java, then navigate to de/mendelson/comm/as2/message and run:

javac -classpath /path/to/as2.jar MDNText.java

this will create a new MDNText.class file. Unzip the jar somewhere that will not trample anything, replace the MDNText.class file, and create a new jar. This updated file should solve the problem. At least, it did for me. Your mileage may vary, of course.

Sources

Ant

Monday, December 21st, 2009

I poked fun at Ant before. I applaud the devs for trying to develop a better development tool. I also see the usefulness of a less Unix-centric build tool when writing in Java (WORA, right?). The problem, as I see it, is that their cure is ultimately worse than the disease.

It is annoying to have to deal with hard tabs in Makefiles, but can anyone really claim that handwriting XML is more pleasant? I certainly cannot. A couple of commands in vim and the Makefiles are easy enough to work with. Nothing can take the pain of XML away–not even the hierarchical editors that are becoming common.

Another virtue of the Makefile is its beautiful simplicity. We have dependencies and then we have commands that can be used to update those dependencies that are automatically generated. An Ant build file, on the other hand, requires that all of its tasks be Java classes.

This makes Ant much less useful in the generic case. I have been playing with some literate programming lately and have to tangle the source out of the original Noweb file. In a Makefile, this is easy enough. In an Ant file, I have two choices: break out the Java compiler and write an Ant task to handle Noweb files cleanly. Or I can use the exec command (at least, I think that is what it is called–it is what NAnt calls it). If I do the former, I get a lot of overhead to do something simple. If I do the latter, I have an ugly XMLified Makefile.

In the final analysis, I think Ant would have been a lot more useful if it had kept the Makefile’s cardinal simplicity and removed the ugly parts (hard tabs). To make it truly platform independent, common shell commands (copy, delete, etc.) may have needed some massaging by the Make system.

Unixing away from phpMyAdmin

Tuesday, December 8th, 2009

Here at the ol’ job, we use MySQL (something that I have blogged about before) and, naturally, have phpMyAdmin installed. I seldom use it as I prefer a a nice, CLI interface. It does provide a few amenities that have log me in even when I don’t strictly speaking need it. Some of these are the editing feature (yes, I am lazy enough that sometimes I would rather not sit down and write out an UPDATE query), the printing (which is much nicer than out-of-the-box lp or lpr on *nix machines), and dumping stuff to CSV or Excel (which is nice for one-off reports that I occasionally have to run).

The last couple of days, while working on some reconciliation type reports that get a little involved, I decided to take advantage of the Unix philosophy (a tool for every job, do one thing and do it well, etc.) and make my life quicker and easier from the MySQL command line. So, here is a look at the various tweaks I’ve made.

The first thing to look at is paging. The client doesn’t do any out of the box. After jacking off with a handful of pagers (less, more, most, and w3m) I decided on w3m for reasons that will soon become fairly clear. To make mysql page, simply run the command:

pager w3m

or more, less, most, etc. Whatever command you want to be the pager. This setting can be made permanent

Next up, we have printing. This is why I chose w3m. less and most provided no way that I could see to pass the piped-in text off to a printer. If some pager coniusseur would care to correct me on this score, I am all ears.

Set:

keymap C-p SAVE_SCREEN “| a2ps -r test.txt -1 -r -f 7pts”
keymap q EXIT
keymap C-p SAVE_SCREEN "| a2ps -1 -r -f 7pts"
keymap q EXIT

The second item maps q to exit without confirmation. Out of the box, w3m always prompts. I hate being prompted. Remove at your liking. The first line maps the sequence Control + P to a SAVE_SCREEN command (which is used to dump pages to files) and then pipes it to a2ps. You can look up the options for a2ps, but the end result is that, since no output file was specified, a2ps prettifies the text handed it and sends it off to the printer.

Finally, we have that little problem of dumping to Excel. We do not have to dump straight to .xls or .xlsx format. CSV will do, despite being a poor format in general. MySQL can do this part natively by running a query like so:

select * from foo
into outfile 'someplace.csv'
fields terminated by ',' lines terminated by '\n';

This is nice, but, speaking for myself, I usually review the results before dumping them out, just to be sure it looks roughly the way I want or expect. Another good way to do this, is to simply put the query into a file and run it like this:

mysql -uuser database < query.sql

When in noninteractive mode, the mysql client outputs the records in a tab delimited format. Piping this through sed and into a text file will create a simplistic CSV or opening it in tab-delimited form with a spreadsheet app (like Excel or OpenOffice Calc) will allow it to be exported to a more friendly format.

What I Want in a WM

Monday, November 2nd, 2009

I have been looking at various Window Managers lately. The major desktop environments leave me feeling a little dissatisfied.

  • KDE – I loved the 3.5+ branch of KDE. However, the world is moving on and that may not be an option much longer. The 4.x branch has been unstable on my machine. It works all right and looks excellent, but my desktop sessions disappear every so often.
  • Gnome – Gnome treats me like an idiot. I don’t like patronizing software. It is too eager to offer me information I don’t want.

Both KDE and Gnome offer a wide variety of keyboard shortcuts, but there are many operations that can only really be done with the mouse. In both cases, I want every single window manager operation to be performable from the keyboard. Again, speaking of options, I don’t think it needs to be required, but there should be no less power at the keyboard than there is for the mouse.

A quick look at the alternate window managers of the Linux world show that a lot of other hacker types want the keyboard capabilities I want. In addition, the window managers are infinitely extensible. However, I have two major problems with every one of the window
managers I have looked at or tinkered with:

  • They are ugly. I don’t need Mac OS X beauty on the desktop, but I do not want something that looks like a ’93 desktop put through a blender. I have to look at the screen a lot of the day. It doesn’t have to be drop dead gorgeous, but it can’t look like pure trash either.
  • They drop their extensibility in my lap. I appreciate that every single detail can be tweaked, but not every detail should be tweaked. Some reasonable defaults are vital, especially when evaluating window managers. If I have to spend a few days reading their APIs and writing customization files in various scripting languages, why should I invest that much effort just to learn whether or not the window manager has the potential to be what I need it to be?

Especially hard for me to understand is the first one. I can understand that to the small communities of hackers working away on their window manager, the extensibility is exciting. Since they know every detail of the innards anyway, it doesn’t annoy them to have to
look at the API first.

But how can these themes be seen as anything other than astoundingly ugly? Browsing through a lot of the theme galleries just make my eyes hurt. They make Windows 95 look like the space age of computing. So, here is the window maker/desktop environment (I do not care to haggle about which it is) I want looks like this:

  • Keyboard it all. If I want to move, resize, retile, restack, etc. windows from the keyboard, I can.
  • Reasonable defaults. The full functionality is available withoutvhaving to fiddle with personal startup files. I can start it up and begin tweaking it from there.
  • Easy on the eyes. Antialiased windows, rounded off window borders, and tasteful window decorations are key. Again, Compiz/Vista like effects are not necessary. Just some good taste.
  • A respectable collection of widgets. Look at OpenBox or Fluxbox. They have many panels written for them. This is a good thing overall, but could we start by having at least one good panel included in the default distribution?

I am still on my quest. I suspect that if I work hard with Fluxbox or Awesome, I will be able to get what I want. Whether I have the time for this in the near future is, of course, another question entirely.

Ubuntu’s Hardware Support

Wednesday, September 16th, 2009

When I bought a new computer over a year and a half ago, I was unpleasantly surprised to find that the then-present Ubuntu did not support my hardware in full. I have written here about some of the trials and tribulations I have had getting everything set up just so. Ultimately, I had to wait a couple of versions, but the most important thing I did to get everything running stably was to upgrade from the Ubuntu sanctioned kernel version of 2.6.28 to the newer 2.6.30.

Many an article has been written about how I never should have had to do that or know that or have any concept of what a kernel was, how it differed from the operating system or desktop environment as a whole, or what version I needed. I will say upfront, that I agree. While I have a pretty good nuts ‘n bolts knowledge of a Linux desktop, I should never need it to get up and running. The real problem here is less one of raw technical capability (since I was able to solve the problem with an upgrade), than it is the simple fact that most manufacturers give Linux no thought on the desktop. Windows would run a lot rougher if OEMs didn’t work with Microsoft to ensure that it is otherwise. The idea of this all working, out of the box, with no OEM involvement is simply ridiculous. The only ones who can test a hardware configuration before it is released into the wild are the ones putting it together in the first place.

Until OEMs start working with the major Linux distros (or, at least, the major distro of their choice), this problem will never entirely go away. Contrary to what many Linux advocates say, OEMs are not evil. Ultimately, they don’t care what operating system people run, as long as the money winds up in their project. If Dell believed that an immediate adoption of Haiku (an OSS BeOS clone) would make them top dog, they would do it. Apple straddles a fine line between being a software company and a hardware company, but this is not so of HP/Compaq, Dell, Gateway, eMachines & company. They sell boxen. If changing OSes or supporting more OSes would mean more sales, they would do it.

The only way, then, that the OEMs will ever support Linux will be when there are enough Linux desktop users that it is worthwhile in terms of simple supply and demand. The only way that Linux will make its inroads is if distro packagers make life as easy as is humanly possibly in the meanwhile. I have to assume that I am not the only one to purchase a machine that needed a bleeding edge setup to work properly. So, the only way to really service these users (like me!) is to make it easier to go bleeding edge when it is necessary. I understand the idea of sticking to a version of the kernel, like 2.6.28, for the duration of a release. It makes it a lot simpler to ensure that all of the software will work together.

However, to accommodate those with newer rigs, the clear solution is to make it easier to go bleeding edge. It should not be something so trivial as clicking a check box on some preferences dialog, but it should be easier to use a later kernel with a given release. Fedora almost gets it right with Rawhide. By changing a simple option, you can go bleeding edge. However, it is less bleeding edge than it is like running off a random dev’s test box. You never know if it will work the next morning. For the system components that directly support hardware, like the kernel and some of the low level daemons, I would recommend a special backports type of repository that is being updated alongside the new one. If there are hardware difficulties, make it easier for the user to use NDISwrapper (the best thing to ever happen to Linux wireless) and upgrade to later versions of the kernel without sitting atop of Linus’s Git branch. It would not be perfect, but it would help a great deal because, as things stand now, you have to fight with Fedora or Ubuntu (or else do an inordinate amount of work) to use a version of the kernel that is not officially sanctioned.

I didn’t know you could do this…

Thursday, August 13th, 2009

I was paging some code through less and accidentally hit the ‘v’ key, and it launched my editor on the file. Unfortunately, it doesn’t work when the file is coming through stdin (though you could rerun the command and redirect the output, launching the editor afterwards). This would be easy to implement. Dump the input until EOF into a file in the /tmp directory, then launch the editor on it. I pulled open the man page and confirmed it. I guess this just falls under live and learn.

Adding Some Color

Tuesday, July 28th, 2009

This may sound crazy, but the thing I miss the most about Gentoo is its nice, pretty out of the box terminal. I do a lot of work from a good old shell, no matter what the OS. Even on Windows, I often whip out cmd to do basic file management. It is just much quicker and more efficient.As with any environment you spend a lot of time in, it is nice if it is easy on the eyes. Today, I got utterly and truly sick of Ubuntu’s no-color prompt so I busted Daniel Robbins article “Prompt Magic” and built the following prompt:

PS1=”${debian_chroot:+($debian_chroot)}\e[34;1m\u\e[0;1m@\e[32;1m\h:\e[0;1m\w\e[32;1m \$ \[\e[0m\]“
  1. export PS1

The Debian chroot business is lifted from the default /etc/profile. This generates the following:

Imperfect, but much better.