Building Erlang Projects Offline

[Joseph Lloyd]

I need a way of building Erlang apps and releases on an internal corporate network that is intentionally isolated from the internet.  I have tried installing rebar3 without success so far.   Has anyone done this?  Are there better ways of achieving offline builds of erlang apps/releases?

Thanks,

Joseph

[Michael Truog]

Hi Joseph,

One approach is to use rebar2 for the build and reltool (included with
Erlang/OTP) for the release.  That approach is used in the
https://github.com/CloudI/CloudI repository if you need an example.

Best Regards,
Michael

[A. G. Madi]

Hey Joseph,

I'm in the same position but I use rebar3.  What I do is to download all dependencies and move them to the internal network. I place them in the _checkouts directory in my release's directory. That way rebar3 will find everything it needs is already present and doesn't try to connect anywhere.  

[Tristan Sloughter]

There was an issue installing rebar3 or building a project with it? You can download the pre-built escript https://s3.amazonaws.com/rebar3/rebar3 -- the only time you should need to go outside the internal network.

The only time rebar3 should be hitting the network is if you have dependencies for it to fetch.

Is it hitting the network when it shouldn't or is it a case like you want it to use a local copy of dependencies?

Tristan

[Oliver Korpilla]

In my project we're isolated from the internet when building, something which the elixir package manager doesn't like very much, which mix defaults to using.

We ended up downloading a version of hex into a folder and also a binary version of rebar3 for building our Erlang dependencies, the configured or build system to use those.

Mix can build a full deployable release including an ERTS if needed, both from elixir and Erlang sources. So I know it can definitely be done. The only somewhat annoying thing is that the setup always starts rebar3 for compiling dependencies even if nothing is to be done. But after being started rebar3 at least recognizes nothing needs rebuilding.

If such a setup is interesting for you I could provide you with some details. It requires installing elixir for the build tooling but you can still do all your coding in Erlang as you wish.

Oliver

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Joseph Lloyd]

Clearly, I am messing up somewhere.  This is our first project, and right now it is super simple: no dependencies.   I've tried downloading a pre-built rebar3, however, when I run it on an internal node, I get the following error:

escript: exception error: undefined function rebar3:main/1
  in function  escript:run/2 (escript.erl, line 758)
  in call from escript:start/1 (escript.erl, line 277)
  in call from init:start_em/1
  in call from init:do_boot/3

Are there dependencies that are needed outside of my own project that rebar3 needs?  If so, how do I locate them to copy them into a _checkouts directory?

Thanks,

Joseph

[Tristan Sloughter]

What version of Erlang are you using?

Based on that error my guess is your Erlang version is too old for the latest pre-built binary and will either have to build from source or download the escript of an old version https://github.com/erlang/rebar3/releases

[Joseph Lloyd]

Yep, that was my problem.  I was running OTP 21, when I downgraded rebar3 it worked.  Rookie error. Thank you for your help.

[Viktor Söderqvist]

On 2022-02-03 21:35, Tristan Sloughter wrote:
> There was an issue installing rebar3 or building a project with it? You
> can download the pre-built escript
> https://s3.amazonaws.com/rebar3/rebar3
> <https://s3.amazonaws.com/rebar3/rebar3> -- the only time you should
> need to go outside the internal network.

In certain corporations, downloading a binary in this way and using it
to build a business-critical system is out of the question. It's opening
up the system to Supply Chain Attacks, a topic that has received lots of
attention lately, for example in the US president Biden's executive
order 14028, Improving the nation's cybersecurity[1] and related NIST
publications[2].

What if s3.amazonaws.com is compromised in a way so that is it serves a
special version of rebar3 only to your build server and the normal
version to everybody else? Or what if your DNS server is compromised so
that you get a fake s3.amazonaws.com?

It turns out that there is no documented way to build rebar3 from source
code in an offline build environment. The _checkouts trick doesn't work
for bootstrapping. It is possible (although undocumented, so we can call
it a hack) to bootstrap rebar3 by first placing all the dependencies and
their dependencies under _build/default/lib/ prior to running the
bootstrap script.

Regarding using rebar3 for building software, it is true that it doesn't
download anything if all deps are available under _checkouts. Another
way to achieve this is to place your app and all the deps under lib/ in
the project directory. If any dependency is missing though, rebar3 will
attempt to download it. There is no way to stop this other than blocking
Internet access in the build environment.

Why would you want to do that anyway? And why does anyone want a build
environment to be offline? Well, automatically downloading and running
any code that you haven't proof-read and approved in advance can be
regarded a security issue.

Cheers,
Viktor

[1]:
https://www.federalregister.gov/documents/2021/05/17/2021-10460/improving-the-nations-cybersecurity#p-54
[2]:
https://www.nist.gov/itl/executive-order-improving-nations-cybersecurity/software-supply-chain-security

[Mikael Pettersson]

On Sun, Feb 20, 2022 at 11:11 PM Viktor Söderqvist
<vik...@zuiderkwast.se> wrote:
> Why would you want to do that anyway? And why does anyone want a build
> environment to be offline? Well, automatically downloading and running
> any code that you haven't proof-read and approved in advance can be
> regarded a security issue.

+1

We maintain our own internal mirrors of whatever 3rd party software we
might depend on, and build machines are only able to access those, not
the Internet. Yes it does require tweaks to rebar.config but the
alternative of just pulling stuff off the Internet is simply not an
option. (All our environments are network-isolated, not just build
nodes.)

[Oliver Korpilla]

For our mixed Erlang/elixir environment we also have an offline
requirement. Because our continuous integration should not simply stall
because some server anywhere in the world we have no influence on dies.

Initially we mirrored the project releases we were using on internal
servers but that was shelved.

Right now we use fixed revisions of all our dependencies, including the
aforementioned binary rebar3 off of AWS to build our Erlang
dependencies, and we configure mix accordingly to use all dependencies
from local.

We're also supplying a fixed version of elixir's package manager hex by
supplying a pre-made home directory for build purposes.

Frankly, this whole "package management by default" is a real hassle if
you want to go offline. The hoops I had to jump through so that nothing
gets downloaded from the internet were more effort than we ever anticipated.

Oliver

--
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

[Fred Hebert]

On 02/21, Oliver Korpilla wrote:
>
>Frankly, this whole "package management by default" is a real hassle if
>you want to go offline. The hoops I had to jump through so that nothing
>gets downloaded from the internet were more effort than we ever anticipated.
>
>Oliver
>

While I understand the general frustration, the general expectation at
the time of design (now 6+ years ago) was that people would generally do
what was popular at the time: set up their own private mirrors for all
dependencies, whether git-based on hex-based. That sort of stuff should
be supported right now.

The vast majority of most recent developments have shifted outside of
that design into one of flat source vendoring, or some variation thereof.

The challenge we've had since then is in trying to corral all the sorts
of requirements various people have, and it's an unwieldy mess:

- Some people do want the mirroring (though they're smaller now than
before)
- Some people want a monorepo where they maintain patch sets and
continuously update the libraries as non-public variations
- Some people want a regular project but with an offline mode where
dependencies are not expected to change
- Some people want to also version Erlang versions themselves and be
able to configure these paths
- Some people will want all the files to be turned into system-wide,
versioned libraries that can be used across projects in unison
- Some people require interoperability with other cross-language build
tools
- Some people will want a mix of these various options, but all of them
do need to be offline.

And here by 'people', I tend to mean 'pwople working at corporations who
also happen not to really be able to share the code of their projects.'
The general end result of this is that many of the proposals we get for
a change or a patch set does the bare minimum people need for their use
case, and often in ways that wouldn't work great with existing design or
other use cases. Absorbing maintainership for that hasn't felt very
interesting.

The last bit is the unsurprising necessary disclaimer: Rebar3 is
maintained by two people who do it in their free time. I personally do
not even work with Erlang as a software engineer anymore and have moved
on to the role of SRE (for unrelated reasons -- now Erlang is a hobby I
enjoy again). Tristan does have his own schedule as well.

This is the sort of project that is frankly unlikely to see major
progress when done as a hobby, because it's specifically a
corporate-driven sort of feature that most users at home never
encounter, at least until the bill-of-materials US legislation somehow
extends to side project done in your free time.

For me personally (I can't talk for Tristan here), I'm unlikely to start
doing multi-organization corporate-style project development in my free
time, unpaid, just for the sake of it. I have hobbies that interest me
more. I am however willing to guide or help design bits of it, because
I do understand that the sort of domain-specific knowledge around
everyone's builds has been concentrated in a few of us over the last few
years.

Regards,
Fred.

[Tristan Sloughter]

I had a draft started with these points from Fred before seeing this :)

I'll add that there have been ongoing discussions about offline bootstrapping and general offline/vendoring support in the build and packaging WG, https://erlef.org/wg/build-and-packaging

Those interested should join us there and help move a solution forward.

Ericsson had or has someone working on at least the bootstrap issue but I don't know where that is at the moment.

Part of my day job is still Erlang, but only open source stuff, so no need for this functionality -- at least not by any current customer base that is using the open source libraries and our service.

Tristan