Checklist for deploying open sourced GroupWare
Server requirements
When I'm planning a deployment, my first step is to verify that I have a server that can handle the new software. Because of the open source nature of eGroupWare, you have a lot of flexibility in this area. There are no firm hardware requirements, and even the software requirements are flexible. The only real software requirement is that the server must have a version of PHP that’s greater than 4.1.
Aside from the PHP requirement, eGroupWare will run on Windows, Mac, and Linux. Whatever server you run the GroupWare on, it must also have a Web server installed, and the server must have a database program that eGroupWare can use. Obviously, the Web server that you'll use will vary depending on the operating system, but some of the supported Web servers include IIS, Apache 1.3x and 2.x, and Roxen. You can use a variety of SQL-based databases as well, including MySQL, PostgreSQL, and MSSQL.
Generally speaking, if your server meets these requirements and still has plenty of free system resources, then eGroupWare should run. The .ZIP file for eGroupWare is about 13.7 MB and can be downloaded along with the other versions from SourceForge.net.
Feature planning
The next stage in the planning process is to determine which features you're going to use. This step varies greatly depending on the particular GroupWare product you'll deploy. For example, Microsoft Exchange doesn’t really give you the option of leaving out many features aside from the conferencing server or the chat server. On the other hand, eGroupWare is designed to be modular, and you can choose which modules you want to install. Currently, the available modules include e-mail, an address book, calendaring, a notepad for recording notes, to-do lists, content management, a discussion forum, and a set of bookmarks.
As a consultant, it's your job to figure out which available modules your client's users are really going to need. It might be tempting to give users all of the modules, but you must remember that your client's IT department is going to have to support each module.
Capacity planning
Before deploying any GroupWare package, you need to find out if there's any hard-coded user limit or if there is a practical limit to the number of users that the applications can support. Most modern GroupWare applications don’t have a physical user limit, and the practical limit is often way beyond what a small to medium-sized company would ever come close to reaching. Nonetheless, it’s important to check for these limitations just in case.
You also need to be aware of the user limit imposed by your server hardware. There's no direct correlation between hardware and a user limit that would, for example, restrict you to 100 mailboxes because you only have a Pentium II server. Instead, the limit is based in terms of the amount of server resources consumed by each user.
Each user account will have a certain minimal amount of disk space and memory space that the server will need to allocate. This amount of space varies widely among GroupWare packages and is best calculated through benchmarking. For example, if you were using a Windows server, you might install the GroupWare application and then take benchmark readings for the amount of available RAM and hard disk space. Next, you could set up about 10 accounts and take the benchmark readings again to find out how much the values have changed. Now take the total amount of space that the values have changed and divide it by the total number of accounts created to get a rough idea of how much memory and disk space are consumed by each user.
Keep in mind that the values you calculate are only the minimum amount of space consumed by an empty account. If you determine that each account consumes 10 KB of disk space, it would be unrealistic to assume that 100 users would eat up only a megabyte of disk space as each account consumes more and more space. As users make use of their GroupWare accounts, they will begin to use disk space to store things such as e-mail messages, documents, and calendar entries. Further complicating the situation is the fact that no two people use exactly the same amount of disk space.
Lock down your server
Most of the time, locking down a server is something people do after a new server is up and running. However, from the time your server first goes online, it's vulnerable until it has been locked down. Therefore, I strongly recommend including the lockdown as a part of the planning process. Having a blueprint for the lockdown allows you to complete the lockdown in as little time as possible and ensures you don’t forget anything.
It would be possible to write an entire book on locking down a GroupWare Server, especially one that runs on so many different platforms. However, you basically need to know what the requirements are for your GroupWare server and lock down everything else. For example, eGroupWare requires that ports 80 (HTTP), 443 (HTTPS), and 22 (SSH) be open. Therefore, you must leave these ports open, but focus on closing all other unnecessary ports.
The ports listed above are just to make the software run. If you plan on using your eGroupWare Server for e-mail, you'll also have to open ports 25 (SMTP), 465 (SMTPS), 110 (POP3), 993 (IMAPS), 143 (IMAP), and 995 (POP3 over SSL).
You must also make efforts to secure the underlying operating system and Web server. If you were running eGroupWare on a Microsoft box, for example, you might use the Microsoft Baseline Security Analyzer to routinely scan your server for missing security patches. This utility will scan only the operating system and the Web server. You also have to keep the GroupWare application up to date in order to remain secure. One way of finding out about critical security updates for eGroupWare is to subscribe to its mailing list.
Clients
It’s easy to focus all of your attention on the GroupWare server and forget all about the clients. Clients accessing an eGroupWare server usually access the server through a Web browser, so the clients aren’t really an issue. However, many other GroupWare applications do require a client component to be installed on each workstation. Therefore, you need to consider how you'll deploy the component and whether each workstation has sufficient hardware and software resources to accommodate the software.
TechRepublic originally published this article on 27 April 2004.