Deploy Podcast Feed Gen

[tobinus]

Oh man, this is gonna be an exciting one.

hemingway.radiorevolt.no

1. The beta instance can be used as a basis. Create a copy of the directory.
2. Create new virtualenv, install packages.
3. Create a new PostgreSQL database, and initialize it according to the instructions in INSTALLATION.md.
4. Go through the configuration files, so they are fit for production.
5. Make a copy of the SystemD or upstart unit file, replacing the path. Enable the new unit.
6. Make a copy of the sites-file in Apache, and customize it to fit the new installation (vhost podkast.radiorevolt.no).
7. Add command to crontab which cleans up the Apache cache (search Google for it).
8. Enable the new sites-available conf.
9. Use Apache's test-config-utility.
10. Make the changes live by reloading Apache.
11. Use /etc/hosts on your own computer to test that the site works.

ITK

1. Ask someone with competence on DNS servers to confirm that this procedure will indeed work.
2. Ask ITK to add entry to their DNS server for podkast.radiorevolt.no. Notice them that this won't work immediately.

domeneshop.no or feedburner.google.com

1. Investigate what is done when the migrate tool is used in feedburner.google.com, and either use it or follow along.
2. Make cirkus.samfundet.no the authoritative name server for podkast.radiorevolt.no.

After a couple hours, everyone should be using podcast-feed-gen. Time for hi-fives!

[tobinus]

Seems I've been wrong? I think there's a CNAME entry in cirkus.samfundet.no that points to Google's Feedburner server, and that Google's DNS server isn't used.

[tobinus]

So, this procedure has been followed through, and podkast.radiorevolt.no now points to this solution! Hooray!

There are still a few missing things, though.

• Sometimes, iTunes asks for a whacky url (like /~r/Skammekroken/...), which of course returns 404.
• Check that the processes' memory usage doesn't grow with no bounds
• Ensure database is backed up.
• Set up redirection from old SRiB podcast solution
• Inform everyone about the new solution
• Update related wiki-articles on the internal wiki
• Check that the server logs are rotated
• Check that the file system doesn't grow with no bounds

[tobinus]

The reason weird URLs were being used, was because the old Feedburner feed used them, and iTunes didn't update the feed before trying to download episodes. If I were to deploy this again, I would make sure to redirect the Feedburner URLs to Feedburner.

[tobinus]

The memory usage grew throughout the night, but I've make a quick fix by ensuring the processes are restarted after 500 requests.

[tobinus]

The server logs are rotated as they should. The log's space usage should be less than 1,1MB, which seems reasonable.

[tobinus]

Fixed an oversight; the Feedburner slug for the all episodes feed hadn't been put into alternate_show_names.py

[tobinus]

Database is not backed up? I need to find a solution for that.

[tobinus]

Now, the old solution is no longer running. Thanks for all the fish, SRiB!