Synology and UPnP and UBNT

Uncategorized No Comments »

Synology is a fairly good NAS product, but they occasionally seem to drop a ball (*cough* *cough* python3 update, ever? *cough*). UPnP is tonight’s frustration, but A comment by user scyto on UBNT’s community support from May 2016 is what helped.

Plagiarizing Scyto’s response (in case it gets “updated” to the new and “improved” forum) is:

It seems synology built natpmp int0 their units but never turned it on – here is how.

  1. ensure you already cofigure your synoogy with the router wizard in non password mode
  2. enable SSH access to the synology
  3. login with an SSH client
  4. sudo vi /etc/portforward/router.conf to edit the file 
  5. change the following lines in the file:
    1. support_change_port=yes
    2. support_router_upnp=yes
    3. support_router_natpmp=yes
    4. router_type=natpmp
  6. leave all other lines as-in

What scyto doesn’t mention is that after saving /etc/portforward/router.conf there’s no need to sigHUP anything or force a reload — just works the next time you hit [SAVE] on the “External Access” config screen.

Docker Jenkins golang tool “Not Found”?

Uncategorized No Comments »

There I was, setting up a Dockerized Jenkins (well, BlueOcean) to auto populate a golang tool for Jenkins to properly build the converted-to-golang “ouizone” code (more on that later). It was gonna be awesome and unblock remote upgrade of a physical server.

go: No such file or directory

Wait, what? It’s a static-linked binary (which means mostly static: still needs Libc) and it’s not interpreted, so there’s no missing interpreter. Happens regardless the version of go that I tried (notable mention: thanks Google for changing the path: $TOOL/bin/go -> $TOOL/go/bin/go)

Checking, the key part is that it’s mostly static: libc is still needed. The docker container from jenkinsci is a musl -based system, and the go toolchain is a libc. Musl is not multilib, but is indeed small, and in the ldd output of the go binary, go depends on /lib64/ld-linux-x86-64.so.2 rather than (container) /lib/ld-musl-x86_64.so.1

So… how to fix this? Following the suggestion in Trion’s jenkins-docker-client:

sudo docker exec -u root -it blueocean bash
bash-4.4# ln -s /lib /lib64 
bash-4.4# ln -s /lib/ld-musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2

Codifying that by burning it into a DockerFile that extends jenkinsci/blueocean should make it permanent. …another day. Today, it works, and I got a bit of work to do.

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in