moby--moby/vendor/github.com/vishvananda/netns
Sebastiaan van Stijn de0eabbd66
vendor: github.com/vishvananda/netns v0.0.0-20210104183010-2eb08e3e575f
full diff: db3c7e526a...2eb08e3e57

- Add support for detecting netns for all possible QoS in Kubernetes
- Add go1.10 build constraint

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
2022-03-01 22:58:47 +01:00
..
LICENSE
README.md vendor: github.com/vishvananda/netns v0.0.0-20210104183010-2eb08e3e575f 2022-03-01 22:58:47 +01:00
netns.go vendor: vishvananda/netns db3c7e526aae966c4ccfa6c8189b693d6ac5d202 2020-07-28 21:26:13 +02:00
netns_linux.go vendor: github.com/vishvananda/netns v0.0.0-20210104183010-2eb08e3e575f 2022-03-01 22:58:47 +01:00
netns_unspecified.go bump libnetwork. vishvananda/netlink 1.0, vishvananda/netns 2019-06-25 14:10:15 +02:00

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.