Skip to main content
F
forrie
Known Participant
September 9, 2011
Question

Upgrading FMS software on many Linux systems

  • September 9, 2011
  • 2 replies
  • 773 views

We have several systems, inside and outside (development, test and production), that we need to upgrade FMS on.    Over time, I have found the process utterly cumbersome, prone to errors and time consuming... and outright annoying therefore.   The permissions are never consistent, usually insecure (tmp and other directories world writable), and so on.

I wonder if anyone here has come up with a nifty way to work around this.    For example, our setup is pretty uniform, so it's really unnecessary to do an interactive install all the time -- I could of course strip down the installFMS script, but I don't want to conflict with future changes.

I've also thought about just breaking down and making an RPM for internal use (more work).

Suggestions welcomed.

    This topic has been closed for replies.

    2 replies

    A
    aruser
    Known Participant
    September 9, 2011

    According to Adobe you remove the older FMS install and install the new release. On the CentOS5.6 x86_64 I used tar to harvest the data, sent it to a VM staging server with the new FMS Interactive install and configured it. Then I use the staging server to rsync data to the phycial server. I leave SELinux enabled and chcon the file label context accordingly.

    I just reloaded the server's OS since it required deleting all of the old fms install, it was easier to go at a clean slate. Plus, you can install the newest release of your Linux distro, patch and install.

    It would be nice if you could do a upgrade on the server, instead of rip/replace.

    We use physical servers big cpu's, memory,  2 RAID sets (OS in RAID1),  (/opt - video in RAID10) plus I use the noatime option on the mount point(s).

    Our production VMware environment was not well suited for video, so we purchased physical servers.

    F
    forrieAuthor
    Known Participant
    September 12, 2011

    Our environment consists of several systems in the chain that *cannot* be dynamically imaged or reinstalled on demand; this includes:  production, development and test.   

    Also, I've found some inconsistencies with how the installation handles things, such as if you have your applications located outside the FMS tree, the script (if you read it) happily re-creates things and redoes the *.ini.   In our case, we copy and move back the *.ini and xml to the config tree.

    Reading through the installFMS script and how this is handled, it seems clear it's written by a more Windows-orientated programmer.

    The scipt also doesn't take advantage of a basic Linux command:  "install" which can also correct permissions.

    My method right now is backing up the original tree, installing the new and copying back our configs and apps.  It's a waste of time.   I'm going to try to streamline this either by reducing the install script to something non-interactive, or more painfully an RPM.

    calmchessplayer
    calmchessplayer
    Inspiring
    September 9, 2011

    well if i were  to  do this without  breaking stuff for several hours I would make an image of the production machine then install the Image to a virtual machine. Start chanings stuff and document all the changes I had to make in order to make the "new" system work. As far as doing this so that its not awkward you can see if some neural networks are available to do all the thinking for you. I hate to be mean but are you or do you have an Administrator? Are you scared of Linux? I can upgrade my Linux box in less than a day. What version of Linux are you running? In order to install FMS on Linux for some distros you need a patch. Do you need a patch for your linux distro and version of FMS?

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices