Adventures in Django Deployment: What is a Web Server Anyway?

I recently had some hair-raising adventures in the land of website deployment. I’ve been completely rebuilding my website with a Django backend because I love Python. (This blog will eventually be hosted there, although WordPress does excel at the blog thing, so I might just get crazy and integrate Django AND WordPress. But I digress.) I had everything working all fine and dandy on my local computer and was ready to deploy my almost-identical-but-now-Django-backed placeholder site. I’ve long had Apache serving a few VirtualHosts and handling the SSL certificates on my personal DigitalOcean droplet, so my choice of web server was made for me. At least all that domain config stuff was done, so it would be a cinch to get Django up and running in place of my static site, I thought.

I thought wrong.

It started off so well. I installed python and PostgreSQL on my server and configured my production settings file to match (and to pull in the passwords from a separate ini file on the server and out of the git tracking). I set up a bare repo and some git hooks to make pushing to production easy. (I know I should also set up a separate staging subdomain for testing, but I’ve been in a hurry to get something real up there since I’m starting the ol’ job hunt.) Everything seemed to be ready to push so I turned to the Apache config.

This is where my troubles began. I had been running Django’s testing server locally, but the docs were very clear that this testing server should not be used in production. They did not go into details as to why other than “security and scaling,” but I took their word for it. That’s okay, I thought; I have Apache set up already anyway. The docs also kept talking about this “WSGI” thing, but when I had tried to figure out how to configure that, it had mostly just confused me, and well, it was working on my machine.

Continue reading “Adventures in Django Deployment: What is a Web Server Anyway?”

If you wanna resize a partition with gparted…

…you gotta manually compile the latest version of e2fsck.

WHY IS EVERYTHING SO DIFFICULT?!

OK, it’s not that difficult, but you would think the error messages for such a common operation would have been more helpful. I’m just trying to extend the Raspberry Pi image I just flashed so it takes up the whole SD card.

Here’s how to do the thing.

For the record, e2fsck is the ext-filesystem-specific component of the fsck filesystem utility. I have just this week been using it to check ext filesystems for errors like so:

e2fsck /dev/sdb5 (or whatever)

Make sure the drive is unmounted first:
umount /dev/sdb

Be careful; that’s umount, not unmount. I can’t tell you how many times that used to throw me off!

Update:

Additional issues! For some reason I could mount the filesystem once, but not again after that. Apparently I should have just resized the filesystem manually instead of using gparted to begin with. I resolved the issue thanks to the info found in this thread and the following commands:

(make sure partition is unmounted)
e2fsck -f /dev/sdX
resize2fs /dev/sdX

Changing the Default OS in GRUB—the Easy Way!

A grub larva

Like many folks, I have my laptop set to dual boot Windows and Linux. This isn’t the sort of thing that’s too terribly difficult to set up, but GRUB always boots up Linux by default, and sometimes that’s not ideal, such when I’m trying to install Windows updates that require a restart or two. I’m a distractible beast, and I always seem to look away from my computer at just the wrong time.

When I searched for an easy way to switch which OS was set to boot by default, I found a lot of dead ends, either outdated information or complicated methods that just seemed like a lot more trouble than they were worth for what is, at the end of the day, a minor annoyance. Well I took another crack at it the other day and I finally found an easy solution! Better yet, I found out that it’s also easy to set GRUB to save whichever OS was booted last as use that as the default! That’s not even what I was initially trying to figure out how to do, but that’s exactly the behavior I wanted, I realized.

Now, this should work for any version of GRUB2, though I can’t personally vouch for other setups; I have GRUB version 2.02 from Linux Mint. But the solution is to simply edit the /etc/default/grub file, which is used to generate the actual grub.conf file (which should not be edited by hand).

There is a line which reads:

GRUB_DEFAULT=0

The value is an index number for the menu items displayed by the GRUB menu at boot, starting at zero for the first item. You can switch this number to set any other item on the list as the default, so 1 for the 2nd menu item, 2 for the 3rd menu item, etc.

OR! You can change this value to saved and add one more option as follows:

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true

As you might suppose, this tells GRUB to start saving a reference to whichever OS was last booted and sets that reference as the new default. After saving these changes, the GRUB boot menu will still display as before, so you are free to manually select whichever OS you need, but left unattended, whichever menu option was chosen last will be booted automatically when the countdown timer runs out.

For good measure, now that I was more confident about my default boot selection, I went ahead and shortened that boot countdown to 30 seconds:

GRUB_TIMEOUT=30

As the file reminds you in the comments, once you are done saving your changes, be sure to run sudo update-grub to put them into effect.

For more details and to learn about some of the other GRUB options, check out this post from How To Geek.