Re: Sugar in a chroot?

[Jerry Vonau]

On Tue, 2013-08-06 at 21:37 -0700, Sameer Verma wrote:
> On Tue, Aug 6, 2013 at 7:18 PM, Chris Ball  wrote:
> > Hi,
> >
> > On Wed, Aug 07 2013, Sameer Verma wrote:
> >> 2) If we can run Android on the XO-4, then Fedora/Sugar can run in a
> >> chroot. That gives us Sugar and Android on the XO-4.
> >
> > Well, if it was that easy, we'd all be running Ubuntu desktops on our
> > Android phones already, right?
> >
> > The graphics system gets in the way -- you can't run X on top of
> > Android, yet Gtk depends on X, and Sugar depends on Gtk.
> >
> 
> Thanks. I've been running Debian on a Android phone, but I access
> GNOME over VNC from a different computer. Wonder if a VNC viewer on
> the Android phone itself would show me the UI.
> 

Think connecting to the loopback (lo) address should work if the vnc
service is bound to that address.

Jerry

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar in a chroot?

[Sameer Verma]

On Tue, Aug 6, 2013 at 7:18 PM, Chris Ball  wrote:
> Hi,
>
> On Wed, Aug 07 2013, Sameer Verma wrote:
>> 2) If we can run Android on the XO-4, then Fedora/Sugar can run in a
>> chroot. That gives us Sugar and Android on the XO-4.
>
> Well, if it was that easy, we'd all be running Ubuntu desktops on our
> Android phones already, right?
>
> The graphics system gets in the way -- you can't run X on top of
> Android, yet Gtk depends on X, and Sugar depends on Gtk.
>

Thanks. I've been running Debian on a Android phone, but I access
GNOME over VNC from a different computer. Wonder if a VNC viewer on
the Android phone itself would show me the UI.

cheers,
Sameer

> - Chris.
> --
> Chris Ball  
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar in a chroot?

[Chris Ball]

Hi,

On Wed, Aug 07 2013, Sameer Verma wrote:
> 2) If we can run Android on the XO-4, then Fedora/Sugar can run in a
> chroot. That gives us Sugar and Android on the XO-4.

Well, if it was that easy, we'd all be running Ubuntu desktops on our
Android phones already, right?

The graphics system gets in the way -- you can't run X on top of
Android, yet Gtk depends on X, and Sugar depends on Gtk.

- Chris.
-- 
Chris Ball  
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: Sugar in a chroot?

[Andrew McMillan]

On Tue, 2013-08-06 at 17:58 -0700, Sameer Verma wrote:
> I've been looking closely at Ubuntu on Android (different from the
> Ubuntu Touch) and other projects that run Linux in a chroot on
> Android. http://linuxonandroid.org/
> 
> 1) Given that the XO-4 is a dual core ARM, how hard would it be to run
> Android on it? (I sincerely apologize for the cruel Apr 1 joke earlier
> this year 
> https://bhagmalpur.wordpress.com/2013/04/01/android-on-the-olpc-xo-4-touch/)
> 
> 2) If we can run Android on the XO-4, then Fedora/Sugar can run in a
> chroot. That gives us Sugar and Android on the XO-4.

I guess that running *that* in a chroot on a standard XO-4 can be next
years April 1st joke :-)


> I'm fairly certain others have thought of this, but I'd like to know
> how far we've gotten down this path, if at all.

There are definitely investigations going on with regard to running
Android on the XO-4.  Consequential questions are things like:

* Which version of Android?
* Which Linux kernel version?

Marvell have done some work to support Android 4.0 (ICS) on the MMP3
chip used in the XO-4 using the 3.0 Linux kernel (standard for ICS) but
I would rather see a more recent version.

Most of the Android customisations to the Linux kernel got merged back
in across the 3.3 through 3.8 series', and with 3.10 being declared the
new LTS version I would not be surprised to see that used for Key Lime
Pie.  One big sucky problem is that the multi-core support from Marvell
is *only* present in that one 3.0 tree, and it hasn't made it upstream.

So yeah: investigation continues...

Cheers,
Andrew.

-- 
Andrew McMillan,
VP Software,
One Laptop per Child Association Inc.

___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Sugar in a chroot?

[Sameer Verma]

I've been looking closely at Ubuntu on Android (different from the
Ubuntu Touch) and other projects that run Linux in a chroot on
Android. http://linuxonandroid.org/

1) Given that the XO-4 is a dual core ARM, how hard would it be to run
Android on it? (I sincerely apologize for the cruel Apr 1 joke earlier
this year 
https://bhagmalpur.wordpress.com/2013/04/01/android-on-the-olpc-xo-4-touch/)

2) If we can run Android on the XO-4, then Fedora/Sugar can run in a
chroot. That gives us Sugar and Android on the XO-4.

I'm fairly certain others have thought of this, but I'd like to know
how far we've gotten down this path, if at all.

cheers,
Sameer
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

[Jerry Vonau]

This behavior was noted with XO-1s only, all others(1.5,1.75,4) appear work
fine in testing.

Jerry



On 6 August 2013 13:09, Samuel Greenfeld  wrote:

> I reimaged & registered a XO-1.75 and a XO-4 with 13.2.0 to a XS-0.7
> schoolserver.  Afterwards I opened Browse, and was able to open
> http://schoolserver/ to login to Moodle without problems.
>
> This does not mean that there is not a bug with 13.2.0, XS, and/or XSCE;
> but one thing you could try is to fully stop and restart the Browse
> activity after registering if the first login attempt does not work.
> Sometimes I have found this helps.
>
>
> On Tue, Aug 6, 2013 at 11:14 AM, Gonzalo Odiard wrote:
>
>> I don't have a school server to try.
>> You should fill a ticket on bugs.sugarlabs.org
>> cced: Manuel Quiñones, who maintain Browse activity.
>>
>> Gonzalo
>>
>>
>> On Tue, Aug 6, 2013 at 12:08 PM, Jerry Vonau  wrote:
>>
>>> Think it's more of a question of looking for confirmation. Is anybody
>>> else seeing this behavior on 13.2.0-13 on XO-1s when used with any version
>>> of school-servers? I'm at a loss trying to explain why this is occurring to
>>> Anna. With the noted behavior where would you file the bug report? OLPC is
>>> what I'm thinking but looking if someone else might be impacted also or can
>>> confirm this.
>>>
>>> Jerry
>>>
>>>
>>> On 6 August 2013 05:12, Gonzalo Odiard  wrote:
>>>
 There are a ticket filled?

 Gonzalo


 On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau wrote:

> Great piece of deductive testing Anna, way to go. Forwarding for
> further investigation.
>
> Jerry
>
> -- Forwarded message --
> From: Anna 
> Date: 5 August 2013 15:02
> Subject: [XSCE] Re: Client side Moodle transparent auth broken in
> 13.2.0 stable
> To: xsce-devel 
>
>
> I just realized that someone will probably ask what's the most recent
> build where Moodle transparent auth did work.  Lucky for me, I just had to
> test one older.  Moodle transparent auth DOES work in 13.2.0-12.
>
> So whatever broke client side Moodle transparent auth should be
> confined to 13.2.0-13.
>
>
> On Mon, Aug 5, 2013 at 2:19 PM, Anna  wrote:
>
>> I very recently upgraded my little herd of XOs to the latest stable
>> build 13.2.0-13.  Unfortunately, something in that build has broken
>> Moodle's transparent authentication.  When a registered client goes to
>> http://schoolserver/moodle, all it gets is the login page.
>>
>> Now, that's not unheard of, you can usually just click the "Home"
>> button and get automatically logged in.  But when I've seen that before,
>> the XO's SN is filled out in the Username field on the login page.  The
>> 13.2.0-13 XO doesn't show that.  No matter what you click on in the 
>> Moodle
>> login page, it never logs in.
>>
>> To verify it was a client side issue, I flashed an XO-1 with 13.1.0
>> stable, and registered first to be admin.  I also registered a 13.2.0-13 
>> as
>> the second client.  On the 13.1.0, I can go to the Moodle homepage and it
>> automatically logged me in.  I tried again to access the Moodle homepage 
>> on
>> the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin
>> XO, I went to Site Administration -> Users -> Accounts -> Browse list of
>> users and saw both XOs listed.  It indicated that the 13.2.0-13 client 
>> had
>> never logged in.
>>
>> So, the user account is being created on the server for the 13.2.0-13
>> XO upon registration, but client side transparent authentication is not
>> working.
>>
>> To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I
>> went to
>> http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pland
>>  the test was successful.
>>
>> Now, I have successfully tested Moodle transparent auth with previous
>> iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that
>> broke transparent auth must have been relatively recent.
>>
>> I took a look at the Browse Activity version between the two clients:
>> 13.1.0 = Browse 149
>> 13.2.0-13 = Browse 149.3
>>
>> I knew it wouldn't make a difference, but I also tested the 13.2.0-13
>> as first registration and it doesn't care that its the admin user.  And
>> also tested with a fresh flash to make sure there wasn't something sticky
>> in there from a previous registration gumming things up.
>>
>> I've tested this with the XSCE installed a couple days ago
>> (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I
>> also remembered I have an XS 0.6 (duh, Anna) and the results were the 
>> same.
>>  I don't have an XS 0.7 installation, but I would expect the same 
>> results.
>>
>> Since this is a client side issue, I'm not sure w

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

[Samuel Greenfeld]

I reimaged & registered a XO-1.75 and a XO-4 with 13.2.0 to a XS-0.7
schoolserver.  Afterwards I opened Browse, and was able to open
http://schoolserver/ to login to Moodle without problems.

This does not mean that there is not a bug with 13.2.0, XS, and/or XSCE;
but one thing you could try is to fully stop and restart the Browse
activity after registering if the first login attempt does not work.
Sometimes I have found this helps.


On Tue, Aug 6, 2013 at 11:14 AM, Gonzalo Odiard  wrote:

> I don't have a school server to try.
> You should fill a ticket on bugs.sugarlabs.org
> cced: Manuel Quiñones, who maintain Browse activity.
>
> Gonzalo
>
>
> On Tue, Aug 6, 2013 at 12:08 PM, Jerry Vonau  wrote:
>
>> Think it's more of a question of looking for confirmation. Is anybody
>> else seeing this behavior on 13.2.0-13 on XO-1s when used with any version
>> of school-servers? I'm at a loss trying to explain why this is occurring to
>> Anna. With the noted behavior where would you file the bug report? OLPC is
>> what I'm thinking but looking if someone else might be impacted also or can
>> confirm this.
>>
>> Jerry
>>
>>
>> On 6 August 2013 05:12, Gonzalo Odiard  wrote:
>>
>>> There are a ticket filled?
>>>
>>> Gonzalo
>>>
>>>
>>> On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau  wrote:
>>>
 Great piece of deductive testing Anna, way to go. Forwarding for
 further investigation.

 Jerry

 -- Forwarded message --
 From: Anna 
 Date: 5 August 2013 15:02
 Subject: [XSCE] Re: Client side Moodle transparent auth broken in
 13.2.0 stable
 To: xsce-devel 


 I just realized that someone will probably ask what's the most recent
 build where Moodle transparent auth did work.  Lucky for me, I just had to
 test one older.  Moodle transparent auth DOES work in 13.2.0-12.

 So whatever broke client side Moodle transparent auth should be
 confined to 13.2.0-13.


 On Mon, Aug 5, 2013 at 2:19 PM, Anna  wrote:

> I very recently upgraded my little herd of XOs to the latest stable
> build 13.2.0-13.  Unfortunately, something in that build has broken
> Moodle's transparent authentication.  When a registered client goes to
> http://schoolserver/moodle, all it gets is the login page.
>
> Now, that's not unheard of, you can usually just click the "Home"
> button and get automatically logged in.  But when I've seen that before,
> the XO's SN is filled out in the Username field on the login page.  The
> 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle
> login page, it never logs in.
>
> To verify it was a client side issue, I flashed an XO-1 with 13.1.0
> stable, and registered first to be admin.  I also registered a 13.2.0-13 
> as
> the second client.  On the 13.1.0, I can go to the Moodle homepage and it
> automatically logged me in.  I tried again to access the Moodle homepage 
> on
> the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin
> XO, I went to Site Administration -> Users -> Accounts -> Browse list of
> users and saw both XOs listed.  It indicated that the 13.2.0-13 client had
> never logged in.
>
> So, the user account is being created on the server for the 13.2.0-13
> XO upon registration, but client side transparent authentication is not
> working.
>
> To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I
> went to
> http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pland
>  the test was successful.
>
> Now, I have successfully tested Moodle transparent auth with previous
> iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that
> broke transparent auth must have been relatively recent.
>
> I took a look at the Browse Activity version between the two clients:
> 13.1.0 = Browse 149
> 13.2.0-13 = Browse 149.3
>
> I knew it wouldn't make a difference, but I also tested the 13.2.0-13
> as first registration and it doesn't care that its the admin user.  And
> also tested with a fresh flash to make sure there wasn't something sticky
> in there from a previous registration gumming things up.
>
> I've tested this with the XSCE installed a couple days ago
> (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I
> also remembered I have an XS 0.6 (duh, Anna) and the results were the 
> same.
>  I don't have an XS 0.7 installation, but I would expect the same results.
>
> Since this is a client side issue, I'm not sure where to go from here
> as far as troubleshooting.
>
> Anna
>



 ___
 Sugar-devel mailing list
 sugar-de...@lists.sugarlabs.org
 http://lists.sugarlabs.org/listinfo/sugar-devel


>>>
>>
>
> ___

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

[Gonzalo Odiard]

I don't have a school server to try.
You should fill a ticket on bugs.sugarlabs.org
cced: Manuel Quiñones, who maintain Browse activity.

Gonzalo


On Tue, Aug 6, 2013 at 12:08 PM, Jerry Vonau  wrote:

> Think it's more of a question of looking for confirmation. Is anybody else
> seeing this behavior on 13.2.0-13 on XO-1s when used with any version of
> school-servers? I'm at a loss trying to explain why this is occurring to
> Anna. With the noted behavior where would you file the bug report? OLPC is
> what I'm thinking but looking if someone else might be impacted also or can
> confirm this.
>
> Jerry
>
>
> On 6 August 2013 05:12, Gonzalo Odiard  wrote:
>
>> There are a ticket filled?
>>
>> Gonzalo
>>
>>
>> On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau  wrote:
>>
>>> Great piece of deductive testing Anna, way to go. Forwarding for further
>>> investigation.
>>>
>>> Jerry
>>>
>>> -- Forwarded message --
>>> From: Anna 
>>> Date: 5 August 2013 15:02
>>> Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0
>>> stable
>>> To: xsce-devel 
>>>
>>>
>>> I just realized that someone will probably ask what's the most recent
>>> build where Moodle transparent auth did work.  Lucky for me, I just had to
>>> test one older.  Moodle transparent auth DOES work in 13.2.0-12.
>>>
>>> So whatever broke client side Moodle transparent auth should be confined
>>> to 13.2.0-13.
>>>
>>>
>>> On Mon, Aug 5, 2013 at 2:19 PM, Anna  wrote:
>>>
 I very recently upgraded my little herd of XOs to the latest stable
 build 13.2.0-13.  Unfortunately, something in that build has broken
 Moodle's transparent authentication.  When a registered client goes to
 http://schoolserver/moodle, all it gets is the login page.

 Now, that's not unheard of, you can usually just click the "Home"
 button and get automatically logged in.  But when I've seen that before,
 the XO's SN is filled out in the Username field on the login page.  The
 13.2.0-13 XO doesn't show that.  No matter what you click on in the Moodle
 login page, it never logs in.

 To verify it was a client side issue, I flashed an XO-1 with 13.1.0
 stable, and registered first to be admin.  I also registered a 13.2.0-13 as
 the second client.  On the 13.1.0, I can go to the Moodle homepage and it
 automatically logged me in.  I tried again to access the Moodle homepage on
 the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin
 XO, I went to Site Administration -> Users -> Accounts -> Browse list of
 users and saw both XOs listed.  It indicated that the 13.2.0-13 client had
 never logged in.

 So, the user account is being created on the server for the 13.2.0-13
 XO upon registration, but client side transparent authentication is not
 working.

 To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I
 went to
 http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pland
  the test was successful.

 Now, I have successfully tested Moodle transparent auth with previous
 iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that
 broke transparent auth must have been relatively recent.

 I took a look at the Browse Activity version between the two clients:
 13.1.0 = Browse 149
 13.2.0-13 = Browse 149.3

 I knew it wouldn't make a difference, but I also tested the 13.2.0-13
 as first registration and it doesn't care that its the admin user.  And
 also tested with a fresh flash to make sure there wasn't something sticky
 in there from a previous registration gumming things up.

 I've tested this with the XSCE installed a couple days ago
 (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I
 also remembered I have an XS 0.6 (duh, Anna) and the results were the same.
  I don't have an XS 0.7 installation, but I would expect the same results.

 Since this is a client side issue, I'm not sure where to go from here
 as far as troubleshooting.

 Anna

>>>
>>>
>>>
>>> ___
>>> Sugar-devel mailing list
>>> sugar-de...@lists.sugarlabs.org
>>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>>
>>>
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

[Jerry Vonau]

Think it's more of a question of looking for confirmation. Is anybody else
seeing this behavior on 13.2.0-13 on XO-1s when used with any version of
school-servers? I'm at a loss trying to explain why this is occurring to
Anna. With the noted behavior where would you file the bug report? OLPC is
what I'm thinking but looking if someone else might be impacted also or can
confirm this.

Jerry

On 6 August 2013 05:12, Gonzalo Odiard  wrote:

> There are a ticket filled?
>
> Gonzalo
>
>
> On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau  wrote:
>
>> Great piece of deductive testing Anna, way to go. Forwarding for further
>> investigation.
>>
>> Jerry
>>
>> -- Forwarded message --
>> From: Anna 
>> Date: 5 August 2013 15:02
>> Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0
>> stable
>> To: xsce-devel 
>>
>>
>> I just realized that someone will probably ask what's the most recent
>> build where Moodle transparent auth did work.  Lucky for me, I just had to
>> test one older.  Moodle transparent auth DOES work in 13.2.0-12.
>>
>> So whatever broke client side Moodle transparent auth should be confined
>> to 13.2.0-13.
>>
>>
>> On Mon, Aug 5, 2013 at 2:19 PM, Anna  wrote:
>>
>>> I very recently upgraded my little herd of XOs to the latest stable
>>> build 13.2.0-13.  Unfortunately, something in that build has broken
>>> Moodle's transparent authentication.  When a registered client goes to
>>> http://schoolserver/moodle, all it gets is the login page.
>>>
>>> Now, that's not unheard of, you can usually just click the "Home" button
>>> and get automatically logged in.  But when I've seen that before, the XO's
>>> SN is filled out in the Username field on the login page.  The 13.2.0-13 XO
>>> doesn't show that.  No matter what you click on in the Moodle login page,
>>> it never logs in.
>>>
>>> To verify it was a client side issue, I flashed an XO-1 with 13.1.0
>>> stable, and registered first to be admin.  I also registered a 13.2.0-13 as
>>> the second client.  On the 13.1.0, I can go to the Moodle homepage and it
>>> automatically logged me in.  I tried again to access the Moodle homepage on
>>> the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin
>>> XO, I went to Site Administration -> Users -> Accounts -> Browse list of
>>> users and saw both XOs listed.  It indicated that the 13.2.0-13 client had
>>> never logged in.
>>>
>>> So, the user account is being created on the server for the 13.2.0-13 XO
>>> upon registration, but client side transparent authentication is not
>>> working.
>>>
>>> To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I
>>> went to
>>> http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pland 
>>> the test was successful.
>>>
>>> Now, I have successfully tested Moodle transparent auth with previous
>>> iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that
>>> broke transparent auth must have been relatively recent.
>>>
>>> I took a look at the Browse Activity version between the two clients:
>>> 13.1.0 = Browse 149
>>> 13.2.0-13 = Browse 149.3
>>>
>>> I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as
>>> first registration and it doesn't care that its the admin user.  And also
>>> tested with a fresh flash to make sure there wasn't something sticky in
>>> there from a previous registration gumming things up.
>>>
>>> I've tested this with the XSCE installed a couple days ago
>>> (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I
>>> also remembered I have an XS 0.6 (duh, Anna) and the results were the same.
>>>  I don't have an XS 0.7 installation, but I would expect the same results.
>>>
>>> Since this is a client side issue, I'm not sure where to go from here as
>>> far as troubleshooting.
>>>
>>> Anna
>>>
>>
>>
>>
>> ___
>> Sugar-devel mailing list
>> sugar-de...@lists.sugarlabs.org
>> http://lists.sugarlabs.org/listinfo/sugar-devel
>>
>>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Re: [Sugar-devel] Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

[Gonzalo Odiard]

There are a ticket filled?

Gonzalo


On Tue, Aug 6, 2013 at 4:27 AM, Jerry Vonau  wrote:

> Great piece of deductive testing Anna, way to go. Forwarding for further
> investigation.
>
> Jerry
>
> -- Forwarded message --
> From: Anna 
> Date: 5 August 2013 15:02
> Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0
> stable
> To: xsce-devel 
>
>
> I just realized that someone will probably ask what's the most recent
> build where Moodle transparent auth did work.  Lucky for me, I just had to
> test one older.  Moodle transparent auth DOES work in 13.2.0-12.
>
> So whatever broke client side Moodle transparent auth should be confined
> to 13.2.0-13.
>
>
> On Mon, Aug 5, 2013 at 2:19 PM, Anna  wrote:
>
>> I very recently upgraded my little herd of XOs to the latest stable build
>> 13.2.0-13.  Unfortunately, something in that build has broken Moodle's
>> transparent authentication.  When a registered client goes to
>> http://schoolserver/moodle, all it gets is the login page.
>>
>> Now, that's not unheard of, you can usually just click the "Home" button
>> and get automatically logged in.  But when I've seen that before, the XO's
>> SN is filled out in the Username field on the login page.  The 13.2.0-13 XO
>> doesn't show that.  No matter what you click on in the Moodle login page,
>> it never logs in.
>>
>> To verify it was a client side issue, I flashed an XO-1 with 13.1.0
>> stable, and registered first to be admin.  I also registered a 13.2.0-13 as
>> the second client.  On the 13.1.0, I can go to the Moodle homepage and it
>> automatically logged me in.  I tried again to access the Moodle homepage on
>> the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin
>> XO, I went to Site Administration -> Users -> Accounts -> Browse list of
>> users and saw both XOs listed.  It indicated that the 13.2.0-13 client had
>> never logged in.
>>
>> So, the user account is being created on the server for the 13.2.0-13 XO
>> upon registration, but client side transparent authentication is not
>> working.
>>
>> To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went
>> to
>> http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pland 
>> the test was successful.
>>
>> Now, I have successfully tested Moodle transparent auth with previous
>> iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that
>> broke transparent auth must have been relatively recent.
>>
>> I took a look at the Browse Activity version between the two clients:
>> 13.1.0 = Browse 149
>> 13.2.0-13 = Browse 149.3
>>
>> I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as
>> first registration and it doesn't care that its the admin user.  And also
>> tested with a fresh flash to make sure there wasn't something sticky in
>> there from a previous registration gumming things up.
>>
>> I've tested this with the XSCE installed a couple days ago
>> (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I
>> also remembered I have an XS 0.6 (duh, Anna) and the results were the same.
>>  I don't have an XS 0.7 installation, but I would expect the same results.
>>
>> Since this is a client side issue, I'm not sure where to go from here as
>> far as troubleshooting.
>>
>> Anna
>>
>
>
>
> ___
> Sugar-devel mailing list
> sugar-de...@lists.sugarlabs.org
> http://lists.sugarlabs.org/listinfo/sugar-devel
>
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel

Fwd: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0 stable

[Jerry Vonau]

Great piece of deductive testing Anna, way to go. Forwarding for further
investigation.

Jerry

-- Forwarded message --
From: Anna 
Date: 5 August 2013 15:02
Subject: [XSCE] Re: Client side Moodle transparent auth broken in 13.2.0
stable
To: xsce-devel 


I just realized that someone will probably ask what's the most recent build
where Moodle transparent auth did work.  Lucky for me, I just had to test
one older.  Moodle transparent auth DOES work in 13.2.0-12.

So whatever broke client side Moodle transparent auth should be confined to
13.2.0-13.


On Mon, Aug 5, 2013 at 2:19 PM, Anna  wrote:

> I very recently upgraded my little herd of XOs to the latest stable build
> 13.2.0-13.  Unfortunately, something in that build has broken Moodle's
> transparent authentication.  When a registered client goes to
> http://schoolserver/moodle, all it gets is the login page.
>
> Now, that's not unheard of, you can usually just click the "Home" button
> and get automatically logged in.  But when I've seen that before, the XO's
> SN is filled out in the Username field on the login page.  The 13.2.0-13 XO
> doesn't show that.  No matter what you click on in the Moodle login page,
> it never logs in.
>
> To verify it was a client side issue, I flashed an XO-1 with 13.1.0
> stable, and registered first to be admin.  I also registered a 13.2.0-13 as
> the second client.  On the 13.1.0, I can go to the Moodle homepage and it
> automatically logged me in.  I tried again to access the Moodle homepage on
> the 13.2.0-13 XO-1, but yep, still just got the login page.  On the admin
> XO, I went to Site Administration -> Users -> Accounts -> Browse list of
> users and saw both XOs listed.  It indicated that the 13.2.0-13 client had
> never logged in.
>
> So, the user account is being created on the server for the 13.2.0-13 XO
> upon registration, but client side transparent authentication is not
> working.
>
> To verify the 13.2.0-13 XO's Browse Activity is accepting cookies, I went
> to
> http://www.bu.edu/htbin/computing/browsers/troubleshooting/cookietest.pland 
> the test was successful.
>
> Now, I have successfully tested Moodle transparent auth with previous
> iterations of 13.2.0, perhaps 8 or 9?  So whatever change on 13.2.0 that
> broke transparent auth must have been relatively recent.
>
> I took a look at the Browse Activity version between the two clients:
> 13.1.0 = Browse 149
> 13.2.0-13 = Browse 149.3
>
> I knew it wouldn't make a difference, but I also tested the 13.2.0-13 as
> first registration and it doesn't care that its the admin user.  And also
> tested with a fresh flash to make sure there wasn't something sticky in
> there from a previous registration gumming things up.
>
> I've tested this with the XSCE installed a couple days ago
> (xs-config-0.8.4.123.gda5e8e3-1) and the latest DXS from this morning.  I
> also remembered I have an XS 0.6 (duh, Anna) and the results were the same.
>  I don't have an XS 0.7 installation, but I would expect the same results.
>
> Since this is a client side issue, I'm not sure where to go from here as
> far as troubleshooting.
>
> Anna
>
___
Devel mailing list
Devel@lists.laptop.org
http://lists.laptop.org/listinfo/devel