aptalca

Oh no, you can do what you propose, but you have a bug in your config currently. Let's say you set up 2 subdomains, sd1 and sd2. You create two server blocks in nginx, one for each, both listening on port 443 and they point to different root folders. When the request comes in, nginx looks at the destination address, if it's sd1.domain.url, it sends it to the first server block. But if a request comes in at port 443 and the destination address is neither sd1.domain.url or sd2.domain.url (it could be just the ip address XXX.XXX.XXX.XXX), in that case nginx needs to decide where to send that request. The "default_server" setting, which you have in your config file in the line "listen 443 ssl default_server;" means that any request that comes in on port 443, that doesn't match any of the listed server blocks by destination address, should be sent to that default block. In your case, you have two blocks designated as default, your esports.DOMAIN.ch block contains it, and the default site config contains it. That's the reason nginx is not starting. Delete one of the two "default_server" settings, and nginx should start, considering there aren't any other issues with your config. You can just modify that line to "listen 443 ssl;" I would recommend starting with a single very basic site config that works (like the default one I included) and start modifying it step by step with container restarts in between. That way, if nginx is no longer starting, you'll know that your last change broke something.

Well, for one, I don't think nginx likes it if you have more than one "default" server defined for the same port. You have multiple configs with that. That's likely the issue.

Unfortunately, letsencrypt does not handle adding or removing urls graciously (yet). So this container does not support it (in fact, if you modify the variables later on and let it renew through cron, it might break the whole thing). What you can do is, delete the etc/letsencrypt folder in your config location (it contains the keys) and then restart the container with the new url settings. The old certs will simply be discarded. You will still get e-mail notifications about them expiring (You can optionally revoke them in command line before deleting them but it's complicated). Or, better yet, delete the whole config folder and reinstall from fresh to be sure. Keep in mind that if you do it too many times, letsencrypt may block future cert retrievals/renewals for a certain period of time (which makes testing this container a real pain from a development perspective). site-confs directory should handle multiple configs. The nginx.conf is set to include all configs in that folder. There must be an error in one of the configs that prevents nginx from starting. The nginx log might tell you what it is.

Here's the Unraid logs from restarting it. How do you check if the docker image is full? I highly doubt it is, since it's 10GB and I saw this same issue when it was the only docker app installed, but I can check. Apr 12 08:52:44 Media php: /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker 'restart' 'PlexRequests' Apr 12 08:52:44 Media kernel: docker0: port 3(vethca05738) entered disabled state Apr 12 08:52:44 Media kernel: veth27e6fc1: renamed from eth0 Apr 12 08:52:44 Media kernel: docker0: port 3(vethca05738) entered disabled state Apr 12 08:52:44 Media avahi-daemon[2629]: Withdrawing workstation service for veth27e6fc1. Apr 12 08:52:44 Media avahi-daemon[2629]: Withdrawing workstation service for vethca05738. Apr 12 08:52:44 Media kernel: device vethca05738 left promiscuous mode Apr 12 08:52:44 Media kernel: docker0: port 3(vethca05738) entered disabled state Apr 12 08:52:44 Media kernel: device vethfcc4630 entered promiscuous mode Apr 12 08:52:44 Media kernel: docker0: port 3(vethfcc4630) entered forwarding state Apr 12 08:52:44 Media kernel: docker0: port 3(vethfcc4630) entered forwarding state Apr 12 08:52:44 Media kernel: nf_conntrack: falling back to vmalloc. Apr 12 08:52:44 Media avahi-daemon[2629]: Withdrawing workstation service for veth04d6a32. Apr 12 08:52:44 Media kernel: docker0: port 3(vethfcc4630) entered disabled state Apr 12 08:52:44 Media kernel: eth0: renamed from veth04d6a32 Apr 12 08:52:44 Media kernel: docker0: port 3(vethfcc4630) entered forwarding state Apr 12 08:52:44 Media kernel: docker0: port 3(vethfcc4630) entered forwarding state Apr 12 08:52:58 Media emhttp: cmd: /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker logs --tail=350 -f PlexRequests Apr 12 08:52:59 Media kernel: docker0: port 3(vethfcc4630) entered forwarding state I actually needed the logs for the container (by typing the command I posted in terminal), but. . . those messages in the unraid log don't seem right. Perhaps jonp or limetech can elaborate as there may be an issue with your network settings

Click on advanced view

Did you forward outside port 443 to the container's port 943 on your router? If so what do the logs say?

Could your docker image file be full by any chance? Also try the following in unraid terminal docker logs PlexRequests That might show more info on any potential errors

Can you post a screenshot of your container settings? The issue is not obvious to me. Is this a new install? I would recommend deleting the local folder and reinstalling it from scratch.

Can you post a screenshot of your container settings?

You probably used a/mnt/user location for the config folder. Change it to /mnt/cache or /mnt/disk and it should work

Great to hear is working. Let me know if you find any other bugs It seems it was premature (they accidentally changed the version number in their github). It has now been reverted. No version 1.29.1 yet :-) I believe the internal updater should update in the case of incremental updates (versions 1.29.X) but honestly, ever since I created the first zoneminder container, I don't think there has been any incremental updates, so that has not been tested. Worst case, I'll push an update to the container.

*UPDATE: Just did it and this time I get: "/defaults/letsencrypt.sh: line 11: ./letsencrypt-auto: No such file or directory" *** Running /etc/my_init.d/00_regen_ssh_host_keys.sh... *** Running /etc/my_init.d/firstrun.sh... Setting the correct time Current default time zone: 'Europe/Berlin' Local time is now: Fri Apr 8 19:07:24 CEST 2016. Universal Time is now: Fri Apr 8 17:07:24 UTC 2016. Using existing nginx.conf Using existing nginx-fpm.conf Using existing site config Using existing landing page Using existing jail.local Using existing fail2ban filters Using existing letsencrypt installation rm: cannot remove ‘/etc/letsencrypt’: No such file or directory SUBDOMAINS entered, processing Sub-domains processed are: -d XXXX.XXXX.XX -d XXXX.XXXX.XX -d XXXX.XXXX.XX -d XXXX.XXXX.XX -d XXXX.XXXX.XX Using existing DH parameters <-------------------------------------------------> <-------------------------------------------------> cronjob running at Fri Apr 8 19:07:24 CEST 2016 domains.conf: line 1: -d: command not found URL is XXXX.XX Subdomains are XXXX,XXXX,XXXX,XXXX,XXXX letting the script update itself; help info may be displayed, you can ignore that :-) /defaults/letsencrypt.sh: line 11: ./letsencrypt-auto: No such file or directory deciding whether to renew the cert(s) Existing certificate is still valid for another 75 day(s); skipping renewal. * Starting authentication failure monitor fail2ban ...done. *** Running /etc/rc.local... *** Booting runit daemon... *** Runit started as PID 121 Apr 8 19:07:24 88d529fcdb60 syslog-ng[128]: syslog-ng starting up; version='3.5.3' Oops, that second issue was my bad. I accidentally removed a line in the last update. The next version is being pushed and it should work.

This container only allows inbound access on two ports, 80 and 443 And for those ports, you have fail2ban that bans abusers through iptables

That's on my list of things to do as well. Like you mentioned, dhparams is easy, just replace the local file yourself and you're good to go. But for certs, I'll have to make that change

Have you tested that the memory works with the X9SRL-F board? I have the same board and need some memory and saw that the memory you bought is not on the supermicro tested memory list. Yep. It was picked up right away. Voltage and the timings were recognized correctly. I ran a memtest overnight (only 1.5 passes lol) no issues there The server has been chugging along fine for the last few days (since Sunday)

I wasn't aware of that. I'll look into it. But isn't .net a Windows thing??

It seems you changed the folder path when you reinstalled, or installed this on top of a different nginx container. The one being used should be under /config/nginx/site-confs (replace config with your config folder location from the container settings)

I need to see the full log

You might have to remove the php redirecting because it might cause issues with external sites that do their own php processing (I had to remove that our plexwatch had issues) And you might have to use a url prefix for owncloud. Now that you set up the secure Web server, I recommend googling owncloud and nginx proxy and following codes to accomplish that

Yup, that's it [emoji1] I posted sample reverse proxy configs a few pages back. You can use those as a starting point

I got the first one in my log last night as well. Funny enough, that's because letsencrypt updated the auto script itself the night before (v0.4.2 to v0.5.0). Not sure if that was a mistake on their part or not. I'll investigate. For the second one, I'm assuming that your certs were renewed last night, is that correct? If so that error always happens during renewal and it never caused any issues

What do the logs say? If letsencrypt didn't like your url and failed, then the webserver won't come up

Don't worry, I haven't forgotten about the php issue [emoji6] I wanted to get the cert renewals completely figured out as it was my top priority. I think that's done now so I'll look into php in the next few days

Don't map port 80 to 443. you are not trying to reach the unraid gui. Plus, you should never make your unraid web gui accessible from the Internet. It is not secure enough. You're trying to reach the webserver running inside the container. So do this: on your router, forward outside port 443 to port 443 at your local server ip. Then in the container settings, map 443 to 443 so an outside request to port 443 gets forwarded all the way to port 443 inside the container. And make sure not to put http in the url field in container settings [emoji6] it should be just unraid.ip.myfritz.net Then check the logs to make sure that it was able to generate a certificate By the way port 443 is the default port for https so when it all works out, you access the new webserver by going to https://unraid.ip.myfritz.net no need to define port number

When you first start it, it updates meteor, which can take a while depending on how slow meteor servers are (it took me over an hour once). Just let it run for a while As for the crash, I have no idea without seeing a log or something I'll make it more verbose so the user can see why it hasn't started yet in the logs