mysqlApache Prerequisites
You need the following on your local server:1-. A running Apache server with a dir capable of running .cgi programs.
2-. A running MySQL server that you know the root passwd for.
3-. The MySQL client lib and header files installed in the normal places (/usr/lib/mysql and /usr/include/mysql.)We assume you know about:
1-. Setting up and installing Apache Mod_SSL servers.
2-. Basic vi (or another editor like pico etc.) operation.
3-. Compiling and installing source code based software.
Getting, compiling mysqlApache.cgi and setting up initial system users
See INSTALLOnce this is done, and no problems were encountered (send us all compilation warnings and errors please!), you can proceed to setup your application. Submit bugs via http://openisp.net site link.
First, login to the application via your browser (Latest Mozilla, FireFox, or -shudder- MSIE 6+, only). The initial system set login is Root/wsxedc (!change this ASAP!) Once you are logged in you need to create at least one Admin level and one Reseller level accounts:
-Click on top right tClient link.
-Click on [New] button, in top left navigation tool bar.
-Enter the user's name or nick name in the cLabel field.
-Enter the user's first and last name in the appropiate fields.
-Enter uMaxSites=1 and uMaxIPs=1 for default max values or any other higher number. See tConfiguration parameters for more info.
-Optionally enter other appropiate or relevant info in the other fields.
-Click on [Create New Record].
-Click on [Authorize].
-Enter a 6 char min passwd and select the user level.
-Click on [Confirm Authorize].
-Repeat this for the other level user.
-Click on the logout link.
-Login as the Admin level user you just created.Finally, create a Reseller level user. This user will then be able to create websites for himself or other users. The Root level users should not be able to create websites, these accounts should only be used for setting up system parameters or fixing rare problems. Of course the Root level users can change the tClient uMaxSites and uMaxIPs of themselves or anyone else, if this default scheme is not adequate.
Setting up IP numbers to be used by your virtual hosts
Edit your /etc/rc.d/rc.local script and add all the IP numbers that will be available for automated website hosting (Please note that future releases will be able to configure IP's on the fly, release them, as well as configure boot time startup of IP's. The final application will also allow sharing of a single centralized pool of IP's for all webfarms running mysqlApache.)
If your OS version (or linux kernel version) allows, you may also setup virtual port IP's via /etc/sysconfig/network-scripts system. This is the best way if available.Typical rc.local entries for a virtual ip at boot (check your system via ifconfig -a):
ifconfig eth0:1000 123.123.123.1 up ifconfig eth0:1001 123.123.123.2 up ... ifconfig eth0:1021 123.123.123.22 upBe very careful when setting up remotely your server IP's; ifconfig mistakes will mean calling into your colocation facility and finding and having "joe" reboot your server for you!Finally, via the cgi, access the tIP table and click on the [New] button. Enter the optional IP range setup above Ex. 123.123.123.1-22 in the cIP right panel field, then hit [Create New Record]. Or simply [New], enter a single IP in cIP, and [Create New Record].
Setting up the mysqlApache run servers and tConfiguration variables
First run from the shell as root:
shell>$CGIDIR/mysqlApache.cgi ApacheInstallThis will install the default root directory structure for the two mysqlApache managed httpd daemons: /usr/local/apache and /usr/local/apache_ssl. Note that a third httpd daemon (webconsole) will be running this is for your intranet or SSL access to the mysqlApache.cgi itself.
It will also install the supplied newwebsite.tar new web site directory structure tar file in /usr/local/apache/newwebsite and untar it. This tar file and the associated dir structure is what is installed in the user cWebDir space for each virtual website. This can be customized accordingly and then "tar cf newwebsite.tar *" should be executed inside /usr/local/apache/newwebsite dir to create the default new web site structure.
For the shared SSL server you will need to install in /usr/local/apache_ssl/conf/ the certificate and the certificate private key files as follows -we assume that in tConfiguration the cServerDomain=isp.net:
isp.net.crt.pem isp.net.key.pemThe cert (...crt.pem) should not be encrypted by a passkey. If it is you must modify the httpd.conf SSL template (tTemplate menu) and specify a passkey generating program. This implies the same security risks as having the cert not password protected. Creating your cert (and/or cert request) and key are beyond the scope of this tutorial (see www.modssl.org for starters.)Finally via the mysqlApache.cgi, configure the tConfiguration variables, each variable has a comment section that serves both as a mini help text and for your own comments. Read each variable comment and modify accordingly. With default install most should be fine as is, only having to customize for your server name and IP as well as for your ISP email and url.
These tConfiguration parameters if not setup correctly will keep the servers from running:
cServerIP: Should be the main IP of the server itself.
cServerDomain: Should be the FQDN of the server itself.
cApacheDir: The default is fine if you ran ApacheInstall.
cApacheSSLDir: The default is fine if you ran ApacheInstall.
cWebDir should be /home/web or some dir on a partition with plenty of space. It should exist.
Setting up the root crontab for jobqueue processing
Before installing the crontab you should familiarize yourself with the capabilities of the mysqlApache.cgi application running from the commandline:
shell>$CGIDIR/mysqlApache.cgiThis will provide a menu of the different commands and arguments available.
After creating virtual websites via the cgi interface, you should run:
shell>$CGIDIR/mysqlApache.cgi jobqueue debugAnd check to see if the sites and site users are being created correctly. Once all is debugged and the application is running as expected you can install a root crontab to do this for you every hour or so (as required by your workload and customer expectations.) Remember root crontab only.shell>crontab -e (Add the following line or similar) 20 * * * * /var/www/html/cgi-bin/mysqlApache.cgi jobqueue process > /dev/nullAny errors will be emailed to root on the localhost, or maybe someother account if cron is so setup.
MySQL root password security
Job queue processing via crontab in a few instances requires knowledge of the MySQL server root passwd (Ex. enabling MySQL database for a website admin user.) In order to keep the MySQL root password out of ps scans we use the tConfiguration table to save this data. The tConfiguration table would then have a record with cLabel=cMySQLRootPwd and cValue=thisistherootpwd. (Internal note: this idea should be used for normal mysqlapache crontab jobs and even extended to all mysqlISP systems.)
Introduction to mysqlX interface
The mysqlX RAD interface although slightly industrial in look and feel and rough around the edges. Allowed for quick deployment of a webconsole (web browser) based interface to mySQL based applications. It permits a standardized look for many different ISP tools. With it's flaws and all it is more efficient to standardize and keep all interface bugs in one place.You login to the interface with a case sensitive login which can have spaces, for example: John Smith. And a password. This should be done in most cases via an SSL httpd (https) instance for security and then you can go to normal http for normal data manipulation to keep server load down and response times low.
Once you have logged in you will be at the main (post) page. The top right area will have numerous links to the different tables. The links viewed may change depending on the permission level of the login.
Every table page has 3 areas (below the top common header), of which 2 are usually the only ones in use. The left and the right side panels. The right side panel has the schema based form interface, and the left panel has the schema independent application interface or interfaces to other related table data. Usually the left panel will also provide navigation links into other application specific areas or just into the table records. The 3rd area is the bottom panel which is used mostly in the mysqlBind application for the zone resource records.
Most table pages will have a record navigator along with the typical New/Modify/Delete buttons. Most buttons should have the yellow tool tip pop-ups that explain the function briefly. Most operations are two step based, for example: [Delete] then [Confirm Delete.] Keeping things somewhat safe for casual use. Also a simple mySQL recommended "record locking" replacement scheme has been implemented to keep multiple users from modifying the same record in parallel. This is done by simply checking the modification date against the (stateless) cgi form information. This may be a cause for confusion when using the browser BACK feature and then trying to modify a record.
Another cause for confusion is the cgi stateless model itself that may show data in the browser that has changed or is not correct. Unixservice's ism|5 native GTK+ and Win32 applications overcome this problem without resorting to Java or other such non standard HTML extensions. The KISS principle has been used throughout and the open source community motto "Release early and often" has been followed for good or for "temporary until next release 'worse.'"
Some field checking and manipulation is used via the RAD, and in some cases has created strange problems. Many layers of cgi security and permission level access to New/Mod/Delete and field operations are in place allthough not debugged and in many instances not yet in sync with the applications needs. The use as Root is then in some cases the only way to go, especially with earlier versions of the application.
Intro to new tUsage and traffic mysqlApache subsystem
Starting in release 1.42 we began to implement the tUsage table per site and per site user usage data collecting. This was needed to make sure mysqlISP new billing system (mysqlISP 1.23) would also have real usage product handling in place.This whole thing is changing all the time. As our live production alpha systems provide us with feedback. Even the tUsage table schema has changed many times requiring "drop table tUsage" and clicking on tUsage again to upgrade, which is far from a permanent solution and causing loss of test data -and even access_log and xferlog data. You should proceed with caution if you decide to try this out at home...lol.
Basically, we studied all the typical problems associated with mass website hosting applications and per site logfile analysis and rotation. After reading up tons of mailing list entries for Ensim, CPanel, Plesk, Cobalt RAQ appliances, etc, and using our own and our customers experience we decided on the following guidelines for our solution:
1-. Do not overload the server.With these basic guidelines in mind we came up with this KISS method. A single root crontab entry that insures that everything is done correctly with insignificant or no data loss (*1). Example:
2-. Eliminate logrotate based methods.
3-. Never combine log files into one giant per server one.
4-. Force things to be done in a sequential order to avoid loss of billable bottom line important data.
5-. Allow for special handling on a per site basis if needed.
6-. If webalizer is used do not duplicate it's efforts.
7-. Help webalizer not load the server or DNS.
After this has run you will have daily usage information in tUsage, that will be used to update mysqlISP products via the mysqlApache and mysqlISP tJob job queue system via a code still being developed at the time of this writing.2 0 * * * /cgi-bin/mysqlApache.cgi Webalize >/home/openisp/logs/mysqlApache.webalize.errors\ 2>&1;/usr/local/sbin/traffic run >>/home/openisp/logs/mysqlApache.traffic.log 2>&1Read traffic.c for more information. You may want to customize it. It also has information on the tConfiguration name/value pairs used. Also check out mainfunc.h for the "Webalize" command line above functionality. It also has info on the optional FTP xferlog webalizer configuration file in tConfiguration.Notes
(*1) A little loss may occur in million hits per day sites, which should not matter for billing purposes since it would be 0.01% of the traffic data. The loss ocurrs in the time the server/OS takes between copying the logfile and then truncating the access_log to 0. Usually this is a very short time. Especially in our daily model that insures small access logs. These high traffic sites should all run webalizer incrementally and at least daily.
If you know a lot about C and mySQL please review our code and send us suggestions.