Re: [lxc-devel] multiple lxc container path directories?
Hi Michael, On 06/08/14 18:59, Michael H. Warfield wrote: I see, reviewing my notes now, that you were the one who brought it up back in December last year. Funny too that I just got done doing something very very similar for lxc-autostart and the -g/--groups parameter (which is a comma separated string with multiple invocations). Of course I remember. That was about extending the -P option. This thread is about changing the lxcpath config option, keeping -P as it is. The difference is: Some wrapper functionality could loop over all lxc config dirs, to run an lxc-* -P /somdir command either for all affected containers (e.g. to start or stop a set of containers), or for the first container with a matching name. AFAICS this would have a much smaller impact on the lxc-* commands, making it more easy to implement (hopefully). Probably I do not see all problems of this approach yet, so I started a sample implemen- tation (a bash wrapper script). Its not complete yet; stay tuned. Doing lxc_path as multiple elements is much more involved that just the mere parser as that variable is deeply embedded throughout the code. Given Stéphane's reluctance to incorporate the lxc-autostart patches into the stable-1.0 branch, I can pretty much foresee this not making it into that branch due to its complexity, so it probably wouldn't show up in a release until 1.1 time frame or later. Of course new functionality should not go to the stable branch. 1.1 would be fine. Regards Harri signature.asc Description: OpenPGP digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] Store alien config lines
Any config lines not starting with 'lxc.*' are ignored by lxc. That
can be useful for third party tools, however lxc-clone does not copy such
lines.
Fix that by tracking such lines in our unexpanded config file and
printing them out at write_config(). Note two possible shortcomings here:
1. we always print out all includes followed by all aliens. They are
not kept in order, nor ordered with respect to lxc.* lines.
2. we're still not storing comments. these could easily be added to
the alien lines, but i chose not to in particular since comments are
usually associated with other lines, so destroying the order would
destroy their value. I could be wrong about that, and if I am it's
a trivial fix.
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/conf.c| 12
src/lxc/conf.h| 2 ++
src/lxc/confile.c | 43 +++
3 files changed, 53 insertions(+), 4 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 521a48d..23ed7f3 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -2690,6 +2690,7 @@ struct lxc_conf *lxc_conf_init(void)
lxc_list_init(new-keepcaps);
lxc_list_init(new-id_map);
lxc_list_init(new-includes);
+ lxc_list_init(new-aliens);
for (i=0; iNUM_LXC_HOOKS; i++)
lxc_list_init(new-hooks[i]);
lxc_list_init(new-groups);
@@ -4365,6 +4366,17 @@ static void lxc_clear_saved_nics(struct lxc_conf *conf)
free(conf-saved_nics);
}
+static inline void lxc_clear_aliens(struct lxc_conf *conf)
+{
+ struct lxc_list *it,*next;
+
+ lxc_list_for_each_safe(it, conf-aliens, next) {
+ lxc_list_del(it);
+ free(it-elem);
+ free(it);
+ }
+}
+
static inline void lxc_clear_includes(struct lxc_conf *conf)
{
struct lxc_list *it,*next;
diff --git a/src/lxc/conf.h b/src/lxc/conf.h
index 53590bc..ace1da0 100644
--- a/src/lxc/conf.h
+++ b/src/lxc/conf.h
@@ -342,6 +342,8 @@ struct lxc_conf {
/* list of included files */
struct lxc_list includes;
+ /* config entries which are not lxc.* are aliens */
+ struct lxc_list aliens;
};
int run_lxc_hooks(const char *name, char *hook, struct lxc_conf *conf,
diff --git a/src/lxc/confile.c b/src/lxc/confile.c
index 2ab3fcb..32f08c7 100644
--- a/src/lxc/confile.c
+++ b/src/lxc/confile.c
@@ -1632,6 +1632,31 @@ static int config_utsname(const char *key, const char
*value,
return 0;
}
+static int store_martian_option(char *line, void *data)
+{
+ struct lxc_conf *conf = data;
+ char *str;
+ struct lxc_list *list;
+ size_t len = strlen(line);
+
+ if (!conf-unexpanded)
+ return 0;
+ list = malloc(sizeof(*list));
+ if (!list)
+ return -1;
+ lxc_list_init(list);
+ str = malloc(len+1);
+ if (!str) {
+ free(list);
+ return -1;
+ }
+ strncpy(str, line, len);
+ len[len] = '\0';
+ list-elem = str;
+ lxc_list_add_tail(conf-aliens, list);
+ return 0;
+}
+
static int parse_line(char *buffer, void *data)
{
struct lxc_config_t *config;
@@ -1656,12 +1681,16 @@ static int parse_line(char *buffer, void *data)
line += lxc_char_left_gc(line, strlen(line));
- /* martian option - ignoring it, the commented lines beginning by '#'
-* fall in this case
-*/
- if (strncmp(line, lxc., 4))
+ /* ignore comments */
+ if (line[0] == '#')
goto out;
+ /* martian option - save it in the unexpanded config only */
+ if (strncmp(line, lxc., 4)) {
+ ret = store_martian_option(line, data);
+ goto out;
+ }
+
ret = -1;
dot = strstr(line, =);
@@ -2258,10 +2287,16 @@ void write_config(FILE *fout, struct lxc_conf *c)
struct lxc_list *it;
int i;
+ /* first write any includes */
lxc_list_for_each(it, c-includes) {
fprintf(fout, lxc.include = %s\n, (char *)it-elem);
}
+ /* now write any aliens */
+ lxc_list_for_each(it, c-aliens) {
+ fprintf(fout, %s\n, (char *)it-elem);
+ }
+
if (c-fstab)
fprintf(fout, lxc.mount = %s\n, c-fstab);
lxc_list_for_each(it, c-mount_list) {
--
1.9.1
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] multiple lxc container path directories?
On Thu, 2014-06-12 at 08:10 +0200, Harald Dunkel wrote: Hi Michael, On 06/08/14 18:59, Michael H. Warfield wrote: I see, reviewing my notes now, that you were the one who brought it up back in December last year. Funny too that I just got done doing something very very similar for lxc-autostart and the -g/--groups parameter (which is a comma separated string with multiple invocations). Of course I remember. That was about extending the -P option. This thread is about changing the lxcpath config option, keeping -P as it is. The difference is: Some wrapper functionality could loop over all lxc config dirs, to run an lxc-* -P /somdir command either for all affected containers (e.g. to start or stop a set of containers), or for the first container with a matching name. AFAICS this would have a much smaller impact on the lxc-* commands, making it more easy to implement (hopefully). Probably I do not see all problems of this approach yet, so I started a sample implemen- tation (a bash wrapper script). Its not complete yet; stay tuned. It's really the same thing as it feeds into the same area of code. Also, it seems that some of the code already exists as the processing logic for -P can handing multiple invocations and it's up to the calling command to allow for it. If no -P options are specified, then the global lxcpath config variable is loaded in place of the -P option. So they're intimately linked. Doing lxc_path as multiple elements is much more involved that just the mere parser as that variable is deeply embedded throughout the code. Given Stéphane's reluctance to incorporate the lxc-autostart patches into the stable-1.0 branch, I can pretty much foresee this not making it into that branch due to its complexity, so it probably wouldn't show up in a release until 1.1 time frame or later. Of course new functionality should not go to the stable branch. 1.1 would be fine. Regards Harri ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! signature.asc Description: This is a digitally signed message part ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
[lxc-devel] [PATCH] [resend?] Add a unexpanded lxc_conf
Currently when a container's configuration file has lxc.includes,
any future write_config() will expand the lxc.includes. This
affects container clones (and snapshots) as well as users of the
API who make an update and then c.save_config().
To fix this, separately track the expanded and unexpanded lxc_conf. The
unexpanded conf does not contain values read from lxc.includes. The
expanded conf does. Lxc functions mainly need the expanded conf to
figure out how to configure the container. The unexpanded conf is used
at write_config().
Signed-off-by: Serge Hallyn serge.hal...@ubuntu.com
---
src/lxc/conf.c | 13 +
src/lxc/conf.h | 4
src/lxc/confile.c | 45 ++---
src/lxc/confile.h | 2 +-
src/lxc/lxc_execute.c | 2 +-
src/lxc/lxccontainer.c | 38 +++---
src/lxc/lxccontainer.h | 10 ++
7 files changed, 102 insertions(+), 12 deletions(-)
diff --git a/src/lxc/conf.c b/src/lxc/conf.c
index 4b52550..521a48d 100644
--- a/src/lxc/conf.c
+++ b/src/lxc/conf.c
@@ -2689,6 +2689,7 @@ struct lxc_conf *lxc_conf_init(void)
lxc_list_init(new-caps);
lxc_list_init(new-keepcaps);
lxc_list_init(new-id_map);
+ lxc_list_init(new-includes);
for (i=0; iNUM_LXC_HOOKS; i++)
lxc_list_init(new-hooks[i]);
lxc_list_init(new-groups);
@@ -4364,6 +4365,17 @@ static void lxc_clear_saved_nics(struct lxc_conf *conf)
free(conf-saved_nics);
}
+static inline void lxc_clear_includes(struct lxc_conf *conf)
+{
+ struct lxc_list *it,*next;
+
+ lxc_list_for_each_safe(it, conf-includes, next) {
+ lxc_list_del(it);
+ free(it-elem);
+ free(it);
+ }
+}
+
void lxc_conf_free(struct lxc_conf *conf)
{
if (!conf)
@@ -4402,6 +4414,7 @@ void lxc_conf_free(struct lxc_conf *conf)
lxc_clear_saved_nics(conf);
lxc_clear_idmaps(conf);
lxc_clear_groups(conf);
+ lxc_clear_includes(conf);
free(conf);
}
diff --git a/src/lxc/conf.h b/src/lxc/conf.h
index f5fab3d..53590bc 100644
--- a/src/lxc/conf.h
+++ b/src/lxc/conf.h
@@ -283,6 +283,7 @@ struct saved_nic {
struct lxc_conf {
int is_execute;
+ bool unexpanded;
char *fstab;
int tty;
int pts;
@@ -338,6 +339,9 @@ struct lxc_conf {
/* set to true when rootfs has been setup */
bool rootfs_setup;
+
+ /* list of included files */
+ struct lxc_list includes;
};
int run_lxc_hooks(const char *name, char *hook, struct lxc_conf *conf,
diff --git a/src/lxc/confile.c b/src/lxc/confile.c
index 70097f8..2ab3fcb 100644
--- a/src/lxc/confile.c
+++ b/src/lxc/confile.c
@@ -1552,10 +1552,34 @@ static int config_console(const char *key, const char
*value,
return config_path_item(lxc_conf-console.path, value);
}
+static int add_include_file(const char *fname, struct lxc_conf *lxc_conf)
+{
+ struct lxc_list *list;
+ char *v;
+ int len = strlen(fname);
+
+ list = malloc(sizeof(*list));
+ if (!list)
+ return -1;
+ lxc_list_init(list);
+ v = malloc(len+1);
+ if (!v) {
+ free(list);
+ return -1;
+ }
+ strncpy(v, fname, len);
+ v[len] = '\0';
+ list-elem = v;
+ lxc_list_add_tail(lxc_conf-includes, list);
+ return 0;
+}
+
static int config_includefile(const char *key, const char *value,
struct lxc_conf *lxc_conf)
{
- return lxc_config_read(value, lxc_conf);
+ if (lxc_conf-unexpanded)
+ return add_include_file(value, lxc_conf);
+ return lxc_config_read(value, lxc_conf, NULL);
}
static int config_rootfs(const char *key, const char *value,
@@ -1673,8 +1697,10 @@ static int lxc_config_readline(char *buffer, struct
lxc_conf *conf)
return parse_line(buffer, conf);
}
-int lxc_config_read(const char *file, struct lxc_conf *conf)
+int lxc_config_read(const char *file, struct lxc_conf *conf, struct lxc_conf
*unexp_conf)
{
+ int ret;
+
if( access(file, R_OK) == -1 ) {
return -1;
}
@@ -1682,7 +1708,16 @@ int lxc_config_read(const char *file, struct lxc_conf
*conf)
if( ! conf-rcfile ) {
conf-rcfile = strdup( file );
}
- return lxc_file_for_each_line(file, parse_line, conf);
+ ret = lxc_file_for_each_line(file, parse_line, conf);
+ if (ret)
+ return ret;
+ if (!unexp_conf)
+ return 0;
+ if (!unexp_conf-rcfile) {
+ unexp_conf-rcfile = strdup( file );
+ }
+
+ return lxc_file_for_each_line(file, parse_line, unexp_conf);
}
int lxc_config_define_add(struct lxc_list *defines, char* arg)
@@ -2223,6 +2258,10 @@ void write_config(FILE *fout, struct lxc_conf *c)
struct lxc_list *it;
int i;
+
Re: [lxc-devel] [RFC] Per-user namespace process accounting
On 29/05/14 07:37, Marian Marinov wrote: Hello, I have the following proposition. Number of currently running processes is accounted at the root user namespace. The problem I'm facing is that multiple containers in different user namespaces share the process counters. So if containerX runs 100 with UID 99, containerY should have NPROC limit of above 100 in order to execute any processes with ist own UID 99. I know that some of you will tell me that I should not provision all of my containers with the same UID/GID maps, but this brings another problem. If this matters, we also suffer from the same problem here. So we support any implementation that would address it. Cheers, Alin. ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] [RFC] Per-user namespace process accounting
Quoting Alin Dobre (alin.do...@elastichosts.com): On 29/05/14 07:37, Marian Marinov wrote: Hello, I have the following proposition. Number of currently running processes is accounted at the root user namespace. The problem I'm facing is that multiple containers in different user namespaces share the process counters. Most ppl here probably are aware of this, but the previous, never-completed user namespace implementation provided this and only this. We (mostly Eric and I) spent years looking for clean ways to make that implementation, which had some advantages (including this one), complete. We did have a few POCs which worked but were unsatisfying. The two things which were never convincing were (a) conversion of all uid checks to be namespace-safe, and (b) storing namespace identifiers on disk. (As I say we did have solutions to these, but not satisfying ones). These are the two things which the new implementation address *beautifully*. So if containerX runs 100 with UID 99, containerY should have NPROC limit of above 100 in order to execute any processes with ist own UID 99. I know that some of you will tell me that I should not provision all of my containers with the same UID/GID maps, but this brings another problem. If this matters, we also suffer from the same problem here. So we support any implementation that would address it. ISTM the only reasonable answer here (at least for now) is to make it more convenient to isolate uid ranges, by providing a way to shift uids at mount time as has been discussed a bit. If we go down the route of talking about uid 99 in ns 1 vs uid 99 in ns 2, then people will also expect isolation at file access time, and we're back to all the disadvantages of the first userns implementation. (If someone proves me wrong by suggesting a clean solution, then awesome) -serge ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
Re: [lxc-devel] LXC 1.0.4 approaching
On Tue, Jun 10, 2014 at 09:40:16AM -0400, Michael H. Warfield wrote: On Tue, 2014-06-10 at 07:18 -0400, Dwight Engen wrote: On Mon, 9 Jun 2014 11:06:03 -0400 Stéphane Graber stgra...@ubuntu.com wrote: Hey there, I just pushed Mike's lxc-autostart change to 1.0.4 as it was requested by both him (for Fedora) and Dwight (for Oracle). There's one more crasher in the python3 binding I'd like to sort out and then I think I'll be good for 1.0.4 on my side. My current plan is for a release in the early afternoon US eastern time on Thursday. It'd be great if distro maintainers planning on using 1.0.4 could spend some time testing the current stable-1.0 branch to make sure it didn't regress in some ways and that the bugs you care about have been fixed. Hey Stéphane, The stable branch did fine in my testing here. I did explicitly test the autostart stuff on both OL6.x (sysvinit) and OL7 (systemd). Thanks! Yeah, stable branch is running fine here on Fedora 20. Thanks! Regards, Mike -- Michael H. Warfield (AI4NB) | (770) 978-7061 | m...@wittsend.com /\/\|=mhw=|\/\/ | (678) 463-0932 | http://www.wittsend.com/mhw/ NIC whois: MHW9 | An optimist believes we live in the best of all PGP Key: 0x674627FF| possible worlds. A pessimist is sure of it! Good to hear it looks good for you! I've been a bit more busy than I expected today so I'll have to postpone the release to tomorrow. Tagging is pretty quick, but I need a couple of hours to write the release announcement, possibly even a bit longer given the number of changes that happened since 1.0.3. -- Stéphane Graber Ubuntu developer http://www.ubuntu.com signature.asc Description: Digital signature ___ lxc-devel mailing list lxc-devel@lists.linuxcontainers.org http://lists.linuxcontainers.org/listinfo/lxc-devel
