On 6/9/2020 16:18 PM, Paul Theodoropoulos via devel wrote:
Yes, it is nonsensical that changing it to root:ntp would make the cert
file harder to read - because that's not what I did.
s/harder/easier/
--
Paul Theodoropoulos
www.anastrophe.com
___
On 6/9/2020 10:51 AM, Paul Theodoropoulos via devel wrote:
On 6/9/2020 3:51 AM, Hal Murray wrote:
I can't figure out how changing something from ntp:ntp to root:ntp is
going to
allow ntpd to read it. Could you say more?
If it tries to read pre-drop root, it is still root and can read
anythin
On 6/9/2020 3:51 AM, Hal Murray wrote:
When I recently installed 3.19 from repo on the new 'raspberry pi os (64
bit)', I had to change /etc/letsencrypt from ownership ntp:ntp to root:ntp
in order to get past the 'permission denied' errors.
3.19 sounds more like a GPSD version. Did you update nt
Hal,
I have solved the issue for now, by changing the group of the live/and
archive/ directories in /etc/letsencrypt to ntp,and giving the group read
permissions.
root@ntpmon:/etc/letsencrypt# ls -l
total 36
drwx-- 4 root root 4096 Oct 21 2018 accounts
drwxr-x--- 3 root ntp 4096 Jan 17 20
> When I recently installed 3.19 from repo on the new 'raspberry pi os (64
> bit)', I had to change /etc/letsencrypt from ownership ntp:ntp to root:ntp
> in order to get past the 'permission denied' errors.
3.19 sounds more like a GPSD version. Did you update ntpsec too?
I can't figure out ho
mikie.simp...@gmail.com said:
> I used to have a symlink into /etc/ntp from /etc/letsencrypt/live... which
> worked until the recent changes.
Do you have old log files? Can you find a case with the old setup where your
ntpd reloaded the updated certificate and key?
The recent change was add
On 6/9/20 3:20 AM, Mike Simpson via devel wrote:
> As you only get a 90 day very from LE I now have a cron job after the
> “certbot renew” which copies the keys over and chown them. It feels clunky.
Use a deploy hook. I wrote the attached one for Debian. Note that Debian
uses user "ntpsec" and gr
Hi Hal,
As you only get a 90 day very from LE I now have a cron job after the “certbot
renew” which copies the keys over and chown them. It feels clunky.
I used to have a symlink into /etc/ntp from /etc/letsencrypt/live... which
worked until the recent changes.
How do apache or openhttpd mana
On 6/8/2020 23:09 PM, ASSI via devel wrote:
Sanjeev Gupta via devel writes:
The file:
-rw-r--r-- 1 root root 3558 May 9 09:39
fullchain28.pem
can't stat certificate (chain) from
/etc/letsencrypt/live/ntpmon.dcs1.biz/fullchain.pem: Permission denied
It seem
Sanjeev Gupta via devel writes:
> The file:
> -rw-r--r-- 1 root root 3558 May 9 09:39
> fullchain28.pem
> can't stat certificate (chain) from
> /etc/letsencrypt/live/ntpmon.dcs1.biz/fullchain.pem: Permission denied
It seems to me you're having NTPd look for the
> But then I lose the automatic rotation :-(
Good catch. I do the update manually after it sends me reminder email.
Is the automatic stuff a cron job? Did you set it up manually, or is there an
option to set it up?
We should make a pass at the documentation collecting these ideas.
--
These
On Tue, Jun 9, 2020 at 12:23 PM Hal Murray wrote:
> > Which causes ntpd to fail on startup (I assume after dropping root):
>
> Looks like you are dying trying to read the certificate. It will get
> worse
> when you want to read the key.
>
> --
>
> Do you trust user ntp? If so, the f
> Which causes ntpd to fail on startup (I assume after dropping root):
Looks like you are dying trying to read the certificate. It will get worse
when you want to read the key.
--
Do you trust user ntp? If so, the fix is to change ownership. I copy the
cert and key over to /etc/
(git commit 892fbb435e71349da502b7e2436648f52a09af6f )
Hal, I have the other end of the stick now.
My LetsEncrypt certificate path is /etc/letsencrypt/archive/ntpmon.dcs1.biz/
The file:
-rw-r--r-- 1 root root 3558 May 9 09:39 fullchain28.pem
However,
root@ntpmon:/etc/letsencrypt# ls -dl /etc/l
rlaa...@wiktel.com said:
> ntpd seems to load the TLS certificate and key before dropping privileges.
> Unfortunately, when it tries to *reload* the certificate later, it has
> dropped privileges and fails. This is a bit of a trap, as a sysadmin can
> think a setup is working when it isn't. (This
ntpd seems to load the TLS certificate and key before dropping
privileges. Unfortunately, when it tries to *reload* the certificate
later, it has dropped privileges and fails. This is a bit of a trap, as
a sysadmin can think a setup is working when it isn't. (This bit me.) I
think it would be bette
16 matches
Mail list logo
