November 2024 - ripe-atlas - mailman.ripe.net

Re: Changes to RIPE Atlas API keys
by Ponikierski, Grzegorz 26 Feb '25

26 Feb '25

Hi! > * We'll deprecate and remove the ability to use the URL form in about a > year (around October 2024). > * We plan to send further reminders about this change over time, as well > as reaching out to heavy users of the to-be-removed format. It’s October 2024. Is this plan still valid? I admit that I have a bunch of tools which use URL form which I would have to update to use "Authorization" header. Regards, Grzegorz From: Robert Kisteleki <robert(a)ripe.net> Organisation: RIPE NCC Date: Tuesday, 19 September 2023 at 12:11 To: "ripe-atlas(a)ripe.net" <ripe-atlas(a)ripe.net> Subject: [atlas] Changes to RIPE Atlas API keys Dear RIPE Atlas users, We'd like to update you on some upcoming changes regarding API keys in RIPE Atlas. TL;DR nothing changes regarding how you can use your API keys in the short term - as long as you're actually using them. However, we'll change how unused or forgotten keys are handled as well as remove the less secure in-URL use of them. At the moment RIPE Atlas users can query their existing API keys via the UI and API, including the possibility to retrieve old keys. In order to improve the security of how we handle these, we'll introduce the following changes in October 2023: * The listing (retrieval) of keys will only reveal parts of the keys (enough to identify them) in the API as well as in the UI. * We'll add the ability to "regenerate" an API key, which will replace the secret UUID of the key while keeping exactly the same permissions. * Unused API keys will automatically be frozen after 1 year of not being used. Active keys (i.e. the ones that have been used at least once) will not be frozen. You still have the ability to save your keys until these changes are done and, as written above, you will be able to regenerate them later. We'll notify this list when the changes are about to be done. In addition, in order to further increase the security of our system, in the long run we'll make changes about how these API keys are communicated to the API: * At the moment the API accepts these either in HTTP headers ("Authorization" header) or in the URL (?key=xyz), although the Authorization header version has been documented as the preferred version for some time. * We'll deprecate and remove the ability to use the URL form in about a year (around October 2024). * We plan to send further reminders about this change over time, as well as reaching out to heavy users of the to-be-removed format. Regards, Robert Kisteleki RIPE Atlas team -- ripe-atlas mailing list ripe-atlas(a)ripe.net<mailto:ripe-atlas@ripe.net> https://urldefense.com/v3/__https://lists.ripe.net/mailman/listinfo/ripe-at…<https://urldefense.com/v3/__https:/lists.ripe.net/mailman/listinfo/ripe-atl…>

2 5

Probe #2413 somehow failing
by ripe＠brite.cz 29 Nov '24

29 Nov '24

Hi team, please have a look at Probe #2413, it shows connected but it seems it is not providing any measurements results. I tried different cables, power sources, connected to different switch, and finally move it to completely different location. It is v1 so it does not have USB memory stick. Please advise. Thanks Jiri

7 8

v2 probe repair?
by Phillip Remaker 28 Nov '24

28 Nov '24

Hello! I have an 11+ year old v2 probe Seems to be in a reboot loop. Starts up, all LEDs go blank, and it repeats. Any diagnostics I can do? Any repairs? https://atlas.ripe.net/probes/4111/#tab-network

3 6

Streaming result data missing probe information with "enrichProbes: true"
by Wouter de Vries 27 Nov '24

27 Nov '24

Hi folks, When using the Streaming API there is an option called "enrichProbes" which should cause probe metadata to be added to every result. That seems to have worked for a while, but it has stopped working. Example code (in python) to reproduce (it's the example from the docs, with just enrichProbes set to true): import json import websocket ws = websocket.WebSocket() ws.connect("wss://atlas-stream.ripe.net/stream/") params = {"streamType": "result", "msm": 1001, "enrichProbes": True} ws.send(json.dumps(["atlas_subscribe", params])) for data in ws: print(data) Example result: ["atlas_result",{"fw":5080,"mver":"2.6.2","lts":66,"dst_name":"193.0.14.129","af":4,"dst_addr":"193.0.14.129","src_addr":"192.168.1.20","proto":"ICMP","ttl":56,"size":32,"result":[{"rtt":21.447667},{"rtt":21.226292},{"rtt":21.253375}],"dup":0,"rcvd":3,"sent":3,"min":21.226292,"max":21.447667,"avg":21.3091113333,"msm_id":1001,"prb_id":50274,"timestamp":1731917452,"msm_name":"Ping","from":"85.107.81.62","type":"ping","step":240}] As you can see there is no probe metadata present. I'm fairly sure I'm doing this right and I think this worked previously. Is something broken in the backend? Best regards, Wouter

2 2

UI feature wish: "Daily Credits Balance" pie chart widget
by ripe＠nurfuerspam.de 26 Nov '24

26 Nov '24

Hi, I very much like/liked the "Daily Credits Balance" pie chart widget from the old UI dashboard (https://atlas.ripe.net/my/). It gives an instant overview of the credit revenue and expenditure stream, not only the grand total, but also the _share_ of individual probes and measurements in the revenue and expenditure streams. With the actual number being shown when hovering over an individual slice of the pie. And clicking on a slice would take one to the page of the respective probe or measurement (though it seems currently broken for measurements, possibly because of the ongoing restructuring). Is there a way to get it back in the new dashboard, refreshed obviously, and integrated into the new overall site layout? Thanks! Kind regards, R.

2 1

Probe flash drive corrupted
by Michael J. Oghia 20 Nov '24

20 Nov '24

Hi team, all: I just checked my dashboard, and one of my probes is offline. The error message says: "Your probe was automatically untagged as "system: Flash drive filesystem corrupted." Does anyone know how to fix it? Or does it require me to change the probes? If the latter is the case, how can I go about doing that? Kind regards, -Michael

2 4

Feature idea: new status "Probe (temporarily) closed for new UDMs"
by ripe＠nurfuerspam.de 20 Nov '24

20 Nov '24

Hi, Obviously, measurements are the purpose of being of the RIPE Atlas system. Thus, e.g., I take greate care to maximize probe uptime so measurements scheduled on them don't get disrupted by local events that are likely not representative of what most measurements are looking at. However, sometimes, temporary disruption may be known to come up, but is unavoidable, e.g., for maintenance of, or around the probe. Or a probe needs to be taken out of service "for good". In those cases, it is obviously hardly possible to avoid long-running measurements from being impacted, either by a short-term disruption, or by the removal of a probe altogether. And measurement owners obviously are aware of that, and need to take that into account in a way specific to each measurement's purpose. And it is obviously possible to remove, e.g., defunct probes from a running measurement and replace them with new ones. However, when a probe host knows _ahead of time_ that their probe will experience some event potentially disrupting measurements (like during planned maintenance activities), or will have to be decommissioned at a specific time in the future, how about if they could signal that condition to the Atlas infrastructure, and the infrastructure would at least not schedule _new_ measurements on such probes? E.g., by having a new probe "status" that can be explicitly set by the probe host to say, "this probe shall (perhaps just temporarily) not get any _new_ UDMs scheduled at this time (while the status is set)". Just a thought, not sure how much effort that would be to implement, and whether that would be worth the benefit of disrupting "fewer" measurements in case of foreseeable issues with a probe (or anchor), especially also upon an upcoming need to decommission one entirely. Thanks! Kind regards, R.

1 0

Re: [opensource-wg] RV: [ripe-list] Update on the Community Projects Fund 2024
by Rodolfo García Peñas (kix) 18 Nov '24

18 Nov '24

Hello, I would like to congratulate all the projects selected by the Community Projects Fund. I also wish to express my gratitude to the organising committee for initially selecting our project, 'RIPE Atlas distributed network telescope'. I am currently engaged in doctoral research on IBR traffic, and together with my supervisory team, we have proposed this project. We saw this as an ideal opportunity for the community to collect IBR traffic and make it available. We currently have a small working network of sensors (HoDiNT, Home Distributed Network Telescope [1]) and our objective is to extend the network and have RIPE manage the traffic collected. The HoDiNT sensors receive IBR traffic forwarded from the home connection router and forward it to a collector for analysis. They are fully compatible with Atlas sensors. This would enrich the traffic of other research centres, such as CAIDA or Merrit, and offer other students and research centres the possibility of having IBR traffic available for analysis. I was delighted that our project was selected, but a few hours later the organisation sent us an email stating that the RIPE Atlas team had raised some concerns about our proposal which may impact our ability to receive funding. We were requested to attend a meeting with the organisation and the RIPE Atlas team to discuss the proposal a few days later. The meeting was unfortunately not attended by a representative of RIPE Atlas. We were informed that the project was not deemed feasible. I would like to thank Alastair, who had to pass on the news to us, which is not an easy situation. I accept the decision taken, although I do not agree with either the substance or the form. I think we should have been given the opportunity to reformulate the project, maintaining the original objective but circumventing the limitations exposed. We will continue to improve HoDiNT in order to make it available to the community as soon as possible. If anyone is interested in contributing to the project, improving the code (mainly Python) and/or hosting sensors, please contact us. Due to limited resources, it is not possible to add sensors to the network openly, and we are doing so with sensors from colleagues and friends whom we thank for their time and resources. Regards, Rodolfo. [1] https://www.sciencedirect.com/science/article/pii/S138912862400402X [2] https://drive.google.com/file/d/1VGJ4PEcf-kHtFVT7rsXd9QYDqRL6rGH6/view?usp=… -- Rodolfo García Peñas (kix) http://www.kix.es/ "I asked him once how to change the key bindings and Dave said 'You use the Change Configuration command. On Unix it is abbreviated as cc.' Dave Conroy and Lawrence Stewart. On Friday, November 15th, 2024 at 14:18, Marcos Sanz via opensource-wg <opensource-wg(a)ripe.net> wrote: > FYI. Sorry for the cross-posting. > > > -----Mensaje original----- > > De: Alastair Strachan projectsfund(a)ripe.net > > Enviado el: jueves, 14 de noviembre de 2024 12:55 > > Para: ripe-list(a)ripe.net > > Asunto: [ripe-list] Update on the Community Projects Fund 2024 > > > > Dear all, > > > > After the announcement of this year’s Community Projects Fund recipients, > > some challenges emerged with the RIPE Atlas distributed network telescope > > project which would have prevented the project from achieving the goals > > outlined in the project plan. > > > > After careful consideration, the Selection Committee made the difficult > > decision to withdraw funding for the project. While we understand this is > > really disappointing for the recipients, we sincerely hope they will continue > > initiatives that bring value to our community and the Internet. > > > > The Selection Committee has now chosen another project to support from our > > pool of finalists: OpenPenny - An open-source tool to identify non-spoofed > > traffic. You can read about the project on the Community Projects Fund 2024 > > page: > > https://www.ripe.net/community/community-initiatives/cpf/previous- > > funding-recipients/funding-recipients-2024/ > > <https://www.ripe.net/community/community-initiatives/cpf/previous- > > funding-recipients/funding-recipients-2024/> > > > > Warm regards, > > Alastair Strachan > > Community Projects Fund Coordinator > > ----- > To unsubscribe from this mailing list or change your subscription options, please visit: https://mailman.ripe.net/mailman3/lists/opensource-wg.ripe.net/ > As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings. > More details at: https://www.ripe.net/membership/mail/mailman-3-migration/

2 1

RIPE Atlas Community Project Update
by Michael J. Oghia 15 Nov '24

15 Nov '24

Hi all, See the message below from Alastair from NCC. Does anyone know if the project can re-apply for the next round of funding? Kind regards, -Michael ---------- Forwarded message --------- From: Alastair Strachan <projectsfund(a)ripe.net> Date: Fri, Nov 15, 2024 at 8:48 AM Subject: [ripe-list] Update on the Community Projects Fund 2024 To: <ripe-list(a)ripe.net> Dear all, After the announcement of this year’s Community Projects Fund recipients, some challenges emerged with the RIPE Atlas distributed network telescope project which would have prevented the project from achieving the goals outlined in the project plan. After careful consideration, the Selection Committee made the difficult decision to withdraw funding for the project. While we understand this is really disappointing for the recipients, we sincerely hope they will continue initiatives that bring value to our community and the Internet. The Selection Committee has now chosen another project to support from our pool of finalists: OpenPenny - An open-source tool to identify non-spoofed traffic. You can read about the project on the Community Projects Fund 2024 page: https://www.ripe.net/community/community-initiatives/cpf/previous-funding-r… Warm regards, Alastair Strachan Community Projects Fund Coordinator

2 2

Probe registration problem
by Robert Kisteleki 13 Nov '24

13 Nov '24

Hello, I just put up a status page entry to https://status.ripe.net/ as follows: We're experiencing a problem with accepting new and reconnecting probes in the infrastructure. Probe that are currently connected, as well as new and ongoing measurements and data delivery are not affected. Regards, Robert

1 1