Re: [systemd-devel] Latest SELinux Access Patch.
On Thu, 06.09.12 16:23, Daniel J Walsh (dwa...@redhat.com) wrote: Heya, sory for taking so much time for a review! > This patch adds the ability to look at the calling process that is trying to > do dbus calls into systemd, then it checks with the SELinux policy to see if > the calling process is allowed to do the activity. > > The basic idea is we want to allow NetworkManager_t to be able to start and > stop ntpd.service, but not necessarly mysqld.service. > > Similarly we want to allow a root admin webadm_t that can only manage the > apache environment. systemctl enable httpd.service, systemctl disable > iptables.service bad. > > To make this code cleaner, we really need to refactor the dbus-manager.c code. > This has just become a huge if-then-else blob, which makes doing the correct > check difficult. This looked pretty good to me, and so I have merged this now. I made a couple of changes afterwards: - I turned the method table into a null char separated string. THis should make things a bit more readable, and get rid of a lot of relocations. I do have suspicion though that many of entries that are currently in there are not right, they should be reviewed again. - The audit data is now retrieved via the library calls we already had in util.c for this. - We should prefer the source path over the fragment path for a unit when detecting the label. The fragment path might be auto-generated, while the source path is the source of the auto-generation. I have changed the sources accordingly. I'd like to see one more thing changed: - Share more code wiht the rest of the SELinux bits in systemd, for example the caching of whether selinux is enabled or not. Otherwise looks pretty OK to me now. Please have another look on what I merged, in case I broke somethng with my changes. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 3/3] journalctl: add SIGWINCH handler in --follow mode
Recalculate the terminal size on SIGWINCH to make sure we take in to
the account the new real estate.
---
src/journal/journalctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/src/journal/journalctl.c b/src/journal/journalctl.c
index 8e52dd5..a04bb05 100644
--- a/src/journal/journalctl.c
+++ b/src/journal/journalctl.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -78,6 +79,10 @@ static enum {
ACTION_DISK_USAGE,
} arg_action = ACTION_SHOW;
+static recalc_columns(int _unused_ signum) {
+columns_uncached();
+}
+
static int help(void) {
printf("%s [OPTIONS...] [MATCH]\n\n"
@@ -175,6 +180,7 @@ static int parse_argv(int argc, char *argv[]) {
case 'f':
arg_follow = true;
+signal(SIGWINCH, recalc_columns);
break;
case 'o':
--
1.7.12
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] bash-completion: add rumidentary support for journalctl
---
bash-completion/systemd-bash-completion.sh | 51 ++
1 file changed, 51 insertions(+)
diff --git a/bash-completion/systemd-bash-completion.sh
b/bash-completion/systemd-bash-completion.sh
index fc2dda5..39ef165 100644
--- a/bash-completion/systemd-bash-completion.sh
+++ b/bash-completion/systemd-bash-completion.sh
@@ -279,3 +279,54 @@ _loginctl () {
return 0
}
complete -F _loginctl loginctl
+
+_journalctl() {
+local cur=${COMP_WORDS[COMP_CWORD]} prev=${COMP_WORDS[COMP_CWORD-1]}
+local -A OPTS=(
+[STANDALONE]='-a --all -b --this-boot -f --follow --header
+ -h --help -l --local --new-id128 --no-pager
+ --no-tail -q --quiet --setup-keys --verify
--version'
+[ARG]='-D --directory --interval -n --lines -o --output
+ -p --priority --verify-key'
+)
+local journal_fields=(MESSAGE{,_ID} PRIORITY CODE_{FILE,LINE,FUNC}
+ ERRNO SYSLOG_{FACILITY,IDENTIFIER,PID}
+ _{P,U,G}ID _COMM _EXE _CMDLINE
+ _AUDIT_{SESSION,LOGINUID}
+ _SYSTEMD_{CGROUP,SESSION,UNIT,OWNER_UID}
+ _SELINUX_CONTEXT _SOURCE_REALTIME_TIMESTAMP
+ _{BOOT,MACHINE}_ID _HOSTNAME _TRANSPORT
+ _KERNEL_{DEVICE,SUBSYSTEM}
+ _UDEV_{SYSNAME,DEVNODE,DEVLINK}
+ __CURSOR __{REALTIME,MONOTONIC}_TIMESTAMP)
+
+
+if __contains_word "$prev" ${OPTS[ARG]}; then
+case $prev in
+--directory|-D|--verify-key)
+comps=$(compgen -A file -- "$cur")
+compopt -o filenames
+;;
+--output|-o)
+comps='short short-monotonic verbose export
json cat'
+;;
+*)
+return 0
+;;
+esac
+COMPREPLY=( $(compgen -W '$comps' -- "$cur") )
+return 0
+fi
+
+if [[ $cur = -* ]]; then
+COMPREPLY=( $(compgen -W '${OPTS[*]}' -- "$cur") )
+return 0
+else
+# append an '=' to the end of the completed field
+# TODO: would be nice to be able to tell readline here not to
+# append an extra space after the completed word, if such an
+# option exists.
+COMPREPLY=( $(compgen -W '${journal_fields[*]/%/=}' -- "$cur")
)
+fi
+}
+complete -F _journalctl journalctl
--
1.7.12
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] bash-completion: fix whitespace
Use spaces for indentation instead of tabs.
---
bash-completion/systemd-bash-completion.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/bash-completion/systemd-bash-completion.sh
b/bash-completion/systemd-bash-completion.sh
index 39ef165..db5636b 100644
--- a/bash-completion/systemd-bash-completion.sh
+++ b/bash-completion/systemd-bash-completion.sh
@@ -143,16 +143,16 @@ _systemctl () {
elif __contains_word "$verb" ${VERBS[STARTABLE_UNITS]}; then
comps=$( __filter_units_by_property CanStart yes \
$( __get_inactive_units \
- | while read -r line; do \
- [[ "$line" =~ \.(device|snapshot)$ ]] || printf
"%s\n" "$line"; \
- done ))
+| while read -r line; do \
+[[ "$line" =~ \.(device|snapshot)$ ]] ||
printf "%s\n" "$line"; \
+done ))
elif __contains_word "$verb" ${VERBS[RESTARTABLE_UNITS]}; then
comps=$( __filter_units_by_property CanStart yes \
$( __get_all_units \
- | while read -r line; do \
- [[ "$line" =~ \.(device|snapshot|socket|timer)$
]] || printf "%s\n" "$line"; \
- done ))
+| while read -r line; do \
+[[ "$line" =~
\.(device|snapshot|socket|timer)$ ]] || printf "%s\n" "$line"; \
+done ))
elif __contains_word "$verb" ${VERBS[STOPPABLE_UNITS]}; then
comps=$( __filter_units_by_property CanStop yes \
--
1.7.12
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [HEADS-UP] Early-boot SysV service support is going away
Heya, In a month or two we'll make the SysV service logic in systemd generator-based. This helps us clean up our codebase a bit and makes SysV service support an optional plugin rather than something that is built into PID1. Effectively, by doing this move very little will change in behaviour for SysV scripts, with one exception however: we will remove support for early-boot SysV scripts. Early-boot SysV scripts are those for the special "S", "boot", or "b" runlevel that exist on some distributions. These runlevels are highly distro specific, have never been really standardized and are really cumbersome to support right now with a lot of per-distribution hacks. Please do not misunderstand this: it's one thing supporting normal SysV scripts, it's another one supporting them in the early boot part of the things. The former is going to stay for a long time, the latter however is going to be removed in a couple of month. Anyway, this is basically just a heads-up about this, so that you folks who still need this can think about good solutions what to do instead. Here's what I can propose: a) port the early-boot init scripts to native systemd units. You probably should do that anyway, and in most cases there should be very little left that systemd doesn't do on its own anyway in the early-boot process. We recommend to go this way, of course. or b) Try to forward-port support for these magic runlvels to what's coming. Probably a lot of work, since due to the conversion to a generator this is a lot more work than it might appear right now. The code structure of the sysv logic will change quite substantially. or c) write an explicit generator for these services, in the specific syntax of your distro. Anyway, please think about it, we'd just like to make you aware of this in time. At least Debian, Suse, Ubuntu, Angstrom appear to be candidates where this lost functionality might be noticable. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Handling lid close in logind?
On Mon, 03.09.12 22:10, Matthias Clasen (matthias.cla...@gmail.com) wrote: > > On Mon, Sep 3, 2012 at 5:17 AM, Richard Hughes wrote: > > > I don't think the desktop guys want any kind of authentication when > > the lid is closed. How feasible would it be to do the suspend when the > > inhibit is removed? I guess then it puts logind into a "active but > > will suspend asap" state which might be difficult to handle. > > As I said on irc, the user experience I envision in this case is: > > - user closes lid > - polkit dialog is shown (not useful because the lid is closed) > - we beep a few times to cause the user to open the lid and see the dialog > - if the lid is not opened, we forcefully suspend after a few seconds > > A similar situation where we can't wait for a policykit dialog to be > answered is emergency shutdown when the battery runs empty. So, what I wonder is: if this inhibitor is supposed to be ignored, why take it in the first place? I mean, the inhibitor is supposed to inhibit, no? To me it appears really as if the inhibitor should not have been taken in the first place/not have been allowed to be taken in the first place, rather then not being honoured after it was successfully taken. Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Cryptsetup on FakeRAID fails with timeout
2012/9/17 Ali Lown : > I am unable to get systemd to mount a LUKS partition on boot. This > LUKS partition (pdc_bhjchdjgaep5) sits on top of a fakeraid mirror set > (pdc_bhjchdjgae) of 2TB disks (sdd,sde). Disclaimer: what I am proposing below is not a solution, just a workaround. Now that a normal "md" raid is able to assemble fake RAIDs perviously handled by dmraid, could you please try to migrate? Just try to assemble md raid as usual, obviously without having run dmraid. You'll get devices like md126_p1 and md126_p2. -- Alexander E. Patrakov ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Cryptsetup on FakeRAID fails with timeout
I am unable to get systemd to mount a LUKS partition on boot. This LUKS partition (pdc_bhjchdjgaep5) sits on top of a fakeraid mirror set (pdc_bhjchdjgae) of 2TB disks (sdd,sde). I am using systemd from scm (f6c2e28b07a0d24c68f7780fc986ac3619fdcbdb). I have also tried systemd 189, and have the same problem there. The relevant line in fstab is: /dev/mapper/cryptmedia /home/ali/media auto defaults,noatime 0 0 and from crypttab: cryptmedia /dev/mapper/pdc_bhjchdjgaep5 - luks,verify Currently, this results in the boot process stalling for 90 seconds (default timeout) without ever displaying a password prompt. (No entries appear in /run/systemd/ask-password/) The relevant lines from syslog simply show the timeout 2012-09-17T12:28:45.441746+01:00 alipc-desktop-ex systemd[1]: Expecting device dev-mapper-pdc_bhjchdjgaep5.device... 2012-09-17T12:28:45.441750+01:00 alipc-desktop-ex systemd[1]: Expecting device dev-mapper-cryptmedia.device... 2012-09-17T12:30:15.439580+01:00 alipc-desktop-ex systemd[1]: Job dev-mapper-cryptmedia.device/start timed out. 2012-09-17T12:30:15.441039+01:00 alipc-desktop-ex systemd[1]: Timed out waiting for device dev-mapper-cryptmedia.device. 2012-09-17T12:30:15.442428+01:00 alipc-desktop-ex systemd[1]: Dependency failed for Cryptography Setup for cryptmedia. 2012-09-17T12:30:15.443037+01:00 alipc-desktop-ex systemd[1]: Job systemd-cryptsetup@cryptmedia.service/start failed with result 'dependency'. 2012-09-17T12:30:15.444311+01:00 alipc-desktop-ex systemd[1]: Dependency failed for /home/ali/media. 2012-09-17T12:30:15.445105+01:00 alipc-desktop-ex systemd[1]: Job home-ali-media.mount/start failed with result 'dependency'. 2012-09-17T12:30:15.445750+01:00 alipc-desktop-ex systemd[1]: Job dev-mapper-cryptmedia.device/start failed with result 'timeout'. 2012-09-17T12:30:15.446486+01:00 alipc-desktop-ex systemd[1]: Job dev-mapper-pdc_bhjchdjgaep5.device/start timed out. Notably, running the commands in systemd-cryptsetup@cryptmedia.service manually works correctly, so this seems to be a problem with how systemd is trying to run the commands. Do you have any ideas how I can debug this 'timeout'? Is it a problem due to the FakeRAID device not being a 'real' drive, so udev not reporting something correctly? Thanks in advance. Ali ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] gps.target
On Sat, 15.09.12 00:35, shawn (shawnland...@gmail.com) wrote: > I noticed that "gps.target" (along with: fingerprint.target, > wireless.target, netdevice.target) were in the proposed feature list, > and I am wonder how this would work. > > most usb gps devices, which are the vast majority of devices out there > and supported by gpsd, are usb-to-serial converters, and by product:id > and in udev are not distinguishable as gps devices: udev must call gpsd > which will then probe the device and figure out if it is a gps device > before letting go of it. > > Anyways, I was wonder what the gps.target idea was--what would trigger > it? gpsd through this udev stuff already launches automatically when a > usb gps device is inserted (although it never shuts down by itsself) Well, the TODO list is mostly about things we should investigate I guess, not necessarily stuff we should implement 1:1... ;-) I have no experience with GPS devices I must say. I assumed we could detect many of them (not necessarily all) and pull in a target, which then could pull in things. I kinda like the indirection of that, since it makes it easily possible to enable/these services with "systemctl enable" and friends. We often have the probs of not being able to detect many devices properly. But there are always chances to get something working, for example a tiny udev helper which looks in some meta data (or even talks over the serial) and adds the results as udev props to the device. How is gpsd currently started from udev? Note that on systemd systems udev will kill all long running processes spawned from udev rules these days, people need to do things with SYSTEMD_WANTS instead. udev is not supposed to be a framework for spawning forking daemons inline... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn does not mount /dev/shm
On Sat, 15.09.12 21:57, Pierre Schmitz (pie...@archlinux.de) wrote: > Hi, > > systemd-nspawn does not create a tmpfs mount to /dev/shm. Is this an > oversight or intentional? The original intention here was to mount only the stuff that is necessary to get a system booted up safely in place. i.e. we mount /dev because we populate it with the safe subset of device nodes. And we mount /proc, so that we can mount /proc/sys read-only into it. But for /dev/shm there was simply no real reason for, since the OS booted in it could just do that safely on its own. That said, I do actually agree it is useful to just pre-mount it these days, too, for three reasons: a) it's kinda surprising that we mount all the rest, just not this one, so let's just go for it; b) for people who just spawn a shell in it rather than a full OS it makes life simpler; c) it probably makes sense to do this to make boots without CAP_SYS_ADMIN possible. (right now we hard add CAP_SYS_ADMIN for nspawn containers, but we could actully make that optional, and should.) Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] nspawn does not mount /dev/shm
On Sun, 16.09.12 17:08, Kay Sievers (k...@vrfy.org) wrote: > On Sun, Sep 16, 2012 at 4:25 PM, Zbigniew Jędrzejewski-Szmek > wrote: > > On Sat, Sep 15, 2012 at 09:57:00PM +0200, Pierre Schmitz wrote: > >> > >> systemd-nspawn does not create a tmpfs mount to /dev/shm. Is this an > >> oversight or intentional? > > nspawn has recently grown abilities to add /dev/fd, /dev/stdin, > > /dev/stdout, /dev/stderr. I think that /dev/shm should be added to. > > I pushed a change to do that to git now. > > Ugh, /dev is a tmpfs already. Why do we want another one on top? Probably makes sense since people might want different mount options on it, later (applied via fstab), and it might be a good idea to separate the world-writable /dev/shm from /dev, for quota reasons. (I mean, you know the DoS, and in this case it is simply to fix by using a separate mount for this... Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/4] man: generate an index of directives
On Mon, 17.09.12 11:04, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > On 09/17/2012 10:55 AM, Lennart Poettering wrote: > > On Sun, 16.09.12 17:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > >> Systemd has a large (and growing) number of manpages. Sometimes it's > >> not immediately obvious, where to look for a directive. Especially, > >> when something is described in more than one place. Making sense of > >> all the settings should be easier with an index. > >> --- > >> Seems useful to me, but might be a bit over-complicated. Thoughts? > > > > Interesting idea. I think I like it. I am too lazy to have a look at how > > the result looks. Could you upload the generated .html man page > > somewhere? > > http://in.waw.pl/~zbyszek/systemd-man/systemd.directives.html > http://in.waw.pl/~zbyszek/systemd-man/systemd.directives.5 Looks useful. Please commit! Though I'd like to see "Systemd directives" changed to "System Manager Directives" or so, to clarify that this is about PID 1 itself. Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/4] man: generate an index of directives
On 09/17/2012 10:55 AM, Lennart Poettering wrote: > On Sun, 16.09.12 17:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > >> Systemd has a large (and growing) number of manpages. Sometimes it's >> not immediately obvious, where to look for a directive. Especially, >> when something is described in more than one place. Making sense of >> all the settings should be easier with an index. >> --- >> Seems useful to me, but might be a bit over-complicated. Thoughts? > > Interesting idea. I think I like it. I am too lazy to have a look at how > the result looks. Could you upload the generated .html man page > somewhere? http://in.waw.pl/~zbyszek/systemd-man/systemd.directives.html http://in.waw.pl/~zbyszek/systemd-man/systemd.directives.5 Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [RFC PATCH 1/4] man: generate an index of directives
On Sun, 16.09.12 17:43, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > Systemd has a large (and growing) number of manpages. Sometimes it's > not immediately obvious, where to look for a directive. Especially, > when something is described in more than one place. Making sense of > all the settings should be easier with an index. > --- > Seems useful to me, but might be a bit over-complicated. Thoughts? Interesting idea. I think I like it. I am too lazy to have a look at how the result looks. Could you upload the generated .html man page somewhere? Thanks! Lennart -- Lennart Poettering - Red Hat, Inc. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
