S3v3nD34dly51ns

so after some trial and error I was successfully able to get Odoo up and running. I have stumbled through this multiple times only due to the fact of my own errors. For those having issues I will attempt to break down the easiest way of installing and getting it running. However the only issue I am having is editing my site after processing it though NGINX, as it just sits there and rotates when accessing it through https: . 1. Installed a PostGRES15 instance named "odoo-DB" points to port 5499 2. Installed Odoo17, named the database, PW and user fields within the config file itself. 3. Following the directions that Eurotimmy put within the readme file which you can find here https://github.com/Eurotimmy/unraid-templates/blob/main/Odoo17/README.md (adjust IP address, ports and DB fields as necessary to meet your requirements) [options] addons_path = /mnt/extra-addons data_dir = /var/lib/odoo admin_passwd = admin db_host = 192.168.55.9 db_port = 5499 db_user = odoo db_password = odoo db_name = odoo ; csv_internal_sep = , ; db_maxconn = 64 ; db_name = False ; db_template = template1 ; dbfilter = .* ; debug_mode = False ; email_from = False ; limit_memory_hard = 2684354560 ; limit_memory_soft = 2147483648 ; limit_request = 8192 ; limit_time_cpu = 60 ; limit_time_real = 120 ; list_db = True ; log_db = False ; log_handler = [':INFO'] ; log_level = info ; logfile = None ; longpolling_port = 8072 ; max_cron_threads = 2 ; osv_memory_age_limit = 1.0 ; osv_memory_count_limit = False ; smtp_password = False ; smtp_port = False ; smtp_server = False ; smtp_ssl = True ; smtp_user = False ; workers = 0 ; xmlrpc = True ; xmlrpc_interface = ; xmlrpc_port = 8069 ; xmlrpcs = True ; xmlrpcs_interface = ; xmlrpcs_port = 8071 Copied the config file and adjusted accordingly (see above), once Odoo was installed. Went to Unraid>Tools>New Permissions and selected 'Shares' and chose 'appdata'. (Keep in mind to do this a little easier make sure that SMB is temporarily enabled for your appdata share folder). Let the new permissions run it's course (takes about 7-10 minutes, longer in some cases). Once it's finished using your text edited config file (I used Notepad++) save file as odoo.conf in appdata\odoo\config. *Note: This is just easier for me, however you can do all of this using the Unraid Terminal as Eurotimmy described above. 4. Start the Odoo17 container, click on the container and watch the Logs, everything should start populating. Once loaded go to the WebUI (http://your.internal.ip.address:port). Should see it has loaded up. 5. Log in with default credentials admin, admin. 6. Seeing as I Already have NGINX installed that points to http://internal.ip.address:8069, and also created an instance on my hosting service that points to https://my.domainname.com and NGINX creates it's SSL cert. 7. After first initial boot, do not forget to delete the -i base within the container Advanced Tab>Post Arguments and then restart your Odoo container. I have this also stop my database when I did this, so make sure to restart your DB if this happens. If everything is operating as it should, you should be able to access Odoo WebUI with no issues. Now the only problem I am having like I said earlier is everything works on the https: side of things with the only exception of the web editor. As soon as I click on 'Edit' on my site, it goes to a grey screen and just a spinning wheel. Now I've done a little digging and found several instances of this happening on earlier versions of Odoo and it's actually due to the configuration end on NGINX. Many report adding add_header 'Content-Security-Policy''upgrade-insecure-requests'; to the config file for NGINX for this instance will work around that. However that is not the case for me. I am wondering if anyone else is having a similar issue and whether or not you have found a fix? As I am setting up a site for a person who would like to edit this site for their own and they are not on prem and cannot edit from within the local network.

Thank you @NeoMatrixJR, doing that enabled the container to start. The only other issue I am having is a Twitch related issue that I'm hoping someone here may have experienced and may know a work around. Whereas RomM is relying on Twitch API for it's metadata I am having to create an API. However everytime I attempt to create an API and I click 'Create' nothing happens it just sits there. I have searched Twitch forums and there's no real solution other than login and back out, which I have done several times but still get the same.

I have run into this so many times, I have uninstalled, reinstalled and still had issues. then i figured it out. 1. go into your (shared) appdata folders and create a separate folder (expose the appdata to SMB if it's easier, I named my folder moodle-DB). 2. Install Mariadb through the community apps, for testing i made it simple, port 3327, all passwords for the database were 'moodle', then for the appdata folder it points to point it to your newly created 'moodle-DB folder' let it run its course. 3.install moodle from the apps, within the configuration point it to the database using the IP address and it's port, now here's where i kept dropping the ball, within the setup of the path data it is not 'finished' per say the container path shows /mnt/user/appdata/moodle/path however the field to fill it out just shows /mnt/user/appdata/moodle/ so i threw in path at the end and it started into installing 4. Check your logs for moodle when it's installing Also if you have residual folders and files left over from prior installs its a good idea to remove them with the cleanup appdata plugin and remove them entirely and start fresh. Hope that helps some.

However now I am buggered with another issue......SMTP email sending in moodle I have the correct webmail roundcube settings setup within the container as well as the interface as well mail.[mydomain.com] ssl is enabled so port 465 correct email sender and password and still nothing, i have used the mail pluggin as well as still get a 'moodle is unable to communicated with your email provider' . anyone find a solution to this or is it just me having this issue?

Yes I was able to increase upload max file size this morning after scouring everywhere. ChatGPT had the answer and I copy pasted the response lol. 1. You'll need to open terminal in Unraid 2. type in docker exec -it your_moodle_container_name /bin/bash (replace your_moodle_container_name with the actual name of your moodle container) 3. Find the Path to php.ini: Use the php -i command to display the PHP configuration. Look for the "Loaded Configuration File" line to find the path to the php.ini file by typing php -i | grep "Loaded Configuration File" Note down the path displayed. It might look like /opt/bitnami/php/etc/php.ini or similar. Edit php.ini Using sed: 4. Now, use the sed command with the correct path to edit the php.ini file: bash by typing sed -i 's/upload_max_filesize = .*/upload_max_filesize = 1G/' /opt/bitnami/php/etc/php.ini sed -i 's/post_max_size = .*/post_max_size = 1G/' /opt/bitnami/php/etc/php.ini whereas 40MB was nowhere near enough for the tutorial videos I am uploading I went with 1G instead of the 40MB, please adjust accordingly. 5.Restart the Docker Test

As someone who has many containers running, being able to organize them is an absolutely awesome feature for a plugin. However I have found that since the Unraid 16.12.2 -16.12.3 update that the folders will not stay in the order you set them after refreshing the page, nor does it allow to move the containers within the folder itself (the up n down arrows on the right of the container are unclickable). If I click the unlock icon and move a folder to the top then relock it, when I refresh the page it goes back to the way it was. Is this just happening to me or has anyone else experienced this? The only reason that this has become problematic is when I'm running a backend database that needs to start before the frontend interface. What will happen is it will reconfigure the containers so that the frontend starts up before the backend. Especially after a reboot when certain services should be available before others. +1 for DockerBox (get rid of the Organizer)

I know this is an old post, but was looking through google and saw this, perhaps an installation using docker compose? this is what I have found thus far. Courtesy of Github Docker Compose Wazuh # Wazuh App Copyright (C) 2017, Wazuh Inc. (License GPLv2) version: '3.7' services: wazuh.master: image: wazuh/wazuh-manager:4.8.0 hostname: wazuh.master restart: always ports: - "1515:1515" - "514:514/udp" - "55000:55000" environment: - INDEXER_URL=https://wazuh1.indexer:9200 - INDEXER_USERNAME=admin - INDEXER_PASSWORD=SecretPassword - FILEBEAT_SSL_VERIFICATION_MODE=full - SSL_CERTIFICATE_AUTHORITIES=/etc/ssl/root-ca.pem - SSL_CERTIFICATE=/etc/ssl/filebeat.pem - SSL_KEY=/etc/ssl/filebeat.key - API_USERNAME=wazuh-wui - API_PASSWORD=MyS3cr37P450r.*- volumes: - master-wazuh-api-configuration:/var/ossec/api/configuration - master-wazuh-etc:/var/ossec/etc - master-wazuh-logs:/var/ossec/logs - master-wazuh-queue:/var/ossec/queue - master-wazuh-var-multigroups:/var/ossec/var/multigroups - master-wazuh-integrations:/var/ossec/integrations - master-wazuh-active-response:/var/ossec/active-response/bin - master-wazuh-agentless:/var/ossec/agentless - master-wazuh-wodles:/var/ossec/wodles - master-filebeat-etc:/etc/filebeat - master-filebeat-var:/var/lib/filebeat - ./config/wazuh_indexer_ssl_certs/root-ca-manager.pem:/etc/ssl/root-ca.pem - ./config/wazuh_indexer_ssl_certs/wazuh.master.pem:/etc/ssl/filebeat.pem - ./config/wazuh_indexer_ssl_certs/wazuh.master-key.pem:/etc/ssl/filebeat.key - ./config/wazuh_cluster/wazuh_manager.conf:/wazuh-config-mount/etc/ossec.conf wazuh.worker: image: wazuh/wazuh-manager:4.8.0 hostname: wazuh.worker restart: always environment: - INDEXER_URL=https://wazuh1.indexer:9200 - INDEXER_USERNAME=admin - INDEXER_PASSWORD=SecretPassword - FILEBEAT_SSL_VERIFICATION_MODE=full - SSL_CERTIFICATE_AUTHORITIES=/etc/ssl/root-ca.pem - SSL_CERTIFICATE=/etc/ssl/filebeat.pem - SSL_KEY=/etc/ssl/filebeat.key volumes: - worker-wazuh-api-configuration:/var/ossec/api/configuration - worker-wazuh-etc:/var/ossec/etc - worker-wazuh-logs:/var/ossec/logs - worker-wazuh-queue:/var/ossec/queue - worker-wazuh-var-multigroups:/var/ossec/var/multigroups - worker-wazuh-integrations:/var/ossec/integrations - worker-wazuh-active-response:/var/ossec/active-response/bin - worker-wazuh-agentless:/var/ossec/agentless - worker-wazuh-wodles:/var/ossec/wodles - worker-filebeat-etc:/etc/filebeat - worker-filebeat-var:/var/lib/filebeat - ./config/wazuh_indexer_ssl_certs/root-ca-manager.pem:/etc/ssl/root-ca.pem - ./config/wazuh_indexer_ssl_certs/wazuh.worker.pem:/etc/ssl/filebeat.pem - ./config/wazuh_indexer_ssl_certs/wazuh.worker-key.pem:/etc/ssl/filebeat.key - ./config/wazuh_cluster/wazuh_worker.conf:/wazuh-config-mount/etc/ossec.conf wazuh1.indexer: image: wazuh/wazuh-indexer:4.8.0 hostname: wazuh1.indexer restart: always ports: - "9200:9200" environment: - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g" - "bootstrap.memory_lock=true" ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 volumes: - wazuh-indexer-data-1:/var/lib/wazuh-indexer - ./config/wazuh_indexer_ssl_certs/root-ca.pem:/usr/share/wazuh-indexer/certs/root-ca.pem - ./config/wazuh_indexer_ssl_certs/wazuh1.indexer-key.pem:/usr/share/wazuh-indexer/certs/wazuh1.indexer.key - ./config/wazuh_indexer_ssl_certs/wazuh1.indexer.pem:/usr/share/wazuh-indexer/certs/wazuh1.indexer.pem - ./config/wazuh_indexer_ssl_certs/admin.pem:/usr/share/wazuh-indexer/certs/admin.pem - ./config/wazuh_indexer_ssl_certs/admin-key.pem:/usr/share/wazuh-indexer/certs/admin-key.pem - ./config/wazuh_indexer/wazuh1.indexer.yml:/usr/share/wazuh-indexer/opensearch.yml - ./config/wazuh_indexer/internal_users.yml:/usr/share/wazuh-indexer/opensearch-security/internal_users.yml wazuh2.indexer: image: wazuh/wazuh-indexer:4.8.0 hostname: wazuh2.indexer restart: always environment: - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g" - "bootstrap.memory_lock=true" ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 volumes: - wazuh-indexer-data-2:/var/lib/wazuh-indexer - ./config/wazuh_indexer_ssl_certs/root-ca.pem:/usr/share/wazuh-indexer/certs/root-ca.pem - ./config/wazuh_indexer_ssl_certs/wazuh2.indexer-key.pem:/usr/share/wazuh-indexer/certs/wazuh2.indexer.key - ./config/wazuh_indexer_ssl_certs/wazuh2.indexer.pem:/usr/share/wazuh-indexer/certs/wazuh2.indexer.pem - ./config/wazuh_indexer/wazuh2.indexer.yml:/usr/share/wazuh-indexer/opensearch.yml - ./config/wazuh_indexer/internal_users.yml:/usr/share/wazuh-indexer/opensearch-security/internal_users.yml wazuh3.indexer: image: wazuh/wazuh-indexer:4.8.0 hostname: wazuh3.indexer restart: always environment: - "OPENSEARCH_JAVA_OPTS=-Xms1g -Xmx1g" - "bootstrap.memory_lock=true" ulimits: memlock: soft: -1 hard: -1 nofile: soft: 65536 hard: 65536 volumes: - wazuh-indexer-data-3:/var/lib/wazuh-indexer - ./config/wazuh_indexer_ssl_certs/root-ca.pem:/usr/share/wazuh-indexer/certs/root-ca.pem - ./config/wazuh_indexer_ssl_certs/wazuh3.indexer-key.pem:/usr/share/wazuh-indexer/certs/wazuh3.indexer.key - ./config/wazuh_indexer_ssl_certs/wazuh3.indexer.pem:/usr/share/wazuh-indexer/certs/wazuh3.indexer.pem - ./config/wazuh_indexer/wazuh3.indexer.yml:/usr/share/wazuh-indexer/opensearch.yml - ./config/wazuh_indexer/internal_users.yml:/usr/share/wazuh-indexer/opensearch-security/internal_users.yml wazuh.dashboard: image: wazuh/wazuh-dashboard:4.8.0 hostname: wazuh.dashboard restart: always ports: - 443:5601 environment: - OPENSEARCH_HOSTS="https://wazuh1.indexer:9200" - WAZUH_API_URL="https://wazuh.master" - API_USERNAME=wazuh-wui - API_PASSWORD=MyS3cr37P450r.*- - DASHBOARD_USERNAME=kibanaserver - DASHBOARD_PASSWORD=kibanaserver volumes: - ./config/wazuh_indexer_ssl_certs/wazuh.dashboard.pem:/usr/share/wazuh-dashboard/certs/wazuh-dashboard.pem - ./config/wazuh_indexer_ssl_certs/wazuh.dashboard-key.pem:/usr/share/wazuh-dashboard/certs/wazuh-dashboard-key.pem - ./config/wazuh_indexer_ssl_certs/root-ca.pem:/usr/share/wazuh-dashboard/certs/root-ca.pem - ./config/wazuh_dashboard/opensearch_dashboards.yml:/usr/share/wazuh-dashboard/config/opensearch_dashboards.yml - ./config/wazuh_dashboard/wazuh.yml:/usr/share/wazuh-dashboard/data/wazuh/config/wazuh.yml depends_on: - wazuh1.indexer links: - wazuh1.indexer:wazuh1.indexer - wazuh.master:wazuh.master nginx: image: nginx:stable hostname: nginx restart: always ports: - "1514:1514" depends_on: - wazuh.master - wazuh.worker - wazuh.dashboard links: - wazuh.master:wazuh.master - wazuh.worker:wazuh.worker - wazuh.dashboard:wazuh.dashboard volumes: - ./config/nginx/nginx.conf:/etc/nginx/nginx.conf:ro volumes: master-wazuh-api-configuration: master-wazuh-etc: master-wazuh-logs: master-wazuh-queue: master-wazuh-var-multigroups: master-wazuh-integrations: master-wazuh-active-response: master-wazuh-agentless: master-wazuh-wodles: master-filebeat-etc: master-filebeat-var: worker-wazuh-api-configuration: worker-wazuh-etc: worker-wazuh-logs: worker-wazuh-queue: worker-wazuh-var-multigroups: worker-wazuh-integrations: worker-wazuh-active-response: worker-wazuh-agentless: worker-wazuh-wodles: worker-filebeat-etc: worker-filebeat-var: wazuh-indexer-data-1: wazuh-indexer-data-2: wazuh-indexer-data-3:

You are a life saver. I have been trying and trying to get an ERP system in place and apparently I have come to the right spot. Is it possible to take this particular setup and use Adempiere (ERP) instead of the Dolibarr. Adempiere is another open source ERP like Dolibarr, but far more in depth with lot numbers and just everything in general. It's a very vast interface. I have been banging my head into walls for weeks trying to compose Adempiere with something like PostreSQL and a possible barcode scanner but my skillset with docker compose has much to be desired. The only documentation I can find in the wild regarding installing Adempiere through docker compose is here: https://adempiere.gitbook.io/docs/system-administration/installation/install-adempiere-easily-with-docker Again, with little experience with docker compose I am at a loss.

I've updated from the 6.9 and progressively updated as the updates have been available up to the current (6.11.5), since getting into the 6.11 updates I have noticed that every time I do a clean reboot, my system will come back online and automatically start doing a Parity check. Even though I have it scheduled to perform once a month. The system tells me that it is performing this check due to a unclean shutdown. I have no explanation as to why this started all of a sudden, nothing has changed for hardware. I have no VMs running and just a handful of docker containers.

recently updated my docker container and now it's not able to boot. Getting the following error. Haven't changed anything other than updating it. Is there a way to roll back the update to the prior?