*OFFICIAL* Pod Runners, Federation Update -- Friday, Sept. 16 -- 9:00AM PDT -- 6:00PM CEST -- 9:30 PM IST

[Ilya Z]

Hey Everyone (especially Pod Runners),

Over the last two weeks we've been working on updating nitty gritty details of our federation protocol (Thanks Mike Macgirvin, for pointers for improvement). 

We've done three things:

1) Updated our "salmon" implementation to batch public posts (making "Diaspora HQ" psots less costly and giving us a path forward for accepting comments from Friendika [and other federated social networks] on public posts.)

2) Updated Base64 encoding to not contain new lines (allowing federation between pods running on Ruby 1.9.2)

3) Updated the signature algorithm for relay-able objects to match that of our Salmon implementation

All three of these updates will not be backwards compatible, so we will be rolling them up into one update (branch:federation_update). It would be good to update at the same time. We we're going to do it on:

 Friday, September 16 -- 9:00AM PDT -- 6:00PM CEST -- 9:30 PM IST

Let us know if this is problematic.

Thanks,

Ilya

[Mike Macgirvin]

Bad timing for me, but I recognise the need and there's no better time
to fix protocol stuff than the present. Go for it, but Friendika will
have to lag until after the weekend (I'm a day ahead of you, so it's not
so bad).

Is there any information you can provide about this "batched salmon"?
Such as - is there a new "public endpoint" to accept it? Or do we just
take the message from the first recipient and copy to any other listeners?

And you might have a look at http://dfrn.org/zot-protocol.txt - which is
my current take on a possible path to future protocol federation. (A
clean superset of salmon with encryption and batching which could
accommodate Diaspora xml messages, ActivityStreams, and eventually MIME
email formats into a common web delivery system).

There's a discussion forum at googlegroups/zot-dev

[Ryan Hughes]

Did someone or will someone update the protocol documentation on the wiki?

Sorry I've been out of the action for awhile. I've had some other projects heating up. But I can update the wiki to reflect this change, if nobody else wants to and/or has done it already.

--Ryan

Ilya Z <il...@joindiaspora.com> wrote:

--
You received this message because you are subscribed to the Google Groups "diaspora-dev" group.
To post to this group, send email to diaspo...@googlegroups.com.
To unsubscribe from this group, send email to diaspora-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/diaspora-dev?hl=en.

[Daniel Grippi]

Mike (et. al) --

Batching is not specific to our salmon implementation.  We're working on a few upgrades to how we federate data, and it seems like two different improvements got rolled into "1) batched salmon."

Some clarification:

Changes to our salmon "implementation"

For salmon objects pertaining to public posts, we will be abiding more closely to the salmon spec, and will not be using the encryption scheme currently in place.  We have broken our salmon slaps into two different parts:  An implementation which is closer to the salmon spec, then our encrypted implementation on top of that.  Creating a delineation between these two methods will make it easier to understand what's happening in our salmon implementation.  It's currently a work in progress, but you can find the two files here:

https://github.com/diaspora/diaspora/blob/master/lib/salmon/slap.rb (unencrypted headers/payloads)

https://github.com/diaspora/diaspora/blob/master/lib/salmon/encrypted_slap.rb (encrypted headers/payloads)

(note: our divergence from the salmon spec will live in encrypted_slap)

Our change to batch federated messages

Currently, we're working on getting our dispatching logic to only send a single instance of a public message to a receiving installation.  When a user creates a message, she will dispatch N messages, given N servers.  The receiving servers will deal with who should receive the message, given the post author and who on that server is sharing with the author.  This is going to be a huge improvement over what we currently do, which is a user dispatching P messages to P users (at least for right now, p >> n).

This 'batched message' change means we're making another receive hook for public messages (we are not batching private posts in this revision).  We have yet to make the batch receive route, but will fill you in once we put it into code.

Future revisions to federation will include batching private data as well, but we're not quite there yet, and we're taking it one step at at time.  Public posts seem to generate much higher HTTP traffic at this point in writing, so batching these messages are going to give us the biggest gain.

I hope this wasn't too confusing.

d

[Mike Macgirvin]

On 14/09/2011 1:20 AM, Daniel Grippi wrote:
> This 'batched message' change means we're making another receive hook

> for *public messages* (we are not batching private posts in this

> revision). We have yet to make the batch receive route, but will fill
> you in once we put it into code.
>

This was really the important question. I need to add a bit of code on
our end to duplicate this receive hook (and publish to it going out to
Diaspora), and will require either the relative path from the server
root that I need to provide or a means of dynamic discovery.

>
> https://github.com/diaspora/diaspora/blob/master/lib/salmon/slap.rb (unencrypted headers/payloads)
> https://github.com/diaspora/diaspora/blob/master/lib/salmon/encrypted_slap.rb (encrypted headers/payloads)
> (note: our divergence from the salmon spec will live in encrypted_slap)

As I'm reading this, it appears we're going to get something like this
(on the unencrypted version):

<?xml version='1.0' encoding='UTF-8'?>
<entry xmlns='http://www.w3.org/2005/Atom'>
<header>
<iv>#{iv}</iv>
<aes_key>#{aes_key}</aes_key>
<author>
<name>#{@author.name}</name>
<uri>acct:#{@author.diaspora_handle}</uri>
</author>
</header>
#{@magic_sig.to_xml}
</entry>

This isn't a salmon. But it's not an atom either.

First of all there is no "header" in the 2005/Atom namespace (just as
there was no "encrypted_header" either). This should really have a
different namespace. A strict parser is going to spit the dummy.

But it's all wrong because there's no atom in this packet at all (though
I haven't dug all the way through this iteration of magic_sig.to_xml).

Also if there is no encryption, what is this iv and aes_key and why are
they here?

These nits aside, I'm guessing my "Diaspora public salmon endpoint"
should just accept a Diaspora packet like before, except the actual
payload is unencrypted - and I look for the author in atom:header
instead of atom:encrypted_header ?

[Ilya Z]

Ooops just realized that I didn't reply to the entire list.

---------- Forwarded message ----------
From: Ilya Z <il...@joindiaspora.com>
Date: Wed, Sep 14, 2011 at 3:32 PM
Subject: Re: [D*] *OFFICIAL* Pod Runners, Federation Update -- Friday, Sept. 16 -- 9:00AM PDT -- 6:00PM CEST -- 9:30 PM IST
To: Mike Macgirvin <mi...@macgirvin.com>

Hi Mike,

Thanks for the feedback! Absolutely agreed, the xml that we're sending is definitely not in Atom format. Here are the things we're going to do before Friday:

1) Fixup the XML: 

• Removing the the Atom namespace from the root node.
• Namespacing our custom headers as diaspora:header and diaspora:encrypted_header (for public salmon and encrypted salmon respectively). 
• Changing data's type from 'application/atom+xml' to type="application/xml", since our serialization method is also not Atom. 

2) Remove the AES key field from the Public Salmon slap, since we're definitely aren't using it.

3) Removing the author node from both headers and instead using author_id, as the identifier for the sender.

So, the resulting xml entries should be:

------ Public Salmon ------

<?xml version='1.0' encoding='UTF-8'?>

<entry>

<diaspora:header xmlns:diaspora='https://github.com/diaspora/diaspora/wiki/Diaspora%27s-federation-protocol'>

     <author_id>#{@author.diaspora_handle}</author_id>

</diaspora:header>

<me:env xmlns:me="http://salmon-protocol.org/ns/magic-env">

    <me:encoding>base64url</me:encoding>

    <me:alg>RSA-SHA256</me:alg>

    <me:data type="application/xml">base64url-encoded prepared payload message</me:data>

    <me:sig>signature</me:sig>

</me:env>

</entry>

------ Encrypted Salmon ------

<?xml version='1.0' encoding='UTF-8'?>

<entry>

<diaspora:encrypted_header xmlns:diaspora='https://github.com/diaspora/diaspora/wiki/Diaspora%27s-federation-protocol'> RSA encrypted(

<diaspora:header xmlns:diaspora='https://github.com/diaspora/diaspora/wiki/Diaspora%27s-federation-protocol'>

     <iv>#{iv}</iv>

     <aes_key>#{aes_key}</aes_key>

     <author_id>#{@author.diaspora_handle}</author_id>

</diaspora:header>

)

</diaspora:encrypted_header>

<me:env xmlns:me="http://salmon-protocol.org/ns/magic-env">

    <me:encoding>base64url</me:encoding>

    <me:alg>RSA-SHA256</me:alg>

    <me:data type="application/xml">AES encrypted(base64url-encoded prepared payload message)</me:data>

    <me:sig>signature</me:sig>

</me:env>

</entry>

We'd love any feedback.

To answer your interop. question, we'll POST the above 'public' XML to 'receive/public'. This route is currently hardcoded, but will live in webfinger profile.

As outlined both here and on other federated mailing lists here are some more improvements that should happen in future protocol refactors: 

1) removing the double base64 encoding

2) changing the key format from PKCS#1 to PKCS#8 

3) making sure RSA signature algorithm (low level one) is run on emsa formated string. 

OpenSSL's "RSA_PKCS1_PADDING" in RSA_private_encrypt (http://www.openssl.org/docs/crypto/RSA_private_encrypt.html

) method is not sufficient since it does not include the include the prefix ([0x30, 0x31, 0x30, 0xd, 0x6, 0x9, 0x60, 0x86, 0x48, 0x1, 0x65, 0x3, 0x4, 0x2, 0x1, 0x5, 0x0, 0x4, 0x20]) before signing. Is this correct?

These are ordered in terms of perceived difficulty. As far as priority, changing the format for the keys seems to be the highest, since it's the highest barrier to entry blocker for federation. Let us know if there is anything else for future protocol refactors.

Thanks,

Ilya

[Mike Macgirvin]

Thanks - This gives me enough information to work with, and fixes a lot
of stuff.

The only problem I'm seeing now is with 'entry' in the XML, since it has
no namespace at all. We don't know for sure what an 'entry' is and
whether or not it's something we are able to process. Perhaps something
like the following (I'm typing this in by hand, there may be typos).

The top level term doesn't have to be 'diaspora', it could be 'xml' or
anything you want. It could even be 'entry'. The entire XML document now
defaults to your namespace and makes the content hierarchy clear both to
machines and to humans who may read it.

I'd probably recommend using a namespace identifier that doesn't belong
to somebody else's website unless it's purl.org. This doesn't have to
resolve. Sure, you can use a github page if you want, but you're
building something which could be around for years. Put some thought
into this. It could end up being hard-coded into a lot of parsers.

------ Public Salmon ------

<?xml version='1.0' encoding='UTF-8'?>

<diaspora xmlns="http://joindiaspora.com/protocol"
xmlns:me="http://salmon-protocol.org/ns/magic-env">

<!--
now you can do a plain Diaspora header (or encrypted_header)
as the entire document by default is in the
https://joindiaspora.com/protocol (or whatever) namespace
-->

<header>
<author_id>#{@author.diaspora_handle}</author_id>
</header>

<!-- the me namespace is already defined -->
<me:env>

<me:encoding>base64url</me:encoding>
<me:alg>RSA-SHA256</me:alg>
<me:data type="application/xml">base64url-encoded prepared payload
message</me:data>
<me:sig>signature</me:sig>
</me:env>

</diaspora>

[Mike Macgirvin]

As a separate followup...

On 15/09/2011 8:32 AM, Ilya Z wrote:
> As outlined both here and on other federated mailing lists here are some
> more improvements that should happen in future protocol refactors:
>
> 1) removing the double base64 encoding

(And if possible the double url encoding on posted data).

> 2) changing the key format from PKCS#1 to PKCS#8

Diaspora may get more mileage in terms of federation by providing salmon
(modulus,exponent) keys. Full OStatus federation will require this. I
believe Ruby gives you access to these low-level key details, whereas we
have to rip apart the ASN.1 block in PHP to get to them.

But if you do publish a DER/PEM key (these are easier for many systems
to work with), pkcs#8 is a better choice than pkcs#1.

> 3) making sure RSA signature algorithm (low level one) is run on emsa
> formated string.
>
> OpenSSL's "RSA_PKCS1_PADDING" in RSA_private_encrypt
> (http://www.openssl.org/docs/crypto/RSA_private_encrypt.html
> ) method is not sufficient since it does not include the include the
> prefix ([0x30, 0x31, 0x30, 0xd, 0x6, 0x9, 0x60, 0x86, 0x48, 0x1, 0x65,
> 0x3, 0x4, 0x2, 0x1, 0x5, 0x0, 0x4, 0x20]) before signing. Is this correct?

I've checked and Ruby's RSA signing method does the right thing. Don't
worry about these bits - they're already inside openssl as long as you
invoke the SHA256 hash method on the sign function.

It might be a good time to consider versioning the protocol so that
protocol transitions can be made painlessly behind the scenes. As the
number of nodes increase, "federated fridays" are going to be
increasingly impractical. This won't solve level 1 security threats, but
other changes could be rolled out at any time without impacting anybody
at all.

[Ilya Z]

Hey Mike,

Just updated the salmon. Just for reference here is a example of what we're going to be sending:

--- Public Salmon ----

    <?xml version='1.0' encoding='UTF-8'?> 

    <diaspora xmlns="https://joindiaspora.com/protocol" xmlns:me="http://salmon-protocol.org/ns/magic-env">

      <header>    <author_id>alice@localhost:9887</author_id>

</header>

      <me:env>

  <me:data type='application/xml'>ICAgICAgPFhNTD4KICAgICAgPHBvc3Q-PHN0YXR1c19tZXNzYWdlPgogIDxyYXdfbWVzc2FnZT5oaTwvcmF3X21lc3NhZ2U-CiAgPGd1aWQ-OTk5OGNiZmY1YTdlMGRkMjwvZ3VpZD4KICA8ZGlhc3BvcmFfaGFuZGxlPmFsaWNlQGxvY2FsaG9zdDo5ODg3PC9kaWFzcG9yYV9oYW5kbGU-CiAgPHB1YmxpYz5mYWxzZTwvcHVibGljPgogIDxjcmVhdGVkX2F0PjIwMTEtMDktMTUgMjM6Mjg6NDAgVVRDPC9jcmVhdGVkX2F0Pgo8L3N0YXR1c19tZXNzYWdlPjwvcG9zdD4KICAgICAgPC9YTUw-Cg==</me:data>

  <me:encoding>base64url</me:encoding>

  <me:alg>RSA-SHA256</me:alg>

  <me:sig>ShsQqfatowPfiSgD0R4WEOzckwKNVOEDErerVI9T1Nikqc9pS8NtxLFe7kY5qDnVZnpKYLSCdQ0MGc_2XzBMMPdz2z-aKYbEmStwEszZ3n9eT0gmtwPpSKNbEH8uik1AuFDWi5lZyaJWecwgisXCy5jNHE7M7DPZNNn96HmOYB0=</me:sig>

  </me:env>

    </diaspora>

--- Encrypted Salmon ---------

    <?xml version='1.0' encoding='UTF-8'?> 

    <diaspora xmlns="https://joindiaspora.com/protocol" xmlns:me="http://salmon-protocol.org/ns/magic-env">

              <encrypted_header>

          eyJjaXBoZXJ0ZXh0IjoielY0ckltZ3NnQTZZTUxyNXZxbDNnNzVYakxhWm55VDg3c3lWTktYQ3A5ZlFWM040NHpBRDR1bGlCcmMwWFNTRnluOUV3SmFzbjJhMThlR2dvbVBsS2dLa1Z3Vm9SVytvdDRDRlIxVVRkRDNRSHZ1cHFSRzhQUVFGWkdGV3FDeVRYQWJKSTNldFVuKzRXdEYraHJsb3RNdWNvcUZMazlVZVl1dkVkVWM3QTM1V2F1cHk1aGNXRFlVMlZDK0Qrb0x3ZmJwZnZsQzZrcTRVUkpnV3ZxYXFRVEFuVnI1dy93dXA0WXNtZHdyYnJqZ29UQnk4SVgzTC9JVUxJck9IelBjZkVULytHa0I1Y2o3UXhQbGpDU1hsdVE9PSIsImFlc19rZXkiOiJOY0lyc3h5anZjMnpHWVlqT3g5djdkazdGWURHNjZkVFBOVWlLV2lrVE9CaHd4QzhTYjlBa0p5M1FxK1JZNTZ1YnJmd2p1bVJGOG04ZjhpT0prRERvbHUzeDZEcysxdEJrSXRjQXdCVjEwZDJ1dUEvOXVpTEZINC9rUjFid25IVHhwbkY0ZTNMaWtFN3ZYdEptd3l6bHdNc3poZFJPTmRNakh1M212YkIvems9In0=

        </encrypted_header>

      <me:env>

  <me:data type='application/xml'>ZlU3VlJOSXYzdFIxMWdhT0pOSmptZXRpY0VEMU1KeTVab2NmTDFHd3h1TWdpRmtKc3RXbDV5VXZHNmdMUUY4WDZCUVBTck1hUnlBQnUyNS9aUEp6UW1oS2lrSWV0VzN0bngxaUdyOVZQMFY5U3NPT2c4QytBT3NYY3FzNDlWeFI3QTRCS3RzWWdDQzRKTVVlR0FRZm1ZaGdYbFZ2cXVFVWlQZ2twWmdsZzhQMWpka1oxcXJ2ZTh2VEUzVlMxM0oxVTlmMldtOWl0ZCtDdFM2blFhMFc2T1VSTFdCeWZlN2xmU0ZRY3BtM1FnOG9pQlQ1VEJhNU5YSlJXbXBrYVlWMVpScGJKWjA5VjNNSmFRVElmWXR5S3ZoM3VmMUFrVnJtWDQ5dTFmM1FlakJnNlYzQW15TTRGNUh1eWZ6WTFxcEpvd0ZEOGtDdDhaSzdjWDVQSGJVYUFubTltYW0zYkl3bVlINzhzNXhFL2ZObldFdmhJdlA4QWphaGdKQXNod3dh</me:data>

  <me:encoding>base64url</me:encoding>

  <me:alg>RSA-SHA256</me:alg>

  <me:sig>agvzvQotz6SrRZdMSaCQgEwn5iGQjSpXoahS9LOoChiL_hQC-GK8CUFPrMXwjmBxiCkqyjJR0Ro3sliJtpVavMWvklGx-IsFTuasItt5wUN1m_tZF4C1Jp_yYV-8Z0fiY83Sb6jk-a-E0UV9Q4P7ExnOx44RwWqcTkHgWNVQ06Y=</me:sig>

  </me:env>

    </diaspora>

We still need to strip "=" at the end of lines, but this can be rolled out later without federation breaking. 

Best,

Ilya

[Mike Macgirvin]

Just made a few last minute adjustments and I think we're good to go.

[Disconnect]

I'd be a lot more comfortable about updating if CI wasn't red and
severely outdated.. (Sept 4)

On Thu, Sep 15, 2011 at 8:50 PM, Mike Macgirvin <mi...@macgirvin.com> wrote:
> Just made a few last minute adjustments and I think we're good to go.
>

[Christophe]

Have a look here:

http://travis-ci.org/#!/diaspora/diaspora

[Sarah Mei]

Ah, yes, I should have anounced to the list - I migrated our CI to Travis last weekend.

Sarah

[Jonne Hass]

We should redirect ci.joindiaspora.com to Travis.

[Sarah Mei]

Actually, there are a few features that Travis is too underpowered to run, so I'm going to convert our old CI box to run only those. I'll modify the front page on ci.joindiaspora.com to point people to Travis, though, for the "official" build status.

On Friday, September 16, 2011, Jonne Hass <list-...@mrzyx.home.kg> wrote:
> We should redirect ci.joindiaspora.com to Travis.
>
> Am 16.09.2011 15:16, schrieb Sarah Mei:
>
> Ah, yes, I should have anounced to the list - I migrated our CI to Travis last weekend.
>
> Sarah
>
> On Friday, September 16, 2011, Christophe <chris...@wk3.org> wrote:
>> Have a look here:
>>

>> http://travis-ci.org/#!/diaspora/diaspora <http://travis-ci.org/#%21/diaspora/diaspora>

>>
>> On Fr 16 Sep 2011 15:10:33 CEST, Disconnect wrote:
>>>
>>> I'd be a lot more comfortable about updating if CI wasn't red and
>>> severely outdated.. (Sept 4)
>>>
>>> On Thu, Sep 15, 2011 at 8:50 PM, Mike Macgirvin<mi...@macgirvin.com>  wrote:
>>>>
>>>> Just made a few last minute adjustments and I think we're good to go.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups "diaspora-dev" group.
>>>> To post to this group, send email to diaspo...@googlegroups.com.

>>>> To unsubscribe from this group, send email to diaspora-dev...@googlegroups.com <diaspora-dev%2Bunsu...@googlegroups.com>.

>>>> For more options, visit this group at http://groups.google.com/group/diaspora-dev?hl=en.
>>>>
>>>>
>>>
>>
>> --
> You received this message because you are subscribed to the Google Groups "diaspora-dev" group.
> To post to this group, send email to diaspo...@googlegroups.com.
> To unsubscribe from this group, send email to diaspora-dev...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/diaspora-dev?hl=en.
>
> --
> You received this message because you are subscribed to the Google Groups "diaspora-dev" group.
> To post to this group, send email to diaspo...@googlegroups.com.

> To unsubscribe from this group, send email to diaspora-dev...@googlegroups.com <diaspora-dev%2Bunsu...@googlegroups.com>.

[Ilya Z]

Hey Everyone,

For those of you who haven't updated yet, you should:

1) Stop your app servers and let the workers finish processing your queues. (We renamed a couple of things and resque jobs call the method names with which they were queued getting the latest master will error with method not found.)

2) Get the latest master and bundle and boot everything up

Hope this helps,

Thanks,

Ilya

[Loïc Guitaut]

Done! And it’s great, federation is working correctly on ruby 1.9.2 :)

PS: Could you delete the fl...@social.belfalas.org profile existing on
joindiapora.com please? It is totally out of sync, and so I can’t add
people from joindiaspora :/ (Since the feature we discussed on IRC with
MrZYX about crawling to keep remote profiles in sync doesn’t exist for
now ;))

Le 16/09/2011 19:56, Ilya Z a écrit :
> Hey Everyone,
>
> For those of you who haven't updated yet, you should:
>
> 1) Stop your app servers and let the workers finish processing your
> queues. (We renamed a couple of things and resque jobs call the method
> names with which they were queued getting the latest master will error
> with method not found.)
> 2) Get the latest master and bundle and boot everything up
>
> Hope this helps,
> Thanks,
>
> Ilya
>
> On Fri, Sep 16, 2011 at 6:54 AM, Sarah Mei <sa...@joindiaspora.com
> <mailto:sa...@joindiaspora.com>> wrote:
>
> Actually, there are a few features that Travis is too underpowered
> to run, so I'm going to convert our old CI box to run only those.
> I'll modify the front page on ci.joindiaspora.com

> <http://ci.joindiaspora.com> to point people to Travis, though, for

> the "official" build status.
>
> On Friday, September 16, 2011, Jonne Hass <list-...@mrzyx.home.kg

> <mailto:list-...@mrzyx.home.kg>> wrote:
> > We should redirect ci.joindiaspora.com

> <http://ci.joindiaspora.com> to Travis.

> >
> > Am 16.09.2011 15:16, schrieb Sarah Mei:
> >
> > Ah, yes, I should have anounced to the list - I migrated our CI to
> Travis last weekend.
> >
> > Sarah
> >
> > On Friday, September 16, 2011, Christophe <chris...@wk3.org

> <mailto:chris...@wk3.org>> wrote:
> >> Have a look here:
> >>
> >>
> http://travis-ci.org/#!/diaspora/diaspora <http://travis-ci.org/#%21/diaspora/diaspora>
>
> >>
> >> On Fr 16 Sep 2011 15:10:33 CEST, Disconnect wrote:
> >>>
> >>> I'd be a lot more comfortable about updating if CI wasn't red and
> >>> severely outdated.. (Sept 4)
> >>>
> >>> On Thu, Sep 15, 2011 at 8:50 PM, Mike
> Macgirvin<mi...@macgirvin.com <mailto:mi...@macgirvin.com>> wrote:
> >>>>
> >>>> Just made a few last minute adjustments and I think we're good
> to go.
> >>>>
> >>>> --
> >>>> You received this message because you are subscribed to the
> Google Groups "diaspora-dev" group.
> >>>> To post to this group, send email to

> diaspo...@googlegroups.com <mailto:diaspo...@googlegroups.com>.

> >>>> To unsubscribe from this group, send email to
> diaspora-dev...@googlegroups.com

> <mailto:diaspora-dev%2Bunsu...@googlegroups.com> <diaspora-dev%2Bunsu...@googlegroups.com
> <mailto:diaspora-dev%252Buns...@googlegroups.com>>.

>
> >>>> For more options, visit this group at
> http://groups.google.com/group/diaspora-dev?hl=en.
> >>>>
> >>>>
> >>>
> >>
> >> --
> > You received this message because you are subscribed to the Google
> Groups "diaspora-dev" group.
> > To post to this group, send email to diaspo...@googlegroups.com

> <mailto:diaspo...@googlegroups.com>.

> > To unsubscribe from this group, send email to
> diaspora-dev...@googlegroups.com

> <mailto:diaspora-dev%2Bunsu...@googlegroups.com>.

> > For more options, visit this group at
> http://groups.google.com/group/diaspora-dev?hl=en.
> >
> > --
> > You received this message because you are subscribed to the Google
> Groups "diaspora-dev" group.
> > To post to this group, send email to diaspo...@googlegroups.com

> <mailto:diaspo...@googlegroups.com>.

> > To unsubscribe from this group, send email to
> diaspora-dev...@googlegroups.com

> <mailto:diaspora-dev%2Bunsu...@googlegroups.com> <diaspora-dev%2Bunsu...@googlegroups.com
> <mailto:diaspora-dev%252Buns...@googlegroups.com>>.

>
> > For more options, visit this group at
> http://groups.google.com/group/diaspora-dev?hl=en.
> >
>
> --
> You received this message because you are subscribed to the Google
> Groups "diaspora-dev" group.
> To post to this group, send email to diaspo...@googlegroups.com

> <mailto:diaspo...@googlegroups.com>.

> To unsubscribe from this group, send email to
> diaspora-dev...@googlegroups.com

> <mailto:diaspora-dev%2Bunsu...@googlegroups.com>.

> For more options, visit this group at
> http://groups.google.com/group/diaspora-dev?hl=en.
>
>
> --
> You received this message because you are subscribed to the Google
> Groups "diaspora-dev" group.
> To post to this group, send email to diaspo...@googlegroups.com.
> To unsubscribe from this group, send email to
> diaspora-dev...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/diaspora-dev?hl=en.

--
,= ,-_-. =. Loïc Guitaut
((_/)o o(\_)) http://www.belfalas.org
`-'(. .)`-' Jabber ID : Fl...@im.apinc.org
\_/ GnuPG KeyID : 0xA78CD85D

[Michael Scheffler]

Hi all,

I wanted to update my pod an ran into big problems with mysql2. I did
eveything as usual, git pull, bundle install, migrated db. But if I want
to start the sever I only get:
Starting server on /tmp/thin.0.sock ...
/usr/lib64/ruby/gems/1.8/gems/activerecord-3.0.10/lib/active_record/connection_adapters/abstract/connection_specification.rb:71:in
`establish_connection_without_activerecord_import': Please install the
mysql2 adapter: `gem install activerecord-mysql2-adapter` (no such file
to load -- active_record/connection_adapters/mysql2_adapter) (RuntimeError)

So ... I uninstalled all mysql2-versions, tried bundle install again,
same problem. Updated mysql2 to 0.2.7 in Gemfile (found via google),
same problem again. I can't start my pod :/

Anyone knows this problem and a solution? It's really urgend, because
nobody can use the pod right now :(

Kind Regards,
Micha

[Michael Scheffler]

Ok, found the answer: I forgot to merge db: "mysql" into my
script_server.yml. Stupid me!

Nevertheless an error-message would be fine ;)

- Micha

[Jonne Hass]

Try updating your config/script_server.yml with the new db setting.

Michael Scheffler <du...@duke.de> schrieb:

>>>> http://travis-ci.org/#!/diaspora/diaspora<
>> http://travis-ci.org/#%21/diaspora/diaspora>

>>
>>>>
>>>> On Fr 16 Sep 2011 15:10:33 CEST, Disconnect wrote:
>>>>>
>>>>> I'd be a lot more comfortable about updating if CI wasn't red and
>>>>> severely outdated.. (Sept 4)
>>>>>
>>>>> On Thu, Sep 15, 2011 at 8:50 PM, Mike Macgirvin<mi...@macgirvin.com>
>>   wrote:
>>>>>>
>>>>>> Just made a few last minute adjustments and I think we're good to go.
>>>>>>
>>>>>> --
>>>>>> You received this message because you are subscribed to the Google
>> Groups "diaspora-dev" group.
>>>>>> To post to this group, send email to diaspo...@googlegroups.com.

>>>>&
 gt;>
To unsubscribe from this group, send email to

[Jonne Hass]

Whoops didn't read your second mail :)

Jonne Hass <list-...@mrzyx.home.kg> schrieb: