[Server-devel] Server-devel Digest, Vol 20, Issue 13
Eroni Tuiloma
eroni.tui at gmail.com
Thu Dec 11 20:32:38 EST 2008
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-request at lists.laptop.org>wrote:
> Send Server-devel mailing list submissions to
> server-devel at 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-request at lists.laptop.org
>
> You can reach the person managing the list at
> server-devel-owner at 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.langhoff at gmail.com>
> Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to
> Work With eth1
> To: Anna <aschoolf at gmail.com>
> Cc: XS Devel <server-devel at lists.laptop.org>
> Message-ID:
> <46a038f90812111004y43f8309csa6772c4d2d5ad49a at mail.gmail.com>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Thu, Dec 11, 2008 at 3:55 PM, Anna <aschoolf at 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.langhoff at gmail.com
> martin at 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 <aschoolf at gmail.com>
> Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to
> Work With eth1
> To: "Martin Langhoff" <martin.langhoff at gmail.com>, "XS Devel"
> <server-devel at lists.laptop.org>
> Message-ID:
> <196348a20812110955v5a1e53b1jbca86ca53d1ace67 at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Dec 11, 2008 at 10:09 AM, Martin Langhoff <
> martin.langhoff at 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 <aschoolf at gmail.com>
> Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to
> Work With eth1
> To: "Martin Langhoff" <martin.langhoff at gmail.com>
> Cc: XS Devel <server-devel at lists.laptop.org>
> Message-ID:
> <196348a20812111019q1bbfb753oa1fb6b0a7824d4dd at mail.gmail.com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Thu, Dec 11, 2008 at 12:04 PM, Martin Langhoff <
> martin.langhoff at 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 <rgs at rieder.net.py>
> Subject: Re: [Server-devel] Amateurish Workaround to Get Bonding to
> Work With eth1
> To: Martin Langhoff <martin.langhoff at gmail.com>
> Cc: XS Devel <server-devel at lists.laptop.org>
> Message-ID: <1229020334.6408.51.camel at 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.mcqueen at collabora.co.uk>
> Subject: Re: [Server-devel] Gadget fedora package
> To: Martin Langhoff <martin.langhoff at gmail.com>
> Cc: server-devel at lists.laptop.org, Marco Pesenti Gritti
> <marcopg at sugarlabs.org>
> Message-ID: <49415D1C.5040805 at 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-devel at lists.laptop.org
> http://lists.laptop.org/listinfo/server-devel
>
>
> End of Server-devel Digest, Vol 20, Issue 13
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/server-devel/attachments/20081212/2fd91b3f/attachment-0001.htm
More information about the Server-devel
mailing list