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
Hi, Thank you for the report, it's really helpful! We'll have to see if some of this should be turned into github issues -- there are pros and cons as always. On 2019-10-24 05:10, Tobias Sachs wrote:
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.
It's possible. I'm personally against piping stuff you just downloaded into shell but YMMV :-) In any case, one would have to go through prompts and such anyway, for example to check GPG key ids and hashes and such.
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.
Yes, that's annoying. But, this is only applicable during the testing period so maybe it's not worth solving...
4. Near my Probes and only my is „(Register)“, is this on purpose?
No, that will need to go away. It's also a typical example of the zillion small things we need to adapt for sw probes. Thanks for pointing it out.
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
Nice!
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
I believe there will be demand for a docker version, so I'm happy that it's emerging! The way I see it there are some issues to resolve: * permanent storage of key material, so outside the container? * how to handle upgrading if there's a new (upstream) available * perhaps more to make this version sustainable It's be nice to get to a point where we can claim the docker version is as complete as any other release in all respects.
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
Can you explain what problem you want to solve? If you want to "move" your probe from one server to another as a one-off action, you can always just install the new one, submit its key to us as a replacement [almost implemented :-)] and stop the old instance. Cheers, Robert
Cheers! Tobias
Hi everyone, Happy to see progress on software probes :). I will try to deploy it on our raspberries on the weekend. My thoughts on the docker stuff, we should aim to make it run with alpine linux before we release an official container, because a CentOS container seems to be too bloated. Storage outside of the container should be no problem, I suggest we make a docker-compose file to setup all the storage stuff etc.. If there is an upgrade script between versions we should run the upgrade script at every container start. Best, Annika
On 24. Oct 2019, at 09:21, Robert Kisteleki <robert@ripe.net> wrote:
Hi,
Thank you for the report, it's really helpful! We'll have to see if some of this should be turned into github issues -- there are pros and cons as always.
On 2019-10-24 05:10, Tobias Sachs wrote:
2. What are your thoughts about a 'curl https://install.atlas.ripe.com <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.
It's possible. I'm personally against piping stuff you just downloaded into shell but YMMV :-) In any case, one would have to go through prompts and such anyway, for example to check GPG key ids and hashes and such.
3. When you visit https://atlas.ripe.net/apply/swprobe/ <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.
Yes, that's annoying. But, this is only applicable during the testing period so maybe it's not worth solving...
4. Near my Probes and only my is „(Register)“, is this on purpose?
No, that will need to go away. It's also a typical example of the zillion small things we need to adapt for sw probes. Thanks for pointing it out.
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
Nice!
6. Any ideas about an official Docker package? Because the container is just running fine :o https://atlas.ripe.net/probes/1000013/ <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
I believe there will be demand for a docker version, so I'm happy that it's emerging! The way I see it there are some issues to resolve: * permanent storage of key material, so outside the container? * how to handle upgrading if there's a new (upstream) available * perhaps more to make this version sustainable
It's be nice to get to a point where we can claim the docker version is as complete as any other release in all respects.
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
Can you explain what problem you want to solve? If you want to "move" your probe from one server to another as a one-off action, you can always just install the new one, submit its key to us as a replacement [almost implemented :-)] and stop the old instance.
Cheers, Robert
Cheers! Tobias
Hi!
Am 24.10.2019 um 09:21 schrieb Robert Kisteleki <robert@ripe.net>:
I believe there will be demand for a docker version, so I'm happy that it's emerging! The way I see it there are some issues to resolve: * permanent storage of key material, so outside the container? * how to handle upgrading if there's a new (upstream) available
The question I have is a more sustainable versioning overall. On GitHub is just the source code available but not the rpm. Key is stored outside with the docker overlay2 driver or directly on the disk. I would prompt the users to make a backup from it. Upgrading can handle another container, it just watches for a new version, pulls it, deletes the old container and is starting the new one. With CentOS at this time it is a good idea to keep the software inside docker up to date :)
Can you explain what problem you want to solve? If you want to "move" your probe from one server to another as a one-off action, you can always just install the new one, submit its key to us as a replacement [almost implemented :-)] and stop the old instance.
Sure, but both solutions are producing the same end result. The same probe ID is reporting.
Happy to see progress on software probes :). I will try to deploy it on our raspberries on the weekend.
My thoughts on the docker stuff, we should aim to make it run with alpine linux before we release an official container, because a CentOS container seems to be too bloated.
Storage outside of the container should be no problem, I suggest we make a docker-compose file to setup all the storage stuff etc.. If there is an upgrade script between versions we should run the upgrade script at every container start.
Hi Anika, Any success with RPI? The problem at this time is that we need tini for handling multiple running processes inside one container like cron, SSH, telnet, the pings and pongs, so implementing that into Alpine would also be an overhead :) ### CGroup: /docker/XYZ/system.slice/atlas.service ├─ 28 /bin/sh /usr/local/atlas/bin/ATLAS ├─ 73 /usr/local/atlas/bb-13.3/usr/sbin/telnetd -b 127.0.0.1 -p 2023 -P /var/atlas-probe/run/telnetd-port2023-pid.vol ├─ 95 /usr/local/atlas/bb-13.3/bin/perd -c /var/atlas-probe/crons/main -A 9801 -P /var/atlas-probe/run/perd-main.pid.vol ├─ 97 /usr/local/atlas/bb-13.3/bin/eperd -c /var/atlas-probe/crons/7 -A 9807 -P /var/atlas-probe/run/perd-7.pid.vol -O /home/atlas/data/new/7 -i 7 ├─ 98 /bin/sh /usr/local/atlas/bin/ATLAS ├─ 100 /usr/local/atlas/bb-13.3/bin/eooqd /var/atlas-probe/crons/oneoff -A 9809 -P /var/atlas-probe/run/eooqd.pid.vol -i 9 ├─ 124 /usr/bin/ssh -o ServerAliveInterval 60 -o StrictHostKeyChecking yes -o UserKnownHostsFile /var/atlas-probe/.ssh/known_hosts -R 54453:127.0.0.1:2023 -L 8080:127.0.0.1:8080 -i /var/a... └─11726 sleep 180 ### Afaik there is no upgrade needed? The only dependency we have inside Docker is the magic ssh key :)
Having been through a Docker to Kubernetes (and custom container controllers along the way as well), I recommend that any secrets be optionally (preferred) made available by environment variables. The supervisor (tini?) can extract this information. K8S, for example, makes it very easy to specify values stored in secret vault to be made available as env variables to the container. Docker similarly allows specifying this way. In a previous company we had up to 5 different ways that a container could accept runtime config (cmd line, environment, config file, http pull/push). In the end environment was the preferred way. -phil From: atlas-sw-probes <atlas-sw-probes-bounces@ripe.net> on behalf of Tobias Sachs <tobias@tobiassachs.de> Date: Monday, October 28, 2019 at 6:54 PM To: "atlas-sw-probes@ripe.net" <atlas-sw-probes@ripe.net> Subject: Re: [atlas-sw-probes] Feedback from today/yesterday Hi! Am 24.10.2019 um 09:21 schrieb Robert Kisteleki <robert@ripe.net<mailto:robert@ripe.net>>: I believe there will be demand for a docker version, so I'm happy that it's emerging! The way I see it there are some issues to resolve: * permanent storage of key material, so outside the container? * how to handle upgrading if there's a new (upstream) available The question I have is a more sustainable versioning overall. On GitHub is just the source code available but not the rpm. Key is stored outside with the docker overlay2 driver or directly on the disk. I would prompt the users to make a backup from it. Upgrading can handle another container, it just watches for a new version, pulls it, deletes the old container and is starting the new one. With CentOS at this time it is a good idea to keep the software inside docker up to date :) Can you explain what problem you want to solve? If you want to "move" your probe from one server to another as a one-off action, you can always just install the new one, submit its key to us as a replacement [almost implemented :-)] and stop the old instance. Sure, but both solutions are producing the same end result. The same probe ID is reporting. Happy to see progress on software probes :). I will try to deploy it on our raspberries on the weekend. My thoughts on the docker stuff, we should aim to make it run with alpine linux before we release an official container, because a CentOS container seems to be too bloated. Storage outside of the container should be no problem, I suggest we make a docker-compose file to setup all the storage stuff etc.. If there is an upgrade script between versions we should run the upgrade script at every container start. Hi Anika, Any success with RPI? The problem at this time is that we need tini for handling multiple running processes inside one container like cron, SSH, telnet, the pings and pongs, so implementing that into Alpine would also be an overhead :) ### CGroup: /docker/XYZ/system.slice/atlas.service ├─ 28 /bin/sh /usr/local/atlas/bin/ATLAS ├─ 73 /usr/local/atlas/bb-13.3/usr/sbin/telnetd -b 127.0.0.1 -p 2023 -P /var/atlas-probe/run/telnetd-port2023-pid.vol ├─ 95 /usr/local/atlas/bb-13.3/bin/perd -c /var/atlas-probe/crons/main -A 9801 -P /var/atlas-probe/run/perd-main.pid.vol ├─ 97 /usr/local/atlas/bb-13.3/bin/eperd -c /var/atlas-probe/crons/7 -A 9807 -P /var/atlas-probe/run/perd-7.pid.vol -O /home/atlas/data/new/7 -i 7 ├─ 98 /bin/sh /usr/local/atlas/bin/ATLAS ├─ 100 /usr/local/atlas/bb-13.3/bin/eooqd /var/atlas-probe/crons/oneoff -A 9809 -P /var/atlas-probe/run/eooqd.pid.vol -i 9 ├─ 124 /usr/bin/ssh -o ServerAliveInterval 60 -o StrictHostKeyChecking yes -o UserKnownHostsFile /var/atlas-probe/.ssh/known_hosts -R 54453:127.0.0.1:2023 -L 8080:127.0.0.1:8080 -i /var/a... └─11726 sleep 180 ### Afaik there is no upgrade needed? The only dependency we have inside Docker is the magic ssh key :)
On 2019/10/24 5:10 , Tobias Sachs wrote:
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
This is harmless. I made a note to suppress this message. Philip
participants (5)
-
Annika Wickert -
Phil Stanhope -
Philip Homburg -
Robert Kisteleki -
Tobias Sachs