TKLPatch and LAMP Appliance | TurnKey GNU/Linux

I am not easily overcoming my lack of understanding of TKLpatch. What I'm trying to do at this point is add Samba to the LAMP appliance. Ultimately, I'd like to also add webmin-samba.

However, when I use the example patch, Drupal5, as a model, I get nothing. More frustrating - when I use the Drupal5 patch, I'm not getting anything. I missing a step, perhaps? Do I have to download the debs manually? If so, how do I do that?

What I can do:

sftp the ISO

Extract the ISO

Chroot and tool around the ISO manually, modify usage.txt, populate var/www.

Generate an ISO and sftp it out of the virtual machine

What I can't seem to do: anything in need of a repository.

Any help is appreciated.

Replies (3)

You're still a bit confused

Reply 1 2010-04-01

There seems to be a persistent misconception on your end that is confusing you on what needs to be done. That may be a product of confusing documentation so I updated the patch development page to try and explain things a bit more clearly. Thanks for the feedback!

Anyhow, tklpatch allows you to apply a "patch" to an ISO to create a new ISO. You don't need to chroot the ISO manually AT ALL. If you do chroot and change the contents of the filesystem that WONT create a tklpatch. A patch is a directory structure which includes a compact set of instructions / files which you can post on the forums here and share with others. That's easier and more transparent than sharing the entire ISO. Take a look at some of the other tklpatches (e.g., OpenVPN) that have been created for reference.

Try this:

tklpatch-example helloworld
tklpatch turnkey-core.iso helloworld

This will create an example "helloworld" patch which instructs tklpatch to install the "hello" package (which prints hello world).

What do you mean ' not everything can be made into a patch'?!?

Reply 2 2013-01-09

You're obviously not trying hard enough!! :p

But seriously, if you have a look at the TKLPatch documentation you can see that the tklpatch command h (like all good Linux software) is a top level script that calls other modular scrpts that:

extract the iso
apply the patch (basically a bash install script and/or a collection of files to overlay on the default filesystem) using a chroot
regenerate an iso

The patch is a nice way of doing it as it can be easily used by others, but if you'd rather do it yourself and not share, then there is not reason why you couldn't just call the indivdual scripts one at a time (and do everything you wish manually).

Yeah that's cool...

Reply 3 2013-01-09

I have used 're-mastering' before, but more for desktop systems rather than servers. Although even that I have given up on because they tend to bloat a fair bit over time, and unless you do them really regularly in my experinece the idea is often much better than the reality... But each to their own...

As for your points above:

TKLBAM would be a better disaster recovery solution IMO (although may be impractical for all the images as well)
TKLPatch patches the ISO so installation to differeing hardware is no issue (other than if the hardware isn't supported by the original ISO - although you could patch it to solve that potential issue...)
There are better ways around that IMO - such as an apt-proxy or even just using squid (a proxy for pretty much whatever you want...)

To go back to your origanal point though (building an 'all-in-one' type appliance) personally I prefer to virtualise. I am a big fan of Proxmox (includes both KVM - for Windows and other OS; and OVZ - for Linux inc TKL). There is some degree of redundancy, but I'm fine with that, and if most of your servers are Linux then OVZ is incredibly lightweight (the PVE devs claim that there is only a 1-3% performance hit vs hardware - I can't vouch for that, but it is pretty much like running on hardware!). The beauty of it is that if something goes really pear-shaped with a VM then you only lose that function - not everything. Also it gives me the confidence to tinker more - knowing that I'm not going to bring down the entire infrastructure because I mussed something up...

As for specifics - I haven't yet had any joy getting FOG to run in OVZ although I have read that it is possible. I currently have it running as an OVZ, but I have a 2nd intance running in KVM just as a storage node (it's the NFS that causes the issues with OVZ). I did create a FOG TKLPatch some time ago, but I recently tried it (for the above setup) and it was a bit of a fail... IRC I never got it completely polished for TKL v11 (which was Ubuntu based) and it certainly didn't 'just work' with v12 (Debian based)... But it may be of some use to you as a starting point?