[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
[Server-devel] Patch fixing a problem with --kickstart-include
By naming the kickstart file as ks.cfg, anaconda would _always_ take it, regardless of kernel boot options. This is not what was expected - it is safer to give it a different name, and then use the boot menu item to select it. The patch is on top if F-9 . 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 0001-base.py-The-kickstart-file-is-now-named-revisorks.c.patch Description: Binary data ___ 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
Re: [Server-devel] Notes on replacing bridging with bonding
Jerry Vonau wrote: > Martin Langhoff wrote: >> On Mon, Sep 8, 2008 at 7:43 PM, Alexander Dupuy <[EMAIL PROTECTED]> wrote: >>> 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) >> well, I grepped network-functions and ifup-eth and none of the TYPE >> checks are for bonding anything. The check is done against the output >> of modprobe. So if it's going to be ignored, I'll save the >> corresponding bytes (and potential confusion later). >> > ifup does a check for type=Bridge > Bonding can be handled via VLAN=yes and PHYDEV=msh0 in the ifcfg files for the bond device, ifup uses those values to setup the bonding in a hotplug environment. The slave (msh0) should have SLAVE=yes MASTER=bond0 in its file. Hotplug works also, bond0 doesn't need to have its slave present to become active, plug the slave in, becomes active and bonding does the right thing. Bye, bye dummy interface. # 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: >> that's what the most modern doco could find suggested. And the >> ifup-eth src is clearly looking at the output of modprobe, so there's >> something to it... >> > well, udev loads the modules on boot, for configured devices. "network" > checks to see if the required module for the nic is loaded, if missing > loads it. > Think we can just dump a file in /etc/modprobe.d/ with the bonding options needed. I've been using bonding mode=active-backup miimon=100" to test with, any idea what we may be using here? >>> everything you have looks perfectly >>> reasonable. >> thanks for sanity checking. One thing I have not been able to _test_ >> is that I want one of the bonding devices to have 2 IP addresses,so >> I've setup lanbond0 and lanbond0:1 - with eth1 as a slave to lanbond0. >> >> lanbond0:1 comes up automatically with lanbond0 . I am not 100% >> certain that eth1 - if / when it comes up - will get the 2 addresses. >> > Sorry, I'll get to mocking up the layout later. > Based on the quick mockup, I'll say no, the slaves should not have an ipaddress assigned to them. Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Notes on replacing bridging with bonding
Martin Langhoff wrote: > On Mon, Sep 8, 2008 at 7:43 PM, Alexander Dupuy <[EMAIL PROTECTED]> wrote: >> 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) > > well, I grepped network-functions and ifup-eth and none of the TYPE > checks are for bonding anything. The check is done against the output > of modprobe. So if it's going to be ignored, I'll save the > corresponding bytes (and potential confusion later). > ifup does a check for type=Bridge >>> # 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: > > that's what the most modern doco could find suggested. And the > ifup-eth src is clearly looking at the output of modprobe, so there's > something to it... > well, udev loads the modules on boot, for configured devices. "network" checks to see if the required module for the nic is loaded, if missing loads it. >> everything you have looks perfectly >> reasonable. > > thanks for sanity checking. One thing I have not been able to _test_ > is that I want one of the bonding devices to have 2 IP addresses,so > I've setup lanbond0 and lanbond0:1 - with eth1 as a slave to lanbond0. > > lanbond0:1 comes up automatically with lanbond0 . I am not 100% > certain that eth1 - if / when it comes up - will get the 2 addresses. > Sorry, I'll get to mocking up the layout later. Jerry ___ Server-devel mailing list Server-devel@lists.laptop.org http://lists.laptop.org/listinfo/server-devel
Re: [Server-devel] Notes on replacing bridging with bonding
On Mon, Sep 8, 2008 at 7:43 PM, Alexander Dupuy <[EMAIL PROTECTED]> wrote: > 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) well, I grepped network-functions and ifup-eth and none of the TYPE checks are for bonding anything. The check is done against the output of modprobe. So if it's going to be ignored, I'll save the corresponding bytes (and potential confusion later). >> # 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: that's what the most modern doco could find suggested. And the ifup-eth src is clearly looking at the output of modprobe, so there's something to it... > everything you have looks perfectly > reasonable. thanks for sanity checking. One thing I have not been able to _test_ is that I want one of the bonding devices to have 2 IP addresses,so I've setup lanbond0 and lanbond0:1 - with eth1 as a slave to lanbond0. lanbond0:1 comes up automatically with lanbond0 . I am not 100% certain that eth1 - if / when it comes up - will get the 2 addresses. cheers, martin -- [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
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
