Hi Henning!
>> But the basic-installed systems wasn't installed using FAI.
>
> That's not necessary for softupdates.
No, but I *want* it to have been installed by FAI. The whole point here
is to have identical (well, at least similar) installations of Debian
across servers rented from different DCs.
> No problem, softupdate can manage other systems as well :)
Well, yes, but you're right, that's not the point here. Though I'd doubt
the usefulness of FAI for an RPM based distro or for Gentoo, but again,
let's stay on topic here.
> Apart from this being an interesting problem, to solve, I wonder if it
> would simpler to force customers to rent th Server from a set of
> known-working providers that fullfill some requirements - developing
> something that works with every random system can become very
> expensive - either for you or for the customers.
It would definitely make a nice idea for (... insert your favorite root
server provider here, such as H....r, S....o, ...) to allow you a way to
control their PXE environment. It wouldn't be rocket science at all if
they would allow you to upload a PXE config into their TFTP server which
matches the MAC address of the server they rent to you and there you'd
be. But they don't. (Anyone from those companies on this list?)
We rent servers based on price / performance. There are companies who
give you servers for a monthly rent where we ourselves would need to
calc twice the amount just for the deprecation of the hardware, not even
thinking of Internet connection, power, etc.
You can rent rackspace with some companies and put your own servers
there, but then again, you end up with very unattractive prices. In
other words: The one-off effort to do what I am doing here right now
pays off the more servers you rent for 1/2 or 1/3 of the monthly price
which you otherwise would have to put up.
But in order to have the widest possible choice of rented servers to
achieve the best price performance possible, you need to find ways to
make work what they give you rather than having to go with the one or
two providers who give you what you might want and having to accept
their prices.
It remains also the problem of being able to switch. A provider might go
off business; this has happened more than once, for whatever reason.
Having our own FAI based automated setup on servers which we purposely
source from at least two different rental companies of which we know
that one is not a reseller of the other one, if one of them goes out of
business we still have to other one and we can exchange any of them
against a new one.
It's a bit OT but we currently develop some hot failover clustering
setup which will work on 39 EUR / month root servers rented from any
company anywhere in the world.
That much about the commercial background.
I think I will put my technical remarks into a separate email.
Regards,
Torsten
Henning Sprang schrieb:
Torsten Schlabach wrote:
But the basic-installed systems wasn't installed using FAI.
That's not necessary for softupdates.
It needs an
entirely new partitioning of the hard disk,
so you want to wipe the whole system anyway. O.K.
it might have an entirely
different kernel than what we want to install,
You can install another one
it might not even be
Debian yet.
No problem, softupdate can manage other systems as well :)
But anyway, I now understand, you want to do something different than I
propose, but also kexec seems not to be what you need - kexec just
changes the kernel, but keeps all processes and stuff runnning, it
doesn't boot from scratch, doesn't it? (at least that is what I
understand what it's made for).
So, you say the main problem/change for you now is that FAI doesn't have
a special kernel anymore.
But you can do exactly the same with the normal debian kernel. It can
boot from nfsroot just as the special FAI kernel did, and it should be
possible to give the required kernel parameters on the grub command line
- just as you did before with the special FAI kernel.
Only that the normal debian kernel also needs an initrd. But when
booting it via grub that is even easier than with PXE.
Did you try this already before trying kexec?
Another idea might be to run the provider's rescue system and try to run
setup-storage directly from there.
But you seem to have a very heterogeneous environment, and cannot rely
on anything.
Apart from this being an interesting problem, to solve, I wonder if it
would simpler to force customers to rent th Server from a set of
known-working providers that fullfill some requirements - developing
something that works with every random system can become very expensive
- either for you or for the customers.
Henning
