Server Moves – Time Consuming!

I’ve recently moved server (again).

I’ve had to move between servers for a little while now because of a few issues that were causing software issues.

Those issues have been focused on and solved, however, each time I move server, and begin reconfiguring, I always consider each one could be done a little differently.

Each different software item we run could be configured a little differently for a better result.

It’s seriously an artform, the art of configuring a linux server from scratch.

Of course, I didn’t sit there and manually reconfigure the box each time, that’d be a big waste. Instead, we use the power of scp to copy data over, have all the processes on the server tested and running, implement the configuration files and add the data and let it run, after some testing of course.

Now, each time I do this, not everything works 100%, for example, email might act a little funny, or we’ll lose the ability to receive or make calls.

Actually, just while on that note, I’m “VERY” tired of the inconsistent programming by a particular coder, I won’t name them here, but it’s just “silly”.

For example, the first update, they used a variable like “get-this”, they then changed it in the next version, assumably to make it shorter, to “get”, and this time we fetch the next update, and it’s changed back to “get-this”.

Very much annoying, as if you use a direct call to that, you end up having more issues, like fixing the issue.

I wrote about this a while back, basically, the person should be using an alias to the function, and not simply “renaming”, other coders use the same, and it’s just inconsiderate to be changing it so much.

Anyway, with the move near complete again (and a nice 9days uptime in the data centre! :)), we are on top of it all and screaming along to finding my weekend time free again for OzVoIPStatus maintenance.

I originally planned this weekend for it, however, moving from a underpowered loan server to my beast was much, much more of a priority, and moving a dynamic site like OzVoIPStatus does take a fair bit of thought. It’s not a simple one line command, though, I am sure I could make it so, it takes a fair bit of thought into what part of it slots into what area of move, and basically everything is live before data is even migrated to ensure that we always have the providers monitored, one server is on top of it, the other is getting data and staying up to date, and keeping on top of it.

Eventually the two are split, and we see if the configuration was successful.

Assuming all goes well for OzVoIPStatus, we move on to setting up mail for it, and test that its successful, and eventually we land with the setup configured.

It’s certainly not a walk in the park, and takes a fair bit of time, and in nearly every case, I am sure I could have configured it all differently and got a different result!

As I mentioned earlier, there’s gotta be some sort of artform to it. You really have to find the time each time to manually configure and compile software and optimise it to your requirements, and adjust configuration settings to tweak them to the peak.

That’s not a quick task, and I guess the only thing that can be said is.. Thanks a heap for yum and the open source gurus that will happily compile these packages and a configuration file that makes it simple to configure and tweak each option to your needs.

Trixbox and systems like that just basically have a script that runs (and breaks in several scenarios) after install and writes out configuration the way you want. It’s just another compilation of packages really.

Trixbox could have been better done in my opinion too.

It would have been far easier to not rely on a “trixboxload” folder, and instead, use a repo, then it’s a simple yum install trixbox to get it and all its dependancies. For a CD install, the same thing, just a repo that points at the cd ;).

The script they use is generally buggy from my testing, breaking for various reasons, like yum not installed (the first case ;)), all could be easily checked for and error handled (but its not).

And the other let down for Trixbox: It installs a dang IRCd for no apparent (or related) reason, therefore opening the system to a security exploit, and besides, it takes up resources, needlessly.

Back to the topic: Building a linux server, building a distro, it’s all a very unique artform to get a server from command prompt to your chosen ideal configuration, very fun, if you can find the time.

Enjoy!

This entry was posted in Linux, Random, VoIP. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *