As per Certbot documentation for Ubuntu 16.04 and other distros, there is supposedly installed with the package a cron job that will automatically renew certificates:
The Certbot packages on your system come with a cron job that will
renew your certificates automatically before they expire. Since Let's
Encrypt certificates last for 90 days, it's highly advisable to take
advantage of this feature.
However I cannot find any related documentation on this subject, and I cannot find any cron job configured on crontab after following certbot installation instructions on the same page (version 0.19.0). Does this feature really exists? If yes, how to find it and configure it?
Note: I found this piece of doc when trying to configure automatic renewal with hooks. I could manually configure a cron job but using a built-in automated renewal feature seems more appropriate.
In Ubuntu 16.04 (among others) automatic renewal is handled by systemd instead of cron:
foo#localhost:~# systemctl list-timers
NEXT LEFT LAST PASSED UNIT ACTI
Fri 2018-05-25 19:05:59 UTC 1min 25s left n/a n/a systemd-tmpfiles-clean.timer syst
Sat 2018-05-26 00:56:58 UTC 5h 52min left Fri 2018-05-25 12:13:30 UTC 6h ago certbot.timer cert
Sat 2018-05-26 06:17:45 UTC 11h left Fri 2018-05-25 06:42:23 UTC 12h ago apt-daily-upgrade.timer apt-
Sat 2018-05-26 12:51:39 UTC 17h left Fri 2018-05-25 18:51:08 UTC 13min ago apt-daily.timer apt-
The timer is triggered twice per day by default.
foo#localhost:~# cat /lib/systemd/system/certbot.timer
[Unit]
Description=Run certbot twice daily
[Timer]
OnCalendar=*-*-* 00,12:00:00
RandomizedDelaySec=3600
Persistent=true
[Install]
WantedBy=timers.target
In short, try this:
https://certbot.eff.org/docs/using.html#webroot
long:
you have picked an odd timing for setting up ssl with certbot.
There are issues with vulnerabilities sadly. For their old renewal method that is.
so I opened this question here, and it contains some info where you should be looking for answers
Certbot automatic renewal vulnerabilities
Related
I want to get the status of daylight savings time in cross platforms as in the command timedatectl as active/not active. Since I am trying it with cross platforms I don't want to use timedatectl.
So my questions are:
When I use timedatectl status command in my system, it is not showing the DST Status. I don't know why. Can anybody explain this?
** My System output **
$ timedatectl status
Local time: Tue 2021-06-29 16:26:16 IST
Universal time: Tue 2021-06-29 10:56:16 UTC
RTC time: Tue 2021-06-29 10:56:16
Time zone: Asia/Kolkata (IST, +0530)
System clock synchronized: yes
NTP service: active
RTC in local TZ: no
It is not showing DST active : a (or) n/a status. I want know why?
Is there any default API or bin files similar to timedatectl to do the job of validating the DST is active/not status in the system (cross platforms)?
I tried to change time zone in redhat 7 from UTC to Asia/Kuala_Lumpur using command:
#timedatectl set-timezone Asia/Kuala_Lumpur
but it shows as below:
[root#mykultestrhel04t ~]# timedatectl
Local time: Thu 2019-08-22 06:41:03 UTC
Universal time: Thu 2019-08-22 06:41:03 UTC
RTC time: Thu 2019-08-22 06:41:03
Time zone: Asia/Kuala_Lumpur (UTC, +0000)
NTP enabled: yes
NTP synchronized: yes
RTC in local TZ: no
DST active: n/a
I want the result to be instead as below:
Time zone: Asia/Kuala_Lumpur (+08, +0800)
How can I change it to (+08, +0800)
Can anyone help?
You need to change the TZ environment variable. MY is the timezone setting for Malaysian peninsular.
export TZ=MY
You would normally add this command in your /etc/profile file. /etc/profile is the system-wide start-up script which will apply to all system users.
Note you can check from the shell your correct timezone setting using the tzselect shell command. It comes handy when you want to know what time it is in other countries, or if you just wonder what
timezones exist.
I have 3 servers, 2 on AWS and one on Digital Ocean, and the timezone for all is set to CDT. But when I check the current time on all 3 by using the date command via command line, none of them matches.
Server1: Wed Jun 12 23:36:01 CDT 2019
Server2: Wed Jun 12 23:45:51 CDT 2019
Server3: Wed Jun 12 23:38:39 CDT 2019
Could anyone please suggest what needs to be done here? Thanks.
Since you have not explicitly said that you have ntp running on them, you'll need to install that. Once that is installed and set up properly, you should show the same exact time on all of them.
I have 3 new fresh installs of Ubuntu 16.04.2 LTS xenial on Azure VM, in the system log I noticed I have a time discrepancy and the system is logging this ever 5 seconds.
Mar 5 17:57:57 server1 systemd[1]: snapd.refresh.timer: Adding 2h 17min 4.279485s random time.
Mar 5 17:57:57 server1 systemd[1]: apt-daily.timer: Adding 5h 14min 48.381690s random time.
Mar 5 17:57:57 server1 systemd[19425]: Time has been changed
Mar 5 17:57:57 server1 systemd[37054]: Time has been changed
I have stopped the two services: apt-daily.timer and snapd.refresh.timer, and the "Time has been changed" messages still persist. It seems to be a time discrepancy between the VM and host system. I am not sure how to address this. I also have VMs of the same exact version that I installed over a month ago on Azure and they don't show this error.
Thanks for guidance on this
I have two problems running freeswitch from systemd :
EDIT 2 - I have moved the slow start up question to here (Freeswitch pauses on check_ip at boot on centos 7.1) as although they may be related it's probably good as a standalone.
EDIT - I have noticed something else. Look at these next lines captured from the terminal output when running it from there. The gap is 4 minutes but it has been around 10 minutes before. I noticed it because I was trying to find out why port 8021 was taking several minutes to accept the fs_cli connection. Why does this happen? Never happened to me before and I've installed loads of FS boxes. This does the same thing on both 1.7 & todays 1.6.
2015-10-23 12:57:35.280984 [DEBUG] switch_scheduler.c:249 Added task 1 heartbeat (core) to run at 1445601455
2015-10-23 12:57:35.281046 [DEBUG] switch_scheduler.c:249 Added task 2 check_ip (core) to run at 1445601455
2015-10-23 13:01:31.100892 [NOTICE] switch_core.c:1386 Created ip list rfc6598.auto default (deny)
I sometimes get double processes started. Here is my status line after such an occurrence :
# systemctl status freeswitch -l
freeswitch.service - freeswitch
Loaded: loaded (/etc/systemd/system/multi-user.target.wants/freeswitch.service)
Active: activating (start) since Fri 2015-10-23 01:31:53 BST; 18s ago
Main PID: 2571 (code=exited, status=0/SUCCESS); : 2742 (freeswitch)
CGroup: /system.slice/freeswitch.service
├─usr/bin/freeswitch -ncwait -core -db /dev/shm -log /usr/local/freeswitch/log -conf /usr/local/freeswitch/conf -run /usr/local/freeswitch/run
└─usr/bin/freeswitch -ncwait -core -db /dev/shm -log /usr/local/freeswitch/log -conf /usr/local/freeswitch/conf -run /usr/local/freeswitch/run
Oct 23 01:31:53 fswitch-1 systemd[1]: Starting freeswitch...
Oct 23 01:31:53 fswitch-1 freeswitch[2742]: 2743 Backgrounding.
and there are two processes running.
The PID file is sometimes not written fast enough for the systemd process to pick it up, but by the time I see this (no matter how fast I run the command) it's always there by the time I do :
Oct 23 02:00:26 arribacom-sbc-1 systemd[1]: PID file
/usr/local/freeswitch/run/freeswitch.pid not readable (yet?) after
start.
Now, in (2) everything seems to work ok, and I can shut down the freeswitch process using
systemctl stop freeswitch
without any issues, but in (1) it just doesn't seem to do anything.
I'm wondering if the two are related, and that freeswitch is reporting back to systemd that the program is running before it actually is. Then systemd is either starting up another process or (sometimes) not.
Can anyone offer any pointers? I have tried to mail the freeswitch users list but despite being registered I simply cannot get any emails to appear on the list (but that's another problem).
* Update *
If I remove the -ncwait it seems to improve the double process starting but I still get the can't read PID warning, so I'm still sure there's an issue present, possibly around timing(?).
I'm on Centos 7.1, & my freeswitch version is
FreeSWITCH Version 1.7.0+git~20151021T165609Z~9fee9bc613~64bit (git
9fee9bc 2015-10-21 16:56:09Z 64bit)
and here's my freeswitch.service file (some things have been commented out until I understand what they are doing and any side effects they may have) :
[Unit]
Description=freeswitch
After=syslog.target network.target
#
[Service]
Type=forking
PIDFile=/usr/local/freeswitch/run/freeswitch.pid
PermissionsStartOnly=true
ExecStart=/usr/bin/freeswitch -nc -core -db /dev/shm -log /usr/local/freeswitch/log -conf /u
ExecReload=/usr/bin/kill -HUP $MAINPID
#ExecStop=/usr/bin/freeswitch -stop
TimeoutSec=120s
#
WorkingDirectory=/usr/bin
User=freeswitch
Group=freeswitch
LimitCORE=infinity
LimitNOFILE=999999
LimitNPROC=60000
LimitSTACK=245760
LimitRTPRIO=infinity
LimitRTTIME=7000000
#IOSchedulingClass=realtime
#IOSchedulingPriority=2
#CPUSchedulingPolicy=rr
#CPUSchedulingPriority=89
#UMask=0007
#
[Install]
WantedBy=multi-user.target
In the current master branch, take the two files from debian/ directory:
freeswitch-systemd.freeswitch.service -- should go as /lib/systemd/system/freeswitch.service
freeswitch-systemd.freeswitch.tmpfile -- should go as /usr/lib/tmpfiles.d/freeswitch.conf
You probably need to adapt the paths, or build FreeSWITCH to use standard Debian paths.