cloudogu / ces-commons Goto Github PK
View Code? Open in Web Editor NEWLicense: MIT License
License: MIT License
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:
192.170.2.42
.vagrant halt
.Vagrantfile
, e.g. 182.180.3.23
.vagrant up
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.
CES instances which have not been set-up with ces-commons 0.3.0
ces-commons = 0.3.0 in conjunction with ces-commons < 0.3.0
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.