Thanks for the fix .Version 0.5 networking is 100% on my test machine . For those places that have slow internet connections and are remote and are using version 0.5 can they be advised to simply edit
/etc/sysconfig/network-scripts/ifcfg-eth1 (Edit this line to look like this) if [ "foo$XS_LANBOND_MAINXS_IPADDR" != "foo" ]; then (Add this line) HOTPLUG=yes i take it that theres no repercussions on the other services since the fix looks logical . On Fri, Dec 12, 2008 at 6:36 AM, <server-devel-requ...@lists.laptop.org>wrote: > Send Server-devel mailing list submissions to > server-de...@lists.laptop.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.laptop.org/listinfo/server-devel > or, via email, send a message with subject or body 'help' to > server-devel-requ...@lists.laptop.org > > You can reach the person managing the list at > server-devel-ow...@lists.laptop.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Server-devel digest..." > > > Today's Topics: > > 1. Re: Amateurish Workaround to Get Bonding to Work With eth1 > (Martin Langhoff) > 2. Re: Amateurish Workaround to Get Bonding to Work With eth1 (Anna) > 3. Re: Amateurish Workaround to Get Bonding to Work With eth1 (Anna) > 4. Re: Amateurish Workaround to Get Bonding to Work With eth1 > (Raul Gutierrez Segales) > 5. Re: Gadget fedora package (Robert McQueen) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 11 Dec 2008 16:04:09 -0200 > From: "Martin Langhoff" <martin.langh...@gmail.com> > Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to > Work With eth1 > To: Anna <ascho...@gmail.com> > Cc: XS Devel <server-de...@lists.laptop.org> > Message-ID: > <46a038f90812111004y43f8309csa6772c4d2d5ad...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Thu, Dec 11, 2008 at 3:55 PM, Anna <ascho...@gmail.com> wrote: > > It worked for me, however, it looks like it returns a bunch of config > files > > to their "pristine" state, which isn't a big deal on this particular test > > machine, as I had only edited sshd_config.in and sshd_config to allow > for > > password authentication. This might be something users might want to be > > aware of if they've been testing other stuff and have tweaked some of > these > > files. > > Good to hear it works for you! > > Yes, we do override some files -- including sshd_config. However > > - we store a copy in git to be able to retrieve it later > - we do respect sshd_config.in -- if you edit sshd_config.in, your > changes will be preserved, and any new sshd_config.in we want to > deploy will be written as sshd_config.in.rpmnew > > cheers, > > > > m > -- > martin.langh...@gmail.com > mar...@laptop.org -- School Server Architect > - ask interesting questions > - don't get distracted with shiny stuff - working code first > - http://wiki.laptop.org/go/User:Martinlanghoff > > > ------------------------------ > > Message: 2 > Date: Thu, 11 Dec 2008 11:55:28 -0600 > From: Anna <ascho...@gmail.com> > Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to > Work With eth1 > To: "Martin Langhoff" <martin.langh...@gmail.com>, "XS Devel" > <server-de...@lists.laptop.org> > Message-ID: > <196348a20812110955v5a1e53b1jbca86ca53d1ac...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, Dec 11, 2008 at 10:09 AM, Martin Langhoff < > martin.langh...@gmail.com > > wrote: > > > > > yum --enablerepo=olpcxs-testing install xs-config > > > > which if you try now will bring xs-config-0.5.9.g13a7973-1.noarch.rpm > > which has two fixes. This has a further typo fix (that I had made in > > the script I tested, but forgot to include) and also sets it to be > > HOTPLUG=yes so if eth1 is slow to come up, it should work once it's > > up. > > > > let me know if it helps... > > > It worked for me, however, it looks like it returns a bunch of config files > to their "pristine" state, which isn't a big deal on this particular test > machine, as I had only edited sshd_config.in and sshd_config to allow for > password authentication. This might be something users might want to be > aware of if they've been testing other stuff and have tweaked some of these > files. > > Downloading Packages: > xs-config-0.5.9.g13a7973-1.noarch.rpm | 106 kB > 00:00 > Running rpm_check_debug > Running Transaction Test > Finished Transaction Test > Transaction Test Succeeded > Running Transaction > Installing : xs-config [1/1] > /etc / > # It may be dirty > xs-commitchanged -m 'Dirty state' rsyslog.conf > # Overwrite > cp -p rsyslog.conf.in rsyslog.conf > xs-commitchanged -m "Made from rsyslog.conf.in" rsyslog.conf > # It may be dirty > xs-commitchanged -m 'Dirty state' motd > # Overwrite > cp -p motd.in motd > xs-commitchanged -m "Made from motd.in" motd > xs-commitchanged -m 'Dirty state' sysctl.conf > cp -p sysctl.conf.in sysctl.conf > xs-commitchanged -m "Made from sysctl.conf.in" sysctl.conf > sysctl -p sysctl.conf > net.ipv4.ip_forward = 1 > net.ipv4.conf.default.rp_filter = 1 > net.ipv4.conf.default.accept_source_route = 0 > kernel.sysrq = 1 > kernel.core_uses_pid = 1 > net.ipv4.tcp_syncookies = 1 > kernel.shmmax = 268435456 > # It may be dirty > xs-commitchanged -m 'Dirty state' ssh/sshd_config > # Overwrite > cp -p ssh/sshd_config.in ssh/sshd_config > xs-commitchanged -m "Made from ssh/sshd_config.in" ssh/sshd_config > Created commit bb554ba: Made from ssh/sshd_config.in - changed file > /etc/ssh/sshd_config > 1 files changed, 3 insertions(+), 3 deletions(-) > # It may be dirty > xs-commitchanged -m 'Dirty state' sysconfig/named > # Overwrite > cp -p sysconfig/named.in sysconfig/named > xs-commitchanged -m "Made from sysconfig/named.in" sysconfig/named > # It may be dirty > xs-commitchanged -m 'Dirty state' sysconfig/init > # Overwrite > cp -p sysconfig/init.in sysconfig/init > xs-commitchanged -m "Made from sysconfig/init.in" sysconfig/init > # It may be dirty > xs-commitchanged -m 'Dirty state' sysconfig/iptables-config > # Overwrite > cp -p sysconfig/iptables-config.in sysconfig/iptables-config > xs-commitchanged -m "Made from sysconfig/iptables-config.in" > sysconfig/iptables-config > # It may be dirty > xs-commitchanged -m 'Dirty state' sysconfig/squid > # Overwrite > cp -p sysconfig/squid.in sysconfig/squid > xs-commitchanged -m "Made from sysconfig/squid.in" sysconfig/squid > touch sudoers.tmp > chmod 640 sudoers.tmp > cat-parts sudoers.d > sudoers.tmp > chmod 440 sudoers.tmp > xs-commitchanged -m 'Dirty state' sudoers > mv -f sudoers.tmp sudoers > xs-commitchanged -m "Made from sudoers.d" sudoers > # It may be dirty > xs-commitchanged -m 'Dirty state' rssh.conf > # Overwrite > cp -p rssh.conf.in rssh.conf > xs-commitchanged -m "Made from rssh.conf.in" rssh.conf > # It may be dirty > xs-commitchanged -m 'Dirty state' php.ini > # Overwrite > cp -p php.ini.in php.ini > xs-commitchanged -m "Made from php.ini.in" php.ini > # It may be dirty > xs-commitchanged -m 'Dirty state' sysconfig/httpd > # Overwrite > cp -p sysconfig/httpd.in sysconfig/httpd > xs-commitchanged -m "Made from sysconfig/httpd.in" sysconfig/httpd > # It may be dirty > xs-commitchanged -m 'Dirty state' init.d/squid > # Overwrite > cp -p init.d/squid.in init.d/squid > xs-commitchanged -m "Made from init.d/squid.in" init.d/squid > # It may be dirty > xs-commitchanged -m 'Dirty state' sysconfig/ejabberd > # Overwrite > cp -p sysconfig/ejabberd.in sysconfig/ejabberd > xs-commitchanged -m "Made from sysconfig/ejabberd.in" sysconfig/ejabberd > xs-commitchanged -m 'Dirty state' sysconfig/network-scripts/ifcfg-eth0 > cp -p sysconfig/olpc-scripts/ifcfg-eth0 > sysconfig/network-scripts/ifcfg-eth0 > xs-commitchanged -m "Made from olpc-scripts" > sysconfig/network-scripts/ifcfg-eth0 > xs-commitchanged -m 'Dirty state' sysconfig/network-scripts/ifcfg-eth1 > cp -p sysconfig/olpc-scripts/ifcfg-eth1 > sysconfig/network-scripts/ifcfg-eth1 > xs-commitchanged -m "Made from olpc-scripts" > sysconfig/network-scripts/ifcfg-eth1 > # It may be dirty > xs-commitchanged -m 'Dirty state' httpd/conf.d/proxy_ajp.conf > # Overwrite > cp -p httpd/conf.d/proxy_ajp.conf.in httpd/conf.d/proxy_ajp.conf > xs-commitchanged -m "Made from httpd/conf.d/proxy_ajp.conf.in" > httpd/conf.d/proxy_ajp.conf > # It may be dirty > xs-commitchanged -m 'Dirty state' httpd/conf.d/ssl.conf > # Overwrite > cp -p httpd/conf.d/ssl.conf.in httpd/conf.d/ssl.conf > xs-commitchanged -m "Made from httpd/conf.d/ssl.conf.in" > httpd/conf.d/ssl.conf > Using default domain name > Setting the base dns name to random.xs.laptop.org > find: ./domain_config.d/: No such file or directory > xs-commitchanged -m 'Dirty state' sysconfig/network > sed -e "s/@@SERVERNUM@@/$(cat /etc/sysconfig/xs_server_number)/" < > sysconfig/network.in > sysconfig/network > xs-commitchanged -m "Made from sysconfig/network.in" sysconfig/network > xs-commitchanged -m 'Dirty state' hosts > sed -e "s/@@SERVERNUM@@/$(cat /etc/sysconfig/xs_server_number)/" < > hosts.in> hosts > xs-commitchanged -m "Made from hosts.in" hosts > # It may be dirty > xs-commitchanged -m 'Dirty state' sysconfig/dhcpd > # Overwrite > cp -p sysconfig/dhcpd.in sysconfig/dhcpd > xs-commitchanged -m "Made from sysconfig/dhcpd.in" sysconfig/dhcpd > / > Stopping httpd: [ OK ] > Starting httpd: httpd: Could not reliably determine the server's fully > qualified domain name, using 127.0.0.1 for ServerName > [ OK ] > Shutting down system logger: [ OK ] > Starting system logger: [ OK ] > > Installed: xs-config.noarch 0:0.5.9.g13a7973-1 > Complete! > > Anna Schoolfield > Birmingham > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.laptop.org/pipermail/server-devel/attachments/20081211/7e936d38/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Thu, 11 Dec 2008 12:19:27 -0600 > From: Anna <ascho...@gmail.com> > Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to > Work With eth1 > To: "Martin Langhoff" <martin.langh...@gmail.com> > Cc: XS Devel <server-de...@lists.laptop.org> > Message-ID: > <196348a20812111019q1bbfb753oa1fb6b0a7824d...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > On Thu, Dec 11, 2008 at 12:04 PM, Martin Langhoff < > martin.langh...@gmail.com > > wrote: > > > > > - we do respect sshd_config.in -- if you edit sshd_config.in, your > > changes will be preserved, and any new sshd_config.in we want to > > deploy will be written as sshd_config.in.rpmnew > > > > > Well, I did edit sshd_config.in and then did the make xs-config thing like > I > was supposed to. My changes were preserved in > /etc/ssh/sshd_config.in.rpmsave. > > But going forward, and since I'm looking at possibly installing XS 0.5 on > quite a few machines here, before I burn the CD again, can I edit > /etc/sysconfig/network-scripts/ifcfg-eth1 on the iso like so: > > (Edit this line to look like this) > if [ "foo$XS_LANBOND_MAINXS_IPADDR" != "foo" ]; then > (Add this line) > HOTPLUG=yes > > Will that work? I need to keep the install steps to a minimum and I'd > rather make the changes to the iso. > > Anna Schoolfield > Birmingham > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.laptop.org/pipermail/server-devel/attachments/20081211/5268c8ab/attachment-0001.htm > > ------------------------------ > > Message: 4 > Date: Thu, 11 Dec 2008 15:32:14 -0300 > From: Raul Gutierrez Segales <r...@rieder.net.py> > Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to > Work With eth1 > To: Martin Langhoff <martin.langh...@gmail.com> > Cc: XS Devel <server-de...@lists.laptop.org> > Message-ID: <1229020334.6408.51.ca...@laptop> > Content-Type: text/plain > > Will a new ISO (XS-0.5.1?) be released to address this issue? > > > On Wed, 2008-12-10 at 18:51 -0200, Martin Langhoff wrote: > > On Wed, Dec 10, 2008 at 6:09 PM, Martin Langhoff > I spotted exactly > > the same difference and tested it -- does not seem > > > to work. Hope to get to the bottom of it. > > > > Alright, fixed. Credit to Anna and Jerry for narrowing down on the issue. > > > > The actual problem is laughably simple -- late in the dev cycle of 0.5 > > a typo sneaked in. A minor edit of ifcfg-eth1 fixes it, see: > > > > > http://dev.laptop.org/git?p=projects/xs-config;a=commitdiff;h=acd64ab3d2342fbda08a944e31878db6b3b563f2 > > > > In any case, you can grab the rpm with the fix from > > > > > http://xs-dev.laptop.org/xsrepos/testing/olpc/9/i386/xs-config-0.5.7.g11aaacf-1.noarch.rpm > > > > or perform > > > > yum --enablerepo=olpcxstesting install xs-config > > > > thanks everyone -- specially Anna -- for you help and patience. > > > > cheers, > > > > > > > > martin > > > > ------------------------------ > > Message: 5 > Date: Thu, 11 Dec 2008 18:34:04 +0000 > From: Robert McQueen <robert.mcqu...@collabora.co.uk> > Subject: Re: [Server-devel] Gadget fedora package > To: Martin Langhoff <martin.langh...@gmail.com> > Cc: server-de...@lists.laptop.org, Marco Pesenti Gritti > <marc...@sugarlabs.org> > Message-ID: <49415d1c.5040...@collabora.co.uk> > Content-Type: text/plain; charset=ISO-8859-1 > > Martin Langhoff wrote: > > But I'm working on this space at the moment - switching away from the > > "all online users" patch that I suspect Guillaume is talking about and > > shifting to a different strategy using PostgreSQL. > > > > So its "mostly behind us" (emphasis on mostly) as I mentioned but > > things are looking promising. The strategies I'm planning to use are > > in use by several large scale sites based on ejabberd with custom > > roster behaviours. > > I thought about having the server subdivide people into smaller mutually > visible groups, particularly in G1G1 when having magic groups which try > and group by network proximity or random grouping is reasonable. It > works just because that the n^2 scalability problems are avoided by > simply making n smaller, but I still believe that approaches based > around shared rosters aren't ultimately the right thing to do. > > Remember that what we're talking about isn't simply whether people can > see each other's presence or not, but that we rely on a bidirectional > presence subscription to use PEP to publish the extra OLPC-specific > properties of a buddy, as well as their currently active activity, all > of the activities they're running, and the properties of all of those > activities. > > Problems with this: > > * It's further from what XMPP does normally because it continues and > presumes/presupposes that the server knows best who should see each > other. Gadget only publishes buddy information if they subscribe to > it, and only publishes activities if it's invited to it, allowing > fine-grained control, and for the other cases we should allow people > to punch in JIDs or find people in activities/groups and make their > own friendship subscriptions. > > * It's inefficient because every client in an activity ends up pushing > PEP nodes with verbose details of their activities, when actually if > the server had a concept of the activity it would only need to be > aware of one copy of this information. That means when an activity > changes its properties, you get the changed activity details N times, > once for each participant. Gadget receives the activity details > directly from the activity once only. > > * It's inefficient because the server pushes all of these to all > clients in the mutually-visible group, even if that's too much > information for the UI to display, or it's just not relevant because > that view isn't open currently. Gadget pushes changes to only those > people who are interested in a certain activity. > > * It precludes finer-grained visibility controls - you can't set up > activities which are only visibile to certain groups of people > without letting those people see all of your activities, or none. > Although Gadget currently allows all people on a server to query an > activity it's invited to, it gives us one place to implement > functionality like sharing with certain groups or list of people. > > * You're limited to having subsets of people who are on one server, and > because we need bi-directional subscriptions for PEP to work, both > servers need to agree, so you really have very few options for > including other people from other servers unless you start setting up > a protocol by which servers inter-agree who should see each other on > users' behalves. Seems pretty tricky... > > Further to this Gadget offers: > * Searches for buddies and activities are made out of all information > available to Gadget, rather than people being split into different > "silos". So even if people in different classes are using some niche > activity, they can still find each other. > > * If server to server connections are enabled, its possible to invite a > Gadget from another server (a partner school, for example) into an > activity to make it searchable by people in the other school. We > could even look at gadget<->gadget propogation of activities and > buddies if we wanted to. > > > cheers, > > > > martin > > Regards, > Rob > > -- > Robert McQueen +44 7876 562 564 > Director, Collabora Ltd. http://www.collabora.co.uk > > > > ------------------------------ > > _______________________________________________ > Server-devel mailing list > server-de...@lists.laptop.org > http://lists.laptop.org/listinfo/server-devel > > > End of Server-devel Digest, Vol 20, Issue 13 > ******************************************** >
_______________________________________________ Server-devel mailing list server-de...@lists.laptop.org http://lists.laptop.org/listinfo/server-devel