[yast-commit] r65274 - in /trunk/autoinstallation/doc: ./ images/src/ misc/ xml/

Author: ug Date: Mon Aug 8 14:12:13 2011 New Revision: 65274 URL: http://svn.opensuse.org/viewcvs/yast?rev=65274&view=rev Log: changed to file structure of the documentation Added: trunk/autoinstallation/doc/images/src/ trunk/autoinstallation/doc/images/src/EPS (with props) trunk/autoinstallation/doc/images/src/PNG (with props) trunk/autoinstallation/doc/images/src/WEB (with props) trunk/autoinstallation/doc/xml/ trunk/autoinstallation/doc/xml/ASKSection.xml trunk/autoinstallation/doc/xml/BootMedia.xml trunk/autoinstallation/doc/xml/BootloaderSection.xml trunk/autoinstallation/doc/xml/CreateProfile.xml trunk/autoinstallation/doc/xml/CreateProfileDetails.xml trunk/autoinstallation/doc/xml/FilesSection.xml trunk/autoinstallation/doc/xml/GeneralSection.xml trunk/autoinstallation/doc/xml/Installation.xml trunk/autoinstallation/doc/xml/Introduction.xml trunk/autoinstallation/doc/xml/KDumpSection.xml trunk/autoinstallation/doc/xml/LDAPSection.xml trunk/autoinstallation/doc/xml/MailSection.xml trunk/autoinstallation/doc/xml/Makefile trunk/autoinstallation/doc/xml/Makefile.am trunk/autoinstallation/doc/xml/Makefile.in trunk/autoinstallation/doc/xml/NFSSection.xml trunk/autoinstallation/doc/xml/NISSection.xml trunk/autoinstallation/doc/xml/NTPSection.xml trunk/autoinstallation/doc/xml/NetworkInstallation.xml trunk/autoinstallation/doc/xml/NetworkSection.xml trunk/autoinstallation/doc/xml/PartitioningSection.xml trunk/autoinstallation/doc/xml/PrinterSection.xml trunk/autoinstallation/doc/xml/Profile.xml trunk/autoinstallation/doc/xml/ReportSection.xml trunk/autoinstallation/doc/xml/RulesAndClasses.xml trunk/autoinstallation/doc/xml/RunlevelSection.xml trunk/autoinstallation/doc/xml/ScriptsSection.xml trunk/autoinstallation/doc/xml/SecuritySection.xml trunk/autoinstallation/doc/xml/SoftwareSection.xml trunk/autoinstallation/doc/xml/SoundSection.xml trunk/autoinstallation/doc/xml/SysconfigSection.xml trunk/autoinstallation/doc/xml/UsersSection.xml trunk/autoinstallation/doc/xml/X11Section.xml trunk/autoinstallation/doc/xml/advanced.xml trunk/autoinstallation/doc/xml/appendix-rules.xml trunk/autoinstallation/doc/xml/appendix2.xml trunk/autoinstallation/doc/xml/autoyast.xml trunk/autoinstallation/doc/xml/bin (with props) trunk/autoinstallation/doc/xml/catalog.xml trunk/autoinstallation/doc/xml/creating_autoyast2_modules.xml trunk/autoinstallation/doc/xml/entities (with props) trunk/autoinstallation/doc/xml/examples (with props) trunk/autoinstallation/doc/xml/images (with props) trunk/autoinstallation/doc/xml/linuxrc.xml trunk/autoinstallation/doc/xml/multiplesource.xml trunk/autoinstallation/doc/xml/purpose.xml trunk/autoinstallation/doc/xml/web (with props) Removed: trunk/autoinstallation/doc/ASKSection.xml trunk/autoinstallation/doc/BootMedia.xml trunk/autoinstallation/doc/BootloaderSection.xml trunk/autoinstallation/doc/CreateProfile.xml trunk/autoinstallation/doc/CreateProfileDetails.xml trunk/autoinstallation/doc/FilesSection.xml trunk/autoinstallation/doc/GeneralSection.xml trunk/autoinstallation/doc/Installation.xml trunk/autoinstallation/doc/Introduction.xml trunk/autoinstallation/doc/KDumpSection.xml trunk/autoinstallation/doc/LDAPSection.xml trunk/autoinstallation/doc/MailSection.xml trunk/autoinstallation/doc/NFSSection.xml trunk/autoinstallation/doc/NISSection.xml trunk/autoinstallation/doc/NTPSection.xml trunk/autoinstallation/doc/NetworkInstallation.xml trunk/autoinstallation/doc/NetworkSection.xml trunk/autoinstallation/doc/PartitioningSection.xml trunk/autoinstallation/doc/PrinterSection.xml trunk/autoinstallation/doc/Profile.xml trunk/autoinstallation/doc/ReportSection.xml trunk/autoinstallation/doc/RulesAndClasses.xml trunk/autoinstallation/doc/RunlevelSection.xml trunk/autoinstallation/doc/ScriptsSection.xml trunk/autoinstallation/doc/SecuritySection.xml trunk/autoinstallation/doc/SoftwareSection.xml trunk/autoinstallation/doc/SoundSection.xml trunk/autoinstallation/doc/SysconfigSection.xml trunk/autoinstallation/doc/UsersSection.xml trunk/autoinstallation/doc/X11Section.xml trunk/autoinstallation/doc/advanced.xml trunk/autoinstallation/doc/appendix-rules.xml trunk/autoinstallation/doc/appendix2.xml trunk/autoinstallation/doc/autoyast.xml trunk/autoinstallation/doc/autoyast2-8.1.txt trunk/autoinstallation/doc/catalog.xml trunk/autoinstallation/doc/creating_autoyast2_modules.xml trunk/autoinstallation/doc/linuxrc.xml trunk/autoinstallation/doc/misc/ trunk/autoinstallation/doc/multiplesource.xml trunk/autoinstallation/doc/purpose.xml Modified: trunk/autoinstallation/doc/Makefile.am Modified: trunk/autoinstallation/doc/Makefile.am URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/Makefile.am?rev=65274&r1=65273&r2=65274&view=diff ============================================================================== --- trunk/autoinstallation/doc/Makefile.am (original) +++ trunk/autoinstallation/doc/Makefile.am Mon Aug 8 14:12:13 2011 @@ -4,133 +4,7 @@ # $Id$ # -SUBDIRS = autodocs images entities bin components examples xsl +SUBDIRS = xml autodocs images entities bin components examples xsl htmldir = $(docdir)/html -xml_file = autoyast.xml -xml_files = $(wildcard *.xml) - - -EXTRA_DIST = $(xml_files) $(wildcard *.xsl) web/default.css - -CLEANFILES = .html.sum profile.dtd.xml elements \ - elements.xml elements.ent profile.dtd.xml examples.ent\ - components.ent .ps.sum autoyast.out autoyast.pdf autoyast.fo \ - images.ent - -STYLESHEET_CSS = default.css - -html_DATA = $(wildcard html/*.html) \ - html/index.html \ - html/yast2docs.css \ - html/default.css - -#doc_DATA = autoyast.pdf - -components: components.ent - bin/components.sh noref > components.ent - -examples: examples.ent - bin/examples.sh > examples.ent - -html/index.html: autoyast.xml - XML_CATALOG_FILES=@XML_CATALOG@ \ - time -p @XSLTPROC@ --xinclude \ - -stringparam chunk.fast '1' \ - --stringparam html.stylesheet $(STYLESHEET_CSS) \ - @STYLESHEET_HTML@ autoyast.xml - XML_CATALOG_FILES=@XML_CATALOG@ \ - time -p @XSLTPROC@ --xinclude \ - -stringparam base.dir 'html/devel/' \ - -stringparam chunk.fast '1' \ - --stringparam html.stylesheet $(STYLESHEET_CSS) \ - @STYLESHEET_HTML@ creating_autoyast2_modules.xml - cd html/devel; \ - ln -s ../default.css ./default.css; \ - ln -s ../images ./images - cd ../.. - -html/index.html: autoyast.xml - XML_CATALOG_FILES=@XML_CATALOG@ \ - @XSLTPROC@ --xinclude @STYLESHEET_HTML@ \ - $< - -#autoyast.fo: autoyast.xml -# XML_CATALOG_FILES=@XML_CATALOG@ \ -# @XSLTPROC@ @XSLTPROC_FLAGS@ --xinclude \ -# -o $@ @STYLESHEET_PDF@ $< - -#autoyast.fo: autoyast.xml -# saxon -o autoyast.fo autoyast.xml @STYLESHEET_PDF@ - -#autoyast.pdf: autoyast.fo -# fop -q $< $@ - -autoyast.xml: images.ent examples components - -html/yast2docs.css: html/index.html - cp @STYLESHEET_CSS@ html - cp -a $(ydatadir)/docbook/images html - -html/default.css: html/index.html webimages - cp web/default.css html - -images.ent: - @make -r -C images/WEB -f makefile.ent ima - -: images.ent chunks webimages - - -webimages: - mkdir -p html/img - cp -a images/WEB/*png html/img - - -.PHONY: images examples.ent components.ent - -images: images/EPS/* images/PNG/* - @if ! [ -e "img" ]; then \ - mkdir -p img; \ - fi - @if ! [ -e "img/Makefile" ]; then \ - ln -s ../images/makefile.images img/Makefile; \ - fi - - @echo "generating PNG files for all outputs..."; - @if [ "$(IMAGES)" = "all" ]; then \ - rm -f img/*.{png,pdf}; \ - fi; - - @for j in `bin/findImages.sh` ; do \ - if [ -e "images/EPS/$$j" ]; then \ - source="images/EPS/$$j"; eps="1";\ - elif [ -e "images/PNG/$$j" ]; then \ - source="images/PNG/$$j"; eps="0"; \ - fi; \ - dest=`echo "img/$$j" | sed -e "s|_|-|g;s|.eps||g;s|.png||g;"`; \ - if [ -e "$$source" ]; then \ - if [ ! -f $$dest".png" ] || [ $$dest".png" -ot $$source ]; then \ - if [ $$eps == "1" ]; then \ - echo " converting $$source -> $$dest'.pdf'"; \ - bin/epstopdf12 -o=$$dest".pdf" $$source; \ - echo " converting $$source -> $$dest'.png'"; \ - convert $$source $$dest".png"; \ - else \ - echo " linking $$source -> $$dest'.png'"; \ - convert -depth 8 $$source $$dest".png"; \ - fi; \ - fi; \ - fi; \ - done - @make -r -C img ima - - -install-data-local: - install -d -m 755 $(DESTDIR)$(htmldir) - cp -a $(srcdir)/html/images $(DESTDIR)$(htmldir) - cp -a $(srcdir)/html/img $(DESTDIR)$(htmldir) - cp -a $(srcdir)/html/devel $(DESTDIR)$(htmldir) - -clean-local: - rm -rf html Added: trunk/autoinstallation/doc/images/src/EPS URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/images/src/EPS?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/images/src/EPS (added) +++ trunk/autoinstallation/doc/images/src/EPS Mon Aug 8 14:12:13 2011 @@ -0,0 +1 @@ +link ../EPS \ No newline at end of file Added: trunk/autoinstallation/doc/images/src/PNG URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/images/src/PNG?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/images/src/PNG (added) +++ trunk/autoinstallation/doc/images/src/PNG Mon Aug 8 14:12:13 2011 @@ -0,0 +1 @@ +link ../PNG \ No newline at end of file Added: trunk/autoinstallation/doc/images/src/WEB URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/images/src/WEB?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/images/src/WEB (added) +++ trunk/autoinstallation/doc/images/src/WEB Mon Aug 8 14:12:13 2011 @@ -0,0 +1 @@ +link ../WEB \ No newline at end of file Added: trunk/autoinstallation/doc/xml/ASKSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/ASKSection.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/ASKSection.xml (added) +++ trunk/autoinstallation/doc/xml/ASKSection.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,453 @@ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ + +<!ENTITY % images SYSTEM "images.ent"> +%images; + +<!ENTITY % entities SYSTEM "entities/en.ent"> +%entities; + +<!-- Examples --> +<!ENTITY % examples SYSTEM "examples.ent"> +%examples; + +<!-- components --> +<!ENTITY % components SYSTEM "components.ent"> +%components; + +]> + <section id="CreateProfile.Ask"> + <title> + Ask the user for values during installation + </title> + + <para> + This feature is only available since SUSE Linux 10.1 and SLES10. + </para> + <para> + You have the option to let the user decide the values of specific + parts of the profile during the installation. If you use that feature, + a popup will come up during the installation and will ask the user to + enter a specific part of the profile. So if you want a full auto installation + but you want the user to set the password of the local account, you can do + this via the <emphasis>ask</emphasis> directive in the profile. + </para> + <para> + The following elements must be between the <ask-list config:type="list"><ask> ... </ask></ask-list> tags in the <general> section. + </para> + <para> + <table frame='top'> + <title>XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>question</entry> + <entry>The question you want to ask the user. + <para><screen><question>Enter the LDAP server</question></screen></para></entry> + <entry>The default value is the path to the element (the path often looks strange, so I recommend to enter a question)</entry> + </row> + <row> + <entry>default</entry> + <entry>you can set a pre-selection for the user. A textentry will be filled out with this value, + a checkbox will be "true" or "false" and a selection will have this default "value" pre-selected. + <para><screen><default>dc=suse,dc=de</default></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>help</entry> + <entry>An optional helptext that is shown on the left side of the question. + <para><screen><help>Enter the LDAP server address.</help></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>title</entry> + <entry>An optional title that is shown above the questions. + <para><screen><title>LDAP server</title></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>type</entry> + <entry>the type of the element you want to change. Possible values are "symbol","boolean","string" and "integer". + The filesystem in + the partition section is a symbol, while the "encrypted" element in the user configuration is a boolean. + You can see the type of that element if you look in your profile at the config:type="...." attribute. + Since openSUSE 11.2 and SLES11-SP2 you can use "static_text" as type too. A static_text is just a text that + does not require any user input and can be used to show information if it's not wanted in the help text. + <para><screen><type>symbol</type></screen></para></entry> + <entry>optional. The defaul is string. If type is "symbol" you must provide the selection element too (see below)</entry> + </row> + <row> + <entry>password</entry> + <entry>if this boolean is set to "true", a password dialog pops up instead of a simple text entry. Setting this + to "true" makes only sense if "type" is string. + <para><screen><password config:type="boolean">true</password></screen></para></entry> + <entry>optional. The default is "false"</entry> + </row> + <row> + <entry>path (deprecated since openSUSE 11.0 - use pathlist)</entry> + <entry>The path to the element in the profile. It's a comma seperated list of elements that describes the + path to the element you want to change. For example, the ldap server element can be found in the profile + in the <ldap><ldap_server> section. So if you want to change that value, you have to set the + path to "ldap,ldap_server". If you want to change the password of the first user in the profile, you have to + set the path to "users,0,user_password". The "0" indicates the first user in the <users config:type="list"> + list of users in the profile. + <para><screen><path>networking,dns,hostname</path></screen></para></entry> + <entry>this information is optional but you should at least provie <emphasis>path</emphasis> or <emphasis>file</emphasis></entry> + </row> + <row> + <entry>pathlist (available since openSUSE 11.0 and replaces <emphasis>path</emphasis>)</entry> + <entry>a list of <emphasis>path</emphasis> elements (see above) + <para><screen><pathlist config:type="list"><path>networking,dns,hostname</path><path>...</path></screen></para></entry> + <entry>this information is optional but you should at least provie <emphasis>path</emphasis> or <emphasis>file</emphasis></entry> + </row> + <row> + <entry>file (available since SLES10 SP1 and SL 10.2)</entry> + <entry>you can store the answer to a question in a file, to use it in one of your scripts later. If you ask during stage=inital and you want to use the answer in stage2, then you have to copy the answer-file in a chroot script that is running as chrooted=false. Do it like this "cp /tmp/my_answer /mnt/tmp/". The reason for that is, that /tmp in stage1 is just in the RAM disk and will get lost after the reboot but the installed system is already mounted at /mnt/ + <para><screen><file>/tmp/answer_hostname</file></screen></para></entry> + <entry>this information is optional but you should at least provie <emphasis>path</emphasis> or <emphasis>file</emphasis></entry> + </row> + <row> + <entry>password</entry> + <entry>if this boolean is set to "true", a password dialog pops up instead of a simple text entry. Setting this + to "true" makes only sense if "type" is string. + <para><screen><password config:type="boolean">true</password></screen></para></entry> + <entry>optional. The default is "false"</entry> + </row> + <row> + <entry>stage</entry> + <entry>stage configures the installation stage where the question pops up. You can set this value to "cont" or + "initial". "initial" means the popup comes up very early in the installation, short after the pre-script + has run. "cont" means, that the dialog with the question comes after the first reboot, when the system + boots for the very first time. Questions you answer during the "inital" stage, will write their answer + into the profile on the harddisk. You should know that if you enter cleartext passwords during "initial". + Of course it does not make sense to ask for a filesystem to use in the "cont" phase. The harddisk is already + partitioned at that stage and the question will have no effect. + <para><screen><stage>cont</stage></screen></para></entry> + <entry>optional. The default is "initial"</entry> + </row> + <row> + <entry>selection</entry> + <entry>the selection element contains a list of <entry> elements. Each entry represents a possible option + for the user to choose. So the user can't enter a value in a textfield, but he can choose from a list + of values. + <para><screen> +<selection config:type="list"> + <entry> + <value> + reiser + </value> + <label> + Reiser Filesystem + </label> + </entry> + <entry> + <value> + ext3 + </value> + <label> + Extended3 Filesystem + </label> + </entry> +</selection></screen></para></entry> + <entry>optional for type=string, not possible for type=boolean and a must have for type=symbol</entry> + </row> + <row> + <entry>dialog (available since SL 10.3 and SLES10 SP2)</entry> + <entry>Since OpenSUSE 10.3 you can have more than one question per dialog. To make that possible you have + to specifiy the dialog-id with an integer. All questions with the same dialog-id are on the same dialog. + The dialogs are sorted by the id too. + <para><screen><dialog config:type="integer">3</dialog></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>element (available since SL 10.3 and SLES10 SP2)</entry> + <entry>Since OpenSUSE 10.3 you can have more than one question per dialog. To make that possible you have + to specifiy the element-id with an integer. The questions on a dialog are sorted by the id. + <para><screen><element config:type="integer">1</element></screen></para></entry> + <entry>optional (see dialog></entry> + </row> + <row> + <entry>frametitle (available since SL 10.3 and SLES10 SP2)</entry> + <entry>Since OpenSUSE 10.3 you can have more than one question per dialog. Each question on a dialog has + a frame that can have a frametitle. A small caption for each question if you want so. Since openSUSE 11.3 you can put multiple elements into one frame. They have to have the same frametitle then. + <para><screen><frametitle>User data</frametitle></screen></para></entry> + <entry>optional (default is no frametitle)</entry> + </row> + <row> + <entry>script (available since SL 10.3 not in SLES10 SP1)</entry> + <entry>with 10.3 you can run scripts after a question has been answered (see the table below for detailed instructions about scripts) + <para><screen><script>...</script></screen></para></entry> + <entry>optional (default is no script)</entry> + </row> + <row> + <entry>ok_label (available since openSUSE 11.2 / SLES11 SP2</entry> + <entry>You can change the Label on the "Ok" button. The last element that specifies the label for a dialog wins. + <para><screen><ok_label>Finish</ok_label></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>back_label (available since openSUSE 11.2 / SLES11 SP2</entry> + <entry>You can change the Label on the "Back" button. The last element that specifies the label for a dialog wins. + <para><screen><back_label>change values</back_label></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>timeout (available since openSUSE 11.2 / SLES11-SP2</entry> + <entry>You can specify an integer here that is used as timeout in seconds. If the user does not answer the question before the timeout, the default value is taken as answer. When the user touches/changes any widget in the dialog, the timeout is turned off and the dialog has to be confirmed by the ok-button. + <para><screen><timeout config:type="integer">30</timeout></screen></para></entry> + <entry>optional. A missing value is interpreted as 0 which means that there is no timeout</entry> + </row> + <row> + <entry>default_value_script (available since openSUSE 11.2 / SLES11-SP2)</entry> + <entry>you can run scripts to set the default value for a question(see the table below for detailed instructions about default value scripts). It's useful if you can "calculate" a useful default value, especially in combination with the "timeout" option. + <para><screen><default_value_script>...</default_value_script></screen></para></entry> + <entry>optional (default is no script)</entry> + </row> + </tbody> + </tgroup> + + </table> + </para> + + <para> + The following elements must be between the <ask-list config:type="list"><ask><default_value_script>...</default_value_script>...</ask></ask-list> tags in the <general> section. It's available since 11.2 and SLES11-SP2 + </para> + <para> + <table frame='top'> + <title>XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>source</entry> + <entry>the source code of the script. Whatever you echo to STDOUT will be used as default value for the ask-dialog. If your script has an exit code other than 0, the normal default element is used. Take care you echo with "echo -n" to suppress the '\n' and that you echo reasonable values and not "okay" for a boolean + <para><screen><source>...</source></screen></para></entry> + <entry>this value is required. Otherwise nothing would be executed</entry> + </row> + <row> + <entry>interpreter</entry> + <entry>the interpreter to use + <para><screen><interpreter>perl</interpreter></screen></para></entry> + <entry>default is shell (you can set "/bin/myinterpreter" as value too)</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + + + <para> + The following elements must be between the <ask-list config:type="list"><ask><script>...</script>...</ask></ask-list> tags in the <general> section. It's available since 10.3 (not SLES10 SP1). + </para> + <para> + <table frame='top'> + <title>XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>filename</entry> + <entry>the filename of the script + <para><screen><filename>my_ask_script.sh</filename></screen></para></entry> + <entry>default is ask_script.sh</entry> + </row> + <row> + <entry>source</entry> + <entry>the source code of the script. Together with "rerun_on_error" on you check the value that was entered for sanity (since 11.0 only). Your script can create a file "/tmp/next_dialog" with a dialog id in it. That's the next dialog autoyast will raise then. A value of -1 terminates the ask sequence. If that file is not created, autoyast will run the dialogs in a normal order (since 11.0 only) + <para><screen><source>...</source></screen></para></entry> + <entry>this value is required. Otherwise nothing would be executed</entry> + </row> + <row> + <entry>environment</entry> + <entry>a boolean that passes the "value" of the answer to the question as an environment variable to the script. The variable is named "VAL". + <para><screen><environment config:type="boolean">true</environment></screen></para></entry> + <entry>optional (default is "false").</entry> + </row> + <row> + <entry>feedback</entry> + <entry>a boolean that turns on feedback for the script execution. That means that STDOUT will be shown in a popup box that must be confirmed after the script execution. + <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> + <entry>optional (default is "false").</entry> + </row> + <row> + <entry>debug</entry> + <entry>a boolean that turns on debugging for the script execution + <para><screen><debug config:type="boolean">true</debug></screen></para></entry> + <entry>optional (default is "true"). This value needs feedback to be turned on too.</entry> + </row> + <row> + <entry>rerun_on_error (available since openSUSE 11.0)</entry> + <entry>a boolean that keeps the dialog open until the script has an exit code of 0 (zero). So you can parse and check the answers the user gave in the script and popup an error with the "feedback" option. + <para><screen><rerun_on_error config:type="boolean">true</rerun_on_error></screen></para></entry> + <entry>optional (default is "false"). This value should be used together with the feedback option.</entry> + </row> + </tbody> + </tgroup> + + </table> + </para> + <para> + Below you can see an example of the usage of the "ask" feature. + </para> + <para> + <screen> +<general> + <ask-list config:type="list"> + <ask> + <!-- deprecated since openSUSE 11.0; use pathlist instead + <path>ldap,ldap_server</path> + --> + <pathlist config:type="list"> + <path>ldap,ldap_server</path> + </pathlist> + <stage>cont</stage> + <help>choose your server depending on your department</help> + <selection config:type="list"> + <entry> + <value>ldap1.mydom.de</value> + <label>LDAP for development</label> + </entry> + <entry> + <value>ldap2.mydom.de</value> + <label>LDAP for sales</label> + </entry> + </selection> + <default>ldap2.mydom.de</default> + <default_value_script> + <source> <![CDATA[ +echo -n "ldap1.mydom.de" +]]> + </source> + </default_value_script> + </ask> + <ask> + <!-- deprecated since openSUSE 11.0; use pathlist instead + <path>networking,dns,hostname</path> + --> + <pathlist config:type="list"> + <path>networking,dns,hostname</path> + </pathlist> + <question>Enter Hostname</question> + <stage>initial</stage> + <default>enter your hostname here</default> + </ask> + <ask> + <!-- deprecated since openSUSE 11.0; use pathlist instead + <path>partitioning,0,partitions,0,filesystem</path> + --> + <pathlist config:type="list"> + <path>partitioning,0,partitions,0,filesystem</path> + </pathlist> + <question>Filesystem</question> + <type>symbol</type> + <selection config:type="list"> + <entry> + <value config:type="symbol">reiser</value> + <label>default Filesystem (recommended)</label> + </entry> + <entry> + <value config:type="symbol">ext3</value> + <label>Fallback Filesystem</label> + </entry> + </selection> + + </ask> + </ask-list> + ... +</general> +</screen> +</para> +<para> +The following example is a nice way to choose between autoyast profiles. Autoyast will read the "modified.xml" file again after the ask-dialogs are done. So we can fetch a complete new profile. +</para> +<para> +<screen> + <ask> + <selection config:type="list"> + <entry> + <value>part1.xml</value> + <label>Simple partitioning</label> + </entry> + <entry> + <value>part2.xml</value> + <label>encrypted /tmp</label> + </entry> + <entry> + <value>part3.xml</value> + <label>LVM</label> + </entry> + </selection> + <title>XML Profile</title> + <question>Choose a profile</question> + <stage>initial</stage> + <default>part1.xml</default> + <script> + <filename>fetch.sh</filename> + <environment config:type="boolean">true</environment> + <source><![CDATA[ +wget http://10.10.0.162/$VAL -O /tmp/profile/modified.xml 2>/dev/null +]]> + </source> + <debug config:type="boolean">false</debug> + <feedback config:type="boolean">false</feedback> + </script> + </ask> +</screen> +<para> +Since openSUSE 11.0 you can verify the answer of a question with a script like this: +</para> +<para> +<screen> + <ask> + <script> + <filename>my.sh</filename> + <rerun_on_error config:type="boolean">true</rerun_on_error> + <environment config:type="boolean">true</environment> + <source><![CDATA[ +if [ "$VAL" = "myhost" ]; then + echo "Illegal Hostname!"; + exit 1; +fi +exit 0 +]]> + </source> + <debug config:type="boolean">false</debug> + <feedback config:type="boolean">true</feedback> + </script> + <dialog config:type="integer">0</dialog> + <element config:type="integer">0</element> + <!-- deprecated since openSUSE 11.0; use pathlist instead + <path>networking,dns,hostname</path> + --> + <pathlist config:type="list"> + <path>networking,dns,hostname</path> + </pathlist> + <question>Enter Hostname</question> + <default>enter your hostname here</default> + </ask> +</screen> +</para> +</para> + + + </section> + Added: trunk/autoinstallation/doc/xml/BootMedia.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/BootMedia.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/BootMedia.xml (added) +++ trunk/autoinstallation/doc/xml/BootMedia.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,57 @@ + <section id="choosingbootmedia"> + <title>Choosing the right Boot Medium</title> + <para> + There are different methods for booting the client. The computer can boot from + its network interface card (NIC) to receive the boot images via &dhcp; /TFTP + or a suitable kernel as well as an initrd image are loaded from a + floppy or a boot-able CD-ROM. + </para> + <section id="bootfromfloppy"> + <title> + Booting from a floppy + </title> + <para> + For testing/rescue purposes or because the NIC does not have a PROM or PXE + you can build a boot floppy to use with &autoyast2;. Using a floppy + to initiate an auto-install process is limited due to the size of the + data a floppy can hold. However, it is still possible to use + floppies when auto-installing a single, disconnected machine. + </para> + <para> + Floppies can be used to store the control file, especially when using + the original &company-suse; CD-ROMs for a single, disconnected machine. Using the + kernel command line, you can specify the location of the control + file on the floppy. (See <quote></link></quote>) + </para> + <para> + Even without specifying any command line options, it is still possible to initiate the + auto-install process by placing a control file on a floppy with a + special, pre-defined file name. (<filename>autoinst.xml</filename>) &yast2; will check for + <filename>autoinst.xml</filename> upon startup and if it was found it + will switch from interactive to automated installation. + </para> + </section> + + <section id="bootfromcd"> + <title>Booting from CD-ROM</title> + <para> + You can use the original &company-suse; CD-ROMs in combination with other + media, i.e. with a floppy to hold the control file or in combination + with network where the control file can be located. + </para> + <para> + It is also possible to create customized CD-ROMs to hold only the + package you need in addition to the control file which also can be + saved on the CD-ROM. This method requires creation of CD-ROMs + every time you wish to change the configuration though. + </para> + </section> + </section> + + <!-- + Local Variables: + mode: xml + sgml-parent-document: ("autoyast2.xml" "chapter" "section") + End: + --> \ No newline at end of file Added: trunk/autoinstallation/doc/xml/BootloaderSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/BootloaderSection.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/BootloaderSection.xml (added) +++ trunk/autoinstallation/doc/xml/BootloaderSection.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,572 @@ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ + +<!ENTITY % images SYSTEM "images.ent"> +%images; + +<!ENTITY % entities SYSTEM "entities/en.ent"> +%entities; + +<!-- Examples --> +<!ENTITY % examples SYSTEM "examples.ent"> +%examples; + +<!-- components --> +<!ENTITY % components SYSTEM "components.ent"> +%components; + +]> + +<section id="CreateProfile.Bootloader"> + <title>The Boot loader</title> + <para>This documentation is for yast2-bootloader and is is valid for SLE11 and openSUSE 11.0+. For older versions please use the documentation that comes with your distribution in /usr/share/doc/packages/autoyast2/</para> + <para> + General scope of autoyast profile only bootloader part. + <screen> +<bootloader> + <device_map config:type="list"> + - info about order of devices in device.map + </device_map> + <global> + - info about configuration of installation (installation settings for GRUB and generic boot code) + </global> + <initrd_modules config:type="list"> + - list of initrd modules + </initrd_modules> + <loader_type>grub</loader_type> - type of bootloader + <sections config:type="list"> + - bootloader sections in menu.lst + </sections> + </bootloader> +</screen> +</para> + <section><title>Device map</title> +<para> +You can define devices and their order in device.map but it is not necessary. yast2-bootloader checks the devices during the installation and proposes a device.map by itself. It can happen that the order of the devices is wrong or you have defined a different order than it is in the BIOS (please take care about changes there. it can leads to unbootable system). +</para> +<screen> +<device_map config:type="list"> + <device_map_entry> + <firmware>hd0</firmware> <!-- order of devices in target map --> + <linux>/dev/disk/by-id/ata-ST3500418AS_6VM23FX0</linux> <!-- name of device (disk) --> + </device_map_entry> +</device_map> +</screen> + </section> + <section><title>Globals</title> + <para> + This is an important part where you can define where to install GRUB and also how the boot process will work. It is not necessary to define this part as mentioned before, yast2-bootloader proposes a configuration by itself and so this is optional. Usually the AutoYaST profile includes only this part and all other parts are added automatically during installation by yast2-bootloader. Unless you have some special needs, you don't have to specify the bootloader config in the XML file. +<screen> + <global> + <activate>true</activate> + <default>openSUSE 11.2 - 2.6.31.5-0.1</default> + <gfxmenu>(hd0,1)/boot/message</gfxmenu> + <lines_cache_id>4</lines_cache_id> + <timeout config:type="integer">10</timeout> + </global> +</screen> + </para> +<para> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>activate</entry> + <entry> + <para>set boot flag on boot partition. The boot partition can be "/" if there is no separate /boot partition. If the boot partition is on logical partition, the boot flag is set to the extended partition. + </para> + <para><screen><activate>true</activate></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>default</entry> + <entry> + <para> + name(title) of the default boot section from menu.lst + </para> + <para><screen><default>openSUSE 11.2 - 2.6.31.5-0.1</default></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>gfxmenu</entry> + <entry> + <para> + path to the graphical boot menu (/boot/message). 'none' means don't use graphical boot menu + </para> + <para><screen><gfxmenu>(hd0,1)/boot/message</gfxmenu></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>timeout</entry> + <entry> + <para> + timeout in seconds for automatic booting the default boot section from menu.lst + </para> + <para><screen><timeout config:type="integer">10</timeout></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>generic_mbr</entry> + <entry> + <para> + write generic boot code to MBR. (It is ignored if boot_mbr is set to true) + </para> + <para><screen><generic_mbr>false</generic_mbr></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>boot_mbr</entry> + <entry> + <para> + write GRUB to MBR of the first disk in the order (device.map include order of disks) + </para> + <para><screen><boot_mbr>false</boot_mbr></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>boot_boot</entry> + <entry> + <para> + write GRUB to separate /boot partition (if separate /boot partition missing GRUB will be written to "/") + </para> + <para><screen><boot_boot>false</boot_boot></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>boot_root</entry> + <entry> + <para> + write GRUB to "/" partition + </para> + <para><screen><boot_root>false</boot_root></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>boot_extended</entry> + <entry> + <para> +write GRUB to the extended partition (it is important if you want to use a generic boot code and the "boot" partition is logical) NOTE: if the boot partition is logical it should use boot_mbr (write GRUB to MBR) instead of generic_mbr. + </para> + <para><screen><boot_extended>false</boot_extended></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>boot_custom</entry> + <entry> + <para> + write GRUB to custom device. + </para> + <para><screen><boot_custom>/dev/sda3</boot_custom></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>trusted_grub</entry> + <entry> + <para> + use trusted GRUB instead of the classical GRUB (gfxmenu is deleted automatically if this option is true) please doesn't use trusted GRUB if your hardware doesn't support it. + </para> + <para><screen><trusted_grub>false</trusted_grub></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>lines_cache_id</entry> + <entry> + <para> + internal option which means cache id for perl-Bootloader. Please don't use it or change it in a cloned XML file. + </para> + <para><screen></screen></para> + </entry> + <entry></entry> + </row> + </tbody> + </tgroup> +</table> +</para> + </section> + <section><title>Initrd modules </title> +<para> + This is a list of initrd modules. It is not necessary to add this part it should be added automatically. Please don't modify it if you are not sure what the initrd modules are. +</para> + </section> + <section><title>Loader Type</title> + <para> + This part defines the type of the bootloader. It could be grub, lilo, ppc or elilo. + </para> + <screen> +<loader_type>grub</loader_type> + </screen> + </section> + <section><title>Sections</title> + <para> +This includes the configuration of the boot sections in the menu.lst. This part is added by yast2-bootloader during installation automatically. It is good to know that yast2-bootloader deletes boot sections with no valid kernel and initrd path. It also deletes such boot sections. + </para> +<screen> + <sections config:type="list"> + <section> + <append>resume=/dev/disk/by-id/raid-sil_ajacccbhejai-part2 splash=silent quiet showotps</append> + <image>(hd0,0)/vmlinuz-2.6.31-10-default</image> + <initial>1</initial> + <initrd>(hd0,0)/initrd-2.6.31-10-default</initrd> + <lines_cache_id>0</lines_cache_id> + <name>openSUSE 11.2 Milestone 8 - 2.6.31-10 (default)</name> + <original_name>linux</original_name> + <root>/dev/mapper/sil_ajacccbhejai_part3</root> + <type>image</type> + <vgamode>0x31a</vgamode> + </section> + <section> + <append>resume=/dev/disk/by-id/raid-sil_ajacccbhejai-part2 splash=silent quiet showopts</append> + <image>(hd0,0)/vmlinuz-2.6.31-10-xen</image> + <initrd>(hd0,0)/initrd-2.6.31-10-xen</initrd> + <lines_cache_id>2</lines_cache_id> + <name>Xen -- openSUSE 11.2 Milestone 8 - 2.6.31-10</name> + <nounzip>0</nounzip> + <original_name>xen</original_name> + <root>/dev/mapper/sil_ajacccbhejai_part3</root> + <type>xen</type> + <vgamode>0x31a</vgamode> + <xen>(hd0,0)/xen.gz</xen> + <xen_append></xen_append> + </section> + <section> + <blockoffset>1</blockoffset> + <chainloader>/dev/fd0</chainloader> + <lines_cache_id>3</lines_cache_id> + <name>Floppy</name> + <noverifyroot>true</noverifyroot> + <original_name>floppy</original_name> + <type>other</type> + </section> + </sections> +</screen> +</section> + <section><title>Options</title> + <para> +the options depend on the <emphasis>type</emphasis>. + </para> + <section><title>Options for section type: image and xen</title> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>append</entry> + <entry> + <para> + list of kernel args but without(!) vga= and root= + </para> + <para><screen><append>splash=silent quiet showopts</append></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>image</entry> + <entry> + <para> + path to the kernel + </para> + <para><screen><image>(hd0,0)/vmlinuz-2.6.31-10</image></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>initrd</entry> + <entry> + <para> + path to the initrd + </para> + <para><screen><initrd>(hd0,0)/my-initrd</initrd></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>lines_cache_id</entry> + <entry> + <para> + internal option which means cache id for perl-Bootloader. Please don't use it or change it in a cloned XML file. + </para> + <para><screen></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>name</entry> + <entry> + <para> + name of section + </para> + <para><screen><name>Productive System</name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>original_name</entry> + <entry> + <para> + internal name of section parsed by YaST from a comment in the config file. There are some rules for names and original_name helps to determine if boot section is linux or failsafe and for chainloader it helps to determine if it is windows or other linux/floppy etc. Please use simple original_name: linux, xen, windows, floppy etc. + </para> + <para><screen><original_name>linux</original_name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>root</entry> + <entry> + <para> + location of the root partition ("/") + </para> + <para><screen><root>/dev/mapper/sil_ajacccbhejai_part3</root></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>type</entry> + <entry> + <para> + type of section it could (image/xen/other/menu) + </para> + <para><screen><type>xen</type></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>vgamode</entry> + <entry> + <para> + kernel arg for vga (vga=) + </para> + <para><screen><vgamode>0x31a</vgamode></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>xen</entry> + <entry> + <para> + path to xen.gz + </para> + <para><screen><xen>(hd0,0)/xen.gz</xen></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>xen_append</entry> + <entry> + <para> + kernel args for XEN + </para> + <para><screen><xen_append></xen_append></screen></para> + </entry> + <entry></entry> + </row> + </tbody> + </tgroup> +</table> + </section> + <section><title>Options for section type: other (chainloader)</title> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>lines_cache_id</entry> + <entry> + <para> + internal option which means cache id for perl-Bootloader. Please don't use it or change it in a cloned XML file. + </para> + <para><screen></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>name</entry> + <entry> + <para> + name or title of section + </para> + <para><screen><name>Floppy</name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>original_name</entry> + <entry> + <para> + internal name of section parsed by YaST from a comment in the config file. There are some rules for names and original_name helps to determine if boot section is linux or failsafe and for chainloader it helps to determine if it is windows or other linux/floppy etc. Please use simple original_name: linux, xen, windows, floppy etc. + </para> + <para><screen><original_name>linux</original_name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>type</entry> + <entry> + <para> + type of section it could (image/xen/other/menu) + </para> + <para><screen><type>other</type></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>blockoffset</entry> + <entry> + <para> + offset in chainloader (used only in grub) + </para> + <para><screen><blockoffset>1</blockoffset></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>chainloader</entry> + <entry> + <para> + partition part for chainloader (so chainloader+blockoffset get final chainloader item in grub) + </para> + <para><screen><chainloader>/dev/fd0</chainloader></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>noverifyroot</entry> + <entry> + <para> + with/without checking root + </para> + <para><screen><noverifyroot>true</noverifyroot></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>remap</entry> + <entry> + <para> + it is special for windows and it means remapping disk which makes the second disk the first e.g. map (hd0) (hd1) map (hd1) (hd0) + </para> + <para><screen><remap>false</remap></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>makeactive</entry> + <entry> + <para> + add the makeactive argument for chainloader section + </para> + <para><screen><makeactive>false</makeactive></screen></para> + </entry> + <entry></entry> + </row> + </tbody> + </tgroup> +</table> +</section> + <section><title>Options for section type: menu (configfile)</title> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>lines_cache_id</entry> + <entry> + <para> + internal option which means cache id for perl-Bootloader. Please don't use it or change it in a cloned XML file. + </para> + <para><screen></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>name</entry> + <entry> + <para> + name or title of section + </para> + <para><screen><name>Floppy</name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>original_name</entry> + <entry> + <para> + internal name of section parsed by YaST from a comment in the config file. There are some rules for names and original_name helps to determine if boot section is linux or failsafe and for chainloader it helps to determine if it is windows or other linux/floppy etc. Please use simple original_name: linux, xen, windows, floppy etc. + </para> + <para><screen><original_name>linux</original_name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>type</entry> + <entry> + <para> + type of section it could (image/xen/other/menu) + </para> + <para><screen><type>other</type></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>configfile</entry> + <entry> + <para> + path to menu.lst config file + </para> + <para><screen><configfile>1</configfile></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>root</entry> + <entry> + <para> + device name for loading menu.lst from other installation of linux + </para> + <para><screen><root>/dev/sda1</root></screen></para> + </entry> + <entry></entry> + </row> + </tbody> + </tgroup> +</table> +</section> +</section> +</section> + Added: trunk/autoinstallation/doc/xml/CreateProfile.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/CreateProfile.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/CreateProfile.xml (added) +++ trunk/autoinstallation/doc/xml/CreateProfile.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,168 @@ + + <chapter id="CreateProfile"> + <title >Creating A Control File</title> + + <section id="Autoinstallation.collectInfo"> + <title>Collect information</title> + <para> + In order to create the control file, first you need to collect + information about the systems your are going to + install. This includes among other things hardware data and network + information. Make sure you know the following about the machines you want to install: + </para> + <itemizedlist> + <listitem> + <para>Hard disk types and sizes</para> + </listitem> + <listitem> + <para>Graphic interface and attached monitor if any</para> + </listitem> + <listitem> + <para>Network interface and MAC address if known (i.e. when using &dhcp;)</para> + </listitem> + </itemizedlist> + <para> + With these parameters you are ready to go and create a profile of your systems + to control the auto-installation process. + </para> + </section> + <section id="CreateProfile.CMS"> + <title> + Using the Configuration Management System + </title> + <para> + In order to create the control file for one or more computers, a configuration + interface based on &yast2; is provided. This system depends on existing modules + which are usually used to configure a computer in regular operation mode, + i.e. after &company-suse; Linux is installed. + </para> + <para> + The configuration management system lets you create control files easily and + additionally it lets you manage a repository of configurations for use + in a networked environment and with multiple clients. + </para> + <figure> + <title>Configuration System</title> + <mediaobject>&autoyast2-maindialog;</mediaobject> + </figure> + + <section> + <title>Creating a new Profile</title> + <para> + With some exceptions, almost all resources of the control file can + be configured using the configuration management system. The system + offers flexibility and configuration of some resources is + identical to this available in the &yast2; Control Center. In + addition to the existing and familiar modules new + interfaces were created for special and complex configurations, + for example for partitioning, general options and software. + </para> + <para> + Furthermore, using the &cms; guarantees that the resulting control file is + valid and insures that it can be used directly to start automated installation. + </para> + <para> + Make sure the configuration system is installed (package + <emphasis>autoyast2</emphasis>) and call it using the <emphasis>YaST2 + Control Center</emphasis> or call it directly as root with the + following command (make sure the <emphasis>DISPLAY</emphasis> variable is set correctly to + start the graphical user interface instead of the text based one): + </para> + <screen> +/sbin/yast2 autoyast + </screen> + + </section> + + + </section> + + <section id="CreateProfile.Manual"> + <title>Creating/Editing a Control File Manually</title> + <para> + If you edit the control file manually, make sure it has a valid syntax. To + check the syntax, use some tools already available + on the distribution. For example to verify that the file is well + formed, use the utility <command>xmllint</command> available with the + <emphasis>libxml2</emphasis> package: + </para> + <screen> +xmllint <control file> + </screen> + <para> + If the control file is not well formed, i.e. if a tag is not closed, + <command>xmllint</command> will report about the errors. + </para> + <para> + Before going on with the auto-installation, please fix any errors + resulting from such checks. The auto-installation process can't be + started with an invalid and non-well formed control file. + </para> + + <para> + You can use any XML editor available on your system or use your + favorite text editor with XML support (i.e. Emacs, Vim). However, it is not quite + optimal to create the control file manually for large number of machines + and it should only be seen as an interface between the auto-installation + engine and the Configuration Management System (<abbrev>CMS</abbrev>). + </para> + + <figure id="kxmleditor"> + <title id="kxmleditor.title" >Editing the control file with <command>kxmledit</command></title> + <mediaobject>&kxmleditor;</mediaobject> + </figure> + + </section> + + <section id="CreateProfile.XSLT"> + <title>Creating a Profile (control file) via Script with XSLT</title> + <para> + For the case you have a template and just want to change a few things via script or command line, + you can use a XSLT processor like <emphasis>sablot</emphasis> for this. Lets say you have an autoyast profile + and you want to fillout the hostname via script for any reason (maybe because you have to do it + so often, you want to script it) + </para> + <para> + First you have to create an XSL file + </para> + <example> + <title>Example file for replacing hostname/domain by script</title> + <screen>http://www.w3.org/2001/XInclude"/> + </screen> + </example> + <para> + As you can see, this file expects the "hostname" and the "domain" as parameters from the user. + <screen><xsl:param name="hostname"/> +<xsl:param name="domain"/></screen> + There will be a "copy" of those parameters in the "dns" section of the control file. That means, + if there already is a domain element in the dns section, you'll get a second one (no good). + </para> + <para> + If you want to create a new autoyast profile now from the template plus the XSL file, run the following command: + <screen>sabcmd add_hostname.xsl \$hostname=myHost \$domain=my.domain template.xml</screen> + You'll get a filled out autoyast profile then on STDOUT. + </para> + <para> + If you have multiple XSL files you want to apply to a template, do it like this + <screen> + sabcmd add_hd_vg.xsl \$device=/dev/sda \$partition=p2 \$vg=system \ + | sabcmd add_harddisk.xsl \$device=/dev/system \$lvm=true \ + | sabcmd .... + | sabcmd add_hostname.xsl \$hostname=myHost \$domain=my.domain + </screen> + So you just pipe the output of each sabcmd to the next sabcmd. + </para> + <para> + For more information aout XSLT, go to the official webpage <ulink url="http://www.w3.org/TR/xslt">www.w3.org/TR/xslt</ulink> + </para> + </section> + + </chapter> + + <!-- + Local Variables: + mode: xml + sgml-parent-document: ("autoyast.xml" "book" "chapter") + End: + --> Added: trunk/autoinstallation/doc/xml/CreateProfileDetails.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/CreateProfileDetails.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/CreateProfileDetails.xml (added) +++ trunk/autoinstallation/doc/xml/CreateProfileDetails.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,74 @@ + <chapter id="configuration"> + <title>Configuration and Installation Options</title> + <para> + This chapter introduces important parts of a control file for + standard purposes. To have an idea about the other options available, + use the configuration management system. + </para> + <para> + Note that for some of the configuration options to work, additional + packages have to be installed, depending on the software selection you + have configured. If you choose to install <emphasis>Minimal</emphasis> + then some packages might be missing and those have to be added to the + individual package selection. + </para> + <para> + YaST will install packages required by YaST modules in the second phase + of the installation and before the post-installation phase of AutoYaST + has started, however if the YaST modules are not available in the + system, this will not happen. For example, no security settings will be + configured if <emphasis>yast2-security</emphasis> is not installed. + </para> + + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + + <section id="CreateProfile.Hardware"> + <title> + Miscellaneous hardware and system components + </title> + + <para> + In addition to the core component configuration, like network + authentication and security, &autoyast;2 offers a wide range of + hardware and system configuration which is available by default on + any system installed manually and in an interactive way. For + example, it is possible to configure printers, sound devices, TV + cards and any other hardware components which have a module within YaST2. + </para> + <para> + Any new configuration options that will be added to &yast2; will be + automatically available as an auto-installation resource. + </para> + + + + http://www.w3.org/2001/XInclude"/> + http://www.w3.org/2001/XInclude"/> + </section> + + </chapter> + <!-- + Local Variables: + mode: xml + sgml-parent-document: ("autoyast.xml" "book" "chaper") + End: + --> Added: trunk/autoinstallation/doc/xml/FilesSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/FilesSection.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/FilesSection.xml (added) +++ trunk/autoinstallation/doc/xml/FilesSection.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,59 @@ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ + +<!ENTITY % images SYSTEM "images.ent"> +%images; + +<!ENTITY % entities SYSTEM "entities/en.ent"> +%entities; + +<!-- Examples --> +<!ENTITY % examples SYSTEM "examples.ent"> +%examples; + +<!-- components --> +<!ENTITY % components SYSTEM "components.ent"> +%components; + +]> + + <section id="createprofile.completeconf"> + <title>Adding complete configurations</title> + <para> + For many applications and services you might have prepared a + configuration file which should be copied in a complete form to some + location in the installed system. This is for example if you are + installing a web server and have a <emphasis>ready to go</emphasis> + server configuration file (<filename>httpd.conf</filename>). + </para> + <para> + Using this resource, you can embed the file into the control file by + specifying the final path on the installed system. &yast2; will copy this + file to the specified location. + </para> + <para> + This feature requires the autoyast2 package to be installed. If the package is + missing, AutoYaST will silently ignore the <emphasis>files</emphasis> section. + Since openSUSE 11.1 and SLES11 AutoYaST will install the package on it's own if + it's missing. + </para> + <para> + Since openSUSE 11.1 and SLES11 you can specify a <emphasis>file_location</emphasis> + where the file should be retrieved from, like an HTTP server for example. That would + look like this <emphasis><file_location>http://my.server.site/issue</file_location>;</emphasis> + </para> + <para> + Since openSUSE 11.2 (not SLES11) you can create directories by specifying a file_path that ends with a slash. + </para> + &example.files; + + <para> + A more advanced example is shown below. This configuration will create + a file using the content supplied in <emphasis>file_contents</emphasis> + and will change the permissions and ownership of the file. After the + file has been copied to the system, a script is executed which can be + used to manipulate the file and prepare it for the environment of the client. + </para> + &example.filesadv; + </section> + Added: trunk/autoinstallation/doc/xml/GeneralSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/GeneralSection.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/GeneralSection.xml (added) +++ trunk/autoinstallation/doc/xml/GeneralSection.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,215 @@ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ + +<!ENTITY % images SYSTEM "images.ent"> +%images; + +<!ENTITY % entities SYSTEM "entities/en.ent"> +%entities; + +<!-- Examples --> +<!ENTITY % examples SYSTEM "examples.ent"> +%examples; + +<!-- components --> +<!ENTITY % components SYSTEM "components.ent"> +%components; + +]> + + + <section id="CreateProfile.General"> + <title id="CreateProfile.General.title"> + General Options + </title> + + <para> + General + options include all the settings related to the installation process and + the environment of the installed system. + </para> + <example> + <title>General Options</title> + <para> + The mode section configures the behavior of AutoYaST when it comes to confirmation and rebooting. The following has to be in the <general><mode> section + </para> + <para> + By default, the auto-installation process has to be confirmed by the + user. The confirmation should be disabled if a fully unattended + installation is desired. This option is used to view and change the + settings on a target system before anything is committed and can be + used for debugging. It is set to <emphasis>true</emphasis> by default + to avoid recursive installs when the system schedules a reboot after + initial system setup. + </para> + <para> + With <emphasis>halt</emphasis> you make autoyast to turn off the machine + after all packages have been installed. So instead of the reboot into + stage two, the machine is turned off. The bootloader is alreay installed + and all your chroot scripts have run. + </para> + <para> + <emphasis>final_halt</emphasis> and <emphasis>final_reboot</emphasis> are new + with openSUSE 11.0 and SLES11. You can reboot or halt the machine, + when everything with installation and configuration is done, with that. + </para> + <para> + openSUSE 11.0 uses the kexec feature and does not reboot anymore between stage1 and stage2. With + the <emphasis>forceboot</emphasis> option you can force the reboot in case you need it for some + reason. true will reboot, false will not reboot and a missing <emphasis>forceboot</emphasis> option + uses the products default. + </para> + <para> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>confirm</entry> + <entry>if this boolean is set to "true" the installation stops at the confirmation screen (also called proposal screen) and has to be confirmed with the "install"-button. + <para><screen><confirm config:type="boolean">true</confirm></screen></para> + </entry> + <entry>optional. The default is true</entry> + </row> + <row> + <entry>halt</entry> + <entry>shut down the machine after the first stage. So if you turn it on again, the machine boots and the second stage of the autoinstallation starts + <para><screen><halt config:type="boolean">true</halt></screen></para> + </entry> + <entry>optional. The default is false</entry> + </row> + <row> + <entry>second_stage</entry> + <entry>this boolean configures if AutoYaST will run in the second stage too (after the partitioning, software and bootloader installation of the first stage). If you set this to false, a normal manual installation happens in the second stage. + <para><screen><second_stage config:type="boolean">true</second_stage></screen></para> + </entry> + <entry>optional. The default is true</entry> + </row> + <row> + <entry>final_reboot</entry> + <entry>if you set this to true, the machine will reboot at the very end of the installation (when everything is installed and configured at the end of the second stage) + <para><screen><final_reboot config:type="boolean">true</final_reboot></screen></para> + </entry> + <entry>optional. The default is false. It makes no sense to set this <emphasis>and</emphasis> final_halt to true. This options is available since openSUSE 11.0 and SLES11</entry> + </row> + <row> + <entry>final_halt</entry> + <entry>if you set this to true, the machine will shutdown at the very end of the installation (when everything is installed and configured at the end of the second stage) + <para><screen><final_halt config:type="boolean">true</final_halt></screen></para> + </entry> + <entry>optional. The default is false. It makes no sense to set this <emphasis>and</emphasis> final_reboot to true. This options is available since openSUSE 11.0 and SLES11</entry> + </row> + <row> + <entry>forceboot</entry> + <entry>Some openSUSE releases use kexec to avoid the reboot after the first stage. They immediately boot into the installed system. You can force a reboot with this + <para><screen><forceboot config:type="boolean">true</forceboot></screen></para> + </entry> + <entry>optional. The default is false.</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + + +<screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + + + <para> + AutoYaST in openSUSE 11.1 allows you to configure the proposal screen with the <proposals config:type="list"> + option in the profile. All proposals that are listed in that section are shown in the proposal screen if you set the + <emphasis>confirm</emphasis> option to true. + </para> + <para> + This is the list of proposals for openSUSE 11.1 are (you can find that in the control.xml on the installation source too): + <itemizedlist> + <listitem> + <para> + partitions_proposal + </para> + </listitem> + <listitem> + <para> + bootloader_proposal + </para> + </listitem> + <listitem> + <para> + country_simple_proposal + </para> + </listitem> + <listitem> + <para> + timezone_proposal + </para> + </listitem> + <listitem> + <para> + users_proposal + </para> + </listitem> + <listitem> + <para> + hwinfo_proposal + </para> + </listitem> + <listitem> + <para> + mouse_proposal + </para> + </listitem> + <listitem> + <para> + software_proposal + </para> + </listitem> + <listitem> + <para> + runlevel_proposal + </para> + </listitem> + <listitem> + <para> + deploying_proposal + </para> + </listitem> + </itemizedlist> + </para> + <para> + The wait section was invented with openSUSE 11.1 and SLES11. You can let AutoYaST sleep before and after each module during the second stage. + You can run scripts and/or you can pass a value (in seconds) for AutoYaST to sleep. In the example above AutoYaST will sleep for 15 seconds (10+5) before + the network configuration happens and 10 seconds (3+7) after the network configuration is done. The scripts in the example don't really make a lot of sense + because you could pass that value as "time" value too but I think you get how scripts in the wait section work now. + </para> + <note> + <title>Change starting from SUSE Linux 10.1/SLES10</title> + <para> + The <emphasis>language</emphasis>, <emphasis>keyboard</emphasis> and + <emphasis>clock</emphasis> properties in the <emphasis>general</emphasis> + resource were moved to the root (<emphasis>profile</emphasis>) element of + the autoyast profile. So don't use them in the general section anymore. + </para> + <para> + Since now you can use the <emphasis>second_stage</emphasis> property, which + can turn off autoyast after the first reboot. So the complete second stage is + a manual installation (default is true, which means that autoyast is doing a + complete installation). Since openSUSE 11.0 you can set the boolean <emphasis>final_reboot</emphasis> + and <emphasis>final_halt</emphasis> to reboot/turn off the machine at the end of stage two. + </para> + <para> + For the signature-handling, please read the <emphasis>Software</emphasis> chapter + of this documentation. + </para> + </note> + </section> + Added: trunk/autoinstallation/doc/xml/Installation.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Installation.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/Installation.xml (added) +++ trunk/autoinstallation/doc/xml/Installation.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,786 @@ + +<chapter id="Invoking"> + <title>The Auto-Installation Process</title> + <section id="Installation.process"> + + <title> + Introduction + </title> + <para> + After the system has booted and the control file has been retrieved, + &yast2; performs configuration of the system according to the information + provided in the control file. All the configuration is summarized in a window that is shown by + default and should be deactivated if a full automatic installation is + needed. + </para> + <para> + When &yast2; has reached the point where the summary of the configuration is shown, + &yast2; has only probed hardware and prepared the system for + auto-installation, thus, nothing has been changed in the system yet, so + that in case of any error, the process still can be aborted. + </para> + + <para> + A system should be automatically installable without the need to have + any graphic adaptor or monitor. Having a monitor attached to the + client machine is nevertheless recommended to follow the process and + to get feedback in case of any errors. Choosing between the Qt and the + Ncurses interfaces is possible. For headless + clients, system messages can be monitored using the serial console. + </para> + <section id="Installation.Interface.X11"> + <title> + X11 Interface + </title> + <para> + This is the default interface while auto-installing. No special + variables are required to activate it. + </para> + </section> + <section id="Installation.Interface.SerialConsole"> + <title> + Serial console + </title> + <para> + You can start installing a system using the serial console by adding + the keyword console (i.e. console=ttyS0) to the command line of the + kernel. This will start linuxrc in console mode and later in the + process, &yast2; also is started in serial console mode. + </para> + </section> + <section id="Installation.Interface.Ncurses"> + <title> + Text based YaST2-Installation + </title> + <para> + This option can also be activated on the command line. This will start + YaST2 in <emphasis>Ncurses</emphasis> mode. To start &yast2; in text + mode, add <emphasis>textmode=1</emphasis> on the command line. + </para> + <para> + Starting &yast2; in text mode is recommended when installing a client + with less than 64 MB or when X11 is not being configured at all, + especially on headless machines. + </para> + </section> + </section> + + <section id="bootmedium"> + <title>Choosing the right Boot Medium</title> + <para> + There are different methods for booting the client. The computer can boot from + its network interface card (NIC) to receive the boot images via &dhcp; /TFTP + or a suitable kernel as well as an initrd image are loaded from a + floppy or a boot-able CD-ROM. + </para> + <section> + <title> + Booting from a floppy + </title> + <para> + For testing/rescue purposes or because the NIC does not have a PROM or PXE + you can build a boot floppy to use with &autoyast2;. Using a floppy + to initiate an auto-install process is limited due to the size of the + data a floppy can hold. However, it is still possible to use + floppies when auto-installing a single, disconnected machine. + </para> + <para> + Floppies can be used to store the control file, especially when using + the original &company-suse; CD-ROMs for a single, disconnected machine. Using the + kernel command line, you can specify the location of the control + file on the floppy. + </para> + <para> + Even without specifying any command line options, it is still possible to initiate the + auto-install process by placing a control file on a floppy with a + special, pre-defined file name. (<filename>autoinst.xml</filename>) &yast2; will check for + <filename>autoinst.xml</filename> upon startup and if it was found it + will switch from interactive to automated installation. + </para> + </section> + + <section> + <title>Booting from CD-ROM</title> + <para> + You can use the original &company-suse; CD-ROMs in combination with other + media, i.e. with a floppy to hold the control file or in combination + with network where the control file can be located. + </para> + <para> + It is also possible to create customized CD-ROMs to hold only the + package you need in addition to the control file which also can be + saved on the CD-ROM. This method requires creation of CD-ROMs + every time you wish to change the configuration though. + </para> + </section> + + <section> + <title>Booting via PXE over the network</title> + <para> + Booting via PXE requires a DHCP and a TFTP server in your network. The computer + will boot then without a physical media like a boot floppy or CDROM. + </para> + <para> + Here is a small example of a "/srv/tftp/pxelinux.cfg/default" file: + <screen> +default SLES9 + +# install SLES9 +label SLES9 + kernel linux_sles9 + append initrd=initrd_sles9 vga=0x0314 install=.... autoyast=... language=de_DE + +# boot harddisc +label hd· + LOCALBOOT 0 + </screen> + </para> + <para> + It's recommended to add the vga=... parameter with a valid value for graphical + installations, to trigger an installation with the frame buffer device instead + of the vesa driver or ncurses mode. + </para> + <para> + Here is as a small example my "/etc/dhcp.conf" file: + <screen> +option domain-name-servers 192.168.66.1; +default-lease-time 600; +max-lease-time 7200; +ddns-update-style none; ddns-updates off; +log-facility local7; +option grub-menufile code 150 = text; +option grub-menufile "(nd)/menu.lst";· +subnet 192.168.66.0 netmask 255.255.255.0 { + range 192.168.66.100 192.168.66.200; + # PXE related stuff ... + # + # "next-server" defines the tftp server which will· + # serve the pxelinux image to the PXE clients. + next-server 192.168.66.1; + allow booting; + allow bootp; + option routers 192.168.66.1; # default gateway + + # + # "filename" specifies the pxelinux image on the tftp server· + # which will be served to the PXE clients. + # The configured tftp server on 192.168.100.1 runs in a· + # "change-root jail" to /srv/tftpboot + filename "pxelinux.0"; +} + </screen> + </para> + <para> + A problem you might run into if you do installation via PXE is, that the + installation will run into an endless loop, because after the first reboot, + the machine is doing PXE boot again and will restart the installation instead + of booting from harddisc for the second stage of the installation. + </para> + <para> + This problem can be solved in different ways. One way is to use a http server + to provide the autoyast profile and instead of a static profile, a CGI script + on the webserver is run that provides the profile and then changes the TFTP server + configuration then for this special host, so that the next PXE boot from that + machine will be from harddisc by default. + </para> + <para> + Another way is to use autoyast to upload a new PXE boot configuration for that host. + That is done via autoyast profile like this: + <screen> + <![CDATA[ + <pxe> + <pxe_localboot config:type="boolean">true</pxe_localboot> + <pxelinux-config> +DEFAULT linux + LABEL linux + localboot 0 + + + </pxelinux-config> + <tftp-server>192.168.66.1</tftp-server> + <pxelinux-dir>/pxelinux.cfg</pxelinux-dir> + <filename>__MAC__</filename> <!-- since openSUSE 11.2, not SLES11 --> + </pxe> +]]> + </screen> + This will upload a new configuration for the actual machine to the tftp server short + before the first reboot happens. In most installations the TFTP daemon runs as user + "nobody". You have to make sure that that user has write permissions to the "pxelinux.cfg" + directory if you use that mechanism. + So if your machine got the IP address "192.168.66.195" a file "C0A842C3" will + be uploaded and if the machine reboots and will get the same IP address + via DHCP again, the new configuration will be used that has the harddisc as + a default boot media. + </para> + <para> + Of course this requires that the machine will get the same IP address again after the + reboot and if you want to do another autoinstallation for that machine, you have to + remove the file from the TFTP server. + </para> + <para> + Since openSUSE 11.2 (not SLES11) you can configure the filename too that will be uploaded. + If you use the "magic" __MAC__ filename, the filename will be the mac address of your machine like this "01-08-00-27-79-49-ee". + A missing filename creates the IP address filename like in the past. + </para> + </section> + </section> + + <section id="invoking_autoinst"> + <title id="invoking_autoinst.title"> + Invoking the Auto-Installation process + </title> + + <section> + <title>Command line Options</title> + <para> + Adding the command line variable <emphasis>autoyast</emphasis> will make + <emphasis>linuxrc</emphasis> start in automated mode. + <command>Linuxrc</command> searches for a configuration file, which + should be distinguished from the main control file in the following + places: + </para> + <itemizedlist> + <listitem> + <para>In the root directory of the initial ram-disk used for booting + the system up</para> + </listitem> + <listitem> + <para>In the root directory of the floppy</para> + </listitem> + </itemizedlist> + <para> + The configuration file used by <command>linuxrc</command> can have the + following keywords (for a detailed description of how linuxrc works and + other keywords, see <quote></link></quote> ): + </para> + + <table frame='top'> + <title>Keywords for <command>linuxrc</command></title> + <tgroup cols='2'> + <thead> + <row> + <entry>Keyword</entry> + <entry>Value</entry> + </row> + </thead> + + + <tbody> + + <row><entry>netdevice</entry><entry>Which network device to use for + network setup (Device used for &bootp; / &dhcp; requests)</entry></row> + <row><entry>server</entry><entry>Which server to contact for source directory (NFS Server)</entry></row> + <row><entry>serverdir</entry><entry>Directory on NFS Server </entry></row> + <row><entry>hostip</entry><entry>When empty, client sends &bootp; request, otherwise client is configured with entered IP configuration.</entry></row> + <row><entry>netmask</entry><entry>Netmask</entry></row> + <row><entry>gateway</entry><entry>Gateway</entry></row> + <row><entry>nameserver</entry><entry>Nameserver</entry></row> + <row><entry>insmod</entry><entry>Kernel modules to load.</entry></row> + <row> + <entry>autoyast</entry> + <entry>Location of the the control file to be used for the + automatic installation, i.e + <emphasis>autoyast=http://192.168.2.1/profiles/</emphasis></entry> + + </row> + <row> + <entry>install</entry> + <entry>Location of the installation directory, i.e. <emphasis>install=nfs://192.168.2.1/CDs/</emphasis> </entry> + </row> + <row> + <entry>instmode</entry> + <entry>Installation mode, i.e. nfs, http etc. (Not needed if + <emphasis>install</emphasis> is set)</entry> + </row> + <row> + <entry>y2confirm</entry> + <entry>even with <confirm>no</confirm> in the profile, the confirm proposal comes up. + This is available since SUSE Linux 10.1 / SLES10 + </entry> + </row> + </tbody> + </tgroup> + </table> + + + + <para> + These variables and keywords will bring the system up to the point + where &yast2; can take over with the main control file. Currently, the + source medium is + automatically discovered, which in some cases makes it possible to + initiate the auto-install process without giving any instructions to + linuxrc. + </para> + + <para> + The traditional <command>linuxrc</command> configuration file + (<filename>info</filename>) has the function of + giving the client enough information about the installation server and + the location of the sources. In most cases this file is not needed; it is however + needed in special network environments where &dhcp; / &bootp; are not + used or when special kernel modules have to be loaded. + </para> + <para> + All linuxrc keywords + can be passed to <command>linuxrc</command> using the kernel command + line. The command line can for example also be set when creating network boot-able + images or it can be passed to the kernel using a specially configured + &dhcp; server in combination with Etherboot or &pxe;. + </para> + <para> + The format of the special command line variable + <emphasis>autoyast</emphasis> can be used as described in table <quote></link></quote> + </para> + + <table frame='top' id="commandLineAutoYaST"> + <title id="commandLineAutoYaST.title">Command line variables for AutoYaST</title> + <tgroup cols='2'> + <thead> + <row> + <entry> + Command line variable + </entry><entry>Description</entry> + </row> + </thead> + <tbody> + <row><entry>autoyast=default</entry><entry>Default auto-installation option </entry></row> + <row><entry>autoyast=file://<path></entry><entry>Looks for + control file in specified path (relative to source root + directory, i.e. <emphasis>file:///autoinst.xml</emphasis> if in + the top directory of a CD-ROM and you did an installation from CD)</entry></row> + + <row> + <entry> + autoyast=device://<device>/<file></entry><entry>Looks + for control file on a storage device. (only device name needed + without full path, i.e. /dev/sda1 is wrong, instead use sda1). + Since openSUSE 11.2 (not SLES11) you can leave out the device to trigger + AutoYaST's search routine over all devices. (autoyast=device:///my.xml) + </entry> + </row> + + + <row> + <entry>autoyast=floppy://<path></entry> + <entry>Looks for control file in the floppy (Useful when booting + from CD). Since SLES10 SP1 and later the fallback is looking on USB devices too</entry> + </row> + <row> + <entry>autoyast=nfs://<server>/<path></entry> + <entry>Looks for control file on <server> </entry> + </row> + <row> + <entry>autoyast=http://[user:password@]<server>/<path>;</entry> + <entry>Retrieves the control file from a web server using the HTTP protocol.</entry> + </row> + <row> + <entry>autoyast=https://[user:password@]<server>/<path>;</entry> + <entry>Retrieves the control file from a web server using HTTPS (encrypted connection) protocol (possible since SL 10.1 and SLES10</entry> + </row> + <row> + <entry>autoyast=tftp://<server>/<path></entry> + <entry>Retrieve the control file with TFTP</entry> + </row> + <row> + <entry>autoyast=ftp://[user:password@]<server>/<path></entry> + <entry>Retrieve the control file with FTP</entry> + </row> + <row> + <entry>autoyast=usb://<path> (since SLES10 SP1)</entry> + <entry>Retrieve the control file from USB devices (autoyast will search on all USB devices it can find)</entry> + </row> + <row> + <entry>autoyast=relurl://<path> (since openSUSE 11.0)</entry> + <entry>Retrieve the control file from the installation source (install=....)</entry> + </row> + <row> + <entry>autoyast=slp (since openSUSE 11.2, not SLES 11)</entry> + <entry>Query the location of the profile from an SLP server (service:autoyast:...). Since openSUSE 11.3 you can add a "description=" attribute so you can "translate" the URL into something more readable</entry> + </row> + <row> + <entry>autoyast=cifs://<server>/<path> (since openSUSE 11.2, not SLES 11)</entry> + <entry>Looks for control file on <server> with CIFS</entry> + </row> + <row> + <entry>autoyast=label://<label>/<path> (since openSUSE 11.3, not SLES 11)</entry> + <entry>Looks for control file on a device that has the label</entry> + </row> + </tbody> + </tgroup> + </table> + <para> + Several scenarios for auto-installation are possible using different + types of infrastructure and source media. The simplest way is by using + the source media from the &company-suse; Box. In that case you have + either a DVD with all &company-suse; packages or a set of CD-ROMs. To initiate the + auto-installation process however, the auto-installation command line + variable should be entered at system boot-up and the control file should + be accessible to YaST2. The following list of scenarios explains how + the control file can be supplied and the setup needed for the + auto-installation process to be successful. + </para> + <itemizedlist> + <listitem> + <para> + Using &company-suse; original CD-ROMs from &company-suse; Linux box: + </para> + <para> + To use the original CD-ROMs, you need a media with the control + file, the control file can reside on the following locations: + </para> + <orderedlist> + <listitem> + <para> + <emphasis>Floppy</emphasis>: Control file accessible via the + <emphasis>autoyast=floppy</emphasis> option. &yast2; also searches + upon startup for a file named + <filename>autoinst.xml</filename>. If such a file is found, YaST2 + will switch into auto-installation mode even if no special + command line variables were supplied. (See <quote></link></quote> ) + </para> + </listitem> + <listitem> + <para> + <emphasis>Network</emphasis>: Control file accessible via the + <emphasis>autoyast=nfs://..</emphasis>, + <emphasis>autoyast=ftp://..</emphasis> + <emphasis>autoyast=http://..</emphasis> or + <emphasis>autoyast=tftp://..</emphasis> options. + </para> + </listitem> + + </orderedlist> + </listitem> + <listitem> + <para> + Using 'self-made' CD-ROMs: + </para> + <para> + In this case, you can include the control file on the CD-ROM + for easy access (using the <emphasis>autoyast=file://</emphasis> + option) or use one of the above mentioned methods used with the + original &company-suse; CD-ROMs. + </para> + <para> + Using CD-ROMs for autoinstallation, it is required to instruct the + installer to use the CD-ROM for installation and not try to find + the installation files on the network. This can be accomplished by + adding the <emphasis>instmode=cd</emphasis> option to the kernel + command line (this can be done by adding the option to the + isolinux.cfg file on the CD). + </para> + </listitem> + <listitem> + <para> + Using NFS and Floppy, Network or CD-ROM for system boot-up. + </para> + <para> + This option is the most important one due to the fact that + installations of PC farms are normally done using NFS servers and other + network services like &bootp; / &dhcp; . The control file can reside in + the following places: + </para> + <orderedlist> + <listitem> + <para> + <emphasis>Floppy/CD-ROM</emphasis>: Control file accessible via the + <emphasis>autoyast=file://..</emphasis> option. + </para> + </listitem> + <listitem> + <para> + <emphasis>Network</emphasis>: Control file accessible via the + <emphasis>autoyast=http://..</emphasis>, + <emphasis>autoyast=ftp://..</emphasis>, + <emphasis>autoyast=nfs://..</emphasis> or + <emphasis>autoyast=tftp://..</emphasis> options. + </para> + </listitem> + + </orderedlist> + </listitem> + + </itemizedlist> + + <note> + <title>Disabling network and DHCP</title> + <para>To disable network during installations where network is not + needed or not available, for example when auto-installing from + CD-ROMs use the linuxrc option <emphasis>netsetup</emphasis> to + set network configuration behavior. To disable network setup use + <emphasis>netsetup=0</emphasis> </para> + </note> + + + <para> + If <emphasis>autoyast=default</emphasis> is defined, &yast2; will look + for a file named <filename>autoinst.xml</filename> in + the following three places: + </para> + <orderedlist> + <listitem> + <para> + The root directory of the floppy disk. + </para> + </listitem> + <listitem> + <para> + The root directory of the installation medium. + </para> + </listitem> + <listitem> + <para> + The root directory of the initial ram disk used to boot the system. + </para> + </listitem> + </orderedlist> + + <para> + With all autoyast invocation options, excluding + <emphasis>default</emphasis>, it is possible to specify the location of + the control file in the following ways: + </para> + + <orderedlist numeration="arabic"> + <listitem> + <para> + Specify the exact location of the control file: + <screen> +autoyast=http://192.168.1.1/control-files/client01.xml + </screen> + </para> + </listitem> + <listitem> + <para> + Specify a directory where several control files are located + </para> + <screen> +autoyast=http://192.168.1.1/control-files/ + </screen> + <para> + In this case the relevant control file is retrieved using the hex digit + representation of the IP as described below. + </para> + </listitem> + </orderedlist> + <para> + If only the path prefix variable is defined, &yast2; will fetch the + control file from the specified location in the following way: + </para> + <orderedlist numeration="arabic"> + <listitem> + <para> + First, it will search for the control file using its own IP address in + upper case hexadecimal, e.g. <emphasis>192.0.2.91 -> C000025B</emphasis>. + </para> + </listitem> + <listitem> + <para> + If that file is not found, it will remove one hex digit and try + again. This action is repeated till the file with the correct name + is found. Ultimately, it will try looking for a file with the MAC + address of the clients as the file name (mac should have the + following syntax: <emphasis>0080C8F6484C</emphasis>) and if not found a file named + <filename>default</filename> (in lower + case). + </para> + </listitem> + </orderedlist> + + <para> + As an example, for 192.0.2.91, the HTTP client will try: + </para> + <literallayout> +C000025B +C000025 +C00002 +C0000 +C000 +C00 +C0 +C +0080C8F6484C +default + </literallayout> + <para> + in that order. + </para> + <para> + To determine the hex representation of the IP address of the client, + use the utility called <command>/usr/sbin/gethostip</command> available + with the <emphasis>syslinux</emphasis> package. + </para> + <example> + <title>Determine HEX code for an IP address</title> + <screen> +# /usr/sbin/gethostip 10.10.0.1 +10.10.0.1 10.10.0.1 0A0A0001 + </screen> + </example> + + + + </section> + + <section id="autoinstall.singlesystem"> + <title id="autoinstall.singlesystem.title"> + Auto-installing a Single System + </title> + <para> + The easiest way to auto-install a system without any network connection + is by using the standard CD-ROMs that come in the &company-suse; Linux box. Using the + CD-ROMs in combination with a floppy disk lets you getting started with + &autoyast2; very fast and without spending much time configuring + installation server and network environments. + </para> + + + <para> + Create the control file and + name it <filename>autoinst.xml</filename>. Copy the file + <filename>autoinst.xml</filename> to a floppy by either mounting the + floppy or by using the <emphasis>mtools</emphasis>. + </para> + <screen> +mcopy autoinst.xml a: + </screen> + + </section> + + + <section> + <title>Combining linuxrc <emphasis>info</emphasis> file with &yast2; control file</title> + <para> + If you choose to pass information to <emphasis>linuxrc</emphasis> using + the <emphasis>info</emphasis> file, it is possible to integrate the + keywords in the XML control file. In the case the file has to be + accessible to linuxrc and has to be named <emphasis>info</emphasis>. + </para> + <para> + Linuxrc will look for a string (<emphasis>start_linuxrc_conf</emphasis> + in the control file which represents the + beginning of the file. If it is found, it will parse the content starting + from that string and will finish when the string + <emphasis>end_linuxrc_conf</emphasis> is found. The options are stored in + the control file in the following way: + </para> + <example> + <title> + Linxurc options in the control file + </title> + <screen> + <![CDATA[ +.... + <install> +.... + <init> + <info_file> +<![CDATA[ +# +# Don't remove the following line: +# start_linuxrc_conf +# +install: nfs://192.168.1.1/CDs/full-i386 +textmode: 1 +autoyast: file:///info + +# end_linuxrc_conf +# Do not remove the above comment +# +]]]><![CDATA[]> + + </info_file> + </init> +...... + </install> +.... +]]> + </screen> + </example> + <para> + Note that the autoyast keyword must point to the same file, i.e. if it + is on a floppy, then the protocol <emphasis>floppy</emphasis> has to be + used. In other cases where the <emphasis>info</emphasis> file is stored + in the initial ram-disk, the <emphasis>file</emphasis> option has to be used. + </para> + </section> + </section> + <section id="System_Configuration"> + <title id="System_Configuration.title"> + System Configuration + </title> + <para> + The system configuration during auto-installation can be seen as the + most important part of the whole process. Customizing a system to your + environment needs is what makes an auto-installation system attractive, + not the installation part. + </para> + <para> + As you have seen in the previous chapters, almost anything can be + configured automatically on the target system. In addition to the + pre-defined directives, you can always use post-scripts to change other + things in the system. Additionally you can change any system variables and + if required, copy complete configuration files into the target system. + </para> + <section> + <title> + Post-Install and System Configuration + </title> + <para> + The Post-Installation and the System Configuration are initiated directly after the last + package is installed in the target system and is continued after the + system has booted for the first time. + </para> + <para> + Before the system is booted for the first time, &yast2; writes all data + collected during installation into the system and finally it writes the + boot loader in the specified location. In addition to these regular + tasks, which are also done when performing a regular installation, YaST2 + executes the <emphasis>chroot-scripts</emphasis> as specified in the + control file. Note that these scripts are executed while the system is + still not mounted. + </para> + <para> + If a different kernel than the default is installed, a hard reboot will + be required. A hard reboot can also be forced during auto-installation, + independent of the installed kernel. This can be accomplished using the + <emphasis>reboot</emphasis> property of the + <emphasis>general</emphasis> resource. (See General Options</link>) + </para> + </section> + <section> + <title>System Customization</title> + <para> + Most of the system customization is done in the second stage of the + installation. &yast2; provides most of the important resources needed to + bring up a system to a usable , general state. However, you may have + other requirements for the installed system. If the required + customizations can't be done using &yast2; resources, then the + post-install scripts can be used to accomplish this task. + </para> + <para> + You can define an unlimited number of custom scripts in the control + file either by editing the control file or by using the configuration + system. + </para> + </section> + </section> + + </chapter> + + + + + + <!-- + Local Variables: + mode: xml + sgml-parent-document: ("autoyast.xml" "book" "chapter") + End: + --> Added: trunk/autoinstallation/doc/xml/Introduction.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Introduction.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/Introduction.xml (added) +++ trunk/autoinstallation/doc/xml/Introduction.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,161 @@ + <chapter id="introduction"> + <title>Introduction</title> + + <para> + &autoyast2; is a system for installing one or more SuSE Linux systems + automatically and without user intervention. &autoyast2; installations + are performed using an autoyast profile with installation and configuration + data. That profile can be created using the configuration insterface + of &autoyast2; and can be provided to &yast2; during installation in + different ways. + </para> + + <section id="avail"> + <title>Availability</title> + <para> + &autoyast2; is available with recent &company-suse; products starting + from <emphasis>SuSE Linux 8.0</emphasis> and business products starting from + <emphasis>SLES 8</emphasis>. + </para> + <para>Products prior to SuSE Linux 8.0 and business products based + on <emphasis>SLES 7</emphasis> have an auto-installation + system based on <emphasis>YaST1</emphasis>. A configuration management + system is provided by <emphasis>ALICE</emphasis> for these products. + </para> + <note> + <title>Updated documentation</title> + <para>Updated documentation can always be found at the following URL: + <ulink url="http://www.suse.com/~ug">http://www.suse.com/~ug</ulink></para> + </note> + </section> + + + <section id="motiv"> + <title>Motivation</title> + <para> + The <ulink url="http://www.linuxjournal.com/">Linux Journal</ulink>, in + an article in http://www.linuxjournal.com/categories.php?op=newindex&catid=178">issue 78</ulink> writes: + </para> + <para> + <quote> + A standard Linux installation asks many questions about what to + install, what hardware to configure, how to configure the network + interface, etc. Answering these questions once is informative and maybe + even fun. But imagine a system engineer who has to set up a new Linux + network with a large number of machines. Now, the same issues need to + be addressed and the same questions answered repeatedly. This makes the + task very inefficient, not to mention a source of irritation and + boredom. Hence, a need arises to automate this parameter and option + selection.</quote> + </para> + <para> + <quote>The thought of simply copying the hard disks naturally crosses one's + mind. This can be done quickly, and all the necessary functions and + software will be copied without option selection. However, the fact is + that simple copying of hard disks causes the individual computers to + become too similar. This, in turn, creates an altogether new mission of + having to reconfigure the individual settings on each PC. For example, + IP addresses for each machine will have to be reset. If this is not + done properly, strange and inexplicable behavior results.</quote> + </para> + + <para> + Regular installation of SuSE Linux is semi-automated by default. The user is + requested to select the necessary information at the beginning of the + installation (In most cases language only), &yast2; then generates a + proposal for the underlying system depending on different factors and + system paramters. In + most cases, and especially for new systems, such a proposal can be + used to install the system and provides a usable installation. + </para> + <para> + The steps following the proposal are fully automated and the user is only + prompted at the end of the installation to configure hardware and network services. + </para> + <para> + &autoyast2; can be used where no user intervention is required or + where customization is required. Using an autoyast profile, &yast2; + prepares the system for a custom installation and avoids any + interaction with the user, unless specified in the file + controling the installation. + </para> + <para> + &autoyast2; is not an automated GUI system. This means that in most + cases many screen will be skipped, i.e. you will never see the language + selection interface. &autoyast2; will simply pass the language + parameter to the sub-system without displaying any language related + interface. + </para> + + </section> + + <section id="overviewandconcept"> + <title>Overview and Concept</title> + <para> + Using &autoyast2;, multiple systems sharing the same environment and + similar but not necesserily identical hardware performing similar + tasks can easily be installed in parallel and in a short time. A + configuration file (referred to as "autoyast profile") is created using + existing configuration resources. The profile file can be easily + tailored for any specific environment. + </para> + + + <para> + Unlike autoinstallation systems available with older &company-suse; + releases, &autoyast2; is fully integrated and provides various options for + installing and configuring a system. The main advantage over older + systems and other auto-installation systems is the possibility to configure a + computer by using existing modules and avoiding using custom scripts which + are normally executed at the end of the installation. + </para> + + <para> + This document will guide you through the three steps of auto-installation: + </para> + <itemizedlist> + <listitem> + <para> + Preparation: All relevant information about the target system are + collected and turned into the appropriate directives of the profile. + The profile file is transferred onto the target system where + its directives will be parsed and transformed to &yast2; conforming + data. </para> + </listitem> + <listitem> + <para> + Installation: follows the instructions given in the profile and + installs the base system. + </para> + </listitem> + <listitem> + <para> + Configuration: &yast2; in addition to user-defined post-install + scripts complete the system configuration + </para> + </listitem> + </itemizedlist> + <para> + The complete and detailed process is illustrated in the following figure: + </para> + + <?anas-pagebreak?> + <figure id="process"> + <title id="process.title">Auto-installation process</title> + <mediaobject>&autoyast-oview;</mediaobject> + </figure> + </section> + + + </chapter> + + + + <!-- + Local Variables: + mode: xml + sgml-parent-document: ("autoyast.xml" "book" "book") + End: + --> + Added: trunk/autoinstallation/doc/xml/KDumpSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/KDumpSection.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/KDumpSection.xml (added) +++ trunk/autoinstallation/doc/xml/KDumpSection.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,576 @@ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ + +<!ENTITY % images SYSTEM "images.ent"> +%images; + +<!ENTITY % entities SYSTEM "entities/en.ent"> +%entities; + +<!-- Examples --> +<!ENTITY % examples SYSTEM "examples.ent"> +%examples; + +<!-- components --> +<!ENTITY % components SYSTEM "components.ent"> +%components; + +]> + + <!-- {{{ Kdump --> + + <section id="CreateProfile.kdump"> + <title> + Kernel dumps + </title> + + <note> + This feature is only available since SLES 11 (not openSUSE 11.1). It is not available + on the <emphasis>zSeries</emphasis> (<emphasis>s390x</emphasis>) architecture! + </note> + + <para> + With kdump the system is able to create crashdump files if the whole system (i.e., the + kernel) crashes. That crash dump files contain the memory contents while the system crashed. + Such core files can be analyzed later by the support or a (kernel) developer to find the + reason why the system crashed. It's mostly useful for servers where you cannot + easily reproduce such crashes on another system and where it's important that the + problem gets fixed. + </para> + + <para> + The only downside of enabling kdump is that this costs you between 64 MiB and + 128 MiB of System RAM (on "normal" sized systems) that needs to be reserved to + be used by kdump in the case the system crashes and the dump needs to be generated. + </para> + + <para>This section only describes how to setup kdump with &autoyast;. It does not describe + how kdump works in general and also does not describe each small detail. Refer to + the kdump(7) manual page which is in the package named <emphasis>kdump</emphasis> or to + the <ulink url="http://en.opensuse.org/Kdump">openSUSE Kdump documentation</ulink>. + </para> + + <para> + At first, let's present an overall example for the kdump configuration: + </para> + + &example.kdump; + + <!-- {{{ Memory Reservation --> + <section id="CreateProfile.kdump.reservation"> + <title>Memory Reservation</title> + + <para> + As already mentioned above, it's necessary to reserve some memory at bootup for + kdump. Because that memory must be reserved very early during the boot process, + the configuration is done via a kernel command line parameter called + <literal>crashkernel</literal>. That memory will be used to load a second kernel + in that memory that will be executed without rebooting if the first kernel + crashes. That kernel also has a special initrd which contains all programs + that are necessary to save the dump to network or disk, send the notification + email and finally reboot. + </para> + + <para> + You can enable or disable that the <literal>crashkernel</literal> parameter is + written for the default boot kernel with the <literal>add_crash_kernel</literal> + tag and you can specify the value of the <literal>crashkernel</literal> parameter + using the <literal>crash_kernel</literal> tag. + </para> + + <para> + For the memory reservation there are two things to specify: The <emphasis>amount</emphasis> + of reserved memory (such as <literal>64M</literal> to reserve 64 MiB of memory from + the RAM) and the <emphasis>offset</emphasis>. The syntax is + <literal>crashkernel=AMOUNT@OFFSET</literal>. Luckily the kernel is able to auto-detect the + right offset for you nowadays (with the exception of the Xen hypervisor where you have to + specify <emphasis>16M</emphasis> as offset), so you don't have to worry about that too much. + You can just specify <literal><crash_kernel>crashkernel=64M</crash_kernel></literal> + and the right thing will happen. + </para> + + <para> + For the <emphasis>amount</emphasis> of memory, following values are recommended: + </para> + + <para> + <table frame="top"> + <title>Recommended values for the reserved memory amount</title> + <tgroup cols="2"> + <thead> + <row> + <entry>Platform</entry> + <entry>Recommended values</entry> + </row> + </thead> + <tbody> + <row> + <entry> + i386 and x86-64 + </entry> + <entry> + <literal>64M</literal> for small machines (about 2 GiB of RAM, 4 cores) + and <literal>128M</literal> for larger machines + </entry> + </row> + </tbody> + <tbody> + <row> + <entry> + PPC64 + </entry> + <entry> + <literal>128M</literal> for small machines + and <literal>256M</literal> for larger machines + </entry> + </row> + </tbody> + <tbody> + <row> + <entry> + IA64 + </entry> + <entry> + <literal>256M</literal> for small machines, + <literal>512M</literal> for medium machines and + <literal>1G</literal> and more for really large machines + (mostly SGI Altix systems) + </entry> + </row> + </tbody> + </tgroup> + </table> + </para> + + <para> + To make things even more complicated, there's a so-called <emphasis>extended + command line syntax</emphasis> where you can specify the amount of reserved + memory dependent of the System RAM. That is good if you share one &autoyast; + profile for multiple installations or when you often remove or install memory + on one machine. The syntax is: + </para> + + <para> + <screen>BEGIN_RANGE_1-END_RANGE_1:AMOUNT_1,BEGIN_RANGE_2-END_RANGE_2:AMOUNT_2@OFFSET</screen> + </para> + + <para> + In that syntax <literal>BEGIN_RANGE_1</literal> is the start of the first + memory range (for example: <literal>0M</literal>) and <literal>END_RANGE_1</literal> + is the end of the first memory range (and can be empty in case "infinity" should + be assumed) and so on. So for example + <literal>256M-2G:64M,2G-:128M</literal> means to reserve 64 MiB of crashkernel + memory when the system has between 256 MiB and 2 GiB RAM and to reserve + 128 MiB of crashkernel memory when the system has above 2 GiB RAM. + </para> + + <para> + The following table contains the settings that are necessary for the + memory reservation: + </para> + + <para> + <table frame='top'> + <title>XML representation of the memory reservation settings</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>add_crash_kernel</entry> + <entry>If the memory should be reserved, that basically enables or disables kdump. + <para><screen><add_crash_kernel config:type="boolean">true</add_crash_kernel></screen></para></entry> + <entry>required</entry> + </row> + <row> + <entry>crash_kernel</entry> + <entry>The syntax of the crashkernel command line as discussed above. + <para><screen><crash_kernel>256M:64M</crash_kernel></screen></para></entry> + <entry>required</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + <!-- }}} --> + + <!-- {{{ Dump Saving --> + <section id="CreateProfile.kdump.saving"> + <title> + Dump Saving + </title> + + <!-- {{{ Target --> + <section id="CreateProfile.kdump.saving.target"> + <title> + Target + </title> + + <para> + The element <literal>KDUMP_SAVEDIR</literal> holds an URL to where the dump + is saved. Following methods are possible: + </para> + + <itemizedlist mark='opencircle'> + <listitem> + <para> + <literal>file</literal> to save to the local disk + </para> + </listitem> + <listitem> + <para> + <literal>ftp</literal> to save to an FTP server (without encryption) + </para> + </listitem> + <listitem> + <para> + <literal>sftp</literal> to save to an SSH2 SFTP server + </para> + </listitem> + <listitem> + <para> + <literal>nfs</literal> to save to a NFS location and + </para> + </listitem> + <listitem> + <para> + <literal>cifs</literal> to save the dump to a CIFS/SMP export from Samba or Microsoft Windows. + </para> + </listitem> + </itemizedlist> + + <para> + For details see the kdump(5) manual page. Two examples are: + <literal>file:///var/crash</literal> (which is the default location + according to FHS) and <literal>ftp://user:password@host:port/incoming/dumps</literal>. + Below that directory, a directory name that contains a time stamp will be created + in which the dumps are saved. + </para> + + <para> + When the dump is saved to the local disk, <literal>KDUMP_KEEP_OLD_DUMPS</literal> + can be used to delete old dumps automatically. This setting takes a number that + specifies how much old dumps should be kept. If the partition has less than + <literal>KDUMP_FREE_DISK_SIZE</literal> megabytes free disk space after saving the + dump, the dump is not copied at all. + </para> + + <para> + If you would not like only to save the dump but also the whole kernel and + (if installed) the debug information of the kernel to that directory to have + everything you need (except all kernel modules and the debugging information + of all kernel modules) to analyze the dump in one directory, you can set + <literal>KDUMP_COPY_KERNEL</literal> to <literal>true</literal>. + </para> + </section> + <!-- }}} --> + <!-- {{{ Filtering and Compression --> + <section id="CreateProfile.kdump.saving.compression"> + <title> + Filtering and Compression + </title> + + <para> + The size of kernel dumps is uncompressed and unfiltered as large as your system has RAM. + To get smaller files (for example, to send it to support), you can compress the whole + dump file afterwards. However, the drawback is that the dump has to be uncompressed + afterwards before opening, so the disk space needs to be there in any case. + </para> + + <para> + To use page compression which compresses every page and allows dynamic decompression + with the crash(8) debugging tool, set <literal>KDUMP_DUMPFORMAT</literal> to + <literal>compressed</literal> (which is actually the default). + </para> + + <para> + To filter the dump, you have to set the <literal>KDUMP_DUMPLEVEL</literal>. Then not all + memory is saved to disk but only memory that does not fulfill some criteria. I.e. you + may want to leave out pages that are completely filled by zeroes as they don't + contain any useful information. 0 produces a full dump and 31 is the smallest dump. + The manual page kdump(5) and makedumpfile(8) contain a table that lists for + each value which pages will be saved. + </para> + + </section> + <!-- }}} --> + <!-- {{{ Table --> + <section id="CreateProfile.kdump.saving.summary"> + <title> + Summary + </title> + <para> + <table frame='top'> + <title>XML representation of the dump target settings</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>KDUMP_SAVEDIR</entry> + <entry>An URL that specifies the target to which the dump and related files will be saved. + <para><screen><KDUMP_SAVEDRIR>file:///var/crash/</KDUMP_SAVEDIR></screen></para></entry> + <entry>required</entry> + </row> + <row> + <entry>KDUMP_COPY_KERNEL</entry> + <entry>If not only the dump itself should be saved to <literal>KDUMP_SAVEDIR</literal> but + also the kernel and its debugging information (if installed). + <para><screen><KDUMP_COPY_KERNEL>false</KDUMP_COPY_KERNEL></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>KDUMP_FREE_DISK_SIZE</entry> + <entry> + The number of megabytes that should always be free after saving the dump. If that + space would be below that value, the dump will not be copied. + <para><screen><KDUMP_FREE_DISK_SIZE>64</KDUMP_FREE_DISK_SIZE></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>KDUMP_KEEP_OLD_DUMPS</entry> + <entry> + The number of dumps that are kept (i.e., not deleted) if <literal>KDUMP_SAVEDIR</literal> + points to a local directory. Specify 0 if you don't want to delete dumps at all and + specify -1 if all dumps (except the one that is just saved) should be deleted. + <para><screen><KDUMP_KEEP_OLD_DUMPS>4</KDUMP_KEEP_OLD_DUMPS></screen></para></entry> + <entry>optional</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + <!-- }}} --> + + </section> + <!-- }}} --> + <!-- {{{ Email Notification --> + <section id="CreateProfile.kdump.notification"> + <title> + Email Notification + </title> + + <para> + It's useful to get notified via email that a machine has crashed and a dump has been + saved. That way you can for example setup a dump server in a company and trigger + some actions by that email automatically like calling the administrator from home + to check if everything runs again. + </para> + + <para> + Because the dump is saved in a special initrd environment, we cannot use a local + mail server just to send that notification email. However, it's better to send + that email in the initrd just because it's more likely that we have a working network + connection here (which we need in the netdump case to save the dump away anyway) + compared that the server comes up again and everything is working. + </para> + + <para>You have to provide at least exactly one address in + <literal>KDUMP_NOTIFICATION_TO</literal> and zero, one or more addresses + in <literal>KDUMP_NOTIFICATION_CC</literal>. Please note that you can only + specify the address here, not a real name or some other fancy stuff. + </para> + + <para> + To actually send the email, we need <literal>KDUMP_SMTP_SERVER</literal> and + (if the server needs authentication) <literal>KDUMP_SMTP_USER</literal> and + <literal>KDUMP_SMTP_PASSWORD</literal>. Please note that TSL or SSL are not supported. + That may be added in future. + </para> + + <para> + <!-- {{{ Table: XML representation of the email notification settings --> + <table frame='top'> + <title>XML representation of the email notification settings</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>KDUMP_NOTIFICATION_TO</entry> + <entry>Exactly one email address (and only an address) to which the mail + should be sent. Additional recipients can be specified in + <literal>KDUMP_NOTIFICATION_CC</literal>. + <para><screen><KDUMP_NOTIFICATION_TO>bwalle@suse.de</KDUMP_NOTIFICATION_TO></screen></para></entry> + <entry>optional (email notification is disabled if empty)</entry> + </row> + <row> + <entry>KDUMP_NOTIFICATION_CC</entry> + <entry>Zero, one or more recipients that are in the Cc line of the notification mail. + <para><screen><KDUMP_NOTIFICATION_CC>spam@suse.de devnull@suse.de</KDUMP_NOTIFICATION_CC></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>KDUMP_SMTP_SERVER</entry> + <entry> + Host name of the SMTP server that will be used for the mail delivery. Please note + that the SMTP authentication is supported (see <literal>KDUMP_SMTP_USER</literal> + and <literal>KDUMP_SMTP_PASSWORD</literal>) but TSL and SSL are <emphasis>not</emphasis> + supported. + <para><screen><KDUMP_SMTP_SERVER>email.suse.de</KDUMP_SMTP_SERVER></screen></para></entry> + <entry>optional (email notification is disabled if empty)</entry> + </row> + <row> + <entry>KDUMP_SMTP_USER</entry> + <entry> + User name that is used together with <literal>KDUMP_SMTP_PASSWORD</literal> + for SMTP authentication. + <para><screen><KDUMP_SMTP_USER>bwalle</KDUMP_SMTP_USER></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>KDUMP_SMTP_PASSWORD</entry> + <entry> + Password that is used together with <literal>KDUMP_SMTP_USER</literal> + for SMTP authentication. + <para><screen><KDUMP_SMTP_PASSWORD>geheim</KDUMP_SMTP_PASSWORD></screen></para></entry> + <entry>optional</entry> + </row> + </tbody> + </tgroup> + </table> + <!-- }}} --> + </para> + </section> + <!-- }}} --> + <!-- {{{ Kdump kernel settings --> + <section id="CreateProfile.kdump.kernel"> + <title> + Kdump kernel settings + </title> + + <para> + As already mentioned, a special kernel is booted to save the dump. + If you don't want to use the auto-detection mechanism to find out which kernel + is used (see the kdump(5) manual page that describes the algorithm which + is used to find the kernel), you can specify the version of a custom kernel + in <literal>KDUMP_KERNELVER</literal>. If you set that to + <literal>foo</literal>, then the kernel located in + <filename>/boot/vmlinuz-foo</filename> or <filename>/boot/vmlinux-foo</filename> + (in that order on platforms that have a <filename>vmlinuz</filename> file) + will be used. + </para> + + <para> + You can even specify the command line which will be used to boot the kdump kernel. + Normally the boot command line is used minus some settings that hurt in the + kdump case (like the <literal>crashkernel</literal> parameter itself) plus + some settings that are needed in the kdump case (see the manual page kdump(5)). + If you just want some additional parameters like a overwritten console setting + then use <literal>KDUMP_COMMANDLINE_APPEND</literal>. If you know what you're doing + and you want to specify the whole command line, set <literal>KDUMP_COMMANDLINE</literal>. + </para> + + <para> + <!-- {{{ Table: XML representation of the kernel settings --> + <table frame='top'> + <title>XML representation of the kernel settings</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>KDUMP_KERNELVER</entry> + <entry>Version string for the kernel that will be used for kdump. Leave it + empty to use the auto-detection mechanism (strongly recommended). + <para><screen><KDUMP_KERNELVER>2.6.27-default</KDUMP_KERNELVER></screen></para></entry> + <entry>optional (auto-detection if empty)</entry> + </row> + <row> + <entry>KDUMP_COMMANDLINE_APPEND</entry> + <entry>Additional command line parameters for the kdump kernel. + <para><screen><KDUMP_COMMANDLINE_APPEND>console=ttyS0,57600</KDUMP_COMMANDLINE_APPEND></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>KDUMP_COMMANDLINE</entry> + <entry> + Overwrite the automatically generated kdump command line. Use with care. + Normally <literal>KDUMP_COMMANDLINE_APPEND</literal> is the setting you're + looking for. + <para><screen><KDUMP_COMMANDLINE_APPEND>root=/dev/sda5 maxcpus=1 irqpoll</KDUMP_COMMANDLINE></screen></para></entry> + <entry>optional (email notification is disabled if empty)</entry> + </row> + </tbody> + </tgroup> + </table> + <!-- }}} --> + </para> + </section> + <!-- }}} --> + <!-- {{{ Expert settings --> + <section id="CreateProfile.kdump.expert"> + <title> + Expert settings + </title> + + <para> + <!-- {{{ Table: XML representation of the expert settings --> + <table frame='top'> + <title>XML representation of the expert settings</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>KDUMP_IMMEDIATE_REBOOT</entry> + <entry><literal>true</literal> if the system should be rebooted automatically + after the dump has been saved, <literal>false</literal> otherwise. The default + is to reboot the system automatically. + <para><screen><KDUMP_IMMEDIATE_REBOOT>true</KDUMP_IMMEDIATE_REBOOT></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>KDUMP_VERBOSE</entry> + <entry>Bitmask that specifies how to verbose the kdump process should be. + Read kdump(5) for details. + <para><screen><KDUMP_VERBOSE>3</KDUMP_VERBOSE></screen></para></entry> + <entry>optional</entry> + </row> + <row> + <entry>KEXEC_OPTIONS</entry> + <entry>Additional options that are passed to <application>kexec</application> + when loading the kdump kernel. Normally empty. + <para><screen><KEXEC_OPTIONS>--noio</KEXEC_OPTIONS></screen></para></entry> + <entry>optional</entry> + </row> + </tbody> + </tgroup> + </table> + <!-- }}} --> + </para> + + </section> + <!-- }}} --> + + </section> + <!-- }}} --> + + Added: trunk/autoinstallation/doc/xml/LDAPSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/LDAPSection.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/LDAPSection.xml (added) +++ trunk/autoinstallation/doc/xml/LDAPSection.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,35 @@ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ + +<!ENTITY % images SYSTEM "images.ent"> +%images; + +<!ENTITY % entities SYSTEM "entities/en.ent"> +%entities; + +<!-- Examples --> +<!ENTITY % examples SYSTEM "examples.ent"> +%examples; + +<!-- components --> +<!ENTITY % components SYSTEM "components.ent"> +%components; + +]> + <section id="Configuration.Network.LDAP"> + <title> + &ldap; client + </title> + <para> + The installed machine can be set up as an + <emphasis>> &ldap; client</emphasis> to authenticate users with an + OpenLDAP; server. Required data are the name of the search base (base DN, e.g, dc=mydomain,dc=com) + and the IP address of the &ldap; server (e.g., 10.20.0.2). + </para> + <para> + If &ldap; is activated, <emphasis>NSS</emphasis> and <emphasis>PAM</emphasis> + will be configured accordingly to use &ldap; for user authentication. + </para> + &example.ldapclient; + </section> + Added: trunk/autoinstallation/doc/xml/MailSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/MailSection.xml?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/MailSection.xml (added) +++ trunk/autoinstallation/doc/xml/MailSection.xml Mon Aug 8 14:12:13 2011 @@ -0,0 +1,38 @@ +<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ + +<!ENTITY % images SYSTEM "images.ent"> +%images; + +<!ENTITY % entities SYSTEM "entities/en.ent"> +%entities; + +<!-- Examples --> +<!ENTITY % examples SYSTEM "examples.ent"> +%examples; + +<!-- components --> +<!ENTITY % components SYSTEM "components.ent"> +%components; + +]> + <section id='Configuration.Network.Sendmail'> + <title> + Mail Configuration (Sendmail or Postfix) + </title> + <para> + For the mail configuration of the client this + module lets you create a detailed mail configuration. The module + contains various options and it is recommended to use it at least for + the initial configuration. + + </para> + <example> + <title>Mail Configuration</title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> +</example> + </section> + Added: trunk/autoinstallation/doc/xml/Makefile URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/xml/Makefile?rev=65274&view=auto ============================================================================== --- trunk/autoinstallation/doc/xml/Makefile (added) +++ trunk/autoinstallation/doc/xml/Makefile Mon Aug 8 14:12:13 2011 @@ -0,0 +1,730 @@ +# Makefile.in generated by automake 1.11.1 from Makefile.am. +# doc/xml/Makefile. Generated from Makefile.in by configure. + +# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002, +# 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation, +# Inc. +# This Makefile.in is free software; the Free Software Foundation +# gives unlimited permission to copy and/or distribute it, +# with or without modifications, as long as this notice is preserved. + +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY, to the extent permitted by law; without +# even the implied warranty of MERCHANTABILITY or FITNESS FOR A +# PARTICULAR PURPOSE. + + + +# +# Makefile.am for y2c_autoinst/doc +# +# $Id: Makefile.am 63765 2011-04-11 15:40:31Z ug $ +# + + +pkgdatadir = $(datadir)/autoyast2 +pkgincludedir = $(includedir)/autoyast2 +pkglibdir = $(libdir)/autoyast2 +pkglibexecdir = $(libexecdir)/autoyast2 +am__cd = CDPATH="$${ZSH_VERSION+.}$(PATH_SEPARATOR)" && cd +install_sh_DATA = $(install_sh) -c -m 644 +install_sh_PROGRAM = $(install_sh) -c +install_sh_SCRIPT = $(install_sh) -c +INSTALL_HEADER = $(INSTALL_DATA) +transform = $(program_transform_name) +NORMAL_INSTALL = : +PRE_INSTALL = : +POST_INSTALL = : +NORMAL_UNINSTALL = : +PRE_UNINSTALL = : +POST_UNINSTALL = : +build_triplet = x86_64-suse-linux-gnu +host_triplet = x86_64-suse-linux-gnu +target_triplet = x86_64-suse-linux-gnu +subdir = doc/xml +DIST_COMMON = $(srcdir)/Makefile.am $(srcdir)/Makefile.in +ACLOCAL_M4 = $(top_srcdir)/aclocal.m4 +am__aclocal_m4_deps = $(top_srcdir)/configure.in +am__configure_deps = $(am__aclocal_m4_deps) $(CONFIGURE_DEPENDENCIES) \ + $(ACLOCAL_M4) +mkinstalldirs = $(install_sh) -d +CONFIG_CLEAN_FILES = +CONFIG_CLEAN_VPATH_FILES = +SOURCES = +DIST_SOURCES = +RECURSIVE_TARGETS = all-recursive check-recursive dvi-recursive \ + html-recursive info-recursive install-data-recursive \ + install-dvi-recursive install-exec-recursive \ + install-html-recursive install-info-recursive \ + install-pdf-recursive install-ps-recursive install-recursive \ + installcheck-recursive installdirs-recursive pdf-recursive \ + ps-recursive uninstall-recursive +am__vpath_adj_setup = srcdirstrip=`echo "$(srcdir)" | sed 's|.|.|g'`; +am__vpath_adj = case $$p in \ + $(srcdir)/*) f=`echo "$$p" | sed "s|^$$srcdirstrip/||"`;; \ + *) f=$$p;; \ + esac; +am__strip_dir = f=`echo $$p | sed -e 's|^.*/||'`; +am__install_max = 40 +am__nobase_strip_setup = \ + srcdirstrip=`echo "$(srcdir)" | sed 's/[].[^$$\\*|]/\\\\&/g'` +am__nobase_strip = \ + for p in $$list; do echo "$$p"; done | sed -e "s|$$srcdirstrip/||" +am__nobase_list = $(am__nobase_strip_setup); \ + for p in $$list; do echo "$$p $$p"; done | \ + sed "s| $$srcdirstrip/| |;"' / .*\//!s/ .*/ ./; s,\( .*\)/[^/]*$$,\1,' | \ + $(AWK) 'BEGIN { files["."] = "" } { files[$$2] = files[$$2] " " $$1; \ + if (++n[$$2] == $(am__install_max)) \ + { print $$2, files[$$2]; n[$$2] = 0; files[$$2] = "" } } \ + END { for (dir in files) print dir, files[dir] }' +am__base_list = \ + sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \ + sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g' +am__installdirs = "$(DESTDIR)$(htmldir)" +DATA = $(html_DATA) +RECURSIVE_CLEAN_TARGETS = mostlyclean-recursive clean-recursive \ + distclean-recursive maintainer-clean-recursive +AM_RECURSIVE_TARGETS = $(RECURSIVE_TARGETS:-recursive=) \ + $(RECURSIVE_CLEAN_TARGETS:-recursive=) tags TAGS ctags CTAGS \ + distdir +ETAGS = etags +CTAGS = ctags +DIST_SUBDIRS = $(SUBDIRS) +DISTFILES = $(DIST_COMMON) $(DIST_SOURCES) $(TEXINFOS) $(EXTRA_DIST) +am__relativize = \ + dir0=`pwd`; \ + sed_first='s,^\([^/]*\)/.*$$,\1,'; \ + sed_rest='s,^[^/]*/*,,'; \ + sed_last='s,^.*/\([^/]*\)$$,\1,'; \ + sed_butlast='s,/*[^/]*$$,,'; \ + while test -n "$$dir1"; do \ + first=`echo "$$dir1" | sed -e "$$sed_first"`; \ + if test "$$first" != "."; then \ + if test "$$first" = ".."; then \ + dir2=`echo "$$dir0" | sed -e "$$sed_last"`/"$$dir2"; \ + dir0=`echo "$$dir0" | sed -e "$$sed_butlast"`; \ + else \ + first2=`echo "$$dir2" | sed -e "$$sed_first"`; \ + if test "$$first2" = "$$first"; then \ + dir2=`echo "$$dir2" | sed -e "$$sed_rest"`; \ + else \ + dir2="../$$dir2"; \ + fi; \ + dir0="$$dir0"/"$$first"; \ + fi; \ + fi; \ + dir1=`echo "$$dir1" | sed -e "$$sed_rest"`; \ + done; \ + reldir="$$dir2" +ACLOCAL = ${SHELL} /space/YaST_trunk/trunk/autoinstallation/missing --run aclocal-1.11 +AMTAR = ${SHELL} /space/YaST_trunk/trunk/autoinstallation/missing --run tar +AUTOCONF = ${SHELL} /space/YaST_trunk/trunk/autoinstallation/missing --run autoconf +AUTOHEADER = ${SHELL} /space/YaST_trunk/trunk/autoinstallation/missing --run autoheader +AUTOMAKE = ${SHELL} /space/YaST_trunk/trunk/autoinstallation/missing --run automake-1.11 +AWK = gawk +CAT_ENTRY_END = --> +CAT_ENTRY_START = Reply