[systemd-devel] systemd-resolved: Using different dns server for a certain suffix

2017-02-07 Thread Daurnimator 
I'm trying to add tor support to a system that uses systemd for
network configuration.
I have configured tor to listen for local DNS queries on 127.0.0.2.
Now I'd like systemd-resolved to resolve queries that end in ".onion"
to go to that DNS server.
See what I've tried:

02-08 05:59:39 daurnimator@daurn-vultr /etc/systemd/network $ cat tor.network
[Match]
Name=lo

[Network]
DNS=127.0.0.2
Domains=~onion
02-08 06:00:23 daurnimator@daurn-vultr /etc/systemd/network $ dig
@127.0.0.2 frxleqtzgvwkv7oz.onion

; <<>> DiG 9.11.0-P2 <<>> @127.0.0.2 frxleqtzgvwkv7oz.onion
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 899
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;frxleqtzgvwkv7oz.onion. IN A

;; ANSWER SECTION:
frxleqtzgvwkv7oz.onion. 60 IN A 127.192.40.24

;; Query time: 0 msec
;; SERVER: 127.0.0.2#53(127.0.0.2)
;; WHEN: Wed Feb 08 06:00:28 UTC 2017
;; MSG SIZE  rcvd: 56

02-08 06:00:28 daurnimator@daurn-vultr /etc/systemd/network $ dig
@127.0.0.53 frxleqtzgvwkv7oz.onion

; <<>> DiG 9.11.0-P2 <<>> @127.0.0.53 frxleqtzgvwkv7oz.onion
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 25762
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;frxleqtzgvwkv7oz.onion. IN A

;; Query time: 14 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Wed Feb 08 06:00:31 UTC 2017
;; MSG SIZE  rcvd: 51

02-08 06:00:31 daurnimator@daurn-vultr /etc/systemd/network $ sudo
systemctl status systemd-resolved
● systemd-resolved.service - Network Name Resolution
   Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service;
enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-02-08 05:52:04 UTC; 9min ago
 Docs: man:systemd-resolved.service(8)
   http://www.freedesktop.org/wiki/Software/systemd/resolved
   
http://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
   
http://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
 Main PID: 29816 (systemd-resolve)
   Status: "Processing requests..."
Tasks: 1 (limit: 4915)
   CGroup: /system.slice/systemd-resolved.service
   └─29816 /usr/lib/systemd/systemd-resolved

Feb 08 05:52:03 daurn-vultr systemd[1]: Starting Network Name Resolution...
Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: Positive Trust Anchors:
Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: . IN DS 19036 8 2
49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: Negative trust
anchors: 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa
18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21
Feb 08 05:52:04 daurn-vultr systemd-resolved[29816]: Using system
hostname 'daurn-vultr'.
Feb 08 05:52:04 daurn-vultr systemd[1]: Started Network Name Resolution.
Feb 08 05:52:06 daurn-vultr systemd-resolved[29816]: Switching to DNS
server 108.61.10.10 for interface ens3.
Feb 08 06:00:31 daurn-vultr systemd-resolved[29816]: Processing query...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Errorneous detection of degraded array

2017-02-07 Thread NeilBrown 
On Tue, Jan 31 2017, Andrei Borzenkov wrote:

>
 Changing the
   Conflicts=sys-devices-virtual-block-%i.device
 lines to
   ConditionPathExists=/sys/devices/virtual/block/%i
 might make the problem go away, without any negative consequences.

>>>
>>> Ugly, but yes, may be this is the only way using current systemd.
>>>
>
> This won't work. sysfs node appears as soon as the very first array
> member is found and array is still inactive, while what we need is
> condition "array is active".

Of course, you are right.
A suitable "array is active" test is the existence of
  .../md/sync_action
which appears when an array is activated (except for RAID0 and Linear,
which don't need last-resort support).

So this is what I propose to post upstream.  Could you please confirm
that it works for you?  It appears to work for me.

Thanks,
NeilBrown

From: NeilBrown 
Date: Wed, 8 Feb 2017 15:01:05 +1100
Subject: [PATCH] systemd/mdadm-last-resort: use ConditionPathExists instead of
 Conflicts

Commit cec72c071bbe ("systemd/mdadm-last-resort: add Conflicts to .service 
file.")

added a 'Conflicts' directive to the mdadm-last-resort@.service file in
the hope that this would make sure the service didn't run after the device
was active, even if the timer managed to get started, which is possible in
race conditions.

This seemed to work is testing, but it isn't clear why, and it is known
to cause problems.
If systemd happens to know that the mentioned device is a dependency of a
mount point, the Conflicts can unmount that mountpoint, which is certainly
not wanted.

So remove the "Conflicts" and instead use
 ConditionPathExists=!/sys/devices/virtual/block/%i/md/sync_action

The "sync_action" file exists for any array which require last-resort
handling, and only appear when the array is activated.  So it is safe
to reliy on it to determine if the last-resort is really needed.

Fixes: cec72c071bbe ("systemd/mdadm-last-resort: add Conflicts to .service 
file.")
Signed-off-by: NeilBrown 
---
 systemd/mdadm-last-resort@.service | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/systemd/mdadm-last-resort@.service 
b/systemd/mdadm-last-resort@.service
index e93d72b2b45e..f9d4d12738a3 100644
--- a/systemd/mdadm-last-resort@.service
+++ b/systemd/mdadm-last-resort@.service
@@ -1,7 +1,7 @@
 [Unit]
 Description=Activate md array even though degraded
 DefaultDependencies=no
-Conflicts=sys-devices-virtual-block-%i.device
+ConditionPathExists=!/sys/devices/virtual/block/%i/md/sync_action
 
 [Service]
 Type=oneshot
-- 
2.11.0



signature.asc
Description: PGP signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] how to add test sysfs nodes, to sys.tar.xz?

2017-02-07 Thread Dan Streetman 
On Sun, Feb 5, 2017 at 6:26 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Mon, Jan 30, 2017 at 05:40:40PM -0500, Dan Streetman wrote:
>> On Thu, Jan 26, 2017 at 9:36 AM, Zbigniew Jędrzejewski-Szmek
>>  wrote:
>> > Thanks for working on the tests.
>> >
>> > On Thu, Jan 26, 2017 at 09:21:41AM -0500, Dan Streetman wrote:
>> >> However, I'd like to also add tests for whitespace replacement using
>> >> actual device $attr{}, which I think means the test/sys.tar.xz file
>> >> needs to be updated to add device (maybe a NVMe device) nodes that
>> >> include whitespace in its model and/or serial strings - is that how
>> >> new test sysfs device nodes are added?  Updating the entire binary
>> >> seems like a big change just for a few device node files..
>> > It's only 162k. It's not perfect that we have to update it every time
>> > we add tests, but it's not too terrible.
>> >
>> > If you're feeling ambitious, you might want to convert that tarball to
>> > a script which generates the nodes. After all, it's just a bunch of
>> > directories, with symlinks and a few simple text files. Then this will
>> > be normal text file and git will be able to track changes to it. This
>> > would a much nicer solution in the long run.
>>
>> I crafted a script that does that, which isn't complex, although it
>> isn't simple either.  However, I'm wondering, why not just store the
>> files directly in git?  It would be simpler than either the tarball or
>> a script, and git can handle symlinks and binary files, unless there's
>> some shortcoming that I'm not seeing?
>
> In principle, this would work too. But git tools aren't too good when
> working with symlinks (e.g. git diff treats them as normal text files,
> and displays a stupid warning about a missing newline, etc). When
> scaled to the number of files in /sys, I think working with this
> approach would be rather unpleasant.
>
> Can you paste the script you have?

yep, opened pr 5250
https://github.com/systemd/systemd/pull/5250

>
> Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel