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>
Hi, Frank Steiner wrote:
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.
Cant you do that with <location> ?
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...
Hmm, some external script might do the trick, I will take a look.
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/
This should be possible. You can always create a new source tree a la SLES with your customized packages.
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".
Hmm, yeah, this is a problem. I will take a look, no promises though :)
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...
Its already back :) Check it out on the next release.
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...
Note that you can also use classes. For example in my test env. I keep all partitioning data out of the profile and include them using classes. It works great. This of course combined with rules works also.
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?
I will look into this, no promises though. Should not be difficult to implement.
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...
Complicated, but I will add it to my WISHLIST :-)
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.
Dont understand what you mean here.
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.
nice, added to WISHLIST.
11) A match variable for hostname would be nice. It is available from dhcp, so it would be nice if you could match it.
hmm, I thought it was there already. looking..
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 :-)
Thank you for the this list, such feedback is very important and is always welcome. Anas
cu, Frank
Hi Anas, Anas Nashif wrote:
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.
Cant you do that with <location> ?
sorry, I was not precise here. I meant stuff like this: disk=/dev/sda bios=0x80 disk=/dev/hda bios=0x81 Anyway, there is this other bug I reported back in January which inserts the wrong boot device (hda even if sda was specified), so we have to boot manually once anyway during the installation of our scsi servers :-) It would be nice if that bug would be fixed in the next release...
3) It would be nice if you could include special kernel packages to be used outside of the general package repository, ...
This should be possible. You can always create a new source tree a la SLES with your customized packages.
Ah, ok, I will try this! I missed that this was possible!
5) Please bring back that fstab-search feature :-) It ...
Its already back :) Check it out on the next release.
Cool :-))) Thanks a lot! Will it, by the way, be possible to use the autoyast from SuSE 9.1 for 9.0 e.g.? Or are all the versions tied to their SuSE releases?
6) I would like to specify a rule without condition in rules.xml. Reason is to add a general profile ...
Note that you can also use classes. For example in my test env. I keep all partitioning data out of the profile and include them using classes. It works great. This of course combined with rules works also.
There I have a general problem, because from the online documentation I couldn't figure out how and where exactly I could use classes, especially in rules.xml. I wrote this in the January mail, too, that I could not insert classes anywhere without the xml validator complaining. The website is also not very detailed in this point (combining rules and classes), so I tried to check from the dtd where I could include classes. But the main problem was that when inserted any class in rules.xml, I couldn't validate automatically anymore (we do this always by some scripts before starting an installation). If you could send me an example for classes in rules.xml or maybe your profile example using classes for partitioning data, that would help me lot!
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.
Dont understand what you mean here.
That was connected to point 6) (bad sorting I did there ;-)) Since I wasn't able (or just too stupid :-)) to work with classes in rules.xml, I had to put all the 40 rules for partition matching in the rules.xml itself. You wrote in some older mail on this list that one could use the general include mechanism for xml to include parts of profiles into others, i.e., defining another xml file as entity and including it in the body with &whatever;. I don't remember if that worked for normal profiles, anyway, it does not work for rules.xml because the file to be included is not transfered. So the idea here was just "write some line into rules.xml causing it to include some other rules file". I think if I understand how to use classes in rules.xml, I have everything I need! About all the other points let me just say "thanks a lot" for at considering them, and I will just be happy if some of the features might make it into some release one day :-) 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. *
Frank Steiner wrote:
Hi Anas,
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?
This works now, you can have the scripts anywhere using a new options named <location>. This can a URL supporting http/ftp/nfs just like with the autoyast= option while booting.
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.
This is also available now: something like that would work: profile-@ip@.xml, not profile-$ip.xml as you proposed. Anas
On Tue, 2004-03-23 at 10:46, Anas Nashif wrote:
Frank Steiner wrote:
Hi Anas,
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?
This works now, you can have the scripts anywhere using a new options named <location>. This can a URL supporting http/ftp/nfs just like with the autoyast= option while booting.
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.
This is also available now:
something like that would work:
profile-@ip@.xml, not profile-$ip.xml as you proposed.
Anas
Two questions: 1.) Where are the these two abilities documented? 2.) Is there any way to take this a step farther, and have the ability to reference the return value of a script in the result of the rule? So I could do something like run a script to ask "What is the name of the machine?", and then use the name the user types in to look up the autoyast file under that name. ...sorry this post is a little bit of a repeat of an earlier one of mine... -Bryan
Bryan Fink wrote:
On Tue, 2004-03-23 at 10:46, Anas Nashif wrote:
Frank Steiner wrote:
Hi Anas,
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?
This works now, you can have the scripts anywhere using a new options named <location>. This can a URL supporting http/ftp/nfs just like with the autoyast= option while booting.
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.
This is also available now:
something like that would work:
profile-@ip@.xml, not profile-$ip.xml as you proposed.
Anas
Two questions:
1.) Where are the these two abilities documented?
These abilities are not available to users yet, they will be available with SuSE Linux 9.1/SLES9.
2.) Is there any way to take this a step farther, and have the ability to reference the return value of a script in the result of the rule? So I could do something like run a script to ask "What is the name of the machine?", and then use the name the user types in to look up the autoyast file under that name.
Everything is possible, now however its a bit too late for the upcoming releases. I will note that down and see if it can be implemented for future releases. anas
...sorry this post is a little bit of a repeat of an earlier one of mine...
-Bryan
Anas Nashif wrote:
7) The script feature again: It would be very nice if ...
This works now, you can have the scripts anywhere using a new options named <location>. This can a URL supporting http/ftp/nfs just like with the autoyast= option while booting.
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.
This is also available now:
something like that would work:
profile-@ip@.xml, not profile-$ip.xml as you proposed.
pretty cool :-) This will make our organisation of the next installation (starting with SLES 9, following SuSE 9.1) a lot easier! Thanks a lot! Best regards, 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
participants (3)
-
Anas Nashif -
Bryan Fink -
Frank Steiner