GNU/Linux


Ubuntu – Overwrite dockerd default settings

Trying to create a new bridge on docker, we got the following error

$ docker-compose up -d;
Creating network "docker-compose_new_bridge" with driver "bridge"
ERROR: could not find an available, non-overlapping IPv4 address pool among the defaults to assign to the network

After investigating, we realized that it was due to some default limitations of docker that did not allow more virtual networks to be created. To overcome the problem, we read that we had to give access to more address space using the /etc/docker/daemon.json.

On Ubuntu that file did not exist so we created it and copied the following content to it:

{
  "default-address-pools": [
    {
      "base": "172.80.0.0/16",
      "size": 24
    },
    {
      "base": "172.90.0.0/16",
      "size": 24
    }
  ]
}

Source: https://docs.docker.com/engine/reference/commandline/dockerd/

This configuration allowed Docker to reserve the network address space 172.80.[0-255].0/24 and 172.90.[0-255].0/24, that provided the daemon a total of 512 networks each owning 256 addresses.

To apply the changes to the daemon, we restarted it:

sudo systemctl restart docker.service;

and then we applied our changes to our docker ecosystem:

docker-compose up -d;

Ubuntu how clear journal logs and free up some disk space

On a machine that has Ubuntu 20.04LTS was recently running out of space, while using the Disk Usage Analysis tool we noticed that /var/log/journal was taking a bit more than 4 GB.

We knew that the machine was not hosting any kind of public service nor did it have any hardware problems, so we decided to clear up old logs. To do so, we used the following command that removed all logs that were older than two days.

sudo journalctl --vacuum-time=2d;

The result was great as it saved 3.9 GB of space:

Vacuuming done, freed 3.9G of archived journals from /var/log/journal/ee4a566eacf347dbb47e03b3f33821a1.

More information on journalctl can be found here. You can find more options on removing old logs, for example limiting the total size of logs that you want to keep, using this variation which will keep only 50 MB of data:

sudo journalctl --vacuum-size=50M;

Netflix error f7701-1003 on Ubuntu 1

Recently we got the error F7701-1003 on Netflix after an update on the operating system was performed. To repair it we installed the package libavcodec-extra using the following command:

sudo apt install libavcodec-extra;

After the installation was complete, we just restarted the browser and Netflix was operating again as expected.

Below is the basic information about the package that was installed:

Package: libavcodec-extra
Version: 7:4.2.4-1ubuntu0.1
Priority: extra
Section: universe/libs
Source: ffmpeg
Origin: Ubuntu
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer: Debian Multimedia Maintainers <[email protected]>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 65,5 kB
Depends: libavcodec-extra58 (= 7:4.2.4-1ubuntu0.1)
Homepage: https://ffmpeg.org/
Download-Size: 14,8 kB
APT-Manual-Installed: yes
APT-Sources: http://cy.archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages
Description: FFmpeg library with extra codecs (metapackage)
 FFmpeg is the leading multimedia framework, able to decode, encode, transcode,
 mux, demux, stream, filter and play pretty much anything that humans and
 machines have created. It supports the most obscure ancient formats up to the
 cutting edge.
 .
 This metapackage depends on the latest version of the libavcodec variant
 that offers additional codec support. Application packages can depend
 on it if they require or suggest this variant in a robust manner.

Package: libavcodec-extra
Version: 7:4.2.2-1ubuntu1
Priority: extra
Section: universe/libs
Source: ffmpeg
Origin: Ubuntu
Maintainer: Ubuntu Developers <[email protected]>
Original-Maintainer: Debian Multimedia Maintainers <[email protected]>
Bugs: https://bugs.launchpad.net/ubuntu/+filebug
Installed-Size: 65,5 kB
Depends: libavcodec-extra58 (= 7:4.2.2-1ubuntu1)
Homepage: https://ffmpeg.org/
Download-Size: 14,8 kB
APT-Sources: http://cy.archive.ubuntu.com/ubuntu focal/universe amd64 Packages
Description: FFmpeg library with extra codecs (metapackage)
 FFmpeg is the leading multimedia framework, able to decode, encode, transcode,
 mux, demux, stream, filter and play pretty much anything that humans and
 machines have created. It supports the most obscure ancient formats up to the
 cutting edge.
 .
 This metapackage depends on the latest version of the libavcodec variant
 that offers additional codec support. Application packages can depend
 on it if they require or suggest this variant in a robust manner.

Monkey Problems 2

Recently, we tried to user monkeyrunner on an Ubuntu 18.04 LTS. We installed Android Studio through snap and we setup the Android SDK in ~/Andoid. monkeyrunner was installed in ~/Android/Sdk/tools/bin. To our immeasurable disappointment we found out that when we tried to execute monkeyrunner, it would give the following error:

$ ./monkeyrunner
-Djava.ext.dirs=/home/tux/Android/Sdk/tools/lib:/home/tux/Android/Sdk/tools/lib/x86_64 is not supported. Use -classpath instead.
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.

At first, we had no idea what that meant, so we used file command on monkeyrunner and we found out that monkeyrunner is a bash script.

$ file monkeyrunner
monkeyrunner: POSIX shell script, ASCII text executable

After reading the code, we read the following at the last lines:

#need to use "java.ext.dirs" because "-jar" causes classpath to be ignored
#might need more memory, e.g. -Xmx128M
exec java -Xmx128M $os_opts $java_debug -Djava.ext.dirs="$frameworkdir:$swtpath" -Djava.library.path="$libdir" -Dcom.android.monkeyrunner.bindir="$progdir" -jar "$jarpath" "$@"

First thing we did was to find the java version that was used, since the command that was giving the problem was that. We found out that we had version 11.

$ java -version
openjdk version "11.0.6" 2020-01-14
OpenJDK Runtime Environment (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1)
OpenJDK 64-Bit Server VM (build 11.0.6+10-post-Ubuntu-1ubuntu118.04.1, mixed mode, sharing)

After reading a bit, we found out that after Java version 8 the command line directive -Djava.ext.dirs it was deprecated and the recommendation to use -classpath was added. In the past, java.ext.dirs was used to instruct the JRE from where to load additional class and jar files. Since we had Java version 11 we had to try the recommendation to remove the -Djava.ext.dirs directive and use -classpath instead. So, we edited the file monkeyrunner and changed the last line as follows:

exec java -Xmx128M $os_opts $java_debug -classpath "$frameworkdir/*:$swtpath" -Djava.library.path="$libdir" -Dcom.android.monkeyrunner.bindir="$progdir" -jar "$jarpath" "$@"

We tried executing the newly updated monkeyrunner again, only to hit another wall!

$ ./monkeyrunner
Exception in thread "main" java.lang.NoClassDefFoundError: com/android/chimpchat/ChimpChat
at com.android.monkeyrunner.MonkeyRunnerStarter.(MonkeyRunnerStarter.java:60)
at com.android.monkeyrunner.MonkeyRunnerStarter.main(MonkeyRunnerStarter.java:188)
Caused by: java.lang.ClassNotFoundException: com.android.chimpchat.ChimpChat
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:581)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
… 2 more

It turns out that when you use the -jar directive, JRE will ignore the -classpath directive and so it will again not be able to load any external class or jar files…

Solution

Instead of reinventing the wheel (We tried, we failed, it was painful. Still worth the shot!) we decided to install Java version 8 on Ubuntu 18.04 LTS side by side with Java version 11 and just used that.

First, we checked the list of installed jvm on our machine using the following command:

update-java-alternatives --list;

Where we got the following:

$ update-java-alternatives --list
java-1.11.0-openjdk-amd64 1111 /usr/lib/jvm/java-1.11.0-openjdk-amd64
java-1.8.0-openjdk-amd64 1081 /usr/lib/jvm/java-1.8.0-openjdk-amd64

It turned out we already had Java version 8 but if we didn’t we would install it as follows:

sudo apt install openjdk-8-jdk;

and then it would again appear in the list mentioned above.

Then, we switched to the Java version 8 using the following command and selecting the appropriate option:

sudo update-alternatives --config java;

$ sudo update-alternatives --config java
[sudo] password for tux:
There are 2 choices for the alternative java (providing /usr/bin/java).
Selection Path Priority Status
0 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 auto mode
1 /usr/lib/jvm/java-11-openjdk-amd64/bin/java 1111 manual mode
2 /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java 1081 manual mode
Press to keep the current choice[*], or type selection number: 2
update-alternatives: using /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java to provide /usr/bin/java (java) in manual mode

After switching Java to Version 8 monkeyrunner was working as expected!!