cloudogu / ces-commons Goto Github PK

https://github.com/cloudogu/makefiles

When calling getIp() in an environment that does not have a network adapter that has a 192.168.x.x IP address, the IP address of the first network adapter (eth0) is returned.

In case of the ecoystem eth0 is the NAT adapter that cannot be reached from outside of the VM. It usually has the address 10.0.2.15.

Please make the logic more robust so it also returns the externally accessible IP address (private or public network instead of the NAT adapter) even when this IP address does not start in 192.168..

The behaviour can be reproduced by starting an ecosystem with a private network and an IP address of for example 192.170.2.42.
When calling vagrant up, it will output a setup link for http://10.0.2.15:8080, whereas it can only be reached at http://192.170.2.42:8080.

A workaround would be to query the external IP address via vagrant ssh -c "ifconfig eth1" and to perform a setup. However, when shutting down the ecosystem and starting it again with a different IP (which is not unlikely for public/bridged networks), the ecosystem will no longer be accessible from outside the VM.

You can reproduce this like so:

• Start the ecosystem VM, for example as shown above with an IP of 192.170.2.42.
• Perform a minimal CES setup
• When everything is done, shut down the VM, e.g. with vagrant halt.
• Change the IP address in the Vagrantfile, e.g. 182.180.3.23.
• Start the VM again, vagrant up
• Access the ecosystem in browser via https://182.180.3.23.

Right now, the last step does not return an answer. Desired behaviour is that we can reach the ecosystem at the new address.

For the coming new version of SonarQube (7.9) it is required to configure vm.max_map_count to 262144. It would be nice to do this directly with ces-commons.

When upgrading ces-commons versions lower than 0.1.4, the postinst-script is failing because systemd wants to set an already installed symlink when enabling ipchangecheck unit.

Failed to execute operation: File exists
dpkg: error processing package ces-commons (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
ces-commons

Preparing to unpack .../ces-commons_0.1.5_amd64.deb ...
Unpacking ces-commons (0.1.5) ...
Setting up ces-commons (0.1.5) ...
Failed to execute operation: File exists
dpkg: error processing package ces-commons (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 ces-commons
E: Sub-process /usr/bin/dpkg returned an error code (1)

on an Ubuntu 16.04 system.

If the CES is run in Azure, the machine gets two IP addresses. One internal address, which is still used for connecting to the etcd and an external which is used for accessing the CES from outside and for which the certificate needs to be generated. The internal address needs to be written to /etc/ces/node_master, the external needs to be written to the /config/_global/fqdn key in etcd.

The parameters we use to configure docker to store key/value pairs in etcd have been removed since Docker 23.0.0
https://github.com/cloudogu/ces-commons/blob/develop/deb/etc/systemd/system/docker.service.d/dockeroptions.conf#L8
moby/moby#40383

Make sure the HashiCorp apt repo key is correctly imported and the apt repo is correctly configured. See https://www.hashicorp.com/blog/announcing-the-hashicorp-linux-repository

The ces self-signed certificate is to be added to the certificate authority.

This is required e.g. for terraform to download terraform-providers from the terraform-registry.

The combination of static IP + Self-Signed certificate produces annoying issues when using OS X + Chrome. Further, working with a domain is simpler than with a static IP. In this issue, the domain local.cloudogu.com should be added as an alternative DNS entry for the SSL certificate.

The get_ip function for vagrant (https://github.com/cloudogu/ces-commons/blob/develop/deb/etc/ces/functions.sh#L122) still uses the old network interface schema (eth0, eth1) and needs to be changed to accept the new schema (enp0s3 etc.).

The /config etcd directory may not be available until the ces-setup has been performed.
Extend the /usr/local/bin/ipchange.sh script with a check to see if the /config directory exists in etcd before getting /config/_global/fqdn in https://github.com/cloudogu/ces-commons/blob/develop/deb/usr/local/bin/ipchange.sh#L34

A ssl-certificate cannot be generated before ces-setup because the domain is not yet set. But instead the ip address could also be used for this. Then the certificate-generation will work.

After rebooting the CES with a new IP address, the ipchangecheck service fails, if the "onlink" network option(?) is set.

Feb 28 14:32:00 ces ipchange.sh[1293]: Device "onlink" does not exist.
Feb 28 14:32:00 ces systemd[1]: ipchangecheck.service: Main process exited, code=exited, status=1/FAILURE

A successful quickfix has been changing the {print $NF}-part in line 126 of /etc/ces/functions.sh to {print $5} and setting the new IP address in /etc/ces/node_master manually, but this maybe isn't a general solution.

Within the release of version 0.3.0 / PR #13, the SystemD docker service definition moved from the ecosystem to this package (compare ecosystem PR 414)

IMO this move broke Debian's package management in recognizing a certain state of a config file. The usual
In consequence, when upgrading from any earlier ces-commons version to 0.3.0, Debian's package management requires a file conflict resolution.

affected systems:

CES instances which have not been set-up with ces-commons 0.3.0

affected versions:

ces-commons = 0.3.0 in conjunction with ces-commons < 0.3.0

known workarounds:

Case 1: No custom modifications to /etc/systemd/system/docker.d.service/dockeroptions.conf:

The conflict consists solely of adding additional lines. If no custom modifications were made applying the maintainer's version is a good choice. If the package upgrade is already underway apt or apt-get provides a way to pick the maintainer's version. In a scripted environment (f. i. with a cesapp Blueprint file the conflict could be avoided by first deleting dockeroptions.conf and then upgrading the package.

Case 1: Custom modifications to /etc/systemd/system/docker.d.service/dockeroptions.conf:

Here you are on your own. Basically the package's dockeroptions.conf should be taken as the base. Then apply your customization. Please note that this solution will not solve the general problem, that is: the next time ces-commons changes dockeroptions.conf you have to solve the arising conflict again. A second config file might be the better solution, though.