mirror of https://github.com/containers/podman.git
Update CNI so we can match wrapped errors. This should silence ENOENT warnings when trying to read the cni conflist files. Fixes #10926 Because CNI v1.0.0 contains breaking changes we have to change some import paths. Also we cannot update the CNI version used for the conflist files created by `podman network create` because this would require at least containernetwork-plugins v1.0.1 and a updated dnsname plugin. Because this will take a while until it lands in most distros we should not use this version. So keep using v0.4.0 for now. The update from checkpoint-restore/checkpointctl is also required to make sure it no longer uses CNI to read the network status. [NO TESTS NEEDED] Signed-off-by: Paul Holzinger <pholzing@redhat.com> |
||
---|---|---|
.. | ||
LICENSE | ||
README.md | ||
go.mod | ||
go.sum | ||
netns.go | ||
netns_linux.go | ||
netns_unspecified.go |
README.md
netns - network namespaces in go
The netns package provides an ultra-simple interface for handling network namespaces in go. Changing namespaces requires elevated privileges, so in most cases this code needs to be run as root.
Local Build and Test
You can use go get command:
go get github.com/vishvananda/netns
Testing (requires root):
sudo -E go test github.com/vishvananda/netns
Example
package main
import (
"fmt"
"net"
"runtime"
"github.com/vishvananda/netns"
)
func main() {
// Lock the OS Thread so we don't accidentally switch namespaces
runtime.LockOSThread()
defer runtime.UnlockOSThread()
// Save the current network namespace
origns, _ := netns.Get()
defer origns.Close()
// Create a new network namespace
newns, _ := netns.New()
defer newns.Close()
// Do something with the network namespace
ifaces, _ := net.Interfaces()
fmt.Printf("Interfaces: %v\n", ifaces)
// Switch back to the original namespace
netns.Set(origns)
}
NOTE
The library can be safely used only with Go >= 1.10 due to golang/go#20676.
After locking a goroutine to its current OS thread with runtime.LockOSThread()
and changing its network namespace, any new subsequent goroutine won't be
scheduled on that thread while it's locked. Therefore, the new goroutine
will run in a different namespace leading to unexpected results.
See here for more details.