Re: Proposal for improvement of newsyslog.conf
On Wed, 2021-12-08 at 02:12 +0300, Антон Касимов wrote: > Hi, > I've noticed that newsyslog sends SIGHUP to syslogd on /var/log/wtmp > rotation. > But syslogd does not deal with the wtmp log file so there is no need for > SIGHUP. > > I propose to make slightly changes to default newsyslog.conf file: > 13c13 > < /var/log/wtmp 644 7 *$W6D4 B > --- > > /var/log/wtmp 644 7 *$W6D4 B "" > > Is misc a proper mailing list, or shall I send this message to bugs? > tech@ is usually the best place for this kind of suggestions. Also make sure that you make your diff unified (diff -u). martijn@
relayd unable to get local issuer certificate
Hello,
I decided to try using relayd as a TLS accelerator and have run into an
issue - as usual, I'm sure I'm missing something obvious.
I generated a TLS cert with acme-client and tested and confirmed it
worked with httpd. I then configured relayd to perform TLS acceleration
by following examples in the man pages. Everything works great when
tested from a web browser. However, when I try to fetch a file via curl,
wget or ftp etc, I get a cert validation error: (ip and domain removed
for privacy)
...
$ curl -iv https://www.example.com:8088/test.txt
* Trying 192.0.1.189:8088...
* Connected to www.example.com (192.0.1.189) port 8088 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Unknown (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* SSL certificate problem: unable to get local issuer certificate
* Closing connection 0
curl: (60) SSL certificate problem: unable to get local issuer certificate
More details here: https://curl.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
...
My relayd config looks like this:
...
http protocol https {
match request header append "X-Forwarded-For" value "$REMOTE_ADDR"
match request header append "X-Forwarded-By" \
value "$SERVER_ADDR:$SERVER_PORT"
match request header set "Connection" value "close"
# Various TCP options
tcp { sack, backlog 128 }
tls { no tlsv1.0, ciphers HIGH, keypair example.com }
# tls no session tickets
}
relay test {
# Run as a SSL/TLS accelerator
listen on $ext_addr port 8088 tls
protocol https
# Forward to hosts in the webhosts table using a src/dst hash
forward to port 80 mode loadbalance \
check icmp
}
...
I'm not sure what the issue is here, this is my first foray into relayd
TLS acceleration, so I was hoping to get a quick sanity check here to
make sure I'm not missing something obvious. I've certainly put some
legwork into figuring this out, I spent all day futzing with this to no
avail. Everything here is bog standard, so I'm curious what I'm doing wrong.
As usual, any insight or advice would be greatly appreciated.
Regards,
Jordan
Proposal for improvement of newsyslog.conf
Hi, I've noticed that newsyslog sends SIGHUP to syslogd on /var/log/wtmp rotation. But syslogd does not deal with the wtmp log file so there is no need for SIGHUP. I propose to make slightly changes to default newsyslog.conf file: 13c13 < /var/log/wtmp 644 7 *$W6D4 B --- > /var/log/wtmp 644 7 *$W6D4 B "" Is misc a proper mailing list, or shall I send this message to bugs? -- Антон Касимов / Anton Kasimov
Re: Unwind does not seem to query forwarders it is pointed to
> So something is odd. When unwind starts or learns about new resolvers it
> checks if they can do DNSSEC validation. It the equivalent of this:
>
> dig @192.168.1.150 +dnssec . NS
> and
> dig @192.168.1.1 +dnssec . NS
>
> and got a response it liked.
192.168.1.150 is a Samba 4 internal DNS server which I think is not
capable of dnssec yet. And I do not need it now. It is pointed to
192.168.1.1 as a forwarder.
192.168.1.1 is an unbound + nsd OpenBSD router which I did not set up to do
dnssec. It is pointed to
my provider's DNS server as a forwarder.
I do not quite understand how any of the two DNS servers pretend to give DNSSEC
information
On Пн 06 дек 2021 17:20:28, Florian Obser wrote:
> On 2021-12-06 13:49 +03, Maksim Rodin wrote:
> > Hello
> > I have the following unwind.conf:
> > ```
> > cat /etc/unwind.conf
> > fwd1=192.168.1.150
> > fwd2=192.168.1.1
> > forwarder { $fwd1 $fwd2 }
> > preference forwarder
> > ```
> > and an automatically generated resolv.conf:
> > ```
> > cat /etc/resolv.conf
> > nameserver 127.0.0.1 # resolvd: unwind
> > lookup file bind
> > ```
> > I may not understand the purpose of unwind correctly but I expect the
> > unwind to respond to DNS queries using the forwarders it is pointed to
> > in its config.
>
> That is one purpose, and you configured it do exactly that.
>
> > But when I do:
> > ```
> > nslookup dc.mydomain.ru
> > ```
> > It says:
> > ```
> > Server: 127.0.0.1
> > Address:127.0.0.1#53
> >
> > ** server can't find dc.mydomain.ru: SERVFAIL
> > ```
> >
> > And I see in the logs the following:
> > ```
> > unwind[8550]: validation failure : no signatures from
> > 192.168.1.150 for DS ru. while building chain of trust
> > ```
> > The DNS server on 192.168.1.150 definitely knows about the host
> > dc.mydomain.ru
> >
> > When I ask that DNS server directly:
> > ```
> > nslookup dc.mydomain.ru 192.168.1.150
> > ```
> > It returns the correct answer
> >
> > So the unwind daemon seems to always query root name servers instead of my
> > two
> > servers.
> > Is that the expected behavior?
>
> It does not do that. I talks to your two servers. But it tries to do
> DNSSEC validation: "no signatures from 192.168.1.150 for DS ru."
>
> So something is odd. When unwind starts or learns about new resolvers it
> checks if they can do DNSSEC validation. It the equivalent of this:
>
> dig @192.168.1.150 +dnssec . NS
> and
> dig @192.168.1.1 +dnssec . NS
>
> and got a response it liked.
>
> $ unwindctl status
>
> probably outputs something like
>
> 1. forwarder validating
>
> So it knows the root zone is signed and your forwarders hand out DNSSEC
> information, but for some reason your forwarders do not answer to
>
> dig @192.168.1.150 +dnssec ru DS
>
> No idea why.
>
> >
> > --
> > Maksim Rodin
> >
>
> --
> I'm not entirely sure you are real.
>
--
С уважением,
Родин Максим
