• Visitors can check out the Forum FAQ by clicking this link. You have to register before you can post: click the REGISTER link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. View our Forum Privacy Policy.
  • Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Linux upgrades (openSuSE) question

Collapse
X
  •  
  • Filter
  • Time
  • Show
Clear All
new posts

    Linux upgrades (openSuSE) question

    So time for a technical question, a bit long winded I'm afraid...

    I have a number of customer systems which are running openSuSE versions 11 and 12 which need to be upgraded to 13.2. These systems have been specially configured to run certain piece of software so they are highly configured and although the base is the same, they do have a number of files which are specific to that customer. The problem is, is that you cannot do an upgrade from any version prior to 13.1 to 13.2 which makes it rather difficult. I have procedures in place to back up their data (the system is basically two parts, OS with applications and data) and to backup their OS/application section and luckily it seems that most systems have a primary partition which is the same size. Each customer is different so my plan is to somehow create a 'golden master' which can then be cloned for each customer as I have a script which they'll initially run and that sends their system information to an FTP server.

    My first thought was to get the customers to install autoyast2, run it, send me the XML and I could build a customised DVD which would basically install 13.2 with all their customisations. That has been thrown out for a number of reasons as (a) I need as little as possibly user (read customer) manual interaction and (b) I forgot, some of the systems are RedHat

    I'm now looking at using susestudio which looks to be nearly the answer apart from you can only define the disks using LVM which I don't but could be taken into account plus a few other little bits and pieces. I can create a 'golden master' and then clone it so that the ISO is customised per customer (such as data, networking, etc.) but there is still some manual interaction (and I can't get it to fully work!)

    What would be nice, would be to create a local iso and then clone that with all customisations but that looks like a non-starter...

    I do have another alternative and that is to go onsite and do it all but I'm ruling that out as they're spread across the globe.

    So my question(s) are, has anybody done something like this before or any ideas, pointers, etc. Many thanks for all your knowledgeable answers in advance
    Brexit is having a wee in the middle of the room at a house party because nobody is talking to you, and then complaining about the smell.

    #2
    So what is presenting the problem? Could you install the base OS and then use Puppet (or similar) to push out the app and data? That way when a new OS comes along, you just reclone, register the nodes and puppet does all the work for you?

    Or do you want a product to install the OS too? Any reason that it has to be multiple OSes? Could you standardise on one?
    And the lord said unto John; "come forth and receive eternal life." But John came fifth and won a toaster.

    Comment


      #3
      Had a similar issue with the lack of in-place upgrade on RHEL, and we found we could do the upgrade, via a frig documented on t'internet, but Redhat warned us that if they discovered we'd done it they wouldn't support us if issues, so we did it the hard way.

      I'm not sure if OpenSuse is to Suse what Centos is to Red Hat (idk) but if it's not vendor supported might be worth a punt.

      A good kickstart file can do 99% of the work, I prefer xCAT (100% free) for this, steep learning curve but it does multi-OSes too like AIX, Solaris and also physicals, LPAR, LDOM, nPar, vPAR and well as Zones/containers, WPAR, HPVM, etc...

      Haven't got a proper answer tho

      Comment


        #4
        Originally posted by b0redom View Post
        So what is presenting the problem? Could you install the base OS and then use Puppet (or similar) to push out the app and data? That way when a new OS comes along, you just reclone, register the nodes and puppet does all the work for you?

        Or do you want a product to install the OS too? Any reason that it has to be multiple OSes? Could you standardise on one?
        Looked at that but its no good for what I need. Firstly it would require the customer to install something and then configure it and secondly I have no access to most of these systems. They're already running our application but need to upgrade the OS for the newest version of the software and because you can't do an OS upgrade in place you basically need to do a re-install.
        Brexit is having a wee in the middle of the room at a house party because nobody is talking to you, and then complaining about the smell.

        Comment


          #5
          Originally posted by stek View Post
          Had a similar issue with the lack of in-place upgrade on RHEL, and we found we could do the upgrade, via a frig documented on t'internet, but Redhat warned us that if they discovered we'd done it they wouldn't support us if issues, so we did it the hard way.

          I'm not sure if OpenSuse is to Suse what Centos is to Red Hat (idk) but if it's not vendor supported might be worth a punt.

          A good kickstart file can do 99% of the work, I prefer xCAT (100% free) for this, steep learning curve but it does multi-OSes too like AIX, Solaris and also physicals, LPAR, LDOM, nPar, vPAR and well as Zones/containers, WPAR, HPVM, etc...

          Haven't got a proper answer tho
          Sadly there isn't one for SuSE and tools like xCAT (I use something similar called WAVV) are no good as the systems are all standalone. You could think of it as 25 odd standalone systems worldwide which I have no access to which need the OS, which is in the primary partition, to be upgraded and then the data restored back into the secondary partition. This means the install ISO has to have all disk partitions defined to it, all networking (every system is different), all desktop configurations, all customer defined configuration scripts, parameters and files, the rather special software installed along with a few 3rd party products (i.e. RAID manager) and so on. In other words a live Linux CD which is created just for that customer and where they basically just have to insert it, and maybe click a few buttons or answer a couple of questions and it installs everything, once complete, they're back up and running.

          I do something similar for their backups where I just dd the primary partition to an external USB drive and to restore they just boot from a live CD and dd back in again...
          Brexit is having a wee in the middle of the room at a house party because nobody is talking to you, and then complaining about the smell.

          Comment


            #6
            It's been a couple of years since I tried SuseStudio but it didn't manage to build me a working system, which rather put me off.

            Another option is to grab the Suse 13.2 image building kit, Kiwi, which can be found in the GUI version of Yast via Software Management.


            kiwi - KIWI - Appliance Builder

            The KIWI Image System provides an operating system image builder for Linux supported hardware platforms as well as for virtualization and cloud systems like Xen, KVM, VMware, EC2 and more. The online documentation can be found here: doc.opensuse.org - Documentation Guides & Manuals

            The 13.2 documentation was something of a mess. I have copies of a previous version of documentation in PDF format which work fine for all but the recently changed stuff.

            Problems I've had with openSuse 13.2:
            • Is btrfs ready for production yet? The system partition is set up as btrfs by default. That's fine for playing at home but for end user systems I'd play safe and go for XFS.
            • Yast got rewritten in Ruby for 13.n. There are still some oddities in there. Specifically it decided that the IP address range 172.16 - 172.31 range actually stopped at 172.19. Might have been fixed by now, dunno, I went for DHCP anyway.
            • I came across what can best be described as schizophrenia wrt Python 2 vs Python 3 . The version of LibreOffice which comes with 13.2 has a dependency on Python 3, so remove Python 3 and it will remove LibreOffice as well.


            Oh, the sodding games. With the Gnome flavour if you remove the games they simply come back.

            With the KDE version I couldn't find a way to change the layout of the console keyboard from US English. I don't normally give in so easily, but this one had me beat. Not a big deal here, but that's going to be a problem for anyone with different keyboards.

            I did download the Kiwi kit but another project became a higher priority, so I haven't had the chance to test it out.
            Last edited by Sysman; 28 May 2015, 08:55.
            Behold the warranty -- the bold print giveth and the fine print taketh away.

            Comment


              #7
              What a bag of tulip! Kiwi and the autoyast components just don't work, having tried every which way but loose I've come to the conclusion that no-one has actually used it nor tested it. Anyway I've managed to get 2 solutions, the first is to create a system on a server here and customise for a customer, dd it to a flash drive then they can boot from a live CD and dd from the flash drive. Not ideal as they'll have to do a number of manual customisations themselves. The second was quite nice, using autoyast2 I can create a reference profile which is in XML format and heavily customisable so I can create the networking, partitioning, etc. per customer and then put it on a USB stick. When they boot they just point the boot options to the USB stick and the XML file and it does it all automatically. We'll see how it goes, thanks for the feedback
              Brexit is having a wee in the middle of the room at a house party because nobody is talking to you, and then complaining about the smell.

              Comment

              Working...
              X