It is a very popular (and affordable) email management solution for help desks & sales teams. It is a bit complex, so you’ll want to take a moment to review the features and consider ways to synthesize it for your business. It appears that everything is managed through email and you have certain email addresses that customers and prospects use (or that it recognizes).

There is workflow, tagging, team resolution, and an integrated knowledge base. Instead of typing an article into the knowledge base, simply answering a client’s problem would give you the ability to ‘Tag’ and file that email into the Knowledge base.

If you’re looking for a Helpdesk+KnowledgeBase combo, this could be a real winner since it integrates tightly with email.

So, here’s our setup:

1) Email: This actually works really well. We use IMAP and the Blackberry (through Sprint) has a nice service that allows us to connect to our IMAP server. The Blackberry checks the IMAP Server every 15 minutes and alerts me to the new messages. I set my blackberry up to be the master and it reconciles every 15 minutes. WARNING: This means that my blackberry is actually deleting messages from my IMAP (and to be literal, it is expunging them - so they aren’t even in my trash folder). I chose this option so I don’t have hundreds of emails waiting on me when I get back to the office. Remember, I can’t sync (but that comes later).

2) Local PIM (personal information management): This includes contacts, calendar, tasks, and notes. Simply put, forget about using them. We have two issues that we’re up against. First, we use Thunderbird - so we don’t have a good option for calendar, tasks, and notes. I hope their progress with Sunbird and Lightning continues! The calendar isn’t as hopeless as Tasks/Notes since the Blackberry can sync with iCal formatted calendars. If you use an iCal compatible Calendar, then you can have your events.

As for locally stored contacts, I couldn’t find an easy solution to sync to the Blackberry. The best idea I had was to use Plaxo’s Thunderbird client and access via the web (premium service)

3) Groupware Server: If you are using an OpenSource Groupware product, there are more options available for syncing the blackberry. For basic calendars & tasks, the Blackberry will sync with any iCal formatted calendar. To do this, you will need an application like PocketMac.

For a more robust solution, the best option is to setup a Groupware solution that is compatible with a SyncML server like funambol. There are many solutions available (and even some services like Zyb). We use eGroupware and it integrates with SyncML. For the Blackberry, SyncBerry [$29.95] provides Over-The-Air (OTA) synchronization with Contacts, Calendar, and Tasks (InfoLog). Once the SyncML server is setup, there are two options for syncing Thunderbird. One is an community supported Mozilla extension of funambol and the other is a ‘beta’ application called TSync. This ensures that the Blackberry & Thunderbird are both sync’d to the corporate groupware package/service.

Note: I’m writing this article as I research these solutions. We haven’t implemented the SyncML server, so I can’t vouch for the success of this piece.

4) Internet Access (Phone): This is my favorite part! First, the 8703e has a beautiful screen and it is very easy to access web pages. For our company, we disabled images & their placeholders to increase load speeds. Since we haven’t implemented SyncML, everyone simply accesses eGroupware via the phone’s web browser. It isn’t pretty, but it’s functional (especially if you make the calendar display in list view).

** BONUS**
This phone actually acts as a wireless Modem on the Sprint Network!!! All of the research I’ve conducted has been through the phone - connected via a USB cable. The 8703e on Sprint’s EDVO network is getting an average of 340kbps - easily enough for basic web usage.

All in all, I think the Blackberry will be a fantastic solution once we have eGroupware+SyncML+SyncBerry+Thunderbird/funambol. In fact, CentreSource will begin providing Nashville clients with installations of the OpenSource combination upon successful implementation.

Until then, it is a great tool for checking IMAP email and accessing the web (via the phone and as a modem).

So, I went on a quest to see what I could find. The systems I chose have the following features: Easy to use, Flexible to store any file, Versioning, Ability to handle large Volumes of Data, Customizable Meta Data, Document Text Search (including PDF), and Provide a Web Interface for Universal Access. Here are the ONLY two candidates I found:

KnowledgeTree: http://www.ktdms.com/products/ktdmsfeatures

Comments: Mature and well-supported open source solution. Supports grouping of data, meta-tags, versioning, and has some nice time saving features for dealing with large volumes of data. I particularly like the ability to have pre-defined data requests per document type - as well as the ‘discussion’. It doesn’t have anything specific for media management - but the system’s flexibility keeps that from being an issue. Per your requirements, it also has some basic collaboration through checkin/out and ‘work flow management’.

Support: Commercial Support available, as well as commercial tools for better integration into a Windows/Client environment.

jLibrary: http://jlibrary.sourceforge.net/4/index.html

Comments: Looks to be a very promising solution. jLibrary combines a rich feature set you’d expect in a document management system with an easy to use interface. It also has a nice feature of providing access via a client, as well as the web. jLibrary allows for large volume management, meta-data for groups, and even a relationship manager(separate from meta and categories). Currently, the product is in beta - so it may be good to wait for the first production release.

Support: Commercial support is available

* Add support for tunneling arbitrary network packets over a
connection between an OpenSSH client and server via tun(4) virtual
network interfaces. This allows the use of OpenSSH (4.3+) to create
a true VPN between the client and server providing real network
connectivity at layer 2 or 3. This feature is experimental and is
currently supported on OpenBSD, Linux, NetBSD (IPv4 only) and
FreeBSD.

Enter puttycyg — it allows you to use putty as a raw terminal emulator (i.e. without telnet or ssh) in running your cygwin shell. From puttycyg’s README:

RATIONALE

The Windows Console is an inadequate terminal emulator. It is impossible
to resize horizontally without pulling up a dialog box. It is impossible
to send an ASCII NUL. Basic keyboard options do not exist such as
configuring the ASCII character sent by the Backspace key.

Some solutions for these problems already exist. One can use xterm or rxvt
instead of the Console. One can also telnet or ssh to the local machine
over the loopback interface using almost any terminal emulator including
PuTTY.

However, one should be able to use Cygwin with a decent terminal emulator
without having to install Cygwin/X or to install telnetd or sshd.

Pretty cool.

1) Convoluted install process.

GForge is probably the best example of this I’ve ever encountered. In their case it’s understandable, since gforge is a fork of the sourceforge code, which is obviously a loose amalgamation of stuff to begin with. But at the end of the day, there are no excuses for its installation process. For example, here is a snippet from the “WEB SETUP - MANUAL INSTALLATION” section in the INSTALL file. (You’d think “MANUAL” installation would be as opposed to an automatic one somewhere, but not that I could find):

tar -xjf gforge-4.0.2.tar.bz2
mv gforge-4.0.2 /var/www/
cd /var/www/
ln -s gforge-4.0.2 gforge
mkdir mailman
mkdir uploads
mkdir jpgraph
mkdir scmtarballs
mkdir scmsnapshots
mkdir localizationcache

#project vhost space
mkdir homedirs
mkdir /home/groups
ln -s /home/groups homedirs/groups

etc...

It goes on like this for nearly 2-3 pages.

So, what are the problems with this? First, of course, is that these instructions are meaningless for anyone that doesn’t have shell access. Second is that they are meaningless to anyone who isn’t familiar with the guts of a UNIX shell in general. But these are forgiveable. The gravest sin is that these instructions are completely meaningless for a server that doesn’t match their configuration. Creating random directories in /var/www? Creating random directories in /home/ to support their app? I don’t think so. Debian follows the FHS as closely as possible for a reason, and I am not about to manually unpack all this crap on my server without some way to keep track of it, much less in a slew of non-standard locations.

And these locations differ for any other distribution as well. It’s not impossible to translate what the instructions mean to say, but regardless, it’s a lot of work. I estimated by the full length of those instructions, it would have probably taken me 2 hours to install, and that’s if I didn’t try to translate their directory/setup choices into something more standard, much less try to make a package out of it.

The icing on the cake here is that gforge requires Register_globals to be “on” for PHP — which is akin to opening the door to every PHP exploit on the planet.

Conversely, PHP Live! does what I would expect, and what every good web app should do. It wasn’t picky about where it was installed, and the instructions were clear and concise:

1. gunzip, untar or unzip the application somewhere on the server that
you can access it with an "http:" address.
2. (UNIX Only) Change the permissions of the "web/" directory to be
write able by the browser.  The "web/" directory is located in the root
unpacked directory of PHP Live!.
3. Create an empty MySQL database to be used by PHP Live!.  Remember to
restart your MySQL server if you added a new user.  (Don't create any
tables, just create an empty database.)
4. Visit http://www.yourservername.com/phplive/
5. The setup will walk you through an automated, painless Q&A session.
Finish the questions till you get to the "Success" screen.

And that’s it. It handles smoothly all the stuff it should — creating the tables according to its own schema, populating data. It all Just Works, and well within the confines of the directory I set up for the virtualhost in /var/www/support.centresource.com/

2) Terrible upgrade processes.

SugarCRM wins the award here. The first problem is that SugarCRM requires you to upgrade sequentially through every single revision released after the version you are using. I pity anyone that lets their instance of SugarCRM get as out of date as our installation is, since it takes no less than seven upgrades to get current.

To make matters worse is the fact that they changed the upgrade method between many versions. Some versions have a “wizard”, some require manual steps. And none of the wizards, in my experience, worked much at all — meaning it was clear that I’d have to take manual steps to fix whatever it was the upgrade “wizard” failed to do. To this day I still haven’t upgraded SugarCRM because I simply don’t have the time to do everything necessary.

3) “Smart” packaging

Perhaps in response to the ease of installation of things in the world of Windows, a lot of LAMP developers have taken to publishing their code in an “all-in-one” type package that includes everything necessary to run their application’s functionality. VTiger is a great example of this. VTiger is a fork of the SugarCRM code that they have improved and repackaged, along with everything you need to run it: Apache, Postfix, etc. The problem is they have no provision for people that, you know, are already running this software. It’s nice that they are trying to be accomodating to people that are buying a server, installing an OS and then letting Vtiger do its thing, but here in the real world, applications are usually installed on boxes already in use for other things.

It’s not impossible of course to extrapolate their PHP code itself from the “smart” installation package as a whole, but it essentially means doing everything by hand, and fixing everything in their code that incorrectly assumes things about my config and the software I am using.

Not all LAMP packages suffer from the problems highlighted above, naturally, but it’s disturbingly common. It’s as if they package and release their code without considering that people are actually going to be installing it on servers that aren’t identical to their own. (Shocker, I know.)

• PPTP support in the kernel
• FUSE (userspace filesystem) support has been merged
• ipw2100 and ipw2200 (the wireless card my laptop uses) have been merged in as well

Check out the human-readable Changelog.

First up is interface trunking, which will allow the combination of two or more ports into one virtual interface. This allows load-balancing (simple round-robin for now) and failover:

trunk(4) provides several possible benefits. The first one is a slightly improved performance, because the traffic could be distributed over several physical network interfaces. You could get more than 100Mbit/s with a fast Ethernet trunk, even more than 1G/s with a gigabit trunk. The most interesting feature of trunk is failover on layer 2. The trunk will continue to work if you remove the network cable of an attached port, as long as there’re other running ports attached to the trunk. The interface link states are used to detect inactive ports and to skip them in the round-robin scheduling.

This can also be used in conjunction with the existing interface grouping in interesting ways:

Interfaces can be in more than one group, and of course a group can contain more than one interface. Now, pf can filter based on the group names. You could, for example, have your external interface on a typical firewall join a group ext, and have pf filter on the group ext instead of the interface. That way, your ruleset is hardware independent–the group assignment goes to the hostname.if files, which are machine dependent anyway. If you do the same for your internal interface it makes even more sense; if you add a second internal one, say, a wireless card, you just make it join the group–no need to modify the ruleset.

Perhaps coolest of all comes some good news on the IPSEC front. Currently, OpenBSD’s IPSEC support relies on the extremely clunky combination of ipsecadm for manual keying and isakmpd.conf for automatic keying, both of which are relatively obscure and daunting. OpenBSD 3.8 will introduce ipsecctl, which will obselete both isakmpd.conf and ipsecadm:

We decided to use a language derived from pf.conf(5) (see ipsec.conf(5)): Rules define which packets will go through ipsec(4), which security services will be applied, and how keys are established. Care is taken that only a minimal set of parameters needs to be specified, and reasonable default values are used otherwise.

For example:

esp from 192.168.3.14 to 192.168.3.12 spi 0xdeadbeef:0xbeefdead \
authkey file “auth14:auth12″ enckey file “enc14:enc12″

This rule creates an IPsec tunnel between the hosts 192.168.3.4 and 192.168.3.12 using ESP with static keys read from some files. No authentication and encryption algorithms are specified; thus ipsecctl(8) will use HMAC-SHA2-256 and AES countermode as strong default algorithms.

For automatic keying, ipsecctl(8) generates proper configurations and feeds them to isakmpd(8) using its FIFO interface. Thus it is not necessary anymore to use isakmpd.conf(5). For example, to set up a VPN between the networks 10.1.1.0/24 and 10.1.2.0/24, one can use this rule:

ike esp from 10.1.1.0/24 to 10.1.2.0/24 peer 192.168.3.2

Again, ipsecctl(8) will choose good default values for authentication and encryption (3DES-SHA1 for phase 1 and AES-128 and HMAC-SHA2-256 for phase 2), SA lifetimes, and so on.

There’s more where that came from, including improved RAID support and other stuff. Check out the article for more.

They all had the exact same problem, he said, “When I boot them up, they get as far as LI….” To even the most casual Linux user, this is a sadly common problem. I realized that none of these servers had been rebooted since we performed a Woody to Sarge upgrade, and something clearly hosed LILO.

This whole experience raised a number of questions for me:

1. I fixed the LILO issue by just booting up the Debian install CD, breaking into a shell, and doing the “mount/chroot/lilo” dance, and then installed GRUB. But I wouldn’t expect your average user to do this. I know that Debian has (or had, at least) some sort of “rescue” functionality, but I can’t find any documentation for it on the web anywhere. Anyone know?
2. I don’t know if this is a bug, or what, but just about every person I have talked to about their Woody to Sarge upgrade has managed to hose their boot sector. I assume this is because somewhere in the installation process, lilo gets upgraded (naturally) but perhaps it’s optional to re-run “lilo”. In fact, I can imagine people specifically saying not to run lilo out of fear of hosing their boot sector. Well, it’s burned a lot of people and it looks like it burned us here. Is this is an acknowledged problem?