Am 30.03.2015 um 01:17 schrieb Michael Biebl:
> So I suggest using the Type=forking option but also setting
> RestartPreventExitStatus=255 [1], since 255 seems to be the return code
> on config errors and I don't think it makes sense to restart in that case.
>
> The resulting ssh.service would loo
On Mar 18, Faidon Liambotis wrote:
> Well, the root cause IMO is that 75-persistent-net-generator.rules is
> inherently susceptible to races. It's my understanding that it's valid
> for events to be triggered multiple times -- there are multiple places
> in d-i that "udevadm trigger" is called, i
Am 30.03.2015 um 04:56 schrieb Michael Biebl:
> Looks like a found a simple reproducer (this is on my work laptop) done
> during normal runtime of the system:
>
> $ rm /etc/udev/rules.d/70-persistent-net.rules
> $ while true ; do echo add > /sys/class/net/eth0/uevent ; done
>
> I let this run fo
Processing control commands:
> tags -1 confirmed
Bug #765577 [udev-udeb] netboot install writes duplicates to
70-persistent-net.rules
Bug #777126 [udev-udeb] udev: duplicate eth? entries
Added tag(s) confirmed.
Added tag(s) confirmed.
--
765577: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=
Control: tags -1 confirmed
Am 18.03.2015 um 19:50 schrieb Michael Biebl:
> Am 18.03.2015 um 18:52 schrieb Michael Biebl:
>> Am 18.03.2015 um 18:15 schrieb Faidon Liambotis:
>>> Another less arbitrary/racy workaround I suggesed was a grep near the
>>> top of write_net_rules' write_rule() function.
Hi,
I agree: no nameserver → no resolution.
Please reopen this bug report.
Thank you!
Carlo
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-mai
How come this issue isn't RC?
You're sending every DNS resolution attempt, and thus effectively the
metadata on almost any TCP/IP connection, to a company well-known to
collect and use this kind of data.
This is worse than, say, Ubuntu's Unity Lens spyware.
__
Am 22.02.2015 um 19:45 schrieb Russ Allbery:
> That's the problem with forking services that don't have status
> notification. The default is Type=simple, which per systemd.service(5):
>
> If set to simple (the default value if neither Type= nor BusName=
> are specified), it is expected t
btw: Letting people use unknowingly a specific nameserver may have also
further consequences than just privacy leakage.
Since e.g. the Google nameservers are well known to allow people to
circumvent DNS blocks, they're quite likely under special observation by
governmental agencies in autocratic c
On Sun, 2015-03-29 at 12:47 +0200, Marco d'Itri wrote:
> So far, it is. If you still want to argue about this (which I something
> that I strongly recommend against!), then you should explain in detail
> the threat model that you are trying to address and how the current
> configuration would be
Processing commands for cont...@bugs.debian.org:
> tags 762700 + pending
Bug #762700 [systemd] systemd: journald fails to forward some messages to syslog
Added tag(s) pending.
> thanks
Stopping processing here.
Please contact me if you need assistance.
--
762700: http://bugs.debian.org/cgi-bin/b
On Mar 29, Christoph Anton Mitterer wrote:
> And AFAIU the problem of data/privacy leakage isn't just made up, is it?
So far, it is. If you still want to argue about this (which I something
that I strongly recommend against!), then you should explain in detail
the threat model that you are tryin
On Sun, 29 Mar 2015 05:57:22 +0200 m...@linux.it (Marco d'Itri) wrote:
> This default is not used as long as a resolver has been configured by
> the system administrator or provided by DHCP, and I see no value in
> allocating development time to break cases which currently work by
> removing suppor
Am Sonntag, 29. März 2015, 07:18:43 schrieb Christoph Anton Mitterer:
> On Sun, 2015-03-29 at 06:55 +0200, Michael Biebl wrote:
> > Am 29.03.2015 um 06:35 schrieb Christoph Anton Mitterer:
> > > I'm really not inclined to start another security discussion, since
> > > that's already lost cause in D
Am Sonntag, 29. März 2015, 08:28:20 schrieb martin f krafft:
> also sprach Christoph Anton Mitterer [2015-03-29
07:18 +0200]:
> > So if resolved is used - and I'd guess that's the long term goal
> > - then people would automatically get resolving - always.
> > Even when they have /etc/resolv.conf
Am Sonntag, den 29.03.2015, 04:31 +0200 schrieb Marco d'Itri:
> At this time I see no obvious justifications for #4, but still it would
> help if the people interested in enabling this feature could document
> how it is used in practice.
Hi,
although I filed this bug, I don't actually use syste
16 matches
Mail list logo
