[yast-commit] r61166 - in /trunk/autoinstallation: doc/ package/

Author: ug Date: Fri Mar 5 11:16:35 2010 New Revision: 61166 URL: http://svn.opensuse.org/viewcvs/yast?rev=61166&view=rev Log: new structure for documentation Added: trunk/autoinstallation/doc/ASKSection.xml trunk/autoinstallation/doc/BootloaderSection.xml trunk/autoinstallation/doc/FilesSection.xml trunk/autoinstallation/doc/GeneralSection.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/NetworkSection.xml trunk/autoinstallation/doc/PartitioningSection.xml trunk/autoinstallation/doc/PrinterSection.xml trunk/autoinstallation/doc/ReportSection.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 Modified: trunk/autoinstallation/doc/CreateProfileDetails.xml trunk/autoinstallation/doc/autoyast.xml trunk/autoinstallation/doc/creating_autoyast2_modules.xml trunk/autoinstallation/package/autoyast2.changes Added: trunk/autoinstallation/doc/ASKSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/ASKSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/ASKSection.xml (added) +++ trunk/autoinstallation/doc/ASKSection.xml Fri Mar 5 11:16:35 2010 @@ -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 (not SLES11) 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. + <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 in openSUSE 11.2 (not SLES11)</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 in openSUSE 11.2 (not SLES11)</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 in openSUSE 11.2 (not SLES11)</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 but not in SLES11)</entry> + <entry>with 11.2 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 (not SLES11). + </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 "false"). 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/BootloaderSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/BootloaderSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/BootloaderSection.xml (added) +++ trunk/autoinstallation/doc/BootloaderSection.xml Fri Mar 5 11:16:35 2010 @@ -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> + Modified: trunk/autoinstallation/doc/CreateProfileDetails.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/CreateProfileDetails.xml?rev=61166&r1=61165&r2=61166&view=diff ============================================================================== --- trunk/autoinstallation/doc/CreateProfileDetails.xml (original) +++ trunk/autoinstallation/doc/CreateProfileDetails.xml Fri Mar 5 11:16:35 2010 @@ -19,3042 +19,25 @@ system, this will not happen. For example, no security settings will be configured if <emphasis>yast2-security</emphasis> is not installed. </para> - <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> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - - - <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> - 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> - <section id="CreateProfile.Reporting"> - <title id="CreateProfile.Reporting.title"> - Reporting - </title> - - <para> - The <emphasis>report</emphasis> resource manages 3 types of pop-ups - that may appear during installation. - </para> - <itemizedlist> - <listitem> - <para> - Messages Popups (Usually non-critical, informative messages) - </para> - </listitem> - <listitem> - <para> - Warning Popups (If something might go wrong) - </para> - </listitem> - <listitem> - <para> - Error Popups (In the case of an error) - </para> - </listitem> - </itemizedlist> - <example> - <title>Reporting Behavior</title> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - - <para> - Depending on your experience, you can skip, log and show (with timeout) - those messages. It is recommended to show all - <emphasis>messages</emphasis> with timeout. Warnings can be skipped in - some places but should not be ignored. - </para> - <para> - By default, the settings in auto-installation mode is to show all messages without logging and - with a timeout of 10 seconds. - </para> - <warning> - <title> - Critical system messages - </title> - <para> - Note that <emphasis>not</emphasis> all messages during installation are controlled by the - <emphasis>report</emphasis> resource. Some critical messages concerning - package installation and partitioning will still show up ignoring your - settings in the <emphasis>report</emphasis> section. Mostly those - messages will have to be answered with <emphasis>Yes</emphasis> or <emphasis>No</emphasis>. - </para> - </warning> - </section> - - - - - <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> - - <section id="CreateProfile.Partitioning"> - <title> - Partitioning - </title> - - <section> - <title>drive configuration</title> - <warning> - <title> - EVMS support dropped in openSUSE 11.1 and SLES11 - </title> - <para> -since openSUSE 11.1 and SLES11 there is no longer support for EVMS in the installation system. That means all support for EVMS in AutoYaST was dropped too. Alll EVMS documentation on this page is on valid for SLES10 (all service packs) and openSUSE versions prior openSUSE 11.1 - </para> - </warning> - <para> - The following elements must be between the <partitioning config:type="list"><drive> ... </drive></partitioning> tags in the <profile> section. - </para> - <table frame='top'> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Values</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry>device</entry> - <entry>the device you want to configure in this section. Since SUSE Linux 10.1 and SLES10, you can use persistent device names via id, like <emphasis>/dev/disk/by-id/ata-WDC_WD3200AAKS-75L9A0_WD-WMAV27368122</emphasis>. With SLES10 SP1 and SUSE Linux 10.2, <emphasis>by-path</emphasis> is possible too like <emphasis>/dev/disk/by-path/pci-0001:00:03.0-scsi-0:0:0:0</emphasis>. - <para><screen><device>/dev/hda</device></screen></para> - </entry> - <entry>optional. If left out, autoyast tries to guess the device. A RAID must always have "/dev/md" as device</entry> - </row> - <row> - <entry>initialize</entry> - <entry>if set to true, the partition table gets wiped out before autoyast starts the partition calculation -<para><screen><initialize config:type="boolean">true</initialize></screen></para> -</entry> - <entry>optional. The default is false.</entry> - </row> - <row> - <entry>is_lvm_vg</entry> - <entry>This tells autoyast that this device is not a physical device but a LVM volume group (see LVM configuration below) -<para><screen><is_lvm_vg config:type="boolean">true</is_lvm_vg></screen></para> -</entry> - <entry>DEPRECATED since SLES10SP1 and SL10.2 - use <emphasis>type</emphasis> instead. Must be true if this device is a LVM volume group. The default is false.</entry> - </row> - <row> - <entry>is_evms_vg</entry> - <entry>this tells autoyast that this device is not a physical device but an EVMS volume group (see EVMS configuration below) -<para><screen><is_evms_vg config:type="boolean">true</is_evms_vg></screen></para> -</entry> - <entry>DEPRECATED since SLES10SP1 and SL10.2 - use <emphasis>type</emphasis> instead. Must be true if this device is an EVMS volume group. The default is false.</entry> - </row> - <row> - <entry>partitions</entry> - <entry>this is a list of <partition> entries (see table below) -<para><screen><partitions config:type="list"><partition>...</partition>...</partitions></screen></para> -</entry> - <entry>optional. If no partition is specified, autoyast will create it's own idea of a nice partitioning (see Automated Partitioning below).</entry> - </row> - <row> - <entry>pesize</entry> - <entry>this value makes only sense with LVM/EVMS. -<para><screen><pesize>8M</pesize></screen></para> -</entry> - <entry>optional. Default is 4M for EVMS/LVM volume groups.</entry> - </row> - <row> - <entry>use</entry> - <entry>this parameter tells autoyast which strategy it shall use to partition the harddisc. -<para>You can choose between:</para> -<itemizedlist> -<listitem> -<para>all (uses the whole device while calculating the new partitioning)</para> -</listitem> -<listitem> -<para>linux (only existing linux partitions are used)</para> -</listitem> -<listitem> -<para>free (only unused space on the device gets used. No other partitions gets touched)</para> -</listitem> -<listitem> -<para>1,2,3 (a list of comma seperated numbers that indicates the partition numbers to use)</para> -</listitem> -</itemizedlist> -</entry> - <entry>this parameter should be provided</entry> - </row> - <row> - <entry>type</entry> - <entry>this value describes the type of the <emphasis>drive</emphasis> and is a replacement for -<emphasis>is_lvm_vg</emphasis> and <emphasis>is_evms_vg</emphasis> used in SLES10 and SL10.1 -<para>You can choose between:</para> -<itemizedlist> -<listitem> -<para>CT_DISK for physical harddisks (default)</para> -</listitem> -<listitem> -<para>CT_LVM for LVM volume groups</para> -</listitem> -<listitem> -<para>CT_EVMS for EVMS volume groups</para> -</listitem> -</itemizedlist> - -<para><screen><type config:type="symbol">CT_LVM</type></screen></para> -</entry> - <entry>optional. Default is CT_DISK for a normal physical harddisk.</entry> - </row> - </tbody> - </tgroup> - </table> - </section> - - <section> - <title>partition configuration</title> - <para> - The following elements must be between the <partitions config:type="list"><partition> ... </partition></partitions> tags in the <drive> section. - </para> - <table frame='top'> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Values</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry>create</entry> - <entry> - <para> - the "create" tells autoyast if this partition must be created or if it's already existing - </para> - <para><screen><create config:type="boolean">false</create></screen></para> - </entry> - <entry>if set to false, there must be some information for autoyast which partition this is (like with partition_nr)</entry> - </row> - <row> - <entry>mount</entry> - <entry> - <para> - the mountpoint of this partition. - </para> - <para><screen><mount>/</mount></screen></para> - <para><screen><mount>swap</mount></screen></para> - </entry> - <entry>you should have at least a root partition (/) and a swap partition</entry> - </row> - <row> - <entry>fstopt</entry> - <entry> - <para> - mount options for this partition - </para> - <para><screen><fstopt>ro,noatime,user,data=ordered,acl,user_xattr</fstopt></screen></para> - </entry> - <entry>see "man mount" for the mountoptions you can use</entry> - </row> - <row> - <entry>label</entry> - <entry> - <para> - the label the partition has (useful for the "mountby" parameter - see below). - </para> - <para><screen><label>mydata</label></screen></para> - </entry> - <entry>see "man e2label" for example.</entry> - </row> - <row> - <entry>uuid</entry> - <entry> - <para> - the uuid the partition has (only useful for the "mountby" parameter - see below). - </para> - <para><screen><uuid>1b4e28ba-2fa1-11d2-883f-b9a761bde3fb</uuid></screen></para> - </entry> - <entry>see "man uuidgen"</entry> - </row> - <row> - <entry>size</entry> - <entry> - <para> - the size for the partition like 4G, 4500M, ... The /boot partition and the swap partition can have "auto" as - size too, to let autoyast calculate a reasonable size for them. On partition can have the value "max" to fillup - all available space. - </para> - <para> - with SUSE Linux 10.2 and SLES10 SP1, you can specify the the size in percentage. So 10% will use 10% of the size - of the harddisk/VG. You can mix auto,max,sizes and percentage like you want. - </para> - <para><screen><size>10G</size></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>format</entry> - <entry> - <para> - shall autoyast format the partition? - </para> - <para><screen><format config:type="boolean">false</format></screen></para> - </entry> - <entry>if "create" is true, then it's very likely that this is true too</entry> - </row> - <row> - <entry>filesystem</entry> - <entry> - <para> - what filesystem is used on this partition? -<itemizedlist> -<listitem> -<para>reiser (the default)</para> -</listitem> -<listitem> -<para>ext2</para> -</listitem> -<listitem> -<para>ext3</para> -</listitem> -<listitem> -<para>xfs</para> -</listitem> -<listitem> -<para>jfs</para> -</listitem> -<listitem> -<para>swap</para> -</listitem> -</itemizedlist> - </para> - <para><screen><filesystem config:type="symbol">reiser</filesystem></screen></para> - </entry> - <entry>optional. The default is reiser</entry> - </row> - <row> - <entry>partition_nr</entry> - <entry> - <para> - the partition_nr this partition has/will have. If you have set create=false, then you can tell - autoyast which partition you mean by the partition_nr. You can force autoyast to create only - primary partitions by configuring only partition numbers below 5. - </para> - <para><screen><partition_nr config:type="integer">2</partition_nr></screen></para> - </entry> - <entry>in most cases nr. 1-4 are primary partitions and 5-... are logical partitions</entry> - </row> - <row> - <entry>partition_id</entry> - <entry> - <para> - the partition_id configures the id of the partition. If you want something else than 131 - for linux partition or 130 for swap, you must configure that with partition_id. - </para> - <para><screen><partition_id config:type="integer">131</partition_id></screen></para> - </entry> - <entry>the default is 131 for linux partition. 130 for swap is set by autoyast itself too.</entry> - </row> - <row> - <entry>filesystem_id</entry> - <entry> - <para> - look at partition_id above. For historical reasons they represent the same. - </para> - <para><screen><filesystem_id config:type="integer">131</filesystem_id></screen></para> - </entry> - <entry>since 10.1 and SLES10 it's recommended to use partition_id instead.</entry> - </row> - <row> - <entry>mountby</entry> - <entry> - <para> - instead of a partition number, you can tell autoyast to mount a partition by label, uuid, path or id which are the udev path and udev id (see /dev/disk/...) - </para> - <para><screen><mountby config:type="symbol">label</mountby></screen></para> - </entry> - <entry>see "label" and "uuid" documentation above</entry> - </row> - <row> - <entry>lv_name</entry> - <entry> - <para> - if this partition is in a logical volume in a volume group (LVM or EVMS) - (see is_lvm_vg/is_evms_vg parameter in drive configuration) you - must specifiy the logical volume name here. - </para> - <para><screen><lv_name>opt_lv</lv_name></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>stripes</entry> - <entry> - <para> - It's an integer that tells AutoYaST to do LVM striping. You can configure across how man devices you want to stripe - </para> - <para><screen><stripes config:type="integer">2</stripes></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>stripesize</entry> - <entry> - <para> - It's an integer that tells AutoYaST the size of each block in kb - </para> - <para><screen><stripesize config:type="integer">4</stripesize></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>lvm_group</entry> - <entry> - <para> - if this is a physical partition that is used by (part of) a volume group (LVM), - you have to specify the name of the volume - group here. - </para> - <para><screen><lvm_group>system</lvm_group></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>evms_group</entry> - <entry> - <para> - if this physical partition is used by a volume group (EVMS), you have to specify the name of the volume - group here. - </para> - <para><screen><evms_group>system</evms_group></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>raid_name</entry> - <entry> - <para> - this physical volume is part of a RAID and the name of the raid is specified here. - </para> - <para><screen><raid_name>/dev/md0</raid_name></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>raid_type</entry> - <entry> - <para> - this physical volume is part of a RAID and the type of the raid is specified here.. - </para> - <para><screen><raid_type>raid1</raid_type></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>raid_options</entry> - <entry> - <para> - special options for the raid are specified here. See below. - </para> - <para><screen><raid_options>...</raid_options></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>resize</entry> - <entry> - <para> - This parameter is available since SLES10 SP1 and OpenSUSE 10.2. - This boolean must be true if an existing partition should be resized. In this case, - you want to set <emphasis>create</emphasis> to <emphasis>false</emphasis> too and in - most cases you don't want to <emphasis>format</emphasis> the partition. You need to - tell autoyast the <emphasis>partition_nr</emphasis> and the <emphasis>size</emphasis>. - The size can be in percentage of the original size or as a number of the new size, like - <emphasis>800M</emphasis>. <emphasis>max</emphasis> and <emphasis>auto</emphasis> don't - work as size here. - </para> - <para><screen><resize config:type="boolean">false</resize></screen></para> - </entry> - <entry>The resize only works with physical disks. Not with LVM/EVMS volumes.</entry> - </row> - </tbody> - </tgroup> - </table> - </section> - <section> - <title>raid options</title> - <para> - The following elements must be between the <partition><raid_options> ... </raid_options></partition> tags. - </para> - <table frame='top'> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Values</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry>chunk_size</entry> - <entry> - <para> - </para> - <para><screen><chunk_size>4</chunk_size></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>parity_algorithm</entry> - <entry> - <para> - possible values are: left_asymmetric, left_symmetric, right_asymmetric, right_symmetric - </para> - <para><screen><parity_algorithm>left_asymmetric</parity_algorithm></screen></para> - </entry> - <entry></entry> - </row> - <row> - <entry>raid_type</entry> - <entry> - <para> - possible values are raid0,raid1 and raid5 - </para> - <para><screen><raid_type>raid1</raid_type></screen></para> - </entry> - <entry>the default is raid1</entry> - </row> - </tbody> - </tgroup> - </table> - </section> - <section> - <title> - Automated Partitioning - </title> - - <para> - For the automated partitioning to be completed, only the sizes and mount points of - partitions can be provided. All other data needed for successful partitioning - can be calculated during installation if they were not provided in the control file. - </para> - <para> - If no partitions are defined and the specified drive is also the drive where - the root partition should be created, the following partitions are created - automatically: - </para> - <itemizedlist> - <listitem> - <para> - <emphasis>/boot</emphasis> - </para> - <para> - Size of the <emphasis>/boot</emphasis> is determined by the - architecture of the target system. - </para> - </listitem> - <listitem> - <para> - <emphasis>swap</emphasis> - </para> - <para> - Size of the <emphasis>swap</emphasis> partitions is determined by the - amount of memory available in the system. - </para> - </listitem> - <listitem> - <para> - <emphasis>/</emphasis> (root partition) - </para> - <para> - Size of the <emphasis>/</emphasis> (root partition) is the space left - after creating <emphasis>swap</emphasis> and <emphasis>/boot</emphasis>. - </para> - </listitem> - </itemizedlist> - - <para> - Depending on the initial status of the drive and how it was - previously partitioned, it is possible to create the <emphasis>default</emphasis> - partitioning in the following ways: - </para> - <itemizedlist> - <listitem> - <para> - <emphasis>Use free space</emphasis> - </para> - <para> - If the drive is already partitioned, it is possible to create the - new partitions using the available space on the hard drive. This - requires the availability of enough space for all selected - packages in addition to swap. - </para> - </listitem> - <listitem> - <para> - <emphasis>Reuse all available space</emphasis> - </para> - <para> - This option will lead to the deletion of all existing - partitions (Linux and non-Linux partitions). - - </para> - </listitem> - - <listitem> - <para> - <emphasis>Reuse all available Linux partitions</emphasis> - </para> - <para> - This option will lead to the deletion of existing Linux - partitions. All other partitions (i.e. Windows) will be - kept. Note that this works only if the Linux partitions are at the end of the device. - - </para> - </listitem> - - <listitem> - <para> - <emphasis>Reuse only specified partitions</emphasis> - </para> - <para> - This option will lead to the deletion of the specified partitions. - The selection of the partitions scheduled for deletion should be - started from the last available partition. - </para> - </listitem> - </itemizedlist> - <para> - Repartitioning using only some of the existing partitions can be - accomplished only if the region selected to be partitioned exists at - the end of the device and only with neighboring partitions. This - means that you cannot repartition a region which contains a partition that - should not be touched in the middle. - </para> - - <caution> - <title>Important Notice</title> - <para> - The value provided in the <emphasis>use</emphasis> property determines how existing data and - partitions are treated. The value <emphasis>all</emphasis> means that - <emphasis>ALL</emphasis> data on the disk will - be erased. Make backups and use the <emphasis>confirm</emphasis> - property if you are going to - keep some partitions with important data. This is automated - installation and no pop-ups will notify you about partitions being deleted. - </para> - </caution> - <para> - In case of the presence of multiple drives in the target system, all - drives must be identified with their device names and how the partitioning should be performed. - </para> - - <para> - Partition sizes can be given in Gigabytes, Megabytes or can be set to - a flexible value using the keywords <emphasis>auto</emphasis> and - <emphasis>max</emphasis>. <emphasis>max</emphasis> is used to fill a - partition to the maximal available space on a - drive (Which mean that the partition should be the last one on the drive). - <emphasis>auto</emphasis> can be used to determine the size of - a <emphasis>swap</emphasis> or <emphasis>boot</emphasis> partitions - depending on the memory available and the type of the system. - </para> - <para>A fixed size can be given as shown below:</para> - <para> - <emphasis>1GB</emphasis> will create a partition with 1 GB size. - <emphasis>1500MB</emphasis> will create a partition which is 1.5 GB big. - </para> - <example> - <title>Automated partitioning</title> - <para> - The following is an example of a single drive system, which is not - pre-partitioned and should be automatically partitioned according to - the described pre-defined partition plan. If you leave the device out, - an autodetection of the device will happen. So you don't have to do - different profiles for /dev/sda or /dev/hda systems. - </para> - <screen> - http://www.w3.org/2001/XInclude"/> - - </screen> - </example> - <para> - A more detailed example shows how existing partitions and - multiple drives are handled. - </para> - <example> - <title>Detailed automated partitioning</title> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - </section> - - <section> - <title>Advanced Partitioning features</title> - <section> - <title>Wipe out partition table</title> - <para> - In the most cases this is not needed because autoyast can delete partitions - one by one automatically but you have the option to let autoyast clear the partition table - instead of deleting the partitions individually. - </para> - <para> - if you go into the "drive" section, you can add - <screen> -<![CDATA[ -<initialize config:type="boolean">true</initialize> -]]> -</screen> - which tells Autoyast to delete the partition table before it starts to analyse the - actual partitioning and calculates it's partition plan. Of course this means, that you - can't keep any of your existing partitions. - </para> - </section> - <section> - <title>Mount Options</title> - <para> - By default a file system which is to be mounted is - identified in <filename>/etc/fstab</filename> by the device name. This identification - can be changed so the file system is found by searching - for a <acronym>UUID</acronym> or a volume label. Note that not all file systems can be mounted - by <acronym>UUID</acronym> or a volume label. To specify how a - partition is to be mounted, use the <emphasis>mountby</emphasis> - property which has the <emphasis>symbol</emphasis> type. Possible - options are: - </para> - <itemizedlist> - <listitem> - <para>device (default)</para> - </listitem> - <listitem> - <para>label</para> - </listitem> - <listitem> - <para>UUID</para> - </listitem> - </itemizedlist> - <para> - If you choose to mount the partition using a label, the name - entered in the <emphasis>label</emphasis> property is used as the - volume label. - </para> - <para> - Add any legal mount option allowed in the fourth field of - <filename>/etc/fstab</filename>. Multiple options are separated by commas. Possible fstab options: - </para> - <itemizedlist> - <listitem> - <para><emphasis>Mount Read-Only (ro):</emphasis> No writable - access to the file system is possible. Default is false.</para> - - </listitem> - <listitem> - <para><emphasis>No access time (noatime):</emphasis> Access times - are not updated when a file is read. Default is false.</para> - - </listitem> - <listitem> - <para><emphasis>Mountable by User (user):</emphasis> The file - system may be mounted by an ordinary user. Default is - false.</para> - - </listitem> - <listitem> - <para> - <emphasis>Data Journaling Mode (ordered | journal | - writeback) :</emphasis> Specifies the journaling mode for - file data. journal -- All data is committed into the journal - prior to being written into the main file system. ordered -- - All data is forced directly out to the main file system prior - to its meta data being committed to the journal. writeback -- - Data ordering is not preserved. - </para> - </listitem> - <listitem> - <para> - <emphasis>Access Control List (acl):</emphasis> Enable access - control lists on the file system. - </para> - </listitem> - <listitem> - <para> - <emphasis>Extended User Attributes (user_xattr):</emphasis> Allow - extended user attributes on the file system. - </para> - </listitem> - - </itemizedlist> - <example> - <title>Mount Options</title> - - <screen> - http://www.w3.org/2001/XInclude"/> - - </screen> - </example> - </section> - - <section> - <title>Keeping Specific Partitions</title> - <para> - In some cases you might choose to keep some partitions untouched - and only format specific target partitions, rather than creating them from - scratch. This might be the case of Linux installations have to - co-exist with another operating system or if certain partitions - contain data that you wish to keep untouched. - </para> - <para> - Such scenarios require certain knowledge about the target systems - and hard drives. Depending on the scenario, you might need to know - the exact partition table of the target hard drive with partition - id's, sizes and numbers. With such data you can tell &autoyast; to - keep certain partitions, format others and create new partitions if - needed. - </para> - - <para> - The following example will keep partitions 1, 2 and 5 and delete - partition 6 to create two new partitions. All kept partitions will - be only formatted. - </para> - <example> - <title> - Keeping partitions - </title> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - <para> - The last example requires exact knowledge about the existing partition - table and about the partition numbers of those partitions that - should be kept. In some cases however, such data might be not - available, especially in a mixed hardware environment with - different hard drive types and configurations. The following - scenario is for a system with a non-Linux OS with a designated - area for a Linux installation. - </para> - <figure id="partitioning-keep1"> - <title id="partitioning-keep1.title" >Keeping partitions</title> - <mediaobject>&partitioning-keep1;</mediaobject> - </figure> - - <para> - In this scenario and as shown in figure <quote></quote> , &autoyast2; - should not in any case create any new - partitions, instead it should search for certain partition types on the system and use - them according to the partitioning plan in the control file. No - partition numbers are given in this case, only the mount points and - the partition types (Additional configuration data can be provided, - for example file system options, encryption and filesystem type) - </para> - <example> - <title> Auto-detection of partitions to be kept.</title> - <screen> http://www.w3.org/2001/XInclude"/></screen> - </example> - </section> - </section> - - <section> - <title>Using existing mount table (fstab)</title> - <note> - <title>New Feature</title> - </note> - <para> - This option will allow the AutoYaST to use an existing - <filename>/etc/fstab</filename> and use the partition data from - from a previous installation. All partitions are kept and no new - partitions are created. The found partitions will be formatted and - mounted as specified in <filename>/etc/fstab</filename> found on a - Linux root partition. - </para> - <para> - Although the default behaviour is to format all partitions, it is - also possible to leave some partitions untouched and only mount them, - for example data partitions. If multiple installations are found on - the system (multiple root partitions with different - <emphasis>fstab</emphasis> files, the installation will abort, unless - the desired root partition is configured in the control file. The - following example illustrates how this option can be used: - </para> - <example> - <title> - Reading existing <filename>/etc/fstab</filename> - </title> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - </section> - - <section> - <title> - Logical Volume Manager (LVM) - </title> - <para> - To configure LVM, first you need to create a <emphasis>physical volume</emphasis> using the - normal partitioning method described above. - </para> - <example> - <title> - Create LVM Physical Volume - </title> - <para> - The following example shows how to prepare for LVM in the - <emphasis>partitioning</emphasis> resource: - </para> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - - </example> - <para> - The last example will create a non-formatted partition on device - <filename>/dev/sda1</filename> of the type <emphasis>LVM</emphasis> and - with the volume group <emphasis>system</emphasis>. The partition - created will use all available space on this drive. - </para> - - <example> - <title> - LVM Logical Volumes (New syntax) - </title> - <screen> -http://www.w3.org/2001/XInclude"/> - </screen> - </example> - <para> - With SUSE Linux 10.1 and all following versions, it's possible to set the <emphasis>size</emphasis> - to <emphasis>max</emphasis> for the logical volumes. Of course, you can only use <emphasis>max</emphasis> - only for one(!) logical volumes. You can't have two logical volumes in one volume group with the - <emphasis>size</emphasis> set to <emphasis>max</emphasis> - </para> - </section> - - <section> - <title> - Enterprise Volume Management System (EVMS) - SLES10 only! - </title> - <para> - SLES10 autoyast has EVMS support. SLES11 has not! - </para> - <para> - Using EVMS is quite similar to using LVM (see above). So switching from LVM to EVMS - is just a small change in the autoyast profile. All you have to do is to change the - "is_lvm_vg" element into "is_evms_vg" and the "lvm_group" element into "evms_group". - </para> - <para> - With autoyast it's not possible to mix LVM and EVMS. - </para> - <para> - Using the LVM example from above for EVMS now looks like this: - </para> - <example> - <title> - EVMS Logical Volumes - </title> - <screen> -http://www.w3.org/2001/XInclude"/> - </screen> - </example> - </section> - <section> - <title>Software RAID</title> - <para> - Using &autoyast;, you can create and assemble software RAID devices. The - supported RAID levels are the following: - </para> - <itemizedlist> - <listitem> - <para> - <emphasis>RAID 0:</emphasis> This level increases your disk performance. - There is <emphasis>NO</emphasis> redundancy in this mode. If one - of the drives crashes, data recovery will not be possible. - - </para> - </listitem> - <listitem> - <para> - <emphasis>RAID 1:</emphasis>This mode has the best redundancy. It can be - used with two or more disks. This mode maintains an exact copy of all data on all - disks. As long as at least one disk is still working, no data is lost. The partitions - used for this type of RAID should have approximately the same size. - </para> - </listitem> - - <listitem> - <para> - <emphasis>RAID 5:</emphasis> This mode combines management of a larger number - of disks and still maintains some redundancy. This mode can be used on three disks or more. - If one disk fails, all data is still intact. If two disks fail simultaneously, - all data is lost. - </para> - </listitem> - <listitem> - <para> - <emphasis>Multipath:</emphasis>This mode allow access to the same physical device - over multiple controller for redundancy against a fault in a controller - card. This mode can be used with at least two devices. - </para> - </listitem> - </itemizedlist> - <para> - As with LVM, you need to create all <emphasis><acronym>RAID</acronym></emphasis> partitions first and assign - the partitions to the <acronym>RAID</acronym> device you want to - create and additionally you need to specify whether a partition or a device should be configured in the - <acronym>RAID</acronym> or if it should configured as a <emphasis>Spare</emphasis> device. - </para> - <para> - The following example shows a simple RAID1 configuration: - </para> - - - <example> - <title>RAID1 configuration</title> - <screen> -http://www.w3.org/2001/XInclude"/> - </screen> - </example> - - - <para> - The following has to be taken into consideration when configuring - raid: - </para> - <itemizedlist> - <listitem> - <para>The device for raid is always <emphasis>/dev/md</emphasis></para> - </listitem> - <listitem> - <para>The property <emphasis>partition_nr</emphasis> is used to - determine the MD device number. if - <emphasis>partition_nr</emphasis> is equal to 0, then - <emphasis>/dev/md0</emphasis> is configured.</para> - </listitem> - <listitem> - <para>All RAID specific options are contained in the - <emphasis>raid_options</emphasis> resource.</para> - </listitem> - </itemizedlist> - - - - </section> - </section> - <section id="CreateProfile.Software"> - <title> - Software - </title> - - <section id="Software.Selections.sles10"> - <title> - Package Selections with patterns - </title> - <para> - SLES10 no longer supports <emphasis>selections</emphasis> but uses - <emphasis>patterns</emphasis> now. Autoyast is not be able to convert - selections into patterns and so you have to do that on your own. - If you want to use a SLES9 autoyast profile to install a SLES10 - server, you have to remove all <emphasis>addon</emphasis> entries and the - <emphasis>base</emphasis> entry. Patterns are configured like this: - </para> - <example> - <title> - Package selection in control file with patterns - </title> - <screen> -http://www.w3.org/2001/XInclude"/> - </screen> - </example> - <para> - As you can see, the <emphasis>packages</emphasis> section is still the same like on - a SLES9. Just the <emphasis>addon</emphasis> and <emphasis>base</emphasis> is gone. - </para> - </section> - <section> - <title> - Deploying Images - </title> - <para> - This feature is available since openSUSE 11.1 but not in SLES11. - </para> - <para> - Since openSUSE 11.0 you can choose to use images during installation to speed up the installation. - This is available in openSUSE 11.1 too. At then end, in the installed system, there is - no difference visible if you did an image or a single RPM installation. - </para> - <example> - <title> - Activating images deployment - </title> - <screen> -http://www.w3.org/2001/XInclude"/> - </screen> - </example> - </section> - - <section> - <title> - Installing additional and customized Packages - </title> - <para> - In addition to the packages available for installation on the CD-ROMs, - you can add external packages including customized kernels. Customized - kernel packages must be compatible to the &company-suse; packages and must - install the kernel files to the same locations. - </para> - <para> - Unlike earlier versions, to install custom and external packages - there is no need for a special resource in the control - file. Instead you need to re-create the package database and update - it with any new packages or new package versions in the source repository. - </para> - <para> - A script is provided for this task which will query packages - available in the repository and create the required package - database. - </para> - - <para> - Creating a new package database is only needed if new RPMs - (i.e. update RPMs) were added. To re-create the database, use the - <command>/usr/bin/create_package_descr</command> - command. For example, use this command line to create the package - database. (When creating the database, all languages will be reset to English). - </para> - <example> - <title>Creating package database</title> - <screen> - cd /usr/local/CDs/LATEST/suse - create_package_descr -x PATH_TO_EXTRA_PROV -d /usr/local/CDs/LATEST/suse - </screen> - </example> - <note> - <title>Change starting from SUSE Linux 9.1/SLES 9</title> - <para>To provide extra dependencies which can not be extracted from the - rpm files, an extra file with missing dependencies is available in the - directory <filename>suse/setup/descr</filename>. The file - <filename>EXTRA_PROV</filename> can be used when recreating the package - database using the <emphasis>-x</emphasis> option.</para> - </note> - <para> - In the above example, the directory - <filename>/usr/local/CDs/LATEST/suse</filename> contains the architecture - dependent and independent packages, i.e. <emphasis>noarch</emphasis> and <emphasis>i586</emphasis>. - This might look different on other architectures. - </para> - <para> - The advantage of this method is that you can keep an up-to-date - repository with fixed and updated package (i.e. from &company-suse; FTP - server). Additionally this method makes the creation of custom CD-ROMs easier. - </para> - <note> - <title>Change starting from SUSE Linux 10.1/SLES 10</title> - <para> - With SLES10/SL10.1, the concept of adding own RPMs to an installation source has changed. - The <emphasis>yast/order</emphasis> and <emphasis>yast/instorder</emphasis> is no longer supported. Neither - by AutoYaST nor by YaST. To add own RPMs to an installation source (that includes add-on products like the - SDK) you have to add a file <emphasis>add_on_products</emphasis> to the CD1 of the main product. - <screen> -media_url [path_on_media [product_1 [product_2 [....]]] - </screen> - media_url is URL of the media itself - path_on_media is path of the catalog on the media. If not present, / (root) is assumed - product_1 and following are the names for products, which should be marked for installation. If no product is mentioned, all products found on the media are selected for installation. - For example: - <screen> -http://192.168.66.6/SLES10/sdk/CD1 -http://192.168.66.6/SLES10/CD1/updates - </screen> - Besides that <emphasis>add_on_products</emphasis> file, you can use the autoyast profile to specify add-on products. For example: - <screen> -<add-on> - <add_on_products config:type="list"> - <listentry> - <media_url>http://192.168.66.6/SLES10/CD1/updates</media_url>; - <product>SuSE-Linux-Updates</product> - <product_dir>/</product_dir> - <ask_on_error config:type="boolean">false</ask_on_error> <!-- available since openSUSE 11.0 --> - <name>MyUpdates</name> <!-- available since openSUSE 11.1/SLES11 (bnc#433981) --> - </listentry> - </add_on_products> -</add-on> - </screen> - With that entry in the autoyast profile, the <emphasis>add_on_products</emphasis> file is not necessary. - Since openSUSE 11.0 AutoYaST can ask the user to make the add-on available intead of reporting a timed out error when the add-on can't be found at the given location. Set ask_on_error to true for that (the default is false). - Your add-on can be on a different CD/DVD than the installation source then. - </para> - <para> - YaST checks the signatures of files on the installation source now. If a <emphasis>content</emphasis> file is - not signed, during a manual installation YaST asks the user what to do. During an autoinstallation, the - installation source gets rejected silently. - </para> - </note> - <para> - If you want to use unsigned installation sources with autoyast, you can turn of the checks with the following - configuration in your autoyast profile (part of the <emphasis>general</emphasis> section. - </para> - <para> - The following elements must be between the <general><signature-handling> ... </signature-handling></general> tags. - </para> - <para> - <table frame='top'> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Values</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry>accept_unsigned_file</entry> - <entry>the installer will accept unsigned files like the content file - <para><screen><accept_unsigned_file config:type="boolean">true</accept_unsigned_file></screen></para> - </entry> - <entry>optional. If left out, autoyast lets yast decide what to do</entry> - </row> - <row> - <entry>accept_file_without_checksum</entry> - <entry>the installer will accept files without a checksum in the content file - <para><screen><accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum></screen></para> - </entry> - <entry>optional. If left out, autoyast lets yast decide what to do</entry> - </row> - <row> - <entry>accept_verification_failed</entry> - <entry>the installer will accept files where the verification of the signature failed. So the file was signed but the check failed. - <para><screen><accept_verification_failed config:type="boolean">true</accept_verification_failed></screen></para> - </entry> - <entry>optional. If left out, autoyast lets yast decide what to do</entry> - </row> - <row> - <entry>accept_unknown_gpg_key</entry> - <entry>the installer will accept new gpg keys on the installation source that are used to sign the content file for example - <para><screen><accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key></screen></para> - </entry> - <entry>optional. If left out, autoyast lets yast decide what to do</entry> - </row> - <row> - <entry>accept_non_trusted_gpg_key</entry> - <entry>This basically means, we know the key, but it is not trusted - <para><screen><accept_non_trusted_gpg_key config:type="boolean">true</accept_non_trusted_gpg_key></screen></para> - </entry> - <entry>optional. If left out, autoyast lets yast decide what to do</entry> - </row> - <row> - <entry>import_gpg_key</entry> - <entry>the installer will accept and import new gpg keys on the installation source in it's database. - <para><screen><import_gpg_key config:type="boolean">true</import_gpg_key></screen></para> - </entry> - <entry>optional. If left out, autoyast lets yast decide what to do</entry> - </row> - </tbody> - </tgroup> - </table> - </para> - <para> - Since openSUSE 10.3 it's possible to configure the signature handling for each add-on individually. The following elements must be between the - <signature-handling> section of the individual add-on. - </para> - <para> - <table frame='top'> - <tgroup cols="3"> - <thead> - <row> - <entry>Attribute</entry> - <entry>Values</entry> - <entry>Description</entry> - </row> - </thead> - <tbody> - <row> - <entry>accept_unsigned_file</entry> - <entry>the installer will accept unsigned files like the content file for this add-on product - <para><screen><accept_unsigned_file config:type="boolean">true</accept_unsigned_file></screen></para> - </entry> - <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> - </row> - <row> - <entry>accept_file_without_checksum</entry> - <entry>the installer will accept files without a checksum in the content file for this add-on - <para><screen><accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum></screen></para> - </entry> - <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> - </row> - <row> - <entry>accept_verification_failed</entry> - <entry>the installer will accept files where the verification of the signature failed. So the file was signed but the check failed. - <para><screen><accept_verification_failed config:type="boolean">true</accept_verification_failed></screen></para> - </entry> - <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> - </row> - <row> - <entry>accept_unknown_gpg_key</entry> - <entry>the installer will accept new gpg keys on the installation source that are used to sign the content file for example - <para><screen> - <accept_unknown_gpg_key> - <all config:type="boolean">false</all> - <keys config:type="list"> - <keyid>3B3011B76B9D6523</keyid> - </keys> - </accept_unknown_gpg_key> - </screen></para> - </entry> - <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> - </row> - <row> - <entry>accept_non_trusted_gpg_key</entry> - <entry>This basically means, we know the key, but it is not trusted - <para><screen> - <accept_non_trusted_gpg_key> - <all config:type="boolean">false</all> - <keys config:type="list"> - <keyid>3B3011B76B9D6523</keyid> - </keys> - </accept_non_trusted_gpg_key> -</screen></para> - </entry> - <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> - </row> - <row> - <entry>import_gpg_key</entry> - <entry>the installer will accept and import new gpg keys on the installation source in it's database. - <para><screen> - <import_gpg_key> - <all config:type="boolean">false</all> - <keys config:type="list"> - <keyid>3B3011B76B9D6523</keyid> - </keys> - </import_gpg_key> - </screen></para> - </entry> - <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> - </row> - </tbody> - </tgroup> - </table> - </para> - </section> - <section> - <title>Kernel packages</title> - <para> - Kernel packages are not part of any selection. The required kernel - is determined during installation. If the kernel package is added to any selection - or to the individual package selection, installation will mostly fail due to conflicts. - </para> - <para> - To force the installation of a specific kernel, use the - <emphasis>kernel</emphasis> property. The following is an example - forcing the installation of the default kernel. In this example this - kernel will be installed in any case, even if an SMP or other kernel - is required</para> - <example> - <title> - Package selection in control file - </title> - <screen> -http://www.w3.org/2001/XInclude"/> - - </screen> - </example> - </section> - <section> - <title>Removing automatically selected packages</title> - <para> - Some packages are selected automatically either because of a - dependency or because it available in a selection. - </para> - <para> - Removing such packages might break the system consistency and it is - not recommended to remove basic packages unless a replacement which - provides same services is provided. Best example for this case are - <acronym>MTA</acronym> packages. By default, <emphasis>postfix</emphasis> - will be selected and installed. If you wish however to use another - <acronym>MTA</acronym> like <emphasis>sendmail</emphasis>, then - postfix can be removed from the list of selected package using a list - in the software resource. The following example shows how this can be done: - - </para> - <example> - <title> - Package selection in control file - </title> - <screen> -http://www.w3.org/2001/XInclude"/> - - - </screen> - </example> - </section> - <section> - <title>Installing packages during stage 2</title> - <para> - if you want to install packages after the reboot during stage 2, instead of - during the normal installation process in stage 1, you can use the - <emphasis>post-packages</emphasis> element for that: - </para> - <screen> -<software> - <post-packages config:type="list"> - <package>yast2-cim</package> - </post-packages> -</software> - </screen> - </section> - <section> - <para> - Since SLES11 and openSUSE 11.1 you can install patterns in stage 2 too. - use the <emphasis>post-patterns</emphasis> element for that: - </para> - <screen> -<software> - <post-patterns config:type="list"> - <pattern>apparmor</pattern> - </post-patterns> -</software> - </screen> - </section> - <section> - <title>Online update in stage2</title> - <para> - since openSUSE 11.1 you can do an online update at the end of the installation with the boolean - <emphasis>do_online_update</emphasis>. - Of course that makes only sense if you add an online update repository with the suse-register/customer-center section for example or in a post-script. If the online update repository was available in stage1 already via add-on section, then autoyast has already installed the latest packages available. If a kernel update is done via online-update, a reboot at the end of stage2 is triggered. - </para> - <screen> -<software> - <do_online_update config:type="boolean">true</do_online_update> -</software> - </screen> - </section> - </section> - - <section id="CreateProfile.Services"> - <title> - Services and Run-levels - </title> - <para> - With the run-level resource you can set the default run-level and specify - in detail which system services you want to be started in which - run-level. - </para> - <para> - The default property specifies the <emphasis>default</emphasis> run - level of the system. Changes to the default run-level will take effect - the next time you boot the system. After installation is completed, - the system has run-level 5, which is <emphasis>Full multiuser with - network and XDM</emphasis>. If you have configured a system with no - X11, then it is recommended to reboot the system after the first stage - using the <emphasis>reboot</emphasis> property in the <emphasis>general</emphasis> resource. - - </para> - <para> - A service should run in using a space delimited list of the run-levels - as shown in the following example. An alternative to specifying the - exact run-levels is to change the status of the service by either - enabling or disabling it using the - <emphasis>service_status</emphasis> property. - </para> - &example.runlevels; - - </section> - - <section id="CreateProfile.Network"> - <title> - Network configuration - </title> - - <section id="Configuration.Network.Devices"> - <title> - Network devices, DNS and Routing. - </title> - <para> - Network configuration is used to connect a single &company-suse; Linux - workstation to an Ethernet-based LAN or to configure dial-up - connection. More complex configuration (multiple network cards, - routing, etc.) is also provided. With this module it's possible to - configure and setup Ethernet Controllers and Token-Ring Controllers. - </para> - <para> - In the networking section, when this option is set to true (default is false, this option is available since openSUSE 11.2 but not SLES11): - <screen> - <keep_install_network config:type="boolean">true</keep_install_network> - </screen> - YaST will keep network settings created during installation (via Linuxrc) - and/or merge it with network settings from the AutoYaST profile (if these are defined). - AutoYaST settings have higher priority than already present configuration files. - YaST will write ifcfg-* files from profile without removing old ones. - If there is none (or empty) dns and routing section, YaST will keep already present values. Otherwise settings from the profile will be applied. - </para> - <para> - To configure network settings and activate networking automatically, - one global resource is used to store the whole network configuration. - </para> - - &example.network; - </section> - - <section id="Configuration.Network.Proxy"> - <title> - Proxy - </title> - <para> - Configure your Internet proxy (caching) settings using this - resource. - </para> - <para> - <emphasis>HTTP proxy</emphasis> is the name of the proxy server for your access to the world wide web (WWW). - <emphasis>FTP proxy</emphasis> is the name of the proxy server for your access to the file transfer services (FTP). - <emphasis>No proxy</emphasis> domains is a list of domains for - which the requests should be done directly without caching. - </para> - <para> - If you are using a proxy server with authorization, fill in Proxy user name and Proxy password. - </para> - <example> - <title> - Netwrok configuration: Proxy - </title> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - - - </section> - <section id="Configuration.Network.Inetd"> - <title>(X)Inetd </title> - - <para> - The profile has elements to specify which superserver should be - used (netd_service), whether it should be enabled (netd_status) and - how the services should be configured (netd_conf). - </para> - <para> - A service description element has conceptually two parts: key and - non-key. When writing the configuration, services are matched using - the key fields and to the matching service, non-key fields are - applied. If no service matches, it is created. If more services - match, a warning is reported. The key fields are script, service, - protocol and server. - </para> - <para> - Service and protocol are matched literally. script is the base name - of the config file: usually a file in<filename> /etc/xinetd.d</filename>, for example "echo-udp", - or "inetd.conf". For compatibility with 8.2, server is matched more - loosely: if it is <filename>/usr/sbin/tcpd</filename>, the real server name is taken from - server_args. After that, the basename of the first - whitespace-sparated word is taken and these values are compared. - </para> - &example.inetd; - - </section> - <section id="Configuration.Network.NIS"> - <title>NIS</title> - <para> - Using the <emphasis>nis</emphasis> resource, you can configure the target machine as a <emphasis>NIS - client</emphasis>. The following example shows a detailed - configuration using multiple domains. - </para> - &example.nis; - </section> - <!-- - <section id="Configuration.Network.NISplus"> - <title> - NIS+ - </title> - <para> - If you activate NIS+, the data of the - NIS+ Server will be added to <filename>/etc/hosts</filename>. Keyserv and the NIS+ cache manager - will be started and the NSS and PAM configuration will be modified to use - NIS+ and set the Secret Key of a user. - </para> - &example.nisplus; - </section> - --> - <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> - <section> - <title> - NFS Client and Server - </title> - <para> - Configuration of a system as an NFS client or an NFS server is - possible and can be done using the configuration system. The - following examples shows how both NFS client and server can be configured. - </para> - <para> - Up to SLE11 and openSUSE 11.2, the following structure of NFS client configuration - is used: - </para> - <example> - <title> - Network configuration: NFS client - </title> - <screen> - - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - <para> - From openSUSE 11.3 (SLE12 respectively) on, the structure of NFS client configuration - has changed. Some global configuration options were introduced - <emphasis>enable_nfs4</emphasis> - to switch NFS4 support on/off and <emphasis>idmapd_domain</emphasis> to define domain name for - rpc.idmapd (this only makes sense with enabled NFS4). Attention: the old structure is not - compatible with the new one and the profiles with NFS section created on older releases will not - work with newer products. - </para> - <example> - <title> - Network configuration: NFS client - new style (openSUSE 11.3 and newer) - </title> - <screen> - - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - - <example> - <title> - Network configuration: NFS Server - </title> - <screen> - - - http://www.w3.org/2001/XInclude"/> - </screen> -</example> - </section> - - <section id='Configuration.Network.Ntp'> - <title> - NTP Client - </title> - <para> - Select whether to start the NTP daemon when booting the system. The NTP - daemon resolves host names when initializing. The first - synchronization of the clock is performed before the NTP daemon is - started. To use this host for initial synchronization configure the - property <emphasis>initial_sync</emphasis>. - </para> - <para> - To run NTP daemon in - chroot jail, set <emphasis>start_in_chroot</emphasis>. Starting any daemon - in a chroot jail is more secure and strongly recommended. - To adjust NTP servers, peers, local clocks, and NTP broadcasting, - add the appropriate entry to the control file. an example of various - configuration options is shown below. - </para> - <example> - <title> - Network configuration: NTP Client - </title> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> -</example> - </section> - </section> - <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> - - - - <section id="CreateProfile.Security"> - <title> - Security settings - </title> - - <para> - Using the features of this module, you will be able to change the local - security settings on the target system. The local security settings - include the boot configuration, login settings, password settings, - user addition settings, and file permissions. - </para> - <para> - Configuring the security settings automatically corresponds to the - <emphasis>Custom Settings</emphasis> in the security module available in - the running system which lets you create your own, customized - configuration. - </para> - - &example.security; - <section> - <title>Password Settings Options</title> - <para> - Change various password settings. These settings are mainly stored in the <filename>/etc/login.defs</filename> file. - </para> - <para> - Use this resource to activate one of the <emphasis>encryption</emphasis> methods currently supported. - If not set, <emphasis>DES</emphasis> is configured. - </para> - <para> - <emphasis>DES</emphasis>, the Linux default method, works in all - network environments, but it restricts you to passwords no longer than - eight characters. <emphasis>MD5</emphasis> allows longer passwords, - thus provides more security, but some network protocols don't support - this, and you may have problems with NIS. <emphasis>Blowfish</emphasis> - is also supported. - </para> - <para>Additionally, you can setup the system to check for password - plausibility and length etc.</para> - </section> - <section> - <title>Boot Settings</title> - <para> - Use the security resource, you can change various boot settings. - </para> - <itemizedlist> - <listitem> - <para><emphasis>How to interpret Ctrl + Alt + Del</emphasis></para> - <para>When someone at the console has pressed the CTRL + ALT + DEL key combination, the system usually reboots. Sometimes it is desirable to ignore this event, for example, when the system serves as both workstation and server.</para> - </listitem> - <listitem> - <para><emphasis>Shutdown behavior of KDM</emphasis></para> - <para>Set who is allowed to shut down the machine from KDM.</para> - </listitem> - </itemizedlist> - - - </section> - <section> - <title>Login Settings</title> - <para>Change various login settings. These settings are mainly stored in the '/etc/login.defs' file.</para> - </section> - <section> - <title>New user settings (useradd settings)</title> - <para>Set the minimum and maximum possible user ID and set the minimum - and maximum possible group ID. - </para> - </section> - - </section> - - <section id="Configuration.X11"> - <title> - Monitor and X11 Configuration - </title> - <para> - FIXME - </para> - - <example> - <title> - X11 and Monitor configuration - </title> - <screen> -http://www.w3.org/2001/XInclude"/> - </screen> - </example> - - - </section> - - <section id="Configuration.Security.users"> - <title> - Users - </title> - <para> - The root user and at least one normal user can be added during install - using data supplied in the control file. User data and passwords - (encrypted or in clear text) are part of the <emphasis>configure</emphasis> resource in the - control file. - </para> - <para> - At least the root user should be configured during - auto-installation, which will insure you will be able to login after - installation is finished and of course it will insure nobody else can login - into the system (in case the password is not set). - </para> - <para>The two users in the following example are added during system - configuration.</para> - - <example> - <title> - User configuration - </title> - <screen> - http://www.w3.org/2001/XInclude"/> - </screen> - </example> - <para> - The last example shows the minimal information required for adding - users. More options are available for a more customized user account - management. The data in <filename>/etc/default/useradd</filename> is - used to determine the home directory of the user to be created in - addition to other parameters. - </para> - </section> - <section id="createprofile.scripts"> - <title>Custom user scripts</title> - <para> - By adding scripts to the auto-installation process you can customize the - installation for your needs and take control in different stages of the - installation. - </para> - <para> - In the auto-installation process, five types of scripts can be executed and they - will be described here in order of "appearance" during the installation. - </para> - <para> - <note>All scripts have to be in the <scritps> section.</note> - </para> - <para> - <itemizedlist> - <listitem><emphasis>pre-scripts</emphasis> (very early, before anything else really happened)</listitem> - <listitem><emphasis>postpartitioning-scripts</emphasis> (after partitioning and mounting to /mnt but before RPM installation - since openSUSE 11.2)</listitem> - <listitem><emphasis>chroot-scripts</emphasis> (after the package installation, before the first boot)</listitem> - <listitem><emphasis>post-scripts</emphasis> (during the first boot of the installed system, no services running)</listitem> - <listitem><emphasis>init-scripts</emphasis> (during the first boot of the installed system, all servies up and running)</listitem> - </itemizedlist> - </para> - <section id="pre-install.scripts"> - <title>Pre-Install Scripts</title> - <para> - Executed before &yast2; does any real change to the system - (Before partitioning and package installation but after the hardware detection) - </para> - <para> - You can use the pre-script to modify your profile and let autoyast read it again. - If you want to do that, you can find your profile in "/tmp/profile/autoinst.xml". - Do what you want to do with that file and store the modified version in - "/tmp/profile/modified.xml". Autoyast will read that modified script then again after - the pre-script is done. - </para> - <para> - With SUSE Linux 10.0 and all following versions it's possible to change the partitioning with fdisk - in your pre-script. With pre 10.0 versions of SUSE Linux (like SLES9), that was not possible. - </para> - <note><title>Pre-Install Scripts with confirmation</title> - <para> - Pre-scripts are executed at an early stage of the installation. - This means if you have requested to confirm the installation, the - pre-scripts will be executed before the confirmation screen - shows up. (<emphasis>profile/install/general/mode/confirm</emphasis>) - </para> - </note> - <para> - The following elements must be between the <scripts><pre-scripts config:type="list"><script> ... </script></pre-scripts>...</scripts> tags - </para> - <para> - <table frame='top'> - <title>pre script XML representation</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Element</entry> - <entry>Description</entry> - <entry>Comment</entry> - </row> - </thead> - <tbody> - <row> - <entry>location</entry> - <entry>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...). - <para><screen><location>http://10.10.0.1/myPreScript.sh</location>;</screen></para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>source</entry> - <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. - - <para><screen><source> -<![CDATA[ -echo "Testing the pre script" > /tmp/pre-script_out.txt -]]> -</source></screen></para></entry> - <entry>Either <location> or <source> must be defined</entry> - </row> - <row> - <entry>interpreter</entry> - <entry>the interpreter that must be used for the script. Supported options are shell and perl. - <para><screen><interpreter>perl</interpreter></screen></para></entry> - <entry>optional (default is shell)</entry> - </row> - <row> - <entry>filename</entry> - <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... - <para><screen><filename>myPreScript5.sh</filename></screen></para></entry> - <entry>optional. The default is the type of the script (pre-scripts) in this case</entry> - </row> - <row> - <entry>feedback</entry> - <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so - no confirmation is needed. - <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> - </row> - <row> - <entry>feedback_type</entry> - <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. - <para><screen><feedback_type>warning</feedback_type></screen></para></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> - </row> - <row> - <entry>debug</entry> - <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings - turned on. - <para><screen><debug config:type="boolean">true</debug></screen></para></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> - </row> - </tbody> - </tgroup> - </table> - </para> - </section> - - <section id="postpartitioning-install.scripts"> - <title>Postpartitioning Scripts</title> - <note> - <para>Available starting from openSUSE 11.2 only (not SLES11).</para> - </note> - <para> - Executed after &yast2; did the partitioning and wrote the fstab. The empty system is mounted to /mnt already. - This type of script is available since openSUSE 11.2 (not SLES11). - </para> - <para> - The following elements must be between the <scripts><postpartitioning-scripts config:type="list"><script> ... </script></postpartitioning-sripts>...</scripts> tags - </para> - <para> - <table frame='top'> - <title>postpartitioning script XML representation</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Element</entry> - <entry>Description</entry> - <entry>Comment</entry> - </row> - </thead> - <tbody> - <row> - <entry>location</entry> - <entry>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...). - <para><screen><location>http://10.10.0.1/myScript.sh</location>;</screen></para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>source</entry> - <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. - - <para><screen><source> -<![CDATA[ -echo "Testing postpart script" > /mnt/postpart_test.txt -]]> -</source></screen></para></entry> - <entry>Either <location> or <source> must be defined</entry> - </row> - <row> - <entry>interpreter</entry> - <entry>the interpreter that must be used for the script. Supported options are shell and perl. - <para><screen><interpreter>perl</interpreter></screen></para></entry> - <entry>optional (default is shell)</entry> - </row> - <row> - <entry>filename</entry> - <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... - <para><screen><filename>myScript5.sh</filename></screen></para></entry> - <entry>optional. The default is the type of the script (postpartitioning-scripts in this case)</entry> - </row> - <row> - <entry>feedback</entry> - <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so - no confirmation is needed. - <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> - </row> - <row> - <entry>feedback_type</entry> - <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. - <para><screen><feedback_type>warning</feedback_type></screen></para></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> - </row> - <row> - <entry>debug</entry> - <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings - turned on. - <para><screen><debug config:type="boolean">true</debug></screen></para></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> - </row> - </tbody> - </tgroup> - </table> - </para> - </section> - - - - <section id="chroot.scripts"> - <title>Chroot environment scripts</title> - <para>Chroot scripts are executed before the machine reboots for the first time. - Actually chroot scripts are two differnt kind of script with - one name. You can execute chroot script before the installation chroots into - the installed system and configures the boot loader and you can execute a script - after the chroot into the installed system has happend (look at the "chrooted" parameter for that). Both types of scripts are - executed before yast2 boots for the first time. - </para> - <para> - The following elements must be between the <scripts><chroot-scripts config:type="list"><script> ... </script></chroot-scripts>...</scripts> tags - </para> - <para> - <table frame='top'> - <title>chroot script XML representation</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Element</entry> - <entry>Description</entry> - <entry>Comment</entry> - </row> - </thead> - <tbody> - <row> - <entry>location</entry> - <entry>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...). - <para> - <screen><location>http://10.10.0.1/myChrootScript.sh</location>;</screen> - </para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>source</entry> - <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. - <para><screen><source> -<![CDATA[ -echo "Testing the chroot script" > /tmp/chroot_out.txt -]]> -</source></screen></para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>chrooted</entry> - <entry>this value can be true or false. "False" means that the installed system is still mounted at "/mnt" and no chrooting has happened till now. The bootloader is not installed too at that stage. "True" means, we did a chroot into /mnt, so we are now in the installed system. The bootloader is installed and if you want to change anything in the installed system, you don't have to use the "/mnt/" prefix anymore. - <para><screen><chrooted config:type="boolean">true</chrooted></screen></para></entry> - <entry>optional (the default is false)</entry> - </row> - <row> - <entry>interpreter</entry> - <entry>the interpreter that must be used for the script. Supported options are shell and perl.and if you are in a chrooted=true condition, you can use python too if it's installed. - <para><screen><interpreter>perl</interpreter></screen></para></entry> - <entry>optional (default is shell)</entry> - </row> - <row> - <entry>filename</entry> - <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... - <para><screen><filename>myPreScript5.sh</filename></screen></para></entry> - <entry>optional. The default is the type of the script (chroot-scripts) in this case</entry> - </row> - <row> - <entry>feedback</entry> - <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so - no confirmation is needed. - <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> - </row> - <row> - <entry>feedback_type</entry> - <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. - <para><screen><feedback_type>warning</feedback_type></screen></para></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> - </row> - <row> - <entry>debug</entry> - <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings - turned on. - <para><screen><debug config:type="boolean">true</debug></screen></para></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> - </row> - </tbody> - </tgroup> - </table> - </para> - </section> - <section id="post-insall.scripts"> - <title>Post-Install Scripts</title> - <para> - These scripts are executed after AutoYaST has completed the - system configuration and after it has booted the system for the first time. - </para> - <para> - It is possible to execute the post scripts in an earlier phase while - the installation network is still up and before AutoYaST configures - the system. To run network enabled post scripts, the boolean - property <emphasis>network_needed</emphasis> has to be set to true. - </para> - <para> - The following elements must be between the <scripts><post-scripts config:type="list"><script> ... </script></post-scripts>...</scripts> tags - </para> - <para> - <table frame='top'> - <title>post script XML representation</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Element</entry> - <entry>Description</entry> - <entry>Comment</entry> - </row> - </thead> - <tbody> - <row> - <entry>location</entry> - <entry>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...) but then you need a running network interface of course - <para> - <screen><location>http://10.10.0.1/myPostScript.sh</location>;</screen> - </para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>source</entry> - <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. - <para><screen><source> -<![CDATA[ -echo "Testing the chroot script" > /tmp/chroot_out.txt -]]> -</source></screen></para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>network_needed</entry> - <!-- FIXME: double check that. I'm very unsure if this is correct --> - <entry>this value can be true or false. On "false" the script will run after the yast modules like the user configuration and everything else are done. The network is configured but still not up and running. With this value on "true", the script runs before(!) all yast modules are configured. So there is no local user and no network is configured but the installation network is still up and running (of course only if you did a network installation). - <para><screen><network_needed config:type="boolean">true</network_needed></screen></para></entry> - <entry>optional (the default is false)</entry> - </row> - <row> - <entry>interpreter</entry> - <entry>the interpreter that must be used for the script. Supported options are shell, perl and python if it's installed. - <para><screen><interpreter>perl</interpreter></screen></para></entry> - <entry>optional (default is shell)</entry> - </row> - <row> - <entry>filename</entry> - <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... - <para><screen><filename>myPostScript5.sh</filename></screen></para></entry> - <entry>optional. The default is the type of the script (post-scripts) in this case</entry> - </row> - <row> - <entry>feedback</entry> - <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the - user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so - no confirmation is needed. - <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> - <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> - </row> - <row> - <entry>feedback_type</entry> - <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. - <para><screen><feedback_type>warning</feedback_type></screen></para></entry> - <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> - </row> - <row> - <entry>debug</entry> - <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings - turned on. - <para><screen><debug config:type="boolean">true</debug></screen></para></entry> - <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> - </row> - </tbody> - </tgroup> - </table> - </para> - </section> - <section id="init.scripts"> - <title>Init Scripts</title> - <para> - These scripts are executed during the initial boot process and after - &yast2; has finished. The final scripts are executed using a special - <emphasis>init.d</emphasis> script which is executed only - once. The final scripts are executed toward the end of the boot - process and after network has been intialized. - </para> - <para> - Init scripts are configured using the tag <emphasis>init-scripts</emphasis> and - are run using the special purpose <emphasis>init.d</emphasis> script <filename>/etc/init.d/autoyast</filename>. - </para> - <para> - The following elements must be between the <scripts><init-scripts config:type="list"><script> ... </script></init-scripts>...</scripts> tags - </para> - <para> - <table frame='top'> - <title>init script XML representation</title> - <tgroup cols="3"> - <thead> - <row> - <entry>Element</entry> - <entry>Description</entry> - <entry>Comment</entry> - </row> - </thead> - <tbody> - <row> - <entry>location</entry> - <entry>you can define a location from where the script gets fetched. - Locations can be the same like for the profile (http,ftp,nfs,...) but then you need a running network interface of course - <para> - <screen><location>http://10.10.0.1/myInitScript.sh</location>;</screen> - </para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>source</entry> - <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want - to put the whole shell script into the XML profile, look at the location parameter. - <para><screen><source> -<![CDATA[ -echo "Testing the init script" > /tmp/init_out.txt -]]> -</source></screen></para></entry> - <entry>either <location> or <source> must be defined</entry> - </row> - <row> - <entry>filename</entry> - <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... - <para><screen><filename>mynitScript5.sh</filename></screen></para></entry> - <entry>optional. The default is the type of the script (init-scripts) in this case</entry> - </row> - </tbody> - </tgroup> - </table> - </para> - </section> - <para> - When added to the control file manually, the - scripts have to be included in a <emphasis>CDATA</emphasis> element to avoid confusion with - the file syntax and other tags defined in the control file. - </para> - <section id="script_examples"> - <title>Script example</title> - <example> - <title>Post script configuration</title> - <screen> - http://www.w3.org/2001/XInclude"/> - - </screen> - </example> - <para> - After installation is finished, the scripts and the output logs can be - found in the directory <filename>/var/adm/autoinstall</filename>. The - scripts are located in <filename>scripts</filename> and the output logs of the - scripts are located in the <filename>log</filename> directory. - </para> - <para> - The log is the output resulting when executing the shell scripts using - the following command: - </para> - <screen> - <![CDATA[ - /bin/sh -x <script_name> 2&> /var/adm/autoinstall/logs/<script_name>.log - ]]> - </screen> - </section> - </section> - - - <section id="createprofile.sysconfig"> - <title>System variables (Sysconfig)</title> - <para> - Using the sysconfig resource, it is possible to define configuration - variables in the sysconfig repository - (<filename>/etc/sysconfig</filename>) directly. Sysconfig - variables, offer the possibility to fine-tune many system components and - environment variables exactly to your needs. - </para> - - <para> - Refer to the handbook for more details about the many - configuration options available in <filename>/etc/sysconfig</filename> - </para> - <para> - The following example shows how a variable can be set using the sysconfig - resource. - </para> - &example.sysconfig; - </section> - - - <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> + 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> @@ -3074,1027 +57,12 @@ automatically available as an auto-installation resource. </para> - <section id="CreateProfile.Hardware.Printer"> - <title> - Printer - </title> - - <para> - Although Printer configuration, like other configurations can be - done manually, it is recommended to use the Configuration System to - create such a configuration because of the complexity and the range - of options offered by such modules. - </para> - <para> - Using the configuration system will guarantee that the options - provided are consistent. The following is an example of a - configuration section which was - created using the configuration system. - </para> - &example.printer; - </section> - - <section id="CreateProfile.Hardware.Sound"> - <title> - Sound devices - </title> - <para> - An example of sound configuration created using the configuration - system is shown below. - </para> - &example.sound; - </section> - </section> - - <!-- {{{ 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> - <!-- }}} --> - - <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 (not SLES11) 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. - <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 in openSUSE 11.2 (not SLES11)</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 in openSUSE 11.2 (not SLES11)</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 in openSUSE 11.2 (not SLES11)</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 but not in SLES11)</entry> - <entry>with 11.2 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 (not SLES11). - </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 "false"). 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> + 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> </chapter> Added: trunk/autoinstallation/doc/FilesSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/FilesSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/FilesSection.xml (added) +++ trunk/autoinstallation/doc/FilesSection.xml Fri Mar 5 11:16:35 2010 @@ -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/GeneralSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/GeneralSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/GeneralSection.xml (added) +++ trunk/autoinstallation/doc/GeneralSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,153 @@ +<!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> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + + + <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> + 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/KDumpSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/KDumpSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/KDumpSection.xml (added) +++ trunk/autoinstallation/doc/KDumpSection.xml Fri Mar 5 11:16:35 2010 @@ -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/LDAPSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/LDAPSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/LDAPSection.xml (added) +++ trunk/autoinstallation/doc/LDAPSection.xml Fri Mar 5 11:16:35 2010 @@ -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/MailSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/MailSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/MailSection.xml (added) +++ trunk/autoinstallation/doc/MailSection.xml Fri Mar 5 11:16:35 2010 @@ -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/NFSSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/NFSSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/NFSSection.xml (added) +++ trunk/autoinstallation/doc/NFSSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,73 @@ +<!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> + <title> + NFS Client and Server + </title> + <para> + Configuration of a system as an NFS client or an NFS server is + possible and can be done using the configuration system. The + following examples shows how both NFS client and server can be configured. + </para> + <para> + Up to SLE11 and openSUSE 11.2, the following structure of NFS client configuration + is used: + </para> + <example> + <title> + Network configuration: NFS client + </title> + <screen> + + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + <para> + From openSUSE 11.3 (SLE12 respectively) on, the structure of NFS client configuration + has changed. Some global configuration options were introduced - <emphasis>enable_nfs4</emphasis> + to switch NFS4 support on/off and <emphasis>idmapd_domain</emphasis> to define domain name for + rpc.idmapd (this only makes sense with enabled NFS4). Attention: the old structure is not + compatible with the new one and the profiles with NFS section created on older releases will not + work with newer products. + </para> + <example> + <title> + Network configuration: NFS client - new style (openSUSE 11.3 and newer) + </title> + <screen> + + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + + <example> + <title> + Network configuration: NFS Server + </title> + <screen> + + + http://www.w3.org/2001/XInclude"/> + </screen> +</example> + </section> + Added: trunk/autoinstallation/doc/NISSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/NISSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/NISSection.xml (added) +++ trunk/autoinstallation/doc/NISSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,42 @@ +<!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.NIS"> + <title>NIS</title> + <para> + Using the <emphasis>nis</emphasis> resource, you can configure the target machine as a <emphasis>NIS + client</emphasis>. The following example shows a detailed + configuration using multiple domains. + </para> + &example.nis; + </section> + <!-- + <section id="Configuration.Network.NISplus"> + <title> + NIS+ + </title> + <para> + If you activate NIS+, the data of the + NIS+ Server will be added to <filename>/etc/hosts</filename>. Keyserv and the NIS+ cache manager + will be started and the NSS and PAM configuration will be modified to use + NIS+ and set the Secret Key of a user. + </para> + &example.nisplus; + </section> + --> + Added: trunk/autoinstallation/doc/NTPSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/NTPSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/NTPSection.xml (added) +++ trunk/autoinstallation/doc/NTPSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,49 @@ +<!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.Ntp'> + <title> + NTP Client + </title> + <para> + Select whether to start the NTP daemon when booting the system. The NTP + daemon resolves host names when initializing. The first + synchronization of the clock is performed before the NTP daemon is + started. To use this host for initial synchronization configure the + property <emphasis>initial_sync</emphasis>. + </para> + <para> + To run NTP daemon in + chroot jail, set <emphasis>start_in_chroot</emphasis>. Starting any daemon + in a chroot jail is more secure and strongly recommended. + To adjust NTP servers, peers, local clocks, and NTP broadcasting, + add the appropriate entry to the control file. an example of various + configuration options is shown below. + </para> + <example> + <title> + Network configuration: NTP Client + </title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> +</example> + </section> + Added: trunk/autoinstallation/doc/NetworkSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/NetworkSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/NetworkSection.xml (added) +++ trunk/autoinstallation/doc/NetworkSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,111 @@ +<!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.Network"> + <title> + Network configuration + </title> + + <section id="Configuration.Network.Devices"> + <title> + Network devices, DNS and Routing. + </title> + <para> + Network configuration is used to connect a single &company-suse; Linux + workstation to an Ethernet-based LAN or to configure dial-up + connection. More complex configuration (multiple network cards, + routing, etc.) is also provided. With this module it's possible to + configure and setup Ethernet Controllers and Token-Ring Controllers. + </para> + <para> + In the networking section, when this option is set to true (default is false, this option is available since openSUSE 11.2 but not SLES11): + <screen> + <keep_install_network config:type="boolean">true</keep_install_network> + </screen> + YaST will keep network settings created during installation (via Linuxrc) + and/or merge it with network settings from the AutoYaST profile (if these are defined). + AutoYaST settings have higher priority than already present configuration files. + YaST will write ifcfg-* files from profile without removing old ones. + If there is none (or empty) dns and routing section, YaST will keep already present values. Otherwise settings from the profile will be applied. + </para> + <para> + To configure network settings and activate networking automatically, + one global resource is used to store the whole network configuration. + </para> + + &example.network; + </section> + + <section id="Configuration.Network.Proxy"> + <title> + Proxy + </title> + <para> + Configure your Internet proxy (caching) settings using this + resource. + </para> + <para> + <emphasis>HTTP proxy</emphasis> is the name of the proxy server for your access to the world wide web (WWW). + <emphasis>FTP proxy</emphasis> is the name of the proxy server for your access to the file transfer services (FTP). + <emphasis>No proxy</emphasis> domains is a list of domains for + which the requests should be done directly without caching. + </para> + <para> + If you are using a proxy server with authorization, fill in Proxy user name and Proxy password. + </para> + <example> + <title> + Netwrok configuration: Proxy + </title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + + + </section> + <section id="Configuration.Network.Inetd"> + <title>(X)Inetd </title> + + <para> + The profile has elements to specify which superserver should be + used (netd_service), whether it should be enabled (netd_status) and + how the services should be configured (netd_conf). + </para> + <para> + A service description element has conceptually two parts: key and + non-key. When writing the configuration, services are matched using + the key fields and to the matching service, non-key fields are + applied. If no service matches, it is created. If more services + match, a warning is reported. The key fields are script, service, + protocol and server. + </para> + <para> + Service and protocol are matched literally. script is the base name + of the config file: usually a file in<filename> /etc/xinetd.d</filename>, for example "echo-udp", + or "inetd.conf". For compatibility with 8.2, server is matched more + loosely: if it is <filename>/usr/sbin/tcpd</filename>, the real server name is taken from + server_args. After that, the basename of the first + whitespace-sparated word is taken and these values are compared. + </para> + &example.inetd; + + </section> + </section> + Added: trunk/autoinstallation/doc/PartitioningSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/PartitioningSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/PartitioningSection.xml (added) +++ trunk/autoinstallation/doc/PartitioningSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,982 @@ +<!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.Partitioning"> + <title> + Partitioning + </title> + + <section> + <title>drive configuration</title> + <warning> + <title> + EVMS support dropped in openSUSE 11.1 and SLES11 + </title> + <para> +since openSUSE 11.1 and SLES11 there is no longer support for EVMS in the installation system. That means all support for EVMS in AutoYaST was dropped too. Alll EVMS documentation on this page is on valid for SLES10 (all service packs) and openSUSE versions prior openSUSE 11.1 + </para> + </warning> + <para> + The following elements must be between the <partitioning config:type="list"><drive> ... </drive></partitioning> tags in the <profile> section. + </para> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>device</entry> + <entry>the device you want to configure in this section. Since SUSE Linux 10.1 and SLES10, you can use persistent device names via id, like <emphasis>/dev/disk/by-id/ata-WDC_WD3200AAKS-75L9A0_WD-WMAV27368122</emphasis>. With SLES10 SP1 and SUSE Linux 10.2, <emphasis>by-path</emphasis> is possible too like <emphasis>/dev/disk/by-path/pci-0001:00:03.0-scsi-0:0:0:0</emphasis>. + <para><screen><device>/dev/hda</device></screen></para> + </entry> + <entry>optional. If left out, autoyast tries to guess the device. A RAID must always have "/dev/md" as device</entry> + </row> + <row> + <entry>initialize</entry> + <entry>if set to true, the partition table gets wiped out before autoyast starts the partition calculation +<para><screen><initialize config:type="boolean">true</initialize></screen></para> +</entry> + <entry>optional. The default is false.</entry> + </row> + <row> + <entry>is_lvm_vg</entry> + <entry>This tells autoyast that this device is not a physical device but a LVM volume group (see LVM configuration below) +<para><screen><is_lvm_vg config:type="boolean">true</is_lvm_vg></screen></para> +</entry> + <entry>DEPRECATED since SLES10SP1 and SL10.2 - use <emphasis>type</emphasis> instead. Must be true if this device is a LVM volume group. The default is false.</entry> + </row> + <row> + <entry>is_evms_vg</entry> + <entry>this tells autoyast that this device is not a physical device but an EVMS volume group (see EVMS configuration below) +<para><screen><is_evms_vg config:type="boolean">true</is_evms_vg></screen></para> +</entry> + <entry>DEPRECATED since SLES10SP1 and SL10.2 - use <emphasis>type</emphasis> instead. Must be true if this device is an EVMS volume group. The default is false.</entry> + </row> + <row> + <entry>partitions</entry> + <entry>this is a list of <partition> entries (see table below) +<para><screen><partitions config:type="list"><partition>...</partition>...</partitions></screen></para> +</entry> + <entry>optional. If no partition is specified, autoyast will create it's own idea of a nice partitioning (see Automated Partitioning below).</entry> + </row> + <row> + <entry>pesize</entry> + <entry>this value makes only sense with LVM/EVMS. +<para><screen><pesize>8M</pesize></screen></para> +</entry> + <entry>optional. Default is 4M for EVMS/LVM volume groups.</entry> + </row> + <row> + <entry>use</entry> + <entry>this parameter tells autoyast which strategy it shall use to partition the harddisc. +<para>You can choose between:</para> +<itemizedlist> +<listitem> +<para>all (uses the whole device while calculating the new partitioning)</para> +</listitem> +<listitem> +<para>linux (only existing linux partitions are used)</para> +</listitem> +<listitem> +<para>free (only unused space on the device gets used. No other partitions gets touched)</para> +</listitem> +<listitem> +<para>1,2,3 (a list of comma seperated numbers that indicates the partition numbers to use)</para> +</listitem> +</itemizedlist> +</entry> + <entry>this parameter should be provided</entry> + </row> + <row> + <entry>type</entry> + <entry>this value describes the type of the <emphasis>drive</emphasis> and is a replacement for +<emphasis>is_lvm_vg</emphasis> and <emphasis>is_evms_vg</emphasis> used in SLES10 and SL10.1 +<para>You can choose between:</para> +<itemizedlist> +<listitem> +<para>CT_DISK for physical harddisks (default)</para> +</listitem> +<listitem> +<para>CT_LVM for LVM volume groups</para> +</listitem> +<listitem> +<para>CT_EVMS for EVMS volume groups</para> +</listitem> +</itemizedlist> + +<para><screen><type config:type="symbol">CT_LVM</type></screen></para> +</entry> + <entry>optional. Default is CT_DISK for a normal physical harddisk.</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + + <section> + <title>partition configuration</title> + <para> + The following elements must be between the <partitions config:type="list"><partition> ... </partition></partitions> tags in the <drive> section. + </para> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>create</entry> + <entry> + <para> + the "create" tells autoyast if this partition must be created or if it's already existing + </para> + <para><screen><create config:type="boolean">false</create></screen></para> + </entry> + <entry>if set to false, there must be some information for autoyast which partition this is (like with partition_nr)</entry> + </row> + <row> + <entry>mount</entry> + <entry> + <para> + the mountpoint of this partition. + </para> + <para><screen><mount>/</mount></screen></para> + <para><screen><mount>swap</mount></screen></para> + </entry> + <entry>you should have at least a root partition (/) and a swap partition</entry> + </row> + <row> + <entry>fstopt</entry> + <entry> + <para> + mount options for this partition + </para> + <para><screen><fstopt>ro,noatime,user,data=ordered,acl,user_xattr</fstopt></screen></para> + </entry> + <entry>see "man mount" for the mountoptions you can use</entry> + </row> + <row> + <entry>label</entry> + <entry> + <para> + the label the partition has (useful for the "mountby" parameter - see below). + </para> + <para><screen><label>mydata</label></screen></para> + </entry> + <entry>see "man e2label" for example.</entry> + </row> + <row> + <entry>uuid</entry> + <entry> + <para> + the uuid the partition has (only useful for the "mountby" parameter - see below). + </para> + <para><screen><uuid>1b4e28ba-2fa1-11d2-883f-b9a761bde3fb</uuid></screen></para> + </entry> + <entry>see "man uuidgen"</entry> + </row> + <row> + <entry>size</entry> + <entry> + <para> + the size for the partition like 4G, 4500M, ... The /boot partition and the swap partition can have "auto" as + size too, to let autoyast calculate a reasonable size for them. On partition can have the value "max" to fillup + all available space. + </para> + <para> + with SUSE Linux 10.2 and SLES10 SP1, you can specify the the size in percentage. So 10% will use 10% of the size + of the harddisk/VG. You can mix auto,max,sizes and percentage like you want. + </para> + <para><screen><size>10G</size></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>format</entry> + <entry> + <para> + shall autoyast format the partition? + </para> + <para><screen><format config:type="boolean">false</format></screen></para> + </entry> + <entry>if "create" is true, then it's very likely that this is true too</entry> + </row> + <row> + <entry>filesystem</entry> + <entry> + <para> + what filesystem is used on this partition? +<itemizedlist> +<listitem> +<para>reiser (the default)</para> +</listitem> +<listitem> +<para>ext2</para> +</listitem> +<listitem> +<para>ext3</para> +</listitem> +<listitem> +<para>xfs</para> +</listitem> +<listitem> +<para>jfs</para> +</listitem> +<listitem> +<para>swap</para> +</listitem> +</itemizedlist> + </para> + <para><screen><filesystem config:type="symbol">reiser</filesystem></screen></para> + </entry> + <entry>optional. The default is reiser</entry> + </row> + <row> + <entry>partition_nr</entry> + <entry> + <para> + the partition_nr this partition has/will have. If you have set create=false, then you can tell + autoyast which partition you mean by the partition_nr. You can force autoyast to create only + primary partitions by configuring only partition numbers below 5. + </para> + <para><screen><partition_nr config:type="integer">2</partition_nr></screen></para> + </entry> + <entry>in most cases nr. 1-4 are primary partitions and 5-... are logical partitions</entry> + </row> + <row> + <entry>partition_id</entry> + <entry> + <para> + the partition_id configures the id of the partition. If you want something else than 131 + for linux partition or 130 for swap, you must configure that with partition_id. + </para> + <para><screen><partition_id config:type="integer">131</partition_id></screen></para> + </entry> + <entry>the default is 131 for linux partition. 130 for swap is set by autoyast itself too.</entry> + </row> + <row> + <entry>filesystem_id</entry> + <entry> + <para> + look at partition_id above. For historical reasons they represent the same. + </para> + <para><screen><filesystem_id config:type="integer">131</filesystem_id></screen></para> + </entry> + <entry>since 10.1 and SLES10 it's recommended to use partition_id instead.</entry> + </row> + <row> + <entry>mountby</entry> + <entry> + <para> + instead of a partition number, you can tell autoyast to mount a partition by label, uuid, path or id which are the udev path and udev id (see /dev/disk/...) + </para> + <para><screen><mountby config:type="symbol">label</mountby></screen></para> + </entry> + <entry>see "label" and "uuid" documentation above</entry> + </row> + <row> + <entry>lv_name</entry> + <entry> + <para> + if this partition is in a logical volume in a volume group (LVM or EVMS) + (see is_lvm_vg/is_evms_vg parameter in drive configuration) you + must specifiy the logical volume name here. + </para> + <para><screen><lv_name>opt_lv</lv_name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>stripes</entry> + <entry> + <para> + It's an integer that tells AutoYaST to do LVM striping. You can configure across how man devices you want to stripe + </para> + <para><screen><stripes config:type="integer">2</stripes></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>stripesize</entry> + <entry> + <para> + It's an integer that tells AutoYaST the size of each block in kb + </para> + <para><screen><stripesize config:type="integer">4</stripesize></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>lvm_group</entry> + <entry> + <para> + if this is a physical partition that is used by (part of) a volume group (LVM), + you have to specify the name of the volume + group here. + </para> + <para><screen><lvm_group>system</lvm_group></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>evms_group</entry> + <entry> + <para> + if this physical partition is used by a volume group (EVMS), you have to specify the name of the volume + group here. + </para> + <para><screen><evms_group>system</evms_group></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>raid_name</entry> + <entry> + <para> + this physical volume is part of a RAID and the name of the raid is specified here. + </para> + <para><screen><raid_name>/dev/md0</raid_name></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>raid_type</entry> + <entry> + <para> + this physical volume is part of a RAID and the type of the raid is specified here.. + </para> + <para><screen><raid_type>raid1</raid_type></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>raid_options</entry> + <entry> + <para> + special options for the raid are specified here. See below. + </para> + <para><screen><raid_options>...</raid_options></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>resize</entry> + <entry> + <para> + This parameter is available since SLES10 SP1 and OpenSUSE 10.2. + This boolean must be true if an existing partition should be resized. In this case, + you want to set <emphasis>create</emphasis> to <emphasis>false</emphasis> too and in + most cases you don't want to <emphasis>format</emphasis> the partition. You need to + tell autoyast the <emphasis>partition_nr</emphasis> and the <emphasis>size</emphasis>. + The size can be in percentage of the original size or as a number of the new size, like + <emphasis>800M</emphasis>. <emphasis>max</emphasis> and <emphasis>auto</emphasis> don't + work as size here. + </para> + <para><screen><resize config:type="boolean">false</resize></screen></para> + </entry> + <entry>The resize only works with physical disks. Not with LVM/EVMS volumes.</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + <section> + <title>raid options</title> + <para> + The following elements must be between the <partition><raid_options> ... </raid_options></partition> tags. + </para> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>chunk_size</entry> + <entry> + <para> + </para> + <para><screen><chunk_size>4</chunk_size></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>parity_algorithm</entry> + <entry> + <para> + possible values are: left_asymmetric, left_symmetric, right_asymmetric, right_symmetric + </para> + <para><screen><parity_algorithm>left_asymmetric</parity_algorithm></screen></para> + </entry> + <entry></entry> + </row> + <row> + <entry>raid_type</entry> + <entry> + <para> + possible values are raid0,raid1 and raid5 + </para> + <para><screen><raid_type>raid1</raid_type></screen></para> + </entry> + <entry>the default is raid1</entry> + </row> + </tbody> + </tgroup> + </table> + </section> + <section> + <title> + Automated Partitioning + </title> + + <para> + For the automated partitioning to be completed, only the sizes and mount points of + partitions can be provided. All other data needed for successful partitioning + can be calculated during installation if they were not provided in the control file. + </para> + <para> + If no partitions are defined and the specified drive is also the drive where + the root partition should be created, the following partitions are created + automatically: + </para> + <itemizedlist> + <listitem> + <para> + <emphasis>/boot</emphasis> + </para> + <para> + Size of the <emphasis>/boot</emphasis> is determined by the + architecture of the target system. + </para> + </listitem> + <listitem> + <para> + <emphasis>swap</emphasis> + </para> + <para> + Size of the <emphasis>swap</emphasis> partitions is determined by the + amount of memory available in the system. + </para> + </listitem> + <listitem> + <para> + <emphasis>/</emphasis> (root partition) + </para> + <para> + Size of the <emphasis>/</emphasis> (root partition) is the space left + after creating <emphasis>swap</emphasis> and <emphasis>/boot</emphasis>. + </para> + </listitem> + </itemizedlist> + + <para> + Depending on the initial status of the drive and how it was + previously partitioned, it is possible to create the <emphasis>default</emphasis> + partitioning in the following ways: + </para> + <itemizedlist> + <listitem> + <para> + <emphasis>Use free space</emphasis> + </para> + <para> + If the drive is already partitioned, it is possible to create the + new partitions using the available space on the hard drive. This + requires the availability of enough space for all selected + packages in addition to swap. + </para> + </listitem> + <listitem> + <para> + <emphasis>Reuse all available space</emphasis> + </para> + <para> + This option will lead to the deletion of all existing + partitions (Linux and non-Linux partitions). + + </para> + </listitem> + + <listitem> + <para> + <emphasis>Reuse all available Linux partitions</emphasis> + </para> + <para> + This option will lead to the deletion of existing Linux + partitions. All other partitions (i.e. Windows) will be + kept. Note that this works only if the Linux partitions are at the end of the device. + + </para> + </listitem> + + <listitem> + <para> + <emphasis>Reuse only specified partitions</emphasis> + </para> + <para> + This option will lead to the deletion of the specified partitions. + The selection of the partitions scheduled for deletion should be + started from the last available partition. + </para> + </listitem> + </itemizedlist> + <para> + Repartitioning using only some of the existing partitions can be + accomplished only if the region selected to be partitioned exists at + the end of the device and only with neighboring partitions. This + means that you cannot repartition a region which contains a partition that + should not be touched in the middle. + </para> + + <caution> + <title>Important Notice</title> + <para> + The value provided in the <emphasis>use</emphasis> property determines how existing data and + partitions are treated. The value <emphasis>all</emphasis> means that + <emphasis>ALL</emphasis> data on the disk will + be erased. Make backups and use the <emphasis>confirm</emphasis> + property if you are going to + keep some partitions with important data. This is automated + installation and no pop-ups will notify you about partitions being deleted. + </para> + </caution> + <para> + In case of the presence of multiple drives in the target system, all + drives must be identified with their device names and how the partitioning should be performed. + </para> + + <para> + Partition sizes can be given in Gigabytes, Megabytes or can be set to + a flexible value using the keywords <emphasis>auto</emphasis> and + <emphasis>max</emphasis>. <emphasis>max</emphasis> is used to fill a + partition to the maximal available space on a + drive (Which mean that the partition should be the last one on the drive). + <emphasis>auto</emphasis> can be used to determine the size of + a <emphasis>swap</emphasis> or <emphasis>boot</emphasis> partitions + depending on the memory available and the type of the system. + </para> + <para>A fixed size can be given as shown below:</para> + <para> + <emphasis>1GB</emphasis> will create a partition with 1 GB size. + <emphasis>1500MB</emphasis> will create a partition which is 1.5 GB big. + </para> + <example> + <title>Automated partitioning</title> + <para> + The following is an example of a single drive system, which is not + pre-partitioned and should be automatically partitioned according to + the described pre-defined partition plan. If you leave the device out, + an autodetection of the device will happen. So you don't have to do + different profiles for /dev/sda or /dev/hda systems. + </para> + <screen> + http://www.w3.org/2001/XInclude"/> + + </screen> + </example> + <para> + A more detailed example shows how existing partitions and + multiple drives are handled. + </para> + <example> + <title>Detailed automated partitioning</title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + </section> + + <section> + <title>Advanced Partitioning features</title> + <section> + <title>Wipe out partition table</title> + <para> + In the most cases this is not needed because autoyast can delete partitions + one by one automatically but you have the option to let autoyast clear the partition table + instead of deleting the partitions individually. + </para> + <para> + if you go into the "drive" section, you can add + <screen> +<![CDATA[ +<initialize config:type="boolean">true</initialize> +]]> +</screen> + which tells Autoyast to delete the partition table before it starts to analyse the + actual partitioning and calculates it's partition plan. Of course this means, that you + can't keep any of your existing partitions. + </para> + </section> + <section> + <title>Mount Options</title> + <para> + By default a file system which is to be mounted is + identified in <filename>/etc/fstab</filename> by the device name. This identification + can be changed so the file system is found by searching + for a <acronym>UUID</acronym> or a volume label. Note that not all file systems can be mounted + by <acronym>UUID</acronym> or a volume label. To specify how a + partition is to be mounted, use the <emphasis>mountby</emphasis> + property which has the <emphasis>symbol</emphasis> type. Possible + options are: + </para> + <itemizedlist> + <listitem> + <para>device (default)</para> + </listitem> + <listitem> + <para>label</para> + </listitem> + <listitem> + <para>UUID</para> + </listitem> + </itemizedlist> + <para> + If you choose to mount the partition using a label, the name + entered in the <emphasis>label</emphasis> property is used as the + volume label. + </para> + <para> + Add any legal mount option allowed in the fourth field of + <filename>/etc/fstab</filename>. Multiple options are separated by commas. Possible fstab options: + </para> + <itemizedlist> + <listitem> + <para><emphasis>Mount Read-Only (ro):</emphasis> No writable + access to the file system is possible. Default is false.</para> + + </listitem> + <listitem> + <para><emphasis>No access time (noatime):</emphasis> Access times + are not updated when a file is read. Default is false.</para> + + </listitem> + <listitem> + <para><emphasis>Mountable by User (user):</emphasis> The file + system may be mounted by an ordinary user. Default is + false.</para> + + </listitem> + <listitem> + <para> + <emphasis>Data Journaling Mode (ordered | journal | + writeback) :</emphasis> Specifies the journaling mode for + file data. journal -- All data is committed into the journal + prior to being written into the main file system. ordered -- + All data is forced directly out to the main file system prior + to its meta data being committed to the journal. writeback -- + Data ordering is not preserved. + </para> + </listitem> + <listitem> + <para> + <emphasis>Access Control List (acl):</emphasis> Enable access + control lists on the file system. + </para> + </listitem> + <listitem> + <para> + <emphasis>Extended User Attributes (user_xattr):</emphasis> Allow + extended user attributes on the file system. + </para> + </listitem> + + </itemizedlist> + <example> + <title>Mount Options</title> + + <screen> + http://www.w3.org/2001/XInclude"/> + + </screen> + </example> + </section> + + <section> + <title>Keeping Specific Partitions</title> + <para> + In some cases you might choose to keep some partitions untouched + and only format specific target partitions, rather than creating them from + scratch. This might be the case of Linux installations have to + co-exist with another operating system or if certain partitions + contain data that you wish to keep untouched. + </para> + <para> + Such scenarios require certain knowledge about the target systems + and hard drives. Depending on the scenario, you might need to know + the exact partition table of the target hard drive with partition + id's, sizes and numbers. With such data you can tell &autoyast; to + keep certain partitions, format others and create new partitions if + needed. + </para> + + <para> + The following example will keep partitions 1, 2 and 5 and delete + partition 6 to create two new partitions. All kept partitions will + be only formatted. + </para> + <example> + <title> + Keeping partitions + </title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + <para> + The last example requires exact knowledge about the existing partition + table and about the partition numbers of those partitions that + should be kept. In some cases however, such data might be not + available, especially in a mixed hardware environment with + different hard drive types and configurations. The following + scenario is for a system with a non-Linux OS with a designated + area for a Linux installation. + </para> + <figure id="partitioning-keep1"> + <title id="partitioning-keep1.title" >Keeping partitions</title> + <mediaobject>&partitioning-keep1;</mediaobject> + </figure> + + <para> + In this scenario and as shown in figure <quote></quote> , &autoyast2; + should not in any case create any new + partitions, instead it should search for certain partition types on the system and use + them according to the partitioning plan in the control file. No + partition numbers are given in this case, only the mount points and + the partition types (Additional configuration data can be provided, + for example file system options, encryption and filesystem type) + </para> + <example> + <title> Auto-detection of partitions to be kept.</title> + <screen> http://www.w3.org/2001/XInclude"/></screen> + </example> + </section> + </section> + + <section> + <title>Using existing mount table (fstab)</title> + <note> + <title>New Feature</title> + </note> + <para> + This option will allow the AutoYaST to use an existing + <filename>/etc/fstab</filename> and use the partition data from + from a previous installation. All partitions are kept and no new + partitions are created. The found partitions will be formatted and + mounted as specified in <filename>/etc/fstab</filename> found on a + Linux root partition. + </para> + <para> + Although the default behaviour is to format all partitions, it is + also possible to leave some partitions untouched and only mount them, + for example data partitions. If multiple installations are found on + the system (multiple root partitions with different + <emphasis>fstab</emphasis> files, the installation will abort, unless + the desired root partition is configured in the control file. The + following example illustrates how this option can be used: + </para> + <example> + <title> + Reading existing <filename>/etc/fstab</filename> + </title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + </section> + + <section> + <title> + Logical Volume Manager (LVM) + </title> + <para> + To configure LVM, first you need to create a <emphasis>physical volume</emphasis> using the + normal partitioning method described above. + </para> + <example> + <title> + Create LVM Physical Volume + </title> + <para> + The following example shows how to prepare for LVM in the + <emphasis>partitioning</emphasis> resource: + </para> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + + </example> + <para> + The last example will create a non-formatted partition on device + <filename>/dev/sda1</filename> of the type <emphasis>LVM</emphasis> and + with the volume group <emphasis>system</emphasis>. The partition + created will use all available space on this drive. + </para> + + <example> + <title> + LVM Logical Volumes (New syntax) + </title> + <screen> +http://www.w3.org/2001/XInclude"/> + </screen> + </example> + <para> + With SUSE Linux 10.1 and all following versions, it's possible to set the <emphasis>size</emphasis> + to <emphasis>max</emphasis> for the logical volumes. Of course, you can only use <emphasis>max</emphasis> + only for one(!) logical volumes. You can't have two logical volumes in one volume group with the + <emphasis>size</emphasis> set to <emphasis>max</emphasis> + </para> + </section> + + <section> + <title> + Enterprise Volume Management System (EVMS) - SLES10 only! + </title> + <para> + SLES10 autoyast has EVMS support. SLES11 has not! + </para> + <para> + Using EVMS is quite similar to using LVM (see above). So switching from LVM to EVMS + is just a small change in the autoyast profile. All you have to do is to change the + "is_lvm_vg" element into "is_evms_vg" and the "lvm_group" element into "evms_group". + </para> + <para> + With autoyast it's not possible to mix LVM and EVMS. + </para> + <para> + Using the LVM example from above for EVMS now looks like this: + </para> + <example> + <title> + EVMS Logical Volumes + </title> + <screen> +http://www.w3.org/2001/XInclude"/> + </screen> + </example> + </section> + <section> + <title>Software RAID</title> + <para> + Using &autoyast;, you can create and assemble software RAID devices. The + supported RAID levels are the following: + </para> + <itemizedlist> + <listitem> + <para> + <emphasis>RAID 0:</emphasis> This level increases your disk performance. + There is <emphasis>NO</emphasis> redundancy in this mode. If one + of the drives crashes, data recovery will not be possible. + + </para> + </listitem> + <listitem> + <para> + <emphasis>RAID 1:</emphasis>This mode has the best redundancy. It can be + used with two or more disks. This mode maintains an exact copy of all data on all + disks. As long as at least one disk is still working, no data is lost. The partitions + used for this type of RAID should have approximately the same size. + </para> + </listitem> + + <listitem> + <para> + <emphasis>RAID 5:</emphasis> This mode combines management of a larger number + of disks and still maintains some redundancy. This mode can be used on three disks or more. + If one disk fails, all data is still intact. If two disks fail simultaneously, + all data is lost. + </para> + </listitem> + <listitem> + <para> + <emphasis>Multipath:</emphasis>This mode allow access to the same physical device + over multiple controller for redundancy against a fault in a controller + card. This mode can be used with at least two devices. + </para> + </listitem> + </itemizedlist> + <para> + As with LVM, you need to create all <emphasis><acronym>RAID</acronym></emphasis> partitions first and assign + the partitions to the <acronym>RAID</acronym> device you want to + create and additionally you need to specify whether a partition or a device should be configured in the + <acronym>RAID</acronym> or if it should configured as a <emphasis>Spare</emphasis> device. + </para> + <para> + The following example shows a simple RAID1 configuration: + </para> + + + <example> + <title>RAID1 configuration</title> + <screen> +http://www.w3.org/2001/XInclude"/> + </screen> + </example> + + + <para> + The following has to be taken into consideration when configuring + raid: + </para> + <itemizedlist> + <listitem> + <para>The device for raid is always <emphasis>/dev/md</emphasis></para> + </listitem> + <listitem> + <para>The property <emphasis>partition_nr</emphasis> is used to + determine the MD device number. if + <emphasis>partition_nr</emphasis> is equal to 0, then + <emphasis>/dev/md0</emphasis> is configured.</para> + </listitem> + <listitem> + <para>All RAID specific options are contained in the + <emphasis>raid_options</emphasis> resource.</para> + </listitem> + </itemizedlist> + + + + </section> + </section> + Added: trunk/autoinstallation/doc/PrinterSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/PrinterSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/PrinterSection.xml (added) +++ trunk/autoinstallation/doc/PrinterSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,39 @@ +<!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.Hardware.Printer"> + <title> + Printer + </title> + + <para> + Although Printer configuration, like other configurations can be + done manually, it is recommended to use the Configuration System to + create such a configuration because of the complexity and the range + of options offered by such modules. + </para> + <para> + Using the configuration system will guarantee that the options + provided are consistent. The following is an example of a + configuration section which was + created using the configuration system. + </para> + &example.printer; + </section> + Added: trunk/autoinstallation/doc/ReportSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/ReportSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/ReportSection.xml (added) +++ trunk/autoinstallation/doc/ReportSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,77 @@ +<!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.Reporting"> + <title id="CreateProfile.Reporting.title"> + Reporting + </title> + + <para> + The <emphasis>report</emphasis> resource manages 3 types of pop-ups + that may appear during installation. + </para> + <itemizedlist> + <listitem> + <para> + Messages Popups (Usually non-critical, informative messages) + </para> + </listitem> + <listitem> + <para> + Warning Popups (If something might go wrong) + </para> + </listitem> + <listitem> + <para> + Error Popups (In the case of an error) + </para> + </listitem> + </itemizedlist> + <example> + <title>Reporting Behavior</title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + + <para> + Depending on your experience, you can skip, log and show (with timeout) + those messages. It is recommended to show all + <emphasis>messages</emphasis> with timeout. Warnings can be skipped in + some places but should not be ignored. + </para> + <para> + By default, the settings in auto-installation mode is to show all messages without logging and + with a timeout of 10 seconds. + </para> + <warning> + <title> + Critical system messages + </title> + <para> + Note that <emphasis>not</emphasis> all messages during installation are controlled by the + <emphasis>report</emphasis> resource. Some critical messages concerning + package installation and partitioning will still show up ignoring your + settings in the <emphasis>report</emphasis> section. Mostly those + messages will have to be answered with <emphasis>Yes</emphasis> or <emphasis>No</emphasis>. + </para> + </warning> + </section> + Added: trunk/autoinstallation/doc/RunlevelSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/RunlevelSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/RunlevelSection.xml (added) +++ trunk/autoinstallation/doc/RunlevelSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,48 @@ +<!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.Services"> + <title> + Services and Run-levels + </title> + <para> + With the run-level resource you can set the default run-level and specify + in detail which system services you want to be started in which + run-level. + </para> + <para> + The default property specifies the <emphasis>default</emphasis> run + level of the system. Changes to the default run-level will take effect + the next time you boot the system. After installation is completed, + the system has run-level 5, which is <emphasis>Full multiuser with + network and XDM</emphasis>. If you have configured a system with no + X11, then it is recommended to reboot the system after the first stage + using the <emphasis>reboot</emphasis> property in the <emphasis>general</emphasis> resource. + + </para> + <para> + A service should run in using a space delimited list of the run-levels + as shown in the following example. An alternative to specifying the + exact run-levels is to change the status of the service by either + enabling or disabling it using the + <emphasis>service_status</emphasis> property. + </para> + &example.runlevels; + + </section> + Added: trunk/autoinstallation/doc/ScriptsSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/ScriptsSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/ScriptsSection.xml (added) +++ trunk/autoinstallation/doc/ScriptsSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,495 @@ +<!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.scripts"> + <title>Custom user scripts</title> + <para> + By adding scripts to the auto-installation process you can customize the + installation for your needs and take control in different stages of the + installation. + </para> + <para> + In the auto-installation process, five types of scripts can be executed and they + will be described here in order of "appearance" during the installation. + </para> + <para> + <note>All scripts have to be in the <scritps> section.</note> + </para> + <para> + <itemizedlist> + <listitem><emphasis>pre-scripts</emphasis> (very early, before anything else really happened)</listitem> + <listitem><emphasis>postpartitioning-scripts</emphasis> (after partitioning and mounting to /mnt but before RPM installation - since openSUSE 11.2)</listitem> + <listitem><emphasis>chroot-scripts</emphasis> (after the package installation, before the first boot)</listitem> + <listitem><emphasis>post-scripts</emphasis> (during the first boot of the installed system, no services running)</listitem> + <listitem><emphasis>init-scripts</emphasis> (during the first boot of the installed system, all servies up and running)</listitem> + </itemizedlist> + </para> + <section id="pre-install.scripts"> + <title>Pre-Install Scripts</title> + <para> + Executed before &yast2; does any real change to the system + (Before partitioning and package installation but after the hardware detection) + </para> + <para> + You can use the pre-script to modify your profile and let autoyast read it again. + If you want to do that, you can find your profile in "/tmp/profile/autoinst.xml". + Do what you want to do with that file and store the modified version in + "/tmp/profile/modified.xml". Autoyast will read that modified script then again after + the pre-script is done. + </para> + <para> + With SUSE Linux 10.0 and all following versions it's possible to change the partitioning with fdisk + in your pre-script. With pre 10.0 versions of SUSE Linux (like SLES9), that was not possible. + </para> + <note><title>Pre-Install Scripts with confirmation</title> + <para> + Pre-scripts are executed at an early stage of the installation. + This means if you have requested to confirm the installation, the + pre-scripts will be executed before the confirmation screen + shows up. (<emphasis>profile/install/general/mode/confirm</emphasis>) + </para> + </note> + <para> + The following elements must be between the <scripts><pre-scripts config:type="list"><script> ... </script></pre-scripts>...</scripts> tags + </para> + <para> + <table frame='top'> + <title>pre script XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>location</entry> + <entry>you can define a location from where the script gets fetched. + Locations can be the same like for the profile (http,ftp,nfs,...). + <para><screen><location>http://10.10.0.1/myPreScript.sh</location>;</screen></para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>source</entry> + <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want + to put the whole shell script into the XML profile, look at the location parameter. + + <para><screen><source> +<![CDATA[ +echo "Testing the pre script" > /tmp/pre-script_out.txt +]]> +</source></screen></para></entry> + <entry>Either <location> or <source> must be defined</entry> + </row> + <row> + <entry>interpreter</entry> + <entry>the interpreter that must be used for the script. Supported options are shell and perl. + <para><screen><interpreter>perl</interpreter></screen></para></entry> + <entry>optional (default is shell)</entry> + </row> + <row> + <entry>filename</entry> + <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... + <para><screen><filename>myPreScript5.sh</filename></screen></para></entry> + <entry>optional. The default is the type of the script (pre-scripts) in this case</entry> + </row> + <row> + <entry>feedback</entry> + <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the + user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + no confirmation is needed. + <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> + <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + </row> + <row> + <entry>feedback_type</entry> + <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <para><screen><feedback_type>warning</feedback_type></screen></para></entry> + <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + </row> + <row> + <entry>debug</entry> + <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + turned on. + <para><screen><debug config:type="boolean">true</debug></screen></para></entry> + <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + + <section id="postpartitioning-install.scripts"> + <title>Postpartitioning Scripts</title> + <note> + <para>Available starting from openSUSE 11.2 only (not SLES11).</para> + </note> + <para> + Executed after &yast2; did the partitioning and wrote the fstab. The empty system is mounted to /mnt already. + This type of script is available since openSUSE 11.2 (not SLES11). + </para> + <para> + The following elements must be between the <scripts><postpartitioning-scripts config:type="list"><script> ... </script></postpartitioning-sripts>...</scripts> tags + </para> + <para> + <table frame='top'> + <title>postpartitioning script XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>location</entry> + <entry>you can define a location from where the script gets fetched. + Locations can be the same like for the profile (http,ftp,nfs,...). + <para><screen><location>http://10.10.0.1/myScript.sh</location>;</screen></para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>source</entry> + <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want + to put the whole shell script into the XML profile, look at the location parameter. + + <para><screen><source> +<![CDATA[ +echo "Testing postpart script" > /mnt/postpart_test.txt +]]> +</source></screen></para></entry> + <entry>Either <location> or <source> must be defined</entry> + </row> + <row> + <entry>interpreter</entry> + <entry>the interpreter that must be used for the script. Supported options are shell and perl. + <para><screen><interpreter>perl</interpreter></screen></para></entry> + <entry>optional (default is shell)</entry> + </row> + <row> + <entry>filename</entry> + <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... + <para><screen><filename>myScript5.sh</filename></screen></para></entry> + <entry>optional. The default is the type of the script (postpartitioning-scripts in this case)</entry> + </row> + <row> + <entry>feedback</entry> + <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the + user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + no confirmation is needed. + <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> + <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + </row> + <row> + <entry>feedback_type</entry> + <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <para><screen><feedback_type>warning</feedback_type></screen></para></entry> + <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + </row> + <row> + <entry>debug</entry> + <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + turned on. + <para><screen><debug config:type="boolean">true</debug></screen></para></entry> + <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + + + + <section id="chroot.scripts"> + <title>Chroot environment scripts</title> + <para>Chroot scripts are executed before the machine reboots for the first time. + Actually chroot scripts are two differnt kind of script with + one name. You can execute chroot script before the installation chroots into + the installed system and configures the boot loader and you can execute a script + after the chroot into the installed system has happend (look at the "chrooted" parameter for that). Both types of scripts are + executed before yast2 boots for the first time. + </para> + <para> + The following elements must be between the <scripts><chroot-scripts config:type="list"><script> ... </script></chroot-scripts>...</scripts> tags + </para> + <para> + <table frame='top'> + <title>chroot script XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>location</entry> + <entry>you can define a location from where the script gets fetched. + Locations can be the same like for the profile (http,ftp,nfs,...). + <para> + <screen><location>http://10.10.0.1/myChrootScript.sh</location>;</screen> + </para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>source</entry> + <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want + to put the whole shell script into the XML profile, look at the location parameter. + <para><screen><source> +<![CDATA[ +echo "Testing the chroot script" > /tmp/chroot_out.txt +]]> +</source></screen></para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>chrooted</entry> + <entry>this value can be true or false. "False" means that the installed system is still mounted at "/mnt" and no chrooting has happened till now. The bootloader is not installed too at that stage. "True" means, we did a chroot into /mnt, so we are now in the installed system. The bootloader is installed and if you want to change anything in the installed system, you don't have to use the "/mnt/" prefix anymore. + <para><screen><chrooted config:type="boolean">true</chrooted></screen></para></entry> + <entry>optional (the default is false)</entry> + </row> + <row> + <entry>interpreter</entry> + <entry>the interpreter that must be used for the script. Supported options are shell and perl.and if you are in a chrooted=true condition, you can use python too if it's installed. + <para><screen><interpreter>perl</interpreter></screen></para></entry> + <entry>optional (default is shell)</entry> + </row> + <row> + <entry>filename</entry> + <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... + <para><screen><filename>myPreScript5.sh</filename></screen></para></entry> + <entry>optional. The default is the type of the script (chroot-scripts) in this case</entry> + </row> + <row> + <entry>feedback</entry> + <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the + user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + no confirmation is needed. + <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> + <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + </row> + <row> + <entry>feedback_type</entry> + <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <para><screen><feedback_type>warning</feedback_type></screen></para></entry> + <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + </row> + <row> + <entry>debug</entry> + <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + turned on. + <para><screen><debug config:type="boolean">true</debug></screen></para></entry> + <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + <section id="post-insall.scripts"> + <title>Post-Install Scripts</title> + <para> + These scripts are executed after AutoYaST has completed the + system configuration and after it has booted the system for the first time. + </para> + <para> + It is possible to execute the post scripts in an earlier phase while + the installation network is still up and before AutoYaST configures + the system. To run network enabled post scripts, the boolean + property <emphasis>network_needed</emphasis> has to be set to true. + </para> + <para> + The following elements must be between the <scripts><post-scripts config:type="list"><script> ... </script></post-scripts>...</scripts> tags + </para> + <para> + <table frame='top'> + <title>post script XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>location</entry> + <entry>you can define a location from where the script gets fetched. + Locations can be the same like for the profile (http,ftp,nfs,...) but then you need a running network interface of course + <para> + <screen><location>http://10.10.0.1/myPostScript.sh</location>;</screen> + </para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>source</entry> + <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want + to put the whole shell script into the XML profile, look at the location parameter. + <para><screen><source> +<![CDATA[ +echo "Testing the chroot script" > /tmp/chroot_out.txt +]]> +</source></screen></para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>network_needed</entry> + <!-- FIXME: double check that. I'm very unsure if this is correct --> + <entry>this value can be true or false. On "false" the script will run after the yast modules like the user configuration and everything else are done. The network is configured but still not up and running. With this value on "true", the script runs before(!) all yast modules are configured. So there is no local user and no network is configured but the installation network is still up and running (of course only if you did a network installation). + <para><screen><network_needed config:type="boolean">true</network_needed></screen></para></entry> + <entry>optional (the default is false)</entry> + </row> + <row> + <entry>interpreter</entry> + <entry>the interpreter that must be used for the script. Supported options are shell, perl and python if it's installed. + <para><screen><interpreter>perl</interpreter></screen></para></entry> + <entry>optional (default is shell)</entry> + </row> + <row> + <entry>filename</entry> + <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... + <para><screen><filename>myPostScript5.sh</filename></screen></para></entry> + <entry>optional. The default is the type of the script (post-scripts) in this case</entry> + </row> + <row> + <entry>feedback</entry> + <entry>if this boolean is true, stdout and stderr of the script will be shown in a popup that the + user has to confirm via ok-button. If stdout and stderr are empty, no popup is shown and so + no confirmation is needed. + <para><screen><feedback config:type="boolean">true</feedback></screen></para></entry> + <entry>optional. The default is false. This option was invented with SL 10.1 / SLES10</entry> + </row> + <row> + <entry>feedback_type</entry> + <entry>this can be "message", "warning", "error" and you can control the timeout of those popups with the <report> section. + <para><screen><feedback_type>warning</feedback_type></screen></para></entry> + <entry>optional. If missing, an always blocking popup is used. This option was invited with openSUSE 11.2 (not SLES11)</entry> + </row> + <row> + <entry>debug</entry> + <entry>if this is true, every single line of a shell script is logged. Perl scripts are run with warnings + turned on. + <para><screen><debug config:type="boolean">true</debug></screen></para></entry> + <entry>optional. The default is true. This option was invented with SL 10.1 / SLES10</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + <section id="init.scripts"> + <title>Init Scripts</title> + <para> + These scripts are executed during the initial boot process and after + &yast2; has finished. The final scripts are executed using a special + <emphasis>init.d</emphasis> script which is executed only + once. The final scripts are executed toward the end of the boot + process and after network has been intialized. + </para> + <para> + Init scripts are configured using the tag <emphasis>init-scripts</emphasis> and + are run using the special purpose <emphasis>init.d</emphasis> script <filename>/etc/init.d/autoyast</filename>. + </para> + <para> + The following elements must be between the <scripts><init-scripts config:type="list"><script> ... </script></init-scripts>...</scripts> tags + </para> + <para> + <table frame='top'> + <title>init script XML representation</title> + <tgroup cols="3"> + <thead> + <row> + <entry>Element</entry> + <entry>Description</entry> + <entry>Comment</entry> + </row> + </thead> + <tbody> + <row> + <entry>location</entry> + <entry>you can define a location from where the script gets fetched. + Locations can be the same like for the profile (http,ftp,nfs,...) but then you need a running network interface of course + <para> + <screen><location>http://10.10.0.1/myInitScript.sh</location>;</screen> + </para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>source</entry> + <entry>the script itself. The source code of the script if you want so. Encapsulated in a CDATA tag. If you don't want + to put the whole shell script into the XML profile, look at the location parameter. + <para><screen><source> +<![CDATA[ +echo "Testing the init script" > /tmp/init_out.txt +]]> +</source></screen></para></entry> + <entry>either <location> or <source> must be defined</entry> + </row> + <row> + <entry>filename</entry> + <entry>the filename of the script. It will be stored in a temporary directory under /tmp/... + <para><screen><filename>mynitScript5.sh</filename></screen></para></entry> + <entry>optional. The default is the type of the script (init-scripts) in this case</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + <para> + When added to the control file manually, the + scripts have to be included in a <emphasis>CDATA</emphasis> element to avoid confusion with + the file syntax and other tags defined in the control file. + </para> + <section id="script_examples"> + <title>Script example</title> + <example> + <title>Post script configuration</title> + <screen> + http://www.w3.org/2001/XInclude"/> + + </screen> + </example> + <para> + After installation is finished, the scripts and the output logs can be + found in the directory <filename>/var/adm/autoinstall</filename>. The + scripts are located in <filename>scripts</filename> and the output logs of the + scripts are located in the <filename>log</filename> directory. + </para> + <para> + The log is the output resulting when executing the shell scripts using + the following command: + </para> + <screen> + <![CDATA[ + /bin/sh -x <script_name> 2&> /var/adm/autoinstall/logs/<script_name>.log + ]]> + </screen> + </section> + </section> + Added: trunk/autoinstallation/doc/SecuritySection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/SecuritySection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/SecuritySection.xml (added) +++ trunk/autoinstallation/doc/SecuritySection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,90 @@ +<!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.Security"> + <title> + Security settings + </title> + + <para> + Using the features of this module, you will be able to change the local + security settings on the target system. The local security settings + include the boot configuration, login settings, password settings, + user addition settings, and file permissions. + </para> + <para> + Configuring the security settings automatically corresponds to the + <emphasis>Custom Settings</emphasis> in the security module available in + the running system which lets you create your own, customized + configuration. + </para> + + &example.security; + <section> + <title>Password Settings Options</title> + <para> + Change various password settings. These settings are mainly stored in the <filename>/etc/login.defs</filename> file. + </para> + <para> + Use this resource to activate one of the <emphasis>encryption</emphasis> methods currently supported. + If not set, <emphasis>DES</emphasis> is configured. + </para> + <para> + <emphasis>DES</emphasis>, the Linux default method, works in all + network environments, but it restricts you to passwords no longer than + eight characters. <emphasis>MD5</emphasis> allows longer passwords, + thus provides more security, but some network protocols don't support + this, and you may have problems with NIS. <emphasis>Blowfish</emphasis> + is also supported. + </para> + <para>Additionally, you can setup the system to check for password + plausibility and length etc.</para> + </section> + <section> + <title>Boot Settings</title> + <para> + Use the security resource, you can change various boot settings. + </para> + <itemizedlist> + <listitem> + <para><emphasis>How to interpret Ctrl + Alt + Del</emphasis></para> + <para>When someone at the console has pressed the CTRL + ALT + DEL key combination, the system usually reboots. Sometimes it is desirable to ignore this event, for example, when the system serves as both workstation and server.</para> + </listitem> + <listitem> + <para><emphasis>Shutdown behavior of KDM</emphasis></para> + <para>Set who is allowed to shut down the machine from KDM.</para> + </listitem> + </itemizedlist> + + + </section> + <section> + <title>Login Settings</title> + <para>Change various login settings. These settings are mainly stored in the '/etc/login.defs' file.</para> + </section> + <section> + <title>New user settings (useradd settings)</title> + <para>Set the minimum and maximum possible user ID and set the minimum + and maximum possible group ID. + </para> + </section> + + </section> + Added: trunk/autoinstallation/doc/SoftwareSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/SoftwareSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/SoftwareSection.xml (added) +++ trunk/autoinstallation/doc/SoftwareSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,413 @@ +<!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.Software"> + <title> + Software + </title> + + <section id="Software.Selections.sles10"> + <title> + Package Selections with patterns + </title> + <para> + SLES10 no longer supports <emphasis>selections</emphasis> but uses + <emphasis>patterns</emphasis> now. Autoyast is not be able to convert + selections into patterns and so you have to do that on your own. + If you want to use a SLES9 autoyast profile to install a SLES10 + server, you have to remove all <emphasis>addon</emphasis> entries and the + <emphasis>base</emphasis> entry. Patterns are configured like this: + </para> + <example> + <title> + Package selection in control file with patterns + </title> + <screen> +http://www.w3.org/2001/XInclude"/> + </screen> + </example> + <para> + As you can see, the <emphasis>packages</emphasis> section is still the same like on + a SLES9. Just the <emphasis>addon</emphasis> and <emphasis>base</emphasis> is gone. + </para> + </section> + <section> + <title> + Deploying Images + </title> + <para> + This feature is available since openSUSE 11.1 but not in SLES11. + </para> + <para> + Since openSUSE 11.0 you can choose to use images during installation to speed up the installation. + This is available in openSUSE 11.1 too. At then end, in the installed system, there is + no difference visible if you did an image or a single RPM installation. + </para> + <example> + <title> + Activating images deployment + </title> + <screen> +http://www.w3.org/2001/XInclude"/> + </screen> + </example> + </section> + + <section> + <title> + Installing additional and customized Packages + </title> + <para> + In addition to the packages available for installation on the CD-ROMs, + you can add external packages including customized kernels. Customized + kernel packages must be compatible to the &company-suse; packages and must + install the kernel files to the same locations. + </para> + <para> + Unlike earlier versions, to install custom and external packages + there is no need for a special resource in the control + file. Instead you need to re-create the package database and update + it with any new packages or new package versions in the source repository. + </para> + <para> + A script is provided for this task which will query packages + available in the repository and create the required package + database. + </para> + + <para> + Creating a new package database is only needed if new RPMs + (i.e. update RPMs) were added. To re-create the database, use the + <command>/usr/bin/create_package_descr</command> + command. For example, use this command line to create the package + database. (When creating the database, all languages will be reset to English). + </para> + <example> + <title>Creating package database</title> + <screen> + cd /usr/local/CDs/LATEST/suse + create_package_descr -x PATH_TO_EXTRA_PROV -d /usr/local/CDs/LATEST/suse + </screen> + </example> + <note> + <title>Change starting from SUSE Linux 9.1/SLES 9</title> + <para>To provide extra dependencies which can not be extracted from the + rpm files, an extra file with missing dependencies is available in the + directory <filename>suse/setup/descr</filename>. The file + <filename>EXTRA_PROV</filename> can be used when recreating the package + database using the <emphasis>-x</emphasis> option.</para> + </note> + <para> + In the above example, the directory + <filename>/usr/local/CDs/LATEST/suse</filename> contains the architecture + dependent and independent packages, i.e. <emphasis>noarch</emphasis> and <emphasis>i586</emphasis>. + This might look different on other architectures. + </para> + <para> + The advantage of this method is that you can keep an up-to-date + repository with fixed and updated package (i.e. from &company-suse; FTP + server). Additionally this method makes the creation of custom CD-ROMs easier. + </para> + <note> + <title>Change starting from SUSE Linux 10.1/SLES 10</title> + <para> + With SLES10/SL10.1, the concept of adding own RPMs to an installation source has changed. + The <emphasis>yast/order</emphasis> and <emphasis>yast/instorder</emphasis> is no longer supported. Neither + by AutoYaST nor by YaST. To add own RPMs to an installation source (that includes add-on products like the + SDK) you have to add a file <emphasis>add_on_products</emphasis> to the CD1 of the main product. + <screen> +media_url [path_on_media [product_1 [product_2 [....]]] + </screen> + media_url is URL of the media itself + path_on_media is path of the catalog on the media. If not present, / (root) is assumed + product_1 and following are the names for products, which should be marked for installation. If no product is mentioned, all products found on the media are selected for installation. + For example: + <screen> +http://192.168.66.6/SLES10/sdk/CD1 +http://192.168.66.6/SLES10/CD1/updates + </screen> + Besides that <emphasis>add_on_products</emphasis> file, you can use the autoyast profile to specify add-on products. For example: + <screen> +<add-on> + <add_on_products config:type="list"> + <listentry> + <media_url>http://192.168.66.6/SLES10/CD1/updates</media_url>; + <product>SuSE-Linux-Updates</product> + <product_dir>/</product_dir> + <ask_on_error config:type="boolean">false</ask_on_error> <!-- available since openSUSE 11.0 --> + <name>MyUpdates</name> <!-- available since openSUSE 11.1/SLES11 (bnc#433981) --> + </listentry> + </add_on_products> +</add-on> + </screen> + With that entry in the autoyast profile, the <emphasis>add_on_products</emphasis> file is not necessary. + Since openSUSE 11.0 AutoYaST can ask the user to make the add-on available intead of reporting a timed out error when the add-on can't be found at the given location. Set ask_on_error to true for that (the default is false). + Your add-on can be on a different CD/DVD than the installation source then. + </para> + <para> + YaST checks the signatures of files on the installation source now. If a <emphasis>content</emphasis> file is + not signed, during a manual installation YaST asks the user what to do. During an autoinstallation, the + installation source gets rejected silently. + </para> + </note> + <para> + If you want to use unsigned installation sources with autoyast, you can turn of the checks with the following + configuration in your autoyast profile (part of the <emphasis>general</emphasis> section. + </para> + <para> + The following elements must be between the <general><signature-handling> ... </signature-handling></general> tags. + </para> + <para> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>accept_unsigned_file</entry> + <entry>the installer will accept unsigned files like the content file + <para><screen><accept_unsigned_file config:type="boolean">true</accept_unsigned_file></screen></para> + </entry> + <entry>optional. If left out, autoyast lets yast decide what to do</entry> + </row> + <row> + <entry>accept_file_without_checksum</entry> + <entry>the installer will accept files without a checksum in the content file + <para><screen><accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum></screen></para> + </entry> + <entry>optional. If left out, autoyast lets yast decide what to do</entry> + </row> + <row> + <entry>accept_verification_failed</entry> + <entry>the installer will accept files where the verification of the signature failed. So the file was signed but the check failed. + <para><screen><accept_verification_failed config:type="boolean">true</accept_verification_failed></screen></para> + </entry> + <entry>optional. If left out, autoyast lets yast decide what to do</entry> + </row> + <row> + <entry>accept_unknown_gpg_key</entry> + <entry>the installer will accept new gpg keys on the installation source that are used to sign the content file for example + <para><screen><accept_unknown_gpg_key config:type="boolean">true</accept_unknown_gpg_key></screen></para> + </entry> + <entry>optional. If left out, autoyast lets yast decide what to do</entry> + </row> + <row> + <entry>accept_non_trusted_gpg_key</entry> + <entry>This basically means, we know the key, but it is not trusted + <para><screen><accept_non_trusted_gpg_key config:type="boolean">true</accept_non_trusted_gpg_key></screen></para> + </entry> + <entry>optional. If left out, autoyast lets yast decide what to do</entry> + </row> + <row> + <entry>import_gpg_key</entry> + <entry>the installer will accept and import new gpg keys on the installation source in it's database. + <para><screen><import_gpg_key config:type="boolean">true</import_gpg_key></screen></para> + </entry> + <entry>optional. If left out, autoyast lets yast decide what to do</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + <para> + Since openSUSE 10.3 it's possible to configure the signature handling for each add-on individually. The following elements must be between the + <signature-handling> section of the individual add-on. + </para> + <para> + <table frame='top'> + <tgroup cols="3"> + <thead> + <row> + <entry>Attribute</entry> + <entry>Values</entry> + <entry>Description</entry> + </row> + </thead> + <tbody> + <row> + <entry>accept_unsigned_file</entry> + <entry>the installer will accept unsigned files like the content file for this add-on product + <para><screen><accept_unsigned_file config:type="boolean">true</accept_unsigned_file></screen></para> + </entry> + <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> + </row> + <row> + <entry>accept_file_without_checksum</entry> + <entry>the installer will accept files without a checksum in the content file for this add-on + <para><screen><accept_file_without_checksum config:type="boolean">true</accept_file_without_checksum></screen></para> + </entry> + <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> + </row> + <row> + <entry>accept_verification_failed</entry> + <entry>the installer will accept files where the verification of the signature failed. So the file was signed but the check failed. + <para><screen><accept_verification_failed config:type="boolean">true</accept_verification_failed></screen></para> + </entry> + <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> + </row> + <row> + <entry>accept_unknown_gpg_key</entry> + <entry>the installer will accept new gpg keys on the installation source that are used to sign the content file for example + <para><screen> + <accept_unknown_gpg_key> + <all config:type="boolean">false</all> + <keys config:type="list"> + <keyid>3B3011B76B9D6523</keyid> + </keys> + </accept_unknown_gpg_key> + </screen></para> + </entry> + <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> + </row> + <row> + <entry>accept_non_trusted_gpg_key</entry> + <entry>This basically means, we know the key, but it is not trusted + <para><screen> + <accept_non_trusted_gpg_key> + <all config:type="boolean">false</all> + <keys config:type="list"> + <keyid>3B3011B76B9D6523</keyid> + </keys> + </accept_non_trusted_gpg_key> +</screen></para> + </entry> + <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> + </row> + <row> + <entry>import_gpg_key</entry> + <entry>the installer will accept and import new gpg keys on the installation source in it's database. + <para><screen> + <import_gpg_key> + <all config:type="boolean">false</all> + <keys config:type="list"> + <keyid>3B3011B76B9D6523</keyid> + </keys> + </import_gpg_key> + </screen></para> + </entry> + <entry>optional. If left out, the global signature-handing in the <general> section is used.</entry> + </row> + </tbody> + </tgroup> + </table> + </para> + </section> + <section> + <title>Kernel packages</title> + <para> + Kernel packages are not part of any selection. The required kernel + is determined during installation. If the kernel package is added to any selection + or to the individual package selection, installation will mostly fail due to conflicts. + </para> + <para> + To force the installation of a specific kernel, use the + <emphasis>kernel</emphasis> property. The following is an example + forcing the installation of the default kernel. In this example this + kernel will be installed in any case, even if an SMP or other kernel + is required</para> + <example> + <title> + Package selection in control file + </title> + <screen> +http://www.w3.org/2001/XInclude"/> + + </screen> + </example> + </section> + <section> + <title>Removing automatically selected packages</title> + <para> + Some packages are selected automatically either because of a + dependency or because it available in a selection. + </para> + <para> + Removing such packages might break the system consistency and it is + not recommended to remove basic packages unless a replacement which + provides same services is provided. Best example for this case are + <acronym>MTA</acronym> packages. By default, <emphasis>postfix</emphasis> + will be selected and installed. If you wish however to use another + <acronym>MTA</acronym> like <emphasis>sendmail</emphasis>, then + postfix can be removed from the list of selected package using a list + in the software resource. The following example shows how this can be done: + + </para> + <example> + <title> + Package selection in control file + </title> + <screen> +http://www.w3.org/2001/XInclude"/> + + + </screen> + </example> + </section> + <section> + <title>Installing packages during stage 2</title> + <para> + if you want to install packages after the reboot during stage 2, instead of + during the normal installation process in stage 1, you can use the + <emphasis>post-packages</emphasis> element for that: + </para> + <screen> +<software> + <post-packages config:type="list"> + <package>yast2-cim</package> + </post-packages> +</software> + </screen> + </section> + <section> + <para> + Since SLES11 and openSUSE 11.1 you can install patterns in stage 2 too. + use the <emphasis>post-patterns</emphasis> element for that: + </para> + <screen> +<software> + <post-patterns config:type="list"> + <pattern>apparmor</pattern> + </post-patterns> +</software> + </screen> + </section> + <section> + <title>Online update in stage2</title> + <para> + since openSUSE 11.1 you can do an online update at the end of the installation with the boolean + <emphasis>do_online_update</emphasis>. + Of course that makes only sense if you add an online update repository with the suse-register/customer-center section for example or in a post-script. If the online update repository was available in stage1 already via add-on section, then autoyast has already installed the latest packages available. If a kernel update is done via online-update, a reboot at the end of stage2 is triggered. + </para> + <screen> +<software> + <do_online_update config:type="boolean">true</do_online_update> +</software> + </screen> + </section> + </section> + Added: trunk/autoinstallation/doc/SoundSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/SoundSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/SoundSection.xml (added) +++ trunk/autoinstallation/doc/SoundSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,30 @@ +<!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.Hardware.Sound"> + <title> + Sound devices + </title> + <para> + An example of sound configuration created using the configuration + system is shown below. + </para> + &example.sound; + </section> + Added: trunk/autoinstallation/doc/SysconfigSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/SysconfigSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/SysconfigSection.xml (added) +++ trunk/autoinstallation/doc/SysconfigSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,41 @@ +<!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.sysconfig"> + <title>System variables (Sysconfig)</title> + <para> + Using the sysconfig resource, it is possible to define configuration + variables in the sysconfig repository + (<filename>/etc/sysconfig</filename>) directly. Sysconfig + variables, offer the possibility to fine-tune many system components and + environment variables exactly to your needs. + </para> + + <para> + Refer to the handbook for more details about the many + configuration options available in <filename>/etc/sysconfig</filename> + </para> + <para> + The following example shows how a variable can be set using the sysconfig + resource. + </para> + &example.sysconfig; + </section> + Added: trunk/autoinstallation/doc/UsersSection.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/UsersSection.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/UsersSection.xml (added) +++ trunk/autoinstallation/doc/UsersSection.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,55 @@ +<!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.Security.users"> + <title> + Users + </title> + <para> + The root user and at least one normal user can be added during install + using data supplied in the control file. User data and passwords + (encrypted or in clear text) are part of the <emphasis>configure</emphasis> resource in the + control file. + </para> + <para> + At least the root user should be configured during + auto-installation, which will insure you will be able to login after + installation is finished and of course it will insure nobody else can login + into the system (in case the password is not set). + </para> + <para>The two users in the following example are added during system + configuration.</para> + + <example> + <title> + User configuration + </title> + <screen> + http://www.w3.org/2001/XInclude"/> + </screen> + </example> + <para> + The last example shows the minimal information required for adding + users. More options are available for a more customized user account + management. The data in <filename>/etc/default/useradd</filename> is + used to determine the home directory of the user to be created in + addition to other parameters. + </para> + </section> + Added: trunk/autoinstallation/doc/X11Section.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/X11Section.xml?rev=61166&view=auto ============================================================================== --- trunk/autoinstallation/doc/X11Section.xml (added) +++ trunk/autoinstallation/doc/X11Section.xml Fri Mar 5 11:16:35 2010 @@ -0,0 +1,39 @@ +<!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.X11"> + <title> + Monitor and X11 Configuration + </title> + <para> + FIXME + </para> + + <example> + <title> + X11 and Monitor configuration + </title> + <screen> +http://www.w3.org/2001/XInclude"/> + </screen> + </example> + + + </section> + Modified: trunk/autoinstallation/doc/autoyast.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/autoyast.xml?rev=61166&r1=61165&r2=61166&view=diff ============================================================================== --- trunk/autoinstallation/doc/autoyast.xml (original) +++ trunk/autoinstallation/doc/autoyast.xml Fri Mar 5 11:16:35 2010 @@ -1,12 +1,13 @@ <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" -"/usr/share/xml/docbook/schema/dtd/4.2/docbookx.dtd"[ +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[ <!ENTITY Profile SYSTEM "Profile.xml"> <!ENTITY Introduction SYSTEM "Introduction.xml"> <!ENTITY CreateProfile SYSTEM "CreateProfile.xml"> +<!ENTITY PartitioningSection SYSTEM "PartitioningSection.xml"> <!ENTITY NetworkInstallation SYSTEM "NetworkInstallation.xml"> <!ENTITY date SYSTEM "systemdate"> Modified: trunk/autoinstallation/doc/creating_autoyast2_modules.xml URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/doc/creating_autoyast2_modules.xml?rev=61166&r1=61165&r2=61166&view=diff ============================================================================== --- trunk/autoinstallation/doc/creating_autoyast2_modules.xml (original) +++ trunk/autoinstallation/doc/creating_autoyast2_modules.xml Fri Mar 5 11:16:35 2010 @@ -1,6 +1,6 @@ <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN" -"/usr/share/xml/db41xml/docbookx.dtd"[]> +"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd"[]> <article> <articleinfo> Modified: trunk/autoinstallation/package/autoyast2.changes URL: http://svn.opensuse.org/viewcvs/yast/trunk/autoinstallation/package/autoyast2.changes?rev=61166&r1=61165&r2=61166&view=diff ============================================================================== --- trunk/autoinstallation/package/autoyast2.changes (original) +++ trunk/autoinstallation/package/autoyast2.changes Fri Mar 5 11:16:35 2010 @@ -1,4 +1,9 @@ ------------------------------------------------------------------- +Fri Mar 5 11:04:13 CET 2010 - ug@suse.de + +- new structure for documentation + +------------------------------------------------------------------- Tue Mar 2 09:55:14 CET 2010 - ug@suse.de - don't install post-packages with ayast_setup twice (bnc#584564) -- To unsubscribe, e-mail: yast-commit+unsubscribe@opensuse.org For additional commands, e-mail: yast-commit+help@opensuse.org