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
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 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
> > 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 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
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
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 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
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 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, 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 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 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: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 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, 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
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
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 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
>>
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
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 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
22 matches
Mail list logo
