Re: [suse-autoinstall] Dynamic changes in autoYast control file (Not through rules)
On 20 Jun, Alexander Dubinin wrote:
Idea is to generate swap partition size automatically, using script. Does I have possibility to start some script _before_ autoyast config file is processed?
The pre scripts are run after the xml file has already been assembled AFAIK.
Preferable is a way, similar to used in RedHat KickStart - run pre-configuration script, generate partition layout and pass this layout to AutoYast like "include" in KickStart.
You can already do this using rules and classes instead of specific xml
files. See http://yast.suse.com/autoinstall/9.1/html/rulesandclass.html
example of what I'm doing...
<rule>
<disksize>
<match>/dev/hda 10000</match>
Hi Michael,
The way, you proposed to do is wery well known, but it doesn't work in
my case (As I wrote below - I can't use rules :)
Biggest problem is what rules processing fixed only to
"rules/rules.xml" file, it doesn't work for autoYast control file. It
would be nice to use rules/classes constructs, but...
I can't use anything but autoyast control file - no any directory for
rules/rules.xml, etc.
AutoYast control file in my case is generated automatically by CGI
script (Depending on information in database for specific host), and
it need to be changed a little depending on specific part of hardware
configuration.
Best way is to do it like in RedHat - where pre-script can generate
some files for future use by installation process (Partition table,
for example)..
Is there something like this?
How can I use XML XInclude to include file, generated by "pre" scripts?
It was mentioned in FAQ for SLES8, but not working for SLES9...
It's really bad if SuSE installer missing such great functionality...
Regards,
Alexander
2005/6/20, Michael Marion
On 20 Jun, Alexander Dubinin wrote:
Idea is to generate swap partition size automatically, using script. Does I have possibility to start some script _before_ autoyast config file is processed?
The pre scripts are run after the xml file has already been assembled AFAIK.
Preferable is a way, similar to used in RedHat KickStart - run pre-configuration script, generate partition layout and pass this layout to AutoYast like "include" in KickStart.
You can already do this using rules and classes instead of specific xml files. See http://yast.suse.com/autoinstall/9.1/html/rulesandclass.html
example of what I'm doing...
<rule> <disksize> <match>/dev/hda 10000</match>
greater </disksize> <disksize> <match>/dev/hdb 10000</match>greater </disksize> <result> <profile>dideab.xml</profile> <continue config:type="boolean">false</continue> </result> </rule>That rule matches dual IDE disks, installed as hda and hdb (I have a similar rule for hda and hdc). Then the dideab.xml (or dideac.xml if hda and hdc) file is just the partitioning bit.
A custom example is...
<rule> <custom1> <script> <![CDATA[ #!/bin/sh PATH=/bin:/sbin:/usr/bin:/usr/sbin if [ -n "`grep site= /proc/cmdline`" ] then echo -n `cat /proc/cmdline | sed -e 's/.*site=//g' -e 's/ .*//g'` else echo -n sandiego fi ]]> </script> <match>*</match>
exact </custom1> <result> <profile>@custom1@.xml</profile> <continue config:type="boolean">true</continue> </result> </rule>This allows us to pass a site (for remote offices) on the boot line and load the file <site>.xml. In that file, we have the pre/chroot/post install scripts for looking at the local site's NFS installation path. Then we have a generic file that lists all the packages to install, which is the same for everyone..
It's a little confusing at first, but once you get how the rules/classes work, it's pretty slick.
-- Mike Marion-Unix SysAdmin/Staff Engineer-http://www.qualcomm.com Jimmy: "The job market is very competitive right now for someone with my skills! ...There are a whole lot of kids on summer vacation." -- The PJs.
-- Regards, Alexander Dubinin
On Tuesday 21 June 2005 01:16, Alexander Dubinin wrote:
Best way is to do it like in RedHat - where pre-script can generate some files for future use by installation process (Partition table, for example).. Is there something like this?
well actually rules would be the way to go but since you can't go that way (I'm not so sure if I understand why) you can go the dirty way of modifiying your profile by a pre script. Your profile is under /tmp/profile/... do whatever you want to do with that file in a pre-script and save the modified version in "/tmp/profile/modified.xml" The profile will be read again then after the pre-script has finished.
How can I use XML XInclude to include file, generated by "pre" scripts?
how would that help you? If you have an XInclude in the profile, all XIncludes will be read together with the rest of the profile at once. The pre script is in the profile too and if you modify an XInclude file, it will not help, since the XInclude files have already been read. You can modify it but it will not be read again. I hope you understand the problem with your suggestion.
It was mentioned in FAQ for SLES8, but not working for SLES9...
you can do XIncludes of course but it does not help in your situation. -- ciao, Uwe Gansert Uwe Gansert, Server Technologies Team SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nürnberg, Germany e-mail: uwe.gansert@suse.de, Tel: +49-(0)911-74053-0, Fax: +49-(0)911-74053-476, Web: http://www.suse.de
Hi Uwe, Yes, this is much more interesting! Thank you for answer! Seems like exactly what I need :) I may describe, why rules are not suitable. Only one reason - because these need directory structure for work, and fixed filename. I use automatic OS provisioning system, which generates configuration file (from template) and uses parameters from database - like NIS server, Install path, packages, etc. So, the only thing I passing to SuSE installer kernel is "autoyast=http://.../gettemplate.cgi install="nfs://..." This script generates RH KickStart, Debian, FreeBSD or autoYast - whatever you want - configuration file automatically - depending on which OS should be deployed. This is why it's not possible to use directory structure for making rules.xml and related fles. BTW, I can use XInclude to get more files from same generator, but some options about system configuration need to be passed back to it, to generate correct content. Hope, that way, you proposed, will work :) Really, nice to see it more "oficially" documented, or see some way to force second pass of processing XML control file after pre-scripts. Can I just add XInclude to /tmp/profile/modified.xml ? Will it be processes again? Or I should add already prepared XML code? BTW - will see it in next hour ;) Thanks a lot! -- Regards, Alexander Dubinin
participants (3)
-
Alexander Dubinin -
Michael Marion -
Uwe Gansert