« Lighttpd, Rails and Tracks • The road to Tracks 1.1 »
Feb 2005 12

Making Tracks publicly accessible

Posted by bsag

Updated to include corrections from commenters 19/02/2005

A couple of people have asked on the wiki how you set up Tracks so that you can access it from other computers. The answer depends a little on how you have your computer networked, and on the platform you are running on.

One thing you can’t do, as far as I know, is use WEBrick to access Tracks remotely. WEBrick runs on localhost (127.0.0.1) by default and so you can only access it from the computer on which it’s running, but it is possible to use it on interfaces other than localhost (see comment 2 below for instructions). Otherwise, you’ll need to run a full web server like Apache or lighttpd. Since Apache doesn’t run on Windows (yet), you Windows folks are not going to get much out of this article, as I’ll be describing the procedure using Apache. However, if anyone out there has experience of setting up a Rails-compatible server on Windows, send me a note and I’ll document it here. Apache does run on Windows, and there’s a nice bundle available called XAMPP which will give you Apache, MySQL, PHP and lots of other great stuff in one easy to install package.

Setting up Apache isn’t something I’ll cover in detail. There’s plenty of documentation on the Apache site, and many *nix based distributions come with it pre-installed. If you’re on MacOS X, it’s very easy. Just go to System Preferences > Sharing and check the box next to ‘Personal Web Sharing’. After a few seconds, you’ll get confirmation of the URL from which you can access your sites at the bottom of the window. Try using it to make sure that you get the default index.html welcome message, showing that Apache is working.

Now the tricky part is the IP address of your machine. If you’re running it on a machine which has a stable domain name, there’s no problem; you just enter http://your.domain.tld/ as the first part of the URL. However, if like most people you’re using a computer on a cable or ADSL modem, you probably just have an IP address, which is likely to be assigned dynamically, and will therefore change over time. Worse, you might be using a router or an Airport Base Station which is distributing local IP addresses (like 10.0.x.x or 192.168.x.x) to the machines on the local network. That means that it’s going to be difficult to access from outside your network. In the case of machines sitting behind a router, I think it is possible to tunnel connections through to local IP addresses (so that a call to the external IP gets routed to an internal IP), but it’s complicated and can compromise the security of your network. You’d probably be better off thinking about getting your Tracks installation hosted by a hosting company in that case.

If you have a dynamic IP which isn’t a local one, you can use DynDNS to help you track the changing IP address so that you can always connect to your computer remotely. I haven’t tried it myself, but I’ve heard that it works quite well.

If you have a static IP, there shouldn’t be any problems. First, you need to make sure that your Apache config file (/etc/httpd/httpd.conf on MacOS X) is set up to handle .cgi files. Somewhere in the config file, make sure that you have this line:

AddHandler cgi-script .cgi

You’ll probably find that the line is in there but commented out with #; just remove the #, save the file and restart Apache, and you should be fine. Then you need to make a few other changes to httpd.conf and .htaccess (in tracks/public) to make things run smoothly. There’s a very clear explanation here. The crucial step is making sure that you make an alias which points to the public directory within the tracks directory. You might find it easier to use what’s called a VHost installation, in which case follow the instructions at the bottom of this page.

It’s worth checking tracks/log/apache.log if you encounter errors to try to debug it. One last thing: by default, the setup runs in ‘development’ mode, which means that you don’t have to restart the server to see changes as a result of editing the source code. This is fine for development, but it’s a bit slower. Once you’ve got things set up, you probably want to change a line in tracks/config/environment.rb. Change line 2 in that file from:

RAILS_ENV  = ENV['RAILS_ENV'] || 'development'

to

RAILS_ENV  = ENV['RAILS_ENV'] || 'production'

I’ll probably make this the default in future releases.

Well, I hope that this brief explanation helps a little. I would say that running your own externally accessible server isn’t trivial, and you do have to worry about the security of your machine, and of course make sure that it’s running all the time. For many people (particularly those like me who are behind a router), it makes much more sense to find a good web host who will take care of all those worries for you. I host my own working Tracks installation on TextDrive, and I recommend them unreservedly.

Filed under: tips

12 Comments

Picture of Daniel Von FangeDaniel Von Fange
Sat, 12 Feb 2005 @ 19:16

Random note: Apache does run under windows.

Picture of ryan nelsonryan nelson
Sun, 13 Feb 2005 @ 03:31

Actually, it’s pretty easy to get WEBrick running on non-localhost…

for Tracks, edit

/your/directory/tracks/script/server

...on around line 8, it says “IP”… change 127.0.0.1 to “0.0.0.0”, to mean “all interfaces”, or to the IP address you want to listen on.  Worked for me.

running “server -h” also showed a ”-b” option that apparently lets you specify what ip address to listen on from the startup command.

Picture of bsagbsag
Sun, 13 Feb 2005 @ 18:15

Daniel Von Fange: Really? I didn’t see any mention of a binary on the Apache site. Can you compile it from source? If you could point me to somewhere that explains the process, I’ll include it here. Thanks for pointing it out!

ryan nelson: Cool! Thanks for the instructions. Is WEBrick fairly stable and secure when used in this way?

Picture of rhwrhw
Tue, 15 Feb 2005 @ 03:52

Okay, so I managed to get this going… I have a server already running apache, and got it to work at

http://servername/rails/todo/list etc.

Two problems:  The formatting seems mysteriously gone!  Ie, all of the content is there, but it looks like the css file or whatever is setting the style is missing.  When I look at the same file at

http://127.0.0.1:3000/todo/list

it’s as pretty as ever.  Ideas?

Second problem:  I can go directly to

http://servername/rails/todo/list

without logging in.  I was able to password protect access to the whole directly, so I have to enter a separate password to get into at all, so this isn’t an immediate issue, but it seemed a bit wierd.

Related issue—it seems that one can always just create an arbirary number of new users with access to the same database, so that there is actually no access control…

Thanks!

Picture of bsagbsag
Wed, 16 Feb 2005 @ 08:43

rhw: Sorry to take so long to respond… I’m fairly sure that both problems are caused by not pointing Apache at the correct document root (i.e. public within the tracks directory. You should just have http://servername/todo/list, which is why the CSS file isn’t loading properly, as I’ve linked to it relative to the root (i.e. /stylesheets/standard.css which is relative to public—I should probably make this less fragile, but that’s another issue…)

You probably need a virtual host container in your httpd.conf which points to public. Something like:

[VirtualHost your server ip]

DocumentRoot /pathto/tracks/public/

ErrorLog /pathto/tracks/log/apache.log

ServerName tracks

[Directory /pathto/tracks/public/]

Options ExecCGI FollowSymLinks

AddHandler cgi-script .cgi

AddHandler fastcgi-script .fcgi

AllowOverride all

Order allow,deny

Allow from all

[/Directory]

[/VirtualHost]


</pre>

NB. Square backets should be substituted for angle brackets!

If you don’t feel comfortable doing that, then you might be able to do something with the .htaccess file by putting the subdirectory into the RewriteBase line:

RewriteBase /rails/dispatch.cgi

I can’t test this out at the moment, but I think it might work. You will then have to change the URLs for the stylesheet and javascripts so that they are the full and correct URLs.

Oh, and the issue with signup.rhtml is a known one. The password protection is just a minimal thing to make it easier for people to restrict access if they have it on a public server, but it’s not a full multi user setup (as you say, all users access the same database). Also, you’ll probably want to delete signup.rhtml (or rename it), and comment out the def signup method in login_controller after you’ve created all the users you want, or anyone can come and create a user on your system. I hope to make this a bit smoother in future.

Picture of bsagbsag
Wed, 16 Feb 2005 @ 08:48

Aarg. I don’t like that way Textpattern munges code in comments—the Virtualhost thing got totally messed up. Anyway, the basic idea is that you need to put the full path to public in the document root line. I’ll try to put something up on the wiki later to make it clearer.

Picture of rhwrhw
Wed, 16 Feb 2005 @ 20:30

From the page you linked to originally, it looked like it was possible to do either a virtual host or non-virutal host install, so I went with the latter (as described at

here.

This means that http://sitename/ still ends up being what it was orginally (which I couldn’t figure out with the vhost install, but maybe I was just confused…) at http://sitename/rails/

I currently get the “Congratulations, you’ve put ruby on rails.” screen

And I had already changed that line in .htaccess

Okay… I just found the files to change.  I changed the lines specifying the stylesheets in layouts/ to have the full path, and now it looks much better.

Still one remaining visual thing, the two symbols below each element (for edit and delete) are still missing and I couldn’t find the obvious thing to change.  Can you point me to where these are specified?

With regard to the access control—That’s fine, I can delete signup—but how to I restrict access to todo/list to users who have signed in?  Currently I can go there directly.  Thanks!

Picture of bsagbsag
Wed, 16 Feb 2005 @ 21:52

rhw: The variables which hold the paths to the delete and edit images are in tracks/app/controllers/application.rb. Did you try putting the prefix ‘rails’ in the RewriteBase line in .htacess like this?

RewriteBase /rails/dispatch.cgi

That might work for the login issue, but I’m not sure. Otherwise, you could try adding a RewriteRule for the login pages, so that server/rails/login/login is rewritten as server/login/login. Again, I’m not sure if that will work. .htaccess files confuse me wink If anyone else has any suggestions, feel free to chip in. If you can get VHosts working (and I agree, it isn’t trvial) they are much more reliable because you don’t have to worry about these paths issues.

Picture of textdrive_newbietextdrive_newbie
Wed, 16 Feb 2005 @ 21:58

What if we don’t have control over httpd.conf and can’t bounce the server?  I’ve got Tracks unzipped in my TextDrive account at ~/public_html/tracks—how do I tell Apache that tracks.example.com should dispatch everything to ~/public_html/tracks/public/dispatch.(f)cgi, without having access to httpd.conf?

Thanks in advance for any advice.

Picture of rhwrhw
Wed, 16 Feb 2005 @ 23:44

Okay, changing the paths for the images worked, thanks.

Yes, I had already put that prefix in .htaccess, and no luck.

Anyways, I will ignore these issues for now, since I don’t quite understand these Rewrite rules and was able to just add a separate password for the area.

Picture of schilkeschilke
Thu, 17 Feb 2005 @ 23:51

> I didn’t see any mention of a

> binary on the Apache site

AFAIR there should be some links at least. Apache runs fine on my w2k system for more than 4 yrs now (and also did on windows 95 before).

The apache group suggests to use apache on windows for experimental purposes only – but AFAIK that’s more from the point of security…

> Can you compile it from source?

yes but even better: there are lots of installers available – for absolutely easy life I personally would recommend XAMPP (initially Apache, MySQL, PHP, Perl – but actually far more…) – available for users from both worlds Linux and Windows.

(That’s something easy to solve – the more difficult for me as a win user is to get through all the unsorted information about ruby, rails and tracks – I’ll be back with questions for sure when I have completed my lessons *g*)

Tracks took my attention while discovering GTD and researching software that could do a better job than all this ugly windows (and mac os…) stuff with its proprietary data formats and missing cross OS compatibility.

+ I wasn’t able to avoid some kind of suppressed noise when discovering that you integrated taskspace wink

Picture of bsagbsag
Sat, 19 Feb 2005 @ 11:31

textdrive_newbie: First, I wouldn’t keep tracks in your public_html because it potentially exposes your database config to the world. Move it to a location in your home directory like ~/sites/tracks. Then there are two possible ways to go. One is detailed here. That will only work if you have mod_vd enabled (I think it is enabled by default). Make sure that you use the full paths when making the symlink. The other way is to put in a ticket to support asking if they can set you up with a subdomain like tracks.yourdomain.com which points to ~/sites/tracks/public. However, I know that they’ve got a bit of a ticket backlog at the moment because of the action of comment spammers, so do be patient with them.

schilke: Thanks so much for the link! I’ve added it to the updated article. At some point when I get time (ha!), I’ll try to re-organise the wiki and this site to make it easier to find information. I know it’s a bit of a mess right now.
-----

Page 1 of 1 pages

Name:

Email (not shown on page):

Location (optional):

URL:

Remember my personal information

Notify me of follow-up comments?

Please enter the word you see in the image below: