[Dev] DDNS + parabola.nu sub-domain for our build server

Luke g4jc at openmailbox.org
Sun Mar 26 00:53:26 GMT 2017

On 03/25/2017 06:32 PM, Isaac David wrote:
> Le ven. 24 mars 2017 à 23:29, André Silva:
>> Hey guys, Luke .R let me know that DDNS + sub-domain is not needed for
>> our build server, since we can configure it to upload directly to
>> winston. Using DDNS on a build server may expose my local area network,
>> which isn't good for security.
> what about starting the builds themselves? will it also read the TODO
> list from another server?
> do we want more than ssh on that server? one option would be asking
> that machine to open a reverse ssh tunnel to winston or proton (I will
> use proton in this example):
>    ssh -f -N -T -R $BURNER_PROTON_PORT:localhost:$PORT_IN_BUILD_SERVER \
>        $BUILD_USER at proton
> $BUILD_USER and its corresponding $KEYFILE_TO_PROTON would have to be
> set up in advance. then any user at proton with the ability to `ssh -p
> $BURNER_PROTON_PORT localhost` would begin to negotiate a connection
> to the build server; which, at your option, could use hackers.git and
> the bulk of the login infraestructure being used in winston to spare
> the need for more credentials. more generally and conveniently, one
> would:
>        $SOME_USER_ON_BUILD_SERVER at proton
> to jump straight to the build server from anywhere, via proton behind
> the scenes.
> of course any form of ssh access to the build server would give a
> select few a free pass to its LAN. you could try to isolate the server
> to a second LAN daisy-chained to the main one. it only takes an extra
> router.

Reverse SSH is a neat idea. Most professional build servers end up using
Jenkins or similar though.

We would want to limit who can just randomly login to the build server.
Ultimately, I'd like to see some script which allows the user to
upload/queue a build and then the server just does it and uploads to
proton. Either way I don't like the idea of a build-server publicly
facing the internet or running any web services unless it's absolutely
necessary. This box needs to be kept tight for security and quality of
our binaries. Running it on a VLAN / NAT might be an option as well.

Related to automation, there is an interesting ongoing discussion here:

More information about the Dev mailing list