Well if we really want to go that route, we can
a. specify a monitor-port in $lxcpath/lxc.conf
b. write a world-unreadable $lxcpath/monitor-secret file
c. require catting $lxcpath/monitor-secret at initial connection
so /var/lib/lxc/lxc.conf can have monitor-port=9998, while
/home/serge/lxcbas
Hi Serge,
Yeah you are correct we need regular users to be able to monitor their own
containes. I guess we can encrypt the messages but I'm not going there :)
Cheers,
On Wed, Apr 17, 2013 at 8:52 AM, Serge Hallyn wrote:
> Quoting S.Çağlar Onur (cag...@10ur.org):
> > Hi there,
> >
> > What abou
Quoting S.Çağlar Onur (cag...@10ur.org):
> Hi there,
>
> What about using AF_INET but binding a restricted port while adding a new
> field to the message? As an example we can start to create a hmac (or
> something like that) per container in the creation time and save that into
> LXCPATH/CONTAINE
Hi there,
What about using AF_INET but binding a restricted port while adding a new
field to the message? As an example we can start to create a hmac (or
something like that) per container in the creation time and save that into
LXCPATH/CONTAINERNAME/hmac. Then both client (can add that value to
m
Quoting Dwight Engen (dwight.en...@oracle.com):
> On Tue, 16 Apr 2013 08:52:56 -0500
> Serge Hallyn wrote:
>
> > Quoting S.Çağlar Onur (cag...@10ur.org):
> > > Hi Serge,
> > >
> > > I was just following your lead as you said you don't wan't any long
> > > running monitor daemon :)
> >
> > Yup,
On Tue, 16 Apr 2013 08:52:56 -0500
Serge Hallyn wrote:
> Quoting S.Çağlar Onur (cag...@10ur.org):
> > Hi Serge,
> >
> > I was just following your lead as you said you don't wan't any long
> > running monitor daemon :)
>
> Yup, at this point I"m going for the least bad solution. (since the
> be
Quoting S.Çağlar Onur (cag...@10ur.org):
> Hi Serge,
>
> I was just following your lead as you said you don't wan't any long running
> monitor daemon :)
Yup, at this point I"m going for the least bad solution. (since the best
solution, multicast af_unix, isn't possible :)
> Also I'm not sure ho
On 04/15/2013 07:18 PM, Serge Hallyn wrote:
> Quoting Daniel Lezcano (daniel.lezc...@free.fr):
>> On 04/15/2013 07:53 AM, S.Çağlar Onur wrote:
>>> Hi Daniel,
>>>
>>>
>>> On Sun, Apr 14, 2013 at 4:42 PM, Daniel Lezcano
>>> mailto:daniel.lezc...@free.fr>> wrote:
>>>
>>> On 04/14/2013 09:56 PM, S.
Hi Serge,
I was just following your lead as you said you don't wan't any long running
monitor daemon :) Also I'm not sure how does that daemon is going to help
starting multiple containers concurrently using only API. I'm guessing the
first request will cause that daemon to start and it will never
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> On 04/15/2013 07:53 AM, S.Çağlar Onur wrote:
> > Hi Daniel,
> >
> >
> > On Sun, Apr 14, 2013 at 4:42 PM, Daniel Lezcano
> > mailto:daniel.lezc...@free.fr>> wrote:
> >
> > On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
> > > Hi all,
> > >
Hi Daniel,
Seems like my assumption was wrong (I was under the impression that calling
setsockopt with SO_BROADCAST will require root privileges) as I was able to
send fake state updates with my user account using following fake client;
#include
#include
#include
#include
#include
#include
Hi Daniel,
On Mon, Apr 15, 2013 at 5:14 AM, Daniel Lezcano wrote:
> On 04/15/2013 07:53 AM, S.Çağlar Onur wrote:
> > Hi Daniel,
> >
> >
> > On Sun, Apr 14, 2013 at 4:42 PM, Daniel Lezcano
> > mailto:daniel.lezc...@free.fr>> wrote:
> >
> > On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
> >
On 04/15/2013 07:53 AM, S.Çağlar Onur wrote:
> Hi Daniel,
>
>
> On Sun, Apr 14, 2013 at 4:42 PM, Daniel Lezcano
> mailto:daniel.lezc...@free.fr>> wrote:
>
> On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
> > Hi all,
> >
> > I had some free time today so I tried to implement something
Hi Daniel,
On Sun, Apr 14, 2013 at 4:42 PM, Daniel Lezcano wrote:
> On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
> > Hi all,
> >
> > I had some free time today so I tried to implement something using
> > AF_INET messages over loopback broadcast address. I'm not including
> > the patch here becau
On 04/14/2013 09:56 PM, S.Çağlar Onur wrote:
> Hi all,
>
> I had some free time today so I tried to implement something using
> AF_INET messages over loopback broadcast address. I'm not including
> the patch here because gmail web interface damages it and that's what
> I use right now so please use
Hi all,
I had some free time today so I tried to implement something using AF_INET
messages over loopback broadcast address. I'm not including the patch here
because gmail web interface damages it and that's what I use right now so
please use [1] to see it.
I'm sending it to get your feedback and
Hi Daniel,
I might be completely wrong and I'm only asking for educational purposes as
I started to read netlink docs couple of hours ago but it looks like it's
possible to crete new netlink protocol/group and use it for IPC between
userspace applications, in fact it looks like that's what udev-mo
On 04/12/2013 06:55 PM, S.Çağlar Onur wrote:
> I'm not experienced with it so please forgive me if I'm talking
> non-sense but what about switching back to using (or abusing depending
> on your point of view) netlink via libnl?
Because it is much more than abusing :) It is hacking the rtnetlink
se
I'm not experienced with it so please forgive me if I'm talking non-sense
but what about switching back to using (or abusing depending on your point
of view) netlink via libnl?
On Fri, Apr 12, 2013 at 10:02 AM, Serge Hallyn wrote:
> Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> > Sorry for
Quoting Daniel Lezcano (daniel.lezc...@free.fr):
> Sorry for jumping so late in the thread but I disagree to use DBUS with
> LXC because of the dependency with more packages, LXC has been designed
> to be stand alone, nothing prevent to add more complexity and
> dependencies but on top of LXC not i
On 04/10/2013 09:42 PM, Stéphane Graber wrote:
> On 04/10/2013 08:15 PM, Serge Hallyn wrote:
>> Quoting Christian Seiler (christ...@iwakd.de):
>>> Hi there,
>>>
Let's say I do
sudo lxc-monitor -n r1 -n r2
and now do
sudo lxc-start -n r1
How do we k
On 04/10/2013 08:15 PM, Serge Hallyn wrote:
> Quoting Christian Seiler (christ...@iwakd.de):
>> Hi there,
>>
>>> Let's say I do
>>>
>>> sudo lxc-monitor -n r1 -n r2
>>>
>>> and now do
>>>
>>> sudo lxc-start -n r1
>>>
>>> How do we know to send the 'started' event to the lxc-monitor, since
>
Quoting Christian Seiler (christ...@iwakd.de):
> Hi there,
>
> > Let's say I do
> >
> > sudo lxc-monitor -n r1 -n r2
> >
> > and now do
> >
> > sudo lxc-start -n r1
> >
> > How do we know to send the 'started' event to the lxc-monitor, since
> > there was not yet a lxc-start daemon run
Hi there,
> Let's say I do
>
> sudo lxc-monitor -n r1 -n r2
>
> and now do
>
> sudo lxc-start -n r1
>
> How do we know to send the 'started' event to the lxc-monitor, since
> there was not yet a lxc-start daemon running?
Just to throw my 2¢ in there - why not use DBus for that? It
Quoting Stéphane Graber (stgra...@ubuntu.com):
> On 04/10/2013 06:43 PM, Serge Hallyn wrote:
> > Quoting Stéphane Graber (stgra...@ubuntu.com):
> >> On 04/10/2013 06:49 AM, Serge Hallyn wrote:
> >>> Quoting S.Çağlar Onur (cag...@10ur.org):
> Hi Serge,
>
> On Tue, Apr 9, 2013 at 4:47
On 04/10/2013 06:43 PM, Serge Hallyn wrote:
> Quoting Stéphane Graber (stgra...@ubuntu.com):
>> On 04/10/2013 06:49 AM, Serge Hallyn wrote:
>>> Quoting S.Çağlar Onur (cag...@10ur.org):
Hi Serge,
On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn
wrote:
> All right you made m
Quoting Stéphane Graber (stgra...@ubuntu.com):
> On 04/10/2013 06:49 AM, Serge Hallyn wrote:
> > Quoting S.Çağlar Onur (cag...@10ur.org):
> >> Hi Serge,
> >>
> >> On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn
> >> wrote:
> >>
> >>> All right you made me finally take a closer look at the monitor cod
On 04/10/2013 06:49 AM, Serge Hallyn wrote:
> Quoting S.Çağlar Onur (cag...@10ur.org):
>> Hi Serge,
>>
>> On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn wrote:
>>
>>> All right you made me finally take a closer look at the monitor code
>>> (which I'd been avoiding). It's much simpler than I'd imagin
Quoting S.Çağlar Onur (cag...@10ur.org):
> Hi Serge,
>
> On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn wrote:
>
> > All right you made me finally take a closer look at the monitor code
> > (which I'd been avoiding). It's much simpler than I'd imagined. So
> > here are the challenges:
> >
> > 1.
Hi Serge,
On Tue, Apr 9, 2013 at 4:47 PM, Serge Hallyn wrote:
> All right you made me finally take a closer look at the monitor code
> (which I'd been avoiding). It's much simpler than I'd imagined. So
> here are the challenges:
>
> 1. lxc-monitor should be able to watch 'all containers' (at le
All right you made me finally take a closer look at the monitor code
(which I'd been avoiding). It's much simpler than I'd imagined. So
here are the challenges:
1. lxc-monitor should be able to watch 'all containers' (at least under
a given lxcpath). That is actually the strong reason to object
Hi Serge,
Got it, in this case I'm waiting Daniel to respond before changing the
patch based on your comments.
On Tue, Apr 9, 2013 at 8:47 AM, Serge Hallyn wrote:
> Quoting S.Çağlar Onur (cag...@10ur.org):
> > From: "S.Çağlar Onur"
> >
> > Otherwise trying to start N containers in parallel giv
Quoting S.Çağlar Onur (cag...@10ur.org):
> From: "S.Çağlar Onur"
>
> Otherwise trying to start N containers in parallel gives "lxc_container: bind
> : Address already in use" error.
>
> Found while using Go bindings to create/start/stop large number of containers
> in parallel so I reproduced
From: "S.Çağlar Onur"
Otherwise trying to start N containers in parallel gives "lxc_container: bind :
Address already in use" error.
Found while using Go bindings to create/start/stop large number of containers
in parallel so I reproduced the same using Python API to rule out possible Go
rela
34 matches
Mail list logo
