Applications and settings

May 17th, 2004 Comments Off on Applications and settings

One of the things that always bothers me in applications — both in those that I use and in those that I develop — is where their settings are stored. If done improperly, this can become a problem for users and developers. For users, because its becomes harder to backup those configurations, since they will need to account for more paths when creating copies of the information they need secured. For developers, because it can create development issues. Backups are by far the most boring things users will ever do with regards to the systems they user. Because of that, applications should help them. What happens instead is that applications make backups more difficult, storing data in various places without no connection whatsoever. This problems happens in both operating systems I use the most: Linux and Windows. It probably happens in other systems as well, although I read somewhere that Mac OS deals with configurations in a much more sane way.

Under Linux, there are two main places where an application can store its settings: in the /etc and /home directories. The former is used by system applications, since its permissions are more restrictive, accessible only to administrative users and applications that run as system users. The latter is used by the users themselves, as it name says, storing the data they produce and also the settings of the applications they may have installed. For both directories, a backup is merely a matter of copying the whole directory structure.

The problems begins, then, when applications decide to store configurations outside those directories, because they don’t have access to the more restrictive directory and, at the same time, need to store their settings outside the /home directory since they are intended for general use. It’s the case, for example, of Web applications. Those programs are usually installed in shared places, where users can do the needed modifications to their configurations without compromising the whole system.

Because they can’t access the system directories, however, those applications end up storing configurations in their own installation directories. Worse, some of them actually mix data, code and configuration, forcing users to filter what needs to be saved in a backup, creating new execution paths that add to already complicated backups scripts.

Under Windows, every time I ever installed a system from the scratch, I lost configuration data from one application or other. Although Windows has a specific path where applications can save settings relating to the user, some applications don’t use this path, either because their developers didn’t know how or didn’t care to use it or because they make only a partial use of it. Macromedia Dreamweaver, for example, store most of its configuration data in the place it is installed. I always forget to backup changes to its configuration when I reinstall my system. Also, some applications — like Windows itself — stores binary data that contains information that can’t be separated but belongs to the specific computer its installed, making it simply impossible to restored a backup if the system fails catastrophically. The registry comes to mind with regards to the problem.

Linux is a better player here, since most of its configuration files are stored in textual formats, which can be quickly changed and adapted as the need arises. But even under Linux it’s possible to forget to save some of those configurations and lose time when the system needs to be reinstalled or moved. MovableType, MoinMoin, and SquirrelMail are examples of Web applications that keep their configuration files mixed with their code, forcing their users to remember those directories and files when they backup their systems. Worse, some of them actually have configuration data mixed with their code, forcing users to deal with that not only the applications are reinstalled but when they are upgraded as well.

For developers, saving configuration data in the wrong place can be a problem as well. Web applications, whose code generally runs unaltered in the servers, requiring no compilation, when kept in version control system tend to have their complete structure mirrored there, including configuration files. If developers are not careful, creating filters to avoid including those local configuration files in the version control system, those files will be changed at every check in. Check outs will them overwrite the configuration files in the systems of different developers, forcing them to correct those files and lose time their could be using in more profitable activities.

As a user, it’s not my obligation to take care of those aspects of the applications I use. It always bugs me when I’m forced to find the configurations of the dozens of applications I need just to discover later that I forgot some obscure path when the backups are restored. As a system administrator, things like that only increase the work I must do.

As a developer, however, it’s my job to guarantee that both users and system administrators will have an easier time when saving the configuration files of the applications I developed. As a developer, it’s my job to pay attention to where the applications I developed are saving their data.

Under Windows, system applications will have a hard time finding out where they should store their settings since that operating system has no standard place to store them save the registry, which is a binary file, which can be easily corrupted if manipulated in the wrong way. Under Linux, the /etc directory is the right place to store settings, preferably in separate directories.

User application should always store they settings in the home directories of their users. Under Windows, that is the Documents and Settings directories (in more recent versions of the system). Under Linux, that is the /home directory, preferably in a hidden directory under it. Luckily, most Linux applications already do that.

Web applications, on the other hand, must use configurable configuration systems. An ideal way to do that is to allow users to choose whatever place is more convenient to them, using environment variables, symbolic links or stub files that include the real configuration file, located somewhere else in the system. In any case, an application should be ready to read its configuration data from any place.

Recently, installing Web applications in this server, I decide to create a standard directory to store all relevant hosting configurations for the sites I have under it. In this directory, there are sub-directories for the users, applications, and domains I host. As I use Linux, I was able to move the configuration files of the applications I installed to that standard directory, then creating links pointing to them in the places that the applications expect them to be.

Of course, it’s not always possible to do something like, whether using Linux or not. Some users work under so restrictive systems that they can do nothing about it. But it’s always good to offer options, even if some users will not benefit from them.

To solve this problem is version control systems, I’m using a new strategy as well. In the systems I’m developing now, the CVS only hosts a sample configuration file, There’s another stub configuration file, that the applications uses, whose sole function is to point to the real configuration data. Depending on the language the system was developed in, I’m using symbolic links or include files. In any case, however, the configuration file remains outside the application directory, which also increases security, if the system is a Web application. Systems that use plug-ins expose a configuration API, avoiding the creation of even more configuration paths.

If you are a developer, it always pays to think about those issues before you start coding. You will have less problems and your users will also be thankful.

Comments are closed.

What's this?

You are currently reading Applications and settings at Reflective Surface.

meta