Lý sự pclouds

wow set! is a special form

"amazing how players swing between hesitantly right and confidently wrong"

Looks pretty simple, and even though power management is still not optimized until Turing. At least there's no xrandr to switch screen at X startup.

The old xorg.conf for Optimus looks like this

Section "Module"
    Load "modesetting"
EndSection

Section "Device"
    Identifier "intel"
    Driver "modesetting"
    BusID "PCI:0:2:0"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "PCI:4:0:0"
    Option "AllowEmptyInitialConfiguration" "yes"
EndSection

Section "Screen"
    Identifier "nvidia"
    Device "nvidia"
EndSection

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "nvidia"
    Inactive "intel"
EndSection

Not sure if the "intel" screen is needed. But basically we set up two GPU devices and attach them to two screens, but in the end we specify to use nvidia screen. The other screen will be used behind the scene by nvidia and xrandr.

The new config looks more like this

Section "Module"
    Load "modesetting"
EndSection

Section "Device"
    Identifier "intel"
    Driver "modesetting"
    BusID "PCI:0:2:0"
EndSection

Section "Screen"
    Identifier "intel"
    Device "intel"
EndSection

Section "Device"
    Identifier "nvidia"
    Driver "nvidia"
    BusID "PCI:4:0:0"
    Option "AllowEmptyInitialConfiguration" "yes"
EndSection

Section "ServerLayout"
    Identifier "layout"
    Screen 0 "intel"
    Option "AllowNVIDIAGPUScreens"
EndSection

We still configure two GPUs, but only the intel screen is specified and used. The server layout section has an extra line to make use of the nvidia device.

That's it. To use nvidia for rendering, you need to set __NV_PRIME_RENDER_OFFLOAD=1 and __GLX_VENDOR_LIBRARY_NAME=nvidia. The former for Vulkan, the latter OpenGL.

To use CUDA (e.g. ffmpeg nvenc) then nvidia-uvm needs to be loaded and it's only built with uvm USE flag in nvidia-drivers.

To use external monitors (that are hard wired to NVIDIA card instead of the integrated one), this command must still be run

xrandr --setprovideroutputsource NVIDIA-G0 modesetting

Cập nhật 2 lần. Lần cuối: Wed Apr 13 14:57:21+0003 2022

The file can be search if full path is not given. ".desktop" extension can be skipped too.

Rebuild systemd without resolvconf USE flag. Then emerge openresolv.

Wireguard seems all the rage these days. But it seems quite simple to configure, as advertised. Not so sure about speed.

Anyway, this is a standard encrypted tunnel connecting two subnets. These should be "private" subnets, not related to any other networks. Let's allocate the client end with 192.168.2.0/24 and the server end 192.168.3.0/24.

Two authenticate and encrypt stuff, wiregard uses public and private keys. Each endpoint has a set of keys like this. You can generate it with wg. For client side:

$ P=$(wg genkey);echo Private: $P; echo Public: $(echo $P|wg pubkey)
Private: yPcUBdVfvZJp1NK5NXsNjldagv3nAzD7i5nZUng4Fns=
Public: 6Ye93aP1/xDVCtNieYTwXZcnrxq6vc0IkaPVopBNxlI=

and for server side

$ P=$(wg genkey);echo Private: $P; echo Public: $(echo $P|wg pubkey)
Private: wPSzCFCC2vy7XT1eAhxBsTESls31sGdOOXoH+Fnhalw=
Public: uCVsuTV3gW8FV2U8Bv5mNV4PJEXh15Thzj/AN6UTWiI=

It goes without saying that private keys need to be kept secret.

Now let's configure the server side. I'll stay with the quick-n-dirty wg-quick for server side. Add a file /etc/wireguard/wg0s.conf like this:

[Interface]
Address = 192.168.3.1/24
PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o ens3 -j MASQUERADE
ListenPort = 5544
PrivateKey = wPSzCFCC2vy7XT1eAhxBsTESls31sGdOOXoH+Fnhalw=

[Peer]
PublicKey = 6Ye93aP1/xDVCtNieYTwXZcnrxq6vc0IkaPVopBNxlI=
AllowedIPs = 192.168.2.0/24

Here what it is saying is to configure a new network interface wg0s with address and subnet 192.168.3.1/24. Listen on UDP port 5544 (globally, not related to just that addrress). And this server endpoint has the private key blah blah blah (pubkey could be derived from private key, just like you run the wg pubkey above).

For each tunnel, you'll need a Peer section. Here we only have one tunnel, so one peer with its public key and the list of allowed IPs.

AllowedIPs, according to wireguard website, can be used as both routing and access list. Packets coming to the tunnel must be in the list. And when you have multiple peers, then these address ranges will be used to select the right peer. Multiple address ranges are fine.

Here we make sure we accept all IPs from the client subnet.

So that's it. You can start it with

# wg-quick up wg0s
[#] ip link add wg0s type wireguard
[#] wg setconf wg0s /dev/fd/63
[#] ip -4 address add 192.168.3.1/24 dev wg0s
[#] ip link set mtu 1420 up dev wg0s
[#] ip -4 route add 192.168.2.0/24 dev wg0s
[#] iptables -A FORWARD -i wg0s -j ACCEPT; iptables -A FORWARD -o wg0s -j ACCEPT; iptables -t nat -A POSTROUTING -o ens3 -j MASQUERADE

Here you see the effect of PostUp entry in the config file. It's really nothing fancy here. Most of the config file is sent to wg0s interface via setconf command. The rest is more or less straightforward. You can check its status:

# wg show
interface: wg0s
  public key: uCVsuTV3gW8FV2U8Bv5mNV4PJEXh15Thzj/AN6UTWiI=
  private key: (hidden)
  listening port: 5544

peer: 6Ye93aP1/xDVCtNieYTwXZcnrxq6vc0IkaPVopBNxlI=
  allowed ips: 192.168.2.0/24

For client side configuratoin I'm going to avoid wg-quick because I want to control routing part. It also starts with adding config file, /etc/wireguard/wg0c.conf:

[Interface]
ListenPort = 47824
PrivateKey = yPcUBdVfvZJp1NK5NXsNjldagv3nAzD7i5nZUng4Fns=

[Peer]
PublicKey = uCVsuTV3gW8FV2U8Bv5mNV4PJEXh15Thzj/AN6UTWiI=
AllowedIPs = 0.0.0.0/0
Endpoint = 1.2.3.4:5544
PersistentKeepalive = 10

Here, since we don't use wg-quick and will feed the config file to wg directly, we can't declare extra entries that are only used by wg-quick such as Address, PostUp or PostDown. We'll do it manually later.

I'm going to allow all IPs going through the tunnel here. If it's a typical VPN, we usually want to route everything through it.

The only new thing here is Endpoint entry and PersistentKeepalive. Endpoint should be the public address of the server endpoint (remember the server endpoint IP/net is actually private; and we listen on all IPs, not just that one). So whatever other IP on that host. Of course you need to get the listen port number right.

PersistentKeepalive is needed if you're behind NAT, to keep the connection alive. In LAN, you probably can live without it. And yeah no need to do anything extra for NAT traversal.

So, let's create wg0c network interface

# ip link add wg0c type wireguard

then configure it with the file we just created

# wg setconf wg0c /etc/wireguard/wg0c.conf 

if you add extra stuff, you'll be rejected here. Then configure the network interface properly. This is pretty much standard procedures:

# ip -4 address add 192.168.2.1/24 dev wg0c
# ip link set mtu 1420 up dev wg0c
# ip -4 route add 192.168.3.0/24 dev wg0c

And if you do everything right, wg show will show this

# wg show
interface: wg0c
  public key: 6Ye93aP1/xDVCtNieYTwXZcnrxq6vc0IkaPVopBNxlI=
  private key: (hidden)
  listening port: 47824

peer: uCVsuTV3gW8FV2U8Bv5mNV4PJEXh15Thzj/AN6UTWiI=
  endpoint: 209.141.62.235:5544
  allowed ips: 0.0.0.0/0
  latest handshake: 1 minute, 52 seconds ago
  transfer: 5.49 KiB received, 8.14 KiB sent
  persistent keepalive: every 10 seconds

You can see that handshaking was fine, there's data transferring... You can try to ping and stuff... Doing wg show on the server side should show something similar too.

And that's it. For a real VPN you may want to route more traffic through wg0c which will come out at wg0s and be masqueraded/NAT'd. I think I'm starting to like it.

Cập nhật 1 lần. Lần cuối: Sat Apr 04 06:14:08+0011 2020