jowi

Some months ago i used this topic to run a wordpress container, and i recall walking through a step by step description (like spaceinvaders tutorials) on how to add the mariadb, how to create the db etc but i can't seem to find it anymore? Is there a step by step tutorial anywhere on how to set up a new wordpress site on unraid?

yeah i tried some more renewing and recreating certificates, and all of a sudden it worked. Well, for me it always worked, but i now have new certificates... still don’t understand why the ping doesnt work, but for me everything is fine... 👍

Weird, everything pings fine from here, also, all domains are working fine over 4G on my phone... nextcloud works, i’ve got a wordpress site that runs etc. all is good as far as i cab tell? I dont get it.

But to be clear, if you ping nextcloud.20ten.nl , you get a timeout as well?

The ziggo modem is in bridge mode; so shouldn't have any port forwarding / firewall etc. I'm using pfsense as router, there is port fwding configured (1443/180 to https/http 443/80 internally on unraid for nginx proxymngr) Will reboot the modem anyway.

External ip is correct. Also curl ifconfig.me shows the same. According to hosting provider my domains do resolve OK: https://dnschecker.org/#A/nextcloud.20ten.nl https://dnschecker.org/#A/dehef.20ten.nl Ip is a cable modem from a local ISP. For the rest everything is working fine here on my side of the modem... pinging to it works fine from my side: 77.248.64.xxroot@UNRAID:/etc# ping 77.248.64.xx PING 77.248.64.xx (77.248.64.xx) 56(84) bytes of data. 64 bytes from 77.248.64.xx: icmp_seq=1 ttl=64 time=0.140 ms 64 bytes from 77.248.64.xx: icmp_seq=2 ttl=64 time=0.150 ms 64 bytes from 77.248.64.xx: icmp_seq=3 ttl=64 time=0.122 ms 64 bytes from 77.248.64.xx: icmp_seq=4 ttl=64 time=0.137 ms 64 bytes from 77.248.64.xx: icmp_seq=5 ttl=64 time=0.124 ms 64 bytes from 77.248.64.xx: icmp_seq=6 ttl=64 time=0.166 ms 64 bytes from 77.248.64.xx: icmp_seq=7 ttl=64 time=0.131 ms ^C --- 77.248.64.xx ping statistics --- 7 packets transmitted, 7 received, 0% packet loss, time 6146ms rtt min/avg/max/mdev = 0.122/0.138/0.166/0.014 ms bit lost here on what is going on?

External ip is correct (77.248.64.xx) but i can't also ping to it... DNS A records are also correct and pointing to this ip. Nothing has changed as far as i can see. I will contact my hosting provider to see if there is something wrong there. Wouldnt be the first time. What is ACL?

Ah ok, that works... now i get some more info, firewall issues? DNS records? Don't understand, all worked fine, why is it complaining about this for the certificates now all of a sudden? [code] /tmp # certbot renew --dry-run Saving debug log to /var/log/letsencrypt/letsencrypt.log - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/npm-2.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert is due for renewal, auto-renewing... Plugins selected: Authenticator webroot, Installer None Renewing an existing certificate Performing the following challenges: http-01 challenge for nextcloud.20ten.nl Using the webroot path /config/letsencrypt-acme-challenge for all unmatched domains. Waiting for verification... Challenge failed for domain nextcloud.20ten.nl http-01 challenge for nextcloud.20ten.nl Cleaning up challenges Attempting to renew cert (npm-2) from /etc/letsencrypt/renewal/npm-2.conf produced an unexpected error: Some challenges have failed.. Skipping. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/npm-3.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert is due for renewal, auto-renewing... Plugins selected: Authenticator webroot, Installer None Renewing an existing certificate Performing the following challenges: http-01 challenge for documentserver.20ten.nl Using the webroot path /config/letsencrypt-acme-challenge for all unmatched domains. Waiting for verification... Challenge failed for domain documentserver.20ten.nl http-01 challenge for documentserver.20ten.nl Cleaning up challenges Attempting to renew cert (npm-3) from /etc/letsencrypt/renewal/npm-3.conf produced an unexpected error: Some challenges have failed.. Skipping. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Processing /etc/letsencrypt/renewal/npm-4.conf - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Cert is due for renewal, auto-renewing... Plugins selected: Authenticator webroot, Installer None Renewing an existing certificate Performing the following challenges: http-01 challenge for dehef.20ten.nl Using the webroot path /config/letsencrypt-acme-challenge for all unmatched domains. Waiting for verification... Challenge failed for domain dehef.20ten.nl http-01 challenge for dehef.20ten.nl Cleaning up challenges Attempting to renew cert (npm-4) from /etc/letsencrypt/renewal/npm-4.conf produced an unexpected error: Some challenges have failed.. Skipping. All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/npm-2/fullchain.pem (failure) /etc/letsencrypt/live/npm-3/fullchain.pem (failure) /etc/letsencrypt/live/npm-4/fullchain.pem (failure) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates below have not been saved.) All renewal attempts failed. The following certs could not be renewed: /etc/letsencrypt/live/npm-2/fullchain.pem (failure) /etc/letsencrypt/live/npm-3/fullchain.pem (failure) /etc/letsencrypt/live/npm-4/fullchain.pem (failure) ** DRY RUN: simulating 'certbot renew' close to cert expiry ** (The test certificates above have not been saved.) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 3 renew failure(s), 0 parse failure(s) IMPORTANT NOTES: - The following errors were reported by the server: Domain: dehef.20ten.nl Type: connection Detail: Fetching http://dehef.20ten.nl/.well-known/acme-challenge/4fd7A4LKzcJxFvt4MYbLvSf6OxWUP5Mtd3xn4Su-HHA: Timeout during connect (likely firewall problem) To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided. - The following errors were reported by the server: Domain: documentserver.20ten.nl Type: connection Detail: Fetching http://documentserver.20ten.nl/.well-known/acme-challenge/hNPkFB8MC8whRSBugq-sa9O73F0phkv1yRIHAzNAxDc: Timeout during connect (likely firewall problem) To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided. - The following errors were reported by the server: Domain: nextcloud.20ten.nl Type: connection Detail: Fetching http://nextcloud.20ten.nl/.well-known/acme-challenge/uVRln4-qO9gV1eNfm2ys02uvieIT0GPN0SWe1fB-1F8: Timeout during connect (likely firewall problem) To fix these errors, please make sure that your domain name was entered correctly and the DNS A/AAAA record(s) for that domain contain(s) the right IP address. Additionally, please check that your computer has a publicly routable IP address and that no firewalls are preventing the server from communicating with the client. If you're using the webroot plugin, you should also verify that you are serving files from the webroot path you provided. - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. /tmp # [/code]

just 'internal error' and ' timeout'. Probably logged somewhere but i dont know where. Not a guru certbot: command not found???? where is certbot?

I have to renew my certificates, but i'm getting internal errors and timeouts? Also deleted the certificate and trying to get a new one, also same errors. What is the trick with nginx for renewal? I'm using letsencrypt certificates btw. Do i need to run the letsencrypt container as well for this to work? Or can i use some other certificate? From where?

Isn’t that a spinup issue? What happens when you have your array spun up to begin with?

You have to add other folders by editing the docker settings in unraid. There you can add a path on your host system using an alias name, that will show up inside the roon container.

Thanks deleted everything and reinstalled the server, using proper paths this time, now rebuilding again. So far so good.

Got some issues with this: Move the following files and subdirectories from /mnt/cache/appdata/roonserver/RoonServer to /mnt/cache/appdata/roonserver/app/RoonServer/: /Appliance, /RoonMono, /Server, Version, check.sh, and start.sh. In my case, there is no folder "/mnt/cache/appdata/roonserver/RoonServer", just "/mnt/cache/appdata/RoonServer" ... second: Move the following files and subdirectories from /mnt/cache/appdata/roonserver/ to /mnt/cache/appdata/roonserver/data/: /RAATServer, /RoonGoer, and .rmembid. The RAATServer and RoonGoer and .rmembid are NOT located in "/mnt/cache/appdata/roonserver" but in "/mnt/cache/appdata/" itself.... As far as i know i never changed or was asked to change the paths of raatserver and roongoer etc...? So how come these are not in the "/mnt/cache/appdata/roonserver" folder in my case? So in my appdata folder there is RAATServer, RoonGoer and RoonServer. My container path for 'app' is /mnt/cache/appdata/... i guess that is the problem? It should have been "/mnt/cache/appdata/roonserver" ? Should i just remove, reinstall and start over using /mnt/cache/appdata/roonserver for 'app' container path?

Oh but the docker often looses it’s connection to the core anyway, so i end up rebuilding the library every few weeks... so nothing new there

What am i missing if i just update the roon container using docker update in unraid, and update the client from within the app, and have it rebuild my lib or use a previously saved library backup? Why do i need all he steps described above?

Ok... this is getting silly. Now i've re-installed everything (including database) and now i can view the site from my domain, also the wp-admin, but NOT from my unraid machine... if i go to wp using unraid webui (so to my 192.168.xx.yy:port) it complains about ERR_SSL_PROTOCOL_ERROR, while SSL is NOT configured. I'm really starting to hate wordpress now.

Thanks, will read the thread from the start and try again

On my local ip, and used nginx proxy manager to redirect my domain name to it.

It should look like this: (also works ok directly from unraid's webui button)

Another issue. I'm using nginx proxy manager to redirect my domain to the unraid internal ip, works on some mobile devices, but on my mac i get this website rendered... no pictures, no styles, just large icons. The site works fine on my ipad. Have cleared cache, did not help. Any ideas?

What do you mean with wrong redirects due to install? If i look in the wordpress dashboard/settings, the ip and port is the same as in the unraid docker settings (192.168.1.25:6262 in both cases). If i hover over the webui context menu however, unraid shows 192.168.1.25:8080 in the statusbar, which is my unify controller. But i never entered 8080 in wordpress anywhere during setup nor install, so this is probably wordpress's default port? And hidden somewhere in a settings file somewhere inside the wp container? In the database, site_url and home fields in wp_options are also both set to 192.168.1.25:6262. *edit* Solved i just had to edit the webui PORT setting from [IP]:[PORT:8080] to 6262 in the advanced mode of the container settings in unraid... this is what you suggested in the first place, but i did not know you could manually set this in the advanced mode... never noticed this

Doesn’t work. I’ve set my port to 6262 in the docker settings, but the webui CONTEXT menu in the unraid docker page, the context menu where you can start and stop the container etc, ignores it and opens a totally different port, in my case the port where my ubiquity unify controller is located.

This wordpress docker supports one website? Is that correct? What if i want to create and host a couple of wordpress based sites, do i need a separate docker installed and set up for each one?

Did not work at all for me, the webgui button in the docker page in unraid took me to a totally different container... it took me a while to find out that if i entered the actual configured wordpress ip:port manually in my browser, it finally started wordpress and i could walk through the install... so it looks like the webgui button is broken in this container? It looks like it does not use the configured ip:port from the settings.