- atlas-sw-probes - mailman.ripe.net

How to remove unused SW-Probe
by ripe＠groetzner.net 08 May '20

08 May '20

Hello, how can I remove a unused VM-Probe? I don`t think „transfer ownership“ ist he right solution for an SW-Probe 😉 Sascha

4 3

New release v5020
by Philip Homburg 08 May '20

08 May '20

Hi, I just pushed version v5020 to github (https://github.com/RIPE-NCC/ripe-atlas-software-probe/tree/v5020) The main change is to the 'SOS' mechanism. Probes look up a special DNS name just before they try to connect. This can be used to diagnose probes that have trouble connecting. For hardware probes we rely on the probe's ethernet address to distinguish between probes. For software probes that doesn't work because we don't record ethernet addresses for software probes. We made a change to have software probes send the hash of the probe's public key instead. With this change the network tab of the probe page shows the 'SOS History'. >From this release we now also support CentOS 8 binary packages, though I noticed that we did not yet add that to the installation instructions. Finally, we changed the way we accept SSH public keys. We now accepts longer RSA keys (max. 4096 bits) as well as ECDSA and ED25519 Philip Homburg

2 2

Fwd: Thank you for applying for a RIPE Atlas software probe
by Georgi Vasilev 08 May '20

08 May '20

Hello, May I ask you to check, what is the problem with my probe. Here is the link https://atlas.ripe.net/probes/16362/ Thank you in advance Br, Georgi Vasilev ---------- Forwarded message --------- From: RIPE Atlas <no-reply(a)ripe.net> Date: Thu, Jan 30, 2020 at 12:25 PM Subject: Thank you for applying for a RIPE Atlas software probe To: Georgi Vasilev <georgi.petkov.vasilev(a)gmail.com> Dear Georgi Vasilev, Thank you for applying for a RIPE Atlas software probe! Your application ID is 91. If your application was successful, you will receive another email with the probe ID and additional instructions. We appreciate your support of the RIPE Atlas network. If you have any questions or concerns, please don't hesitate to contact atlas(a)ripe.net Kind regards, RIPE Atlas Team

2 1

Problem with UDM
by Thierry Montigneaux 20 Apr '20

20 Apr '20

Hi, I have just activated my first sw probe, on a dedicated CentOS7 VM, id 1000408. Out of habit, I did configure CentOS the way I usually configure my servers, notably by running OpenSSH on a non-default port and by activating only the ed25519 host key in sshd_config. I noticed 3 issues after having let the atlas-probe service run for a while, which included a couple of service restarts : 1. The SOS History table for the probe on the probe web page was not being populated with any data after the restarts. 2. The ./status/ssh_err.txt file showed the following message: « RSA host key for IP address '178.63.8.31' not in list of known hosts. » 3. I tried to set up a test one-off measurement using my sw probe by manually selecting its ID on the measurement setup screen, but it would not register the probe. I also noted after 12+ hours that no UDM was active for the probe from other users (from my experience with a hardware probe I have been operating for a while, it should be put at use by the network pretty quickly unless I am too impatient here ;-) ). My first action was to revert OpenSSH to default settings (use port 22, activate the RSA host key). This apparently contributed to solving problem 1 as the SOS History data started to appear on subsequent service restarts. Concerning the SSH error logged for the probe, the RSA Key for 'ctr-fsn01.atlas.ripe.net' was present in /var/atlas-probe/.ssh/known_hosts, but there was no entry in the file for a key for the corresponding IP address 178.63.8.31. I tried to add it to the probe known_hosts file but it disappeared after restarting the service. I guess the file is overwritten on service restart. I then added an entry for the RSA key for the IP address in the global /etc/ssh/ssh_known_hosts. The SSH error disappeared from the probe log file on the following service restart. So problem 2 solved for me, but that raises the question of whether there is a key missing for the probe known_hosts file for that IP address ? Now I am left with problem 3 and I have no clue as to why I can’t create a UDM which uses my sw probe ID. The built-in measurements seem to work fine if I read the probe web page info correctly. Any help welcome. Thierry

3 3

Missing DNS resolution system tags
by Maurice Walker 24 Feb '20

24 Feb '20

Hello, My software probe has been connected for about ten days now. It is in an IPv6-only network and was assigned IPv6 capable, works and stable system tags. But it was not assigned any DNS resolution tags yet, neither positive nor negative. I'm not aware of any DNS issues and its measurements seem okay. I searched for similar probes and it seems that all IPv6-only software probes are affected. Software probes with working IPv4 do have DNS tags, so do IPv6-only hardware probes. Cheers, Maurice

1 0

Software probes status on various platforms
by Robert Kisteleki 29 Jan '20

29 Jan '20

Hello, The official release of software probes is scheduled for 11(ish) of February. This means that we'll remove the barrier to register software probes at this date. The RIPE NCC provides: * the source code on github * centos7 binary package * centos8 binary package in the near future We hear people having interest in openwrt, docker, raspbian and perhaps debian versions. Some of you have these up and running as a result of one-time efforts. Unfortunately, I'm not aware that any of these manifested as being available to the public in the form of installable packages. Please speak up if you have working versions that we can point people to as this would help us encouraging people to deploy software probes without requiring them to have knowledge about installing from source... Thanks, Robert

1 0

Re: [atlas-sw-probes] SW Probe offline after reinstall & SSH KEY change
by ripe＠brite.cz 27 Jan '20

27 Jan '20

Hi team, it seems it still does not work correctly. I had to change my probe 1000078 hosting server. The situation with SSH KEY is the same as described below. Furthermore on https://atlas.ripe.net/probes/1000078/#!tab-network I can see its new IP addresses, what is weird, since it still shows Offline, but the new IPv4 and IPv6 are there. Cheers Jiri _________________________________________________________________________________ Johan ter Beest jterbeest at ripe.net Fri Jan 17 19:36:53 CET 2020 Hi Jiri, > On 17 Jan 2020, at 14:51, <ripe at brite.cz> <ripe at brite.cz> wrote: > > Hi team, > I have SW probe 1000069 running on router Turris Omnia. I had to commit factory reset and reinstall all software. All went good, I have the SW Probe running, got new SSH KEY [command "/etc/init.d/atlas get_key"] and pasted the new key to web > Update SSH Key. First it accepted, but the probe never managed to connect. I restarted the probe process and even whole router, also tried to get the key from the probe again and when pasting to Update SSH Key field it says "A probe with this key already exists. Please enter a unique key". So the new key is sure recorded correctly. For some reason the new key was not copied to the probe. I have now done this manually so it should be able to connect now > > Probe log: > root at turris:~# /etc/init.d/atlas log > 01/17/20 12:36:02 ctrl-init > 01/17/20 13:39:02 net-try > 01/17/20 13:39:05 net-ok > 01/17/20 12:39:05 ctrl-init > 01/17/20 13:42:06 net-try > 01/17/20 13:42:09 net-ok > 01/17/20 12:42:09 ctrl-init > 01/17/20 13:45:09 net-try > 01/17/20 13:45:12 net-ok > 01/17/20 12:45:12 ctrl-init > > From https://www.ripe.net/ripe/mail/archives/atlas-sw-probes/20191023/000002.html I read "We'll add a means to replace this key for an existing probe, in case you need to reinstall and lose the original key material." Does it mean it is not implemented yet? It should be implemented… I will check on Monday why it failed to copy the new key to the probe. Cheers and have a good weekend :) Johan > > Thank you > > Jiri

2 2

SW Probe offline after reinstall & SSH KEY change
by ripe＠brite.cz 17 Jan '20

17 Jan '20

Hi team, I have SW probe 1000069 running on router Turris Omnia. I had to commit factory reset and reinstall all software. All went good, I have the SW Probe running, got new SSH KEY [command "/etc/init.d/atlas get_key"] and pasted the new key to web > Update SSH Key. First it accepted, but the probe never managed to connect. I restarted the probe process and even whole router, also tried to get the key from the probe again and when pasting to Update SSH Key field it says "A probe with this key already exists. Please enter a unique key". So the new key is sure recorded correctly. Probe log: root@turris:~# /etc/init.d/atlas log 01/17/20 12:36:02 ctrl-init 01/17/20 13:39:02 net-try 01/17/20 13:39:05 net-ok 01/17/20 12:39:05 ctrl-init 01/17/20 13:42:06 net-try 01/17/20 13:42:09 net-ok 01/17/20 12:42:09 ctrl-init 01/17/20 13:45:09 net-try 01/17/20 13:45:12 net-ok 01/17/20 12:45:12 ctrl-init >From https://www.ripe.net/ripe/mail/archives/atlas-sw-probes/20191023/000002.html I read "We'll add a means to replace this key for an existing probe, in case you need to reinstall and lose the original key material." Does it mean it is not implemented yet? Thank you Jiri

2 1

Connection & Traffic - No data available...
by ripe＠brite.cz 13 Jan '20

13 Jan '20

I noticed for multiple (maybe all) SW probes there is no Connection & Traffic shown. Is it by design? Would I be able to change it for my probe? Thank you Jiri https://atlas.ripe.net/probes/1000069/

2 1

How to change RIPE Atlas Software Probe configuration and network settings?
by ripe＠brite.cz 09 Jan '20

09 Jan '20

I have RIPE Atlas Software Probe 1000069 up and running, but it somehow made up its network settings on its own. I need to virtually “plug” it into one of my other network interfaces. Is there a way how to configure its network settings? On https://atlas.ripe.net/probes/1000069/#!tab-network I show: Local Address 192.168.1.1 Gateway 10.11.5.146 Netmask 255.255.255.0 DNS Resolvers 127.0.0.1 it works, but I don’t see any interface of 10.11.5.146 (in LUCI or ifconfig), and one of my other local LAN has assigned 192.168.1.1/24 therefore the probe itself should not have the same, and I want to have the probe connected to different Network Interface. Furthermore for IPv6 it picked all IPv6 addresses of the router - one WAN and both LAN IPv6 addresses (I have two LANs), I want it different. I tried assign probe IP address via web interface, it does not work. Any idea how to configure the probe network settings? Thank you Jiri

2 2

Re: [atlas-sw-probes] SW Probe 1000069 issue
by ripe＠brite.cz 09 Jan '20

09 Jan '20

Maybe it was shortly after router reboot and it was doing clock adjusting during the time, since I am in GMT+1 timezone. The further content of file /tmp/log/ripe_sw_probe looks time-consistent. See attachment (.txt extension added. At 9:08 I rebooted the router). I uncommented those two lines in both scripts, now it does not show any messages in Log. When I run /etc/init.d/atlas restart, I get following log: Jan 9 10:21:25 turris atlas-sw-probe: Stopping atlas sw probe Jan 9 10:21:25 turris atlas-sw-probe: Kill all atlas processes Jan 9 10:21:25 turris atlas-sw-probe: Kill ssh tunnel Jan 9 10:23:37 turris telnetd[8892]: found atlas session Nothing else ATLAS related in Log. It looks the probe is now sending measurements results fine. Thanks for now, I will have further questions about the Probe network settings, will send another email shortly... Cheers Jiri ______________________________________________________________ > Od: "Philip Homburg" <philip.homburg(a)ripe.net> > Komu: atlas-sw-probes(a)ripe.net > Datum: 09.01.2020 10:35 > Předmět: Re: [atlas-sw-probes] SW Probe 1000069 issue > >Hi, > >On 2020/01/08 10:31 , ripe(a)brite.cz wrote: >> Some outputs: >> >> root@turris:~# /etc/init.d/atlas log >> 01/08/20 10:17:01 net-ok >> 01/08/20 09:17:01 reg-init >> 01/08/20 09:17:03 ctrl-init >> 01/08/20 09:17:04 keep-start >> 01/08/20 10:20:04 keep-found >> 01/08/20 10:20:04 net-ok >> 01/08/20 10:23:04 keep-found >> 01/08/20 10:23:04 net-ok >> 01/08/20 10:26:04 keep-found >> 01/08/20 10:26:04 net-ok > >The weird thing here is the timestamps. I wonder why the clock seems to >jump back for an hour for 3 of the entries. > >> Syslog: >> Jan 8 09:29:04 turris ATLAS[2929]: enough space free, no need to do anything >> Jan 8 09:29:04 turris ATLAS[2929]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory >> Jan 8 09:29:04 turris ATLAS[2929]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory >> Jan 8 09:29:04 turris ATLAS[2929]: condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/v6addr.txt' exists >> Jan 8 09:29:04 turris ATLAS[2929]: condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/simpleping' exists > >This is mostly harmless. On hardware probes, those messages went to >/dev/null. The last two should be gone in the next release of software >probe code. I'll make a note to suppress the first one and make sure to >disable code that generates the 2nd and 3rd on software probes. > >When I look at our logs, I can see something weird that I don't quite >understand. > >The 'ATLAS ' and 'reginit.sh' scripts contain the lines (for the ATLAS >script, lightly different for the reginit.sh script): >#exec >/tmp/ATLAS.out 2>/tmp/ATLAS.err >#set -x > >Maybe you can uncomment those lines in both scripts, reboot and send me >the logs files? > > >Philip > > >

1 0

SW Probe 1000069 issue
by ripe＠brite.cz 09 Jan '20

09 Jan '20

Hi team, I have probe 1000069 running on Turris Omnia. I followed: https://wiki.turris.cz/doc/en/howto/atlas-probe https://atlas.ripe.net/docs/software-probe/ https://www.ripe.net/ripe/mail/archives/atlas-sw-probes/20191023/000002.html https://www.ripe.net/ripe/mail/archives/atlas-sw-probes/20191023/000004.html I was able to install, register and run. It shows as "connected". But - it seems it was working and sending measurement results for couple of minutes after registration yesterday, and then it stopped sending results since then, although it keeps showing "connected". Not sure what to check. The process is running, I restarted the router couple of times since then. Some outputs: root@turris:~# /etc/init.d/atlas log 01/08/20 10:17:01 net-ok 01/08/20 09:17:01 reg-init 01/08/20 09:17:03 ctrl-init 01/08/20 09:17:04 keep-start 01/08/20 10:20:04 keep-found 01/08/20 10:20:04 net-ok 01/08/20 10:23:04 keep-found 01/08/20 10:23:04 net-ok 01/08/20 10:26:04 keep-found 01/08/20 10:26:04 net-ok Syslog: Jan 8 09:29:04 turris ATLAS[2929]: enough space free, no need to do anything Jan 8 09:29:04 turris ATLAS[2929]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory Jan 8 09:29:04 turris ATLAS[2929]: buddyinfo: can't open '/proc/buddyinfo': No such file or directory Jan 8 09:29:04 turris ATLAS[2929]: condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/v6addr.txt' exists Jan 8 09:29:04 turris ATLAS[2929]: condmv: not moving, destination '/usr/libexec/atlas-probe-scripts/data/out/simpleping' exists I couldn't find what the errors mean... Please advise. Thank you Jiri

3 2

Merry Christmas and a HTTP 302
by Radek Zajíc 02 Jan '20

02 Jan '20

Hi everyone, Merry Christmas (or Festive season, if you prefer) and a happy New Year to everyone! I have just registered my first software RIPE probe. I can see it in my RIPE Atlas probe list. When checking systemd logs, I can see that the probe is registered properly with its control server (which is ctr-fsn01.atlas.ripe.net). When I ran the first measurement from it, the measurement didn’t show up on the web. I see the following error in the systemd journal: pro 24 09:36:38 controller ATLAS[8785]: total size in dir: 5668 pro 24 09:36:38 controller ATLAS[8785]: httppost: before getaddrinfo pro 24 09:36:38 controller ATLAS[8785]: httppost: before connect pro 24 09:36:38 controller ATLAS[8785]: httppost: sending request pro 24 09:36:38 controller ATLAS[8785]: posting file '/var/atlas-probe/data/out/ooq/2' pro 24 09:36:38 controller ATLAS[8785]: posting file '/var/atlas-probe/data/out/ooq/1' pro 24 09:36:38 controller ATLAS[8785]: httppost: getting result pro 24 09:36:38 controller ATLAS[8785]: httppost: POST command failed: '302 ' pro 24 09:36:38 controller ATLAS[8785]: httppost: leaving with error pro 24 09:36:38 controller ATLAS[8785]: ooqd: httppost failed with 1 This conforms to what I see in tcpdump: POST /?PROBE_ID=1000060&SESSION_ID=34f398cd76888d91da4adb236e00ded25abf69bcf959509b748ad7e84b33c2c8&SRC=oneoff HTTP/1.1 Host: 127.0.0.1 Connection: close User-Agent: httppost for atlas.ripe.net Content-Type: application/x-www-form-urlencoded Content-Length: 5759 P_TO_C_REPORT RESULT { ... } HTTP/1.1 302 Location: /manage Content-Length: 0 Date: Tue, 24 Dec 2019 08:14:38 GMT Connection: close The question is: why does the probe (talking via the initiated SSH tunnel at 8080:127.0.0.1:8080) receive such a message from the controller? Is this common or a bug? O/S: Ubuntu 18.04, amd64 SW probe version: atlasswprobe==5000-1 Thanks for any insight and/or hint. Cheers, Radek Zajic

2 2

How many SW probes ...
by Novak Jirka 27 Nov '19

27 Nov '19

... can I register on my RIPE SSO account? Only one or more? Thx, NONES

2 1

Re: [atlas-sw-probes] RIPE Atlas sw probe testing kickoff
by Martin Žák 26 Nov '19

26 Nov '19

Hi, my name is Martin Žák and have SSO account with adress martin(a)commar.cz. How to enter public-key? Send for you? ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDWAfGLFnjvdyjMotZuuo0UcKMXGsLvJNHbYdtAiZyGPFPH BVWvI7NVmm9rzB4pMjHzt129x6g0nTWADGmDc/PmaCLZ9zwlkc3QvQ62C6CkSQI5d+CfE4AATyvG Oxc4RE+HBFX+Hcat+oYrcYf0QnzRD1/Jyfv5t0LgU+PHKZLt6ggFQAldPWIghSWJXiKMvH6BOgSV mFT9AFUKPoWdDhg4n0BiUN1dzcHrVgejhqYV3kUtW0dQt2TbtNCBL+acSM6I7RF8ZPfAj31ILOt9 9FVFIvlOHEaNVRMfq861abMu+rFP0KQpul8RaE6XPKMg4XQv1ca1r+fxQrdyIIFGk3nx turris-atlas Thanks. ================================= Martin Žák <mailto:martin@commar.cz> martin(a)commar.cz Skype: martin_unetice tel.: 603 203 618 soukr. tel.: 777 914 715 prac. qrcode (6)

3 2

Current status
by Robert Kisteleki 18 Nov '19

18 Nov '19

Hi, Mini-stats: we have 76 people on this list, and as of now we have 26 sw probes up and running. AFAIK we have some on debian, some centos and some docker experimental ones. Please make use of this list if possible to coordinate efforts, if any. For those who have been subscribed after the initial mails went out: you probably want to check the archives, in particular these two mails, to get you started: https://www.ripe.net/ripe/mail/archives/atlas-sw-probes/20191023/000002.html https://www.ripe.net/ripe/mail/archives/atlas-sw-probes/20191023/000004.html Regards, Robert

1 0

experimental debian support
by Philip Homburg 11 Nov '19

11 Nov '19

Hi, I pushed experimental debian support to the ripe-atlas-software-probe repo. Run 'ripe-atlas-software-probe/build-config/debian/bin/make-deb' to create a debian package. Philip

1 0

Docker Compose Files
by Tobias Sachs 31 Oct '19

31 Oct '19

Hi! Here is the link for the docker-compose project https://github.com/Knight1/ripe-atlas_dockerized <https://github.com/Knight1/ripe-atlas_dockerized> "Should start and report :o“ There is no CI at this point because it is not meant for any stable use at this time but my two servers are running fine. I just want to make sure there are no hidden bugs :) Feel free to open Issues, PR’s or just tell me anything you want :) Is there a possibility for a test atlas account or is this test infra not accessible from the outside? Because I know that there are test and dev servers and I don’t want to add many more test servers just for development to my prod account. Cheers! Tobas

2 1

Feedback from today/yesterday
by Tobias Sachs 29 Oct '19

29 Oct '19

Hi all and a good morning! Just my little feedback from today/yesterday. No big problems so far just minor problems :) 1. There is always this error inside the log even with official software is this known? Is someone other having it? condmv: unable to rename '/var/atlas-probe/data/new/v6addr.txt' to '/var/atlas-probe/data/out/v6addr.txt': No such file or directory 2. What are your thoughts about a 'curl https://install.atlas.ripe.com | bash' ? I know there are many pros and cons for such a setup but overall it would make the process simpler. 3. When you visit https://atlas.ripe.net/apply/swprobe/ without being logged in it redirects to /denied. Ok, logging in.., hmm, still denied :o Turns out that /denied does not check the status from the user after SSO login and SSO simply redirects you back. 4. Near my Probes and only my is „(Register)“, is this on purpose? 5. I managed to make a functional Dockerfile. https://gist.github.com/Knight1/f903d5230890f8fa283601bee1494280 Important infos - There is no check for the ripe files - You have to manually copy the files from the source to the mounted docker folder Testing 1. docker build -t atlas-sw . 2. docker run -it --rm -v /sys/fs/cgroup:/sys/fs/cgroup:ro --cap-add=sys_admin --name=atlas atlas-sw 3. docker cp atlas:/var/atlas-probe/ /opt/docker/atlas-probe/ 4. docker run -it --rm -v /sys/fs/cgroup:/sys/fs/cgroup:ro -v /opt/docker/atlas-probe/:/var/atlas-probe/ --cap-add=sys_admin --name=atlas --memory=128m atlas-sw 6. Any ideas about an official Docker package? Because the container is just running fine :o https://atlas.ripe.net/probes/1000013/ Sure I will monitor the logs and there are some bugs I know to report/fix but in summary it is running and reporting. I only tested ping :o 7. Has someone managed to migrate a ssh private key to a new host? I know that the system is lurking for a file to know about the initialization status but in the file that manages the initialization the statefile is from $1 Cheers! Tobias

5 5

State of sw probe packages
by Robert Kisteleki 23 Oct '19

23 Oct '19

Hi, Here's the current state of packaging: Source of the software is available on on GitHub: https://github.com/RIPE-NCC/ripe-atlas-software-probe This uses a submodule for the actual measurement code: https://github.com/RIPE-NCC/ripe-atlas-probe-busybox I think it's fair to assume that this will serve as the upstream for any packages from now on. The NCC maintains a CentOS 7 (x86_64) binary package. Instructions on how to use this are available at https://atlas.ripe.net/docs/software-probe/. We're likely going to build a CentOS 8 version too. Philip and others worked on a Debian (8-9-10?) port at the IoT hackathon before the RIPE meeting. I believe this is also good news for Raspbian (Pi) users. Pointers will follow. Folks at CZ.NIC generously spent energy on making a Turris (Omnia and Mox) version. I believe these are close to being released. Jan can provide more details. My understanding is that as a by-product of the Turris work an OpenWrt (source) package is/was also made. I'm not sure about the state of this and I might be wrong anyway. Jan, can you clarify? I know of no work as of yet for Docker releases, nor anything on BSDs. We are aware that the code depends on some older libraries (openssl 1.0.x I believe) which are not the ones used in the latest release of various distros. Philip is working on fixing this. That's it for now. Feel free to discuss and/or cooperate the various aspects and releases as you see fit! Cheers, Robert

1 0

Software probes availability?
by hvjunk 23 Oct '19

23 Oct '19

Good day, I think the question on everybody’s mind: When/where can we get KVM images to start testing/deploying? HEndrik

2 1

RIPE Atlas sw probe testing kickoff
by Robert Kisteleki 23 Oct '19

23 Oct '19

Hi, This is the mail that may help you get started with software probes :-) We're in the testing period, meaning we are authorising those who showed interest (i.e. you) to apply for a software probe. I could do this to about 2/3 of you, namely those whose RIPE Atlas SSO account I could find (ie. same as in the testers' survey). The kick-off documentation page for software probes is https://atlas.ripe.net/docs/software-probe/. This has some general info as well as description of how to install the RPM we maintain (CentOS7). The actual page to apply for a software probe is https://atlas.ripe.net/apply/swprobe/. This page is only available to you if your SSO account is already known/authorised (see previous paragraph). Let me know you get an error getting here [1]. Note that in order to apply for your probe, you need to tell us its (SSH) public key. In turn we'll make a probe ID for you once the probe is enabled (pretty soon after application). We'll add a means to replace this key for an existing probe, in case you need to reinstall and lose the original key material. I'll send a separate mail about the current state of software packaging. Cheers, Robert [1] make sure you have an SSO account (make one at https://access.ripe.net/ if needed), then visit the Atlas website while being logged in so that Atlas learns about you, and send me a mail

1 0

Test
by Davide Lucchesi 21 Oct '19

21 Oct '19

Test message. — Davide

1 0