[systemd-devel] systemd

[yan...@iscas.ac.cn]

Hello guys:
I have a question. If I want use systemd in my system,like mint 17 ,what 
should I do? 



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

Re: [systemd-devel] systemd

[Reverend Homer]

Hi,

09.10.2015 11:45, yan...@iscas.ac.cn пишет:


Hello guys:
 I have a question. If I want use systemd in my system,like mint 17
,what should I do?

Please, don't use devel mailing list for such questions.
If you want to install systemd on linux mint, you should do something 
like this: 
http://superuser.com/questions/917804/switching-to-systemd-on-linux-mint

or this: https://wiki.ubuntu.com/systemd
Or you can install the distro with systemd by default. For example, 
Ubuntu 15.04 has systemd as default init, AFAIK.


yan...@iscas.ac.cn


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



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

Re: [systemd-devel] Secret machine-id for RFC 7217 stable addresses

[Damien Robert]

Tom Gundersen  wrote in message
:
> If I understand correctly, most of the point of RFC7217 is achieved
> even if the secret key is known. The important point is to have a good
> hashing function, and in that case knowing the secret key will not let
> you discover any of the other parameters (which are the ones you
> really want to hide).

Well if you know the secret key and the hash, you can do an exhaustive
search on the other parameters to recover them since they have low
entropy.

> Moreover, if the point is privacy, if an attacker has access (in some
> way) to the machine-id, there is no point in him going after the
> interface identifier as he can already identify the client.
> Given those two facts, might it not be sufficient to use the
> machine-id as the secret key after all?

It all depends on your model of security. You could imagine an attack where
an attacker known several machine-ids (for whatever reason, I can imagine
for instance a client downloading a vm preseeded with a machine-id). Then
when the client connects to the attacker, the attacker can try to hash all
his known machine-ids and the other low entropy parameters into the hash
function to get a match, in order to recover the machine-id and hence break
privacy.

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

Re: [systemd-devel] container virtual Ethernet link naming

[Johannes Ernst]

> On Oct 9, 2015, at 13:00, Dan Williams  wrote:
> 
> On Fri, 2015-10-09 at 12:53 -0700, Johannes Ernst wrote:
>> man systemd-nspawn, section on --network-veth
>>"The container side of the Ethernet link will be named 
>> host0."
>> 
>> container> ip link
>> ...
>> 2: host0@if9:  mtu 1500 qdisc fq_codel 
>> state UP mode DEFAULT group default qlen 1000
>>link/ether ce:d3:4f:6c:44:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0
>> 
>> Where does the @if9 come from, and what’s the naming scheme here?
> 
> It comes from /sbin/ip.  What's after the @ is the interface index of
> the veth peer, so "if9" == interface index 9 and that tells you what the
> peer link will be outside the container/namespace.  The stuff after the
> @ isn't controlled by systemd/udev, the "if" prefix is hardcoded
> in /sbin/ip.

This is actually cool, and as far as I can find, entirely undocumented :-)

I put a paragraph on the Arch wiki: 
https://wiki.archlinux.org/index.php/Systemd-nspawn#Virtual_Ethernet_interfaces 
based on your information. Thank you!

Cheers,



Johannes.

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

Re: [systemd-devel] [PATCH 2/2] udev/path_id: improve and enhance bus detection for Linux on z Systems

[Hendrik Brueckner]

Hi folks,

On Wed, Sep 23, 2015 at 01:42:57PM +0200, Hendrik Brueckner wrote:
> From: Liu Yuan Yuan 
> 
> Improve and enhance the path_id udev builtin to correctly handle bus'
> available on Linux on z Systems (s390).
> 
> Previously, the CCW bus and, in particular, any FCP devices on it, have
> been treated separately.  This commit integrates the CCW bus into the
> device chain loop.  FCP devices and their associated SCSI disks are now
> handled through the common SCSI handling functions in path_id.
> 
> This implies also a change in the naming of the symbolic links created
> by udev.  So any backports of this commit to existing Linux distribution
> must be done with care.  If a backport is requires, a udev rule can be
> created to create the "old-style" symbolic links too.
> 
> Apart from the CCW bus, this commit adds bus support for the:
> 
> - ccwgroup bus which manages network devices, and
> - ap bus which manages cryptographic adapters
> - iucv bus which manages IUCV devices on z/VM
> 
> Signed-off-by: Liu Yuan Yuan 
> Signed-off-by: Hendrik Brueckner 
> ---
>  src/udev/udev-builtin-path_id.c |   57 --
>  1 files changed, 30 insertions(+), 27 deletions(-)

Any feedback regarding this change?  Did I miss to notify someone
to pick that patch up?

Thanks and kind regards,
  Hendrik

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

Re: [systemd-devel] systemd

[Lennart Poettering]

On Fri, 09.10.15 13:22, Reverend Homer (mk.43.e...@gmail.com) wrote:

> Hi,
> 
> 09.10.2015 11:45, yan...@iscas.ac.cn пишет:
> >
> >Hello guys:
> > I have a question. If I want use systemd in my system,like mint 17
> >,what should I do?

Switching to systemd is really something your distribution has to
prepare for, it's not an app you can install on top. Hence, please ask
your distribution for help, we cannot really help you from upstream
there. Sorry.

> Please, don't use devel mailing list for such questions.

As Mantas already wrote: we only have one mailing list for systemd,
and its called "systemd-devel". But because we only have one, it's
really the place where everything should go, include questions as the
one above I guess.

As long as we aren't drowned in noise I would like to keep it that
way. Hence, I think the mail was OK to send here.

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] Secret machine-id for RFC 7217 stable addresses

[Simon McVittie]

On 08/10/15 21:47, Tom Gundersen wrote:
> On Mon, Sep 7, 2015 at 7:49 PM, Lubomir Rintel  wrote:
>> This sounds a bit like machine-id, unfortunately given it's world
>> readable and available via DBus (and possibly on a network?) it
>> doesn'tseem to be secret enough.

For context, the D-Bus machine ID (on which the systemd machine ID was
based) was intended to be used somewhat like the hostname, except with
the expectation that it is actually unique (unlike hostnames, which are
user-meaningful and therefore somewhat likely to collide). For instance,
GNOME's displays control panel stores a separate monitor layout per
machine ID, so that each machine has its appropriate monitor layout even
if they NFS-share a home directory.

Like a hostname, the machine ID is not really meant to be secret; for
instance, I think it would be OK to use the machine ID as a fallback
hostname, which could result in it being sent over the network in DHCP
or mDNS packets.

> A priori, it would perhaps have been nice to consider the real
> machine-id on disk to be "secret", and only ever expose a hash of it

How secret is "secret" here? Readable by root only? Readable by root and
system users? Readable by all local users? If a system component like
systemd (or D-Bus for that matter) is going to provide this as a "system
API", then it needs to be well-defined.

From the D-Bus point of view, in new installations it seems fine to use
the hash of a random secret as a basis for the world-readable machine
ID. However, in existing installations that are upgraded, the old
machine ID should always be preserved.

S

-- 
Simon McVittie
Collabora Ltd. 

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

Re: [systemd-devel] systemd and intltool

[Jan Synacek]

Jan Synacek  writes:

> Lennart Poettering  writes:
>
>> On Thu, 10.09.15 19:10, Michael Biebl (mbi...@gmail.com) wrote:
>>
>>> Hi,
>>> 
>>> reading https://wiki.gnome.org/Projects/GnomeCommon/Migration, it says
>>> that intltool is practically dead and one should use gettext directly.
>>> 
>>> Do we still need intltool in systemd? Does gettext have support for
>>> translating PolicyKit policy files?
>>
>> Happy to take a patch that removes the intltool hookup if it replaces
>> it with the right gettext hookup instead.
>
> I have investigated this a bit... AFAIK, gettext cannot be directly used
> to parse and merge translations into XML files. However, a simple python
> script instead of intltools should be enough for systemd's needs. I'll
> investigate further and possibly submit a pull request.

Submitted as https://github.com/systemd/systemd/pull/1513.

-- 
Jan Synacek
Software Engineer, Red Hat


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] systemd

[Mantas Mikulėnas]

On Fri, Oct 9, 2015 at 1:22 PM, Reverend Homer  wrote:

> Hi,
>
> 09.10.2015 11:45, yan...@iscas.ac.cn пишет:
>
>>
>> Hello guys:
>>  I have a question. If I want use systemd in my system,like mint 17
>> ,what should I do?
>>
> Please, don't use devel mailing list for such questions.
>

It's also a tech support list.


> If you want to install systemd on linux mint, you should do something like
> this:
> http://superuser.com/questions/917804/switching-to-systemd-on-linux-mint


It's Debian-specific; I'm not sure if Mint has imported all the changes...

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

Re: [systemd-devel] [PATCH 2/2] udev/path_id: improve and enhance bus detection for Linux on z Systems

[Colin Guthrie]

Hendrik Brueckner wrote on 09/10/15 08:13:
> Any feedback regarding this change?  Did I miss to notify someone
> to pick that patch up?

The process these days is via PR on GitHub. Normally patches posted to
the ML get a PR created for them automatically, but I don't see that here...

Perhaps retry via GitHub?

Col


-- 

Colin Guthrie
gmane(at)colin.guthr.ie
http://colin.guthr.ie/

Day Job:
  Tribalogic Limited http://www.tribalogic.net/
Open Source:
  Mageia Contributor http://www.mageia.org/
  PulseAudio Hacker http://www.pulseaudio.org/
  Trac Hacker http://trac.edgewall.org/

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

[systemd-devel] byte size that sd_bus_message_read can take.

[Jay Lee]

Hi,

I am writing a service using sd-bus API library in systemd211.
The service runs linux command lines (i.e. iptables ...) from user input.
It sounds stupid, but the service is needed for my project. :)  I am
wondering how many bytes sd_bus_message_read() can read/send at a time
because the output size from commands can be huge. It will be awesome if it
reads infinite, but I have this feeling that it limits the size of bytes to
read at a time.

thanks in advance.

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

[systemd-devel] container virtual Ethernet link naming

[Johannes Ernst]

man systemd-nspawn, section on --network-veth
"The container side of the Ethernet link will be named 
host0."

container> ip link
...
2: host0@if9:  mtu 1500 qdisc fq_codel state 
UP mode DEFAULT group default qlen 1000
link/ether ce:d3:4f:6c:44:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0

Where does the @if9 come from, and what’s the naming scheme here?

Cheers,



Johannes.

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

Re: [systemd-devel] container virtual Ethernet link naming

[Dan Williams]

On Fri, 2015-10-09 at 12:53 -0700, Johannes Ernst wrote:
> man systemd-nspawn, section on --network-veth
> "The container side of the Ethernet link will be named 
> host0."
> 
> container> ip link
> ...
> 2: host0@if9:  mtu 1500 qdisc fq_codel state 
> UP mode DEFAULT group default qlen 1000
> link/ether ce:d3:4f:6c:44:5f brd ff:ff:ff:ff:ff:ff link-netnsid 0
> 
> Where does the @if9 come from, and what’s the naming scheme here?

It comes from /sbin/ip.  What's after the @ is the interface index of
the veth peer, so "if9" == interface index 9 and that tells you what the
peer link will be outside the container/namespace.  The stuff after the
@ isn't controlled by systemd/udev, the "if" prefix is hardcoded
in /sbin/ip.

Dan

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