d8sychain

Members
  • Posts

    56
  • Joined

  • Last visited

Everything posted by d8sychain

  1. Searching Google suggests that '$wgVirtualRestConfig' in 'LocalSettings.php'. However if you're using my docker it will be in a different file 'LocalSettings_Extensions.php' https://m.mediawiki.org/wiki/Manual:$wgVirtualRestConfig Here is what mine looks like just as an example. $wgVirtualRestConfig['modules']['parsoid'] = array('url' => 'http://localhost:8142','domain' => 'localhost','prefix' => '') ;
  2. Extension:DarkMode show MediaWiki version 1.38+. Skin:DarkVector specifies using a different branch for MediaWiki depending on the version "(for MW 1.39 and above use mw-1.39 branch, for MW 1.34 and below use mw-1.34 branch)" This docker image is MediaWiki version 1.33.1 and PHP version 7.3.10
  3. @Eddyall I looked at the extension, from what I can tell it is for MediaWiki version 1.37.0 and above. So unless you've updated the MediaWiki version that is packaged in the docker container then it's probably not compatible.
  4. Did you you download the extension files and put them in the correct file path? Mediawiki doesn't import an extension, it just loads it.
  5. I would like to, but given all of my other obligations at the moment, I unfortunately don't see it happening any time soon. Changing to a newer version of Mediawiki is the easy part, testing and debugging any issues is the time consuming part, and since it's at least stable, I'd rather not push updates and potentially break things without thorough testing. A big change in Mediawiki a version or two ago was they ported the Visual Editor to PHP. Which means there are few things in the docker that is no longer needed to get Visual Editor working, and probably a few changes that need to be made. Testing takes time that I don't have to spare at the moment. Sorry everyone, one day... I haven't abandoned it.
  6. I just got Mayan-EDMS running a few hours ago, although I have only tested it with consuming one file in a monitored folder. This might help
  7. 1. Installing Docker Compose Add the following to /boot/config/go in order to install docker-compose on each boot: COMPOSE_VERSION=$(curl -s https://api.github.com/repos/docker/compose/releases/latest | grep 'tag_name' | cut -d\" -f4) curl -L https://github.com/docker/compose/releases/download/${COMPOSE_VERSION}/docker-compose-`uname -s`-`uname -m` -o /usr/local/bin/docker-compose chmod +x /usr/local/bin/docker-compose 2. Persisting user-defined networks By default, UnRAID will not persist user-defined Docker networks. You'll need to enable this setting in order to avoid having to re-run docker-compose up -d every time your server is rebooted. It's found in the Settings tab, [Server-IP/Settings/DockerSettings] You'll need to set Advanced View to On and disable the Docker service then Apply to make the change. Set Preserve user defined networks: Yes Enable Docker: Yes Apply 3. Prep for Mayan-EDMS Connect to Unraid with a SSH terminal or use the WebGUI console terminal Execute each line: mkdir /mnt/user/appdata/mayan-edms cd /mnt/user/appdata/mayan-edms curl https://gitlab.com/mayan-edms/mayan-edms/-/raw/master/docker/docker-compose.yml -O nano .env Edit the .env file and add the following: MAYAN_APP_VOLUME=/mnt/user/appdata/mayan-edms/media MAYAN_REDIS_VOLUME=/mnt/user/appdata/mayan-edms/redis MAYAN_POSTGRES_VOLUME=/mnt/user/appdata/mayan-edms/postgres To confirm cat .env You will most likely need to edit the docker-compose.yml changing at least the default port number ports: - "80:8000" To something like ports: - "8002:8000" 4. Launch the Mayan EDMS Docker Compose containers docker-compose --file docker-compose.yml --project-name mayan up --detach Initial Thoughts... I have been using Paperless-ng (a fork of the original Paperless project) for a few weeks and following its development. There are several promising features in the works (at the time of writing this). Over all Paperless-ng is simple to use and effective at what currently does. That being said its not packed with features like some of the other DMS out there. There isn't much I can say about Mayan-EDMS in comparison to Paperless-ng, seeing how I have had this running for maybe an hour. My initial thoughts are Mayan-EDMS is PACKED with features and customization. However, its all a little bit overwhelming and not as intuitive to setup and just start using like Paperless-ng is. Summary If you're an individual or even a small business like a freelancer / one-person-show, Paperless-ng is probably a good choose for you. If you're a bigger operation and need features like multi-user environment with roles and permissions, document versioning, digital signatures, collaboration tools, then Mayan-EDMS or maybe another DMS is probably better suited for you. I plan on continuing to try out Mayan-EDMS and may update this if my opinions on Mayan change any If you're interested in the history of Mayan-EDMS and its creator then this is a good watch YouTube: FLOSS Weekly 253: Mayan EDMS
  8. This Elasticsearch docker version is built from the official Elasticsearch docker with minimal changes tailoring it for easier use on Unraid and for the purpose for use with Nextcloud. *Minimal support will be provided for this docker. 99% of this docker is based from the Elasticsearch official docker https://hub.docker.com/_/elasticsearch with very minimal charges made. Example of provided support: Requesting that the base image get bumped to a newer version of Elasticsearch and tested before releasing Help with installation incase something in the directions are not clearly understood. Installation Directions below MUST be used in order to get Elasticsearch 5 and above working correctly. Directions: 1. Install CA User Scripts 2. Create a new script named vm.max_map_count 3. Contents of script as follows: #!/bin/bash sysctl -w vm.max_map_count=262144 4. Set script schedule to At Startup of Array. 5. Add the docker container. If you are using this for Nextcloud then continue... The ingest-attachment plugin is added by default at the 1st start of the container 6. Browse to the Admin UI in Nextcloud and config according https://github.com/nextcloud/fulltextsearch/wiki/Basic-Installation. 7. Browse to the Unraid docker tab, click the nextcloud docker icon then Console or Open a SSH Terminal (like PuTTY) and login in to your Unraid server and bash into the container docker exec -it nextcloud /bin/bash. If you are using linuxserver.io's Nextcloud docker the user is abc otherwise the default is www-data and the path to occ is /config/www/nextcloud/ 8. Enter: nextcloud default sudo -u www-data php <path/to/nextcloud install>/occ fulltextsearch:index linuxserver.io nextcloud docker sudo -u abc php /config/www/nextcloud/occ fulltextsearch:index 9. And wait... This can take a while depending on the number of files in your nextcloud server. The following is an excerpt from https://github.com/nextcloud/fulltextsearch/wiki/Commands fulltextsearch:index This is the main command of the app, which is used to index your content. You will need to use this command to index your files at least once. To start your first index: ./occ fulltextsearch:index Options can be pushed using JSON: user/users: user/array of users that will be indexed. provider/providers: provider/array of providers that will be used to retrieve content of the Nextcloud. path: location, can be a file or a folder. Used by the Files content provider only. Limit the index to the files from this location. If the file or folder does not exist, the index will be over. paused: true/false. If set to true, index will start paused. errors: reset Reset the errors ./occ fulltextsearch:index "{\"user\": \"cult\", \"providers\":[\"files\", \"test\"]}" Adding and removing plugins In the docker volume host path, the default is /mnt/user/appdata/elasticsearch contains file my-plugins.txt Edit this file, adding and/or removing needed plugins, and then restart the container. A built-in script will check this file at container start and compare it to the currently installed plugins and install and/or remove plugins accordingly.
  9. BTW to everyone, The MediaWiki Maintenance utility has be in d8sychain/mediawiki:edge since it was published. The current 'Edge' version (2020-02-19 v1.33.2-db8 yep almost be a year) is considered finalized as far as I'm concerned. The only reason I never merged it into 'Latest' was because I never finished all of the documentation explaining the added features and their instructions and updating any instructions that may have changed. From SSH terminal, login to UnRaid, then 'docker exec -it docker name /bin/bash' then 'maintenance' or On the UnRaid UI go to the Docker page and click the icon for the MediaWiki docker, then click Console, type 'bash', then 'maintenance' Highlights for v1.33.2-db8: Bumping to Alpine v3.11 (lsiobase/nginx:3.11) Added OPTION to add MariaDB(MySQL) built into the container, providing a one-container-does-all, or you can run a separate MariaDB(MySQL) server (NEW FEATURE) MediaWiki Maintenance CLI Menu (NEW FEATURE) ExtensionManager (ENHANCED FEATURE) Backup functions (NEW FEATURE) Database functions (NEW FEATURE) Services functions (NEW FEATURE) MediaWiki file upload, logo, favicon settings changed see Change Log for details
  10. @EwanL Fixing the extension will be easy 😁 1) On the UnRaid UI go to the Docker page and click the icon for the MediaWiki docker, then click Console 2) Type 'bash' enter, then 'maintenance' enter then you should see this: BTW: Feel free to make a backup before continuing. 3) You want to Option: 1) Extension Manager and then Option: 3) Remove Extension 4) Find the MobileFrontend extension in the list and enter the number for it then press enter again to skip Verbose (done, this removes all the files and any lines in the LocalSettings.php that contain the extension) 5) Choose Option: 1) Add wfLoadExtension Type 6) Enter the extension name 'MobileFrontend' (must be typed/enter just as it is on the extension page case sensitive) 7) Configure the extension according to the extension's instructions (you can probably skip this since that should have previously be done and should still be there) And that's it for the extension, this will get the branch version that matches what you are using e.g. 1.33 and include the 'wfLoadExtension( 'MobileFrontend' );' in the LocalSettings.php Now for the hard part, the skin. (It's on my todo list to make scripts to automate managing skins, but at the time that I write all of the scripts for the MediaWiki Maintenance utility I didn't care about skins, just extensions.) So the MinervaNeue skin version that you need can be found here https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/MinervaNeue/+/refs/heads/REL1_33 1) Go to the folder for the MinervaNeue e.g. appdata/mediawiki/www/mediawiki/skins/MinervaNeue 2) Delete all of the folders contents 3) Download this: https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/skins/MinervaNeue/+archive/refs/heads/REL1_33.tar.gz 4) Extract the tar to the MinervaNeue folder 5) Configure the skin according to the extension's instructions (you can probably skip this since that should have previously be done and should still be there) Hopefully I didn't leave anything out.
  11. From the MediaWiki MobileFrontend extension page (https://www.mediawiki.org/wiki/Extension:MobileFrontend) The following skins are compatible with MobileFrontend: Skin:Minerva Neue (stable, default on WMF wikis) Skin:Vector (default desktop skin, uses an experimental responsive mode for mobile) Skin:Timeless (experimental skin) To start with, its probably best if you undo what you've tried so far. With out going into a step by step, what changes did you make and I'll try to advise the quickest/easiest way to undo them, unless you just want to yourself.
  12. I did a quick test and put MobileFrontend and the MinervaNeue skin on one of my 'production' wikis. It works with out any errors, however the skin doesn't seem to work correctly, as in, the page loads but any link/action doesn't respond. That could just be due to something not configured, I didn't look that deeply into it. I can say that the mobile Timeless skin works as far as viewing pages but you can't edit. With all of that being said. I can walk you through getting the extension and skin loaded if you want. (Saving myself from explaining each step incase you're not still interested😁. If you are though, I'll gladly help you.)
  13. @EwanL if I remember correctly that skin used to be built into the MobileFrontend extension until 1.34 and then it was removed and needed to be installed separately. So with 1.33 you just need the extension. I'd have to double check to be sure though.
  14. @KDP I realize it might be a little late for this, but MW has an Export pages and Import pages feature. They're listed under 'Special pages'. You can export pages, modules, ect as a XML file and then import it to a different wiki.
  15. Looks like I might need to brush the dust off of the project, make some changes and put out a MW v1.35. It comes with some nice changes to the MW core. Now that Parsoid has been ported to PHP, Node.js is no longer needed and can be dropped from this docker. Also MediaWiki 1.35 is the current stable long-term support release of MediaWiki and its end-of-life will be September 2023 https://www.mediawiki.org/wiki/Version_lifecycle In addition Alpine 3.12 was released May 2020
  16. @KDP The log looks normal. I don't see that it is trying to serve any pages. Example, after the last line in your log file should be followed with something like this: {"log":"- - 19/Oct/2020:03:40:00 +0000 \"GET /Main_Page\" 200\n","stream":"stderr","time":"2020-10-19T03:40:01.934684746Z"} {"log":"- - 19/Oct/2020:03:40:01 +0000 \"GET /load.php\" 200\n","stream":"stderr","time":"2020-10-19T03:40:02.644460091Z"} {"log":"- - 19/Oct/2020:03:40:01 +0000 \"GET /load.php\" 200\n","stream":"stderr","time":"2020-10-19T03:40:08.060153582Z"} {"log":"- - 19/Oct/2020:03:40:08 +0000 \"GET /load.php\" 200\n","stream":"stderr","time":"2020-10-19T03:40:08.771861407Z"} Might need to look at the NGINX log file also. Side note, if you are not to invested into this docker yet, you might want to try a different vision d8sychain/mediawiki:edge https://github.com/d8sychain/docker-mediawiki/tree/edge There are quite a few improvements to it vs d8sychain/mediawiki:latest. I never merged with 'latest' because basically I never finished updating the documentation that goes along with it.
  17. Get the Container ID number (you can this in the UnRaid UI docker tab, shown in advanced view) Use the following: cp "$(find /var/lib/docker/containers -name "Container ID*.log")" /mnt/user/appdata The log file will be located in the appdata folder
  18. The email issue sounds like an issue with the mediawiki code itself maybe. The issue with web access to mediawiki, I might be able to help, but I'm going to need some logs or some more info to go on.
  19. I'm really just guessing, but perhaps your issue is a combination with DNS, routing, and Cert matching. Have you tested connecting to the wiki internally (LAN) vs externally (WAN)? Can you provide some more details on your setup, PM me if you prefer.
  20. I did a quick search and from what I found SSL_ERROR_RX_RECORD_TOO_LONG is something that occurs exclusively on Firefox. This might help also -> https://cheapsslsecurity.com/blog/ssl_error_rx_record_too_long/ LetsEncrypt Wiki Config #wiki reverse proxy server { listen 443 ssl; root /config/www; index index.html index.htm index.php; server_name wiki.example.com; ssl_certificate /config/keys/letsencrypt/fullchain.pem; ssl_certificate_key /config/keys/letsencrypt/privkey.pem; ssl_dhparam /config/nginx/dhparams.pem; ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA'; ssl_prefer_server_ciphers on; client_max_body_size 0; location / { include /config/nginx/proxy.conf; proxy_pass http://UNRAID IP:PORT #; } }
  21. @Shirkie I'm sorry I haven't gotten back sooner. I'm in the middle of a large remodel/construction project in between my day job and everything else. I haven't touched development on this since February, so it's going to take me a min to get my head back into the code re-familiarize myself with it and I just don't have the time to do so right now. I have newer code / version, that has quite a few improvements and features than the "latest" build. Its version is "edge". I never merged the new code due to I hadn't finished updating all of the documentation that goes along with it. That being said, if you use the "edge" version it should eliminate any permission problems that your having. I've done quite a bit of testing and use "edge" version in 3 wiki projects of my own, and "edge" is solid with several built in tools/features to ease managing to mediawiki docker, it just lacks the updated documentation on how to use said features. Highlights: Bumping to Alpine v3.11 (lsiobase/nginx:3.11) Added OPTION to add MariaDB(MySQL) built into the container, providing a one-container-does-all, or you can run a separate MariaDB(MySQL) server (NEW FEATURE) MediaWiki Maintenance CLI Menu (NEW FEATURE) ExtensionManager (ENHANCED FEATURE) Backup functions (NEW FEATURE) Database functions (NEW FEATURE) Services functions (NEW FEATURE) MediaWiki file upload, logo, favicon settings changed see Change Log for details If you are not to invested in the current docker version for your wiki, I suggest starting with a fresh version of "edge" -> d8sychain/mediawiki:edge. It is possible to change over from "latest" to "edge", but there are some manual steps have to be taken, like deleting some files so that they get replaced with newer versions. They won't get replaced automatically just in case the end user has made any customization to the files to fit their specific needs , such as the NGINX config file.. If you have anymore problems or questions, don't hesitate to ask. I'll do what I can to answer them, just bare with my time constraints at this time.
  22. I'll try to get back with you tomorrow evening.