Petr Menšík wrote:
> I don't think it is so easy. It can add facl on resolv.conf file before
> it drops privileges. But Any other process might remove the file again
> and write a new one, preventing openvpn to update it later. Because
> openvpn is not supposed to be owner of /etc/resolv.conf, it
I don't think it is so easy. It can add facl on resolv.conf file before
it drops privileges. But Any other process might remove the file again
and write a new one, preventing openvpn to update it later. Because
openvpn is not supposed to be owner of /etc/resolv.conf, it should not
dictate what
Petr Menšík wrote:
> It is about 2 years when we were removing CAP_DAC_OVERRIDE from our
> services, because selinux-policy does not grant it anymore. I think it
> is a good thing. Running as openvpn user, but requiring then
> CAP_DAC_OVERRIDE is insecure! It gives it more rights than just root
>
On 2/25/21 4:50 PM, David Sommerseth wrote:
> Hi!
>
> On 25/02/2021 14:39, Petr Menšík wrote:
> [..snip...]
>>
>> This case is exactly what I am trying to prevent. There is multiple
>> implementations of dns cache, most of them can support split-DNS by some
>> configuration. If openvpn supports
On 2/25/21 9:06 AM, Peter Boy wrote:
>
>> Am 24.02.2021 um 18:18 schrieb Paul Wouters :
>> There is no technical reason why this is not in its own package. There
>> has been some focussing on reducing minimal installs, and this is a
>> prime candidate for that. I'm fine with the workstation or
On 25/02/2021 16:02, Dan Williams wrote:
On Thu, 2021-02-25 at 11:57 +0100, David Sommerseth wrote:
[...snip...]
* NetworkManger and OpenVPN
Outside of that, OpenVPN via NetworkManager will be a different beast
to
tackle which we have not yet dug into from the OpenVPN project side.
From
Hi!
On 25/02/2021 14:39, Petr Menšík wrote:
[..snip...]
It is not optimal yet, but we plan to provide full support for split-DNS
(only pushed domains will be resolved via the DNS server requested by
the VPN server) and exclusive DNS (use only the DNS server pushed by VPN
server).
>
This case
On Thu, 2021-02-25 at 11:57 +0100, David Sommerseth wrote:
> On 22/02/2021 16:29, Petr Menšík wrote:
> > Why? I thought about common interface to various DNS cache
> > implementations for workstations and different VPN providers
> > available.
> > While I think the best place to direct, which
Hi David,
more below.
On 2/25/21 11:57 AM, David Sommerseth wrote:
> On 22/02/2021 16:29, Petr Menšík wrote:
>> Why? I thought about common interface to various DNS cache
>> implementations for workstations and different VPN providers available.
>> While I think the best place to direct, which
On 22/02/2021 16:29, Petr Menšík wrote:
Why? I thought about common interface to various DNS cache
implementations for workstations and different VPN providers available.
While I think the best place to direct, which interface resolvers should
handle given domains. resolvconf handles conflicting
* Paul Wouters:
> On Mon, 22 Feb 2021, Petr Menšík wrote:
>
>> Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
>> in case I don't want it?
>
> In the past I also mentioned this. The overwhelming majority of installs
> do not gain any benefit from te systemd-resolved
> Am 24.02.2021 um 18:18 schrieb Paul Wouters :
>
> On Mon, 22 Feb 2021, Petr Menšík wrote:
>
>> Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
>> in case I don't want it?
>
> ….
> There is no technical reason why this is not in its own package. There
> has been
On Mon, 22 Feb 2021, Petr Menšík wrote:
Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
in case I don't want it?
In the past I also mentioned this. The overwhelming majority of installs
do not gain any benefit from te systemd-resolved service. Most servers,
containers
Michael Catanzaro wrote:
> Is there some reason systemd-resolved cannot be a subpackage? Seems
> like that would be the easiest solution?
+1 to making this a subpackage. I really don't see why this has to be part
of the main systemd package.
There are other optional parts of systemd that should
On 2/22/21 9:12 PM, Lennart Poettering wrote:
> Quite frankly, I am not sure it would be a good idea to do things that
> way.
>
> note that resolved should be fine as a resolvconf replacement, even if
> you don't want to use it as a resolver: just set the /etc/resolv.conf
> symlink to
On Mo, 22.02.21 17:15, Petr Menšík (pemen...@redhat.com) wrote:
> Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
> in case I don't want it? Then I don't have to make a proxy, but install
> indeed a different package providing resolvconf. I think I would submit
> that PR
On Mon, Feb 22, 2021 at 5:15 pm, Petr Menšík
wrote:
Wouldn't it be much simpler, if I could just dnf remove
systemd-resolved
in case I don't want it?
Is there some reason systemd-resolved cannot be a subpackage? Seems
like that would be the easiest solution?
If that's problematic for some
Wouldn't it be much simpler, if I could just dnf remove systemd-resolved
in case I don't want it? Then I don't have to make a proxy, but install
indeed a different package providing resolvconf. I think I would submit
that PR on Fedora package instead. Or don't have any
/usr/sbin/resolvconf, in
On Mo, 22.02.21 16:29, Petr Menšík (pemen...@redhat.com) wrote:
It might be OK for systemd's resolvectl to pass the call on to some
other executable if it notices resolved is not there. We do the same
in the "telinit" tool, so that Debian can have multiple init systems,
and when ours owns the
Hi,
I have submitted new package openresolv [1], which provides resolvconf
tool, similar to Debian's resolvconf package.
Why? I thought about common interface to various DNS cache
implementations for workstations and different VPN providers available.
While I think the best place to direct,
20 matches
Mail list logo
