grawity

Internal or external? Where is it showing as "RAW"? Your screenshot doesn't show that.

Same goes for lslocks, lsfd, and probably some others.

The program works by checking the namespaces of each and every process (via /proc/PID/ns) – it doesn't get the command from namespace, but the other way around – and if you run it without sudo, it might not have access to see certain processes, or to determine that they also hold the same namespaces, so its guess as to what process might be the "main" process will vary depending on the information it was able to collect.

Multiple processes can hold the same namespace (like how a whole container belongs to a single net namespace and everything), so lsns has to guess which one of them is the most important for the purpose of the list.

sudo lsns -t net could be used to find all network namespaces that exist, and sudo nsenter --net --target <pid> to enter it (or nsenter --all for mount namespace etc).

So if you want to use nsenter to look inside some namespace (which does basically the same thing as ip netns exec) you have to specify a PID of some process that's in that namespace, like the container's main PID.

Namespaces are nameless by default (both network namespaces and other kinds) – they're only associated with the processes holding them. The ip netns tool can be used to make a net namespace persistent and give it a name, but it's optional; if Docker doesn't bind it to a name under /run/netns then ip netns will not show it.

(Programs can still send raw L2 packets "manually", like arping for manually testing ARP queries, and some tools like ping -I have an option to send IP directly through a specific interface, bypassing the routing table... but those are mostly exceptions.)

Without a routing table entry going through some interface, yes, that interface mostly remains useless – though there are various exceptions, e.g. I think it'll still answer ARP queries as long as it has an IP address at all, and can still receive IP packets, just won't send them.

Omitting the slash suffix depends on which era the tools come from – modern tools would assume just a single IP (i.e. equal to a /32 or /128), older tools might assume the "classful addressing" scheme from 1980s. With ifconfig for example, if you do just ifconfig eth0 192.168.3.4 I think it still assumes a /24 because anything 192.x used to be Class C several decades ago.

It's mainly just VM/container platforms like Docker that try to automatically assign 172.17, 172.18 etc. to each new virtual network they manage (in hopes that it won't conflict with the user's real network)

Well, not exactly automatically – you have to decide on the address block for each network, and configure addresses on the corresponding interfaces. Your host receives that config from the router via DHCP, but the router itself has been configured manually to be on 192.168.1.1/24 (even if it's factory default). If there's no DHCP or similar, then the new interface will just stay without an address until you configure one

Yes, the /24 means slightly different things in those two contexts – when an address is configured on an interface it's still just one address, and the "/24" is just used to derive the 192.168.1.0/24 route.

Really both the 198.19.249.0/24 and 0.0.0.0/0 routes match, but the /24 is "more specific" so it's the one that gets used, and the /0 only gets used if nothing else matches. If you delete the /24 route, then the /0 default route will be used.

So yes, when you have a packet for the printer at 198.19.249.42, the OS will look in its routing table, find the local route (according to the subnet mask that was configured on the NIC), and will go ahead and make an ARP query to learn the printer's MAC addrss (layer 2 address) for sending it there.

Subnet masks get converted to dev routes, the default gateway gets converted to a 0.0.0.0/0 via ... route, and it becomes a single routing-table lookup that covers every situation instead of three different lookup types for the different cases.

So if you have a packet to 192.168.1.5, for example, the OS doesn't directly go looking for an interface that's in the matching subnet to figure out if that address is local on that interface – it could, I'm pretty sure some minimal OSes do that, but a "full" OS like Linux or Windows will convert everything to routes and then look at the routing table since that's a more general and flexible approach.

The router knows the subnet is local via its eth2 (or whatever) the same way the host does – its interface was configured with the corresponding IP address/netmask, and it derives the local route from that, e.g. it has a 192.168.1.0/24 dev eth0 route because eth0 was configured with an 192.168.1.1/24 IP address.

Which is particularly important to gateways which always have more than one physical connection, e.g. the home router being connected to your LAN switch on its "eth0" and to some WAN interface on its "eth1". The route specifying 192.168.1.0/24 dev eth0 is what tells it to send bits towards the LAN Ethernet and not through the WAN.

(And the virtual interfaces, like container veth, just imitate that concept 1:1. There is no common pool of "all locally reachable hosts", unless you use an Ethernet switch or a 'bridge' interface to create that out of individual one-to-one connections.)

Interfaces mainly represent physical connections. If you have two Ethernet interfaces, eth0 and eth1 (with cables going in opposite directions to different networks) then you have to physically send the signal over the correct cable so that they reach the correct network. No amount of IP address will help if the device is on the other end of cable A but you sent the bits over cable B, for example

But if you change your host's routes so that it sends everything towards the gateway (e.g. a longer subnet mask), then the gateway will use its routing table in exactly the same way – it'll also see that the subnet is local via its eth2 or eth-lan, and will forward the packets to the printer's MAC address ... and will also inform your host that it ought to be talking to the printer directly (with an ICMP 'Redirect' packet).

(Incidentally, the actual OSI protocols – namely ISO CLNP – don't really do that; a CLNP host would send even local packets through a gateway until the gateway informs it about a more-direct path. But we're not using CLNP anymore (outside of airports), we're using IPv4/IPv6, and creating this shortcut is the very purpose of the netmask in IP.)

Within a local network, you already don't use a default gateway. Your host, after consulting its routing table, finds a local 'dev eth0' route and knows that it can reach the destination directly at Ethernet level, so it will just make a direct ARP query and send the pings towards the printer's MAC address instead of the gateway's. Indeed that's the exact purpose of the subnet mask (and of the route you deleted) – it tells the host which addresses are reachable in this way.

Another note – even if you're pinging your own addresses (e.g. taking an address from ip addr on the host and pinging it from the same host), an interface which is bridged doesn't do any IP processing; the bridge takes that over. So I would not be surprised if you got no response from fe80::38fd:c6ff:fe37:f54%vethbf1bfcc as long as it is in the bridge.

And as for the IPv6 addresses – the fe80:: "link-local" addresses are always a special case (to some extent they're an exception to what I just said about local routes), because every interface uses the same fe80:: prefix, and you always have to manually specify which interface to use. For example, ping fe80::d84c:3aff:fef1:e382%eth0 to ping your physical router via eth0, and ping fe80::blah%docker0 to ping a container that is on the docker0 bridge, and ping fe80::blah%veth-blah to ping a container that has an un-bridged veth.

So the veth is what allows the containers to be on the same (virtual) network as the host. When the veths are part of a bridge, then the whole bridge is a local network, and you can indeed ping any address on the bridge's subnet – but only as long as your routing table informs the OS that those addresses are in fact part of the local network. The route you deleted was the "local subnet" route that the OS automatically generates from the subnet mask; that's what allowed it to know that 172.18.0.0/16 is local on br-asdfg. You'd get the same result if you deleted the 192.168.1.0/24 eth0 route.

There is no "the" local network: each interface with an IP address connects to a separate local network. Your host belongs to three: one physical via eth0 and two virtual networks via 'br' interfaces. Which leads to the point that network interfaces are the means by which the host connects to some network – normally your containers do not have the eth0 that your host has; the only interface (and therefore, network connection) they have is the 'veth' that connects them to the host's corresponding veth, and through it to the 'br-asdfgh' local network.

I really want to drive the point home that the deliberate purpose of network namespaces is to make containers act like separate network nodes, i.e. like VMs or actual physical hosts. All of the same networking concepts apply: IP routing with your eth0 connected to another PC's eth0 works the same as a veth connected to a container's veth – with both needing their own IPs and agreeing on a subnet mask, and of course your ip only seeing your own eth0 but not the other host's. (Admittedly there are some oddities like "macvlan", but you aren't using those right now.)

Veths always come in pairs, imitating a cable that has two ends, but both veths that you see are the 'A' end (so to speak) of their respective pairs, while the 'B' end has been reassigned into each of the containers and is no longer visible to ip in the host namespace. The only way to see those other interfaces is to run the ip command within the respective machine – for containers, that's done using nsenter or using some Docker-specific command (or of course by SSH'ing into the container).

You can skip the bridge but not the IP configuration, i.e. if you remove vethbf1bfcc from the bridge, then vethbf1bfcc itself needs to have an IP address configured on it, just as a regular eth0 would (and it ought to be to be a distinct subnet from the 172.18.0.0/16 that's used by the bridge).

For what it's worth, what I've heard that the "AHCI vs IRST" option isn't necessarily SATA-only on some mainboards – i.e. its label is not entirely accurate to what it does – as Intel has a similar kind of thing with NVMe, where its "Intel VMD" might grab control of all NVMe PCI devices on the system and put them behind the VMD controller (which needs a vendor driver); and I have seen posts stating that telling the system firmware to switch the SATA controller to pure AHCI mode also had the effect of disabling VMD for NVMe on their PCs.

Does it have permissions to read from LDAP? (is it using anonymous bind or a bind DN+password or SASL EXTERNAL?)

Then olcDatabase={1}mdb is the already created database for your regular entries, and that entry's olcSuffix: should tell you the top-level DN that it was configured for (which is the first entry that you'll need to ldapadd).

I'd also recommend installing Apache Directory Studio; it's a bit more convenient than manual CLI usage (at least for management – I still use :w !ldapadd from Nvim to create new entries).

Yes, you'll need create the parent objects before you can create anything underneath them. (OUs are objectClass: organizationalUnit.) Users don't necessarily have to go into an OU though – if the directory is going to be small, it's usually fine to create user objects directly under your root object; they can always be moved later (e.g. if it turns out that some app insists on having an OU specified).

Schema is customizable, as part of LDAP design – OpenLDAP comes with both variants of the NIS or POSIX account schema under /etc/(open)ldap/schema. Most of those aren't loaded by default.

the temporary ext4 might work but seems overkill; it'll be easier to use an in-memory filesystem, such as tmpfs (most Linux systems already have a tmpfs at /run these days, and often but not always at /tmp, and you can copy e.g. Busybox to it).

The difference is that shred tries to overwrite the contents of the file, which older Linux kernels would disallow, in newer kernels it's allowed (but can cause the program to crash), while rm just unlinks it without changing its contents. The issue is that programs don't necessarily load into memory in full; the executable and library files are paged-in as needed, and if the file is overwritten that'll also overwrite code in the page cache. (or e.g. if the physical storage disappears, the program will run from page cache but will crash if it needs to load the remaining code.)

What does it report when connecting to the server using ssh -X or ssh -Y? The SDDM-created xauth file is irrelevant here.

Does xauth list $DISPLAY report any entries on the client, immediately before running ssh? Is $XAUTHORITY set on the client side, before running ssh? What's the exact error message you get?

@Player_X_YT: Can you clarify whether sddm is on the "X server" side or the "SSH server" side? Is lightdm on the "X client" side or the "SSH client" side? (Normally those are always opposite; the SSH client runs on the X server and vice versa; and it's very unclear which way you're trying to make the connection go.)

@terdon: The local and remote paths normally have nothing to do with each other. (I believe OP is likewise misunderstanding that X forwarding and using the server's Xorg are mutually exclusive things.) In addition, though, the local side generally has two distinct xauth files: one for X apps as the "keys to use when connecting" list (that's the ~/.Xauthority file) and a separate one for the X server as the "keys to accept" list (often in /tmp or /run), so although I don't know about SDDM, it's normal that e.g. pgrep Xorg will show a different "-auth /foo/bar" than the one in $XAUTHORITY.

@terdon: That explanation doesn't make sense. If OP wants to forward the X11 connections to their local Xorg over SSH, then by definition those X11 connections will not go anywhere near the Xorg running on the SSH server, and have no need to use its Xauth file; they need to use the Xauth file that represents the forwarded connection, as that will be the only one that contains the correct auth data for the "SSH client"-side X server (and which is generated by sshd as part of setting up the forward).

I think it was docs.google.com/document/d/… that tried to make a better historical explanation of all that, rather than trying to retrofit OSI model to non-OSI things again

e.g. the session layer was defined to provide communications over half-duplex connections, and Internet doesn't really have those (half-duplex is dealt at a much much lower layer)

I remember someone explaining the two weird layers as a relic specifically of the mainframe era, though

as well as a set of actual protocols that used to implement them, once upon a time

@northerner the OSI model does specify how protocols should work – specifically, how OSI protocols should work; there's a whole set of standards at ITU-T that describe the function of each layer

I'm pretty sure apt-pinning has existed for at least two decades... I remember using it to install "testing" packages onto "stable" at many times.