[BlueOnyx:20500] Re: BlueOnyx on Azure

[Michael Stauber]

Hi all,

> https://azure.microsoft.com/en-gb/marketplace/?term=centos
> 
> It would be interesting to see what the take up would be if BlueOnyx 
> made itself available on this platform. On paper it is not hard.
> It just needs a couple of libraries added and the ability to start up
> using dhcp

Generally: Installing BlueOnyx 5209R via the instructions outlined at
http://www.blueonyx.it/index.php?page=5209r-manual-install is pretty
seamless and straightforward.

But DHCP is a definite problem. BlueOnyx usually needs static IP's and
has constructors that parse and also write the network configs on CCEd
init or during setup.

So you will run into this situation:

You boot your standard CentOS (off DHCP) and it's fine. You install
BlueOnyx via the above method and eventually get it running. You go to
the GUI for the first time to do the initial setup. Which will save your
network config. So you then have the DHCP obtained IP's statically
written into your network config. It'll still work at this point.

But during the next boot you might not have network anymore, as the DHCP
obtained previous IP is no longer available as it has been assigned
elsewhere and you were expected to get a new one during this boot.

Now there is one work around which is not documented:

When you install BlueOnyx 5209R via the instructions above the first
thing you *need* to do before you get started is this:

touch /etc/is_aws

That creates an empty file which the network constructors and handlers
look for. If they find this file, the network config will *never* be
rewritten by the GUI or CCEd.

That way you can get BlueOnyx working under DHCP. You still will be
faced with another challenge:

The Vsites need static IPs. Say your DHCP obtained IP is 192.168.10.1
and you create some Vsites on it. Your Cloud provider has a NAT in place
which maps your public IP to this private one. So first time around
it'll work just fine.

During the next reboot your new DHCP obtained private IP is 10.1.128.10.
Your server has inherited this IP automatically by DHCP - no problem.
But all your Vsites are still configured on the IP 192.168.10.1 which
you had before.

As that IP is no longer available to you, Apache won't start, as it
cannot bind to that IP. So you need provisions in place which
automatically change the IP's of all Vsites to the IP obtained from DHCP
during every startup of the BlueOnyx VPS.

This is somewhat trivial and we do have a command line Perl script which
can do that: /usr/sausalito/sbin/MassIPChange.pl

But you'd need to make sure it runs every startup by turning it into a
constructor or calling it elsewhere. It gets worse if you run your own
DNS on the BlueOnyx. Because then you'd have to update all DNS records, too.

Long story short: It can be done, but requires extra effort and extra
work arounds. It'll also have a negative impact on your peace of mind,
because every reboot will have you gnawing your nails, as you're never
sure if your band-aids are still holding up. That'll make it a bit
questionable if it's really worth the cost savings of moving to Azure or
any other Cloud provider who requires these dirty little hacks.

My recommendation: Better opt for a solution where BlueOnyx runs out of
the box without compromises and hacks. On the cheap you can easily run
BlueOnyx under OpenVZ, as we do have detailed provisions for this
already built in from day one and even provide OS templates for it with
BlueOnyx preinstalled.

Lastly another piece of advice: I played around extensively with AWS as
one large client had pressured me into providing BlueOnyx images on AWS
a couple of years ago. It cost me around three months of my life that
I'd like to have back, because it was a pretty frustrating endeavour.I
got it working by throwing a ton of work arounds onto the problem, but
in the end there was one catch which never could get fully worked out:
The way AWS boots "instances" (that's how they call their VPS's) is
pretty intricate and sometimes OS related YUM updates of my modified
CentOS "instance" would mess with it and break it. If and when that
happened, you were screwed and only detailed inside knowledge about how
to mount a non-working instance as file are into another working VPS
would allow you to fix it - if you knew what to do. Even then there was
never a guarantee that the next OS update wouldn't break it yet again.

The kicker of course being: Tech support? For this particular problem?
You get the canned answer that "support for non-standard images is not
provided." Boom, headshot.

So whatever solution you choose: You need a "Plan B" that includes
working backups at the absolute minimum and preferably also expert help
that covers your particular scenario. If you skip one or the other, then
you may end up in a pretty undesirable situation.

-- 
With best regards

Michael Stauber