File System Layout Cleanup

(this is a work in process)

Goal: make the file system more organized, eventually support online updates of more of the framework of freepbx.

Motivation: support online updates, have a sane layout (eg, global functions used by AGI and other scripts should not be in the "web" root folder, that makes no sense!)

Related tickets: #1497

Remapping

Description	New location	Old location from tarball	Old (default) location
Root directory	/usr/share/freepbx/
Config file	/etc/freepbx/freepbx.conf	amportal.conf	/etc/amportal.conf
Modules	/usr/share/freepbx/modules/	amp_conf/htdocs/admin/modules/	/var/www/admin/modules/
Libraries	/usr/share/freepbx/lib/	amp_conf/htdocs/admin/ (mostly)	/var/www/admin/
Web interface	/usr/share/freepbx/htdocs/	amp_conf/htdocs/	/var/www/
Binaries/scripts	/usr/share/freepbx/bin/	amp_conf/bin/	/var/lib/asterisk/bin/
AGI scripts	/usr/share/freepbx/agi-bin/	amp_conf/agi-bin/	/var/lib/asterisk/agi-bin/
Music on hold	<tarball>/contrib/mohmp3	amp_conf/mohmp3/	/var/lib/asterisk/mohmp3/

See more detail below

Config file

Now is probably a good time to rename amportal.conf to freepbx.conf. An upgrade script can do it during install_amp. It may also make sense to have parse_amportal_conf() look for freepbx.conf first, then fall back to amportal.conf.

It also may be desirable to put this in /usr/share/freepbx/conf/freepbx.conf, and then symlink to /etc.. (or vise-versa). See discussion below about bootstrapping.

Modules

Since the modules are used by everything in freepbx (not just the web interface), they should really be in a shared location, not the web root. Design-wise, this makes more sense, but there are a couple possible issues:

Permissions

It is possible there could be permission issues with having this directory outside of web root, since it would need to be writable by the web interface in order for online updates to work. The quick fix is that group ownership is set to a group the web user is in and it's set group-writable. Possibly a longer-term fix is to have a priviledged FreepbxDaemon? running, and have the web interface tell the daemon to do module upgrades (which would then invoke the module_admin script).

Libraries

Right now, libraries are a mess. They are scattered around, and a lot of stuff is mixed up in amp_conf/htdocs/admin/functions.inc.php. In addition, there are at least 3 copies of php-asmanager.php, and multiple (different) versions of parse_amportal_conf() in various locations.

What needs to be done:

• We need a way to parse amportal.conf (freepbx.conf) in order to figure out where
• Take the main functions.inc.php, and separate it out into functions used exclusively by the web interface, and functions used by all aspects of freepbx (possbily including the web interface). The web interface-only functions can stay in the web directory, but the rest of the functions should get moved into a /usr/share/freepbx/lib/freepbx.inc.php (?). Effectively, the design goal of this is that bin/ agi-bin/ etc scripts should not be using ANYTHING in /var/www.

Web Interface

The web interface would physically be in /usr/share/freepbx/htdocs/. To make it accessible, either a symlink would be installed, eg, /var/www/freepbx -> /usr/share/freepbx/htdocs/ or a directive like "Alias /freepbx/ /usr/share/freepbx/htdocs/" can be used. Both of these methods would make, eg, the admin interface accessible at http://hostname/freepbx/admin/ which is a bit different than the way it is now, but probably makes more sense.

Binaries

Many of the binaries that we now put into /var/lib/asterisk/bin/, should probably be linked into /usr/bin/ (or somewhere in the path), as well as their old (backwards-compatible) location of /var/lib/asterisk/bin/. module_admin and retrieve_conf would be good candidates here (all the perl retrive_* scripts are not really meant to be called directly, only invoked by retrieve_conf).

Music on hold

I've personally always hated that install_amp sticks the musiconhold files in by default, though I think this is partially fixed now (by default it won't install mp3 files except on a fresh install?). It may make more sense to not do that at all, and just leave them in a contrib/ directory for the user to deal with.

Boot strapping config

aka parsing freepbx.conf (amportal.conf)

One of the reasons we have so many parse_amportal_conf()'s is because we need a way to find where eg, the web root/library path is to load functions.inc.php (which contains the real parse_amportal_conf()). Over time, some of the other parse_amportal_conf()s have changed from a simple script, to including more of the defaults/sanitizing that the main one contains, as needed.

Ultimately, what we need to do is scrap all that, and figure out a way to parse it once with the full parse_amportal_conf() function.

Possibilities:

• During install_amp, write the main directory location out to a constant in the top of each file, so it always looks for FREEPBXROOT/conf/amportal.conf (this is the reason why having the conf/ directory would be used, see discussion about config file above).
• Default to /usr/share/freepbx, and if an environment variable FREEPBXROOT is set, use that instead.
• A combination of both the above

Online updates

Part of this process should also involve making more of freepbx upgradeable from the online upgrade system.

This would involve adding some more ModuleSubdirectories:

• lib/, which would go to /usr/share/freepbx/lib/*
• htdocs/, which would go to /usr/share/freepbx/htdocs/*
• etc, which would go to /etc/freepbx/* (is this one necessary, or even desired?)

(note, this would link each file -- NOT directories -- eg, if modulename/htdocs/admin/common/something.css exists, a symlink /usr/share/freepbx/htdocs/admin/common/something.css would be created to point at it)

As you can imagine, now much/all of the web interface (htdocs) can be moved into modules/core/htdocs/, freepbx.inc.php (functions.inc.php) can be moved to modules/core/lib/freepbx.inc.php, and so on, and it would be upgradeable by upgrading core in module_admin. It may not be possible to do this to EVERYTHING, as eg, having no modules installed should be enough to be able to use module admin.. but we may be able to do it in a way that core is just always installed somehow.

(Really, symlinking into the core directory, even if core is "disabled", will still work, the symlinks are NOT disabled..)

Symlinks

All the symlinks would be done by retrieve_conf normally, as well as install_amp (since install_amp will need to invoke module_admin to install/upgrade core, and you need the links initially in order to make anything work).