[systemd-devel] Satitic IP in container

[arnaud gaboury]

I set up successful a Arch container managed by systemd-nspsawn.

I have an issue setting an IP for the container.

My host is Arch, running custom Kernel 3.13.5-1 (userspace is set) and
systemd-git (lats updated yesterday evening).
dhcpcd.service is disabled and network is started with these profiles:
*
Description="Bridge connection to container"
Interface=br0
Connection=bridge
BindsToInterfaces=()
IP=no
SkipNoCarrier=yes
*
NB : I tried with IP=static Adress='192.168.1.94/24' but nothing changes

Description='hortensia static ethernet connection'
Interface=enp7s0
Connection=ethernet
After=(bridge-hortensia)
IP=static
Address=('192.168.1.87/24')
Gateway='192.168.1.254'
DNS=('212.147.10.180' '212.147.10.162')
*

Any other profiles will break the network on host and/or container

Somme command ouptuts:

gabx@hortensia ➤➤ ~ % ip addr
2: enp7s0:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.87/24 brd 192.168.1.255 scope global enp7s0
   valid_lft forever preferred_lft forever
3: br0:  mtu 1500 qdisc noqueue state
UNKNOWN group default
link/ether 66:c3:60:92:5f:2c brd ff:ff:ff:ff:ff:ff
*
gabx@hortensia ➤➤ /etc/netctl % ip route
default via 192.168.1.254 dev enp7s0
192.168.1.0/24 dev enp7s0  proto kernel  scope link  src 192.168.1.87
***

Now I enabled systemd-network with these two files:
70-dahlia.netdev
*
[Match]
Host=77f348a2b3fb429b85a5de751ea9175a  <<< /etc/machie id in conatiner
Virtualization=systemd-nspawn

[NetDev]
Name=br0
Kind=bridge

80-dahlia.network
*
[Match]
Virtualization=container
MACAddress=fa:2c:eb:75:bd:a4  <<< container MAC address

[Network]
DHCP=no
DNS=192.168.1.254

[Address]
Address=192.168.1.94/24

[Route]
Gateway=192.168.1.254
*

I start the container this way :
# systemd-nspawn --machine=dahlia -bD /dahlia

Container network is up, but no IP assigned, as returned by ip addr

# systemd-nspawn --machine=dahlia --network-veth --network-bridge=br0  -bD
/dahlia no network inside container
# systemd-nspawn --machine=dahlia --network-bridge=br0 -bD /dahlia  >>>no
network inside container

I certainly miss something, but do not know what.

Thank you for help/hints.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Problems with systemd-coredump

[Manuel Reimer]

On 02/18/2014 11:05 AM, Thomas Bächler wrote:

Am 17.02.2014 21:27, schrieb Manuel Reimer:

As soon as a bigger coredump (about 500 MB) is to be stored, the whole
system slows down significantly. Seems like storing such big amounts of
data takes pretty long and is a very CPU hungry process...


I completely agree. Since the kernel ignores the maximum coredump size
when core_pattern is used, a significant amount of time passes whenever
a larger process crashes, with no benefit (since the dump never gets
saved anywhere).

This is extremely annoying if processes with sizes in the tens or
hundreds of gigabytes crash, which sadly happened to me quite a few
times recently.


If this feature is broken by design, why is it still enabled by default 
on Arch Linux? systemd-coredump makes it nearly impossible to debug 
bigger processes and it took me quite some time to figure out how to get 
coredumps placed to /var/tmp so I can use them to find out why my 
process has crashed.


Yours

Manuel

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

[systemd-devel] How to build systemd with statically linking

[황재영]

Hello,

I've tried to build systemd(v43) with statically linking.

I revised Makefile.am and spec file but it was not built statically.

 

systemd: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically
linked (uses shared libs), for GNU/Linux 2.6.25,
BuildID[sha1]=0x4afa2d030f0e7d3446aed9835c2f99bdee1f2473, not stripped

 

diff --git a/Makefile.am b/Makefile.am
index 9762da1..6def4d1 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -730,6 +730,7 @@ systemd_SOURCES = \
src/main.c

systemd_CFLAGS = \
+ -static \
$(AM_CFLAGS) \
$(DBUS_CFLAGS) \
$(UDEV_CFLAGS)
diff --git a/packaging/systemd.spec b/packaging/systemd.spec
index fc9a794..8b0f7de 100644
--- a/packaging/systemd.spec
+++ b/packaging/systemd.spec
@@ -187,8 +187,8 @@ This package includes the man pages for systemd.

%build
cp %{SOURCE1001} .
-%autogen
-%configure --disable-static \
+%autogen -static
+%configure \
--with-rootdir="" \
--with-distro=meego \
--disable-gtk \

 

Best regards



 

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

Re: [systemd-devel] How to build systemd with statically linking

[David Timothy Strauss]

On Sat, Mar 1, 2014 at 12:46 AM, 황재영  wrote:
> I've tried to build systemd(v43) with statically linking.

That version is ancient. I'm afraid you won't find much help with it
here. Have you tried a newer release?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Creating a Release Tarball

[Tom Gundersen]

On Sat, Mar 1, 2014 at 8:36 AM, Justin Brown  wrote:
> commands to prep the repository before creating the tarball. Could
> someone enlighten me what steps need to be taken before building the
> RPM?

$ make distcheck

should create a tarball for you.

Cheers,

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

Re: [systemd-devel] How to build systemd with statically linking

[Cristian Rodríguez]

El 01/03/14 05:46, 황재영 escribió:

Hello,

I've tried to build systemd(v43) with statically linking.

I revised Makefile.am and spec file but it was not built statically.


Do not use static linking, it won't work. also systemd 43 is an ancient 
relic.



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

Re: [systemd-devel] Satitic IP in container

[Tom Gundersen]

On Sat, Mar 1, 2014 at 9:18 AM, arnaud gaboury  wrote:
> I set up successful a Arch container managed by systemd-nspsawn.
>
> I have an issue setting an IP for the container.
>
> My host is Arch, running custom Kernel 3.13.5-1 (userspace is set) and
> systemd-git (lats updated yesterday evening).
> dhcpcd.service is disabled and network is started with these profiles:
> *
> Description="Bridge connection to container"
> Interface=br0
> Connection=bridge
> BindsToInterfaces=()
> IP=no
> SkipNoCarrier=yes
> *
> NB : I tried with IP=static Adress='192.168.1.94/24' but nothing changes
> 
> Description='hortensia static ethernet connection'
> Interface=enp7s0
> Connection=ethernet
> After=(bridge-hortensia)
> IP=static
> Address=('192.168.1.87/24')
> Gateway='192.168.1.254'
> DNS=('212.147.10.180' '212.147.10.162')
> *
>
> Any other profiles will break the network on host and/or container
>
> Somme command ouptuts:
>
> gabx@hortensia ➤➤ ~ % ip addr
> 2: enp7s0:  mtu 1500 qdisc pfifo_fast state
> UP group default qlen 1000
> link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
> inet 192.168.1.87/24 brd 192.168.1.255 scope global enp7s0
>valid_lft forever preferred_lft forever
> 3: br0:  mtu 1500 qdisc noqueue state
> UNKNOWN group default
> link/ether 66:c3:60:92:5f:2c brd ff:ff:ff:ff:ff:ff
> *
> gabx@hortensia ➤➤ /etc/netctl % ip route
> default via 192.168.1.254 dev enp7s0
> 192.168.1.0/24 dev enp7s0  proto kernel  scope link  src 192.168.1.87
> ***
>
> Now I enabled systemd-network with these two files:
> 70-dahlia.netdev
> *
> [Match]
> Host=77f348a2b3fb429b85a5de751ea9175a  <<< /etc/machie id in conatiner
> Virtualization=systemd-nspawn
>
> [NetDev]
> Name=br0
> Kind=bridge
>
> 80-dahlia.network
> *
> [Match]
> Virtualization=container
> MACAddress=fa:2c:eb:75:bd:a4  <<< container MAC address

You mean the MAC address of the 'host0' device? This will not be
stable between reboots of the container, so I guess this won't work
(you can verify with "ip link"). I suggest simply matching on the name
instead: "Name=host0". I'll put on our TODO to set persistent MAC
addresses for these devices (assuming we can figure out a stable way
to generate them).

To get some more details, you could try starting networkd manually
(inside the container) in debug mode. It should then print whenever a
matching .network file is found for a given device:

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

> [Network]
> DHCP=no
> DNS=192.168.1.254
>
> [Address]
> Address=192.168.1.94/24
>
> [Route]
> Gateway=192.168.1.254
> *
>
> I start the container this way :
> # systemd-nspawn --machine=dahlia -bD /dahlia
>
> Container network is up, but no IP assigned, as returned by ip addr
>
> # systemd-nspawn --machine=dahlia --network-veth --network-bridge=br0  -bD
> /dahlia no network inside container
> # systemd-nspawn --machine=dahlia --network-bridge=br0 -bD /dahlia  >>>no
> network inside container
>
> I certainly miss something, but do not know what.
>
> Thank you for help/hints.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Satitic IP in container

[arnaud gaboury]

You mean the MAC address of the 'host0' device? This will not be

> stable between reboots of the container, so I guess this won't work
> (you can verify with "ip link").


You are right, this address changes across reboot. I get rid of this line.

I suggest simply matching on the name
> instead: "Name=host0".


 I have a problem with this host0. On container, no host0 listed. If I
remember correcty, I shall start systemd-nspawn with some more options,
like --network-veth, right ?

>
> To get some more details, you could try starting networkd manually
> (inside the container) in debug mode. It should then print whenever a
> matching .network file is found for a given device:
>
> hum hum. Maybe the problem comes from this : the host run systemd-git, BUT
the container systemd 208 !! This could explain my troubles ?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] Satitic IP in container

[Tom Gundersen]

On Sat, Mar 1, 2014 at 2:28 PM, arnaud gaboury  wrote:
>> I suggest simply matching on the name
>> instead: "Name=host0".
>
>  I have a problem with this host0. On container, no host0 listed. If I
> remember correcty, I shall start systemd-nspawn with some more options, like
> --network-veth, right ?

No, --network-bridge=br0 means that a pair of veth devices are created
(host0 inside the container and vb-* outside), and the vb-* is added
to your bridge br0. So you should really have host0 in the container
with this option. However, if you don't, which device did this mac
address you used to match on come from?

>> To get some more details, you could try starting networkd manually
>> (inside the container) in debug mode. It should then print whenever a
>> matching .network file is found for a given device:
>>
> hum hum. Maybe the problem comes from this : the host run systemd-git, BUT
> the container systemd 208 !! This could explain my troubles ?

Yeah, this won't work, as networkd will not be in your container, so
it can't set up your ip address...

Cheers,

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

Re: [systemd-devel] Satitic IP in container

[arnaud gaboury]

>
> No, --network-bridge=br0 means that a pair of veth devices are created
> (host0 inside the container and vb-* outside), and the vb-* is added
> to your bridge br0. So you should really have host0 in the container
> with this option. However, if you don't, which device did this mac
> address you used to match on come from?
>
> Yeah, this won't work, as networkd will not be in your container, so
> it can't set up your ip address...
>
> Cheers,
>
> Tom
>

I will maybe see the light then !
I am still confused about what shall be done in the host machine, and what
in the container.
Let's go systemd -git and --network-bridge= br0
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

[systemd-devel] binding tmpfiles.d to unit startup

[Colin Walters]

Hi,

So for OSTree I am trying to move to a model where services populate 
the contents of /var on *start*.  See previous discussion here:


https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg07859.html

The really great part about this is that one is then able to totally 
reset OS state at any time by simply just doing a shutdown of services, 
then "rm -rf /var/*", then  reboot.  (You can also reset /etc, that's a 
separate discussion)


Now while patching the service code itself got me pretty far, 
ultimately there are a lot of RPMs and such out there...so what I ended 
up doing for rpm-ostree was to generate tmpfiles.d snippets from the 
/var content:


https://github.com/cgwalters/rpm-ostree/commit/f8ddf38aa2dce207399d5e485842168eb2540e5f

Basically we end up with a gigantic 
/usr/lib/tmpfiles.d/rpm-ostree-autovar.conf that has stuff like:


d /var/spool/mail 0775 0 12 - -
d /var/lib/dnsmasq 0755 0 0 - -
...

The problem with this is it all happens on boot, and it doesn't really 
scale.  I want the RPMs (and packages in general) to do this by default.


So what's the problem with patching the world to do mkdir() on bootup?

1) Lots of work
2) Loss of association between package data and directory.  While this 
is

   pretty minor, it *is* useful to be able to do rpm -qf /var/kerberos
   and see that it comes from the "krb5-libs" package.
3) SELinux labeling - any service that creates a directory like this 
will
   have to be sure it labels it correctly.  While the latest SELinux 
does have

   support for doing this automatically, it'd still be better if it was
   done at a more trusted level.

What I really want is an easy way to bind tmpfiles.d snippets to unit 
startup.

Something like:

StateDirectory=/var/kerberos 0755 0 0

(Why not full tmpfiles.d syntax?  Well I can't think of a good reason 
to make
a *file* on startup.  There are packages that ship plain files in /var 
but

I'd say they're broken.)

With this, it's easy to do without patching the service.  It retains the
association (if a bit indirect) between the service and its state 
directory,
because you can query ownership of the .service file.  And systemd 
ensures

SELinux labeling happens correctly.

Thoughts?  Should be a pretty easy patch.


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

Re: [systemd-devel] [PATCH] TODO: Simple conditionals in tmpfiles

[Colin Walters]

On Fri, Feb 28, 2014 at 9:36 AM, Josh Triplett  
wrote:

---

Strawman proposal, open to suggestions.


...


+  - Simple conditionals: "C path mode user group - (tmpfiles-line)" 
does tmpfiles-line if path has mode, user, and group:
+C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775 root 
utmp
+C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755 root 
utmp
+C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777 root 
utmp


While I know I *just* posted a mail suggesting that more service state 
move to unit files... this feels pretty hacky to me.


Are there any use cases other than screen?

I also don't like the idea of admins "configuring" via chmod on stuff 
in /usr/bin.  OSTree simply won't support that for example.


A lot of this may come back to the discussion about screen and 
sessions.  If for example, users could request a new headless session, 
then most of the screen security-related architecture would be 
completely unnecessary with systemd, since the per-user state could 
just be hooked off of the per-user runtime dir.  

The per-user runtime dir would stay alive because the headless session 
would keep the user around.



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

Re: [systemd-devel] Satitic IP in container

[arnaud gaboury]

On Sat, Mar 1, 2014 at 3:26 PM, arnaud gaboury  wrote:
>
>
>>
>> No, --network-bridge=br0 means that a pair of veth devices are created
>> (host0 inside the container and vb-* outside), and the vb-* is added
>> to your bridge br0. So you should really have host0 in the container
>> with this option. However, if you don't, which device did this mac
>> address you used to match on come from?
>>
>> Yeah, this won't work, as networkd will not be in your container, so
>> it can't set up your ip address...
>>
>> Cheers,
>>
>> Tom
>
>
> I will maybe see the light then !
> I am still confused about what shall be done in the host machine, and what in 
> the container.
> Let's go systemd -git and --network-bridge= br0
>
I am nearly done.

On host side :
 /etc/systemd/network/70-dahlia.netdev
[Match]
Host=host0
Virtualization=container

[NetDev]
Name=br0
Kind=bridge

[Match]
Virtualization=container

*** /etc/systemd/network/80-dahlia.network
[Network]
DHCP=no
DNS=('212.147.10.162' '212.147.10.180')


[Address]
Address=192.168.1.94/24

[Route]
Gateway=192.168.1.254
**
Start the container
# sudo systemd-nspawn --machine=dahlia --network-bridge=br0 -bD /dahlia

On host :

gabx@hortensia ➤➤ systemd/network % ip addr
2: enp7s0:  mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.87/24 brd 192.168.1.255 scope global enp7s0
   valid_lft forever preferred_lft forever
3: br0:  mtu 1500 qdisc noqueue
state DOWN group default
link/ether 7a:21:78:cc:bc:a9 brd ff:ff:ff:ff:ff:ff
8: vb-dahlia:  mtu 1500 qdisc noop master br0
state DOWN group default qlen 1000
link/ether 7a:21:78:cc:bc:a9 brd ff:ff:ff:ff:ff:ff

Now on Container:

gab@dahlia ➤➤ ~ % ip addr
2: host0:  mtu
1500 qdisc pfifo_fast state DOWN group default qlen 1000
link/ether 3a:4f:1f:c5:b5:d1 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.94/24 brd 192.168.1.255 scope global host0   IP
is finally here
   valid_lft forever preferred_lft forever
gab@dahlia ➤➤ ~ % ip route
default via 192.168.1.254 dev host0
192.168.1.0/24 dev host0  proto kernel  scope link  src 192.168.1.94


BUT
gab@dahlia ➤➤ ~ % ping -c 3 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.1.94 icmp_seq=1 Destination Host Unreachable
From 192.168.1.94 icmp_seq=2 Destination Host Unreachable
From 192.168.1.94 icmp_seq=3 Destination Host Unreachable


On container, I have of course systemd-networkd enable. I have the
same file /etc/systemd/network/80-dahlia.network . Not sure if I do
need it. When removed, I lost the IP.
No netctl profile enable, no dhcpcd.service enable. /etc/conf.d is empty

Any idea why I can't reach the network ?

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

Re: [systemd-devel] Creating a Release Tarball

[Lennart Poettering]

On Sat, 01.03.14 01:36, Justin Brown (justin.br...@fandingo.org) wrote:

> Sorry for this very basic question, but I've hit a wall and can't
> figure what I need to do. I'm getting started on trying to do some
> systemd development. The most natural way for me to compile systemd is
> to use the Fedora RPM spec to create an RPM and install that on a test
> machine. I've pulled the systemd-210.tar.xz and used that to build
> RPMs based on the Fedora 20 systemd package. That's easy enough.
> 
> The problem that I have is taking the systemd git repository and
> turning that into a tarball that the RPM spec file can use. In
> particular, it fails -- at least initially -- because there are lots
> of files missing in doc/. I'm assuming that I need to run some
> commands to prep the repository before creating the tarball. Could
> someone enlighten me what steps need to be taken before building the
> RPM?
> 
> 1. ??
> 2. tar cJf systemd-210.tar.xz systemd-210/
> 3. mv systemd-210.tar.xz ~/rpmbuild/SOURCES/
> 4. rpmbuild -bb ~/rpmbuild/SPECS/systemd.spec


git clone git://anongit.freedesktop.org/systemd/systemd systemd
cd systemd
./autogen.sh c
make distcheck

This will generate the .xz tarball for you.

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] How to build systemd with statically linking

[Lennart Poettering]

On Sat, 01.03.14 17:46, Ȳ�翵 (j-zero.hw...@samsung.com) wrote:

> Hello,
> 
> I've tried to build systemd(v43) with statically linking.
> 
> I revised Makefile.am and spec file but it was not built statically.

We do not support static linking. We probably should turn this off
entirely in the build system if there is a way, to make sure people get
a clean error.

The systemd tree makes use of NSS and even includes an NSS module. That
kind of stuff is inherently dynamic in nature, and can never be done
statically. Hence we simply do not support that. Only the most trivial
libraries actually support it.

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] How to build systemd with statically linking

[Samuli Suominen]

On 01/03/14 20:11, Lennart Poettering wrote:
> On Sat, 01.03.14 17:46, Ȳ�翵 (j-zero.hw...@samsung.com) wrote:
>
>> Hello,
>>
>> I've tried to build systemd(v43) with statically linking.
>>
>> I revised Makefile.am and spec file but it was not built statically.
> We do not support static linking. We probably should turn this off
> entirely in the build system if there is a way, to make sure people get
> a clean error.

configure.ac already has:

AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static
is not supported by systemd])])

as the user was trying to build version 43, that'd explain why he didn't
see it, as that snippet wasn't added
at that time yet.
in any case, please don't make the building of libudev.a any more harder
than it is now, i know it has it's
pitfalls, and it shouldn't be officially supported in any way, but if
you know what you are doing, you can,
by removing this snippet from configure.ac, get a semi-working libudev.a
which is a prerequisite for
building static lvm2/cryptsetup binaries

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

Re: [systemd-devel] binding tmpfiles.d to unit startup

[Michael Biebl]

2014-03-01 15:46 GMT+01:00 Colin Walters :
> Hi,
>
> So for OSTree I am trying to move to a model where services populate the
> contents of /var on *start*.  See previous discussion here:
>
> https://www.mail-archive.com/systemd-devel@lists.freedesktop.org/msg07859.html
>
> The really great part about this is that one is then able to totally reset
> OS state at any time by simply just doing a shutdown of services, then "rm
> -rf /var/*", then  reboot.  (You can also reset /etc, that's a separate
> discussion)
>
> Now while patching the service code itself got me pretty far, ultimately
> there are a lot of RPMs and such out there...so what I ended up doing for
> rpm-ostree was to generate tmpfiles.d snippets from the /var content:
>
> https://github.com/cgwalters/rpm-ostree/commit/f8ddf38aa2dce207399d5e485842168eb2540e5f
>
> Basically we end up with a gigantic
> /usr/lib/tmpfiles.d/rpm-ostree-autovar.conf that has stuff like:
>
> d /var/spool/mail 0775 0 12 - -
> d /var/lib/dnsmasq 0755 0 0 - -
> ...
>
> The problem with this is it all happens on boot, and it doesn't really
> scale.  I want the RPMs (and packages in general) to do this by default.
>
> So what's the problem with patching the world to do mkdir() on bootup?
>
> 1) Lots of work
> 2) Loss of association between package data and directory.  While this is
> pretty minor, it *is* useful to be able to do rpm -qf /var/kerberos
> and see that it comes from the "krb5-libs" package.
> 3) SELinux labeling - any service that creates a directory like this will
> have to be sure it labels it correctly.  While the latest SELinux does
> have
> support for doing this automatically, it'd still be better if it was
> done at a more trusted level.
>
> What I really want is an easy way to bind tmpfiles.d snippets to unit
> startup.
> Something like:
>
> StateDirectory=/var/kerberos 0755 0 0
>
> (Why not full tmpfiles.d syntax?  Well I can't think of a good reason to
> make
>  a *file* on startup.  There are packages that ship plain files in /var but
>  I'd say they're broken.)
>
> With this, it's easy to do without patching the service.  It retains the
> association (if a bit indirect) between the service and its state directory,
> because you can query ownership of the .service file.  And systemd ensures
> SELinux labeling happens correctly.
>
> Thoughts?  Should be a pretty easy patch.

I vaguely remember that we exactly had this discussion a while ago.
Unfortunately I'm not able to find it in the archives right now.

One of the objections I remember was, that this would lead to having
two different ways of setting up runtime directories.

-- 
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] binding tmpfiles.d to unit startup

[Colin Walters]

On Sat, Mar 1, 2014 at 1:44 PM, Michael Biebl  wrote:


I vaguely remember that we exactly had this discussion a while ago.



Argh, yes, possibly. The dangers of getting older...


Unfortunately I'm not able to find it in the archives right now.



I think if we did talk about it, it was some variant, and then maybe 
the conversation was on IRC?



One of the objections I remember was, that this would lead to having
two different ways of setting up runtime directories.

Can you elaborate on this?  The two different things being tmpfiles.d 
and unit files?



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

Re: [systemd-devel] binding tmpfiles.d to unit startup

[Michael Biebl]

2014-03-01 19:47 GMT+01:00 Colin Walters :
> On Sat, Mar 1, 2014 at 1:44 PM, Michael Biebl  wrote:
>
> I vaguely remember that we exactly had this discussion a while ago.
>
>
> Argh, yes, possibly. The dangers of getting older...
>
> Unfortunately I'm not able to find it in the archives right now.

Found it: 
http://lists.freedesktop.org/archives/systemd-devel/2013-July/011956.html
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] binding tmpfiles.d to unit startup

[Tom Gundersen]

On Sat, Mar 1, 2014 at 8:04 PM, Michael Biebl  wrote:
> 2014-03-01 19:47 GMT+01:00 Colin Walters :
>> On Sat, Mar 1, 2014 at 1:44 PM, Michael Biebl  wrote:
>>
>> I vaguely remember that we exactly had this discussion a while ago.
>>
>>
>> Argh, yes, possibly. The dangers of getting older...
>>
>> Unfortunately I'm not able to find it in the archives right now.
>
> Found it: 
> http://lists.freedesktop.org/archives/systemd-devel/2013-July/011956.html

And a bit further down that thread there was this proposal from Lennar
(which doesn't seem far from what Colin wants):
.

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

Re: [systemd-devel] binding tmpfiles.d to unit startup

[Zbigniew Jędrzejewski-Szmek]

On Sat, Mar 01, 2014 at 02:46:45PM +, Colin Walters wrote:
> 2) Loss of association between package data and directory.  While
> this is
>pretty minor, it *is* useful to be able to do rpm -qf /var/kerberos
>and see that it comes from the "krb5-libs" package.
On a related note, I want to generate rpm %files contents from tmpfiles
snippets. I think it should work like this:



%build
systemd-tmpfiles --generate-rpm-files 
%{buildroot}/usr/lib/tmpfiles.d/%{name}.conf >.tpmfiles.list

%files -f .tmpfiles.list

%post
systemd-tmpfiles --create /usr/lib/tmpfiles.d/%{name}.conf



Where the output out tmpfiles --generate-rpm-files [name subject to change],
would be something like:

%ghost /var/name/

The point is that this will simplify rpm packaging by removing the need
to repeat the list in two places.

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

Re: [systemd-devel] binding tmpfiles.d to unit startup

[Michael Biebl]

2014-03-01 20:18 GMT+01:00 Tom Gundersen :
> On Sat, Mar 1, 2014 at 8:04 PM, Michael Biebl  wrote:
>> 2014-03-01 19:47 GMT+01:00 Colin Walters :
>>> On Sat, Mar 1, 2014 at 1:44 PM, Michael Biebl  wrote:
>>>
>>> I vaguely remember that we exactly had this discussion a while ago.
>>>
>>>
>>> Argh, yes, possibly. The dangers of getting older...
>>>
>>> Unfortunately I'm not able to find it in the archives right now.
>>
>> Found it: 
>> http://lists.freedesktop.org/archives/systemd-devel/2013-July/011956.html
>
> And a bit further down that thread there was this proposal from Lennar
> (which doesn't seem far from what Colin wants):
> .

In Debian we have debhelper addons which generate maintainer scripts
code automatically to run systemd-tmpfiles
/usr/lib/tmpfiles.d/foo.conf upon installation, so this isn't really a
problem anymore for us.

Regarding discoverability, my suggestion in that thread was to add a
new field which allows to reference the associated tmpfiles snippet,
similar as we do for Documentation.

Having such a reference on the tmpfile snippet(s) in the .service file
would also make it possible to run them automatically whenever the
service is started. This could be useful for distros which haven't
automated the invocation of systemd-tmpfiles

Michael

-- 
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] binding tmpfiles.d to unit startup

[Colin Walters]

On Sat, Mar 1, 2014 at 2:18 PM, Tom Gundersen  wrote:

And a bit further down that thread there was this proposal from Lennar
(which doesn't seem far from what Colin wants):
.

Right...so rereading that, the discussion seemed to peter out after: 
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012090.html


I see Michael's point here as well:
http://lists.freedesktop.org/archives/systemd-devel/2013-July/012037.html

Certainly it magnifies the pain for the RPM world in that there's 
nothing that scans the build directory and says "hey you installed 
something that looks like a tmpfiles.d snippet, let me auto-generate 
some postinst shell script".


I think any postinsts like this are still pretty ugly though.  It means 
the directories are created when the daemon is *installed*, not when 
it's run.  Which is odd and against the generally dynamic nature of 
systemd.


Also, running shell script as root is just full of fail, sorry package 
people =)  Even if it's auto-generated from a centrally maintained 
place.


I admit this is sometimes what you want, e.g. if you need a way to 
install postgres and then restore a dump file from backup *before* 
starting it.  Those cases could be covered of course by an 
administrator doing a mkdir manually and if they're careful about 
SELinux, using restorecon.


So basically here'd what I'd propose, which is an extension of 
Lennart's:


RuntimeDirectory=/run/mydaemon
PersistentStateDirectory=/var/lib/mydaemon

We could cover a lot of simple cases with that - default to being owned 
by User= and mode 0700, and have RuntimeDirectoryMode= and 
PersistentStateDirectoryMode= to override that last bit.


Note - the previous discussion seemed largely about /run, but I am most 
interested in real permanent directories in /var.


The primary goal again for me is that I can rm -rf /var/* and reboot, 
and have the system be clean.



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

Re: [systemd-devel] How to build systemd with statically linking

[Lennart Poettering]

On Sat, 01.03.14 20:36, Samuli Suominen (ssuomi...@gentoo.org) wrote:

> 
> On 01/03/14 20:11, Lennart Poettering wrote:
> > On Sat, 01.03.14 17:46, Ȳ�翵 (j-zero.hw...@samsung.com) wrote:
> >
> >> Hello,
> >>
> >> I've tried to build systemd(v43) with statically linking.
> >>
> >> I revised Makefile.am and spec file but it was not built statically.
> > We do not support static linking. We probably should turn this off
> > entirely in the build system if there is a way, to make sure people get
> > a clean error.
> 
> configure.ac already has:
> 
> AS_IF([test "x$enable_static" = "xyes"], [AC_MSG_ERROR([--enable-static
> is not supported by systemd])])
> 
> as the user was trying to build version 43, that'd explain why he didn't
> see it, as that snippet wasn't added
> at that time yet.
> in any case, please don't make the building of libudev.a any more harder
> than it is now, i know it has it's
> pitfalls, and it shouldn't be officially supported in any way, but if
> you know what you are doing, you can,
> by removing this snippet from configure.ac, get a semi-working libudev.a
> which is a prerequisite for
> building static lvm2/cryptsetup binaries

Why would you do something like that? That's just broken.

Also the API between udevd and libudev is not stable, you should never
mix different implementations.

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] [PATCH] TODO: Simple conditionals in tmpfiles

[Josh Triplett]

On Sat, Mar 01, 2014 at 03:03:17PM +, Colin Walters wrote:
> On Fri, Feb 28, 2014 at 9:36 AM, Josh Triplett
>  wrote:
> >---
> >
> >Strawman proposal, open to suggestions.
> >
> ...
> >
> >+  - Simple conditionals: "C path mode user group -
> >(tmpfiles-line)" does tmpfiles-line if path has mode, user, and
> >group:
> >+C /usr/bin/screen 2755 root utmp - d /var/run/screen 0775
> >root utmp
> >+C /usr/bin/screen 4755 root utmp - d /var/run/screen 0755
> >root utmp
> >+C /usr/bin/screen 0755 root utmp - d /var/run/screen 1777
> >root utmp
> >
> While I know I *just* posted a mail suggesting that more service
> state move to unit files... this feels pretty hacky to me.
> 
> Are there any use cases other than screen?

Games: "if the game has group games and mode 2755...".  But yeah, it
does seem like a hack.  In any case, given that the Debian screen
maintainer ended up accepting another solution instead (telling the
admin to create an overriding /etc/tmpfiles.d file if they change the
permissions, and handling upgrades via postinst), I don't feel strongly
attached to this proposal if nobody sees another useful application for
it.

Besides, inventing a new conditional syntax seems wrong.  Might work
better to introduce a new unit type, foo.tmpfiles, with the full set of
ConditionFoo from unit files, and then add a couple of additional
ConditionFoo types based on data available by statting files.

> I also don't like the idea of admins "configuring" via chmod on
> stuff in /usr/bin.  OSTree simply won't support that for example.

I can't argue with that; I'd personally rather see screen handled via a
set of packages, one per permission model, with the admin installing the
one they want.  Or better yet:

> A lot of this may come back to the discussion about screen and
> sessions.  If for example, users could request a new headless
> session, then most of the screen security-related architecture would
> be completely unnecessary with systemd, since the per-user state
> could just be hooked off of the per-user runtime dir.
> 
> The per-user runtime dir would stay alive because the headless
> session would keep the user around.

I'd certainly love to see a saner implementation of screen multiuser
support that doesn't require root.

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

Re: [systemd-devel] binding tmpfiles.d to unit startup

[Colin Walters]

On Sat, Mar 1, 2014 at 2:46 PM, Colin Walters  
wrote:


RuntimeDirectory=/run/mydaemon
PersistentStateDirectory=/var/lib/mydaemon


Btw, see also this thread:

https://lists.fedoraproject.org/pipermail/server/2014-February/000843.html

Putting these together (and how about we just go ahead and mandate /run 
and /var/lib), we could have something like:


RuntimeDirectory=yes

That would auto-instantiate /run/$SYSTEMD_UNIT_NAME.

Similarly,
PersistentStateDirectory=yes
would give you /var/lib/$SYSTEMD_UNIT_NAME

Notably, this would help administrators move away from the package 
being the central naming unit and more towards systemd being the basis 
for names.  

(It is confusing that one has to deal with package names, systemd unit 
names, and process names, which can all be the same, closely related, 
or wildly different)



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

Re: [systemd-devel] How to build systemd with statically linking

[Cristian Rodríguez]

El 01/03/14 15:36, Samuli Suominen escribió:


which is a prerequisite for
building static lvm2/cryptsetup binaries


Just wondering.. why would want to do that ?

It is going to break sooner or later.. maybe even worst, it may only 
appear to work..


Any program remotely useful needs a shared libc around, most components 
in the boot sequence do, systemd included. this also applies to the old 
sysvinit stuff. (sed, grep, bash, coreutils too..)




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

[systemd-devel] [PATCH] networkd-wait-online: use automatic cleanup

[Thomas H.P. Andersen]

From: Thomas Hindoe Paaboel Andersen 

---
Only compile tested. I just wanted to get rid of the warnings about
use of the uninitialized variables.

 Makefile.am|  3 ++-
 src/network/network-util.h | 28 
 src/network/networkd-wait-online.c | 12 +---
 3 files changed, 35 insertions(+), 8 deletions(-)
 create mode 100644 src/network/network-util.h

diff --git a/Makefile.am b/Makefile.am
index c4a975d..1ad2756 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2417,7 +2417,8 @@ libsystemd_network_la_SOURCES = \
src/libsystemd-network/dhcp-internal.h \
src/libsystemd-network/dhcp-protocol.h \
src/libsystemd-network/dhcp-lease-internal.h \
-   src/libsystemd-network/sd-dhcp-lease.c
+   src/libsystemd-network/sd-dhcp-lease.c \
+   src/libsystemd-network/network-util.h
 
 libsystemd_network_la_LIBADD = \
libsystemd-internal.la \
diff --git a/src/network/network-util.h b/src/network/network-util.h
new file mode 100644
index 000..9979e6d
--- /dev/null
+++ b/src/network/network-util.h
@@ -0,0 +1,28 @@
+/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
+
+#pragma once
+
+/***
+  This file is part of systemd.
+
+  Copyright 2014 Thomas Hindø Paabøl Andersen
+
+  systemd is free software; you can redistribute it and/or modify it
+  under the terms of the GNU Lesser General Public License as published by
+  the Free Software Foundation; either version 2.1 of the License, or
+  (at your option) any later version.
+
+  systemd is distributed in the hope that it will be useful, but
+  WITHOUT ANY WARRANTY; without even the implied warranty of
+  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+  Lesser General Public License for more details.
+
+  You should have received a copy of the GNU Lesser General Public License
+  along with systemd; If not, see .
+***/
+
+#include "util.h"
+
+DEFINE_TRIVIAL_CLEANUP_FUNC(sd_network_monitor*, sd_network_monitor_unref);
+
+#define _cleanup_network_monitor_unref_ _cleanup_(sd_network_monitor_unrefp)
diff --git a/src/network/networkd-wait-online.c 
b/src/network/networkd-wait-online.c
index 51c6bbd..50b753b 100644
--- a/src/network/networkd-wait-online.c
+++ b/src/network/networkd-wait-online.c
@@ -20,8 +20,10 @@
 ***/
 
 #include "sd-event.h"
+#include "event-util.h"
 #include "sd-daemon.h"
 #include "sd-network.h"
+#include "network-util.h"
 
 #include "util.h"
 
@@ -62,9 +64,9 @@ static int event_handler(sd_event_source *s, int fd, uint32_t 
revents,
 }
 
 int main(int argc, char *argv[]) {
-sd_event *event;
-sd_event_source *event_source;
-sd_network_monitor *monitor;
+_cleanup_event_unref_ sd_event *event = NULL;
+_cleanup_event_source_unref_ sd_event_source *event_source = NULL;
+_cleanup_network_monitor_unref_ sd_network_monitor *monitor = NULL;
 int r, fd, events;
 
 log_set_target(LOG_TARGET_AUTO);
@@ -129,9 +131,5 @@ out:
 sd_notify(false,
   "STATUS=All interfaces configured...");
 
-sd_event_source_unref(event_source);
-sd_event_unref(event);
-sd_network_monitor_unref(monitor);
-
 return r < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
 }
-- 
1.8.5.3

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

Re: [systemd-devel] [PATCH] networkd-wait-online: use automatic cleanup

[Tom Gundersen]

On Sat, Mar 1, 2014 at 10:52 PM, Thomas H.P. Andersen  wrote:
> From: Thomas Hindoe Paaboel Andersen 
>
> ---
> Only compile tested. I just wanted to get rid of the warnings about
> use of the uninitialized variables.

Applied. Thanks!

-t

>  Makefile.am|  3 ++-
>  src/network/network-util.h | 28 
>  src/network/networkd-wait-online.c | 12 +---
>  3 files changed, 35 insertions(+), 8 deletions(-)
>  create mode 100644 src/network/network-util.h
>
> diff --git a/Makefile.am b/Makefile.am
> index c4a975d..1ad2756 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -2417,7 +2417,8 @@ libsystemd_network_la_SOURCES = \
> src/libsystemd-network/dhcp-internal.h \
> src/libsystemd-network/dhcp-protocol.h \
> src/libsystemd-network/dhcp-lease-internal.h \
> -   src/libsystemd-network/sd-dhcp-lease.c
> +   src/libsystemd-network/sd-dhcp-lease.c \
> +   src/libsystemd-network/network-util.h
>
>  libsystemd_network_la_LIBADD = \
> libsystemd-internal.la \
> diff --git a/src/network/network-util.h b/src/network/network-util.h
> new file mode 100644
> index 000..9979e6d
> --- /dev/null
> +++ b/src/network/network-util.h
> @@ -0,0 +1,28 @@
> +/*-*- Mode: C; c-basic-offset: 8; indent-tabs-mode: nil -*-*/
> +
> +#pragma once
> +
> +/***
> +  This file is part of systemd.
> +
> +  Copyright 2014 Thomas Hindø Paabøl Andersen
> +
> +  systemd is free software; you can redistribute it and/or modify it
> +  under the terms of the GNU Lesser General Public License as published by
> +  the Free Software Foundation; either version 2.1 of the License, or
> +  (at your option) any later version.
> +
> +  systemd is distributed in the hope that it will be useful, but
> +  WITHOUT ANY WARRANTY; without even the implied warranty of
> +  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> +  Lesser General Public License for more details.
> +
> +  You should have received a copy of the GNU Lesser General Public License
> +  along with systemd; If not, see .
> +***/
> +
> +#include "util.h"
> +
> +DEFINE_TRIVIAL_CLEANUP_FUNC(sd_network_monitor*, sd_network_monitor_unref);
> +
> +#define _cleanup_network_monitor_unref_ _cleanup_(sd_network_monitor_unrefp)
> diff --git a/src/network/networkd-wait-online.c 
> b/src/network/networkd-wait-online.c
> index 51c6bbd..50b753b 100644
> --- a/src/network/networkd-wait-online.c
> +++ b/src/network/networkd-wait-online.c
> @@ -20,8 +20,10 @@
>  ***/
>
>  #include "sd-event.h"
> +#include "event-util.h"
>  #include "sd-daemon.h"
>  #include "sd-network.h"
> +#include "network-util.h"
>
>  #include "util.h"
>
> @@ -62,9 +64,9 @@ static int event_handler(sd_event_source *s, int fd, 
> uint32_t revents,
>  }
>
>  int main(int argc, char *argv[]) {
> -sd_event *event;
> -sd_event_source *event_source;
> -sd_network_monitor *monitor;
> +_cleanup_event_unref_ sd_event *event = NULL;
> +_cleanup_event_source_unref_ sd_event_source *event_source = NULL;
> +_cleanup_network_monitor_unref_ sd_network_monitor *monitor = NULL;
>  int r, fd, events;
>
>  log_set_target(LOG_TARGET_AUTO);
> @@ -129,9 +131,5 @@ out:
>  sd_notify(false,
>"STATUS=All interfaces configured...");
>
> -sd_event_source_unref(event_source);
> -sd_event_unref(event);
> -sd_network_monitor_unref(monitor);
> -
>  return r < 0 ? EXIT_FAILURE : EXIT_SUCCESS;
>  }
> --
> 1.8.5.3
>
> ___
> 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

[systemd-devel] [RFC/PATCH] tmpfiles: implement --transform=rpm

[Zbigniew Jędrzejewski-Szmek]

---

I'm not sure if this can be actually as useful as I envisioned. At
least in case of systemd.spec there's a lot of special-casing
required, which partially destroys the usefulness of this. Configuration
for "normal" packages will hopefully be more straighforward.

I made the switch name generic, so that other "transforms" can
be added later without complicating the command-line api.

Zbyszek

 src/tmpfiles/tmpfiles.c | 144 +++-
 1 file changed, 107 insertions(+), 37 deletions(-)

diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 6e36dc7..008bc16 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -101,6 +101,10 @@ typedef struct Item {
 bool keep_first_level:1;
 } Item;
 
+enum {
+TRANSFORM_RPM = 1,
+};
+
 static Hashmap *items = NULL, *globs = NULL;
 static Set *unix_sockets = NULL;
 
@@ -108,6 +112,7 @@ static bool arg_create = false;
 static bool arg_clean = false;
 static bool arg_remove = false;
 static bool arg_boot = false;
+static int arg_transform = 0;
 
 static char **include_prefixes = NULL;
 static char **exclude_prefixes = NULL;
@@ -125,7 +130,13 @@ static const char conf_file_dirs[] =
 #define MAX_DEPTH 256
 
 static bool needs_glob(ItemType t) {
-return t == IGNORE_PATH || t == IGNORE_DIRECTORY_PATH || t == 
REMOVE_PATH || t == RECURSIVE_REMOVE_PATH || t == RELABEL_PATH || t == 
RECURSIVE_RELABEL_PATH;
+return IN_SET(t,
+  IGNORE_PATH,
+  IGNORE_DIRECTORY_PATH,
+  REMOVE_PATH,
+  RECURSIVE_REMOVE_PATH,
+  RELABEL_PATH,
+  RECURSIVE_RELABEL_PATH);
 }
 
 static struct Item* find_glob(Hashmap *h, const char *match) {
@@ -972,22 +983,55 @@ static int clean_item(Item *i) {
 return r;
 }
 
+static int transform_item(Item *i, int transform) {
+assert(i);
+assert(transform == TRANSFORM_RPM);
+
+switch (i->type) {
+
+case IGNORE_PATH:
+case IGNORE_DIRECTORY_PATH:
+case REMOVE_PATH:
+case RECURSIVE_REMOVE_PATH:
+case ADJUST_MODE:
+case TRUNCATE_DIRECTORY:
+case RELABEL_PATH:
+case RECURSIVE_RELABEL_PATH:
+log_debug("%s ignored.", i->path);
+return 0;
+
+case CREATE_FILE:
+case TRUNCATE_FILE:
+case WRITE_FILE:
+case CREATE_FIFO:
+case CREATE_SYMLINK:
+case CREATE_BLOCK_DEVICE:
+case CREATE_CHAR_DEVICE:
+printf("%%ghost %s\n", i->path);
+break;
+
+case CREATE_DIRECTORY:
+printf("%%ghost %%dir %s\n", i->path);
+break;
+}
+
+return 0;
+}
+
 static int process_item(Item *i) {
-int r, q, p;
+int r, q, p, s;
 
 assert(i);
 
 r = arg_create ? create_item(i) : 0;
 q = arg_remove ? remove_item(i) : 0;
 p = arg_clean ? clean_item(i) : 0;
+s = arg_transform ? transform_item(i, arg_transform) : 0;
 
-if (r < 0)
-return r;
-
-if (q < 0)
-return q;
-
-return p;
+return r < 0 ? r :
+q < 0 ? q :
+p < 0 ? p :
+s;
 }
 
 static void item_free(Item *i) {
@@ -1270,14 +1314,15 @@ static int help(void) {
 
 printf("%s [OPTIONS...] [CONFIGURATION FILE...]\n\n"
"Creates, deletes and cleans up volatile and temporary files 
and directories.\n\n"
-   "  -h --help Show this help\n"
-   " --version  Show package version\n"
-   " --create   Create marked files/directories\n"
-   " --cleanClean up marked directories\n"
-   " --remove   Remove marked files/directories\n"
-   " --boot Execute actions only safe at 
boot\n"
-   " --prefix=PATH  Only apply rules that apply to 
paths with the specified prefix\n"
-   " --exclude-prefix=PATH  Ignore rules that apply to paths 
with the specified prefix\n",
+   "  -h --helpShow this help\n"
+   " --version Show package version\n"
+   " --create  Create marked files/directories\n"
+   " --clean   Clean up marked directories\n"
+   " --remove  Remove marked files/directories\n"
+   " --bootExecute actions only safe at boot\n"
+   " --transform=rpm   Create files list suitable for RPM 
%%files section\n"
+   " --prefix=PATH Only apply rules that match the 
specified prefix\n"
+   " --exclude-prefix=PATH Ignore rules that match the 
specified prefix\n",
p

Re: [systemd-devel] Set environment for user@.service

[subi . the . dream . walker]

Hi,

Before systemd 209, I put 'Environment=ENV=%h/.somedir' in
/etc/user@.service.d/env.conf to set some variables. Now since %h is not
available for system units anymore, I take the workaround by adding a
user unit set-my-env.service:
-
[Unit]
Description=Set systemd environment
Before=default.target

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=-/usr/bin/systemctl --user set-environment ENV=%h/.somedir

[Install]
WantedBy=basic.target


The problem is that set-my-env.service may not affect the early units
pulled in by default.target. I wonder how we can execute
set-my-env.service as soon as user@.service is started. Thanks.

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

Re: [systemd-devel] [RFC/PATCH] tmpfiles: implement --transform=rpm

[Kay Sievers]

On Sun, Mar 2, 2014 at 3:06 AM, Zbigniew Jędrzejewski-Szmek
 wrote:
> +   " --transform=rpm   Create files list suitable for 
> RPM %%files section\n"

Hmm, can't we maybe come up with something that isn't specific to rpm
or dpkg, something that is easily parsed but not bound to the
internals of the format of the files?

It sounds like the-wrong-way-around to encode packaging formats into
high-level systemd tools. In the end, both formats are really a blast
from the past, and represent the status quo, but are surely not the
future of how packaging of of a modern Linux system should look like,
so it might be nicer to make it generic?

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