On Feb 25, 2012, at 9:14 AM, Bruce Dubbs wrote:
> Qrux wrote:
>> Bruce, Nathan, et al.,
>>
>> Bridging sort of "inverted" the semantics
>> of /lib/lsb/<service> by setting IFACE to the bridge interface. It
>> inverted the semantics in ipv4-static. I just altered it so the
>> semantics are identical.
>
> I'm not seeing everything you are saying. Can you please send me a diff.
TL;DR - I understand where it came from (i.e., using IFACE to specify the
bridge), but in the new services implementation, it's cleaner to have
service-specific variables to implement service-specific actions and allow
IFACE to uniformly refer to the physical link.
Code immediately below; explanations follow.
Q
################################################################
ONBOOT=yes
IFACE="eth1" # Enslaved port
BRIDGE="br1"
SERVICE="bridge ipv4-static"
IP=192.168.1.102
PREFIX=24
BROADCAST=192.168.1.255
STP=no # Use Spanning Tree Protocol?
MTU=9000
################################################################
--- ifup 2012-02-09 15:34:37.000000000 -0800
+++ ifup-MTU 2012-02-25 16:06:51.000000000 -0800
@@ -105,6 +105,10 @@
log_warning_msg "\nInterface ${IFACE} doesn't exist."
exit 0
fi
+
+ # Link is up, so set MTU (if value is a positive int).
+ test -n "${MTU}" -a $MTU -eq $MTU -a 0 -lt $MTU 2> /dev/null && \
+ ip link set dev ${IFACE} mtu $MTU
fi
for S in ${SERVICE}; do
--- bridge 2012-02-01 18:52:01.000000000 -0800
+++ bridge-MTU 2012-02-25 16:23:11.000000000 -0800
@@ -14,22 +14,23 @@
. /lib/lsb/init-functions
. ${IFCONFIG}
-if [ -n "${INTERFACE}" ]; then
- log_failure_msg "INTERFACES variable missing from ${IFCONFIG}"
+# Call the bridge ${BRIDGE} for clarity.
+if [ -n "${BRIDGE}" ]; then
+ log_failure_msg "BRIDGE variable missing from ${IFCONFIG}"
exit 1
fi
case "${2}" in
up)
log_info_msg2 "\n"
- log_info_msg "Creating the ${1} interface..."
- brctl addbr ${1}
- ip link set ${1} up
+ log_info_msg "Creating the ${BRIDGE} interface..."
+ brctl addbr ${BRIDGE}
+ ip link set ${BRIDGE} up
evaluate_retval
- for I in ${INTERFACES}; do
- log_info_msg "Adding ${I} to ${1}..."
- ip link set ${I} up &&
- brctl addif ${1} ${I}
+ for IF in ${IFACE}; do
+ log_info_msg "Adding ${IF} to ${BRIDGE}..."
+ #QRUX - Don't worry about the PHY link; let ifup deal with that.
+ brctl addif ${BRIDGE} ${IF}
evaluate_retval
done
@@ -44,16 +45,16 @@
;;
down)
- for I in ${INTERFACES}; do
- log_info_msg "Removing ${I} from ${1}..."
- ip link set ${I} down &&
- brctl delif ${1} ${I}
+ for IF in ${IFACE}; do
+ log_info_msg "Removing ${IF} from ${BRIDGE}..."
+ #QRUX - Don't worry about the PHY link; let ifdown deal with that.
+ brctl delif ${BRIDGE} ${IF}
evaluate_retval
done
- log_info_msg "Bringing down the ${1} interface..."
- ip link set ${1} down
- brctl delbr ${1}
+ log_info_msg "Bringing down the ${BRIDGE} interface..."
+ ip link set ${BRIDGE} down
+ brctl delbr ${BRIDGE}
evaluate_retval
;;
> {$1} is the name of the config file extension...
I'm aware that the name and IFACE don't *have to* match, so my fixes allow for
your "ifconfig.testconfig" test case now...
Still, it seems awfully specious to say: "It's only the number of files that
needs to coincide; everything else is gravy." The files are indeed supposed to
be match the interfaces; that's why there are exactly as many as are interfaces
that you want to start. Imagine you have 2 NICs. Would you name one file
ifconfig.eth0 and expect to see IFACE=eth1 inside of it, and a second one
called ifconfig.eth1 and see IFACE=eth0 inside? Sure, it works, but that
doesn't mean it should. Seems like using the filename--which, I emphasize, is
already the conventional usage--is a perfectly valid way to enforce a
non-insane setup.
I just don't buy into config-file-testing being salient. Why not just test
interface configs like anything else? Just copy the existing one to a backup,
then use it to test.
> I can see where you might want to set the MTU, but shouldn't any ethx
> interface connected to the bridge have the same value as the bridge MTU?
Yes, that's right. The bridge uses whatever the underlying link uses. Indeed,
I'm trying to set the MTU of the physical link, which should be done by ifup.
In the existing scripts, it doesn't--because it can't, because IFACE is set to
the bridge, and the physical link is specified in a variable that's
*service-specific* (${INTERFACES}, when it's a bridge). That's backwards. So,
my changes revert IFACE to the physical link--allowing ifup to deal with
physical stuff like MTU and CHECK_LINK--and adapt bridge to use a
*service-specific* variable like ${BRIDGE}, which upstream stuff (e.g., ifup)
doesn't need to know--or care--about.
Conceptually, ifup/ifdown should access ONE variable to refer to the physical
link, and that should be IFACE. It shouldn't change based on whether the
service is a bridge or ipv4-static (or whatever else comes along).
Q
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
