Re: [yast-devel] Innovation Time: autoyast and its competition
On Mon, 13 Jul 2020 14:50:26 +1000 William Brown <wbrown@suse.de> wrote:
On 11 Jul 2020, at 07:05, josef Reidinger <jreidinger@suse.cz> wrote:
Hi, this friday I decide to look what competition offers for automated/unattended installation. Here are some of my notes:
Available: debian: https://wiki.debian.org/AutomatedInstallation including FAI ubuntu: kickstart compatibility https://help.ubuntu.com/community/KickstartCompatibility redhat: kickstart https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
Kickstart text file with syntax. Recommended way for creation is cloning of manual installation. Also UI is available, but does not support advanced partitioning and not for everyone. Interesting feature is that kickstart allow to specify on failure script (both user error %onerror and program error %traceback ) which is executed when fatal failure happen. This is often used for debugging and error reporting. Also all pre,post,etc script has option --erroronfail which makes failure of script fatal for whole installation. What I really like about kickstart documentation is that they mention when it is introduced, when it is deprecated and when it is removed for each option. I have to say also that I found kickstart file more readable then autoyast XML. See examples at http://www.stratuslab.eu/fp7/doku.php/tutorial:baseimagecreationkickstart.ht... and I think you get quickly idea what each line means. Kickstart allows composition using including of other files. This is used for dynamic content together with pre script and include of file generated by script. What surprise me that autoyast allows much more schemas to locate its file. E.g. ftp is not supported in kickstart.
kickstart also creates a template in /root from any install so that you can *easily* recreate the system. AutoYAST doesn't do this, and because the syntax is more complex, it's really hard to start with and get a working or reproducable build.
So maybe a start is yast creating a "/root/autoyast.xml" if you want to "recreate" the system the way you built it?
Actually this works in autoyast if product wants to do it by default. It should done for SLE and not done for openSUSE ( product can control it ). And even if product does not create it by default, you can always run `yast2 clone_system` which creates it for you. If it does not work, please report a bug.
FAI https://fai-project.org/ Based on cfengine. Supports also SUSE, but main target is debian. It has also web service ( quite limited ) to generate modified installation image. what is nice that they has users survey publically available. So I see in some of their report that users use it even for SLE, others use autoyast and fai only for debian. would be nice to have similar survey. I would like to play a bit more with FAI, as I see also opportunity to contribute there and help some SUSE/openSUSE users which prefer cfengine.
Visibility of autoyast When I am searching for competition I am also interested how autoYaST is visible: Googling "unattended installation" no chance, "unattended installation linux" nothing, "unattended installation suse" shows finally autoyast. "automatic installation" no chance, "automatic installation linux" autoyast is heavily beaten by fai and kickstart, autoyast is on second page at bottom, "automatic instalation suse" is clear win.
This is probably more a reflection of how autoyast being hard to use today, which makes it so that people don't often use it, leading to lower google search rates.
So making autoyast really really easy to use and configure would probably boost that,
If you have more ideas how to make it easier to use and configurable, do not hesitate to speak to us. Any ideas are welcome ( no guarantee to implement it :)
Hope that helps!
any feedback helps. Josef
I hope you find this useful.
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
-- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 13 Jul 2020, at 19:21, josef Reidinger <jreidinger@suse.cz> wrote:
On Mon, 13 Jul 2020 14:50:26 +1000 William Brown <wbrown@suse.de> wrote:
On 11 Jul 2020, at 07:05, josef Reidinger <jreidinger@suse.cz> wrote:
Hi, this friday I decide to look what competition offers for automated/unattended installation. Here are some of my notes:
Available: debian: https://wiki.debian.org/AutomatedInstallation including FAI ubuntu: kickstart compatibility https://help.ubuntu.com/community/KickstartCompatibility redhat: kickstart https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/htm...
Kickstart text file with syntax. Recommended way for creation is cloning of manual installation. Also UI is available, but does not support advanced partitioning and not for everyone. Interesting feature is that kickstart allow to specify on failure script (both user error %onerror and program error %traceback ) which is executed when fatal failure happen. This is often used for debugging and error reporting. Also all pre,post,etc script has option --erroronfail which makes failure of script fatal for whole installation. What I really like about kickstart documentation is that they mention when it is introduced, when it is deprecated and when it is removed for each option. I have to say also that I found kickstart file more readable then autoyast XML. See examples at http://www.stratuslab.eu/fp7/doku.php/tutorial:baseimagecreationkickstart.ht... and I think you get quickly idea what each line means. Kickstart allows composition using including of other files. This is used for dynamic content together with pre script and include of file generated by script. What surprise me that autoyast allows much more schemas to locate its file. E.g. ftp is not supported in kickstart.
kickstart also creates a template in /root from any install so that you can *easily* recreate the system. AutoYAST doesn't do this, and because the syntax is more complex, it's really hard to start with and get a working or reproducable build.
So maybe a start is yast creating a "/root/autoyast.xml" if you want to "recreate" the system the way you built it?
Actually this works in autoyast if product wants to do it by default. It should done for SLE and not done for openSUSE ( product can control it ). And even if product does not create it by default, you can always run `yast2 clone_system` which creates it for you. If it does not work, please report a bug.
Generally this kind of thing points to an issue in usability called "discoverability". "Can a person find the controls that exist?". I had no idea that yast2 clone_system existed. Certainly, making it by default would be an awesome step forward. Another think that I recall anaconda does (did?) is that it says "a kickstart was created in /root/install.ks" in the post install step somewhere. These both make it easy to find that capability and to work from there.
FAI https://fai-project.org/ Based on cfengine. Supports also SUSE, but main target is debian. It has also web service ( quite limited ) to generate modified installation image. what is nice that they has users survey publically available. So I see in some of their report that users use it even for SLE, others use autoyast and fai only for debian. would be nice to have similar survey. I would like to play a bit more with FAI, as I see also opportunity to contribute there and help some SUSE/openSUSE users which prefer cfengine.
Visibility of autoyast When I am searching for competition I am also interested how autoYaST is visible: Googling "unattended installation" no chance, "unattended installation linux" nothing, "unattended installation suse" shows finally autoyast. "automatic installation" no chance, "automatic installation linux" autoyast is heavily beaten by fai and kickstart, autoyast is on second page at bottom, "automatic instalation suse" is clear win.
This is probably more a reflection of how autoyast being hard to use today, which makes it so that people don't often use it, leading to lower google search rates.
So making autoyast really really easy to use and configure would probably boost that,
If you have more ideas how to make it easier to use and configurable, do not hesitate to speak to us. Any ideas are welcome ( no guarantee to implement it :)
I have lots of ideas and would love to help. As I think of anything I'll let you know. Generally I think (given my background is LDAP) we found in that community that it was really hard for people to get started. There was a lot of confusing language, the tools were cryptic and needlessly complex, and this turned a lot of people off. We want to a lot of effort to improve this in the 389-ds project at least, so that instead of needing an LDIF to create users, there were commands like "dsidm user create" which was much easier to find, and much clearer about what it does (compared to ldapadd -f /some/user.ldif -H ldaps://example.com -x -D 'cn=user' -w ) So what would make it easier to get started? What did you find confusing when you started to work on autoyast? Those things could be hints that help you to find areas to improve. because if you are an autoyast expert, and find something annoying or hard, how would a user feel who doesn't have your knowledge or experience? Of course, without knowing much about autoyast myself my first impressions are: * The config file syntax is really daunting and hard to parse compared to kickstart * It's hard to "inject" an autoyast file into your install process without knowing exactly where to put it. Could the installer prompt you to add an autoyast url early on or similar instead? * It's hard to find the tools to generate an autoyast profile. You might find that if your goal is to make autoyast more usable, it's worth looking into https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things which is equally as applicable to software as physical objects. Anyway, hope that helps :)
Hope that helps!
any feedback helps.
Josef
I hope you find this useful.
Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
— Sincerely,
William Brown
Senior Software Engineer, 389 Directory Server SUSE Labs
— Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (2)
-
josef Reidinger -
William Brown