In Part one you setup a Linux Cloud Server on Rackspace, then in Part two you installed HyperSQL and an SCM database. Now its time to install the WebDev WAS (Web Application Server)

Install the WAS Sever

When you purchase the WAS server (You can find the US distributor here), you have to purchase either the Windows or the Linux version. Naturally since you are setting up a Linux server, you will want to purchase the Linux version. With my update they provided me with both a 32bit and 64 bit install. The 64 bit install is WB170PACKUSDEPLINUX64078p.zip. This file contains a PDF file with instructions, the install application and package.

Reading the PDF you will discover a number of things, the first being the documentation if fairly out of date when it comes to Linux distribution versions. So some of the version and library requirements will be much lower than what is currently available from the Linux repositories.

Apache and VSFTP were already setup and configured in part one, so you have met those requirements. Next the document mentions a couple of library requirements. The first being libstdc++. This should already be installed with your installation but you can issue the following command to make sure.

yum install libstdc++

Next the document say that the QT 4.5 or later library is required. The following command will install it

yum install qt-x11

The document gives some information on testing the QT Library but since your server does not have a GUI, I don’t believe the command is available. However while testing the websites, I found that captcha controls were not working. It seems something form the graphics library was still missing. With no other clues as to what, I broke down and loaded the KDE desktop with this command

yum groupinstall "X Window System" "KDE (K Desktop Environment)"

Don’t get too excited  “startx” the command that should start the Gui still doesn’t work through the Cloud Control panels terminal, and since I don’t want the GUI anyway I didn’t spend any time figuring out why. But the good news is after installing KDE the captcha controls now work.

Now its time to copy the install files to the server. Just as you did with the HyperFileSQL install, use FTP to upload the install to the server. However this time we are just copying the two file instead of an entire direcotry

You need to give the install file execution permisions with the following command

chmod +x /var/www/html/webdev_install64

Then run the install with this command

/var/www/html/webdev_install64

The install will now launch and the license screen will be displayed. Just like the HyperFileSQL install, you must scroll through the license using the down arrow key to be able to select the “I accept” button.

The next screen is giving us the warnings about the requirements that you have already handled, so select the next button to continue.

Next you need to provide your serial number. Sorry I took the screen shot before keying mine in 🙂

Next is the install location. The default is fine so chose next.

The next screen is requesting some configuration information about the Apache install, the defaults are fine, so select next.

Next is setting up the administrator login, again take the defaults and chose next.

Since the group does not exist, you will be asked if you want to create it, chose yes.

You will be asked a similar question concerning the account, select yes.

And finally it will ask if you want to install the WAS.

The install will now begin. After a few minutes it will complete, and you will get a completion screen with some final details.

When chosing OL, you will get a similar completion screen, chose Done on this screen.

Some of the information on the completion pages was a little misleading. The http://webdev/ should be replaced with either the DNS entry you made to point to the server of the IP address of the server. To test the server you can open up the following address in your browser (replacing the server name with your server name or IP address)

http://webdev.thenextage.com/WD170AWP/WD170AWP/version

Which will display the version information of the server, verifying the installation.

Before you go much further, switch back over the the terminal window and run the following commands to delete the setup files from the web directory.

rm /var/www/html/wevdev_install64
rm /var/www/html/WebDev_Install.zip

Configuring the WAS Server

Its now time to do some configuration of the server. To reach the WebDev Administator and test the installation the address is  http://webdev.thenextage.com/WDAdminWeb170 (your domain will naturally be different). Which will bring up the Administrator page

At this point you have not changed the Admin login information, so the Username is “Admin” as well as the password. Which will log you into the administrator.

I hope you are running chrome as your browser, which will can automatically translate the web pages, because some of the text is displayed in French! The first step is to set the Admin password, so click on the Accounts button, then selected the admin account from the list of accounts, and press the Edit button.

At the bottom of the User edit screen you will be able to reset the password. Enter the current password “admin” and then the password you desire and then click the Modifier button.

That will popup a confirmation window, in French.

Click OK, just trust me 🙂  And that will give us a final confirmation that the password was changed, again in french. If you made a type on the passwords you will get a different message and you will have to correct your entries.

Click OK returns to the User Edit screen, so its a little confusing between the french messages and the return to the edit screen, if you really have changed the password. The easiest way to be sure is to reload the original web address for the WebDev Administrator and log in again.

There are a few Linux configuration changes to make so switch back over to the terminal window for the server. The first change you are going to make is to increase the number of semaphores available on the server. You might be wondering what Semaphores are, well I could tell you, but then, you know what… Seriously they are used to keep track of system resources for threading etc. The document from pcSoft, gives us the following formula to determine the number of semaphores required.  Semaphores = 4 + (4* Number of simultaneous connections). So to support 100 simultaneous connections you are going to change the semaphores to 404. This is done by editing the Kernel sysctl configuration file. But before you begin you need to know what the current settings for are. So type the following command

sysctl kernel.sem

this will return a list with 4 different numbers, record these numbers, because you will need them shortly.

Now use VI to edit the file

vi /etc/sysctl.conf

You are looking for a line that begins with “kernel.sm =” if it is not there you need to add it. Using the information from the previous command, except replacing the last number with 404. If you have been following along exactly, the line will not exist, so just add the following 2 lines to the file and then save it.

# Semaphore Setting
kernel.sem = 250 32000 32 404

So that the new setting will take effect, you should issue the following command.

sysctl -p

Similarly the number of segments of shared memory has to be edited to support the number of connections desired. The formula provided by the pcSoft document says the segments needs to be 4 + number of simultaneous connections. So to support 100 connections the setting needs to be 104. To find out the current setting issue the following command.

sysctl kernel.shmmni

Which on my server returns 4096, so no need to change that setting. If needed, the change would be made to the same sysctl.conf file with the line kernel.shmmni =.

The next setting is the Minimum size of the shared memory. The formula for this setting is (WB Session History Size + (WB Maxium Request sent to the server *  Number of simultaneous connections))*1024

WB Session History Size corresponds to SHMHISTORYSIZE in the WebDev Configuration and defaults to 2048 kb.

WB Maxium Request sent to the server corresponds to SHMDIALOGSIZE in the WebDev Configuration and defaults to 500 kb.

Since you have not changed any of the default settings, to value required for 100 connections is 53297152.

To find the current setting of the server issue the following commnad

sysctl kernel.shmmax

Which on my server returns 68719476736, which is more than the requirement so no change needed. If a change was need it would be done by editing the same config file and editing the kernel.shmmax = line.

Adding a WebDev User and uploading your first site.

I would like to Quote one of my fellow bloggers here. I would give him credit by name but he doesn’t list his name on his website, but you can find his website at http://ilikewd.free.fr. He has a article describing his challenges of getting WebDev 12 running on Ubuntu 8.0.4, which was an incredible help to me when I got stuck on my attempts. My favorite quote of the week comes from him “Installing WebDev for Linux is like reading the Da Vinci code. You have to decode cryptic messages, discover untold stories, find hidden log files and use a magic language.” What he very nicely put, I will but in plain “Uncle Pete” speak, “When it comes to the user setup section of the Linux deployment document, assume that half the information is mistaken, and the other half is an absolute lie.”

A few of the tips that came from that article that were a huge help were:

1. WebDev keeps a log file of communications with the Remote Deployment tool. It is in located at /usr/local/WebDev/17.0/wdinstalle.log
2. The apache user must be added to the webdevadmin group, so that it has the correct permissions to access the files and deploy sites.

What follows is quite a departure from the documentation, but this is what I did to get it to work, as always use at your own risk, your mileage may vary, and a few other lawyerly quotes. Setting up a user for each site, makes it easier to manage and deploy sites. For testing purposes and to see how deployment works, you are going to upload the eBusiness example provided with WebDev. So the first step is to create a user to administer and upload the site. ebusiness seems like a logical user name, so add the user with this command

adduser ebusiness

To set the password for the new user issue this command and follow the prompts

passwd ebusiness

The adduser command added a home directory for the user. You need to make sure that the webdevadmin group has access to that folder with these command

chgrp webdevadmin /home/ebusiness
chmod g+rx /home/ebusiness

You now need to add a few directories to the users home directory, so change to the home directory of the ebusiness user with this command

cd /home/ebusiness

The following commands will create the 4 directories required

mkdir site
mkdir data
mkdir webservice
mkdir ftp_webdev

Those folders need to be assigned to the webdevadmin group that was created when you installed the WAS server, and be owned by the ebusiness user. These commands accomplish that.

chown ebusiness:webdevadmin site
chown ebusiness:webdevadmin data
chown ebusiness:webdevadmin webservice
chown ebusiness:webdevadmin ftp_webdev

Now log into the WebDev Administator, click on accounts, and added a new account matching the Linux account you just added.

This creates the WebDev account and opens up a form that will allow you to make changes. You will notice that the directories you just created are specified on this screen as well. Change the maximum number of connections for all sites in this account to an appropriate value and press the Apply button. The account is now created and you are return the the Account Management Page.

You are now ready to deploy the site, Run WebDev on your development machine, and open the eBusiness example. Then from the Workshop menu, chose “Deploy the Site” and from that sub-menu chose “Deploy the site remotely”

This will launch a wizard to deploy the site. You can take the defaults on the first page and click next.

The next page lets you select the elements to include, select everything and click next.

Since this project uses an component you are given the option to include it, go ahead and select it and click next.

Next is Languages, click next

The next screen allows you to provide some Copyright information, change as you desire and click next.

The next screen gives you the opportunity to make a backup copy of the project as a snapshot of the deployment. Skip that step and click next.

When you click next, the library will be created and then a second wizard will launch for deployment. Chose “Deploy the WebDev site on a remote WebDev Application Server” and click next.

The next screen needs the address for the server and the account that you just created. The account information is the same for both the WebDev and the FTP account.

More than likely Active FTP will not work for you, as any NAT translation or firewall between you and the server will interfere, so click on the “Avanced parameters” button, then on the Advanced tab, set the FTP transfer mode to Passive FTP.

You can now click the “Test the parameters” button and you should get a confirmation message. It took me two days to get the confirmation message, but through the magic of the web, here’s the message!

After clicking the OK on the confirmation, click the green check mark to return to the main wizard screen, and click next. Which will bring up the Deployment parameters settings, change as you desire and click next.

Next will list the files that will be transferred, click next.

Next is settings for Automatic data modification. Set as you desire. I will resist giving my opinion about automatic data modification. (Must resist giving opinion, must resists). Ok, I managed to resist, so click next.

Next is setting parameters for the site, change as desired and click next.

Then you are given an option to generate a statistical file for the site, click next.

And finally you reach the done screen, so click the green check mark.

The site will now be transfered and activated. This can take a few minutes. The progress screen will provide some feedback about what is going on. When completed the progress window will change to Setup Completed and give you a link to test the site.

If you are wondering what those warnings are my friend Google translate says they are telling you that there are not enough connections for this users for the site. (Which is because the user is setup with 100 connections but the default taken when creating the site was 150) And that you should change your setting or contact your administrator for more connections. And the line there is letting you know that the max is 100 connections. All important information and if this were a production site you would want to put some thought into the connections allowed, but for now you can move on.

NOTE: After creating a new site, Apache should have been gracefully restarted, so that changes to its configuration file for the new site are recognized. This did not seem to happen when I uploaded this site, so the first time I ran the site all of the images were missing and it did not function correctly. So to manually reset Apache you can issue this command

service httpd restart

You can now test the site by opening up a browser and going to the address listed in the Setup Complete window (http://webdev.thenextage.com/WD170AWP/WD170AWP/connect/eBusiness in my case), go ahead and log in and play around a little.

Setting up Virtual Host for Apache

If the question hasn’t already crossed your mind, I am sure it will shorty. What’s with that long address and how to I change that?

Webdev did create a shorter URL for you when it published the site, which in this case is http://webdev.thenextage.com/eBusiness. That is the address to the server, followed by the project name, which remember is case sensitive. That’s shorter but still not perfect if you want to have an actual domain pointing to the site.

Viturtual Host is part of that answer. Virtual Host allow Apache to serve several websites from one server and IP address. The first step is to setup a DNS entry to point to the server. In this case I am adding a sub-domain pointer, but the steps would be very similar to host multiple domains as well.  From the Rackspace Control Panel, edit the DNS settings and add a new CNAME record.

After adding that entry going to http://ebusiness.thenextage.com would take you to the same webpage as webdev.thenextage.com. Which is the “Uncle Pete is a Cool Cat” test page from the first article. To have that address point to a different website, you need to make some changes to the Apache configuration. The Apache configuration file is fairly large, which makes difficult to edit, so you are going to create a separate configuration file to manage the virtual host settings. To do this edit the file with this command

vi /etc/httpd/conf/httpd.conf

And at the end of the file add the following line, which will cause Apache to also load the vhost.conf file when it restarts.

Include /etc/httpd/conf/vhost.conf

And then create the new vhost.conf file using vi with this command

vi /etc/httpd/conf/vhost.conf

Here is a copy of my file

NameVirtualHost *:80
<VirtualHost *:80>
    ServerName ebusiness.thenextage.com
    ServerAlias ebusiness.thenextage.com
    DocumentRoot "/var/www/html/ebusiness"
    CheckSpelling On
</VirtualHost>
<VirtualHost *:80>
    ServerName webdev.thenextage.com
    ServerAlias webdev.thenextage.com
    DocumentRoot "/var/www/html"
</VirtualHost>

The first line tells the system that virtual host will be listing on all the IPs of the system, and on the normal HTTP port 80

Then each Virtual Host has its own section. ServerName is what will be search for in the Http request. If it finds a match, any Apache setting in that Virtual Host section take place. This is where you would normally put myfirstdomain.com in one Virtual Host entry, and myseconddomain.com in the second Virtual Host entry.

ServerAlias is the alias for the domain. If you are doing a full domain setup, ServerName would have myfirstdomain.com and ServerAlias would have http://www.myfirstdomain.com

DocumentRoot is where Apache will try to load the home page for the site.

CheckSpelling is a special directive that tells Apache not to use case sensitive URLs. During the initial test of the the eBusiness website you might have noticed that a few graphics were missing, such as the square colored boxes in the left had menu, and under the product picture on the product specific pages.

If you view the page source you will find the line for this graphic is <img src=”Images/Bullet_Menu.png” , and if you look in the /home/ebusiness/site/eBusiness/EBUSINESS_WEB/UK/images folder on the server you will see that the image does exists. The issue is that the folder is images and the source code is looking in Images. Linux is case sensitive, so it doesn’t find the image. WebDev should have handled this and I am not sure why it did not but the “CheckSpelling On” setting will resolve the issue. However, you should be careful with this setting as it will create a small performance hit as your URLs are parsed.

After restarting Apache, you would now be able to navigate to http://ebusiness.thenextage.com/eBusiness , or if you were setting up a true domain, http://www.myfirstdomain.com/eBusiness. Getting closer but still not there. And once you start navigating the site you will still see all the ugly URLs of WebDev. If the URL’s don’t bother you then you could setup a Virtual Host like this entry

<VirtualHost *:80>
    ServerName x.thenextage.com
    ServerAlias x.thenextage.com
    DocumentRoot "/var/www/html"
    RedirectMatch ^/$ http://x.thenextage.com/eBusiness
 </VirtualHost>

With that setup if someone type http://x.thenextage.com then it will automatically redirect them to http://x.thenextage.com/eBusiness, and then once there the normal WB URLs will take place such as http://x.thenextage.com/EBUSINESS_WEB/UK/product.awp?P1=90&AWPIDA05683F4=5805BD122682602C2BD68DF278D4527375C47D5A

You can make it appear like your entire site just uses your primary domain name. This is accomplished with using a frameset. There are SEO considerations with framesets and there may also be issues if your website links to any external websites, many detect a frame set being used and block the link, but those are topics for another article. If you SEO and external linking issues, then you can create a index.html file like the following

<HTML><HEAD>
<META NAME="description" CONTENT="http://ebusiness.thenextage.com/eBusiness">
<META NAME="keywords" CONTENT="">
</HEAD>
<FRAMESET border=0 rows="100%,*" frameborder="no" marginleft=0 margintop=0 marginright=0 marginbottom=0>
<frame src="http://ebusiness.thenextage.com/eBusiness" scrolling=auto frameborder="no" border=0 noresize>
<frame topmargin="0" marginwidth=0 scrolling=no marginheight=0 frameborder="no" border=0 noresize>
</FRAMESET>
</HTML>

That file sets up a frame set and host the website inside the frame set, so as the URL changes on the pages, they are not displayed because that is the internal frame. The key to the file is the webaddress entered after the <frame src= , that should be the address to launch your site. In your Virtual Host setup you set the DocumentRoot for ebusiness.thenextage.com to “/var/www/html/ebusiness”, which means that anytime someone attempts to navigate to http://ebusiness.thenextage.com, Apache will launch /var/www/html/ebusiness/index.html. So fire up you favorite FTP client, and use the FTPAdmin login created in the first article, which uses /var/www/html/ as its home directory, and create a ebusiness folder under that root and upload the index.html page you just created.

Now if you navigate to http://ebusiness.thenextage.com, the website comes up, and as you move through the pages the address remains the same.

If you have been paying attention, you may have noticed that you now have two domains (x.thenextage.com and ebusiness.thenextage.com) both launching the same website. You could add a bit of fancy code to your site to change the logos and style based on the URL address and have the appearance of two sites, but only one code base to maintain. Again a good topic for a future article.

Converting the Website to use the HyperFileSQL Client Server database

Now that you have the site up and running, you will notice it is very responsive, however at this point it is still using HyperFile classic files, so now is a good time to convert the site to use the Client Server database. This is nearly the exact same steps as you used to move the Classic files for the Windows application in the second article. I won’t bore you will step by step instructions, refer back to the second article if you need help. The steps are

1. Open up the eBusiness Project
2. From the Project menu, select Load the Analysis
3. From the Analysis menu, select Connections
4. Add a new connection and follow the instructions, pointing the the HyperFileSQL server at rackspace.
5. When asked select copying the files to the server and associating the files in the Analysis with the new connection.
6. Once the wizard is done and the files have been move, use the Workshop -> Deploy the Site menu to upload an update of the site.
7. The site is now using the Client Server database. You can verify this by editing a record via the website, then using the HyperFileSQL Control Center, view the tables on the server and verify that your change was made. Note: the files are password protected with the password of “ebusiness”

Launching a Second Site

adduser pcreminder
passwd pcreminder
chgrp webdevadmin /home/pcreminder
chmod g+rx /home/pcreminder
mkdir site
mkdir data
mkdir webservice
mkdir ftp_webdev
chown pcreminder:webdevadmin site
chown pcreminder:webdevadmin data
chown pcreminder:webdevadmin webservice
chown pcreminder:webdevadmin ftp_webdev

Next use the WebDev Administrator to add the pcreminder user to WebDev. The open the project in WebDev, and go through the deploy the site, using the pcreminder user instead of the ebusiness user. Create a copy of the index.html file from early but change it to point to pcr.thenextage.com/pcReminder. Then using your FTP client, log in using the FTPAdmin user, create a pcr folder under the root and upload the index.html file. Then us VI to edit the /etc/httpd/conf/vhost.conf file and add the following lines.

<VirtualHost *:80>
   ServerName pcr.thenextage.com
   ServerAlias pcr.thenextage.com
   DocumentRoot "/var/www/html/pcr"
   CheckSpelling On
</VirtualHost>

And now pcr.thenextage.com launches my pcReminder test site!

I am working on a couple of tax resolution help site that will be launching at the first of the year. I don’t have anything published yet but here are the seconds of the vhost.conf file so you can see how they look when not using a subdomain.

<VirtualHost *:80>
   ServerName thetaxcure.com
   ServerAlias www.thetaxcure.com
   DocumentRoot "/var/www/html/thetaxcure"
   CheckSpelling On
</VirtualHost>
<VirtualHost *:80>
   ServerName taxfix.it
   ServerAlias taxfix.it
   DocumentRoot "/var/www/html/taxfixit"
   CheckSpelling On
</VirtualHost>

Notice the differences with the ServerName and ServerAlias entries. Those domains were register with godaddy.com, then when into the rackspace cloud control center and added new DNS records for them, and then went back to go daddy and edited the domains and changed the Name Server records to the Rackspace ones.

Summary

So there we have it, you have a Linux Cloud Server at RackSpace, with HyperFileSQL Client / Server and Webdev, running and ready for you to create the next Facebook, Instagram, or whatever. Just be sure to remember you good ole’ Uncle Pete, when you cash in for billions.

• WEBDEV