All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Making KVM reinstalls less painful?
I've grown addicted to the test/reinstall/test/reinstall cycle that is possible with providers like DO or Vultr. Both offer a "click to reinstall" feature, or heck you can do it with an API call probably.
However, I still love my old LEB providers with their Solus and such. There, I have to mount the CD and then go through...every...screen...of...the...Debian...installer...and typing in netmasks and saying no to the popularity contest and deselecting print server is just not much fun anymore. It probably wasn't fun ever.
Is there any way to speed up or automate KVM installs? Before you answer:
I know some providers have templates, but mine don't have Deb 8 x64
I know about ansible, et al. and that's the first thing I do...but I still need to have a basic OS to run my ansible against.
Not every provider allows a custom ISO.
Tn theory I could install over pxe or something, but that would mean having another VPS on the same LAN, and I don't in many cases. Not all providers offer private networking.
OvZ is so much easier to use in this regard, alas...or am I missing something obvious? I just want to blast an bootable image onto the VPS, and then ansible can come along and fix it up.
Comments
Maybe find another LEB/LET provider?
I realize many (most?) simply download the available templates from SolusVM's repo (which hasn't been updated in over a year, maybe longer), but there has to be at least a couple whom know how to build their own templates, its not exactly rocket science.
Time to step your game guys!
dd an image over rescue system?
Other option is a preconfigured netinstall
I don't believe SolusVM has any built in rescue system, however if the provider allows you to boot a live disk it may be a good viable solution. Install Debian 8, get it all setup and then create a DD image using SSHFS to a remote box.
The big issue with the LEB hosts using solusvm, myself included is that we are fairly restricted by an absolutely dog shit template management system.
In principal if your host was willing they could simply make a template/media group for you, let you do a base line install via ISO, then create a KVM template from it and put it in your media group so it is only available to you.
While this sounds simple it is an administrative overhead that could very quickly get out of control.
@solusvm confirmed that they officially stopped maintaining their own templates 2 years ago https://tdn.solusvm.com/ it bothers me that most of the templates on there are broken or have security issues and despite reporting it a year ago they have done nothing to even remove them.
the only other solution I can come up with for you which is a bit outside the box is baseline an install, pack it up, host it somewhere as a network install and use any old template initially, modify grub to pull/start a network install.
CentOS example, I am sure it can be modded for deb.
I know a few customers use a similar method to get around the super basic xenpv implementation.
The steps to make a template for ovz or kvm are actually really simple, solusvm missed a trick by not enabling it for customers who could have bought or been given a few GB of extra space to store their own user driven templates.
@raindog308 we seem to investigate similar things at similar times...
I think one way to do it is via gPXE boot (https://en.wikipedia.org/wiki/GPXE). It seems that Solus KVM's have it available at boot -- it allows you to PXE boot via HTTP which is potentially very interesting.
I have not had time to play with this enough myself or to fully confirm functionality, but it looks like in theory you could boot from HTTP sitting on any network and potentially setup any OS you need.
It sure beats waiting on an ISO image mount (which I have had some providers take days to do).
I think you're thinking "HTTP = any web server in the world". I don't think that's the case here. I think they mean "if you don't want to use TFTP you can use HTTP" but it's still on your local LAN.
I could be wrong but I think if we could do PXE over the Internet, lots of people would be doing it already.
You may well be right; I really haven't had time to investigate, but really need to.
Check out this link for example -- I don't think the boot URL is limited to a local subnet (?)
PXE requires DHCP which requires a LAN. DHCP over WAN is not good.
It depends a little bit on the limitations you can accept. If you are just looking for a clean state and can live with half your disk space, installing once and saving (DD) the root/boot partition would get you there. VNC console needed, of course.
Edit: Reread the other posts and looks like most of us are proposing similar solutions.
Edit: Wouldn't debian installer let you use a kick-start to preseed the answers?
iPXE anyone?
ipxe.org/
It looks like a 2-step...do your DHCP and then run iPxe somehow. A custom ISO would solve both I suppose...interesting.
Now that I think about it...that's kind of the way I shim OpenBSD onto DigitalOcean:
In theory I could do the same here...
For our KVM we just made our own templates with proxmox
@raindog308, I just wanted to followup on this, after some basic testing:
Using iPXE (a fork of gPXE; available in Proxmox, for example, as a network boot option), I was able to:
Wow, thanks for coming back - I will check that out!
It is really sweet, because you could boot a script .... which may address your desire for automation.
This is nice!
My (ducking here) low end solution to the problem:
I have a standard "image" (which is just an rsync backup of a "templatized" VPS) that I keep.
When I get a new VPS, I request for whatever Debian image they have. Once the VPS is up and assuming the image is OK and I can SSH in, I just rsync the backup from the remote instance locally (to some temp folder), and then nuke the local VPS from the local rsync template. This nicely gets rid of systemd and other nuisances and I get to start with a nice clean (and pure without systemd - no I'm NOT interested in a vim-vs-emacs-vs-systemd-vs-sysvinit war here) Debian 8 instance.
Pretty much everything else is "automatic" (except for the special settings for the new IP/Hostname that the VPS needs tweaked) (it's an image that has all that I need and it doesn't change too often barring apt-get updates)
After the reboot (assuming I had no typos etc. with the IP), things just work and I'm in business with other non standard customizations I may need for the VPS.
I assume between 2 and 3 is where ansible/puppet/chef/pick-your-poison can take over and do things your way.
@nullnothere, yes, this can work, however, if I understand your methodology correctly:
I am not trying to rain on your great suggestion, I am just highlighting use cases where I don't this technique be the best approach. However, If your use case can utilize this approach, it is fast and simple.
Cheers
Yes (esp. for OpenVZ where I don't think there are any other options). For KVM, I understand this concern and I agree that, as you point out, there are probably other ways of getting a better/more trusted base OS setup.
I wipe everything (except /proc, /sys etc.). So there's no need to remove packages etc. The new (overwritten) files are the state of the OS packages et al.
Yes. I'm kind of iffy on the whole encrypted FS for a VPS. Anyone who has access to the host node, probably has ways of getting into the guest OS when it is running (or so me thinks) - so I'm not really gung ho about this. But for a VPS at rest, this is obviously a great help and prevents nefarious data access. So this covers stupidity/mistakes from the provider but certainly not the someone-evil-with-3-letters-is-out-to-get-you (in which case, I think there are far bigger problems to worry about). (as an aside why is it that globally all the evil-watchers-for-want-of-a-better-term use only 3 letter abbreviations)
My image is what I want (i.e. standard - Jessie in my case). So I don't want Wheezy by default (any more - though I had a similar Wheezy image sometime back).
Correct. Again, I currently have a few templates like this but it shouldn't be hard to setup one (personal) template and have it use 32/64 bit as needed. Rather than go the route of setting up a fresh instance and get all the packages etc. via whatever tool, I've just decided I'll maintain a few images that I use mostly and just rsync it to destination VPS as needed and go from there.
I fully agree - and I enjoy this kind of open discussions - that's how all of us get ideas from one another and I've certainly learnt a lot by just observing/reading from what everyone does (and I have miles to go before I sleep...)
Thanks.
And perhaps you could share your thoughts on the encryption bits - if it's not too much effort (and a performance penalty), I'll definitely consider it as well even though (I believe it doesn't really buy you running-VPS security).
Corrections and feedback welcome!
Tried ProxMox?
With OpenStack gaining traction among LEB providers it will be easy to offer these features; would be nice if everyone could pool in and make a list of current offerings.
PXE is DEFINETLY bootable over http. Subnet doesn't matter at all(anymore than it does for normal browsing). Done it many a times. Is really quite neat for testing out random distro's. As long as the PXE client itself supports HTTP transfer, it shouldn't be a problem.
http://ipxe.org/ <- can be booted from floppy, usb, cd, or grub. And can chain a configuration file with ip configuration, and/or with hardcoded http address for fetching linux to install.
oh, and i'm way too late, someone tested. ignore me.
>
No worries, it is what we are discussing after I confirmed it via some basic testing. Definitely useful stuff.
But see my problem is between those two sentences. Most Solus shops, if you request a VM, they have very limited set of templates and you use the installer for the rest. The installer is the pain part. Once a box is answering SSH, it's easy to use ansible or something to get it square away, but getting to that point in a lot of places requires clicking through the Debian installer, partitioning disks, selecting packages, etc. Very manual.
I suppose I could install on of the templates and then rsync as you suggest, but that'd be installing Deb 7 for example and then rsyncing Deb 8...sounds like a recipe for problems.
Understood.
How do you boot the VPS (or dedis) though - I assume it'll wait at some stage for a password to decrypt the FS (also, are you using LUKS or something else - details please!) - so how do you automate a reboot to get back to running stage? Key file (without password) implies no real security.
Again - some details on what you use and how you manage to boot without user intervention will help understand the setup better to see if I can use any of your techniques (more for learning/best practices rather than necessity at this stage)
Happens all the time and it's not even "standard" across hosts (even though it may all come from SolusVM for OpenVZ) - which is why I gave up working with what they provide and just put together my own so that it is at least consistent and saves me the hassle to get every VPS to reasonably uniform state.
>
On my (personal) machines, I've not (yet) found a reliable/foolproof/secure way to boot the machine (without signed UEFI etc.) - so in theory even though my volumes are encrypted, someone could modify the boot loader, log my keystrokes, potentially wipe traces of intrusion/interception prior to boot completion and I really wouldn't be any the wiser. I need to do something like write a compiler to compile the compiler using the said compiler which doesn't (yet) exist.... it's getting to be a nice recursive problem with serious philosophical overtones but I digress.
Thanks and looking forward to more details...
What you should find comforting about this is that it (encrypted fs) is very reliable -- I have servers with 400+ day uptimes at Online.net, for example running Proxmox on encrypted fs. So, encryption has come a long way.
Agreed. Autonomy and initiative over delays and support tickets. (Not dissing hosts, but just saying sometimes you have a tight window to get something done)
i like dhcp and pxe to run a local install NOT using any HTTP/FTP (not reliable, even local) so a full package iso/image with minimal packages (apt/yum, system required to full hardware support and ssh essentially) being installed.
As last step write a script to set the IP assigned on next boot static (or use real DHCP with public IPs - installer ideally on other bridge but DHCP MAC limited is fine by KVM security, better solution but more work in ways), if using same bridge replace DHCP data to public (or internal if NAT), schedule disk resize to full dev size on reboot, reboot, done.
My primary extended version pulls a script by the MAC from a server at end by HTTP/FTP and just let the user input what to run (essential 'user-files').