aptalca

*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.

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

I need to see the full log

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

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

Decent idea actually. I click it a lot during testing (sometimes not on purpose), and I usually use it as an excuse to go have a smoke. So I can see how other people would do the same thing. I click on it every time I make a change to one of my repo xmls to see if it looks fine. It only takes about 30 seconds for me

Is that type of error logged in nginx's error.log? Because that file is in the config folder under logs/nginx/ and should be easily accessible. Apache-utils requires manual creation through command line. I figured if you're already exec'ing into the container (most users don't) you can easily install it with apt-get. Since it's only used once, there is no need to install it into the main image. I thought about automating it, but I didn't want people to put their passwords in the docker run command as a environment variable or anywhere else in plain text to be honest. There are some online generators, that are javascript based and run in the client browser. Nothing is uploaded (you can test by cutting the internet access while generating)

Yep I know, but Logs were lost, which is why I wont bother to find the reason. But I am pretty sure 443 was not pointing to the container, I had no proxy setup yet und was using it for another webserver. And the "old" keys were correctly "archived" so it had to be a renewal, that was started during the upgrade process of unraid. Well "pretty sure" is what it is. I'll try and test the setup that I think was active at that time. If it does not work, I am just getting old I think I figured out what happened. I made the change from checking file modified date to checking certificate expiration date in the dev repo while on vacation and completely forgot to merge it master. So in your case, your files must have been modified somehow (chown maybe?) so the script was reading the cert creation date wrong. I just pushed a new update that fixes that issue among others https://hub.docker.com/r/aptalca/nginx-letsencrypt/

Hi dcpdad, 1) If you're asking about password protection for access from the internet, then I would recommend using a reverse proxy like nginx. It allows for authorization through htpasswd, which I trust. Check out the nginx-letsencrypt container I put together, it handles the ssl certs and reverse proxy. I use that for all my container GUIs so I can access them securely 2) Not really, I guess I'm a little OCD and prefer to import the books manually so I can check to make sure the info retrieved from the internet is correct. I'm not sure if calibre has that functionality built-in or not. I know it has terminal commands you can use for importing through command line, which could be put into a cron script, but I honestly don't have time to look into that. If someone else figures it out, feel free to send a pr on github

Great to hear is working. Let me know if you find any other bugs

Zoneminder is now fixed, update pushed

Instructions are on the docker hub page: https://hub.docker.com/r/aptalca/zoneminder-1.29/ You probably need to change the path_zms that is listed under important I'm making some progress, in the prior docker 1.28.1, the events were stored in the config path under /appdata/zoneminder/data/zoneminder/events, separate from the container, in this version, I'm not so sure that is the case. I've recorded several events, but the /appdata/zoneminderv129/data/events folder is empty. So it seemed by default, the old version stored events in the config path, but 1.29 does not. I see that I can change the path for events, I assume /config/data/events may work ? Appreciate your help. Oops, my bad. They changed all the paths between 1.28 and 1.29 and I must have missed this change. That's why I had to create a separate docker. No way to update the old one in place. Will be fixed in the next update. Thanks for letting me know.

Instructions are on the docker hub page: https://hub.docker.com/r/aptalca/zoneminder-1.29/ You probably need to change the path_zms that is listed under important

If 443 was not forwarded to the container, it should not have been able to validate. Plus, the script does not run the letsencrypt command unless the existing certs are at least 60 days old. Not sure what happened in your case. Maybe the certs weren't successfully created the first time you ran it. Again, without seeing the logs from before, I can't tell. An older version of this container used to calculate the cert age by the file's mtime, which wasn't the best method. Latest version actually checks the cert creation date so it's more reliable. Also, just so you know, there are two logs, the docker log will tell you what happened when the letsencrypt.sh ran at container start. And then there is the letsencrypt.log file in the config folder under log/nginx/ and that one stores the latest cron output. Make sure you check both. I'll give it some thought. Although the 4096 dh might take forever to generate. letsencrypt.log file in the config folder should tell you what happened during the last attempt. I might change it to append so you can see the history as well. There are two checkpoints. The first is, letsencrypt.sh that I created will only attempt a renewal if the existing certs are over 60 days old. That's done by comparing the cert creation time and the current time on the server. The other checkpoint is administered by letsencrypt servers. I don't remember their timeline but by default, if the certs aren't close to expiring, the headless command skips the renewal. This parameter bypasses that behavior so only my letsencrypt.sh script controls when the certs are renewed rather than the letsencrypt servers. The reason is that if letsencrypt sets that to 5 days before expiration and the cron script doesn't run during that time, the certs expire. And I don't want to schedule the cron script too frequently because the update method requires that the nginx webserver is taken down during cert renewal. And I certainly don't want to let the user decide on the frequency, because letsencrypt has a bunch of restrictions on that and they'll block you from further cert creations per domain or per user (this made the testing of this container fairly difficult early on as I kept hitting the limits and now I am getting a ton of e-mails daily about expiring certs that are not being used, and are all duplicates, but were created in the process). I considered that but then realized that it would never be a turn key solution. The user will always have to figure out how to set it up on their systems. I'd rather have them go and research it so they know what they are doing before attempting it, rather than me providing a partial solution and end up with a ton of support requests because they don't know what they are doing and it is just not working. I did post copies of my conf files in the letsencrypt thread, though: https://lime-technology.com/forum/index.php?topic=43696.msg437353#msg437353 The container fixes the time so that it matches the host system's local time (even for cron, which is by default UTC) I don't advertise the 60 day thing because honestly, the user does not even need to know that. The container will take care of it all. As long as it's running, the certs will be kept up-to-date. If it was down for a while, it will renew upon container start. Renewal does require revalidation. That's part of their core mission: provide short term certs that are often validated, automatically. I originally wanted to make this a separate container just for cert management. The idea was that this container would keep the certs up-to-date and put them somewhere other containers could access. But there are some serious (and annoying) restrictions with how acme is set up. You have to use either port 80 or 443 for validation. No other port works. In other words, you have to run letsencrypt on the same machine/container your webserver is running. Also, if you want to do it through port 443, you have to use letsencrypt's built-in webserver for validation, which means you have to stop your main webserver while you're validating. That's why I had to integrate it into a full nginx container so the script can do automatic renewals. So basically, this isn't really a letsencrypt container. It's actually an nginx container with letsencrypt and fail2ban built-in. On my company webserver that is hosted on a vps, I have a custom letsencrypt solution that is very similar to the one built-in here (almost the same cron script but modified for multiple certs with different domain names).

Hit the advanced view button at the top right and it will reveal new settings and likely an error message. It won't let you install without entering that info under advanced view. And make sure you read the description at the top [emoji14] Aptalca, you may want to update the instructions given at https://hub.docker.com/r/aptalca/docker-duckdns/ - I had to resort to searching this forum for 'duckdns' to discover that I needed to click the greyed out 'Advanced' button in the top right of the container setup page. You should always read the description on the container install page in the unraid gui [emoji14] The docker hub description is really for non unraid users but I leave the unraid info just to promote it.

No problem. I'm glad you like the containers. Port 80 for that container is optional. The letsencrypt validation occurs through 443 and you're supposed to connect to www through 443 as well in order to use ssl by default. Plus, you have to map 80 to a different port anyway because it's already being used by the unraid gui. You can use duckdns, just make sure to put yoursubdomain.duckdns.org in the url field and leave the subdomain as www

Not yet, I tried a few things but couldn't isolate the issue yet. Didn't have to much time lately

I think you can run multiple containers at the same time. You just have to give the second one a different container name during install and pick different ports.

I fixed the xml templates so if you're having the issue, install from scratch from the community applications and it should install fine

Hmm. That's strange because someone else is having the same exact issue with the letsencrypt container. It seems like an unraid issue. Which unraid version are you on? Not at my server to check, but I don't think that the trailing / after the port should be there. Good eye, that's the problem. My xmls leave the protocol field blank and the dockerman fills it with tcp. It seems that the new unraid (I'm assuming folks updated to the latest beta) leaves it blank and it causes the issue

Hmm. That's strange because someone else is having the same exact issue with the letsencrypt container. It seems like an unraid issue. Which unraid version are you on?

The script is used to externally trigger an event on zoneminder (e.g. security alarm going off). The script needs to be always running for this to occur. The default behaviour is that it's not running. As a temporary fix I've just added it to the zoneminder init.d script which seems to do the job. Cheers. Zoneminder wiki says that the script is called when you turn on opt_triggers in the settings. Does that not work for you? https://wiki.zoneminder.com/How_to_use_your_external_camera's_motion_detection_with_ZM Thanks

Awesome thanks! Would it be possible to have the option of zmtrigger.pl (/usr/bin/zmtrigger.pl) always running? Could you elaborate on this? What's the current behavior and what is the desired? Thanks

Thanks for the heads up. Fixed in the new update.

For all zoneminder fans, version 1.29 is out. But it's a separate container. Due to the extensive changes in the new version, it was near impossible to update a 1.28 version in place. So you'll have to install this separate container and set it up from scratch. Don't try to install it using the same config folder with existing data, it won't work. To be honest, I wasn't even able to update my existing install to 1.29 no matter how hard I tried (without deleting the existing data), so there was no way I could do it for all the existing users with different configs. Let me know if the new one has any issues