Re: Summary: Using the LSB Bootscripts

[Bryan Kadzban]

Bryan Kadzban wrote:
> DJ Lucas wrote:
>> * the path for the setclock script in 55-lfs.rules needs to be 
>> changed
> 
> So... yeah.
> 
> Why was this whole tree moved in the LSB scripts, again?  :-)
> 
> I really really hate systems where I can't reasonably tab-complete
> the bootscript filenames.  And there's way too much junk in /etc
> whose name collides with init.d for me to enjoy using a system that
> puts the init.d directory directly in /etc.  I *very* much prefer the
> existing bootscript setup, where all of the scripts and whatnot are
> sequestered under /etc/rc.d instead.  (Mostly because that can be tab
> completed after about 2 characters, and anything else under it in
> either 1, or 3.)
> 
> And of course, symlinks don't help, because symlinks (for the
> individual runlevel directories) collide with the rc.d name.
> 
> What requires these specific paths?

Still curious on this.  From the LSB link provided earlier, it *sounds*
like the requirement is that packages can put scripts into /etc/init.d/*
and then run install-initd, to get them turned on.  That can be done
pretty easily with the scripts in /etc/rc.d/init.d and a single symlink
named /etc/init.d pointing into the rc.d tree (no need for the rc?.d
links or directories to be directly in /etc).

Which is what I plan on doing on all of my systems anyway (except
without the link, since I don't care much about this kind of LSB setup)
-- but why not keep the tab completion, which is an IMO-extremely-nice
property of the current script setup?



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/15/11 3:25 AM, DJ Lucas wrote:
> wanted anyway). Problem with dhclient is that the value of DHCP_STOP
> will always be empty...all interfaces using dhclient will go. If you do
> 'service network stop' then no big deal. OTOH, if you execute ifdown
> ethn, and you have dhclient configured on multiple interfaces, not so
> good. I still don't understand why anyone would choose dhclient over
> dhcpcd. This will work, I just need a slightly more intelligent way to
> handle it, might actually be easier to provide a default IFCONFIG values
> in each service script, and walk /lib/network-services.

dhclient is the reference implementation and widely used, it works well. 
Also, I believe your statement about stopping per interface is 
incorrect, or at least I may be misunderstanding what you're saying.
You can kill a specific pid file per interface for dhclient. Here's what 
Fedora does:

[ -n "$(pidof -x dhclient)" ] && {
for VER in "" 6 ; do
 if [ -f "/var/run/dhclient$VER-${DEVICE}.pid" ]; then
 dhcpid=$(cat /var/run/dhclient$VER-${DEVICE}.pid)
 if [[ "$DHCPRELEASE" = [yY1]* ]];  then
 /sbin/dhclient -r -lf 
/var/lib/dhclient/dhclient$VER-${DEVICE}.leases -pf 
/var/run/dhclient-${DEVICE}.pid ${DEVICE} >/dev/null 2>&1
 retcode=$?
 else
 kill $dhcpid >/dev/null 2>&1
 retcode=$?
 reason=STOP$VER interface=${DEVICE} 
/sbin/dhclient-script
 fi
 if [ -f "/var/run/dhclient$VER-${DEVICE}.pid" ]; then
 rm -f /var/run/dhclient$VER-${DEVICE}.pid
 kill $dhcpid >/dev/null 2>&1
 fi
 fi
 done
}

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/18/11 12:28 AM, Bryan Kadzban wrote:
> Anybody know how other distros do it?  I can't figure out what Debian's
> ifdown binary is supposed to do (its source is *extremely* obfuscated,
> being built from a texinfo file, and containing a file parser)...

Fedora does a much more elaborate version of what I included in my 
adjusted scripts. First it checks to see what type of a network device 
it is and then process a specific down script for that device type.

In the Ethernet type, which is default, they check to see if dhcp is 
running and if the device has a lease and if so release it. Then they have:

# we can't just delete the configured address because that address
# may have been changed in the config file since the device was
# brought up.  Flush all addresses associated with this
# instance instead.
if [ -d "/sys/class/net/${REALDEVICE}" ]; then
 if [ "${REALDEVICE}" = "${DEVICE}" ]; then
 ip addr flush dev ${REALDEVICE} 2>/dev/null
 else
 ip addr flush dev ${REALDEVICE} label ${DEVICE} 2>/dev/null
 fi

 if [ "${SLAVE}" = "yes" -a -n "${MASTER}" ]; then
 echo "-${DEVICE}" > 
/sys/class/net/${MASTER}/bonding/slaves 2>/dev/null
 fi

 if [ "${REALDEVICE}" = "${DEVICE}" ]; then
 ip link set dev ${DEVICE} down 2>/dev/null
 fi
fi

After that they also check for any specific bridging rules and handle 
that as well.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/17/2011 11:34 PM, Bryan Kadzban wrote:
> Few nits related to the shell.  In the network script:
>
>>  # Process individual configuration files
>>  for file in `ls "${dir}"`; do
> Ew.  :-)  How about:
>
> for file in "${dir}"/* ; do
>  ONBOOT=`grep "ONBOOT" "${file}" | sed ...
> ...
>
>  
I had used it that way for debugging to create a list. There was a 
reason that it was left that way, but I can't for the life of me recall 
what it was, and it obviously wasn't important.
> (since it always does a ${dir}/${file} as written)
>
> In the ifup/ifdown scripts:
>
>> else
>>  grep "${INTERFACE}" /proc/net/dev 2>&1>  /dev/null
>>  if [ "${?}" != "0" ]; then
> Why not a (simpler):
>
> if grep "${INTERFACE}" /proc/net/dev 2>&1>  /dev/null ; then
>
> instead?  (This is done in several places: anywhere the script is
> testing the value of "$?" can potentially be simplified.)
>
Simply preference, it looks more explicit to my eyes if someone wants to 
review the script and learn from it. I went ahead and changed all four 
examples to inline tests.

>>  echo "ERROR: ${INTERFACE} is not a valid network interface."
>>  echo ""
>>  exit2
> That should be "exit 2", right?  :-)
Fixed.
>>  fi
>> fi

Thanks for the review.

-- 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

Re: Summary: Using the LSB Bootscripts

[Bryan Kadzban]

Few nits related to the shell.  In the network script:

> # Process individual configuration files
> for file in `ls "${dir}"`; do

Ew.  :-)  How about:

for file in "${dir}"/* ; do
ONBOOT=`grep "ONBOOT" "${file}" | sed ...
...

(since it always does a ${dir}/${file} as written)

In the ifup/ifdown scripts:

> else
> grep "${INTERFACE}" /proc/net/dev 2>&1 > /dev/null
> if [ "${?}" != "0" ]; then

Why not a (simpler):

if grep "${INTERFACE}" /proc/net/dev 2>&1 > /dev/null ; then

instead?  (This is done in several places: anywhere the script is
testing the value of "$?" can potentially be simplified.)

> echo "ERROR: ${INTERFACE} is not a valid network interface."
> echo ""
> exit2

That should be "exit 2", right?  :-)

> fi
> fi




signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Bryan Kadzban]

Jeremy Huntwork wrote:
> On 5/16/11 1:49 AM, Bryan Kadzban wrote:
>> I'm not sure what the goal *should* be.  :-)  Does it make sense to
>> try to clean up completely in this kind of setup?  Maybe or maybe
>> not.
>> 
>> I do think it's least *surprising* to only undo the effects of the
>> start script, though.  For whatever that's worth.
> 
> I do think we're getting a little overcomplicated here. Let's try to
>  simplify expectations. Here's what I expect (and I *think* this is 
> reasonable - you tell me :-) )
> 
> When I run the equivalent of /etc/init.d/network stop:
> 
> All devices configured to start ONBOOT are shut down,

Yeah (subject to what DJ said as well, though).

> any addresses assigned to them are removed (this of course means that
> if there is a running dhcp service in the background, it won't add
> any addresses to the device until I restart the network service).

Hmm.

I guess this does make sense if you consider "/etc/rc/init.d/network
stop" to be the equivalent of "tear down all networking".  And I suppose
that's not unreasonable.  At machine shutdown time especially, I'd
expect everything to stop.

This does, however, mean that extra manual configuration will be lost on
an "/etc/rc.d/init.d/network restart" run, and that I think I'd find a
bit surprising.  Obviously this is hard to fix, though; maybe another
param could be provided to the stop mode to prevent flushing IPs, etc.?
That still seems like a bit of a hack though.

Or maybe we just go with it.  That's probably not too bad.  :-)

Anybody know how other distros do it?  I can't figure out what Debian's
ifdown binary is supposed to do (its source is *extremely* obfuscated,
being built from a texinfo file, and containing a file parser)...



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/17/2011 08:54 AM, Jeremy Huntwork wrote:
>
> I do think we're getting a little overcomplicated here. Let's try to
> simplify expectations. Here's what I expect (and I *think* this is
> reasonable - you tell me :-) )
>
> When I run the equivalent of /etc/init.d/network stop:
>
> All devices configured to start ONBOOT are shut down,
Also anything configured by hotplug or any other method that uses 
/sbin/ifup with a configuration file as the config file will be in the 
state directory. When networking is stopped, there is no need to check 
the value of ONBOOT. Conditions on the value of ONBOOT could actually be 
harmful when stopping networking.

-- 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

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/17/2011 08:54 AM, Jeremy Huntwork wrote:

On 5/16/11 1:49 AM, Bryan Kadzban wrote:

I'm not sure what the goal *should* be.  :-)  Does it make sense to try
to clean up completely in this kind of setup?  Maybe or maybe not.

I do think it's least *surprising* to only undo the effects of the start
script, though.  For whatever that's worth.

I do think we're getting a little overcomplicated here. Let's try to
simplify expectations. Here's what I expect (and I *think* this is
reasonable - you tell me :-) )

When I run the equivalent of /etc/init.d/network stop:

All devices configured to start ONBOOT are shut down, any addresses
assigned to them are removed (this of course means that if there is a
running dhcp service in the background, it won't add any addresses to
the device until I restart the network service).

When I run the equivalent of /etc/init.d/network start:

Any devices configured to start ONBOOT are brought up according to the
settings in their associated config file.

This behavior implies that I should be able to modify network devices on
the fly. If the service is restarted, the devices will only be activated
with configuration explicitly stated in the config files.

JH
With ifup and ifdown public, they needed to have predictable behavior 
with invalid options, and provide a help text. Having been edited a 
thousand times, those scripts had become kind of ugly to look at. At 
very least, they are more linear, but IMO they are much cleaner and easy 
to follow now.


Scripts attached for review.

-- DJ Lucas


--
This message has been scanned for viruses and
dangerous content, and is believed to be clean.

#!/bin/sh
# Begin /etc/init.d/network

### BEGIN INIT INFO
# Provides:$network
# Required-Start:  $local_fs swap localnet
# Should-Start:$syslog
# Required-Stop:   $local_fs swap localnet 
# Should-Stop: $syslog
# Default-Start:   3 4 5
# Default-Stop:0 1 2 6
# Short-Description:   Starts and configures network interfaces.
# Description: Starts and configures network interfaces.
# X-LFS-Provided-By:   LFS
### END INIT INFO

. /lib/lsb/init-functions

case "${1}" in
start)
# Start all network interfaces
for dir in ${NETWORK_DEVICES}/ifconfig.*
do
interface=${dir##*/ifconfig.}
# skip if $dir is * (because nothing was found)
if [ "${interface}" = "*" ]; then
continue
fi
# Process individual configuration files
for file in `ls "${dir}"`; do
ONBOOT=`grep "ONBOOT" "${dir}/${file}" | sed 's@^ONBOOT=@@'`
case "${ONBOOT}" in
Y* | y* | 0)
/sbin/ifup -c "${dir}/${file}" "${interface}"
;;
esac
done
done
;;

stop)
# Reverse list
DIRS=""
for dir in /run/network/ifconfig.*
do
DIRS="${dir} ${DIRS}"
done

# Stop all network interfaces
for dir in ${DIRS}; do
interface=${dir##*/ifconfig.}
# skip if $dir is * (because nothing was found)
if [ "${interface}" = "*" ]; then
continue
fi
# Process individual configuration files
for file in `ls "${dir}"`; do
# No checking necessary if it is in /run/network
/sbin/ifdown -c "${dir}/${file}" "${interface}"
done
link_status=`/sbin/ip link show "${interface}" | \
grep -o "state DOWN"`
if [ "${link_status}" != "state DOWN" ]; then
message="Shutting down the ${interface} interface..."
/sbin/ip addr flush "${interface}" &&
/sbin/ip link set "${interface}" down
evaluate_retval standard
fi
done
;;

restart)
${0} stop
sleep 1
${0} start
;;

*)
echo "Usage: ${0} {start|stop|restart}"
exit 1
;;
esac

# End /etc/init.d/network
#!/bin/sh

# Begin /sbin/ifdown
#
# Description : Interface Down
#
# Authors : DJ Lucas - d...@linuxfromscratch.org
#
# Version : 00.02
#


. /lib/lsb/init-functions

function get_args()
{
if test -z "${1}" ; then
showhelp
exit 1
fi

while test -n "${1}" ; do
case "${1}" in
-c | --configfile)
check_arg $1 $2
CONFIGFILE="${2}"
shift 2
;;
-f | --force)
FORCE="1"
shift 1
;;
eth* | iw* | wlan*)
 INTERFACE="${1}"
 shift 1
;;
   

Re: Summary: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/16/11 1:49 AM, Bryan Kadzban wrote:
> I'm not sure what the goal *should* be.  :-)  Does it make sense to try
> to clean up completely in this kind of setup?  Maybe or maybe not.
>
> I do think it's least *surprising* to only undo the effects of the start
> script, though.  For whatever that's worth.

I do think we're getting a little overcomplicated here. Let's try to 
simplify expectations. Here's what I expect (and I *think* this is 
reasonable - you tell me :-) )

When I run the equivalent of /etc/init.d/network stop:

All devices configured to start ONBOOT are shut down, any addresses 
assigned to them are removed (this of course means that if there is a 
running dhcp service in the background, it won't add any addresses to 
the device until I restart the network service).

When I run the equivalent of /etc/init.d/network start:

Any devices configured to start ONBOOT are brought up according to the 
settings in their associated config file.

This behavior implies that I should be able to modify network devices on 
the fly. If the service is restarted, the devices will only be activated 
with configuration explicitly stated in the config files.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Bryan Kadzban]

Zachary Kotlarek wrote:
> A compromise might be to provide an `ifreset` script, that does a
> full ipflush, walks the services dir calling a `reset` target, etc.,
> but *not* integrate that script into ifdown.

That seems like a pretty good idea.  :-)



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

Bruce Dubbs  wrote:

>Zachary Kotlarek wrote:
>> On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote:
>> 
>>> I also *think* the only way the cached config might not match the
>>> running config is if root mucked with the running config manually.
>> 
>> 
>> Or when /run is not writable at the time the network scripts execute.
>
>The only way that could happen would be if rcsysinit.d/S00mountvertfs 
>failed to execute which means that the whole system would fail.  You 
>wouldn't have /proc or /sys either.
>

Actually, that is handled by rc directly now.

-- DJ

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
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

Re: Summary: Using the LSB Bootscripts

[Bruce Dubbs]

Zachary Kotlarek wrote:
> On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote:
> 
>> I also *think* the only way the cached config might not match the
>> running config is if root mucked with the running config manually.
> 
> 
> Or when /run is not writable at the time the network scripts execute.

The only way that could happen would be if rcsysinit.d/S00mountvertfs 
failed to execute which means that the whole system would fail.  You 
wouldn't have /proc or /sys either.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Zachary Kotlarek]

On May 16, 2011, at 12:49 AM, Bryan Kadzban wrote:

> I also *think* the only way the cached config might not match the
> running config is if root mucked with the running config manually.


Or when /run is not writable at the time the network scripts execute. Or if the 
cached config were lost for some reason (someone deleted the wrong file in /run 
or mounted a new fs over /run after the network scripts came up). I don't think 
either is likely to be a common occurrence.


> And in that case, I don't think it's smart to override that decision.



I think this is the real question -- do we want to help people get back to a 
"known good" state at the cost of breaking out-of-band configuration, or do we 
let people in bad states deal with that on their own?

A compromise might be to provide an `ifreset` script, that does a full ipflush, 
walks the services dir calling a `reset` target, etc., but *not* integrate that 
script into ifdown.

Zach



smime.p7s
Description: S/MIME cryptographic signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/16/2011 12:49 AM, Bryan Kadzban wrote:
> Zachary Kotlarek wrote:
>> On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote:
>>
>>> I'm trying to figure out why it'd be necessary to do this.  We
>>> already have the previous configuration of every interface stuffed
>>> away in /run, and we use that when deciding which service scripts
>>> to call when bringing down networking.  Doesn't that kill the pppd
>>> / pppoe / dhclient / dhcpcd / whatever daemons already?  And
>>> doesn't that remove the IPs that were configured already, for
>>> static?
>> I thought the goal was to predictably handle scenarios where the
>> running config didn't match the cached version, or where there was no
>> cached version.
> While I don't want to speak for the people actually doing the work here,
> it seems to me like this might be getting a bit complicated for the wins
> here.  I don't think it's very likely that there is no cached version
> (since we store it away at boot time when the scripts set up the
> interfaces).
>
> I also *think* the only way the cached config might not match the
> running config is if root mucked with the running config manually.  And
> in that case, I don't think it's smart to override that decision.
>
> (Consider, for instance, a setup that requires two IPs on a single NIC,
> both on a single subnet -- say one for management and another for real
> traffic, with filtering upstream to prevent management packets from the
> public Internet.  The management IP might be set up outside the scripts
> for some reason (especially at machine setup time, but potentially in
> other cases as well, for configuration management and redundancy
> reasons), in which case flushing all IPs at interface-down would be
> actively harmful.)
>
> Though I suppose this isn't terribly likely either.  Hmm.
>
>> If the goal is only to directly cancel the configuration as-cached,
>> and not to care if that cache is no longer accurate or no longer
>> exists, then I agree, there's no need to do any of this special
>> handling as the normal service scripts should be sufficient.
> I'm not sure what the goal *should* be.  :-)  Does it make sense to try
> to clean up completely in this kind of setup?  Maybe or maybe not.
>
> I do think it's least *surprising* to only undo the effects of the start
> script, though.  For whatever that's worth.
It is worth a lot, and I'm kind of in the same camp. However, there was 
a request, and I'd like for this to be the same solution for all 
_if_possible_.  The thing is, what do admins typically do when using 
other distros? I know how I make changes in LFS, and that involves a 
temporary config file, stop networking, copy new config, start 
networking, which seems pretty obvious to me having been using LFS for 
so long. When I use a distro, I usually use some distro supplied tool to 
make configuration changes, but I only maintain maybe 10 distro Linux 
servers at this point, and couldn't tell you the last time I had to make 
networking changes. This may not be the case for somebody who has been 
using say RedHat on 50+ servers for the past 10 years and knows the 
format of the configuration files like the back of her hand.

For instance, take a temporary configuration change, admin might simply 
run 'ifdown eth0' (or 'service network stop') expecting all the 
configuration changes to go out the window right then (I don't honestly 
know if that is the case in other distros, I know that it works as is 
for ). I don't think that is unacceptable, it's just finding a working 
solution that is agreeable by everyone. An argument can equally be made 
for root changes to be undone by root (as above, and I am actually in 
that group). As far as I'm concerned, what is there now works well 
enough for my purposes, and probably greater than 99.99% of all users, 
but I don't mind spending the extra time to explore the possibility of 
additional functionality to cover the other less than .01%, but I do 
need to step back for a second and take into account all arguments 
for/against.

If I do come up with what I think to be a working solution, it certainly 
won't go in without review because I don't use the other services very 
often (at all right now, everything is static now). I need to see if it 
would reek havoc on other corner cases such as the one mentioned above. 
It may be that we can't meet everyone's expectations (which is why I 
haven't simply added 'ip addr flush $1' to the end of the ifdown script 
yet). That is another thing too, now that ifup and ifdown are no longer 
in a controlled environment and available to admins without mucking 
around in the network-devices tree, some error checking needs to be done 
in the scripts for proper arguments and maybe a help text. As it is now, 
if you run ifdown on an interface that has no config file, you get a 
warning and an ugly error message from bash. That will probably be 
another small change that doesn't have any affect the existing automated 
setup.

--

Re: Summary: Using the LSB Bootscripts

[Bryan Kadzban]

Zachary Kotlarek wrote:
> On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote:
> 
>> I'm trying to figure out why it'd be necessary to do this.  We 
>> already have the previous configuration of every interface stuffed 
>> away in /run, and we use that when deciding which service scripts 
>> to call when bringing down networking.  Doesn't that kill the pppd 
>> / pppoe / dhclient / dhcpcd / whatever daemons already?  And 
>> doesn't that remove the IPs that were configured already, for 
>> static?
> 
> I thought the goal was to predictably handle scenarios where the 
> running config didn't match the cached version, or where there was no
> cached version.

While I don't want to speak for the people actually doing the work here,
it seems to me like this might be getting a bit complicated for the wins
here.  I don't think it's very likely that there is no cached version
(since we store it away at boot time when the scripts set up the
interfaces).

I also *think* the only way the cached config might not match the
running config is if root mucked with the running config manually.  And
in that case, I don't think it's smart to override that decision.

(Consider, for instance, a setup that requires two IPs on a single NIC,
both on a single subnet -- say one for management and another for real
traffic, with filtering upstream to prevent management packets from the
public Internet.  The management IP might be set up outside the scripts
for some reason (especially at machine setup time, but potentially in
other cases as well, for configuration management and redundancy
reasons), in which case flushing all IPs at interface-down would be
actively harmful.)

Though I suppose this isn't terribly likely either.  Hmm.

> If the goal is only to directly cancel the configuration as-cached, 
> and not to care if that cache is no longer accurate or no longer 
> exists, then I agree, there's no need to do any of this special 
> handling as the normal service scripts should be sufficient.

I'm not sure what the goal *should* be.  :-)  Does it make sense to try
to clean up completely in this kind of setup?  Maybe or maybe not.

I do think it's least *surprising* to only undo the effects of the start
script, though.  For whatever that's worth.



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Zachary Kotlarek]

On May 15, 2011, at 12:31 PM, Bryan Kadzban wrote:

> I'm trying to figure out why it'd be necessary to do this.  We already
> have the previous configuration of every interface stuffed away in /run,
> and we use that when deciding which service scripts to call when
> bringing down networking.  Doesn't that kill the pppd / pppoe / dhclient
> / dhcpcd / whatever daemons already?  And doesn't that remove the IPs
> that were configured already, for static?


I thought the goal was to predictably handle scenarios where the running config 
didn't match the cached version, or where there was no cached version.

If the goal is only to directly cancel the configuration as-cached, and not to 
care if that cache is no longer accurate or no longer exists, then I agree, 
there's no need to do any of this special handling as the normal service 
scripts should be sufficient.

Zach



smime.p7s
Description: S/MIME cryptographic signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Bryan Kadzban]

Zachary Kotlarek wrote:
> On May 15, 2011, at 2:25 AM, DJ Lucas wrote:
>> might actually be easier to provide a default IFCONFIG values in 
>> each service script, and walk /lib/network-services.
> 
> This make sense to me -- then it's easy to extend the same approach 
> for arbitrary service types -- say pppoe -- which might want to do 
> similar things (i.e. kill the daemon on interface-down).

I'm trying to figure out why it'd be necessary to do this.  We already
have the previous configuration of every interface stuffed away in /run,
and we use that when deciding which service scripts to call when
bringing down networking.  Doesn't that kill the pppd / pppoe / dhclient
/ dhcpcd / whatever daemons already?  And doesn't that remove the IPs
that were configured already, for static?



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Bryan Kadzban]

DJ Lucas wrote:
> * the path for the setclock script in 55-lfs.rules needs to be
> changed

So... yeah.

Why was this whole tree moved in the LSB scripts, again?  :-)

I really really hate systems where I can't reasonably tab-complete the
bootscript filenames.  And there's way too much junk in /etc whose name
collides with init.d for me to enjoy using a system that puts the init.d
directory directly in /etc.  I *very* much prefer the existing
bootscript setup, where all of the scripts and whatnot are sequestered
under /etc/rc.d instead.  (Mostly because that can be tab completed
after about 2 characters, and anything else under it in either 1, or 3.)

And of course, symlinks don't help, because symlinks (for the individual
runlevel directories) collide with the rc.d name.

What requires these specific paths?



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[Zachary Kotlarek]

On May 15, 2011, at 2:25 AM, DJ Lucas wrote:

> might actually be easier to provide a default IFCONFIG values 
> in each service script, and walk /lib/network-services.


This make sense to me -- then it's easy to extend the same approach for 
arbitrary service types -- say pppoe -- which might want to do similar things 
(i.e. kill the daemon on interface-down).

Zach



smime.p7s
Description: S/MIME cryptographic signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/15/2011 01:39 AM, Nathan Coulson wrote:



On Sat, May 14, 2011 at 9:36 PM, DJ Lucas > wrote:


On 05/14/2011 04:37 PM, DJ Lucas wrote:
> Everything is covered per this conversation in SVN with the
exception of
> accounting for missing /run in LightCube OS, but I think it was
decided
> that it would be added. Also no ip flush (I forgot, but will get
it in a
> day or two) on down interface, and dhcp calls not accounted for.
I'll need to setup both DHCP clients to test functionality for this,
which is why I didn't just do it tonight. The problem I want to
avoid is
if we do a flush, but the client daemon is still running, come
expiration, the client daemon might try to reconfigure the
device...even
if it means adding dhcp logic in the lfs scripts (or replacing them in
BLFS). Also, is anyone still using RP for PPPoE, alos simple ppp, that
is willing to test? I unfortunately no longer have a ?DSL circuit to
test with so I'll need some help from somebody who does. I would think
if the link is set down the client daemons for the dhcp clients would
exit, but would ppp attempt to reconnect? I'm also thinking that the
added functionality for ifdown can be done in a modular way in
/lib/network-services so that it can be divvied up for each who
needs it.

-- DJ Lucas


dhclient, and dhcpcd checks,  does get ugly if we test for specific 
programs.  I always liked avoiding package specific work.  (and there 
are other dhcp clients out there.  My openwrt has dnsmaq for example)
Yeah, could use a bit of help here actually. I'm thinking about 
providing default service config values in the service script itself (to 
be over ridden by the config file), and a guard at the top of the 
service script for IFCONFIG, and just walking the /lib/network-service 
tree from ifdown. This seems easiest, and more importantly, most 
efficient in that for each service, a generic "stop" target can can be 
called for an interface (as opposed to down), and the service script has 
the logic, not the ifdown script. This makes it extensible for whatever 
you want to throw at it. For instance, in the case of both dhcp cleints, 
you check for the appropriate lease file, or just exit 0. Have to 
explicitly exclude ipv4-static and ipv4-static-route, reason being we'll 
flush all IPs on the interface, so ipv4-static is not needed, and when 
the link is dropped, the kernel will drop the static routes as well. Do 
you see anything wrong with that logic?


-- 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

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/15/2011 01:22 AM, DJ Lucas wrote:
> On 05/15/2011 12:11 AM, Zachary Kotlarek wrote:
>> Could we just do this in ifdown:
>>
>>  if [ -x /lib/network-services/dhcp ]; then
>>  /lib/network-services/dhcp $interface down
>>  fi
>>
>> and assume that whatever DHCP client is installed (if any) provides a script 
>> appropriate to handle the interface shutdown?
>>
>>  Zach
> Actually, yeah, that is a great idea! We had planned to merge the dhcp
> scripts anyway to simplify Gnome-System-Tools interface management in BLFS.
>
Okay, couple of caveats, but nothing major. For dhcpcd it is simply a 
check for $PIDFILE or exit 0 and guard the source of $IFCONFIG with an 
if then. For dhclient, it is a check of dhclient.leases, and wrap source 
of $IFCONFIG. Of course, both will have to have the install target 
service as dhcp with a different file name in the tarball (which we 
wanted anyway). Problem with dhclient is that the value of DHCP_STOP 
will always be empty...all interfaces using dhclient will go. If you do 
'service network stop' then no big deal. OTOH, if you execute ifdown 
ethn, and you have dhclient configured on multiple interfaces, not so 
good. I still don't understand why anyone would choose dhclient over 
dhcpcd. This will work, I just need a slightly more intelligent way to 
handle it, might actually be easier to provide a default IFCONFIG values 
in each service script, and walk /lib/network-services.

-- 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

Re: Summary: Using the LSB Bootscripts

[Nathan Coulson]

On Sat, May 14, 2011 at 9:36 PM, DJ Lucas  wrote:

> On 05/14/2011 04:37 PM, DJ Lucas wrote:
> > Everything is covered per this conversation in SVN with the exception of
> > accounting for missing /run in LightCube OS, but I think it was decided
> > that it would be added. Also no ip flush (I forgot, but will get it in a
> > day or two) on down interface, and dhcp calls not accounted for.
> I'll need to setup both DHCP clients to test functionality for this,
> which is why I didn't just do it tonight. The problem I want to avoid is
> if we do a flush, but the client daemon is still running, come
> expiration, the client daemon might try to reconfigure the device...even
> if it means adding dhcp logic in the lfs scripts (or replacing them in
> BLFS). Also, is anyone still using RP for PPPoE, alos simple ppp, that
> is willing to test? I unfortunately no longer have a ?DSL circuit to
> test with so I'll need some help from somebody who does. I would think
> if the link is set down the client daemons for the dhcp clients would
> exit, but would ppp attempt to reconnect? I'm also thinking that the
> added functionality for ifdown can be done in a modular way in
> /lib/network-services so that it can be divvied up for each who needs it.
>
> -- DJ Lucas
>

dhclient, and dhcpcd checks,  does get ugly if we test for specific
programs.  I always liked avoiding package specific work.  (and there are
other dhcp clients out there.  My openwrt has dnsmaq for example)

-- 
Nathan Coulson (conathan)
--
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/15/2011 12:11 AM, Zachary Kotlarek wrote:
> Could we just do this in ifdown:
>
>   if [ -x /lib/network-services/dhcp ]; then
>   /lib/network-services/dhcp $interface down
>   fi
>
> and assume that whatever DHCP client is installed (if any) provides a script 
> appropriate to handle the interface shutdown?
>
>   Zach
Actually, yeah, that is a great idea! We had planned to merge the dhcp 
scripts anyway to simplify Gnome-System-Tools interface management in BLFS.

-- 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

Re: Summary: Using the LSB Bootscripts

[Zachary Kotlarek]

On May 14, 2011, at 11:36 PM, DJ Lucas wrote:

> I'll need to setup both DHCP clients to test functionality for this, 
> which is why I didn't just do it tonight. The problem I want to avoid is 
> if we do a flush, but the client daemon is still running, come 
> expiration, the client daemon might try to reconfigure the device...even 
> if it means adding dhcp logic in the lfs scripts (or replacing them in 
> BLFS).


Could we just do this in ifdown:

if [ -x /lib/network-services/dhcp ]; then
/lib/network-services/dhcp $interface down
fi

and assume that whatever DHCP client is installed (if any) provides a script 
appropriate to handle the interface shutdown?

Zach



smime.p7s
Description: S/MIME cryptographic signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Summary: Using the LSB Bootscripts

[DJ Lucas]

On 05/14/2011 04:37 PM, DJ Lucas wrote:
> Everything is covered per this conversation in SVN with the exception of
> accounting for missing /run in LightCube OS, but I think it was decided
> that it would be added. Also no ip flush (I forgot, but will get it in a
> day or two) on down interface, and dhcp calls not accounted for.
I'll need to setup both DHCP clients to test functionality for this, 
which is why I didn't just do it tonight. The problem I want to avoid is 
if we do a flush, but the client daemon is still running, come 
expiration, the client daemon might try to reconfigure the device...even 
if it means adding dhcp logic in the lfs scripts (or replacing them in 
BLFS). Also, is anyone still using RP for PPPoE, alos simple ppp, that 
is willing to test? I unfortunately no longer have a ?DSL circuit to 
test with so I'll need some help from somebody who does. I would think 
if the link is set down the client daemons for the dhcp clients would 
exit, but would ppp attempt to reconnect? I'm also thinking that the 
added functionality for ifdown can be done in a modular way in 
/lib/network-services so that it can be divvied up for each who needs it.

-- 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

Summary: Using the LSB Bootscripts

[DJ Lucas]

Everything is covered per this conversation in SVN with the exception of 
accounting for missing /run in LightCube OS, but I think it was decided 
that it would be added. Also no ip flush (I forgot, but will get it in a 
day or two) on down interface, and dhcp calls not accounted for. Quite a 
few changes are required for the book to work with them now including:

* rendering of scripts in the book, path and name changes
* tarball creation with book render job
* inittab is installed by the bootscripts package (this could be changed 
if desired)
* initd-tools page needs to be added
* the path for the setclock script in 55-lfs.rules needs to be changed
* the network interface configuration file should be placed in 
/etc/network/ifconfig./
* setting clock parameters for the setclock script is done in /etc/rc.site
* setting the hostname is now done in /etc/rc.site
* add mention of turning off bootlogging and interactive prompt


For LightCube OS (or anyone else that would like to customize the 
scripts for their release), hopefully all that is needed is a similar 
patch to the one below, in addition to the one adding additional 
services and scripts (which will need to be rediffed for the new file 
layout),

diff -Naur lsb-bootscripts-20110514/etc/default/rc.site 
lsb-bootscripts-20110514-LCOS/etc/default/rc.site
--- lsb-bootscripts-20110514/etc/default/rc.site2011-05-14 
16:00:31.0 -0500
+++ lsb-bootscripts-20110514-LCOS/etc/default/rc.site2011-05-14 
16:30:27.0 -0500
@@ -9,7 +9,7 @@
  BOOTLOG_ENAB="yes"

  # Hostname
-HOSTNAME=
+HOSTNAME=

  # System time variables
  UTC=1
@@ -17,12 +17,12 @@

  # Manual input is not appropriate on remote systems. Define what 
happens when
  # an error is encountered that interupts the boot/shutdown proceess
-FAILURE_ACTION="read ENTER"
+FAILURE_ACTION='echo ""'

  # Distro Information
-DISTRO="Linux From Scratch" # The distro name
-DISTRO_CONTACT="lfs-dev@linuxfromscratch.org" # Bug report address
-DISTRO_MINI="lfs" # Short name used in filenames for distro config
+DISTRO="LightCube OS"
+DISTRO_CONTACT="http://dev.lightcube.us/projects/lightcubeos/issues";
+DISTRO_MINI="lightcube"

  # Define custom colors used in messages printed to the screen
  BRACKET="\\033[1;34m" # Blue
@@ -45,9 +45,9 @@
  export PREFIX_SUCCESS PREFIX_WARNING PREFIX_FAILURE

  # Interactive startup
-iprompt="yes" # Wether to display the interactive boot promp
+iprompt="no" # Wether to display the interactive boot promp
  itime="2" # The ammount of time (in seconds) to display the prompt
-dlen="29" # The total length of the distro welcome string
+dlen="23" # The total length of the distro welcome string
  ilen="38" # The total length of the interactive message
  welcome_message="Welcome to ${INFO}${DISTRO}${NORMAL}"
  i_message="Press '${FAILURE}I${NORMAL}' to enter interactive startup"
diff -Naur lsb-bootscripts-20110514/Makefile 
lsb-bootscripts-20110514-LCOS/Makefile
--- lsb-bootscripts-20110514/Makefile2011-05-14 16:00:31.0 -0500
+++ lsb-bootscripts-20110514-LCOS/Makefile2011-05-14 
16:26:42.0 -0500
@@ -25,7 +25,7 @@
  install: create-dirs
  install -m ${MODE} etc/init.d/checkfs   ${EXTDIR}/init.d/
  install -m ${MODE} etc/init.d/cleanfs   ${EXTDIR}/init.d/
-install -m ${CONFMODE} etc/init.d/lfs-functions ${EXTDIR}/init.d/
+install -m ${CONFMODE} etc/init.d/lfs-functions 
${EXTDIR}/init.d/lightcube-functions
  install -m ${MODE} etc/init.d/halt  ${EXTDIR}/init.d/
  install -m ${MODE} etc/init.d/console   ${EXTDIR}/init.d/
  install -m ${MODE} etc/init.d/localnet  ${EXTDIR}/init.d/


Think that covers it all. Time for some testing.

-- 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

Re: Using the LSB Bootscripts

[Dan Nicholson]

On Tue, May 10, 2011 at 6:39 AM, Jeremy Huntwork
 wrote:
> On 5/10/11 8:25 AM, DJ Lucas wrote:
>>       * Most important, pull as much as possible of the items below from
>> LightCube OS's files to ease merging and keep the diffs to a minimum so
>> that they are easily shared across distributions.
>>       * Move ifup and ifdown scripts to /sbin.
>>       * Move network service scripts to /lib/services (there was one
>> minor objection here, should that be /lib/network-services or
>> /lib/network? I don't really have any preference here, /lib/services is
>> fine by me).
>>       * Move network configuration files to /etc/network.
>>       * Move network (hostname value) and clock config into
>> /etc/default/rc.site (default to UTC?)
>>       * Use /etc/default for rc configuration files (remaining items in
>> /etc/sysconfig currently).
>
> All fine from my perspective. :)
>
>>       * Add initd-tools to book - This is required for the new scripts.
>> Jeremy what is the status on this in LightCube OS? I remember a few
>> months ago about you possibly taking over maintenance of them, adding a
>> service binary/script and such? At last check, Dan did not have them in
>> an RCS, which is not an issue for now, just curious about the future of
>> the tools. The tarball and homepage are available in Dan's home
>> directory on freedesktop.org if we need for the book. Dan?
>
> I never got around to adding these into a repository, but I could do so.
> I'd be happy to maintain them. I'll need to schedule some time to get
> the infrastructure together for them and then post links.

I nominate you as the new maintainer. :) Since I don't roll my own
anymore I don't actually use the programs, but DJ has used them and
they worked for me at one point. I put the repo on freedesktop.org in
git://anongit.freedesktop.org/~dbn/initd-tools. I updated the webpage
with the relevant info, but it'll take a little longer for cgit to
display the repo.

http://people.freedesktop.org/~dbn/initd-tools/

Let me know if I can help. This was my first major C project, so you
might find some ugly code in there.

Good luck!

--
Dan
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Bryan Kadzban]

Jeremy Huntwork wrote:
> On 5/9/11 11:36 PM, Bryan Kadzban wrote:
>> Right, but the former /etc/sysconfig/network* was also default
>> configuration for how the bootscripts run.  Well, the network script
>> anyway.  :-)
> 
> Just ifup/ifdown (which are now in /sbin) and network-services/* which 
> is now in /lib/{network-}services - maybe I'm missing something?

The network-services/* stuff was what I meant by configuration.
(Especially the ifconfig. file or directory.)

This is more or less bikeshedding at this point though, I think.

>> So networking goes down before the per-client sshd processes, and the
>> kernel isn't smart enough to kill those connections at interface-down
>> time.  :-(
> 
> Well, that's actually a feature and not a bug. If your connection gets 
> interrupted temporarily by forces outside your control, you want the 
> session to be restored without interrupt.

I'd be surprised to find systems that did "ip link set dev eth0 down"
outside root's control.  :-)

(That's what I meant as the possible trigger for killing connections,
but obviously the kernel doesn't do it, so never mind.)

>> In that case, this should work.  Maybe with a comment explaining why
>> it's necessary though.
> 
> Yeah, I should have pasted the two comments that Fedora has in their 
> scripts, too:
> 
>  # if we are in halt or reboot runlevel kill all running sessions
>  # so the TCP connections are closed cleanly

Looks fine.



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[DJ Lucas]

On 05/10/2011 08:11 PM, Bruce Dubbs wrote:
> Archaic wrote:
>
>> Why MIT? These aren't book instructions.
> They are published in the appendices.
>
> -- Bruce
Yeah, but it is not in the tarball. The tarball can (and most likely 
will) be distributed outside of LFS. We are not discussing a change of 
license as it has always been MIT, at least as far as I can recall, back 
to around LFS 4 days maybe? I seem to recall something about Creative 
Commons at one point...been a long time since we've discussed licenses, 
but there is no need to worry about approval, just drop a text copy in 
SVN and it will be there. All of the contributors to the new scripts 
have agreed to that license (knowingly or not). The only maintenance 
burden comes once a year on Jan 1st.

-- 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

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/10/11 9:06 PM, Bruce Dubbs wrote:
> A date gives the user additional information.  How long since the last
> change?  Do I really need to update?  Using mmdd gives a
> monotonically increasing number and an idea of how long it has been
> since changes were made.  That is my preference.

*shrug* Just preference. Seeing dates on packages for any other piece of 
software always gives me a hesitant, uneasy feeling, because it feels 
like the code hasn't gone through a real dev cycle and been properly 
released. I'll work with whatever you all decide.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/10/11 9:11 PM, Bruce Dubbs wrote:
> Unnecessary.  The book copyright already covers it.

Except, if I am understanding it correctly, if LightCube OS uses and 
distributes it, we are bound by that license to keep the it with the 
code and we have no other tie to the book. So putting the license 
explicitly with the code in its package would be useful to us. Also, 
technically, the code is currently being distributed by you in packaged 
format without a license, because anyone could come across the link to 
the code without any direct reference to the book.

Anyway, I don't really see why this would be an objection or problem. 
One LICENSE file that's static and forever unchanging can't possibly be 
a burden for you guys to add?

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Bruce Dubbs]

Archaic wrote:
> On Tue, May 10, 2011 at 07:25:50AM -0500, DJ Lucas wrote:
>>  * ifup - copy configuration file from /etc/network/$int/$file to 
>> /run/network/$int/$file upon successful initialization of the interface.
> 
> I believe /var/run is a more suitable place for this.
> http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA

/var/run is a symlink to /run.  If you follow the discussion on the fhs 
mailing list, this is almost certain to occur.  Expect an update to the 
fhs in the next six months.

>>  * ifdown - source configuration files from /run/network/$int/*.
>>  * ifdown - if interface configuration files do not exist, ip addr 
>> flush $int, ip link set $int down, exit 0.
> 
> There might be situations where manual modification of an existing
> interface was done leaving ip addr flush still a needed option even with
> a state file. I imagine this as generally a corner case, but I'm putting
> it out there in case it is considered a legitimate concern. I saw you
> mention ppp  and pppoe is still a valid use for it. I'm not
> sure how involved the scripts should get. Is grepping for a running dhcp
> client on that interface too far?
> 
>>  * Add a copy of the MIT license file to bootscripts.

Unnecessary.  The book copyright already covers it.

> Why MIT? These aren't book instructions.

They are published in the appendices.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Bruce Dubbs]

Jeremy Huntwork wrote:
> On May 10, 2011, at 3:26 PM, Matthew Burgess
>  wrote:
>> I don't mind changing the version numbering to whatever suits
>> people best, but I'm just interested as to why this is an issue?
>> If I had to pick any numbering scheme at all, I'd choose something
>> simple like Udev's;
> 
> I wouldn't say it's an issue, just a preference. A date seems less
> definite than an actual release number. Something like udevs
> versioning is fine with me.

A date gives the user additional information.  How long since the last 
change?  Do I really need to update?  Using mmdd gives a 
monotonically increasing number and an idea of how long it has been 
since changes were made.  That is my preference.

   -- Bruce

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Nathan Coulson]

On Tue, May 10, 2011 at 1:09 PM, Archaic wrote:

> On Tue, May 10, 2011 at 11:56:23AM -0400, Jeremy Huntwork wrote:
> >
> > http://www.linuxfromscratch.org/lfs/view/development/append
>
>>
>>
>> --
>> http://linuxfromscratch.org/mailman/listinfo/lfs-dev
>> FAQ: http://www.linuxfromscratch.org/faq/
>> Unsubscribe: See the above information page
>>
> ices/mit.html
> >
> > This license is fine with me.
>
> I have no objections, either. Just wondering why.
>
> --
> Archaic
>

never did give much thought into how the boot scripts were licensed myself,
no objections.

-- 
Nathan Coulson (conathan)
--
Location: British Columbia, Canada
Timezone: PST (-8)
Webpage: http://www.nathancoulson.com
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On May 10, 2011, at 3:26 PM, Matthew Burgess  
wrote:
>>> 
>> 
> I don't mind changing the version numbering to whatever suits people best,
> but I'm just interested as to why this is an issue?  If I had to pick any
> numbering scheme at all, I'd choose something simple like Udev's;

I wouldn't say it's an issue, just a preference. A date seems less definite 
than an actual release number. Something like udevs versioning is fine with me.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Archaic]

On Tue, May 10, 2011 at 11:56:23AM -0400, Jeremy Huntwork wrote:
> 
> http://www.linuxfromscratch.org/lfs/view/development/appendices/mit.html
> 
> This license is fine with me.

I have no objections, either. Just wondering why.

-- 
Archaic

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Matthew Burgess]

On Tue, 10 May 2011 10:47:34 -0500, DJ Lucas  wrote:
> Jeremy Huntwork  wrote:
>>
>>Can we do something more explicit about versioning?
> 
> Need Bruce or Matt to chime in here, but I don't see that it's a big deal
> to something about a more common versioning scheme.

I don't mind changing the version numbering to whatever suits people best,
but I'm just interested as to why this is an issue?  If I had to pick any
numbering scheme at all, I'd choose something simple like Udev's; just a
plain incrementing integer.

Thanks,

Matt.

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/10/11 11:13 AM, DJ Lucas wrote:
>> Why MIT? These aren't book instructions.
>
> Hmm, to change licenses, or rather define one outside the scope of the book, 
> we'd need approval from all contributors. That is currently AFAIK Alexander, 
> Archaic, Bruce, Dan, Jeremy, Matt, Michael Tremmor (IPFire), Nathan, and 
> Myself. What license you have in mind?

http://www.linuxfromscratch.org/lfs/view/development/appendices/mit.html

This license is fine with me.

Thanks,

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Archaic]

On Tue, May 10, 2011 at 10:13:57AM -0500, DJ Lucas wrote:
> 
> /var/run will be /run in FHS 3.0, LFS has already moved to the new
> layout, but I'd imagine that the compatibility symlink will be
> required for at least 3 years of not longer, so we could use /var/run
> to be compatible for a while...just trying to future proof and reduce
> cruft as much as possible.

In the LFS world, compatibility has been less of an issue due to the
nature of configuring/compiling everything. We could move lightcube
there. I was hoping to delay that, though, because of other things in
the lightcube tasklist having higher priority, but I understand about
future proofing, so perhaps the scripts defaulting to /run where a
/var/run symlink is known to still work with the scripts would be the
best compromise?
> 
> Hmm, to change licenses, or rather define one outside the scope of the
> book, we'd need approval from all contributors. That is currently
> AFAIK Alexander, Archaic, Bruce, Dan, Jeremy, Matt, Michael Tremmor
> (IPFire), Nathan, and Myself. What license you have in mind?

Actually, I was referring to what Bruce said:

http://www.linuxfromscratch.org/pipermail/lfs-dev/2011-May/064678.html


-- 
Archaic

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[DJ Lucas]

Jeremy Huntwork  wrote:

>On 5/10/11 8:25 AM, DJ Lucas wrote:
>>   * Most important, pull as much as possible of the items below
>from
>> LightCube OS's files to ease merging and keep the diffs to a minimum
>so
>> that they are easily shared across distributions.
>>   * Move ifup and ifdown scripts to /sbin.
>>   * Move network service scripts to /lib/services (there was one
>> minor objection here, should that be /lib/network-services or
>> /lib/network? I don't really have any preference here, /lib/services
>is
>> fine by me).
>>   * Move network configuration files to /etc/network.
>>   * Move network (hostname value) and clock config into
>> /etc/default/rc.site (default to UTC?)
>>   * Use /etc/default for rc configuration files (remaining items
>in
>> /etc/sysconfig currently).
>
>All fine from my perspective. :)
>
>>   * Add initd-tools to book - This is required for the new
>scripts.
>> Jeremy what is the status on this in LightCube OS? I remember a few
>> months ago about you possibly taking over maintenance of them, adding
>a
>> service binary/script and such? At last check, Dan did not have them
>in
>> an RCS, which is not an issue for now, just curious about the future
>of
>> the tools. The tarball and homepage are available in Dan's home
>> directory on freedesktop.org if we need for the book. Dan?
>
>I never got around to adding these into a repository, but I could do
>so. 
>I'd be happy to maintain them. I'll need to schedule some time to get 
>the infrastructure together for them and then post links.
>
>>   * The three items above are the best I think we can do with it
>and
>> should cover>  99% of all cases, the known exceptions being starting
>the
>> dhcp client or ppp client manually, and possibly manual configuration
>of
>> wireless interfaces (I've never configured wireless in LFS - also
>what
>> about VPN tools started manually?). I believe Bryan is already on
>board
>> with these changes, Bruce, Jeremy, Zach?
>
>LightCube OS is meant to be used as X-less servers, mostly web 
>application servers. As such, dhcp is the edge scenario for us and
>we'll 
>almost certainly never need wireless, and unlikely that we'd need ppp
>or 
>other sorts of clients. So from our perspective, we're good with static
>
>and dhcp.

Hmm, need to look at it a bit more thoroughly then. Archaic had the same 
concern. His suggestion for greping "dhcp" might be able to be extended or done 
locally in LightCube OS, IPFire, IPCop?, others?, for supported types...but im 
having second thoughts now. It really would be best to get it into main repo if 
this concern is shared across the boards.

>
>> Hope I didn't miss anything, but I've got to go.
>
>Can we do something more explicit about versioning?

Need Bruce or Matt to chime in here, but I don't see that it's a big deal to 
something about a more common versioning scheme.

-- DJ


-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
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

Re: Using the LSB Bootscripts

[DJ Lucas]

Archaic  wrote:

>On Tue, May 10, 2011 at 07:25:50AM -0500, DJ Lucas wrote:
>> 
>>  * ifup - copy configuration file from /etc/network/$int/$file to
>
>> /run/network/$int/$file upon successful initialization of the
>interface.
>
>I believe /var/run is a more suitable place for this.
>http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA

/var/run will be /run in FHS 3.0, LFS has already moved to the new layout, but 
I'd imagine that the compatibility symlink will be required for at least 3 
years of not longer, so we could use /var/run to be compatible for a 
while...just trying to future proof and reduce cruft as much as possible.

We'll also need to account for this with my suggestion of mounting /run 
directly in rc (boot logging requires a tmpfs currently).
>
>>  * ifdown - source configuration files from /run/network/$int/*.
>>  * ifdown - if interface configuration files do not exist, ip
>addr 
>> flush $int, ip link set $int down, exit 0.
>
>There might be situations where manual modification of an existing
>interface was done leaving ip addr flush still a needed option even
>with
>a state file. I imagine this as generally a corner case, but I'm
>putting
>it out there in case it is considered a legitimate concern. I saw you
>mention ppp  and pppoe is still a valid use for it. I'm not
>sure how involved the scripts should get. Is grepping for a running
>dhcp
>client on that interface too far?

Possibly. If it was initialized outside of the standard method would be the 
arguement.

>
>>  * Add a copy of the MIT license file to bootscripts.
>
>Why MIT? These aren't book instructions.

Hmm, to change licenses, or rather define one outside the scope of the book, 
we'd need approval from all contributors. That is currently AFAIK Alexander, 
Archaic, Bruce, Dan, Jeremy, Matt, Michael Tremmor (IPFire), Nathan, and 
Myself. What license you have in mind?

>
>>  * Remove selective boot - personally I'd rather keep that in
>place 
>> simply because it was requested so many times in the past, but
>possibly 
>> disable the functionality by default?
>
>Disabled by default sound like a good compromise.

-- DJ


-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
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

Re: Using the LSB Bootscripts

[Zachary Kotlarek]

On May 10, 2011, at 7:25 AM, DJ Lucas wrote:

> * The three items above are the best I think we can do with it and 
> should cover > 99% of all cases, the known exceptions being starting the 
> dhcp client or ppp client manually, and possibly manual configuration of 
> wireless interfaces (I've never configured wireless in LFS - also what 
> about VPN tools started manually?). I believe Bryan is already on board 
> with these changes, Bruce, Jeremy, Zach?



It sounds like a good plan to me.

The one change I'd suggest is to put the transient files (the copied config 
files) into /var (or even someplace in /tmp) though, and not in /etc. Otherwise 
/etc must be writable for the network scripts to work as expected, and 
boot-time cleanup will need to clear files from /etc, both of which seem 
undesirable to me.

As for the less-common cases:

General manual configuration: If the ifup/ifdown system is only going to 
support a single address per family per named interface, it should be safe to 
always `ip -4/-6 addr flush` in the down script, rather than manually removing 
individual addresses. This will ensure things are in a known state when/if you 
go back up, even if there were changes outside the on-disk configuration. The 
downside is you can't manually add a temporary address without having the 
ifdown script destroy your changes. I don't know which behavior is desired.

Manual DHCP: You could call the DHCP-down behavior in all ifdown calls and just 
ignore the result if DHCP wasn't configured. I can't think of a case where it 
would be inappropriate to stop DHCP on an interface that's going down, 
regardless of the on-disk or manual configuration.

VPNs: I wouldn't try to handle them. IPSec doesn't necessarily fit into the 
"kernel network interface" model that ifup/ifdown are built around and 
commercial VPN clients muck with far to many things to handle in a generic 
network script. There might be some subset that can be handled but I don't 
think there's a general solution.

WiFi: Should fit the model, if someone writes a service script for it. There's 
some work around how to manage SSID switches and the like, but that's outside 
the scope of this system -- at some point there's still going to be an 
ifdown-reconfigure-ifup set of calls.

PPPoE: So long as the scripts are call with the Ethernet interface name and not 
the PPP interface name it should fit into this model. And that seems reasonable 
to me, even if you're moving a single Ethernet port between PPPoE and normal 
networks.

Raw PPP: Has it's own up/down scripts and people using raw PPP are probably 
expecting to use those anyway.

Zach



smime.p7s
Description: S/MIME cryptographic signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Archaic]

On Tue, May 10, 2011 at 07:25:50AM -0500, DJ Lucas wrote:
> 
>  * ifup - copy configuration file from /etc/network/$int/$file to 
> /run/network/$int/$file upon successful initialization of the interface.

I believe /var/run is a more suitable place for this.
http://www.pathname.com/fhs/pub/fhs-2.3.html#VARRUNRUNTIMEVARIABLEDATA

>  * ifdown - source configuration files from /run/network/$int/*.
>  * ifdown - if interface configuration files do not exist, ip addr 
> flush $int, ip link set $int down, exit 0.

There might be situations where manual modification of an existing
interface was done leaving ip addr flush still a needed option even with
a state file. I imagine this as generally a corner case, but I'm putting
it out there in case it is considered a legitimate concern. I saw you
mention ppp  and pppoe is still a valid use for it. I'm not
sure how involved the scripts should get. Is grepping for a running dhcp
client on that interface too far?

>  * Add a copy of the MIT license file to bootscripts.

Why MIT? These aren't book instructions.

>  * Remove selective boot - personally I'd rather keep that in place 
> simply because it was requested so many times in the past, but possibly 
> disable the functionality by default?

Disabled by default sound like a good compromise.

-- 
Archaic

-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/9/11 11:36 PM, Bryan Kadzban wrote:
> Right, but the former /etc/sysconfig/network* was also default
> configuration for how the bootscripts run.  Well, the network script
> anyway.  :-)

Just ifup/ifdown (which are now in /sbin) and network-services/* which 
is now in /lib/{network-}services - maybe I'm missing something?

> So networking goes down before the per-client sshd processes, and the
> kernel isn't smart enough to kill those connections at interface-down
> time.  :-(

Well, that's actually a feature and not a bug. If your connection gets 
interrupted temporarily by forces outside your control, you want the 
session to be restored without interrupt.

> In that case, this should work.  Maybe with a comment explaining why
> it's necessary though.

Yeah, I should have pasted the two comments that Fedora has in their 
scripts, too:

 # if we are in halt or reboot runlevel kill all running sessions
 # so the TCP connections are closed cleanly


Thanks,

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/10/11 8:25 AM, DJ Lucas wrote:
>   * Move network service scripts to /lib/services (there was one
> minor objection here, should that be /lib/network-services or
> /lib/network? I don't really have any preference here, /lib/services is
> fine by me).

Forgot to mention that I vote for /lib/network-services. Longer, but 
it's nice that it's explicit.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/10/11 8:25 AM, DJ Lucas wrote:
>   * Most important, pull as much as possible of the items below from
> LightCube OS's files to ease merging and keep the diffs to a minimum so
> that they are easily shared across distributions.
>   * Move ifup and ifdown scripts to /sbin.
>   * Move network service scripts to /lib/services (there was one
> minor objection here, should that be /lib/network-services or
> /lib/network? I don't really have any preference here, /lib/services is
> fine by me).
>   * Move network configuration files to /etc/network.
>   * Move network (hostname value) and clock config into
> /etc/default/rc.site (default to UTC?)
>   * Use /etc/default for rc configuration files (remaining items in
> /etc/sysconfig currently).

All fine from my perspective. :)

>   * Add initd-tools to book - This is required for the new scripts.
> Jeremy what is the status on this in LightCube OS? I remember a few
> months ago about you possibly taking over maintenance of them, adding a
> service binary/script and such? At last check, Dan did not have them in
> an RCS, which is not an issue for now, just curious about the future of
> the tools. The tarball and homepage are available in Dan's home
> directory on freedesktop.org if we need for the book. Dan?

I never got around to adding these into a repository, but I could do so. 
I'd be happy to maintain them. I'll need to schedule some time to get 
the infrastructure together for them and then post links.

>   * The three items above are the best I think we can do with it and
> should cover>  99% of all cases, the known exceptions being starting the
> dhcp client or ppp client manually, and possibly manual configuration of
> wireless interfaces (I've never configured wireless in LFS - also what
> about VPN tools started manually?). I believe Bryan is already on board
> with these changes, Bruce, Jeremy, Zach?

LightCube OS is meant to be used as X-less servers, mostly web 
application servers. As such, dhcp is the edge scenario for us and we'll 
almost certainly never need wireless, and unlikely that we'd need ppp or 
other sorts of clients. So from our perspective, we're good with static 
and dhcp.

> Hope I didn't miss anything, but I've got to go.

Can we do something more explicit about versioning?

Thanks,

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[DJ Lucas]

On 05/10/2011 07:25 AM, DJ Lucas wrote:
> I'm just about done with the DESTDIR POC (still need to add instructions
> to account for lib64 ->  lib since I did this on multilib first) but that
> can use some time to mature a bit anyway, so should have time on Wed if
> one of y'all don't get there first.
>
> The current task list is as follows (for which I believe we have
> consensus from those who have chimed in so far):
>
>
>   * Use /etc/default for rc configuration files (remaining
Oops...that should be in the bottom list. Sorry Bryan.

-- 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

Re: Using the LSB Bootscripts

[DJ Lucas]

On 05/09/2011 10:33 PM, Bryan Kadzban wrote:
> DJ Lucas wrote:
>>
>> You know what? I think we are over thinking this. How about a state
>> file? Upon successful initialization of an interface, copy the config
>> file to a subdir of /run/network. The ifdown script sources the
>> running copy if it exists and removes it on successful stop of the
>> interface, or ip down interface if it does not exist and exits 0.
> Ooo, I like that idea.  :-)
>
> Now, to get time to hack it together...  :-(
>
I'm just about done with the DESTDIR POC (still need to add instructions 
to account for lib64 -> lib since I did this on multilib first) but that 
can use some time to mature a bit anyway, so should have time on Wed if 
one of y'all don't get there first.

The current task list is as follows (for which I believe we have 
consensus from those who have chimed in so far):

 * Most important, pull as much as possible of the items below from 
LightCube OS's files to ease merging and keep the diffs to a minimum so 
that they are easily shared across distributions.
 * Move ifup and ifdown scripts to /sbin.
 * Move network service scripts to /lib/services (there was one 
minor objection here, should that be /lib/network-services or 
/lib/network? I don't really have any preference here, /lib/services is 
fine by me).
 * Move network configuration files to /etc/network.
 * Move network (hostname value) and clock config into 
/etc/default/rc.site (default to UTC?)
 * Use /etc/default for rc configuration files (remaining items in 
/etc/sysconfig currently).


And here is a summary of remaining items that have not come to consensus 
or haven't been brought up previously in this thread:

 * Add initd-tools to book - This is required for the new scripts. 
Jeremy what is the status on this in LightCube OS? I remember a few 
months ago about you possibly taking over maintenance of them, adding a 
service binary/script and such? At last check, Dan did not have them in 
an RCS, which is not an issue for now, just curious about the future of 
the tools. The tarball and homepage are available in Dan's home 
directory on freedesktop.org if we need for the book. Dan?
 * Add configurable function to handle script errors in place of 
'read Enter'. Of course, the option exists to kill that completely, but 
it puts the error in plain sight for desktop users.
 * ifup - copy configuration file from /etc/network/$int/$file to 
/run/network/$int/$file upon successful initialization of the interface.
 * ifdown - source configuration files from /run/network/$int/*.
 * ifdown - if interface configuration files do not exist, ip addr 
flush $int, ip link set $int down, exit 0.
 * The three items above are the best I think we can do with it and 
should cover > 99% of all cases, the known exceptions being starting the 
dhcp client or ppp client manually, and possibly manual configuration of 
wireless interfaces (I've never configured wireless in LFS - also what 
about VPN tools started manually?). I believe Bryan is already on board 
with these changes, Bruce, Jeremy, Zach?
 * svn mv BOOK/bootscripts/contrib/lsb-v3 BOOK/LSB-Bootscripts.
 * merge necessary changelog entries and readme from original 
bootscripts with LSB-Bootscripts.
 * Add a copy of the MIT license file to bootscripts.
 * Add needed changes to book rendering for new bootscripts (I have 
this done locally).
 * I just noticed, need to fix setclock UTC logic to use case as in 
all others for 0|y*|Y*|t*|T*,1|n*|N*|f*|F*,* exit 2 (invalid argument).
 * Remove selective boot - personally I'd rather keep that in place 
simply because it was requested so many times in the past, but possibly 
disable the functionality by default?
 * Do something with the tmpfs used for the boot log...in fact, we 
could probably setup the /run mount point directly in the rc script and 
remove it from mountvirtfs.

Hope I didn't miss anything, but I've got to go.

-- 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

Re: Using the LSB Bootscripts

[Bryan Kadzban]

Jeremy Huntwork wrote:
> On 5/9/11 1:57 AM, Bryan Kadzban wrote:
>> Right, but you have no way to know (in the static config, or the
>> DHCP config, for instance) whether a pppd was running and needs to
>> be killed, or whether DNS needs to be unregistered (unlikely, but
>> not impossible), or whether a wireless card needs to be
>> disassociated.
> 
> There has to be ways to check in the running system how a device is 
> configured if it's active.

Yeah, but a single "everything goes down this way" script would need to
know about all the possibilities.

(But see DJ's recent mail.)

>> I can see that logic, I suppose.  But bootscript config (which is
>> what both /etc/sysconfig/rtc and friends, and
>> /etc/sysconfig/network*, are today) seems different enough from
>> systemwide defaults for new users, to warrant a different
>> directory.  Maybe the useradd defaults file should have been stuck
>> somewhere near /etc/skel or something.  But at least in my mind,
>> separating the two makes sense.
>> 
>> (Then again, my mind is a scary place.  :-P)
> 
> The /etc/sysconfig/network* have already been moved to /etc/network.
> What is now /etc/default/rc as per the changes is really just
> default configurations for how the bootscripts run.

Right, but the former /etc/sysconfig/network* was also default
configuration for how the bootscripts run.  Well, the network script
anyway.  :-)

>> What happens if the machine shuts down with ssh sessions active,
>> without this?  Do they just hang and eventually time out?  Or do
>> they die when the NIC gets taken down?  (...Is the kernel that
>> smart?)  Or does something log all users out earlier?  (What about
>> killall5, run from sendsignals?  That might be too late though?)
> 
> Without this, the terminal hangs until the timeout is reached and
> then the session closes and the terminal becomes active on the
> localhost again.

So networking goes down before the per-client sshd processes, and the
kernel isn't smart enough to kill those connections at interface-down
time.  :-(

In that case, this should work.  Maybe with a comment explaining why
it's necessary though.



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Bryan Kadzban]

DJ Lucas wrote:
> Jeremy Huntwork  wrote:
>> On 5/9/11 2:53 AM, DJ Lucas wrote:
>>> The simple solution is to stop networking before applying
>>> changes.
>> When
>> 
>> Yes, I know. :) But in practice that becomes an annoyance. Admins
>> used to working Fedora/Debian/Ubuntu or others assume that changing
>> the config and running 'service network restart' is sufficient.
>> 
> 
> You know what? I think we are over thinking this. How about a state
> file? Upon successful initialization of an interface, copy the config
> file to a subdir of /run/network. The ifdown script sources the
> running copy if it exists and removes it on successful stop of the
> interface, or ip down interface if it does not exist and exits 0.

Ooo, I like that idea.  :-)

Now, to get time to hack it together...  :-(



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[DJ Lucas]

Jeremy Huntwork  wrote:

>On 5/9/11 2:53 AM, DJ Lucas wrote:
>> The simple solution is to stop networking before applying changes.
>When
>
>Yes, I know. :) But in practice that becomes an annoyance. Admins used 
>to working Fedora/Debian/Ubuntu or others assume that changing the 
>config and running 'service network restart' is sufficient.
>

You know what? I think we are over thinking this. How about a state file? Upon 
successful initialization of an interface, copy the config file to a subdir of 
/run/network. The ifdown script sources the running copy if it exists and 
removes it on successful stop of the interface, or ip down interface if it does 
not exist and exits 0.



-- DJ

Sent from my Android phone with K-9 Mail. Please excuse my brevity.

-- 
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

Re: Using the LSB Bootscripts

[Bruce Dubbs]

Jeremy Huntwork wrote:

> Just as an FYI, the plans for most of these changes come from myself and 
> Archaic who has been assisting with LightCube. The proposed 
> /etc/default/rc.local file was a last minute addition by myself, but 
> after this discussion, and some more with Archaic, I think perhaps that 
> name is wrong (I forgot about the rc.local bootscript!) and perhaps it 
> should be /etc/default/rc.site.

How about /etc/default/misc.conf?

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/9/11 2:53 AM, DJ Lucas wrote:
> The simple solution is to stop networking before applying changes. When

Yes, I know. :) But in practice that becomes an annoyance. Admins used 
to working Fedora/Debian/Ubuntu or others assume that changing the 
config and running 'service network restart' is sufficient.

> service. IPCop has a nice console configuration tool that you might be
> able to look at for this if one is not already in place (sorry, I
> haven't had the time to give LightCube a spin yet). Perhaps Giles could
> chime in here if needed.

LightCube is mostly manually configured at the moment, I haven't had a 
chance to look at IPCop yet either, perhaps soon.

> Also, it looks like Bryan crossed my message while i was writing further
> in the BLFS case. Again, in LightCube OS, you have less variations and
> can conceivably account for them all (or provide a tool to do the job
> correctly).

That is true and we're prepared to fork the code as necessary, but I 
feel like there's a solution hiding here somehwere.

> Maybe add an additional function to make the behavior configurable and
> call that function? It'd make the scripts a tiny bit cleaner as well.

Hmm, that's a thought.

>> * In the ipv4-static service, instead of attempting to remove the IP set
>> in the configuration file, just flush all addresses with 'ip addr flush
>> [dev]'
> I think that it would work as written in your setup, but just in case
> you didn't check, what happens in the event of eth0-1? Again, however,
> BLFS target makes this not easily maintained.

I haven't tried virtual interfaces yet. That's something I should try 
next, thanks for bringing that up.

> Less files to worry about, single source I trust, but it is also less
> specific as to what those files are used for. I'm guessing that rc.local
> is what was rc.site (which might have been completely removed since the
> selective booting has been removed). Really they should just be moved to
> the rc.site file if LFS keeps the existing layout. I'm not particularly
> partial to the /etc/sysconfig hierarchy, only, as mentioned above, that
> it makes it compatible with instructions currently in the book.

Yeah rc.site is better, see my other reply to Bryan.

> Well, I wouldn't jump to that conclusion just yet about merging
> "upstream", but obviously if they diverge too far (as is the case
> currently) it would be a maintenance nightmare, besides, you would need
> to have them in a local repo anyway and LFS is still using Subversion.
> Git would make maintenance merges between the two much easier, but that
> really isn't your responsibility unless you choose to make it so, which
> is currently a manual effort.

Well let's see what happens. It would be nice to find a solution that 
works for both.

Thanks,

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/9/11 1:57 AM, Bryan Kadzban wrote:
> I believe the book has static IP addressing, and DHCP.  There's also
> both PPP (for both dial-up modems and cell-phone-network access) and
> PPPoE, and I've added WoL to this system, as noted above.  (Obviously
> that only works for wired network cards though.  Not modems or wireless
> or whatever.)
>
> Wireless I have no idea how to set up using this system, although I was
> going to do it at one point.  wpa_supplicant is complicated.  :-)

Nor I. Perhaps then abstract the actual down commands (most boil down to 
one line) into something universal and run tests to see which need to be 
run for that interface, i.e., which is it currently using?

> Right, but you have no way to know (in the static config, or the DHCP
> config, for instance) whether a pppd was running and needs to be killed,
> or whether DNS needs to be unregistered (unlikely, but not impossible),
> or whether a wireless card needs to be disassociated.

There has to be ways to check in the running system how a device is 
configured if it's active.

> I can see that logic, I suppose.  But bootscript config (which is what
> both /etc/sysconfig/rtc and friends, and /etc/sysconfig/network*, are
> today) seems different enough from systemwide defaults for new users, to
> warrant a different directory.  Maybe the useradd defaults file should
> have been stuck somewhere near /etc/skel or something.  But at least in
> my mind, separating the two makes sense.
>
> (Then again, my mind is a scary place.  :-P)

The /etc/sysconfig/network* have already been moved to /etc/network. 
What is now /etc/default/rc as per the changes is really just default 
configurations for how the bootscripts run.

Just as an FYI, the plans for most of these changes come from myself and 
Archaic who has been assisting with LightCube. The proposed 
/etc/default/rc.local file was a last minute addition by myself, but 
after this discussion, and some more with Archaic, I think perhaps that 
name is wrong (I forgot about the rc.local bootscript!) and perhaps it 
should be /etc/default/rc.site.

> Ah, I see what was done: they test $runlevel, then kill all sshd's in
> the case of a reboot or halt.  (This includes killing the script that's
> running, but the do-nothing trap installed before the killall and
> removed after it, stops it from failing.)
>
> What happens if the machine shuts down with ssh sessions active, without
> this?  Do they just hang and eventually time out?  Or do they die when
> the NIC gets taken down?  (...Is the kernel that smart?)  Or does
> something log all users out earlier?  (What about killall5, run from
> sendsignals?  That might be too late though?)

Without this, the terminal hangs until the timeout is reached and then 
the session closes and the terminal becomes active on the localhost again.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[DJ Lucas]

On 05/08/2011 06:25 PM, Jeremy Huntwork wrote:
> Hello,
>
> So we've been using the LSB bootscripts for some time now on LightCube
> OS, with very little modification (we added dhclient service and the
> random bootscript to the default install), and it's behaved wonderfully.
>
> There have been a few things that we noticed that we felt needed to
> change, namely:
>
> * ifdown uses the configured service script to remove addresses from the
> interface. This becomes a problem when a user changes the configuration
> before running the script to restart networking.

The simple solution is to stop networking before applying changes. When 
performing manual configuration, I would have thought this obvious, but 
I've been using LFS for a very long time and this might not be the case 
for users of other distros. I don't know how you have LightCube's UI 
doing the changes, but rather than apply changes and then restarting, 
the logical order is to write a temp file, stop the interface, replace 
the interface configuration file with the temp file, and then start the 
service. IPCop has a nice console configuration tool that you might be 
able to look at for this if one is not already in place (sorry, I 
haven't had the time to give LightCube a spin yet). Perhaps Giles could 
chime in here if needed.

That doesn't mean that there isn't room for improvement, just never 
really thought much about it as I thought above was the obvious method. 
There was one caveat with one of the dhcp clients (I believe it was 
dhclient, but I'm not absolutely positive on that), in that if the 
daemon receives SIGTERM, all interfaces using that dhcp client were 
dropped. There is some logic to that effect in the current service 
scripts. Sorry, fuzzy memory, but I'll try and look at it on Wed night.

Also, it looks like Bryan crossed my message while i was writing further 
down, but I agree with him on this. It would be impossible to catch all 
variations in the BLFS configuration, whereas in LightCube OS, you have 
a well defined group of programs that will be used, and a well defined 
target audience. Anything non-standard falls to the user. While it is 
the same is true in BLFS, we have to pretty much expect to see 
"non-standard" configurations, and catering to only a few will 
undoubtedly lead to some corner case where the added functionality has 
to be disabled. Given the above, I think that the need to stop the 
interface before any reconfiguration is not an unrealistic expectation 
in the BLFS case. Again, in LightCube OS, you have less variations and 
can conceivably account for them all (or provide a tool to do the job 
correctly).
> Two possible scenarios here. One, the static service tries to remove the
> configured IP address from the device (which has changed and will thus
> fail) and adds the new IP. The result is two static IP addresses on the
> device. The second scenario is if you change the service, say from dhcp
> to static. The static will not kill the dhcp client when it restarts,
> and you could have two addresses again. Similarly, the dhcp client will
> not remove static addresses already assigned to the device before
> launching itself.

> * When using in production systems, the heavy use of 'read Enter' on
> script errors, especially in generic cases, make it difficult to manage
> remote machines that have encountered an error on boot or halt/reboot.

Maybe add an additional function to make the behavior configurable and 
call that function? It'd make the scripts a tiny bit cleaner as well.
> * The sshd script (from BLFS) when halting doesn't kill user sshd
> sessions. It just stops the daemon. This results in frozen terminals
> until the session times out.
> * The organization of files feels like it could be improved and made
> easier. For example, the ifdown and ifup scripts seem better placed in
> /sbin.
>
That I like, probably should have been done a long time ago.
> All of the above has led me to modify the scripts for LightCube's use
> and make the following changes:
>
> * Add a param to release any dhclient addresses from a device if it is
> running in the ipv4-static service
We'd need to extend this far too much in BLFS (See Bryan's message)
> * In the ipv4-static service, instead of attempting to remove the IP set
> in the configuration file, just flush all addresses with 'ip addr flush
> [dev]'
I think that it would work as written in your setup, but just in case 
you didn't check, what happens in the event of eth0-1? Again, however, 
BLFS target makes this not easily maintained.
> * In the dhclient service, flush any static addresses as well.
Same issues as above for BLFS's target.
> * Move ifdown and ifup to /sbin
Absolutely.
> * Move the equivalent of /etc/sy

Re: Using the LSB Bootscripts

[Bryan Kadzban]

Jeremy Huntwork wrote:
> On 5/8/11 8:46 PM, Bryan Kadzban wrote:
>> I don't think there's any way to make all potential service scripts
>> able to handle switching to and from all the other potential
>> service scripts, just by starting them.  I don't think that means
>> it's not worth trying to do this, but we do have to be careful not
>> to imply that this sort of thing will always work.
> 
> Well, how many services will there ever be that operate on the same 
> device?

I believe the book has static IP addressing, and DHCP.  There's also
both PPP (for both dial-up modems and cell-phone-network access) and
PPPoE, and I've added WoL to this system, as noted above.  (Obviously
that only works for wired network cards though.  Not modems or wireless
or whatever.)

Wireless I have no idea how to set up using this system, although I was
going to do it at one point.  wpa_supplicant is complicated.  :-)

> If there's much more than what I'm thinking, perhaps you're right and
> it is complicated. In which case I think the underlying methodology
> for bringing up the device needs to be adjusted somehow. Bringing up
> the device by configuration is fine - that's how it should be. When
> taking it down, however, you need to remove any possible configured
> service on it.

Right, but you have no way to know (in the static config, or the DHCP
config, for instance) whether a pppd was running and needs to be killed,
or whether DNS needs to be unregistered (unlikely, but not impossible),
or whether a wireless card needs to be disassociated.

I think it makes sense to require that if an interface needs to have its
method(s) switched, then it needs to be ifdown'ed under the old config,
and ifup'ed under the new config.  That way they can all clean up after
themselves, because they all know what needs to be undone for proper
cleanup.

(Unless I'm missing something here.  :-) )

>> I don't like it (not yet anyway :-) ).  I find "sysconfig" to be a
>> *far* more descriptive name than "default".
>> 
>> (Also I associate "default" with Ubuntu, which does not bring up
>> happy thoughts.  The reasons are not exactly important, and this is
>> obviously a personal-opinion thing.  And I now know it's at least a
>> Debian thing, and might be more widespread.  But the first
>> impression still exists.)
> 
> The reason default was chosen was in order to merge other system-wide
> configuration files, such as /etc/default/useradd, for example.
> Either name works for me, really, but the idea was to consolidate.

I can see that logic, I suppose.  But bootscript config (which is what
both /etc/sysconfig/rtc and friends, and /etc/sysconfig/network*, are
today) seems different enough from systemwide defaults for new users, to
warrant a different directory.  Maybe the useradd defaults file should
have been stuck somewhere near /etc/skel or something.  But at least in
my mind, separating the two makes sense.

(Then again, my mind is a scary place.  :-P)

>> It may be possible to do as you describe, but I'm not sure how; I'd
>> like to see how it was done.  :-)
> 
> I'll get the scripts up as soon as I can.

Ah, I see what was done: they test $runlevel, then kill all sshd's in
the case of a reboot or halt.  (This includes killing the script that's
running, but the do-nothing trap installed before the killall and
removed after it, stops it from failing.)

What happens if the machine shuts down with ssh sessions active, without
this?  Do they just hang and eventually time out?  Or do they die when
the NIC gets taken down?  (...Is the kernel that smart?)  Or does
something log all users out earlier?  (What about killall5, run from
sendsignals?  That might be too late though?)

Not sure if I think it's worth this complication, but it depends on the
downside.



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/8/11 8:57 PM, Jeremy Huntwork wrote:
> I'll get the scripts up as soon as I can. I had to take a break to
> finish up some other important work tonight. At the latest, I'll have
> them available tomorrow.

Here's the main scripts as they currently are (unreleased as yet):
http://dev.lightcube.us/sources/lsb-bootscripts/lsb-bootscripts-test.tar.bz2

And here's the sshd script, which is kept with the openssh sources:
http://dev.lightcube.us/sources/openssh/sshd.init

I forgot to mention that I removed DJ's interactive boot stuff, just to 
keep it simpler. It could certainly be added back in, if anyone wants it.

--
JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Zachary Kotlarek]

On May 8, 2011, at 7:46 PM, Bryan Kadzban wrote:
> I do think putting the service scripts under a subdirectory /lib is
> good, but maybe /lib/network-services or something (to be more explicit)
> would be better than plain "services".


As long as the scripts are 100% parameterized so that any "normal/supported" 
configuration can be done without modifying the scripts themselves, 
/lib/network(-services) sounds good to me. I'd like to avoid putting any actual 
configuration data outside of /etc though -- I'm both a curmudgeon and someone 
who leaves /lib mounted read-only.

Zach



smime.p7s
Description: S/MIME cryptographic signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/8/11 8:46 PM, Bryan Kadzban wrote:
> This seems like it might be starting to get complicated.  The scripts
> may set up more than just IP addresses.  (I have one to set up WoL bits
> via ethtool, for instance.)
>
> I don't think there's any way to make all potential service scripts able
> to handle switching to and from all the other potential service scripts,
> just by starting them.  I don't think that means it's not worth trying
> to do this, but we do have to be careful not to imply that this sort of
> thing will always work.

Well, how many services will there ever be that operate on the same 
device? If there's much more than what I'm thinking, perhaps you're 
right and it is complicated. In which case I think the underlying 
methodology for bringing up the device needs to be adjusted somehow. 
Bringing up the device by configuration is fine - that's how it should 
be. When taking it down, however, you need to remove any possible 
configured service on it.

> I do think putting the service scripts under a subdirectory /lib is
> good, but maybe /lib/network-services or something (to be more explicit)
> would be better than plain "services".

Yes, I almost did this. It looked a bit long, but it was explicit. I 
could go either way here.

> I don't like it (not yet anyway :-) ).  I find "sysconfig" to be a *far*
> more descriptive name than "default".
>
> (Also I associate "default" with Ubuntu, which does not bring up happy
> thoughts.  The reasons are not exactly important, and this is obviously
> a personal-opinion thing.  And I now know it's at least a Debian thing,
> and might be more widespread.  But the first impression still exists.)

The reason default was chosen was in order to merge other system-wide 
configuration files, such as /etc/default/useradd, for example. Either 
name works for me, really, but the idea was to consolidate.

> The only times I restart sshd, it happens from an ssh session.  I think
> this needs to continue working.  You said (later on) that this only
> applies to halting the system, but doesn't "reload" just call "stop" and
> then "start", and doesn't system-halt just call "stop"?
>
> It may be possible to do as you describe, but I'm not sure how; I'd like
> to see how it was done.  :-)

I'll get the scripts up as soon as I can. I had to take a break to 
finish up some other important work tonight. At the latest, I'll have 
them available tomorrow.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Bryan Kadzban]

Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
> 
>> * Add a param to release any dhclient addresses from a device if it is 
>> running in the ipv4-static service
> 
> Wouldn't this be a BLFS issue?  It's a good idea, but I don't use dhcp 
> myself.  It makes it hard to ssh into the system.

Unless you have DNS, and your DHCP server is set to update it as well.
And your DHCP server is set to prevent its clients from updating DNS
(since that's unreliable, since they don't always do it).  And all your
DHCP clients are configured to send a name in their request.  ...Hmm.

But anyway, this is off the topic of most of this thread.  :-)

>> * In the ipv4-static service, instead of attempting to remove the IP set 
>> in the configuration file, just flush all addresses with 'ip addr flush 
>> [dev]'
>> * In the dhclient service, flush any static addresses as well.

This seems like it might be starting to get complicated.  The scripts
may set up more than just IP addresses.  (I have one to set up WoL bits
via ethtool, for instance.)

I don't think there's any way to make all potential service scripts able
to handle switching to and from all the other potential service scripts,
just by starting them.  I don't think that means it's not worth trying
to do this, but we do have to be careful not to imply that this sort of
thing will always work.

>> * Move ifdown and ifup to /sbin
> 
> This should have happened long ago.
> 
>> * Move the equivalent of /etc/sysconfig/network-devices/services to 
>> /lib/services
>> * Move the equivalent of /etc/sysconfig/network-devices to /etc/network
> 
> Agree.  I never liked the directory structure for network startup.

I think it's the way it is for historical reasons (we never made more
than the minimal changes required at each point).

I like not changing it, but only because I'm a bit of a curmudgeon, and
have gotten used to the way it is...

I do think putting the service scripts under a subdirectory /lib is
good, but maybe /lib/network-services or something (to be more explicit)
would be better than plain "services".

>> * Move /etc/sysconfig/rc to /etc/default/rc
>> * Move any remaining /etc/sysconfig files (like modules) to /etc/default
>> * Create an /etc/default/rc.local to house configurations like UTC and 
>> HOSTNAME
> 
> I'm not sure about the name rc.local, but I like the general idea.

I don't like it (not yet anyway :-) ).  I find "sysconfig" to be a *far*
more descriptive name than "default".

(Also I associate "default" with Ubuntu, which does not bring up happy
thoughts.  The reasons are not exactly important, and this is obviously
a personal-opinion thing.  And I now know it's at least a Debian thing,
and might be more widespread.  But the first impression still exists.)

"netconfig" (which is what I think it used to be) isn't correct anymore,
either.  But something in that vein would seem better than a generic
"default" that has no more information in its name.  It's *not* for
defaults, it's for configuration.

>> * Add logic from Fedora to kill client sessions to the sshd init script.
> 
> Again, BLFS, but I agree in principle.  OTOH you may want to keep an ssh 
> session active when restarting sshd.  I suppose this could always be 
> done with an ssh session to a non-standard port, but it warrants a bit 
> more discussion.

The only times I restart sshd, it happens from an ssh session.  I think
this needs to continue working.  You said (later on) that this only
applies to halting the system, but doesn't "reload" just call "stop" and
then "start", and doesn't system-halt just call "stop"?

It may be possible to do as you describe, but I'm not sure how; I'd like
to see how it was done.  :-)



signature.asc
Description: OpenPGP digital signature
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Jeremy Huntwork]

On 5/8/11 8:03 PM, Bruce Dubbs wrote:
> Wouldn't this be a BLFS issue?  It's a good idea, but I don't use dhcp
> myself.  It makes it hard to ssh into the system.

:) yep, necessary for a packaged distro though. And invaluable for 
network booting.

> I'm not sure about the name rc.local, but I like the general idea.

Yes, I vacillated on choosing the name, and I'm still not sure it's 
right. It contains things that gets sourced by /etc/default/rc, but 
items that an end user is more likely to modify. Whereas /etc/default/rc 
isn't really expected to be modified and even contains a little logic 
for setting environment variables.

> Again, BLFS, but I agree in principle.  OTOH you may want to keep an ssh
> session active when restarting sshd.  I suppose this could always be
> done with an ssh session to a non-standard port, but it warrants a bit
> more discussion.

Yes, restarting ssh is fine - and for that it's not necessary to kill 
sessions. This only applies to halt.

> The book says:
>
> "Computer instructions may be extracted from the book under the MIT
> License."
>
> As far as I'm concerned the scripts are public domain and don't need a
> license.
>
> Why don't you post your scripts so we can look at them in more detail.

Will do. I've removed most of the attribution headers in the individual 
files, since my intent was to place them in one global location.

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: Using the LSB Bootscripts

[Bruce Dubbs]

Jeremy Huntwork wrote:

> * Add a param to release any dhclient addresses from a device if it is 
> running in the ipv4-static service

Wouldn't this be a BLFS issue?  It's a good idea, but I don't use dhcp 
myself.  It makes it hard to ssh into the system.

> * In the ipv4-static service, instead of attempting to remove the IP set 
> in the configuration file, just flush all addresses with 'ip addr flush 
> [dev]'
> * In the dhclient service, flush any static addresses as well.
> * Move ifdown and ifup to /sbin

This should have happened long ago.

> * Move the equivalent of /etc/sysconfig/network-devices/services to 
> /lib/services
> * Move the equivalent of /etc/sysconfig/network-devices to /etc/network

Agree.  I never liked the directory structure for network startup.

> * Move /etc/sysconfig/rc to /etc/default/rc
> * Move any remaining /etc/sysconfig files (like modules) to /etc/default
> * Create an /etc/default/rc.local to house configurations like UTC and 
> HOSTNAME

I'm not sure about the name rc.local, but I like the general idea.

> * Add logic from Fedora to kill client sessions to the sshd init script.

Again, BLFS, but I agree in principle.  OTOH you may want to keep an ssh 
session active when restarting sshd.  I suppose this could always be 
done with an ssh session to a non-standard port, but it warrants a bit 
more discussion.

> There have been a few other minor modifications as well.
> 
> Obviously, with that many changes to the structure of the scripts, I 
> don't expect them to be merged upstream. I assume I'd have to manage 
> them myself. So this raises the question of licensing and/or proper 
> attribution. From what I can tell, the scripts don't contain any sort of 
> license. What should be done?

The book says:

"Computer instructions may be extracted from the book under the MIT 
License."

As far as I'm concerned the scripts are public domain and don't need a 
license.

Why don't you post your scripts so we can look at them in more detail.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Using the LSB Bootscripts

[Jeremy Huntwork]

Hello,

So we've been using the LSB bootscripts for some time now on LightCube 
OS, with very little modification (we added dhclient service and the 
random bootscript to the default install), and it's behaved wonderfully.

There have been a few things that we noticed that we felt needed to 
change, namely:

* ifdown uses the configured service script to remove addresses from the 
interface. This becomes a problem when a user changes the configuration 
before running the script to restart networking.

Two possible scenarios here. One, the static service tries to remove the 
configured IP address from the device (which has changed and will thus 
fail) and adds the new IP. The result is two static IP addresses on the 
device. The second scenario is if you change the service, say from dhcp 
to static. The static will not kill the dhcp client when it restarts, 
and you could have two addresses again. Similarly, the dhcp client will 
not remove static addresses already assigned to the device before 
launching itself.

* When using in production systems, the heavy use of 'read Enter' on 
script errors, especially in generic cases, make it difficult to manage 
remote machines that have encountered an error on boot or halt/reboot.

* The sshd script (from BLFS) when halting doesn't kill user sshd 
sessions. It just stops the daemon. This results in frozen terminals 
until the session times out.

* The organization of files feels like it could be improved and made 
easier. For example, the ifdown and ifup scripts seem better placed in 
/sbin.

All of the above has led me to modify the scripts for LightCube's use 
and make the following changes:

* Add a param to release any dhclient addresses from a device if it is 
running in the ipv4-static service
* In the ipv4-static service, instead of attempting to remove the IP set 
in the configuration file, just flush all addresses with 'ip addr flush 
[dev]'
* In the dhclient service, flush any static addresses as well.
* Move ifdown and ifup to /sbin
* Move the equivalent of /etc/sysconfig/network-devices/services to 
/lib/services
* Move the equivalent of /etc/sysconfig/network-devices to /etc/network
* Move /etc/sysconfig/rc to /etc/default/rc
* Move any remaining /etc/sysconfig files (like modules) to /etc/default
* Create an /etc/default/rc.local to house configurations like UTC and 
HOSTNAME
* Add logic from Fedora to kill client sessions to the sshd init script.

There have been a few other minor modifications as well.

Obviously, with that many changes to the structure of the scripts, I 
don't expect them to be merged upstream. I assume I'd have to manage 
them myself. So this raises the question of licensing and/or proper 
attribution. From what I can tell, the scripts don't contain any sort of 
license. What should be done?

Thanks,

JH
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page