Jeremy Davis's picture

[UPDATE 16-10-2011] v0.4 minor update - Fixed autoremove bug (commented out autoremove) and reduced patch size (scripted changes to firstboot scripts rather than include them in overlay). Also updated install instructions below (will install v0.4).

[UPDATE 15-10-2011] (Jeremy) Forked Adrian's tklovz patch and did a major update (changelog below). Also repackaged Adrian's tkliso2ovz kit as a TKLPatch.

[edit] Minor Bug: apt-get autoremove runs interactively so the process of conversion is halted (wants to remove a package 'turnkey-sslcerts' - which possibly should be set to manually installed anyway?) as it waits for input (y/n). This isn't a huge issue (just hit y or n during conversion) and can be easily fixed but I'm not going to worry about it just now. - fixed see above.

TKLOVZ patch Changelog:
* Removed lots of cruft (kernel and modules, plus lots of unneeded packages) from templates which significantly reduces the template size (Core OVZ now ~60MB smaller than ISO).
* Fixed - networking issues.
* Fixed/Workaround - getting stuck on interactive firstboot scripts (causing Webmin and other services to not start). Workaround was to only allow the non-interactive scripts run, requires user to manually run an init-script on first boot (to access interactive initialisation scripts) see below.
* Reworked how ssh keys and ssl-certs are created (now uses default TKL inithook firstboot scripts).
* Stopped confconsole from running (wasn't causing issues but wasn't usable anyway).
* Created a init-ovz script to run interactive firstboot scripts manually (eg Hub initialisation, Security updates, etc).

TKLISO2OVZ Changlog:
* Repackaged Adrian's work with the new version of TKLOVZ patch as a complete TKLPatch so it is easy for newbs (and others) to set up an environment for creating OVZ templates.

Install:
These steps are ideally to be used on a clean install of TKL Core at a terminal (local or SSH). Theoretically this could be used on any installed TKL appliance although running services can cause unpredictable results.

apt-get update
apt-get install tklpatch
wget http://cdn.turnkeylinux.org/files/attachments/tkliso2ovz0.4.tar.gz
tklpatch-apply / tkliso2ovz0.4.tar.gz

Usage:
Example of creating an OVZ template of TKL LAMP. Assuming that the ISO is in the local directory.

tkliso2ovz turnkey-lamp-11.2-lucid-x86.iso

This will create an OVZ template called turnkey-lamp-11.2-lucid-x86-ovz.tar.gz in the local directory.

Firstboot of OVZ container:
Some default TKL inithook firstboot scripts run as they would on any other TKL appliance (eg create SSH keys and SSL certificates) but the interactive ones were causing problems so they no longer run. I have worked around this issue by creating an initialisation script. Some aspects of TKL will work ok without running this script and on some appliances you may not even notice that it hasn't been run. However for full functionality it is recommended that you run the script:

init-ovz

[/UPDATE]

[UPDATE 12-01-2011] Preseeding working so that the appliance start ups with default settings/passwords. Polished the patch a bit. 

[UPDATE 11-01-2011] Added a pair of lines to make mysql start at boot and holding a package to prevent upgrade failures (as recommended in the guide's comments) 

[UPDATE 05-01-2011] I (Adrian) took Jed's work and extend it a bit to make it work. The result was:

1. A tklovz patch that prepares the appliance filesystem to work as an openVZ container.

2. A top level tkliso2ovz script which does the following:

   2.1. tklpatch-extract-iso: to get the filesystem

   2.2. tklpatch-apply tklovz.tar.gz: the patch must be in the same folder or /usr/local/share/tklpatch/tklovz.tar.gz

   2.3. tklpatch-gen-ovztemplate: to compress and get the final template file. 

So if any of you wants to experiment with this, you have to options:

- On a system with tklpatch installed, copy both supplied scripts to /usr/local/bin/ and give them execution permissions. Then place tklovz.tar.gz in your working directory and issue the command:

tkliso2ovz /path/to/turnkey-appliance.iso

- Wait a bit for the following release of TKLDevEnv which will include all the commands already configured. I hope to get it out this week.

Any questions, feel free to ask. I've tested with core and revision-control without issues. But redmine is not working. But I'm still testing, as the appliance had an issue while decompressing the original iso which I think it's related to this error. Also, keep in mind:

- Confconsole won't be running when you access to the console of the container. You must run confconsole if you need access to it. 

- When using venet, confconsole won't work as intented, because you are managing the ip configuration at another level. If you wish yo use confcosole to work as usual, use veth as your network type. Be sure to check the docs about the differences http://wiki.openvz.org/Differences_between_venet_and_veth

- The template name will be the iso name plus -ovz.tar.gz at the end. So if your going to use it in proxmox, be sure to rename it following their guidelines:

<OS>-<OSVERSION>-<NAME>_<VERSION>_<ARCH>.tar.gz

For Example: "turnkeylinux-10.04-revision-control_11.0_i386.tar.gz"

- The host name ends up being renamed to what you specify in the creation of the container. Also the root password is specified in the creation step. - Inithooks don't get runned. So you must manually execute the command /usr/lib/inithooks/run to complete your appliance setup.

[update 18-12-2010] Further testing has revealed some major issues! :( The templates created are currently unusable.

[Original post] For some time now I've been looking to produce OpenVZ templates of the v11 (Lucid based) release of TKL. However, rather than simply provide instructions as I did for the v2009.x release or even provide precreated templates (as xtrac568 did - also for the 2009.x release) I have been trying to script the conversion or better still leverage TKLPatch to create the templates. That way users can create their own templates and templates of TKLPatched appliances could also be produced by end users. Perhaps it could even be included in Adrian's TKL Dev Environment?

Great news is that the OpenVZ templates seem to build nicely in a chroot so you don't even need a working OpenVZ environment to build in. I've made a minor tweak to the top level TKLPatch script (tklpatch) and coupled it with a specific OVZ creation patch (thus creating a new script-thing I've called tklovz).

[Update] It works! Be warned, I haven't extensively tested it, only on the TKL 11.0RC Core ISO and I have only done arbitrary testing of the resulting OpenVZ template. Also as has been mentioned elsewhere not all appliances will run well under OpenVZ. Apparently Java based apps aren't the greatest, but only way to know for sure if the appliance you want to run in OVZ is to test!

Please find attached the tklovz script and patch. Only the name of the ISO needs to be passed to the scipt (unlike tklpatch which also requires the patch name). Assuming the TKLOVZ.tar.gz and your TKL ISO are in ~ (/root) then you only need to unpack tklovz and run it.Using Core as an example:

tar xzvf TKLOVZ.02.tar.gz
./tklovz turnkey-core-11.0rc-lucid-x86.iso

Assuming that all goes well, you should end up with an OpenVZ template named accordingly (in this instance "turnkey-core-11.0rc-lucid-x86.tar.gz").

What this patch/script does

The scripts and files are more fully detailed in the Dev wiki:

  • Extracts the ISO (tklpatch-extract-iso)
  • Applys the patch (tkl-patch apply) - the OVZ creation process script (the conf script of the patch)
    • Modifys required files & services for OVZ template
    • Builds preliminary template with required files
    • Recreates required files in prelimary template, cleans logs etc.
    • Packages final template
  • Instead of recreating an ISO, it copys out the created OpenVZ template (.tar.gz) and names it the same as the original ISO
  • Cleans up the temporary .rootfs & .cdroot filesystems.

I anticipate that there will be updates as I try to tweak things a bit, but no promises.

Forum: 
Jeremy Davis's picture

Where

mv ~/$rootfs/template.tar.bz2 ~/$name.tar.gz

perhaps the leading ~ is causing the problem (because $rootfs should be adequite). It still doesn't explain (to me anyway) why the script doesn't either error or complete. I'll check this when I get home though.

Anone else got any ideas of feedback?

Jeremy Davis's picture

The patch applies and it does most of the work. I changed it so the top level script (a mod of tklpatch) is now meant to handle the final tempate creation. But I've discoverred that it is not returning from

tklpatch-apply $rootfs $patch

the last line before it seems to exit cleanly is:

Removing `local diversion of /sbin/initctl to /sbin/initctl.distrib'

and then it just stops, it does not error. I confirmed this by a simple echo after the tklpatch-apply line and it doesn't get printed on the screen. I'm not sure what I'm doing wrong. Perhaps I should start again from scratch!?

Adrian Moya's picture

Sorry for the late reply. I've been doing a thousand things this days. I'm really interested in helping you pushing this out. Could you please run the command with | tee logfile.log to see the complete output?

tklpatch-apply $rootfs $patch | tee tklpatch-apply.log

Also check: that the conf in the patch has execution permission. If not, you know what to do:

chmod +x /path/to/conf

If it's executing, it's probably returning an error, and that's why it doesn't continue. I had a similar case, and don't remember exactly what was it, but suspect of the exec permission.

Attach the tklpatch-apply.log and check the permission and come back with the results to further help you. 

Also: I'm not ver familiar with OpenVZ, but I think it would be the perfect backend for the Master Server, because appliances would be able to share the memory of the host. But last time I checked OpenVZ, it was a bit outdated. The current kernel was not stable. Which kernel for openvz are you using? 

Jeremy Davis's picture

Although when released the kernels are usually only rpms. Proxmox currently gives you the choice of 3 stable kernels that support OVZ (the forth, 2.6.35 Ubuntu kernel is KVM only):

2.6.18 - both KVM & OVZ, quite old now, but still supported.

2.6.24 - both KVM & OVZ, still available, but no longer supported with updates.

2.6.32 - both KVM & OVZ (latest stable development branch) - default PVE kernel (based on Debian Sqeeze).

Adrian Moya's picture

I remembered what happened then: the conf file didn't had the shebang (#!/bin/bash). This made that the conf file didn't execute. I think that was what got me to a situation similar to the one you describe. 

If possible after those test, if you can share the script to see what's the procedure you're following to generate the image.

Alon Swartz's picture

Having a TLKPatch to convert ISO's into OpenVZ templates will be awesome! It might even push us to release openvz builds of the appliances (once we setup a testing enviroment).

Regarding your issue, try adding -x to the shebang (e.g. #!/bin/bash -ex) as that will be display every command executed to stdout, which should help you zero in on the issue.

Adrian Moya's picture

Yesterday I thought about that, and I think it should be possible to produce also the other formats, not only OVZs.

I haven't made my research yet, but does creating the vmware image and Amazon's ami scriptable? I would love to see TKLDevEnv could produce those. Speaking of which, I'll try to push out the first version next week including the web patchtool. 

Jeremy Davis's picture

What I have posted only creates an OVZ template from an ISO, but could be easily tweaked to apply a patch first as well (that was my initial intention but I left that for now because of the issues I ran into).

If you go ahead with including this with your other ideas Adrian then perhaps it could use switches to determine what formats are output? (ISO/OVZ/VMware image etc)

Adrian Moya's picture

I've finished studying your scripts. You:

1. Apply a fixed patch to generate the OVZ template. (The patch is complete chinese for me :S)

2. At the end instead of creating the iso, your creating the tar.gz template from the resulting /template folder inside the patched-fs. 

Beginning from this (great) idea, I could add to the tklpatch a flag --output-format=format and format could be iso (default) ovz, vmware, ami, etc. So tklpatch would:

1. After patching the base iso, add the additional tkl-ovz patch if format is ovz. 

2. The output would be the template and not the iso. 

For the tkldevenv, some changes would be needed. Instead of patched-isos, you would get Output (generally speaking). 

I'll work on a pilot with only the ovz alternative, but after releasing the next version of tkldevenv with the patchtool (I'll just finish some minor changes and the deployment of the django app so that some early tester can try it out).

Great work you linux newb! ;)

P.S.: BTW I'm already thinking on ways to make this faster. If all images would be based on a fs, maybe we can save some time having the uncompress fs ready for patching. MMMMM, I'll think a bit more about it. 

Jeremy Davis's picture

As it turns out my problems were being caused by a service still running in the chroot. On advice elsewhere I replaced rsyslog with syslog-ng which apparently performs much better in an OpenVZ container. At the end of installation though the service is started and I was neglecting to stop it. For some reason it wasn't throwing out any errors, just stopping after applying the patch.

The strange behaviour of the rootfs not being able to be deleted until after a reboot got me thinking. And some close attention to a full log (thanks to both Alon and Adrian - both pieces of advice helped there) I saw the service starting, so I simply stopped it and now all works well. Yay

I think it could do with some tweaking and trimming still - the template clocks in at 163MB (3MB bigger than the ISO) which is huge! But its a start! And the template appears to work ok (although as stated above I haven't done extensive testing).

Adrian Moya's picture

I'd also study what you did here, in order to blend this into the tkldevenv in a not-so-far future. 

Good work! 

Adrian Moya's picture

Is it ok that the final tar.gz file ends up with all files in the directory turnkey-base.fs/template/ ?

I'll try with this result but that made me curious. 

[Update]: I've just compared with other tar.gz template from proxmox and they have a . (dot) folder only and the filesystem in it. I'll be upgrading the proxmox to 1.7 and see how it goes...

Jeremy Davis's picture

It shouldn't be like that.

That shows my inattention and lack of quality control - but in my defense it was 2am after a barbecue with friends. I was so excited that I had got the process to work that I actually didn't test the final template. I tested an earlier template from before I had solved my issue with the process cleaning up and completeing totally. I made the mistake of thinking that because I hadn't fundamentally changed the template creation process that it would still work.

I will fix it and reupload shortly.

[Update] Fixed and new version uploaded.

Jeremy Davis's picture

The templates created are currently not working well enough to say that this is successful :( The templates boot but I am unable to connect via SSH. None of the first boot scripts ran as I expected them to and there are very few services running (not yet sure why).

This is a major blow but I intend to persevere and try to get this working. Sorry to post without doing proper testing first. I sincerely apologise for any inconvenience.

[update] something seriously wrong with networking - confconsole is finding no interfaces to configure (none!) and ifconfig returns nothing. The appliance does not respond to pings and cannot be contacted in anyway that I can find beyond the VNC console built into PVE (no web services eg Webmin, no SSH/SFTP). It seems to be able to make outgoing connections fine (apt-get update completes with no errors) but no incoming connections.

Adrian Moya's picture

Today I took a quick look at the process of creating a template. I found this. I haven't compared if it's the same method you are applying. But once I finish some things I'm currently working on, I'll sit down with this. I'll update my home proxmox today too, and I'm planning to change from kvm to openvz to make better use of resources. But I also check the status of memory overcommit on kvm just in case I'm missing something. 

Jeremy Davis's picture

That's the main one I've been using but I was also having a bit of a play with some other info I found around (mostly on the Ubuntu forums). When I intially set out to do this I sat down and went through it step by step until it worked. I recall having problems with SSH but the fix included in Bodhizazen's blog did the trick from memory. I thought that I hadn't altered the OVZ part at all since I confirmed a working patch and I'm sure I tested the very first template I made with this patching process and it was ok (even though at that point the process wasn't completeing properly - the template was still ok). But obivously I've done something without proper testing.

I'll go back through Bodhizazen's tutorial again, I'm also just having a look at the Ubuntu minimal template that he made (its a lovely ~80MB - half the size of the one I made of Core!) so hopely I might get a feel for some other stuff that can be trimmed. I probably should just get it working first though I guess! Then tweak it.

As for PVE, I've got 1.7 running at work but still on 1.6 at home. So far I have only used KVM for Win and some Linux testing. I know it has some pretty trick features but I still like the minimal overhead and I also quite like the fact that you can get into the filesystem when the VM is off (via the host - although too much playing in there upsets the guest when it restarts).

Kynao's picture

Hi!

If i understood one or two things :), it seems there are some Turnkey openvz templates available and others are in the work

Is there any wiki page tutorial for newbies (using Proxmox) explaining how to install one of these Turnkey OpenVZ template ?

Thanks in advance


Jeremy Davis's picture

There is a link to the unofficial precreated templates of the TKL v2009.10-2 range of appliances in the top post.

Proxmox is pretty easy to use, but first ensure that the template conforms to the PVE naming convension or othrwise it won't show up in the webUI: <OS>-<OSVERSION>-<NAME>_<VERSION>_<ARCH>.tar.gz

Then upload the tar.gz image to Proxmox, either use SFTP (to /var/lib/vz/template/cache) or the interface (under VM manager on the left > Appliance Templates).

Once the template is loaded, go to Virtual Machines (under VM manager on the left) and select the middle "Create" tab (in the main interface). Select Container (OpenVZ) for the type then select your template from the dropdown. From there it should all be self explanatory.

Kynao's picture

Perfect explanation, clearly helpful fo starters like me.

So, there will be some plans for releasing all turnkey images 11.0 for openvz, am i right ?


Jeremy Davis's picture

I anticiapte that eventually they will be officially released but not clear on when that may be.

Once I iron out the kinks, the process I have documented here will be available for any users to convert any appliance (even a community created one utilising TKLPatch) can be convert relatively easily.

If there is enough demand, even if the devs don't officially release OVZ templates I'm sure someone (perhaps me?) will provide at least some of them.

Adrian Moya's picture

Hi Jed, I took a look at your script against the guide. I think almost all where there, but I added some things I didn't see. Anyway I upgraded my home server, but haven't had a chance to test. Is the last upload working fine or should I (when I found some free time!) try to help you fix the script?

Thanks, 

Jeremy Davis's picture

I thought I'd already replied to this post this morning - but obviously not!

The templates created from this process do not work :(. I have been doing a lot more playing today and I went back over that tutorial and commented out everything that wasn't there. I thought I was on a winner but it seems things are getting worse... The template has no network connectivity at all!

I think I'm going to have to scrap the lot and start again. I've got no idea what's going on. It's especially frustrating as I'm sure I had a 10.04 TKL OpenVZ template that works (which I created earlier on), but none of my recent ones seem to work.

This VZ log from Proxmox suggests that the container is starting properly:

/usr/sbin/vzctl start 230
Starting container ...
Container is mounted
Adding IP address(es): 192.168.1.230
Setting CPU units: 1000
Setting CPUs: 1
Set hostname: ovz-template-test.home.lan
File resolv.conf was modified
Setting quota ugidlimit: 0
Container start in progress...
VM 230 started

But this log (VM Syslog) from Proxmox shows that something is wrong as the networking is clearly not being set up right:

Dec 23 10:43:16 ovz-template-test syslog-ng[57]: syslog-ng starting up; version='2.0.9'
Dec 23 10:43:16 ovz-template-test ntpd[71]: ntpd 4.2.4p8@1.1612-o Fri Apr 9 00:28:40 UTC 2010 (1)
Dec 23 10:43:16 ovz-template-test ntpd[72]: precision = 1.000 usec
Dec 23 10:43:16 ovz-template-test ntpd[72]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
Dec 23 10:43:16 ovz-template-test ntpd[72]: Listening on interface #0 wildcard, 0.0.0.0#123 Disabled
Dec 23 10:43:16 ovz-template-test ntpd[72]: Listening on interface #1 wildcard, ::#123 Disabled

As I think I've mentioned already, ifconfig returns nothing but /etc/network/interfaces seems ok.

# Auto generated lo interface
auto lo
iface lo inet loopback

# Auto generated venet0 interface
auto venet0
iface venet0 inet static
    address 127.0.0.1
    netmask 255.255.255.255
    broadcast 0.0.0.0
    up route add default dev venet0

auto venet0:0
iface venet0:0 inet static
    address 192.168.1.230
    netmask 255.255.255.255
    broadcast 0.0.0.0

Have you got any idea Adrian?

Kynao's picture

I'm not very sure if it's directly related but, as exposed here http://forum.proxmox.com/threads/5369-Turnkey-Linux, it seems the proxmox guys proposed to help the Turnkey team members for the creation of openvz templates.

Why is it not possible for Turnkey team and proxmox team to work hand in hand ?


Jeremy Davis's picture

If you read through the forums here you will find that the core devs (Alon & Liraz are not against OpenVZ. They are actually very supportive of it and as eluded to by posts in your thread on Proxmox forums, there have been discussions between PVE & TKL (see here) but they basically stalled. Whilst the projects sort of overlap and could work really well together, Proxmox put their primary effort into their hypervisor and TKL put their effort into a broad range of software appliances in various image formats. This is summed up in a post by Liraz (core TKL dev) here. Martin (PVE dev) clarifies his position here.

My understanding of the TKL perspective is that the core devs already have an established workflow and 40+ (soon to be many more) appliances, already supported in multiple formats - ISO, VM image (OVF), Xen image, Amazon AMI, etc. They have expressed interest in and support of OVZ templates. I'm sure if they has an easy way to script creation of TKL OVZ images into their workflow then they'd have done it ages ago. But they have a todo list forever long and there's only 2 of them so unfortunatly OVZ support falls by the wayside. Despite the fact that I would love it if it was, OVZ is not a priority for TKL. And in fairness why would it be? I suspect most/many TKL users are primarily Win users and probably have no use for OVZ templates at all.

Until TKL devs set up some new build process, or make OVZ templates a priority, the only way we can have TKL templates is to do it manually, or work out a scriptable way to convert ISOs to OVZ templates (hence this thread).

If you read the other thread that I linked to you will see that for the TKL devs its a case of having a reason to put greater priority on OVZ templates for Proxmox. I don't see this happening until someone steps up and sorts out the 3rd party channel suppport for PVE. Martin has stated that they'd be happy to support anyone who steps up and does it. And Liraz has stated that once thats done he'd be happy to prioritize OVZ templates.

Adrian Moya's picture

And included my version based on your work. I'll include this set of commands/patch to the tkldevenv, maybe with an additional command to patch-to-ovz directly.

Hope this works!

Jeremy Davis's picture

Thanks very much for getting this running Adrian.

I will be testing within the next few days hopefully. Getting some v11 based OVZ containers running on my new Proxmox VE server at work is high on my things to do list. :)

Jeremy Davis's picture

Hey Adrian, it looks like you may need to add creatation of the log path in the patch.

Initially I was having errors:

/usr/local/bin/tkliso2ovz: line 86: /var/log/tklpatch/turnkey-core-11.0-lucid-x86-ovz.log: No such file or directory

But creating the tklpatch folder (in /var/log) fixed it. Other than that it all seemed to work well. Ok, off to test the template :)

Adrian Moya's picture

As I was running in tkldevenv, I didn't get this error, but yes, I should remove that fixed path from the standalone version of the main script (tkliso2ovz). 

Jeremy Davis's picture

The atachment only seems to just have the patch file, not the other scripts. Thanks mate.

Adrian Moya's picture

My fault, I forgot this is not only a patch, I'm starting to work right now on preseeding the values on first boot, when I finish I'll upload the new patch along with the scripts. 

BTW, take a look at it, if you see something you'd like to understand feel free to ask, we agree on that. 

Liraz Siri's picture

Your work developing and testing a conversion process seems to have brought us much closer to adding OpenVZ support to TurnKey sooner rather than later. Great job guys!

Perhaps the next step after posting this on the forums and maybe getting a bit more community members to test this will be for us to fire up an EC2 instance, rebuild all the ISOs into the OVZ format, push them to sourceforge and announce on the blog that they are ready for wider testing.

Our original plan was to make the TKL 11.0 release available in 5 formats:

ISO, VMWare's VMDK/VMX, OVF, Eucalyptus, Xen.

But your works makes it exceedingly likely OpenVZ will be soon added to that list. This is more interesting than just adding another format because unlike the other platforms, OpenVZ is a lightweight container-type virtualization system that is inherently more resource efficient than "hard" virtualization.

Adrian Moya's picture

I think we're  almost ready to produce a batch of templates and publish it for testing! I'll be testing some appliance this week at home but so far is very stable to me. And they already startup preconfigured with default settings, so the complete turnkey experience is there. 

Jeremy Davis's picture

No issues to mention although I have only tested a couple (Core & Fileserver). Looking Good Adrian. :)

Jeremy Davis's picture

Hey Adrian I am just converting a few ISOs to OVZ templates and came across this error when decompressing the ISO:

zlib::uncompress failed, unknown error -3

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/gus/snd-interwave-stb.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/gus/snd-interwave.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/msnd/snd-msnd-classic.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/msnd/snd-msnd-lib.ko, skipping

Failed to write turnkey-torrentserver-11.1-lucid-x86.rootfs/lib/modules/2.6.32-26-generic/kernel/sound/isa/msnd/snd-msnd-pinnacle.ko, skipping

Otherwise the process seemed to go ok and seeing as they all seem to be kernel sound modules I suspect it's not a big deal, still seems strange. Any idea? Also FYI the errors occurred in the terminal but weren't recorded in the log file?

Adrian Moya's picture

Hi Jed, I didn't had that problem when converting torrent-server, I'm currently using it in my server. So I'm not really sure what happened there, but I'll retry again to see if I get your errors. Maybe if they are not getting to the log, that's why I didn't catch them. It's possible as I probably runned the script and went off the computer and came again some minutes after. 

Anyway, is it working properly?

Jeremy Davis's picture

Using this process I have uploaded a few OVZ templates to SourceForge, have a look here. I would appreciate feedback from anyone wishing to test them.

I am currently testing a few but haven't tested everything I've uploaded so please be patient. And also please report any bugs, although I may not have the time or know-how to provide any quick fixes.

@Adrian, FYI I have not had a repeat of those errors above for any of the appliances I have converted so not sure what happened there. I built these OVZ templates using your TKLDevEnv with the latest OVZ conversion TKLPatch from your GitHub (Jan '11 IIRC).

I am running mine under PVE and have not had any major issues but I have noticed that there does not seem to be any startup scripts running on first boot (none that are interactive anyway) although perhaps this is something to do with the PVE implementation of OVZ?

Also Todd is having some issues with the Revision Control appliance (OVZ template uploaded by me; running under PVE AFAIK). If you have time Adrian be great if you could give your 2c. The post is here although, it's probably most relevant to continue this discussion either here (or perhaps I should've started a new thread). Thanks mate.

Any input from anybody else who is familiar with OVZ would also be awesome!

Jeremy Davis's picture

Download the latest kit from Adrian's GitHub account (link just above the download). Then apply as you would a patch, but instead of outputting a patch ISO it should output a .tar.gz OVZ template. If you are unsure on how to apply a TKLPatch then look at the documentation. Any further probs please feel free to post back.

Jeremy Davis's picture

I just had to set up a clean environment to create some new templates and found it harder than it perhaps should be, so for the uninitiated I have created a quick, dirty how to using the fileserver appliance as an example. I also checked and it looks like the kit available for download here is the latest version created by Adrian. The links may change so the wget lines may require adjustment.

Firstly in an installed TKL appliance, preferably a clean install of TKL Core (probably just to a VM or something) and once it is running execute the following commands (from the /root directory, by default that's where you should start from when you login):

Install TKLISO2OVZ:

apt-get update
apt-get install tklpatch
wget http://cdn.turnkeylinux.org/files/attachments/tkliso2ovz.tar_0.gz
tar xvfz tkliso2ovz.tar_0.gz
rm tkliso2ovz.tar_0.gz
mv tkliso2ovz /usr/bin
mv tklpatch-gen-ovztemplate /usr/bin
mkdir /var/log/tklpatch

Now creating an OVZ template of the Fileserver appliance is as simple as (download the ISO and convert it):

wget http://downloads.sourceforge.net/project/turnkeylinux/turnkey-fileserver/11.2-lucid-x86/turnkey-fileserver-11.2-core-x86.iso
tkliso2ovz turnkey-fileserver-11.2-lucid-x86.iso

If you are using ProxmoxVE you can change the name (to match PVE naming conventions - you will need to do this for each file adjusting for the appliance name):

mv turnkey-fileserver-11.2-lucid-x86-ovz.tar.gz turnkey-lucid-fileserver_11.2-0_i386.tar.gz

and then rsync it to the correct directory on your PVE host:

rsync -goptv --stats --progress  *i386.tar.gz 192.168.1.50:/var/lib/vz/template/cache

Hans Harder's picture

 

nice, nice....

Never saw this thread.... and since OVZ templates could also be used for LXC templates this is very interesting !

Thx

QUOTE:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Jeremy Davis's picture

Hi all, I have recently made some new OVZs (using this method) and uploaded them. I have been having some issues though and from investigation it seems that the firstboot init scripts are causing some issues. The firstboot scripts are running but as they don't appear when you connect to the VM they just sit there running without other services starting. I will do some further investigation and see what we can do. I would also like to try to remove some debris to reduce their size (the kernel is one thing for starters).

I will look to do this soon but if anyone has any ideas I'd love to hear them.

Hans Harder's picture

 

Most simple thing to clean is :

/lib/modules/*    /lib/partman    /lib/firmware/*

saves about 90Mb

 

Where are the firstboot scripts located... ?

I am trying to modify the openvz to lxc, so i am interested in that part

QUOTE:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Jeremy Davis's picture

I have just uploaded a major update of this and have repackaged Adrian's script and the tklovz patch as a TKLPatch itself. This allows for really easy install (although note its a little funky in that it does not allow for uninstall - it needs to be manually removed). Anyway details in the top of the OP.

@Hans - Thanks for your post. As it turns out I discovered the /lib/modules/* /lib/firmware/* locations myself and removed partman altogether (IIRC it's a component of one of the packages I uninstalled). I also removed a few other irrelevant packages and found a couple of other bits and pieces that could go. The TKL Core template is now ~100MB (~60MB less than the ISO & nearly 70MB less than they were).

I have reworked what Adrian did a little and OVZ containers now use the non-interactive default TKL inithook firstboot scripts. The interactive ones were causing issues (because OVZ doesn't have a true console) so I created an initialisation script ('init-ovz') that needs to be run manually (ideally straight after firstboot). This will run all the interactive firstboot scripts.

I don't know much about LXC but I would imagine that the templates created by this shouldn't need too much tweaking. Be great to hear how you go.

[edit] I have just discovered a minor bug in that apt-get autoremove is trying to remove a package 'turnkey-sslcerts' (which possibly should be set to manually installed anyway?). As it waits for input (y/n) it halts the conversion process. This isn't a huge issue and can be easily fixed but I'm not going to worry about it just now.

Adrian Moya's picture

Guys, sorry for being lost, I've been under a lot of work and real-life things, but I promise tomorrow I'll post my tkl2lxc script (which is ready almost a week ago). The script only fails on startup, so maybe combining Jed's work with this script will result in a working script to produce lxc templates from isos.

I'm travelling tonight, I hope as said before to be able to upload this patch tomorrow and maybe Hans can test the script.

Jeremy Davis's picture

As you may have noticed, I have forked your tklovz patch (on GitHub). It still needs some minor work I think: The apt-get autoremove issue I just posted about and also the way I did the firstboot scripts would perhaps be better scripted into the tklovz patch rather than included in the overlay (what do you think Adrian?). Also I think that there is still probably some stuff I could get rid of (still some cruft in there and some of the packages that I set to manual install may not be needed).

All in all though I'm quite happy with it!

Also I've been thinking that it'd be nice to have this packaged as a .deb (allow for easy install and removal) and I was thinking of including it in my (as yet unused) PPA. Any thoughts on that?

Good to have you back Adrian :)

Hans Harder's picture

Looking forward to that script, because I am completely stuck at the moment

I extracted the openvz core to an rootfs directory for lxc, made a manual config for it and adapted the etc/network/interfaces to a static address within my host bridge address range (also static)

Removed the ntp, rsync and webmin from the rc[0-6].d directories to get minimal services started.

chrooted into the rootfs and set the root password

seems I have problems with tty's & pty,'s  I get :

root@userver1:/var/lib/lxc/tkl01# lxc-start -n tkl01
 * Starting system logging syslog-ng                                     [ OK ]
 * Starting Initialization hooks             openvt: Unable to open /dev/tty8: Operation not permitted
when I do a ssh into the machine, i get a password prompt but after that my other session gets the output....

hans@userver1:/var/lib/lxc/tkl01/rootfs$ ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 09:46 ?        00:00:00 /sbin/init
root        81     1  0 09:46 ?        00:00:00 /usr/sbin/sshd
root        86     1  0 09:46 ?        00:00:00 cron
root        96     1  0 09:46 ?        00:00:00 /usr/sbin/syslog-ng -p /var/run/syslog-ng.pid
root       121    81  0 09:46 ?        00:00:00 sshd: root@pts/0
root       135   121  0 09:47 ?        00:00:00 -bash
root       233   135  0 09:54 ?        00:00:00 ps -ef
root@tkl01 ~#

the prompt is from the host and the output is from the tkl container... :)

when you uploaded the script I will test it..

QUOTE:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Hans Harder's picture

 

So far so good, I have now a running/working TKLcore in a  LXC container...:)

Seems the problem lies in the conf files in /etc/init

root@userver1:/var/lib/lxc/tkl01# lxc-start -n tkl01
 * Starting system logging syslog-ng                                     [ OK ]
 * Starting Shell In A Box Daemon shellinabox                            [ OK ]
 * Starting webmin                                                       [ OK ]

Ubuntu 10.04.1 LTS tkl01 /dev/console

tkl01 login: root
.....
Welcome to Tkl01, TurnKey Linux 11.2 / Ubuntu 10.04 Lucid LTS
.....
root@tkl01 ~# ps -ef
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 14:02 ?        00:00:00 /sbin/init
root        99     1  0 14:02 ?        00:00:00 /usr/sbin/sshd
root       132     1  0 14:02 ?        00:00:00 cron
root       153     1  0 14:02 ?        00:00:00 /usr/sbin/syslog-ng -p /var/run/
ntp        154     1  0 14:02 ?        00:00:00 /usr/sbin/ntpd -p /var/run/ntpd.
104        218     1  0 14:02 ?        00:00:00 /usr/bin/shellinaboxd -q --backg
104        220   218  0 14:02 ?        00:00:00 /usr/bin/shellinaboxd -q --backg
root       231     1  0 14:02 ?        00:00:00 /usr/bin/perl /usr/share/webmin/
root       237     1  0 14:02 console  00:00:00 /bin/login --
root       251   237  3 14:02 console  00:00:00 -bash
root       285   251  0 14:02 console  00:00:00 ps -ef
root@tkl01 ~# route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.2.0     *               255.255.255.0   U     0      0        0 eth0
default         192.168.2.1     0.0.0.0         UG    100    0        0 eth0

Steps:

  • created a LXC config
  • just unpacked the ovz tar in the rootfs for LXC
  • changes in rootfs/etc/init:
    • rc-sysinit.conf    ->   start on filesystem    (without waiting for lo device)
    • added a console.conf  which respawns exec /sbin/getty -8 38400 /dev/console  
  • Removed Sxxinithooks and Sxxntp from rootfs/etc/rc[0-6].d

Somehow I still get a ntpd started, no idea where that is triggered (yet).    I think I will disable the webmin and shellinabox also,  those can be started when needed...

but I am very pleased.... very

QUOTE:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Adrian Moya's picture

You can grab the script here, and play with it. The problem is the same with init-scripts, I was holding this script until I could solve those, but I've been full with work/real life so I felt it was important to pusblish it and see if others can help two.

@Jed: I didn't notice the fork, at least github didn't send a message, anyway, I'll have to take some time to take a look at what you did, but depending of the amount of changes to inithooks, I think overlaying them it's ok. The fact is I removed proxomox from my home network, and replaced it with openstack. The transition haven't gone smoothly, and I'm currently in the middle of restoring all the services that where running at home, so: I won't be able to test more ovz templates, but I'll be able to test lxc and I think both differ little. 

@Hans, please share your results!

I'll keep reading the forum!

Jeremy Davis's picture

My GitHub fork is here. I have decided to script the firstboot stuff (rather than use an overlay - I think it makes it easier to understand what is going on) and I have just commented out the apt-get autoremove for now. I have just pushed these updates to GitHub (I'm still getting the hang of git and GitHub, but I'm getting there...). Also I haven't updated the download (here) with the new version yet.

FYI what I did to get it to start cleanly was simply to move out all the firstboot scripts and just move back the unproblematic ones (ie non-interactive). I did it that way so it can apply to any and all appliances, regardless of the firstboot scripts it has. See the code here.

Open to suggestions on how to do it better though! :)

Hans Harder's picture

I adapted your tkliso2ovz and merged it with Adrian's lxc script and streamlined it a bit, and  now I have the same one for LXC  tkliso2lxc

Perhaps you can get it  and put it on your GitHub. That way you can generate OVZ and LXC files from the TKL iso's

I think TKL is now the only one which can generate prepared LXC containers... :)

apt-get update
apt-get install tklpatch
wget http://www.atbas.org/TKLiso2lxc0.1.tar.gz
tklpatch-apply / TKLiso2lxc0.1.tar.gz

usage:
tkliso2lxc turnkey-core-11.2-lucid-x86.iso

 

Almost everything is the same, except the init scripts are original and for inithooks I created a interactive.d directory

I think ovz and lxc are almost compatible, so if there are changes in the ovz conf, they probably are needed also in the lxc conf file.


Hans Harder's picture

make that  and it will work :)

wget http://www.atbas.org/tkliso2lxc0.1.tar.gz

QUOTE:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Jeremy Davis's picture

Although the script is mostly Adrian's work. I started it but he got it to work! Then I refined the OVZ conversion patch.

Anyway good work! I haven't got LXC setup anywhere so I can't test but I think it's great.

Hans Harder's picture

Jeremy,

Have you already been trying to make an OpenVZ version of the Debian 12.0rc2 version ?

I was reserving some time next week to try it out for LXC again ...

Should be a bit simpler without the upstart scripts I think.

Perhaps I can combine the OpenVZ and LXC code into 1 script since there are very little differences.

QUOTE:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Hans Harder's picture

ok, I see, the OpenVZ tgz file is now also automatically generated, cool ...

Any differences with the previous one with tklovz. Can you specify what is changed...

 

I will see if I can write a script which takes the tgz OpenVZ version and adapt what is needed for LXC.

more simple that way.

 

 

QUOTE:  ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol

Jeremy Davis's picture

Since official TKL OVZ templates have been released there hasn't been any need. And even when applying patches, I have been patching the templates rather than just creating an ISO and converting it. It's pretty easy, I put intructions on the TKLPatch docs (although it would probably be self-evident to someone such as yourself).

The 12.0rc is available as an offical template too (here).

Perhaps it'd be easier to write a patch to apply to the OVZ template? I actually forked TKLPatch to include the ability to apply patches directly to OVZ templates (as well as ISOs) but after discussion with Alon development on that one stalled (he thought it would be better to just have a separate high level script - which would be much easier and straight forward).

Add new comment