From lukas at ltri.eu Sun Jun 4 20:03:25 2023 From: lukas at ltri.eu (Lukas Tribus) Date: Sun, 4 Jun 2023 20:03:25 +0200 Subject: [atlas] state of the source code repository and releases [was: upgrading an original soft probe] In-Reply-To: <0303F229-3EF7-464F-AE21-2232A23C82AB@ripe.net> References: <0303F229-3EF7-464F-AE21-2232A23C82AB@ripe.net> Message-ID: Hello Michel, On Sun, 12 Feb 2023 at 22:51, Michel Stam wrote: > > Hello Randy, > > We are currently actually looking at providing packages for other distributions, through > the regular repositories of the distribution. However that means we have to work pieces > of the software probe to comply to distribution standards. I cannot guarantee right now > whether Debian will be provided, but this is something I would personally like to see. For third party package maintainers and users willing to compile from source: What is the currently released version of the atlas-software-probe? HW probes seem to be running 5080. On the git repository we have the following tags: 2022 Sep 19: 5080 was tagged 2022 Nov 30: 5083 was tagged 2022 Dec 9: 5082 was tagged 2023 Feb 24: 5081 was tagged 2023 Feb 28: 5084 was tagged Is 5080 the current release, which HW probes are running, and the newer tags in the source code repository should be ignored? Is 5084 the current release, but HW probes are lagging behind? Why did we see decreasing versioning tags from November to February? Where can a third party package maintainer (or a user compiling from source) find authoritative information about what the latest atlas SW probe actually is? There is only a single branch in the git repository, which is master. However while the 5080 tag seems to be in the master branch, the newer tags are not, so I guess that means 5080 is indeed the last properly released version. But I really don't like to guess and I don't see how anyone not directly involved in the SW development of the probe would be able to package it considering the ambiguity in the source code repository. Thanks, Lukas From michael.rabinovich at case.edu Tue Jun 6 02:03:15 2023 From: michael.rabinovich at case.edu (Michael Rabinovich) Date: Mon, 5 Jun 2023 20:03:15 -0400 Subject: [atlas] credit request In-Reply-To: References: Message-ID: Many thanks! As I mentioned, I did get all the credits requested, but I am grateful to have them as it will allow us extra flexibility to do some exploratory measurements. Cheers, ?Misha > On Jun 4, 2023, at 6:53 PM, DeuZa wrote: > > Sent 181 000 000 credits > > Sent from Proton Mail for iOS > > > Le mer. 24 mai 2023 ? 17:29, Michael Rabinovich > a ?crit : >> >> Folks, >> >> As I posted couple months ago, we deployed and made available the instrumentation for longitudinal comparison of the performance implications of DNS resolver platforms, including ISP-provided and some influential publicly available resolvers ( https://dns-web-portal.netlify.app/). This work ? and Nick Kernan?s MS thesis ? was enabled by a generous donation of credits several years ago from the RIPE Atlas community ? thanks a lot! Now to keep this measurement going requires ~20M credits per month. I?d like to assemble ~250M credits so we could keep this service up for a year. By then we should be able to see if it?s proved to be valued by the community and whether and how to keep it going beyond this time horizon. Would you please donate to my account what you can? >> >> Many thanks in advance! >> ?Misha > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mstam at ripe.net Thu Jun 8 11:29:48 2023 From: mstam at ripe.net (Michel Stam) Date: Thu, 8 Jun 2023 11:29:48 +0200 Subject: [atlas] state of the source code repository and releases [was: upgrading an original soft probe] In-Reply-To: References: <0303F229-3EF7-464F-AE21-2232A23C82AB@ripe.net> Message-ID: Hi Lukas! Sorry for the delay in response, I was off for a few days and for some reason your mail got buried beneath a pile of other mail. Let me give you a bit of a background; About a year or so ago we set up a CI/CD pipeline for the software and hardware probes. The intent being that the software would be built by a clean platform every single time a commit was tagged for building, or if any of the major branches were updated. This all happens from an internal repository that is not publicly accessible. Somewhere around that time we also started with a new development strategy. A master branch which contains production-ready code. This is the code that users can deploy on their own setup, and it is also the code that the RPMs and the hardware probe firmware will be built on. A testing branch on which the master branch is essentially a pointer. The testing branch contains code that is being readied for the next production release A devel(opment) branch that contains code which is by its nature feature complete, but may not be fully tested yet. This code is merged into the testing branch upon completion and unit testing. Ticket branches that run off the development branch and contain features that may or may not work Out of all of this, only the tags and master branch pointers are automatically synced from the internal repository to the GitHub repository. This is by intent to discourage people from deploying code which is not feature complete. For sake of transparency, as well as convenience, this code is visible. Well spotted! :) The versioning is your next implied question- any number divisible by 10 is a production release (5060, 5070, 5080). Any other number is either a development or a testing release. I would recommend to use the master branch or any tag which is divisible by 10, which in essence would be a (previous) production release. As to decreasing numbers. At the time there were two people working on different features at the same time, some of which we were both testing on different probe platforms simultaneously. One was working on 5083 the other on 5081/2. Ugly, yes. I believe I was restructuring for the version 3 hardware probe at that time. Ideally we would sync only the release tags and not the development tags, but unfortunately that is not how the internal repository (Gitlab) works. The current released version is 5080. I?m working on the next release as we speak, which will include a restructure to accommodate providing packages to the RHEL repositories. I?m interested in talking to debian distribution maintainers who are willing to help do the same for Debian. OpenWRT is also something I?ll be looking at. Short and simple. Master contains the latest production code. Use it in good health :) Cheers, Michel > On 4 Jun 2023, at 20:03, Lukas Tribus wrote: > > Hello Michel, > > > On Sun, 12 Feb 2023 at 22:51, Michel Stam wrote: >> >> Hello Randy, >> >> We are currently actually looking at providing packages for other distributions, through >> the regular repositories of the distribution. However that means we have to work pieces >> of the software probe to comply to distribution standards. I cannot guarantee right now >> whether Debian will be provided, but this is something I would personally like to see. > > For third party package maintainers and users willing to compile from source: > > What is the currently released version of the atlas-software-probe? > > HW probes seem to be running 5080. > > On the git repository we have the following tags: > > 2022 Sep 19: 5080 was tagged > 2022 Nov 30: 5083 was tagged > 2022 Dec 9: 5082 was tagged > 2023 Feb 24: 5081 was tagged > 2023 Feb 28: 5084 was tagged > > > Is 5080 the current release, which HW probes are running, and the > newer tags in the source code repository should be ignored? > Is 5084 the current release, but HW probes are lagging behind? > Why did we see decreasing versioning tags from November to February? > Where can a third party package maintainer (or a user compiling from > source) find authoritative information about what the latest atlas SW > probe actually is? > > There is only a single branch in the git repository, which is master. > However while the 5080 tag seems to be in the master branch, the newer > tags are not, so I guess that means 5080 is indeed the last properly > released version. > > > But I really don't like to guess and I don't see how anyone not > directly involved in the SW development of the probe would be able to > package it considering the ambiguity in the source code repository. > > > > Thanks, > > Lukas -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas at ltri.eu Thu Jun 8 20:32:07 2023 From: lukas at ltri.eu (Lukas Tribus) Date: Thu, 8 Jun 2023 20:32:07 +0200 Subject: [atlas] state of the source code repository and releases [was: upgrading an original soft probe] In-Reply-To: References: <0303F229-3EF7-464F-AE21-2232A23C82AB@ripe.net> Message-ID: Hello Michel, thank you for clarifying. Can we bring those very useful informations (master is production ready; releases are tags based on master divisible by 10, tags non divisible by 10 need to be ignored) into README.rst? Are you accepting PR's or patches? I think what would also help is if you would create a github release with a source tarball. We are only looking at tags because of the absence of GH releases. Formal announcements of new production releases on this mailing list would also help (basically everyone involved with RIPE atlas). It's important to demystify the repository and release process, and for this information not only be in one old mail in the list archives. FWIW OpenWRT is already packaging atlas, it seems to work and the response on packaging related bugs [1] is also very fast [2]. Thanks, Lukas [1] https://github.com/openwrt/packages/issues/20338 [2] https://github.com/openwrt/packages/commit/dc39bbef1452047eb22d78445e30644d2e1d22dd On Thu, 8 Jun 2023 at 11:29, Michel Stam wrote: > > Hi Lukas! > > Sorry for the delay in response, I was off for a few days and for some reason your mail got buried beneath a pile of other mail. > > Let me give you a bit of a background; > > About a year or so ago we set up a CI/CD pipeline for the software and hardware probes. The intent being that the software would be built by a clean platform every single time a commit was tagged for building, or if any of the major branches were updated. This all happens from an internal repository that is not publicly accessible. > > Somewhere around that time we also started with a new development strategy. > > A master branch which contains production-ready code. This is the code that users can deploy on their own setup, and it is also the code that the RPMs and the hardware probe firmware will be built on. > A testing branch on which the master branch is essentially a pointer. The testing branch contains code that is being readied for the next production release > A devel(opment) branch that contains code which is by its nature feature complete, but may not be fully tested yet. This code is merged into the testing branch upon completion and unit testing. > Ticket branches that run off the development branch and contain features that may or may not work > > > Out of all of this, only the tags and master branch pointers are automatically synced from the internal repository to the GitHub repository. This is by intent to discourage people from deploying code which is not feature complete. For sake of transparency, as well as convenience, this code is visible. Well spotted! :) > > The versioning is your next implied question- any number divisible by 10 is a production release (5060, 5070, 5080). Any other number is either a development or a testing release. I would recommend to use the master branch or any tag which is divisible by 10, which in essence would be a (previous) production release. > > As to decreasing numbers. At the time there were two people working on different features at the same time, some of which we were both testing on different probe platforms simultaneously. One was working on 5083 the other on 5081/2. Ugly, yes. I believe I was restructuring for the version 3 hardware probe at that time. > Ideally we would sync only the release tags and not the development tags, but unfortunately that is not how the internal repository (Gitlab) works. > > The current released version is 5080. I?m working on the next release as we speak, which will include a restructure to accommodate providing packages to the RHEL repositories. I?m interested in talking to debian distribution maintainers who are willing to help do the same for Debian. OpenWRT is also something I?ll be looking at. > > Short and simple. Master contains the latest production code. Use it in good health :) > > Cheers, > > Michel > > On 4 Jun 2023, at 20:03, Lukas Tribus wrote: > > Hello Michel, > > > On Sun, 12 Feb 2023 at 22:51, Michel Stam wrote: > > > Hello Randy, > > We are currently actually looking at providing packages for other distributions, through > the regular repositories of the distribution. However that means we have to work pieces > of the software probe to comply to distribution standards. I cannot guarantee right now > whether Debian will be provided, but this is something I would personally like to see. > > > For third party package maintainers and users willing to compile from source: > > What is the currently released version of the atlas-software-probe? > > HW probes seem to be running 5080. > > On the git repository we have the following tags: > > 2022 Sep 19: 5080 was tagged > 2022 Nov 30: 5083 was tagged > 2022 Dec 9: 5082 was tagged > 2023 Feb 24: 5081 was tagged > 2023 Feb 28: 5084 was tagged > > > Is 5080 the current release, which HW probes are running, and the > newer tags in the source code repository should be ignored? > Is 5084 the current release, but HW probes are lagging behind? > Why did we see decreasing versioning tags from November to February? > Where can a third party package maintainer (or a user compiling from > source) find authoritative information about what the latest atlas SW > probe actually is? > > There is only a single branch in the git repository, which is master. > However while the 5080 tag seems to be in the master branch, the newer > tags are not, so I guess that means 5080 is indeed the last properly > released version. > > > But I really don't like to guess and I don't see how anyone not > directly involved in the SW development of the probe would be able to > package it considering the ambiguity in the source code repository. > > > > Thanks, > > Lukas > > From contact at streamyard.com Sat Jun 10 19:28:39 2023 From: contact at streamyard.com (StreamYard) Date: Sat, 10 Jun 2023 17:28:39 +0000 (UTC) Subject: [atlas] Sie wurden zu StreamYard eingeladen Message-ID: <5Td6oZaaSXyfRjwAqNW8QQ@geopod-ismtpd-1> StreamYard Inc. ( https://u7212249.ct.sendgrid.net/ls/click?upn=Ef-2BTvyZXeR9MIWcIdAYELFJPNYCgf6GzX5LOG15TWug-3DAUHq_GSPTJO99CDgyThRLxFvxQYgf2BDhZfWL69CyZ2Hp7HHd9VZQ6QamzD0kNMyUOjvlF2hkpaJFZt4WVOEuDMIBAj-2BQlHWWZw5-2FeQY-2F-2BMILYoQFLd7vL1ysH2eHLyvk1T6bp86aolXHCCLB3-2F7Rudn3UBIzDNMbqcKZKZR-2B5tAarqX-2FXCf-2F4e5dvSQPstoaYYiiyjPvYiwYCN7FcpjnSz1eRXgMmkCmgpF99A2YtoIaUIhCF8zvVWRO6H9XfGsp-2FPEwRZuR45lFqhxln5w8wjgYtcJJHTnheHKj7oPXjEbw8ClsVNJpfDOJFeeDaW66psQK2UnypMAIEAShiA6RsaZ4faf58rGw3dswr-2FVKqLx74lg4sXt1NuPjrY7ODFzgdeGeOAisIBNLFSEaNQ2xnpDEvg-3D-3D ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From contact at streamyard.com Sat Jun 17 19:29:18 2023 From: contact at streamyard.com (StreamYard) Date: Sat, 17 Jun 2023 17:29:18 +0000 (UTC) Subject: [atlas] Vergessen Sie nicht Ihre StreamYard-Einladung! Message-ID: <66eUFkOVRByuHXlDTlDCtQ@geopod-ismtpd-12> StreamYard Inc. ( https://u7212249.ct.sendgrid.net/ls/click?upn=Ef-2BTvyZXeR9MIWcIdAYELFJPNYCgf6GzX5LOG15TWug-3D0-Ry_GSPTJO99CDgyThRLxFvxQYgf2BDhZfWL69CyZ2Hp7HHd9VZQ6QamzD0kNMyUOjvlF2hkpaJFZt4WVOEuDMIBAj-2BQlHWWZw5-2FeQY-2F-2BMILYoQFLd7vL1ysH2eHLyvk1T6bp86aolXHCCLB3-2F7Rudn3UBIzDNMbqcKZKZR-2B5tAarqUQpuY4Oc5WwibR-2BmzxZhVE-2FkrylN5KUzrDeCqHhomONriY1FEqz3q5pqz-2FEiEG-2FrxmOFuKfvQMAuSlFjiC4mMToFz8CK5A04wNNLNAOj79yrlYOhSXTNeXv0Aui5xKZjThLbC6Ee-2FsKrmJiUl52Hoa6VGiEnxMwXasCjNpUeV97kMadoK7AwTPhTOvteSOvZoT5YRz33Al6IlT5U53-2FMNE6ANF4OpPYMzoOIXIvzXqgw-3D-3D ) -------------- next part -------------- An HTML attachment was scrubbed... URL: From carsten at schiefner.de Sat Jun 17 22:24:15 2023 From: carsten at schiefner.de (Carsten Schiefner) Date: Sat, 17 Jun 2023 22:24:15 +0200 Subject: [atlas] Can please be unsubscribed? Message-ID: To whom it may concern? Thank you, -C. From rsmithy at cluenet.org Sat Jun 17 23:19:09 2023 From: rsmithy at cluenet.org (Rich Smith) Date: Sat, 17 Jun 2023 22:19:09 +0100 Subject: [atlas] Can please be unsubscribed? In-Reply-To: References: Message-ID: <013a01d9a161$5b505030$11f0f090$@cluenet.org> Hi Carsten, RIPE uses Mailman, so you should be able to do this yourself by clicking the link at the bottom of the email. I have done this for you, but note a confirmation email has been sent to contact at streamyard.com which just needs to be approved to unsubscribe it. Kind Regards Rich Smith -----Original Message----- From: ripe-atlas On Behalf Of Carsten Schiefner Sent: Saturday, June 17, 2023 9:24 PM To: ripe-atlas at ripe.net Subject: [atlas] Can please be unsubscribed? To whom it may concern? Thank you, -C. -- ripe-atlas mailing list ripe-atlas at ripe.net https://lists.ripe.net/mailman/listinfo/ripe-atlas From schoen at loyalty.org Sat Jun 17 23:34:30 2023 From: schoen at loyalty.org (Seth David Schoen) Date: Sat, 17 Jun 2023 14:34:30 -0700 Subject: [atlas] Can please be unsubscribed? In-Reply-To: <013a01d9a161$5b505030$11f0f090$@cluenet.org> References: <013a01d9a161$5b505030$11f0f090$@cluenet.org> Message-ID: <20230617213430.GA245359@demorgan> Rich Smith writes: > Hi Carsten, > > RIPE uses Mailman, so you should be able to do this yourself by clicking the link at the bottom of the email. > > I have done this for you, but note a confirmation email has been sent to contact at streamyard.com which just needs to be approved to unsubscribe it. I think Carsten's point is that this address is sending autogenerated messages which are inappropriate, so it should be unsubscribed by a list administrator. From endre.szabo at ripeatlas-ml-nerudrr.rediremail.com Tue Jun 20 15:18:16 2023 From: endre.szabo at ripeatlas-ml-nerudrr.rediremail.com (Endre Szabo) Date: Tue, 20 Jun 2023 13:18:16 +0000 Subject: [atlas] Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Message-ID: <7a1dbbafbfee4c56625e8a1c9c2ae898@ripeatlas-ml-nerudrr.rediremail.com> Hi folks, I've got a probe running at a very remote site. Since the energy prices were skyrocketing with the crisis here in Eastern Europe, the probe does not have 7x24 power anymore. It is down for 10-ish hours a weekday. It's been running like this for months now. Suddenly, I've just got this mail below about my probe. The probe is online every day and was online today as well. Does this mail mean that RIPE is unsatisfied with my uptime, and I must return the probe? Or is it some monitoring needing some tuning? --Endre ----- Forwarded message from RIPE Atlas ----- From: RIPE Atlas Subject: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Date: Tue, 20 Jun 2023 13:01:05 -0000 Dear Endre Szabo, We hope this email finds you well. We noticed that your probe with ID 52974 has been disconnected for some time now, and you have probably received reminders from our system asking you to reconnect it. We would like to request you to please either reconnect the probe, or if that is not possible, to return it to us to be refurbished. There is a long waiting list of people keen to receive new probes, and because of global component shortages, we have a very limited number available. 1. You can check your probe using this link below. https://atlas.ripe.net/probes/52974/#tab-status If your probe is already online, you can stop reading here! 2. If you need to troubleshoot a disconnected probe, you can take a look at our tutorials on YouTube, or write to us asking for assistance. https://www.youtube.com/watch?v=BGj1MDIclDQ 3. If the probe is beyond repair, please go here: https://atlas.ripe.net/probes/52974 and click on the "Write-off" button at the bottom of the page. This will allow you to choose a reason for writing off the probe. This will clear the probe host name, and you will no longer receive any more reminders from us about the probe. 4. If you no longer wish to host the probe, please follow step 3 and then send the probe back to us. We will refurbish and redistribute it. Please use this address for shipping: RIPE NCC P.O. Box 10096 1001 EB Amsterdam The Netherlands ===== RIPE NCC Days Sofia, Bulgaria And finally, join us at RIPE NCC Days Sofia, Bulgaria on 27-28 June 2023! This free event provides a unique opportunity for network operators and technical staff to share knowledge and experiences. Don't miss out ? register now at https://www.ripe.net/participate/meetings/regional-meetings/ripe-ncc-days-sofia/ripe-ncc-days-sofia . We look forward to seeing you there! ===== Thank you for continuing to support RIPE Atlas. Best regards, The RIPE Atlas Team ----- End forwarded message ----- From endre.szabo at ripeatlas-ml-nerudrr.rediremail.com Tue Jun 20 15:24:19 2023 From: endre.szabo at ripeatlas-ml-nerudrr.rediremail.com (Endre Szabo) Date: Tue, 20 Jun 2023 13:24:19 +0000 Subject: [atlas] Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Message-ID: <76e83b8bf4eb42f56cbb67073d5f841e@ripeatlas-ml-nerudrr.rediremail.com> Hi folks, I've got a probe running at a very remote site. Since the energy prices were skyrocketing with the crisis here in Eastern Europe, the probe does not have 7x24 power anymore. It is down for 10-ish hours a weekday. It's been running like this for months now. Suddenly, I've just got this mail below about my probe. The probe is online every day and was online today as well. Does this mail mean that RIPE is unsatisfied with my uptime, and I must return the probe? Or is it some monitoring needing some tuning? --Endre ----- Forwarded message from RIPE Atlas ----- From: RIPE Atlas Subject: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation Date: Tue, 20 Jun 2023 13:01:05 -0000 Dear Endre Szabo, We hope this email finds you well. We noticed that your probe with ID 52974 has been disconnected for some time now, and you have probably received reminders from our system asking you to reconnect it. We would like to request you to please either reconnect the probe, or if that is not possible, to return it to us to be refurbished. There is a long waiting list of people keen to receive new probes, and because of global component shortages, we have a very limited number available. 1. You can check your probe using this link below. https://atlas.ripe.net/probes/52974/#tab-status If your probe is already online, you can stop reading here! 2. If you need to troubleshoot a disconnected probe, you can take a look at our tutorials on YouTube, or write to us asking for assistance. https://www.youtube.com/watch?v=BGj1MDIclDQ 3. If the probe is beyond repair, please go here: https://atlas.ripe.net/probes/52974 and click on the "Write-off" button at the bottom of the page. This will allow you to choose a reason for writing off the probe. This will clear the probe host name, and you will no longer receive any more reminders from us about the probe. 4. If you no longer wish to host the probe, please follow step 3 and then send the probe back to us. We will refurbish and redistribute it. Please use this address for shipping: RIPE NCC P.O. Box 10096 1001 EB Amsterdam The Netherlands ===== RIPE NCC Days Sofia, Bulgaria And finally, join us at RIPE NCC Days Sofia, Bulgaria on 27-28 June 2023! This free event provides a unique opportunity for network operators and technical staff to share knowledge and experiences. Don't miss out ? register now at https://www.ripe.net/participate/meetings/regional-meetings/ripe-ncc-days-sofia/ripe-ncc-days-sofia . We look forward to seeing you there! ===== Thank you for continuing to support RIPE Atlas. Best regards, The RIPE Atlas Team ----- End forwarded message ----- From endre.szabo at ripeatlas-ml-nerudrr.rediremail.com Tue Jun 20 15:26:34 2023 From: endre.szabo at ripeatlas-ml-nerudrr.rediremail.com (Endre Szabo) Date: Tue, 20 Jun 2023 13:26:34 +0000 Subject: [atlas] Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation In-Reply-To: <76e83b8bf4eb42f56cbb67073d5f841e@ripeatlas-ml-nerudrr.rediremail.com> References: <76e83b8bf4eb42f56cbb67073d5f841e@ripeatlas-ml-nerudrr.rediremail.com> Message-ID: <658cc0c781c1c8f128ce494aacce05eb@ripeatlas-ml-nerudrr.rediremail.com> Sorry for this duplicate, it was sort of intentional. (Got a backscatter from a list member's MTA to test) On Tue, Jun 20, 2023 at 13:24:19+0000, Endre Szabo wrote: > Hi folks, From jterbeest at ripe.net Tue Jun 20 15:43:03 2023 From: jterbeest at ripe.net (Johan ter Beest) Date: Tue, 20 Jun 2023 15:43:03 +0200 Subject: [atlas] Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation In-Reply-To: <7a1dbbafbfee4c56625e8a1c9c2ae898@ripeatlas-ml-nerudrr.rediremail.com> References: <7a1dbbafbfee4c56625e8a1c9c2ae898@ripeatlas-ml-nerudrr.rediremail.com> Message-ID: <299cf791-11e9-c763-dad7-86d78ec98fa4@ripe.net> Hi Endre, This email was sent to probe hosts in selected countries only as a one-off. We are not unsatified with your uptime and we will take your feedback into account for the next email so we exclude probes that have been online recently. Kind regards, Johan ter Beest RIPE Atlas Team On 20/06/2023 15:18, Endre Szabo wrote: > Hi folks, > > I've got a probe running at a very remote site. Since the energy prices were skyrocketing with the crisis here in Eastern Europe, the probe does not have 7x24 power anymore. It is down for 10-ish hours a weekday. It's been running like this for months now. Suddenly, I've just got this mail below about my probe. The probe is online every day and was online today as well. > > Does this mail mean that RIPE is unsatisfied with my uptime, and I must return the probe? Or is it some monitoring needing some tuning? > > --Endre > > ----- Forwarded message from RIPE Atlas ----- > From: RIPE Atlas > Subject: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation > Date: Tue, 20 Jun 2023 13:01:05 -0000 > > Dear Endre Szabo, > > We hope this email finds you well. We noticed that your probe with ID 52974 has been disconnected for some time now, and you have probably received reminders from our system asking you to reconnect it. > > We would like to request you to please either reconnect the probe, or if that is not possible, to return it to us to be refurbished. There is a long waiting list of people keen to receive new probes, and because of global component shortages, we have a very limited number available. > > 1. You can check your probe using this link below. https://atlas.ripe.net/probes/52974/#tab-status If your probe is already online, you can stop reading here! > > 2. If you need to troubleshoot a disconnected probe, you can take a look at our tutorials on YouTube, or write to us asking for assistance. > https://www.youtube.com/watch?v=BGj1MDIclDQ > > 3. If the probe is beyond repair, please go here: https://atlas.ripe.net/probes/52974 and click on the "Write-off" button at the bottom of the page. This will allow you to choose a reason for writing off the probe. This will clear the probe host name, and you will no longer receive any more reminders from us about the probe. > > 4. If you no longer wish to host the probe, please follow step 3 and then send the probe back to us. We will refurbish and redistribute it. Please use this address for shipping: > RIPE NCC > P.O. Box 10096 > 1001 EB Amsterdam > The Netherlands > > ===== > RIPE NCC Days Sofia, Bulgaria > And finally, join us at RIPE NCC Days Sofia, Bulgaria on 27-28 June 2023! This free event provides a unique opportunity for network operators and technical staff to share knowledge and experiences. Don't miss out ? register now at https://www.ripe.net/participate/meetings/regional-meetings/ripe-ncc-days-sofia/ripe-ncc-days-sofia . We look forward to seeing you there! > ===== > > Thank you for continuing to support RIPE Atlas. > Best regards, > The RIPE Atlas Team > > ----- End forwarded message ----- > From endre.szabo at ripeatlas-ml-nerudrr.rediremail.com Wed Jun 21 04:37:36 2023 From: endre.szabo at ripeatlas-ml-nerudrr.rediremail.com (Endre Szabo) Date: Wed, 21 Jun 2023 02:37:36 +0000 Subject: [atlas] Fw: Action Required: RIPE Atlas Probe 52974 and RIPE NCC Days Sofia invitation In-Reply-To: <299cf791-11e9-c763-dad7-86d78ec98fa4@ripe.net> References: <7a1dbbafbfee4c56625e8a1c9c2ae898@ripeatlas-ml-nerudrr.rediremail.com> <299cf791-11e9-c763-dad7-86d78ec98fa4@ripe.net> Message-ID: Thanks for your exhaustive answer Johan. --Endre On Tue, Jun 20, 2023 at 15:43:03+0200, Johan ter Beest wrote: > Hi Endre, > > This email was sent to probe hosts in selected countries only as a one-off. > We are not unsatified with your uptime and we will take your feedback into > account for the next email so we exclude probes that have been online > recently. > > Kind regards, > Johan ter Beest > RIPE Atlas Team From rennyleal at outlook.com Sat Jun 24 03:45:13 2023 From: rennyleal at outlook.com (Renny Leal) Date: Sat, 24 Jun 2023 01:45:13 +0000 Subject: [atlas] Recovered probe v3 Message-ID: Hi folks I?ve recovered one V3 probe but sadly the person who got it flashed the tp-link original firmware to the device. Is there any way to get the ripe atlas firmware back to it? Thanks in advance Enviado desde Correo para Windows -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernstoud at gmail.com Sun Jun 25 17:14:22 2023 From: ernstoud at gmail.com (Ernst J. Oud) Date: Sun, 25 Jun 2023 17:14:22 +0200 Subject: [atlas] Magellan Message-ID: <7B62F39D-34CD-4C63-A0C6-A058C69E60EB@gmail.com> Hi, Perhaps someone can help me. I use Magellan to create a measurement using connected probes on AS15435. First I search for probes using Magellan and then I supply the ID?s returned of those probes reported as ?connected? when creating the measurement. I don?t want to wait for the stream to time-out so I use the ?stream-limit? parameter, equal to the number of supplied connected probes. So when that number of connected probes have supplied data the streaming is complete. However, it appears that probes are reported as connected by Magellan but do not supply data when specified for a measurement, for instance probe 2565. That probe is Reported by Magellan as connected but when I use it in a measurement it does not supply data. Thus streaming will only time-out and does not stop not when spevified connected probes have supplied data. Apparantly ?connected? does not imply ?can be used in a measurement?. How can I supply probe ID?s in a ?create measurement? command using Magellan knowing for sure that these probes will supply data? Regards, Ernst J. Oud From mstam at ripe.net Mon Jun 26 09:53:15 2023 From: mstam at ripe.net (Michel Stam) Date: Mon, 26 Jun 2023 09:53:15 +0200 Subject: [atlas] Recovered probe v3 In-Reply-To: References: Message-ID: Hi Renny, The only way to get the firmware back on is to ship the unit back to us, we will look it up in and try to recover it. Unfortunately this is not a process you can do yourself. Regards, Michel > On 24 Jun 2023, at 03:45, Renny Leal wrote: > > Hi folks > > I?ve recovered one V3 probe but sadly the person who got it flashed the tp-link original firmware to the device. > > Is there any way to get the ripe atlas firmware back to it? > > Thanks in advance > > > Enviado desde Correo para Windows > > -- > ripe-atlas mailing list > ripe-atlas at ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas -------------- next part -------------- An HTML attachment was scrubbed... URL: From camin at ripe.net Mon Jun 26 15:51:04 2023 From: camin at ripe.net (Chris Amin) Date: Mon, 26 Jun 2023 15:51:04 +0200 Subject: [atlas] Magellan In-Reply-To: <7B62F39D-34CD-4C63-A0C6-A058C69E60EB@gmail.com> References: <7B62F39D-34CD-4C63-A0C6-A058C69E60EB@gmail.com> Message-ID: Hi Ernst, There is no way to know for absolute certain if a probe will be able to carry out a measurement and deliver results. There are a number of factors that prevent a measurement being scheduled on a probe (e.g. it is too busy, it is running an old firmware that doesn't support your measurement options). There are also factors that prevent it delivering results even if it is scheduled (e.g. it disconnects in the meanwhile, it has an issue with its hardware). Many of these issues can be prevented most of the time by requiring one of the so-called stability tags when selecting your probes. These are tags which mark a probe as recently performing mostly successful measurements e.g. for an IPv4 measurement you could do: $ ripe-atlas probe-search --asnv4 15435 --status 1 --format csv --field id --limit 50 --no-header --tag system-ipv4-stable-1d to get a list of probes that have generally had good success with IPv4 measurements in the last day. In the case you gave, probe 2565 would have been excluded from this list because it has not generally been delivering results for a long while, which you can see here: https://atlas.ripe.net/probes/2565/#tab-builtins For more info on the various probe tags you can look at the docs here: https://atlas.ripe.net/docs/getting-started/probe-tags.html#system-tags I hope this helped, please let me know if you have any more questions. Regards, Chris On 25/06/2023 17:14, Ernst J. Oud wrote: > Perhaps someone can help me. > > I use Magellan to create a measurement using connected probes on AS15435. > > First I search for probes using Magellan and then I supply the ID?s returned of those probes reported as ?connected? when creating the measurement. > > I don?t want to wait for the stream to time-out so I use the ?stream-limit? parameter, equal to the number of supplied connected probes. So when that number of connected probes have supplied data the streaming is complete. > > However, it appears that probes are reported as connected by Magellan but do not supply data when specified for a measurement, for instance probe 2565. That probe is Reported by Magellan as connected but when I use it in a measurement it does not supply data. Thus streaming will only time-out and does not stop not when spevified connected probes have supplied data. Apparantly ?connected? does not imply ?can be used in a measurement?. > > How can I supply probe ID?s in a ?create measurement? command using Magellan knowing for sure that these probes will supply data? > > Regards, > > Ernst J. Oud From ernstoud at gmail.com Mon Jun 26 20:28:42 2023 From: ernstoud at gmail.com (Ernst J. Oud) Date: Mon, 26 Jun 2023 20:28:42 +0200 Subject: [atlas] Magellan In-Reply-To: References: Message-ID: <97C40AEF-D252-4C68-90E9-90A8E4B6BE6D@gmail.com> Chris, Thanks. That works, but still there are (2) probes that appear to work fine, are public, have the stable-1d tag, report on the built-in measurements, but do not reply when I include them in a measurement. Probes 29418 and 54253, both running version 5080. No idea why these do not co-operate. Regards, Ernst J. Oud > On 26 Jun 2023, at 15:51, Chris Amin wrote: > ?Hi Ernst, > > There is no way to know for absolute certain if a probe will be able to carry out a measurement and deliver results. There are a number of factors that prevent a measurement being scheduled on a probe (e.g. it is too busy, it is running an old firmware that doesn't support your measurement options). There are also factors that prevent it delivering results even if it is scheduled (e.g. it disconnects in the meanwhile, it has an issue with its hardware). > > Many of these issues can be prevented most of the time by requiring one of the so-called stability tags when selecting your probes. These are tags which mark a probe as recently performing mostly successful measurements e.g. for an IPv4 measurement you could do: > > $ ripe-atlas probe-search --asnv4 15435 --status 1 --format csv --field id --limit 50 --no-header --tag system-ipv4-stable-1d > > to get a list of probes that have generally had good success with IPv4 measurements in the last day. > > In the case you gave, probe 2565 would have been excluded from this list because it has not generally been delivering results for a long while, which you can see here: https://atlas.ripe.net/probes/2565/#tab-builtins > > For more info on the various probe tags you can look at the docs here: https://atlas.ripe.net/docs/getting-started/probe-tags.html#system-tags > > I hope this helped, please let me know if you have any more questions. > > Regards, > Chris > > On 25/06/2023 17:14, Ernst J. Oud wrote: > >> Perhaps someone can help me. >> I use Magellan to create a measurement using connected probes on AS15435. >> First I search for probes using Magellan and then I supply the ID?s returned of those probes reported as ?connected? when creating the measurement. >> I don?t want to wait for the stream to time-out so I use the ?stream-limit? parameter, equal to the number of supplied connected probes. So when that number of connected probes have supplied data the streaming is complete. >> However, it appears that probes are reported as connected by Magellan but do not supply data when specified for a measurement, for instance probe 2565. That probe is Reported by Magellan as connected but when I use it in a measurement it does not supply data. Thus streaming will only time-out and does not stop not when spevified connected probes have supplied data. Apparantly ?connected? does not imply ?can be used in a measurement?. >> How can I supply probe ID?s in a ?create measurement? command using Magellan knowing for sure that these probes will supply data? >> Regards, >> Ernst J. Oud > > -- > ripe-atlas mailing list > ripe-atlas at ripe.net > https://lists.ripe.net/mailman/listinfo/ripe-atlas From robert at ripe.net Wed Jun 28 13:01:25 2023 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 28 Jun 2023 13:01:25 +0200 Subject: [atlas] RIPE Atlas Quarterly Planning Q3 2023 Message-ID: <80e3482f-445e-d897-9f4a-8cddc727b565@ripe.net> Dear colleagues, We have published our next quarterly plans for RIPE Atlas on our website: https://www.ripe.net/support/documentation/quarterly-planning/ripe-atlas This quarter, we'll continue discussing the five proposals for changing the RIPE Atlas behaviour and start working on renewing the big data backend. If you have any input on our plans or want to let us know what you would like to see us work on, please let us know. Kind regards, Robert Kisteleki RIPE NCC From ernstoud at gmail.com Fri Jun 30 13:23:59 2023 From: ernstoud at gmail.com (Ernst J. Oud) Date: Fri, 30 Jun 2023 13:23:59 +0200 Subject: [atlas] =?utf-8?q?Delays_in_backend=E2=80=A6?= Message-ID: <39DD7387-78B9-41FE-B19C-E34EAAE67A04@gmail.com> Hi, Measurements stream fine in Magellan, but results only show up in the web interface after - in extreme cases - hours. The RIPE status info says: Resolved This incident has been resolved. Posted 1 day ago. Jun 29, 2023 - 10:11 UTC Investigating We are experiencing issues with the RIPE Atlas backend and currently are investigating this issue. Posted 1 day ago. Jun 29, 2023 - 08:55 UTC But clearly this has not been resolved! Regards, Ernst J. Oud -------------- next part -------------- An HTML attachment was scrubbed... URL: