mirror of
https://github.com/fspc/gbootroot.git
synced 2025-02-23 09:03:23 -05:00
This adds yard template help.
This commit is contained in:
freesource
parent
e00a11f5ab
commit
b13f144c4b
@ -3,7 +3,7 @@
|
|||||||
<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E"
|
<body text="#000000" bgcolor="#FFFFFF" link="#0000EF" vlink="#51188E"
|
||||||
alink="#FF0000">
|
alink="#FF0000">
|
||||||
|
|
||||||
<center>$Id: index.html,v 1.110 2003/01/11 03:56:01 freesource Exp $</center>
|
<center>$Id: index.html,v 1.111 2003/01/14 03:45:00 freesource Exp $</center>
|
||||||
|
|
||||||
<p>
|
<p>
|
||||||
|
|
||||||
@ -44,7 +44,7 @@ Download gBootRoot</h3>
|
|||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
|
|
||||||
<li><em>1.4.0</em> available in tar.gz, deb, and rpm formats.
|
<li><em>1.4.2</em> available in tar.gz, deb, and rpm formats.
|
||||||
|
|
||||||
|
|
||||||
<li>Main repository:
|
<li>Main repository:
|
||||||
@ -135,7 +135,13 @@ make-debian-x11 debian package</a>
|
|||||||
<a href="images/screenshot2.jpg">1.3.6</a><br>
|
<a href="images/screenshot2.jpg">1.3.6</a><br>
|
||||||
<a href="images/screenshot.jpg">1.2.13</a>
|
<a href="images/screenshot.jpg">1.2.13</a>
|
||||||
|
|
||||||
<p><a href="#FAQ">FAQ</a></P>
|
<p>
|
||||||
|
|
||||||
|
<a href="#FAQ">FAQ</a>
|
||||||
|
|
||||||
|
<br><a href="#cli-help">CLI Help</a>
|
||||||
|
|
||||||
|
<br><a href="#template-help">Yard Template Help</a>
|
||||||
|
|
||||||
<p><a href="#links">links</a></P>
|
<p><a href="#links">links</a></P>
|
||||||
|
|
||||||
@ -154,8 +160,8 @@ directory you can reference it with "gbootroot --template
|
|||||||
template_name" and this will create the corresponding root_fs in
|
template_name" and this will create the corresponding root_fs in
|
||||||
/tmp/gboot_non_root_`id -u`/. If you want the root_fs to have a
|
/tmp/gboot_non_root_`id -u`/. If you want the root_fs to have a
|
||||||
different name use the --root-filename option. All these options and
|
different name use the --root-filename option. All these options and
|
||||||
more can be found with -h or --help or see the <a
|
more can be found with -h or --help or see the
|
||||||
href="#cli-help">reference</a>.
|
<a href="#cli-help">reference</a>.
|
||||||
|
|
||||||
<P align="center">
|
<P align="center">
|
||||||
<b>How to Use gBootRoot's GUI</b></P>
|
<b>How to Use gBootRoot's GUI</b></P>
|
||||||
@ -1611,7 +1617,7 @@ compression is done either in the ABS (not yet) or the ARS, the main
|
|||||||
section is just used to put together the parts.
|
section is just used to put together the parts.
|
||||||
|
|
||||||
|
|
||||||
<a name="cli-help"><h2><a name="links">CLI Help</h2></a>
|
<a name="cli-help"><h2>CLI Help</h2></a>
|
||||||
|
|
||||||
<pre>
|
<pre>
|
||||||
Usage: gbootroot [OPTION]...
|
Usage: gbootroot [OPTION]...
|
||||||
@ -1642,6 +1648,152 @@ Usage: gbootroot [OPTION]...
|
|||||||
--no-stdout don't print to console
|
--no-stdout don't print to console
|
||||||
</pre>
|
</pre>
|
||||||
|
|
||||||
|
|
||||||
|
<a name="template-help"><h2>Yard Template Help</h2></a>
|
||||||
|
|
||||||
|
<h3> Format rules </h3>
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
|
||||||
|
<li> Lines beginning with # or % are comments.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> Blank lines and whitespace are ignored.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> Lines of the form "filename1 -> filename2" will create symbolic (soft)
|
||||||
|
links on the root fs. For example, if you want sh linked to ash
|
||||||
|
in the root fs you could specify: "/bin/sh -> /bin/ash".
|
||||||
|
The literal output from the last column found when using `ls -s`
|
||||||
|
may be used, or fictional links may be created, for instance,
|
||||||
|
ashsa -> bash (In this case if /bin/bash exists on the system the link
|
||||||
|
would be /bin/ashsa -> /bin/bash, otherwise /asha -> /bash)
|
||||||
|
(There is no way to specify hardlinks, though hard linked files
|
||||||
|
that exist on the hard disk will be hard linked.)
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> Lines of the form "filename1 <= Replacements/pathto_filename2"
|
||||||
|
will cause filename2 to be copied to filename1 on the root fs.
|
||||||
|
This is useful for specifying trimmed-down replacements for
|
||||||
|
/etc/passwd, /etc/inittab, etc. For the above example, filename2
|
||||||
|
is found in its real path below the Replacements directory which is
|
||||||
|
found in the default Replacements path of $HOME/yard/Replacements.
|
||||||
|
Replacements may be specified in their absolute or relative paths
|
||||||
|
(found using $PATH).
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> User defined paths may be specified in the Path Box
|
||||||
|
(Edit->Settings->Path). These paths may be used to search for the
|
||||||
|
relative paths for Replacements, links and files.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> Glob designations (?, * and []) are generally allowed, eg /dev/hd[ab]*
|
||||||
|
Wildcards are not allowed in link specs or replacement specs.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> The $RELEASE variable which may be used to locate the modules directory
|
||||||
|
can come from one of three sources, the kernel version returned from a
|
||||||
|
selected kernel in the main section,
|
||||||
|
a user defined kernel version in the ABS, or the value of `uname -r`
|
||||||
|
returned automatically when the other two sources aren't specified.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> You don't need to explicitly specify intermediate directories unless you
|
||||||
|
just want to make sure they exist.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> You don't need to specify shared libraries or loaders because
|
||||||
|
necessary libraries are detected automatically.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<ul> <h3> Control Structures </h3>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> The if/elsif operator may be used to test for the existence of an
|
||||||
|
absolute or relative file condition. If the condition is true
|
||||||
|
than the following statements will be parsed, otherwise additional
|
||||||
|
conditions are examined. The statements can be specified by any
|
||||||
|
of the formats rules, but can't be on the same line as the
|
||||||
|
condition. The \ deliminator is used at the beginning and ending
|
||||||
|
of the control structure so that the parser knows how to properly
|
||||||
|
treat the logic.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> This is especially useful for creating templates that work
|
||||||
|
properly for different distributions allowing portability.
|
||||||
|
Consider these examples:
|
||||||
|
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<pre>
|
||||||
|
Example 1
|
||||||
|
---------
|
||||||
|
|
||||||
|
\
|
||||||
|
if ( getty )
|
||||||
|
/etc/inittab <= Replacements/etc/inittab.example-deb
|
||||||
|
/sbin/getty
|
||||||
|
elsif ( mingetty )
|
||||||
|
/etc/inittab <= Replacements/etc/inittab.example.mingetty-rpm
|
||||||
|
/sbin/mingetty
|
||||||
|
/etc/gettydefs
|
||||||
|
elsif ( agetty )
|
||||||
|
/etc/inittab <= Replacements/etc/inittab.example.agetty-slack
|
||||||
|
/sbin/agetty
|
||||||
|
/etc/gettydefs
|
||||||
|
\
|
||||||
|
|
||||||
|
Example 2
|
||||||
|
---------
|
||||||
|
|
||||||
|
\ if ( /etc/pam.d/system-auth )
|
||||||
|
/etc/pam.d/system-auth \
|
||||||
|
|
||||||
|
</pre>
|
||||||
|
|
||||||
|
|
||||||
|
<ul> <h3>NSS and PAM</h3>
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> You may choose between two behaviors for the treatment of NSS and PAM
|
||||||
|
libraries. The old Yard behavior assumes that only the user knows which
|
||||||
|
service modules they want to include in the file set, and tests
|
||||||
|
(see Tests menu) may be run on the configuration files to show what isn't
|
||||||
|
provided, so that the user can include the missing modules manually by
|
||||||
|
editing the template, but the user still needs to figure out any
|
||||||
|
dependencies since the modules are dynamically loaded.
|
||||||
|
|
||||||
|
<p>
|
||||||
|
|
||||||
|
<li> The new Yard behavior (default) assumes that the user does know what they
|
||||||
|
want based on what the user puts in the NSS (nsswitch.conf) and PAM
|
||||||
|
(pam.conf or pam.d/*) configuration files. The configuration files are
|
||||||
|
then parsed and the corresponding service modules are included in the
|
||||||
|
file set if they exist on the host system, tests (see Tests menu) can be
|
||||||
|
run to find out which ones don't exist. The service modules are checked
|
||||||
|
for library dependencies. What this means is that the user only needs
|
||||||
|
to specify the configuration files in the template, and doesn't need to
|
||||||
|
be concerned with the service modules or libraries involved. The new
|
||||||
|
behavior is recommended, and won't effect the file set even if the
|
||||||
|
requirements are already included in the template. If desired, the old
|
||||||
|
behavior may be regained by switching off Edit->Settings->"NSS Conf"
|
||||||
|
and Edit->Settings->"PAM Conf".
|
||||||
|
|
||||||
|
</ul>
|
||||||
|
</ul>
|
||||||
|
|
||||||
<h2><a name="links">Links</h2>
|
<h2><a name="links">Links</h2>
|
||||||
|
|
||||||
<ul>
|
<ul>
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user