You are here
Rik Goldman - Thu, 2010/04/01 - 21:58
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.
Forum:
You're still a bit confused
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:
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'?!?
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:
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...
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:
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?
Add new comment