Tyler McManus .com

So in the continuing pursuit of setting up the preferred web development environment for myself on my home network, I installed Subversion (SVN) on my Ubuntu Desktop 7.10 “CLAMP” (ColdFusion + LAMP) server. Here’s the general process I wanted in place:

1. Run the SVN repository directly on my local web server, blocking anonymous access, and checking out my projects via the secure shell protocol (svn+ssh://).

2. Check out said projects from the repository onto my primary machine where I develop using Eclipse and the Subclipse plug-in. (I also use the CFEclipse and Aptana plug-ins. Props on two excellent products! )

3. Commit the changes to the repository on my Web Server, which would then auto-publish the latest copy of my source to the web server’s web root.

4. Drink and be merry.

Having SVN automatically post the latest version of my source directly to the web root proved to be a bit of a challenge for me as I’m basically a newbie to both Linux and the process of setting up SVN. This effort and the bit of research involved is the focus of this post. This post also assumes you’re running a Linux variant.

Advice Disclaimer: Before I start, I would like to make note that this setup is for my home network and sandbox, not a professional production environment. I would not suggest this configuration for such an instance. Perhaps it could work for moving source from a development area to a staging/debug area as some have suggested, but I would rather not “auto-publish” directly to a customer-facing application. Unless such functionality was tightly controlled, in my estimation there seems too much opportunity for problems to arise. End disclaimer.

There are essentially two different ways to have SVN automatically post your content to your web root, and both of them center around using SVN’s built-in hooks, specifically the post-commit hook. For more info on SVN hooks go here, but in essence they allow you to run specific scripts at various key points in the repository usage process. The post-commit script, as I’m sure you guessed by the name, is ran after a commit has successfully completed, and can execute whatever command or string of commands you’d like. This script can be basically anything, but the most common examples I’ve listed as “Options” following the walk-through on the post-commit script itself.

Firstly, the post-commit (and other scripts) can be found in the “hooks” folder of your repository location in the form “post-commit.tmpl”.

Step 1. Copy post-commit.tmpl into the same directory as just “post-commit”.

Step 2. Open the file, commenting out any uncommented lines of code with a hash symbol (#), like for example, the line at the bottom of the current SVN installation post-commit that tries to run an email notification with every commit. Save your changes.

Step 3. Give the script the proper permissions. Permissions seem to be the number one area in which people have problems running their post-commit scripts. When your script runs, it will do so as the SVN user, not you. That SVN user will need create/delete rights in the web root. I handled this by creating a SVN user group in Ubuntu which includes the SVN user as well as the Apache user: www-data. You may prefer other solutions. Like, for example, writing and compiling a small C program, and then just giving that program the rights to do what you want.

Also, the script being run on post-commit will need SVN repository permissions, so if you are using the standard SVN protocol, you’ll need to ensure that the appropriate user is listed in the SVN passwd file (and that the passwd file is configured in the svnserve.conf file). If you are connecting via SSH, you could create an additional user account and limit its priviledges to just this process. For general help setting up SVN on Ubuntu (my operating system of choice), check out this excellent guide on Ubuntu.com.

Step 4. Choose either option A or option B.

Option A.

The SVN export. This is the cleanest, and arguably the most “correct” method. However, it is also the heaviest in terms of processor load, memory usage, and time (if your site/application is of any but the smallest of sizes). The SVN export is as it sounds - a complete export of your most current version of source files, images, everything you have in version control. Its primary function is for the distribution of source for production. To utilize this function, you would again edit the post-commit file, and directly under the hashbang (the first line of code denoted by the “#!” character combination), add this line:

/usr/bin/svn export svn://localhost/repository /var/www --username somesvnuser --password theirpassword

Note the full path preceding the svn command as there is no internal path variable within SVN. This is intentional so as to avoid assumption-based errors in file management. Also note that we are designating the user to be the specific svn user which we have given the correct repository permissions (based either on the SVN passwd file, or for SVN+SSH, the system user accounts).

Though the SVN export is obviously a necessary function in version control, it does not work for my purposes here as I’m looking to post short incremental changes to my code base, and am not interested in overwriting and re-exporting my entire project every time I commit a change.

Continue to step 5.

Option B.

The SVN update. This method involves treating the web root as another working copy previously checked out from your repository, which is continually and automatically updated upon each successful commit. The key difference between an update and a full export are that the update only re-fetches the files which have changed since the last update. For my usage, this is _much_ more efficient than the previous option, and in the end was the method I chose. Here’s how to go this route: Remember that post-commit file? Edit it again and add and save this line, instead of the export line in the previous option:

/usr/bin/svn update /var/www --username somesvnuser --password theirpassword

Again, note the full path on the SVN command, and the specific user designation.

Now, before this script can be successfully ran, the working copy needs to be checked out into the web root. Do so in a terminal window with:

$ svn co svn://localhost/repository /var/www --username somesvnuser ---password theirpassword

Also, there is a catch: Whenever you (or a script) checks out or updates a working copy, SVN automatically creates some hidden “.svn” folders and files in the root of your project, this case being your web root. You may not notice them but they’re there. And in so existing are a security risk as they may contain information you’re likely to want to hide from public access. However, if you’re running Apache, this is easily handled with a few lines added to the httpd.conf file disallowing the access to those .svn folders and files. This may minimally increase Apache’s workload, but will definitely provide much appreciated convenience to you:

<DirectoryMatch "^/.*/.svn/">
    Order deny,allow
    Deny from all
</DirectoryMatch>

After you’ve added and saved this line, restart Apache:

$ /etc/init.d/apache2 restart

Continue to step 5.

Step 5. Make the post-commit script an executable application in a terminal window:

$ chmod +x post-commit

Step 6. If you’re using Eclipse with the Subclipse plug-in like I am, and you try to commit a change to the repository without your script having everything it needs to perform its task (like I did), Eclipse may hang on you, and you will get no feedback on the error. So, I suggest running the script itself in the terminal window first to get that much needed feedback. Run it without sudo btw. The script must have the permissions it needs to run on its own.

$ /your/repository/hooks/post-commit

If all goes well, you’re on your way. Any problems, please see the note above about permissions, as this is the most common issue in regard to running SVN scripts. Go browse the web root to ensure it contains the latest version of your project.

Step 7. Open Eclipse, make a change in the code, and try to commit. If it doesn’t hang, you’re good to go. If it does, go back to the terminal for feedback and re-examine your script and its permissions. Good luck!

Step 8. Say “Woo-hoo!”.

Supplemental: An interesting auto-publish option: Rsync. In researching this topic, I came across what I thought was an innovative take on the auto-publishing topic. Lincolnloop.com posts a process whereby the web server’s working copy is actually stored outside of the web root, and the post-commit script runs a shell command that rsync’s the web server’s working copy with another one in the web root, only it uses a separate text file containing names of folders and files that should not be transferred, cleaning resolving the issue of publishing sensitive information.

And that’s about all I have to say about that. Hope this helps someone. Peace.

A friend was asking how to set up Compiz and the desktop cube rotation effects on the latest version of Ubuntu, so here’s the quick rundown.

1. Make sure your graphics card supports direct rendering with OpenGL. Without it, you can’t run Compiz. In the terminal:

$ glxinfo | grep rendering

The result should be:

direct rendering: Yes

If its not, you’ll need to either install OpenGL or change your graphics card.

2. On the Panel, click Applications > Add/Remove.

3. Search for ‘Compiz’.

4. Check the box next to ‘Advanced Desktop Effects Settings’ . Click ‘Apply Changes’ to install.

5. Once installed, in the Panel, click System > Preferences > Advanced Desktop Effects Settings.

6. In General Options > Desktop Size, use these settings:

Horizontal Virtual Size: 4
Vertical Virtual Size: 1
Number of Desktops: 1

7. Click Back and go to the Desktop options. Check the boxes for ‘Desktop Cube’ and ‘Rotate Cube’.

That’s it. A couple things that make it look even better:

8. Under Effects, check the box ‘Cube Reflection’.

9. Under Utility, check the box for ‘Cube Caps’.

To see the cube rotation effect, press CTRL+ALT while click and dragging with your mouse in any direction. Have fun!

This post is a semi-tutorial for the installation and configuration of Adobe Coldfusion 8 on an Ubuntu 7.10 Gutsy Gibbon desktop edition LAMP server running apache2, php5, mysql5, and phpmyadmin. I say semi-tutorial cuz this post assumes your set up is like mine as laid out in my previous post, “Tutorial: LAMP Server On Ubuntu 7.10 Desktop“. If your setup differs from mine, this post may not work for you. Oh also, I’m a TOTAL LINUX NEWBIE so thats my upfront disclaimer. This is just what worked for me. At the end of this post, you’ll find links to the sites I found helpful in this process. To the authors of said links, thank you for your help. It was awesome of you to post your experiences, and with them I found it easier to wade through this process. I hope others find my post as helpful. So here we go (this is long).

1. Go to www.adobe.com/go/trycoldfusion. To download cf8, you’ll need an adobe account, but its free and takes one minute to register.

2. The file you want is obviously the linux one: Coldfusion-8-lin.bin. Download it to your machine.

3. Notice the checksum for the file is listed there on the download page. Once its finished downloading, run md5sum in a terminal:

$ cd downloaddirectory
$ md5sum Coldfusion-8-lin.bin

and compare the result against the one posted on the Adobe download page. At the time of this posting, the checksum is:

ce9bb2af5cbf908cbd4403ce506335ef

If the checksums do not match, it means the file is bad, so delete the file and download it again.

4. By default, the binary does not have executable permissions, so if you try to run it, either nothing will happen or it will try to open in a text editor lol. To see what I’m referring to, while still in the terminal in your download directory, enter this:

$ ls -l

and you will see a line preceding the Coldfusion-8-lin.bin file that looks like:

-rw-r--r--

These are the file’s permissions, which show as only for reading and writing, but it needs x’s, so run this:

$ chmod +x Coldfusion-8-lin.bin

and it is now an executable application. To see this via command line, run ls -l again, you’ll see:

-rwxr-xr-x

5. Now run the binary, but you’ll need to run it as sudo, otherwise you’ll get part way into the installation and it will tell you that it requires root privileges to continue:

$ sudo ./Coldfusion-8-lin.bin

The next several steps will walk you through the installation process. Note that at any time you can go back to a previous step in the installation process by typing ‘back’. You may also type ‘quit’ to quit, but quitters never … something something (i stopped listening and missed the rest of the maxim).

6. Language? type ‘1′ for ‘english’.

7. Press enter through all the legal prompts, reading each page line by line of course ;).

8. Install type? For me this will be a developer machine on my home network so number ‘3′, I choose you.

9. Server configuration? I don’t need anything fancy so i type ‘1′ for the standard server configuration. Your mileage may vary.

10. Is there already a server configuration of coldfusion 8 installed? ‘2′ for no.

11. I disabled the documentation but left everything else cuz i might use it. One could make the argument that disabling the documentation is a good idea for security reasons, but like I said before, this machine is on my home network so it doesn’t really matter as much. I just don’t need the documentation. There’s plenty of good sites for that (maybe someday mine will be one of them).

12. Installation folder? I went with the default: /opt/coldfusion8

13. More legal stuff if you are installing Adobe LiveCycle Data Services. I might use Adobe AIR at some point so I went ahead and installed that.

14. Serial number? Left it blank for Developer Edition.

15. Earlier version? ‘2′ for no.

16. Add Web Server Configuration? Here, I diverge from most of the other tutorials I found on this subject. The majority of people seem to be skipping the Apache configuration here, finishing the install, then copying various connector files and restarting various services after the installation is completed. This may have been something necessary for Coldfusion 7. If so, I can’t speak to that. But instead of doing all that, I went the route of adding the configuration for Apache during the installation. So choose the number for ‘Add Web Server Configuration’, then select the number for ‘Apache’ at the next prompt.

17. Key file locations the installation asks for next are:

Apache configuration file: /etc/apache2
Apache binary file: /usr/sbin/apache2
Apache control file: /usr/sbin/apache2ctl

18. Once this is done, you’ll know cuz you’ll see the option to edit the Apache configuration you just added. But we don’t want to do that so type ‘4′ instead to continue the installation.

19. For the web root and Coldfusion Administrator location, I went the default Apache web root on my machine: /var/www

20. Runtime user? Whatever user you want.

21. Password? That user’s password.

22. RDS enabled? I said yes for the moment even though my plan is to set up Subversion at some point in the near future.

23. RDS password? um, macaroni.

24. Review the installation configuration, then press enter to make it all happen. Mmm, feels good. On my machine this last part (of the first part? o_0 ) took less than five minutes. Once its done, you’ll get this:

You have successfully completed
the first step in installing Adobe Coldfusion 8.
To continue with your installation,
go to /opt/coldfusion8/bin and type
"./coldfusion start" to start your server.
Once the server is started,
log in to the configuration wizard at
http://[machinename]/CFIDE/administrator/index.cfm

25. So do that, but as sudo:

$ cd /opt/coldfusion8/bin
$ sudo ./coldfusion start

Coldfusion should start in a few seconds then tell you that it will be writing its logs to /opt/coldfusion8/logs/cfserver.log

26. Now take a breath.

27. Open your preferred browser *cough* firefox *cough* and navigate to http://localhost/CFIDE/administrator/index.cfm. Once you sign in using the username and password you just provided at setup, it should automatically finish its own configuration, then take you to the Coldfusion Administrator’s main page.

28. So lets test Coldfusion by creating and saving a .cfm page that we’ll navigate to in a moment. Create and open the file:

$ gksudo gedit /var/www/index2.cfm

Once the text editor appears, add the below lines and save:

<cfset request.greeting = "hello from coldfusion" />
<cfoutput>#request.greeting#</cfoutput>

29. Now navigate to http://localhost/index2.cfm. Does Coldfusion greet you? I hope so. It did me. I feel all warm and fuzzy-like.

30. Now lets make sure we can connect to the MySQL service. Go back to the Coldfusion Administrator, click the Data Sources link in the left pane, then in the form on the right add the name of one of your MySQL databases, select MySQL (4/5) as your Driver (assuming thats the version you’re running. it is if you followed my lamp server tutorial from yesterday) and click Add.

On the next screen enter the Database name again, set the Server as 127.0.0.1 since MySQL is running on the same machine as Coldfusion, and enter the username and password for your MySQL user account. Click Submit. It should verify the connection for you upon submitting where at the top of the main page you should see:

* data source updated succesfully.

31. So now that we’ve got a data source set up in the Coldfusion Administrator, lets go back and edit our index2.cfm:

$ gksudo gedit /var/www/index2.cfm

adding a query and query output to make sure we can connect to MySQL. Please note that the database name, table name, and field names will change according to your own setup.

<cfquery name="fetch" datasource="testdatabase">
    SELECT *
    FROM thetable
</cfquery>

<cfoutput query="fetch">
    <br/>#fetch.fieldname# - #fetch.otherfieldname#
</cfoutput>

32. Save your changes, and refresh your browser. You should now see the output of your specific table. If so, congratulations, you are now successfully running Coldfusion 8 with Apache 2, and MySQL 5 on Ubuntu 7.10 desktop edition. Think of all the fun acronyms you can refer to your machine as now: CAMU, CAML, MACL, the list goes on.

Extra credit: If you’re tuning in after following my LAMP server tutorial from yesterday, you may want to navigate back to http://localhost/ and notice that the index.php file we created yesterday still echoes “hello there” indicating that PHP is still parsing as it should. The Coldfusion installation and Apache configuration did not break PHP. They are both sharing Apache and running out of the same directory. This is exactly what I wanted as like I said, this is a development machine, wherein I will be writing various things in either PHP or Coldfusion. Maybe both? (Maybe not). The other benefit for Coldfusion of simultaneously running a PHP setup on the same server is that you can use the phpMyAdmin to administer your MySQL needs. And also, there’s one more letter to slap onto your Acronym. I think I’m going to call this setup a CLAMP server. Yes, CLAMP it is. Shiny. Good luck to all and I hope this tutorial helps someone.

Credits and references (thanks again to the authors):

CF8 on Ubuntu Feisty Fawn
CFMX7 on Ubuntu Feisty Fawn
CFMX7.02 on Ubuntu Edgy Eft