DIE WIKI DIE

A Wiki is good for recording and storing all of the shit that comes out of your brain.

A Wiki is a terrible place for managing and showcasing all of the shit that comes out of your brain.

The Wiki love affair has got to stop. Please, make it stop. At least stop using Wikis as your primary technical support system.

1) Every wiki is out of date. It doesn't matter how much information you've got in your Wiki if much of it no longer applies.

2) Wikis have no good mechanism to determine what content is out of date. They also have no mechanism to convey to the reader that the information may be out of date. A Wiki relies solely on the writer to maintain the validity of the information, and the writer can't do that, as evident by his use of a Wiki to manage information. What's so bad about out-of-date information? It costs your consumers time. Lots and lots of time.

3) Wikis encourage "yada yada" explanation.

4) Wikis disrupt discussion forums, which are vastly more immediately useful. (Reply: it's in the wiki).

5) Wikis encourage bad information management through the very feature that makes a Wiki unique and useful.

6) Wikis are often difficult to navigate and search, as Wikis are often designed with the Wiki writer in mind.

In conclusion, I hate Wikis. If you need a helpdesk application, then use one.

Liferay + Alfresco = Lalfrescoray

Hey what's that, some egg on my face?

My comments about the Liferay WebDAV support in this whiny article are incorrect. As of Liferay 5.1 WebDAV does seem to work since I replaced a goofy NIC in my server. Please see the article comments for more information.

*************************************

Once again I find myself stuck between two partial solutions that I can't combine to solve what seems to me to be a rather simple problem. Here it is:

1) I need a "portal".
2) I need a document management "portlet".
3) I must access the document management system via CIFS or WebDAV.
4) The system must be somewhat seamless; single sign on at least.

After reviewing some options, I decided that Liferay should be able to meet my requirements. It's a "portal" with lots of "portlets" included, including document management. (notice my sarcastic quotation marks)

DENIED: Liferay's WebDAV doesn't work well enough to be considered well enough.

Ok ok, I've heard a lot of talk on the ol' blogosphere about integrating Alfresco and Liferay. From all the buzz it must be a pretty good solution, especially with all this "web script" stuff on the Alfresco side. Plus Alfresco has some great features that I can take advantage of, and I know that it's CIFS support works because I've used it in the past.

FAIL. Liferay and Alfresco do not mix. Like, not at all. Well, not if you want to use Alfresco 2.1 Community or better. (BTW, the latest Liferay Alfresco Content Portlet 5.0.0.1 uses Alfresco 2.0) Ok ok, I'm being a little too negative. They do mix I'm sure if you write your own authentication filter to make SSO work. No problem!

You see, both Liferay and Alfresco love talking it up about standards support, like JSR-168, but it seems that neither of them pull it off well enough to, you know, INTEROPERATE.

The guy (guys?) at Cignex have a supposed solution using CAS between the two, but Alfresco doesn't jive with CAS as easily as Liferay, and I couldn't get this working reliably for SSO. I even bought this book called "Liferay Portal Enterprise Intranets" by Jonas Yuan in anticipation of the Alfresco integration section. What a complete bust and $60 down the drain. The book isn't necessarily bad, but the devil is in the details and the book is unfortunately devil-free.

Not suprisingly, another solution is to simply purchase Alfresco Enterprise, because it uses a different code base than community. In fact, Alfresco Enterprise 2.2+ will work with Liferay while Alfresco Community 2.9B will not. Open source? Sorta.

Frankly, I'm a little bit suprised to see the world of open source portals and document mangagement systems still in such a ridiculous state. Liferay has more bugs than a volkswagon dealer and both Liferay and Alfresco are stupidly difficult to configure in any interesting way, as all Java-based web applications seem to be. XML NIGHTMARE! Here's a tip: if it takes weeks just to understand how to configure your software, then your software isn't finished. Excessive meta configuration files are not a feature. Most of your users don't give a shit about Java Beans or any other beans for that matter.

Community? Not very good in either camp. Outdated documents, wikis (DIE WIKI DIE) and very poor forum support.

Not to just pick on Liferay and Alfresco, I've also tried out Exo and Icecore (built on Liferay) with limited success. I've looked at the JBoss portal a few times also but I just can't get over them basing their forum portlet on phpBB. I know, sounds petty, but phpBB....jesus...I don't want to think about this anymore. Bye.

Oh, and one more thing (damn I'm frustrated). HTTP Basic Auth is NOT a good solution for any feature of any software intended to be used in the Enterprise. (yes, including the Starship Enterprise) Pushing it over SSL only makes transport safer, and doesn't solve the root problem. (and we're just self-signing anyhow, even if we don't like to admit to it) And entering a password into a browser is NOT a good solution, ever. Receiving a password from a web browser is NOT a good solution. This is all the more true on the Starship Enterprise where people are either using potentially weak SSO or making all of their passwords match. The last thing you want are domain passwords in your damn browser cookies. I'm looking at you, REST authentication appologist!

Liferay + Alfresco on OpenVZ

This post is similar to my last entry, as it deals with Java apps and resource settings in OpenVZ. Today I tried to fire up Liferay 5 with the Alfresco 2.1 WAR on Tomcat 5.5, and kept getting the following OutOfMemoryError:

INFO: Starting Coyote HTTP/1.1 on http-8080
Jul 10, 2008 7:50:07 PM org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:295)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:433)
Caused by: java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:597)
at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.(ThreadPool.java:648)
at org.apache.tomcat.util.threads.ThreadPool.openThreads(ThreadPool.java:520)
at org.apache.tomcat.util.threads.ThreadPool.start(ThreadPool.java:149)
at org.apache.jk.common.ChannelSocket.init(ChannelSocket.java:436)
at org.apache.jk.server.JkMain.start(JkMain.java:328)
at org.apache.jk.server.JkCoyoteHandler.start(JkCoyoteHandler.java:154)
at org.apache.catalina.connector.Connector.start(Connector.java:1090)
at org.apache.catalina.core.StandardService.start(StandardService.java:457)
at org.apache.catalina.core.StandardServer.start(StandardServer.java:700)
at org.apache.catalina.startup.Catalina.start(Catalina.java:552)
... 6 more

This error turned out to be a bit deceptive and had me needlessly fiddling with Java and OpenVZ memory settings for a time. I should have known to check /proc/user_beancounters right away. If I had, I would have noticed that I was hitting the limit on the numproc parameter, which is set to a very low 240. I increased the limit to to 1000 (just to get an idea of how many processes I would need) using the following command:

vzctl set 101 --save --numproc 1000:1000

Turns out that Liferay with the Alfresco plugin on Tomcat 5.5 using MySQL for everything uses up 248 processes on my machine just to start.

Anyhow, the OutOfMemoryError was due to the process limit and had nothing to do with memory. Just thought I'd share in case anyone else runs into this and Googles before troubleshooting properly.

Installing JDK in OpenVZ VPS

I started playing with OpenVZ today because I'm getting terrible performance from QEMU+KQEMU and various Java applications.

I had some trouble installing the JDK inside my VPS, and the problem cost me about an hour so I figured I'd share. I'm running OpenVZ from a pretty bare Ubuntu Hardy server, and the VPS was created from ubuntu-8.04-i386-minimal.tar.gz which I downloaded from the OpenVZ site.

When I'd try to install the Sun JDK or OpenJDK via apt-get, I'd get the following error:

Setting up sun-java6-bin (6-06-0ubuntu1) ...
Aborted
dpkg: error processing sun-java6-bin (--configure):
subprocess post-installation script returned error exit status 134
dpkg: dependency problems prevent configuration of sun-java6-jre:
sun-java6-jre depends on sun-java6-bin (= 6-06-0ubuntu1) | ia32-sun-java6-bin (= 6-06-0ubuntu1); however:
Package sun-java6-bin is not configured yet.
Package ia32-sun-java6-bin is not installed.
dpkg: error processing sun-java6-jre (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of sun-java6-jdk:
sun-java6-jdk depends on sun-java6-bin (= 6-06-0ubuntu1); however:
Package sun-java6-bin is not configured yet.
dpkg: error processing sun-java6-jdk (--configure):
dependency problems - leaving unconfigured
Errors were encountered while processing:
sun-java6-bin
sun-java6-jre
sun-java6-jdk
E: Sub-process /usr/bin/dpkg returned an error code (1)

Turns out it's just a resource problem. If you're getting this error, check /proc/user_beancounters and see if you're getting any failures:

cat /proc/user_beancounters

101: kmemsize 625164 1720287 11055923 11377049 0
lockedpages 0 0 256 256 0
privvmpages 1173 129807 131072 139264 2

As you can see I was having problems with the limit on privvmpages. I doubled the default twice before it worked, resulting in a barrier of 262144 and a limit of 278528. You can change these values like so:

vzctl set 101 --privvmpages 262144:278528 --save

Sigh, Goodbye OpenSUSE

So I had to ditch OpenSUSE 10.3. It doesn't come as any surprise, really. I've never been able to break out of the Linux installation loop:

1) Install new distro
2) Work out various hardware kinks
3) Try to configure new distro to my liking
4) Try to use new distro for a few weeks
5) Hit a brick wall on some necessary feature; or distro simply breaks
6) Goto step 1

I had OpenSUSE 10.3 installed on both my Thinkpad R32 laptop, and on a standard desktop machine (Asus Mobo, Athlon XP, Geforce 6200 video). In both cases I ran into a dreaded KDE Freeze Bug. Unfortunately the KFB has like 80HP and does 20+2 (freeze) damage, which is a formidable enemy; even though I'm dumping all my skill points into Linux Tinkering and have several Potions of Diet Pepsi in my inventory.

Screw it. I might put more effort into battling the Freeze Bug, but OpenSUSE 10.3's package manager is absolutely atrocious. There have been so many times over the past month that I've thought about searching for software and decided that it wasn't worth it to wait for the package manager to start up. Even if I had that kind of time I'd still just end up fighting RPM dependency nightmares.

I realize that OpenSUSE 11 is just out and has a substantially better package management system. Unfortunately, they said the same thing about 10.3. If the package manager in 10.3 offered "dramatically improv[ed] speed," then I can't imagine how terrible it was previously. And even if package management is twice as fast in version 11, it would still be too damn slow.

So I installed Ubuntu 8.04 on both machines. So far so good, although I ran into the same old nVidia driver problem on the desktop and the laptop won't shut down properly with my PCMCIA wireless card installed. The nVidia driver issue was easy enough to fix (again), and when I figure out where to tell Ubuntu to eject the PCMCIA card on shutdown I'll update that blog post.

It's nice to be back on Ubuntu even though it uses the ever-ugly Gnome desktop and lacks a proper control panel. The Debian package management is really where it's at. I've decided not to try anything fancy with the laptop either - defaults all the way. We'll see how long this all lasts.

Oh, here's a cute one: when I successfully wake my Thinkpad from hibernation, the Hardy Heron informs me that the laptop was unable to hibernate. Thank goodness for the guy who put the "don't tell me this again" checkbox in that dialog.

Nagios with NSClient++ Character Flaws

Arg. It can be frustrating to pass special characters to check_nt arguments!

First, the dreaded ampersand (&):

Unfortunately, it appears as though the ampersand is the field delimiter used by NSClient++, so passing an ampersand to check_nt is absolutely not going to work. Take a look at the following code snippit from check_nt.c :

  249  case CHECK_PROCSTATE:
  250 
  251   if (value_list==NULL)
  252    output_message = strdup (_("No service/process specified"));
  253   else {
  254    preparelist(value_list);  /* replace , between services with & to send the request */
  255    asprintf(&send_buffer,"%s&%u&%s&%s", req_password,(vars_to_check==CHECK_SERVICESTATE)?5:6,
  256         (show_all==TRUE) ? "ShowAll" : "ShowFail",value_list);
  257    fetch_data (server_address, server_port, send_buffer);
  258    return_code=atoi(strtok(recv_buffer,"&"));
  259    temp_string=strtok(NULL,"&");
  260    output_message = strdup (temp_string);
  261   }
  262   break

  620 void preparelist(char *string) {
  621  /* Replace all , with & which is the delimiter for the request */
  622  int i;
  623 
  624  for (i = 0; (size_t)i < strlen(string); i++)
  625   if (string[i] == ',') {
  626    string[i]='&';
  627   }
  628 }
  

As you can see, the ampersand is hardwired into the request to the NSClient++ server, so any fix will require changes to both the check_nt plugin and NSClient++.

There is no workaround for this, except to avoid using the ampersand (escaping the ampersand with a backslash ( \ ) does not work). If, for example, you are trying to check on the status of the "Backup Exec Device & Media Service", use the service name instead of the display name -- NSClient++ can use either. In this case, the service name is "BackupExecDeviceMediaService", which you can find in the service properties.

P.S. - if you're unfortunate enough to be using Backup Exec, I feel for you.

Next, the dollar sign ($):

The dollar sign is a goofy one too, and can't be escaped with the backslash character ( \ ). Instead, you have to double it and put quotes around it (like so: "$$"). Neat, eh?

An example: let's say that you're trying to monitor the service MSSQL$BKUPEXEC. Unfortunately, this is both the display name, and the service name, so the last trick we used won't work. No worries, though, thanks to our friend the double-dollar-sign-enclosed-in-quotes. Your check_command will look like this:

check_command check_nt!SERVICESTATE!-l "MSSQL"$$"BKUPEXEC"

So awesome! Yay for annoying things!

Note: you might think you're clever and use single quotes instead of double around the entire service name. Unfortunately, that does not work reliably. It does seem to work, however, if you're only checking on one service name in the command. Anyhow, don't bother.

Next up, the backslash ( \ ):

This one is pretty easy, you just double it up ( like so: \\ ). Thus checking on a performance counter will look something like this:

check_command check_nt!COUNTER!-l "\\Network Interface(Intel[R] 82546EB Based Dual Port Network Connection - Packet Scheduler Miniport)\\Bytes Total/sec"

Phew, that counter name is a mouthfull, which is actually why I chose it. Don't try to manually type in your performance counters; copy and paste them. From a terminal to the Windows machine you're monitoring, open up Performance Monitor. Add the counter you're looking for to the graph, select the counter from the legend at the bottom of the window, and then click on the Copy Properties button (it's one of the buttons at the top of the graph). Now open up notepad or your favorite text editor and paste the performance counter data into it. Somewhere in there you should see a .path attribute that contains the entire counter reference which you can copy and paste into the specific Nagios configuration file we're working with (remove the server name and double all of the back slashes). Thankfully we can copy and paste from a terminal in Windows to local windows, if we're running Windows.

Note: I believe that much of the confusion over passing arguments to the check_nt command in Nagios has to do with this double back slash which looks like we're escaping the back slash. We're not...well, not really. Don't expect to simply use regular Bash shell notation in your arguments. Single quotes don't necessarily behave the way you'd like. Escaping doesn't work the way you might expect it to. Just don't bother trying to out-think the system, follow its conventions, make no assumptions, and you'll be fine.

OpenSuse 10.3 + Nvidia Driver for Geforce 6200 = CRAP

Sigh. So I followed the instructions you gave me for installing the nVidia driver for my 6200 with YaST. The installation process was very simple, but the after installation process not so much.

I'm curious as to why exactly you'd want to set my monitor refresh rate to 71.0KHz : 88.4Hz? Seems a little odd. Thankfully my monitor can still display this rate, but I get a big "OUT OF RANGE" box in the center of my screen. Nice.

Ok, so the obvious place to start is the "Graphics Card and Monitor" utility from the YaST2 Control Center. In other words, SaX2: X11 Configuration. (BTW, your multi-case meaningless acronyms are sweet. Sweet indeed.) Working around the giant "OUT OF RANGE" message, I'm able to limit the range of my monitor and I do so. No go. Neither changing the monitor nor reducing the frequencies has any effect. The card insists on driving the monitor at 71 : 88.4.

I check the xorg.conf file and verify that the correct frequency ranges are there. They are. I change a few things and break the config. Ok, restore the old file.

Aha! Wipe that evil grin off your smug face, because you haven't beaten me on this April morning! I found a workaround:

1. Get into the YaST Control Center (e.g. Administrator Settings), and choose the Hardware tab from the left.
   
   
2. Click Graphics Card and Monitor and click the Options button for the video card.
   
   
3. There should be a VertRefresh option. Set it to 60 (or some other safe value for your monitor, but 60 should almost always be safe).

Voila. Not the best, but at least it works.

If you can't get into X at all, then manually edit your xorg.conf file:

1. Login to your shell as root, or `su -` to become root.
   
   
2. Enter `emacs /etc/X11/xorg.conf` (Unless you have a simpler editor installed, but my install only had Emacs and vi.)
   
   
3. Hit enter once if you get the Emacs "welcome / help" screen. You should now see the contents of the xorg.conf file. Scroll down to 'Section "Device"' and add the following line before 'EndSection':
   
   Option "VertRefresh" "60"
   
   
4. CTRL+X then CTRL+C to quit Emacs. Hit 'y' on your way out to save.
   
   
5. Restart (or test by running `startx` from your shell).
   
   
6. I'm not sure if SaX will freak out on you for manually editing the file, so follow the first procedure above to make sure it sticks.

Happy Wasting-Your-Time,

Year of the Linux Desktop

xx00