Re: [systemd-devel] A potentially cross platform solution forprocess containment in init applications

[Rong]

> OK, I'll bite.
>
> The good thing about cgroupfs is that processes cannot escape
> supervision, unless they are priviliged and do some non-trivial stuff
> that cannot happen by accident, very much unlike an fd which anyone can
> close and which is closed all the time. Also, cgroups provide us with a
> way to list all processes in a unit without priviliges, and to quickly
> (without iterating through lots of fds, and without priviliges agin)
> determine to which unit a process belongs. Nothing like that works with
> your fuse approach.
It is very easy in FUSE. You just return an error code when handling unwanted 
"close()" in the initfs, thus the client can not just close the fd handler 
unless the process crashes.
It is also easy to maintain a list of processes who opened a particular fd with 
the FUSE api. No iterating is needed. You can also get the list via lsof/fuser 
if maintain such lists is too much.

> Also, why involve fuse at all? a couple of fifos in the fs could do
> everything else you suggest without relying on fuse...

Please tell me you are just kidding. The only things you can do with a pipe are 
read/write/close, that is all. And pipe is even just meant for 1 to 1 
communication. unix socket make much more sense, but is not match for what FUSE 
can do.
With FUSE, you get auto ref-counting by the kernel, you get your hands on all 
syscalls on filesystem. You can implement your own policy of who has access to 
initfs, who can close the descriptors, etc.
>
> Also, all big Linux distributions have already switched or have
> announced that they'll switch to systemd. That's more than we ever could
> ask for, and there's nothing else for us to win.

Indeed, systemd is taking over most major linux distributions, but this doesn't 
change the fact that cgroups remains a controversial api, and may go through 
major api update in the future. I think FUSE approach is cleaner, even without 
talking about cross platform compatibility.

> I can only encourage the other Unixes to come up with their own service
> management solutions, that make use of their specific feature set in the
> best possible way, so that we get some serious competition in place
> again.

Is there any plan for standardization on configuration file format, so other 
implementations of init in linux/bsd/whatever could coexist using the same set 
of conf file for daemons? 

> 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] A potentially cross platform solution for process containment in init applications

[Lennart Poettering]

On Fri, 21.03.14 06:53, Rong (tr...@qq.com) wrote:

> Hi,
> 
> Currently systemd is using cgroups kernel interface for process
> containment. Cgroups is a very easy solution on linux to handle the
> double fork used by daemons, and it can help respawning services in
> case of self-crash. However cgroups seems to be the major stopper for
> systemd to be cross platform.

There's a lot more in systemd that is not cross-platform.

> I'm thinking about an alternative approach for process containment, utilizing 
> the widely accepted FUSE interface in all major unix systems. Below is a 
> brief description:

> a). A fuse daemon will providing a special file system, let's say
> /run/initfs

> b). For every daemon which needs to be contained, we can start a
> helper process first, and open a file in the special file system. For
> instance, to start apache daemon, we start the helper and create/open
> a file "/run/initfs/apache". Make sure close-on-exit is NOT set on
> this file descriptor.

> c). Fork-exec to start the daemon. Now we can identify all process
> with reference to "/run/initfs/apache" as a part of the apache daemon.
> 
> Aside from being cross platform, the FUSE interface also gives very
> powerful api for many advanced functionalities. This initfs file
> server is basically an user space extension of the kernel, just like
> some normal server in the microkernels. You could even have multiple
> instance of such initfs server running on the same box(using separate
> vfs/pid namespace to hide them from each other), thus making init on
> linux containers much easier.
> 
> Any thoughts?

OK, I'll bite.

The good thing about cgroupfs is that processes cannot escape
supervision, unless they are priviliged and do some non-trivial stuff
that cannot happen by accident, very much unlike an fd which anyone can
close and which is closed all the time. Also, cgroups provide us with a
way to list all processes in a unit without priviliges, and to quickly
(without iterating through lots of fds, and without priviliges agin)
determine to which unit a process belongs. Nothing like that works with
your fuse approach.

Also, why involve fuse at all? a couple of fifos in the fs could do
everything else you suggest without relying on fuse...

Also, all big Linux distributions have already switched or have
announced that they'll switch to systemd. That's more than we ever could
ask for, and there's nothing else for us to win.

I can only encourage the other Unixes to come up with their own service
management solutions, that make use of their specific feature set in the
best possible way, so that we get some serious competition in place
again.

Lennart

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

[systemd-devel] A potentially cross platform solution for process containment in init applications

[Rong]

Hi,

Currently systemd is using cgroups kernel interface for process containment. 
Cgroups is a very easy solution on linux to handle the double fork used by 
daemons, and it can help respawning services in case of self-crash. However 
cgroups seems to be the major stopper for systemd to be cross platform. 

I'm thinking about an alternative approach for process containment, utilizing 
the widely accepted FUSE interface in all major unix systems. Below is a brief 
description:
a). A fuse daemon will providing a special file system, let's say /run/initfs
b). For every daemon which needs to be contained, we can start a helper process 
first, and open a file in the special file system. For instance, to start 
apache daemon, we start the helper and create/open a file "/run/initfs/apache". 
Make sure close-on-exit is NOT set on this file descriptor.
c). Fork-exec to start the daemon. Now we can identify all process with 
reference to "/run/initfs/apache" as a part of the apache daemon.

Aside from being cross platform, the FUSE interface also gives very powerful 
api for many advanced functionalities. This initfs file server is basically an 
user space extension of the kernel, just like some normal server in the 
microkernels. You could even have multiple instance of such initfs server 
running on the same box(using separate vfs/pid namespace to hide them from each 
other), thus making init on linux containers much easier.

Any thoughts?___
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

[poma]

On 19.03.2014 14:09, Tom Gundersen wrote:

> I haven't yet gotten around to this. We probably should just restart
> the dhcp client if the mac address changes, for whatever reason.
> Unless anyone else has a better idea.
> 
> Cheers,
> 
> Tom

Nobody's perfect.
- NetworkManager - bridge dhcp
  http://goo.gl/Zm5Rts
- systemd-networkd - bridge dhcp
  http://goo.gl/iodPmA
Good luck with dhcpc circus.


poma


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

Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

[Marco d'Itri]

On Mar 20, Lennart Poettering  wrote:

> TO figure out what we can do in Fedora I have now started a discussion
> on fedora-devel, about getting rid of tcpwrap system-wide. Let's see
> where this goes. Would be interested in feedback about this from other
> distros too.
Debian has no plans to drop tcp-wrappers, support for user space ACLs is 
very useful.
Even if upstream is not active anymore we have been maintaining the 
package and adding new features with no troubles.

-- 
ciao,
Marco


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

Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

[Dave Reisner]

On Thu, Mar 20, 2014 at 08:29:07PM +0100, Lennart Poettering wrote:
> On Thu, 20.03.14 12:49, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
> 
> > The underlying components have not seen any upstream activity
> > since 1997 and are not particulary nice either.
> > 
> > Those interested in computer archeology can explicitly use --enable-tcpwrap
> 
> Is suse intending to drop tcpwrap from its core os?
> 
> I am all for getting rid of tcpwrap, but just disabling it in
> configure.ac by default looks like the wrong option to me...
> 
> So far our policy was to enable evertyhing that exists in systemd by
> default when you build it with the default options, so that everything
> gets at least regularly compile tested, if not actually tested in
> real-life. 
> 
> So, if this shall stay in systemd, then it should be enabled by
> default. The only other option I see is to remove it entirely, but i'd
> really like to keep the bigger picture in view there. Or in other words,
> if we get rid of it in systemd, we should do so knowing that this is in
> sync with what the big distros intend to do in general too.
> 
> TO figure out what we can do in Fedora I have now started a discussion
> on fedora-devel, about getting rid of tcpwrap system-wide. Let's see
> where this goes. Would be interested in feedback about this from other
> distros too.

Arch removed tcpwrap from our repositories almost 3 years ago:

https://www.archlinux.org/news/dropping-tcp_wrappers-support/

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

Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

[Cristian Rodríguez]

El 20/03/14 16:29, Lennart Poettering escribió:

On Thu, 20.03.14 12:49, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:


The underlying components have not seen any upstream activity
since 1997 and are not particulary nice either.

Those interested in computer archeology can explicitly use --enable-tcpwrap


Is suse intending to drop tcpwrap from its core os?


Nope, but I am attempting some baby steps to see if that's gonna fly or not.

Fortunately not many daemons or packages actually use this thing, in my 
opinion we shouldn't keep unmaintained core os components around, ever.


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

Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

[Tom Gundersen]

On Thu, Mar 20, 2014 at 8:29 PM, Lennart Poettering
 wrote:
> On Thu, 20.03.14 12:49, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:
>
>> The underlying components have not seen any upstream activity
>> since 1997 and are not particulary nice either.
>>
>> Those interested in computer archeology can explicitly use --enable-tcpwrap
>
> Is suse intending to drop tcpwrap from its core os?
>
> I am all for getting rid of tcpwrap, but just disabling it in
> configure.ac by default looks like the wrong option to me...
>
> So far our policy was to enable evertyhing that exists in systemd by
> default when you build it with the default options, so that everything
> gets at least regularly compile tested, if not actually tested in
> real-life.
>
> So, if this shall stay in systemd, then it should be enabled by
> default. The only other option I see is to remove it entirely, but i'd
> really like to keep the bigger picture in view there. Or in other words,
> if we get rid of it in systemd, we should do so knowing that this is in
> sync with what the big distros intend to do in general too.
>
> TO figure out what we can do in Fedora I have now started a discussion
> on fedora-devel, about getting rid of tcpwrap system-wide. Let's see
> where this goes. Would be interested in feedback about this from other
> distros too.

We dropped tcpwrap from Arch  a few years back [0]. I can not remember
any fallout at all, maybe Dave's memory is better?

Cheers,

Tom

[0]: 
___
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

[Tom Gundersen]

On Wed, Mar 19, 2014 at 2:09 PM, Tom Gundersen  wrote:
> On Wed, Mar 19, 2014 at 1:25 PM, poma  wrote:
>> Still the same issue, DHCPC starts too early, before the correct MAC
>> address is set for the bridge.
>>
>> git 7bf2f4397255bc8f6cf20a0f2adab4c984ea7d14
>
> I haven't yet gotten around to this. We probably should just restart
> the dhcp client if the mac address changes, for whatever reason.
> Unless anyone else has a better idea.

Adding Umut as well as this problem is the same in sd-ipv4ll.

I have now shuffled the code around a bit in git to give a clearer
error message when this problem is encountered. The underlying problem
remains though.

My proposal is:

Whenever the MAC address changes under us networkd calls
sd_{dhcp_client,ipv4ll}_set_mac(), and it is the libs' responsibility
to then do the right thing.

Currently the libs don't support this and will fail with EBUSY, so I
suggest we change that into letting them restart themselves
internally, and send out notifications that the lease has been lost
(so networkd will drop the addresses correctly, if it has any
assigned).

Umut, Patrik, what do you think?

Cheers,

Tom

>> journalctl -b -u systemd-networkd
>> ...
>> 12:51:55 networkd[579]: timestamp of '/etc/systemd/network' changed
>> 12:51:55 networkd[579]: timestamp of '/run/systemd/network' changed
>> 12:51:55 networkd[579]: bridge0: creating netdev
>> 12:51:55 networkd[579]: enp1s6: link (with ifindex 2) added
>> 12:51:55 networkd[579]: enp1s9: link (with ifindex 3) added
>> 12:51:55 networkd[579]: enp3s0: found matching network
>> '/etc/systemd/network/base0.network'
>> 12:51:55 networkd[579]: enp3s0: requesting link status
>> 12:51:55 networkd[579]: enp3s0: enslaving by 'bridge0'
>> 12:51:55 networkd[579]: enp3s0: link (with ifindex 4) added
>> 12:51:55 networkd[579]: lo: link (with ifindex 1) added
>> 12:51:55 networkd[579]: bridge0: found matching network
>> '/etc/systemd/network/bridge0dhcp.network'
>> 12:51:55 networkd[579]: bridge0: requesting link status
>> 12:51:55 networkd[579]: bridge0: bringing link up
>> 12:51:55 networkd[579]: bridge0: link (with ifindex 5) added
>> 12:51:55 networkd[579]: bridge0: netdev ready
>> 12:51:55 networkd[579]: bridge0: enslaving link 'enp3s0'
>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>> 12:51:55 networkd[579]: bridge0: link status updated:  -> 0x1002
>> 12:51:55 networkd[579]: 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
>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>> 12:51:55 networkd[579]: enp3s0: link status updated:  -> 0x1002
>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>> 12:51:55 networkd[579]: bridge0: link is up
>> 12:51:55 networkd[579]: bridge0: carrier on
>> 12:51:55 networkd[579]: DHCP CLIENT: set MAC address to 96:c0:ae:06:29:ce
>> 12:51:55 networkd[579]: bridge0: acquiring DHCPv4 lease
>> 12:51:55 networkd[579]: DHCP CLIENT: STARTED
>> 12:51:55 networkd[579]: bridge0: link status updated: 0x1002 ->
>> 0x00011043
>> 12:51:55 networkd[579]: 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
>> 12:51:55 networkd[579]: DHCP CLIENT: DISCOVER
>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>> 12:51:55 networkd[579]: 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
>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>> 12:51:55 networkd[579]: bridge0: MAC address: 96:c0:ae:06:29:ce
>> 12:51:55 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>> 12:51:55 networkd[579]: bridge0: MAC address: 00:12:34:56:78:30
>> 12:51:55 networkd[579]: bridge0: carrier off
>> 12:51:55 networkd[579]: DHCP CLIENT: STOPPED
>> 12:51:56 networkd[579]: bridge0: link status updated: 0x00011043 ->
>> 0x1043
>> 12:51:56 networkd[579]: enp3s0: enslaved
>> 12:51:56 networkd[579]: enp3s0: bringing link up
>> 12:51:56 networkd[579]: enp3s0: link configured
>> 12:51:56 networkd[579]: bridge0: MAC address: 00:12:34:56:78:30
>> 12:51:56 networkd[579]: bridge0: link status updated: 0x1043 ->
>> 0x1003
>> 12:51:56 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>> 12:51:56 networkd[579]: enp3s0: link is up
>> 12:51:56 networkd[579]: enp3s0: link status updated: 0x1002 ->
>> 0x1003
>> 12:51:56 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>> 12:51:57 networkd[579]: enp3s0: MAC address: 00:12:34:56:78:30
>> 12:51:57 networkd[579]: enp3s0: carrier on
>> 12:51:57 networkd[579]: enp3s0: link status updated: 0x1003 ->
>> 0x00011043
>> 12:51:57 networkd[579]: enp3s0: 

Re: [systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

[Lennart Poettering]

On Thu, 20.03.14 12:49, Cristian Rodríguez (crrodrig...@opensuse.org) wrote:

> The underlying components have not seen any upstream activity
> since 1997 and are not particulary nice either.
> 
> Those interested in computer archeology can explicitly use --enable-tcpwrap

Is suse intending to drop tcpwrap from its core os?

I am all for getting rid of tcpwrap, but just disabling it in
configure.ac by default looks like the wrong option to me...

So far our policy was to enable evertyhing that exists in systemd by
default when you build it with the default options, so that everything
gets at least regularly compile tested, if not actually tested in
real-life. 

So, if this shall stay in systemd, then it should be enabled by
default. The only other option I see is to remove it entirely, but i'd
really like to keep the bigger picture in view there. Or in other words,
if we get rid of it in systemd, we should do so knowing that this is in
sync with what the big distros intend to do in general too.

TO figure out what we can do in Fedora I have now started a discussion
on fedora-devel, about getting rid of tcpwrap system-wide. Let's see
where this goes. Would be interested in feedback about this from other
distros too.

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] network: dhcp: create explicit host route to gateway

[Brandon Philips]

This is a better approach that was suggested by Mike and ack'd by Tom.

Some DHCP servers gives you a netmask of 255.255.255.255 so the gateway is not
routable. Other DHCP client implementations look through the existing routes to
figure out if they should add an explicit host route. See below for a link.

However, it makes sense to just create the route explicitly whether it is
needed or not since it is explicit, makes the dhcp route entries independent of
other entries and saves us from knowing the state of the kernel tables.

After patch route table on a machine with a network (common case):

default via 10.0.2.2 dev ens3
10.0.2.0/24 dev ens3  proto kernel  scope link  src 10.0.2.15
10.0.2.2 dev ens3  scope link

After patch route table on a machine without a network (this case):

default via 10.240.0.1 dev ens4v1
10.240.0.1 dev ens4v1  scope link

The code from dhcpcd that works around this issue is on line 637.
https://android.googlesource.com/platform/external/dhcpcd/+/master/configure.c


0001-network-dhcp-create-explicit-host-route-to-gateway.patch
Description: Binary data
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

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

[Tom Gundersen]

On Thu, Mar 20, 2014 at 6:52 PM, Tom Gundersen  wrote:
> On Wed, Mar 19, 2014 at 2:36 PM, Umut Tezduyar Lindskog
>  wrote:
>> ---
>>  src/libsystemd-network/sd-ipv4ll.c |   86 +---
>>  src/network/networkd-link.c|   12 +++-
>>  src/network/networkd.h |1 +
>>  src/shared/net-util.c  |   39 +
>>  src/shared/net-util.h  |2 +
>>  src/systemd/sd-ipv4ll.h|1 +
>>  src/udev/net/link-config.c |   27 +
>>  7 files changed, 119 insertions(+), 49 deletions(-)
>>
>> 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 (

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

[Tom Gundersen]

On Wed, Mar 19, 2014 at 2:36 PM, Umut Tezduyar Lindskog
 wrote:
> ---
>  src/libsystemd-network/sd-ipv4ll.c |   86 +---
>  src/network/networkd-link.c|   12 +++-
>  src/network/networkd.h |1 +
>  src/shared/net-util.c  |   39 +
>  src/shared/net-util.h  |2 +
>  src/systemd/sd-ipv4ll.h|1 +
>  src/udev/net/link-config.c |   27 +
>  7 files changed, 119 insertions(+), 49 deletions(-)
>
> 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 out;
> +}
> +
> +if (ll->address == 0) {
> +r = ipv4ll_pick_address(ll, &ll->address);
> +if (r < 0)
> 

[systemd-devel] [PATCH] build: change tcpwrappers support to disabled by default

[Cristian Rodríguez]

The underlying components have not seen any upstream activity
since 1997 and are not particulary nice either.

Those interested in computer archeology can explicitly use --enable-tcpwrap
---
 configure.ac | 22 --
 1 file changed, 8 insertions(+), 14 deletions(-)

diff --git a/configure.ac b/configure.ac
index 3ced6cf..6859510 100644
--- a/configure.ac
+++ b/configure.ac
@@ -432,28 +432,22 @@ AM_CONDITIONAL(HAVE_XZ, [test "$have_xz" = "yes"])
 
 # 
--
 AC_ARG_ENABLE([tcpwrap],
-AS_HELP_STRING([--disable-tcpwrap],[Disable optional TCP wrappers 
support]),
+AS_HELP_STRING([--enable-tcpwrap],[Enable optional TCP wrappers 
support]),
 [case "${enableval}" in
 yes) have_tcpwrap=yes ;;
 no) have_tcpwrap=no ;;
-*) AC_MSG_ERROR(bad value ${enableval} for 
--disable-tcpwrap) ;;
+*) AC_MSG_ERROR(bad value ${enableval} for 
--enable-tcpwrap) ;;
 esac],
-[have_tcpwrap=auto])
+[have_tcpwrap=no])
 
-if test "x${have_tcpwrap}" != xno ; then
+AS_IF([test "x$have_tcpwrap" = "xyes" ], [
 ACX_LIBWRAP
-if test "x${LIBWRAP_LIBS}" = x ; then
-if test "x$have_tcpwrap" = xyes ; then
+AS_IF([test "x${LIBWRAP_LIBS}" = "x"], [
+   AS_IF([test "x$have_tcpwrap" = "xyes"], [
 AC_MSG_ERROR([*** TCP wrappers support not found.])
-fi
-have_tcpwrap=no
-else
+], [
 M4_DEFINES="$M4_DEFINES -DHAVE_LIBWRAP"
-have_tcpwrap=yes
-fi
-else
-LIBWRAP_LIBS=
-fi
+have_tcpwrap=yes])])], [LIBWRAP_LIBS=])
 AC_SUBST(LIBWRAP_LIBS)
 
 # 
--
-- 
1.8.4.5

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

Re: [systemd-devel] Building systemd from git

[Kevin Wilson]

Hi all,
Thanks for the quick response from all responders; I was afraid that
etc here was indeed in a different context than a path

regards,
KW

On Thu, Mar 20, 2014 at 4:08 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Thu, Mar 20, 2014 at 04:02:37PM +0200, Kevin Wilson wrote:
>> Thanks, Zbyszek.
>>
>> > --prefix etc.
>>
>> I assume you mean:
>> --prefix /etc
>> and not
>> prefix /etc
>>
>> is it so ?
> No, I meant "--prefix" as in the command line option to ./configure,
> e.g. "--prefix=/usr", and "etc" as in "et cetera", not the directory.
> Something like "./configure --prefix=/usr --sysconfdir=/etc 
> --localstatedir=/var".
> Generally, it is best to use the same flags that you distribution uses.
> Then you'll overwrite existing files instead writing them to a different
> directory and potentially causing confusion.
>
> Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Building systemd from git

[Zbigniew Jędrzejewski-Szmek]

On Thu, Mar 20, 2014 at 04:02:37PM +0200, Kevin Wilson wrote:
> Thanks, Zbyszek.
> 
> > --prefix etc.
> 
> I assume you mean:
> --prefix /etc
> and not
> prefix /etc
> 
> is it so ?
No, I meant "--prefix" as in the command line option to ./configure,
e.g. "--prefix=/usr", and "etc" as in "et cetera", not the directory.
Something like "./configure --prefix=/usr --sysconfdir=/etc 
--localstatedir=/var".
Generally, it is best to use the same flags that you distribution uses.
Then you'll overwrite existing files instead writing them to a different
directory and potentially causing confusion.

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

Re: [systemd-devel] Building systemd from git

[Kay Sievers]

On Thu, Mar 20, 2014 at 3:02 PM, Kevin Wilson  wrote:
> Thanks, Zbyszek.
>
>> --prefix etc.
>
> I assume you mean:
> --prefix /etc
> and not
> prefix /etc
>
> is it so ?

No.

Just check out git and run ./autogen.sh, it will tell you what to do.

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

Re: [systemd-devel] Building systemd from git

[Reindl Harald]

Am 20.03.2014 15:02, schrieb Kevin Wilson:
>> --prefix etc.
> 
> I assume you mean:
> --prefix /etc
> and not
> prefix /etc
> 
> is it so ?
> KW

no: http://en.wikipedia.org/wiki/Et_cetera
you don't want your binary tree in /etc

> On Wed, Mar 19, 2014 at 10:44 PM, Zbigniew Jędrzejewski-Szmek
>  wrote:
>> On Wed, Mar 19, 2014 at 10:25:30PM +0200, Kevin Wilson wrote:
>>> Hello,
>>>
>>> When I build systemd from git using the usual procedure of configure,
>>> without setting special parameters, it installs folder under
>>> /usr/etc/systemd/ (like /usr/etc/systemd/system and its children,
>>> /usr/etc/systemd/network/, and more).
>> That's the usual GNU "style".
>>
>>> Is there a way to run configure so that, instead of
>>> /usr/etc/systemd/, it will use /etc/systemd/ ?
>>> In Fedora, for example, the rpm uses the /etc/systemd and not
>>> /usr/etc/systemd/, which does not exist.
>> Use --prefix etc.
>>
>> Look ./autogen.sh for some nice default options



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] Building systemd from git

[Kevin Wilson]

Thanks, Zbyszek.

> --prefix etc.

I assume you mean:
--prefix /etc
and not
prefix /etc

is it so ?

KW





On Wed, Mar 19, 2014 at 10:44 PM, Zbigniew Jędrzejewski-Szmek
 wrote:
> On Wed, Mar 19, 2014 at 10:25:30PM +0200, Kevin Wilson wrote:
>> Hello,
>>
>> When I build systemd from git using the usual procedure of configure,
>> without setting special parameters, it installs folder under
>> /usr/etc/systemd/ (like /usr/etc/systemd/system and its children,
>> /usr/etc/systemd/network/, and more).
> That's the usual GNU "style".
>
>> Is there a way to run configure so that, instead of
>> /usr/etc/systemd/, it will use /etc/systemd/ ?
>> In Fedora, for example, the rpm uses the /etc/systemd and not
>> /usr/etc/systemd/, which does not exist.
> Use --prefix etc.
>
> Look ./autogen.sh for some nice default options.
>
> Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] [RFC PATCH] service: add Restart option to execute StartLimitAction immediately

[Michael Olbrich]

---

Hi,

The idea is to reboot immediately when a service crashes or the watchdog
triggers. This is useful in embedded scenarios when there is only one
important service. There are use-cases where rebooting immediately instead
of trying to restart the application first makes sense.
The environment of the restarted application is not well defined. The
watchdog is for unexpected failures. So making sure that the application
behaves correctly can be difficult. When rebooting only takes a few
seconds, doing so may be more robust than trying to recover from an
undefined state.

This is an RFC for now. Mostly because I think the configuration is rather
awkward like this.
Hooking into Restart/StartLimitAction was the easiest way to handle this in
the code. But it doesn't feel natural to configure it like this. Any Ideas
on how to  express this in the unit file?

Regards,
Michael

 src/core/service.c | 23 ++-
 src/core/service.h |  1 +
 2 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/src/core/service.c b/src/core/service.c
index 78a2e06..ef494ba 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -1832,6 +1832,8 @@ static int cgroup_good(Service *s) {
 return !r;
 }
 
+static int service_start_limit_execute(Service *s);
+
 static void service_enter_dead(Service *s, ServiceResult f, bool 
allow_restart) {
 int r;
 assert(s);
@@ -1843,6 +1845,10 @@ static void service_enter_dead(Service *s, ServiceResult 
f, bool allow_restart)
 
 if (allow_restart &&
 !s->forbid_restart &&
+s->restart == SERVICE_RESTART_FAIL) {
+service_start_limit_execute(s);
+} else if (allow_restart &&
+!s->forbid_restart &&
 (s->restart == SERVICE_RESTART_ALWAYS ||
  (s->restart == SERVICE_RESTART_ON_SUCCESS && s->result == 
SERVICE_SUCCESS) ||
  (s->restart == SERVICE_RESTART_ON_FAILURE && s->result != 
SERVICE_SUCCESS) ||
@@ -2363,12 +2369,9 @@ fail:
 service_enter_stop(s, SERVICE_FAILURE_RESOURCES);
 }
 
-static int service_start_limit_test(Service *s) {
+static int service_start_limit_execute(Service *s) {
 assert(s);
 
-if (ratelimit_test(&s->start_limit))
-return 0;
-
 switch (s->start_limit_action) {
 
 case SERVICE_START_LIMIT_NONE:
@@ -2416,6 +2419,15 @@ static int service_start_limit_test(Service *s) {
 return -ECANCELED;
 }
 
+static int service_start_limit_test(Service *s) {
+assert(s);
+
+if (ratelimit_test(&s->start_limit))
+return 0;
+
+return service_start_limit_execute(s);
+}
+
 static int service_start(Unit *u) {
 Service *s = SERVICE(u);
 int r;
@@ -3754,7 +3766,8 @@ static const char* const 
service_restart_table[_SERVICE_RESTART_MAX] = {
 [SERVICE_RESTART_ON_FAILURE] = "on-failure",
 [SERVICE_RESTART_ON_WATCHDOG] = "on-watchdog",
 [SERVICE_RESTART_ON_ABORT] = "on-abort",
-[SERVICE_RESTART_ALWAYS] = "always"
+[SERVICE_RESTART_ALWAYS] = "always",
+[SERVICE_RESTART_FAIL] = "fail"
 };
 
 DEFINE_STRING_TABLE_LOOKUP(service_restart, ServiceRestart);
diff --git a/src/core/service.h b/src/core/service.h
index 1992926..2cdc7ad 100644
--- a/src/core/service.h
+++ b/src/core/service.h
@@ -56,6 +56,7 @@ typedef enum ServiceRestart {
 SERVICE_RESTART_ON_WATCHDOG,
 SERVICE_RESTART_ON_ABORT,
 SERVICE_RESTART_ALWAYS,
+SERVICE_RESTART_FAIL,
 _SERVICE_RESTART_MAX,
 _SERVICE_RESTART_INVALID = -1
 } ServiceRestart;
-- 
1.9.1

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

[systemd-devel] sudo -u app_user systemctl --user

[David Schmitt]

Hi,

for a hosting project, I'd like to enable some users to control the user 
session of an application user.


Configuring and running the applications under the app user already 
works great.


The straightforward way in my mind would have been to enable sudoing 
from the personal accounts into the app user, allowing to run "systemctl 
--user ..." Sadly, this does not work out, as I've not found a way to 
get sudo to enter the app user's xdg session.


Curiously, using su- this would work. I'm wondering whether I've 
overlooked some configuration bit or whether sudo is just doing things 
differently enough, so that I'll have to use su- instead and create some 
kind of wrapper script for safety.


# su works

personal@testagent:~$ sudo -kn su - app_user -c 'systemctl --user status 
nginx.service'
nginx.service - The nginx HTTP and reverse proxy server
  Loaded: loaded 
(/srv/dasz/home/app_user/.config/systemd/user/nginx.service; enabled)
  Active: failed (Result: exit-code) since Thu, 20 Mar 2014 07:49:54 
+0100; 2h 17min ago
 Process: 17746 ExecStartPre=/usr/sbin/nginx -c 
/srv/dasz/etc/nginx/nginx.conf -t (code=exited, status=1/FAILURE)
  CGroup: name=systemd:/user/app_user/shared/systemd-17741/nginx.service


# sudo doesn't

personal@testagent:~$ sudo -kn -u app_user systemctl --user status nginx.service
Failed to get D-Bus connection: Unable to autolaunch a dbus-daemon without a 
$DISPLAY for X11
personal@testagent:~$


IIUIC, systemctl's behaviour is caused by this difference:

personal@testagent:~$ sudo -kn su - app_user -c env | grep ^XDG
XDG_SESSION_ID=c19
XDG_SESSION_COOKIE=1f9ce2afe379e46cdfedb64153259313-1395305911.233556-949665988
XDG_RUNTIME_DIR=/run/user/app_user
personal@testagent:~$ sudo -knu app_user env | grep ^XDG
personal@testagent:~$


I've also tried replacing sudo's pam config with su's, because the 
former is only creating noninteractive sessions by default, but that 
didn't change the behaviour.


Environment: Debian stable

# dpkg -l login sudo systemd libpam-systemd
||/ Name   Version  
Architecture
+++-==--
ii  libpam-systemd:amd64   44-11+deb7u4 
amd64
ii  login  1:4.1.5.1-1  
amd64
ii  sudo   
1.8.5p2-1+nmu1   amd64
ii  systemd44-11+deb7u4 
amd64
#


I'm aware that this is not the current systemd version, but since I 
believe this is a actually problem on the sudo side, I hope that won't 
make a big difference.




Thanks for any hints you can provide.


Regards, David

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

Re: [systemd-devel] [PATCH 1/2] domain: move compose logic on its own kdbus_domain_compose_path() function

[Daniel Mack]

Hi,

On 03/19/2014 09:24 PM, Djalal Harouni wrote:
> Signed-off-by: Djalal Harouni 
> ---
>  domain.c | 68 
> +++-
>  1 file changed, 37 insertions(+), 31 deletions(-)
> 
> diff --git a/domain.c b/domain.c
> index 2e05e90..d27cad2 100644
> --- a/domain.c
> +++ b/domain.c
> @@ -223,12 +223,44 @@ struct kdbus_domain 
> *kdbus_domain_find_by_major(unsigned int major)
>   return domain;
>  }
>  
> +/* Caller has validated parent and name arguments */
> +static int kdbus_domain_compose_path(struct kdbus_domain *domain,
> +  struct kdbus_domain *parent,
> +  const char *name)

[...]

> + ret = kdbus_domain_compose_path(d, parent, name);
> + if (ret < 0)
> + goto exit_unlock;

Hmm, what's the purpose of adding such a single-user function? We
generally try to avoid them, unless it really makes the code more
readable, which isn't the case here IMHO.

Or are you planning to call it from somewhere else as well?


Thanks,
Daniel

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

Re: [systemd-devel] [PATCH 2/2] domain: grab the domain's parent lock only when needed

[Daniel Mack]

On 03/19/2014 09:24 PM, Djalal Harouni wrote:
> Signed-off-by: Djalal Harouni 
> ---
>  domain.c | 13 +
>  1 file changed, 5 insertions(+), 8 deletions(-)
> 
> diff --git a/domain.c b/domain.c
> index d27cad2..554b4fe 100644
> --- a/domain.c
> +++ b/domain.c
> @@ -183,12 +183,13 @@ struct kdbus_domain *kdbus_domain_unref(struct 
> kdbus_domain *domain)
>   return NULL;
>  }
>  
> -static struct kdbus_domain *kdbus_domain_find(struct kdbus_domain const 
> *parent,
> +static struct kdbus_domain *kdbus_domain_find(struct kdbus_domain *parent,
> const char *name)
>  {
>   struct kdbus_domain *domain = NULL;
>   struct kdbus_domain *n;
>  
> + mutex_lock(&parent->lock);
>   list_for_each_entry(n, &parent->domain_list, domain_entry) {
>   if (strcmp(n->name, name))
>   continue;
> @@ -196,6 +197,7 @@ static struct kdbus_domain *kdbus_domain_find(struct 
> kdbus_domain const *parent,
>   domain = kdbus_domain_ref(n);
>   break;
>   }
> + mutex_unlock(&parent->lock);
>  
>   return domain;
>  }
> @@ -288,9 +290,6 @@ int kdbus_domain_new(struct kdbus_domain *parent, const 
> char *name,
>   atomic64_set(&d->msg_seq_last, 0);
>   idr_init(&d->user_idr);
>  
> - if (parent)
> - mutex_lock(&parent->lock);
> -
>   mutex_lock(&kdbus_subsys_lock);
>  
>   /* compose name and path of base directory in /dev */
> @@ -340,21 +339,19 @@ int kdbus_domain_new(struct kdbus_domain *parent, const 
> char *name,
>  
>   /* link into parent domain */
>   if (parent) {

What if 'parent' was already unrefed at this point? That can happen any
time as soon we give up the lock.

kdbus_domain_unref() calls kdbus_domain_disconnect(), wihch grabs
domain->lock, so we're only safe as long as we hold the lock across all
operations on the object, right?


Daniel

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

Re: [systemd-devel] [PATCH] libsystemd-network: Prepend hardware type byte to client identifier

[Patrik Flykt]

On Wed, 2014-03-19 at 13:53 +0200, Patrik Flykt wrote:
> Even though client identifiers SHOULD be treated as opaque objects by
> DHCP servers, follow the recommendation of a hardware type field with
> value 0x01 (ethernet) followed by the hardware address as described in
> RFC 2132.

Applied this patch.

Cheers,

Patrik


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

Re: [systemd-devel] [PATCH] libsystemd-network: Don't unnecessarily send too long packets

[Patrik Flykt]

On Wed, 2014-03-19 at 14:38 +0200, Patrik Flykt wrote:
> Since the length used by options is known, send packets with no
> extra padding.

Applied this patch too.

Cheers,

Patrik


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