Docker image includes unneeded Ubuntu "restricted" (non-free) repo

Dev
1

Hello Discourse team,

I did a quick peek at /etc/apt/sources.list and found this list:

deb http://archive.ubuntu.com/ubuntu xenial main restricted universe
deb http://archive.ubuntu.com/ubuntu xenial-updates main restricted universe
deb http://archive.ubuntu.com/ubuntu xenial-security main restricted universe

The restricted repo contains non-free software.

I installed the vrms tool and after running it, it tells me that there are no proprietary packages in the docker image. The non-free restricted repo is primarily for those who want to install non-free drivers, so there should be no practical use of this repo by Discourse.

According to https://meta.discourse.org/t/does-the-discourse-team-distribute-proprietary-versions-of-discourse/87864/2, Discourse doesn’t distribute non-free software.

Could you please edit your sources.list file so that it does not open the door to accidentally installing packages from the restricted repository? I would really appreciate that. :slight_smile:

Thanks,
Andrew

2

I believe this come from our upstream docker image, at this line

https://github.com/discourse/discourse_docker/blob/master/image/base/Dockerfile#L3

That line points to the official Ubuntu image from the Docker library which has this line:

https://github.com/tianon/docker-brew-ubuntu-core/blob/dist-amd64/xenial/Dockerfile#L2

where it adds this archive that contains the restricted lines you found.

I don’t know if there is an official Ubuntu docker image with those disabled.

4 Likes
3

Thanks for the links @Flaco. Does this line and those that follow override those settings?

https://github.com/discourse/discourse_docker/blob/master/image/base/Dockerfile#L15

1 Like
4

Oops, I totally missed that :blush:.

Yeah, so we are overwriting the Ubuntu defaults there.

Maybe try to build the image without the restricted bits and run the tests to see if everything pass?

3 Likes
5

Hello Rafael,

Thanks for your reply. I edited that file so only “main” repos would be included, but “universe” and “restricted” came back in anyhow. I’ll do some more testing to see if I can get it to work.

Thanks,
Andrew

1 Like
6

Hello Rafael,

I managed to build the image with main and universe only. universe is required because discourse installs at least one package from there: fping.

How do I run automated tests for the system?

Thanks,
Andrew

7

For tests we build another image using the one you just built as a base.

Running ruby auto_build.rb discourse_test will build it.

8

Hello Rfael,

Thanks for those instructions. discourse_test wasn’t an option, so I went with discourse_test_build instead of discourse_test_public.

I don’t see instructions for running automated tests in the README file, so I experimented a bit. I saw these lines in the output of docker images:

REPOSITORY                 TAG                 IMAGE ID            CREATED             SIZE
discourse/discourse_test   build               683b0277af9f        About an hour ago   3.7GB
local_discourse/app        latest              49278c40bf4c        19 hours ago        2.6GB
...

So I changed this line in ./launcher

#local_discourse=local_discourse
local_discourse=discourse

I copied containers/app.yml to containers/discourse_test.yml and ran

./launcher start discourse_test

But I got this error:

...
Unable to find image 'discourse/discourse_test:latest' locally
/usr/bin/docker: Error response from daemon: manifest for discourse/discourse_test:latest not found.
See '/usr/bin/docker run --help'.

I couldn’t find the text tag or latest in the ./launcher file or the docker run man page, so I’m still not sure how to specify build rather than latest in ./launcher. I checked image/auto_build.rb and it looks like the other option is to build discourse_test_public, but that is tagged as release, not latest, so it’s not clear how to spin up one of the test images and to run the automated tests. Do you know how to do this?

Thanks,
Andrew

9

After building the image locally you can run tests with:

docker run --rm  discourse/discourse_test:build
10

I ran the tests and got the following error. Was the random seed generation too slow, causing the test suite to time out and abort? There were other randomly generated seeds before this. This vm only has two virtual CPUs, but I can increase that number.

...
Finished in 6 minutes 10 seconds (files took 21.73 seconds to load)
260 examples, 0 failures

Randomized with seed 36421

yarn install v1.9.4
[1/4] Resolving packages...
success Already up-to-date.
Done in 0.50s.
Puma starting in single mode...
* Version 3.11.4 (ruby 2.5.1-p57), codename: Love Song
* Min threads: 0, max threads: 16
* Environment: development
* Listening on tcp://0.0.0.0:60099
Use Ctrl-C to stop
node /var/www/discourse/vendor/assets/javascripts/run-qunit.js http://localhost:60099/qunit?seed=137594233159754697689085641368770876532 600000
Warming up Rails server
Rails server is warmed up
navigate to http://localhost:60099/qunit?seed=137594233159754697689085641368770876532
DEBUG: -------------------------------
DEBUG: Ember  : 2.13.3
DEBUG: jQuery : 3.3.1
DEBUG: -------------------------------

Running: {"seed":"137594233159754697689085641368770876532"}

.............................................F........................................................................................................................................
...........................................................................................................................................................F..........................
.....................................................................F................................................................................................................
........................................................Tests timed out
rake aborted!
Command failed with status (124): [node /var/www/discourse/vendor/assets/java...]
/var/www/discourse/lib/tasks/qunit.rake:89:in `block in <main>'
/var/www/discourse/bundle/ruby/2.5.0/gems/rake-12.3.1/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => qunit:test
(See full trace by running task with --trace)
115:signal-handler (1534527556) Received SIGTERM scheduling shutdown...
2018-08-17 17:39:16.546 UTC [134] LOG:  received smart shutdown request
2018-08-17 17:39:16.594 UTC [134] LOG:  worker process: logical replication launcher (PID 143) exited with exit code 1
2018-08-17 17:39:16.602 UTC [138] LOG:  shutting down
115:M 17 Aug 17:39:16.611 # User requested shutdown...
115:M 17 Aug 17:39:16.612 # Redis is now ready to exit, bye bye...
2018-08-17 17:39:17.114 UTC [134] LOG:  database system is shut down
Terminating
11

I created a pull request here: https://github.com/discourse/discourse_docker/pull/405