Re: [systemd-devel] Dynamic locale changes with localed
On Tue, Jul 02, 2013 at 09:42:46PM +0900, Tristan Van Berkom wrote: Hello Mailing List. I have a quick question about the org.freedesktop.locale1 interface. I'm not aware of anyone working on something like that. I think you'd be best off simply reading the sources, esp. locale_message_handler [1], they're short enough even if you're not familiar with the codebase. Zbyszek [1] http://cgit.freedesktop.org/systemd/systemd/tree/src/locale/localed.c?id=HEAD#n981 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH 1/3] cryptsetup: Move password query out of main
Also use _cleanup_free_ where possible.
---
src/cryptsetup/cryptsetup.c | 153 +---
1 file changed, 72 insertions(+), 81 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 347394d..994a0e0 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -215,7 +215,8 @@ finish:
}
static char *disk_mount_point(const char *label) {
-char *mp = NULL, *device = NULL;
+char *mp = NULL;
+_cleanup_free_ char *device = NULL;
FILE *f = NULL;
struct mntent *m;
@@ -238,11 +239,68 @@ finish:
if (f)
endmntent(f);
-free(device);
-
return mp;
}
+static int get_password(const char *name, usec_t until, bool accept_cached,
char ***passwords) {
+int r;
+char **p;
+_cleanup_free_ char *text = NULL;
+
+assert(name);
+assert(passwords);
+
+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 (r 0) {
+log_error(Failed to query password: %s, strerror(-r));
+return r;
+}
+
+if (opt_verify) {
+_cleanup_strv_free_ char **passwords2 = NULL;
+
+assert(strv_length(*passwords) == 1);
+
+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 (r 0) {
+log_error(Failed to query verification password: %s,
strerror(-r));
+return r;
+}
+
+assert(strv_length(passwords2) == 1);
+
+if (!streq(*passwords[0], passwords2[0])) {
+log_warning(Passwords did not match, retrying.);
+return -EAGAIN;
+}
+}
+
+strv_uniq(*passwords);
+
+STRV_FOREACH(p, *passwords) {
+char *c;
+
+if (strlen(*p)+1 = opt_key_size)
+continue;
+
+/* Pad password if necessary */
+if (!(c = new(char, opt_key_size)))
+return log_oom();
+
+strncpy(c, *p, opt_key_size);
+free(*p);
+*p = c;
+}
+
+return 0;
+}
+
static int help(void) {
printf(%s attach VOLUME SOURCEDEVICE [PASSWORD] [OPTIONS]\n
@@ -257,9 +315,6 @@ static int help(void) {
int main(int argc, char *argv[]) {
int r = EXIT_FAILURE;
struct crypt_device *cd = NULL;
-char **passwords = NULL, *truncated_cipher = NULL;
-const char *cipher = NULL, *cipher_mode = NULL, *hash = NULL, *name =
NULL;
-char *description = NULL, *name_buffer = NULL, *mount_point = NULL;
if (argc = 1) {
help();
@@ -281,9 +336,12 @@ int main(int argc, char *argv[]) {
uint32_t flags = 0;
int k;
unsigned try;
-const char *key_file = NULL;
usec_t until;
crypt_status_info status;
+const char *key_file = NULL, *cipher = NULL, *cipher_mode =
NULL,
+ *hash = NULL, *name = NULL;
+_cleanup_free_ char *description = NULL, *name_buffer = NULL,
+*mount_point = NULL, *truncated_cipher =
NULL;
/* Arguments: systemd-cryptsetup attach VOLUME SOURCE-DEVICE
[PASSWORD] [OPTIONS] */
@@ -386,73 +444,14 @@ int main(int argc, char *argv[]) {
for (try = 0; try opt_tries; try++) {
bool pass_volume_key = false;
-
-strv_free(passwords);
-passwords = NULL;
+_cleanup_strv_free_ char **passwords = NULL;
if (!key_file) {
-char *text, **p;
-
-if (asprintf(text, Please enter passphrase
for disk %s!, name) 0) {
-log_oom();
-goto finish;
-}
-
-k = ask_password_auto(text, drive-harddisk,
until, try == 0 !opt_verify, passwords);
-free(text);
-
-if (k 0) {
-log_error(Failed to query password:
%s, strerror(-k));
+k = get_password(name, until, try == 0
!opt_verify, passwords);
+if (k == -EAGAIN)
+continue;
+
[systemd-devel] [PATCH 2/3] cryptsetup: Move attaching of the device out of main
---
src/cryptsetup/cryptsetup.c | 229 +++-
1 file changed, 121 insertions(+), 108 deletions(-)
diff --git a/src/cryptsetup/cryptsetup.c b/src/cryptsetup/cryptsetup.c
index 994a0e0..cb48009 100644
--- a/src/cryptsetup/cryptsetup.c
+++ b/src/cryptsetup/cryptsetup.c
@@ -301,6 +301,108 @@ static int get_password(const char *name, usec_t until,
bool accept_cached, char
return 0;
}
+static int attach_luks_or_plain(struct crypt_device *cd,
+const char *name,
+const char **key_file,
+char **passwords,
+uint32_t flags) {
+int r = 0;
+bool pass_volume_key = false;
+
+assert(cd);
+assert(name);
+assert(key_file);
+
+if (!opt_type || streq(opt_type, CRYPT_LUKS1))
+r = crypt_load(cd, CRYPT_LUKS1, NULL);
+
+if ((!opt_type r 0) || streq_ptr(opt_type, CRYPT_PLAIN)) {
+struct crypt_params_plain params = {};
+const char *cipher, *cipher_mode;
+_cleanup_free_ char *truncated_cipher = NULL;
+
+if (opt_hash) {
+/* plain isn't a real hash type. it just means use no
hash */
+if (!streq(opt_hash, plain))
+params.hash = opt_hash;
+} else
+params.hash = ripemd160;
+
+if (opt_cipher) {
+size_t l;
+
+l = strcspn(opt_cipher, -);
+truncated_cipher = strndup(opt_cipher, l);
+if (!truncated_cipher)
+return log_oom();
+
+cipher = truncated_cipher;
+cipher_mode = opt_cipher[l] ? opt_cipher+l+1 : plain;
+} else {
+cipher = aes;
+cipher_mode = cbc-essiv:sha256;
+}
+
+/* for CRYPT_PLAIN limit reads
+ * from keyfile to key length, and
+ * ignore keyfile-size */
+opt_keyfile_size = opt_key_size / 8;
+
+/* In contrast to what the name
+ * crypt_setup() might suggest this
+ * doesn't actually format anything,
+ * it just configures encryption
+ * parameters when used for plain
+ * mode. */
+r = crypt_format(cd, CRYPT_PLAIN,
+ cipher,
+ cipher_mode,
+ NULL,
+ NULL,
+ opt_keyfile_size,
+ params);
+
+/* hash == NULL implies the user passed plain */
+pass_volume_key = (params.hash == NULL);
+}
+
+if (r 0) {
+log_error(Loading of cryptographic parameters failed: %s,
strerror(-r));
+return r;
+}
+
+log_info(Set cipher %s, mode %s, key size %i bits for device %s.,
+ crypt_get_cipher(cd),
+ crypt_get_cipher_mode(cd),
+ crypt_get_volume_key_size(cd)*8,
+ crypt_get_device_name(cd));
+
+if (*key_file) {
+r = crypt_activate_by_keyfile_offset(cd, name, CRYPT_ANY_SLOT,
+ *key_file,
opt_keyfile_size,
+ opt_keyfile_offset,
flags);
+if (r 0) {
+log_error(Failed to activate with key file '%s': %s,
*key_file, strerror(-r));
+*key_file = NULL;
+return -EAGAIN;
+}
+} else {
+char **p;
+
+STRV_FOREACH(p, passwords) {
+if (pass_volume_key)
+r = crypt_activate_by_volume_key(cd, name, *p,
opt_key_size, flags);
+else
+r = crypt_activate_by_passphrase(cd, name,
CRYPT_ANY_SLOT, *p, strlen(*p), flags);
+
+if (r = 0)
+break;
+}
+}
+
+return r;
+}
+
static int help(void) {
printf(%s attach VOLUME SOURCEDEVICE [PASSWORD] [OPTIONS]\n
@@ -335,13 +437,11 @@ int main(int argc, char *argv[]) {
if (streq(argv[1], attach)) {
uint32_t flags = 0;
int k;
-unsigned try;
+unsigned tries;
usec_t until;
crypt_status_info status;
-const char *key_file = NULL, *cipher = NULL, *cipher_mode =
NULL,
- *hash = NULL, *name
[systemd-devel] [PATCH 3/3] cryptsetup: Add tcrypt support
Tcrypt uses a different approach to passphrases/key files. The passphrase and all key files are incorpaorated into the password to open the volume. So, the idea of slots that provide a way to open the volume with different passphrases/key files that are independent from each other like with LUKS does not apply. Therefore, we use the key file from /etc/crypttab as the source for the passphrase. If the passphrase of a volume is empty, using /dev/null as key file is enough. The actual key files that are combined with the passphrase into a password are provided as a new option in /etc/crypttab and can be given multiple times if more than one key file was used for a volume. --- man/crypttab.xml| 300 +++- src/cryptsetup/cryptsetup.c | 81 +++- 2 files changed, 259 insertions(+), 122 deletions(-) diff --git a/man/crypttab.xml b/man/crypttab.xml index 1063b46..386fa0d 100644 --- a/man/crypttab.xml +++ b/man/crypttab.xml @@ -75,23 +75,29 @@ fields are mandatory, the remaining two are optional./para +paraSetting up encrypted block devices using this file +supports three encryption modes: LUKS, TrueCrypt and plain. +See citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry +for more information about each mode. When no mode is specified +in the options field and the block device contains a LUKS +signature, it is opened as a LUKS device; otherwise it is +assumed to be in raw dm-crypt (plain mode) format./para + paraThe first field contains the name of the resulting encrypted block device; the device is set up within filename/dev/mapper//filename./para paraThe second field contains a path to the -underlying block device, or a specification of a block +underlying block device or file, or a specification of a block device via literalUUID=/literal followed by the -UUID. If the block device contains a LUKS signature, -it is opened as a LUKS encrypted partition; otherwise -it is assumed to be a raw dm-crypt partition./para +UUID./para paraThe third field specifies the encryption password. If the field is not present or the password -is set to none, the password has to be manually -entered during system boot. Otherwise the field is -interpreted as a path to a file containing the -encryption password. For swap encryption +is set to none or literal-/literal, the password has +to be manually entered during system boot. Otherwise the +field is interpreted as a absolute path to a file containing the +encryption password. For swap encryption filename/dev/urandom/filename or the hardware device filename/dev/hw_random/filename can be used as the password file; using @@ -104,181 +110,237 @@ options are recognized:/para variablelist class='crypttab-options' + +varlistentry +termvarnameallow-discards/varname/term + +listitemparaAllow discard requests to be +passed through the encrypted block device. This +improves performance on SSD storage but has +security implications./para/listitem +/varlistentry + varlistentry termvarnamecipher=/varname/term -listitemparaSpecifies the cipher -to use; see +listitemparaSpecifies the cipher to use. See citerefentryrefentrytitlecryptsetup/refentrytitlemanvolnum8/manvolnum/citerefentry -for possible values and the default -value of this option. A cipher with -unpredictable IV values, such as -literalaes-cbc-essiv:sha256/literal, -is recommended. /para/listitem +for possible values and the default value of +this option. A cipher with unpredictable IV +values, such as literalaes-cbc-essiv:sha256/literal, +is recommended./para/listitem /varlistentry - varlistentry -
Re: [systemd-devel] [PATCH] scope: Silence compiler warning
On Mon, Jul 01, 2013 at 05:16:02PM +0200, Jan Janssen wrote:
---
src/core/dbus-scope.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/src/core/dbus-scope.c b/src/core/dbus-scope.c
index bddf8f4..f6cfe38 100644
--- a/src/core/dbus-scope.c
+++ b/src/core/dbus-scope.c
@@ -93,7 +93,7 @@ static int bus_scope_set_transient_property(
if (streq(name, PIDs)) {
DBusMessageIter sub;
-unsigned n;
+unsigned n = 0;
Apologies, I just fixed this myself in git without having seen this patch.
if (dbus_message_iter_get_arg_type(i) != DBUS_TYPE_ARRAY ||
dbus_message_iter_get_element_type(i) !=
DBUS_TYPE_UINT32)
--
1.8.3.2
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] No such file or directory when enabling a service
On Thu, Jun 27, 2013 at 08:14:03PM +, Lars Kellogg-Stedman wrote: I'm running systemd 204 under Fedora 19 (beta). I have /etc/systemd/system/postfix-update-hook.service installed as a symlink to /etc/postfix/support/postfix-update-hook.service. I can start it: # systemctl start postfix-update-hook And check the status: # systemctl status postfix-update-hook postfix-update-hook.service Loaded: loaded (/etc/postfix/support/postfix-update-hook.service; linked) Active: active (running) since Thu 2013-06-27 19:59:28 UTC; 25s ago Main PID: 19276 (postfix-update-) CGroup: name=systemd:/system/postfix-update-hook.service └─19276 /bin/sh /etc/postfix/support/postfix-update-hook But I can't enable it: # systemctl enable postfix-update-hook Failed to issue method call: No such file or directory If I replace the symlink in /etc/systemd/system with an actual file, then it works just fine: # cd /etc/systemd/system # mv postfix-update-hook.service postfix-update-hook.service.symlink # cp postfix-update-hook.service.symlink postfix-update-hook.service # systemctl enable postfix-update-hook ln -s '/etc/systemd/system/postfix-update-hook.service' '/etc/systemd/system/multi-user.target.wants/postfix-update-hook.service' Is this expected behavior? I suspect it is. 'systemctl link' does what you want if you're interested in including unit files from outside the default unit search path. Thanks, -- Lars Kellogg-Stedman l...@oddbit.com ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd config recipes for namespace-isolated webapps
Hi folks!
At OLPC, I got an early chance to use and abuse systemd, and I like it
quite a bit.
We currently have ~500 identical VMs (created from kickstarts, kept
almost in sync via satellite), each hosts apache/mysql daemons, and 2
installs of the same PHP webapp (production, test).
Goal is to reduce the number of VMs radically, as memory and storage
overheads are killing us.
I am now looking at systemd (under F-19, RHEL7 later) and wondering
whether there are any recipes that can guide me a bit through setting
up webapps in CGs with suitable namespaces.
What I _think_ I need is
0 - one target per customer, which in turn pulls in
1 - apache
2 - mysql
3 - cronjobs
4 - apache/tomcat/java setup {for some customers}
5 - sftp -- namespace-aware?
with 1,2 and 3 set to use the same CG. And stopping the target should
ensure all the CG is down/dead.
If possible, I prefer to avoid containers (and the associated chroot
maintenance).
High on the list of goals is to protect customers from data leakage,
so guidelines towards effective use of namespaces are sought here.
Pointers, hints, anyone else working in a similar direction?
cheers,
martin
ps: I have read all/most of LWN and Lennart's articles, but welcome a
gentle pointer if relevant...
--
martin.langh...@gmail.com
- ask interesting questions
- don't get distracted with shiny stuff - working code first
~ http://docs.moodle.org/en/User:Martin_Langhoff
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemd and criu (checkpoint / restart)
Hello, TL;DR criu works if you disable the journal and stop the .socket before restore, criu appears to be incompatible with systemd-nspawn. I've been having fun with systemd, -nspawn, and the latest criu tools. These are just my research notes. I wanted to share progress, would love any feedback or pointers on places this does not work. Before we begin: localhost criu2 # systemd --version systemd 204 +PAM -LIBWRAP -AUDIT -SELINUX +IMA -SYSVINIT -LIBCRYPTSETUP -GCRYPT -ACL -XZ localhost criu2 # criu -V Version: 0.6 localhost criu2 # uname -a Linux localhost 3.10.0+ #4 SMP Mon Jul 1 13:36:25 PDT 2013 x86_64 Intel(R) Core(TM) i7-2677M CPU @ 1.80GHz GenuineIntel GNU/Linux In the following gist: 1) I setup a socket activated go http server (just plain, no nspawn) 2) start the process via socket activation 3) criu dump it 4) shut down the .socket 5) criu restore, works, yay https://gist.github.com/polvi/310fad0a2a3b0859cfb1 What works: - Application state is dumped and restored successfully. What doesn't work: - The system .socket has to be disabled to because the restore will open the socket. Not sure if there is a work around for this, with the exception of not using socket activation. - The status of the .service is now in a killed state. This is because the dump kills the process when it is done. - Once the process is restored (with the same pid) systemd is confused and is no longer monitoring it. Maybe there is a way to get systemd to realize that the process is running again? - I had to set StandardError=null and StanardOut=null to keep the journal from opening a socket to the service. With-out this the container will not checkpoint, because the criu tools do not allow one end of a socket to be checkpointed. For -nspawn, I'm pretty sure it is incompatible with criu. This took a bunch of fighting, and in the end, triggered a bug in criu. I was able to dump, but not restore the container. In the following gist you'll see where I hit bugs and the fix... 1) I start a busybox while loop in a container using systemd-nspawn 2) nsenter the container and umount /proc/sys/kernel/random/boot_id and /proc/kmsg because they are in a (deleted) state, and criu does not really care for that. I guess -nspawn is setting these up. 3) Updated my copy of iproute2, because criu requires the ip addr save functionality 4) Now it gets really bad... criu restores mount namespaces using pivot_root. systemd uses MS_ENTER. Initially I was hitting a bug where pivot_root was not working because my container was on a different filesystem. After bind mounting the container filesystem to my running root, the restore triggers a bug. 5) I give up. https://gist.github.com/polvi/d883043343e4db8e16cb What works: - It dumped the state of something! What does not work: - Restoring - Using the containers mount namespace (because of criu and pivot_root) In summary, to make this actually work, I think we'd need to implement checkpoint/restart into systemd itself. With this, we could get around all the journal issue, and maybe even make socket activation work. Containers seem to be their own beast. -Alex ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] man: improve grammar and word formatting in numerous man pages
On Tue, Jul 02, 2013 at 12:16:09PM +0200, Jason St. John wrote: On Sat, Jun 29, 2013 at 5:38 PM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Jun 27, 2013 at 09:51:44PM +0200, Jason St. John wrote: Hi David, you changed the spellings of 'file system' and 'namespace'. Here is a proposal to use 'hostname' and 'file name' (instead of 'host name' and 'filename'). Consistency might be more important than pure grammatical considerations, so ... what do you think? Zbyszek I agree that consistency is more important than being grammatically pure; however, Red Hat seems to use file system in all of their documentation. I don't see an obvious pattern for hostname vs. host name though, but it's difficult to get good numbers on that. My patch makes host name and file name a consistent standard for systemd man pages. I can't find anything missed in the man pages when I grep for their variations except for 3 examples in systemctl(1) and udev(7). OK, so I have 0 'file names?' in man-pages, and lots of 'filenames?'. 'hostnames?' is almost much more popular than 'host names?'. Michael Kerrisk shall be our guide here, thus 'filename' and 'hostname' win. The same is true for 'timezone' vs. 'time zone', even though 'timezone' is not even a real word. Do you want me to resubmit the patch to fix those? Or should I resubmit this patch in two parts, one for the host name, file name, etc. changes and a second patch for the non-contentious changes? It's fine, applied with the modifications described above. P.S. I changed your reply to a bottom post. Hopefully that isn't a problem. Thanks, Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] Broken build and CI strategy
On Fri, Jun 28, 2013 at 09:18:24AM +0200, Holger Hans Peter Freyther wrote: On Fri, Jun 28, 2013 at 09:05:40AM +0200, Peter Sztanojev wrote: there already is a jenkins ci for systemd kindly provided by Pantheon: http://systemd.getpantheon.com:8080/jenkins/ The jenkins script is still using make test (which is like calling make /tmp), to execute the tests one would need to call make check but we already had this and it wasn't changed... Okay, there needs to be something done about this ASAP. I have now twice gone to build a package, then run 'make check', and it has failed for simple reasons like translations missing or not being in the right places. These should be caught by jenkins and reported to the IRC channel. I realize that some files have been added recently, but they need to be fully added, not just thrown into the pot (pun not intended). Thanks, -- William Giokas | KaiSforza | http://kaictl.net/ GnuPG Key: 0x73CD09CF Fingerprint: F73F 50EF BBE2 9846 8306 E6B8 6902 06D8 73CD 09CF pgpP6CNqB8Xht.pgp Description: PGP signature ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [systemd-commits] 2 commits - Makefile.am TODO src/core src/login src/shared src/systemctl src/test units/-.slice units/slices.target units/system.slice
On Thu, Jun 27, 2013 at 09:34:24PM +0200, Kay Sievers wrote: On Thu, Jun 27, 2013 at 7:12 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Thu, Jun 27, 2013 at 06:40:37AM +0200, Zbigniew Jędrzejewski-Szmek wrote: make distcheck fails for me, because make uninstall chokes on -.slice. automake-1.12.2-5.fc18.noarch and automake-1.13.4-1.fc19.noarch both. Sent a bug report to bug-autom...@gnu.org just now, should show up in their db soon. http://debbugs.gnu.org/cgi/bugreport.cgi?bug=14728 Awesome response in that bug. :) It's great when completely generic tools get to decide what file names projects can use. :) We should probably work around it, until it is sorted out. Any better idea than the attached? Hi Kay, I went ahead and applied your patch. It's not pretty, but I think that having a working distcheck has priority. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] replace tabs with spaces in various files
Applied. Zbyszek ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] Log failing start conditions
On Wed, Jun 26, 2013 at 03:06:38PM +0200, har...@redhat.com wrote:
From: Harald Hoyer har...@redhat.com
$ systemctl status dracut-initqueue.service
dracut-initqueue.service - dracut initqueue hook
Loaded: loaded (/usr/lib/systemd/system/dracut-initqueue.service;
static)
Active: inactive (dead)
start condition failed at Wed 2013-06-26 13:01:05 UTC; 22s ago
Docs: man:dracut-initqueue.service(8)
Jun 26 13:01:05 lenovo systemd[1]: Starting of dracut-initqueue.service
skipped because the following start conditions were not met:
ConditionKernelCommandLine:|rd.break=initqueue
ConditionPathExistsGlob: |/lib/dracut/hooks/initqueue/timeout/*.sh
ConditionPathExistsGlob: |/lib/dracut/hooks/initqueue/online/*.sh
ConditionPathExistsGlob: |/lib/dracut/hooks/initqueue/finished/*.sh
ConditionPathExistsGlob: |/lib/dracut/hooks/initqueue/settled/*.sh
ConditionPathExistsGlob: |/lib/dracut/hooks/initqueue/*.sh
ConditionPathExists: |/lib/dracut/need-initqueue
Hi Harald,
your patch seems to is better than mine, I somehow missed
the question of muliple conditions. I think you should go ahead
and appy this.
My patch also exported the failing condition over dbus. I guess
we might still want to do this, but let's get this basic functionality
in first.
+if (!(f = open_memstream(buf, size))) {
Style:
f = open_memstream(buf, size);
if (!f) {
+log_warning(Failed to allocate memory stream.);
+return -EALREADY;
+}
+
+condition_dump_list_result(u-conditions, f);
+
+if (ferror(f)) {
+fclose(f);
+log_warning(Failed to write status stream);
+return -EALREADY;
+}
+
+fclose(f);
+
+log_struct_unit(LOG_NOTICE,
+ u-id,
+ MESSAGE_ID(SD_MESSAGE_UNIT_CONDITIONS),
+ MESSAGE=Starting of %s skipped because the
following start conditions were not met:\n%s, u-id, buf,
+ CONDITION_RESULTS=%s, buf,
+ NULL);
+
return -EALREADY;
}
diff --git a/src/systemd/sd-messages.h b/src/systemd/sd-messages.h
index c811a06..c85dda1 100644
--- a/src/systemd/sd-messages.h
+++ b/src/systemd/sd-messages.h
@@ -62,6 +62,7 @@ extern C {
#define SD_MESSAGE_UNIT_STARTING
SD_ID128_MAKE(7d,49,58,e8,42,da,4a,75,8f,6c,1c,dc,7b,36,dc,c5)
#define SD_MESSAGE_UNIT_STARTED
SD_ID128_MAKE(39,f5,34,79,d3,a0,45,ac,8e,11,78,62,48,23,1f,bf)
+#define SD_MESSAGE_UNIT_CONDITIONS
SD_ID128_MAKE(b1,44,ed,c7,3c,f3,49,3b,b4,44,2c,67,03,61,ea,e8)
Strange indentation...
#define SD_MESSAGE_UNIT_STOPPING
SD_ID128_MAKE(de,5b,42,6a,63,be,47,a7,b6,ac,3e,aa,c8,2e,2f,6f)
#define SD_MESSAGE_UNIT_STOPPED
SD_ID128_MAKE(9d,1a,aa,27,d6,01,40,bd,96,36,54,38,aa,d2,02,86)
#define SD_MESSAGE_UNIT_FAILED
SD_ID128_MAKE(be,02,cf,68,55,d2,42,8b,a4,0d,f7,e9,d0,22,f0,3d)
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemd config recipes for namespace-isolated webapps
On Tue, Jul 02, 2013 at 05:18:57PM -0400, Martin Langhoff wrote:
Hi folks!
At OLPC, I got an early chance to use and abuse systemd, and I like it
quite a bit.
We currently have ~500 identical VMs (created from kickstarts, kept
almost in sync via satellite), each hosts apache/mysql daemons, and 2
installs of the same PHP webapp (production, test).
Goal is to reduce the number of VMs radically, as memory and storage
overheads are killing us.
I am now looking at systemd (under F-19, RHEL7 later) and wondering
whether there are any recipes that can guide me a bit through setting
up webapps in CGs with suitable namespaces.
What I _think_ I need is
0 - one target per customer, which in turn pulls in
1 - apache
2 - mysql
3 - cronjobs
4 - apache/tomcat/java setup {for some customers}
5 - sftp -- namespace-aware?
with 1,2 and 3 set to use the same CG. And stopping the target should
ensure all the CG is down/dead.
If possible, I prefer to avoid containers (and the associated chroot
maintenance).
Hi,
I haven't really tried anythng like what you describe, but in general
both container and container-less approaches should work.
with a container: you can have socket activated systemd-nspawn
instance, which boots to a default target containing your services
1-5 + whatever special you want for that customer. It is currently
not possible to launch a systemd-nspawn container directly from /,
but you can do a bind mount to somewhere else. If by chroot
maintanance you mean the need to copy stuff between / and the
container, then it can be avoided this way. Launching systemd-nspawn
containers directly from / is on the list of planned things.
systemd-nspawn@.service already provides part of the installation.
container-less: a bunch of template units with dependencies on one
another should do what you need (instance units can refer to each
other). You can use InaccessibleDirectories= and other settings to
limit what those units can see.
The version with containers is probably slightly more flexible
and will allow more customizations for each customer. The other
one has probably lower overhead. But both should work.
HTH,
Zbyszek
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
