[BlueOnyx:20501] Re: BlueOnyx on Azure

[Group Bluequartz]

Thanks Michael

All very useful.

Actually probably not as difficult as you imagine as the only real issue you have is DHCP and this is not such an issue as you can tell Azure to always give the server the same LAN IP and THEN set the server to not request it and fix it anyway. You just need it when starting the first time.

Jason Ozin


-----Original Message-----
From: Blueonyx [mailto:blueonyx-bounces at mail.blueonyx.it] On Behalf Of Michael Stauber
Sent: 11 January 2017 14:53
To: BlueOnyx General Mailing List <blueonyx at mail.blueonyx.it>
Subject: [BlueOnyx:20500] Re: BlueOnyx on Azure

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
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx