values.yaml Documentation

1. Project Overview & Quickstart (requarks/values.yaml) Copy Chapter

values.yaml

Open-source repository requarks/values.yaml

Repository Details Copy Section

• Repository: requarks/values.yaml
• Primary Language: Code

Note: High-volume repository documentation is actively indexed and synchronized by YakaAI.

2. Official Technical Reference & Guides (requarks/docs) Copy Chapter

File: wiki/admin-guide/install-debian-8.md Copy Chapter

This installation guide is based on a new Debian 8 instance from DigitalOcean / Vultr.

Create user

Let's create a new user for running Wiki.js: adduser wiki

Install MongoDB

Follow the official installation guide: https://docs.mongodb.com/manual/tutorial/install-mongodb-on-debian/

Install Git

The latest git package available for Debian 8 is outdated and cannot be used. We'll compile the latest release from source.

It is recommended to use the latest version available by looking at the https://github.com/git/git/releases page.
Simply replace the version number in the instructions below.

# Remove existing git package: 
apt-get remove git

# Install build requirements:
apt-get install libcurl4-openssl-dev libexpat1-dev gettext libz-dev libssl-dev build-essential autoconf

# Fetch and build Git
cd /tmp
curl -L --progress https://github.com/git/git/archive/v2.13.1.tar.gz | tar xz
cd git-2.13.1/
make configure
./configure
make prefix=/usr/local all
make prefix=/usr/local install

# Confirm this command returns /usr/local/bin/git:
which git

Install Node.js

Install the LTS version of Node.js:

curl -sL https://deb.nodesource.com/setup_6.x | bash -
apt-get install -y nodejs

Install sudo

If sudo is already installed and configured, skip this step.

1. Install sudo: apt install sudo
2. Add the wiki user to sudo group: adduser wiki sudo
3. Edit the sudoers file: nano /etc/sudoers
   • Add the following line wiki ALL=(ALL:ALL) ALL right after %sudo ALL=(ALL:ALL) ALL
   • Ctrl-X to save.
4. Disconnect from your SSH / Terminal session and reconnect.

Install Wiki.js

1. Login as the wiki user: sudo -i -u wiki
2. Create a folder to install Wiki.js: mkdir wiki
3. Go inside the folder: cd wiki
4. Install Wiki.js: curl -sSo- https://wiki.js.org/install.sh | bash
5. Follow the instructions to complete the installation.

File: wiki/admin-guide/manage-access-rights.md Copy Chapter

What are access rights?

When you create or authorize a user in the system, that user has read-only permissions on all pages. Access rights is a list of permissions that are assigned to a user which define what he can or cannot do.

View access rights

From the Users page, click on the name of the account you want to view.

A section is titled Access Rights, which lists the current access rights of the user:

Manage access rights

A user can have as many access rights as needed. For example, you may want the user to be able to read any page but only create / edit a few. An access right rule consists of 4 parts:

• Permission: Defines what the user can do.
• Path precision: Whether the path entered should match precisly (Path match exactly) or only match the beginning (Path starts with).
• Path: The actual path
• Allow / Deny: Allow means the rule will be applied. Deny means the user will not be able to access the page.

By default, a user has Read Only (permission) to all pages that starts with (path precision) the path / (path).

To allow a user to create and edit any page on the site, simply change that permission to Read and Write.

Add a new rule Copy Chapter

To provide granular access to a user, you can add as many rules as you need. Rules are additive, with the Deny action having priority.

Given this example:

• The user can read any page, with the exception of all pages that starts with /violin.
• The user can edit (and create) the page /piano, but not /pianos or /piano/studio-grand
• The user cannot read, create or edit any page that begins with /violin. Therefor, he can read the page /viola but not /violin/strings

Click Save Changes to save the new rules.

Remove a rule Copy Chapter

Simply click the red X button next to the rule to delete.

Click Save Changes to save the updated rules.

File: wiki/admin-guide/manage-users.md Copy Chapter

List all users

• Click on Account from the sidebar.
• Click on Users from the sidebar.

A list of all users authorized to login will be displayed.

Create a new local user

A local user is stored in the Wiki.js database. This authentication method is enabled by default and is used for the root administrator.

To create a new user, click on the Create / Authorize User button in the top right corner of the Users page.

Fill in the fields and click Create User.

Authorize a social user

A social user is authenticated using Microsoft, Google or Facebook login mechanisms. It provides convenience for users by not having to remember yet another login.

To authorize a social user to login to Wiki.js, click on the Create / Authorize User button in the top right corner of the Users page.

Fill in the email address of the user and select the social provider in the Provider dropdown menu.

Finally, click the Authorize User button.

Edit a user

To edit information about a user, click on its name from the Users page list.

Note that the email address cannot be modified as this is the unique identifier of the user. If the email address of a user changed, you must create a new account and delete the old one if necessary.

Read the Manage Access Rights page to learn how to provide the necessary access rights to a user.

Delete a user

To delete (or de-authorize) a user, click on its name from the Users page list.

Click on the red Delete Account button at the bottom right of the page.

File: wiki/admin-guide/setup-nginx.md Copy Chapter

Below are example configurations that can be used as a reverse proxy setup for Wiki.js.

Sample NGINX configurations

HTTP reverse-proxy example Copy Chapter

server {
	listen 80;
	listen [::]:80;
	server_name  wiki.example.com;

	location / {
		proxy_set_header Host $http_host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_pass http://127.0.0.1:3001;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_next_upstream error timeout http_502 http_503 http_504;
	}
}

HTTPS reverse-proxy example Copy Chapter

server {
	listen 443 ssl http2;
	listen [::]:443 ssl http2;
	server_name  wiki.example.com;

	ssl_session_timeout 1d;
	ssl_session_cache shared:SSL:50m;
	ssl_session_tickets off;

	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH EDH+aRSA !RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS";
	ssl_prefer_server_ciphers on;

	ssl_certificate /etc/nginx/ssl/wiki.example.com/fullchain.pem;
	ssl_certificate_key /etc/nginx/ssl/wiki.example.com/privkey.pem;
	ssl_trusted_certificate /etc/nginx/ssl/wiki.example.com/chain.pem;

	location / {
		proxy_set_header Host $http_host;
		proxy_set_header X-Real-IP $remote_addr;
		proxy_pass http://127.0.0.1:3001;
		proxy_http_version 1.1;
		proxy_set_header Upgrade $http_upgrade;
		proxy_set_header Connection "upgrade";
		proxy_next_upstream error timeout http_502 http_503 http_504;
	}
}

File: wiki/docker/compose.md Copy Chapter

Prerequisites

• Docker

Create config file

1. Create a copy of the sample config file on your host.
2. Modify the config file with your own settings.

Make sure to set the db parameter to point to the mongo container. In the example docker compose file, the mongo container is named wikidb. As such, the db connection string should be set to: mongodb://wikidb:27017/wiki

Create Docker Compose file

1. Create a copy of the sample Docker Compose file.
2. Change the ports port to match the port entered in your config.yml file.
3. Replace the WIKI_ADMIN_EMAIL parameter value with the email of the administrator account. This account will be created when run the first time.
4. Replace the ./config.yml value with the path of your config file created earlier. It will be linked to your docker container. Do not change the path of the config file inside the container (/var/wiki/config.yml)!
5. Change the local path of the MongoDB data folder (./data/mongo) if necessary. Do not change the path of the data folder inside the mongo container (/db/data)!

Run the container

It's now time to run the containers as defined in the previous step:

sudo docker-compose up

First login

An administrator account is created the first time you run the container. The default password is admin123. Change it upon login!

File: wiki/docker/dockerfile.md Copy Chapter

Prerequisites

• Docker
• A MongoDB database server (either running inside another container or on a remote machine)

Create config file

1. Create a copy of the sample config file on your host.
2. Modify the config file with your own settings.

Create Dockerfile

1. Create a copy of the sample Dockerfile.
2. Replace the WIKI_ADMIN_EMAIL parameter value with the email of the administrator account. This account will be created when run the first time.
3. Replace the your-config.yml value with the name of your config file created earlier. This file must be located in the same folder as your Dockerfile if not providing the full path. It will be copied inside your docker container.
4. Change the EXPOSE port to match the port entered in your config.yml file.

Build the image

From a command prompt in the same folder as your Dockerfile, execute the following command to build your Dockerfile:

sudo docker build -t wiki .

Run the container

It's now time to run the container from the image created in the previous step:

sudo docker run -p 8080:3000 wiki

The -p parameter above is optional. Define it if you want to re-map the exposed port to something else.

First login

An administrator account is created the first time you run the container. The default password is admin123. Change it upon login!

File: wiki/install/authentication.md Copy Chapter

{.pagelogo}

Wiki.js supports multiple authentication providers. You may choose to enable one, some or even all of them.

:warning: You must have at least 1 provider enabled as edits can only be performed while authenticated.
{.is-warning}

Local

The local provider stores user accounts in the wiki database. It does not rely on any 3rd party service and accounts are unique to your wiki.

This is the most simple solution and is enabled by default.

Microsoft Account

The Microsoft Account provider lets users login using their own Microsoft account.

1. Go to https://account.live.com/developers/applications/index
2. Create a new application (e.g. Wiki).
3. Under Properties, take note of the generated Application Id.
4. Under Application Secrets, click on Generate New Password. Take note of the provided password! It will not be shown again.
5. Under Platforms, click on Add Platform. Choose Web.
6. A Redirect URIs field just appeared. Enter the full URL of your wiki followed by /login/ms/callback as e.g.: https://www.example.com/login/ms/callback
7. Under Microsoft Graph > Delegated Permissions, click Add.
8. Find entry User.ReadBasic.All and check it, then click Ok. You should now have both User.Read and User.ReadBasic.All listed.
9. (optional) Add a logo, terms of service and privacy statement URLs if needed.
10. Click Save.

Under the auth section of your config.yml, you can now enter the required info:

microsoft:
  enabled: true
  clientId: YOUR_APPLICATION_ID
  clientSecret: YOUR_APPLICATION_PASSWORD

Google ID

The Google ID provider lets users login using their own Google ID.

1. Go to https://console.cloud.google.com/
2. Create a new Project (e.g. Wiki).
3. From the sidebar menu, click API Manager.
4. Click on the Enable API button.
5. Enable the Google+ API.
6. From the sidebar menu, click Credentials.
7. Under the OAuth consent screen tab, fill in the required info and click Save.
8. Back to the Credentials tab, click on Create credentials > OAuth client Id.
9. Choose Web Application and enter a name (e.g. Wiki).
10. Under Restrictions, enter the authorised origin domain of your wiki (e.g. https://www.example.com) and the authorised redirect URL (full URL of your wiki followed by /login/google/callback as e.g.: http://www.example.com/login/google/callback)
11. Click Create and take note of both the generated Client ID and Client Secret.

Under the auth section of your config.yml, you can now enter the required info:

google:
  enabled: true
  clientId: YOUR_CLIENT_ID
  clientSecret: YOUR_CLIENT_SECRET

Facebook

The Facebook provider lets users login using their own Facebook account.

1. Go to https://developers.facebook.com
2. Choose 'Add a New App'
3. Your app id should be clearly visible on the top of the page. To get your app secret, go to the 'Dashboard' and click 'Show' next to the starred-out secret
4. You can now test logging in with your own account and users you explicitly give access. To open up logging in via your app to everyone, make your app 'public' under 'App Review'.

Under the auth section of your config.yml, you can now enter the required info:

facebook:
  enabled: true
  clientId: YOUR_FACEBOOK_APP_ID
  clientSecret: YOUR_FACEBOOK_APP_SECRET

GitHub

The GitHub provider lets users login using their own GitHub account.

1. Go to https://github.com/settings/applications/new
2. Enter an Application Name (e.g. Wiki).
3. Enter the Homepage URL to your wiki.
4. In the Authorization Callback URL field, enter the full URL of your wiki followed by /login/github/callback (e.g.: http://www.example.com/login/github/callback).
5. Click on Register Application.
6. Take note of both the generated Client ID and Client Secret.
7. (optional) Upload a logo for your application.

Under the auth section of your config.yml, you can now enter the required info:

github:
	enabled: true
	clientId: GITHUB_CLIENT_ID
	clientSecret: GITHUB_CLIENT_SECRET

Slack

The Slack provider lets users login using their own Slack account.

1. Go to https://api.slack.com/apps
2. Click on Create an App.
3. Enter a name under App Name (e.g. Wiki) and select a Development Slack Team.
4. Click on Create App.
5. In the left sidebar, navigate to OAuth & Permissions.
6. Under Redirect URLs, click Add a New Redirect URL and enter the full URL of your wiki followed by /login/slack/callback (e.g.: http://www.example.com/login/slack/callback).
7. Click Add and then Save URLs.
8. Under Permissions, add the following scopes: identity.basic and identity.email
9. Save Changes and navigate to Basic Information in the left sidebar.
10. Take note of the Client ID and Client Secret shown under App Credentials.
11. (optional) Upload a logo and customize the look and description of your app.

:warning: Quote your slack client ID otherwise it will be treated as float instead as a string and this will cut it off.
{.is-warning}

Under the auth section of your config.yml, you can now enter the required info:

slack:
	enabled: true
	clientId: SLACK_CLIENT_ID
	clientSecret: SLACK_CLIENT_SECRET

LDAP (Active Directory)

The LDAP provider lets users login using their LDAP / Active Directory account.

This provider is only for classic LDAP / Active Directory systems, it is not compatible with Azure Active Directory. Use the Azure Active Directory provider instead (coming soon).

Under the auth section of your config.yml, enter the required info:

ldap:
	enabled: true
	url: ldap://serverhost:389
	bindDn: cn='root'
	bindCredentials: BIND_PASSWORD
	searchBase: o=users,o=example.com
	searchFilter: (uid={{username}})
	tlsEnabled: false
	tlsCertPath: C:\example\root_ca_cert.crt

The searchFilter option has a variable {{username}} which contains the value entered by the user during login. You can use this variable however you want in your searchFilter expression.

For Active Directory, you should usually use the samaccountname in the searchFilter, e.g.: (samaccountname={{username}})

The user must have an email address associated with the account, or sign in will fail. This holds true regardless of searchFilter configuration.

Azure Active Directory

The Azure AD provider lets users login using their Azure Active Directory (AAD) account.

This provider is only for Azure AD, it is not compatible with LDAP / classic Active Directory. Use the LDAP (Active Directory) provider instead.

1. Login to your Azure AD Portal.
2. Click on Azure Active Directory.
3. On the left menu bar, select App Registrations.
4. Create a new application integration with New application registration.
5. Name it something useful like Wiki and make sure the application type is Web app / API.
6. Your Sign-on URL will be the full domain of your Wiki followed by /login/azure/callback.
   e.g https://portal.example.com/login/azure/callback
7. Click Create.
8. You will then see your application in the App registrations menu. Click on it.
9. The Application ID will be given to you. Add this to your config.yml as clientId.
10. A private app key will need to be generated now. Under Settings there will be a Keys option. Click on that. There should be no keys present. Write in a description for the key in Key Description and set a Duration. Something like wiki_priv and Never expires is fine.
11. Click Save. Your private key will now be generated. Copy the key's value and add it to clientSecret in your config.yml. Be careful to note this down as this will be the only time that you see it.
12. Make sure that in Reply URLs it contains your https://portal.example.com/login/azure/callback or the integration won't work. You must be using SSL on your Wiki site for Microsoft to allow the API integration.
13. Check to make sure that correct permissions have been granted. Under the App Registration Settings, select the Required Permissions option. Select the Windows Azure Active Directory object. From here, make sure that Sign in and read user profile under Delegated Permissions is ticked.
14. Your tenant ID is your example.onmicrosoft.com. Note: your regular domain example.com will not work here as it needs to be the Microsoft Azure AD name. Alternatively, you can find your tenant ID string via Azure Active Directory -> Properties -> Directory ID.

azure:
	enabled: true
	clientId: YOUR_CLIENT_ID
	clientSecret: YOUR_CLIENT_SECRET
	resource: '00000002-0000-0000-c000-000000000000'
	tenant: YOUR_TENANT_ID_OR_AD_DOMAIN

Note: If you are receiving a User Email Not Found error from Wiki.js after trying to login with your Azure AD Credentials, this is a known bug and being worked on. The bug is described here and a solution is provided in the thread.

File: wiki/install/configuration.md Copy Chapter

{.pagelogo}

The configuration file is automatically generated for you during the Configuration Wizard.
You may however change settings or additional options not shown during the wizard, based on the list below.

The configuration file is located at the root, named config.yml. Environment variables can be used to set property values with the syntax $(ENV_VAR_NAME). Note that any changes will not be applied until Wiki.js is restarted.

General Site Settings

Authentication

Wiki.js offers various authentication providers that you can enable. See the authentication guide to learn how to get the necessary info for each provider.

Database

Git Repository

Wiki.js works with pretty much any Git repository. See the Git repository guide to learn how to get the necessary info from the most popular providers.

Features

You can enable / disable specific optional features.

Logging

By default, all logs are stored locally in the /logs directory. You can send logs to additional remote logging services:

File: wiki/install/database.md Copy Chapter

{.pagelogo}

MongoDB

MongoDB is a free and open-source cross-platform document-oriented database program. Classified as a NoSQL database program, MongoDB uses JSON-like documents with schemas.

:information_source: MongoDB 3.2 or later is required.

• Official Website
• Installation Guide

It can safely be installed on the same server as Wiki.js. MongoDB is mainly used for users and content metadata, which is very light on server resources usage.

Replica Set / Sharded Cluster installations are fully supported.

Should you prefer on having a cloud provider host the MongoDB instance for you, here's a few examples:

• MongoDB Atlas
• mLab
• Compose (IBM)
• ObjectRocket (rackspace)

 :warning: Cloud Provider Considerations

Make sure the MongoDB instance runs in the same datacenter (preferrably) or the same region. Connecting to instances located in another location will result in latency and poor performances!
{.is-warning}

Connection String

A MongoDB connection string is formatted as such:
mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]

Refer to the official MongoDB documentation for all the possible options.

You can also use an environment variable containing the MongoDB connection string, e.g:
$(MONGO_URI)

Examples

Using a local MongoDB instance (on the same server as Wiki.js):
mongodb://localhost:27017/wiki

A username/password protected instance on a single remote server:
mongodb://username:[email protected]:27017/wiki

A username/password protected instance on a remote cluster:
mongodb://username:[email protected]:27017,second.server.com:27017,third.server.com:27017/wiki