Categories
Technology Weblogging

Web Server 101 for Ghost

update

I disabled the Ghost weblog because I don’t want to maintain two different weblogging software applications, and Drupal is my primary weblogging software.

The configuration listed here was sound and reliable for well over six months.

—-

Recently I installed Ghost on my server. Ghost is a Node.js weblogging tool that you can host yourself or have another organization host for you.

It’s not a complicated application to install. There’s even a How to Install Ghost web site, with handy instructions for installing Ghost in various environments.

Take my environment, which is Ubuntu Linux hosted on a Linode VPS. You could order a brand new VPS, but chances are your server is already set up, and you’re just looking to install Ghost.

You have to install Node.js first, of course. Then you download the Ghost source code, and install the application, using the following steps:

mkdir -p /var/www/
cd /var/www/
wget -O ghost.zip https://ghost.org/zip/ghost-latest.zip
unzip -d ghost ghost.zip
cd ghost
npm install --production
cp config.example.js config.js

Next you edit the configuration file, changing the default IP and port values to ones that allow people to access your new Ghost weblog:

host: '[your Linode public IP]',
port: '80'

Lastly, start that puppy up:

npm start --production

 

Now, you’re all set, good to go, blasting full ahead on all cylinders…

…right for that wall that is about to hit you, hard, in the face.

A reality check on that environment

Let’s back this sweet scenario up to, oh, step 1: your environment.

True, you could be installing Ghost in a brand new environment with nothing else installed. Chances are, though, you’re installing Ghost in an existing system that is already running a web server. Chances are also good the web server you’re running is Apache, which is running on port 80, the same as your new Ghost installation.

So what happens when you try to run Ghost on the same port you’re using with Apache?

If you try to start the application withnpm, you’ll get an almost immediate error response signaling that an unhandled error event has occurred, and to contact the Ghost author. If you try to start the Ghost application via another tool, such asforever, you may not see an immediate problem at the command line, but if you access the Ghost site via a browser, you’ll get a 503 “Service Temporarily Unavailable Error”.

You’re getting an error because you can’t run both web services at the same port. You then have two options to run your Ghost weblog. Option 1 is to shut down Apache or install Ghost on a machine where Apache is not installed, and then you can run Ghost at port 80. The second option is to find a way to get Apache (or other web server) and Ghost to co-exist.

Let’s take a look at that first option: running Ghost in a stand alone environment at port 80.

Running Ghost in a Stand Alone Environment

If you don’t have Apache installed, or no other web service running at port 80, you could follow the steps I gave earlier, and you might expect Ghost to start. You might, but you could be in for a surprise.

If you try to start Ghost with a line such as the following:

npm start --production

You’ll most likely get an error. If you try to start Ghost up directly, using Node, you’ll find that the error is EACCES, “permission denied”. The reason why is that port numbers below 1024 are what is known as privileged ports, requiring root permission. When you tried to start up Ghost as a normal user, you lacked the permissions to start the service.

You might be tempted to use sudo to start the Ghost application:

sudo npm start --production

And yes, Ghost should be alive and well and running on port 80. But this command just triggered a visceral response from security minded web developers, because now Ghost (which is currently in beta development and unlikely to be hardened) is now running with root privileges. Not even Apache, hardy veteran of the web wars that it is, responds to web requests with processes running with root privileges.

Behind the scenes, when you start Apache as root, it spawns a worker thread that handles a web request. This worker thread runs with the privileges of a non-root user, typicallywww-data. If you’re running a Linux server, you can issue the following command and see that one Apache process is running as root, while other child processes are running as the Apache user (www-data).

ps -ef | grep apache

Other web servers, such as Nginx, operate under the same principle.

So, what do you do if you want to run Ghost at port 80?

Well, you can start Ghost up on port 2368 (the default port) and then go where most folks don’t dare to go by tweaking iptables to redirect port 80 to port 2368, or something similar. Bottom line, though, is you just don’t run Ghost as a stand alone web server/application, period.

In an issue thread at github the architects behind Ghost have stated that they see Ghost as an application, not web server. As such, they don’t recommend that people run it directly, as a web server. Instead, they recommend using Ngnix or Apache as the web server, and then reverse proxy to Ghost. Both Nginx and Apache are hardened from a security perspective, and both do a better job providing other services the Ghost folks won’t be providing.

The Ghost folk recommend using Ngnix,and you can use Ngnix as reverse proxy for both Apache and Ghost if you’re hosting Apache applications. For myself, I don’t need the extra level of complexity or the performance boost that Ngnix can provide for static files, so I decided to go with Apache as reverse proxy. I’ll cover the steps I took, but first, let’s return to that running instance of Ghost.

Running Ghost Forever

My Ghost weblog is currently running at Shelley’s Toy Box. Shelley’s Toy Box is my hack and trash domain where I’ll try new things. I thought about getting a separate VPS for it, but can’t really afford it at this time, so I’m making do with a virtual host for now.

Ghost is running at port 2368, the default. Yes, this means you could also access the Ghost weblog at http://burningbird.net:2368, and completely bypass Apache doing so, but we’ll get to that in a little bit. For now, I have started Ghost usingforever:

forever start  -l forever.log -o out.log -e err.log index.js

If Ghost crashes and burns,forevershould start it back up. However, if the server, itself, gets re-booted, Ghost isn’t restarted. Luckily, since I’m running Ubuntu, I can use Ubuntu’s Upstart to re-start Ghost withforever.

I created a simple file named ghost.conf in /etc/init, with the following text:

# /etc/init/ghost.conf
description "Ghost"

start on (local-filesystems)
stop on shutdown

setuid your-userid
setgid your-grpid

script
    export HOME="path-to-ghost"
    cd path-to-ghost
    exec /usr/local/bin/forever -a -l path-to-logfiles/forever.log --sourceDir path-to-ghost index.js

end script

Now when my system re-boots, the Ghost weblog restarts. And it restarts as my non-privileged user thanks to thesetuidandsetgid.

Using Apache as reverse proxy

Apache has a good description of forward and reverse proxies, but simply stated, a reverse proxy allows web users to access both Apache and Ghost in our servers, seemingly on the same port 80.

I’ve not used Apache as a reverse proxy before, so this is new territory for me. After going through variations that left my server crawling on its knees, I found a routine that seems to work well, or at least, not work badly.

First, I had to enable bothmod_proxyandmod_proxy_http:

sudo a2enmod proxy
sudo a2enmod proxy_http

I’m not turning on forward proxying, so didn’t uncomment any of the lines within the proxy.conf file in Apache’s mods-available subdirectory.

I already have several virtual hosts configured, so it was a simple matter of creating another for Shelley’s Toy Box. In the settings, I turnProxyRequestsoff, just because I’m paranoid (it shouldn’t be on), and then add myProxyPassandProxyPassReversesettings:

<VirtualHost ipaddress:80>
    ServerAdmin shelleyp@burningbird.net
    ServerName shelleystoybox.com

    ErrorLog path-to-logs/error.log
    CustomLog path-to-logs/access.log combined

    ProxyRequests off

    <Location />
            ProxyPass http://ipaddress:2368/
            ProxyPassReverse http://ipaddress:2368/
    </Location>
</VirtualHost>

I specify my ip address for the virtual host, because I have used two IP addresses in the same server in the past, and may again in the future.

Once I enable the site and reload Apache, I’m good to go.

a2ensite shelleystoybox.com
service apache2 reload

The only issue left is the fact that people can also access the Ghost weblog directly using other domains and the 2368 port (i.e. http://burningbird.net:2368). Since I’m running Ubuntu and am using iptables, I add the following rule:

iptables -A input -i eth0 -p tcp --dport 2368 -j DROP

This prevents direct access of port 2368, while still allowing Apache to proxy requests to the port. I maintain it between boots using iptables-persistent. However, it is modifying iptables, so you have to balance modifying iptables against people accessing the site via another site domain and direct access of the port.

Ghost as Weblog

Ghost is an important addition to the Node.js community because weblogging software appeals to a broad range of interests and experience levels. That latter is particularly important because we’re now seeing with Ghost the issues people face when running a Node.js web application, particularly in a world where Apache is so ubiquitous. Ghost is a learning experience, and not just for the Ghost developers or users.

Having said that, at this time I don’t recommend Ghost for people who are only looking for a weblogging tool. Ghost is still in the early stages of development and lacks much of the basic functionality we’ve come to associate with weblogging software. However, if you’re interested in Node.js development and are looking to get in on the ground floor of a weblogging application (before all the complex bells and whistles are added), Ghost can be a fun and educational alternative to Drupal or WordPress.

Whatever you do, though, don’t run Ghost with root privileges. It’s no fun to get your butt bitten off.

Categories
Books JavaScript

JavaScript, not a ‘real language’

Simon St. Laurent and I have been discussing that exciting upcoming conference, DHTMLConf.

Party like golden sparkles following the mouse cursor is cool again!

If you’re going to JSFest, how can you not go to DHTMLConf? This is a conference celebrating a time when all of the technologies we take so seriously now, were fun!

Simon is going, and is taking along a copy of his old Dynamic HTML book he managed to find. That made me dig around online for anything on my old books, including my Dynamic HTML book (1998), as well as my earlier (1996) JavaScript How-To.

I had to laugh when I saw the marketing blurb attached to the JavaScript How-To book at Amazon:

JavaScript is the ultimate in web eye-candy. It is not a real programming language such as Java, and it isn’t really essential for web site development, but it sure is a lot of fun for tinkerers.

Categories
HTML5 Standards XHTML/HTML

Letting go of the passion can be a good thing

For years I battled with members of the WhatWG and others over elements and attributes in HTML. Months, we’d go back and forth about the usefulness of the details element, or in passionate defense of the beleaguered longdesc.

I wrote hundreds of pages in defense of RDF over Microdata; the virtues of SVG in addition to Canvas; and what the hell does it really mean when we talk about web accessibility?

But I lost a lot of the interest in fighting over markup about the same time it seemed most of us became burned out on the never ending debates. I dived into the exciting possibilities of Node.js, while also exploring, more deeply, the world outside of technology. My interests were split between JavaScript and circus elephants, web technologies and sustainable food systems. Along the way, I lost the passion I felt about finding the one true way for forward movement of the web. The technologies are still important to me, yes, but I had lost the pounding insistence of rightness I felt about individual components, and even entire systems. And once the noise in my own head seemed to quiet, I could hear others—their passion, their sense of what’s right.

The real epiphany came when I was reviewing Kurt Cagle’s upcoming book, “HTML5 Graphics with SVG and CSS3”. In the book, Kurt has a chapter on HTML5 where he demonstrated an unconventional HTML web page that blasted apart all I thought I knew about what is a proper web page. It did so because as chaotic seeming as it is, it’s still a valid web page. I couldn’t see the validity of the page, though, because I had been rigidly holding on to a perspective about HTML that really was over, done with, gone.

Never to return.

I had been seeing the web through XHTML colored glasses. In the past, I had been trying to map the precision and order that exemplifies XHTML with the loose but more nuanced flow that is HTML5, and there really is no philosophical compatibility between the two. Kurt’s example forced me to see HTML5 it all its raw essence, for lack of a better word. And what blows me away is realizing that browser companies, as well as many web developers, designers, and folks interested in accessibility prefer HTML5, even at its messiest, over the ordered world of XHTML. They do so not because they embrace chaos, but because they saw something in the future of HTML I didn’t.

I don’t seek a second epiphany that would allow me to view the web through their eyes. My passions have gone elsewhere. In the world of technology, my focus now is on JavaScript and Node, and all the new adventures that seem to be exploding about both. HTML is complimentary to my interests, but not central. It is now nothing more than a tool; essential to developing with JavaScript and in ensuring accessibility of my published words, yes, but still just a tool.

HTML is a passion for others, though, and I respect that passion because I respect them. If the people I respect assure me, knowledgeably and with conviction, that using certain elements in a certain way will ensure my web pages are accessible for all across a variety of mediums, I will pay attention. When next I take on the grand redesign of my web sites (typically an itch I must scratch on average every three to four years), I will modify my pages accordingly. I do so not because I believe in the technology, but because I believe in the people.

Categories
Documents Political Web

Eclectically yours #1

Once Google Reader bit the dust I made my move to Feedly, and I’m quite happy with the change. I especially like the search feature incorporated in the Pro version of Feedly. Since I follow several court cases, and the only “notification” the federal PACER system provides is an RSS feed of every court docket entry, being able to search on key terms ensures I don’t miss a filing.

Speaking of Feedly…

Food Safety News reports that a coalition of consumer groups interested in food safety are gunning for two amendments to the House Farm Bill. The one I’m most interested in is the infamous Steve King amendment titled the “Protect Interstate Commerce Act”. This amendment would start a race for the bottom when it comes to animal welfare laws, food quality, and food safety laws. The King amendment would basically allow one state’s agricultural law to override another, more restrictive law. In other words, King wants to force Iowa’s crappy agricultural laws on to the rest of the country.

It’s one of the worst amendments attached to any bill in more modern times, from a man who is infamous for bad legislation focused on supporting his big agribusiness contributors and little else. What’s surprising is how many Tea Party Congressional members voted for the amendment, as these supposedly “states rights” types are voting for a bill that undermines states rights.

Remember pink slime? There’s a hearing in December related to a motion to dismiss by ABC News and the other defendants. The story contains a link to a copy of the motion to dismiss, but I couldn’t find one for the memorandum, which is the interesting part. However, I’m assuming it’s similar (if not identical) to the one filed with a similar motion in the federal court. Food Liability Law Blog provided a copy of this document. BPI’s response at the time was to refer to its memorandum in support of its motion to remand back to the South Dakota state court.

The pink slime case started in South Dakota, moved to the federal court system, and then back to the state court. I hate it when a court case gets moved back to a state court, because most states don’t have an easily accessible document system. PACER is pricey, but at least you can easily access most documents.

Speaking of documents, California’s effort to get a case management system online has failed, and now the tech companies are circling, like vultures over a particularly juicy carcass, over new contracts to build a system.

They are scrambling for a mother lode of multimillion-dollar contracts for software and licensing, vast additional sums for upkeep, and the right to set up a toll booth on Court Road for 38 million people.

I’m all for private contracting of court systems, though I think the states would do better to share expertise with each other when it comes to implementation. My biggest concern, though, is system privatization: hiring companies to run the systems, as well as develop them.

Privatization of court systems is, in my opinion, wrong, wrong, wrong. Not only does privatization add to the expense of an already outrageously expensive legal system, they inhibit easy access to the documents. Instead of paying a fee such as ten cents a document page, like you do with PACER, it may cost you several dollars to access even the smallest document.

Still, some court document access is better than nothing, which is what you have with most state courts.

Categories
Documents Web

Harvard Business School: it will cost you to link to us

Discovered via Facebook, Harvard Business School’s extraordinarily parsimonious attempts to milk every last penny out of its material:

No one ever charges people for the act of curating and directing attention. That is our job. It is our mantra. But that is precisely what HBSP are doing. To be sure, HBR looks like any other magazine and is already paid for under an institutional license by the UofT library. What HBSP are charging for are the links to those articles made by academics in the ordinary course of teaching. While our Dean was clear that he wanted us to continue to treat ideas as ideas and give the best to our students, he also wanted us now to be aware that it was costing money each time we did so. I don’t know how much it costs but my guess is that it is $5 or so per article per student. So if I have a class of 40 students and in the process of being thorough, add 10 HBR articles to my reading list or class webpage or, if the students do the same on bulletin boards for the class, we have to pay $2,000 for the privilege. I want to adhere to norms but that is enough to cause me to think twice.

Note, this isn’t direct access to the article content, this is just linking to, or citing the article.

I guess Harvard must be hard up for cash.