text:
- Apps
- Help
- Blog
- Screenshots
- TurnKey Hub
You are here
spammy - Fri, 2016/07/08 - 18:02
Are there any plans to make TKL images available via a LXD compatible image server?
What needs to change?
Jeremy Davis - Wed, 2016/07/13 - 12:06
TBH I wasn't aware that LXD had any image servers. But a quick google demonstrates that indeed there are! :)
Do you know much about it? Like what requirements there are to have an app listed? From what I can see the "offical" LXD library images are all built by sripts contained within a specific GitHub repo. If that's the requirement then it's too hard IMO. If there is some other mechanism then it may well be possible...
Another thought is that perhaps if we can understand the requirements of a "LXD library" we could create our own?
Ok, we'll add it to the issue tracker
Jeremy Davis - Tue, 2016/07/19 - 04:53
TBH I don't know when we'll get chance to look into this further but I've added it to the tracker (https://github.com/turnkeylinux/tracker/issues/670) so we don't forget about it. TBH though unless someone from the community looks into it further I don't imagine that it will happen any time soon...
Thanks tons for the additional info
Jeremy Davis - Wed, 2016/10/19 - 03:22
That's great! It does indeed appear to be fairly straight forward.
My only reservation is that it sounds like we will need an additional (LXD) server to host the images. Obviously that in and of itself is not a big deal. But then it's another server that needs to be maintained. The "weird" Apache config (that pretends to be an LXD server - as noted by Stephane) sounds like more what we'd want. Then we could just add an additional vhost to our existing webserver (i.e. for this website) that provides the images direct from our mirror. FWIW I just posted on the GitHub thread.
Regardless it's certainly on our todo list. Unfortunately though our todo list is very long so I have no idea when we might get to it.
Stephane has replied already
Jeremy Davis - Wed, 2016/10/19 - 03:40
And has provided some alternate info that sounds like it should be really easy. We'll still need to have a play with it and configure our webserver to use it, but we should be able to script the relevant info and generate the json files automatically.
I'm still not sure when we'll get to it, but it sounds doable. If one of you guys wants to have a play with it that'd certainly push things forward, although I can't guarantee when we'd be able to implement it. The less we need to do ourselves and the easier it is for us to implement, the sooner we can roll it out...
John Carver - Sat, 2017/01/07 - 19:08
Hi Jeremy, I took a look at Stephane's suggestions and made an attempt to adapt a 14.1 lxc image to create an lxd container running on Ubuntu Xenial. I used the debian jessie files from the links Stephane provided and adapted them for a TurnKey appliance. (see the post below).
In addition to the two json files that Stephane described, you will also need to create a tarred metadata file with accompanying templates. LXD uses .xz compression by default, but gzip will also work. By convention, linuxcontainers.org uses lxd.tar.xz for the tarred metadata and templates, keeping all images in separate folders. I chose to use the same name as the original image except inserting a .lxd so that all files can be stored in the same folder.
. ├── debian-8-turnkey-tkldev_14.1-1_amd64.lxd.tar.gz ├── debian-8-turnkey-tkldev_14.1-1_amd64.tar.gz ├── metadata.yaml └── templates ├── hostname.tpl └── hosts.tpl
The metadata file must be named
{ "architecture": "x86_64", "creation_date": 1460431832, "properties": { "architecture": "x86_64", "description": "TKLDev - TurnKey Development Toolchain and Build System (20160411)", "name": "turnkey-tkldev-14.1-jessie-amd64", "os": "turnkey", "release": "jessie", "variant": "14.1" }, "templates": { "/etc/hostname": { "template": "hostname.tpl", "when": [ "create", "copy" ] }, "/etc/hosts": { "template": "hosts.tpl", "when": [ "create", "copy" ] } } }
The accompanying template files will probably be the same for all appliances. The supplied templates simply set the container.name into /etc/hostname and /etc/hosts whenever the container is created or copied. It's possible we could create other templates to perform additional functions.
{{ container.name }}
127.0.0.1 localhost 127.0.1.1 {{ container.name }} # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Stephane makes mention of two ways to implement the lxd repo, one using a customized apache server and the other using simplestreams. I couldn't figure out if simplestreams was a requirement for second method or if it was just a convenient way to create and manage the json files. There doesn't seem to be a package for simplestreams on Debian.
Information is free, knowledge is acquired, but wisdom is earned.
Thanks for your follow up and extra info John
Jeremy Davis - Thu, 2017/01/12 - 07:30
TBH this is really high on our agenda. I think it would be really awesome to provide, but not a priority for us ATM.
Still fantastic info you've shared here! Hopefully we'll get a chance to come back to this and give it some love! :)
external thread describes 'How To' convert LXC to LXD containers
bmullan - Fri, 2017/01/06 - 19:10
I know Turnkey builds LXC (lxc1) containers but there is a good external thread recently about "how to" convert original lxc1 to lxc2 (re LXD) containers.
Fajar Nugraha is one of the LXD developers and per his last statement on that thread:
There's a script to convert lxc -> lxd somewhere on this list, but I usually do things manually: (1) create a container in lxd. Start it, stop it, then look at its uid mapping (i.e. "which u/gid owns /var/lib/lxd/containers/container_name/rootfs") (2) use fuidshift with "-r" to shift your lxc container u/gid back to privileged, using the starting u/gid value in your original lxc config (should be 951968) (3) use fuidshift again, but this time without "-r", to shift your lxc container to unprivileged, using the starting u/gid value from (1) (4) move your new lxd container's original rootfs somewhere else (or delete it if you want), then replace it with rootfs from (3) (5) start your lxd containers
So if anyone has the interest to migrate an LXC container to LXD so you can then take advantage of LXD to manage it locally or remotely, use CRIU (live migration) and some of the other nice features LXD added to the original LXC (lxc1)
The "script" that Fajar refered to may be this one:
Using TurnKey images with LXD
John Carver - Sat, 2017/01/07 - 06:45
I recently started looking at LXD as an alternative to Proxmox for a development environment. I simply can't lug my home development server when I hit the road. I'm looking for a way to run multiple TurnKey images on my laptop for a self-contained development environment. I tried using LXC for this purpose a few years ago, but never quite got it to work. The good news is that LXD is compatible with the TurnKey images for Proxmox 4.x.
Following are my user notes from testing on a laptop running Ubuntu 16.04 (Xenial).
LXD Users Guide
LXD is designed to work alongside LXC and provide a simpler user interface for managing LXC containers.
$ sudo apt-get install lxd lxd-tools $ newgrp lxd
Initialize LXD:
Run the following command, selecting the default settings, except for the creation of an IPv6 network.
$ sudo lxd init Name of the storage backend to use (dir or zfs) [default=dir]: Would you like LXD to be available over the network (yes/no) [default=no]? Do you want to configure the LXD bridge (yes/no) [default=yes]? Warning: Stopping lxd.service, but it can still be activated by: lxd.socket LXD has been successfully configured.
Working with LXD:
$ lxc image list +-------+-------------+--------+-------------+------+------+-------------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE | +-------+-------------+--------+-------------+------+------+-------------+ $ lxc image copy lxc-org:/debian/jessie/amd64 local: --alias=jessie-amd64 Image copied successfully! $ lxc image list +--------------+--------------+--------+----------------------------------------+--------+---------+-----------------------------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE | +--------------+--------------+--------+----------------------------------------+--------+---------+-----------------------------+ | jessie-amd64 | 06b11f7b270f | no | Debian jessie (amd64) (20170104_22:42) | x86_64 | 94.05MB | Jan 5, 2017 at 5:40pm (UTC) | +--------------+--------------+--------+----------------------------------------+--------+---------+-----------------------------+ $ lxc launch jessie-amd64 jessie-01 Creating jessie-01 Starting jessie-01 $ lxc list +-----------+---------+---------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-----------+---------+---------------------+------+------------+-----------+ | jessie-01 | RUNNING | | | PERSISTENT | 0 | +-----------+---------+---------------------+------+------------+-----------+ $ lxc stop jessie-01 --force $ lxc list +-----------+---------+---------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-----------+---------+---------------------+------+------------+-----------+ | jessie-01 | STOPPED | | | PERSISTENT | 0 | +-----------+---------+---------------------+------+------------+-----------+ $ lxc delete jessie-01 $ lxc list +-----------+---------+---------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-----------+---------+---------------------+------+------------+-----------+
Importing TurnKey Image:
The goal is to be able to import and run TurnKey images under LXD. Fortunately the 14.x images created for Proxmox LXC format are compatible with LXD. Following the examples by Stéphane Graber, we must manually (for now) create some metadata to accompany the TurnKey image. First download the desired image from the proxmox directory on mirror.turnkeylinux.org, for example debian-8-turnkey-tkldev_14.1-1_amd64.tar.gz. Try to use a method such as rsync that preserves the original creation/modification dates.
$ rsync -av -P rsync://mirror.turnkeylinux.org/turnkeylinux/images/proxmox/debian-8-turnkey-tkldev_14.1-1_amd64.tar.gz ./
Determine the creation_date from the last modified date of the image file.
$ stat -c%y debian-8-turnkey-tkldev_14.1-1_amd64.tar.gz 2016-04-11 22:30:32.000000000 -0500 $ stat -c%Y debian-8-turnkey-tkldev_14.1-1_amd64.tar.gz 1460431832
20160411 date the image was created.
1460431832 date and time the image was created in epoch format.
architecture is x86_64 for an amd64 image. amd64 may also work for the architecture.
Create a subdirectory "templates" and the following three files in yaml format. Change the name, description, etc. corresponding to the appliance image.
{ "architecture": "x86_64", "creation_date": 1460431832, "properties": { "architecture": "x86_64", "description": "TKLDev - TurnKey Development Toolchain and Build System (20160411)", "name": "turnkey-tkldev-14.1-jessie-amd64", "os": "turnkey", "release": "jessie", "variant": "14.1" }, "templates": { "/etc/hostname": { "template": "hostname.tpl", "when": [ "create", "copy" ] }, "/etc/hosts": { "template": "hosts.tpl", "when": [ "create", "copy" ] } } }
{{ container.name }}
127.0.0.1 localhost 127.0.1.1 {{ container.name }} # The following lines are desirable for IPv6 capable hosts ::1 ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters
Create a tar file of the metadata and templates for LXD. The name could be anything, but I chose to name it similar to the original image.
$ tar -czvf debian-8-turnkey-tkldev_14.1-1_amd64.lxd.tar.gz metadata.yaml templates/*
Now import the image into LXD.
$ lxc image import debian-8-turnkey-tkldev_14.1-1_amd64.lxd.tar.gz debian-8-turnkey-tkldev_14.1-1_amd64.tar.gz --alias turnkey-tkldev_14.1_amd64 $ lxc image list +---------------------------+--------------+--------+--------------------------------------------------------------------+--------+----------+-----------------------------+ | ALIAS | FINGERPRINT | PUBLIC | DESCRIPTION | ARCH | SIZE | UPLOAD DATE | +---------------------------+--------------+--------+--------------------------------------------------------------------+--------+----------+-----------------------------+ | turnkey-tkldev_14.1_amd64 | 20c8484e42bf | no | TKLDev - TurnKey Development Toolchain and Build System (20160411) | x86_64 | 197.68MB | Jan 6, 2017 at 6:48pm (UTC) | +---------------------------+--------------+--------+--------------------------------------------------------------------+--------+----------+-----------------------------+
Next you can create (launch) a container running the image.
$ lxc launch turnkey-tkldev_14.1_amd64 tkldev Creating tkldev Starting tkldev $ lxc list +-----------+---------+---------------------+------+------------+-----------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +-----------+---------+---------------------+------+------------+-----------+ | tkldev | RUNNING | 10.76.85.211 (eth0) | | PERSISTENT | 0 | +-----------+---------+---------------------+------+------------+-----------+
Notice that launch both creates and starts the container unlike LXC which had separate commands. There is no method for loading an inithooks.conf file, but the init sequence creates one on the fly with a random password. Since there is no /dev/console, the turnkey-init is not triggered and must be run manually. Connect to the container using the 'exec' command.
$ lxc exec tkldev bash root@tkldev ~# turnkey-init ...
Information is free, knowledge is acquired, but wisdom is earned.
Using TurnKey images with LXD
John Carver - Sat, 2017/01/07 - 18:02
Hi Brian. I didn't see your preceding post because I was busy composing my post. :)
I think Fajar's script addresses a different use case, i.e. converting or moving an existing lxc1 container to an lxd container. My effort was in exploring how to use an existing proxmox (lxc1) rootfs image to create the lxd container. Admittedly I'm just learning to use LXD, so I may not be aware of all the possibilities. I haven't tried to use a 13.x (openvz) image with LXD but I suspect it would not work. I think you would first have to create a lxc1 container using the lxc-turnkey template, and then use Fajar's script to convert to lxd format.
Information is free, knowledge is acquired, but wisdom is earned.
Using TurnKey images with LXD
John Carver - Sun, 2017/01/08 - 16:56
Brian, I've run into a problem trying to run TKLdev appliance in a LXD unprivileged container. Inside the container, mount is being blocked by AppArmor even though I'm root. I've been looking for an example of how to create a profile that allows mount to operate within the container but not outside for security. I haven't found anything helpful so far. Do you have any ideas?
mount: permission denied fatal: non-zero exitcode (32) for command: mount -t aufs -o 'dirs=/turnkey/fab/bootstraps/jessie,udba=reval' 'none' 'build/bootstrap' /usr/share/fab/product.mk:476: recipe for target 'build/stamps/bootstrap' failed make: *** [build/stamps/bootstrap] Error 1
dmesg shows a number of these errors.
[360426.345856] audit: type=1400 audit(1483730835.496:72): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-tkldev_</var/lib/lxd>" name="/sys/fs/pstore/" pid=7328 comm="mount" flags="rw, nosuid, nodev, noexec, remount, relatime" [471499.216660] audit: type=1400 audit(1483841915.104:76): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-tkldev_</var/lib/lxd>" name="/" pid=25654 comm="mount" flags="ro, remount, relatime"
Information is free, knowledge is acquired, but wisdom is earned.
Using TurnKey images with LXD
bmullan - Sun, 2017/01/08 - 22:10
John.. you are correct re "I think you would first have to create a lxc1 container using the lxc-turnkey template, and then use Fajar's script to convert to lxd format."
Junaid Shahid - Wed, 2017/02/08 - 13:34
yeah he is right, I have tried that and it's worked.. !
Junaid Shahid - Thu, 2017/02/09 - 13:50
Hey thanks, I have check this, that's really cool :)
Followup on TurnKey images for LXD
John Carver - Fri, 2017/05/26 - 04:05
After I completed work on the 14.2 updates for the LXC appliance, I turned my attention back to LXD. I soon found that although images created using the process I outlined above initially worked, there were nagging issues like not being able to stop a running container or use mount within a running container. After far too much experimentation, it finally hit me that some of the issues were caused by not applying the container patches included in the lxc-turnkey template and others such as mounting in an unprivileged container required the additional changes outlined by Brian Mullan.
My first thought was to just install LXD on the 14.2 LXC appliance and script the conversion process. To my surprise, I found that development of LXD for Debian is lagging and it likely won't be ready for the upcoming release of stretch. That means a fully supported LXD appliance would have to wait until TurnKey 16.0 release (Debian 10). Stéphane Graber has outlined an alternate procedure for installing LXD on Debian stretch using snaps. If Jeremy, Alon, and Liraz are agreeable, this might be a path to develop a 15.0 LXD appliance.
In the meantime, I plan on scripting the download and conversion on my Ubuntu laptop because I really want to have a portable development environment.
Information is free, knowledge is acquired, but wisdom is earned.
Hi John, thanks for the update
Jeremy Davis - Sat, 2017/05/27 - 08:47
Your suggestion of using an LXD snap to provide a v15.x LXD host appliance sounds like a legitimate plan to me. Obviously I'll need to discuss it with the other guys, but on face value I don't see why they wouldn't be open to that.
bmullan - Sun, 2017/07/02 - 23:01
I just ran across this and you might find it interesting in regards to migrating LXC (v1) containers to LXD (lxc v2 containers)...
thread about script to migrate LXC v1 containers to LXD (lxc v2) containers
John Carver - Mon, 2017/07/03 - 05:57
Thanks for the link to the lxc-to-lxd script. Actually I had found it earlier in my research and have had some good success in using it to create LXD images. I've been planning to write a new post about how I created a TKLdev workstation on Ubuntu 16.04 using LXC and LXD. The process starts by using lxc v1 to download a TurnKey Proxmox image to a v1 container. Some additional tweaks are performed and then the lxc-to-lxd script is used to convert to a v2 container. The normal LXD commands are then used to create a v2 image. I haven't yet written a script for the process, but that's the obvious next step.
I did have an issue with DNS name resolution which I only figured out today. I couldn't figure out why the LXD container names were not being resolved by dnsmasq as they are with the LXC containers. It finally dawned on me that the hostname used within the container defaults to the appliance name, not the container name. When the container is first started, an IP address is assigned to the initial default name. For example, when I create a new container, linuxgeeks, from a Drupal8 image, the hostname for the container will be drupal8.lxd not the desired linuxgeeks.lxd. I had a dickens of a time trying to change the hostname and get dnsmasq to resolve properly. I think the hostname must be changed in three places, /etc/hosts, /etc/hostname, and /etc/network/interfaces; then networking restarted 'service networking restart'. The dnsmasq service on the host may also need to be reloaded. I think it may be possible to change the hostname before starting the container so the correct name is added at the start.
Information is free, knowledge is acquired, but wisdom is earned.
Still learning LXD ...
John Carver - Wed, 2017/07/05 - 16:09
After doing some more testing yesterday, I realized that the DNS hostname resolution problem was caused by my forgetting to include metadata.yaml and associated templates before building the LXD image. I found that I needed to add three templates, one for each of the files where the hostname needs to be changed. With the templates in place, the hostname is changed to the container name as expected and dnsmasq answers DNS queries properly. Copying or renaming the container should also change the hostname.
Now to figure out a better way to handle inithooks.conf.
Information is free, knowledge is acquired, but wisdom is earned.
FWIW we have a hostname confconsole plugin
Jeremy Davis - Thu, 2017/07/06 - 04:44
And there are plans to allow the confconsole plugins to be leveraged via commandline (and therefore could be preseeded via inithooks).
Hopefully that will be ready by the time we release v15.0 but I can't promise anything...
Created a script to convert a KVM VM to an LXD container rootfs
bmullan - Wed, 2017/12/27 - 03:45
There have been times when I found a .ISO of which I'd like to create an LXD container but in the past had to settle for using it to create a KVM VM for the application.
I finally spent some time to create a script which automatically extracts the KVM VM's rootfs and copies it to an previously created LXD container's rootfs directory.
So far this seems to work well as I've taken various .ISO from TurnkeyLinux (https://www.turnkeylinux.org/), created a KVM VM, then used the script to extract the VM's rootfs and copy it to an LXD container I'd previously prepared for it.
The script hopefully sets the UID/GID in the container correctly for use.
The script's process is fairly fast and so far has enabled me to turn up 4-5 LXD containers that originated from an .ISO file. They all seem to work okay from what I can tell.
Hopefully, I've documented the convert-vm.sh script enough so that others might improve on it and/or make use of it in the use-cases like I had.
You can find everything on Github at:
Sounds great!
Jeremy Davis - Tue, 2018/01/02 - 04:42
Good work on that Brian, and thanks for sharing your process. We're currently working on TurnKey v15.0. We still have a couple of OS issues that I plan to resolve before we release a Core RC, but once we've done that, perhaps we can look at this again and see if we can make our default LXC builds more easily compatible with LXD.
If you have any thoughts or suggestions in that regard, they'd be warmly welcomed.
TurnKey Portable Development Environment (PDE)
John Carver - Thu, 2018/02/08 - 23:18
I've opened a new forum topic, TurnKey Portable Development Environment (PDE), to continue the discussion of using LXC/LXD containers for TurnKey development work. I've been able to get TKLdev to work in an LXD (v.2) privileged container. I've also scripted the conversion from a 'proxmox' appliance image to an 'lxd' image using an LXC (v.1) container as an intermediary. Unfortunately, because of the lack of support for LXD in Debian, I've had to rely on Ubuntu 16.04 or later. Hopefully this will change soon so that LXD can be included in the 15.0 appliances.
Information is free, knowledge is acquired, but wisdom is earned.
Great work John! And thanks for the hint Brian! :)
Jeremy Davis - Mon, 2018/02/12 - 01:24
Great work guys.
Thanks for your work on this John. Great stuff! :)
And thanks for the hint Brian. It looks like LXD can be installed on Debian Stretch (via a snap). So once we get v15.0 out the door, it looks like providing LXD images for v15.x may be a possibility?! That would be cool!
LXD and Debian
John Carver - Mon, 2018/02/12 - 18:04
Thanks Jeremy. My understanding is that LXD is close to being added to Debian sid, but I'm not sure if it will ever be backported to stretch. I haven't tried using snap yet, but if you are amenable to using it as an alternative to Debian packages, then that would be the way to go. It wouldn't be setting precedent because we already use alternative installation methods (pip for Ansible, and composer for Drupal).
My work on the TurnKey PDE, was done with an eye on folding the work into the 15.0 LXC appliance. I put some of the changes into the lxc-turnkey template so they would be incorporated into both v.1 LXC and v.2 LXD containers.
There are two options for version 15.0. One is to update the LXC appliance and create a new LXD appliance; the other is to update LXC and add LXD to the same appliance. There are several reasons why I favor the latter approach.
- An LXD appliance will still need to have LXC v.1 installed to allow converting appliance images from Proxmox format. Eliminating LXC would require upstream support for LXD v.2 images, something I don't expect to happen for the v.15.0 release.
- The LXD v.2 user interface is far superior to the LXC v.1 interface. Current LXC users will probably want to use the new interface, but they will need to tools to convert existing containers to the LXD v.2 format.
That begs the question, "If we combine LXC and LXD into one appliance, what should it be called?"
Information is free, knowledge is acquired, but wisdom is earned.
Here's my thoughts
Jeremy Davis - Tue, 2018/02/13 - 02:31
Here's my thoughts:
If LXD makes it into Sid and all is well with it (i.e. no showstopper bugs reported), then it will automatically migrate to Buster (current testing) after about a week. Once it makes it there, now we have Chris Lamb (current Debian Project Leader) involved with TurnKey, getting it backported to Stretch will be pretty straightforward and easy (assuming that there aren't be any tricky dependencies).
Having said that, if Brian's suggestion is correct (i.e. plans to deprecate deb package and only provide snap), then perhaps we'd be better installing it via snap right from the start?
As for an appliance, I think that the long term goal would be to provide an LXD appliance, with LXD images ready to run (i.e. a somewhat similar LXD experience, to the current LXC appliance experience). My guess is that once we get to that point, there would be limited value in an LXC (only) appliance as well? Although I'm not sure and am open to suggestions and thoughts on that.
Either way, I think that it would be wise to work towards the long term goal incrementally, starting with a smaller win first. So perhaps we leave the LXC appliance as is for v15.0, and produce an LXD appliance separately, at least initially? Then we could look to move the LXD image building into buildtasks for the next v15.x release of the LXD appliance (and perhaps drop the LXC appliance then?).
How does that sound?
Thanks Brian
Jeremy Davis - Tue, 2018/02/13 - 02:32
As I noted in my post above, if LXD is moving to drop deb packages and only provide snaps, then we're probably best to go that route right from the start...
So please do post that link when you find it. Cheers.
[update] I just found this blog post which speaks about removing some of the current deb package channels. I wonder if that's what you were referring to Braan? My reading of it is that it doesn't explicitly say that they'll be moving to snap only packaging. Having said that, it's also quite an old post, so perhaps that's not the one you are referring to and there has been an update since?
LXD and SNAP
bmullan - Wed, 2018/02/14 - 16:29
LXD and SNAP
bmullan - Wed, 2018/02/14 - 16:31
in "Why a Snap"
this sentence...
Moving forward, we will be phasing out our Ubuntu PPAs and then our backports to older Ubuntu releases. Both of those use cases will be transitioned over to the snap.
Ok thanks mate
Jeremy Davis - Thu, 2018/02/15 - 08:31
On one hand that might be cool that it will install "anywhere", but one of the main concerns I've heard around snaps, is that you no longer control your system anymore. Developers can push updates, whether you want them or not.
For a desktop, I can see how that might make sense, but for a production server, that's the last thing I'd want happening. Especially when the software is responsible for running a fleet of LXC/LXD containers!
A quick google did turn up a thread which covers a number of my concerns. It appears that late last year there was some concession made and you can now set update windows, rather than it just update anytime it feels like. That's a good start, but unless they are backported updates (which I'm almost certain they're not) personally, I want a lot more control than that. That's why I use Linux in the first place! :)
I much prefer Debian's model of providing a specific version and backporting security patches for the life of the OS. It does mean that you may miss out on new features, but everything continues to work as it did yesterday, every day! Now that their releases are picking up pace (pretty reliably every 2 years these days) software shouldn't get too out of date. Especially once we can get our updates happening a bit quicker (i.e .v15.0 should have been out 6 months ago)!
Having said that, I'm not totally against aiming for a v15.x LXD appliance that uses the snap. Personally I'd want to keep a vanilla LXC appliance in the library if that was the case.
LXD and SNAP
bmullan - Thu, 2018/02/15 - 10:14
The developers of a snap totally control if/when a snap is updated. Each snap is also self contained in regards to app dependencies which makes or may not be the same as what is installed on the Host OS.
TThe user can update or roll back a will also. The user can also have different versions of an app installed simultaneously (re stable & beta for instance) and run both without affecting each other's own installation.
At least those are some of the benefits as I understand them.
LXD and SNAP
bmullan - Thu, 2018/02/15 - 15:08
Sorry for the double post & the spelling but my previous reply was via my cell phone.
I wanted to add that whether LXD is installed via a SNAP or PPA does not affect at all the OS and the application(s) installed "inside" the container itself.. re the TurnKeyLinux Applications.
It only affects the SNAP itself .. in this case LXD.
I can copy a SNAP LXD container to a non-SNAP LXD server and that container will still run.
But perhaps I am not understanding your comment:
is that you no longer control your system anymore. Developers can push updates, whether you want them or not.
The TurnKeyLinux applications would NOT be SNAP packages themselves unless of course TurnKeyLinux creates them that way.
So from my perspective nothing changes if LXD is SNAP or non-SNAP except LXD itself would be available on more distro's.
I was referring to (the snap install of) LXD
Jeremy Davis - Fri, 2018/02/16 - 01:10
I deleted the double post and no worries on the spelling! :)
My response no doubt shows my level of paranoia and perhaps even a lack of understanding of snaps. But I'm pretty sure my following points are at least somewhat valid.
My concern is that if software is installed via a snap, then the developers can push software to my system (via the snap framework) whenever they like. I am no longer in control of my system if I install software via snap. As you point out, that only specifically affects the software installed via snap. But in the case of LXD, I would argue it's a pretty fundamental component of a container hosting system. By design, it requires significant access to all guest containers. The potential for something bad and out of my control happening, is way too high for my liking.
In my mind, that especially becomes an issue with regard to TurnKey. TurnKey users trust us and IMO with good reason. We're not perfect, not by a long shot. But we tend to err on the side of caution and think things through pretty carefully. We seek to balance security, user friendliness, reliability, stability and user experience in general. Ultimately we seek to empower users to take control their systems.
To my mind, snaps are philosophically headed in the wrong direction. Don't get me wrong, from a technical developer perspective, they seem pretty damn awesome. The idea of packaging software for consumption cross platform, in a single complete environment is pretty cool and on face value, incredibly attractive. And I can certainly see why many end users may find the thought of install and forget, pretty appealing.
I guess some of my concerns also apply to Debian security updates within a TurnKey appliance. But I know the level of security that Debian provides for it's security repo (only a limited number of well vetted Debian Security Team members have push access, binaries are built from source and new packages need to be signed off by multiple team members). I also know that any updates that are pushed via auto security updates are minimalist patches that change as little as possible. We are (almost) guaranteed that the API, commandline options, etc will not change between security updates, unless there is a really good reason. Other than specific edge cases (e.g. Samba 4.1 in Jessie being updated to Samba 4.2) the version rarely ever change without my explicit instructions.
I know that can be a double edged sword, as it also means I may be missing out on new features. But IMO on a server, the less that changes without my explicit request, the better!
As I understand it, that is not how it works with snaps. Software installed via snap can have updates pushed by the developer at any time. As I noted in my post above, that has been somewhat mitigated by new update options within snap. But it still doesn't allow the system administrator to block updates altogether, nor does LXD appear to provide an LTS/security-update only channel.
Without knowing more about the snap security measures, I really don't like the thought of a team I essentially know nothing about, having push access to my server. Especially a piece of likely vital infrastructure as a container hosting software (i.e. LXD). Not that I don't trust the LXD team to do the right thing, I do. It would be suicide for them to knowingly push something malicious or even really broken.
But I don't know what security mechanisms they may have in place to ensure that no malicious (or even poorly tested) software get's pushed to my system. I don't know how closely they guard their credentials and/or keys that allow them to push updates to me. I don't know what holes there may be in their deployment process which could be intercepted or interfered with by someone with malicious intent (e.g. MITM attack). I don't know how well they vet new developers that have push access to snap packaged software.
Whilst I'm sure that they test every software release, how can we be sure that the software contained within the snap will continue to play nice with the rest of my system? What if a newer version of an LXD snap relies on some new snapd functionality which isn't yet available in the version of snapd that I have installed? At worst LXD might break, at best it will not update - which I consider an issue when I'm under the impression that I can "set and forget" (it auto updates right?!).
What happens if a buggy version of LXD gets pushed to my system which breaks things? FWIW, that's one of the main reasons why we moved from Ubuntu to Debian base for TurnKey. Ubuntu pushed a number of buggy security updates which broke people's systems (and I've heard that they've unintentionally done that a few more times since). Even since we switched, Debian (with a much more robust testing regime IMO) have pushed a couple of buggy sec updates (although nothing to the same degree as the issues we had with Ubuntu - broken cron anyone?!). So I'm not talking about some theoretical possibility, I'm talking about something that happens, even when you have a whole Security team testing, reviewing and vetting each other's code.
Even if we put the risk of something bad creeping in aside, we still have the issue of major version bumps. What if an API call your system relies on gets removed in a new version of LXD? What if the behaviour of a specific command or commandline switch changes in a new version? What if some LXD functionality that one of my old containers relies on, changes or is removed completely?
They may seem unlikely scenarios right now, but they are not without precedent and IMO it's only a matter of time before something like that happens. IMO, the less control I have over my system, the more chance there is of something going wrong when I least expect it. At least if I break my own system, I know what lead to it and I'm right there at the terminal already.
And last but certainly not least, the reason why I love Linux so much is that I have the power over, and control of my system. Having updates forced on me which (potentially and sometimes really) break my system is one of the main reasons why I was so happy to have moved away from Windows! I don't want that infecting my Linux!
Bit of an idealist rant I know, but I'd like to think that my perspective is not complete tinfoil hat stuff.
Having said all that, to elaborate on the closing remark of my last post: I'm not fundamentally opposed to installing specific software via a snap in a TurnKey appliance. However, I would not want it to be the only option for TurnKey users to run full Linux containers (i.e. LXC/LXD). And I would also want to spell out my concerns, so users could make an informed decision.
LXD and Snap, More complicated than it appears
John Carver - Fri, 2018/02/16 - 04:07
I thought I would report here my experience in trying to use snapd to install LXD in a TurnKey LXC appliance.
- First, I created a new container from the v.14.2 tkldev image. Named it tkldev-15.
- Second, I configured it to use my github credentials and local apt-cacher-ng, I then applied Jeremy's tips for developing 15.0 on v.14.2 tkldev. See https://gist.github.com/JedMeister/ad6f3b405a889b62985dc933431f7dd1
- Using git, I cloned the lxc project from https://github.com/Dude4Linux/lxc/tree/updates-for-15.0-release
- Ran make, and the project built to completion with a product.iso. Checked root.patched and verified it was 15.0-beta.
- Using fab-chroot build/root.patched, I tried to install snapd and LXD. apt-get install snapd ran to completion and installed several dependent packages.
- snap install LXD, however, failed as snapd was not running.
investigation showed that
- snapd won't run in a chroot, because systemd is not available
- snapd won't run in a TurnKey appliance because systemd has been disabled and replaced by sysvinit.
- My conclusion is that snapd can't be used in v.15.0 unless the build system is rewritten to use systemd and tkldev rewritten to replace aufs with overlayfs and systemd-nspawn instead of chroot. Seems like an awful lot of work.
Information is free, knowledge is acquired, but wisdom is earned.
Thanks for the info John
Jeremy Davis - Fri, 2018/02/16 - 04:58
We may have to work around some issues within the root.patched chroot, due to systemd not always playing nice inside a chroot, but otherwise it shouldn't be an issue (so long as thre are SysVInit scripts). As you can see on the bug report, I did initially investigate using systemd-nspawn (sort of like LXC itself really - chroot on steroids) but we ended up just developing a wrapper script for the service command (which will get cleaned up by the build process).
The usage of SysVInit (instead of SystemD) in the v14.x containers was to workaround a bug in the version of SystemD in Debian Jessie. The issue has been fixed in newer versions of SystemD (and packaged in Stretch). So we intend to revert to SystemD in the LXC container builds for v15.x anyway.
So my guess is that it will probably work ok once we get there. Although personally, I'm still hoping for a backported LXD package to appear in the Debian repos. Even if LXD themselves no longer create packages other than snaps, there's nothing stopping distros from creating their own packages! :)
LXD compile from source
John Carver - Fri, 2018/02/16 - 17:08
FWIW I was able to compile and install LXD using fab-chroot and following the instructions at https://github.com/lxc/lxd. I had to add gcc to the list of prerequisites. I was able to start the LXD daemon and run 'lxc list' so there doesn't appear to be any major roadblocks. However there was no 'make install' target so all the SysVInit scripts and SystemD support would have to be created or copied from the Ubuntu debs. Compiling from source leaves behind a lot of cruft so I wouldn't recommend doing this as part of the build process.
I'm facing a similar situation with the OpenVAS appliance. The v6 version available in Stretch is old and out of date. The version I want to use is v9 is available in Buster, but no sign of a backport yet.
For now, I will focus on converting root.patched into an LXD image so I can test without needing a VM.
Information is free, knowledge is acquired, but wisdom is earned.
Sounds good.
Jeremy Davis - Sat, 2018/02/17 - 02:51
Good to know that a source install works. Although I agree, we should leave that as a last resort. Whilst on some levels I think a source install is preferable to a snap install, at least on my own personal systems. But I think for TurnKey users, it may be a bit too much to expect them to be able to do future updates from source. Ideally I'd most like to see a Debian package, but failing that a snap install is still an option in my mind (despite my rant the other day!)
Re OpenVAS, backports can be requested via the debian-backports mailing list. Worst case scenario, we could get it backported ourselves (i.e. fund Chris Lamb to do it).
LXD, Debian, SNAP and PPAs etc
bmullan - Fri, 2018/03/09 - 23:53
John et Al
These are a couple of the latest comments by Stephane Graber on the lxd user forum related to LXD, Debian and also SNAP vs PPAs.
Anyway, wanted to make sure you saw Stephane's comments:
Stephane's comments
John Carver - Sat, 2018/03/10 - 19:59
Thanks Brian
Stephane says,
I believe the current packaging effort is therefore centered around LXD 2.0.x (LTS branch), meaning that you'd be able to get LXD 2.0.10 (or whatever the latest stable release is) natively through Debian but would then need to use the snap for something more recent.
I am currently using version 2.21-0ubuntu in the Portable Development Environment. I had to pull this version from xenial-backports to get some needed features. I'm afraid using the Debian LTS version won't meet our needs for an LXD appliance. Bummer!!
Information is free, knowledge is acquired, but wisdom is earned.
Bootstraps for Debian stretch
John Carver - Sat, 2018/03/03 - 21:59
@Jeremy, did you see my comments on your gist about creating bootstraps for Debian stretch? It's been a few days and I didn't want you to miss them if it will help you prepare for the v15.0 release.
See https://gist.github.com/JedMeister/ad6f3b405a889b62985dc933431f7dd1
Information is free, knowledge is acquired, but wisdom is earned.
Hi John
Jeremy Davis - Sun, 2018/03/04 - 22:56
Thanks for the bump. I'm not sure why, but I don't seem to have got notifications about your posts on that gist?! Even though I would have expected to get notifications anyway, plus you explicitly mentioned me?!
Anyway, good work on your posts. FWIW there is actually a bootstrap in that same bucket, although I did forget to explicitly note that!:
http://dev-apt.jeremydavis.org/bootstraps/bootstrap-stretch-amd64.tar.gz http://dev-apt.jeremydavis.org/bootstraps/bootstrap-stretch-amd64.tar.gz.hash
And I have no issue with people using that bucket, just so long as it's not being abused (because I pay for excessive traffic). Hopefully it won't be long and we'll have those packages merged into the default TurnKey repo. And we'll have a proper automated dev-testing repo soon too! (fingers crossed...). Then instead of dev-test.jeremydavis.org it'll be a normal archive.turnkeylinux.org repo (probably just called 'stretch-testing').
I'll probably make up a refreshed bootstrap build sometime soon. That will be up on the official mirror before we officially release any v15.0 appliances; with the possible exception of the Core RC.
FWIW, if you wanted to play around with TKLDev v15.0 you can. It's a bit convoluted and will require building your own packages of fab etc, but it's possible.
importing TurnKey images into LXD now possible with LXD/LXC 3.0
bmullan - Sat, 2018/04/07 - 19:52
LXD and LXC 3.0.0 were released last week and feature several major new features including but not limited to these two:
lxd clustering - turns multi-host's for LXD containers to operate as one giant LXD host server
lxd clustering FOSDEM 2018 video: https://www.youtube.com/watch?v=DVqMeo3lvv0&t=293s
lxd-p2c a tool to copy a physical system (real or VM) into an LXD container. I would assume this may enable someone to use Turnkey to create a physical install or VM and then use lxd-p2c tool to convert/copy that physical install or VM into either a "local" or "remote" Host machine running LXD 3.0.
Once they verify that the new LXD container is running they could then decommission the phyiscal machine or VM
lxd-p2c FOSDEM 2018 video: https://youtu.be/JKztAWZOj9g
imho - the orchestration & management of local/remote nodes/lxd containers in the new lxd clustering seems much easier than kubernetes and may scale equally well but watch the video to see what you think.
The reason I included the mention of both the new LXD 3.0 release features of lxd-p2c and the lxd clustering was that a work-flow may be:
- create a turnkey vm or machine
- convert/copy the vm or machine to an LXD server somewhere using lxd-p2c app
- add the LXD server to an LXD cluster of remote/local Host machines (could be cloud based?)
- manage & scale the new turnkey lxd container using the normal LXD cli commands as you would if they were just a single local machine
Anyway I thought I'd let you know this all may be much easier now.
John Carver - Sun, 2018/04/08 - 00:01
Thanks Brian, As usual you are ahead of me when it comes to LXC/LXD news. And to think I just spent the last several months developing lxd-make-image which does something similar to lxd-p2c. If the latter will convert a product.iso then it's exactly what we're looking for. I don't consider my time wasted, however, because I learned a lot in the process.
My work has stalled for a bit because I got hit with a bug in the last Ubuntu kernel update. My laptop gives four errors NMI ... hardlock cpu0, cpu1, cpu2, cpu3, then stops dead. Pretty sure it was the kernel update which may have been corrupted. Until I get this figured out I'm SOL.
Information is free, knowledge is acquired, but wisdom is earned.
A tool to create an LXD .DEB file for use on Debian 9 and Debian
bmullan - Wed, 2018/05/09 - 15:45
I don't know if this will help you folks with LXD on Debian (I use ubuntu) but I found this tool on GitHub which creates an .DEB file to install the latest LXD on either Debian 9 or Debian 10.
Thanks Brian
Jeremy Davis - Thu, 2018/05/10 - 02:40
That looks great. I'm not sure when I'll have a play, but that's certainly a handy tool for when I do!
Google announced ChromeOS will run regular Linux Apps
bmullan - Thu, 2018/05/10 - 04:17
Just some FYI...
Google announced today at Google I/O 2018 that ChromeOS will now run regular Linux applications using Crostini and containers.
Crostini's containers are LXD.
I got confirmation from Stephane Graber (LXD/LXC project lead) and from several others on the Crostini subreddit.
This opens up both LXD and linux apps to potentially hundreds of thousands of ChromeBooks & Tablets.
Hopefully, Turnkey can eventually work with LXD so your apps can also work in this new huge new market as well.
here are some links on Reddit & the announcement by Stephane Graber
Wow that's cool!
Jeremy Davis - Fri, 2018/05/11 - 06:10
Yes, that certainly adds to the impetus to ensure that TurnKey runs smoothly as an LXD container! Thanks for the heads up on that!
LXD teasm has rewritten & improved the LXC-to-LXD migration tool
bmullan - Fri, 2018/08/24 - 19:00
Just any fyi
With LXD v3.3 release they notes indicate the LXC-to-LXD conversion tool has been updated. Just fyi in case this helps.
New features
Rewrote and improved
Our LXC to LXD migration tool has been rewritten in Go to match the rest of our codebase.
It now uses the LXD migration API to transfer the containers (similar to
lxd-p2c) and has support for both LXC 2.x and 3.x.
success using lxd-p2c to convert a turnkeylinux app to lxd
bmullan - Wed, 2019/04/10 - 19:00
I had the time today to convert one of the TurnkeyLinux apps to an LXD container using the lxd-p2c tool.
On my home PC I use the SNAP version of LXD. the SNAP LXD is now available for most Distro's to enable them to run/use LXD.
When doing the one-time "sudo lxd init" I answered the question "Did I want LXD available over the internet" with Yes
Then there are a couple more related questions ending with what Password should be used to authenticate remote access to the local LXD Daemon.
Once that was done
I downloaded the Sahana .ISO to my PC
Created a KVM VM with the Sahana .ISO (a virtualbox or vmware workstation VM would work equally as well).
Then on my local PC I used GO to compile the latest lxd-p2c from the GO source using the instructions on this linuxcontainers forum post:
I then used SCP to copy the lxd-p2c executable to the Sahana VM.
Finally, logged into the Sahana VM I executed the following command (note the above URL of the web post had the command options wrong)
# ./lxd-p2c https://<IP_of_PC_w_LXD>:8443 / sahana
the above command uses lxd-p2c to copy the rootfs of the VM to the IP_of_PC_w_LXD and and creates a new LXD container named "sahana".
- took about 3 minutes to copy the Root Filesystem of the VM to my home PC's LXD Daemon,
- create a new LXD container called sahana
- start the sahana container
Back on my PC (ie not in the VM) I could check that the container was running:
$ lxc list sahana
| sahana | RUNNING | 10.105.172.253 (eth0) | | PERSISTENT | 0 |
Pointing my PC's web browser to:
and the Sahana web page pops up... so it works !
now I can use LXD to manage the turnkey app sahana
bmullan - Wed, 2019/04/10 - 19:06
I'm able to now:
snapshot the sahana LXD container
export the sahana LXD container to other LXD systems
clone/copy the sahana container to make more
create an LXD cluster of sahana using the LXD cluster feature/command.
Great work Brian! :)
Jeremy Davis - Thu, 2019/04/11 - 02:00
That sounds pretty cool. Thanks for sharing your experience! I'm sure others would find that of interest.
Although I note that it's really only going to be relevant for individuals wishing to migrate an existing server to LXD, or for personal usage. I say that because each server would essentially be a "clone" of the original (rather than an individual server). So it would have the exact same "secrets", such as any usernames, passwords and emails, as well as using the same salt for password hashing etc. So long as the user is aware of those limitations it would be ok, but not really suitable for distribution.
If you wished to ensure that each LXD server is unique, then prior to generating the "clone" I would recommend resetting the inithooks and following many/most of the tweaks that we do for the current LXC builds (some may likely be redundant though). That will ensure that each LXD guest you create is a truly unique server. Then each individual server could be preseeded, or initialised via first login (as our current LXC build does).
I started outlining the process that you might need to take, but I got quite bogged down on details... So I backed out of that. If you are interested in trying to do that for your ISO -> LXD servers, then I suggest that you have a look at our bt-container script (all of buildtasks is written in bash so hopefully ti should be relatively straight forward to follw). That's what we use to transform the ISO into the current LXC build. As I noted above, some of that may be redundant. At least a few things we do are likely covered by their conversion process. Although there are certainly some things that we do that wouldn't be covered, for example, they would be unaware of our inithooks/firstboot processes.
If you want to dig into that a little deeper, please feel free to ask if you have any questions.
That might work, but I'm not sure...
Jeremy Davis - Mon, 2019/04/15 - 02:44
That might sort of work, although I strongly suspect that the end result would be sub-optimal. It would still require some additional effort on behalf of the end user to get everything up and running. Plus there would be security implications until the user completes the inithooks. That's possibly not a huge deal for a user who understands what is going on, what is required and understanding of the implications of leaving it unconfigured; but really not ideal for general distribution.
By default all "headless" appliances (i.e. ones that do not have a proper terminal - e.g. LXC guests) generate random passwords on firstboot and are then "fenced" until the user (re)sets all the passwords (the fence blocks all access except via SSH until the inithooks are completed). The ISO builds do not include all the components required to provide the fence. The random generation and fence is quite important because otherwise, the server will contain some secrets, etc left over from build time. For example, for about ~70% of the library, anybody with access to Adminer, could use the "default" password to modify the DB! Under normal circumstance, because of the way we implement things, there is no way to leverage any "default" passwords, but would not be the case in an LXD server built from an ISO.
Whilst under LXC/LXD the user can set the root password at launch time, none of the other passwords would be set. Without the tweaks we provide, the user would need to manually launch the firstboot scripts. I also suspect that the default inithooks would still be running, but in the background, with the user having no way to connect to them. So the user would likely need to manually kill them first. Otherwise the inithooks would continue to run on everyboot (still in the background) and I'm not really sure what further implications that might have. I'm not sure, but I suspect that it may cause the passwords set by the user to not survive a reboot.
Like I said though, the tweaks we provide are all scripted via buildtasks. So you could create a script to run within the ISO guest prior to conversion to LXD. Then you could re-implement everything that we do, so it all works as intended. It might take a little effort to get it all working nicely, but I think that the end result would be worth it. Then you would have an LXD appliance which should "just work" the same as our existing "headless" appliances.
It's due to the limitations of LXC/LXD
Jeremy Davis - Thu, 2019/04/18 - 04:17
On a system with a "proper" terminal (e.g. a VM and/or an ISO install), the inithooks (i.e. firstboot scripts - where passwords etc are set) block the starting of the other services. In an LXC/LXD container, you don't have a "proper" terminal (because it's completely "headless"). So whilst the inithooks will still start, they can't attach to the terminal, so will run in the background. That will not be apparent to a user, unless they go looking for it.
We work around the limitations of containers with some funky tricks contained within buildtasks. I've already mentioned the "fence", but another of the important components of that we're using dtach to link the running session of inithooks to the login session (dtach is sort of like a super slim alternative to screen). Incidentally our default LXC containers use an alternate SystemD service, especially written for Linux containers, not the default service which runs on ISOs. ). So that way, the user is greeted with the inithooks on firstboot - same as when running on other platforms such as VM.
There's no reason why you couldn't reapply those same tweaks that we use, but you'll need to read through the bt-container script to see what needs to be done. As our scripts are (also) converting the ISO to a(n LXC) container build, some of the work we do can almost certainly be skipped. The conversion script you are using will do much of the same stuff that we do.
IMO, if TurnKey were to provide LXD builds, the best path would be to leverage the existing LXC buildtask and add in any additional steps which may be required. Sort of like the way that we extended our original VMDK build to also produce the OVA build. From my understanding, John has already done a lot (perhaps all?) of this work, although IIRC his scripts leverage the build process prior to the ISO being produced (i.e from the rootfs). To ensure consistency between all the builds, all of our alternate builds are generated, starting with the ISO (which is unpacked and adjusted as need be).
If you're interested in pursuing that further (i.e. beyond your own personal needs) then I suspect that it would be possible to leverage John's work, in combination with the existing buildtasks scripts. It's a little sucky that they have written their tools in Go (don't get me wrong, IMO Go is a good choice, just I don't know it...). So looking at the script probably won't be much help to me. Although, it might be interesting to compare the contents of the generated LXD container against our default LXC build and/or John's LXD build to see what's different. I don't have the time or energy right now, but if someone would like to upload an LXD build of a TurnKey appliance somewhere, I could probably have a look at some point.
LXD and Proxmox LXC 2022
Marcos - Fri, 2022/05/27 - 03:59
Guys im sure many things have evolved in the last 6 to 8 years in this matter. We are now on Core 16 and TKL keeps solid and working well.
How do you manage to deploy cloud proxmox lxc on production and develop them in local LXD in your laptops maybe @jed and John could give me some tips
Haven't seen John for a while and I've never used LXD.
Jeremy Davis - Tue, 2022/06/14 - 05:30
John hasn't been about for a while, so I'm not sure if we'll hear from him. And unfortunately I am completely unfamiliar LXD (never used it). When I'm away from my Proxmox server, I either spin up an instance (on AWS) via the Hub or run a local instance in VirtualBox.
Sorry I don't have anything better for you. Having said that, It looks like LXD is close to making it into Debian. Once it makes it's way into 'testing', then we can request a backport. Once we have a native install to work with, then I'd like to revive our LXC appliance - except as an LXD appliance. I'm not sure how practical that will be, nor what sort of timeframe it might take to get there.
LXD Portable Development Environment
John Carver - Wed, 2022/06/15 - 00:06
Hi Guys, John is still lurking around but my interests have moved on to other projects such as Raspberry Pi development. One of the last TurnKey related projects I was working on was running LXD on my Ubuntu laptop in what I dubbed, the TurnKey Portable Development Environment (PDE). Although it was developed on Ubuntu 16.04, I was able to run it on 18.04 and 20.04 before my laptop died. You can find my latest efforts at https://github.com/Dude4Linux/turnkey-pde. I can't remember if the conversion scripts were working for TurnKey 15.x but I think that's where I stopped. The examples show version 14.2.
Marcos, I hope you'll be able to find something helpful there to get you started.
Information is free, knowledge is acquired, but wisdom is earned.
John such an onnor to have an
Marcos - Wed, 2022/06/15 - 03:59
John such an onnor to have an answer from you and im glad that the old and bowy John Carter is still sailing.
So basically what i have done is almost the same as you propose in your git repo, BUT today LXD is a Snap package that can be installed trought snap install or without big headaches in Debian.
Im still having problems converting the image back to the PMX envirment, everytime i export a LXC container (that has been developed locally) and generate a tar.gz ou zsdt image and try to run it in the Proxmox it run but looks like all the changes i made don't take effect. Altought the images are snapshoted before the export. Is a very very weird behaviour that i currently can't find any logic at all.
About Raspberrys i my self have been trying to help the OpenCPN and OpenMarine communities (Embeded hardware for ships and sailing vessels) and have a little bit of expirience in that.
In the health and clinical eng envirment normally we use smaller embeeded devices that are centralized trought a midleware raspeberry. Hasura and Proxmox work extremlly well and stable.
Is almost a shame to me to say that but the budgeting in brazil is pretty bad for healthcare so what we have to do is do what we can, rasp and atmels have been a curse and also a bless for us in this latitudes.
A big hugh for you all guys thanks for the encoragment and sharing all this. So glad and happy of beeing part of a community like TKL
Thanks John, what a legend you are! :)
Jeremy Davis - Wed, 2022/06/15 - 09:43
Awesome thanks John!
Glad to hear that you're still floating about! :)
If you're into playing with RPi now, have you seen the (preliminary/not-yet-official) TurnKey Raspberry Pi builds? They still have some rought edges and I'm super keen to get back to it and get them "offical", but it may be of some interest?!
Take care and look after yourself. Thanks again for dropping and sharing your wisdom and experience.


text:
David Sibbet finds it tough to understand a story unless you can see it in some way.
"Really good storytellers paint pictures in your mind," he told attendants of the 2011 Systems Thinking in Action Conference this morning during his keynote address titled Visual Teams: Graphic Tools for Creating and Sustaining High Performance.
A pioneer in the field of graphic facilitation, Sibbet talked about the importance of visual literacy in systems thinking and how tools such as graphic recordings—those oversized, mural-esque type of drawings that capture the essence of a meeting with caricatures, systems models, thought bubbles, Post-It Notes, scribbled handwriting, and all sorts of arrows—are crucial in the storytelling process.
Sibbet introduced the audience to the latest practices and technologies that teams are using to open up the "group mind" and help teams to be able to think collectively about systems, interconnections, the broader context, and consequences. For teams that work from a systems perspective, visualizing is as common as talking, Sibbet said.
After briefly mentioning consulting firms that heavily rely on visualization, like IDEO, Sibbet gave everyone a crash course in drawing—from learning how to draw a real circle (it's not about the wrist movement, people, it's all in the shoulder) to drawing lines to drawing stick figures known as seed shapes that represent people. He showed the crowd how any concept or seed shape can look "enlightened" by drawing a few lines around it that look like a burst of energy.
Sibbet stressed that visual literacy is all about visualizing. It's the best way the understand all the variables at work.
"To see relationships," Sibbet told the audience, "you need to see displays."
Read other posts by Aimee C. Juarez
NOTE: This post was submitted from the 2011 Systems Thinking in Action conference hosted by Pegasus Communications in Seattle, Washington. Photo of Michael Erickson sketching a graphic recording courtesy of Aimee C. Juarez.
Keep up with our community: Facebook | Twitter | Saybrook's Organizational Systems Program

subset: commoncrawl


text:
Chape&Mache is the creative partnership of Aurélie Chapelle (born 1986) and David Machado (born 1984). Having graduated with honours from the école supérieure des beaux arts d'Angers in 2011, their collaboration really began in 2013, under the name Chape&Mache.
Their work is symbolic and full of imagery drawn from observations of daily life, perpetual interaction and the blending of their two worlds.
They approach numerous fields through singular pieces which question collective or individual practices.
Each new Chape&Mache project is a piece of creative alchemy.


text:
Shaw vs St Aug 1-21-12
Here are highlights from the Shaw-St.Augustine's College games at Shaw in Raleigh, shot for The Carolinian, on Jan. 21, 2012. Please browse through the images to relive and/or experience the action. For the best viewing, please click on SLIDESHOW and select the medium or fast speeds.Read More
Images are not for sale.
Images are not for sale.


text:
Come Valentine's Day, it would seem that one edible aphrodisiac is on the mind and one only; Chocolate. While I may have my own chocolate-covered plans as well, it's a crying shame that vegetables are barely even considered when it comes time for a seductive or romantic dinner.
Light, fresh, and invigorating foods should be what's on the menu, and what could fit the bill better than those much-maligned vegetables? Thank goodness for Vegetable Love 2009, which asks everyone to think of sexy veggie recipes for the holiday.
For an occasion such as this, I tend to think that simplicity should reign, lest that complicated unchicken cordon bleu ends up burning in the oven while you're busy fussing over the already over-reduced pan sauce you're making on the stove. Nope, I'll stick with something fool-proof and guaranteed to satisfy, thank you very much!
Roasted red pepper soup is certainly nothing extraordinary in and of itself, but with a simple garnish of "sour cream" hearts, this unassuming starter is sure to kick of your meal on the right foot. Flavorful without being heavy or cloying like many pureed soups can be, this one definitely won't weigh you down.
Roasted Red Pepper Soup
Flavorful without being heavy or cloying like many pureed soups can be, this one light starter won't weigh you down.
- 2 Large Red Bell Peppers
- 2 Cloves Garlic
- 1/4 Medium Onion
- 1 1/2 Cups Vegetable Broth
- 1 Bay Leaf
- 1 Teaspoon Balsamic Vinegar
- Salt and Pepper
- Preheat your oven to 450 degrees, and place your peppers on a baking pan lined with a sheet of aluminum. Roast for 25 – 30 minutes.
- Meanwhile, smash your cloves of garlic and roughly chop the onion. Move them into a medium saucepan, and add in the broth and bay leaf. Set over medium heat and simmer for about 20 minutes, until the onions are translucent.
- Once the outsides of the peppers are nicely charred, pull them out of the oven and crimp another sheet of aluminum on top to form a nice little package. Let it rest for 10 minutes to steam. Peel the skin off and remove the seeds and membrane. Transfer the cleaned peppers into your blender or food processor. Remove the bay leaf from the broth, and pour the contents of the saucepan, along with the vinegar. Thoroughly puree until completely smooth, and add salt and pepper to taste.
To make the hearts or just a creamy topping to swirl in, mix together 2 tablespoons of vegan sour cream and 1 teaspoon of plain non-dairy milk until smooth. Transfer the mixture into a small piping bag or squeeze bottle. Squeeze two small dots right next to each other onto the surface of the soup, and then drag a toothpick right down the center, between them. Wipe off the toothpick between hearts to keep it clean and separate.
Nutrition Information:
Serving Size:1
Amount Per Serving: Calories: 54Total Fat: 0gSaturated Fat: 0gTrans Fat: 0gUnsaturated Fat: 0gCholesterol: 0mgSodium: 651mgCarbohydrates: 12gFiber: 2gSugar: 7gProtein: 2g


text:
I was just saying to myself the other day that magnifying glasses are a very underrated item in the world today. How else are we supposed to read fine print?!?! I guess a pair of glasses or some contacts would work, but what if it's really super small and what if I want something that is also affiliated with a cult horror movie? Oh if only there was a magnifying glass available on eBay from a 1985 horror/sci-fi movie directed by Tobe Hooper………….
Oh my lucky horror stars! Is that? Could it be? It is! Putting the magnifying glass game to shame is an actual promotional magnifying glass from the 1985 movie Lifeforce. It looks as though it was given to video stores in promotion for the VHS release. Aside from the boobs that were in the movie, there were actually some cool vampires too and Lifeforce is a bit of a guilty pleasure of mine. But mostly for the boobs. If you're feeling especially nostalgic and want to own this rare magnifying glass so you can read your funnies on Sunday morning, then head over to the eBay listing HERE. Yikes – $55? Really, random eBay seller? Well, maybe the price will lower. Until it does, enjoy some of the free complimentary Lifeforce boobs below.
(photo courtesy of scififilmfestival.com)


text:
Item #: 201589
PROMASTER uses advanced technology and superior internal and external components to create a safer, higher quality digital camera battery. All PROMASTER Digital Camera Batteries are extensively tested to ensure battery longevity and performance.
PROMASTER Digital Camera Batteries feature:
• Guaranteed camera fit that matches the original manufacturer's design
• Capacity greater than or equal to the original manufacturer's battery capacity
• Superior internal welding and manufacturing
• Advanced circuitry for maximum battery life
• Additional internal protection circuits
• Stronger adhesives and insulation, designed to help prevent battery failure
|• 3.7V 925mAH Lithium Ion
Replaces Olympus LI-50b


text:
Viewfield Baptist Church lies in the heart of the old city of Dunfermline, once Scotland's capital and the home of kings and queens.
We strongly recommend that you include this option, as your tickets are non-refundable and this will protect you against cancellation resulting from accidents and unexpected illnesses up to a maximum amount of £100 per ticket.
Booking refund protection is an optional service offered by the booking vendor and administered by Ticketplan on their behalf. It is not an insurance policy.
Full details are included in the TicketPlan terms and conditions, which we advise you to read and retain. By adding TicketPlan to your order you are confirming that you have read and accept the Terms & Conditions.
Those marked blue are available on Scotland on Tour


text:
Mexico pushing labour reform, won't ratify USMCA with US tariffs
By Mike BlanchfieldIndustry Government Manufacturing Aluminum Exports labour reform manufacturing Mexico NAFTA Obrador Steel tariffs trade USMCA
Wants a package of labour reform ratified in Mexico's Congress before its April 30 adjournment.
OTTAWA — Mexico's Congress will be asked to approve a major labour-reform bill this spring as a necessary step to ratifying the new North American free-trade pact later this autumn, say Mexican officials.
But unless the Trump administration lifts the punishing tariffs it has imposed on Mexican steel and aluminum imports – duties it also imposed on Canada – Mexico is prepared to keep the status quo with the 25-year-old North American Free Trade Agreement.
The push to improve workers' rights in Mexico was a key priority for Canada and the US during the rocky NAFTA renegotiation because they wanted to level the playing field between their workers and lower-paid Mexican workers, especially in the auto sector.
When Mexico and the US reached their surprise bilateral agreement last August, forcing the Trudeau government to quickly forge a deal with the Trump administration, Foreign Affairs Minister Chrystia Freeland lauded Mexico for making labour concessions.
But a senior trade official in the new government of socialist reformer Andres Manuel Lopez Obrador suggested in an interview it wasn't a huge sacrifice because elevating the status of country's workers was a key plank in the platform that brought their Morena party to power.
Lopez Obrador made it clear in his election campaign that he wanted to strengthen the rights of workers and labour unions, which made a good fit with Canada's bargaining position, Luz Maria de la Mora, Mexico's deputy trade minister, said in an interview.
"With the agreement or without the agreement, this is something central to President Lopez Obrador – strengthening workers' rights and strengthening trade deals in Mexico," said de la Mora.
She said the new government wants a package of labour reform ratified in Mexico's Congress before its April 30 adjournment "so we can reflect the commitments that we've made under the new U.S.-Mexico-Canada agreement in domestic legislation."
That means the new agreement will be sent to the Mexican Congress for ratification after it reconvenes in Sept. 1, she said.
But that won't happen unless the United States lifts its so-called section 232 tariffs on steel and aluminum exports, said de la Mora.
US President Donald Trump imposed tariffs of 25 per cent on steel and 10 per cent on aluminum from Mexico and Canada, using the controversial national-security clause in US trade law – "Section 232," as it's called in shorthand – that both countries say was illegal.
Canadian Transport Minister Marc Garneau recently told Trump's top economic adviser, Larry Kudlow, during a public panel in Washington that the tariffs are "a serious impediment to us moving forward on what is the best trade deal in the world."
On Nov. 30, Prime Minister Justin Trudeau, Trump and former Mexican president Enrique Pena Nieto, who was on his last day in office, signed the new trade agreement. It now faces ratification by the legislatures of all three countries.
Trudeau spoke to Trump on Feb. 28 and "raised the issue of steel and aluminum tariffs and expressed the need for the removal of tariffs," the Prime Minister's Office said.
Canada has been clear from the outset that the tariffs "are illegal and unjustified," said Adam Austen, a spokesman for Freeland.
"Now that we have concluded our NAFTA negotiation with the United States, we believe it is all the more reason for the US administration to lift its tariffs," Austen said, although he did not say specifically whether the issue would lead to a delay in ratification.
If the tariffs aren't lifted, de la Mora suggested Mexico is fine with the current version of NAFTA that remains in force.
"We hope to have this new agreement in place. But in the absence of the new agreement, we know that NAFTA is good enough," she said.
Mexico would prefer the updated agreement "for the relations we have with the U.S. and Canada but we are OK with the current NAFTA."
Mexican senators, who were in Ottawa the past week to conference with their Canadian parliamentary counterparts, echoed de la Mora's assessment.
"We are going to approve it, but right now our government is trying to deal with this (the tariffs)," Sen. Antares Guadalupe said in an interview.
"We're not in a rush. Trade right now, it's working," she added. "We have many things to do but we want to take it slowly because it is very important to have it in a very good way for Mexico."
Sen. Hector Vasconcelos, the head of the Mexican Senate's foreign-affairs committee, said the ratification of the new agreement is also subject to the domestic political situations in all three countries. That includes the ongoing turmoil in the Trump administration and Canada's legislative clock, which will see the House of Commons adjourn in June until after the October federal election.
Asked what happens if the new agreement is not ratified, Vasconcelos laughed.
"Life goes on, I assure you," he said, referring to the current NAFTA. "It's good enough and we will try to get it better. That's what we are going to do. We have to discuss a lot in Mexico."
Print this page


text:
ACCLAIM RECORDS - ONLY TRUE UNDERGROUND BLACK METAL MUSIC LABEL, DISTRO & PROMOTION + Death / Doom / Heavy / Ambient
2009 demo of RAGGRADARH. Dark and aggressive Heathen Black Metal.
Covers are included in the folder, the track is in 320kbps mp3.
NOTE: You can download this file 2 times in total! After that the download will no longer be possible.


text:
Antivirus (AV) firms are warning of a "highly dangerous" virus that disguises itself as a newsletter from a popular German AV site. There have been reports of mass infections in Germany caused by the malicious code.
The 'Yarner' virus disguises itself as the AV program YAW, arriving as an attachment to an official looking message purporting to be from AV website Trojaner- info.de. The email contains the subject line: 'Trojaner- Info Newsletter [infected computer's current date]'.
If the attached Yawsetup.exe file is opened, the worm creates a file in the Windows directory with a random name up to 100 characters long and registers the file in the registry as an auto run key. This means that the worm is run every time Windows boots up.
Yarner spreads as a mass mailing virus, accessing the Microsoft Outlook address book to retrieve addresses as well as scanning all .php, .htm, .shtm, .cgi and .pl files for addresses.
After harvesting the details the worm connects to a remote SMTP server in order to forward itself to more unsuspecting victims.
AV firms have warned that Yarner also contains a highly destructive payload. It has a one in 10 chance of destroying all data and information on an infected machine after forwarding itself.
Experts have warned that this latest epidemic is more evidence of malicious code writers using social engineering to trick unwary users.
Eugene Kaspersky, head of AV research at Kaspersky Labs, said: "Trojaner-Info, supposedly in whose name the infected messages are sent, is a popular German resource for solving AV security problems. This service has no relationship whatsoever to this current epidemic.
"What is occurring now simply confirms once again that an email address and a message text can be easily falsified and, with the use of this trick, a user has a malicious program thrust upon him or herself."


text:
Brushed on while grilling and/or served on the side, barbecue sauce is America's favorite cooking sauce. Photo by E.Z. Foryu | IST.
Rubs, Marinades
& Glazes
Category Main Page
Articles & Reviews
Main Nibbles
Main Page
Articles & Reviews Of Foods From A To Z
Product Reviews
Main Page
Beverage, Books
News & More
ERIC DANTIS is a professional chef in New York City.
June 2010
It's that time of year where we Northerners polish the grill, buy loads of charcoal and stock up on meat for those outdoor barbecues. And what barbecue is complete without that sweet, tangy, smoky condiment we call barbecue sauce?
Whether it's Carolina-, Kansas City- or Texas-style or a simple mop sauce or marinade, almost every grill master has some form of barbecue sauce at hand. We've tried dozens of new sauces over the past year, and here showcase the ones we think are the best.
A quick comparison of the major barbecue sauce types from the experts at Ribber City Sauce Company. All are based on tomato paste (or in cheaper recipes, ketchup):
Let us start off by saying that we receive a lot of barbecue sauce. No, wait—let us rephrase that: We receive more barbecue sauce than any other savory product. Yes, really. And, unfortunately, most of them are not distinct. But a few we tried this year were true standouts.
For this story, as in years past, we tested several sauces at a time on several occasions. We tried them side-by-side both on a spoon and on our favorite chicken, Murray's Chicken. This truly allowed us to distinguish the difference between a good sauce (and in some cases, a not-so-good sauce) and a great sauce worth being on this list.
Our criteria was simple: So many sauces are so simplistically sweet, we call them "meat sugar"—and avoid them. We looked for a balance of sweet, tangy and heat and other notable flavors such as herbs, spices and smoke. We also selected all-natural products and eschewed high fructose corn syrup.
This is Part IV of our Best Barbecue Sauce series. See Part I, Part II and Part III for other favorites, including kosher and sugar-free barbecue sauces. This is Page 1 of a four-page article. Click on the black links below to visit other pages. Products are presented in alphabetical order. All prices and product availability are verified at publication but are subject to change.
BBQ Stu's barbecue team has competed in BBQ competitions throughout the country with their Original, Pennsylvania Gold, Steel City Blast Furnace and Steel City Blast Furnace X-XTRA Hot flavors of barbecue sauce. Of these, Pennsylvania Gold was our pick as the best in the line. Plus, it's gluten- and fat-free.
We appreciated this sauce because we thought it brought something different to the table besides a sweet, smoky, mustard-based sauce. It has by far the most aggressive mustard flavor of this year's selections, so if you appreciate a good spicy mustard, chances are that you'll like this sauce.
The mustard flavor is strong and brings a good amount of heat, which dissipates quickly. You're left with the sweet finish of classic barbecue sauce flavors balanced nicely with spicy mustard.
INGREDIENTS: Select mustard seed, sugar, water, vinegar, fresh peppers, modified food starch, fruit juice for color, turmeric, natural flavors and spices. CALORIES: 2 tablespoons, 45 calories.
BBQ stu's barbeque sauce
Pennsylvania Gold
Buy online at BBQStus.com.
Continue To Page 2: Grumpy's Goodnight Loving & Jube's San Francisco 1906 BBQ
Go To The Article Index Above
If you love spicy mustard, try Pennsylvania Gold Barbeque Sauce. Photo courtesy BBQ Stu's.
© Copyright 2005-2023 Lifestyle Direct, Inc. All rights reserved. All images are copyrighted to their respective owners.


text:
December 14, 2013
Stubhub Center
https://www.mudrunguide.com/event/los-angeles-california-ruckus-obstacle-race-2013/ Stubhub Center, 18400 S. Avalon Blvd. , Carson, CA, United States Ruckus Obstacle Race Series firstname.lastname@example.com use-title true MM/DD/YYYY
Race Start Time:
9:00 AM first wave start with waves going off every 20 min. The last wave for the 2 mile race goes off at 3:00 PM.
Venue:Stubhub Center
18400 S. Avalon Blvd.
Carson, CA, United States - View Map
Distance & Course Length:
2 mile, 4 mile and Kids Mini Ruckus, as well as Team Options
Organizer:Ruckus Obstacle Race Series Ruckus events have something for anyone aged 2-72.
Our courses are designed for a wide range of participants and almost 100% of runners finish. Ruckus events are demanding enough for the elite, but achievable for all. It is all about having a unique, rewarding experience, that is as much fun as it is a challenge.
This event was created for those looking for an "Adult Playground" experience that they can't get anywhere else. There is no time limit and participants are encouraged to run the course at their own pace.
At the end of the day, the course is what the participant chooses to make it, and will provide an unforgettable experience.
Click "About" above to hide this text again
6 Past Events, 0 other upcoming races
Click here to read or add your own Los Angeles California Ruckus Obstacle Race 2013 reviews
Use discount code MRG2013 for $10 off your registration
Registration:Visit Event Website
This event has passed, registration is closed.
Who's Attending?
Cost & Pricing:
|Kid's Mini
|October 16th, 2013
|November 20th, 2013
|December 11th, 2013 (Online Registration Closes)
|Race Day Registration
What You Get / What's Included:
- T-Shirt
- Medal or sweet schwag
- Scrapes & bruises
- Free beer
- Chip timing
Course Description:
Ruckus events feature industry leading obstacle innovation.
The Heater & Challenge courses feature over 20+ large-scale obstacles. Some are more difficult than others.
It is expected that participants complete each obstacle; all we ask is that you try.
No one will be disqualified if they are unable to complete a certain obstacle.
Purposely avoiding obstacles in order to get a better finish time is not allowed.
All obstacles must be completed during the Champions Heat.
Aid Stations:
There are 3 aid stations for the 4 miler, 1 for the 2 miler and the Kids Mini Ruckus.
Ruckus events have something for anyone aged 2-72. For those looking to compete, runners are separated into 4 Divisions.
Men's Open
Men's Master (45+)
Women's Open
Women's Master (45+)
All ages are as of race day. The first person to cross the finish line wins their division, and will receive a Golden Helmet
The last heat of the day is the Champions Heat. This is where Champions are crowned with the Golden Helmet.
You must qualify to run in this wave. The top 10% of each division (Men's, Men's Master, Women's, Women's Master) will be eligible to compete in the Champions Heat.
Your time will be measured against everyone in your division not your individual wave. Participants who qualify for this wave will run the same course a second time.
No prizes except for the Champions Heat Golden Helmet.
Ruckus courses are always built with spectators in mind. As a result, nearly the entire course, including the biggest obstacles, is visible to spectators. The high-energy spectator areas also feature a Health & Fitness Expo, Beer Garden, and Food Trucks. Reserve your spectator pass online for $10 and join the party! Children under the age of 10, and registered participants do not need to purchase a Spectator Pass.
There will be a $10 charge for parking for each car so please remember to car pool. You will receive specific parking instructions a few days before the race. Make sure to follow those directions and please be respectful to the rules and surrounding site locations.
Post Party:
We offer a post-race party with music, beer, food and vendors.
We have a changing area for post-race, and the event is timed. Minimum age is 2 years old for the Kids Mini Ruckus. If volunteers have a group of 25 or more, Ruckus will donate $500 to your organization. This is a great way to raise some funding and have some fun at an exciting event.
There is nothing better than running the Ruckus with your friends. As a result, participants have the option to create teams during registration.
What better way to experience some added camaraderie than climbing a 14-foot cargo net with friends or family?
Your team can be as small or big as you'd like; there are no restrictions. You will not be timed as a team. While teams can run the race together, everyone is timed individually.
Team members must coordinate start times with each other if they want to run together. We recommend teams sign up early, as wave times sell out, and once they are closed, they are closed.
Coupons / Discount Codes:
Please see our obstacle course race discount & promotion page for all the latest discounts, promos, promotions, discount codes, and coupon codes for Los Angeles California Ruckus Obstacle Race 2013. There also may be one listed at the top of this page.


text:
Welcome to our new community events calendar! Here's what's happening in our community!
Please submit your event at least two weeks in advance. All posts need to be approved prior to being published and will not show up right away, so please be patient. If you have an event to list, please visit our Submissons page.
* Please type in regular format, do not use ALL CAPS or BOLDED text.
|3 Thu
12:00 am
1:00 am
2:00 am
3:00 am
4:00 am
5:00 am
6:00 am
7:00 am
8:00 am
9:00 am
10:00 am
11:00 am
12:00 pm
1:00 pm
2:00 pm
3:00 pm
4:00 pm
5:00 pm
6:00 pm
7:00 pm
8:00 pm
9:00 pm
10:00 pm
11:00 pm
9:00 am Lindsay's Health Centre for Women @ Antigonish Women's Resource Centre, 219 Main Street
Lindsay's Health Centre for Women @ Antigonish Women's Resource Centre, 219 Main Street
Mar 3 @ 9:00 am – 4:00 pm
Lindsay's Health Centre for Women is a partnership of the Guysborough Antigonish Strait Health Authority, the Antigonish Women's Resource Centre and the medical community. Services are provided by a multi-disciplinary team that includes Mental Health Services,[...]


text:
How Australia got hot for solar power
Down under, they're all over alternative energy - starting with a 1,600-foot-tall "solar tower" that can power a small city.
SAN FRANCISCO (Business 2.0 Magazine) -- The editors have identified the Best business ideas in the world, which will appear here in a series throughout the next month. Check back daily for updates.
Rattling down a red dirt road on the edge of the Australian outback, Roger Davey hits the brakes and hops out of a rented Corolla. With a sweep of his arm, he surveys his domain - 24,000 acres of emptiness stretching toward the horizon, the landscape bare but for clumps of scrubby eucalyptus trees and an occasional sheep.
It's a dead-calm antipodean winter's day, the silence of this vast ranch called Tapio Station broken only by the cry of a currawong bird. Davey, chief executive of Melbourne renewable-energy company EnviroMission, aims to break ground here early next year on the world's first commercial "solar tower" power station.
"The tower will be over there," Davey says, pointing to a spot a mile distant where a 1,600-foot structure will rise from the ocher-colored earth. Picture a 260-foot-diameter cylinder taller than the Sears Tower encircled by a two-mile-diameter transparent canopy at ground level. About 8 feet tall at the perimeter, where Davey has his feet planted, the solar collector will gradually slope up to a height of 50 to 60 feet at the tower's base.
Acting as a giant greenhouse, the solar collector will superheat the air with radiation from the sun. Hot air rises, naturally, and the tower will operate as a giant vacuum. As the air is sucked into the tower, it will produce wind to power an array of turbine generators clustered around the structure.
The result: enough clean, green electricity to power some 100,000 homes without producing a particle of pollution or a wisp of planet-warming gases.
"We're aiming to be competitive with the coal people," says Davey, 60. "We're filling a gap in the renewable-energy market that has never been able to be filled before."
And although its final dimensions are still being tweaked, the 50-megawatt Tapio Station plant is just the small model: A half-mile-tall version is in the works for China, and EnviroMission is scouting sites in the American Southwest for other possible skyscraping power plants.
Tower of power
The solar tower is the most audacious of a host of renewable-energy projects under way in Australia that are making the country the global hotbed of alternative-energy entrepreneurship.
Among the sea of slick suits crowding the Qantas Club at Melbourne Airport just after dawn on a clear June morning, Davey, stands out in his brown-checked sports jacket. EnviroMission communications director Kim Fort� leans over and whispers to Davey; she thinks she spots a familiar face amid the preflight caffeinating: a government bureaucrat involved in dispensing $370 million to low-emission energy projects. EnviroMission has applied for a $75 million piece of that pie, and a decision is imminent.
It's a crucial time in Davey's eight-year quest to turn the space-age images on EnviroMission's website into steel and glass. Secure the cash from the feds and a third of the cost of the solar tower's construction is in the bank. That in turn will likely open the wallets of Australian investment banks.
So today Davey and Fort� are taking a 36-seater prop plane to Mildura - "Gateway to the Outback" - to rally support in the rural towns near the tower site.
Energy without the mess
With a solar tower, there's no fuel to dig out of the ground, transport, or dispose of, no smog, no scarred landscapes from open-pit mining. The sun rises every day and is not subject to embargoes, geopolitics, or commodity markets.
And once the solar tower's capital costs are paid off, the price of producing electricity should drop dramatically, as operating and maintenance costs are expected to be minimal. Despite its monolithic scale, the technology behind the tower is based on an elemental scientific truth: Hot air rises. The solar tower's only moving parts are its turbines.
Davey's mobile phone trills. "Hello? Yes, mate. 2:30 at your office. Done. Thanks, mate." On the line was an executive with AGL, one of Australia's largest utilities. Early on, EnviroMission locked up a deal to provide AGL with electricity produced by the solar tower. Davey has also secured the services of Macquarie Bank, one of the country's most prominent investment banks and a financier of major infrastructure projects in Australia and overseas.
In 2002 executives at Xiang Jiang Industrial, a Shanghai developer and construction company, stumbled across press mentions of Davey's project. Xiang Jiang subsequently became EnviroMission's second-largest shareholder and has created a joint venture with the company to build and operate solar towers in China.
At some point, almost everyone who comes across Davey and his tower ends up asking the same question: Is this for real? As far as Davey has come in his quest, many hurdles do remain.
But out at Tapio Station, Davey insists that the solar tower will be built whether or not the government gives EnviroMission $75 million. "This used to be a dream," he says, staring out at the horizon where the tower will rise. "Then it became a concept. Now it's becoming reality."
This is an excerpt from a longer story in Business 2.0's August issue. Click here to read the complete version.


text:
Welcome to the Chocolate Tree Web Site.
For those of you who have been regular visitors here: A sincere thanks. For those of you who are here for the first time: Welcome! Please take a moment to take a look at all of the selections we have to offer.
The Chocolate Tree is Beaufort's one-stop-shop for fine chocolates and other confections made right on the premises! You can have your candies shipped anywhere in the world or visit our master candy-makers in action in Historic Downtown Beaufort, South Carolina.
All our Sweets are freshly made at THE CHOCOLATE TREE using only the finest ingredients available. Remember that The Chocolate Tree has been serving the Beaufort area since 1980.
Call or Drop by Today.


text:
EMBARK partners with many community organizations to provide a wide range of transportation programs to meet the diverse needs of the community. Through these programs, qualified customers maintain independence and access community services by arranging their own transportation.
Applicants age 60 years and older are eligible for the majority of EMBARK's Mobility Management Services and all services require an application process. Applications based on a disabling condition may require verification of the applicant's functional disability by a physician or other certified healthcare professional.
Services for Adults Age 60+
|Through a partnership with the Areawide Aging Agency, EMBARK offers a full range of transportation options to individuals age 60 and older who live within our service area. Senior transportation services are free to participants and donations are accepted to provide continued support for the program. All senior transportation services require arrangements to be made in advance of the date transportation is needed.
EMBARK Senior Transportation Partners
Senior transportation services funded in part by the Older American's Act, the Oklahoma Department of Human Services, and the Areawide Aging Agency in partnership with EMBARK.
EMBARK Plus provides lift-equipped public transportation to eligible individuals within the Oklahoma City limits who are not functionally able to ride our fixed-route bus service due to a disabling condition.
Income and Other Age-Based Services
Norman Mobility Management Services
Norman residents in need of ADA Paratransit must complete the EMBARK Plus Norman Application. Completed applications can be sent by postal mail to 2000 S May Ave, OKC, by fax to 405-316-1668, or by email to email@example.com.
For more information on senior transportation services call Cleveland Country Aging Services. For more information on the services they provide, call 405-235-RIDE.
Interested in learning more about transportation in the City of Norman? The Community Planning & Transportation Committee meets monthly and you can learn more here.
Email Updates


text:
A handy little tool that will easily remove graphite shafts broken off at the hosel of wood and iron heads. This tool concept was developed by professional clubmaker Patrick Kennedy and is a real time saver. To use, drill a pilot hole using a 7/32" drill bit and screw in the Broken Graphite Shaft Extractor . Place the Broken Graphite Shaft Extractor into any Graphite Shaft Extractor for easy shaft tip removal.
7/32 Drill Bit sold seperately - GolfWorks code DBH18