Emacs Wiki Migration

We’re going to move Emacs Wiki from Alex’s host to Nic’s host.

A *backlog* of things to do:

1. The emacsmirror on GitHub should be kept up to date.

1. Make sure git integration works. Currently every page edit results in a local commit.

2. Make sure the emacs-git-update script is called from a cron job to push changes to GitHub. Right now we’re waiting for emacsmirror to add a new SSH key.

2. Make sure the static copies of the Elisp Area files are created. Or that the caching proxy uses a different rule for the four variants (compact or not, using bootstrap or not).

3. Add a redirect for `/cgi-bin/wiki` links. Right now they all redirect to `http://www.emacswiki.org/emacs` and any remaining path-info is lost.

1. I have also discovered old links to `/cgi-bin/oddmuse` which should go to `oddmuse.org/wiki`

4. *DONE* Move the Emacs Wiki installation on Nic’s server from Nic’s home directory to a general directory where both Alex and Nic can work on it. → Nic

1. we’re going to keep working in Nic’s home

5. *DONE* Remove the distinction between links to missing pages and links to existing pages in order to make pages easier to cache. → Alex

1. change made to the config files on both hosts

6. *DONE* Remove the cache-control header from the Oddmuse backend. Don’t use the default 10s, either. → Alex

1. removed Expires* lines from .htaccess on both hosts; the caching proxy should handle this

2. changed current.pl on both hosts back to the current version of Oddmuse (ie. using cache control max-age of 10s)

3. changed config files on both hosts to delete `Cache-control:.*\n` from the header

7. *DONE* Figure out why there’s extra HTML at the bottom of any page that’s not a 200 OK response. Examples: http://www.emacswiki.org/emacs/A shows `NOT FOUND / The requested URL /emacs.pl/A was not found on this server. / Apache/2.4.7 (Ubuntu) Server at emacswiki.org Port 80`

1. This is caused by the mod_perl setup somehow. Switching back to CGI helps resolve this.

2. Apache site config file changed. No more ModPerl::Registry. MultiViews enabled again.

3. mod_cgi enabled on Nic’s host

4. emacs.pl remains unchanged

5. .htaccess remains unchanged (MultiViews allows for a small simplification, if I remember correctly)

6. Apache restarted

8. *DONE* Abandon my host and have Nic’s server do all the serving. Right now we’re load-balancing between the two.

9. *DONE* Add ?bypass as a way to bypass any caching in the nginx

10. *DONE* If the current user doesn’t have a cookie set, we’ll use a cache_control header with a max-age of 1d. This is done by the caching proxy.

1. the cookie name is Wiki

2. bypass on Cookie “Wiki” and argument “bypass”

11. *DONE* If the current user has a cookie set, don’t use the caching proxy at all, for now? This would make sure bots and read-only users get cached pages where as actual wiki editors do not.

12. *DONE* Figure out how to handle the caches exactly. Last-modified-time, ETag, whatever.

13. *DONE* Define a list of request matches that bypass the cache.

1. cache=0 in the query string– must use “?bypass”

2. Preview= in the query string– this is hardly ever used; it’s simpler to just let POST requests bypass the cache

3. action=edit in the query string

4. all the other action= calls for administrative stuff (locking, banning) are no problem because these users will have the cookie set (alternatively: provide a complete list?)

5. added ?bypass ?action and ?preview as cache bypassers

14. *DONE* Fix permissions – Apache runs as www-data but we want to use Nic’s group. Use the `fix-data-dir-permissions` script.

15. *DONE* Updates from ELL need to be copied to the wiki. Make sure update-ell is called from a cron job on a regular basis. Make sure ell-to-wiki.pl works. Make sure wikiput works.

16. *DONE* Make sure the static copies of the RSS files are created. Or that the caching proxy uses a different rule for the most common RSS links visible from RecentChanges.

1. Don’t install the cron job creating the static file. ✓

2. Get rid of the static files. ✓

3. Fix the link elements in the HTML that point to the static files.– We’re leaving the links as-is and handling the URLs in nginx.

4. Make sure that ?action=rss gets cached. ✓

17. *DONE* Make sure the backup script is called from a cron job in order to keep a copy of all the necessary files in Chile.

18. *DONE* Make sure browser language preferences work again.

19. *DONE* Make sure that the difference between 简体中文 and 繁體中文 works.

20. *DONE* Make sure that Recent Changes works for other languages, eg. switch to Deutsch and visit Letzte Änderungen. Does it show recent changes or not?

1. This requires all `$RCName` values to replace SPC with __

21. *DONE* Make sure `http://www.emacswiki.org/info-ref` works again.

22. *DONE* Make sure the redirection of these links work again:

1. `http://www.emacswiki.org/cgi-bin/info-ref` ✓ → all cgi-bin issues resolved by commenting `/etc/apache2/conf-enabled/serve-cgi-bin.conf`

2. `http://www.emacswiki.org/cgi-bin/emacs` ✓

3. `http://www.emacswiki.org/cgi-bin/emacs-en` ✓

4. `http://www.emacswiki.org/emacs-en` ✓

5. `http://www.emacswiki.org/emacs-en/[[SiteMap]]` ✓

6. `http://www.emacswiki.org/emacs.pl` is not redirected and simply works?

7. `http://www.emacswiki.org/wiki` ✓

8. `http://www.emacswiki.org/wiki.pl` ✓

23. *DONE* Fix upload of images and serving their static copies.

24. *DONE* Pass the REMOTE_ADDR from nginx to Apache, possibly under another name?

emacsmirror

change made

http://www.emacswiki.org/emacs/A

Comments

(Please contact me if you want to remove your comment.)

I remember having issues with mod_perl many years ago, with extra characters being loaded. Been too long since I dealt with it, so memory is foggy. There was a script somewhere that kept sending extra data, hence the 404s. I’ve switched to nginx - for a long time now - and the transition from apache was relatively quick and painless.

I suspect you might need to tweak your perl scripts, and see if there’s been any changes to FCGI and/or CGI in perl, find ways to optimise further.

– Eric 2015-01-01 21:32 UTC

Eric

---

Yeah, right now it seems easier to tune nginx as a caching proxy and simply keep the wiki running as a CGI script when some requests should get a fresh response. And skip all of the FCGI or mod_perl trouble.

– Alex Schroeder 2015-01-02 12:11 UTC

Alex Schroeder

---

I know it’s probably too late for this but have you considered rtfd.org? It’s fantastic due to the search quality (elasticsearch).

– Anndy 2015-01-16 16:53 UTC

---

Hm, it looks like a very different thing from a wiki where anybody can edit anonymously, right?

– Alex Schroeder 2015-01-16 18:05 UTC

---

Yeah that’s true. You’d need a github account to edit the source. Depending on how much content is added anonymously this might be ok (or might not be). I love rtfd because it’s got awesome search and navigation is also easy.

– Anndy 2015-01-18 22:17 UTC