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