nginx configuration full derp
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
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 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:
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?
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.
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.
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?
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.
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.
Also, what does 'apt-cache policy nginx' say? That should spit out what the package manager thinks is going on.
> 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
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…
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.)
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
~~
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
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:
![](
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.
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?
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.
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.
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 ship
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.
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:
> Response Headers -
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
although the main domain isn't pointed to the server…
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.
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.
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.
@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
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.
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;
# }
# }
# 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
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
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…
@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.
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
WTF, WTF and possibly: another WTF.
> 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;
#}
#}
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.
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.
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.
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.