nginx configuration full derp

I have always wanted a website. And now I almost have it.

There is a problem.

I was told that static sites are the way to go. That I should get one. Jekyll, Github, haml, Ruby, version control, for the love of god no PHP, and all that stuff. Whatever. Much better than the old stiff WordPress mammoth. Static site would be like a young-born circus elephant compared to that. And I did. It involved all kinds of black geek sorcery from my point of view but eventually my hipster sass-compass Octopress site was ready. I nearly lost my mind and job along the process, so good thing I got finally something done.

It all went well until I talked with some hacker guy about my hosting. "Cool. Octopress. So where you host that thing of yours?", he asked. "Oh, it's on Webfaction", I replied. "WHAT?!", he yelled. "DUDE YOU HAVE A STATIC SITE AND IT'S ON SHARED HOSTING!?! THAT'S LIKE KEEPING A SUPERMODEL IN A LOCKED SHED IN YOUR BACKYARD!!!!" At this point, I kindly asked him to not to use caps lock again during our conversation. He replied with a hurricane of zeros and ones, which I believe contained several curse words translated into binary code. After that he wrote just one word to me. Linode. Taking account the fact we have recently talked about web hosting, I presumed it was a last resort suggestion for finding salvation from the damnation of shared web hosting.

So I got my Linode account. Installed nginx, Apache and so on. I set the hostname. I named my linode "moonshine". I chose Ubuntu 10.04 LTS as my Linux distribution. Then I had to configure the nginx server.

Sweet. Mother. Of. God.

Remember those old video games which had the final enemy boss level? Yeah. The nginx.conf file became that for me. So in my case the final boss fight came up with trying to create a website, not while playing a video game. Which is much worse. There's all these code blocks, locations, server names and what not. And yes. I read the Linode tutorial on basic nginx configuration. It's just too hard for me. Hard like "lasso a unicorn, find the Holy Grail and solve the European Economic crisis with them." Like yes, I know the things I need but I really don't know how can solve that with them. Very illogical. So, where should start to configure the nginx.conf file so I can beat my final boss and get through this battle as hero? A hero with a working website.

Thanks for your answers, in advance.

P.S. I did look through the forums if there would have been any post like mine. I believe there wasn't.

51 Replies

Just to make sure we're looking at the right thing here, what do you get for 'ls -l /etc/nginx/sites-enabled/' ?

Bam! OK. That means all of the config is in /etc/nginx/sites-available/default, so it's looking at the server_name line in there to determine its hostname.

Here's what I would do, to stay sane:

1) cp /etc/nginx/sites-available/default /etc/nginx/sites-available/doodleskull

2) Edit /etc/nginx/sites-available/doodleskull.com so that the servername line is "servername derp.doodleskull.com doodleskull.com www.doodleskull.com;"

3) ln -s /etc/nginx/sites-available/doodleskull /etc/nginx/sites-enabled/doodleskull

4) Restart nginx (service nginx restart). Make sure your web site still works OK. If not, rm /etc/nginx/sites-enabled/doodleskull, restart nginx, and hopefully you'll be back where you were.

5) rm /etc/nginx/sites-enabled/default

6) Restart nginx (service nginx restart). Make sure your web site still works OK. If not, ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default, restart nginx, and hopefully you'll be back where you were.

And I think that should do the trick…

Post your nginx.conf and anything in /etc/nginx/sites-enabled/ again? I think it's due for another pair of eyeballs in its current state.

Sorry, my previous post should have ended with a link to Reddit Enhancement Suite.


ಠ_ಠ

http://derp.doodleskull.com/archives (without ending slash) redirects to http://locahost/archives/, but http://derp.doodleskull.com/archives/ (with ending slash) works fine. That tells me the first entry on the server_name line is 'localhost'.

Two possible fixes:

1) Make the first entry on the server_name line derp.doodleskull.com

Or – the second one here is the one I'd pick, given the rest of this thread --

2) Set "servernamein_redirect off"

For the comic vs. video thing, I don't know but I loathe video. I follow a few comics that do the daily comic + occasional video thing and I never get around to watching the videos. I'd have to stop my music and devote a number of minutes to watching the video, which may or may not be amusing. Same reason I don't really watch television.

Disclaimer: I have enough ADD that it's a strain to catch up on /r/reactiongifs, even with Reddit Enhancement Suite.

There is no thinking! There is only knowing! To know is to know, to think is to think!

ls -l /etc/nginx/sites-enabled/

:-)

Also, try "/etc/init.d/nginx restart" again, if you haven't in awhile… it's possible the old server is still running…

There's a symlink from /etc/nginx/sites-enabled/doodleskull to /etc/nginx/sites-available/doodleskull, right? I think there's a nifty script that automagically does this, but I can't recall what it is named.

Also, what does 'apt-cache policy nginx' say? That should spit out what the package manager thinks is going on.

LOL, this is one of the most hilariously written (albeit verbose) questions I've seen in a long time.

If you followed any tutorial that involves compiling nginx from source, I dunno.

If you just did "apt-get install nginx", then maybe I can help you.

Don't touch /etc/nginx/nginx.conf. There's nothing in that file that needs to be edited right now.

Instead, go to /etc/nginx/sites-available. There should be a file named "default" there. Don't touch that one, either. Create another file with whatever name you want. Let's say the filename is "doodleskull". Put the following lines in there:

server {
    listen 80;
    server_name example.com www.example.com;
    root /wherever/your/static/site/is/located;
}

Replace both occurrences of "example.com" with your domain. Replace the path with the name of the directory where you uploaded your static site. (If you haven't uploaded it yet, do it first.) Don't forget the semicolon at the end of each line.

Done? Now issue the following commands:

ln -s /etc/nginx/sites-available/doodleskull /etc/nginx/sites-enabled/doodleskull
/etc/init.d/nginx reload

That's it. You can put a lot of other things in that configuration file to customize your server's behavior, but if it's a static site you shouldn't have to do much more than that.

I had static on my site once, it turned out to be a loose ground wire.

Finally, the reinforcements have arrived. However, my friends, this battle took a dramatic turn.

I don't have /etc/nginx/sites-available directory. I do have /etc/apache2/sites-available folder, though. But that's a bit like saying "I do have a Volvo" when someone asks if you have a Ferrari in your garage.

I installed nginx by following this guide: ~~[http://library.linode.com/web-servers/nginx/installation/ubuntu-10.04-lucid" target="_blank">](http://library.linode.com/web-servers/n … 0.04-lucid">http://library.linode.com/web-servers/nginx/installation/ubuntu-10.04-lucid](

This guide downloads and compiles nginx to: /opt/nginx

There's not /sites-available sub-folder either.

I also installed nginx from the Ubuntu packages by using the command: apt-get install nginx Thus, there seems to be two nginx directories in /opt: /nginx and /nginx-1.0.12

So… I installed nginx… twice?

So it seems that you have not one, not two, but three web servers installed on your Linode!

1) Apache

2) nginx (ubuntu package)

3) nginx (compiled)

That can cause all sorts of trouble the next time you reboot your server, because whichever server grabs port 80 first will crash the other two.

First, get rid of Apache if you don't need it: apt-get remove apache2

Second, get rid of the compiled nginx. You're better off using the official package, because then you won't have to worry about security fixes all the time. I'd like to tell you that you can probably nuke /opt/nginx without damaging anything else, but…

There are some possible complications.

1. Why are there two nginx directories in /opt? The official package doesn't place anything in /opt. If both directories are from the compiled version, that's fine, you could delete them both… but if not, something smells fishy.

2. After installing nginx with apt-get, do you have /etc/nginx/sites-available now? Or at least /etc/nginx? If not, something smells even more fishy.

3. The tutorial also tells you to create an init script at /etc/init.d/nginx, which will probably stop working if you delete the compiled nginx. Unfortunately, this is the exact same location where Ubuntu's official nginx package places its own init script, so your file could have come from either source. You could try deleting the init script and run "apt-get install --reinstall nginx", but I can't guarantee that this will put the right init script in its place.

1. Got rid of Apache, with apt-get remove, that went well.

2. Got rid both nginx servers, only that I had to remove them manually from the /opt folder. I removed both nginx folders. Before that I tried 'make uninstall' in the nginx folders and 'apt-get remove nginx'. It didn't work.

3. After manually deleting nginx folder, installed nginx again from Ubuntu packages with 'apt-get install nginx'. I chose it to overwrite the old /etc/init.d/nginx script.

4. Created file 'doodleskull' in /etc/nginx/sites-available and put there what server to listen and appropriate root for actual site files.

5. So everything went fine, right? Nah, not so fast, my friend.

6. Pointed my domain name to Linode's servers from Namecheap. Nameservers, that is.

7. Long story short, didn't work, I see the site fine but page speed test sites (wanted to check if the page load time improved from Webfaction to Linode) gave all a 404 error. Eventually pointed nameservers back to Webfaction just to be sure that site is up with out 404's. Will try again later to solve this mammoth problem.

8. Don't know WTF to do next.

9. Thanks for the help though.

10. Actually there wasn't a thing number 10, but I wanted to end this with 10, because all lists on the internet come in tens.

This is the most amusing help thread I've read in a while.

Did you copy the sites-available file exactly? You'll want to add a line to tell nginx where to log errors:

error_log /path/to/site/logs/error.log;

Reload nginx and hit some of your pages. Check the error log you just specified for more details and come back to this thread if it's not clear.

@doodleskull:

6. Pointed my domain name to Linode's servers from Namecheap. Nameservers, that is.

Wait. Did you configure linodes nameservers to return your linode's IP address for your domain name?

What is the domain name for your website?

@sednet:

Wait. Did you configure linodes nameservers to return your linode's IP address for your domain name?

What is the domain name for your website?
(OP's username).com seems to have been registered thru Namecheap, hosted on Webfaction, and built with Octopress. This fits OP's description.

The same domain is also served by Linode's nameservers, and it points to an IP address in Linode's London datacenter.

Requesting the domain at the IP address returns a 404 from nginx/1.0.12. Interestingly, no version of Ubuntu supplies that particular version of nginx. The only repository that currently contains nginx/1.0.12 is dotdeb for Debian. OP trying a new distro? :P

Anyway, it's a bad idea to move an entire domain over until you're sure that your site is functioning properly. Moving nameservers is particularly dangerous because it can take a day or two to take effect, and another day or two to reverse any mistakes.

Does webfaction allow you to tweak the DNS? If so, try adding a subdomain with an A record that points at your Linode's IP address. Add the corresponding subdomain to your "doodleskull" configuration file (just append it to the "server_name" line), and reload nginx. Test away on the subdomain. If it works, move the main domain.

Holy crap. Not only that I'm fat, ugly and broke I'm now also incompatible ever becoming a sys admin. How low one human can get?

Anyways. Let's continue to humiliate me & my skills publicly so all the people who can actually do this stuff can laugh at my expense.

> Did you copy the sites-available file exactly?

Umm, that would be a no. I just created 'doodleskull' file in the /etc/nginx/sites-available folder. It has only these lines in it and nothing else:

server { 
    listen 80; 
    server_name derp.doodleskull.com doodleskull.com www.doodleskull.com; 
    root /where/i/believe/my/site/is/located/but/dont/really/have/a/clue; 
}

Moving on:

> Interestingly, no version of Ubuntu supplies that particular version of nginx. The only repository that currently contains nginx/1.0.12 is dotdeb for Debian. OP trying a new distro?

Okay… I re-installed nginx earlier from the Ubuntu package, or so I think at least. I might have also tried to build the Large Hadron Collider via the command line, which may have caused this. In other words, I don't have clue.

Webfaction allows me to tweak the DNS. I created "derp.doodleskull.com" and pointed it with a A record to my Linode's IP. Reloaded nginx, tested the subdomain, got a 404 again.

Oh, and the error log thing. I put that error log path also in the "doodleskull" file, reloaded nginx but the error log was empty. As are my ideas to get my website working. The battle continues.

Thanks again guys for the help.

> There's a symlink from /etc/nginx/sites-enabled/doodleskull to /etc/nginx/sites-available/doodleskull, right?

I'm not sure. I believe so?

> Also, what does 'apt-cache policy nginx' say?

This:

nginx:
  Installed: 0.7.65-1ubuntu2.2
  Candidate: 0.7.65-1ubuntu2.2
  Version table:
 *** 0.7.65-1ubuntu2.2 0
        500 http://us.archive.ubuntu.com/ubuntu/ lucid-updates/universe Packages
        100 /var/lib/dpkg/status
     0.7.65-1ubuntu2.1 0
        500 http://security.ubuntu.com/ubuntu/ lucid-security/universe Packages
     0.7.65-1ubuntu2 0
        500 http://us.archive.ubuntu.com/ubuntu/ lucid/universe Packages

derp.doodleskull.com is still being served by nginx/1.0.12.

Anything in /var/log/nginx/error.log or similarly named files? (The errorlog line suggested by StanTheman won't do anything unless the www-data user has write permission to the appropriate directory.)

Just check /etc/nginx/sites-enabled/doodleskull and verify that it contains the same thing as /etc/nginx/sites-available/doodleskull. If the symlink has been set up correctly, whenever you edit one of those files, the other file should be modified too.

It's also possible that your old compiled nginx is still hanging around in RAM if you haven't rebooted yet. For some reason, apt-get doesn't automatically start the newly installed nginx ater installation is complete, which means that it may not be running. What does the command "ps aux" return? (edit: dang, hoopycat beat me to this suggestion.)

In /var/log/nginx/error.log:

2012/02/22 15:14:16 [emerg] 16626#0: open() "/path/to/site/logs/error.log" failed (2: No such file or directory)
2012/02/22 17:27:33 [emerg] 17763#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/02/22 17:27:33 [emerg] 17763#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/02/22 17:27:33 [emerg] 17763#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/02/22 17:27:33 [emerg] 17763#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/02/22 17:27:33 [emerg] 17763#0: bind() to 0.0.0.0:80 failed (98: Address already in use)
2012/02/22 17:27:33 [emerg] 17763#0: still could not bind()

ps aux returns:

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.3   2736  1580 ?        Ss   Feb12   0:02 /sbin/init
root         2  0.0  0.0      0     0 ?        S    Feb12   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Feb12   0:01 [ksoftirqd/0]
root         4  0.0  0.0      0     0 ?        S    Feb12   0:09 [kworker/0:0]
root         5  0.0  0.0      0     0 ?        S    Feb12   0:00 [kworker/u:0]
root         6  0.0  0.0      0     0 ?        S    Feb12   0:00 [migration/0]
root         7  0.0  0.0      0     0 ?        S    Feb12   0:00 [migration/1]
root         8  0.0  0.0      0     0 ?        S    Feb12   0:00 [kworker/1:0]
root         9  0.0  0.0      0     0 ?        S    Feb12   0:00 [ksoftirqd/1]
root        10  0.0  0.0      0     0 ?        S    Feb12   0:00 [migration/2]
root        11  0.0  0.0      0     0 ?        S    Feb12   0:00 [kworker/2:0]
root        12  0.0  0.0      0     0 ?        S    Feb12   0:00 [ksoftirqd/2]
root        13  0.0  0.0      0     0 ?        S    Feb12   0:00 [migration/3]
root        14  0.0  0.0      0     0 ?        S    Feb12   0:00 [kworker/3:0]
root        15  0.0  0.0      0     0 ?        S    Feb12   0:00 [ksoftirqd/3]
root        16  0.0  0.0      0     0 ?        S<   Feb12   0:00 [cpuset]
root        17  0.0  0.0      0     0 ?        S<   Feb12   0:00 [khelper]
root        18  0.0  0.0      0     0 ?        S    Feb12   0:00 [kworker/u:1]
root        22  0.0  0.0      0     0 ?        S    Feb12   0:00 [xenwatch]
root        23  0.0  0.0      0     0 ?        S    Feb12   0:00 [xenbus]
root       149  0.0  0.0      0     0 ?        S    Feb12   0:04 [sync_supers]
root       151  0.0  0.0      0     0 ?        S    Feb12   0:00 [bdi-default]
root       153  0.0  0.0      0     0 ?        S<   Feb12   0:00 [kblockd]
root       163  0.0  0.0      0     0 ?        S<   Feb12   0:00 [md]
root       247  0.0  0.0      0     0 ?        S<   Feb12   0:00 [rpciod]
root       248  0.0  0.0      0     0 ?        S    Feb12   0:22 [kworker/0:1]
root       280  0.0  0.0      0     0 ?        S    Feb12   0:00 [kswapd0]
root       281  0.0  0.0      0     0 ?        SN   Feb12   0:00 [ksmd]
root       282  0.0  0.0      0     0 ?        S    Feb12   0:00 [fsnotify_mark]
root       286  0.0  0.0      0     0 ?        S    Feb12   0:00 [ecryptfs-kthr]
root       288  0.0  0.0      0     0 ?        S<   Feb12   0:00 [nfsiod]
root       291  0.0  0.0      0     0 ?        S    Feb12   0:00 [jfsIO]
root       292  0.0  0.0      0     0 ?        S    Feb12   0:00 [jfsCommit]
root       293  0.0  0.0      0     0 ?        S    Feb12   0:00 [jfsCommit]
root       294  0.0  0.0      0     0 ?        S    Feb12   0:00 [jfsCommit]
root       295  0.0  0.0      0     0 ?        S    Feb12   0:00 [jfsCommit]
root       296  0.0  0.0      0     0 ?        S    Feb12   0:00 [jfsSync]
root       297  0.0  0.0      0     0 ?        S<   Feb12   0:00 [xfs_mru_cache]
root       298  0.0  0.0      0     0 ?        S<   Feb12   0:00 [xfslogd]
root       299  0.0  0.0      0     0 ?        S<   Feb12   0:00 [xfsdatad]
root       300  0.0  0.0      0     0 ?        S<   Feb12   0:00 [xfsconvertd]
root       301  0.0  0.0      0     0 ?        S<   Feb12   0:00 [glock_workque]
root       302  0.0  0.0      0     0 ?        S<   Feb12   0:00 [delete_workqu]
root       303  0.0  0.0      0     0 ?        S<   Feb12   0:00 [gfs_recovery]
root       304  0.0  0.0      0     0 ?        S<   Feb12   0:00 [crypto]
root       866  0.0  0.0      0     0 ?        S    Feb12   0:00 [khvcd]
root       979  0.0  0.0      0     0 ?        S<   Feb12   0:00 [kpsmoused]
root       980  0.0  0.0      0     0 ?        S    Feb12   0:24 [kworker/2:1]
root      1006  0.0  0.0      0     0 ?        S    Feb12   0:35 [kworker/1:1]
root      1009  0.0  0.0      0     0 ?        S    Feb12   0:02 [kjournald]
root      1013  0.0  0.0      0     0 ?        S    Feb12   0:35 [kworker/3:1]
root      1034  0.0  0.1   2368   604 ?        S    Feb12   0:00 upstart-udev-br
root      1036  0.0  0.1   2236   560 ?        S

~~And ls -l /etc/nginx/sites-enabled/ gave:

total 0
lrwxrwxrwx 1 root root 34 2012-02-21 09:56 default -> /etc/nginx/sites-available/default
lrwxrwxrwx 1 root root 38 2012-02-21 10:22 doodleskull -> /etc/nginx/sites-available/doodleskull

~~

Your old nginx is still running. No wonder the changes you made to the new nginx configuration isn't being respected.

Kill the old, zombie nginx with a clean head shot:

kill -9 1945
kill -9 1947

Then restart the new nginx:

/etc/init.d/nginx restart

Consider the zombie nginx server as killed.

However, derp.doodleskull.com still shows a 404. Now it's just powered by nginx 0.7.65.

Since I've pointed the subdomain to 178.79.162.39, which is my Linode IP, so from my understanding it's not the problem here. On the other hand, it was my understanding that created this server apocalypse mess, so I'm not the one to say anything at this point.

But it would seem that's something's messed up either in my 'doodleskull' file in /etc/nginx/sites-available or I've put my site files in the wrong directory. Currently they're at /srv/doodleskull.com/public_html/.

I don't know. I took a photo of myself just a minute ago, maybe it will provide more valuable information:

![](" />

Killed also the double reply.

Well, at least you ended the zombie apocalypse, so it may be possible to rebuild the world!

Some observations:

  • According to your last post on page 1 of this thread, there seems to be a proper symlink from sites-available to sites-enabled. So that's not the problem.

  • Typing derp.doodleskull.com into a browser produces a different result from typing 178.79.162.39 into a browser ("Welcome to nginx!") so apparently nginx knows that this subdomain should be treated differently.

  • If there were problems with file permissions, the response would be 403, not 404. So permissions are not the issue here.

  • If the directory existed but there was no index.html in there, nginx would return 403, not 404. So that's not the case, either.

  • Which brings us back to the directory structure:

1) In a previous post, you said you had the following line in the doodleskull file:

root /where/i/believe/my/site/is/located/but/dont/really/have/a/clue; 

Is this exactly the same as /srv/doodleskull.com/public_html ? No typos, no weird characters in between, no unnecessary slash at the end?

2) One way to diagnose errors is to see if you can get the same program to produce a different error. Try pointing the line quoted above at non-existent paths like /herp/derp, or forbidden paths like /root. Restart nginx after every change. Does this cause the error message to change?

3) What does /srv/doodleskull.com/public_html actually contain? Please do an "ls -la" in that directory and post the results here.

> Is this exactly the same as /srv/doodleskull.com/public_html ?

Yup, that would be the same.

> Try pointing the line quoted above at non-existent paths like /herp/derp

Gives still a 404.

These are the files in the /srv/doodleskull.com/public_html folder:

total 104
drwxr-xr-x 17 root root  4096 2012-02-23 14:45 .
drwxrwxrwx  4 root root  4096 2012-02-12 05:53 ..
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 about
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 archives
-rw-r--r--  1 root root 17404 2012-02-21 10:06 atom.xml
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 bird-hate
-rw-r--r--  1 root root  1406 2012-02-21 10:06 favicon.png
drwxr-xr-x  4 root root  4096 2012-02-21 10:06 files
drwxr-xr-x  2 root root  4096 2012-02-21 10:07 fonts
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 hello
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 images
-rw-r--r--  1 root root  5549 2012-02-21 10:06 index.html
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 javascripts
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 movie-titles
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 nice
-rw-r--r--  1 root root  1607 2012-02-21 10:06 sitemap.xml
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 stylesheets
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 sucks
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 vacation-to-do
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 videos
drwxr-xr-x  2 root root  4096 2012-02-21 10:06 zombie-hangover

Standing by for orders. Over.

Hmm, perhaps the minimal configuration I gave you at the beginning was too minimal? I did that because my usual template relies on features that may not be available on nginx 0.7.65. (The preferred method for handling document roots and a few other things have changed in the last couple of years.) But maybe I shouldn't have left out the following block:

location / {
    root  /srv/doodleskull.com/public_html;
    index  index.html;
}

Put it right after the "root" line, inside the server { } block. Restart nginx. Any difference?

Edit: Added missing semicolon.

location / { root /srv/doodleskull.com/public_html; index index.html; }

Not any difference, no.

The "Welcome to nginx!" index.html is in /var/www/nginx-default directory. How /srv/doodleskull.com/public_html and /var/www/nginx-default are connected?

Could I rsync my Octopress generated site to the /var/www/nginx-default folder or will it make the server a zombie again?

OK, last resort: back up /var/www/nginx-default first, and then move your site to /var/www/nginx-default, and temporarily delete the "doodleskull" symlink from /etc/nginx/sites-enabled. (You can leave it in /etc/nginx/sites-available.) This will probably cause nginx to serve the same material no matter which domain you use, even the bare IP address. This is OK until you need to add a second website.

Alternatively, you could try editing /etc/nginx/sites-available/default and change all references to /var/www/nginx-default to a more convenient location.

I'm seriously running out of ideas as to why nginx is not finding your website files in its current location. Maybe the zombie outbreak left some subtle damages to your ecosystem, causing oceans to turn grey or something.

Alternatively, I could just have used Apache instead of nginx in the first place. I just had this grandiose idea that nginx would be better for me than Apache.

People have written tutorials all over the web specificly for Linode + Octopress with Apache, Matt Gemmell posted even his .htaccess file for reference if I remember correctly. So should this nginx installation go even more south at some point, I can always start again with a clean Apache installation. I've got a local copy of my site at all times, so it doesn't matter where or what on top of I put it.

> This will probably cause nginx to serve the same material no matter which domain you use, even the bare IP address. This is OK until you need to add a second website.

No need for a second site. If I'll need a second website, I'll open a separate Linode account for it.

> I'm seriously running out of ideas as to why nginx is not finding your website files in its current location.

Thanks for assisting this far. I really am thankful of all the help I've gotten in this thread.

I'll do the steps later today when I get home that you suggested on your last message and post an update on how it went.

@doodleskull:

Alternatively, I could just have used Apache instead of nginx in the first place. I just had this grandiose idea that nginx would be better for me than Apache.
Maybe. You know, at least you didn't have a zombie outbreak involving Apache.

But it's not your fault – There are too many tutorials out there, including Linode's own, that talk about compiling nginx from source as if that was the natural way to install it on Ubuntu. No, apt-get (or aptitude) is the only natural way to install anything on Ubuntu, and compiling should be the last resort for packages that aren't in the repositories. Those tutorials should come with a big warning, but they don't.

As a result, somebody messes up their nginx installation and cries for help on this forum every other month, and what could have been a 5-minute quick fix turns into an unmanageable mess. This was exactly the kind of mess that standardized binary-based distros such as Ubuntu were supposed to help you avoid! You're just another casualty of the compiler-happy tutorial writers.

How to install Apache: apt-get install apache2

How to install nginx: apt-get install nginx

If you really need the latest version, use a more recent version of Ubuntu.

Anything else should be seen with the utmost suspicion.

/rant

Anyway, good luck with your skull doodling!

````
root 1945 0.0 0.1 4760 656 ? Ss Feb12 0:00 nginx: master p
nginx 1947 0.0 0.2 5088 1432 ? S Feb12 0:00 nginx: worker p

That looks like the old server you compiled. Kill it with:

kill 1945 1947

Then start the ubuntu packed one with:

/etc/init.d/nginx start

````

EDIT: Oh sorry, Didn't see this thread had already run into a second page.

Now I can't get the browser even to connect to my Linode.

178.79.162.39 = nothing when typed to browser

li300-39.members.linode.com = nothing

derp.doodleskull.com = you guessed it, nothing

I started to ass around with Linode backups after hybinet said I should backup certain directories. I should have backed the directories up manually. I however have Linode backups, which I thought I could use but the control panel or whatever said that I don't have enough space on my disk if I want to use the backups.

That's why I needed to turn my Linode off, resize the disk for retrieving something from the backups. After I did this, and visited derp.doodleskull.com, nothing came up. The browser can't connect to my Linode.

Eventually I went and rebuilt my Linode installation. Now I've got nginx installed (the proper way with apt-get) but still, nothing.

I'm aware than I suck with this server stuff more than Bieber sucks with music. That's a lot. But still, the guides for doing this stuff could be simpler. For reference, even the rough guide for building a space shipseems simpler.

It can't be like > "Wanna set up a server? Well, that should be no biggie. Just study Terminal commands for 17 years at first, and then read this 'Getting started guide' which has 5647 pages. Then, you'll be ready to start to build your first server. That'll eat up something between 34 and 46 years from your calendar. After that, you're done. Now you can set up your site. Happy blogging."

Oh jesus, how can get my website up? Maybe in the next life.

At this moment, your server loads the "Welcome to nginx!" page no matter which domain I request. This page is stored in /var/www/nginx-default, right? (More recent versions of nginx have it in /usr/share/nginx/www, so check that out as well, though I'm pretty sure Ubuntu 10.04 uses the old location.) Try replacing the index.html file in this directory with the index.html file from your static site. Or even just edit it directly and insert some gibberish after the "Welcome to nginx!" message. Any change?

Okay I started nginx with "/etc/init.d/nginx start" and now it seems to be working, I get the 'Welcome to nginx!" message. Although, in my case it should say "Welcome to hell!"

Let see how long I can manage the keep things calm before the next 18,9 richter server earthquake comes for a visit.

See you in the next episode of "Stupid zombie n00b setting up zombie servers" on Linode forums! Every day at 7pm PST time!

@doodleskull:

See you in the next episode of "Stupid zombie n00b setting up zombie servers" on Linode forums! Every day at 7pm PST time!
You're drawing webcomics with skulls and other dead-looking characters in them. What else did you expect would happen to your server? You jinxed yourself. :twisted:

I put in http://derp.doodleskull.com/ and get a real page :). Looks to be the same as doodleskull.com .

> Response Headers - http://derp.doodleskull.com/

Server: nginx/0.7.65

Date: Sun, 26 Feb 2012 21:06:36 GMT

Content-Type: text/html

Last-Modified: Sat, 25 Feb 2012 21:25:22 GMT

Content-Encoding: gzip

200 OK

ha, funny thread. yeah looks like he got this sorted?

http://178.79.162.39/

although the main domain isn't pointed to the server…

I'm still having problems. Not only mentally but also with my Linode.

I've got an archives page for my stories and with the derp.doodleskull.com the archives doesn't open. It redirects to localhost/archives. This probably has something to do with the nginx configuration file or with the fact that I don't know what the hell I'm doing.

OT question: (hybinet if you're around I like to hear your opinion) should I do webcomics/image+text based stories on my site or should I do videos? Like if I turned this thread into a story, would you prefer a written/drawn story or a animated video with drawings?

I'm asking this because I don't know in which I should focus my time on, drawing images or making animated videos. Not many people do animated videos in the webcomic realm so that's an interesting option. I originally thought I'd do both, written stories with drawings and animated videos but I just don't have time for both.

I overwrote the /var/www/nginx-default folder with my site files.

If I try to make changes in /etc/nginx/sites-available/doodleskull file (which has the server names and location paths), they don't seem to have an effect. This was the problem earlier and that eventually made to overwrite the files in the nginx-default folder and put my site there.

> 1) Make the first entry on the server_name line derp.doodleskull.com

This is the first entry on that line at the moment. And that file was in /etc/nginx/sites-available/ and is named 'doodleskull'.

Also, now the 'doodleskull' file is missing from /etc/nginx/sites-enabled/ which I suspect happended before when I re-installed everything after a tectonic plate decided to land on my Linode.

http://derp.doodleskull.com/archives/ seems to load fine at the moment. Looks like you fixed the link to include a slash at the end? But the redirection problem hoopycat mentioned is still present, which means something is still off.

@doodleskull:

OT question: (hybinet if you're around I like to hear your opinion) should I do webcomics/image+text based stories on my site or should I do videos? Like if I turned this thread into a story, would you prefer a written/drawn story or a animated video with drawings?

I'm asking this because I don't know in which I should focus my time on, drawing images or making animated videos. Not many people do animated videos in the webcomic realm so that's an interesting option. I originally thought I'd do both, written stories with drawings and animated videos but I just don't have time for both.
I'm just a guy who likes to help people set up Apache and/or nginx on their Linodes. I usually don't even comment on other types of technical questions. So I don't think I'm qualified to give any opinions about the "webcomic realm".

But I do get the impression that your doodles contain more text than the typical webcomic. Your comics almost look like blog posts with occasional images inserted here and there. Perhaps you just want to tell a story and don't like to draw dozens of frames to go with it? If so, perhaps a video might suit you better. You can just draw a few things and move them around to tell a story. But then, I don't know anything about video production. Does it take longer than drawing comics?

But some of your doodles actually do seem to make use of idioms that are more suited to static images, like the side-by-side comparison in this comic as well as the comparison below that. How would you express the same ideas in a video without making it look like you just pointed a camcorder at your pictures? From what little experience I have for procrastinating on YouTube, I gather that when people watch videos, they expect to see video-specific idioms.

Or maybe really should do both, depending on which format suits a particular story better? After a while you can decide which format you like better, and concentrate more on it. There's no need to restrict yourself to one format, when you might come up with a story tomorrow that is more appropriate for another format.

Finally, why does the front page not have a "Next" button? I do know a few things about how web sites work, and I don't like it when I have to scroll all the way back to the top to click "Stories". But everyone knows how to navigate a blog. Allow them to click "Next" and view the next comic, whether that's a picture or a video.

nginx.conf from /etc/nginx

user www-data;
worker_processes  1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    # multi_accept on;
}

http {
    include       /etc/nginx/mime.types;

    access_log    /var/log/nginx/access.log;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

# mail {
#     # See sample authentication script at:
#     # http://wiki.nginx.org/NginxImapAuthenticateWithApachePhpScript
# 
#     # auth_http localhost/auth.php;
#     # pop3_capabilities "TOP" "USER";
#     # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#     server {
#         listen     localhost:110;
#         protocol   pop3;
#         proxy      on;
#     }
# 
#     server {
#         listen     localhost:143;
#         protocol   imap;
#         proxy      on;
#     }
# }

default file from /etc/nginx/sites-available

# You may add here your
# server {
#    ...
# }
# statements for each of your virtual hosts

server {
    listen   80 default;
    server_name  localhost;

    access_log  /var/log/nginx/localhost.access.log;

    location / {
        root   /var/www/nginx-default;
        index  index.html index.htm;
    }

    location /doc {
        root   /usr/share;
        autoindex on;
        allow 127.0.0.1;
        deny all;
    }

    location /images {
        root   /usr/share;
        autoindex on;
    }

    #error_page  404  /404.html;

    # redirect server error pages to the static page /50x.html
    #
    #error_page   500 502 503 504  /50x.html;
    #location = /50x.html {
    #   root   /var/www/nginx-default;
    #}

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
        #proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
        #fastcgi_pass   127.0.0.1:9000;
        #fastcgi_index  index.php;
        #fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #includefastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
        #deny  all;
    #}
}

# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
#listen   8000;
#listen   somename:8080;
#server_name  somename  alias  another.alias;

#location / {
#root   html;
#index  index.html index.htm;
#}
#}

# HTTPS server
#
#server {
#listen   443;
#server_name  localhost;

#ssl  on;
#ssl_certificate  cert.pem;
#ssl_certificate_key  cert.key;

#ssl_session_timeout  5m;

#ssl_protocols  SSLv2 SSLv3 TLSv1;
#ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
#ssl_prefer_server_ciphers   on;

#location / {
#root   html;
#index  index.html index.htm;
#}
#}

doodleskull file from /etc/nginx/sites-available

server {
    listen   80 default;
    server_name  derp.doodleskull.com doodleskull.com www.doodleskull.com;

    access_log  /var/log/nginx/localhost.access.log;

    location / {
        root   /srv/doodleskull;
        index  index.html index.htm;
    }

> Just to make sure we're looking at the right thing here, what do you get for 'ls -l /etc/nginx/sites-enabled/' ?

This:

total 0
lrwxrwxrwx 1 root root 34 2012-02-25 12:32 default -> /etc/nginx/sites-available/default

From the second post in this thread, dated February 20th:

@hybinet:

Done? Now issue the following commands:

ln -s /etc/nginx/sites-available/doodleskull /etc/nginx/sites-enabled/doodleskull
/etc/init.d/nginx reload


The first line there = line #3 in hoopycat's latest post.

I guess you ran these commands at the time, but then it probably got lost in the process of uninstalling and reinstalling various things. (Yeah, those symlinks definitely existed when you posted the last post in the first page of this thread.)

I'd also suggest deleting the "location /doc" and "location /images" lines (and the following 3-5 lines that belong in the same block) from the new "doodleskull" configuration file. They can conflict with files from your own static site.

RANT: Honestly, I don't really see the point of separating "sites-available" and "sites-enabled" in a typical nginx setup. There was a time when these folders didn't exist. You'd just drop some files in a folder and restart nginx, and it would work. "Sites-enabled" was added by the Debian team some time in the last few years, probably because they wanted to standardize the directory structure with what they've had with Apache for a long time. But what's the point of making web sites disabled by default? If I wanted to disable a site, I'd just move the corresponding configuration file somewhere else, like "sites-disabled". In fact, that's what I do with all my nginx installs. I symlink the entire "sites-enabled" directory to "sites-available" and call it a day.

If they had copied the scripts that make the structure work, a2ensite and a2dissite, it might have made more sense.

Current status of derp.doodleskull.com: 404 / Not found (nginx/0.7.65)

The following events take place between one WTF and three WTFs:

1) cp /etc/nginx/sites-available/default /etc/nginx/sites-available/doodleskull 
2) Edit /etc/nginx/sites-available/doodleskull.com so that the server_name line is "server_name derp.doodleskull.com doodleskull.com www.doodleskull.com;" 
3) ln -s /etc/nginx/sites-available/doodleskull /etc/nginx/sites-enabled/doodleskull 
4) Restart nginx (service nginx restart). Make sure your web site still works OK.

This worked fine. Remember I had those slashes at the end of site links? Yeah, I thought I'd get rid of them, if the site worked fine now.

Nope. That resulted a redirection to localhost again. Should have kept those slashes.

Next I tried: > If not, rm /etc/nginx/sites-enabled/doodleskull, restart nginx, and hopefully you'll be back where you were.

5) rm /etc/nginx/sites-enabled/default

6) Restart nginx (service nginx restart). Make sure your web site still works OK.

Still redirected to localhost. The configurations in doodleskull file at /etc/nginx/sites-available also got overwritten or deleted, on the second or first step.

Finally I went for: > If not, ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/default, restart nginx, and hopefully you'll be back where you were.

and added "servername derp.doodleskull.com doodleskull.com www.doodleskull.com;" to servername line in /etc/nginx/sites-available/doodleskull, which resulted a 404.

WTF, WTF and possibly: another WTF.

Be sure to clear your web browser's cache - that may be affecting/continuing the redirect when the server no longer is…errr, serving it. Either that, or hop into "Incognito/Private Browsing/Porn mode" on whatever browser you use to get around the cache.

> clear your web browser's cache

I thought that too, however no help from that either.

I'll put the configuration files here again, if those can reveal something:

First, nginx.conf from /etc/nginx

user www-data;
worker_processes  1;

error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
    # multi_accept on;
}

http {
    include       /etc/nginx/mime.types;

    access_log    /var/log/nginx/access.log;

    sendfile        on;
    #tcp_nopush     on;

    #keepalive_timeout  0;
    keepalive_timeout  65;
    tcp_nodelay        on;

    gzip on;
    gzip_disable "MSIE [1-6]\.(?!.*SV1)";

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

# mail {
#     # See sample authentication script at:
#     # http://wiki.nginx.org/NginxImapAuthenticateWithApachePhpScript
# 
#     # auth_http localhost/auth.php;
#     # pop3_capabilities "TOP" "USER";
#     # imap_capabilities "IMAP4rev1" "UIDPLUS";
# 
#     server {
#         listen     localhost:110;
#         protocol   pop3;
#         proxy      on;
#     }
# 
#     server {
#         listen     localhost:143;
#         protocol   imap;
#         proxy      on;
#     }
# }

Next, the default file from /etc/nginx/sites-available:

# You may add here your
# server {
#    ...
# }
# statements for each of your virtual hosts

server {

    #error_page  404  /404.html;

    # redirect server error pages to the static page /50x.html
    #
    #error_page   500 502 503 504  /50x.html;
    #location = /50x.html {
    #   root   /var/www/nginx-default;
    #}

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
        #proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
        #fastcgi_pass   127.0.0.1:9000;
        #fastcgi_index  index.php;
        #fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #includefastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
        #deny  all;
    #}
}

# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
#listen   8000;
#listen   somename:8080;
#server_name  somename  alias  another.alias;

#location / {
#root   html;
#index  index.html index.htm;
#}
#}

# HTTPS server
#
#server {
#listen   443;
#server_name  localhost;

#ssl  on;
#ssl_certificate  cert.pem;
#ssl_certificate_key  cert.key;

#ssl_session_timeout  5m;

#ssl_protocols  SSLv2 SSLv3 TLSv1;
#ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
#ssl_prefer_server_ciphers   on;

#location / {
#root   html;
#index  index.html index.htm;
#}
#}

And lastly, the doodleskull file from /etc/nginx/sites-available:

# You may add here your
# server {
#    ...
# }
# statements for each of your virtual hosts

server {
    listen   80 default;
    server_name  derp.doodleskull.com doodleskull.com www.doodleskull.com;
    server_name_in_redirect off;

    access_log  /var/log/nginx/localhost.access.log;

    location / {
        root   /var/www/nginx-default;
        index  index.html index.htm;
    }

    #error_page  404  /404.html;

    # redirect server error pages to the static page /50x.html
    #
    #error_page   500 502 503 504  /50x.html;
    #location = /50x.html {
    #   root   /var/www/nginx-default;
    #}

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
        #proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
        #fastcgi_pass   127.0.0.1:9000;
        #fastcgi_index  index.php;
        #fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
        #includefastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
        #deny  all;
    #}
}

# another virtual host using mix of IP-, name-, and port-based configuration
#
#server {
#listen   8000;
#listen   somename:8080;
#server_name  somename  alias  another.alias;

#location / {
#root   html;
#index  index.html index.htm;
#}
#}

# HTTPS server
#
#server {
#listen   443;
#server_name  localhost;

#ssl  on;
#ssl_certificate  cert.pem;
#ssl_certificate_key  cert.key;

#ssl_session_timeout  5m;

#ssl_protocols  SSLv2 SSLv3 TLSv1;
#ssl_ciphers  ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP;
#ssl_prefer_server_ciphers   on;

#location / {
#root   html;
#index  index.html index.htm;
#}
#}

4 pages of editing simple configuration files and we're still where we started. Meanwhile, OP has wasted a month on a non-functioning Linode! Derp Derp WTF indeed. Either the skulls are jinxing his server, or we're missing something that is embarrassingly simple.

Edit 1: Just saw your latest post. Your "default" file is completely messed up. Every single line is commented out!

Why don't we try it again from a clean slate.

WARNING: The following steps will delete a bit of data from your server. If you have anything on your server that you haven't backed up elsewhere, BACK IT UP BEFORE PROCEEDING.

If you get any errors during this process, please post the exact error messages here.

1. Delete everything from /var/www/nginx-default

rm -rf /var/www/nginx-default/*

2. Reinstall nginx:

apt-get install --reinstall nginx

3. Deploy your static site to some other directory. Let's call it /var/www/doodleskull Change your deploy settings in Octopress and make sure that all files are uploaded properly. In particular, make sure that there's a file named /var/www/doodleskull/index.html on your server.

4. Delete all existing configuration files from /etc/nginx/sites-available and /etc/nginx/sites-enabled, with the following commands:

rm /etc/nginx/sites-available/*
rm /etc/nginx/sites-enabled/*

5. While we're at it, let's just delete /etc/nginx/sites-enabled and symlink the entire directory to /etc/nginx/sites-available. This will make it impossible for any virtual host configuration to be ignored by nginx, ever.

rmdir /etc/nginx/sites-enabled
ln -s /etc/nginx/sites-available /etc/nginx/sites-enabled

6. Put the following into a file named /etc/nginx/sites-available/default

server {
    listen 80 default;
    server_name localhost;
    root /var/www/nginx-default;
    index index.html index.htm;
    access_log /var/log/nginx/access.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

7. Put the following into a file named /etc/nginx/sites-available/doodleskull

server {
    listen 80;
    server_name doodleskull.com www.doodleskull.com derp.doodleskull.com;
    server_name_in_redirect off;
    root /var/www/doodleskull;
    index index.html index.htm;
    access_log /var/log/nginx/access.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

8. Restart nginx:

/etc/init.d/nginx restart

9. Clear your browser's cache.

10. Cross your fingers and type derp.doodleskull.com into the address bar.

Edit 2: Fixed a couple of potential problems in the doodleskull file. If you already followed step 7, copy and paste it again.

IT WORKS!

Any possibility to remove those trailing slashes from the end of each link? (skull.com/about/, skull.com/link/, etc.)

Or are those essential to keep the site working?

@doodleskull:

IT WORKS!
Great!

@doodleskull:

Any possibility to remove those trailing slashes from the end of each link? (skull.com/about/, skull.com/link/, etc.)

Or are those essential to keep the site working?
That probably depends on how Octopress generates the directory structure. But since most web servers won't serve files with the text/html content type unless the filename ends with ".html" or ".htm", I don't think "/archives" will work. When a static site generator tells you to use "/archives/" as the URL, the actual web page is most likely being stored as "/archives/index.html". So "/archives/" is about as short as it gets.

The "try_files" line in the nginx config is supposed to handle the redirect from "/archives" to "/archives/". As long as you have that line in your config, you won't have redirect issues anymore. But the actual URL will always have a trailing slash.

I have no trailing slashes in Octopress, for example the about page is: skull.com/about.

When I type some page link in the address bar, say that about page again, it redirects me to skull.com/about/, which is fine for me. If it wouldn't had directed to that, as in the link would not have worked without actually typing that last slash in the link, that may have been a problem. People don't remember that trailing slash ever, so that kind of redirection is good.

Reply

Please enter an answer
Tips:

You can mention users to notify them: @username

You can use Markdown to format your question. For more examples see the Markdown Cheatsheet.

> I’m a blockquote.

I’m a blockquote.

[I'm a link] (https://www.google.com)

I'm a link

**I am bold** I am bold

*I am italicized* I am italicized

Community Code of Conduct