On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
> On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
>
> > A system wide resolver I am not opposed to. I am against a system wide
> > *caching* resolver.
>
> > In this case, a cache *is* helpful, as is DNSSEC. But for the other 6, a
> > c
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:
> On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
> > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
> >
> > > A system wide resolver I am not opposed to. I am against a system wide
> > > *caching* resolver.
> >
> > > In this
A new version of a package I maintain added an appdata.xml. As I haven't
handled such files before, I looked up the internet for some
information. The only helpful hint I found, was a commit adding appdata
support to the qt-creator package in fedora git. [1]
As more packages will add appdata f
William Brown wrote:
>> The cache is never fully flushed. It is only flushed for the domain
>> obtained via DHCP or VPN, because those entries can change. They are
>> not changed for anything else. If the upstream ISP could have
>> spoofed them, so be it - the publisher of the domains could have
>>
William Brown wrote:
>In businesses, it's also common place to have a low-ish ttl (Say 5
>minutes) and when a system is migrated, they swap the A/ records to
>the new system. The dns servers on the network are updated, but the
>workstation has the old record cached. Without a local cache, they
william wrote:
> [...]
> Internal and external zone views in a business. These records may
> different, and so would need flushing between network interface state
> changes.
Sure, let's make it easy to restart the cache upon such transitions.
> Additionally, local DNS caches may issues and dela
On Sun, 13 Apr 2014, William Brown wrote:
Yes. It depends on the "trustworthiness" of the network and or
preconfiguration of some of your own networks you join.
Not really: Every network you join, you have to semi-trust. If you don't
trust it, why did you join it?
You don't always control wh
On Sun, 13 Apr 2014, William Brown wrote:
PS: It also seemed like the proposal was to *bypass* the networks
provided forwarders from DHCP. This *is* a serious issue if it's the
case.
We only bypass DHCP provided forwarders that are broken. We actually
WANT to use them as much as possible, beca
On Sun, 2014-04-13 at 16:29 +0930, William Brown wrote:
> > That depends. You need caching for DNSSEC validation, so really,
> every
> > device needs a cache, unless you want to outsource your DNSSEC
> > validation over an insecure transport (LAN). That seems like a very
> bad
> > idea.
>
> If you
On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote:
> So you've gone out of your way to run a daemon but prevent it from
> working as configured, instead of just reconfiguring it to do what you
> need.
I have to go out of my way to *stop* NetworkManager from running and
to configure a fixe
On Sun, 2014-04-13 at 16:39 +0930, William Brown wrote:
> On Sun, 2014-04-13 at 02:53 -0400, Simo Sorce wrote:
> > On Sun, 2014-04-13 at 16:10 +0930, William Brown wrote:
> >
> > > A system wide resolver I am not opposed to. I am against a system wide
> > > *caching* resolver.
> >
> > > In this
On Sun, 2014-04-13 at 18:18 +0100, Richard W.M. Jones wrote:
> On Sat, Apr 12, 2014 at 04:12:41PM -0400, Simo Sorce wrote:
> > So you've gone out of your way to run a daemon but prevent it from
> > working as configured, instead of just reconfiguring it to do what you
> > need.
>
> I have to go ou
On Mon, 2014-04-07 at 18:29 +0100, Andrew Haley wrote:
> On 04/07/2014 03:23 PM, Peter Robinson wrote:
> >> There have been a few discussions about this in the past but no action.
> >> With feature freeze approaching for F21, I think this is a good time to
> >> address this.
> >>
> >> I will be orp
On Sun, 13 Apr 2014, Richard W.M. Jones wrote:
So you've gone out of your way to run a daemon but prevent it from
working as configured, instead of just reconfiguring it to do what you
need.
I have to go out of my way to *stop* NetworkManager from running and
to configure a fixed IP address.
On Sun, Apr 13, 2014 at 10:18 AM, Richard W.M. Jones
wrote:
Unfortunately NetworkManager can't handle brief network outages
without dropping the connection (RHBZ#1022954 comment 3). This isn't
desirable for servers that have ethernet and fixed IP addresses.
NetworkManager-config-server fixes
Hello,
Please see:
-> http://www.ietf.org/mail-archive/web/dane/current/msg06469.html
-> https://www.ietf.org/mail-archive/web/dane/current/msg06658.html
These two threads are about handling of Authenticated Data(AD) bit by the stub
resolvers. There two proposed solutions for this problem:
On 04/11/2014 05:19 PM, Lennart Poettering wrote:
On Fri, 11.04.14 19:05, Miloslav Trmač (m...@volny.cz) wrote:
There is broad agreement that future access to the user database database
(both reading and writing) will be through sssd[1], and that the data model
of /etc/{passwd,shadow} is too r
On Sun, Apr 13, 2014 at 02:21:03PM +0200, Markus Mayer wrote:
> A new version of a package I maintain added an appdata.xml. As I
> haven't handled such files before, I looked up the internet for some
> information. The only helpful hint I found, was a commit adding
> appdata support to the qt-creat
> > But you can't account for every captive portal in the world. This is why
> > the cache is a bad idea, because you can't possibly account for every
> > system that is captive like this.
>
> Yes we can by monitoring for "captivity signs" when a new network is
> joined. Again, please yum install
On Mon, 14 Apr 2014, William Brown wrote:
What is a "captivity-sign" as you so put it?
Check for clean port 80. It fetches the url specified in
dnssec-triggerd.conf's url: option
(default http://fedoraproject.org/static/hotspot.txt)
If it returns a redirect or a page that does not contain the
On Mon, 2014-04-14 at 00:42 -0400, Paul Wouters wrote:
> On Mon, 14 Apr 2014, William Brown wrote:
>
> > What is a "captivity-sign" as you so put it?
>
> Check for clean port 80. It fetches the url specified in
> dnssec-triggerd.conf's url: option
> (default http://fedoraproject.org/static/hotspo
On 2014-04-11, Jaroslav Reznik wrote:
>= Proposed System Wide Change: The securetty file is empty by default =
> https://fedoraproject.org/wiki/Changes/securetty_file_is_empty_by_default
>
[...]
> Disabling root access via any console device (tty).
>
This is silly. If a system has been broken v
22 matches
Mail list logo
