This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.
Harald Welte laforge at osmocom.orgHi Andrew,
On Sat, Apr 25, 2020 at 11:28:52AM +0100, Andrew Back wrote:
> Appreciate that the Osmocom Docker configurations exist principally for
> automated testing and here it may not make sense, but I wondered if
> builds are published to a registry?
no, they are intentionally not. As long as the container community does
not provide proper tools helping to generate license compliant binary
builds, I don't think we want to (or anyone should!) publicly release
binary container images/layers.
Docker and other related entities have been ignoring this for years,
despite lots of voices raising this topic. See for example
https://lwn.net/Articles/752982/
How, for example, would you comply with copyleft style licenses such as
LGPL/GPL/AGPL to automatize the process of providing the "complete
corresponding source code" to all the binaries that go into a Docker
image? Particularly if you are using upstream images that other people
have built who don't provide you with this information?
You would basically have to recursively collect all the debian source
packages of both your layer, as well as all the layers you inherited
from. I'm not aware of any tooling that one could use to automatize
that process.
> The Makefile in the make project located in the docker-playground repo
> sets docker.io as registry and has a target for docker push. Also see
> OBS Release.key files in project sub-directories, but couldn't find
> container builds being published anywhere.
In my opinion, the only way to safely distribute container images is to
not distribute them, but only distribute the Dockerfile and have users
build the images from there.
So we do have our own internal docker registry that is used within the
Osmocom CI and testing, exactly to prevent any potentially license
incompliant public distribution.
> Also saw the comments from 2017 on Docker shortcomings and assuming SCTP
> works OK now in Docker networking?
I don't know what is the status. In general, I consider the standard
way how docker deals with networking completely broken. The incredible
ignorance of assuming the internet only has TCP and UDP is a 1980ies
assumption. Doing NAT everywhere and programmatically inserting
iptables rules from the docker daemon is also not quite elegant.
For any kind of Docker use for cellular network infrastructure the only
option is to use docker networks (i.e. virtual ethernet segments) and
have static per-container IP addresses. So you don't ever use any of
the EXPOSE / NAT / ... stuff.
Beware that Docker also doesn't fully support this scenario for any
reasonable production deployment, as you cannot have a container being
part of multiple docker networks while having reliable network device
names. Allegedly the eth0..N are now assigned in "alphabetically
increasing order of the docker-network name", which is also way too
fragile for my point of view.
So in the end, my observation still remains: One cannot use Docker in
cellular network infrastructure, at least not in 2G, 3G or 4G, where
everything relies on static IP addreses and SCTP.
It's enough for test autmation, but certainly not for production use.
Regards,
Harald
--
- Harald Welte <laforge at osmocom.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)