Re: [systemd-devel] [PATCH 1/2] test: add basic seccomp tests
On Thu, Jan 23, 2014 at 01:34:57AM +0100, Ronny Chevalier wrote:
> ---
> test/TEST-04-SECCOMP/Makefile | 1 +
> test/TEST-04-SECCOMP/test-seccomp.sh| 11
> test/TEST-04-SECCOMP/test.sh| 79
> +
> test/TEST-04-SECCOMP/will-fail.service | 6 +++
> test/TEST-04-SECCOMP/will-not-fail.service | 6 +++
> test/TEST-04-SECCOMP/will-not-fail2.service | 6 +++
> 6 files changed, 109 insertions(+)
> create mode 12 test/TEST-04-SECCOMP/Makefile
> create mode 100755 test/TEST-04-SECCOMP/test-seccomp.sh
> create mode 100755 test/TEST-04-SECCOMP/test.sh
> create mode 100644 test/TEST-04-SECCOMP/will-fail.service
> create mode 100644 test/TEST-04-SECCOMP/will-not-fail.service
> create mode 100644 test/TEST-04-SECCOMP/will-not-fail2.service
>
> diff --git a/test/TEST-04-SECCOMP/Makefile b/test/TEST-04-SECCOMP/Makefile
> new file mode 12
> index 000..e9f93b1
> --- /dev/null
> +++ b/test/TEST-04-SECCOMP/Makefile
> @@ -0,0 +1 @@
> +../TEST-01-BASIC/Makefile
> \ No newline at end of file
> diff --git a/test/TEST-04-SECCOMP/test-seccomp.sh
> b/test/TEST-04-SECCOMP/test-seccomp.sh
> new file mode 100755
> index 000..fef334e
> --- /dev/null
> +++ b/test/TEST-04-SECCOMP/test-seccomp.sh
> @@ -0,0 +1,11 @@
> +#!/bin/bash -x
> +
> +systemctl start will-fail.service
> +systemctl start will-not-fail.service
> +systemctl start will-not-fail2.service
> +systemctl is-failed will-fail.service | grep failed || exit 1
> +systemctl is-failed will-not-fail.service | grep failed && exit 1
> +systemctl is-failed will-not-fail2.service | grep failed && exit 1
This is weird. You should be able to rely on the exit code rather than
parsing the output, but it seems this was broken in e3e0314b.
> +
> +touch /testok
> +exit 0
> diff --git a/test/TEST-04-SECCOMP/test.sh b/test/TEST-04-SECCOMP/test.sh
> new file mode 100755
> index 000..c29192e
> --- /dev/null
> +++ b/test/TEST-04-SECCOMP/test.sh
> @@ -0,0 +1,79 @@
> +#!/bin/bash
> +# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
> +# ex: ts=8 sw=4 sts=4 et filetype=sh
> +TEST_DESCRIPTION="seccomp tests"
> +
> +. $TEST_BASE_DIR/test-functions
> +
> +check_result_qemu() {
> +ret=1
> +mkdir -p $TESTDIR/root
> +mount ${LOOPDEV}p1 $TESTDIR/root
> +[[ -e $TESTDIR/root/testok ]] && ret=0
> +[[ -f $TESTDIR/root/failed ]] && cp -a $TESTDIR/root/failed $TESTDIR
> +cp -a $TESTDIR/root/var/log/journal $TESTDIR
> +umount $TESTDIR/root
> +[[ -f $TESTDIR/failed ]] && cat $TESTDIR/failed
> +ls -l $TESTDIR/journal/*/*.journal
> +test -s $TESTDIR/failed && ret=$(($ret+1))
> +return $ret
> +}
> +
> +test_run() {
> +if run_qemu; then
> +check_result_qemu || return 1
> +else
> +dwarn "can't run QEMU, skipping"
> +fi
> +if check_nspawn; then
> +run_nspawn
> +check_result_nspawn || return 1
> +else
> +dwarn "can't run systemd-nspawn, skipping"
> +fi
> +return 0
> +}
> +
> +test_setup() {
> +create_empty_image
> +mkdir -p $TESTDIR/root
> +mount ${LOOPDEV}p1 $TESTDIR/root
> +
> +# Create what will eventually be our root filesystem onto an overlay
> +(
> +LOG_LEVEL=5
> +eval $(udevadm info --export --query=env --name=${LOOPDEV}p2)
> +
> +setup_basic_environment
> +
> +# setup the testsuite service
> +cat >$initdir/etc/systemd/system/testsuite.service < +[Unit]
> +Description=Testsuite service
> +After=multi-user.target
> +
> +[Service]
> +ExecStart=/test-seccomp.sh
> +Type=oneshot
> +EOF
> +
> +# copy the units used by this test
> +cp {will-fail,will-not-fail,will-not-fail2}.service \
> +$initdir/etc/systemd/system
> +cp test-seccomp.sh $initdir/
> +
> +setup_testsuite
> +)
> +setup_nspawn_root
> +
> +ddebug "umount $TESTDIR/root"
> +umount $TESTDIR/root
> +}
> +
> +test_cleanup() {
> +umount $TESTDIR/root 2>/dev/null
> +[[ $LOOPDEV ]] && losetup -d $LOOPDEV
> +return 0
> +}
> +
> +do_test "$@"
> diff --git a/test/TEST-04-SECCOMP/will-fail.service
> b/test/TEST-04-SECCOMP/will-fail.service
> new file mode 100644
> index 000..18e034e
> --- /dev/null
> +++ b/test/TEST-04-SECCOMP/will-fail.service
> @@ -0,0 +1,6 @@
> +[Unit]
> +Description=Will fail
> +
> +[Service]
> +ExecStart=/bin/echo "This should not be seen"
> +SystemCallFilter=ioperm
> diff --git a/test/TEST-04-SECCOMP/will-not-fail.service
> b/test/TEST-04-SECCOMP/will-not-fail.service
> new file mode 100644
> index 000..c56797f
> --- /dev/null
> +++ b/test/TEST-04-SECCOMP/will-not-fail.service
> @@ -0,0 +1,6 @@
> +[Unit]
> +Description=Will not fail
> +
> +[Service]
> +ExecStart=/bin/echo "Foo bar"
> +SystemCallFilter=~ioctl
> diff --git a/test/TEST-04-SECCOMP/will-not-fail2.service
> b/test/TEST-04-SECCOMP/will-not-fail2.service
> new file mode 100644
> index 000..2df05e3
> --- /dev
Re: [systemd-devel] [PATCH] rules: name Dell iDRAC virtual usb nic
On 02/12/2014 09:21 AM, Kay Sievers wrote: > On Wed, Feb 12, 2014 at 2:12 PM, wrote: > > From: Charles Rose > > > > Dell servers contain a virtual usb nic for systems management. > > Name the device 'idrac' to easily identify it. > > The 75-net-description.rules is doe describe interfaces, not to carry > out any policy. > > Product specific matches do not really belong into default udev rules > shipped by systemd, we should not add more of them. > > They might have a place in the hardware database files. I'm not > exactly sure though, how to apply policy from the hwdb to renaming > network devices, there is no user like that at the moment. > > What tool is supposed to find that named interface? Can't it just ship > that rule in its own file? Kay, The interface is generic in nature and would be used by multiple utilities/applications to access the iDRAC. The web browser, openwsman, ssh might be some of them for now. This can also be used by customers with custom scripts (python/shell) to fetch/set systems management information. > > Kay > ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to prevent sleep during running oneshot units
Am 13.02.2014 00:14 schrieb "Kai Krakow" : > > Mirco Tischler schrieb: > > > It's late here so excuse me if I'm missing something. But wouldn't a > > simple Before=sleep.target suffice to implement b)? > > I'm not sure... The unit is not enabled, only triggered by the timer - so it > may work. I think I may try that as an alternative to systemd-inhibit. > Systemd-inhibit just does not feel like the right tool for this. > > > If your backup job is still running it blocks sleep.target's start until > > it finishes. > > Then, what happens if I start using my system during backup, sleep.target > had been triggered but is waiting for the backup job to finish? Will it > simply go to sleep then while I am using the system? OTOH, will systemd- > inhibit cover that case? > Yeah, the job to start sleep.target will still be active, so this should only work for overnight stuff. > Twisted around: What happens if sleep is triggered by the system due to idle > time while sleep is inhibited? Will it trigger as soon as the inhibit is > removed again? Or will the idle timer for my system just trigger sleep again > after it has passed a second time? > Systemd-inhibit has the options block and delay for this. But when and if the idle time gets restarted is up to the idle timer ;-) > > Though for the grace period some ugly hack such as > > "ExecStartPost=/usr/bin/sleep " would be required. > > My primary concern here is btrfs doing a lot of background work when > handling snapshots. My backup medium is a btrfs with rsync copying the > source as in-place deltas to a scratch area, then taking a snapshot of it. > Later, I'd like to automatically cleanup old snapshots - but that means I > should wait before going back to sleep until btrfs finished that job. A > simple "sleep" probably won't do. I suppose it would require an option like > "--wait" to "btrfs subvolume delete", then wait another 5 minutes to give > all pending write commits a chance to make it to disk. Sounds like you want systemd-inhibit for both your backup service and the btrfs subvolume delete 'service'. And the kernel will call sync() before suspending, shouldn't that suffice? > > -- > Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to prevent sleep during running oneshot units
Mirco Tischler schrieb: > It's late here so excuse me if I'm missing something. But wouldn't a > simple Before=sleep.target suffice to implement b)? I'm not sure... The unit is not enabled, only triggered by the timer - so it may work. I think I may try that as an alternative to systemd-inhibit. Systemd-inhibit just does not feel like the right tool for this. > If your backup job is still running it blocks sleep.target's start until > it finishes. Then, what happens if I start using my system during backup, sleep.target had been triggered but is waiting for the backup job to finish? Will it simply go to sleep then while I am using the system? OTOH, will systemd- inhibit cover that case? Twisted around: What happens if sleep is triggered by the system due to idle time while sleep is inhibited? Will it trigger as soon as the inhibit is removed again? Or will the idle timer for my system just trigger sleep again after it has passed a second time? > Though for the grace period some ugly hack such as > "ExecStartPost=/usr/bin/sleep " would be required. My primary concern here is btrfs doing a lot of background work when handling snapshots. My backup medium is a btrfs with rsync copying the source as in-place deltas to a scratch area, then taking a snapshot of it. Later, I'd like to automatically cleanup old snapshots - but that means I should wait before going back to sleep until btrfs finished that job. A simple "sleep" probably won't do. I suppose it would require an option like "--wait" to "btrfs subvolume delete", then wait another 5 minutes to give all pending write commits a chance to make it to disk. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] How to prevent sleep during running oneshot units
Zbigniew Jędrzejewski-Szmek schrieb: >> No, you need to wrap your command with it. I.e. instead of >> >> ExecStart=/path/to/backup-command ... >> >> you use >> >> ExecStart=/usr/bin/systemd-inhibit /path/to/backup-command ... > Right. Not too bad, but Inhibits=sleep sounds nice. I probably try that, thou I'd prefer an extra configuration option for it because in the jobs monitor it would show me systemd-inhibit as the running process instead of my backup script. >> What a pity. Are there any deeper plans on that one? I think it should >> not be too difficult to implement and if I had some time I would try it. >> But I don't like inventing all the complex surrounding this may bring in, >> read as: Is there a list / brainstorming of what one had to consider and >> take care of? While documentation of systemd is very good and easy to >> follow, I find it difficult to find documentation of implementation >> details and feature plans (yes, there are the blogs but those seem to >> cover thoughts about already implemented features)... > Yes, it seems that basically changing the timer type would do the trick. > One thing which worries me, is the issue the "laptop in the bag" issue. > But maybe we would just need to document the fact that setting the timer > to need to make sure that the computer will not be in hostile surrounding. > OTOH, it might make sense to add a new inhibition: 'alarms', > which you could set *before* suspending, which would prevent > CLOCK_REALTIME_ALARM timers from firing. Your "laptop in a bag" example is that kind of brainstorming I was thinking of. Of course, such an option to resume from sleep should always be opt-in, never opt-out. So, if we had such a new timer type, systemd should have a switch to actually behave this way and default to fall-back behavior (not waking the system). That way, an energy profile in desktop environment could control this switch: Set your profile to "desktop" and it will opt-in to wake timers, set it to "laptop" or "mobile", and it won't opt-in. If battery is below some threshold it sould also not opt-in. My use case is a desktop PC so I didn't think of such issues. I don't like the fact to solely rely on an inhibition "alarms" because that would means it'd be opt-out only. In my opinion it needs to be opt-in. -- Replies to list only preferred. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 2/3] Fix keysize handling in cryptsetup (bits vs. bytes)
The command line key-size is in bits but the libcryptsetup API expects bytes.
---
src/cryptsetup/cryptsetup.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index f72cf9f..e7e8066 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -414,7 +414,7 @@ static int attach_luks_or_plain(struct crypt_device *cd,
/* for CRYPT_PLAIN limit reads
* from keyfile to key length, and
* ignore keyfile-size */
-opt_keyfile_size = opt_key_size / 8;
+opt_keyfile_size = opt_key_size;
/* In contrast to what the name
* crypt_setup() might suggest this
@@ -577,7 +577,11 @@ int main(int argc, char *argv[]) {
else
until = 0;
-opt_key_size = (opt_key_size > 0 ? opt_key_size : 256);
+if (opt_key_size % 8) {
+log_warning("Key size invalid (not a multiple of 8).");
+goto finish;
+}
+opt_key_size = (opt_key_size > 0 ? opt_key_size : 256) / 8;
if (key_file) {
struct stat st;
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] Add more password agent information
Add an (optional) "Id" key in the password agent .ask files. The Id is
supposed to be a simple string in ":" form which
is used to provide more information on what the requested passphrase
is to be used for (which e.g. allows an agent to only react to cryptsetup
requests).
---
src/ask-password/ask-password.c | 14 +++---
src/cryptsetup/cryptsetup.c | 11 +--
src/shared/ask-password-api.c |9 +++--
src/shared/ask-password-api.h |6 --
4 files changed, 31 insertions(+), 9 deletions(-)
diff --git a/src/ask-password/ask-password.c b/src/ask-password/ask-password.c
index ea0c623..f939eab 100644
--- a/src/ask-password/ask-password.c
+++ b/src/ask-password/ask-password.c
@@ -43,6 +43,7 @@
#include "def.h"
static const char *arg_icon = NULL;
+static const char *arg_id = NULL;
static const char *arg_message = NULL;
static bool arg_use_tty = true;
static usec_t arg_timeout = DEFAULT_TIMEOUT_USEC;
@@ -58,7 +59,8 @@ static int help(void) {
" --timeout=SEC Timeout in sec\n"
" --no-ttyAsk question via agent even on TTY\n"
" --accept-cached Accept cached passwords\n"
- " --multiple List multiple passwords if available\n",
+ " --multiple List multiple passwords if available\n"
+ " --id=ID Query identifier (e.g.
cryptsetup:/dev/sda5)\n",
program_invocation_short_name);
return 0;
@@ -71,7 +73,8 @@ static int parse_argv(int argc, char *argv[]) {
ARG_TIMEOUT,
ARG_NO_TTY,
ARG_ACCEPT_CACHED,
-ARG_MULTIPLE
+ARG_MULTIPLE,
+ARG_ID
};
static const struct option options[] = {
@@ -81,6 +84,7 @@ static int parse_argv(int argc, char *argv[]) {
{ "no-tty",no_argument, NULL, ARG_NO_TTY
},
{ "accept-cached", no_argument, NULL, ARG_ACCEPT_CACHED
},
{ "multiple", no_argument, NULL, ARG_MULTIPLE
},
+{ "id",required_argument, NULL, ARG_ID
},
{}
};
@@ -119,6 +123,10 @@ static int parse_argv(int argc, char *argv[]) {
arg_multiple = true;
break;
+ case ARG_ID:
+ arg_id = optarg;
+break;
+
case '?':
return -EINVAL;
@@ -162,7 +170,7 @@ int main(int argc, char *argv[]) {
} else {
char **l;
-if ((r = ask_password_agent(arg_message, arg_icon, timeout,
arg_accept_cached, &l)) >= 0) {
+if ((r = ask_password_agent(arg_message, arg_icon, arg_id,
timeout, arg_accept_cached, &l)) >= 0) {
char **p;
STRV_FOREACH(p, l) {
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 033c0cd..f72cf9f 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -260,6 +260,7 @@ static int get_password(const char *name, usec_t until,
bool accept_cached, char
int r;
char **p;
_cleanup_free_ char *text = NULL;
+_cleanup_free_ char *id = NULL;
assert(name);
assert(passwords);
@@ -267,7 +268,10 @@ static int get_password(const char *name, usec_t until,
bool accept_cached, char
if (asprintf(&text, "Please enter passphrase for disk %s!", name) < 0)
return log_oom();
-r = ask_password_auto(text, "drive-harddisk", until, accept_cached,
passwords);
+ if (asprintf(&id, "cryptsetup:%s", name) < 0)
+ return log_oom();
+
+r = ask_password_auto(text, "drive-harddisk", id, until,
accept_cached, passwords);
if (r < 0) {
log_error("Failed to query password: %s", strerror(-r));
return r;
@@ -281,7 +285,10 @@ static int get_password(const char *name, usec_t until,
bool accept_cached, char
if (asprintf(&text, "Please enter passphrase for disk %s!
(verification)", name) < 0)
return log_oom();
-r = ask_password_auto(text, "drive-harddisk", until, false,
&passwords2);
+ if (asprintf(&id, "cryptsetup-verification:%s", name) < 0)
+ return log_oom();
+
+r = ask_password_auto(text, "drive-harddisk", id, until,
false, &passwords2);
if (r < 0) {
log_error("Failed to query verification password: %s",
strerror(-r));
return r;
diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index a328f14..1c18274 100644
--- a/src/shared/ask-password-api.c
+++ b/src/shared/ask-password-api.c
@@ -298,6 +298,7 @@ fail:
int ask_password_agent(
[systemd-devel] [PATCH 3/3] Fix askpass buffer overflow
Fix askpass overflow in reading a passphrase from a tty.
Doesn't seem security sensitive, but add a check for correctness.
---
src/shared/ask-password-api.c |5 +
1 file changed, 5 insertions(+)
diff --git a/src/shared/ask-password-api.c b/src/shared/ask-password-api.c
index 1c18274..045cff2 100644
--- a/src/shared/ask-password-api.c
+++ b/src/shared/ask-password-api.c
@@ -213,6 +213,11 @@ int ask_password_tty(
loop_write(ttyfd, "*", 1, false);
dirty = true;
+
+ if (p >= (sizeof(passphrase) - 1)) {
+ loop_write(ttyfd, "\n", 1, false);
+ break;
+ }
}
}
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 0/3] Password agent fixes
The following series contains patch 1 - 3 of the previous patchset that I've posted. Lennart wanted a single "Id=" instead of the two "Purpose=" and "Target=" strings in the .ask files, so I've changed it accordingly. The two following patches are just small fixes. I've left out the binary protocol patch for now. --- David Härdeman (3): Add more password agent information Fix keysize handling in cryptsetup (bits vs. bytes) Fix askpass buffer overflow src/ask-password/ask-password.c | 14 +++--- src/cryptsetup/cryptsetup.c | 19 +++ src/shared/ask-password-api.c | 14 -- src/shared/ask-password-api.h |6 -- 4 files changed, 42 insertions(+), 11 deletions(-) -- David Härdeman ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On Wed, Feb 12, 2014 at 11:12:07PM +0100, Reindl Harald wrote: > > the major point of my critism is systemd-upstream's "release-and-forget" > with no point releases at all and the state of systemd in F20 makes that > not looking like a working strategy overstraining downstream maintainers > > that may work for a browser but not for a core-component of a distruibution > or only in case of luck and not hitted by bugs as we have them now I guess the Linux kernel is not a "core-component" of a distro then, by your definition :) My distro doesn't have this issue, if you have a problem with the distro you are currently using, I suggest talking with them about this, or change to a different one. No one is forcing you to use Fedora... good luck, greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On Wed, Feb 12, 2014 at 11:12 PM, Reindl Harald wrote: > my tone is ok, if someone can't stand critism that's a different problem layer Your tone is not ok. This is a development mailing list and not a bitching or product discussion channel. What you do is not appropriate or welcome here. If that continues, this side of of the "problem layer" will just set you on mailing list moderation again. Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
Am 12.02.2014 22:41, schrieb Jóhann B. Guðmundsson: > On 02/12/2014 07:37 PM, Reindl Harald wrote: >> these are all regressions from F19 to F20 >> https://bugzilla.redhat.com/show_bug.cgi?id=1023820 >> https://bugzilla.redhat.com/show_bug.cgi?id=1010572 >> https://bugzilla.redhat.com/show_bug.cgi?id=1057811 >> https://bugzilla.redhat.com/show_bug.cgi?id=1057618 >> https://bugzilla.redhat.com/show_bug.cgi?id=1023788 >> >> sometimes it feels like systemd-upstrearm has a release-and-forget-strategy >> and don't care about the downstream distributions and issues there nor >> how bad the impact of them for how long is > > I'm not so sure you are aware of this but the major part of systemd > maintenance in > Fedora is and has been handled by Zbyszek for the past year which is doing > that on > his own free time and before him it was Michal who is a Red Hat employee but > working > on completely different thing then systemd and he was also doing systemd > downstream > distribution maintenance on his own free time. i am aware the major point of my critism is systemd-upstream's "release-and-forget" with no point releases at all and the state of systemd in F20 makes that not looking like a working strategy overstraining downstream maintainers that may work for a browser but not for a core-component of a distruibution or only in case of luck and not hitted by bugs as we have them now > Both of them have been doing good job of maintaining systemd in the > distribution > and been extremely conservative in their maintainership extremely conservative would have been keep Fedora 20 on systemd-204 which has none of that problems - systemd-208 obviously has *not* release quality extremely conservative with a stable release: fine extremely conservative with a broken release: not fine, it needs fixes, timly https://bugzilla.redhat.com/show_bug.cgi?id=1023788 reported: 2013-10-27 GA release: 2013-12-17 current:2014-02-12 > so I suggest you keep your tone down towards people contributing their > own free time to the project. my tone is ok, if someone can't stand critism that's a different problem layer i am contributing *my own free time* with testing and bugreports, the last systemd build for F20 was tested, rolled back and commented with feedback minutes after the build completed, so i deserve feedback in a timely manner and not get ignored over months (and i am not the only one) since you are the one fighting against RH on fedora-devel and claiming you are Fedora QA more than once - where where you in case of the bugs above? how did they pass QA if any random tester is facing two of them within minutes? > With regards to those RHEL bugs I suggest you follow Red Hat's official > procedure dealing with those RHEL bugs? maybe read them before make comments and get rid of your hate against Redhat could help, the Fedora bugzilla is below redhat.com and they are all *Fedora* bugs and *one* of them made it to RHEL-Beta *too* signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On 02/12/2014 07:37 PM, Reindl Harald wrote: these are all regressions from F19 to F20 https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788 sometimes it feels like systemd-upstrearm has a release-and-forget-strategy and don't care about the downstream distributions and issues there nor how bad the impact of them for how long is I'm not so sure you are aware of this but the major part of systemd maintenance in Fedora is and has been handled by Zbyszek for the past year which is doing that on his own free time and before him it was Michal who is a Red Hat employee but working on completely different thing then systemd and he was also doing systemd downstream distribution maintenance on his own free time. Both of them have been doing good job of maintaining systemd in the distribution and been extremely conservative in their maintainership so I suggest you keep your tone down towards people contributing their own free time to the project. With regards to those RHEL bugs I suggest you follow Red Hat's official procedure dealing with those and file a support case after all that's what you are paying them for. Ranting on upstream mailinglist will get you nowhere regardless if that upstream is partially on Red Hat's payroll or not... JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On Wed, Feb 12, 2014 at 12:45:50PM -0800, David Timothy Strauss wrote: > On Wed, Feb 12, 2014 at 12:37 PM, Tomasz Torcz wrote: > > That's some downstream distro bug. And this is Fedora mailinglist. > > RHEL issues are offtopic here. > > This is not a Fedora mailing list at all. Ouch. I'm sorry. I thought I was still reading fedora-devel. My apologies to Harald and other readers of systemd-devel. -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." pgp8_mNKZFinb.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On Wed, Feb 12, 2014 at 12:37 PM, Tomasz Torcz wrote: > That's some downstream distro bug. And this is Fedora mailinglist. > RHEL issues are offtopic here. This is not a Fedora mailing list at all. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
my last post for this topic before i get blocked again by disturbing development in peace with real user problems i thought so once per month it's woth to make notice Am 12.02.2014 21:37, schrieb Tomasz Torcz: > On Wed, Feb 12, 2014 at 08:05:47PM +0100, Reindl Harald wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1047614 >> >> Product: Red Hat Enterprise Linux 7 >> Component: systemd (Show other bugs) >> Version: 7.0 > > That's some downstream distro bug this is *the* downstream distro this is *the* employer paing systemd project-leader > And this is Fedora mailinglist > RHEL issues are offtopic here that's new, sadly not true, otherwise the bugreport long before RHEL7-Beta would have prevented to make it in Fedora 20 GA and stay there first reported more than 3 months ago https://bugzilla.redhat.com/show_bug.cgi?id=1023788 signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On Wed, Feb 12, 2014 at 08:05:47PM +0100, Reindl Harald wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1047614 > > Product: Red Hat Enterprise Linux 7 > Component:systemd (Show other bugs) > Version: 7.0 That's some downstream distro bug. And this is Fedora mailinglist. RHEL issues are offtopic here. -- Tomasz Torcz "God, root, what's the difference?" xmpp: zdzich...@chrome.pl "God is more forgiving." ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
Am 12.02.2014 21:19, schrieb Lennart Poettering: > On Wed, 12.02.14 20:05, Reindl Harald (h.rei...@thelounge.net) wrote: > >> https://bugzilla.redhat.com/show_bug.cgi?id=1047614 >> >> Product: Red Hat Enterprise Linux 7 >> Component: systemd (Show other bugs) >> Version: 7.0 >> Hardware:Unspecified Unspecified >> Priority urgent Severity high >> >> first reported more than 3 months ago >> https://bugzilla.redhat.com/show_bug.cgi?id=1023788 >> >> maybe systemd-upstream should consider slow down development >> and spend more energy in quality and stability > > Well, firstly, it's hardly your business how we spend our time firstly it's my business to say my opinion if i get hit by the result daily and as i woke up that morning i saw a free world which permits that your opinion: i do not care about downstream my optinion: bad attitude in case downstream is the public testbed of your employer with the userbase giving you the needed feedback for work in progress on real world setups the truth is likely somewhere between > Secondly, this bug is fixed upstream and that is what i call "release-and-forget" strategy it has not made it in any Fedora package right now http://koji.fedoraproject.org/koji/packageinfo?packageID=10477 and no http://koji.fedoraproject.org/koji/buildinfo?buildID=491024 does not make things better, it breaks systemd-logind and floods logs - i had installed it a few minutes after build and reverted so finally there is no change downstream over months > Thirdly, patches count more than complaining that may be true, if i not would face the same bug and it's friends in F20 day for day i would not need to complain signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On Wed, 12.02.14 20:05, Reindl Harald (h.rei...@thelounge.net) wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1047614 > > Product: Red Hat Enterprise Linux 7 > Component:systemd (Show other bugs) > Version: 7.0 > Hardware: Unspecified Unspecified > Priority urgent Severity high > > first reported more than 3 months ago > https://bugzilla.redhat.com/show_bug.cgi?id=1023788 > > maybe systemd-upstream should consider slow down development > and spend more energy in quality and stability Well, firstly, it's hardly your business how we spend our time. Secondly, this bug is fixed upstream. Thirdly, patches count more than complaining. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
Am 12.02.2014 20:18, schrieb Greg KH: > On Wed, Feb 12, 2014 at 08:05:47PM +0100, Reindl Harald wrote: >> https://bugzilla.redhat.com/show_bug.cgi?id=1047614 >> >> Product: Red Hat Enterprise Linux 7 >> Component: systemd (Show other bugs) >> Version: 7.0 >> Hardware:Unspecified Unspecified >> Priority urgent Severity high >> >> first reported more than 3 months ago >> https://bugzilla.redhat.com/show_bug.cgi?id=1023788 > > This issue has been debugged already, see the mailing list archives it needs to be backported and reach distributions and finally users nobody has any gain from discussions burried in list-archives more than 3 months is way too long >> maybe systemd-upstream should consider slow down development >> and spend more energy in quality and stability > > How exactly would you suggest something like this be done? most of the issues (the above is only one) was introduced with features resulting in more and more processes on a tiny system (sd-pam processes for any userid ever fired up a process) and a user@uid.service, hard dependencies to a running dbus-daemon and what not there where times a stable server was up for months without any of these processes and "messagebus" as well as Consolkit disabled completly resulting in 5 userland processes for a nameserver what about pushing not that much new features and large changes in a tiny timeframe and spend more of the time in bug-triage of existing problems? don't get me wrong but the above was reported long before F20 GA and there are some never seen any QA at all or how can it be that bugs like "Failed to open private bus connection: Failed to connect to socket /run/user/0/dbus/user_bus_socket" or any other ever used uid are present over months or make it in a release at all? one boot of the machine and i see them - why? because i look at the syslog after any reboot and expect the same from upstream there are more and more loglines all day long resulting in nobody cares if there are some important burried https://bugzilla.redhat.com/show_bug.cgi?id=1053315 _ what's that - a workaround relying on a typo? https://bugzilla.redhat.com/show_bug.cgi?id=1023788#c12 >> (In reply to digimer from comment #11) >> Requires=mutil-user.target >> >> BTW at least for me, this "mutil" typo is essential for this hack to work. >> Do the >> s/mutil/multi/ fix or remove the whole line and it no longer does. Too lazy >> at >> the moment to figure out why, just did s/mutil/doesnt-exist/ locally to make >> it >> more clear and moving on... these are all regressions from F19 to F20 https://bugzilla.redhat.com/show_bug.cgi?id=1023820 https://bugzilla.redhat.com/show_bug.cgi?id=1010572 https://bugzilla.redhat.com/show_bug.cgi?id=1057811 https://bugzilla.redhat.com/show_bug.cgi?id=1057618 https://bugzilla.redhat.com/show_bug.cgi?id=1023788 sometimes it feels like systemd-upstrearm has a release-and-forget-strategy and don't care about the downstream distributions and issues there nor how bad the impact of them for how long is signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
On Wed, Feb 12, 2014 at 08:05:47PM +0100, Reindl Harald wrote: > https://bugzilla.redhat.com/show_bug.cgi?id=1047614 > > Product: Red Hat Enterprise Linux 7 > Component:systemd (Show other bugs) > Version: 7.0 > Hardware: Unspecified Unspecified > Priority urgent Severity high > > first reported more than 3 months ago > https://bugzilla.redhat.com/show_bug.cgi?id=1023788 This issue has been debugged already, see the mailing list archives. > maybe systemd-upstream should consider slow down development > and spend more energy in quality and stability How exactly would you suggest something like this be done? greg k-h ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] https://bugzilla.redhat.com/show_bug.cgi?id=1047614
https://bugzilla.redhat.com/show_bug.cgi?id=1047614 Product:Red Hat Enterprise Linux 7 Component: systemd (Show other bugs) Version:7.0 Hardware: Unspecified Unspecified Priorityurgent Severity high first reported more than 3 months ago https://bugzilla.redhat.com/show_bug.cgi?id=1023788 maybe systemd-upstream should consider slow down development and spend more energy in quality and stability signature.asc Description: OpenPGP digital signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Misleading InterfaceStabilityPromise wiki page (due to formatting)
On Wed, Feb 12, 2014 at 6:59 PM, Elijah Newren wrote: > At http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise > (linked to from LWN just recently), the stable, almost-stable, and > not-stable lists all run together in one long bulleted list making it > appear that all categories are part of the stability promise. > > I suspect a newline is needed before the two "The following > interfaces" sentences, so that they don't get formatted as part of the > previous bullet item. (I don't have perms to edit, or I'd just do > it.) Added the newlines. Thanks, Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] Misleading InterfaceStabilityPromise wiki page (due to formatting)
Hi, At http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise (linked to from LWN just recently), the stable, almost-stable, and not-stable lists all run together in one long bulleted list making it appear that all categories are part of the stability promise. I suspect a newline is needed before the two "The following interfaces" sentences, so that they don't get formatted as part of the previous bullet item. (I don't have perms to edit, or I'd just do it.) Elijah ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH v3 2/2] syscallfilter: port to libseccomp
On Wed, 12.02.14 01:29, Ronny Chevalier (chevalier.ro...@gmail.com) wrote:
Commited this one! Thanks!
(I added another commit on top, to add SystemCallErrorNumber= to
optionally return an error from blacklisted syscalls instead of aborting
the process)
> ---
> Ok so I found the problem. I forgot a condition in SET_FOREACH that if e is
> 0, it will stop the foreach (and read have the id 0)
>
> Here is the new patch fixing this. Sorry again
>
> Makefile.am| 30 ++---
> README | 1 +
> TODO | 1 -
> configure.ac | 14 ++
> man/systemd.exec.xml | 18 +++-
> src/core/build.h | 8 +++-
> src/core/dbus-execute.c| 8 +---
> src/core/execute.c | 88 ++
> src/core/execute.h | 12 +-
> src/core/load-fragment.c | 96
> +++---
> src/shared/.gitignore | 4 --
> src/shared/linux/seccomp-bpf.h | 76 -
> src/shared/linux/seccomp.h | 47 -
> src/shared/syscall-list.c | 56
> src/shared/syscall-list.h | 41 --
> src/test/test-tables.c | 3 --
> 16 files changed, 157 insertions(+), 346 deletions(-)
> delete mode 100644 src/shared/linux/seccomp-bpf.h
> delete mode 100644 src/shared/linux/seccomp.h
> delete mode 100644 src/shared/syscall-list.c
> delete mode 100644 src/shared/syscall-list.h
>
> diff --git a/Makefile.am b/Makefile.am
> index 6a3fd48..1b978e5 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -653,8 +653,6 @@ noinst_LTLIBRARIES += \
> libsystemd_shared_la_SOURCES = \
> src/shared/linux/auto_dev-ioctl.h \
> src/shared/linux/fanotify.h \
> - src/shared/linux/seccomp.h \
> - src/shared/linux/seccomp-bpf.h \
> src/shared/ioprio.h \
> src/shared/missing.h \
> src/shared/initreq.h \
> @@ -762,8 +760,6 @@ libsystemd_shared_la_SOURCES = \
> src/shared/net-util.h \
> src/shared/errno-list.c \
> src/shared/errno-list.h \
> - src/shared/syscall-list.c \
> - src/shared/syscall-list.h \
> src/shared/audit.c \
> src/shared/audit.h \
> src/shared/xml.c \
> @@ -771,9 +767,7 @@ libsystemd_shared_la_SOURCES = \
>
> nodist_libsystemd_shared_la_SOURCES = \
> src/shared/errno-from-name.h \
> - src/shared/errno-to-name.h \
> - src/shared/syscall-from-name.h \
> - src/shared/syscall-to-name.h
> + src/shared/errno-to-name.h
>
> #
> --
> noinst_LTLIBRARIES += \
> @@ -998,6 +992,7 @@ libsystemd_core_la_CFLAGS = \
> $(PAM_CFLAGS) \
> $(AUDIT_CFLAGS) \
> $(KMOD_CFLAGS) \
> + $(SECCOMP_CFLAGS) \
> -pthread
>
> libsystemd_core_la_LIBADD = \
> @@ -1012,6 +1007,7 @@ libsystemd_core_la_LIBADD = \
> $(PAM_LIBS) \
> $(AUDIT_LIBS) \
> $(CAP_LIBS) \
> + $(SECCOMP_LIBS) \
> $(KMOD_LIBS)
>
> src/core/load-fragment-gperf-nulstr.c: src/core/load-fragment-gperf.gperf
> @@ -1025,33 +1021,13 @@ CLEANFILES += \
> src/core/load-fragment-gperf.gperf \
> src/core/load-fragment-gperf.c \
> src/core/load-fragment-gperf-nulstr.c \
> - src/shared/syscall-list.txt \
> - src/shared/syscall-from-name.gperf \
> src/shared/errno-list.txt \
> src/shared/errno-from-name.gperf
>
> BUILT_SOURCES += \
> - src/shared/syscall-from-name.h \
> - src/shared/syscall-to-name.h \
> src/shared/errno-from-name.h \
> src/shared/errno-to-name.h
>
> -src/shared/syscall-list.txt:
> - $(AM_V_at)$(MKDIR_P) $(dir $@)
> - $(AM_V_GEN)$(CPP) $(CFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) -dM -include
> sys/syscall.h - < /dev/null | $(AWK) '/^#define[ \t]+__NR_[^ ]+[ \t]+[0-9(]/
> { sub(/__NR_/, "", $$2); if ($$2 !~ /SYSCALL_BASE/) print $$2; }' > $@
> -
> -src/shared/syscall-from-name.gperf: src/shared/syscall-list.txt
> - $(AM_V_at)$(MKDIR_P) $(dir $@)
> - $(AM_V_GEN)$(AWK) 'BEGIN{ print "struct syscall_name { const char*
> name; int id; };"; print "%null-strings"; print "%%";} { printf "%s,
> __NR_%s\n", $$1, $$1 }' < $< > $@
> -
> -src/shared/syscall-from-name.h: src/shared/syscall-from-name.gperf
> - $(AM_V_at)$(MKDIR_P) $(dir $@)
> - $(AM_V_GPERF)$(GPERF) -L ANSI-C -t --ignore-case -N lookup_syscall -H
> hash_syscall_name -p -C < $< > $@
> -
> -src/shared/syscall-to-name.h: src/shared/syscall-list.txt
> - $(AM_V_at)$(MKDIR_P) $(dir $@)
> - $(AM_V_GEN)$(AWK) 'BEGIN{ print "static const char* const
> syscall_names[] = { "} { printf "[SYSCALL_TO_INDEX(__NR_%s)] = \"%s\",\n",
> $$1, $$1 } END{print "};"}' < $< > $@
> -
> src/shared/errno-list.txt:
> $(AM_V_at)$(MKDIR_P) $(dir $@)
> $(AM_V_GEN)$(CPP) $(CFLAGS) $(AM_CPPFLAGS) $(CPPFLAGS) -dM -include
> errno.h - < /
[systemd-devel] [PATCH v2 1/2] test: add basic seccomp tests
---
test/TEST-04-SECCOMP/Makefile | 1 +
test/TEST-04-SECCOMP/test-seccomp.sh| 13 +
test/TEST-04-SECCOMP/test.sh| 79 +
test/TEST-04-SECCOMP/will-fail.service | 8 +++
test/TEST-04-SECCOMP/will-fail2.service | 6 +++
test/TEST-04-SECCOMP/will-not-fail.service | 9
test/TEST-04-SECCOMP/will-not-fail2.service | 6 +++
7 files changed, 122 insertions(+)
create mode 12 test/TEST-04-SECCOMP/Makefile
create mode 100755 test/TEST-04-SECCOMP/test-seccomp.sh
create mode 100755 test/TEST-04-SECCOMP/test.sh
create mode 100644 test/TEST-04-SECCOMP/will-fail.service
create mode 100644 test/TEST-04-SECCOMP/will-fail2.service
create mode 100644 test/TEST-04-SECCOMP/will-not-fail.service
create mode 100644 test/TEST-04-SECCOMP/will-not-fail2.service
diff --git a/test/TEST-04-SECCOMP/Makefile b/test/TEST-04-SECCOMP/Makefile
new file mode 12
index 000..e9f93b1
--- /dev/null
+++ b/test/TEST-04-SECCOMP/Makefile
@@ -0,0 +1 @@
+../TEST-01-BASIC/Makefile
\ No newline at end of file
diff --git a/test/TEST-04-SECCOMP/test-seccomp.sh
b/test/TEST-04-SECCOMP/test-seccomp.sh
new file mode 100755
index 000..efe5c11
--- /dev/null
+++ b/test/TEST-04-SECCOMP/test-seccomp.sh
@@ -0,0 +1,13 @@
+#!/bin/bash -x
+
+systemctl start will-fail.service
+systemctl start will-fail2.service
+systemctl start will-not-fail.service
+systemctl start will-not-fail2.service
+systemctl is-failed will-fail.service | grep failed || exit 1
+systemctl is-failed will-fail2.service | grep failed || exit 1
+systemctl is-failed will-not-fail.service | grep failed && exit 1
+systemctl is-failed will-not-fail2.service | grep failed && exit 1
+
+touch /testok
+exit 0
diff --git a/test/TEST-04-SECCOMP/test.sh b/test/TEST-04-SECCOMP/test.sh
new file mode 100755
index 000..a85b50c
--- /dev/null
+++ b/test/TEST-04-SECCOMP/test.sh
@@ -0,0 +1,79 @@
+#!/bin/bash
+# -*- mode: shell-script; indent-tabs-mode: nil; sh-basic-offset: 4; -*-
+# ex: ts=8 sw=4 sts=4 et filetype=sh
+TEST_DESCRIPTION="seccomp tests"
+
+. $TEST_BASE_DIR/test-functions
+
+check_result_qemu() {
+ret=1
+mkdir -p $TESTDIR/root
+mount ${LOOPDEV}p1 $TESTDIR/root
+[[ -e $TESTDIR/root/testok ]] && ret=0
+[[ -f $TESTDIR/root/failed ]] && cp -a $TESTDIR/root/failed $TESTDIR
+cp -a $TESTDIR/root/var/log/journal $TESTDIR
+umount $TESTDIR/root
+[[ -f $TESTDIR/failed ]] && cat $TESTDIR/failed
+ls -l $TESTDIR/journal/*/*.journal
+test -s $TESTDIR/failed && ret=$(($ret+1))
+return $ret
+}
+
+test_run() {
+if run_qemu; then
+check_result_qemu || return 1
+else
+dwarn "can't run QEMU, skipping"
+fi
+if check_nspawn; then
+run_nspawn
+check_result_nspawn || return 1
+else
+dwarn "can't run systemd-nspawn, skipping"
+fi
+return 0
+}
+
+test_setup() {
+create_empty_image
+mkdir -p $TESTDIR/root
+mount ${LOOPDEV}p1 $TESTDIR/root
+
+# Create what will eventually be our root filesystem onto an overlay
+(
+LOG_LEVEL=5
+eval $(udevadm info --export --query=env --name=${LOOPDEV}p2)
+
+setup_basic_environment
+
+# setup the testsuite service
+cat >$initdir/etc/systemd/system/testsuite.service
Re: [systemd-devel] [PATCH] rules: name Dell iDRAC virtual usb nic
On Wed, Feb 12, 2014 at 2:12 PM, wrote: > From: Charles Rose > > Dell servers contain a virtual usb nic for systems management. > Name the device 'idrac' to easily identify it. The 75-net-description.rules is doe describe interfaces, not to carry out any policy. Product specific matches do not really belong into default udev rules shipped by systemd, we should not add more of them. They might have a place in the hardware database files. I'm not exactly sure though, how to apply policy from the hwdb to renaming network devices, there is no user like that at the moment. What tool is supposed to find that named interface? Can't it just ship that rule in its own file? Kay ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Undefined reference efi_loader_get_boot_usec
El 11/02/14 09:12, Allmeroth, Robert escribió: I helped myself to #ifdef the body of boot_timestamps() in shared/boot_timestamp.c Oh btw.. since you figured out before I did.. the next time please send patches, it does not matter if they are wrong, ifdef is misplaced or whatever.. just try! the worst thing that could happen is that someone will reject it directing you to the correct solution. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] rules: name Dell iDRAC virtual usb nic
From: Charles Rose
Dell servers contain a virtual usb nic for systems management.
Name the device 'idrac' to easily identify it.
---
rules/75-net-description.rules | 3 +++
1 file changed, 3 insertions(+)
diff --git a/rules/75-net-description.rules b/rules/75-net-description.rules
index 7e62f8b..d28c9ff 100644
--- a/rules/75-net-description.rules
+++ b/rules/75-net-description.rules
@@ -5,6 +5,9 @@ SUBSYSTEM!="net", GOTO="net_end"
IMPORT{builtin}="net_id"
+# Dell iDRAC Virtual USB NIC
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="413c", ATTRS{idProduct}=="a102",
NAME="idrac"
+
SUBSYSTEMS=="usb", IMPORT{builtin}="usb_id", IMPORT{builtin}="hwdb
--subsystem=usb"
SUBSYSTEMS=="usb", GOTO="net_end"
--
1.8.5.3
--
Charles Rose
Linux Engineering
Dell Inc.
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] threads and cgroups
On Wed, 12.02.14 11:28, Allmeroth, Robert (robert.allmer...@harman.com) wrote: > Hi, > > I read a lot about the new cgroup concept of the kernel/systemd. > I understand the logic behind it and why systemd wants to be the MCP of it. > But I miss information how threads are handled. > > Example: > Due to performance reasons we arrange components with various profiles into > one executable. > Assume a splash-animation on startup, audio-management, CAN, key input etc. > Some of them should be > protected by a realtime cgroup - others not. > > Right now we are able to put the whole unit/process into one cgroup with > systemd mechanisms (I like the slice concept :)) > Named threads can be handled by extra tooling, e.g. invoked via > ExecStartPost, managing the threads/cgroups directly > > Problems will arise if manual management is impossible in future > implementations. > Is there a systemd concept if and/or how threads living inside of processes > can be assigned to separate cgroups? > > Best regards > Robert > > PS: resources I used: > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ > http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html The plan by the kernel guys is to not allow cgroup management on threads anymore, only entire processes. The APIs in systemd reflect this decision by the kernel guys: you cannot arrange individual threads for organization by cgroups. As a replacement for this in the short-term people should use pthread_setsched*(). Of course, this does not allow grouping, only assignment of scheduling parameters per-trhead. The plan is to add a new API for that in the longer run, but it is unlikely to involve cgroups or anything, but be a specific API for scheduling and nothing else, and not be exposed in any file system. Basically, in the cgroups "version 2.0" design, this feature is gone. Sorry if this is disappointing. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] threads and cgroups
Hi, I read a lot about the new cgroup concept of the kernel/systemd. I understand the logic behind it and why systemd wants to be the MCP of it. But I miss information how threads are handled. Example: Due to performance reasons we arrange components with various profiles into one executable. Assume a splash-animation on startup, audio-management, CAN, key input etc. Some of them should be protected by a realtime cgroup - others not. Right now we are able to put the whole unit/process into one cgroup with systemd mechanisms (I like the slice concept :)) Named threads can be handled by extra tooling, e.g. invoked via ExecStartPost, managing the threads/cgroups directly Problems will arise if manual management is impossible in future implementations. Is there a systemd concept if and/or how threads living inside of processes can be assigned to separate cgroups? Best regards Robert PS: resources I used: http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html ROBERT ALLMEROTH Harman Automotive Division Becker-Göring-Straße 16 76307 Karlsbad Phone: +49 (0) 7248-71-1156 Fax: +49 (0) 7248-71-2156 Email: robert.allmer...@harman.com Web: www.harman.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] hostnamed: Fix the way that static and transient host names interact
It is almost always incorrect to allow DHCP or other sources of
transient host names to override an explicitly configured static host
name.
This commit changes things so that if a static host name is set, this
will override the transient host name (eg: provided via DHCP). Transient
host names can still be used to provide host names for machines that have
not been explicitly configured with a static host name.
The exception to this rule is if the static host name is set to
"localhost" or matches "localhost.*". In those cases we act as if no
static host name has been explicitly set.
As discussed elsewhere, systemd may want to have an fd based ownership
of the transient name. That part is not included in this commit.
---
man/hostnamectl.xml | 8 +++-
src/hostname/hostnamed.c | 36 +++-
2 files changed, 34 insertions(+), 10 deletions(-)
diff --git a/man/hostnamectl.xml b/man/hostnamectl.xml
index 4bc05f5..80e8cde 100644
--- a/man/hostnamectl.xml
+++ b/man/hostnamectl.xml
@@ -68,11 +68,9 @@
(e.g. "Lennart's Laptop"), the static hostname which
is used to initialize the kernel hostname at boot
(e.g. "lennarts-laptop"), and the transient hostname
-which might be assigned temporarily due to network
-configuration and might revert back to the static
-hostname if network connectivity is lost and is only
-temporarily written to the kernel hostname
-(e.g. "dhcp-47-11").
+which is a default received from network configuration.
+If a static hostname is set, and is valid (something other
+than localhost) then the transient hostname is not used.
Note that the pretty hostname has little
restrictions on the characters used, while the static
diff --git a/src/hostname/hostnamed.c b/src/hostname/hostnamed.c
index e57891b..5174fa8 100644
--- a/src/hostname/hostnamed.c
+++ b/src/hostname/hostnamed.c
@@ -228,16 +228,36 @@ static char* context_fallback_icon_name(Context *c) {
return strdup("computer");
}
-static int context_write_data_hostname(Context *c) {
+static bool hostname_is_useful(const char *hn) {
+return !isempty(hn) && !streq(hn, "localhost") &&
+ !startswith(hn, "localhost.");
+}
+
+static int context_update_kernel_hostname(Context *c) {
+const char *static_hn;
const char *hn;
assert(c);
-if (isempty(c->data[PROP_HOSTNAME]))
-hn = "localhost";
-else
+static_hn = c->data[PROP_STATIC_HOSTNAME];
+
+/* /etc/hostname with something other than "localhost"
+ * has the highest preference ... */
+if (hostname_is_useful(static_hn))
+hn = static_hn;
+
+/* ... the transient host name, (ie: DHCP) comes next ...*/
+else if (!isempty(c->data[PROP_HOSTNAME]))
hn = c->data[PROP_HOSTNAME];
+/* ... fallback to static "localhost.*" ignored above ... */
+else if (!isempty(static_hn))
+hn = static_hn;
+
+/* ... and the ultimate fallback */
+else
+hn = "localhost";
+
if (sethostname(hn, strlen(hn)) < 0)
return -errno;
@@ -389,7 +409,7 @@ static int method_set_hostname(sd_bus *bus, sd_bus_message
*m, void *userdata, s
free(c->data[PROP_HOSTNAME]);
c->data[PROP_HOSTNAME] = h;
-r = context_write_data_hostname(c);
+r = context_update_kernel_hostname(c);
if (r < 0) {
log_error("Failed to set host name: %s", strerror(-r));
return sd_bus_error_set_errnof(error, r, "Failed to set
hostname: %s", strerror(-r));
@@ -441,6 +461,12 @@ static int method_set_static_hostname(sd_bus *bus,
sd_bus_message *m, void *user
c->data[PROP_STATIC_HOSTNAME] = h;
}
+r = context_update_kernel_hostname(c);
+if (r < 0) {
+log_error("Failed to set host name: %s", strerror(-r));
+return sd_bus_error_set_errnof(error, r, "Failed to set
hostname: %s", strerror(-r));
+}
+
r = context_write_data_static_hostname(c);
if (r < 0) {
log_error("Failed to write static host name: %s",
strerror(-r));
--
1.8.5.3
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
