Hello, On Oct 17 11:59 Ladislav Slezak wrote (excerpt):
Dne 17.10.2013 10:40, Johannes Meixner napsal(a):
In particular for SLE it is needed that after a system disaster the new installer can re-create the system on new (compatible) replacement hardware as it was before by using a saved config of the system and deploying one or more backup.tar.gz images that contain the files of the system.
To support this the new installer has to do those steps: 1. Boot New Machine 2. Use given config (i.e. the saved system config) 3. Disk Activation (e.g. special stuff to make SAN accessible) 4. Storage/Partitioning 5. Create filesystems and mount them at the right mount points 6. Deploy the files (i.e. untar backup.tar.gz images)
So far we thought only about Studio images (raw disk images), but support for tar.gz is easy so it could be supported as well.
I would very much appreciate it if the new installer supports deployment via tar.gz.
7. Install bootloader 8. Reboot
Ideally "Deploy the files" should support any mixture of installing RPMs and whatever kind of software packages plus untar backup.tar.gz images so that it would be possible to have only user data in backup.tar.gz but use RPMs for the basic system software and whatever kind of software packages for other software like third-party software.
We did not think about this possibility, but it is an interesting idea to mix both approaches...
Initially the new installer may only support one type of data for deployment, i.e. deployment either by installing RPM packages or by installing an image or by untar of a tar.gz archive. For my particular use case "system recovery" it would be basically sufficient to untar a single tar.gz archive (which means the user must backup all in one single archive). But when the new installer supports each of those types of data for deployment, then - I think - it should be relatively easy to also support any mixture of those types. The precondition is that the deployment step works well separated from the other steps - i.e. that the deployment step can work basically on its own. Then it should be relatively easy to run several deployment steps one after the other. To do this the config file must support to define several deployment steps and the sequence when each step should run. For example (config in XML-like syntax): ---------------------------------------------------------------------- <deployments> <deployment> <deployment_sequence_number>10</deployment_sequence_number> <deployment_data_type>image</deployment_data_type> <image_uri>ftp://server/base_system_image.raw</image_uri> </deployment> <deployment> <deployment_sequence_number>11</deployment_sequence_number> <deployment_data_type>rpm</deployment_data_type> <repositories> <repository>cdrom</repository> <repository>http://server/...</repository> </repositories> <packages> <package>apache2-prefork</package> <package>apache2-doc</package> </packages> </deployment> <deployment> <deployment_sequence_number>20</deployment_sequence_number> <deployment_data_type>tgz</deployment_data_type> <tgz_uri>nfs://server/system_config_data.tar.gz</tgz_uri> </deployment> <deployment> <deployment_sequence_number>20</deployment_sequence_number> <deployment_data_type>tgz</deployment_data_type> <tgz_uri>https://server/user_data.tar.gz</tgz_uri> </deployment> <deployment> <deployment_sequence_number>90</deployment_sequence_number> <deployment_data_type>script</deployment_data_type> <script_uri>/home/admin/install_3rdparty_database.sh</script_uri> </deployment> <deployment> <deployment_sequence_number>91</deployment_sequence_number> <deployment_data_type>tgz</deployment_data_type> <tgz_uri>smb://server/database_data.tar.gz</tgz_uri> </deployment> </deployments> ---------------------------------------------------------------------- This would run the following deployment steps: 1. The basic system gets installed as an image from ftp://server/base_system_image.raw 2. On top of the basic system additional software like Apache gets installed as RPM packages. 3. Deployment steps with same sequence number run simultaneously where one installs system config data (e.g. the Apache config) and the other one installs user data (e.g. home directories) by untar of two tar.gz archives in parallel. 4. On top of that a third party database gets installed by running a script from the admin's home directory. 5. Finally the database data gets installed by untar of a tar.gz archive. As far as I understand your current proposal there is another major difference of my proposal compared to your proposal: In your current proposal one would need to replace the whole deployment step if one needs to do any (possibly tiny) special stuff by running a selfmade script. In contrast in my proposal running a selfmade script would be supported by the deployment module of the new installer. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 16746 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org