Creating/Maintaining a ViciBox v.4.0 install table

[Kumba]

New in ViciBox v.4.0 is a PERL-based installer that creates and stores server and cluster information in a table called 'vicibox' on the primary database. This table coordinates all new server installations and will be used for other functions in the future. If you have an older version for ViciBox or a non-ViciBox install you can create compatibility by creating and populating the table yourself. Below is the 'vicibox' table schema as well as the field definitions for the various server roles:

Vicibox table schema:
CREATE TABLE IF NOT EXISTS `vicibox` (
`server_id` tinyint(3) unsigned NOT NULL AUTO_INCREMENT,
`server` varchar(32) NOT NULL,
`server_ip` varchar(32) NOT NULL,
`server_type` enum('Database','Web','Telephony','Archive') NOT NULL DEFAULT 'Telephony',
`field1` varchar(64) NOT NULL,
`field2` varchar(64) NOT NULL,
`field3` varchar(64) NOT NULL,
`field4` varchar(64) NOT NULL,
`field5` varchar(64) NOT NULL,
`field6` varchar(64) NOT NULL,
`field7` varchar(64) NOT NULL,
`field8` varchar(64) NOT NULL,
`field9` varchar(64) NOT NULL
PRIMARY KEY (`server_id`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


Named Field Types:
server_id = Numerical number for the server entry and the primary key, not used for anything other then internal DB reference
server = The name given to the server, this is taken from the systems Hostname when installed but may not always match
server_ip = The IP address used by that server to talk to other ViciDial servers, usually this is the internal IP address
server_type = The role that the server has installed on it. If the server performs multiple roles then it will be listed multiple times, once for each role


DB field types:
field1 = mysql server ID, use 0 for Master, 1 for first slave, 2 for 2nd slave, etc, up to 9
field2 = DB name, default is asterisk
field3 = svn revision of DB
field4 = regular user
field5 = regular pass
field6 = custom user
field7 = custom pass
field8 = slave user, only relevant to primary DB
field9 = slave pass, same as above

Web field types:
field1 = external IP
field2 = audiostore directory

Telephony field type:
field1 = external IP

Archive field type: Auto-Configuration only works on a single archive server, other things have to be done manually
field1 = FTP user
field2 = FTP pass
field3 = FTP Port
field4 = FTP directory
field5 = URL Path


The schema and field definitions are documented at the top of vicibox-install.pl on the installation CDs. The above definitions were taken from vicibox-install.pl v.120920-1502. While all new version will try to maintain backwards compatibility, there may be new features that will require upgrading the schema. I guess we will handle that when we come to it. Currently I only envision broadening the dynamic field list for using more fields or possibly adding additional server roles. Will probably build something into the installer to automatically apply vicibox schema updates when necessary.

To add support for ViciBox v.4.0, you need to run the schema SQL listed above on the primary database server and then populate the table with the appropriate data. If your server does not have a defined field, for example a Slave User or External IP, then leave the field Blank. This will signify that the field or option enabled by that field is not available. All other fields must be filled in.

If you are unsure or do not have the skills to populate this table then it would be best to post up your config in your own post for help or contact the ViciDial Group for support. We do have a vicibox-edit on the project list to be completed but it is a few notches below some other priorities such as the "restore" option.

If anyone feels like helping write a PERL-based vicibox-edit let me know. I am always willing to share the load as long as the end result is maintainable and works.

[tiny typo fix = williamconley]

[williamconley]

Brilliant. I could probably help out with a table editor, but we'd prefer to create it in PHP for web editing for the end user. Possibly in a secured web admin folder? Or were you looking only for "during install"?

As soon as we have an actual 4.0 installation or two running we'll see what we can do.

Also, with your permission, we'll look into adding this in our Ubuntu install. (Later, though, getting it off the ground comes first!)

[Kumba]

Brilliant. I could probably help out with a table editor, but we'd prefer to create it in PHP for web editing for the end user. Possibly in a secured web admin folder? Or were you looking only for "during install"?

As soon as we have an actual 4.0 installation or two running we'll see what we can do.

Also, with your permission, we'll look into adding this in our Ubuntu install. (Later, though, getting it off the ground comes first!)

Problem I have with PHP is adequately securing it. I had already thought about doing that but it would be hard to read everything from PHP. Most notably being the database server if it couldn't read astguiclient.conf. It would also need some sort of permission control either pulled from the vicidial_users table or through some other mechanism.

You can add support for it, it's open source for a reason. I have no qualms about it.

[williamconley]

These days we just lock the folder it's in with apache and keep all "credentials" in /etc/ instead. So if apache/php hiccups from a DOS, all they get is the code. No information. And if apache is working, it will refuse to serve that folder without special permission. We do the same for phpMyAdmin.

We'll definitely look at being sure our final has this in it so a fresh install from your .iso can populate as if it were adding to one of yours. That will allow the Ubuntu users to not flip out when they add a new server moving forward (and allow transition from one to the other, and mixed clusters as Vicidial is already set up to allow). It will also allow "Uniform development" moving forward (no need for the end user to learn "our" system and then relearn yours if they switch).

We are trying to keep this as "stock" as possible. Our guy has completed his basic run, everything is "installed" (with all screens running) and he's become adept at managing the installation system. Now we shoot for functionality and basic stability.