Issue with farm mode after upgrade

[cpjobling]

I just upgraded my copy of the wiki software using npm install -g wiki and now when I try to access any of the existing sites in my farm I just get 'Invalid host'.

I originally installed the wiki on a DigitalOcean droplet (Ubuntu 14.04 LTS) using these instructions.

Is there some extra configuration or flags that I am missing?

My startup script is

start on started networking
stop on stopping networking

respawn
env HOME='/root'

exec wiki -f -p 80

The wiki takes its data from the default /root/.wiki

I'm afraid I have no idea which version of the wiki I was using before the upgrade, but it was about two years old.

[WardCunningham]

Paul and I are looking at this now.

[paul90]

If the processing is failing, there should be something in the wiki log file. This can be found in /var/log/upstart/wiki.log.

[WardCunningham]

The error comes from the newest version of wiki expecting more configuration than earlier versions. As we convert from Mozilla Persona to other identity providers we find more is expected of server operators as far as registrations go. We intend to help.

Let me explain what we have uncovered today.

The error is reported by the farm logic in wiki (search) This says that the (virtual) site requested is not in the allowed list of domains. This is configured with the new "wikiDomains" configuration parameter.

Here I will list the relevant documentation.

• Wiki ReadMe
• Configuring Security

Wiki can now be configured with pluggable security modules for which we now have two, the old Persona module which will stop working at the end of November and the broadly applicable Passport module with support for Google, Twitter and GitHub logins.

• Passport Security ReadMe
• Configuring Passport

The issue of the "wikiDoamins" parameter is address, with examples, for each of the available Passport identity providers.

• Configuring Passport for Google
• Configuring Passport for Twitter
• Configuring Passport for GitHub

It is possible for farm operators to allow their site owners to login with Persona and then convert to the newly configured identity provider on their own. This requires running a one-time conversion script and configuring both Persona and Passport for the server.

We also provide a default security plugin that requires no configuration (other than wikiDomains, it seems) that does not support login leaving each site read-only.

Finally, we hope to provide more variations for login processes corresponding to the variety of ways that federated wiki can be used. Help us imagine what that might be by describing your specific needs and expectations.

[WardCunningham]

We had intended to support upgrade as a two step process: install wiki, configure it for login.

It would be helpful if a configuration that worked for a previous version would continue to work in some minimal way after step one. This means that we should assume some appropriately permissive read-only access in the absence of the "wikiDomains" parameter.

It might also be helpful if login attempts after step one would pop up the login dialog explaining that the site is read-only. It could include a note to administrators pointing to instructions for step two.

[paul90]

There is an updated version of the wiki package ([email protected]) that will behave better without the extra configuration.

Without configuration the wiki will start with the sites read-only, this is because we change the format of the file that stores ownership details, this means that without running the migration and configuring the security module that ownership fails in a safely. We change the format as the old file just stored the email address passed from Persona, while the new scheme needs different information depending on the identity provider used.

The "wikiDomains" parameter is added to both make the security configuration easier and block access from requests with spoofed host headers.

With the exception of Twitter the external identity providers require a know URL to return to as part of the login (the callback URL), and GitHub only allow a single URL, so we added the idea of a 'wikiDomain' to allow us to configure the security domain once and not need to add to the configuration as more wiki are created within that domain. This has the useful side effect that you will only need to login once to a single domain farm to edit your wiki sites.

[synesthesia]

I admit to struggling with this too. I have updated the wiki software, installed wiki-security-passportjs, set up Google, run the update to create owner.json in the status directory of each site on the farm, and created a config.json in the root of the farm (~/.wiki) that looks like the example in the passport readme. The wiki refuses to start in anything other than default security read-only mode.

[paul90]

Looking at the code I see it's not looking in ~/.wiki for a config file. Fix on its way.

[paul90]

Just published [email protected] to npm, this adds ~/.wiki/config.json as a place to look for configuration.

Alternatively wiki can be started with wiki --config ~/.wiki/config.json.

[synesthesia]

Thanks will update, test and report back