webapp-config is a powerful tool that allows you to install, upgrade, and remove web-based applications in a virtual-hosting environment.
webapp-config is aimed at providing the package management functionality that you need if you are running multiple web sites off of the same computer (virtual hosting).
The answer is a two-stage install. The traditional package manager installs a master copy, into /usr/share/webapps/. This master copy isn't fit to run - but it is ready to then be used by webapp-config to install the package multiple times in multiple places.
webapp-config allows you to install multiple copies of the same package on the same computer at the same time. You choose which directory to install each separate copy into.
We call these multiple installations "virtual copies".
You can also have different versions of the same package installed at the same time. This allows you to gradually roll out a new version of a package across your sites; you are not forced to upgrade every single website at once.
webapp-config minimises the number of duplicated files to the absolute minimum possible, to keep disk space usage low. The majority of files are hard linked to the master copy; only configuration files, and any files that the package needs to write to, are copied into the virtual copy.
If you are used to installing web-based applications by hand, you'll appreciate that it can be a pain to get every file owned by the correct user, and with the correct permissions. Some files need to be owned by the user that the webserver runs as. Others need to be owned by specific shell accounts, so that those users can login and edit the configuration files. If your Linux distribution offers you a choice of web servers - each running under a different user - even the installers can struggle to get it right.
With webapp-config, you tell the installer which web server you are going to be using, and which shell account needs to be able to edit the configuration files. webapp-config then installs your files with the correct ownership and permissions.
webapp-config automatically ensures that your configuration files are never overwritten during an upgrade - even if you have not edited the files at all. Additionally, webapp-config will never overwrite any file that it did not install, or that has been changed since it was installed by webapp-config. webapp-config uses md5 checksums to determine whether a file has been changed or not. In the case of symbolic links, webapp-config will not replace a symlink that points to a different file.
When an upgrade does attempt to overwrite a protected file, webapp-config creates a ._cfg file with the new file inside. You can use etc-upgrade to complete the install, just as you would with the regular emerge.
A virtual copy is built mostly by creating hard links to files under /usr/share/webapps. If a hard link cannot be created, the file is copied from /usr/share/webapps instead.
Hard links can only be created to files on the same filesystem. If you keep /usr/share/webapps and /var/www on different filesystems, webapp-config cannot use hard links, and will be forced to copy the files instead.
There are two ways to get around the hard link problem.
The easiest way is to make /usr/share/webapps a symlink to a directory under /var/www. For most people, this will ensure that everything is on the same filesystem.
However, if you keep the websites you host on separate filesystems (like I do), then webapp-config is never going to be able to hard-link files for you.
You can choose to use the --soft command-line switch instead. This switch tells webapp-config to create symbolic links instead of hard links. Symbolic links work across filesystems.
The problem with using symbolic links is that some packages do not work when the virtual copy is made from symbolic links. Many users - and system administrators alas - have also complained that they find directories full of symbolic links confusing. For these reasons, symbolic links are not used by default in webapp-config any more.
Talk about the --virtual-dirs and --virtual-files switches
By default, the master copy, contains the metadata that decides which files get linked into a virtual copy, and which files do not. Files are either owned by the web server (server-owned), are configuration files (config-owned), or are linked in (virtual). Directories can be server-owned, config-owned, or virtual, but most of the time they need to be just plain directories (default-owned) created inside the installation directory (set with the -d switch). webapp-config provides a number of switches which allows you to override the master copy's metadata - if you ever find that you need to.
The --virtual-dirs and --virtual-files switches allow you to decide what webapp-config will do if (respectively) a directory or a file is marked as being virtual. You can tell webapp-config to make the directory or file any of the other choices - server-owned, config-owned, or default-owned - instead.
Additionally, the --force-virtual can be used to override the master copy's metadata, and force every directory and file to be virtual. webapp-config processes --force-virtual before --virtual-dirs and --virtual-files, so you can combine the two to create some interesting effects.
This virtual file voodoo is most useful for websites where you do not want users to be able to edit anything other than the configuration files. Using --force-virtuals --virtual dirs virtual --virtual-files virtual ensures that all files and directories are just links; there are no local copies for the user to edit.
Note: you cannot use --force-virtual to override config-owned files. webapp-config always installs these files as config-owned, because each package needs a local copy of its configuration files in order to work. If you want to restrict who can edit these configuration files, use the -u and -g switches.
Both app-name or app-version can be * to search for multiple packages or versions.
Both app-name or app-version can be * to search for multiple packages or versions.
Use the -d switch to tell webapp-config which directory to look in. directory is a directory under the htdocs dir.
Use the -s server switch to change which web-server an install or upgrade should use.
List of the remaining switches that webapp-config accepts. To see the default values that webapp-config will use when a switch is omitted, use webapp-config --help.
They must be the last two parameters passed to webapp-config.
These parameters are not optional.
Use this switch if you're having problems with the install (-I mode), upgrade (-U mode), or clean (-C mode) operations. Add this switch to the command-line that's not working, and make sure you paste the output into your bug report.
If you need to use this switch, make sure it's the first switch you use to call webapp-config.
webapp-config needs to know which web server you are going to use to access your virtual copy. If you don't provide the correct switch, your virtual copy may not work correctly.
Use webapp-config --list-servers to see a list of valid server settings.
When webapp-apache creates a virtual copy, (-I mode), the virtual copy creates local copies of any configuration files that the package needs to use. By using the -u switch, you can specify which user owns these configuration files.
If you give shell accounts out to the users who host websites on your computer, the -u allows you to give ownership of the configuration file (and therefore write permission) to the shell account associated with the website.
user must be a username, and not a numerical user id.
When webapp-apache creates a virtual copy, (-I mode), the virtual copy creates local copies of any configuration files that the package needs to use. By using the -g switch, you can specify which group owns these configuration files.
If you give shell accounts out to groups of users who host websites on your computer, the -g allows you to give ownership of the configuration file (and therefore write permission) to the group associated with the website.
group must be a group name, and not a numerical group id.
The webapp-config tool allows you to create a virtual copy anywhere you want. You are no longer limited to installing a web-based app in /home/httpd/htdocs/<package-name>/! Simply use the -d switch to tell webapp-config where you want to create your virtual copy.
directory is a directory under your htdocs dir. If you do not set the hostname correctly (by using the -h switch), webapp-config will look under the wrong htdocs directory!
This option is required by the -C switch.
Some web-based applications - whether through genuine need or bad design - need to know the hostname of the website that they are part of.
Some web-based applications need to install files (such as cgi scripts) that do not belong under the htdocs directory. To make sure that these files go in the right place, you need to use the -h switch to tell webapp-config the hostname of the website.
host must be a fully-qualified domain name.
If you do not use the -h switch, your virtual copy may not work correctly.
You may find this option useful if /usr/share/webapps is on a different filesystem to your htdocs directories. However, it has been discovered that some packages do not work with this option, which is why it is no longer the default behaviour. You are always better off making /usr/share/webapps a symlink to a directory on the same filesystem as your htdocs directories.
This option is useful if you keep separate directories for your http: and https: sites.
You can change 'htdocs-secure' by editing the config file /etc/vhosts/webapp-config.
type must be one of:
All of these examples are aimed at Gentoo Linux. If you are using webapp-config on a different Linux distribution, they may not work out of the box for you.
To install a copy of phpmyadmin-2.5.6, so that it is available from http://www.example.com/databases/admin/, you would do this:
webapp-config -I -h www.example.com -d /databases/admin/ phpmyadmin 2.5.6
To make sure that the shell account 'dbadmin' could edit the configuration files of phpmyadmin, you'd add the -u switch like this:
webapp-config -I -h www.example.com -d /databases/admin -u dbadmin phpmyadmin 2.5.6
To upgrade the copy of phpmyadmin-2.5.6 to version 2.5.7, you would do this:
webapp-config -U -d /databases/admin/ phpmyadmin 2.5.7
To upgrade all the virtual copies of phpmyadmin-2.5.6, you would do this:
for x in `webapp-config --list-installs phpmyadmin 2.5.6` ; do webapp-config -U -d $x phpmyadmin 2.5.7 ; done
To remove the copy of phpmyadmin-2.5.7, you would do this:
webapp-config -C -d /databases/admin/
To remove all the virtual copies of phpmyadmin-2.5.7, you would do this:
for x in `webapp-config --list-installs phpmyadmin 2.5.7` ; do webapp-config -C -d $x ; done
webapp.ebuild(5), webapp-config(5), emerge(1)
webapp-config is based on the design for an installer for web-based application installers first defined in GLEP #11: http://www.gentoo.org/proj/en/glep/glep-0011.html for the Gentoo Linux project.
Copyright (c) 2003-2004 Stuart Herbert©