Alfresco - "Commercial Open Source"

So I don't want to sound like too much of a hater, although the purpose of this blog is to give me a place to vent, but I'm very unimpressed with Alfresco's "open source" business model.

While the Church of the Free Software Foundation would have us believe that source code is a basic human right, other companies like Alfresco have a more restrictive view when it comes to the licensing of their code. And really I'm ok with that. Just because something is trivial to duplicate and distribute does not mean that it has no monetary value. Work is work.

What I do have a problem with are various voices from the Alfresco blogs ripping on closed source vendors and patting themselves on the back as if they were on the same level as "real" open source companies like, for instance, the Apache Software Foundation. There's a big difference between commercial open source companies like Alfresco and less restrictive entities like Apache.

Alfresco maintains two open source branches of their software. One for the so-called community, and one for the Starship Enterprise (i.e. paying customers). What's wrong with that?

Well, for starters I've come across bugs in Community version of Alfresco that I know are fixed in Enterprise. Even though the Community or "Labs" version of Alfresco continues to plow along and is nearly at version 3.0, show-stopper bug fixes from Enterprise 2.1+ are still not merged into Community. Ok, it's open source, so I can fix them, right?

Let me ask you this: why should I? If I were to fix the JSR-168 authentication flaw that's holding me back from actually using Alfresco, then I would be duplicating work that has already been done. Not only that, but the severity of the flaw would almost certainly mean that my fix would be of lesser quality than the fix that already exists because I am not an Alfresco developer. Even if I did fix it, and fix it well, there's nobody to give my fix back to because Alfresco doesn't take a lot of community contributions, and (have I mentioned this?), it's already fixed.

So let's talk about the Alfresco Community for a moment. Where is it? I'm seeing an outdated Wiki and some very inactive forums where moderators spend more time moving threads around to "appropriate" forums than answering questions. The use of the word Community here is a bit of a stretch, and has no greater value than I'd expect to get from a closed-source product. The Alfresco Community is less of an "open source community" and more like a gathering of frustrated but oddly grateful beta testers.

In addition to these not-so-opensourcey qualities of Alfresco is the biggest slap in the face of all: the cute little "nag screen" at the bottom of every page rendered by the Community version. You know, the one that reads: "This software might not be any good because the company running it hasn't paid any money." While much of the look and feel of Alfresco can be easily changed, this little gem is actually buried in the Java source. On purpose. To irritate you into paying. Cute.

"Dude, why don't you just shut up and pay for the software?"

I'm not convinced that it's worth paying for yet. If Alfresco has a similar pricing structure to other open source commercial/support companies, then it's probably more expensive than its closed source competitors. Whoa, did I say that? Yeah. Despite what you might have been led to believe, products like Sharepoint from terrible companies like Microsoft are actually dirt cheap for small to medium sized companies. Sure, you don't get free support with the license fees, but at least I'm not forced to pay extra for something I haven't to this day had to use.

So why should I fork over the cash if the "demo" version I'm using doesn't even correctly implement a fairly straight-foward feature? A feature that is actually specified in a formal standard no less!

"Yeah, but it's worth the price because it's open source, which is all open and not all closed 'n' stuff."

I love open source, but in this case I'm not really sure what the benefit is. I don't use open source software because I'm afraid that some day the vendor will go out of business and I'll be able to continue modifying the software myself. I'm certainly not going to just assume that the "community" is going to pick it up and save the day. I do like open source because I can modify the behavior of the software and fix bugs if need be, but this is really something that I rarely want to do. I'm interested in the software because I want to use the software. And I certainly don't want to be fixing bugs in software that I'm paying support fees for.

If an open source application isn't fully open source then its appeal is greatly diminished. The community around it is diminished. It's really only slightly more interesting than closed source alternatives.

"Ok, so you're still saying that Alfresco is more intersting than its closed source competitors. What the hell is your problem?"

Well, frankly I'm just sick and tired of the Alfresco bloggers ripping on closed source companies. Alfresco is not a community driven open source project, and I certainly don't feel that they have any business taking the moral highground and ripping on their closed source competition. Suck it up, Alfresco, and open the the real source. Microsoft might have its head up its ass when it comes to understanding the benefits of open source, but you've only got one eye peeking out.

"Does it make you feel better to make up these insulting questions that I, the reader, am supposedly dying to ask you?"

Why, yes. Yes it does. Thanks.

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.