Wiki.js can't go through corporate proxy

Question

I'm new to Ubuntu, but I've got a job to install Wiki.JS with docker. It works, the server is running, but for some reason it cannot reach GraphQL API.

I've ran into the following problem:

---

Server:

2020-06-14T11:43:53.980Z [MASTER] error: Fetching latest updates from Graph endpoint: [ FAILED ]

2020-06-14T11:43:53.980Z [MASTER] error: request to https://graph.requarks.io failed, reason: connect ETIMEDOUT 104.26.14.122:443

2020-06-14T11:43:56.028Z [MASTER] error: Syncing locales with Graph endpoint: [ FAILED ]

2020-06-14T11:43:56.028Z [MASTER] error: request to https://graph.requarks.io failed, reason: connect ETIMEDOUT 104.26.15.122:443

Client:

Error: GraphQL error: Invalid locale or namespace

Stack trace:

n@http://server.mydomain.test/_assets/js/app.js?1591384357:2:125092
["./node_modules/apollo-client/bundle.umd.js"]/i/k</e.prototype.queryListenerForObserver/<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:146832
["./node_modules/apollo-client/bundle.umd.js"]/i/k</e.prototype.broadcastQueries/</<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:153007
["./node_modules/apollo-client/bundle.umd.js"]/i/k</e.prototype.broadcastQueries/<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:152971
["./node_modules/apollo-client/bundle.umd.js"]/i/k</e.prototype.broadcastQueries@http://server.mydomain.test/_assets/js/app.js?1591384357:2:152920
["./node_modules/apollo-client/bundle.umd.js"]/i/k</e.prototype.fetchRequest/</b<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:154884
["./node_modules/zen-observable/lib/Observable.js"]/j</<.value/</<.next@http://server.mydomain.test/_assets/js/app.js?1591384357:333:17099
b@http://server.mydomain.test/_assets/js/app.js?1591384357:333:14921
y@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15429
["./node_modules/zen-observable/lib/Observable.js"]/w</<.value@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15982
w/</n<.next/<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:140468
w/</n<.next@http://server.mydomain.test/_assets/js/app.js?1591384357:2:140430
b@http://server.mydomain.test/_assets/js/app.js?1591384357:333:14921
y@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15429
["./node_modules/zen-observable/lib/Observable.js"]/w</<.value@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15982
o/</</r<.next@http://server.mydomain.test/_assets/js/app.js?1591384357:2:169810
b@http://server.mydomain.test/_assets/js/app.js?1591384357:333:14921
y@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15429
["./node_modules/zen-observable/lib/Observable.js"]/w</<.value@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15982
["./node_modules/apollo-link-batch/lib/batching.js"]/o</e.prototype.consumeQueue/<.next/</<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:168733
["./node_modules/apollo-link-batch/lib/batching.js"]/o</e.prototype.consumeQueue/<.next/<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:168700
["./node_modules/apollo-link-batch/lib/batching.js"]/o</e.prototype.consumeQueue/<.next@http://server.mydomain.test/_assets/js/app.js?1591384357:2:168669
b@http://server.mydomain.test/_assets/js/app.js?1591384357:333:14921
y@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15429
["./node_modules/zen-observable/lib/Observable.js"]/w</<.value@http://server.mydomain.test/_assets/js/app.js?1591384357:333:15982
t/n.batcher<.batchHandler/</<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:165472
["./node_modules/core-js/modules/es.promise.js"]/J/<@http://server.mydomain.test/_assets/js/app.js?1591384357:2:450433
["./node_modules/core-js/internals/microtask.js"]/i@http://server.mydomain.test/_assets/js/app.js?1591384357:2:412213

---

Keep in mind, I've tested it before on Windows and my collegue on Linux. Both worked as long as the virtual machine didn't have proxy.. I tried to setup the proxy for the machine and set the environment variables but it still doesn't seem to work.

How can I fix this?

Answer 1

How I Got Around This Issue

I had the same issue with sideloading the data in an offline environment. To get around it I had to download (by zip) ALL of the locales from https://github.com/Requarks/wiki-localization not just the en.json and locale.json files. Then bring it to my offline server and add it to my sideload-data folder where my docker-compose is. Also I had to set the config.yml parameter offline: true.

Docker compose

version: "3"
services:
  db:
    image: postgres:11-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    logging:
      driver: "none"
    restart: unless-stopped
    volumes:
      - wiki-data:/var/lib/postgresql/data
    networks:
      - wiki-net
  wiki:
    image: requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
    restart: unless-stopped
    volumes:
      - ./config.yml:/wiki/config.yml
      - ./sideload-data/:/wiki/data/sideload/
    ports:
      - "3000:3000"
    networks:
      - wiki-net
networks:
  wiki-net:
volumes:
  wiki-data:

Troubleshooting tips:

-run docker compose up and see if there is an EACCESS error saying the data could not load, this could indicate that you need to elevate permissions on the folder in the container -create a new container if it's not showing when you docker exec into it

Answer 2

To explain the sideloaing solution with Docker offered by @GanjalfTheGreen, first you need to clone the Wiki.js localization repository (or download selected localizations from that repository; just make sure you have the locales.json and en.json alongside your selected items). Then you need to bind the folder containing the localization files to the /wiki/data/sideload directory inside the container.

Also you need to set the offline parameter in config.yml file to let the wiki.js know that it should use the sideloaded localization files. To do this, you neeed to create a config.yml file in the host machine and bind it to the container config file.

Here is an example:

docker-compose.json

version: "3"
services:

  db:
    image: postgres:11-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    logging:
      driver: "none"
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data

  wiki:
    image: requarks/wiki:2
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
      OFFLINE_ACTIVE: 1
    restart: unless-stopped
    ports:
      - "80:3000"
    volumes:
      - ./sideload:/wiki/data/sideload
      - ./config.yml:/wiki/config.yml

volumes:
  db-data:

config.yml

port: 3000
bindIP: 0.0.0.0
db:
  type: $(DB_TYPE)
  host: '$(DB_HOST)'
  port: $(DB_PORT)
  user: '$(DB_USER)'
  pass: '$(DB_PASS)'
  db: $(DB_NAME)
  storage: $(DB_FILEPATH)
  ssl: $(DB_SSL)
ssl:
  enabled: $(SSL_ACTIVE)
  port: 3443
  provider: letsencrypt
  domain: $(LETSENCRYPT_DOMAIN)
  subscriberEmail: $(LETSENCRYPT_EMAIL)
logLevel: info
ha: $(HA_ACTIVE)
offline: $(OFFLINE_ACTIVE)

Answer 3

The reason you won't be able to get Wiki.JS working behind a corporate firewall is that this functionality is not implemented.

Based on this GitHub issue you can vote for this feature here.

There is a workaround mentioned in the issue (1.), but you can also sideload the missing files (2.).

1. Workaround

I figured out a work around for this: use https://github.com/rofl0r/proxychains-ng with LD_PRELOAD. In my case, I am using docker-compose.

You have to:

• incorporate the compiled proxychains4.so in to /lib/ and set the environment variable
• create your own proxychains.conf

Here is an example:

Dockerfile

FROM requarks/wiki:2

USER root

ADD ./libproxychains4.so /lib/

RUN echo -e 'localnet 192.168.0.0/255.255.0.0\n\
[ProxyList]\n\
http <YOUR PROXY> <PROXY PORT>\n'\
> /etc/proxychains.conf

USER node

docker-compose.yaml

version: "3"
services:

  db:
    image: postgres:11-alpine
    environment:
      POSTGRES_DB: wiki
      POSTGRES_PASSWORD: wikijsrocks
      POSTGRES_USER: wikijs
    restart: unless-stopped
    volumes:
      - /data/wikijs/postgresql/data:/var/lib/postgresql/data

  wiki:
    image: wikijs-proxychains:1
    depends_on:
      - db
    environment:
      DB_TYPE: postgres
      DB_HOST: db
      DB_PORT: 5432
      DB_USER: wikijs
      DB_PASS: wikijsrocks
      DB_NAME: wiki
      LD_PRELOAD: /lib/libproxychains4.so
    restart: unless-stopped
    ports:
      - "80:3000"

2. Sideload

If your wiki is installed in an environment which is isolated from the internet, you can sideload data that would normally be downloaded from the internet.

This is achieved by manually downloading a set of files and placing them in a specific directory in your wiki installation. These files will be imported during initialization.

Getting Started Create a new folder at path data/sideload inside your Wiki.js installation folder. For example, if your wiki is installed at path /home/wiki, you'd need to create a folder at path /home/wiki/data/sideload

Locales In order to install locale packages, you need the master locale file + at least one locale package file.

The files can be downloaded from https://github.com/Requarks/wiki-localization. These files are made up to date every night.

1 - Master File

The master file locales.json contains information about all available languages and is REQUIRED to install any locale.

Place this file inside the sideload folder created previously.

2 - Locale Packages

The locale package file xx.json or xx-zz.json contains all the translations for the language(s) of your choice. You can sideload any number of locales at the same time.

The English package en.json is REQUIRED, as this is the default language during installation. You can change the language afterwards.

Place the file(s) inside the sideload folder created previously alongside the master file. You should now have locales.json, en.json and any additional languages in your folder.

3 - Sideload

Run Wiki.js (or restart the process if already running) to automatically sideload the files localed in the data/sideload folder.

Because of a bug in versions prior to 2.5, the locale files are loaded in incorrect order, causing the clients to be unable to fetch the translations.

As a workaround, once Wiki.js is fully started, restart the server again. The locale data (which is now in the database) will be loaded correctly. I've came around the same issue and will use BlueSpice MediaWiki as long as this feature has not been implemented, since Wiki.JS has "import from MediaWiki" on its roadmap.