Hi Anas,
following is a list of feature request (yes, a lot :-))
that we missed during installing a very heterogenous network
of 60 hosts with SuSE 9.0. Maybe some of them can make into
the next version :-)
1) One cannot specify the disk option for lilo.conf. This is
very bad if you have a host with scsi and ide disks and want
to boot from the scsi disk.
2) You cannot take over the paket selection that is saved from
yast2 as selection file for autoyast. They are incompatible
and must be edited manually. Main difference seem to be the
version numbers in the file saved from yast2, while autoyast
only uses the paket names without versions. Maybe one can
add an option in yast2 to save paket selection for autoyast.
Usually when you get a new SuSE version, you edit the paket
selection on a test host with yast2, save it, and then want
to insert it into your autoyast files...
3) It would be nice if you could include special kernel
packages to be used outside of the general package repository,
just like you could in autoyast1. That's because we often
change the kernel to be used to the latest release from SuSE,
but we would like to keep our install source unchanged, i.e.,
keep the 1:1 copy from the DVD as install source and just
add a special kernel in some other directory. This was nice
how it was done in autoyast1/
4) Something like this would be nice in rules.xml:
<karch>
<operator>or</operator>
<match>k_deflt</match>
exact
</karch>
<karch>
<operator>or</operator>
<match>k_athlon</match>
exact
</karch>
<result>...</result>
for e.g. selection the same kernel package for k_deflt
and k_athlon architectures. But it is not possible,
because one cannot specify <karch> twice with "or".
5) Please bring back that fstab-search feature :-) It
was one of the most powerful things autoyast1 could
do. Now I have to create a partition profile for
each host from the existing fstab (we have about
20 different partition configurations) and add all
of them info the rules file. To tell autoyast
"leave everything as it was if you find a fstab
and just format / and /boot" was a great feature...
6) I would like to specify a rule without condition
in rules.xml. Reason is to add a general profile
from which all hosts start, and then add extension
by testing certain conditions. But for a starting
profile, no condition is needed. This would also make
it easier to keep the profiles small. You could have
a profile file containing all the scripts, one for
all the network stuff, and then just add a few profiles
in rules.xml without condititions. Sth. like
- add general profile
- add scripts profile
- add network profile
- now start to add some stuff conditionally...
7) The script feature again: It would be very nice if
you could find a way to allow external scripts to be
called directly from autoyast. This would help, because
now you write post-install scripts, test them, edit them,
then insert all the code into an xml file. Now, sth.
goes wrong, you test again, and now the danger is that
the script code in the xml file and the external script
get inconsistent easily. Autoyast1 user to have that $I-
Variable, pointing to the install source, so we just
had created a SCRIPTS subdirectory unter the suse dir from
the install source, and called all the scripts from there.
Would it be difficult to add such a reference variable/tag
in autoyast2, too? So that you can do anything on the
install source, like call the scripts?
8) When using several profiles in rules.xml, it would be
nice if you could specify in every profile (or with
every tag) what should be merged and what should be
overwritten. Sometimes you might want to redefine the
whole <network> section, sometimes you might only
want to add a second interface. So, e.g. sth. like
<networking>
<redefine>
<dns>
...
</dns>
</redefine>
<add>
<interfaces config:type="list">
<interface>
..
</interface>
</interfaces>
</add>
</networking>
should overwrite *all* dns specications used before,
but *add* the interface specifications to all the
interface stuff defined before. This would be very
powerful, but I guess it would be hard to implement...
9) An easy way to add general includes would be nice. The
entity include mechanism does not work in rules.xml.
As we have to specify about 40 partition rules (depending
on the IP and the type), we would like to use a separate
file for this and include it to keep rules.xml small.
10) It would be nice if the value matched in a <match> tag
in rules.xml could be referenced in the result section.
Then one could e.g. match the IP in the match tag and
use "profile-$ip.xml" as result. So with one rule you could
add a special profile for each host by just adding
a file "profile-xxx.xxx.xx.xxx.xml" in the profile subdir.
11) A match variable for hostname would be nice. It is available
from dhcp, so it would be nice if you could match it.
Yes, I know, a long list :-)) However, it is not that we don't
like AY2 here at all ;-) It resolved many of the problems that
we had with AY1 and we really like the new features. However,
some of features above would greatly enhance it :-)
cu,
Frank
--
Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/
Lehrstuhl f. Bioinformatik Mail: http://www.bio.ifi.lmu.de/~steiner/m/
LMU, Amalienstr 17 Phone: +49 89 2180-4049
80333 Muenchen, Germany Fax: -4054
* Rekursion kann man erst verstehen, wenn man Rekursion verstanden hat. *
