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"
|
||||
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>
|
||||
|
||||
@ -44,7 +44,7 @@ Download gBootRoot</h3>
|
||||
|
||||
<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:
|
||||
@ -135,7 +135,13 @@ make-debian-x11 debian package</a>
|
||||
<a href="images/screenshot2.jpg">1.3.6</a><br>
|
||||
<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>
|
||||
|
||||
@ -154,8 +160,8 @@ directory you can reference it with "gbootroot --template
|
||||
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
|
||||
different name use the --root-filename option. All these options and
|
||||
more can be found with -h or --help or see the <a
|
||||
href="#cli-help">reference</a>.
|
||||
more can be found with -h or --help or see the
|
||||
<a href="#cli-help">reference</a>.
|
||||
|
||||
<P align="center">
|
||||
<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.
|
||||
|
||||
|
||||
<a name="cli-help"><h2><a name="links">CLI Help</h2></a>
|
||||
<a name="cli-help"><h2>CLI Help</h2></a>
|
||||
|
||||
<pre>
|
||||
Usage: gbootroot [OPTION]...
|
||||
@ -1642,6 +1648,152 @@ Usage: gbootroot [OPTION]...
|
||||
--no-stdout don't print to console
|
||||
</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>
|
||||
|
||||
<ul>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user