I'm trying to run a fairly simple docker stack, but for some reason it is failing to register certificates.
My composer:
version: '2'
services:
nginx-proxy:
image: nginxproxy/nginx-proxy
container_name: nginx-proxy
ports:
- "80:80"
- "443:443"
volumes:
- conf:/etc/nginx/conf.d
- vhost:/etc/nginx/vhost.d
- html:/usr/share/nginx/html
- dhparam:/etc/nginx/dhparam
- certs:/etc/nginx/certs:ro
- /var/run/docker.sock:/tmp/docker.sock:ro
network_mode: bridge
acme-companion:
image: nginxproxy/acme-companion
container_name: nginx-proxy-acme
volumes_from:
- nginx-proxy
volumes:
- certs:/etc/nginx/certs:rw
- acme:/etc/acme.sh
- /var/run/docker.sock:/var/run/docker.sock:ro
network_mode: bridge
volumes:
conf:
vhost:
html:
dhparam:
certs:
acme:
This is my log from acme-companion
Info: running acme-companion version v2.1.0-25-g7f1b754,
Generating a RSA private key,
...................................................................++++,
...........................................................................................................................................................................................++++,
writing new private key to '/etc/nginx/certs/default.key.new',
-----,
1996071824:error:0D0D90AD:asn1 encoding routines:ASN1_TIME_adj:error getting time:crypto/asn1/a_time.c:330:,
Info: a default key and certificate have been created at /etc/nginx/certs/default.key and /etc/nginx/certs/default.crt.,
Warning: /etc/nginx/certs/default.key does not exist. Skipping ownership and permissions check.,
Warning: /etc/nginx/certs/default.crt does not exist. Skipping ownership and permissions check.,
Info: Custom Diffie-Hellman group found, generation skipped.,
Reloading nginx proxy (nginx-proxy)...,
2021/09/13 08:54:28 Contents of /etc/nginx/conf.d/default.conf did not change. Skipping notification '',
2021/09/13 08:54:28 [notice] 91#91: signal process started,
2021/09/13 08:54:29 Generated '/app/letsencrypt_service_data' from 4 containers,
2021/09/13 08:54:29 Running '/app/signal_le_service',
2021/09/13 08:54:29 Watching docker events,
2021/09/13 08:54:29 Contents of /app/letsencrypt_service_data did not change. Skipping notification '/app/signal_le_service',
[Thu Jan 1 00:00:00 UTC 1970] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6,
[Thu Jan 1 00:00:00 UTC 1970] Can not init api.,
[Thu Jan 1 00:00:00 UTC 1970] Registering account: https://acme-v02.api.letsencrypt.org/directory,
[Thu Jan 1 00:00:00 UTC 1970] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6,
[Thu Jan 1 00:00:00 UTC 1970] Could not get nonce, let's try again.,
[Thu Jan 1 00:00:00 UTC 1970] Please refer to https://curl.haxx.se/libcurl/c/libcurl-errors.html for error code: 6,
[Thu Jan 1 00:00:00 UTC 1970] Could not get nonce, let's try again.
So error code 6 should be CURLE_COULDNT_RESOLVE_HOST but I'm not sure exactly what it can't resolve. This server has a connection and everything else seems to work.
If anyone stumbles on to this issue then here is the fix. It seems to affect alpine version 3.13 and probably other ones.
https://github.com/alpinelinux/docker-alpine/issues/135
Related
I am frequently seeing these messages in the redis logs
1#
602854:M 23 Dec 2022 09:48:54.028 * 10 changes in 300 seconds. Saving...
602854:M 23 Dec 2022 09:48:54.035 * Background saving started by pid 3266364
3266364:C 23 Dec 2022 09:48:55.844 * DB saved on disk
3266364:C 23 Dec 2022 09:48:55.852 * RDB: 12 MB of memory used by copy-on-write
602854:M 23 Dec 2022 09:48:55.938 * Background saving terminated with success
2#
LOADING Redis is loading the dataset in memory
3#
7678:signal-handler (1671738516) Received SIGTERM scheduling shutdown...
7678:M 22 Dec 2022 23:48:36.300 # User requested shutdown...
7678:M 22 Dec 2022 23:48:36.300 # systemd supervision requested, but NOTIFY_SOCKET not found
7678:M 22 Dec 2022 23:48:36.300 * Saving the final RDB snapshot before exiting.
7678:M 22 Dec 2022 23:48:36.300 # systemd supervision requested, but NOTIFY_SOCKET not found
7678:M 22 Dec 2022 23:48:36.720 * DB saved on disk
7678:M 22 Dec 2022 23:48:36.720 * Removing the pid file.
7678:M 22 Dec 2022 23:48:36.720 # Redis is now ready to exit, bye bye...
7901:C 22 Dec 2022 23:48:37.071 # WARNING supervised by systemd - you MUST set appropriate values for TimeoutStartSec and TimeoutStopSec in your service unit.
7901:C 22 Dec 2022 23:48:37.071 # systemd supervision requested, but NOTIFY_SOCKET not found
7914:C 22 Dec 2022 23:48:37.071 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
7914:C 22 Dec 2022 23:48:37.071 # Redis version=6.0.9, bits=64, commit=00000000, modified=0, pid=7914, just started
7914:C 22 Dec 2022 23:48:37.071 # Configuration loaded
Are these messages concerning?
Let me know if there's any optimization to be carried out in terms of settings.
The first set of informational messages is related to Redis persistence: it appears your Redis node is configured to save the database to disk if 300 seconds elapsed and it surpassed 10 write operations against it. You can change that according to your needs through the Redis configuration file.
The message LOADING Redis is loading the dataset in memory, on the other side, is an error message received while attempting to connect to a Redis instance which is loading its dataset in memory: that occurs during the startup for standalone servers and master nodes or when replicas reconnect and fully resynchronize with master. If you are seeing this error too often and not right after a system restart, I would suggest to check your system log files and learn why your Redis instance is restarting or resynchronizing (depending on your topology).
I am using a (bash) alias on an Ubuntu 22.04 system to quickly tail the system log without all the garbage that usually is of no importance. (I do want all this logged, but not displayed all the time.) The current alias looks something like this:
$ tail -f --lines=200 /var/log/syslog | \
egrep -v "(named\[.*\]: (REFUSED unexpected RCODE|timed out) resolving)|\[INFO\] (New connection from ::1|Logout.)"
This works fine and give me some output:
Dec 7 13:32:15 root named[1044]: clients-per-query decreased to 20
Dec 7 13:32:29 root mariadbd[1188]: 2022-12-07 13:32:29 83187 [Warning] Aborted connection 83187 to db: 'XXX' user: 'XXX' host: 'localhost' (Got an error reading communication packets)
Dec 7 13:32:39 root named[1044]: connection refused resolving '_.168.192.bl.blocklist.de/A/IN': 46.252.24.212#53
Dec 7 13:32:39 root named[1044]: connection refused resolving '_.215.85.bl.blocklist.de/A/IN': 46.252.24.212#53
Dec 7 13:39:00 root systemd[1]: Starting Clean php session files...
Dec 7 13:39:03 root systemd[1]: phpsessionclean.service: Deactivated successfully.
Dec 7 13:39:03 root systemd[1]: Finished Clean php session files.
Dec 7 13:39:03 root systemd[1]: phpsessionclean.service: Consumed 3.081s CPU time.
Dec 7 13:52:15 root named[1044]: clients-per-query decreased to 19
Dec 7 13:53:06 root named[1044]: connection refused resolving '_.54.142.bl.blocklist.de/A/IN': 46.252.24.212#53
Dec 7 13:55:58 root mariadbd[1188]: 2022-12-07 13:55:58 83536 [Warning] Access denied for user 'xxx'#'localhost' (using password: YES)
Dec 7 13:55:58 root mariadbd[1188]: 2022-12-07 13:55:58 83537 [Warning] Access denied for user ''#'localhost' (using password: NO)
Dec 7 13:59:01 root kernel: [241023.546785] sh (1569030): drop_caches: 3
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> Received signal: wake up
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> ClamAV update process started at Wed Dec 7 14:04:19 2022
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> ^Your ClamAV installation is OUTDATED!
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> ^Local version: 0.103.6 Recommended version: 0.103.7
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> DON'T PANIC! Read https://docs.clamav.net/manual/Installing.html
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> daily.cld database is up-to-date (version: 26743, sigs: 2013590, f-level: 90, builder: raynman)
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> main.cvd database is up-to-date (version: 62, sigs: 6647427, f-level: 90, builder: sigmgr)
Dec 7 14:04:19 root freshclam[1929]: Wed Dec 7 14:04:19 2022 -> bytecode.cvd database is up-to-date (version: 333, sigs: 92, f-level: 63, builder: awillia2)
Dec 7 14:04:52 root named[1044]: validating _spf.eu.mailgun.org/TXT: no valid signature found
Dec 7 14:09:00 root systemd[1]: Starting Clean php session files...
Dec 7 14:09:03 root systemd[1]: phpsessionclean.service: Deactivated successfully.
Dec 7 14:09:03 root systemd[1]: Finished Clean php session files.
Dec 7 14:09:03 root systemd[1]: phpsessionclean.service: Consumed 3.038s CPU time.
Dec 7 14:09:38 root clamd[489]: Wed Dec 7 14:09:38 2022 -> SelfCheck: Database status OK.
However, when I pipe this output through ccze, I get no output at all:
$ tail -f --lines=200 /var/log/syslog | \
egrep -v "(named\[.*\]: (REFUSED unexpected RCODE|timed out) resolving)|\[INFO\] (New connection from ::1|Logout.)" | \
ccze -A
It gets weirder: after removing the RCODE line from my exclusion list it works:
$ tail -f --lines=200 /var/log/syslog | \
egrep -v "(named\[.*\]: timed out resolving)|\[INFO\] (New connection from ::1|Logout.)" | \
ccze -A
Dec 7 13:32:15 root named[1044]: clients-per-query decreased to 20
Dec 7 13:32:29 root mariadbd[1188]: 2022-12-07 13:32:29 83187 [Warning] Aborted connection 83187 to db: 'xxx' user: 'xxx' host: 'localhost' (Got an error reading communication packets)
Dec 7 13:32:39 root named[1044]: connection refused resolving '_.168.192.bl.blocklist.de/A/IN': 46.252.24.212#53
(...)
And if I first cat the syslog to a file and then pipe it through ccze, it also works:
$ tail --lines=200 /var/log/syslog | \
egrep -v "(named\[.*\]: (REFUSED unexpected RCODE|timed out) resolving)|\[INFO\] (New connection from ::1|Logout.)" \
> syslog-ccze.bug
$ cat syslog-ccze.bug | ccze -A
Dec 7 13:32:15 root named[1044]: clients-per-query decreased to 20
Dec 7 13:32:29 root mariadbd[1188]: 2022-12-07 13:32:29 83187 [Warning] Aborted connection 83187 to db: 'xxx' user: 'xxx' host: 'localhost' (Got an error reading communication packets)
Dec 7 13:32:39 root named[1044]: connection refused resolving '_.168.192.bl.blocklist.de/A/IN': 46.252.24.212#53
(...)
For some reason, ccze doesn't like me filtering out the "unexpected RCODE" named messages. Am I missing something obvious, or am I hitting some weird race condition in ccze, or what is happening?
Bah. Once you take the time to actually write down your question, you'll find answers by yourself. :-(
ccze apparently has an internal buffer. It needs a minimum amount of lines before outputting ANYTHING. Increasing the --lines= parameter for tail in my alias helped.
This seems to be undocumented behaviour, so I'll leave the question here to be searchable. Hope it helps and saves you some time. :-)
after upgrading via mc command i get this error when i try to login to the (kind of new) minio console:
Post "https://fqdn.org/": dial tcp 127.0.1.1:443: connect: connection refused
I have a signed and valid SSL Certificate.
Downgrading minio (aka restore Snapshot of VM) solves the problem.
Any ideas?
This is my config:
MINIO_SERVER_URL="https://fqdn.org"
MINIO_ACCESS_KEY="key"
MINIO_VOLUMES="/mnt/hdd2/minio/"
MINIO_OPTS="-C /etc/minio --address :9000 --console-address :9001"
MINIO_SECRET_KEY="minio"
This is my minio startup log:
● minio.service - MinIO
Loaded: loaded (/etc/systemd/system/minio.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2021-11-11 08:41:14 CET; 4min 50s ago
Docs: https://docs.min.io
Process: 3567 ExecStartPre=/bin/bash -c if [ -z "${MINIO_VOLUMES}" ]; then echo "Variable MINIO_VOLUMES not set in /etc/default/minio"; exit 1; fi (code=exited, status=0/SUCCESS)
Main PID: 3568 (minio)
Tasks: 9 (limit: 2351)
Memory: 101.9M
CGroup: /system.slice/minio.service
└─3568 /home/minio/minio server -C /etc/minio --address :9000 --console-address :9001 /mnt/hdd2/minio/
Nov 11 08:41:14 pmit-minio-test systemd[1]: Starting MinIO...
Nov 11 08:41:14 pmit-minio-test systemd[1]: Started MinIO.
Nov 11 08:41:17 pmit-minio-test minio[3568]: WARNING: MINIO_ACCESS_KEY and MINIO_SECRET_KEY are deprecated.
Nov 11 08:41:17 pmit-minio-test minio[3568]: Please use MINIO_ROOT_USER and MINIO_ROOT_PASSWORD
Nov 11 08:41:17 pmit-minio-test minio[3568]: API: https://fqdn.org
Nov 11 08:41:17 pmit-minio-test minio[3568]: Console: https://191.164.213.7:9001 https://127.0.0.1:9001
Nov 11 08:41:17 pmit-minio-test minio[3568]: Documentation: https://docs.min.io
Please see the answer here:
https://github.com/minio/minio/issues/13639#issuecomment-966244704
I had to change this line:
MINIO_SERVER_URL="https://fqdn.org:9000"
I am new to using PLEX server I found a issue in plex server i tried to cast 4-5 images in repeated format but after some time it 'll stuck at some random image. When I see the Log Files of this I found
964] INFO - [Chromecast] [MDE] Finished analysis of jpeg (jpeg)
Jan 15, 2018 13:58:16.652 [6060] ERROR - Error issuing
curl_easy_perform(handle): 7
Jan 15, 2018 13:58:16.652 [8292] ERROR - Error issuing
curl_easy_perform(handle): 7
Jan 15, 2018 13:58:16.652 [1860] ERROR - Error issuing
curl_easy_perform(handle): 7
Jan 15, 2018 13:58:16.683 [6800] INFO - [Chromecast] canPlay: true
Jan 15, 2018 13:58:16.730 [5728] INFO - [Chromecast]
canDirectPlay: true
Jan 15, 2018 13:58:16.840 [3764] INFO - [Chromecast] [PDE] Player
decision
Jan 15, 2018 13:58:16.918 [3104] INFO - [Chromecast] Player: html
I didn't get why this happen so I tried to resolve this issue from last few of weeks but not able to resolve can any one help.
I'm trying to pass simple bash script to an AWS CentOS 7 instance. User Data looks like:
#!/bin/bash
yum update -y
Here is a fragment of cloud init log:
Apr 1 19:03:01 ip-172-20-60-102 cloud-init: /usr/bin/env: bash yum update -y : No such file or directory
Apr 1 19:03:01 ip-172-20-60-102 cloud-init: 2016-04-01 19:03:01,604 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-001 [127]
Apr 1 19:03:01 ip-172-20-60-102 cloud-init: 2016-04-01 19:03:01,616 - cc_scripts_user.py[WARNING]: Failed to run module scripts-user (scripts in /var/lib/cloud/instance/scripts)
Apr 1 19:03:01 ip-172-20-60-102 cloud-init: 2016-04-01 19:03:01,617 - util.py[WARNING]: Running scripts-user (<module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python2.7/site-packages/cloudinit/config/cc_scripts_user.pyc'>) failed
I tried a different approach as suggested in:
Bash script passed to AWS EC2 Instance as User Data file fails to load on initial boot
So I changed User Data to:
"UserData" : { "Fn::Base64" : { "Fn::Join" : ["", [
"#!/bin/bash\n\n",
"yum update -y"
]]}}
I got different kind of error:
Apr 1 19:28:17 ip-172-20-60-102 cloud-init: 2016-04-01 19:28:17,450 - __init__.py[WARNING]: Unhandled non-multipart (text/x-not-multipart) userdata: '"UserData" : { "Fn::Base...'
Apr 1 19:28:20 ip-172-20-60-102 cloud-init: Cloud-init v. 0.7.5 running 'modules:config' at Fri, 01 Apr 2016 19:28:20 +0000. Up 48.56 seconds.
Apr 1 19:28:21 ip-172-20-60-102 cloud-init: Cloud-init v. 0.7.5 running 'modules:final' at Fri, 01 Apr 2016 19:28:20 +0000. Up 48.89 seconds.
Use absolute path. Try /usr/bin/yum -y update .