NSS-MYMACHINES(8)

πŸ’… NSS-MYMACHINES(8) β€” like, the manual page, but make it make sense

okay bestie, so this page is literally called nss-mymachines (the manual section is 8, iykyk) and it's about the little library file libnss_mymachines.so.2. yeah. we're doing this. 🫢


✨ NAME ✨

nss-mymachines, libnss_mymachines.so.2 β€” hostname resolution for your local container instances 🐳✨


πŸŽ€ SYNOPSIS πŸŽ€

libnss_mymachines.so.2

that's it. that's the whole synopsis. iconic, honestly.


πŸ¦‹ DESCRIPTION πŸ¦‹

so nss-mymachines is a plug-in module for the GNU Name Service Switch (NSS) functionality of the GNU C Library (glibc), and what it does is provide hostname resolution for the names of containers that are running locally and are registered with systemd-machined.service(8). like, you type a container's name, it hands you an IP. slay. πŸ’…

the container names get resolved to the IP addresses of that specific container, ordered by their scope. no cap.

quick vibe check though: this functionality only applies to containers that are using network namespacing β€” see the description of --private-network in systemd-nspawn(1). and heads up, the name that gets resolved is the one registered with systemd-machined, which may be different than the hostname configured inside the container. so don't come for me if the vibes don't match the nameplate. 😭

also note: this NSS module only makes available names of the containers running immediately below the current system context. it does not provide host name resolution for containers running side-by-side with the invoking system context, or containers further up or down the container hierarchy.

or, in other words (because I know you were about to ask πŸ™ˆ): on the host system it provides host name resolution for the containers running immediately below the host environment. but when used inside a container environment, it will not be able to provide name resolution for containers running on the host β€” because those are siblings and not children of the current container environment β€” and instead only for nested containers running immediately below its own container environment. family tree rules, bestie. it's giving strict ancestry. 🌳

to activate the NSS module, add "mymachines" to the line starting with "hosts:" in /etc/nsswitch.conf. that's the whole ritual. ✨

and it is recommended to place "mymachines" before the "resolve" or "dns" entry of the "hosts:" line of /etc/nsswitch.conf, so you can make sure that its mappings are preferred over other resolvers such as DNS. put your girl first in line. πŸ‘‘


🌸 CONFIGURATION IN /ETC/NSSWITCH.CONF 🌸

here's an example /etc/nsswitch.conf file that enables nss-mymachines correctly β€” copy it, don't freestyle it:

passwd:         files systemd
group:          files [SUCCESS=merge] systemd
shadow:         files systemd
gshadow:        files systemd

hosts:          mymachines resolve [!UNAVAIL=return] files myhostname dns
networks:       files

protocols:      db files
services:       db files
ethers:         db files
rpc:            db files

netgroup:       nis

look at that hosts: line. mymachines is literally first. main character energy. πŸ’–


πŸ”₯ EXAMPLE: MAPPINGS PROVIDED BY NSS-MYMACHINES πŸ”₯

so the container "rawhide" is spawned using systemd-nspawn(1):

# systemd-nspawn -M rawhide --boot --network-veth --private-users=pick
Spawning container rawhide on /var/lib/machines/rawhide.
Selected user namespace base 20119552 and range 65536.
...

then you peek at what's registered:

$ machinectl --max-addresses=3
MACHINE CLASS     SERVICE        OS     VERSION ADDRESSES
rawhide container systemd-nspawn fedora 30      169.254.40.164 fe80::94aa:3aff:fe7b:d4b9

and then the resolution goes off. first the IPv6 one (the default, no cap):

$ ping -c1 rawhide
PING rawhide(fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide)) 56 data bytes
64 bytes from fe80::94aa:3aff:fe7b:d4b9%ve-rawhide (fe80::94aa:3aff:fe7b:d4b9%ve-rawhide): icmp_seq=1 ttl=64 time=0.045 ms
...

and then force it to v4 with -4:

$ ping -c1 -4 rawhide
PING rawhide (169.254.40.164) 56(84) bytes of data.
64 bytes from 169.254.40.164 (169.254.40.164): icmp_seq=1 ttl=64 time=0.064 ms
...

and then you hop inside and check the interfaces yourself:

# machinectl shell rawhide /sbin/ip a
Connected to machine rawhide. Press ^] three times within 1s to exit session.
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    ...
2: host0@if21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 96:aa:3a:7b:d4:b9 brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet 169.254.40.164/16 brd 169.254.255.255 scope link host0
       valid_lft forever preferred_lft forever
    inet6 fe80::94aa:3aff:fe7b:d4b9/64 scope link
       valid_lft forever preferred_lft forever
Connection to machine rawhide terminated.

the way those addresses match up?? obsessed. 🧚

tiny reminder since we're here: to exit that shell session you press Ctrl+] three times within 1s. the manpage says so, so I say so. πŸ’€

πŸ‘‘ SEE ALSO πŸ‘‘

go read these next, bestie, they're all connected:


okay that's the whole page!! πŸ’œ this iconic little entry ships with systemd 259.10 and it's filed under NSS-MYMACHINES(8). go forth and resolve some containers, bestie β€” mwah πŸŽ€βœ¨

πŸ“¦ where this page comes from