11–20 of 28 posts
As an opensource lover, you gotta appreciate redhat registering a "containers" organisation with rh-only maintained projects. True OSS philosophy at work here!
I've definitely had problems with SLIRP before but which ones does this aim to solve?
As an opensource lover, you gotta appreciate redhat registering a "containers" organisation with rh-only maintained projects. True OSS philosophy at work here!
That's not true. There are projects which are not maintained by RH. Also, anybody could have registered that name before RH... You could have done so.
Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?
SLIRP is a clever tool that turns network traffic (raw IP frames on one side) into connect(2), read, write etc system calls on the other side. eg. If it sees a virtual machine is making a connection by sending a TCP SYN packet, it will on one side turn that into a connect(2) system call, and on the other side send back the appropriate TCP packets to complete the connection. It also does ARP, DNS, etc. If you think of…
While I was still in college in 1999 -- I figured out how to pair a local ppp device with SLIRP on the Sun machines we had shell access on over ssh, enabling me to bounce internet access through our CS network, which got access to a few things we couldn't directly access from our dorms.
Later in my career I learned about the TCP-over-TCP meltdown effect, which explained why I had to restart it every once in a while.
Good times :)
Ok, a stupid question. From what I understand this PR provides a tunnel, so that code in the container's private network namespace sees the external network, as if the code was running on the host. Why is this necessary - is it not possible to make the container use the initial network namespace, and get the same end result in a simpler way?
SLIRP is a clever tool that turns network traffic (raw IP frames on one side) into connect(2), read, write etc system calls on the other side. eg. If it sees a virtual machine is making a connection by sending a TCP SYN packet, it will on one side turn that into a connect(2) system call, and on the other side send back the appropriate TCP packets to complete the connection. It also does ARP, DNS, etc. If you think of…
As an opensource lover, you gotta appreciate redhat registering a "containers" organisation with rh-only maintained projects. True OSS philosophy at work here!
That's not true. There are projects which are not maintained by RH. Also, anybody could have registered that name before RH... You could have done so.
Podman, Buildah, Skopeo and Crun are ALL redhat projects. OSS = Open code (ok) + Open Governance (not ok). In the "containers" org there are currently 23 maintainers, 99% RedHat employees (with a few indies - you always want students contributing for free). This is a great example of enterprise OSS shitshow, whereas a large org register a fake org on github with an intended "open" name - but keep close control on the governance of projects and tries to push (implicitly) its technological stack as a standard.
Disclaimer: I fucking hate enterprise vendors.
Earlier quoted context omitted.
That's not true. There are projects which are not maintained by RH. Also, anybody could have registered that name before RH... You could have done so.
Mate, I've been working in this space for long enough to know exactly what I'm talking about. Podman, Buildah, Skopeo and Crun are ALL redhat projects. OSS = Open code (ok) + Open Governance (not ok). In the "containers" org there are currently 23 maintainers, 99% RedHat employees (with a few indies - you always want students contributing for free). This is a great example of enterprise OSS shitshow, whereas a large…
Earlier quoted context omitted.
SLIRP is a clever tool that turns network traffic (raw IP frames on one side) into connect(2), read, write etc system calls on the other side. eg. If it sees a virtual machine is making a connection by sending a TCP SYN packet, it will on one side turn that into a connect(2) system call, and on the other side send back the appropriate TCP packets to complete the connection. It also does ARP, DNS, etc. If you think of…
I have a project that relies on user mode networking. passt is a very welcome development. Really hoping it supports Windows QEMU hosts at some point.
Anyhow, the presentation mentioned above explains which Linux extensions are needed.
Maybe I'm wrong but I thought netavark already replaced slirp4netns