On 09/05/2011 07:48 PM, Bruce Dubbs wrote:
> DJ Lucas wrote:
> > LSB defined functions belong in /lib/lsb/init_functions so that
> compliant
>> bootscripts work as expected. Do not include the LSB definitions directly in
>> the distro's functions file. Either source them in the distribution's
>> functions or move the distribution's functions to the end of
>> /lib/lsb/init_functions and source only the one file (preferred method as
>> discussed previously in the LSB thread).
> I've got the network service scripts in /lib/boot. I don't have a
> problem with renaming /lib/boot to /lib/lsb/ and functions to
> init_functions, but I'm not sure about having two new directories in
> /lib. I lean toward moving the LFS functions to the end of the a single
> init_functions file.
>
Okay...later question requires review of the spec to see if we can add
other items there, but again, lsb is not descriptive for networking
services. The spec requires /lib/lsb (and later /usr/lib/lsb), and the
discussion earlier wanted the service scripts separated. Need input form
all to see if this is acceptable.
>> There is no reason to redefine 35+ values every time a new script is
>> run. Once per runlevel change in rc is sufficient. One conditional
>> around the source line in each script, on a known constant should be
>> good, and will be more efficient, and nominally faster than sourcing
>> 2 or 3 files for every script that is run.
> I don't really follow this. Do you mean sourcing the functions within
> the rc file? If so, environment variables have to be exported to be
> available in child scripts. Additionally the scripts need to have the
> variables available if not run from the rc file.
>
> If I misunderstand you, please elaborate.
>
No, you didn't misunderstand. The variables have to be exported. That's
why there used to be a testcase around the source of distro functions in
/lib/lsb/init_functions. It was taken out with some of the more recent
changes (merger of $distro-functions and /lib/lsb/init_functions) and I
had forgotten to put it back. The getty does not pass the variables to
the login shell when rc passes control. Take a look at the LSB scripts
and default/rc{,.site} for the items that remain. It's probably a minor
point anyway, but something that was lost in multiple rewrites. Also,
stty sane can go now...it breaks input when run in x terminals in some
cases with our now proper input configurations, it was ^J and ^Z IIRC in
UTF-8 locales, been a few years since I ripped that out. Also, any idea
why the screen is cleared on tty1? I looked but didn't see anything.
>> Get rid of boot_mesg all together. This was left over from a mixed
>> results attempt at international messages and long display output
>> (and line wrapping). As James mentioned the other day, it has long
>> since been abandoned by all of us involved with adding it. Both the
>> echo binary and the bash built-in support the -e flag. We can choose
>> /bin/bash for the schebang in the scripts, or just use /bin/echo. The
>> built-in is faster, but we can guarantee that /bin/echo has the
>> needed functionality if the /bin/sh symlink is changed. Personally, I
>> prefer the /bin/bash schebang, but really no technical argument
>> either way.
> I prefer /bin/bash too, but left everything as /bin/sh (and used
> non-bash constructs). I think there may be a problem if a non-LFS
> script uses /bin/sh and the functions use /bin/bash.
>
> I agree that we can guarantee echo -e works and let the shell decide to
> use a builtin or /bin/echo.
>
Get rid of echo_*() and friends and just use print_*_msg() in these
cases. Handle boot logging in the print_*_msg() functions as per the LSB
spec (framework is already there if the LSB functions are copied directly).
>> Where did /lib/boot come from?
> Alzheimer's. I got my SS card on Saturday. Is that a :) or a :(
>
LOL
>> /lib/services was discussed and approved for
>> the network services by 5 participants (yourself included) back in May with
>> only one objection on naming which was later retracted. "boot" is also a
>> poor choice for the name if the network services are stored here as they
>> will be used after boot.
> I'm not real happy with /lib/services AND /lib/lsb, especially if
> lib/lsb has only one file. How about /lib/services and a symlink from
> /lib/lsb to /lib/services?
>
Again, spec review is required. That is a tomorrow thing. Need input
from others here as well because of the separation that was a goal in
the previous discussion.
>> Same thing for /etc/sysconfig. Consensus was
>> reached among participants to use /etc/default to help clean up the /etc
>> directory a tiny bit, and /etc/network for network configuration scripts.
> I'd like to revisit that. The way I've done the network scripts, there
> are no subdirectories to /etc/sysconfig and all the scripts are in the
> form of ifconfig*. On a simple system, there is only ifconfig.eth0, but
> things like ifconfig.eth0.ip2 are honored. sysconfig stands for system
> configuration and I think more descriptive than default.
>
> There are only a few files in /etc/sysconfig now:
> init_params
> network
> clock
> console
> createfiles
> modules
> ifconfig*
>
> The optional init_params file is new and is intended to allow the user
> to consolidate the other files into one file. I never liked having
> something like clock exist to define one or two environment variables.
> Some of the scripts still demand their own file (that should be fixed),
> but init_params is always sourced in functions.
Yep, rc.site and rc could be combined...just add a separator. All of the
variables that are defined in the functions file can move there. Also,
what happened to the prefix formatting?
>> Also, what about rc.site?
> I'll add that back.
>
>> Networking while certainly cleaner, still has nowhere near the functionality
>> discussed on lfs-dev back in mid May which was agreed upon and improved in
>> discussion by 6 participants with zero voiced objections. See below for one
>> other suggestion made by Bruce that got little attention that I personally
>> think should have gotten more attention.
>>
>> As mentioned earlier, need --help and -h output on ifup and ifdown. A
>> manual page would be a really cool addition, but certainly is not
>> required. Time would probably be better _utilized_ elsewhere, but if
>> that peaks interest, then it's cool, just be prepared for possible
>> changes, but hopefully changes will not be needed and everything can
>> be placed in the service scripts.
> I intend to add -h, --help, and man pages for ifup and ifdown.
>
>> As mentioned previously, use LSB return values and message formatting
>> throughout all scripts for consistency. Use LSB defined functions as well if
>> possible, but do not sacrifice ease of scripting for distro scripts to
>> do so.
This can all be done by using the log_*_msg() functions.
>> IOW: distro functions should be only wrappers to LSB functions to both ease
>> the use of LSB defined functions, and make the bootscripts themselves look
>> much cleaner than raw LSB scripts (which tend to look very ugly).
> AFAIK, there are only 6 LSB bootscript functions: start_daemon,
> killproc, pidofproc, log_success_msg, log_failure_msg, log_warning_msg
>
>> Append bootlog to /var/log/boot.log at the end of rc, fix formatting,
>> and add timestamps as in any other log file. /bin/logger could be
>> used to get you the correct format, though I've preferred alternate
>> methods in the past.
> Reformatting is already on my TODO list. Using logger is a good idea.
> Appending to /var/log/boot.log is somthing I forgot, but doing it is a
> one liner.
Yeah, just do it in rc, the conditional is "prevlevel == S" and further
conditionally on != 0 or 6 if the alternate is used.
>> Also, log
>> only when the following is true:
>> if [ "${PREVLEVEL}" == "N" || "${PREVLEVEL}" == "S" ]; then...
>> or optionally (as was done previously):
>> if [ "${RUNLEVEL}" != "6" || "${RUNLEVEL}" != "0" ]; then...
> To get around a potential problem of file availability early in the boot
> process, I'm logging to /run/var/bootlog, which resides on a tmpfs. I
> think that all boot messages should be there, even after a login prompt.
> This is like dmesg where the kernel logs whenever messages that are
> appropriate.
>
> There is also a problem with logging messages late in the shutdown
> process after partitions are unmounted. I've updated the mountfs script
> for shutdown to use:
>
> umount -a -d -r -t notmpfs
>
> so tmpfs mounts (/run) stays available to the end. I suppose we could
> mark /run/var/bootlog with an end-of-boot marker and then just before
> unmounting partitions, copy everything after the mark to
> /var/log/boot.log. That just leaves swap, localnet and halt/reboot as
> scripts not written to /var/log/boot.log.
>
> Perhaps for shutdown, the mountfs script could be moved so the final
> sequence would be
>
> S80swap
> S90localnet
> S95mountfs
> S99halt/S99reboot
No...it's not really a boot log. No need to run in 0 or 6, or any other
runlevel change for that matter. See my comments above...pending
thoughts from others.
>> Also, a little OT, but while doing major surgery anyway, didn't anybody care
>> for the single line configuration format for the network that Bruce
>> suggested?
>>
>> Maybe comma-space delimited would be better than colon delimited as
>> originally suggested:
>>
>> # Begin eth0.conf
>> #IFACE, SERVICE, PARAMS
>> eth0, ipv4-static, 192.168.1.1, 24, 192.168.1.254, 192.168.1.255
>> eth0, ipv6-static, 2001:270:cb5f:5::, 64, MAC
>> eth0, ipv4-static-route, 192.168.2.192, 26, 192.168.1.2, 1
>> # End eth0.conf
>>
>> Of course, these could also be separated into 3 files named
>> 1stNIC.ipv4.conf,
>> ipv6.eth0.conf, and route-to-192.168.2.192\/26.conf if desired.
> I did suggest that, but decided it was simpler to use a separate file
> for each operation (but not a separate directory). This is especially
> true if we get into wifi later in BLFS. The idea here was to enable
> ifup/ifdown to take a wildcard. For example, if there is
>
> ifconfig.eth0
> ifconfig.eth0.ipv4
> etc
>
> Then the user could just run `ifdown ifconfig.eth0*`
>
> The ifconfig files require a parameter like IFACE=eth0. We could add a
> parameter to ifup/down like '-i eth0' that would scan all the ifconfig*
> files for eth0 and also add -a parameter to bring up or down all entries.
>
Interesting...let others chime in then. The state file still probably
needs to be added back in as that was determined to be the most reliable
way to handle configuration changes without first killing networking.
I'll be happy to post some suggested patches when we have a completed
list of goals. This will work out better than either in the end I think.
-- DJ Lucas
--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
