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 p
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.or
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 @@ stru
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
>
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
---
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
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
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
>
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
___
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
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, Zbysz
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/co
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 +
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 |
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
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
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
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 archeol
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
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 co
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
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
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 p
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 cg
> 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 wit
25 matches
Mail list logo
