Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Making KVM reinstalls less painful?
New on LowEndTalk? Please Register and read our Community Rules.

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?

raindog308raindog308 Administrator, Veteran

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.

«1

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!

  • rskrsk Member, Patron Provider

    dd an image over rescue system?

    Thanked by 1vpsGOD
  • rskrsk Member, Patron Provider

    Other option is a preconfigured netinstall

    Thanked by 1yomero
  • ihadpihadp Member
    edited October 2016

    @rsk said:
    dd an image over rescue system?

    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.

  • AnthonySmithAnthonySmith Member, Patron Provider
    edited October 2016

    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.

    title CentOS 6 VNC Installation
            root (hd0,0)       
            kernel /centos6/vmlinuz vnc vncpassword=houseoflinux headless ip=10.0.0.10 netmask=255.255.255.0 gateway=10.0.0.1 dns=10.0.0.5 ksdevice=eth0 method=http://mirror.centos.org/centos/6/os/x86_64/ lang=en_US keymap=us
            initrd /centos6/initrd.img
    

    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.

    Thanked by 2ipasces6 deadbeef
  • @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).

  • raindog308raindog308 Administrator, Veteran

    geekalot said: 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 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.

    Thanked by 1Jacob
  • @raindog308 said:

    geekalot said: 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 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 (?)

    Thanked by 1raindog308
  • PXE requires DHCP which requires a LAN. DHCP over WAN is not good.

  • ipasces6ipasces6 Member
    edited October 2016

    @raindog308 said:

    Is there any way to speed up or automate KVM installs? Before you answer:
    .
    ...
    .
    onto the VPS, and then ansible can come along and fix it up.

    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/

  • raindog308raindog308 Administrator, Veteran

    geekalot said: Check out this link for example -- I don't think the boot URL is limited to a local subnet (?)

    It looks like a 2-step...do your DHCP and then run iPxe somehow. A custom ISO would solve both I suppose...interesting.

    ipasces6 said: 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.

    Now that I think about it...that's kind of the way I shim OpenBSD onto DigitalOcean:

    • boot any OS
    • download OpenBSD miniroot.fs
    • dd it (overwriting the running OS)
    • power cycle
    • and I'm in the OpenBSD installer

    In theory I could do the same here...

  • Awmusic12635Awmusic12635 Member, Host Rep
    edited October 2016

    For our KVM we just made our own templates with proxmox

  • geekalotgeekalot Member
    edited November 2016

    @raindog308 said:

    geekalot said: Check out this link for example -- I don't think the boot URL is limited to a local subnet (?)

    It looks like a 2-step...do your DHCP and then run iPxe somehow. A custom ISO would solve both I suppose...interesting.

    ipasces6 said: 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.

    Now that I think about it...that's kind of the way I shim OpenBSD onto DigitalOcean:

    • boot any OS
    • download OpenBSD miniroot.fs
    • dd it (overwriting the running OS)
    • power cycle
    • and I'm in the OpenBSD installer

    In theory I could do the same here...

    @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:

    • assign a static IP/netmask/gateway/etc
    • boot Debian installer (or other installers) of my choice from my remote HTTP on nginx
    • You can check out key parts in the documentation, here
    • So this does work over HTTP
  • raindog308raindog308 Administrator, Veteran

    geekalot said: @raindog308, I just wanted to followup on this, after some basic testing:

    Wow, thanks for coming back - I will check that out!

    Thanked by 1yomero
  • @raindog308 said:

    geekalot said: @raindog308, I just wanted to followup on this, after some basic testing:

    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:

    1. I have a standard "image" (which is just an rsync backup of a "templatized" VPS) that I keep.

    2. 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.

    3. 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)

    4. 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 said:
    My (ducking here) low end solution to the problem:

    1. I have a standard "image" (which is just an rsync backup of a "templatized" VPS) that I keep.

    2. 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.

    3. 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)

    4. 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:

    • This assumes you "trust" the pre-installed OS
    • And regarding trust, you would have to spend some time removing packages that were included in the pre-installed OS that are not required (or desired) in final setup
    • This would not accommodate, for example, setup of encrypted filesystem (which is a requirement for every VPS I run)
    • It would not make it easy to downgrade from Jessie to Wheezy, for example. (There are some use cases to want to do this).
    • It would be difficult to use this migrate from 64bit to 32bit

    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

  • @geekalot said:

    @nullnothere said: [snipped]

    @nullnothere, yes, this can work, however, if I understand your methodology correctly:

    • This assumes you "trust" the pre-installed OS

    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.

    • And regarding trust, you would have to spend some time removing packages that were included in the pre-installed OS that are not required (or desired) in final 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.

    • This would not accommodate, for example, setup of encrypted filesystem (which is a requirement for every VPS I run)

    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)

    • It would not make it easy to downgrade from Jessie to Wheezy, for example. (There are some use cases to want to do this).

    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).

    • It would be difficult to use this migrate from 64bit to 32bit

    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 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.

    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? :)

  • mailcheapmailcheap Member, Host Rep

    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.

  • @geekalot said:

    @raindog308 said:

    geekalot said: 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 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 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.

    Thanked by 1geekalot
  • @nullnothere said:

    @geekalot said:

    @nullnothere said: [snipped]

    @nullnothere, yes, this can work, however, if I understand your methodology correctly:

    • This assumes you "trust" the pre-installed OS

    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.

    • geekalot dons his tinfoil hat ..... and a sense of reality before responding ..... :)
    • Actually, more of a concern with OpenVZ, IMHO (where the host creates the template and has oversight/easy intrusion capabilities into your instance). I only use KVM VPS, due to encrypted filesystem requirement.
    • And regarding trust, you would have to spend some time removing packages that were included in the pre-installed OS that are not required (or desired) in final 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.

    • OK
    • This would not accommodate, for example, setup of encrypted filesystem (which is a requirement for every VPS I run)

    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)

    • Yes, I understand about "anyone who has access to the host node" deal. But it definitely helps to greatly limit unauthorized access sensitive data. I actually encrypt all my dedi's and colo's now as well. I no longer have VPS, dedi, or colo that are not encrypted.
    • It would not make it easy to downgrade from Jessie to Wheezy, for example. (There are some use cases to want to do this).

    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).

    • OK. I've run into situations where the host was unable or unwilling to setup a standard (Debian, Ubuntu) iso for whatever reason. (Not because it was "old" either).
    • It would be difficult to use this migrate from 64bit to 32bit

    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.

    >

    • OK

    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.

    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.

    • You're welcome and agreed. This is how technical discussion on LET should be, IMHO.

    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).

    • As I mentioned above, everything I use now is running encrypted FS (including the host nodes running virtualization). It works great and has been super reliable! I do this on multiple kidchires all the way up to large servers. I understand the hit on performance, but protection of my data, and my customer's data, is more important to me. I am under no delusions of grandeur that this is impenetrable ... I just realize that it will need to take some skill and some time; and may require an organization that has a lot of resources. If executed properly, this should hopefully mitigate "casual" data theft at a DC at the server level. (And, yes, I know I have to provide the passphrase via SSH; but if that is borked, then I know I've done everything I can possibly do to protect the data-at-rest).

    Corrections and feedback welcome!

  • @onionnu said:
    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.

  • raindog308raindog308 Administrator, Veteran

    nullnothere said: When I get a new VPS, I request for whatever Debian image they have. Once the VPS is up

    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.

    Thanked by 1geekalot
  • @geekalot said: [various bits and pieces - snipped for readability]

    • Actually, more of a concern with OpenVZ, IMHO (where the host creates the template and has oversight/easy intrusion capabilities into your instance). I only use KVM VPS, due to encrypted filesystem requirement.

    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.

    • Yes, I understand about "anyone who has access to the host node" deal. But it definitely helps to greatly limit unauthorized access sensitive data. I actually encrypt all my dedi's and colo's now as well. I no longer have VPS, dedi, or colo that are not encrypted.

    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)

    • OK. I've run into situations where the host was unable or unwilling to setup a standard (Debian, Ubuntu) iso for whatever reason. (Not because it was "old" either).

    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.

    • As I mentioned above, everything I use now is running encrypted FS (including the host nodes running virtualization). It works great and has been super reliable! I do this on multiple kidchires all the way up to large servers. [...]

    >

    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...

  • @nullnothere said:

    @geekalot said: [various bits and pieces - snipped for readability]

    • Actually, more of a concern with OpenVZ, IMHO (where the host creates the template and has oversight/easy intrusion capabilities into your instance). I only use KVM VPS, due to encrypted filesystem requirement.

    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.

    • Yes, using LUKS for encryption.
    • Passphrase provided manually over SSH during the boot process (using dropbear/busybox) ... see example link below.
    • No automation. Manual boot. Monitoring servers notify if system goes down, manually provide passphrase over SSH.
    • Only time I have configured "automatic"/keyfile was for low risk data ("linux ISO's") using a random 4K+ sequence from a USB drive ... really just for a proof of concept.
    • Yes, I understand about "anyone who has access to the host node" deal. But it definitely helps to greatly limit unauthorized access sensitive data. I actually encrypt all my dedi's and colo's now as well. I no longer have VPS, dedi, or colo that are not encrypted.

    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)

    • Nothing automatic & sexy unfortunately -- just manual SSH via dropbear/busybox.
    • A useful link for you is here
    • 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.

      • OK. I've run into situations where the host was unable or unwilling to setup a standard (Debian, Ubuntu) iso for whatever reason. (Not because it was "old" either).

      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.

    • 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)

    • As I mentioned above, everything I use now is running encrypted FS (including the host nodes running virtualization). It works great and has been super reliable! I do this on multiple kidchires all the way up to large servers. [...]

    >

    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.

    • Wow, now you are really going deep lol. There is always a way around every security mechanism. I am simply trying to protect against the "average" opportunist attacker and when shipping servers, so I am willing to make some compromise on edge cases (based on what is important to me).

    Thanks and looking forward to more details...

  • 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').

Sign In or Register to comment.