Problem building sitemap

[almereyda]

After upgrading a Fedora system, a simple error helped me digging into SELinux and Systemd again.

Since the custom SELinux policies which had been in place for the local, systemd-governed nvm-wiki combination got reverted, the node process didn't have sufficient permissions anymore to fully interact with the flat file storage.

It became obvious when trying to start and access a localhost wiki and SELinux popping up with complaints. After half of them were solved, a newly created page was in browser cache rather than on the server.

An answer to circumvent the general SELinux tragedy with Node.js in a systemd environment can be found in https://github.com/almereyda/node-systemd-selinux

Additionally due to setting up .nvm and .wiki in the same home folder of the wiki user, but running via the init process, further policies apply. This scenario appears to be of a rare kind, why it is probably also the reason for running into such strict constraints.

module systemd-nvm-wiki 1.0;

require {
        type init_t;
        type user_home_t;
        class process execmem;
        class file { create execute execute_no_trans ioctl open read rename unlink write };
        class lnk_file { getattr read };
}

#============= init_t ==============

allow init_t self:process execmem;
allow init_t user_home_t:file { create execute execute_no_trans ioctl open read rename unlink write };
allow init_t user_home_t:lnk_file { getattr read };

Yet an inconsistent state appeared after resolving the different permission errors one after another.
The only usable hint was a console output that stated

Problem building sitemap: a-tempospatial--or-spatiotemporal--investigation e:  [SyntaxError: Unexpected end of input]

As one of the initial policy errors had also been related to the sitemap and a missing rename capability, only following the error message to https://github.com/fedwiki/wiki-server/blob/9ad81cb9f23c680c3a91e4676f704e3f6cb4f7d5/lib/page.coffee#L173 helped in understanding how this could be related to the suspicious Internal Server Error the wiki client displayed when trying to fetch the inconsistent state of the problematic page.

A more verbose error could have helped triaging the faulty storage file in question much faster.

[paul90]

Thank you for recording your experience with running wiki with SELinux.

Not sure that running node using nvm is the best route, outside of development, you might be best using the packaged version. This also allows you to use the standard tools to ensure that node is kept up to date.

A more verbose error could have helped triaging the faulty storage file in question much faster.

The error message you see is what was passed back when the operation failed. Nothing more is available there. Anything more is likely to be within SELinux audit logs, which is outside the scope of what we can do here.

Unless there is an error elsewhere that is getting swallowed, I'm not sure there is anything we can do here to help. Though of course, having recorded your experiences will help others following the same path.

[WardCunningham]

The client records journal actions as they are returned from the server. Should the server return a 500 error it usually means the action did not get recorded. The client recovers by annotating the action with an "error" field and saving the edit in browser local storage.

We don't try to explain these errors to the user because they are impossible to understand without detailed knowledge of our implementation and the protocols it uses. For developers, the Grep plugin is handy for exposing these when a site has been misbehaving.

http://ward.asia.wiki.org/grep-for-errors.html

[WardCunningham]

Explaining Grep For Errors a little more:

It will find pages that have errors recorded in their journal. You might want to know what the error was. This requires more digging.

You can see actions in their json form by clicking on an action and then double-clicking on the timestamp of the revision so retrieved. This requires guesswork to find the action with the error.

You can retrieve the full json text for a page from the json link in the page footer. Use your browser's text search to find "error" in this text. Using this technique I found one recorded error ward.bay.wiki.org:

      "id": "6d0590647712c41e",
      "date": 1431797119637,
      "error": {
        "type": "error",
        "msg": "Internal Server Error",
        "response": "Server Ignoring move. Try reload."
      }

This tells me that some move got lost on 16 May 2015 when the server couldn't find the destination for the move. github

I've not experience the issues @almereyda describes but I wonder what responses might be recorded in his pages.