> On 13 Jul 2020, at 19:21, josef Reidinger <[email protected]> wrote:
>
> On Mon, 13 Jul 2020 14:50:26 +1000
> William Brown <[email protected]> wrote:
>
>>> On 11 Jul 2020, at 07:05, josef Reidinger <[email protected]> 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/html/installation_guide/sect-kickstart-howto
>>>
>>>
>>> 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.html
>>> 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: [email protected]
>>> To contact the owner, e-mail: [email protected]
>>>
>>
>> —
>> 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: [email protected]
To contact the owner, e-mail: [email protected]
