Virtualising a 3.2 Server .

First of all - all suggestions gratefully accepted.

This site has a 1999 Intel server running 3.2. I have replaced the RAID drives over the years but the OS is still original (internal network). The database running on the server although not supported is still required. The server hardware will eventually give up.

There is an ESXi 5 server to mount a VM if I can virtualise the server.

Thank you.
 
Sorry, 3.2 went end-of-life eons ago. That means it's unsupported.
 
@SirDice: no offense but you sound like one of them support people trying to sell the latest and grates.

That being said, even if 3.2 is way off, maybe he can try a few things like dump/restore or something else (maybe install version 9 and try to move the db alone).
 
Even if it's only on an internal network that 3.2 server is a huge security risk. I'm quite sure the database software that's running on it is just as old. Creating another huge security risk. It's basically an accident waiting to happen.

Dump 3.2 and migrate to a recent and supported version.
 
Hack it, publish its data on pastbin, blame someone else. With such an old system it won't be that hard.

Sit back, relax, and watch all those managers freaking out. Then tell them, "I told you so!" :OO
 
This goes a bit offtopic, but who do you think they will "politely" ask to fix it and who do you think they will blame for "not being secured properly"?

I've seen it quite some times and it's ugly, because the bottom line is that they do not understand and they live on another planet where they speak another language (maybe I'm too pessimistic :P).

Why not ... do it :D
 
SirDice said:
Hack it, publish it's data on pastbin, blame someone else. With such an old system it won't be that hard.

Sit back, relax, and watch all those managers freaking out. Then tell them, "I told you so!" :OO

I think that I first mentioned that technique! I am not claiming copyrights though :e
 
da1 said:
This goes a bit offtopic, but who do you think they will "politelly" ask to fix it and who do u think they will blame for "not being secured properly"?
Show them the email you sent years ago warning about it, and the reply from management not to bother :e

I;ve seen it quite some times and it;s ugly, because the bottom line is that they do not understand and they live on another planet where they speak another language (maybe I'm too pessimistic :P).
Yeah, I've been there too. It's quite hard to quantify risk. Try to do so anyway. Show them how much money it's going to cost when it all goes belly up and how much money they need to spend to get it back on track. That's the only language they understand.
 
SirDice said:
Show them how much money it's going to cost when it all goes belly up and how much money they need to spend to get it back on track. That's the only language they understand.

True.
 
Thank you guys - I appreciate your thoughts and also your concerns (noted). The company that was in charge of managing the server software went away. The main request is that I keep the database (Mumps based) intact. I think the integration of the data with the core programming is tight so just pulling the database section of the OS would be beyond my scope.

I would like to virtualise the server and then I could safely work with a copy of it. What would be your thoughts on using a cloning tool to do this?

Regards
 
Touchwood said:
Thankyou guys - I appreciate your thoughts and also your concerns (noted). The company that was in charge of managing the server software went away... The main request is that I keep the database (Mumps based) intact. I think the integration of the data with the core programming is tight so just pulling the database section of the OS would be beyond my scope.
I would like to virtualise the server and then I could safely work with a copy of it. What would be your thoughts on using a cloning tool to do this.

Regards

At this point this will be your only option. Have a look at g4u, it is a rather good open source utility that might help.
 
Touchwood said:
Thank you guys - I appreciate your thoughts and also your concerns (noted). The company that was in charge of managing the server software went away. The main request is that I keep the database (Mumps based) intact. I think the integration of the data with the core programming is tight so just pulling the database section of the OS would be beyond my scope.
You might want to try a fresh install of a recent FreeBSD release (8.3 or 9.0) on a spare system. According to the SourceForge project page, "This version of mumps runs on all FreeBSD Versions 3 through 9, many linux versions and OSX 10.4, 10.5, 10.6 and 10.7 in 32 bit mode (intel)."
 
You also have the option to run the VMware bare metal virtualization disc (VMware cold clone?). Boot from disc, and it will suck in the machine into vCenter. I'm not sure how well it works with RAID controllers, but it is certainly worth a shot.

Of course as stated it is not a supported OS any more, but you already know that...

If I was you, i'd suck the machine into a VM, clone it, spin up a copy in a test environment and try to upgrade it. If you can upgrade it, woohoo. If you can't, well at least you tried.

And yes, I'd certainly give a document (hard copy they can file, not email, and keep a copy yourself) to management outlining the risk, the lack of support availability for when it DOES go pear shaped, and perhaps a list of known vulnerabilities in the 3.2 release.

Essentially, if they decide to keep running this old, no longer supportable, legacy app on a known-insecure environment despite your advice to the contrary, there's nothing more you can do.

Attempting to recover from this being hacked should be in your DR planning - if there is no recovery option then it would be negligent to continue running it, and management need to be (officially) aware of that.
 
I'd download a 3.2 ISO from the FreeBSD archive first. Install it in your vmware space, with the same filesystem layout and partitions. See first if that works. If it does, you could boot it in single user mode, and then copy all the data from the physical machine to the vm (you could use tar/nc for that, or scp, or backup/restore). Reboot it and see if all daemons start. If they do, swap IP adresses, and you should be in business.
 
Thanks guys - you have given me plenty of scenarios to work with.
Goodbye weekend hello FreeBSD docs.
I really do appreciate the excellent feedback.
"SirDice" "ThroAU" -Security well noted and actioned - this morning server's CAT cable no longer connected to the switch.
"gkontos" - Trying G4U (Ghost for Unix) - Copy option.
"frijsdijk" - Got hold of an original Walnut Creek 4 Disc CDROM set of 3.2 (June 1999). Good suggestion.
"Terry_Kennedy" - If above works and I have a working copy, will play with that idea. Hadn't considered Mumps options.
"wblock@" - Will look at clonezilla docs as well. Looked at the dump and restore docs last night.

If I missed someone, apologies. Will let you know how it all works out.
 
Back
Top