WAG 2.0.0 base installation with glibc

[paulb-smartit]

I'm trying to create a 2.0.0 installation using Alpine or Debian, and I am struggling with the prerequisites. In particular glibc-2.34+.

Can I ask what base OS you were using to instal WAG?

[NHAS]

I do all my development on archlinux, so my glibc version is pretty new.

Are you using the binary release or building from source?

Also could you give me the alpine and debian versions you're attempting to do this on?

(I have had installation success on Ubuntu 22.04 as well)

[paulb-smartit]

Alpine 3.17 and Debian 11

Personally love Arch, run Manjaro desktop, but for servers it's a bit too bleeding edge for us.

Also, using binary 2.0.0. Wonder if a build may be better as I do tend to build the v1 branch.

[NHAS]

Yep. Fully understand, really I should be doing binary releases from an older version of glibc so that folk don't have to be bleeding edge to use it.

Just didn't think of it.

Tomorrow I'll rebuild to target debian 11 and make a docker release builder.

If there was an older distribution that you'd like me to target (that still has an appropriate kernel version) feel free to give me a heads up.

P. S

Honestly not sure how youre running it on alpine give its lack of glibc...

[paulb-smartit]

There is a glibc-2.35 that can be installed - https://github.com/sgerrand/alpine-pkg-glibc/releases

Was glibc required on v1?

[NHAS]

Yep v1 had glibc/cgo enabled, is indeed required unfortunately.

In thinking about this, as the ebpf library I use is pure go, I may actually be able to remove that requirement if I can find a pure go way of getting kernel time (monotonic clock).

We shall see

[paulb-smartit]

Good news, Alpine 3.17

wireguard:/opt/wag# ./wag start
2022/12/22 10:54:00 Started firewall management: 
            Setting filter FORWARD policy to DROP
            Allowed input on tunnel port
            Set MASQUERADE
            XDP eBPF program managing firewall
            Set public forwards
2022/12/22 10:54:00 Started control socket: 
             /tmp/wag.sock
2022/12/22 10:54:00 Started listening:
            Tunnel Listener:  192.168.x.x:80 
            Public Listener:  :8080
2022/12/22 10:54:00 Wag started successfully, Ctrl + C to stop

After building it.

[NHAS]

Awesome! Really not sure why alpine + glibc 2.35 wouldn't have been able to run the binary release.

Obviously I got an update on my build machine I just wasn't aware of.

[paulb-smartit]

I may write up a setup guide once I get it sorted.

Looks like the key part to get go running is:

ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2

then build wag from source.

[NHAS]

Welp, that's definitely not the experience I want folk to have.

Hopefully. I can remedy this by removing the requirement for glibc entirely, or building from an older version so at least debian will run

[paulb-smartit]

Debian has its own challenges. The native go version is only v1.15 so you must install that manually, then the libc version becomes an issue.

One thing Debian may resolve for me would be systemd and running wag as a service. I can't seem to get it going as an init.d script in Alpine (no systemd).

[NHAS]

I'm just thinking building on debian for the binary release. As then people can just download it and go.

I'd ask what issues you're having with the Init script, but that might be a whole 'nother issue

[paulb-smartit]

Alpine 3.17

Install go

apk add --no-cache --virtual .build-deps gcc musl-dev openssl curl git make llvm15 clang iptables
curl -LO https://golang.org/dl/go1.18.9.linux-amd64.tar.gz
tar xvzf go1.18.9.linux-amd64.tar.gz -C /usr/local/
echo "export PATH=/usr/local/go/bin:${PATH}" | tee /etc/profile.d/go.sh
source /etc/profile.d/go.sh

Link for ld-linux-x86-64.so.2

ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2

go version
go version go1.18.9 linux/amd64

Then clone and make wag.

I'll revisit the init.d script and create a separate issue.

[paulb-smartit]

With one "from scratch" issue.

I used ./wag gen-config and the first startup produced:

./wag start
panic: assignment to entry in nil map

goroutine 1 [running]:
github.com/NHAS/wag/config.load({_, _})
    /root/wag/config/config.go:199 +0xb6b
github.com/NHAS/wag/config.Load({0x9da6eb, 0xd})
    /root/wag/config/config.go:259 +0xe8
github.com/NHAS/wag/commands.(*start).Check(0xc000020300)
    /root/wag/commands/start.go:61 +0x7a
main.root({0xc000020050?, 0xf?, 0x0?})
    /root/wag/main.go:73 +0x28e
main.main()
    /root/wag/main.go:98 +0x7b

When I copied over and modified my existing config.json and devices.db it's all good.

[NHAS]

config.go:199

Yeah sweet this happens when the ACLs structure is empty, which I never thought would happen. It shouldnt crash tho, I'll make a v2.0.1 to address the things you've brought up

[NHAS]

These changes have been incorporated now. Its worth noting that to do this I've had to move over to using a purely golang implementation of sqlite3, which may mean that database operations are 2x slower than their C counterpart.

I dont expect this to be a major issue as wag isnt a db heavy application (although it does keep updating the db based on where the client endpoint is).

If you notice issues please inform me, the new release is v2.0.1

[NHAS]

I've found some issues myself in testing, apparently the native golang sqlite driver is so slow I keep getting database lockups for some reason. So I'll just have to build with older glibc version as my solution.

[NHAS]

(i.e v2.0.1 is broken)

[NHAS]

This should now be resolved in v2.0.2, as building has been moved to debian 11 and thus an older (and static) version of glibc (2.31)