3piece's picture
3piece - Mon, 2016/09/12 - 06:39

Hi All, I am stil using ProxMox v3.1 in production and would like to add another server, and update some containers.

I can not find any openVZ containers on the repository. Have they all been removed?

 

I have read this article

https://www.turnkeylinux.org/forum/support/20150504/proxmox-moving-openv...

 

And this one:

 

https://www.turnkeylinux.org/blog/14.0-optimized-builds-pt2-proxmox-open...

 

When I try to download a template, say:

 

http://mirror.turnkeylinux.org/turnkeylinux/images/openvz/debian-7-turnk...

 

It says it is not available. The whole directory seems to have had all images removed:

 

http://mirror.turnkeylinux.org/turnkeylinux/images/openvz/

 

Searching on the web for the file only provides the signature files, all the images have been removed from mirror repositories. Why?

 

How can we download openVZ images for our production servers?

 

Do we have to install a new server instance using proxmox 4 with LXC, download new containers and migrate all the data?

This seems like a massive task with over 80 server instances deployed.

 

Best Regards,

James Moyle.

Forum: 
Support
Jeremy Davis's picture

Jeremy Davis - Mon, 2016/09/12 - 12:58
Liraz was a little overzealous the last time he cleaned the mirror. So now we have only the v14.1 appliance images.

I did some very brief testing of the v14.0 LXC containers on PVE 3.4 and they worked so AFAIK if you manually download the templates from our mirror, they should still work fine. I did have an intention of updating the code so v3.4 could also get the latest images but the Proxmox guys recommended not doing that unless we were willing to support them (which wee don't have the resources for)...

I suggest that you SSH into your PVE server, cd to where ever you keep your templates (IIRC /var/lib/vz/templates/cache is the default) then wget the desired image(s) direct from our mirror: http://mirror.turnkeylinux.org//turnkeylinux/images/proxmox/
They should then show up in the UI and you should be able to launch them as you would any other template.

Also FWIW from my reading, if you make a "Proxmox" backup of your container you should be able to restore that straight to a v4.x PVE host.

Jeremy Davis's picture

Jeremy Davis - Tue, 2016/09/20 - 11:21
We had a big clean up of the mirror a few months ago and all the old images have gone.

If you were on a 64 bit machine I would encourage you to use the current LXC host image instead. It's much better than the old v13.x build. However we no longer "officially" support 32 bit builds.

Having said that we did build most of the appliances as 32 bit for v14.1. They are only available as ISOs though, not containers. FWIW they are all on the mirror. Unfortunately we didn't do LXC. TBH I don't recall why, but I suspect that there was some technical reason which we didn't bother trying to work around.

So what you could do if you wanted is to install the 32 bit TKLDev ISO to a VM. Then clone buildtasks to /turnkey, then use the bt-container script to build any of the images you want in 32 bit as containers.

FWIW that's what we use to build all the containers ourselves.

Although having said all that, I'm actually not 100% sure that our v14.x builds will be 100% backwards compatible with the old v13.x LXC host. I suspect they would be, but would have to promise that they are only for you to find you do all that work for nothing...

Lone Wolf's picture

Lone Wolf - Tue, 2016/09/20 - 20:24

That sounds really interesting. So, are you saying that I can install an appliance on a VM, modify it and then repackage it as an ISO (or any other format) to have a new version of the appliance? Or did I misunderstand? I read the process for creating an appliance and I thought that you would always need to start from scratch... Is that the case?

Regards!

Jeremy Davis's picture

Jeremy Davis - Wed, 2016/09/21 - 12:29
I've skimmed your other threads and am really sorry that I haven't had a chance to respond properly yet. You've shared some great stuff, thanks.

If I'm right on what you're thinking, then no, it's not quite like that... But it's still pretty cool IMO.

All the appliance build code is on GitHub. TKLDev is the buildtool (docs are here, although they are a little out of date - ignore mention of the sandbox...). TKLDev is packaged as a standalone appliance. It needs to be installed to a full VM though, it doesn't work as a container. Also you need TKLDev with the same arch of the VMs you want to build.

Armed with those bits you can build the appliances ISOs yourself from source! You can modify the buildcode to tweak it, or create a totally new appliance...

Install TKLPatch and add buildtasks and you can build any appliance in any build format (that we currently provide), from OVA to Docker, OpenStack to LXC container...

By default buildtasks uses the ISO to build the other target builds, but I use Proxmox locally for testing. I have a custom buildtasks script, that builds to ISO, then converts ISO to LXC container, then uploads it straight to my Proxmox server ready to go. I had always intended to script the auto creation of a test container but never got that far... :)

Lone Wolf's picture

Lone Wolf - Fri, 2016/09/23 - 22:56

Don't worry, Jeremy. I know how it can be when we get busy, I have been busy these days, too.

I am glad you found my contributions helpful, so you are welcome.

Regarding what you mention, I do not disagree that it is really cool. I will read the documentation and get back to you if I have any questions. I appreciate your guidance on this particular matter.

Before I continue, my understanding is that these would be the steps:

  1. Install the TKLDEV image to a new Virtual Machine (This can be done by using the ISO to perform the install)
  2. Use git to clone the intended appliance (Core for a brand-new appliance)
  3. Perform any updates on the Virtual Machine (apt-get installs/updates, adding/modifying files)
  4. Perform the build (getting into the cloned directory with git, executing "make")
  5. Retrieve the ISO generated from the build folder
  6. If you desire to build in other formats than the ISO:
    1. Install the build extensions (TKLPatch and buildtasks)
    2. Provide the built ISO to buildtasks and build in the desired format (Perform this step for every desired format) 

Does that summarize the steps required to customize/upgrade an existing appliance? I wonder if step number 3 is more about modifying the files that were cloned, though.

Now I am on to reading the documentation and trying my hand on making a new appliance from Core and customizing an existing appliance. I will let you know if I was successful in my endeavor or if I require further clarification and guidance.

Regards!

Lone Wolf's picture

Lone Wolf - Mon, 2016/09/26 - 08:47

Jeremy,

I was able to build my first ISO from core; however, I must admit that I found the Hello World example a little confusing since I was not sure what was safe to ignore related to the sandbox (it is mentioned all over the page).

After reading some more and checking other appliances in GitHub, it seems clear that I can:

  • Use the overlay directory to include files which will be deployed during installation
  • Modify the plan file to specify the packages which will be installed
  • Add install scripts inside the conf.d directory (I am not sure if the name matters but I am assuming it doesn't).

However, I also noticed that the makefile has been modified in a few of them. Is this done by hand, as well? What is the purpose of COMMON_OVERLAYS and COMMON_CONF in this file? Do I need to touch them to add additional overlay directories and additional common configuration directories?

And, if I do, should they be added with += like in the postgresql one or just with = like in the asp.net apache one? Could it be that this might be causing an issue in the asp.net apache appliance (the examples not being added)?

Please let me know what you think. I will keep playing with TKLDEV and building more ISOs.

Regards!

Jeremy Davis's picture

Jeremy Davis - Fri, 2016/09/30 - 11:29
Apologies again on my late reply, and on the state of the docs too. They're pretty sub-par...

You may have already discovered some of this yourself, but for completeness I'll answer this one here first before I respond on the other thread.

But in essence it sounds like you got it!

Yes the make files are edited by hand (where/when relevant).

COMMON_OVERLAYS and COMMON_CONF are the same as the conf and overlays in the appliance repo, except they are shared between multiple appliances and come from common! It gets a little messy sometimes, but is aiming to implement the DRY (don't repeat yourself) principle.

So some of the stuff in common applies to all appliances, some of it only applies to certain appliances. And it's in the make file that all that is defined. Using LAMP based appliances as an example, they actually call a common lamp makefile, e.g. WordPress

Your question about whether to use '=' or '+='is a really damn good one! TBH I had never even noticed and always just used '='! I just grepped through the appliances and here's the ones that use '+=': 

canvas
gallery
lighttpd-php-fastcgi
lxc
mantis
mattermost
nginx-php-fastcgi
postgresql
roundup
The other ~90 just use '='. So I don't think it matters, although I need to chase that up with Alon and find out for sure. The GNU make docs were no help at all. '+=' doesn't even get mentioned that I could see.

Add new comment