I use LXC containers heavily these days, and I thought it would be great if I could add Unicon to the mix. I wrote a little library to do just that. You can find the code here:
Still in an early stage, but I can do some basic operations like create/start/stop/freeze/unfreeze. I will continue to improve and add new features as I go. If anyone is interested in helping out or have ideas how to best do things in this arena please let me know.
Cheers,
Jafar
Last edit: Jafar 2016-10-12
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You should be able to create containers directlty from the library. Do you get errors if you run the sample program there? The script at the top level should prepare the environment (assumes ubuntu at the moment) to run container, unpriviliged ones. If you have any problems please let me know. I'm working on supporting issuing commands from the unicon program to be run inside the container.
I added the Chef recipe for testing and convience but you don't need that at all. I will add more instrcutions on how to use that one as well. I added it to quickly build a machine with Unicon setup to serve as sanbox for quick isolated testing.
Cheers,
Jafar
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ah, getting your first userland running might be tircky if this is the fisrt time you do it since you have to iron out some configuration details. That is why I wrote the script luxify.sh. To debug, I'd try to boot the container up from command line and see what happen.
lxc-start -l DEBUG -F -n uniconvm
-l DEBUG ramps up your logging level, and -F keeps eveything in the foreground (by default the container process is daemonized). You should be able to see what goes wrong there. The two main reasons that cause booting to fail is that your ~/.local directory needs to be marked as executabe (-x premession). The second reason is networking. Check /etc/lxc/lxc-usernet and make sure it has a line like this:
$USER veth $BRDGNAME 50
where user is your user name, and $BRDGNAME is lxc network bridge.
Again, look at luxify.sh to get some clues on what to configure if you don't want to run the script itself.
Once you get userland containers to run, you never look back! there is no reason to run them with root permissions for the vast majority of cases.
Cheers,
Jafar
Last edit: Jafar 2017-08-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Just needed the networking bridge config and the +x on ~/.local.
$ ./hellolxc
Initialize LXC library...
creating a container named uniconvm...
booting uniconvm...
loop for 20 seconds report the state every 5 seconds
uniconvm is "RUNNING"
uniconvm is "RUNNING"
uniconvm is "RUNNING"
uniconvm is "RUNNING"
uniconvm is "STOPPED"
Time for cleanup, destroying uniconvm
All OK, Goodbye!
:-)
Cheers,
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
run some commands inside uniconvm
uname : Linux
uname -a : Linux uniconvm 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
uname -r : 4.4.0-21-generic
hostname : uniconvm
whoami : root
pwd : /
Reading package lists... Done
Building dependency tree
Reading state information... Done
htop is already the newest version (2.0.1-1ubuntu1).
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think lxcunicon.c needs to be commited to the github space; the copy I see has no attach function defined. Figured out most of the rest just by guessing, before looking at your repository, but I'm not sure how to define the attach in C code.
Cheers,
Brian
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
prompt$ unicon -s hellolxc.icn -x
Initialize LXC library...
container uniconvm already exists
booting uniconvm...
run some commands inside uniconvm
uname : Linux
uname -a : Linux uniconvm 4.4.0-43-generic #63-Ubuntu SMP Wed Oct 12 13:48:03 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
uname -r : 4.4.0-43-generic
hostname : uniconvm
whoami : root
pwd : /
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
lsof strace
The following NEW packages will be installed:
htop
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 76.4 kB of archives.
After this operation, 215 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu xenial-updates/universe amd64 htop amd64 2.0.1-1ubuntu1 [76.4 kB]
Fetched 76.4 kB in 0s (159 kB/s)
Selecting previously unselected package htop.
(Reading database ... 13019 files and directories currently installed.)
Preparing to unpack .../htop_2.0.1-1ubuntu1_amd64.deb ...
Unpacking htop (2.0.1-1ubuntu1) ...
Processing triggers for mime-support (3.59ubuntu1) ...
Setting up htop (2.0.1-1ubuntu1) ...
loop for 20 seconds report the state every 5 seconds
uniconvm is "RUNNING"
uniconvm is "RUNNING"
uniconvm is "RUNNING"
uniconvm is "RUNNING"
uniconvm is "STOPPED"
All OK, Goodbye!
Nice add, Jafar.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks Brian. Good to see my experimental code working at your end.
I just added support for IO redirection. Things are slowly getting to the point where this could be useful and all run from Unicon :-)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was working with Canonical a few years back, to demonstrate GnuCOBOL as a JuJu Charm (Ubuntu Cloud). This is the kind of effort that could make for an easy to wield demo of Unicon in the Cloud. Tap a browser icon, and away you go.
Full disclosure, I think the cloud is a gold rush; a few rare few will make millions/billions, most people will struggle up the mountain, spend 10 years working very hard, to realize they made just enough money to buy a coach ticket home, and then entire towns will be laid waste once the rush is over. But that is personal opinion, and most people seem quite happy to pay the bills that are making a few more billionaires.
It was pretty cool though. At the time I was running Fedora; used a libvirt virtual image of Ubuntu, to run a local JuJu charm cloud instance, that spun off another OS image, to compile a version of GnuCOBOL and host some CGI programs. A screen shot is part of the GnuCOBOL FAQ, http://open-cobol.sourceforge.net/faq/index.html#can-gnucobol-be-used-for-cgi
I barely finished the demo, and then realized that people were getting sucked into the cloud and burning money they shouldn't be burning...
On ubuntu Zesty 64,
luxify.sh :
systemd-services # does not exist
We have systemd-container and 11 more.
systemd-container has nspawn.
I forgot where it was before.
What does one need from systemd-services?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When I first created this script on Ubuntu 14.04 there were many missing packages that you need to get going. With 16.04 the list is a lost shorter and my script is probably an overkill. You might be Ok to move on without systemd-services. Did you try creating a container after runing the script?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
BTW, lxcunicon is now included with unicon sources under plugins/src. There is a sample program under plugins/src/lxcunicon/tests. plugins/lib is now one of the standard/default locations for adding new loadbale modules. So if you build lxcunicon you should be able to use lxcunicon (.so and .u files) from anywhere on your machine without specifying absolute paths.
In the last few nights I have been working on a Unicon program that lanuches containers of different platforms (ubuntu/fedora/centos/debian... i386/amd64). It then checkout, build and test Unicon on each and every container and generate a report for each one. I'm planning to run that as a nightly task on one of my machines and have the test reports available for developers/public. I might check in the program itself under unicon/tests somewhere..
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use LXC containers heavily these days, and I thought it would be great if I could add Unicon to the mix. I wrote a little library to do just that. You can find the code here:
https://github.com/Jafaral/lxcunicon
Still in an early stage, but I can do some basic operations like create/start/stop/freeze/unfreeze. I will continue to improve and add new features as I go. If anyone is interested in helping out or have ideas how to best do things in this arena please let me know.
Cheers,
Jafar
Last edit: Jafar 2016-10-12
A good idiom for a library of functions in a class, thanks, Jafar.
I was just about to razz you that LCX create didn't seem to build in a Unicon, now I see it's a chef recipe. Nice.
Cheers,
Brian
Brian,
You should be able to create containers directlty from the library. Do you get errors if you run the sample program there? The script at the top level should prepare the environment (assumes ubuntu at the moment) to run container, unpriviliged ones. If you have any problems please let me know. I'm working on supporting issuing commands from the unicon program to be run inside the container.
I added the Chef recipe for testing and convience but you don't need that at all. I will add more instrcutions on how to use that one as well. I added it to quickly build a machine with Unicon setup to serve as sanbox for quick isolated testing.
Cheers,
Jafar
creates work. booting up the container failed.
I'm willing to bet it is a poorly configured local LXC infrastructure install (still have a few issues with unprivileged userland containers)
$ unicon -s -t hellolxc.icn -x : main(list_1 = []) Initialize LXC library... hellolxc.icn : 9 | LXC__LXC("./lxcunicon.so") __faux.icn : 8 | | LXC__LXCinitialize() __faux.icn : 18 | | LXC__LXCinitialize failed __faux.icn : 12 | | LXC__LXC_initially(LXC__LXC_1,"./lxcunicon.so") lxcunicon.icn : 78 | | LXC__LXC_initially returned &null __faux.icn : 13 | LXC__LXC returned LXC__LXC_1 hellolxc.icn : 11 | LXC__LXC_Container(LXC__LXC_1,"uniconvm") lxcunicon.icn : 34 | | LXC__LXContainer("uniconvm",&null,&null,&null,&null,&null) __faux.icn : 8 | | | LXC__LXContainerinitialize() __faux.icn : 18 | | | LXC__LXContainerinitialize failed __faux.icn : 12 | | | LXC__LXContainer_initially(LXC__LXContainer_1) lxcunicon.icn : 124 | | | | LXC__LXC_Arch(LXC__LXC_1) lxcunicon.icn : 42 | | | | LXC__LXC_Arch returned (variable = "amd64") lxcunicon.icn : 125 | | | LXC__LXContainer_initially returned &null __faux.icn : 13 | | LXC__LXContainer returned LXC__LXContainer_1 lxcunicon.icn : 34 | LXC__LXC_Container returned LXC__LXContainer_1 hellolxc.icn : 13 | LXC__LXContainer_Exist(LXC__LXContainer_1) lxcunicon.icn : 94 | LXC__LXContainer_Exist failed creating a container named uniconvm... hellolxc.icn : 17 | LXC__LXContainer_Create(LXC__LXContainer_1,&null,&null,&null) lxcunicon.icn : 91 | LXC__LXContainer_Create returned (variable = 1) booting uniconvm... hellolxc.icn : 22 | LXC__LXContainer_Start(LXC__LXContainer_1) lxcunicon.icn : 98 | LXC__LXContainer_Start failed couldn't do itCheers,
Brian
Ah, getting your first userland running might be tircky if this is the fisrt time you do it since you have to iron out some configuration details. That is why I wrote the script luxify.sh. To debug, I'd try to boot the container up from command line and see what happen.
-l DEBUG ramps up your logging level, and -F keeps eveything in the foreground (by default the container process is daemonized). You should be able to see what goes wrong there. The two main reasons that cause booting to fail is that your ~/.local directory needs to be marked as executabe (-x premession). The second reason is networking. Check /etc/lxc/lxc-usernet and make sure it has a line like this:
$USER veth $BRDGNAME 50
where user is your user name, and $BRDGNAME is lxc network bridge.
Again, look at luxify.sh to get some clues on what to configure if you don't want to run the script itself.
Once you get userland containers to run, you never look back! there is no reason to run them with root permissions for the vast majority of cases.
Cheers,
Jafar
Last edit: Jafar 2017-08-31
Just needed the networking bridge config and the +x on ~/.local.
:-)
Cheers,
Brian
Cool! Now we just need an "attach" method to run any command inside the
container on the fly!
You can now send coammnds to be run inside the container via the new container method: Attach(). Here is a code snippet with output:
write("run some commands inside ", name) cmds := ["uname", "uname -a", "uname -r" , "hostname", "whoami", "pwd", "apt-get install htop"] every writes(left(cmd:=!cmds, 12), ": ") & c.Attach(cmd)And the output:
I think lxcunicon.c needs to be commited to the github space; the copy I see has no
attachfunction defined. Figured out most of the rest just by guessing, before looking at your repository, but I'm not sure how to define theattachin C code.Cheers,
Brian
Ahh! I missed to commit that one.... but I just did. Thanks for catching it.
My next step is I/O redirection when issuing commands via Attach(). Stay tuned!
Cheers,
Jafar
Worked the charm
Nice add, Jafar.
Thanks Brian. Good to see my experimental code working at your end.
I just added support for IO redirection. Things are slowly getting to the point where this could be useful and all run from Unicon :-)
Kudos. Yes it could come in handy, Jafar.
I was working with Canonical a few years back, to demonstrate GnuCOBOL as a JuJu Charm (Ubuntu Cloud). This is the kind of effort that could make for an easy to wield demo of Unicon in the Cloud. Tap a browser icon, and away you go.
Full disclosure, I think the cloud is a gold rush; a few rare few will make millions/billions, most people will struggle up the mountain, spend 10 years working very hard, to realize they made just enough money to buy a coach ticket home, and then entire towns will be laid waste once the rush is over. But that is personal opinion, and most people seem quite happy to pay the bills that are making a few more billionaires.
It was pretty cool though. At the time I was running Fedora; used a
libvirtvirtual image of Ubuntu, to run a local JuJu charm cloud instance, that spun off another OS image, to compile a version of GnuCOBOL and host some CGI programs. A screen shot is part of the GnuCOBOL FAQ, http://open-cobol.sourceforge.net/faq/index.html#can-gnucobol-be-used-for-cgiI barely finished the demo, and then realized that people were getting sucked into the cloud and burning money they shouldn't be burning...
https://jujucharms.com/u/bwtiffin/gnucobol-sample
Local Containers seem like a much more human friendly endeavour. :-)
Have good, make well,
Brian
On ubuntu Zesty 64,
luxify.sh :
systemd-services # does not exist
We have systemd-container and 11 more.
systemd-container has nspawn.
I forgot where it was before.
What does one need from systemd-services?
When I first created this script on Ubuntu 14.04 there were many missing packages that you need to get going. With 16.04 the list is a lost shorter and my script is probably an overkill. You might be Ok to move on without systemd-services. Did you try creating a container after runing the script?
BTW, lxcunicon is now included with unicon sources under plugins/src. There is a sample program under plugins/src/lxcunicon/tests. plugins/lib is now one of the standard/default locations for adding new loadbale modules. So if you build lxcunicon you should be able to use lxcunicon (.so and .u files) from anywhere on your machine without specifying absolute paths.
In the last few nights I have been working on a Unicon program that lanuches containers of different platforms (ubuntu/fedora/centos/debian... i386/amd64). It then checkout, build and test Unicon on each and every container and generate a report for each one. I'm planning to run that as a nightly task on one of my machines and have the test reports available for developers/public. I might check in the program itself under unicon/tests somewhere..