[lxc-users] LXC 2.0.4, LXCFS 2.0.3 and LXD 2.0.4 have been released!

[Stéphane Graber]

Hello everyone,

Today the LXC project is pleased to announce the release of:
 - LXC 2.0.4
 - LXD 2.0.4
 - LXCFS 2.0.3

They each contain the accumulated bugfixes since the previous round of
bugfix releases a bit over a month ago.

The detailed changelogs can be found at:
 - https://linuxcontainers.org/lxc/news/
 - https://linuxcontainers.org/lxcfs/news/
 - https://linuxcontainers.org/lxd/news/

As a reminder, the 2.0 series of all of those is supported for bugfix
and security updates up until June 2021.

Thanks to everyone who contributed to those projects and helped make
this possible!


Stéphane Graber
On behalf of the LXC, LXCFS and LXD development teams


signature.asc
Description: PGP signature
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] Unable to delete lxc container

[conandor]

I try to delete a container "$ lxc delete test” but it return "errors: No known 
data errors”. Any idea what I missing here? I’m on Ubuntu 14.04 server.___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] LXC/Samba networking challenge

[Serge E. Hallyn]

On Sun, Aug 14, 2016 at 05:57:49PM +0300, Andrey Repin wrote:
> Greetings, All!
> 
> I've just figured out a problem, but can't seems to find a solution.
> I have a number of containers serving content to the network through samba
> shares.
> 
> The containers' configuration is rather simple and does work for most part
> just right.
> 
> # Common configuration
> lxc.include = /usr/share/lxc/config/ubuntu.common.conf
> 
> # Container specific configuration
> lxc.rootfs = /home/.lxc/build-trusty/rootfs
> lxc.rootfs.backend = dir
> lxc.utsname = build-trusty
> lxc.arch = i686
> 
> # Network configuration
> lxc.network.type = macvlan
> lxc.network.macvlan.mode = bridge
> lxc.network.link = eth0
> 
> lxc.network.hwaddr = 00:16:3e:69:05:85
> lxc.network.name = eth0
> lxc.network.flags = up
> 
> The Samba configured as AD client, and here's the two lines that are related
> to the problem:
> 
> interfaces = lo, eth0

What if you get rid of the comma?

(going by https://www.samba.org/~tpot/articles/multiple-interfaces.html)

> bind interfaces only = Yes
> 
> Now, the smbd is starting all right, and properly serving on lo, but failing
> to bind to the eth0 for some reason.
> Setting "bind interfaces only = No" lets it work, but that's not the desirable
> configuration.
> 
> Samba 4.3.11
> LXC 2.0.3
> 
> 
> -- 
> With best regards,
> Andrey Repin
> Sunday, August 14, 2016 17:45:49
> 
> Sorry for my terrible english...
> 
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Apparmor DENIED messages in the logs

[Andrey Repin]

Greetings, Andrey Repin!

> Greetings, All!

> [ 5408.633325] type=1400 audit(1471009220.304:57): apparmor="DENIED"
> operation="mount" info="failed flags match" error=-13
> profile="lxc-container-default" name="/" pid=12887 comm="mount" flags="ro, 
> remount"

> Host: Ubuntu 12.04
> Guests: 12.04 and 14.04
> LXC: 2.0.3

> I'm getting quite a bit of these lines in the logs.
> Is this normal?

> Container configurations are quite trivial, I've even removed all questionable
> binds.

Got a similar failure report in #lxcontainers, and this made me realize one 
thing.
We both use custom container root, and we both trying to bind mount stuff into
container.
I've tried to tell apparmor to behave, but it seems I've lost my grasp.
Can anyone help out here please?


-- 
With best regards,
Andrey Repin
Monday, August 15, 2016 18:50:19

Sorry for my terrible english...

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] Crucial LXD, Bind Mounts & Gluster Question

[Zach Lanich]

I would have to at very least chown the subdirectory to the same user the 
container is running on in order to have write access to it from with in the 
container, but that was my thought that the volume itself provides enough 
protection. My friend who is an experienced systems administrator seems to be 
very uncomfortable with the idea of bind mounting into the container, as he 
thinks it kind of breaks the isolation that the containers provide when adding 
write access to the mount, Thoughts?


Best Regards,

Zach Lanich
Owner/Lead Developer
weCreate LLC
www.WeCreate.com
814.580.6636

> On Aug 14, 2016, at 2:21 AM, Marat Khalili  wrote:
> 
> Hello Zach,
> 
> > Gluster Volume subdirectories Bind Mounted into their respective containers 
> > (i.e. /data/gluster/user1 -> container:/data/gluster)
> 
> Considering this line, do you even depend on ACLs? I'd think bind mounts 
> provide sufficient protection by itself, as long as server demons run outside 
> containers.
> 
> (I'm currently facing similar problem, but don't have first-hand experience 
> solving it yet.)
> -- 
> 
> With Best Regards,
> Marat Khalili
> 
>> On August 14, 2016 4:50:52 AM GMT+03:00, Zach Lanich  
>> wrote:
>> Hey guys, I have a crucial decision I have to make about a platform I’m 
>> building, and I really need your help to make this decision in regards to 
>> security. Here’s what I’m trying to accomplish:
>> 
>> Platform: Highly Available Wordpress hosting using Galera, GlusterFS & LXD 
>> (don’t worry about the SQL part)
>> - One container per customer on a VM (or ded server)
>> - (preferably) One 3 node GlusterFS Cluster for the Wordpress files of all 
>> customers’ containers
>> - GlusterFS volume divided into subdirectories (one per customer), with ACLs 
>> to control permissions (see *)
>> - Gluster Volume subdirectories Bind Mounted into their respective 
>> containers (i.e. /data/gluster/user1 -> container:/data/gluster)
>> - LXC User/Group mappings to make the ACLs work
>> 
>> My concerns:
>> - (*) Although the containers are isolated (all but the shared kernel), and 
>> that in itself is probably secure enough to feel ok about it, introducing a 
>> shared Gluster volume into the mix and depending on ACLs makes me a bit 
>> nervous. I’d like your opinions on what the norm is in the world (the PaaSs, 
>> etc) and if you guys think this is a terrible idea. If you think this is not 
>> a good way of handling my needs, PLEASE help me find a better solution.
>> 
>> My hangups:
>> - I know PaaSs have found incredibly efficient ways to provide containerized 
>> apps with high availability, and I tend to highly doubt they’re throwing up 
>> 3+ GlusterFS VMs for every single app they deploy. This to me seems like an 
>> impossibly cost-ineffective approach. Correct me if I’m wrong. That being 
>> said, I’m not 100% sure how they’re doing it.
>> 
>> Odd thoughts & alternative solutions that have crossed my mind:
>> - To avoid using a shared single Gluster Volume and ACLs altogether, while 
>> also avoiding too much infrastructure cost, I’ve thought of possible putting 
>> up a 3 VM Gluster cluster, each with matching LXD Containers on them with 
>> Gluster server daemons running in those containers. I could use those 
>> containers & networking to simulate having multiple 3 node Gluster Clusters, 
>> each being dedicated to a respective containerized app on the App Server. 
>> This to me seems like it would be an unnecessarily complex and annoying to 
>> maintain solution, so please help me here.
>> 
>> I hugely appreciate anyones help and this is a huge passion project of mine 
>> and I’ve dedicated an absurd number of hours reading to try and figure this 
>> out.
>> 
>> Best Regards,
>> 
>> Zach Lanich
>> Business Owner, Entrepreneur, Creative
>> Owner/CTO
>> weCreate LLC
>> www.WeCreate.com
>> 
>> 
>> lxc-users mailing list
>> lxc-users@lists.linuxcontainers.org
>> http://lists.linuxcontainers.org/listinfo/lxc-users
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] clarification

[Matt Barrett]

Interesting. I've been using LXD but I thought of it as LXD for the
container server side which hosted LXC containers. I guess that was the
wrong way of looking at it based on your comments.

On Aug 11, 2016 5:24 PM, "Sean McNamara"  wrote:

> On Thu, Aug 11, 2016 at 8:12 PM, Worth Spending 
> wrote:
> > I'm currently reading thru the documentation at:
> https://linuxcontainers.org
> > to learn lxc.
> >
> > There seems to be multiple ways of running lxc commands.
> >
> > lxc-start, lxc-stop, lxc-attach, lxc-ls
>
>
> The "hyphenated" commands are from the "legacy" LXC command line interface.
>
>
> >
> > or lxc with sub commands.
> >
> > lxc start
> >
> > lxc stop
> >
> > lxc list
>
> The "non-hyphenated" commands are for the **LXD** (D, not C) container
> hypervisor. This is a completely different product/application than
> LXC. The LXD client binary, `lxc`, is extremely unfortunately named
> and thus very confusing for new users, which has been discussed about
> 9000 times on this mailing list.
>
>
>
>
> >
> > So, the question is: What is the current preferred usage for lxc
> commands?
> > hyphenated commands or lxc with sub commands?
>
>
> You need to look into the benefits and drawbacks of using either LXC
> or LXD (consider each one separately in terms of what it offers, how
> it's implemented, and how it's used) and make a decision. If you use
> the hyphenated LXC commands, any containers you create in that
> environment will be completely invisible to LXD, and vice versa. They
> each keep track of containers differently so LXD does not know about
> LXC containers and LXC does not know about LXD containers.
>
>
> >
> > Thanks...
> >
> > ___
> > lxc-users mailing list
> > lxc-users@lists.linuxcontainers.org
> > http://lists.linuxcontainers.org/listinfo/lxc-users
> ___
> lxc-users mailing list
> lxc-users@lists.linuxcontainers.org
> http://lists.linuxcontainers.org/listinfo/lxc-users
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

[lxc-users] volumes in LXD

[Yonsy Solis]

Hi guys

I write for work, a playbook script and first one, i build this with lxd 
[1], very basic but works for me.


Now, i use the same playbook in development too, but i like to know if 
something like Volumes in Docker [2] can be applied easily with lxd too. 
With easily i am thinking more in a development mind, one short command 
line needed in the host running the containers, to mount easily the 
directory code in the code lxd container.



[1] https://gist.github.com/ysolis/3ff6a2b89b7e0aaf0af5967fbbb2ee2e

[2] https://blog.docker.com/2015/04/docker-tutorial-3-fun-with-volumes/


--

Yonsy Solis

___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users

Re: [lxc-users] How frequently used containers for Cloud solutions

[Fajar A. Nugraha]

On Sun, Aug 14, 2016 at 5:07 AM, Thouraya TH  wrote:
> Hi all,
>
> Please, I'd like to know how frequently containers are used for Cloud
> solutions and what kind of applications use this type of virtualization.
>
> Please, where can I find these details?

Is there anything in particular you have in mind? Are you working on a
school assignment?

Without any additional details, I suggest you start from Google search
result, and optionally read these:
https://en.wikipedia.org/wiki/Operating-system-level_virtualization
http://www.ubuntu.com/cloud/lxd
http://www.theregister.co.uk/2014/05/23/google_containerization_two_billion/

*not all links are about lxc/lxd, but should be relevant if you ask
about "containers"

-- 
Fajar
___
lxc-users mailing list
lxc-users@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-users