buddycloud / buddycloud-tests-framework Goto Github PK

Moreover, I guess that line 38 of buddycloud-tests-framework/blob/master/installation/tests/api_server_connection.py should be

req = Request('HEAD', answer['protocol'] + "://" + answer['domain'] + ":" + str(answer['port']) + answer['path'])

and not

req = Request('HEAD', answer['protocol'] + "://" + answer['domain'] + answer['path'] + ":" + str(answer['port']))

Which would be more pythonic this way if answer really is a dictionnary
req = Request('HEAD', "%(protocol)s://%(domain)s:%(port)s%(path)s" %answer)

https://github.com/buddycloud/buddycloud-tests-framework/blob/master/installation/tests/buddycloud_server_disco.py

Looks like there is an issue with some python certificate checking modules.

For example see http://protocol.buddycloud.com/buddycloud.textras.com

It's no longer possible to enter a URL in mobile Chrome.

(I'm also not sure what the changing text really adds to this).

I edited a few changes into https://github.com/buddycloud/buddycloud-tests-framework/blob/master/templates/index.html already.

• 'Stop' box should align with search box
• Remove 'protocol checker' header
• Log icon should sit next to information icon

Annotated here:

https://buddycloud-inspection.herokuapp.com/buddycloud.org

fails looking for the api.

dig TXT _buddycloud-api._tcp.buddycloud.org +short

returns

"v=1.0" "host=demo.buddycloud.org" "protocol=https" "path=/api" "port=443"

so, it should be working...

http://protocol.buddycloud.com/tp.mu is able to kill it when it can't find the remote server

It's a good policy to ALWAYS wait 5 seconds before reconnecting on any service :)

seen in the [email protected] channel:

[email protected] (and many others) And why is it abusing [email protected] as a test channel?

When a test fails, we should be able to predict the working record that the user needs to add.

https://github.com/buddycloud/buddycloud-tests-framework/blob/master/installation/tests/api_server_connection.py#L22

Should probably include their domain name and a real working record that can fix this.

The S2S port should be returned as part of the SRV lookup (ie - it won't always be port 5269)

See: https://github.com/buddycloud/buddycloud-tests-framework/blob/master/installation/tests/xmpp_server_srv_lookup.py#L13

Some checks with TLS/TLS

• check that only TLS connections are enabled. In other words, check whether you can connect in plaintext and get rejected.
• check that the site presents a valid certificate
• check that the site rejects connections from invalid and self-signed certificates.

You will probably need to use openssl's s_client

openssl s_client -connect buddycloud.org:5222 -starttls xmpp
openssl s_client -connect buddycloud.org:5222 -starttls xmpp -xmpphost buddycloud.org

I guess you want to pretend to be another s2s connection and throw the site an invalid certificate.

@guilhermesgb I'd be happy to talk more about this on the next call.

I commented on #12 but couldn't see how to reopen, so opening this one. When I try to use protocol.buddycloud.com it gets to the buddycloud discovery test but fails. I then see it continually trying to connect for a long time with following message in prosody logs, repeated every 2 seconds or so:

Jul 26 00:31:38 c2s211be60 info Client connected
Jul 26 00:31:38 c2s211be60 info c2s stream for closed: This server does not serve buddycloud.org
Jul 26 00:31:38 c2s211be60 info Client disconnected: connection closed

Can we make it stop after a few attempts please?

This tool just got much more awesome for me. I didn't realise that I could see more info by clicking on the test.

Perhaps have an explicit "show more" button somewhere on each test so that it's obvious.

The check always complains when it's unable to find HTTPS.

But this could be a bigger problem.

EG we got the following record back:

"v=1.0 host=buddycloud.bam.yt protocol=https path=/api port=433"
and
v="1.0 "host=buddycloud.bam.yt "\protocol=https "\path=/api "\port=433"

"Please ensure your API server will run with HTTPS enabled."

Perhaps better to first warn of a malformed record. I mean the record must always have a version, host, protocol, path and port. Without any of those HTTPS or not HTTPS. That's the root cause.

http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=buddycloud

"v=1.0 host=host.example.org"

@abmargb, please document the way that the media server can be discovered so that @guilhermesgb can implement a test for it on the domain.

Now there is no clear indication that the client is receiving such responses.
The tests whose requests to the server are being responded that way should be highlighted in yellow and the user should be warned about it appropriately.

Now they can only know such a thing happened if they open up the console (in Chrome).

EDIT: That is not the problem anymore. If exceptions happen during a test execution, that is being displayed nicely as well. Also if a test is malformed.

But if the server goes down (404) or is unable to serve your request (503) to issue a test, the webclient won't display that properly yet.

If the DNS tests fail at the first try, changes by the admin won't be noticed by the test suite until the TTL expire, which can be counter-intuitive but also limit the usefulness of the test suite.

Tests should bypass the cache and hit directly the responsible nameserver. This can be accomplished with dig +trace.

They appear like the following:

_xmpp-client._tcp.EXAMPLE.COM. 82698 IN SRV 10 0 5222 server.example.com

more details:

http://blog.teemu.im/2008/12/14/setting-your-srv-records-straight-for-xmpp/

It should retry say, 3 times, then give up. Currently it will keep retrying until it gets another response from the server (other than 503).

see new.buddycloud.com/style-guide :)

When testing for surevine.com's setup the channel server disco failed potentially due to a timeout (after checking the tests). It would be worth checking out why the test failed. Requests for me respond in 1 second using xmpp-ftw so it may not be the timeout.

Hi :)
I don't know if you remember me, i setup buddycloud on my domain a few months ago and found out that Cloudflare had problems with doublequotes in TXT records.

I stopped hacking around and sent 2 support requests to Cloudflare. The first request (CF66300) got closed quickly, the supporters weren't able to figure out why it shouldn't be possible and told be this is by design and the standard for DNS servers. In the second request (CF64630) i quoted a few excerpts of the TXT record specification just to clarify that auto-escaping a doublequote is not "by design". A few days later they closed the request telling me a developer would have a look at it.

Isn't it possible to tighten the belt on the TXT record validation and allow singlequotes aswell? It seems like they are atleast not escaping them. (_buddycloud-api._tcp.bam.yt)

I guess we want people to fork the project and then submit new tests via a pull request.

The documentation says we need a record like this:

buddycloud.EXAMPLE.COM.                   IN A            1.2.3.4

First of all, this ditches support for IPv6 completely, which is a shame. Then, it makes it harder to maintain an infrastructure where multiple services are on the same machine. The tests should allow a CNAME here, unless there is a good reason not to.

I couldn't find the standard where this is defined, so bear with me. :)

From the google doc: https://docs.google.com/a/buddycloud.com/spreadsheet/ccc?key=0AsfJyujQqIAJdEkzUE5wWHhSanRCUXpEZWw2M1htU3c#gid=0

lay out the tests with columns:

• Test Class (eg XMPP Server, buddycloud server, API)
• Test (Just use the name from the Google docs)
• Notes (again, just use the text from the Google Doc)
• Text for a positive result (also google doc text)
• Text for a negative result (this is where we need to be able to give the user feedback, for example set the following DNS record and then substitute in the right details)

For example: https://buddycloud-inspection.herokuapp.com/domain-to-be-tested.com

At least for the moment - we have the "Text for a negative result" in https://docs.google.com/a/buddycloud.com/spreadsheet/ccc?key=0AsfJyujQqIAJdEkzUE5wWHhSanRCUXpEZWw2M1htU3c#gid=0 as a way to give feedback to the user.

• I want to test buddycloud.textras.com
• enter the url http://protocol.buddycloud.com/buddycloud.textras.com
• it gets rewritten to http://protocol.buddycloud.com/textras.com
• and we test textras.com

It seems like there is an overly aggressive rewrite happening somewhere in the stack.

entering "movim.eu " from copy-paste fails.

@abmargb found out that the correct format is

"v=1.0 host=socialcoders.buddycloud.com protocol=https path=/api port=443"

not

_buddycloud-api._tcp.socialcoders.buddycloud.com    IN TXT "v=1.0" "host=buddycloud.socialcoders.buddycloud.com" "protocol=https" "path=/api" "port=433"

(but didn't update the install doc or notify the head of protocol testing. :( grrrr. )

We detected you set up the following incorrect API server TXT records.
You must have just one correct API server SRV record.
These are the SRV records we found and their problems: 

This TXT record is malformed.
"v=1.0 host=socialcoders.buddycloud.com protocol=https path=/api port=443"

The API server TXT record must always have a version, host, protocol, path and port.
Each of these properties must be defined within double quotes and separated by spaces only.
For example, assuming that the server running buddycloud will be named: buddycloud.socialcoders.buddycloud.com,
here you are a TXT record that should work:
_buddycloud-api._tcp.socialcoders.buddycloud.com    IN TXT "v=1.0" "host=buddycloud.socialcoders.buddycloud.com" "protocol=https" "path=/api" "port=433"

Please not that your API server TXT record won't be correct until it contains proper information regarding the version, host, protocol, path and port.
See https://buddycloud.org/wiki/Install#buddycloud_DNS for more information.

At surevine.com we've got user registration turned off and none of the test users installed. I still see the following tests passing which shouldn't/couldn't:

• create_test_user_channel_followers source
  • Could successfully assert creation or existance of some user channels: [email protected] | [email protected] | [email protected] | [email protected]
• create_test_topic_channel source
  • Could successfully assert creation or existance of some topic channels: [email protected]
• create_test_user_channel_not_following source
  • Could successfully assert creation or existance of some user channels: [email protected]

could you set this up as protocol.buddycloud.com
@rodrigods or @abmargb should be able to help you create the DNS that works with Heroku: https://devcenter.heroku.com/articles/custom-domains

Hosting lets you use ptr records. (http://buddycloud.github.io/buddycloud-xep/#DNS-discovery).

The tests currently fail badly due to no PTR checking (assuming disco is working).

EG: protocol.buddycloud.com/imaginator.com

@abmargb can you show Guilherme how the PTR lookup works please.

I see the following in an (unrelated server's) logs:

Jul 15 16:26:56 c2s1f69fc0 info c2s stream for <54.234.13.21> closed: This server does not serve buddycloud.org
Jul 15 16:26:56 c2s1f69fc0 info Client disconnected: connection closed
Jul 15 16:26:58 c2s2217720 info Client connected

For example, the test for the pusher, installation/tests/push_server_disco.py should show how to add the DNS record for the pusher.