Applied. Thanks!
On Wed, Nov 19, 2014 at 12:13 AM, Dan Williams wrote:
> The lease is usually tied to the client ID, so users of the
> lease may want to know what client ID it was acquired with.
> ---
> src/libsystemd-network/dhcp-lease-internal.h | 5 +++
> src/libsystemd-network/sd-dhcp-clien
Applied. Thanks!
On Wed, Nov 19, 2014 at 12:01 AM, Dan Williams wrote:
> The client identifier can be in many different formats, not just
> the one that systemd creates from the Ethernet MAC address. Non-
> ethernet interfaces may have different client IDs formats. Users
> may also have custom
On Tue, 2014-11-18 at 19:32 +0100, Bastien Nocera wrote:
> On Tue, 2014-11-11 at 16:46 +0100, Lennart Poettering wrote:
>
> > I am willing to take a patch for this, but then again, as I own a Yoga
> > I might look into this myself too one day.
>
> If you can write the scaffolding for it, I'm happ
The client identifier can be in many different formats, not just
the one that systemd creates from the Ethernet MAC address. Non-
ethernet interfaces may have different client IDs formats. Users
may also have custom client IDs that the wish to use to preserve
lease options delivered by servers co
The lease is usually tied to the client ID, so users of the
lease may want to know what client ID it was acquired with.
---
src/libsystemd-network/dhcp-lease-internal.h | 5 +++
src/libsystemd-network/sd-dhcp-client.c | 16
src/libsystemd-network/sd-dhcp-lease.c | 58 +
On Tue, 18.11.14 15:45, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:
> 2014-11-18 14:40 GMT+03:00 Tom Gundersen :
> > This is on the TODO (still). Anything in particular you wonder about?
> >
> > Cheers,
>
> Hm. Does LLMNR can replace my needs - i want to able to resolve
> hostnames via multicast
On Tue, 18.11.14 14:55, Vasiliy Tolstov (v.tols...@selfip.ru) wrote:
> Hello. Does somebody have more concrete info about mdns support in
> resolved (also with ability to publish hostname via mdns). As i
> remember Lennart want to add this features...
It's one of the things I am working on right
On Tue, 2014-11-11 at 16:46 +0100, Lennart Poettering wrote:
> I am willing to take a patch for this, but then again, as I own a Yoga
> I might look into this myself too one day.
If you can write the scaffolding for it, I'm happy writing the code that
talks to the accelerometer, and that would ma
I was hesitating a bit about this, as I was worried about different
users of the library clobbering its others on-disk state. However, in
the end the user of the library is ultimately responsible for avoiding
name-space clashes and only saving leases in directories they "own",
so I guess it is ok.
Hi Dan,
Sorry for the delay. This patch looks good, minor nits inline.
Cheers,
Tom
On Tue, Nov 4, 2014 at 6:48 PM, Dan Williams wrote:
> The client identifier can be in many different formats, not just
> the one that systemd creates from the Ethernet MAC address. Non-
> ethernet interfaces ha
Applied. Thanks!
(but cc'ing Patrik just to make sure)
On Tue, Nov 4, 2014 at 6:20 PM, Dan Williams wrote:
> client->secs wasn't getting set in the REBOOT state, causing
> an assertion. REBOOT should work the same way as INIT, per
> RFC 2131:
>
> secs 2 Filled in by client, seconds elapsed
Hi.
Recently, after I had found an update for my BIOS, my desktop started to
resume properly (before I could only suspend it). Kernel and systemd do
their jobs fine. But they seem to have problem cooperating.
For the record I use systemd 215, which means that the issue I describe
here may have be
On Tue, 2014-11-04 at 11:48 -0600, Dan Williams wrote:
> The client identifier can be in many different formats, not just
> the one that systemd creates from the Ethernet MAC address. Non-
> ethernet interfaces have different client IDs formats too. Users
> may also have custom client IDs that th
On Tue, 2014-11-04 at 11:41 -0600, Dan Williams wrote:
> They're useful outside of networkd itself in the libsystemd-network
> library.
Anyone had a chance to review this patch?
> ---
> src/libsystemd-network/dhcp-lease-internal.h | 3 ---
> src/libsystemd-network/sd-dhcp-lease.c | 4 ++--
On Tue, 2014-11-04 at 11:20 -0600, Dan Williams wrote:
> client->secs wasn't getting set in the REBOOT state, causing
> an assertion. REBOOT should work the same way as INIT, per
> RFC 2131:
>
> secs 2 Filled in by client, seconds elapsed since client
>began address acquisition or
Le 18/11/2014 17:17, Tom Gundersen a écrit :
On Tue, Nov 18, 2014 at 4:21 PM, Didier Roche wrote:
Let's say as an admin that I want to disable plymouth-quit.service (which is
a static unit file and symlinked in /usr/lib… on the multi-user target).
Without knowing the systemd internals, my natur
Michael Biebl wrote on 18/11/14 15:55:
> 2014-11-18 16:30 GMT+01:00 Colin Guthrie :
>> Michael Biebl wrote on 18/11/14 15:09:
>>> 2014-11-18 15:59 GMT+01:00 Colin Guthrie :
Didier Roche wrote on 18/11/14 13:58:
> This would be maybe a nice way for the admin to know what's coming from
>
On Tue, Nov 18, 2014 at 5:11 PM, Michael Biebl wrote:
> 2014-11-18 14:52 GMT+01:00 Martin Pitt :
>> Colin Guthrie [2014-11-18 13:01 +]:
>>> > * I suppose even wich such a policy the post-installation script
>>> >still needs to call some systemd-update-policy-mumble-mumble magic
>>> >t
On Tue, Nov 18, 2014 at 4:21 PM, Didier Roche wrote:
> The thing I'm afraid of that we won't have a single place to list all
> disable units, and they will be in multiple packages, so (as I'll repeat
> below), I'm unsure that we would able to only load the preset as once shot,
> as we may add some
2014-11-18 14:52 GMT+01:00 Martin Pitt :
> Colin Guthrie [2014-11-18 13:01 +]:
>> > * I suppose even wich such a policy the post-installation script
>> >still needs to call some systemd-update-policy-mumble-mumble magic
>> >to actually apply the new policy?
>>
>> Well, the *.policy fil
2014-11-18 16:30 GMT+01:00 Colin Guthrie :
> Michael Biebl wrote on 18/11/14 15:09:
>> 2014-11-18 15:59 GMT+01:00 Colin Guthrie :
>>> Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's
Le 18/11/2014 15:59, Colin Guthrie a écrit :
Hiya,
Hey,
Didier Roche wrote on 18/11/14 13:58:
This would be maybe a nice way for the admin to know what's coming from
a distribution default or not. However, let's say I want to ensure that
ssh will always be available on my server, I would (even
Michael Biebl wrote on 18/11/14 15:09:
> 2014-11-18 15:59 GMT+01:00 Colin Guthrie :
>> Didier Roche wrote on 18/11/14 13:58:
>>> This would be maybe a nice way for the admin to know what's coming from
>>> a distribution default or not. However, let's say I want to ensure that
>>> ssh will always be
Le 18/11/2014 15:55, Tom Gundersen a écrit :
I get where you are coming from, but presets will give you the same
result, no?
Apart from what we discussed on this thread with Martin about the "/etc"
clutterness having distro-specific information and not only system ones,
right.
However, this is
2014-11-18 15:40 GMT+01:00 Colin Guthrie :
> Longer term, I want to move this to filetriggers. We have been using
> filetriggers for a while via an RPM patch and it looks like some kind of
> similar functionality will be (at long last) making it to upstream RPM
> in the nearish future. I believe .d
---
README | 3 +++
1 file changed, 3 insertions(+)
diff --git a/README b/README
index aefb349..70d1105 100644
--- a/README
+++ b/README
@@ -82,6 +82,9 @@ REQUIREMENTS:
CONFIG_CGROUP_SCHED
CONFIG_FAIR_GROUP_SCHED
+Required for CPUQuota in resource control unit sett
2014-11-18 15:59 GMT+01:00 Colin Guthrie :
> Didier Roche wrote on 18/11/14 13:58:
>> This would be maybe a nice way for the admin to know what's coming from
>> a distribution default or not. However, let's say I want to ensure that
>> ssh will always be available on my server, I would (even if it'
Hiya,
Didier Roche wrote on 18/11/14 13:58:
> This would be maybe a nice way for the admin to know what's coming from
> a distribution default or not. However, let's say I want to ensure that
> ssh will always be available on my server, I would (even if it's in my
> server preset) then systemctl e
On Tue, Nov 18, 2014 at 2:58 PM, Didier Roche wrote:
>> This I think should be considered a bug in the unit file. If a unit
>> has a /usr/lib symlink, then it is statically enabled (i.e.,
>> 'enable'/'disable' has no effect), so it should not install symlinks
>> in /etc, and hence not have an [Ins
From: Quentin Lefebvre
For plain dm-crypt devices, the behavior of cryptsetup package is to ignore the
hash algorithm when a key file is provided.
With this patch, systemd-cryptsetup now behaves as cryptsetup, so that old
plain dm-crypt devices created with cryptsetup can be mounted at boot tim
From: Quentin Lefebvre
*** BLURB HERE ***
Quentin Lefebvre (1):
This patch solves the bug 52630 described here:
https://bugs.freedesktop.org/show_bug.cgi?id=52630 .
src/cryptsetup/cryptsetup.c | 5 +
1 file changed, 5 insertions(+)
--
2.1.3
Hey Colin,
Colin Guthrie [2014-11-18 14:40 +]:
> In Mageia we do something similar but we shell out to a script instead.
> This allows us to replace the implementation without rebuilding all
> packages.
Debian does the same, there's a "deb-systemd-helper" wrapper called in
the postinst script
Martin Pitt wrote on 18/11/14 13:52:
> Hey Colin,
>
> thanks for the discussion! Trimming heavily; as you said we should let
> some other upstreams chime in too, I just have some followup
> questions.
>
> Colin Guthrie [2014-11-18 13:01 +]:
>>> * I suppose even wich such a policy the post-in
Le 18/11/2014 14:10, Tom Gundersen a écrit :
Hi Didier,
Thanks for your answer Tom and sharing your thoughts on this.
On Tue, Nov 18, 2014 at 12:11 PM, Didier Roche wrote:
This has 3 drawbacks:
- Duplicate symlinks for the same targets between /etc and units enabled in
/usr/lib for units w
Hey Colin,
thanks for the discussion! Trimming heavily; as you said we should let
some other upstreams chime in too, I just have some followup
questions.
Colin Guthrie [2014-11-18 13:01 +]:
> > * I suppose even wich such a policy the post-installation script
> >still needs to call some s
Hey Tom,
Tom Gundersen [2014-11-18 14:10 +0100]:
> This I think should be considered a bug in the unit file. If a unit
> has a /usr/lib symlink, then it is statically enabled (i.e.,
> 'enable'/'disable' has no effect), so it should not install symlinks
> in /etc, and hence not have an [Install] se
Hi Didier,
On Tue, Nov 18, 2014 at 12:11 PM, Didier Roche wrote:
> This has 3 drawbacks:
> - Duplicate symlinks for the same targets between /etc and units enabled in
> /usr/lib for units which are already enabled via /usr/lib, if the admin runs
> "enable"
This I think should be considered a bug
Martin Pitt wrote on 18/11/14 12:01:
> Hello Colin, all,
>
> Colin Guthrie [2014-11-18 11:30 +]:
>> I believe that it is generally discouraged to use "systemctl enable"
>> indirectly or otherwise during postinst.
>
> Right, I don't like this either, hence this discussion. :-) I don't
> know w
Hello Colin, all,
Colin Guthrie [2014-11-18 11:30 +]:
> I believe that it is generally discouraged to use "systemctl enable"
> indirectly or otherwise during postinst.
Right, I don't like this either, hence this discussion. :-) I don't
know whether Debian's current way of enabling units on pa
2014-11-18 14:40 GMT+03:00 Tom Gundersen :
> This is on the TODO (still). Anything in particular you wonder about?
>
> Cheers,
Hm. Does LLMNR can replace my needs - i want to able to resolve
hostnames via multicast (all my servers have only pure ipv6 (slaac)
addresses and statically assigned hostn
On Tue, Nov 18, 2014 at 11:55 AM, Vasiliy Tolstov wrote:
> Hello. Does somebody have more concrete info about mdns support in
> resolved (also with ability to publish hostname via mdns). As i
> remember Lennart want to add this features...
This is on the TODO (still). Anything in particular you w
On Tue, Nov 18, 2014 at 3:30 AM, William Wilhelm wrote:
> I'm building a router and have been experimenting with DHCPServer=yes for
> the LAN side of things. It's been working well.
> I ask if there is any integration between the networkd DHCP server and
> systemd-resolved? When the server hands o
Didier Roche wrote on 18/11/14 11:11:
> Fedora doesn't enable and start all units on package installation: there
> are some preset files, based on flavors, which is basically the policy
> stating which units to enable/disable by default. Some other units are
> always enabled (unless masked), by usi
From: Philippe De Swert
udev_monitor_enable_receiving() enables a udev_monitor to recieve
events. If this fails, the worker here created most likely won't
recieve any events and will probably not be very useful. So now
we check if the event recieving is activated before creating the
new worker.
Fedora doesn't enable and start all units on package installation: there
are some preset files, based on flavors, which is basically the policy
stating which units to enable/disable by default. Some other units are
always enabled (unless masked), by using symlinks directly shipped with
the pack
Hello. Does somebody have more concrete info about mdns support in
resolved (also with ability to publish hostname via mdns). As i
remember Lennart want to add this features...
--
Vasiliy Tolstov,
e-mail: v.tols...@selfip.ru
jabber: v...@selfip.ru
___
s
46 matches
Mail list logo