Re: [systemd-devel] systemd unit file to remount /home /tmp /dev/shm /run with nosuid, nodev

2020-01-02 Thread Josh Triplett
Lennart Poettering wrote:
> And noexec doesn't really make much sense for these dirs, as this
> blocks mmap() with MAP_EXEC and there are plenty apps that want to use
> that. Moreover "noexec" is at best a protection against accidental
> execution and not a security mechanism since it is trivially easy to
> circumvent (just call the interpreter directly with the file to
> execute as first arg, which for ELF means "/lib64/ld-linux-x86-64.so.2 
> $BINARY")

That workaround doesn't actually work anymore; the former (blocking mmap
with MAP_EXEC) exists specifically to protect against the latter
(running the interpreter directly).

$ mount | grep '/run '
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=1620848k,mode=755)
$ sudo cp -a /bin/ls /run/ls
$ /run/ls
bash: /run/ls: Permission denied
(126) $ /lib64/ld-linux-x86-64.so.2 /run/ls
/run/ls: error while loading shared libraries: /run/ls: failed to map segment 
from shared object
(127) $

It's theoretically possible to work around *that* if you have permission
to run arbitrary code and to remap memory from write to execute (both of
which might also be locked down). But even without that, mount -o noexec
does meaningfully improve security, and the trivial workaround no longer
works.

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


[systemd-devel] Robust getpid caching via MADV_WIPEONFORK?

2018-03-19 Thread Josh Triplett
[Bcced to other potentially interested folks.]

As discussed in various places, glibc removed the getpid() cache in
2.25, since it was not robust against all possible ways to fork a
process.

Linux 4.14 added MADV_WIPEONFORK, which robustly ensures that a page
gets wiped to zero on any possible process fork. The commit message
adding it even mentions, as a use case:
>  - systemd/pulseaudio API checks (fail after fork) (replacing a getpid
>check, which is too slow without a PID cache)

Given that, I wanted to start a thread about the idea of making
getpid() caching, and for that matter other potential uses of
pthread_atfork(), robust using MADV_WIPEONFORK when available.

I don't necessarily want to advocate this; rather, since it seems likely
that other applications may wish to do things like this, I wanted to
collect some information and discuss whether it makes sense or not.

I wrote a simple test program, attached (warning: quick hack), that
benchmarks the stock getpid() versus a trivial cached version of
getpid() using MADV_WIPEONFORK (marked as "noinline" to simulate
providing it as a library function), just to get a rough idea.  This
produced the following numbers on my system:

mmap: 3292.00 ns
madvise: 3273.00 ns
uncached getpid: 1 calls in 4569540458.000 ns;  45.695 ns/call
  cached getpid: 1 calls in  132862952.000 ns;   1.329 ns/call

That's a significant speedup per call, but that savings only pays off if
the program calls getpid() more than ~150 times, or ~75 times if the
separate mmap can be avoided.

Given that, I don't think it makes sense for glibc to take this approach
in the standard getpid().  For any program that doesn't call getpid()
extensively, this seems like a pessimization, and many such programs can
do such caching themselves without worrying about an unexpected fork().
I think only specialized library code would ever want to do this.

Hopefully these numbers will help anyone looking to implement such
caching in their own code.

- Josh Triplett
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#ifndef MADV_WIPEONFORK
#define MADV_WIPEONFORK 18
#endif

static pid_t *cached_getpid_page;

__attribute__((noinline))
static pid_t cached_getpid(void)
{
pid_t pid = *cached_getpid_page;
if (!pid)
*cached_getpid_page = pid = getpid();
return pid;
}

static struct timespec get_time(void)
{
struct timespec t;
if (clock_gettime(CLOCK_MONOTONIC_RAW, ) < 0)
err(1, "clock_gettime");
return t;
}

static double to_nsec(struct timespec t)
{
return t.tv_sec * 10 + t.tv_nsec;
if (clock_gettime(CLOCK_MONOTONIC_RAW, ) < 0)
err(1, "clock_gettime");
printf("%llu.%09lu\n", (unsigned long long)t.tv_sec, t.tv_nsec);
}

static const int ITERATIONS = 1;

int main(void)
{
struct timespec start, end;
double duration;

start = get_time();

void *page = mmap(NULL, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
if (page == MAP_FAILED)
err(1, "mmap");

end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("mmap: %f ns\n", duration);

start = get_time();

if (madvise(page, 4096, MADV_WIPEONFORK) < 0)
err(1, "madvise");
cached_getpid_page = page;

end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("madvise: %f ns\n", duration);

start = get_time();
for (int i = 0; i < ITERATIONS; i++)
getpid();
end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("uncached getpid: %d calls in %14.3f ns; %7.3f ns/call\n", ITERATIONS, duration, duration/ITERATIONS);

start = get_time();
for (int i = 0; i < ITERATIONS; i++)
cached_getpid();
end = get_time();
duration = to_nsec(end) - to_nsec(start);
printf("  cached getpid: %d calls in %14.3f ns; %7.3f ns/call\n", ITERATIONS, duration, duration/ITERATIONS);

return 0;
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] ~/.local/bin , XDG, and environment variable overrides

2017-08-29 Thread Josh Triplett
On Tue, Aug 29, 2017 at 06:43:58PM +0200, Lennart Poettering wrote:
> On Sa, 26.08.17 10:43, Josh Triplett (j...@joshtriplett.org) wrote:
> 
> > systemd's file-hierarchy manpage
> > <https://www.freedesktop.org/software/systemd/man/file-hierarchy.html>
> > documents ~/.local/bin as the place under $HOME to install executables
> > in $PATH, and quite a bit of software has adopted that. However, unlike
> > the directories specified in the XDG Base Directory specification, this
> > doesn't include an environment variable (like $XDG_DATA_HOME for
> > ~/.local/share) to override it. I've seen a proposal to use
> > $XDG_BIN_HOME for that. Might it make sense to include that, and start
> > getting software to adopt it?
> 
> Quite frankly, I am not sure that having env vars for all those dirs
> was a good idea in the first place, but sure, if you want to
> standardize that, please go ahead, you have my support. A patch to the
> XDG basedir spec should be very welcome.

Developers on some platforms (e.g. Haiku) wanted the ability to set
those paths. This came up in the context of installing Rust binaries,
which didn't want to hardcode ~/.local/bin , and using something like
$XDG_DATA_HOME/../bin seems quite wrong as well.

> But do not the architecture issues with such a dir, i.e. home
> directories might be shared between systems of different archs, and
> binary programs compiled for one arch and placed in these dirs are
> unlikely to work on the other. I figure this is the reason why this
> concept was never included in XDG basedir spec, but then again I think
> it's fine to still add it as long as the issue is highlighted.

The second version of the patch from Johannes Löthberg seems to address
that.

I also suspect that $XDG_BIN_HOME might actually help folks who want to
deal with that issue, by setting it to a multiarch-style directory that
includes the architecture triple.  (Though that would also imply
installing architecture-independent scripts multiple times; however, I
don't think it's worth trying to define an elaborate scheme to handle
that, not when things like /usr/local/bin and /usr/bin *don't*. We're
not trying to solve that new and rare problem here; we're trying to
document the defacto standard that already exists.)

> > Also, would it make sense to add ~/.local/bin to the XDG Base Directory
> > specification itself? I'd be happy to write up an addition to the spec
> > for that, and propose it on the appropriate list.
> 
> If you add the env var then it should be added to the xdg basedir spec.

See the patches from Johannes Löthberg on the XDG list.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


[systemd-devel] ~/.local/bin , XDG, and environment variable overrides

2017-08-26 Thread Josh Triplett
systemd's file-hierarchy manpage
<https://www.freedesktop.org/software/systemd/man/file-hierarchy.html>
documents ~/.local/bin as the place under $HOME to install executables
in $PATH, and quite a bit of software has adopted that. However, unlike
the directories specified in the XDG Base Directory specification, this
doesn't include an environment variable (like $XDG_DATA_HOME for
~/.local/share) to override it. I've seen a proposal to use
$XDG_BIN_HOME for that. Might it make sense to include that, and start
getting software to adopt it?

Also, would it make sense to add ~/.local/bin to the XDG Base Directory
specification itself? I'd be happy to write up an addition to the spec
for that, and propose it on the appropriate list.

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


Re: [systemd-devel] Monitor path to commit to git

2016-04-08 Thread Josh Triplett
Lennart Poettering wrote:
> inotify doesn't really provide such a feature, and fanotify is
> crap.

Leaving aside any other issues with fanotify, it doesn't seem to provide
this feature either; "man fanotify" says "Fanotify monitoring of
directories is not recursive: to monitor subdirectories under a
directory, additional marks must be created."

That aside, though, can you elaborate on other issues with fanotify?
(Or, do you have or know of something already written on that topic that
you could point to?)
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel


Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

2015-04-20 Thread Josh Triplett
On April 20, 2015 8:39:33 AM PDT, Lennart Poettering lenn...@poettering.net 
wrote:
On Fri, 17.04.15 08:52, Josh Triplett (j...@joshtriplett.org) wrote:

 On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
  Now, to put together a more complex scenario for you: consider a
small
  web UI that can be used to set the system time. It should realy run
at
  minimal privileges, after all it has a surface to the web. Hence
you
  write it as daemon, make it run as a user id of its own, set up a
  chroot() or a file system namespace, but you do keep CAP_SYS_TIME
and
  a bus connection open. With that setup the web daemon can pretty
much
  only set the system clock, and if it exploited cannot be used for
much
  else. It will not have access to /dev/rtc, due to the file system
  namespace, but it can nicely set the system clock via timedated
still,
  and pretty much only that, and the clock will be synced to the RTC
by
  it.
  
  To map this back to your earlier request for an example. In this
case
  process A is the web UI daemon. Capability B is CAP_SYS_TIME.
Message
  C is the SetTime() bus call. Daemon D is timedated. 
  
  If the web UI daemon would not have CAP_SYS_TIME it couldn't change
  the time like this -- unless of course that web UI daemon would run
as
  UID 0 all the time, which is certainly much much less desirable,
given
  that it is a network facing daemon.
 
 I agree with your statement that any process with the ability to do
an
 operation directly (bypassing systemd) should have the ability to do
so
 safely through systemd.  However, that doesn't provide a complete
 solution, because the reverse shouldn't necessarily be true: it
should
 be possible to grant a process the ability to do an operation safely
 through systemd *without* granting it permission to do so directly.

yeah, for that side we have polkit.

 Now, I can still see the value in saying if you have permission to
do
 the unsafe thing directly, you can do the safe thing.  However, that
 seems like an optional enhancement, rather than core required
 functionality to make sane use of (k)dbus.  kdbus without the
 capability-passing mechanism still seems like a wildly useful
 enhancement.

Well, sure, I mean, the caps stuff are *not* essential to kdbus' mode
of operation. But I do believe they make the system better, and should
be used preferably over broad uid == 0 checks.

I'd certainly agree that uid 0 checks are a bad idea, since as little code 
should run as root as possible. However, rather than handing out capabilities 
that allow bypassing systemd and talking directly to the kernel, it seems 
preferable to run unprivileged and grant the necessary permissions to that 
process.


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


Re: [systemd-devel] SD_BUS_VTABLE_CAPABILITY

2015-04-17 Thread Josh Triplett
On Thu, Apr 16, 2015 at 08:23:45PM +0200, Lennart Poettering wrote:
 Now, to put together a more complex scenario for you: consider a small
 web UI that can be used to set the system time. It should realy run at
 minimal privileges, after all it has a surface to the web. Hence you
 write it as daemon, make it run as a user id of its own, set up a
 chroot() or a file system namespace, but you do keep CAP_SYS_TIME and
 a bus connection open. With that setup the web daemon can pretty much
 only set the system clock, and if it exploited cannot be used for much
 else. It will not have access to /dev/rtc, due to the file system
 namespace, but it can nicely set the system clock via timedated still,
 and pretty much only that, and the clock will be synced to the RTC by
 it.
 
 To map this back to your earlier request for an example. In this case
 process A is the web UI daemon. Capability B is CAP_SYS_TIME. Message
 C is the SetTime() bus call. Daemon D is timedated. 
 
 If the web UI daemon would not have CAP_SYS_TIME it couldn't change
 the time like this -- unless of course that web UI daemon would run as
 UID 0 all the time, which is certainly much much less desirable, given
 that it is a network facing daemon.

I agree with your statement that any process with the ability to do an
operation directly (bypassing systemd) should have the ability to do so
safely through systemd.  However, that doesn't provide a complete
solution, because the reverse shouldn't necessarily be true: it should
be possible to grant a process the ability to do an operation safely
through systemd *without* granting it permission to do so directly.

For instance, a user's desktop session should have permission to shut
down the system politely by asking systemd to shut down, without having
permission to shut down the system impolitely by invoking the reboot
system call.  Or in your time service example, the admin may want to
grant the web service permission to set the clock via timedated, but
*not* directly via settimeofday.

(I'm assuming below that you agree there should be a mechanism to offer
privileges to do a safe operation but *not* the corresponding unsafe
operation.  If you don't agree, let's talk about that first.)

Given that, some mechanism needs to exist to grant the
safe-but-not-unsafe permissions.  That might be polkit, or something
like dbus bus policies, or some other mechanism.

Now, I can still see the value in saying if you have permission to do
the unsafe thing directly, you can do the safe thing.  However, that
seems like an optional enhancement, rather than core required
functionality to make sane use of (k)dbus.  kdbus without the
capability-passing mechanism still seems like a wildly useful
enhancement.

Based on that, I'm wondering if there's any fundamental reason not to
split that out as a separate patch, get the remaining less-controversial
parts of kdbus merged, and then make the case for that separately.  Then
kdbus would be available for everyone to use sooner, and later on it
could gain some additional features.

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


Re: [systemd-devel] [PATCH] cryptsetup: Do not warn If the key is /dev/*random

2015-02-03 Thread Josh Triplett
On Mon, Feb 02, 2015 at 04:42:21PM +0100, Lennart Poettering wrote:
 On Mon, 02.02.15 12:06, Cristian Rodríguez (crrodriguez at opensuse.org) 
 wrote:
 
  Using /dev/urandom as a key is valid for swap, do not
  warn if this devices are world readable.
  ---
   src/cryptsetup/cryptsetup.c | 6 --
   1 file changed, 4 insertions(+), 2 deletions(-)
  
  diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
  index e6b37ac..38930ae 100644
  --- a/src/cryptsetup/cryptsetup.c
  +++ b/src/cryptsetup/cryptsetup.c
  @@ -624,8 +624,10 @@ int main(int argc, char *argv[]) {
   
   /* Ideally we'd do this on the open fd, but since 
  this is just a
* warning it's OK to do this in two steps. */
  -if (stat(key_file, st) = 0  (st.st_mode  
  0005))
  -log_warning(Key file %s is 
  world-readable. This is not a good idea!, key_file);
  +if (stat(key_file, st) = 0  (st.st_mode  
  0005)) {
  +if(!STR_IN_SET(key_file, /dev/urandom, 
  /dev/random, /dev/hw_random))
  +log_warning(Key file %s is 
  world-readable. This is not a good idea!, key_file);
  +}
 
 I'd prefer if we'd change the check instead to only apply to
 S_ISREG() files. This way we wouldn't have to list all RNG device
 nodes.

With the exception of /dev/*random, you don't want a world-readable
device used for a key either.  Some people have setups that use a USB
device (e.g. /dev/sd* or /dev/disk/by-*/*) as a keyfile, and in that
case, the file should *not* be world-readable.

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


Re: [systemd-devel] dynamic uid allocation (was: [PATCH] loopback setup in unprivileged containers)

2015-02-03 Thread Josh Triplett
Lennart Poettering wrote:
 Hmm, so, I thought a lot about this in the past weeks. I think the way
 I'd really like to see this work in the end is that we never have to
 persist the UID mappings. This could work if the kernel would provide
 us with the ability to bind mount a file system into the container
 applying a fixed UID shift. That way, the shifted UIDs would never hit
 the actual disk, and hence we wouldn't have to persist their mappings.

It ought to be possible to run an arbitrary distribution inside a
container, even a distribution that itself wants to run sandboxed
applications in containers.  Nesting matters, so a bare shift may not
suffice.  On the other hand, a shift is the simplest solution for simple
utility containers, such as those launched by systemd-nspawn.  nspawn
could trivially avoid persisting the UID map by applying a shift, while
a full container solution might want to construct persistent dynamic UID
maps, or integrate with special PAM/NSS modules, or any number of other
creative solutions.

Container UID handling was exactly what I had in mind when I sent in a
kernel patch for the setusers() system call.  If an unprivileged user on
the host system can have a pile of UIDs handed to them by the host
system, and can use any of those IDs in their UID map, then they can set
up any arbitrary container UID handling without further assistance from
host root.  A PAM module on the host could then, by policy, hand some or
all unprivileged users a substantial stack of host UIDs that they can
arbitrarily map to container UIDs; together with support for applying
UID maps to a mounted filesystem, that would provide all the necessary
kernel support.

In addition to containers, that would also provide a sensible solution
for a smarter fakeroot-style tool that lets a user construct filesystems
with slightly more complicated policies than root owns everything,
again without any help from host root other than here, have a pile of
subordinate UIDs.

I'd be happy to revisit kernel setusers() support if anyone would be
interested in saying yes, this is the solution we want.

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


Re: [systemd-devel] [PATCH 0/5] Enhancements to libabc template project

2014-12-25 Thread Josh Triplett
On Thu, Dec 25, 2014 at 10:20:14PM +0100, Kay Sievers wrote:
 On Sat, Dec 6, 2014 at 11:46 PM, Josh Triplett j...@joshtriplett.org wrote:
  I went to use libabc as the basis for a new library, and found a few issues;
  rather than just correcting them in my own library, I'd like to push the
  changes back into libabc.
 
  Josh Triplett (5):
Makefile.am: Don't add abc subdirectory to include path
Makefile.am: Don't define LIBEXECDIR
autogen.sh: set -e separately, rather than putting -e in the shebang line
m4/.gitignore: Remove stray blank line.
Remove FSF mailing address
 
 All five patches applied.

Thanks!

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


Re: [systemd-devel] libabc, sub-objects, and reference counting

2014-12-08 Thread Josh Triplett
On Mon, Dec 08, 2014 at 05:09:17PM +0100, David Herrmann wrote:
 On Sun, Dec 7, 2014 at 2:39 AM, Josh Triplett j...@joshtriplett.org wrote:
  The sample libabc includes functions to get a thing, as a sample
  sub-object of the overall library context.  Each thing has a reference
  to the parent library context, and a function to return that reference.
  Given that, shouldn't abc_thing_new_from_string call abc_ref, and
  abc_thing_unref call abc_unref?
 
 Sure! Sounds like an oversight in libabc.

I'll send in a patch.

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


[systemd-devel] [PATCH] libabc: Make things hold a reference to their context

2014-12-08 Thread Josh Triplett
The sample libabc includes functions to get a thing, as a sample
sub-object of the overall library context.  Each thing has a reference
to the parent library context, and a function to return that reference.
Given that, abc_thing_new_from_string should call abc_ref, and
abc_thing_unref should call abc_unref when freeing a thing.
---
 src/libabc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/src/libabc.c b/src/libabc.c
index d6ef0b4..21e434b 100644
--- a/src/libabc.c
+++ b/src/libabc.c
@@ -251,6 +251,7 @@ ABC_EXPORT struct abc_thing *abc_thing_unref(struct 
abc_thing *thing)
 if (thing-refcount  0)
 return NULL;
 dbg(thing-ctx, context %p released\n, thing);
+abc_unref(thing-ctx);
 free(thing);
 return NULL;
 }
@@ -269,7 +270,7 @@ ABC_EXPORT int abc_thing_new_from_string(struct abc_ctx 
*ctx, const char *string
 return -ENOMEM;
 
 t-refcount = 1;
-t-ctx = ctx;
+t-ctx = abc_ref(ctx);
 *thing = t;
 return 0;
 }
-- 
2.1.3

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


[systemd-devel] [PATCH 0/5] Enhancements to libabc template project

2014-12-06 Thread Josh Triplett
I went to use libabc as the basis for a new library, and found a few issues;
rather than just correcting them in my own library, I'd like to push the
changes back into libabc.

Josh Triplett (5):
  Makefile.am: Don't add abc subdirectory to include path
  Makefile.am: Don't define LIBEXECDIR
  autogen.sh: set -e separately, rather than putting -e in the shebang line
  m4/.gitignore: Remove stray blank line.
  Remove FSF mailing address

 Makefile.am  | 2 --
 autogen.sh   | 3 ++-
 m4/.gitignore| 1 -
 src/abc/libabc.h | 4 
 src/libabc-private.h | 4 
 src/libabc.c | 4 
 src/test-libabc.c| 4 
 7 files changed, 2 insertions(+), 20 deletions(-)

-- 
2.1.3

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


[systemd-devel] [PATCH 1/5] Makefile.am: Don't add abc subdirectory to include path

2014-12-06 Thread Josh Triplett
Source files, including those in the library itself, should include
abc/example.h, not example.h.
---
 Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 1ac18d0..aa53b51 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -7,7 +7,6 @@ AM_CPPFLAGS = \
-include $(top_builddir)/config.h \
-DSYSCONFDIR=\$(sysconfdir)\ \
-DLIBEXECDIR=\$(libexecdir)\ \
-   -I${top_srcdir}/src/abc \
-I${top_srcdir}/src
 
 AM_CFLAGS = ${my_CFLAGS} \
-- 
2.1.3

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


[systemd-devel] [PATCH 2/5] Makefile.am: Don't define LIBEXECDIR

2014-12-06 Thread Josh Triplett
As README points out, the library should not execute out-of-process
tools.  Thus, it should never need to know LIBEXECDIR.
---
 Makefile.am | 1 -
 1 file changed, 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index aa53b51..d7dcaed 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -6,7 +6,6 @@ AM_MAKEFLAGS = --no-print-directory
 AM_CPPFLAGS = \
-include $(top_builddir)/config.h \
-DSYSCONFDIR=\$(sysconfdir)\ \
-   -DLIBEXECDIR=\$(libexecdir)\ \
-I${top_srcdir}/src
 
 AM_CFLAGS = ${my_CFLAGS} \
-- 
2.1.3

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


[systemd-devel] [PATCH 3/5] autogen.sh: set -e separately, rather than putting -e in the shebang line

2014-12-06 Thread Josh Triplett
Otherwise, if someone uses sh autogen.sh, the -e will get ignored.
---
 autogen.sh | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/autogen.sh b/autogen.sh
index 0d60b0a..07afd85 100755
--- a/autogen.sh
+++ b/autogen.sh
@@ -1,4 +1,5 @@
-#!/bin/sh -e
+#!/bin/sh
+set -e
 
 if [ -f .git/hooks/pre-commit.sample -a ! -f .git/hooks/pre-commit ] ; then
 cp -p .git/hooks/pre-commit.sample .git/hooks/pre-commit  \
-- 
2.1.3

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


[systemd-devel] [PATCH 4/5] m4/.gitignore: Remove stray blank line.

2014-12-06 Thread Josh Triplett
---
 m4/.gitignore | 1 -
 1 file changed, 1 deletion(-)

diff --git a/m4/.gitignore b/m4/.gitignore
index 8bab51c..38066dd 100644
--- a/m4/.gitignore
+++ b/m4/.gitignore
@@ -3,4 +3,3 @@ ltoptions.m4
 ltsugar.m4
 ltversion.m4
 lt~obsolete.m4
-
-- 
2.1.3

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


[systemd-devel] [PATCH 5/5] Remove FSF mailing address

2014-12-06 Thread Josh Triplett
It has changed in the past, and these days, anyone can get a copy of the
LGPL via the web rather than by post.
---
 src/abc/libabc.h | 4 
 src/libabc-private.h | 4 
 src/libabc.c | 4 
 src/test-libabc.c| 4 
 4 files changed, 16 deletions(-)

diff --git a/src/abc/libabc.h b/src/abc/libabc.h
index 8924033..d33129b 100644
--- a/src/abc/libabc.h
+++ b/src/abc/libabc.h
@@ -12,10 +12,6 @@
   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 this library; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #ifndef _LIBABC_H_
diff --git a/src/libabc-private.h b/src/libabc-private.h
index a76f822..7c9ad93 100644
--- a/src/libabc-private.h
+++ b/src/libabc-private.h
@@ -12,10 +12,6 @@
   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 this library; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #ifndef _LIBABC_PRIVATE_H_
diff --git a/src/libabc.c b/src/libabc.c
index 23fdcd5..d6ef0b4 100644
--- a/src/libabc.c
+++ b/src/libabc.c
@@ -12,10 +12,6 @@
   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 this library; if not, write to the Free Software
-  Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA  02110-1301  USA
 */
 
 #include stdio.h
diff --git a/src/test-libabc.c b/src/test-libabc.c
index 6734944..9051966 100644
--- a/src/test-libabc.c
+++ b/src/test-libabc.c
@@ -12,10 +12,6 @@
 but WITHOUT ANY WARRANTY; without even the implied warranty of
 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 GNU General Public License for more details.
-
-You should have received a copy of the GNU General Public License along
-with this program; if not, write to the Free Software Foundation, Inc.,
-51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
 */
 
 #include stdio.h
-- 
2.1.3

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


[systemd-devel] libabc, sub-objects, and reference counting

2014-12-06 Thread Josh Triplett
The sample libabc includes functions to get a thing, as a sample
sub-object of the overall library context.  Each thing has a reference
to the parent library context, and a function to return that reference.
Given that, shouldn't abc_thing_new_from_string call abc_ref, and
abc_thing_unref call abc_unref?

In particular, consider a language binding for a language with garbage
collection, built-in reference counting, or some other mechanism to
avoid requiring explicit calls to _unref functions.  The creation of a
new abc context would call abc_new, and arrange to call abc_unref when
the program no longer needs that abc context.  Similarly, the creation
of a new thing would take an abc context, call abc_thing_new_from_string
(or some similar creation function), and arrange to call abc_thing_unref
when the program no longer needs that thing.  Code in such a language
might create an abc, immediately create a thing, use the thing, and let
all the now-unreferenced objects get destroyed.  If use the thing
references the thing but not the abc context, the language could decide
to call abc_unref immediately after creating the thing, then use the
thing, which would have a pointer to an invalid abc context.

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


[systemd-devel] [PATCH 01/10] man/logind.conf.xml: Make man logind.conf.d work too

2014-11-29 Thread Josh Triplett
---
 Makefile-man.am | 5 +
 man/logind.conf.xml | 1 +
 2 files changed, 6 insertions(+)

diff --git a/Makefile-man.am b/Makefile-man.am
index f817a05..906a968 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1110,8 +1110,13 @@ MANPAGES += \
man/logind.conf.5 \
man/systemd-logind.service.8
 MANPAGES_ALIAS += \
+   man/logind.conf.d.5 \
man/systemd-logind.8
+man/logind.conf.d.5: man/logind.conf.5
 man/systemd-logind.8: man/systemd-logind.service.8
+man/logind.conf.d.html: man/logind.conf.html
+   $(html-alias)
+
 man/systemd-logind.html: man/systemd-logind.service.html
$(html-alias)
 
diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index 0b35f51..ca7525f 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -44,6 +44,7 @@
 
 refnamediv
 refnamelogind.conf/refname
+refnamelogind.conf.d/refname
 refpurposeLogin manager configuration files/refpurpose
 /refnamediv
 
-- 
2.1.3

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


[systemd-devel] [PATCH 02/10] man: Factor out a common snippet for .d directories and precedence

2014-11-29 Thread Josh Triplett
Several manpages contain duplicate text describing a standard set of .d
configuration directories, with the usual sorting, precedence,
overrides, and so on.  Factor this common text out using XInclude before
proliferating it even further.
---
 Makefile-man.am|  1 +
 man/binfmt.d.xml   | 30 --
 man/logind.conf.xml| 27 +--
 man/modules-load.d.xml | 26 --
 man/standard-conf.xml  | 45 +
 man/sysctl.d.xml   | 33 -
 man/sysusers.d.xml | 27 ++-
 7 files changed, 69 insertions(+), 120 deletions(-)
 create mode 100644 man/standard-conf.xml

diff --git a/Makefile-man.am b/Makefile-man.am
index 906a968..c24606a 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1638,6 +1638,7 @@ EXTRA_DIST += \
man/sd_uid_get_state.xml \
man/sd_watchdog_enabled.xml \
man/shutdown.xml \
+   man/standard-conf.xml \
man/standard-options.xml \
man/sysctl.d.xml \
man/systemctl.xml \
diff --git a/man/binfmt.d.xml b/man/binfmt.d.xml
index 2270166..55a3df0 100644
--- a/man/binfmt.d.xml
+++ b/man/binfmt.d.xml
@@ -19,7 +19,8 @@
   You should have received a copy of the GNU Lesser General Public License
   along with systemd; If not, see http://www.gnu.org/licenses/.
 --
-refentry id=binfmt.d conditional='ENABLE_BINFMT'
+refentry id=binfmt.d conditional='ENABLE_BINFMT'
+  xmlns:xi=http://www.w3.org/2001/XInclude;
 
 refentryinfo
 titlebinfmt.d/title
@@ -74,33 +75,10 @@
 paraEmpty lines and lines beginning with ; and # are
 ignored. Note that this means you may not use ; and #
 as delimiter in binary format rules./para
-
-paraEach configuration file shall be named in the
-style of 
filenamereplaceableprogram/replaceable.conf/filename.
-Files in filename/etc//filename override files
-with the same name in filename/usr/lib//filename
-and filename/run//filename. Files in
-filename/run//filename override files with the
-same name in filename/usr/lib//filename. Packages
-should install their configuration files in
-filename/usr/lib//filename, files in
-filename/etc//filename are reserved for the local
-administrator, who may use this logic to override the
-configuration files installed from vendor
-packages. All files are sorted by their filename in
-lexicographic order, regardless of which of the
-directories they reside in. If multiple files specify
-the same binary type name, the entry in the file with
-the lexicographically latest name will be applied./para
-
-paraIf the administrator wants to disable a
-configuration file supplied by the vendor, the
-recommended way is to place a symlink to
-filename/dev/null/filename in
-filename/etc/binfmt.d//filename bearing the
-same filename./para
 /refsect1
 
+xi:include href=standard-conf.xml xpointer=confd /
+
 refsect1
 titleExample/title
 example
diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index ca7525f..e927cf4 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 --
 
-refentry id=logind.conf conditional='ENABLE_LOGIND'
+refentry id=logind.conf conditional='ENABLE_LOGIND'
+  xmlns:xi=http://www.w3.org/2001/XInclude;
 refentryinfo
 titlelogind.conf/title
 productnamesystemd/productname
@@ -59,29 +60,11 @@
 titleDescription/title
 
 paraThese files configure various parameters of the systemd 
login manager, 
citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para
-
-paraEach configuration file shall be named in the style of
-filenamereplaceablefilename/replaceable.conf/filename.
-Files in filename/etc//filename override files with the
-same name in filename/usr/lib//filename and
-filename/run//filename.  Files in
-filename/run//filename override files with the same name in
-filename/usr/lib//filename. Packages should install their
-configuration files in filename/usr/lib//filename. Files in
-filename/etc//filename are reserved for the local
-administrator, who may use this logic to override the
-configuration files installed by vendor packages. All
-  

[systemd-devel] [PATCH 03/10] core: Support system.conf.d and user.conf.d directories in the usual search paths

2014-11-29 Thread Josh Triplett
---
 Makefile-man.am | 12 +++-
 man/systemd-system.conf.xml | 25 -
 man/systemd.xml | 10 ++
 src/core/main.c |  9 -
 src/core/system.conf|  3 +++
 src/core/user.conf  |  3 +++
 6 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index c24606a..f025be0 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -195,6 +195,7 @@ MANPAGES_ALIAS += \
man/sd_journal_wait.3 \
man/sd_machine_get_ifindices.3 \
man/sd_notifyf.3 \
+   man/system.conf.d.5 \
man/systemd-ask-password-console.path.8 \
man/systemd-ask-password-wall.path.8 \
man/systemd-ask-password-wall.service.8 \
@@ -227,7 +228,8 @@ MANPAGES_ALIAS += \
man/systemd-udevd-kernel.socket.8 \
man/systemd-udevd.8 \
man/systemd-update-done.8 \
-   man/systemd-user.conf.5
+   man/systemd-user.conf.5 \
+   man/user.conf.d.5
 man/SD_ALERT.3: man/sd-daemon.3
 man/SD_CRIT.3: man/sd-daemon.3
 man/SD_DEBUG.3: man/sd-daemon.3
@@ -301,6 +303,7 @@ man/sd_journal_test_cursor.3: man/sd_journal_get_cursor.3
 man/sd_journal_wait.3: man/sd_journal_get_fd.3
 man/sd_machine_get_ifindices.3: man/sd_machine_get_class.3
 man/sd_notifyf.3: man/sd_notify.3
+man/system.conf.d.5: man/systemd-system.conf.5
 man/systemd-ask-password-console.path.8: 
man/systemd-ask-password-console.service.8
 man/systemd-ask-password-wall.path.8: 
man/systemd-ask-password-console.service.8
 man/systemd-ask-password-wall.service.8: 
man/systemd-ask-password-console.service.8
@@ -334,6 +337,7 @@ man/systemd-udevd-kernel.socket.8: 
man/systemd-udevd.service.8
 man/systemd-udevd.8: man/systemd-udevd.service.8
 man/systemd-update-done.8: man/systemd-update-done.service.8
 man/systemd-user.conf.5: man/systemd-system.conf.5
+man/user.conf.d.5: man/systemd-system.conf.5
 man/SD_ALERT.html: man/sd-daemon.html
$(html-alias)
 
@@ -553,6 +557,9 @@ man/sd_machine_get_ifindices.html: 
man/sd_machine_get_class.html
 man/sd_notifyf.html: man/sd_notify.html
$(html-alias)
 
+man/system.conf.d.html: man/systemd-system.conf.html
+   $(html-alias)
+
 man/systemd-ask-password-console.path.html: 
man/systemd-ask-password-console.service.html
$(html-alias)
 
@@ -652,6 +659,9 @@ man/systemd-update-done.html: 
man/systemd-update-done.service.html
 man/systemd-user.conf.html: man/systemd-system.conf.html
$(html-alias)
 
+man/user.conf.d.html: man/systemd-system.conf.html
+   $(html-alias)
+
 
 if ENABLE_BACKLIGHT
 MANPAGES += \
diff --git a/man/systemd-system.conf.xml b/man/systemd-system.conf.xml
index 284516d..dfb180c 100644
--- a/man/systemd-system.conf.xml
+++ b/man/systemd-system.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 --
 
-refentry id=systemd-system.conf
+refentry id=systemd-system.conf
+  xmlns:xi=http://www.w3.org/2001/XInclude;
 refentryinfo
 titlesystemd-system.conf/title
 productnamesystemd/productname
@@ -44,25 +45,39 @@
 
 refnamediv
 refnamesystemd-system.conf/refname
+refnamesystem.conf.d/refname
 refnamesystemd-user.conf/refname
-refpurposeSystem and session service manager configuration 
file/refpurpose
+refnameuser.conf.d/refname
+refpurposeSystem and session service manager configuration 
files/refpurpose
 /refnamediv
 
 refsynopsisdiv
 parafilename/etc/systemd/system.conf/filename/para
+
parafilename/etc/systemd/system.conf.d/*.conf/filename/para
+
parafilename/run/systemd/system.conf.d/*.conf/filename/para
+
parafilename/usr/lib/systemd/system.conf.d/*.conf/filename/para
 parafilename/etc/systemd/user.conf/filename/para
+
parafilename/etc/systemd/user.conf.d/*.conf/filename/para
+
parafilename/run/systemd/user.conf.d/*.conf/filename/para
+
parafilename/usr/lib/systemd/user.conf.d/*.conf/filename/para
 /refsynopsisdiv
 
 refsect1
 titleDescription/title
 
-paraWhen run as system instance systemd reads the
-configuration file filenamesystem.conf/filename,
-otherwise filenameuser.conf/filename. These
+paraWhen run as a system instance, systemd interprets the
+configuration file filenamesystem.conf/filename and the
+files in filenamesystem.conf.d/filename directories; when
+run as a user instance, systemd interprets the configuration
+file filenameuser.conf/filename and the files in
+filenameuser.conf.d/filename directories. These
 configuration files contain a few settings controlling
 basic 

[systemd-devel] [PATCH 05/10] systemd-sleep: Support sleep.conf.d directories in the usual search paths

2014-11-29 Thread Josh Triplett
---
 Makefile-man.am |  5 +
 man/systemd-sleep.conf.xml  | 15 ---
 man/systemd-suspend.service.xml |  3 ++-
 src/shared/sleep-config.c   |  7 ---
 4 files changed, 23 insertions(+), 7 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index e0c15fa..2a0d73e 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -196,6 +196,7 @@ MANPAGES_ALIAS += \
man/sd_journal_wait.3 \
man/sd_machine_get_ifindices.3 \
man/sd_notifyf.3 \
+   man/sleep.conf.d.5 \
man/system.conf.d.5 \
man/systemd-ask-password-console.path.8 \
man/systemd-ask-password-wall.path.8 \
@@ -305,6 +306,7 @@ man/sd_journal_test_cursor.3: man/sd_journal_get_cursor.3
 man/sd_journal_wait.3: man/sd_journal_get_fd.3
 man/sd_machine_get_ifindices.3: man/sd_machine_get_class.3
 man/sd_notifyf.3: man/sd_notify.3
+man/sleep.conf.d.5: man/systemd-sleep.conf.5
 man/system.conf.d.5: man/systemd-system.conf.5
 man/systemd-ask-password-console.path.8: 
man/systemd-ask-password-console.service.8
 man/systemd-ask-password-wall.path.8: 
man/systemd-ask-password-console.service.8
@@ -562,6 +564,9 @@ man/sd_machine_get_ifindices.html: 
man/sd_machine_get_class.html
 man/sd_notifyf.html: man/sd_notify.html
$(html-alias)
 
+man/sleep.conf.d.html: man/systemd-sleep.conf.html
+   $(html-alias)
+
 man/system.conf.d.html: man/systemd-system.conf.html
$(html-alias)
 
diff --git a/man/systemd-sleep.conf.xml b/man/systemd-sleep.conf.xml
index d724960..99e0e33 100644
--- a/man/systemd-sleep.conf.xml
+++ b/man/systemd-sleep.conf.xml
@@ -22,7 +22,8 @@ You should have received a copy of the GNU Lesser General 
Public License
 along with systemd; If not, see http://www.gnu.org/licenses/.
 --
 
-refentry id=systemd-sleep.conf
+refentry id=systemd-sleep.conf
+  xmlns:xi=http://www.w3.org/2001/XInclude;
   refentryinfo
 titlesystemd-sleep.conf/title
 productnamesystemd/productname
@@ -44,11 +45,15 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
 
   refnamediv
 refnamesystemd-sleep.conf/refname
+refnamesleep.conf.d/refname
 refpurposeSuspend and hibernation configuration file/refpurpose
   /refnamediv
 
   refsynopsisdiv
 parafilename/etc/systemd/sleep.conf/filename/para
+parafilename/etc/systemd/sleep.conf.d/*.conf/filename/para
+parafilename/run/systemd/sleep.conf.d/*.conf/filename/para
+parafilename/usr/lib/systemd/sleep.conf.d/*.conf/filename/para
   /refsynopsisdiv
 
   refsect1
@@ -98,7 +103,7 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
   /varlistentry
 /variablelist
 
-paraSettings in this file determine what strings
+paraSettings in these files determine what strings
 will be written to
 filename/sys/power/disk/filename and
 filename/sys/power/state/filename by
@@ -108,12 +113,16 @@ along with systemd; If not, see 
http://www.gnu.org/licenses/.
 attempts to suspend or hibernate the machine./para
   /refsect1
 
+  xi:include href=standard-conf.xml xpointer=confd /
+  xi:include href=standard-conf.xml xpointer=conf /
+
   refsect1
 titleOptions/title
 
 paraThe following options can be configured in the
 literal[Sleep]/literal section of
-filename/etc/systemd/sleep.conf/filename:/para
+filename/etc/systemd/sleep.conf/filename or a
+filenamesleep.conf.d/filename file:/para
 
 variablelist class='systemd-directives'
   varlistentry
diff --git a/man/systemd-suspend.service.xml b/man/systemd-suspend.service.xml
index 9a3ae1b..375c255 100644
--- a/man/systemd-suspend.service.xml
+++ b/man/systemd-suspend.service.xml
@@ -114,7 +114,8 @@
 filename/sys/power/state/filename, to trigger the
 actual system suspend. What exactly is written
 where can be configured in the literal[Sleep]/literal
-section of filename/etc/systemd/sleep.conf/filename.
+section of filename/etc/systemd/sleep.conf/filename or a
+filenamesleep.conf.d/filename file.
 See 
citerefentryrefentrytitlesystemd-sleep.conf/refentrytitlemanvolnum5/manvolnum/citerefentry.
 /para
 /refsect1
diff --git a/src/shared/sleep-config.c b/src/shared/sleep-config.c
index 0fd307d..ae14c6b 100644
--- a/src/shared/sleep-config.c
+++ b/src/shared/sleep-config.c
@@ -48,9 +48,10 @@ int parse_sleep_config(const char *verb, char ***_modes, 
char ***_states) {
 {}
 };
 
-config_parse(NULL, PKGSYSCONFDIR /sleep.conf, NULL,
- Sleep\0,
- config_item_table_lookup, items, false, false, true, 
NULL);
+config_parse_many(PKGSYSCONFDIR /sleep.conf,
+  CONF_DIRS_NULSTR(systemd/sleep.conf),
+  Sleep\0, config_item_table_lookup, items,
+  false, NULL);
 
 if (streq(verb, suspend)) {

[systemd-devel] [PATCH 07/10] coredump: Support coredump.conf.d directories in the usual search paths

2014-11-29 Thread Josh Triplett
---
 Makefile-man.am   |  6 --
 man/coredump.conf.xml | 14 +++---
 src/journal/coredump.c|  9 +
 src/journal/coredump.conf |  3 +++
 4 files changed, 23 insertions(+), 9 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 593dc40..01d3408 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -714,8 +714,10 @@ MANPAGES += \
man/coredumpctl.1 \
man/systemd-coredump.8
 MANPAGES_ALIAS += \
-   #
-
+   man/coredump.conf.d.5
+man/coredump.conf.d.5: man/coredump.conf.5
+man/coredump.conf.d.html: man/coredump.conf.html
+   $(html-alias)
 
 endif
 
diff --git a/man/coredump.conf.xml b/man/coredump.conf.xml
index 5eb5c5f..37916f0 100644
--- a/man/coredump.conf.xml
+++ b/man/coredump.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 --
 
-refentry id=coredump.conf conditional=ENABLE_COREDUMP
+refentry id=coredump.conf conditional=ENABLE_COREDUMP
+  xmlns:xi=http://www.w3.org/2001/XInclude;
   refentryinfo
 titlecoredump.conf/title
 productnamesystemd/productname
@@ -44,20 +45,27 @@
 
   refnamediv
 refnamecoredump.conf/refname
-refpurposeCoredump storage configuration file/refpurpose
+refnamecoredump.conf.d/refname
+refpurposeCoredump storage configuration files/refpurpose
   /refnamediv
 
   refsynopsisdiv
 parafilename/etc/systemd/coredump.conf/filename/para
+parafilename/etc/systemd/coredump.conf.d/*.conf/filename/para
+parafilename/run/systemd/coredump.conf.d/*.conf/filename/para
+parafilename/usr/lib/systemd/coredump.conf.d/*.conf/filename/para
   /refsynopsisdiv
 
   refsect1
 titleDescription/title
 
-paraThis file configures the behaviour of 
commandsystemd-coredump/command,
+paraThese files configure the behaviour of 
commandsystemd-coredump/command,
 a handler for core dumps invoked by the kernel./para
   /refsect1
 
+  xi:include href=standard-conf.xml xpointer=confd /
+  xi:include href=standard-conf.xml xpointer=conf /
+
   refsect1
 titleOptions/title
 
diff --git a/src/journal/coredump.c b/src/journal/coredump.c
index d889ed1..be45a68 100644
--- a/src/journal/coredump.c
+++ b/src/journal/coredump.c
@@ -120,10 +120,11 @@ static int parse_config(void) {
 {}
 };
 
-return config_parse(NULL, /etc/systemd/coredump.conf, NULL,
-Coredump\0,
-config_item_table_lookup, items,
-false, false, true, NULL);
+return config_parse_many(/etc/systemd/coredump.conf,
+ CONF_DIRS_NULSTR(systemd/coredump.conf),
+ Coredump\0,
+ config_item_table_lookup, items,
+ false, NULL);
 }
 
 static int fix_acl(int fd, uid_t uid) {
diff --git a/src/journal/coredump.conf b/src/journal/coredump.conf
index 0cc328f..0fe9fe8 100644
--- a/src/journal/coredump.conf
+++ b/src/journal/coredump.conf
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/coredump.conf.d/*.conf.
+#
 # See coredump.conf(5) for details
 
 [Coredump]
-- 
2.1.3

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


[systemd-devel] [PATCH 09/10] timesyncd: Support timesyncd.conf.d directories in the usual search paths

2014-11-29 Thread Josh Triplett
---
 Makefile-man.am|  7 ++-
 man/timesyncd.conf.xml | 17 +++--
 src/timesync/timesyncd-conf.c  |  9 +
 src/timesync/timesyncd.conf.in |  3 +++
 4 files changed, 25 insertions(+), 11 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 36e0ebb..e3c43b2 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1244,11 +1244,16 @@ MANPAGES += \
man/systemd-timesyncd.service.8 \
man/timesyncd.conf.5
 MANPAGES_ALIAS += \
-   man/systemd-timesyncd.8
+   man/systemd-timesyncd.8 \
+   man/timesyncd.conf.d.5
 man/systemd-timesyncd.8: man/systemd-timesyncd.service.8
+man/timesyncd.conf.d.5: man/timesyncd.conf.5
 man/systemd-timesyncd.html: man/systemd-timesyncd.service.html
$(html-alias)
 
+man/timesyncd.conf.d.html: man/timesyncd.conf.html
+   $(html-alias)
+
 endif
 
 if ENABLE_VCONSOLE
diff --git a/man/timesyncd.conf.xml b/man/timesyncd.conf.xml
index aeb7182..1a56c2c 100644
--- a/man/timesyncd.conf.xml
+++ b/man/timesyncd.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 --
 
-refentry id=timesyncd.conf conditional='ENABLE_TIMESYNCD'
+refentry id=timesyncd.conf conditional='ENABLE_TIMESYNCD'
+  xmlns:xi=http://www.w3.org/2001/XInclude;
 refentryinfo
 titletimesyncd.conf/title
 productnamesystemd/productname
@@ -44,24 +45,28 @@
 
 refnamediv
 refnametimesyncd.conf/refname
-refpurposeNetwork Time Synchronization configuration 
file/refpurpose
+refnametimesyncd.conf.d/refname
+refpurposeNetwork Time Synchronization configuration 
files/refpurpose
 /refnamediv
 
 refsynopsisdiv
 parafilename/etc/systemd/timesyncd.conf/filename/para
+
parafilename/etc/systemd/timesyncd.conf.d/*.conf/filename/para
+
parafilename/run/systemd/timesyncd.conf.d/*.conf/filename/para
+
parafilename/usr/lib/systemd/timesyncd.conf.d/*.conf/filename/para
 /refsynopsisdiv
 
 refsect1
 titleDescription/title
 
-paraWhen starting, systemd-timesyncd will read the
-configuration file
-filenametimesyncd.conf/filename.  This
-configuration file controls NTP network time
+paraThese configuration files control NTP network time
 synchronization./para
 
 /refsect1
 
+xi:include href=standard-conf.xml xpointer=confd /
+xi:include href=standard-conf.xml xpointer=conf /
+
 refsect1
 titleOptions/title
 
diff --git a/src/timesync/timesyncd-conf.c b/src/timesync/timesyncd-conf.c
index 4c2dcdb..be1f4bb 100644
--- a/src/timesync/timesyncd-conf.c
+++ b/src/timesync/timesyncd-conf.c
@@ -97,8 +97,9 @@ int config_parse_servers(
 int manager_parse_config_file(Manager *m) {
 assert(m);
 
-return config_parse(NULL, /etc/systemd/timesyncd.conf, NULL,
-Time\0,
-config_item_perf_lookup, timesyncd_gperf_lookup,
-false, false, true, m);
+return config_parse_many(/etc/systemd/timesyncd.conf,
+ CONF_DIRS_NULSTR(systemd/timesyncd.conf),
+ Time\0,
+ config_item_perf_lookup, 
timesyncd_gperf_lookup,
+ false, m);
 }
diff --git a/src/timesync/timesyncd.conf.in b/src/timesync/timesyncd.conf.in
index 674a51d..fc3c6c4 100644
--- a/src/timesync/timesyncd.conf.in
+++ b/src/timesync/timesyncd.conf.in
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/timesyncd.conf.d/*.conf.
+#
 # See timesyncd.conf(5) for details
 
 [Time]
-- 
2.1.3

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


[systemd-devel] [PATCH 08/10] resolved: Support resolved.conf.d directories in the usual search paths

2014-11-29 Thread Josh Triplett
---
 Makefile-man.am  |  5 +
 man/resolved.conf.xml| 16 +++-
 src/resolve/resolved-conf.c  |  9 +
 src/resolve/resolved.conf.in |  3 +++
 4 files changed, 24 insertions(+), 9 deletions(-)

diff --git a/Makefile-man.am b/Makefile-man.am
index 01d3408..36e0ebb 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1204,8 +1204,13 @@ MANPAGES += \
man/resolved.conf.5 \
man/systemd-resolved.service.8
 MANPAGES_ALIAS += \
+   man/resolved.conf.d.5 \
man/systemd-resolved.8
+man/resolved.conf.d.5: man/resolved.conf.5
 man/systemd-resolved.8: man/systemd-resolved.service.8
+man/resolved.conf.d.html: man/resolved.conf.html
+   $(html-alias)
+
 man/systemd-resolved.html: man/systemd-resolved.service.html
$(html-alias)
 
diff --git a/man/resolved.conf.xml b/man/resolved.conf.xml
index c582368..36013a5 100644
--- a/man/resolved.conf.xml
+++ b/man/resolved.conf.xml
@@ -22,7 +22,8 @@
   along with systemd; If not, see http://www.gnu.org/licenses/.
 --
 
-refentry id=resolved.conf conditional='ENABLE_RESOLVED'
+refentry id=resolved.conf conditional='ENABLE_RESOLVED'
+  xmlns:xi=http://www.w3.org/2001/XInclude;
 refentryinfo
 titleresolved.conf/title
 productnamesystemd/productname
@@ -44,23 +45,28 @@
 
 refnamediv
 refnameresolved.conf/refname
-refpurposeNetwork Name Resolution configuration 
file/refpurpose
+refnameresolved.conf.d/refname
+refpurposeNetwork Name Resolution configuration 
files/refpurpose
 /refnamediv
 
 refsynopsisdiv
 parafilename/etc/systemd/resolved.conf/filename/para
+
parafilename/etc/systemd/resolved.conf.d/*.conf/filename/para
+
parafilename/run/systemd/resolved.conf.d/*.conf/filename/para
+
parafilename/usr/lib/systemd/resolved.conf.d/*.conf/filename/para
 /refsynopsisdiv
 
 refsect1
 titleDescription/title
 
-paraWhen starting, systemd-resolved will read the
-configuration file filenameresolved.conf/filename.
-This configuration file controls local DNS and LLMNR
+paraThese configuration files control local DNS and LLMNR
 name resolving./para
 
 /refsect1
 
+xi:include href=standard-conf.xml xpointer=confd /
+xi:include href=standard-conf.xml xpointer=conf /
+
 refsect1
 titleOptions/title
 
diff --git a/src/resolve/resolved-conf.c b/src/resolve/resolved-conf.c
index 63e87f8..81b9d34 100644
--- a/src/resolve/resolved-conf.c
+++ b/src/resolve/resolved-conf.c
@@ -147,8 +147,9 @@ int config_parse_support(
 int manager_parse_config_file(Manager *m) {
 assert(m);
 
-return config_parse(NULL, /etc/systemd/resolved.conf, NULL,
-Resolve\0,
-config_item_perf_lookup, resolved_gperf_lookup,
-false, false, true, m);
+return config_parse_many(/etc/systemd/resolved.conf,
+ CONF_DIRS_NULSTR(systemd/resolved.conf),
+ Resolve\0,
+ config_item_perf_lookup, 
resolved_gperf_lookup,
+ false, m);
 }
diff --git a/src/resolve/resolved.conf.in b/src/resolve/resolved.conf.in
index c8263d6..e5a19ee 100644
--- a/src/resolve/resolved.conf.in
+++ b/src/resolve/resolved.conf.in
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the directives in this file by creating files in
+# /etc/systemd/resolved.conf.d/*.conf.
+#
 # See resolved.conf(5) for details
 
 [Resolve]
-- 
2.1.3

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


[systemd-devel] [PATCH 10/10] journald-remote: Support journal-remote.conf.d and journal-upload.conf.d directories in the usual search paths

2014-11-29 Thread Josh Triplett
---
 src/journal-remote/journal-remote.c | 8 
 src/journal-remote/journal-upload.c | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/src/journal-remote/journal-remote.c 
b/src/journal-remote/journal-remote.c
index a5d40cb..6ec5ad2 100644
--- a/src/journal-remote/journal-remote.c
+++ b/src/journal-remote/journal-remote.c
@@ -1131,10 +1131,10 @@ static int parse_config(void) {
 { Remote,  TrustedCertificateFile, config_parse_path,  
   0, arg_trust  },
 {}};
 
-return config_parse(NULL, PKGSYSCONFDIR /journal-remote.conf, NULL,
-Remote\0,
-config_item_table_lookup, items,
-false, false, true, NULL);
+return config_parse_many(PKGSYSCONFDIR /journal-remote.conf,
+ 
CONF_DIRS_NULSTR(systemd/journal-remote.conf),
+ Remote\0, config_item_table_lookup, items,
+ false, NULL);
 }
 
 static void help(void) {
diff --git a/src/journal-remote/journal-upload.c 
b/src/journal-remote/journal-upload.c
index 8be0f93..62853b6 100644
--- a/src/journal-remote/journal-upload.c
+++ b/src/journal-remote/journal-upload.c
@@ -532,10 +532,10 @@ static int parse_config(void) {
 { Upload,  TrustedCertificateFile, config_parse_path,   0, 
arg_trust  },
 {}};
 
-return config_parse(NULL, PKGSYSCONFDIR /journal-upload.conf, NULL,
-Upload\0,
-config_item_table_lookup, items,
-false, false, true, NULL);
+return config_parse_many(PKGSYSCONFDIR /journal-upload.conf,
+ 
CONF_DIRS_NULSTR(systemd/journal-upload.conf),
+ Upload\0, config_item_table_lookup, items,
+ false, NULL);
 }
 
 static void help(void) {
-- 
2.1.3

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


[systemd-devel] [PATCH] NEWS: Document new .conf.d configuration directories

2014-11-29 Thread Josh Triplett
Also provide guidance to distributions, to make sure they don't start
dropping files in the configuration directories in /etc/.
---
 NEWS | 13 +
 1 file changed, 13 insertions(+)

diff --git a/NEWS b/NEWS
index 0d3ab2b..8fc0720 100644
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,19 @@ CHANGES WITH 218:
   will spew out warnings if the compilation fails. This
   requires libxkbcommon to be installed.
 
+* All systemd programs that read standalone configuration files
+  in /etc now also support a corresponding series of
+  .conf.d configuration directories in /etc/, /run/,
+  /usr/local/lib/, /usr/lib/, and (if configured with
+  --enable-split-usr) /lib/.  In particular, the following
+  configuration files now have corresponding configuration
+  directories: system.conf user.conf, logind.conf,
+  journald.conf, sleep.conf, bootchart.conf, coredump.conf,
+  resolved.conf, timesyncd.conf, journal-remote.conf, and
+  journal-upload.conf.  Note that distributions should use the
+  configuration directories in /usr/lib/; the directories in
+  /etc/ are reserved for the system administrator.
+
 CHANGES WITH 217:
 
 * journalctl gained the new options -t/--identifier= to match
-- 
2.1.3

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


Re: [systemd-devel] [PATCH] NEWS: Document new .conf.d configuration directories

2014-11-29 Thread Josh Triplett
On Sun, Nov 30, 2014 at 12:23:07AM +0100, Lennart Poettering wrote:
 Applied! Thanks!

Thanks for the fast response!

Out of curiosity, what's the process/criteria to apply for commit
access?  (I have an fd.o account already.)  I didn't see any documented
on the systemd homepage.

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


Re: [systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths

2014-11-26 Thread Josh Triplett
On Thu, Nov 27, 2014 at 01:45:43AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Wed, Nov 26, 2014 at 01:24:53PM +0100, Gergely Nagy wrote:
   Josh == Josh Triplett j...@joshtriplett.org writes:
  
  Josh This makes it possible to drop in logind configuration snippets 
  from a
  Josh package or other configuration management mechanism.
  [...]
  Josh If this approach looks sensible, I'll send further patches for 
  various
  Josh other tools with configuration files, such as journald and
  Josh timesyncd;
  
  I recently hit an issue where a journald.conf.d/ would have been
  incredibly useful. Any news on this patchset, by any chance?
 
 Applied. Sorry for the delay.

Thanks!  And no problem.

 It would be great if you could prepare patches for the other deamons.

Will do.

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


Re: [systemd-devel] statelessy system

2014-11-03 Thread Josh Triplett
Zbigniew Jędrzejewski-Szmek wrote:
 On Mon, Nov 03, 2014 at 12:24:42PM +0100, Lennart Poettering wrote:
  Would be happy to take a patch that makes those cases check for a
  config file in /usr/lib as fallback though, to cover all bases.
 Didn't we have a patch to support .d directories floated on the ml?
 Can't seem to find it at the moment.

Yes, I posted one for logind.conf.d; see message IDs
20141029120251.GA30088@thin ([PATCH 1/2] Introduce CONF_DIRS_NULSTR
helper to define standard conf dirs) and 20141029121045.GA5365@thin
([PATCH 2/2] logind: Support logind.conf.d directories in the usual
search paths).
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024676.html
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024677.html

I'd love to see those applied.  If those work for you, I can produce
additional patches for the other config files in /etc/systemd.

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


[systemd-devel] [PATCH 1/2] Introduce CONF_DIRS_NULSTR helper to define standard conf dirs

2014-10-29 Thread Josh Triplett
Several different systemd tools define a nulstr containing a standard
series of configuration file directories, in /etc, /run, /usr/local/lib,
/usr/lib, and (#ifdef HAVE_SPLIT_USR) /lib.  Factor that logic out into
a new helper macro, CONF_DIRS_NULSTR.
---

Realized when defining the Nth instance of this for logind.conf.d that
it really ought to have a common definition.

 src/binfmt/binfmt.c | 10 +-
 src/modules-load/modules-load.c | 10 +-
 src/shared/macro.h  | 15 +++
 src/sysctl/sysctl.c | 10 +-
 src/sysusers/sysusers.c | 10 +-
 src/tmpfiles/tmpfiles.c | 10 +-
 6 files changed, 20 insertions(+), 45 deletions(-)

diff --git a/src/binfmt/binfmt.c b/src/binfmt/binfmt.c
index c1c1522..0a15faf 100644
--- a/src/binfmt/binfmt.c
+++ b/src/binfmt/binfmt.c
@@ -36,15 +36,7 @@
 #include fileio.h
 #include build.h
 
-static const char conf_file_dirs[] =
-/etc/binfmt.d\0
-/run/binfmt.d\0
-/usr/local/lib/binfmt.d\0
-/usr/lib/binfmt.d\0
-#ifdef HAVE_SPLIT_USR
-/lib/binfmt.d\0
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR(binfmt);
 
 static int delete_rule(const char *rule) {
 _cleanup_free_ char *x = NULL, *fn = NULL;
diff --git a/src/modules-load/modules-load.c b/src/modules-load/modules-load.c
index c77b092..84ae337 100644
--- a/src/modules-load/modules-load.c
+++ b/src/modules-load/modules-load.c
@@ -38,15 +38,7 @@
 
 static char **arg_proc_cmdline_modules = NULL;
 
-static const char conf_file_dirs[] =
-/etc/modules-load.d\0
-/run/modules-load.d\0
-/usr/local/lib/modules-load.d\0
-/usr/lib/modules-load.d\0
-#ifdef HAVE_SPLIT_USR
-/lib/modules-load.d\0
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR(modules-load);
 
 static void systemd_kmod_log(void *data, int priority, const char *file, int 
line,
  const char *fn, const char *format, va_list args) 
{
diff --git a/src/shared/macro.h b/src/shared/macro.h
index 9ee332c..6d4712c 100644
--- a/src/shared/macro.h
+++ b/src/shared/macro.h
@@ -384,6 +384,21 @@ do {   
 \
 _found; \
 })
 
+/* Return a nulstr for a standard cascade of configuration directories,
+ * suitable to pass to conf_files_list_nulstr or config_parse_many. */
+#define CONF_DIRS_NULSTR(n) \
+/etc/ n .d\0 \
+/run/ n .d\0 \
+/usr/local/lib/ n .d\0 \
+/usr/lib/ n .d\0 \
+CONF_DIR_SPLIT_USR(n)
+
+#ifdef HAVE_SPLIT_USR
+#define CONF_DIR_SPLIT_USR(n) /lib/ n .d\0
+#else
+#define CONF_DIR_SPLIT_USR(n)
+#endif
+
 /* Define C11 thread_local attribute even on older gcc compiler
  * version */
 #ifndef thread_local
diff --git a/src/sysctl/sysctl.c b/src/sysctl/sysctl.c
index 809e59b..edebe50 100644
--- a/src/sysctl/sysctl.c
+++ b/src/sysctl/sysctl.c
@@ -38,15 +38,7 @@
 
 static char **arg_prefixes = NULL;
 
-static const char conf_file_dirs[] =
-/etc/sysctl.d\0
-/run/sysctl.d\0
-/usr/local/lib/sysctl.d\0
-/usr/lib/sysctl.d\0
-#ifdef HAVE_SPLIT_USR
-/lib/sysctl.d\0
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR(sysctl);
 
 static char* normalize_sysctl(char *s) {
 char *n;
diff --git a/src/sysusers/sysusers.c b/src/sysusers/sysusers.c
index 9b9be96..df585c1 100644
--- a/src/sysusers/sysusers.c
+++ b/src/sysusers/sysusers.c
@@ -67,15 +67,7 @@ typedef struct Item {
 
 static char *arg_root = NULL;
 
-static const char conf_file_dirs[] =
-/etc/sysusers.d\0
-/run/sysusers.d\0
-/usr/local/lib/sysusers.d\0
-/usr/lib/sysusers.d\0
-#ifdef HAVE_SPLIT_USR
-/lib/sysusers.d\0
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR(sysusers);
 
 static Hashmap *users = NULL, *groups = NULL;
 static Hashmap *todo_uids = NULL, *todo_gids = NULL;
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 1e4675f..23fd6ca 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -117,15 +117,7 @@ static char **arg_include_prefixes = NULL;
 static char **arg_exclude_prefixes = NULL;
 static char *arg_root = NULL;
 
-static const char conf_file_dirs[] =
-/etc/tmpfiles.d\0
-/run/tmpfiles.d\0
-/usr/local/lib/tmpfiles.d\0
-/usr/lib/tmpfiles.d\0
-#ifdef HAVE_SPLIT_USR
-/lib/tmpfiles.d\0
-#endif
-;
+static const char conf_file_dirs[] = CONF_DIRS_NULSTR(tmpfiles);
 
 #define MAX_DEPTH 256
 
-- 
2.1.1

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


[systemd-devel] [PATCH 2/2] logind: Support logind.conf.d directories in the usual search paths

2014-10-29 Thread Josh Triplett
This makes it possible to drop in logind configuration snippets from a
package or other configuration management mechanism.

Add documentation to the header of /etc/logind.conf pointing the user at
/etc/logind.conf.d/*.conf.

Introduce a new helper, conf_parse_many, to parse configuration files in
a search path.
---

Revised to keep /etc/systemd/logind.conf around, and to prefer the
entire series of conf.d directories over /etc/systemd/logind.conf, as
suggested by Lennart at
http://lists.freedesktop.org/archives/systemd-devel/2014-October/024122.html

If this approach looks sensible, I'll send further patches for various
other tools with configuration files, such as journald and timesyncd;
however, I wanted to establish the pattern and the common helper
function first.  With the config_parse_many helper, further changes like
this should only require a one-line change to the actual tools, plus
documentation.

 man/logind.conf.xml  | 29 ++---
 src/login/logind.c   |  9 +
 src/login/logind.conf|  3 +++
 src/shared/conf-parser.c | 32 
 src/shared/conf-parser.h |  8 
 5 files changed, 74 insertions(+), 7 deletions(-)

diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index d245bf4..70ca837 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -44,18 +44,41 @@
 
 refnamediv
 refnamelogind.conf/refname
-refpurposeLogin manager configuration file/refpurpose
+refpurposeLogin manager configuration files/refpurpose
 /refnamediv
 
 refsynopsisdiv
 parafilename/etc/systemd/logind.conf/filename/para
+
parafilename/etc/systemd/logind.conf.d/*.conf/filename/para
+
parafilename/run/systemd/logind.conf.d/*.conf/filename/para
+
parafilename/usr/lib/systemd/logind.conf.d/*.conf/filename/para
 /refsynopsisdiv
 
 refsect1
 titleDescription/title
 
-paraThis file configures various parameters of the systemd 
login manager, 
citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para
-
+paraThese files configure various parameters of the systemd 
login manager, 
citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+
+paraEach configuration file shall be named in the style of
+filenamereplaceablefilename/replaceable.conf/filename.
+Files in filename/etc//filename override files with the
+same name in filename/usr/lib//filename and
+filename/run//filename.  Files in
+filename/run//filename override files with the same name in
+filename/usr/lib//filename. Packages should install their
+configuration files in filename/usr/lib//filename. Files in
+filename/etc//filename are reserved for the local
+administrator, who may use this logic to override the
+configuration files installed by vendor packages. All
+configuration files are sorted by their filename in
+lexicographic order, regardless of which of the directories
+they reside in. If multiple files specify the same option, the
+entry in the file with the lexicographically latest name will
+be applied; entries in any filenamelogind.conf.d/filename
+file override entries in
+filename/etc/systemd/logind.conf/filename. It is
+recommended to prefix all filenames with a two-digit number and
+a dash, to simplify the ordering of the files./para
 /refsect1
 
 refsect1
diff --git a/src/login/logind.c b/src/login/logind.c
index 8f00c46..69b219d 100644
--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -1171,10 +1171,11 @@ int manager_run(Manager *m) {
 static int manager_parse_config_file(Manager *m) {
 assert(m);
 
-return config_parse(NULL, /etc/systemd/logind.conf, NULL,
-Login\0,
-config_item_perf_lookup, logind_gperf_lookup,
-false, false, true, m);
+return config_parse_many(/etc/systemd/logind.conf,
+ CONF_DIRS_NULSTR(systemd/logind.conf),
+ Login\0,
+ config_item_perf_lookup, logind_gperf_lookup,
+ false, m);
 }
 
 int main(int argc, char *argv[]) {
diff --git a/src/login/logind.conf b/src/login/logind.conf
index 4608a2c..6b1943a 100644
--- a/src/login/logind.conf
+++ b/src/login/logind.conf
@@ -5,6 +5,9 @@
 #  the Free Software Foundation; either version 2.1 of the License, or
 #  (at your option) any later version.
 #
+# You can override the 

Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

2014-10-20 Thread Josh Triplett
On Mon, Oct 20, 2014 at 08:48:01PM +0200, Lennart Poettering wrote:
 On Mon, 20.10.14 11:28, j...@joshtriplett.org (j...@joshtriplett.org) wrote:
   I'd really prefer if we'd keep things in logind.conf and just provide
   the option of using logind.conf.d. This would be similar to unit
   files, where the unit files are where the beef is and .d/ is just a
   way to override/extend is. THe man page of logind.conf should
   reference the ability that .d/ files are supported, but that should be
   it for the documentation. We should really try to not to be too
   surprising here for admins which tend to expect one configuration
   file, not many.
  
  The main awkwardness there is that /etc/logind.conf, as a file in /etc,
  should be parsed *after* /usr/lib/systemd/logind.conf.d/ and *before*
  /etc/systemd/logind.conf.d/ , which breaks the usual logic to load all
  files in order with files in /etc overriding files in /usr.
 
 Well, as for units the main file should be read first (taking the
 /usr+/etc override logic into account), and only then we should read
 the .d/ drop-ins (individually following the /usr+/etc override
 logic). THis is what we do for unit files too.
 
 .d/ in this context really are supposed to be for overrding and
 extending, and hence reading the .d/ snippets in /usr after the main
 confi file from /etc is the right thing to do I believe.
 
 Ultimately the difference really shouldn#t matter too much I
 think. After all the version in /usr is for vendor defaults, and the
 stuff in /etc for user overrides. .d/ are for overrding hence mostly
 make sense in /etc only really, and should be the total exception in
 /usr.

OK, if you're fine with /usr/lib/systemd/logind.conf.d/*.conf overriding
/etc/logind.conf, then the patch gets *really* simple, and I'll submit
v3 soon.

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


Re: [systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

2014-10-17 Thread Josh Triplett
On Fri, Oct 17, 2014 at 08:40:48AM +0300, Mantas Mikulėnas wrote:
 On Fri, Oct 17, 2014 at 7:29 AM, Josh Triplett j...@joshtriplett.org wrote:
  This makes it possible to drop in logind configuration snippets from a
  package or other configuration management mechanism.
 
 I'm still very curious what packages would need to install drop-ins for 
 logind?

Configuration packages, metapackages, configuration management systems,
etc.

  Introduce a new helper, conf_parse_many, to parse configuration files in
  a search path.
 
  systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf
  rather than /etc/systemd/logind.conf .  Distributions should migrate
  existing modified versions of /etc/systemd/logind.conf to
  /etc/systemd/logind.conf.d/50-default.conf .
 
 Sounds like unnecessary shuffling things around...

It's the same process previously followed for /etc/modules moving to
/etc/modules-load.d, for instance.

  For systemd, are git format-patch -M patches (with git-style renames
  rather than whole-file deletion/insertions) acceptable for mailing list
  review?  That format makes renames much easier to review.
 
 I'm sure the patches are applied using `git am`, so that should work fine.

That was my hope as well.

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


[systemd-devel] [PATCH] logind: Support /etc/systemd/logind.conf.d/*.conf

2014-10-16 Thread Josh Triplett
This makes it possible to drop in configuration file snippets from a
package or other configuration management mechanism.
---
 man/logind.conf.xml  |  4 +++-
 src/login/logind.c   | 21 +
 src/shared/conf-parser.c | 19 +++
 src/shared/conf-parser.h |  7 +++
 4 files changed, 46 insertions(+), 5 deletions(-)

diff --git a/man/logind.conf.xml b/man/logind.conf.xml
index 8ba9523..836f307 100644
--- a/man/logind.conf.xml
+++ b/man/logind.conf.xml
@@ -44,17 +44,19 @@
 
 refnamediv
 refnamelogind.conf/refname
+refnamelogind.conf.d/refname
 refpurposeLogin manager configuration file/refpurpose
 /refnamediv
 
 refsynopsisdiv
 parafilename/etc/systemd/logind.conf/filename/para
+
parafilename/etc/systemd/logind.conf.d/*.conf/filename/para
 /refsynopsisdiv
 
 refsect1
 titleDescription/title
 
-paraThis file configures various parameters of the systemd 
login manager, 
citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para
+paraThese files configures various parameters of the systemd 
login manager, 
citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry./para
 
 /refsect1
 
diff --git a/src/login/logind.c b/src/login/logind.c
index 8f00c46..1feb251 100644
--- a/src/login/logind.c
+++ b/src/login/logind.c
@@ -29,6 +29,7 @@
 
 #include sd-daemon.h
 #include strv.h
+#include conf-files.h
 #include conf-parser.h
 #include mkdir.h
 #include bus-util.h
@@ -1169,12 +1170,24 @@ int manager_run(Manager *m) {
 }
 
 static int manager_parse_config_file(Manager *m) {
+_cleanup_strv_free_ char **filenames = NULL;
+int r;
+
 assert(m);
 
-return config_parse(NULL, /etc/systemd/logind.conf, NULL,
-Login\0,
-config_item_perf_lookup, logind_gperf_lookup,
-false, false, true, m);
+r = conf_files_list(filenames, .conf, NULL, 
/etc/systemd/logind.conf.d, NULL);
+if (r  0)
+return r;
+
+r = config_parse(NULL, /etc/systemd/logind.conf, NULL, Login\0,
+ config_item_perf_lookup, logind_gperf_lookup,
+ false, false, true, m);
+if (r  0)
+return r;
+
+return config_parse_many(filenames, Login\0,
+ config_item_perf_lookup, logind_gperf_lookup,
+ false, m);
 }
 
 int main(int argc, char *argv[]) {
diff --git a/src/shared/conf-parser.c b/src/shared/conf-parser.c
index ee6de65..54bd642 100644
--- a/src/shared/conf-parser.c
+++ b/src/shared/conf-parser.c
@@ -430,6 +430,25 @@ int config_parse(const char *unit,
 return 0;
 }
 
+/* Parse each config file, if it exists. */
+int config_parse_many(char **filenames,
+  const char *sections,
+  ConfigItemLookup lookup,
+  const void *table,
+  bool relaxed,
+  void *userdata) {
+char **fn;
+int r;
+
+STRV_FOREACH(fn, filenames) {
+r = config_parse(NULL, *fn, NULL, sections, lookup, table, 
relaxed, false, true, userdata);
+if (r  0)
+return r;
+}
+
+return 0;
+}
+
 #define DEFINE_PARSER(type, vartype, conv_func) \
 int config_parse_##type(const char *unit,   \
 const char *filename,   \
diff --git a/src/shared/conf-parser.h b/src/shared/conf-parser.h
index 62f2a01..37eee55 100644
--- a/src/shared/conf-parser.h
+++ b/src/shared/conf-parser.h
@@ -92,6 +92,13 @@ int config_parse(const char *unit,
  bool warn,
  void *userdata);
 
+int config_parse_many(char **filenames,
+  const char *sections,  /* nulstr */
+  ConfigItemLookup lookup,
+  const void *table,
+  bool relaxed,
+  void *userdata);
+
 /* Generic parsers */
 int config_parse_int(const char *unit, const char *filename, unsigned line, 
const char *section, unsigned section_line, const char *lvalue, int ltype, 
const char *rvalue, void *data, void *userdata);
 int config_parse_unsigned(const char *unit, const char *filename, unsigned 
line, const char *section, unsigned section_line, const char *lvalue, int 
ltype, const char *rvalue, void *data, void *userdata);
-- 
2.1.1

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


Re: [systemd-devel] [PATCH] logind: Support /etc/systemd/logind.conf.d/*.conf

2014-10-16 Thread Josh Triplett
On Thu, Oct 16, 2014 at 03:36:57PM +0200, Zbigniew Jędrzejewski-Szmek wrote:
 On Thu, Oct 16, 2014 at 12:27:21PM +0200, Josh Triplett wrote:
  This makes it possible to drop in configuration file snippets from a
  package or other configuration management mechanism.
 What kind of settings would you install in this way?

In my case, I plan to have one of my personal configuration packages
install an /etc/systemd/logind.conf.d/lid.conf that contains:

[Login]
HandleLidSwitch=lock

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


Re: [systemd-devel] [PATCH] logind: Support /etc/systemd/logind.conf.d/*.conf

2014-10-16 Thread Josh Triplett
On Thu, Oct 16, 2014 at 09:42:50AM -0400, Rahul Sundaram wrote:
 On Thu, Oct 16, 2014 at 6:27 AM, Josh Triplett  wrote:
  This makes it possible to drop in configuration file snippets from a
  package or other configuration management mechanism.

 Shouldn't those go into /usr according to

 http://0pointer.net/blog/projects/stateless.html

Fair enough, I can trivially have it check
/usr/lib/systemd/logind.conf.d/*.conf as well.  Will do in v2.

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


[systemd-devel] [PATCHv2] logind: Support logind.conf.d directories in the usual search paths

2014-10-16 Thread Josh Triplett
This makes it possible to drop in logind configuration snippets from a
package or other configuration management mechanism.

Introduce a new helper, conf_parse_many, to parse configuration files in
a search path.

systemd now installs /usr/lib/systemd/logind.conf.d/50-default.conf
rather than /etc/systemd/logind.conf .  Distributions should migrate
existing modified versions of /etc/systemd/logind.conf to
/etc/systemd/logind.conf.d/50-default.conf .

Move the logind.conf manpage to logind.conf.d, update it to document the
search paths, and update all references to it.
---

v2: Updated to use the usual search path mechanism and directories.


For systemd, are git format-patch -M patches (with git-style renames
rather than whole-file deletion/insertions) acceptable for mailing list
review?  That format makes renames much easier to review.

 Makefile-man.am  |   4 +-
 Makefile.am  |   5 +-
 man/loginctl.xml |   2 +-
 man/logind.conf.d.xml| 381 +++
 man/logind.conf.xml  | 359 -
 man/nss-myhostname.xml   |   2 +-
 man/pam_systemd.xml  |   2 +-
 man/systemd-inhibit.xml  |   4 +-
 man/systemd-logind.service.xml   |   4 +-
 src/login/50-default.conf|  29 +++
 src/login/logind.c   |  17 +-
 src/login/logind.conf|  29 ---
 src/shared/conf-parser.c |  25 +++
 src/shared/conf-parser.h |   7 +
 units/org.freedesktop.login1.busname |   2 +-
 units/systemd-logind.service.in  |   2 +-
 16 files changed, 469 insertions(+), 405 deletions(-)
 create mode 100644 man/logind.conf.d.xml
 delete mode 100644 man/logind.conf.xml
 create mode 100644 src/login/50-default.conf
 delete mode 100644 src/login/logind.conf

diff --git a/Makefile-man.am b/Makefile-man.am
index a13e948..f28eccd 100644
--- a/Makefile-man.am
+++ b/Makefile-man.am
@@ -1096,7 +1096,7 @@ endif
 if ENABLE_LOGIND
 MANPAGES += \
man/loginctl.1 \
-   man/logind.conf.5 \
+   man/logind.conf.d.5 \
man/systemd-logind.service.8
 MANPAGES_ALIAS += \
man/systemd-logind.8
@@ -1547,7 +1547,7 @@ EXTRA_DIST += \
man/localectl.xml \
man/localtime.xml \
man/loginctl.xml \
-   man/logind.conf.xml \
+   man/logind.conf.d.xml \
man/machine-id.xml \
man/machine-info.xml \
man/machinectl.xml \
diff --git a/Makefile.am b/Makefile.am
index e52db17..e048d83 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -95,6 +95,7 @@ sysusersdir=$(prefix)/lib/sysusers.d
 sysctldir=$(prefix)/lib/sysctl.d
 binfmtdir=$(prefix)/lib/binfmt.d
 modulesloaddir=$(prefix)/lib/modules-load.d
+logindconfdir=$(prefix)/lib/logind.conf.d
 networkdir=$(rootprefix)/lib/systemd/network
 pkgincludedir=$(includedir)/systemd
 systemgeneratordir=$(rootlibexecdir)/system-generators
@@ -5361,8 +5362,8 @@ dist_dbussystemservice_DATA += \
 dist_dbuspolicy_DATA += \
src/login/org.freedesktop.login1.conf
 
-dist_pkgsysconf_DATA += \
-   src/login/logind.conf
+dist_logindconf_DATA = \
+   src/login/50-default.conf
 
 polkitpolicy_files += \
src/login/org.freedesktop.login1.policy
diff --git a/man/loginctl.xml b/man/loginctl.xml
index 749db92..b2eaea4 100644
--- a/man/loginctl.xml
+++ b/man/loginctl.xml
@@ -446,7 +446,7 @@
 
citerefentryrefentrytitlesystemd/refentrytitlemanvolnum1/manvolnum/citerefentry,
 
citerefentryrefentrytitlesystemctl/refentrytitlemanvolnum1/manvolnum/citerefentry,
 
citerefentryrefentrytitlesystemd-logind.service/refentrytitlemanvolnum8/manvolnum/citerefentry,
-
citerefentryrefentrytitlelogind.conf/refentrytitlemanvolnum5/manvolnum/citerefentry
+
citerefentryrefentrytitlelogind.conf.d/refentrytitlemanvolnum5/manvolnum/citerefentry
 /para
 /refsect1
 
diff --git a/man/logind.conf.d.xml b/man/logind.conf.d.xml
new file mode 100644
index 000..1c34017
--- /dev/null
+++ b/man/logind.conf.d.xml
@@ -0,0 +1,381 @@
+?xml version='1.0'? !--*-nxml-*--
+?xml-stylesheet type=text/xsl 
href=http://docbook.sourceforge.net/release/xsl/current/xhtml/docbook.xsl;?
+!DOCTYPE refentry PUBLIC -//OASIS//DTD DocBook XML V4.2//EN
+http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd;
+
+!--
+  This file is part of systemd.
+
+  Copyright 2010 Lennart Poettering
+
+  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. 

Re: [systemd-devel] [PATCH] journalctl: add --utc option

2014-10-02 Thread Josh Triplett
On Thu, Oct 02, 2014 at 09:36:46AM +0200, Jan Synacek wrote:
 Introduce option to display time in UTC.

Does TZ=UTC journalctl not do the right thing?  A quick test here
suggests that it does.  That seems preferable to teaching individual
tools to special-case UTC.

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


Re: [systemd-devel] [PATCH] journalctl: add --utc option

2014-10-02 Thread Josh Triplett
On Thu, Oct 02, 2014 at 09:11:39PM +0200, Lennart Poettering wrote:
 On Thu, 02.10.14 11:56, Josh Triplett (j...@joshtriplett.org) wrote:
 
  On Thu, Oct 02, 2014 at 09:36:46AM +0200, Jan Synacek wrote:
   Introduce option to display time in UTC.
  
  Does TZ=UTC journalctl not do the right thing?  A quick test here
  suggests that it does.  That seems preferable to teaching individual
  tools to special-case UTC.
 
 Not sure i agree. --utc really should only have an effect on our own
 output, and that's a good thing. If you set $TZ you end up changing
 much much more, for example the logic of glibc's own syslog() and what
 it passes on, and we shouldn't influence that.

True, but in the case of journalctl, which just queries and outputs
journal data, what would TZ=UTC affect that you *wouldn't* want?
journalctl shouldn't be calling syslog().

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


[systemd-devel] systemd-resolved, multi-home DNS resolution, VPNs, and privacy

2014-08-28 Thread Josh Triplett
The documentation for systemd-resolved says it sends DNS queries on all
interfaces.  That seems like a bug for privacy and security reasons: I
don't necessarily want a query for foo.internalhost.com going anywhere
other than my VPN for internalhost.com, and if I run a VPN for privacy
purposes then I don't want *anything* other than the VPN itself to send
traffic over a non-VPN interface.  Any way we could fix that while
retaining the works out of the box behavior?

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


Re: [systemd-devel] [PATCH] TODO: add molly-guard functionality

2014-08-25 Thread Josh Triplett
On Mon, Aug 25, 2014 at 07:19:47PM +0200, Lennart Poettering wrote:
 On Sat, 23.08.14 19:26, Josh Triplett (j...@joshtriplett.org) wrote:
 
  Rather than requiring a third-party tool for this, systemctl should
  handle this natively.
 
 This has been proposed before, but I sounds awfully random to me to have
 in systemd. I am pretty sure this should be an add-on, but not
 something we should support out-of-the-box.

I wouldn't argue that it's something we should *enable* by default, just
something to have available and enableable (perhaps via system.conf).

Related to that, would you be willing to take patches for separate tiny
binaries for shutdown/poweroff/etc, so that they don't depend on argv[0]
to decide what to do?  That would make it easier to do things like
diverting /sbin/poweroff to /sbin/poweroff.real and putting a wrapper in
/sbin/poweroff.

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


[systemd-devel] [PATCH] TODO: add molly-guard functionality

2014-08-23 Thread Josh Triplett
Rather than requiring a third-party tool for this, systemctl should
handle this natively.
---
 TODO | 1 +
 1 file changed, 1 insertion(+)

diff --git a/TODO b/TODO
index 0fcd3a0..aaf6444 100644
--- a/TODO
+++ b/TODO
@@ -441,6 +441,7 @@ Features:
   - Something is wrong with symlink handling of autovt@.service in 
systemctl list-unit-files
   - better error message if you run systemctl without systemd running
   - systemctl status output should should include list of triggering units and 
their status
+  - add molly-guard functionality: prompt for hostname if interactively 
shutting down a remote system (running as child of ssh)
 
 * unit install:
   - systemctl mask should find all names by which a unit is accessible
-- 
2.1.0

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


[systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]

2014-07-08 Thread Josh Triplett
[Responding to this version because the latest thread hasn't appeared in
the mbox archives yet.  The comments apply equally well to the latest
version, Add DEPLOYMENT to hostnamectl.]

On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
 +static bool valid_environment(const char *environment) {
 +
 +assert(environment);
 +
 +return nulstr_contains(
 +development\0
 +staging\0
 +production\0,
 +environment);
 +}

Can we please *not* attempt to limit or standardize this particular
set of machine roles?  As already demonstrated in the previous thread,
people have all sorts of staged deployment strategies.  Furthermore,
the concept of a machine role shouldn't be limited to service deployment
strategies.

Debian has a file /etc/debian_chroot, used to describe the nature of a
chroot environment, such as i386 cross for a 32-bit build chroot, or
similar.  The default prompt then incorporates that string.  This seems
quite similar, and I'd love to see a standardized mechanism for that
kind of string.

Rather than limiting this list to a few specific tokens, could we just
provide a MachineRole or similar, which accepts a short freeform text
string?  Then, a staged deployment system could use this for
development/staging/production/validation/replication/blue/whatever,
while another type of system can use its own tokens here.

As general guidance, we could say something like MachineRole should
consist of a space-separated series of printable tokens, such as
'production' or 'staging'..  This also allows MachineRole to contain
something like staging foobranch, for instance, which indicates a
staging server that's part of the experimental parallel foobranch
infrastructure.

This would still allow the role string to serve its primary functions:
querying it to check for particular values used within an organization,
or inserting it into prompts, window titles, and similar.

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


Re: [systemd-devel] Deployment/environment names [was: Re: [PATCH 2/4] Add ENVIRONMENT to hostnamed]

2014-07-08 Thread Josh Triplett
On Wed, Jul 09, 2014 at 01:16:04AM +, Jóhann B. Guðmundsson wrote:
 
 On 07/09/2014 01:05 AM, j...@joshtriplett.org wrote:
 On Tue, Jul 08, 2014 at 10:45:11PM +, Jóhann B. Guðmundsson wrote:
 
 On 07/08/2014 10:45 PM, Josh Triplett wrote:
  [Responding to this version because the latest thread hasn't appeared in
  the mbox archives yet.  The comments apply equally well to the latest
  version, Add DEPLOYMENT to hostnamectl.]
  
  On Tue, Jul 08, 2014 at 12:38:50AM +, Jóhann B. Guðmundsson wrote:
  +static bool valid_environment(const char *environment) {
  +
  +assert(environment);
  +
  +return nulstr_contains(
  +development\0
  +staging\0
  +production\0,
  +environment);
  +}
  Can we please*not*  attempt to limit or standardize this particular
  set of machine roles?  As already demonstrated in the previous thread,
  people have all sorts of staged deployment strategies.  Furthermore,
  the concept of a machine role shouldn't be limited to service deployment
  strategies.
  
 
 Roles != the environment they run in.
 I'm not trying to bikeshed over the naming of the variable itself.  I'm
 arguing that standardizing this particular bit of metadata won't work
 well when so many different deployment strategies exist.  Thus, rather
 than having a fixed set of keywords, I'd propose simply saying this
 contains keywords, and leaving the specific keywords up to the admin.
 If you attempt to standardize production/development/staging, you'll
 either end up with a model that only works for a small subset of
 deployments, or you'll end up adding twelve more keywords, at which
 point you might as well have just said use whatever keyword you like.
 
 The 4 tier covers the majority of the models since more or less the entire
 internet recommend three tier model including M$ [1]
 Anyone wanting to extend that further can do so using the PRETTY_HOSTNAME=

PRETTY_HOSTNAME does not equate to description, and in any case is
not the same thing as a deployment environment.

 This patch is very specific to deployment environment and to solve a very
 specific long standing problem and to achieve that we need to a standardize,
 if we dont we can just as well drop this patch since in the long run we
 cannot introduce something like ConditionDeployment= like David mentioned
 and it kinda defeat's my purpose working in this in the firsplace...

Distribution unit files will never use ConditionDeployment; only
admin-created or admin-modified unit files will.  Given that, it will
work perfectly without a standardized set of names.  Just specify that
DEPLOYMENT contains a keyword *such as* (but not limited to)
production or development, and then state that ConditionDeployment
can specify a keyword.  That will work perfectly without limiting the
set of possible keywords.

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


Re: [systemd-devel] [PATCH rebased] Use strlen even for constant strings

2014-03-16 Thread Josh Triplett
On Sun, Mar 16, 2014 at 02:56:10PM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 On Sat, Mar 15, 2014 at 11:40:07AM -0700, Josh Triplett wrote:
  GCC optimizes strlen(string constant) to a constant, even with -O0.
  Thus, replace patterns like sizeof(string constant)-1 with
  strlen(string constant) where possible, for clarity.  In particular,
  for expressions intended to add up the lengths of components going into
  a string, this often makes it clearer that the expression counts the
  trailing '\0' exactly once, by putting the +1 for the '\0' at the end of
  the expression, rather than hidden in a sizeof in the middle of the
  expression.
 Applied, thanks.
 
  On Sat, Mar 15, 2014 at 05:37:49AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
   strlen() is indeed much nicer. Unfortunately it stopped applying 
   cleanly...
   Could you rebase this?
  
  Done; git rebased it automatically with no conflicts.  (am -3 might work
  in the future for patches that trivially rebase.)
 I tried that, but for some reason it didn't seem to work. Maybe
 your patch was missing the headers necessayr for -3?

Full commits have all those headers (the index lines with partial
hashes on them), but possibly I'm overestimating the capabilities of -3.
In any case, git rebase automatically did the three-way merge.

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


[systemd-devel] [PATCH rebased] Use strlen even for constant strings

2014-03-15 Thread Josh Triplett
GCC optimizes strlen(string constant) to a constant, even with -O0.
Thus, replace patterns like sizeof(string constant)-1 with
strlen(string constant) where possible, for clarity.  In particular,
for expressions intended to add up the lengths of components going into
a string, this often makes it clearer that the expression counts the
trailing '\0' exactly once, by putting the +1 for the '\0' at the end of
the expression, rather than hidden in a sizeof in the middle of the
expression.
---

On Sat, Mar 15, 2014 at 05:37:49AM +0100, Zbigniew Jędrzejewski-Szmek wrote:
 strlen() is indeed much nicer. Unfortunately it stopped applying cleanly...
 Could you rebase this?

Done; git rebased it automatically with no conflicts.  (am -3 might work
in the future for patches that trivially rebase.)

 src/core/dbus.c|  2 +-
 src/core/service.c |  2 +-
 src/journal/journald-server.c  |  2 +-
 src/journal/journald-syslog.c  |  2 +-
 src/libsystemd/sd-bus/bus-kernel.c |  4 ++--
 src/libsystemd/sd-bus/bus-socket.c |  4 ++--
 src/libsystemd/sd-bus/bus-track.c  |  2 +-
 src/shared/cgroup-util.c   |  2 +-
 src/shared/unit-name.c |  2 +-
 src/shared/util.c  |  2 +-
 src/sysctl/sysctl.c|  2 +-
 src/systemctl/systemctl.c  | 40 +++---
 src/udev/udev-rules.c  | 14 ++---
 13 files changed, 40 insertions(+), 40 deletions(-)

diff --git a/src/core/dbus.c b/src/core/dbus.c
index 03f3738..72f36bd 100644
--- a/src/core/dbus.c
+++ b/src/core/dbus.c
@@ -953,7 +953,7 @@ static int bus_init_private(Manager *m) {
 return 0;
 
 strcpy(sa.un.sun_path, /run/systemd/private);
-salen = offsetof(union sockaddr_union, un.sun_path) + 
sizeof(/run/systemd/private) - 1;
+salen = offsetof(union sockaddr_union, un.sun_path) + 
strlen(/run/systemd/private);
 } else {
 size_t left = sizeof(sa.un.sun_path);
 char *p = sa.un.sun_path;
diff --git a/src/core/service.c b/src/core/service.c
index 121ddec..41b95ab 100644
--- a/src/core/service.c
+++ b/src/core/service.c
@@ -361,7 +361,7 @@ static int service_arm_timer(Service *s, usec_t usec) {
 static char *sysv_translate_name(const char *name) {
 char *r;
 
-r = new(char, strlen(name) + sizeof(.service));
+r = new(char, strlen(name) + strlen(.service) + 1);
 if (!r)
 return NULL;
 
diff --git a/src/journal/journald-server.c b/src/journal/journald-server.c
index f0117e7..5befe93 100644
--- a/src/journal/journald-server.c
+++ b/src/journal/journald-server.c
@@ -686,7 +686,7 @@ static void dispatch_message_real(
 #ifdef HAVE_SELINUX
 if (use_selinux()) {
 if (label) {
-x = alloca(sizeof(_SELINUX_CONTEXT=) + 
label_len);
+x = alloca(strlen(_SELINUX_CONTEXT=) + 
label_len + 1);
 
 *((char*) mempcpy(stpcpy(x, 
_SELINUX_CONTEXT=), label, label_len)) = 0;
 IOVEC_SET_STRING(iovec[n++], x);
diff --git a/src/journal/journald-syslog.c b/src/journal/journald-syslog.c
index cbb944f..fee7d91 100644
--- a/src/journal/journald-syslog.c
+++ b/src/journal/journald-syslog.c
@@ -46,7 +46,7 @@ static void forward_syslog_iovec(Server *s, const struct 
iovec *iovec, unsigned
 .msg_iovlen = n_iovec,
 .msg_name = sa,
 .msg_namelen = offsetof(union sockaddr_union, un.sun_path)
-   + sizeof(/run/systemd/journal/syslog) - 1,
+   + strlen(/run/systemd/journal/syslog),
 };
 struct cmsghdr *cmsg;
 union {
diff --git a/src/libsystemd/sd-bus/bus-kernel.c 
b/src/libsystemd/sd-bus/bus-kernel.c
index 80ef15b..5c955f4 100644
--- a/src/libsystemd/sd-bus/bus-kernel.c
+++ b/src/libsystemd/sd-bus/bus-kernel.c
@@ -1390,7 +1390,7 @@ int bus_kernel_create_starter(const char *bus, const char 
*name, BusNamePolicy *
 assert(bus);
 assert(name);
 
-p = alloca(sizeof(/dev/kdbus/) - 1 + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + sizeof(/bus));
+p = alloca(strlen(/dev/kdbus/) + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + strlen(/bus) + 1);
 sprintf(p, /dev/kdbus/%lu-%s/bus, (unsigned long) getuid(), bus);
 
 fd = open(p, O_RDWR|O_NOCTTY|O_CLOEXEC);
@@ -1502,7 +1502,7 @@ int bus_kernel_create_monitor(const char *bus) {
 
 assert(bus);
 
-p = alloca(sizeof(/dev/kdbus/) - 1 + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + sizeof(/bus));
+p = alloca(strlen(/dev/kdbus/) + DECIMAL_STR_MAX(uid_t) + 1 + 
strlen(bus) + strlen(/bus) + 1);
 sprintf(p, /dev/kdbus/%lu-%s/bus, (unsigned long) getuid(), bus);
 
 fd = open(p, O_RDWR|O_NOCTTY|O_CLOEXEC);
diff --git 

Re: [systemd-devel] [PATCH] util: Rewrite in_charset to use strspn

2014-03-11 Thread Josh Triplett
On Wed, Mar 12, 2014 at 12:49:08AM +0100, Lennart Poettering wrote:
 Can you turn this into an inline function please? If it's that simple it
 sounds better to just make it an inline function in the .h file, instead
 of the .c file...

Sure.  Mind if I do that as a two-patch series?  I prefer to avoid
simultaneously changing code and moving it, since it makes the change
diff less obvious.

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


[systemd-devel] [PATCH] util: Make in_charset a static inline in util.h

2014-03-11 Thread Josh Triplett
With in_charset now reduced to a one-liner (plus asserts), make it a
static inline.
---

This applies on top of the previous patch simplifying in_charset.

 src/shared/util.c | 6 --
 src/shared/util.h | 6 +-
 2 files changed, 5 insertions(+), 7 deletions(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index 82326df..9f79409 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -920,12 +920,6 @@ char *delete_chars(char *s, const char *bad) {
 return s;
 }
 
-bool in_charset(const char *s, const char* charset) {
-assert(s);
-assert(charset);
-return s[strspn(s, charset)] == '\0';
-}
-
 char *file_in_same_dir(const char *path, const char *filename) {
 char *e, *r;
 size_t k;
diff --git a/src/shared/util.h b/src/shared/util.h
index c2bc977..0c8eb4b 100644
--- a/src/shared/util.h
+++ b/src/shared/util.h
@@ -529,7 +529,11 @@ char *strjoin(const char *x, ...) _sentinel_;
 
 bool is_main_thread(void);
 
-bool in_charset(const char *s, const char* charset) _pure_;
+static inline bool _pure_ in_charset(const char *s, const char* charset) {
+assert(s);
+assert(charset);
+return s[strspn(s, charset)] == '\0';
+}
 
 int block_get_whole_disk(dev_t d, dev_t *ret);
 
-- 
1.9.0

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


[systemd-devel] [PATCH 1/2] backlight: Fix copy/paste error printing an unrelated error code

2014-03-11 Thread Josh Triplett
udev_device_get_sysattr_value returns NULL on failure, but doesn't
provide an error code; thus, when printing an error from it, don't print
an unrelated error code from a previous call.
---
 src/backlight/backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 86f10cc..81470b3 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -322,7 +322,7 @@ int main(int argc, char *argv[]) {
 
 value = udev_device_get_sysattr_value(device, brightness);
 if (!value) {
-log_error(Failed to read system attribute: %s, 
strerror(-r));
+log_error(Failed to read system attribute);
 return EXIT_FAILURE;
 }
 
-- 
1.9.0

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


[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level

2014-03-11 Thread Josh Triplett
Some systems turn the backlight all the way off at the lowest levels.
Clamp saved brightness to at least 1 or 5% of max_brightness.  This
avoids preserving an unreadably dim screen, which would otherwise force
the user to disable state restoration.
---
 src/backlight/backlight.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 81470b3..b776ab5 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -292,6 +292,7 @@ int main(int argc, char *argv[]) {
 
 if (streq(argv[1], load)  shall_restore_state()) {
 _cleanup_free_ char *value = NULL;
+const char *max_brightness_str;
 
 if (!validate_device(udev, device))
 return EXIT_SUCCESS;
@@ -306,6 +307,44 @@ int main(int argc, char *argv[]) {
 return EXIT_FAILURE;
 }
 
+/* Some systems turn the backlight all the way off at the
+ * lowest levels.  Clamp saved brightness to at least 1 or 5%
+ * of max_brightness.  This avoids preserving an unreadably dim
+ * screen, which would otherwise force the user to disable
+ * state restoration.
+ */
+max_brightness_str = udev_device_get_sysattr_value(device, 
max_brightness);
+if (!max_brightness_str) {
+log_warning(Failed to read max_brightness attribute; 
not checking saved brightness);
+} else {
+unsigned long long brightness, max_brightness, 
new_brightness;
+
+r = safe_atollu(value, brightness);
+if (r  0) {
+log_error(Failed to parse brightness \%s\: 
%s, value, strerror(-r));
+return EXIT_FAILURE;
+}
+
+r = safe_atollu(max_brightness_str, max_brightness);
+if (r  0) {
+log_error(Failed to parse max_brightness 
\%s\: %s, max_brightness_str, strerror(-r));
+return EXIT_FAILURE;
+}
+
+new_brightness = MAX3(brightness, 1, 
max_brightness/20);
+if (new_brightness != brightness) {
+_cleanup_free_ char *old_value = value;
+
+value = asprintf(%llu, new_brightness);
+if (!value) {
+log_oom();
+return EXIT_FAILURE;
+}
+
+log_warning(Saved brightness %s too low; 
increasing to %s, old_value, value);
+}
+}
+
 r = udev_device_set_sysattr_value(device, brightness, value);
 if (r  0) {
 log_error(Failed to write system attribute: %s, 
strerror(-r));
-- 
1.9.0

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


[systemd-devel] [PATCH] util: Rewrite in_charset to use strspn

2014-03-11 Thread Josh Triplett
This simplifies in_charset down to a one-liner, and allows for possible
optimizations of strspn in libc.
---
 src/shared/util.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/src/shared/util.c b/src/shared/util.c
index d28caae..82326df 100644
--- a/src/shared/util.c
+++ b/src/shared/util.c
@@ -921,16 +921,9 @@ char *delete_chars(char *s, const char *bad) {
 }
 
 bool in_charset(const char *s, const char* charset) {
-const char *i;
-
 assert(s);
 assert(charset);
-
-for (i = s; *i; i++)
-if (!strchr(charset, *i))
-return false;
-
-return true;
+return s[strspn(s, charset)] == '\0';
 }
 
 char *file_in_same_dir(const char *path, const char *filename) {
-- 
1.9.0

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


Re: [systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level

2014-03-11 Thread Josh Triplett
On Wed, Mar 12, 2014 at 03:32:47AM +0100, Lennart Poettering wrote:
 On Tue, 11.03.14 18:55, Josh Triplett (j...@joshtriplett.org) wrote:
 
  +/* Some systems turn the backlight all the way off at the
  + * lowest levels.  Clamp saved brightness to at least 1 or 
  5%
  + * of max_brightness.  This avoids preserving an 
  unreadably dim
  + * screen, which would otherwise force the user to disable
  + * state restoration.
  + */
  +max_brightness_str = udev_device_get_sysattr_value(device, 
  max_brightness);
  +if (!max_brightness_str) {
  +log_warning(Failed to read max_brightness 
  attribute; not checking saved brightness);
  +} else {
 
 We try to avoid unnnecessary {} for single-line if blocks, if we can...

Even when the else block *does* need the braces?  (Note that kernel
style says to avoid braces on single-line blocks but always use braces
on all branches of an if/else-if/else if any branch needs them.)

 Hmmm, could you maybe move the entire clamping thing into a function of
 its own?  Maybe clamp_brightness(struct udev_device *d, char
 **brightness) or so, that simply patches the brightness string if it
 feels like it, otherwise leaves it unmodified?

Sure.

  +unsigned long long brightness,
  max_brightness, new_brightness;
 
 Wow, you expect a lot of brightness levels! ;-)
 
 I'd just stick to unsigned here... Keeps it more readable...

It's just two words (long long) and a couple of lls later, but OK.

  +
  +r = safe_atollu(value, brightness);
  +if (r  0) {
  +log_error(Failed to parse brightness 
  \%s\: %s, value, strerror(-r));
  +return EXIT_FAILURE;
  +}
  +
  +r = safe_atollu(max_brightness_str, 
  max_brightness);
  +if (r  0) {
  +log_error(Failed to parse max_brightness 
  \%s\: %s, max_brightness_str, strerror(-r));
  +return EXIT_FAILURE;
  +}
 
 Hmm, I'd prefer if the whole clamping business would be
 non-fatal. i.e. it clamps if it can read the files and parse them, but
 if it can't it won't do anything...

I thought about that, but it would have complicated the logic, and those
kernel files should always be numbers anyway.  However, with a move to a
separate function, this gets easier with early return, so sure.

  +new_brightness = MAX3(brightness, 1, 
  max_brightness/20);
  +if (new_brightness != brightness) {
  +_cleanup_free_ char *old_value = value;
  +
  +value = asprintf(%llu,
  new_brightness);
 
 asprintf() works differently... r = asprintf(value, %llu, 
 new_brightness)...

Gah, I fixed that and then managed to send the wrong patch, sorry.

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


[systemd-devel] [PATCHv2 1/2] backlight: Fix copy/paste error printing an unrelated error code

2014-03-11 Thread Josh Triplett
udev_device_get_sysattr_value returns NULL on failure, but doesn't
provide an error code; thus, when printing an error from it, don't print
an unrelated error code from a previous call.
---
v2: Patch 1/2 unchanged from v1.
 src/backlight/backlight.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 86f10cc..81470b3 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -322,7 +322,7 @@ int main(int argc, char *argv[]) {
 
 value = udev_device_get_sysattr_value(device, brightness);
 if (!value) {
-log_error(Failed to read system attribute: %s, 
strerror(-r));
+log_error(Failed to read system attribute);
 return EXIT_FAILURE;
 }
 
-- 
1.9.0

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


[systemd-devel] [PATCH 2/2] backlight: Avoid restoring brightness to an unreadably dim level

2014-03-11 Thread Josh Triplett
Some systems turn the backlight all the way off at the lowest levels.
Clamp saved brightness to at least 1 or 5% of max_brightness.  This
avoids preserving an unreadably dim screen, which would otherwise force
the user to disable state restoration.
---
v2: Send the right patch this time.  Factor clamping into a separate
function.  Make failures in clamping non-fatal.  Use unsigned rather
than unsigned long long.

 src/backlight/backlight.c | 44 
 1 file changed, 44 insertions(+)

diff --git a/src/backlight/backlight.c b/src/backlight/backlight.c
index 81470b3..44308e0 100644
--- a/src/backlight/backlight.c
+++ b/src/backlight/backlight.c
@@ -192,6 +192,48 @@ static bool validate_device(struct udev *udev, struct 
udev_device *device) {
 return true;
 }
 
+/* Some systems turn the backlight all the way off at the lowest levels.
+ * clamp_brightness clamps the saved brightness to at least 1 or 5% of
+ * max_brightness.  This avoids preserving an unreadably dim screen, which
+ * would otherwise force the user to disable state restoration. */
+static void clamp_brightness(struct udev_device *device, char **value) {
+int r;
+const char *max_brightness_str;
+unsigned brightness, max_brightness, new_brightness;
+
+max_brightness_str = udev_device_get_sysattr_value(device, 
max_brightness);
+if (!max_brightness_str) {
+log_warning(Failed to read max_brightness attribute; not 
checking saved brightness);
+return;
+}
+
+r = safe_atou(*value, brightness);
+if (r  0) {
+log_warning(Failed to parse brightness \%s\: %s, *value, 
strerror(-r));
+return;
+}
+
+r = safe_atou(max_brightness_str, max_brightness);
+if (r  0) {
+log_warning(Failed to parse max_brightness \%s\: %s, 
max_brightness_str, strerror(-r));
+return;
+}
+
+new_brightness = MAX3(brightness, 1U, max_brightness/20);
+if (new_brightness != brightness) {
+char *old_value = *value;
+
+r = asprintf(value, %u, new_brightness);
+if (r  0) {
+log_warning(Failed to format new brightness: %s, 
strerror(-r));
+return;
+}
+
+log_warning(Saved brightness %s too low; increasing to %s, 
old_value, *value);
+free(old_value);
+}
+}
+
 int main(int argc, char *argv[]) {
 _cleanup_udev_unref_ struct udev *udev = NULL;
 _cleanup_udev_device_unref_ struct udev_device *device = NULL;
@@ -306,6 +348,8 @@ int main(int argc, char *argv[]) {
 return EXIT_FAILURE;
 }
 
+clamp_brightness(device, value);
+
 r = udev_device_set_sysattr_value(device, brightness, value);
 if (r  0) {
 log_error(Failed to write system attribute: %s, 
strerror(-r));
-- 
1.9.0

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


Re: [systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer

2014-03-10 Thread Josh Triplett
On Mon, Mar 10, 2014 at 04:44:02PM +0100, Lennart Poettering wrote:
 On Sat, 08.03.14 20:33, Josh Triplett (j...@joshtriplett.org) wrote:
 
  avoid_cleanup also returns a copy of the pointer, making it convenient
  to use at the point where initialization completes, to hand the constructed
  object off somewhere without freeing it.
  
  Change all NULL assignments tagged with /* avoid cleanup */ to use this
  instead.
  ---
  
  Seems like a common pattern, and this makes it more self-documenting.
  In particular, the use in systemctl.c's list_timers function now feels
  like a single logical operation of hand ownership of this object off to
  something else and don't clean it up.
 
 Hmmm, I am all for synctactic sugar, but I don't see the benefit of this
 one really... Especially given that that disabling cleanup is done
 different for different types... For example, disabling cleanup for an
 fd is by assigning -1...

As far as I can tell, that's the *only* differing case.  Everything else
is a pointer and uses NULL.

 I would see benefit in this if we could maybe make this
 type-sensitive... not sure though if C would allow that? I at least
 cannot think of a way to do that?

C11 allows it using _Generic, if you're willing to rely on that.
__builtin_types_compatible_p and some casts could work too.  But again,
I think the only two cases are int and pointer.

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


[systemd-devel] [PATCH] Add avoid_cleanup macro to cancel _cleanup_ of a pointer

2014-03-08 Thread Josh Triplett
avoid_cleanup also returns a copy of the pointer, making it convenient
to use at the point where initialization completes, to hand the constructed
object off somewhere without freeing it.

Change all NULL assignments tagged with /* avoid cleanup */ to use this
instead.
---

Seems like a common pattern, and this makes it more self-documenting.
In particular, the use in systemctl.c's list_timers function now feels
like a single logical operation of hand ownership of this object off to
something else and don't clean it up.

 src/shared/macro.h| 7 +++
 src/systemctl/systemctl.c | 8 +++-
 src/timedate/timedated.c  | 5 +
 src/tmpfiles/tmpfiles.c   | 2 +-
 src/udev/udevadm-hwdb.c   | 2 +-
 5 files changed, 13 insertions(+), 11 deletions(-)

diff --git a/src/shared/macro.h b/src/shared/macro.h
index 08a036b..1e521bc 100644
--- a/src/shared/macro.h
+++ b/src/shared/macro.h
@@ -337,6 +337,13 @@ do {   
 \
 _found; \
 })
 
+#define avoid_cleanup(p)\
+({  \
+typeof(p) _p = (p); \
+(p) = NULL; \
+_p; \
+})
+
 /* Define C11 thread_local attribute even on older gcc compiler
  * version */
 #ifndef thread_local
diff --git a/src/systemctl/systemctl.c b/src/systemctl/systemctl.c
index f395265..d7983d1 100644
--- a/src/systemctl/systemctl.c
+++ b/src/systemctl/systemctl.c
@@ -749,8 +749,8 @@ static int list_sockets(sd_bus *bus, char **args) {
 
 /* from this point on we will cleanup those socket_infos */
 cs += c;
-free(listening);
-listening = triggered = NULL; /* avoid cleanup */
+free(avoid_cleanup(listening));
+avoid_cleanup(triggered);
 }
 
 qsort_safe(socket_infos, cs, sizeof(struct socket_info),
@@ -979,10 +979,8 @@ static int list_timers(sd_bus *bus, char **args) {
 timer_infos[c++] = (struct timer_info) {
 .id = u-id,
 .next_elapse = m,
-.triggered = triggered,
+.triggered = avoid_cleanup(triggered),
 };
-
-triggered = NULL; /* avoid cleanup */
 }
 
 qsort_safe(timer_infos, c, sizeof(struct timer_info),
diff --git a/src/timedate/timedated.c b/src/timedate/timedated.c
index d85ce57..0494d53 100644
--- a/src/timedate/timedated.c
+++ b/src/timedate/timedated.c
@@ -281,10 +281,7 @@ static char** get_ntp_services(void) {
 }
 }
 
-i = r;
-r = NULL; /* avoid cleanup */
-
-return strv_uniq(i);
+return strv_uniq(avoid_cleanup(r));
 }
 
 static int context_read_ntp(Context *c, sd_bus *bus) {
diff --git a/src/tmpfiles/tmpfiles.c b/src/tmpfiles/tmpfiles.c
index 6e36dc7..45f79e2 100644
--- a/src/tmpfiles/tmpfiles.c
+++ b/src/tmpfiles/tmpfiles.c
@@ -1261,7 +1261,7 @@ static int parse_line(const char *fname, unsigned line, 
const char *buffer) {
 return r;
 }
 
-i = NULL; /* avoid cleanup */
+avoid_cleanup(i);
 
 return 0;
 }
diff --git a/src/udev/udevadm-hwdb.c b/src/udev/udevadm-hwdb.c
index 65cbf61..7b6e0af 100644
--- a/src/udev/udevadm-hwdb.c
+++ b/src/udev/udevadm-hwdb.c
@@ -219,7 +219,7 @@ static int trie_insert(struct trie *trie, struct trie_node 
*node, const char *se
 if (err)
 return err;
 
-new_child = NULL; /* avoid cleanup */
+avoid_cleanup(new_child);
 break;
 }
 i += p;
-- 
1.9.0

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


[systemd-devel] systemd-backlight and backlight level 0

2014-03-05 Thread Josh Triplett
systemd-backlight saves backlight levels on shutdown, and restores them
on startup.  However, on some systems, backlight level 0 actually turns
the backlight *off*; this can potentially make the system unusable.
Complicating matters, on most systems, nothing pays attention to the
brightness adjustment keys in text mode.

I'd suggest one or both of the following two changes, to avoid a painful
failure mode:

- systemd-backlight should avoid saving/restoring a backlight level of
  0, and have a minimum backlight level.  (Possibly overridable via
  configuration, for people who *really* want to restore backlight level
  0.)

- Something ought to listen to the brightness keys (and perhaps other
  hotkeys) in pure text mode.  systemd seems like a good place for such
  a something to live.


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


Re: [systemd-devel] systemd-backlight and backlight level 0

2014-03-05 Thread Josh Triplett
On Wed, Mar 05, 2014 at 06:59:27PM +0100, David Herrmann wrote:
 On Wed, Mar 5, 2014 at 6:46 PM, Josh Triplett j...@joshtriplett.org wrote:
  systemd-backlight saves backlight levels on shutdown, and restores them
  on startup.  However, on some systems, backlight level 0 actually turns
  the backlight *off*; this can potentially make the system unusable.
  Complicating matters, on most systems, nothing pays attention to the
  brightness adjustment keys in text mode.
 
  I'd suggest one or both of the following two changes, to avoid a painful
  failure mode:
 
  - systemd-backlight should avoid saving/restoring a backlight level of
0, and have a minimum backlight level.  (Possibly overridable via
configuration, for people who *really* want to restore backlight level
0.)
 
 Never restoring val==0 seems fine to me.

Likewise.

  - Something ought to listen to the brightness keys (and perhaps other
hotkeys) in pure text mode.  systemd seems like a good place for such
a something to live.
 
 We cannot do that. It requires keymap-handling (as brightness keys are
 handled on the keysym, not keycode level) and this is exclusive
 territory of the compositor (or other foreground session controllers).

Perhaps this will get fixed when we switch from kernel VTs to a
userspace-managed console, then.

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


Re: [systemd-devel] systemd-backlight and backlight level 0

2014-03-05 Thread Josh Triplett
On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote:
 On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote:
  systemd-backlight saves backlight levels on shutdown, and restores them
  on startup.  However, on some systems, backlight level 0 actually turns
  the backlight *off*; this can potentially make the system unusable.
  Complicating matters, on most systems, nothing pays attention to the
  brightness adjustment keys in text mode.
  
  I'd suggest one or both of the following two changes, to avoid a painful
  failure mode:
  
  - systemd-backlight should avoid saving/restoring a backlight level of
0, and have a minimum backlight level.  (Possibly overridable via
configuration, for people who *really* want to restore backlight level
0.)
 
 To deal with situations like this there's systemd.restore_state=0 on the
 kernel cmdline, see kernel-command-line(7).

Yeah, I've seen that one; however, having to reboot the system and
change the kernel command line to unbreak it seems less ideal than
having the system avoid broken states to begin with.

 I could be convinced to fix brightness level 0 to 1 when restoring. But
 then again, I fear the next people will come then and say 1 is only
 marginally better than 0, i want the minimum to be 16!... Or even
 others saying Dude, I only got 3 brightness levels, and you took one
 away from me So I am not enthusiastic about the idea...

Given the choice between maximum flexibility and never making the system
unusable, I'll take the latter.  Not that hard to make it configurable,
if that proves necessary.

On restore, I'd suggest reading max_brightness, and if the stored value
falls under a threshold of ceil(max_brightness/SOME_DIVISOR), restore it
to that value instead.  (Ideally there should be some way to ask the
driver what level of brightness will produce a non-zero value in
actual_brightness, but no such mechanism seems to exist.)

Does that sound reasonable?

  - Something ought to listen to the brightness keys (and perhaps other
hotkeys) in pure text mode.  systemd seems like a good place for such
a something to live.
 
 That's definitely a job for the DE I am sure, so that can it do an OSD
 and all the other stuff. We do power button handling in logind only
 because what it does is relatively important and really close to the
 system lifecycle... But brightness keys (or volume keys..) are not close
 at all. I am really sure that that's for the DEs to handle, not us.

DEs don't handle the text consoles.  However, it does sound like this
will have to wait for kmscon or equivalent.

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


Re: [systemd-devel] systemd-backlight and backlight level 0

2014-03-05 Thread Josh Triplett
On Wed, Mar 05, 2014 at 10:21:17PM +0100, David Herrmann wrote:
 On Wed, Mar 5, 2014 at 8:31 PM, Josh Triplett j...@joshtriplett.org wrote:
  On Wed, Mar 05, 2014 at 07:10:51PM +0100, Lennart Poettering wrote:
  On Wed, 05.03.14 09:46, Josh Triplett (j...@joshtriplett.org) wrote:
   systemd-backlight saves backlight levels on shutdown, and restores them
   on startup.  However, on some systems, backlight level 0 actually turns
   the backlight *off*; this can potentially make the system unusable.
   Complicating matters, on most systems, nothing pays attention to the
   brightness adjustment keys in text mode.
  
   I'd suggest one or both of the following two changes, to avoid a painful
   failure mode:
  
   - systemd-backlight should avoid saving/restoring a backlight level of
 0, and have a minimum backlight level.  (Possibly overridable via
 configuration, for people who *really* want to restore backlight level
 0.)
 
  To deal with situations like this there's systemd.restore_state=0 on the
  kernel cmdline, see kernel-command-line(7).
 
  Yeah, I've seen that one; however, having to reboot the system and
  change the kernel command line to unbreak it seems less ideal than
  having the system avoid broken states to begin with.
 
 I'd expect this to be set on the recovery boot option. At I know
 some distros always provide two boot entries and to me this seems like
 the right place to set it.

Not a bad idea, but rather than requiring the addition of an extra
option (or potentially more than one, if other parts of systemd might
want to be more conservative on recovery as well), how about having
systemd-backlight treat single as systemd.restore_state=0?

- Josh Triplett
___
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

2014-03-01 Thread 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
 j...@joshtriplett.org 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


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

2014-02-28 Thread Josh Triplett
---

Strawman proposal, open to suggestions.  A change like this would make
tmpfiles flexible enough to detect what permission configuration an
admin wants to use and go along with that.  In general, set a
directory's permissions based on the set{u,g}id status of the binary
seems common enough to want to support; tmpfiles can implement this with
a simple stat and comparison.

Could potentially be more configurable, by capturing the mode, user, and
group of the item listed as the conditional path, and making them
available as placeholders within the subitem, but that seems like
overkill for the most common cases.

 TODO | 4 
 1 file changed, 4 insertions(+)

diff --git a/TODO b/TODO
index 6cac3e2..988f855 100644
--- a/TODO
+++ b/TODO
@@ -570,6 +570,10 @@ Features:
 * tmpfiles:
   - check systemd-tmpfiles for selinux context hookup for mknod(), symlink() 
and similar
   - apply x on D too (see patch from William Douglas)
+  - 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
 
 * for services: don't set $HOME in services unless requested
 
-- 
1.9.0

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


Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d

2013-04-23 Thread Josh Triplett
On Tue, Apr 23, 2013 at 01:45:32AM +0200, Tom Gundersen wrote:
 On Mon, Apr 22, 2013 at 11:53 PM, Josh Triplett j...@joshtriplett.org wrote:
  1) Leave only root in /etc/passwd and /etc/group.
 
 Not commenting on the overall idea, but if you are going to do
 something like this, at least allow the the files not to exist at all,
 and in this case a default entry for the root user to be assumed.

Sure, seems easy enough to make that entry synthetic as part of the PAM
module.

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


Re: [systemd-devel] [PATCH] TODO: add various journal enhancements

2013-04-22 Thread Josh Triplett
On Thu, Apr 18, 2013 at 12:42:38AM +0200, Kay Sievers wrote:
 On Thu, Apr 18, 2013 at 12:28 AM, Josh Triplett j...@joshtriplett.org wrote:
  On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote:
  On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org 
  wrote:
   +  - Provide one or more FUSE filesystems:
   +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording 
   credentials for all writes rather than limiting permissions
 
  That sounds like overkill. We should surely externalize the creation
  of the files from systemd and make it optional to support legacy
  stuff, otherwise these files should rather be phased out, than
  emulated, I think.
 
  Separate, external, and optional, definitely; no sense running it if you
  have no tools around that read or write the format directly.  But given
  that the glibc API (and corresponding expectations about the file
  format) will exist forever, it seems sensible to have a way to support
  that without actually having the files on the filesystem.
 
 I don't know what *forever* means here, I kind of doubt that. It's
 pure legacy stuff that needs that, and that works with current
 systemd. Most systems out there should not need these silly files at
 all, and the use will surely not grow in the future.

Every terminal emulator, display manager, screen/tmux/etc program, or
other program that needs to embed an interactive shell should log to
utmp and family.  The glibc API represents the standard way to do so.
So either the glibc API needs to directly support logging to (and
reading from) journald, or some compatibility shim like this needs to
exist.

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


Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d

2013-04-22 Thread Josh Triplett
On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote:
 On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote:
  ---
   TODO |5 +
   1 file changed, 5 insertions(+)
 
  diff --git a/TODO b/TODO
  index eb482d0..6cf632a 100644
  --- a/TODO
  +++ b/TODO
  @@ -679,6 +679,11 @@ External:
  - put bootcharts in the journal
  - kernel cmdline bootchart option for simplicity?
 
  +* Support passwd.d and group.d; accumulate a persistent name/number map, to
  +  preserve UID/GID assignments without requiring assignment of unique IDs 
  at
  +  adduser time.
 
 Hmm, how is that related to systemd code? Sounds more like a glibc
 shipped feature/plugin?

It would involve a PAM plugin as well, yes, but also a system daemon
watching those directories for changes and allocating new systemwide
UIDs and GIDs, and I also suspect several bits of systemd functionality
would want to integrate with it, notably logind and container bits.

  Allows installing users without maintainer scripts, and makes
  +  UID namespaces easier to manage.
 
 How would that happen? How do you pre-allocate the numbers in a tiny
 32bit number range. We do not have UUIDs for that like some real
 operating systems have. :)

It'd be nice to start looking into what it would take to support 64-bit
UIDs and GIDs, but in the meantime 32 bits still seems like enough to
allocate new system UIDs when files show up in one of the passwd.d
directories, preserve their mapping, and garbage-collect them when no
longer needed.  That garbage-collection bit also seems like something
systemd would need to help with.

As for containers, it just means that users would get very few UIDs and
GIDs to use in their containers.

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


Re: [systemd-devel] [PATCH] TODO: passwd.d, group.d

2013-04-22 Thread Josh Triplett
On Mon, Apr 22, 2013 at 11:24:56PM +0200, Kay Sievers wrote:
 On Mon, Apr 22, 2013 at 9:29 PM, Josh Triplett j...@joshtriplett.org wrote:
  On Thu, Apr 18, 2013 at 12:26:15AM +0200, Kay Sievers wrote:
  On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org 
  wrote:
   ---
TODO |5 +
1 file changed, 5 insertions(+)
  
   diff --git a/TODO b/TODO
   index eb482d0..6cf632a 100644
   --- a/TODO
   +++ b/TODO
   @@ -679,6 +679,11 @@ External:
   - put bootcharts in the journal
   - kernel cmdline bootchart option for simplicity?
  
   +* Support passwd.d and group.d; accumulate a persistent name/number 
   map, to
   +  preserve UID/GID assignments without requiring assignment of unique 
   IDs at
   +  adduser time.
 
  Hmm, how is that related to systemd code? Sounds more like a glibc
  shipped feature/plugin?
 
  It would involve a PAM plugin as well, yes, but also a system daemon
  watching those directories for changes and allocating new systemwide
  UIDs and GIDs, and I also suspect several bits of systemd functionality
  would want to integrate with it, notably logind and container bits.
 
   Allows installing users without maintainer scripts, and makes
   +  UID namespaces easier to manage.
 
  How would that happen? How do you pre-allocate the numbers in a tiny
  32bit number range. We do not have UUIDs for that like some real
  operating systems have. :)
 
  It'd be nice to start looking into what it would take to support 64-bit
  UIDs and GIDs, but in the meantime 32 bits still seems like enough to
  allocate new system UIDs when files show up in one of the passwd.d
  directories, preserve their mapping, and garbage-collect them when no
  longer needed.  That garbage-collection bit also seems like something
  systemd would need to help with.
 
  As for containers, it just means that users would get very few UIDs and
  GIDs to use in their containers.
 
 Sorry, I lost you. I have really no idea what you are looking for.
 
 Care to start at the beginning again, I read all that again but I
 don't get it. :)

1) Leave only root in /etc/passwd and /etc/group.
2) Add passwd.d and group.d directories in /etc and under /usr, which
   accept one record per file (with name given by the filename) and
   which do not include UIDs or GIDs.
3) When new users or groups show up, dynamically allocate new IDs for
   them, and record them in a separate persistent name-number mapping
   used by the PAM module.  Keep them there as long as the .d file
   exists, or as long as anything on the system (file or process) uses
   the UID.
4) When the .d file goes away, and nothing uses the UID or GID anymore,
   throw it at the back of the list of IDs to reuse.
5) In the same daemon managing this, optionally support minting small
   numbers of ephemeral UIDs/GIDs for use in containers, when they don't
   need to map to any useful persistent privileges on the host system.
   Also optionally support creating new non-ephemeral UIDs/GIDs, for
   persistent use on the host.
6) Eventually move to a big enough ID space that reuse becomes
   irrelevant, and then allow users to obtain larger blocks of IDs for
   container use.

Effectively, treat ID numbers as magic rotating implementation details
that nobody should care about, and names as the primary identifier.

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


[systemd-devel] [PATCHv2] TODO: journal enhancements

2013-04-19 Thread Josh Triplett
---

Resubmitting the uncontroversial bits.

 TODO | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/TODO b/TODO
index 88be72d..33c24ea 100644
--- a/TODO
+++ b/TODO
@@ -272,6 +272,8 @@ Features:
   - journal: store euid in journal if it differs from uid
   - journal: sanely deal with entries which are larger than the individual 
file size, but where the components would fit
   - journalctl: make journalctl smarter, and actually check groups that have 
access to /var/log/journal before printing message about recomming group 
membership for journal access
+  - Replace utmp, wtmp, btmp, and lastlog completely with journal
+  - Port upower to use the journal for historical power information used in 
future calculations
 
 * document:
   - document unit_name_mangle()
-- 
1.8.2.1

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


[systemd-devel] [PATCH] systemd-logind: Fix linking by reordering libraries in LDADD

2013-04-18 Thread Josh Triplett
libsystemd-audit needs functions from libsystemd-shared, so
libsystemd-audit needs to appear first.  Otherwise:

  CCLD   systemd-logind
./.libs/libsystemd-audit.a(audit.o): In function `audit_session_from_pid':
/home/josh/src/systemd/src/shared/audit.c:50: undefined reference to 
`detect_container'
---
 Makefile.am |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Makefile.am b/Makefile.am
index 7b4b2d8..dede567 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3461,8 +3461,8 @@ systemd_logind_CFLAGS = \
 
 systemd_logind_LDADD = \
libsystemd-label.la \
-   libsystemd-shared.la \
libsystemd-audit.la \
+   libsystemd-shared.la \
libsystemd-daemon.la \
libsystemd-dbus.la \
libudev.la
-- 
1.7.10.4

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


[systemd-devel] [PATCH] TODO: timer unit generation

2013-04-17 Thread Josh Triplett
---
 TODO |1 +
 1 file changed, 1 insertion(+)

diff --git a/TODO b/TODO
index 48e5d2e..eb482d0 100644
--- a/TODO
+++ b/TODO
@@ -320,6 +320,7 @@ Features:
 o CLOCK_REALTIME makes jumps (TFD_TIMER_CANCEL_ON_SET)
 o DST changes
   - Support 2012-02~4 as syntax for specifying the fourth to last day of the 
month.
+  - unit generator for compatibility with crontab and cron.d
 
 * update the kernel's TZ (sys_tz) when DST changes
 
-- 
1.7.10.4

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


[systemd-devel] [PATCH] TODO: add various journal enhancements

2013-04-17 Thread Josh Triplett
---
 TODO |7 +++
 1 file changed, 7 insertions(+)

diff --git a/TODO b/TODO
index 88be72d..48e5d2e 100644
--- a/TODO
+++ b/TODO
@@ -272,6 +272,13 @@ Features:
   - journal: store euid in journal if it differs from uid
   - journal: sanely deal with entries which are larger than the individual 
file size, but where the components would fit
   - journalctl: make journalctl smarter, and actually check groups that have 
access to /var/log/journal before printing message about recomming group 
membership for journal access
+  - Replace utmp, wtmp, btmp, and lastlog completely with journal
+  - Provide one or more FUSE filesystems:
+- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials for 
all writes rather than limiting permissions
+- Provide /var/spool/crash or equivalent, exposing an index of coredumps 
directly
+- Provide decoded text logs in /var/log
+  - Port upower to use the journal for historical power information used in 
future calculations
+  - Support optional database-style indexes for frequent or 
performance-critical queries
 
 * document:
   - document unit_name_mangle()
-- 
1.7.10.4

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


[systemd-devel] [PATCH] TODO: passwd.d, group.d

2013-04-17 Thread Josh Triplett
---
 TODO |5 +
 1 file changed, 5 insertions(+)

diff --git a/TODO b/TODO
index eb482d0..6cf632a 100644
--- a/TODO
+++ b/TODO
@@ -679,6 +679,11 @@ External:
- put bootcharts in the journal
- kernel cmdline bootchart option for simplicity?
 
+* Support passwd.d and group.d; accumulate a persistent name/number map, to
+  preserve UID/GID assignments without requiring assignment of unique IDs at
+  adduser time.  Allows installing users without maintainer scripts, and makes
+  UID namespaces easier to manage.
+
 Regularly:
 
 * look for close() vs. close_nointr() vs. close_nointr_nofail()
-- 
1.7.10.4

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


Re: [systemd-devel] [PATCH] TODO: timer unit generation

2013-04-17 Thread Josh Triplett
On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote:
 On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org wrote:
 
  +  - unit generator for compatibility with crontab and cron.d
 
 We kind of decided to port the 40-60 things that use the .d/ dirs to
 native units right away, and leave cron as it is, and not parse its
 config files from systemd.
 
 If people want cron, they should install it; new or common stuff
 should just not pull it in anymore. The default install should not
 require it.

I figured this fell in the general area of wouldn't do it ourselves,
but would probably take a clean patch, which seemed like a good use of
TODO.

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


Re: [systemd-devel] [PATCH] TODO: add various journal enhancements

2013-04-17 Thread Josh Triplett
On Thu, Apr 18, 2013 at 12:12:38AM +0200, Kay Sievers wrote:
 On Wed, Apr 17, 2013 at 11:49 PM, Josh Triplett j...@joshtriplett.org wrote:
 
  +  - Replace utmp, wtmp, btmp, and lastlog completely with journal
 
 We should definitely add the data needed to constuct this information,
 if they are not already there.
 
 The tools could just use the journal directly, but there is the glibc api.

Exactly; barring a compatibility library that provides the same
functions as glibc, which seems hazardous, I'd like to support tools
that only know how to read and write those files directly.

  +  - Provide one or more FUSE filesystems:
  +- Emulate utmp, wtmp, btmp, lastlog; read/write, recording credentials 
  for all writes rather than limiting permissions
 
 That sounds like overkill. We should surely externalize the creation
 of the files from systemd and make it optional to support legacy
 stuff, otherwise these files should rather be phased out, than
 emulated, I think.

Separate, external, and optional, definitely; no sense running it if you
have no tools around that read or write the format directly.  But given
that the glibc API (and corresponding expectations about the file
format) will exist forever, it seems sensible to have a way to support
that without actually having the files on the filesystem.

  +- Provide /var/spool/crash or equivalent, exposing an index of 
  coredumps directly
 
 Coredump are really not consumed by any legacy thing that would need a
 file system. What do you have in mind here. Specialized apps that need
 that should just use the native API, not expect a file system, I
 think.

Just an idea for how to better satisfy user expectations.  Approximately
zero cost, mounted on demand, gives a view into the journal.

  +- Provide decoded text logs in /var/log
 
 I really don't think these plain text streams make much sense today.
 If people want them, they should install syslog. Or some other project
 can do that, I'm confident we do not want that code in systemd.

Maintaining a separate copy of log messages seems like overkill; I want
the data stored solely in the journal.  And I agree that the code
doesn't belong in the journal itself; I'm suggesting that a standalone
FUSE filesystem based on the journal library would prove useful for
compatibility with both tools that want to consume the log format and
users used to /var/log.  Seems pretty trivial to write, as well.

  +  - Port upower to use the journal for historical power information used 
  in future calculations
 
 Yeah, that would be useful.
 
  +  - Support optional database-style indexes for frequent or 
  performance-critical queries
 
 Well, it is not a database, it's a pretty specialized format based on
 bisection lists. What specific thing do you have in mind?

Telling the journal in advance that you'd like to make a lot of queries
for PROPERTY, or for PROPERTY=value, and having it maintain an index
that makes such queries faster than a linear scan and filter.

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


Re: [systemd-devel] [PATCH] TODO: timer unit generation

2013-04-17 Thread Josh Triplett
On Thu, Apr 18, 2013 at 12:15:22AM +0200, Kay Sievers wrote:
 On Thu, Apr 18, 2013 at 12:11 AM, Josh Triplett j...@joshtriplett.org wrote:
  On Thu, Apr 18, 2013 at 12:04:24AM +0200, Kay Sievers wrote:
  On Wed, Apr 17, 2013 at 11:50 PM, Josh Triplett j...@joshtriplett.org 
  wrote:
 
   +  - unit generator for compatibility with crontab and cron.d
 
  We kind of decided to port the 40-60 things that use the .d/ dirs to
  native units right away, and leave cron as it is, and not parse its
  config files from systemd.
 
  If people want cron, they should install it; new or common stuff
  should just not pull it in anymore. The default install should not
  require it.
 
  I figured this fell in the general area of wouldn't do it ourselves,
  but would probably take a clean patch, which seemed like a good use of
  TODO.
 
 Not really, we cannot or don't want to cover all of cron, so cron
 stays around anyway for the grey beards, or existing things out there.

As far as I can tell, timer units already support almost everything
crontabs do; the problem then just becomes a format parser and unit
generator.

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


[systemd-devel] [PATCH] TODO: uses for SO_REUSEPORT

2013-03-15 Thread Josh Triplett
The new socket option SO_REUSEPORT would enable some new functionality;
add it to TODO.
---
 TODO |5 +
 1 file changed, 5 insertions(+)

diff --git a/TODO b/TODO
index f1a0bcf..f469e96 100644
--- a/TODO
+++ b/TODO
@@ -46,6 +46,11 @@ Fedora 19:
 
 Features:
 
+* Support SO_REUSEPORT with socket activation:
+  - Let systemd maintain a pool of servers.
+  - Use for seamless upgrades, by running the new server before stopping the
+old.
+
 * BootLoaderSpec: drop allowing ext234 for $BOOT. Clarify that the
   kernel has to be in $BOOT. Clarify that the boot loader should be
   installed to the ESP. Define a way how an installer can figure out
-- 
1.7.10.4

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


Re: [systemd-devel] PATCH: fix sparse warnings

2012-03-14 Thread Josh Triplett
On Wed, Mar 14, 2012 at 06:58:32PM +0100, Lennart Poettering wrote:
 On Wed, 07.03.12 06:34, Josh Triplett (j...@joshtriplett.org) wrote:
  I've attached a header file which should provide all the endianness
  checking you need.  Just include it in place of endian.h everywhere you
  currently include endian.h.  I stuck an all-permissive MIT license on
  it, for maximum possible reuse.
 
 This looks really cool! Thanks a lot for this. One comment, before we
 stick this into systemd:
 
  #ifndef SPARSE_ENDIAN_H
  #define SPARSE_ENDIAN_H
  
  #include endian.h
  #include stdint.h
  
  #ifdef __CHECKER__
  #define __bitwise __attribute__((bitwise))
  #define __force __attribute__((force))
  #else
  #define __bitwise
  #define __force
  #endif
  
  typedef uint16_t __bitwise le16;
  typedef uint16_t __bitwise be16;
  typedef uint32_t __bitwise le32;
  typedef uint32_t __bitwise be32;
  typedef uint64_t __bitwise le64;
  typedef uint64_t __bitwise be64;
 
 Can we add a suffix _t here? I much prefer le16_t over le16, since this
 is a type.

Sure, feel free.  I used the unsuffixed names to match the kernel's type
names and the names used in the conversion functions, but the endianness
checking will obviously work with whatever names you prefer. :)

The following sed line will give you the names you want:

sed -i 's/\[bl]e\(16\|32\|64\)\/_t/g' sparse-endian.h

 (and also, emacs' recognizes this and highlights it differently ;-))

I just checked with emacs -q, and at least on my system emacs seems to
correctly identify and highlight all six of those names as types by
default, in all the contexts I can think of where a type can appear.

Take a look at
https://www.gnu.org/software/emacs/manual/html_node/ccmode/Font-Locking-Preliminaries.html
; you may want to make sure you have your font-lock level set
sufficiently high.

 Thanks!

No problem; I look forward to seeing what endianness bugs you can squash
with this. :)

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


Re: [systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc

2011-08-24 Thread Josh Triplett
On Wed, Aug 24, 2011 at 08:39:38PM +0200, Lennart Poettering wrote:
 On Sat, 06.08.11 15:48, Josh Triplett (j...@joshtriplett.org) wrote:
 
  Many people prefer to avoid clearing /tmp and /var/tmp, and
  distributions often have explicit settings for how often to clear them
  if at all.  Overriding those with systemd currently requires overriding
  all of /usr/lib/tmpfiles.d/systemd.conf via
  /etc/tmpfiles.d/systemd.conf, copying across all the other entries, and
  updating that override when systemd.conf changes.
  
  Move the /tmp and /var/tmp entries from systemd.conf to a separate
  tmp.conf, making them easier to override without affecting the rest of
  systemd.conf.
 
 Applied. Thanks!

Excellent, thank you!

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


Re: [systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc

2011-08-16 Thread Josh Triplett
On Mon, Aug 15, 2011 at 04:25:58PM +0200, jean-michel.poll...@laposte.net wrote:
 Regarding this issue, there's also the fact that the default files do not 
 clear /tmp as they are.
 Is it OK to default the type to D instead of d for /tmp in the 
 systemd.conf file, so that it is cleared on boot?

Files in /tmp get cleared when older than 10 days; that seems like a
fine default.

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


[systemd-devel] [PATCH] Move /tmp and /var/tmp to a separate tmpfiles.d file to ease overrides via /etc

2011-08-06 Thread Josh Triplett
Many people prefer to avoid clearing /tmp and /var/tmp, and
distributions often have explicit settings for how often to clear them
if at all.  Overriding those with systemd currently requires overriding
all of /usr/lib/tmpfiles.d/systemd.conf via
/etc/tmpfiles.d/systemd.conf, copying across all the other entries, and
updating that override when systemd.conf changes.

Move the /tmp and /var/tmp entries from systemd.conf to a separate
tmp.conf, making them easier to override without affecting the rest of
systemd.conf.
---

This change will allow me to create a personal package which ships
/etc/tmpfiles.d/tmp.conf, without having to include the remainder of
systemd.conf and update the package every time systemd.conf changes.

 Makefile.am |1 +
 tmpfiles.d/systemd.conf |3 ---
 tmpfiles.d/tmp.conf |   12 
 3 files changed, 13 insertions(+), 3 deletions(-)
 create mode 100644 tmpfiles.d/tmp.conf

diff --git a/Makefile.am b/Makefile.am
index b9c8074..2dc3579 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -285,6 +285,7 @@ dist_bashcompletion_DATA = \
 
 dist_tmpfiles_DATA = \
tmpfiles.d/systemd.conf \
+   tmpfiles.d/tmp.conf \
tmpfiles.d/x11.conf
 
 if HAVE_SYSV_COMPAT
diff --git a/tmpfiles.d/systemd.conf b/tmpfiles.d/systemd.conf
index 7d4b356..be29c06 100644
--- a/tmpfiles.d/systemd.conf
+++ b/tmpfiles.d/systemd.conf
@@ -13,9 +13,6 @@ F /run/utmp 0664 root utmp -
 f /var/log/wtmp 0664 root utmp -
 f /var/log/btmp 0600 root utmp -
 
-d /tmp 1777 root root 10d
-d /var/tmp 1777 root root 30d
-
 d /var/cache/man - - - 30d
 
 r /forcefsck
diff --git a/tmpfiles.d/tmp.conf b/tmpfiles.d/tmp.conf
new file mode 100644
index 000..8915b82
--- /dev/null
+++ b/tmpfiles.d/tmp.conf
@@ -0,0 +1,12 @@
+#  This file is part of systemd.
+#
+#  systemd is free software; you can redistribute it and/or modify it
+#  under the terms of the GNU General Public License as published by
+#  the Free Software Foundation; either version 2 of the License, or
+#  (at your option) any later version.
+
+# See tmpfiles.d(5) for details
+
+# Clear tmp directories separately, to make them easier to override
+d /tmp 1777 root root 10d
+d /var/tmp 1777 root root 30d
-- 
1.7.5.4

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


[systemd-devel] [PATCH] Remove X11 lock files for displays :10 and higher too

2011-08-06 Thread Josh Triplett
---

Using .X[0-9]*-lock seems safe to me, but if you prefer I can write
separate lines for [0-9], [0-9][0-9], and [0-9][0-9][0-9].  Now if only
tmpfiles.d could do regexes or extglob rather than just shell-style
globs. :)

 tmpfiles.d/x11.conf |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/tmpfiles.d/x11.conf b/tmpfiles.d/x11.conf
index 5072b58..7f81af6 100644
--- a/tmpfiles.d/x11.conf
+++ b/tmpfiles.d/x11.conf
@@ -15,4 +15,4 @@ d /tmp/.font-unix 1777 root root 10d
 d /tmp/.Test-unix 1777 root root 10d
 
 # Unlink the X11 lock files
-r /tmp/.X[0-9]-lock
+r /tmp/.X[0-9]*-lock
-- 
1.7.5.4

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


[systemd-devel] What makes systemd-nspawn not suitable for secure container setups?

2011-04-23 Thread Josh Triplett
The systemd-nspawn manpage lists the various mechanisms used to isolate
the container, and then says Note that even though these security
precautions are taken systemd-nspawn is not suitable for secure
container setups. Many of the security features may be circumvented and
are hence primarily useful to avoid accidental changes to the host
system from the container.

How can a process in a systemd-nspawn container circumvent the container
setup?  What additional steps would systemd-nspawn need to take to
provide a secure container setup?

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


[systemd-devel] What makes systemd-nspawn not suitable for secure container setups?

2011-04-22 Thread Josh Triplett
The systemd-nspawn manpage lists the various mechanisms used to isolate
the container, and then says Note that even though these security
precautions are taken systemd-nspawn is not suitable for secure
container setups. Many of the security features may be circumvented and
are hence primarily useful to avoid accidental changes to the host
system from the container.

How can a process in a systemd-nspawn container circumvent the container
setup?  What additional steps would systemd-nspawn need to take to
provide a secure container setup?

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


Re: [systemd-devel] What makes systemd-nspawn not suitable for secure container setups?

2011-04-22 Thread Josh Triplett
On Sat, Apr 23, 2011 at 11:28:58AM +0800, microcai wrote:
 于 2011年04月23日 10:55, Josh Triplett 写道:
  The systemd-nspawn manpage lists the various mechanisms used to isolate
  the container, and then says Note that even though these security
  precautions are taken systemd-nspawn is not suitable for secure
  container setups. Many of the security features may be circumvented and
  are hence primarily useful to avoid accidental changes to the host
  system from the container.
  
  How can a process in a systemd-nspawn container circumvent the container
 
 remount /proc and /sys

Ah, good point.  So, root inside the container can trivially circumvent
the container that way.  Any way to prevent that with current kernel
support, or would fixing this require additional kernel changes to lock
down other /proc and /sys mounts?

That particular problem only applies if running code within the
container as root.  How about if running code as an unprivileged user?
With that addition, does systemd-nspawn provide a secure container
(modulo local privilege escalation vulnerabilities)?

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