the Path to a Working Web Server
Completely at a loss for what to post, I was afraid that my fate would be crawling old threads--something along the lines of a Google search: ideas for my first blog post. Then I started setting up the server, and it turns out that that in and of itself is worth an entire post (possibly multiple posts, but I'd rather focus on other things). I went from trivial Linux knowledge, enough to use gcc and make, to a functioning web server in about three weeks. I could have done it in four or five days, but I'm also in college pursuing a degree in computer science, and had to work around classes and generally do it in those times during which I had mental energy. The only other thing of interest--I hesitate to even mention it (not really, but I haven't found the sarcasm font yet)--is that I'm blind. This blog is going to eventually be about programming, probably programming audiogames, but this makes a nice first post. Anyhow, the technicalities and difficulties of setting up a web server:
I decided to go with a vps. At that time, I had know knowledge of which vps provider I wanted, nor what I would need. I would dwell on this point, but there's more interesting things ahead. After an afternoon of what amounts to window shopping and several discussions on Alter Aeon and a private Facebook group I decided on Chicago VPS. I'll probably upgrade sort of soonish. We shall see. It's currently running Debian 6.
VPS in hand, it's time to decide on the webserver. Following even more discussion--this is still the first day--I decided on Nginx. This is where the problems start.
Nginx in hand, it's time to look at octopress. As evidenced by this blog, I am not using Octopress. This is where my blindness comes into play. Octopress is great if you know markdown or are willing to learn it and is most definitely faster than what I'm doing right now--wordpress html editor. The problem is quite simple: Octopress is blog only. I am unable to make websites that look good in pure HTML for the quite simple reason that I can't see them. Screen readers will report invisible elements no problem. Screen readers will happily report text that is the same color as the window. Screen readers have no problem with 20 overlapping links, none at all. An entire afternoon later, and several problems installing the correct versions of ruby to run it, I realize this. Back to the drawing board. Also, back to classes for a week. This is going to eventually have non-blog pages, so it is important.
Great, I thought, what else works. I know, wordpress. That's everywhere these days. Let's use WordPress. Mmm, time to set up php. This sounds innocent. This is where I discover that it is not. I could go on about how I tried many, many times to get it working, but I'm' going to cut to the chase. The Nginx documentation wiki is out of date. if anyone else has to do this, here's the starting point:
location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; try_files $uri = 404; fastcgi_index index.php; include fastcgi_params; }
Unfortunately, i don't yet have WordPress configured for code, so that's probably going to render incorrectly--copy/pasting it may or may not work, who knows. It's also probably not the most secure setup for php.
After that, it gets anticlimactic for a while. Everything ran smoothly, and I'm like, time for word press. unfortunately not.
Time to talk about iptables. Iptables was written by someone who designs things without thought to users. I don't mean that it's poorly written, quite the contrary, it's just that the person who designed it designed it for computers, not humans. The VPS running this is on OpenVZ, so I get iptables or nothing. Realizing that I'm open to all sorts of attacks without iptables, it's time to go get that working.
I'm not even going to try to describe iptables here. Consider this, though: iptables -A INPUT -p tcp --dport ssh -j ACCEPT. It is case sensitive. That is almost certainly not correct and is quite literally the simplest example. It gets worse from there, quickly, and there's all sorts of cryptic errors and such. I'm on a VPS, and only just discovered how to use the serial console--at least, with a screen reader--yesterday, so one mistake locks me out of the server forever. For those who need to do this via ssh, the above should be the first iptables command you type, ever. Be warned that it does not persist by default--on debian you want the iptables-persist package, or maybe it's iptables-persistent. I had bigger issues than iptables won't save, but one of those does the trick, if you do some googling and find out that the magic file you have to save the rules to is /etc/iptables/rules. I'm not going to go into an iptables tutorial, at least not here. I'm still not completely confident that iptbles is set up properly and am almost certain there's a security hole somewhere, and at least one of the rules I needed required that I go learn what happens during a tcp handshake.
Finally, we reach the part that I thought would be hard. I was completely convinced that the hardest part would be setting up the mysql database and getting wordpress going. It's not. It's surprisingly easy in fact, especially compared to iptables. You just do a few things, and the WordPress instructions, surprisingly, actually work as advertised.
And so we come to the final pair of issues, and the easiest to resolve. WordPress wants to run as the same user as the web server and wishes to have ownership of its files. This fixes updating and installing plugins, as no one enables ftp these days (if you have, go learn about sfpt and get winscp). The other issue was the HTML editor only issue that seems to be hitting a lot of people. I fixed this, in my case, with an obscure configuration directive that's not documented anywhere
Anyhow, that's it for the web server and brings us to this evening. I would write about how I started the post by pressing the new post button, but that would lead to infinite recursion and, more importantly, boredom. I'll post about projects I plan to start soon, and intend to get some code samples and a git repository going in the near future. I plan to release some small utility stuff as blog posts with explanation, and might from time to time write about c++ language features and the like. We shall see.