Re: [Server-devel] Notes on replacing bridging with bonding
Martin Langhoff escribió: This is roughly what I am doing: # mark the device as a bonding device # - for some reason TYPE does not work I have placed TYPE=Bonding in the ifcfg-bond0 config files, but this is not needed for Fedora 7 or later (it doesn't hurt to have it, though) # cat /etc/modprobe.d/xs-bonding alias bond0 bonding A modprobe.d/ directory - that's a nice trick! I wasn't aware of this, so just added some lines to the /etc/modprobe.conf file: alias bond0 bonding options bond0 miimon=100 mode=3 downdelay=1000 updelay=1000 As far as I know, these options are pretty much the same as the ones which can be specified with BONDING_OPTS - I guess it is probably better to do that there (this feature was added since Fedora Core 5, when I set mine up). As for the specifics of what might be appropriate for a bonded channel with only one interface expected to be enslaved, I would suggest something along the lines of: # use active backup mode, allowing primary slave to be specified mode=1 # set multicast only on primary multicast=1 # set primary slave primary=wlan1 # set status monitoring to 1000msec miimon=1000 I'm not 100% sure about the last one. I believe that if there is no monitoring, the link status of the bond interface won't reflect the link status of the underlying device, but I haven't confirmed this (or, for that matter, that the link status of the bond device will reflect the underlying device(s) if monitoring is enabled). There is presumably some overhead to this, but at once a second or even tenth of a second, it is negligible. Thinking about this more, since these are wireless devices (active antenna via USB) I don't even know if there is a link status - for those you might want to omit this option. It could theoretically be useful for the wired Ethernet interfaces, though. Other than these options, which aren't strictly necessary (your setup with the defaults should work fine) everything you have looks perfectly reasonable. The only advantage to specifying the active backup mode is a little bit of misconfiguration protection, so that if somehow a second interface gets enslaved to a bond, it won't be used for transmission (packets will still be received on it, however). Explicitly specifying the primary slave in the BONDING_OPTS of the master duplicates some of the configuration which introduces the possibility of inconsistency - I'm not sure what your feelings on that are. If the primary slave is not explicitly specified, the first enslaved device is the primary. @alex -- mailto:[EMAIL PROTECTED] ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] A few F9 upgrade things I need help with...
As part of the XS upgrade, I've ended up caught with a number of F9 oddities -- none of them a complete blocker, but definitely rought edges... - Cannot include beecrypt in Pungi/Revisor build - this is probably a bug worthy of filing in BZ but needs a bit of diagnosys. http://dev.laptop.org/ticket/8363 - Anaconda conflicts with xs-config - Filed as BZ 461550 http://dev.laptop.org/ticket/8366 - Anaconda crash during install with USB-disk-based ks.cfg BZ 461453 - this probably affects all USB-disk based installs. - Anaconda: Install from USB disk: only ISO picked up BZ 461548 - Anaconda: Install from USB disk: Awkward to provide a ks.cfg BZ 461549 All of these are - I think - worthwhile to whack for the ease-of-install experience with Fedora and the XS... cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
[Server-devel] F9 XS - Take it for a spin...
with some caveats... this is a developer preview, lots of things are b0rken, but still... - download all 759MB of iso here http://xs-dev.laptop.org/xs/other/Fedora-0.5.dev2-i386.iso - Burn it to a DVD (see notes below on using USB sticks) - Install it on a new machine - use the kickstart-driven default menu option - After install 1 - login as root 2 - cd /etc make -f xs-config.make earlyset reboot - If you have 2 NICs and F9 got them the wrong way around, just invoke xs-swapnics and reboot Other installation notes... - Upgrades... for some reason, Anaconda isn't realising that it is supposed to be upgrading... working on that... - From a USB device! Ah, well, mildly annoying - - grab mkusbinstall from here http://dev.laptop.org/git?p=projects/xs-livecd;a=tree;f=util;h=202b31c7ef280036e3edd99ef68871e3d0815295;hb=HEAD - use it like you'd use livecd-iso-to-disk - Anaconda will fail to kind the ks file - fix the path to be 'hd:sdb1:/ks.cfg' - assuming your USB disk is mounted as sdb1. It may require waiting a few seconds until sdb1 is mounted. - Anaconda will need to be told where the ISO is. Pick Hard Drive install, sdb1, and the path is 'iso' What's not there yet - idmgr won't start due to sqlalchemy. Douglas is working on some sqlalchemy surgery. - fakechroot doesn't play well with rsync. Waiting on upstream to nod at the patches, though they look good to me, and we do have an RPM for it. - ejabberd is the wrong version - got to fix that. cheers, m -- [EMAIL PROTECTED] [EMAIL PROTECTED] -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
