- ripe-atlas - mailman.ripe.net

[atlas]Simple way to open API access?
by Richard L. Barnes 24 Mar '11

24 Mar '11

Hey all, Suggestion for a simple way to provide some basic automated access to ATLAS data: It's pretty clear from the traffic that the site is driven off a set of JSON APIs [1]. This would make it pretty easy to write scripts that can access information from the site -- except that the script would need to have a Cookie for a valid user session. So it seems like a simple way to open access up would be to allow developers to access these JSON APIs, but with a different form of authentication. Namely, you could grant developers an "API key" that would function in the same way as a 'stat-session' cookie (in particular it would be bound to a developer identity/email), but would last indefinitely. This wouldn't really put any burden on the NCC other than to have a page to register the API keys. It would be helpful to document the APIs, but not strictly necessary, since JSON is so verbose. And you wouldn't necessarily have any additional requirements for the APIs to be stable, if this feature were properly marked as experimental/undocumented. Noting that the other cookie that the ATLAS page sets is "csrftoken" (which would probably have to be ignored in API key requests), it is worth noting that there is some risk with this approach that a bad developer will use this mechanism to enable CSRF attacks. But such attacks should be fairly easy to recognize, and if one is, then the relevant developer can be turned off. Just a thought, --Richard [1] For example <http://atlas.ripe.net/atlas/publicprobesgrid.json>

3 3

[atlas]New Atlas Features
by Andreas Strikos 07 Mar '11

07 Mar '11

Dear Hosts, We've now enabled two features that were requested by hosts earlier: 1. The "Probe DNS" function allows you to ask for a DNS entry for you probe. Operational details: * The exact DNS name of your probe depends on your settings (simple or obfuscated), and can be looked up on the "Probe Conf" section of the probe status page. * The zone file is re-generated every 15 minutes. * The resulting address is the one we observe when the probe to connects to our infrastructure, so if you're using NAT then it's the public address of the NAT device. Currently it's either IPv4 or IPv6, but not both. We'll add the "other address" too in the future. 2. The probe uptime section has more details. It now contains: * Relative uptime for the last week and month, and for the full lifetime. * The source IP address of the individual connections. * The amount of up- and downtime (in days/hours/minutes), for each connection. Regards, Andreas

2 1

[atlas]too many disconnects?
by Wilfried Woeber, UniVie/ACOnet 07 Mar '11

07 Mar '11

[my apologies to the Team for the duplicate, I 1st picked the wrong address] Q to the Team and to the Probe Hosts: My feeling is that the probes do register too many "disconnects". I just had a look at the two under my control and the numbers of transitions are - 466: 25 events between 2010-12-21 07:14:30 UTC and 2011-03-01 10:24:11 UTC 414: 25 events between 2010-11-22 12:31:02 UTC and 2011-02-20 20:18:24 UTC While there may be a local reason for some of the down-periods, I doubt that I had so many outages on my ends. Is anyone else seeing a similar pattern? Regarding presentation, again, could we please have an additional item of "Total Downtime" (next to the "Total Uptime"), and the duration of the downs in the 25 lines with the time stamps? This would make it much more straight- forward to spot patterns.... Minor cosmetics, relevant when reporting stuff, could the probe's number be displayed somewhere in the Probe Conf panel (e.g. in the line with the Firmware Version)? Thanks for your consideration, have a nice weekend Wilfried

3 2

[atlas]Atlas website upgrades
by Andreas Strikos 02 Mar '11

02 Mar '11

Hi, Today, in sync with the new Ripe NCC website we are upgrading Ripe Atlas website. You might encounter strange behaviors on some pages but we believe until the end of the day they will be fixed. Except from the template, there are some other changes in UI like a new tab for public probes and a bigger settings button. Also, from now on there will be an announcement page where you can read the latest information about Atlas. Regards, Andreas

4 3

[atlas]Down/Up fail
by Richard L. Barnes 16 Feb '11

16 Feb '11

Hey guys, I've just been re-engineering my home network to give probe 394 more stable access. It seems that the ATLAS web site still reports it as "down" even though it's clearly reporting information to the central system (since the RRD graphs are updated). Huh? --Richard

2 2

[atlas]Strange behaviour of probe
by Patrick Vande Walle 31 Jan '11

31 Jan '11

Hello Robert, According to the graphs on atlas.ripe.net, my probe (#45) seems to have been offline for nearly 24 hours. During that period, the DSL connection was up nevertheless. Are there more detailed logs on the probe controller that could explain what happened ? Thanks, Patrick Vande Walle

2 1

[atlas]Some new UI features
by Robert Kisteleki 13 Jan '11

13 Jan '11

Hello, We've added some changes to the UI yesterday. From now on upon registering a new probe, or changing its attributes (from the probe status page) the host can set the following additional information: * Router type: optional, describes the router/NAT model you have, mainly in a home installation. This information could be useful for us to correlate weird probe behavior across similar router models. * Allowed bandwidth: it's not used yet, but you can imagine the future purpose for it :) * DNS options: this has been asked by some of you before. By default it's off. If you set it to "simple" then your probe will have a probe-xxxx.probes.atlas.ripe.net DNS entry. If you set it to "obfuscated" then your probe will have a <something random looking>.probes.atlas.ripe.net DNS entry. We'll activate this feature soon. * Public: you can make your probe visible to everyone, which means that all Atlas users will see the probe in their probe list (with role "Viewer"), and they will be able to see the measurement details on the probe status page. Consider this an experimental feature -- we have to see if it's useful or not. You'll need to reload the page (with the browser "reload") in order to see these changes. Regards, Robert

7 8

[atlas]Probe comparisons
by Michael Behringer (mbehring) 13 Jan '11

13 Jan '11

Team, The new feature of making probes generally visible is EXCELLENT. It allows nice comparisons between different probes. For example, I just compared my Orange DSL probe to a Free probe (both France). The results are VERY interesting! (Would be interested to chat with the owner of this Free probe off line, BTW - can you ping me please?). Now of course this leads immediately to a new feature request! :-) (the curse of being popular!) It would be nice to be able to compare a number of probes side by side. In the simplest case, min/avg/max values (graphs are nice but not essential). Now of course the next feature request :-) that'll come out of this is to see the full traceroute from each probe, to be able to understand where the difference in RTT is coming from. On the positive side, the beer supply to the developers at the next RIPE meeting should be plenty! :-) Thanks for all your work! Michael

1 0

[atlas]Not my probes ?
by Andrzej Wolski 12 Jan '11

12 Jan '11

Hi everyone, after coming back from holidays I've looked at the graphs of my probe ( 00:20:4A:C8:24:17 ) and found that I have rights to view about 16 other probes from all over the place. Bug or a feature ? ;-) -- Andrzej Wolski aka Taihen mailto/xmpp: taihen(a)taihen.org

2 1

[atlas]trying to collect basic info about the architecture
by Wilfried Woeber, UniVie/ACOnet 05 Jan '11

05 Jan '11

Dear ATLAS-Team, I am aware of the fact that my poking and attempt to collect information may be premature, as the whole thing is still very much in development... Still, I think it would be useful for many of us to have some sort of "snapshot" regarding the behaviour of the probes and the framework they live in. The initial basic questions on my end would be: What does the term "connect", to one of the controllers, really mean in terms of TCP/IP Lingo? Like: does the thing open a TCP hose to the controller? Is communication based on UDP and/or on TCP? Is the probe capable of bufffering data for a while if connectivity to the Net is still there, but not to the controller(s)? Is there any means to (locally, on the same subnet, or even remotely) trigger or "reboot" a probe, other than disconnecting power (which means physical access required)? I am also wondering how much of this stuff is available already and where to collect it - the 'labs pool may be more appropriate than this list? Thanks to everyone who was and is involved in this fascinating project, with season's greatings and a happy (2010)++ to everyone, Wilfried. PS: for a future version of the probes or as an optional gadget: how about making the thing capable of feeding it off 2 different power plugs, e.g. a primary and a UPS? :-)

4 4

[atlas]Probe actually down?
by Richard L. Barnes 05 Jan '11

05 Jan '11

Probe #394 is reported as being down in the web GUI, but I can ping6 to it without a problem. I'm not near the probe right now, so I can't look at it or its traffic. Are there known cases where probes are alive but not reporting to their controllers? --Richard

4 4

[atlas]Geo-location
by Hartmut Richard Glaser 29 Dec '10

29 Dec '10

After the registration of the probes, how can I correct the geo-location? Thanks Hartmut

4 3

[atlas]Geo-location
by Hartmut Richard Glaser 29 Dec '10

29 Dec '10

After the registration of the probes, how can I correct the geo-location? Thanks Hartmut

1 0

[atlas]DHCP behaviour of the probe on startup
by Wilfried Woeber, UniVie/ACOnet 22 Dec '10

22 Dec '10

Hi folks, while debugging some non-probe-related issues here at my ADSL'd net @home, I was told by the provider's techie, that the probe tries to grab *two* addresses at startup. He was monitoring the ARP table in the router, saw a DHCP request and the address assigned by the DHCP Server, and immediately asfterwards, the probe sent a request for an additional address, which was granted by the server. Trying to verify that, I later found out that I can ping the probe only on the second address. [1] Has anyone seen such a behaviour? Unfortunately, I don't have access to the router (cisco 800 series) as it is fully managed by the ISP, and for my other probe we had the IP-Address hard-wired into the DHCP server for the MAC address. Thanks, Wilfried. [1] this is particularly nasty for home networks with a very small number of addresses available (a bock of 8 in may case) and a long timeout...

2 1

[atlas]how big is the limitation imposed by the req. for DHCPv4?
by Wilfried Woeber, UniVie/ACOnet 22 Dec '10

22 Dec '10

Folks, I'd like to collect input from those interested in principle to deploy groups of probes within their operational environment(s), regarding the requirement to have DHCPv4 available in order to configure the probe (for IPv4). I already came up with a coupe of locations and environments, where such a cute thing would be nice to have, but in most (if not all) of these places, there is no DHCP available (and for good reasons). As an aside to the developers, would it be feasable to connect the probe in network A, configure it for the destination network and then move it over to network B for its happy life? Cheers, Wilfried.

2 1

[atlas]Probe flapping
by Harald Firing Karlsen 21 Dec '10

21 Dec '10

Hi, My RIPE Atlas probe (MAC: 00204AC8243A) started flapping last night and is continuing to flap. It have flapped about 90 times since midnight, do you have any known problems at the moment? -- Kind regards Harald Firing Karlsen

10 17

[atlas]Question about security?
by Marco Davids (SIDN) 17 Dec '10

17 Dec '10

Hi, So how does security on the Atlas portal work? Reason for asking is that I changed the password from home yesterday, but when i logged in from work this morning, i was not asked for the new password. Maybe some kind of sessionid cookie with a long expiry time? Is that safe enough? Regards, -- Marco

2 1

[atlas]RFC5006
by Marco Davids (SIDN) 13 Dec '10

13 Dec '10

Question: Do the Atlas probes support RFC5006 (RDNSS option)? If not, would that be an idea to implement? Regards, -- Marco

3 2

[atlas]Moving a probe
by Richard L. Barnes 13 Dec '10

13 Dec '10

Hey guys, I have had a probe move from Columbia, Maryland, USA to Cambridge, Massachusetts, USA. How do I update the registered location? --Richard

2 1

[atlas]Upgrades today
by Robert Kisteleki 11 Dec '10

11 Dec '10

Hi, Today we'll upgrade some of the central components of the system, including the UI. Please don't be surprised about service interruptions. Regards, Robert

6 10

[atlas]option ntp-servers ?
by Marco Davids (SIDN) 09 Dec '10

09 Dec '10

Hi, Question: does the Atlas-probe obey to the 'option ntp-servers' DHCP option? If not, mine could be into trouble, since I don't allow outbound NTP-requests. (Sorry if this has been asked before, I am new to this list and haven't found the archive just yet) Regards, -- Marco

2 1

[atlas]IPv4 and IPv6 to the same machine(s)...
by Wilfried Woeber, UniVie/ACOnet 07 Dec '10

07 Dec '10

How much effort would it be to add a test and the graph to labs.ripe.net on IPv6? Just checked, it still has an IPv6 address. Btw, Mirjam (on bcc:), the new Labs site does no longer show the address for the incoming connection. Could this be re-instated, please? If possible it should go to somewhere in the header, like next to the login-name... On a more general aspect, I am looking for a good idea to present the measurement data for the same machine(s) for v4 and v6 either in the same graph "on top of each other" or "next to each other"... This could easily evolve into a graphical v6-sanity-check vehicle :-) Wilfried.

5 4

[atlas]Atlas probe showing up as Never seen
by Harald Firing Karlsen 06 Dec '10

06 Dec '10

Hi, I installed my RIPE Atlas-probe yesterday and it still shows up as "Never seen" on the Atlas website. Everything looks good networking-wise (it have received DHCP-offer, etc), but it still shows up as "Never seen" on the Ripe Atlas website. The MAC-address is 00204AC8243A and the IP-address is 91.209.30.2. I hope you can solve this. -- Kind regards Harald Firing Karlsen

1 0

[atlas]probe locations
by Florian Obser 06 Dec '10

06 Dec '10

Hi, so, I had a look at the probe locations at https://atlas.ripe.net/ looks like there is a probe on every continent... except Antarctica! How cool would that be! Maybe there is someone on this list who knows someone who knows someone... ;) While discussing this with a friend we both noticed that the coolness could only be topped by a probe on ISS. Looking at the registration page this seems easy enough, "Method of delivery*: Other, please specify: Soyus or Ariane 5" "Hosting Location" on the other hand will probably be a pain in the ass. Regards, Florian -- I remember yesterday, but the memory is in my head now. Was yesterday real? Or is it only the memory that is real?

4 3

[atlas]DNS records for the probes' internet address
by Tore Anderson 03 Dec '10

03 Dec '10

Hi list, I've got a probe connected to my home broadband connection, which might change its WAN address whenever my ISP feels like it should. I just thought it would be a nice feature if the probes had an A record in DNS that were automatically updated to match the current external address. Like probe-121.atlas.ripe.net or something. That way I would have a hostname I would be sure that points to the WAN address of my CPE whenever I want to log on to my home network from somewhere else. I would think such a feature would be a small incentive for home broadband users to become probe hosts. On an unrelated note, the graphs for the probe in question (#121) doesn't work, they're all gray, even though the probe is up. Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com Tel: +47 21 54 41 27

8 16

[atlas]FYI probe problems after power failure
by Jelte Jansen 03 Dec '10

03 Dec '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Today I had a power failure, and luckily everything came back up when I fixed it. However, a while later, I wondered if the probe had too, and it had not. The status page said it was up, but it hadn't reported data for about 6 hours (grey graphs). I assume I hit one of the problems in the FAQ: - --- Technical background: the probe tries to get current time indication using NTP upon booting, which sometimes fails. This causes the probe to think the curent date is November 1999, which confuses it a lot; it doesn't register properly or it sends measurement data for the twentieth century which is immediately discarded by the system. We plan to convince the probe to insist on vaild NTP or acquire some other time indication. The fix will be deployed in a firmware update. - --- Since the probe boots a lot faster than my gateway, I guess it never retried NTP. Powercycle fixed it indeed. So the lesson here is (at least until there is an update that retries ntpdate, or something), if the machine that provides your Internet connection takes a while to boot up, and they are both powered on at the same time, you may need to powercycle your probe. Jelte -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkz4HX0ACgkQ4nZCKsdOncVlXgCfZe+3FbLdTWTxCvXYZFrmaXjd TsEAn3vqmfjbUmWfueVcziCi2a3Hs6jF =zqNQ -----END PGP SIGNATURE-----

2 1

[atlas]Inaccurate uptime tracking?
by Richard L. Barnes 02 Dec '10

02 Dec '10

Hey guys, I'm seeing an inconsistency between the reported uptime and the actual measurements from probe #394. On the one hand, the probe info page reports only a little over an hour of uptime: Total Uptime: 0d, 1h, 1m Connect at: Disconnect at: 2010-12-02 02:38:06 UTC (still connected) 2010-12-01 04:22:43 UTC 2010-12-01 04:28:42 UTC But the graphs for the last 8 hours show only a brief down-time; roughly: Disconnect: 2010-12-02 02:27:00 UTC Reconnect: 2010-12-02 02:35:00 UTC This wouldn't bother me much if uptime weren't tied to chances to win an iPad :) --Richard

2 2

[atlas]atlas win!
by Florian Obser 01 Dec '10

01 Dec '10

Hi, we are running two probes. One behind my private dsl line at home, one in our data centre. I noticed that the IPv6 ping times to m.root-servers.net are more then twice as bad from our data centre compared to the dsl probe. As it turns out at home I'm talking to the m-root instance in Paris while in the data centre we were talking to the instance in Tokyo(?) It looks like this: http://eafc8bd05a0435ef14d31bbff29687dd7b71c3ca.de/m.root-servers.net.v6.png Not _that_ important in the great scheme of things but non the less quite nice ;) Thanks! Best regards, Florian

2 1

[atlas]P466 - inconsistent readings?
by Wilfried Woeber, UniVie/ACOnet 30 Nov '10

30 Nov '10

Hi Team, could you pls. have a look at the grpahs of 466 and the list of "perceived" outages for the probe? While I can't prove that there wasn't some problem with my ADSL link at home (while sitting in the office :-) ), the graphs for the pings seem to indicate that the probe was alive and kicking all the time. I may be misreading some stuff, though.... Wilfried

2 3

[atlas]some comments regarding the user interface - re-sizing and outage(s)
by Wilfried Woeber, UniVie/ACOnet 30 Nov '10

30 Nov '10

Just minor cosmetics, and for the to-do-list :-) - the probe and measurements display reacts to a resizing of the window, e.g. from partial screen to full-screen, by redrawing the inforamtion and using all the real estate, but does NOT redraw on a switch back to a smaller size. (IE7, W/XP prof. SP3) - regardig the "Uptime" panel, I'd like to see the most recent outage included by default (the UTC stamp of most recent down transition, the most recent up transition and the duration). Alternatively, I'd be happy to make the selection for "Show last 25 connections sticky, maybe by giving the number of entries to display. Cheers, Wilfried.

2 1

[atlas]how many of us are on this list?
by Wilfried Woeber, UniVie/ACOnet 29 Nov '10

29 Nov '10

Hi folks, just had a look at the graphs and at the # of people "talking" on this list... There are some 130 probes "up" and some 150 "ready" :-) Now I am wondering, how many subscriptions does this list have by now? Have a nice weekend, all, Wilfried.

7 8

[atlas]IPv4 DHCP and varying addresses
by Wilfried Woeber, UniVie/ACOnet 25 Nov '10

25 Nov '10

Having a simple question regarding DHCP and varying addresses within a subnet... While I *do* have access to the config of the DHCP server that delivers addresses to 414, and thus the probe will always get that same IP address, I *do not* have access to configure the DHCP service in my ADSL CPE (yet), which means that the individual address given to the probe may change over time. I guess this is expected and being taken care of by the system, but wanted to double-check. Thanks, Wilfried.

2 1

[atlas]The probes and IPv6
by Wilfried Woeber, UniVie/ACOnet 25 Nov '10

25 Nov '10

Just had a look again at the info page for my 414, in the "Configuration" panel. While this thing does have IPv6 connectivity and performs measurements just OK, the section "IPv6", next to the MAC Address, is empty. Bug or "reserved for future use"? While we did the EUI-64 math locally to generate a DNS AAAA entry derived from the MAC, some folks may be better off to see the auto-conf'd address. As an aside, for the "ideas stack", it would be hip to have a means of educating the probe about an IPv6-transport-capable DNS server. I know, there are some issues with this idea :-/ All the best, Wilfried. PS: Looking forward to see probe #2, 466, becoming visible as living in my village, after making pole position for #1 already :-)

2 2

[atlas]Some issues today
by Robert Kisteleki 24 Nov '10

24 Nov '10

Dear All, As you already know, RIPE Atlas is in a prototype phase. A good illustration for it is an issue we had today. We're still investigating the cause, but in the meantime we had to ignore some data points for a subset of the probes -- please don't be surprised to see missing parts of your probe graphs for today. Thanks for your understanding, Robert

1 0

[atlas]Graphs gone...
by Wolfgang Tremmel 24 Nov '10

24 Nov '10

Hello, Probe is up (and shows up) but all the graphs show empty since yesterday. best regards, Wolfgang

4 3

[atlas]warning pop-up in IE for the various atlas-related pages
by Wilfried Woeber, UniVie/ACOnet 24 Nov '10

24 Nov '10

Folks, I noticed that I have to ack a warning pop-up (served by IE7 ;-) ) for each page that is realted to the atlas stuff. IE complains about a mix of secured and unsecured components on the page. In principle I'd prefer continuing with httpS, but the warnings are a real nuisance. Anyone else seeing this? Btw, the Labs stuff shows the same behaviour. Wilfried.

4 5

[atlas]internal timing constraints?
by Wilfried Woeber, UniVie/ACOnet 24 Nov '10

24 Nov '10

Dear Atlas folks, do you have a rough estimate or data about the internal timing of the probes, like what sort of "delay" is added by the probe itself when measuring e.g. ping RTT? The background is that I get different readings or ping RTTs from the probe, compared to the "same" thing done from a regular PC running Linux and sitting on the very same subnet, connected to the very same (small) switch. The absolute difference I see is small (sub-millisecond), but it seems to be systematic. The ping target is a "local" instance of i.root, btw. Thanks, Wilfried.

2 1

[atlas]probe appears down on atlas.ripe.net
by Nuno Vieira - nfsi telecom 24 Nov '10

24 Nov '10

Hello, I have deployed one probe and it has been up since a few hours ago. I checked this morning and it was down. The thing is, i can ping properly the probe on IPv4 and IPv6, and i see traffic comming in and out. We did not changed anything on the network/firewall to prevent traffic. What could be the problem ? regards, --nvieira

2 1

[atlas]labeling the axes in the graphs
by Wilfried Woeber, UniVie/ACOnet 23 Nov '10

23 Nov '10

Dear probe hosts and "herders", a couple of first experiences and thoughts... While I know that RTT is measured in "time" rather than distance, I was slightly detracted in the beginning by he use of "m" as the abbreviation for milli seconds. I guess there would be enough room in the graphs to use "ms"? Maybe it is just me :-) Wilfried.

1 0

[atlas]Upgrades today
by Robert Kisteleki 10 Nov '10

10 Nov '10

Hi, We're doing some major upgrades today on the RIPE Atlas network, both on the central architecture and on the probes. It's expected that during this time probes will disconnect. Regards, Robert

4 7

[atlas]is this correct
by Bert (IETF) Wijnen 10 Nov '10

10 Nov '10

looking at "Last 25 connections", I vaguely suspect that this is somehow not correct (at least not what I expected) Bert *Current status:* Up since 2010-11-09 19:23:06 UTC *Total Uptime:* 20d, 17h, 7m Show last 25 connections Hide last 25 connections *Connect at:* *Disconnect at:* 2010-11-09 19:23:06 UTC (still connected) 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC 2010-11-05 09:53:28 UTC 2010-11-05 21:53:31 UTC

2 4

[atlas]test
by Tom Sylwestrowicz 14 Oct '10

14 Oct '10

test mail to check mailing list works

1 0