Re: [systemd-devel] systemd-journal-remote

2014-03-18 Thread David Timothy Strauss 
On Sun, Mar 16, 2014 at 11:29 PM, Zbigniew Jędrzejewski-Szmek
zbys...@in.waw.pl wrote:
 Curl requires the whole file to be exported first, which isn't great,
 because it wants to give the content size in the header. I'm note
 sure if it is possible to tell it to not do that.

I'm think you just need to implement your own function to use with
CURLOPT_READFUNCTION and set a chunked encoding header [1] instead of
giving libcurl an actual file to upload. You can return zero when
you're done sending everything you want to send.

[1] http://curl.haxx.se/libcurl/c/post-callback.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd bridge with DHCP not working

2014-03-18 Thread Henrik /KaarPoSoft 

On 03/17/2014 10:32 PM, Tom Gundersen wrote:

On Mon, Mar 17, 2014 at 10:21 PM, Henrik /KaarPoSoft
hen...@kaarposoft.dk wrote:

Hi Tom,

Thanks for your feedback...

I was briefly looking through git commits after 211 without finding anything
related. But then again I did not look into too much detail.

Do you know which commit would solve this?


Ah, this was not obvious at all. This was almost certainly fixed as a
side-effect of refactoring the rtnl_message_read_*() code, so if you
pull in 9842de0d93d and the commits it relies on that should do it (I
haven't verified that that's the culprit, but it seems likely from
looking at it).

Cheers,

Tom


Tom,
As far as I can see, 9842de0d93d was already included in 211.
I have rebuild my systemd from the head of git 4dd5da7f.
And the problem remains )))-:
/Henrik

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd bridge with DHCP not working

2014-03-18 Thread Henrik /KaarPoSoft 

On 03/18/2014 09:18 AM, Henrik /KaarPoSoft wrote:

On 03/17/2014 10:32 PM, Tom Gundersen wrote:

On Mon, Mar 17, 2014 at 10:21 PM, Henrik /KaarPoSoft
hen...@kaarposoft.dk wrote:

Hi Tom,

Thanks for your feedback...

I was briefly looking through git commits after 211 without finding
anything
related. But then again I did not look into too much detail.

Do you know which commit would solve this?


Ah, this was not obvious at all. This was almost certainly fixed as a
side-effect of refactoring the rtnl_message_read_*() code, so if you
pull in 9842de0d93d and the commits it relies on that should do it (I
haven't verified that that's the culprit, but it seems likely from
looking at it).

Cheers,

Tom


Tom,
As far as I can see, 9842de0d93d was already included in 211.
I have rebuild my systemd from the head of git 4dd5da7f.
And the problem remains )))-:
/Henrik


As a quick hack, I tried this:

cat  /etc/systemd/network/42-br0.linkEOF
[Match]
Type=bridge
[Link]
MACAddress=10:bf:48:d7:68:e1
EOF

And now I get an IP address by DHCP, and I have connectivity.

But hard-coding the MAC is hardly a viable long-term solution...

/Henrik
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd bridge with DHCP not working

2014-03-18 Thread Tom Gundersen 
On Tue, Mar 18, 2014 at 10:00 AM, Henrik /KaarPoSoft
hen...@kaarposoft.dk wrote:
 On 03/18/2014 09:18 AM, Henrik /KaarPoSoft wrote:

 On 03/17/2014 10:32 PM, Tom Gundersen wrote:

 On Mon, Mar 17, 2014 at 10:21 PM, Henrik /KaarPoSoft
 hen...@kaarposoft.dk wrote:

 Hi Tom,

 Thanks for your feedback...

 I was briefly looking through git commits after 211 without finding
 anything
 related. But then again I did not look into too much detail.

 Do you know which commit would solve this?


 Ah, this was not obvious at all. This was almost certainly fixed as a
 side-effect of refactoring the rtnl_message_read_*() code, so if you
 pull in 9842de0d93d and the commits it relies on that should do it (I
 haven't verified that that's the culprit, but it seems likely from
 looking at it).

 Cheers,

 Tom

 Tom,
 As far as I can see, 9842de0d93d was already included in 211.
 I have rebuild my systemd from the head of git 4dd5da7f.
 And the problem remains )))-:
 /Henrik


 As a quick hack, I tried this:

 cat  /etc/systemd/network/42-br0.linkEOF
 [Match]
 Type=bridge
 [Link]
 MACAddress=10:bf:48:d7:68:e1
 EOF

 And now I get an IP address by DHCP, and I have connectivity.

 But hard-coding the MAC is hardly a viable long-term solution...

Yeah, that's not going to fly.

Could you attach the full debug output of a failing run? To get it,
you probably want to stop systemd-networkd, ip link del the bridge,
and start networkd from the commandline:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

I think I understand what's going on, but I'd like to have it verified
before changing anything.

Cheers,

Tom
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] systemd-networkd bridge with DHCP not working

2014-03-18 Thread Henrik /KaarPoSoft 

On 03/18/2014 10:10 AM, Tom Gundersen wrote:

On Tue, Mar 18, 2014 at 10:00 AM, Henrik /KaarPoSoft
hen...@kaarposoft.dk wrote:

On 03/18/2014 09:18 AM, Henrik /KaarPoSoft wrote:


On 03/17/2014 10:32 PM, Tom Gundersen wrote:


On Mon, Mar 17, 2014 at 10:21 PM, Henrik /KaarPoSoft
hen...@kaarposoft.dk wrote:


Hi Tom,

Thanks for your feedback...

I was briefly looking through git commits after 211 without finding
anything
related. But then again I did not look into too much detail.

Do you know which commit would solve this?



Ah, this was not obvious at all. This was almost certainly fixed as a
side-effect of refactoring the rtnl_message_read_*() code, so if you
pull in 9842de0d93d and the commits it relies on that should do it (I
haven't verified that that's the culprit, but it seems likely from
looking at it).

Cheers,

Tom


Tom,
As far as I can see, 9842de0d93d was already included in 211.
I have rebuild my systemd from the head of git 4dd5da7f.
And the problem remains )))-:
/Henrik



As a quick hack, I tried this:

cat  /etc/systemd/network/42-br0.linkEOF
[Match]
Type=bridge
[Link]
MACAddress=10:bf:48:d7:68:e1
EOF

And now I get an IP address by DHCP, and I have connectivity.

But hard-coding the MAC is hardly a viable long-term solution...


Yeah, that's not going to fly.

Could you attach the full debug output of a failing run? To get it,
you probably want to stop systemd-networkd, ip link del the bridge,
and start networkd from the commandline:

# SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd

I think I understand what's going on, but I'd like to have it verified
before changing anything.

Cheers,

Tom



I guess running from the commandline should not be necessary since I have
[Service]
Environment=SYSTEMD_LOG_LEVEL=debug
in
/etc/systemd/system/systemd-networkd.service.d/debug.conf

Log attached.

/henrik

cat  /etc/systemd/network/42-br0.netdevEOF
[NetDev]
Name=br0
Kind=bridge
EOF

cat  /etc/systemd/network/44-en.networkEOF
[Match]
Name=${IF}

[Network]
Bridge=br0
EOF

cat  /etc/systemd/network/46-br0.networkEOF
[Match]
Name=br0

[Network]
DHCP=yes
EOF

journalctl -b _SYSTEMD_UNIT=systemd-networkd.service|cat

Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: timestamp of 
'/etc/systemd/network' changed
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: timestamp of 
'/run/systemd/network' changed
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: creating netdev
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: eno1: found matching 
network '/etc/systemd/network/44-en.network'
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: eno1: requesting link status
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: eno1: enslaving by 'br0'
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: eno1: link (with ifindex 2) 
added
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: enp11s0: link (with ifindex 
3) added
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: found matching network 
'/etc/systemd/network/46-br0.network'
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: requesting link status
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: bringing link up
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: link (with ifindex 5) 
added
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: lo: link (with ifindex 1) 
added
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: sit0: link (with ifindex 4) 
added
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: link already exists, 
ignoring
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: netdev ready
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: enslaving link 'eno1'
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: MAC address: 
26:1b:73:27:88:8d
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: link status updated: 
 - 0x1002
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: Sent message 
type=method_call sender=n/a destination=org.freedesktop.DBus 
object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=Hello 
cookie=1 reply_cookie=0 error=n/a
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: eno1: MAC address: 
10:bf:48:d7:68:e1
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: eno1: link status updated: 
 - 0x1002
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: Got message 
type=method_return sender=org.freedesktop.DBus destination=:1.3 object=n/a 
interface=n/a member=n/a cookie=1 reply_cookie=1 error=n/a
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: MAC address: 
26:1b:73:27:88:8d
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: Got message type=signal 
sender=org.freedesktop.DBus destination=:1.3 object=/org/freedesktop/DBus 
interface=org.freedesktop.DBus member=NameAcquired cookie=2 reply_cookie=0 
error=n/a
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: MAC address: 
26:1b:73:27:88:8d
Mar 18 10:27:24 komplett-21 systemd-networkd[2667]: br0: link is up
Mar 18 10:27:24 komplett-21

Re: [systemd-devel] systemd-networkd bridge with DHCP not working

2014-03-18 Thread poma 
...

- journalctl/systemd-networkd:
systemd-networkd[597]: timestamp of '/etc/systemd/network' changed
systemd-networkd[597]: timestamp of '/run/systemd/network' changed
systemd-networkd[597]: bridge0: creating netdev
systemd-networkd[597]: enp1s6: link (with ifindex 2) added
systemd-networkd[597]: enp1s9: link (with ifindex 3) added
systemd-networkd[597]: enp3s0: found matching network
'/etc/systemd/network/base0.network'
systemd-networkd[597]: enp3s0: requesting link status
systemd-networkd[597]: enp3s0: enslaving by 'bridge0'
systemd-networkd[597]: enp3s0: link (with ifindex 4) added
systemd-networkd[597]: bridge0: found matching network
'/etc/systemd/network/bridge0dhcp.network'
systemd-networkd[597]: bridge0: requesting link status
systemd-networkd[597]: bridge0: bringing link up
systemd-networkd[597]: bridge0: link (with ifindex 5) added
systemd-networkd[597]: lo: link (with ifindex 1) added
systemd-networkd[597]: bridge0: link already exists, ignoring
systemd-networkd[597]: bridge0: netdev ready
systemd-networkd[597]: bridge0: enslaving link 'enp3s0'
systemd-networkd[597]: bridge0: MAC address: ba:d4:25:ca:79:58
systemd-networkd[597]: bridge0: link status updated:  - 0x1002
systemd-networkd[597]: Sent message type=method_call sender=n/a
destination=org.freedesktop.DBus object=/org/freedesktop/DBus
interface=org.freedesktop.DBus member=Hello cookie=1 reply_cookie=0
error=n/a
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: enp3s0: link status updated:  - 0x1002
systemd-networkd[597]: Got message type=method_return
sender=org.freedesktop.DBus destination=:1.6 object=n/a interface=n/a
member=n/a cookie=1 reply_cookie=1 error=n/a
systemd-networkd[597]: Got message type=signal
sender=org.freedesktop.DBus destination=:1.6
object=/org/freedesktop/DBus interface=org.freedesktop.DBus
member=NameAcquired cookie=2 reply_cookie=0 error=n/a
systemd-networkd[597]: bridge0: MAC address: ba:d4:25:ca:79:58
systemd-networkd[597]: bridge0: MAC address: ba:d4:25:ca:79:58
systemd-networkd[597]: bridge0: link is up
systemd-networkd[597]: bridge0: carrier on
systemd-networkd[597]: DHCP CLIENT: set MAC address to ba:d4:25:ca:79:58
systemd-networkd[597]: bridge0: acquiring DHCPv4 lease
systemd-networkd[597]: DHCP CLIENT: STARTED
systemd-networkd[597]: bridge0: link status updated: 0x1002 -
0x00011043
systemd-networkd[597]: DHCP CLIENT: DISCOVER
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: bridge0: MAC address: ba:d4:25:ca:79:58
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: bridge0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: bridge0: carrier off
systemd-networkd[597]: DHCP CLIENT: STOPPED
systemd-networkd[597]: bridge0: link status updated: 0x00011043 -
0x1043
systemd-networkd[597]: enp3s0: enslaved
systemd-networkd[597]: enp3s0: bringing link up
systemd-networkd[597]: enp3s0: link configured
systemd-networkd[597]: bridge0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: bridge0: link status updated: 0x1043 -
0x1003
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: enp3s0: link is up
systemd-networkd[597]: enp3s0: link status updated: 0x1002 - 0x1003
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: enp3s0: carrier on
systemd-networkd[597]: enp3s0: link status updated: 0x1003 - 0x00011043
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: bridge0: MAC address: 00:12:34:56:78:30
systemd-networkd[597]: bridge0: carrier on
systemd-networkd[597]: bridge0: acquiring DHCPv4 lease
systemd-networkd[597]: DHCP CLIENT: STARTED
systemd-networkd[597]: bridge0: link status updated: 0x1003 -
0x00011043
systemd-networkd[597]: DHCP CLIENT: DISCOVER
systemd-networkd[597]: DHCP CLIENT: OFFER
systemd-networkd[597]: DHCP CLIENT: REQUEST
systemd-networkd[597]: DHCP CLIENT: NAK
systemd-networkd[597]: bridge0: IP address in use.
systemd-networkd[597]: DHCP CLIENT: STOPPED
systemd-networkd[597]: enp3s0: MAC address: 00:12:34:56:78:30

- ip addr show bridge0:
5: bridge0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc noqueue
state UP group default
link/ether 00:12:34:56:78:30 brd ff:ff:ff:ff:ff:ff
inet6 fe80::b8d4:25ff:feca:7958/64 scope link
   valid_lft forever preferred_lft forever

- systemctl restart systemd-networkd

- journalctl/systemd-networkd:
systemd[1]: Stopping Network Service...
systemd[1]: Starting Network Service...
systemd-networkd[1382]: timestamp of '/etc/systemd/network' changed
systemd-networkd[1382]: timestamp of '/run/systemd/network' changed
systemd-networkd[1382]: bridge0: creating

Re: [systemd-devel] systemd-journal-remote

2014-03-18 Thread Zbigniew Jędrzejewski-Szmek 
On Mon, Mar 17, 2014 at 11:00:32PM -0700, David Timothy Strauss wrote:
 On Sun, Mar 16, 2014 at 11:29 PM, Zbigniew Jędrzejewski-Szmek
 zbys...@in.waw.pl wrote:
  Curl requires the whole file to be exported first, which isn't great,
  because it wants to give the content size in the header. I'm note
  sure if it is possible to tell it to not do that.
 
 I'm think you just need to implement your own function to use with
 CURLOPT_READFUNCTION and set a chunked encoding header [1] instead of
 giving libcurl an actual file to upload. You can return zero when
 you're done sending everything you want to send.
 
 [1] http://curl.haxx.se/libcurl/c/post-callback.html
Yeah, actually it works even without a callback, since curl is happy
to read froma FILE* by itself. It turns out that (in contradiction to
what the documentantion says), it is necessary to turn on chunked
transfer encoding explicitly, and then streaming uploads work great.
Some more care is necessary to handle timeouts, and I'm now working on
that.

Zbyszek

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] systemctl: refuse to do kexec, if no kernel is loaded

2014-03-18 Thread harald 
From: Harald Hoyer har...@redhat.com

Doing a kexec with no kernel loaded would currently issue a normal reboot.
This might not be wanted, if the goal of kexec is to circumvent the boot
loader. Better fail to kexec, than to reboot into a maybe broken setup.
---
 src/systemctl/systemctl.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index 5a5681b..ac99f44 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -2853,6 +2853,11 @@ static int start_special(sd_bus *bus, char **args) {
 return -EPERM;
 }
 
+if (a == ACTION_KEXEC  !kexec_loaded()) {
+log_error(No kernel loaded for kexec!);
+return -EINVAL;
+}
+
 if (arg_force = 2 
 (a == ACTION_HALT ||
  a == ACTION_POWEROFF ||
@@ -6711,6 +6716,12 @@ int main(int argc, char*argv[]) {
 goto finish;
 }
 
+if (arg_action == ACTION_KEXEC  !kexec_loaded()) {
+log_error(No kernel loaded for kexec!);
+r = -EINVAL;
+goto finish;
+}
+
 if (!avoid_bus())
 r = bus_open_transport_systemd(arg_transport, arg_host, 
arg_scope != UNIT_FILE_SYSTEM, bus);
 
-- 
1.8.5.3

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR

2014-03-18 Thread Leonid Isaev 
[Sorry, forgot to CC the mailing list]

Hi Lennart,

On Tue, 18 Mar 2014 02:33:50 +0100
Lennart Poettering lenn...@poettering.net wrote:

 On Mon, 17.03.14 19:04, Leonid Isaev (lis...@umail.iu.edu) wrote:
 
  Hi,
  
  Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather
  permissive, hardcoded mount options (or at least I couldn't find a
  documented way of changing them). Specifically, a user is allowed to
  execute things from his $XDG_RUNTIME_DIR. This effectively negates admin's
  ability to constrain users, e.g. by mounting /home as noexec (I have seen
  this done in some environments).
  Is there a need to allow execution from $XDG_RUNTIME_DIR? And how
  should one configure its mount options?
 
 Yes, this is hardcoded in 211, that's true. We could make this
 configurable but I am not really convinced that we really want that?

I agree that a complete, fstab-like configuration may be too much.

 
 I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by
 the standards of the operating system. More specifically, ... proper
 permissions ... must be supported. I'd read that as if the x bit should
 do what it is supposed to do. So, in order to stay compatible with the
 spec allowing to mount it with noexec sounds undesirable.

Well, regardless of what the XDG specification says, the fact is that currently
each user has 2 /home's: one under the admin control, another -- not.

Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR
upon login, but this is hacking around the init system... What about making
XDG_RUNTIME_DIR inherit mount options from /home if the latter is a separate
partition and fall back to the current default otherwise?

 
 Moreover noexec is mostly snake-oil, isn't it? You can invoke the
 executables with an interpreter still, and you can copy the files
 elsewhere...

True for the interpreted code. However regarding other places, if an admin
cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also
constrained (I am not saying that this should be the default, just
configurable).

Thanks,
Leonid.

 
 Note that setting noexec on an fs means you cannot maps its files
 PROT_EXEC anymore, which breaks a number of things. In the past people
 attempted to mount /dev/shm as noexec, and dosemu broke because it made
 use of this. Then people wanted to mount /dev as noexec, which broke X11
 which wanted to map some device nodes PROT_EXEC. Given that we consider
 XDG_RUNTIME_DIR as a private version of /dev/shm among other things it
 really sounds wrong to break this right from the start.

 
 So, I am not really convinced I must say...
 
 Lennart
 



-- 
Leonid Isaev
GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D


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

Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR

2014-03-18 Thread Dave Reisner 
On Mar 18, 2014 12:59 PM, Leonid Isaev lis...@umail.iu.edu wrote:

 [Sorry, forgot to CC the mailing list]

 Hi Lennart,

 On Tue, 18 Mar 2014 02:33:50 +0100
 Lennart Poettering lenn...@poettering.net wrote:

  On Mon, 17.03.14 19:04, Leonid Isaev (lis...@umail.iu.edu) wrote:
 
   Hi,
  
   Currently, XDG_RUNTIME_DIR=/run/user/UID is mounted with rather
   permissive, hardcoded mount options (or at least I couldn't find a
   documented way of changing them). Specifically, a user is allowed to
   execute things from his $XDG_RUNTIME_DIR. This effectively negates
admin's
   ability to constrain users, e.g. by mounting /home as noexec (I have
seen
   this done in some environments).
   Is there a need to allow execution from $XDG_RUNTIME_DIR? And how
   should one configure its mount options?
 
  Yes, this is hardcoded in 211, that's true. We could make this
  configurable but I am not really convinced that we really want that?

 I agree that a complete, fstab-like configuration may be too much.

 
  I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by
  the standards of the operating system. More specifically, ... proper
  permissions ... must be supported. I'd read that as if the x bit should
  do what it is supposed to do. So, in order to stay compatible with the
  spec allowing to mount it with noexec sounds undesirable.

 Well, regardless of what the XDG specification says, the fact is that
currently
 each user has 2 /home's: one under the admin control, another -- not.

 Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR
 upon login, but this is hacking around the init system... What about
making
 XDG_RUNTIME_DIR inherit mount options from /home if the latter is a
separate
 partition and fall back to the current default otherwise?

 
  Moreover noexec is mostly snake-oil, isn't it? You can invoke the
  executables with an interpreter still, and you can copy the files
  elsewhere...

 True for the interpreted code.

And compiled code. The linker is your ELF interpreter.

 However regarding other places, if an admin
 cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also
 constrained (I am not saying that this should be the default, just
 configurable).

 Thanks,
 Leonid.

 
  Note that setting noexec on an fs means you cannot maps its files
  PROT_EXEC anymore, which breaks a number of things. In the past people
  attempted to mount /dev/shm as noexec, and dosemu broke because it made
  use of this. Then people wanted to mount /dev as noexec, which broke X11
  which wanted to map some device nodes PROT_EXEC. Given that we consider
  XDG_RUNTIME_DIR as a private version of /dev/shm among other things it
  really sounds wrong to break this right from the start.

 
  So, I am not really convinced I must say...
 
  Lennart
 



 --
 Leonid Isaev
 GPG key fingerprint: C0DF 20D0 C075 C3F1 E1BE  775A A7AE F6CB 164B 5A6D

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR

2014-03-18 Thread Lennart Poettering 
On Tue, 18.03.14 12:59, Leonid Isaev (lis...@umail.iu.edu) wrote:

  I mean, the XDG_RUNTIME_DIR spec says the dir must be fully-featured by
  the standards of the operating system. More specifically, ... proper
  permissions ... must be supported. I'd read that as if the x bit should
  do what it is supposed to do. So, in order to stay compatible with the
  spec allowing to mount it with noexec sounds undesirable.
 
 Well, regardless of what the XDG specification says, the fact is that 
 currently
 each user has 2 /home's: one under the admin control, another -- not.

Well, the XDG runtime dir is not really a home directory. It has very
clear semantics and lifecycles, and they are quite different from
/home.

 Of course, one could hook into PAM and remount each user's XDG_RUNTIME_DIR
 upon login, but this is hacking around the init system... What about making
 XDG_RUNTIME_DIR inherit mount options from /home if the latter is a separate
 partition and fall back to the current default otherwise?

So when we standardized XDG_RUNTIME_DIR we did so because of the broken
semantics of /home, where there's no guarantee that file locking,
mmapping, unix sockets, fifos, exec, ... would work correctly. Hence for
local runtime stuff we came up with XDG_RUNTIME_DIR, which should clean
all this up, have a clear lifecycle and be the much better place for
doing all these things.

It sounds really backwards to me to weaken this clear definition by
making some of the features completely optional again. I mean, it's fine
if people locally override how things are set up, and willingly break
what is written in the spec, but I am pretty sure we shouldn't push them
to do that by making this too easy to change.

Or with other words: what you want to do there is explicitly what you
say you don't want to do: hacking around the init system! So, if you
want to do that, then go ahead, but I really doubt we should support
anything like this with an easy option upstream. Sorry.

  Moreover noexec is mostly snake-oil, isn't it? You can invoke the
  executables with an interpreter still, and you can copy the files
  elsewhere...
 
 True for the interpreted code. However regarding other places, if an admin
 cares about noexec at all, /var/tmp, /tmp and /dev/shm should be also
 constrained (I am not saying that this should be the default, just
 configurable).

Well, the ELF interpretor stuff means noexec is pretty much entirely
useless.

I only see drawbacks of this I must say. I really don't see the benefit
of adding a config option for this.

Sorry,

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Mount options for $XDG_RUNTIME_DIR

2014-03-18 Thread Mantas Mikulėnas 
On Mar 18, 2014 8:19 PM, Lennart Poettering lenn...@poettering.net
wrote:
 …
 Well, the ELF interpretor stuff means noexec is pretty much entirely
 useless.

If by this you mean running '/lib/ld-linux.so.2' directly, that does not
work with noexec anymore, due to the aforementioned mmap restriction AFAIK:

/mnt/test: error while loading shared libraries: /mnt/test: failed to map
segment from shared object: Operation not permitted
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] sd-ipv4ll: generate predictable addresses

2014-03-18 Thread Umut Tezduyar Lindskog 
---
 TODO   |1 -
 src/libsystemd-network/sd-ipv4ll.c |   86 +++-
 src/network/networkd-link.c|   12 -
 src/network/networkd.h |1 +
 src/shared/net-util.c  |   42 ++
 src/shared/net-util.h  |2 +
 src/systemd/sd-ipv4ll.h|1 +
 src/udev/net/link-config.c |   27 +--
 8 files changed, 122 insertions(+), 50 deletions(-)

diff --git a/TODO b/TODO
index 99cbb9f..d0c7132 100644
--- a/TODO
+++ b/TODO
@@ -667,7 +667,6 @@ Features:
- add reduced [Link] support to .network files
- add IPv4LL tests (inspire by DHCP)
- add Scope= parsing option for [Network]
-   - change LL address generation and make it predictable like get_mac() 
(link-config.c)
- have smooth transition from LL to routable address, without disconnecting 
clients.
 
 External:
diff --git a/src/libsystemd-network/sd-ipv4ll.c 
b/src/libsystemd-network/sd-ipv4ll.c
index c6f6e01..fbe3efd 100644
--- a/src/libsystemd-network/sd-ipv4ll.c
+++ b/src/libsystemd-network/sd-ipv4ll.c
@@ -76,6 +76,8 @@ struct sd_ipv4ll {
 usec_t defend_window;
 int next_wakeup_valid;
 be32_t address;
+struct random_data *random_data;
+char *random_data_state;
 /* External */
 be32_t claimed_address;
 struct ether_addr mac_addr;
@@ -130,30 +132,27 @@ static int ipv4ll_stop(sd_ipv4ll *ll, int event) {
 return 0;
 }
 
-static be32_t ipv4ll_pick_address(sd_ipv4ll *ll) {
+static int ipv4ll_pick_address(sd_ipv4ll *ll, be32_t *address) {
 be32_t addr;
+int r;
+int32_t random;
 
 assert(ll);
+assert(address);
+assert(ll-random_data);
 
-if (ll-address) {
-do {
-uint32_t r = random_u32()  0x;
-addr = htonl(IPV4LL_NETWORK | r);
-} while (addr == ll-address ||
-(ntohl(addr)  IPV4LL_NETMASK) != IPV4LL_NETWORK ||
-(ntohl(addr)  0xFF00) == 0x ||
-(ntohl(addr)  0xFF00) == 0xFF00);
-} else {
-uint32_t a = 1;
-int i;
-
-for (i = 0; i  ETH_ALEN; i++)
-a += ll-mac_addr.ether_addr_octet[i]*i;
-a = (a % 0xFE00) + 0x0100;
-addr = htonl(IPV4LL_NETWORK | (uint32_t) a);
-}
+do {
+r = random_r(ll-random_data, random);
+if (r  0)
+return r;
+addr = htonl((random  0x) | IPV4LL_NETWORK);
+} while (addr == ll-address ||
+(ntohl(addr)  IPV4LL_NETMASK) != IPV4LL_NETWORK ||
+(ntohl(addr)  0xFF00) == 0x ||
+(ntohl(addr)  0xFF00) == 0xFF00);
 
-return addr;
+*address = addr;
+return 0;
 }
 
 static int ipv4ll_timer(sd_event_source *s, uint64_t usec, void *userdata) {
@@ -306,7 +305,9 @@ static void ipv4ll_run_state_machine(sd_ipv4ll *ll, 
IPv4LLTrigger trigger, void
 ll-claimed_address = 0;
 
 /* Pick a new address */
-ll-address = ipv4ll_pick_address(ll);
+r = ipv4ll_pick_address(ll, ll-address);
+if (r  0)
+goto out;
 ll-conflict++;
 ll-defend_window = 0;
 ipv4ll_set_state(ll, IPV4LL_STATE_WAITING_PROBE, 1);
@@ -435,6 +436,36 @@ int sd_ipv4ll_get_address(sd_ipv4ll *ll, struct in_addr 
*address){
 return 0;
 }
 
+int sd_ipv4ll_set_address_seed (sd_ipv4ll *ll, uint64_t entropy) {
+int r;
+
+assert_return(ll, -EINVAL);
+
+free(ll-random_data);
+free(ll-random_data_state);
+
+ll-random_data = new0(struct random_data, 1);
+ll-random_data_state = new0(char, 128);
+
+if (!ll-random_data || !ll-random_data_state) {
+r = -ENOMEM;
+goto error;
+}
+
+r = initstate_r((unsigned int)entropy, ll-random_data_state, 128, 
ll-random_data);
+if (r  0)
+goto error;
+
+error:
+if (r  0){
+free(ll-random_data);
+free(ll-random_data_state);
+ll-random_data = NULL;
+ll-random_data_state = NULL;
+}
+return r;
+}
+
 int sd_ipv4ll_start (sd_ipv4ll *ll) {
 int r;
 
@@ -453,8 +484,17 @@ int sd_ipv4ll_start (sd_ipv4ll *ll) {
 ll-defend_window = 0;
 ll-claimed_address = 0;
 
-if (ll-address == 0)
-ll-address = ipv4ll_pick_address(ll);
+if (!ll-random_data) {
+r = sd_ipv4ll_set_address_seed(ll, random_u64());
+if (r  0)
+goto

[systemd-devel] How to manually set service in failed state

2014-03-18 Thread Usman 
Hi Guys,

I am trying to test some code with respect to my services setup. I have two 
services, lets say service_a and service_b. In service_a unit file I have this:

OnFailure=service_b


And from the man page for OnFailure unit I get this:

A space-separated list of one or more units that are activated when this unit 
enters the failed state

My question is, to test this setup, how can I have service_a in a failed 
state? I have tried using kill -9, but that leaves service in signal state 
and not failed state. How can I manually set a service in failed state so 
that service_b gets started for my testing? Any specific signal? Any help much 
appreciated.

Thanks.___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to manually set service in failed state

2014-03-18 Thread Reindl Harald 


Am 18.03.2014 22:59, schrieb Usman:
 I am trying to test some code with respect to my services setup. I have two 
 services, lets say service_a and
 service_b. In service_a unit file I have this:
 
 OnFailure=service_b
 
 And from the man page for OnFailure unit I get this:
 
 A space-separated list of one or more units that are activated when this unit 
 enters the failed state
 
 My question is, to test this setup, how can I have service_a in a failed 
 state? I have tried using kill -9, but
 that leaves service in signal state and not failed state. How can I 
 manually set a service in failed state so
 that service_b gets started for my testing? Any specific signal? Any help 
 much appreciated.

kill -4

http://www.linux.org/threads/kill-commands-and-signals.4423/

SIGILL - When a process performs a faulty, forbidden, or unknown function, the
system sends the SIGILL signal to the process. This is the ILLegal SIGnal

1) SIGHUP 2) SIGINT 3) SIGQUIT 4) SIGILL
5) SIGTRAP 6) SIGABRT 7) SIGBUS 8) SIGFPE
9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2
13) SIGPIPE 14) SIGALRM 15) SIGTERM 17) SIGCHLD
18) SIGCONT 19) SIGSTOP 20) SIGTSTP 21) SIGTTIN
22) SIGTTOU 23) SIGURG 24) SIGXCPU 25) SIGXFSZ
26) SIGVTALRM 27) SIGPROF 28) SIGWINCH 29) SIGIO
30) SIGPWR 31) SIGSYS 34) SIGRTMIN 35) SIGRTMIN+1
36) SIGRTMIN+2 37) SIGRTMIN+3 38) SIGRTMIN+4 39) SIGRTMIN+5
40) SIGRTMIN+6 41) SIGRTMIN+7 42) SIGRTMIN+8 43) SIGRTMIN+9
44) SIGRTMIN+10 45) SIGRTMIN+11 46) SIGRTMIN+12 47) SIGRTMIN+13
48) SIGRTMIN+14 49) SIGRTMIN+15 50) SIGRTMAX-14 51) SIGRTMAX-13
52) SIGRTMAX-12 53) SIGRTMAX-11 54) SIGRTMAX-10 55) SIGRTMAX-9
56) SIGRTMAX-8 57) SIGRTMAX-7 58) SIGRTMAX-6 59) SIGRTMAX-5
60) SIGRTMAX-4 61) SIGRTMAX-3 62) SIGRTMAX-2 63) SIGRTMAX-1
64) SIGRTMAX



signature.asc
Description: OpenPGP digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to manually set service in failed state

2014-03-18 Thread Michael Biebl 
/etc/systemd/system# cat fail.service
[Unit]
Description=Fail service

[Service]
ExecStart=/bin/false

2014-03-18 22:59 GMT+01:00 Usman deser...@yahoo.com:
 Hi Guys,

 I am trying to test some code with respect to my services setup. I have two
 services, lets say service_a and service_b. In service_a unit file I have
 this:

 OnFailure=service_b

 And from the man page for OnFailure unit I get this:

 A space-separated list of one or more units that are activated when this
 unit enters the failed state

 My question is, to test this setup, how can I have service_a in a failed
 state? I have tried using kill -9, but that leaves service in signal state
 and not failed state. How can I manually set a service in failed state
 so that service_b gets started for my testing? Any specific signal? Any help
 much appreciated.

 Thanks.

 ___
 systemd-devel mailing list
 systemd-devel@lists.freedesktop.org
 http://lists.freedesktop.org/mailman/listinfo/systemd-devel




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] How to manually set service in failed state

2014-03-18 Thread Usman 
Thanks. But this requires that service_a should be a dummy service. I want both 
the services in actual deployment scenario and then fail service_a to simulate 
real crash. Any way I can do that?

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] network@.service unit file : typo

2014-03-18 Thread arnaud gaboury 
Hi all,

From network@.service unit file :

..
ExecStop=/sbin/ip link set dev %I down
Execstop=/sbin/ip addr delete ${address}/${netmask} dev %I  --


There is a typo: should be ExecStop and not Execstop

Regards.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network@.service unit file : typo

2014-03-18 Thread arnaud gaboury 

 From network@.service unit file :

 ..
 ExecStop=/sbin/ip link set dev %I down
 Execstop=/sbin/ip addr delete ${address}/${netmask} dev %I  --
 

 There is a typo: should be ExecStop and not Execstop

Sorry for the noise as it is a netctl unit file.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network@.service unit file : typo

2014-03-18 Thread arnaud gaboury 

 Sorry for the noise as it is a netctl unit file.

I must be very tired : nothing to do with netctl...
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] network@.service unit file : typo

2014-03-18 Thread Mantas Mikulėnas 
On Mar 19, 2014 1:47 AM, arnaud gaboury arnaud.gabo...@gmail.com wrote:

 Hi all,

 From network@.service unit file :

 ..
 ExecStop=/sbin/ip link set dev %I down
 Execstop=/sbin/ip addr delete ${address}/${netmask} dev %I  --
 

 There is a typo: should be ExecStop and not Execstop

This seems like a distribution specific unit; systemd itself certainly does
not ship any .service that would use /sbin/ip.

(In v211 there is systemd-networkd and earlier versions just didn't have
any network configuration.)

-- 
Mantas Mikulėnas graw...@gmail.com
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] [PATCH] sd-ipv4ll: generate predictable addresses

2014-03-18 Thread Lennart Poettering 
On Tue, 18.03.14 20:29, Umut Tezduyar Lindskog (umut.tezdu...@axis.com) wrote:


 +int net_get_unique_predictable_data(struct udev_device *device, uint64_t 
 *result) {
 +size_t l, sz = 0;
 +const char *name;
 +int r;
 +uint8_t *v;
 +
 +/* fetch some persistent data unique (on this machine) to this 
 device */
 +name = udev_device_get_property_value(device, ID_NET_NAME_ONBOARD);
 +if (!name) {
 +name = udev_device_get_property_value(device, 
 ID_NET_NAME_SLOT);
 +if (!name) {
 +name = udev_device_get_property_value(device, 
 ID_NET_NAME_PATH);
 +if (!name) {
 +name = 
 udev_device_get_property_value(device, ID_NET_NAME_MAC);
 +if (!name)
 +return -ENOENT;
 +}
 +}
 +}

To make this a bit nicer I have now added code a new FOREACH_STRING()
macro, working like this:

const char *field, *name = NULL;

FOREACH_STRING(field, ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, 
ID_NET_NAME_PATH, ID_NET_NAME_MAC) {
name = udev_device_get_property_value(device, field);
if (name)
break;
}

if (!name)
return -ENOENT;

Lennart

-- 
Lennart Poettering, Red Hat
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [PATCH] Don't use class in public headers

2014-03-18 Thread Marc-Antoine Perennou 
---
 src/systemd/sd-login.h   | 2 +-
 src/systemd/sd-resolve.h | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/systemd/sd-login.h b/src/systemd/sd-login.h
index 87ebafb..c539dd8 100644
--- a/src/systemd/sd-login.h
+++ b/src/systemd/sd-login.h
@@ -178,7 +178,7 @@ int sd_seat_can_tty(const char *seat);
 int sd_seat_can_graphical(const char *seat);
 
 /* Return the class of machine */
-int sd_machine_get_class(const char *machine, char **class);
+int sd_machine_get_class(const char *machine, char **clazz);
 
 /* Get all seats, store in *seats. Returns the number of seats. If
  * seats is NULL only returns number of seats. */
diff --git a/src/systemd/sd-resolve.h b/src/systemd/sd-resolve.h
index 3c1d482..a02be7d 100644
--- a/src/systemd/sd-resolve.h
+++ b/src/systemd/sd-resolve.h
@@ -103,13 +103,13 @@ int sd_resolve_getnameinfo_done(sd_resolve_query* q, char 
**ret_host, char **ret
  * compatible with the ones of libc's res_query(3). The function returns a new
  * query object. When the query is completed you may retrieve the results using
  * sd_resolve_res_done().  */
-int sd_resolve_res_query(sd_resolve *resolve, sd_resolve_query **q, const char 
*dname, int class, int type);
+int sd_resolve_res_query(sd_resolve *resolve, sd_resolve_query **q, const char 
*dname, int clazz, int type);
 
 /** Issue an resolver query on the specified session. The arguments are
  * compatible with the ones of libc's res_search(3). The function returns a new
  * query object. When the query is completed you may retrieve the results using
  * sd_resolve_res_done().  */
-int sd_resolve_res_search(sd_resolve *resolve, sd_resolve_query **q, const 
char *dname, int class, int type);
+int sd_resolve_res_search(sd_resolve *resolve, sd_resolve_query **q, const 
char *dname, int clazz, int type);
 
 /** Retrieve the results of a preceding sd_resolve_res_query() or
  * resolve_res_search call.  The query object q is destroyed by this
-- 
1.9.0

___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel