How to EXPAND berylium
By Chris Snyder, 2002-07-14 13:01


STEP 1: 
Apache configuration

To create a new berylium site on the same server, make sure that you have the virtual site up and running via httpd.conf. The best strategy due to vitual server limitations with SSL is to make https://newsitename an alias of https://originalsitename and let the certificate have the wrong name, as it is apparently not possible to load a different cert for each virtual name.

If the site will not be serving any pages outside of berylium, the code is set up so that it can run from a central repository. There is no need to have more than one production copy of the berylium code on any machine. This makes virtual hosting a snap, I hope.


STEP 2: (optional)
If you DO need to provide individual http (aka public_html) directories, you can make symbolic links to the files in the original site's http directory so that any updates to those files will be global.

cd /home/newsitename/http
ln -sv /home/originalsitename/http/berylium berylium
ln -sv /home/originalsitename/http/bicons bicons
ln -sv /home/originalsitename/http/config config

Check your work by going to http://newsitename... you should see a single error message "Sorry, there is no site by that name".



STEP 3: 
Berylium site creation

https://originalsitename/berylium-init.php
Enter the db management username and password (not the webserver username and password).
Once the site is created, log into the database via the shell client and make the updates indicated at the bottom of the berylium-setup.php.



STEP 4: 
Customizing the new site

The site admin will want to customize the site, which can be done through the contexts and policies link at the top of any page. Contexts and policies are documented elsewhere.

There are two levels of customization: dynamic (available online to site admins) and hardcoded (available only via filesystem access (ftp, ssh, etc)). Dynamic contexts and policies only apply to anonymous users and basic members, and dynamic contexts can only include defined object fields. Hardcoded contexts and policies apply to all users and hardcoded contexts can include PHP code that is run before or after object display, allowing you to create custom object fields and trigger actions.

As a system administrator, it is your call whether or not to allow admin users the ability to run PHP code on your server. A malicious admin *could* compromise your system as the webserver user. This is a limitation of PHP, not berylium: PHP allows shell and filesystem access by default. 