ungleich redmine: Issueshttp://localhost:3000/http://localhost:3000/favicon.ico?16699092332024-02-25T08:05:43Zungleich redmine
Redmine Open Infrastructure - Task #12598 (In Progress): Evaluate authentik for use at ungleichhttp://localhost:3000/issues/125982024-02-25T08:05:43ZNico Schotteliusnico.schottelius@ungleich.ch
<a name="Installation"></a>
<h2 >Installation<a href="#Installation" class="wiki-anchor">¶</a></h2>
<pre>
helm repo add authentik https://charts.goauthentik.io
helm repo update
helm upgrade --install authentik authentik/authentik -f values.yaml
</pre> Open Infrastructure - Task #12597 (Seen): Add support for pixelfed hostinghttp://localhost:3000/issues/125972024-02-24T12:43:48ZNico Schotteliusnico.schottelius@ungleich.ch
<ul>
<li>Images: <a class="external" href="https://quay.io/repository/zknt/pixelfed">https://quay.io/repository/zknt/pixelfed</a></li>
</ul> Open Infrastructure - Task #12596 (Waiting): Add support for lemmy hostinghttp://localhost:3000/issues/125962024-02-24T12:41:01ZNico Schotteliusnico.schottelius@ungleich.ch
<ul>
<li>Currently stalled until lemmy-ui issue is resolved</li>
<li><a class="external" href="https://github.com/LemmyNet/lemmy-ui/issues/2374">https://github.com/LemmyNet/lemmy-ui/issues/2374</a></li>
<li>Also see: <a class="external" href="https://ipv6.social/@ungleich/111986164143493986">https://ipv6.social/@ungleich/111986164143493986</a></li>
<li>Chart base exists in dev/lemmy</li>
</ul> Open Infrastructure - Task #12344 (Seen): Evaluate kubevirt (Q12024)http://localhost:3000/issues/123442024-01-07T17:41:50ZNico Schotteliusnico.schottelius@ungleich.ch
<ul>
<li>Could it potentially replace opennebula</li>
<li>If yes, how?</li>
</ul> Open Infrastructure - Task #12343 (In Progress): Evaluate cloud-hypervisor (Q12024)http://localhost:3000/issues/123432024-01-07T16:23:14ZNico Schotteliusnico.schottelius@ungleich.ch
<ul>
<li>Might be a lightweight option for running in k8s</li>
<li>Requires quite some work around it</li>
<li>No management tooling</li>
<li>Storage
<ul>
<li>For ceph probably need to use RBD mapped, rook supports that</li>
<li>For creating thin provisioning, probably need to create a wrapper/controller</li>
</ul>
</li>
<li>live migration
<ul>
<li>seems to be supported</li>
</ul>
</li>
<li>Networking unclear
<ul>
<li>macvtap support, see below</li>
</ul></li>
</ul>
<pre>
"tap=<if_name>,ip=<ip_addr>,mask=<net_mask>,mac=<mac_addr>,fd=<fd1:fd2...>,iommu=on|off,num_queues=<number_of_queues>,queue_size=<size_of_each_queue>,id=<device_id>,vhost_user=<vhost_user_enable>,socket=<vhost_user_socket_path>,vhost_mode=client|server,bw_size=<bytes>,bw_one_time_burst=<bytes>,bw_refill_time=<ms>,ops_size=<io_ops>,ops_one_time_burst=<io_ops>,ops_refill_time=<ms>"
</pre>
<a name="live-migration"></a>
<h2 >live migration<a href="#live-migration" class="wiki-anchor">¶</a></h2>
<ul>
<li>examples use same host migration</li>
</ul>
<pre>
% cloud-hypervisor \
--kernel ./hypervisor-fw \
--disk path=focal-server-cloudimg-amd64.raw \
--cpus boot=2 \
--memory size=1024M \
--net "tap=,mac=,ip=,mask=" --api-socket=/tmp/api1
[17:42] nb3:~% cloud-hypervisor --api-socket=/tmp/api2
# receive VM
ch-remote --api-socket=/tmp/api2 receive-migration unix:/tmp/sock
# send VM - fails
% ch-remote --api-socket=/tmp/api1 send-migration --local unix:/tmp/sock
Error running command: Server responded with an error: InternalServerError: ApiError(VmSendMigration(MigrateSend(Local migration requires shared memory or hugepages enabled)))
</pre>
<a name="Sketch-for-running-VMs-with-cloud-hypervisor"></a>
<h2 >Sketch for running VMs with cloud-hypervisor<a href="#Sketch-for-running-VMs-with-cloud-hypervisor" class="wiki-anchor">¶</a></h2>
<ul>
<li>Manage networking outside
<ul>
<li>pod running potentially in hostnetwork</li>
<li>creating bridge depending on which customer it is</li>
<li>Potentially running IPAM on a per customer basis</li>
<li>Could potentially utilise netbox as a backend, but needs to be written</li>
</ul>
</li>
<li>Console access
<ul>
<li>read only via pod</li>
<li>serial forwarding unclear</li>
</ul>
</li>
<li>Disk management
<ul>
<li>Thin provisioning / templates needs to be built</li>
<li>Growing disks might be supported native by k8s/rook</li>
</ul></li>
</ul> Open Infrastructure - Task #12342 (In Progress): Evaluate Cloudstack (Q1 2024)http://localhost:3000/issues/123422024-01-07T16:07:26ZNico Schotteliusnico.schottelius@ungleich.ch
<a name="Notes"></a>
<h2 >Notes<a href="#Notes" class="wiki-anchor">¶</a></h2>
<ul>
<li>Not sure if it supports ceph
<ul>
<li>Not listed on <a class="external" href="https://docs.cloudstack.apache.org/en/4.18.1.0/conceptsandterminology/choosing_deployment_architecture.html">https://docs.cloudstack.apache.org/en/4.18.1.0/conceptsandterminology/choosing_deployment_architecture.html</a></li>
<li>Storage ref: <a class="external" href="http://docs.cloudstack.apache.org/projects/archived-cloudstack-administration/en/latest/storage.html">http://docs.cloudstack.apache.org/projects/archived-cloudstack-administration/en/latest/storage.html</a>
<ul>
<li>lists ceph for kvm</li>
</ul>
</li>
<li>Seems to focus on qcow2 (-> no thin provisioning?)</li>
</ul>
</li>
<li>Can we setup/run cloudstack in k8s?
<ul>
<li>Seems to be an idea, but far from implementation: <a class="external" href="https://github.com/apache/cloudstack/issues/7298">https://github.com/apache/cloudstack/issues/7298</a></li>
</ul></li>
</ul> Open Infrastructure - Task #12340 (In Progress): Evaluate openstack helm chartshttp://localhost:3000/issues/123402024-01-06T14:18:48ZNico Schotteliusnico.schottelius@ungleich.ch
<a name="Objective"></a>
<h2 >Objective<a href="#Objective" class="wiki-anchor">¶</a></h2>
<ul>
<li>Find out whether we can run openstack with it in our IPv6 only clusters</li>
</ul>
<a name="Summary"></a>
<h2 >Summary<a href="#Summary" class="wiki-anchor">¶</a></h2>
<ul>
<li>Seems to be very fragile / unfinished status
<ul>
<li>Charts are distributed in 2 repositories</li>
<li>No released charts so far, cannot just run helm upgrade --install against a chart repo</li>
<li>A lot of distributed files in the repos</li>
<li>ceph-adaptor seems to be IPv4 based (splitting address on dots)</li>
</ul>
</li>
<li>Might be possible to build on top of it, but might need quite some involvement</li>
</ul>
<a name="Progress"></a>
<h2 >Progress<a href="#Progress" class="wiki-anchor">¶</a></h2>
<ul>
<li>Try to stick to "in order setup" </li>
<li>But when one item is blocked, setup other components that might crash due to missing dependencies</li>
</ul>
<a name="Base-documentation"></a>
<h2 >Base documentation<a href="#Base-documentation" class="wiki-anchor">¶</a></h2>
<ul>
<li><a class="external" href="https://docs.openstack.org/openstack-helm/latest/">https://docs.openstack.org/openstack-helm/latest/</a></li>
<li>Related tools from our side: <a class="external" href="https://code.ungleich.ch/ungleich-public/ungleich-tools/src/branch/master/openstack">https://code.ungleich.ch/ungleich-public/ungleich-tools/src/branch/master/openstack</a></li>
</ul>
<a name="Communication"></a>
<h3 >Communication<a href="#Communication" class="wiki-anchor">¶</a></h3>
<ul>
<li>IRC via matrix: <a class="external" href="https://matrix.ungleich.ch/#/room/#_oftc_openstack-helm:matrix.org">https://matrix.ungleich.ch/#/room/#_oftc_openstack-helm:matrix.org</a></li>
<li>Slack: <a class="external" href="https://app.slack.com/client/T09NY5SBT/C3WERB7DE">https://app.slack.com/client/T09NY5SBT/C3WERB7DE</a></li>
</ul>
<a name="Components"></a>
<h2 >Components<a href="#Components" class="wiki-anchor">¶</a></h2>
<ul>
<li><a class="external" href="https://docs.openstack.org/openstack-helm/latest/install/deploy_openstack_backend.html">https://docs.openstack.org/openstack-helm/latest/install/deploy_openstack_backend.html</a></li>
<li><a class="external" href="https://docs.openstack.org/openstack-helm/latest/install/deploy_openstack.html">https://docs.openstack.org/openstack-helm/latest/install/deploy_openstack.html</a></li>
</ul>
<a name="OpenStack-client"></a>
<h3 >OpenStack client<a href="#OpenStack-client" class="wiki-anchor">¶</a></h3>
<ul>
<li>Is installed on the local machine</li>
<li>Installs some python and creates a config file</li>
<li>Installs python packages as root / using pip
<ul>
<li>cmd2 python-openstackclient python-heatclient</li>
</ul></li>
</ul>
<a name="Ceph"></a>
<h3 >Ceph<a href="#Ceph" class="wiki-anchor">¶</a></h3>
<ul>
<li><code>./tools/deployment/ceph/ceph-rook.sh</code>
<ul>
<li>setups up rook in rook-ceph namespace</li>
<li>also saw ceph namespace somewhere
<ul>
<li>ceph cluster is put into ceph namespace</li>
<li>operator is in rook-ceph</li>
</ul>
</li>
<li>sets min_size=1 for testing</li>
<li>uses loop devices</li>
</ul>
</li>
<li><code>./tools/deployment/ceph/ceph-adapter-rook.sh</code>
<ul>
<li>builds a helm chart first: /home/nico/osh/openstack-helm-infra/ceph-adapter-rook-0.1.0.tgz</li>
<li>maybe can reference the chart directly from the git repo</li>
</ul>
</li>
<li>There is also ./tools/deployment/ceph/ceph.sh, not sure for what, not mentioned in doc</li>
</ul>
<a name="Ingress"></a>
<h3 >Ingress<a href="#Ingress" class="wiki-anchor">¶</a></h3>
<ul>
<li>for outside reachability, as usual</li>
</ul>
<a name="rabbitmq"></a>
<h3 >rabbitmq<a href="#rabbitmq" class="wiki-anchor">¶</a></h3>
<a name="MariaDB"></a>
<h3 >MariaDB<a href="#MariaDB" class="wiki-anchor">¶</a></h3>
<a name="Memcached"></a>
<h3 >Memcached<a href="#Memcached" class="wiki-anchor">¶</a></h3>
<a name="Keystone"></a>
<h3 >Keystone<a href="#Keystone" class="wiki-anchor">¶</a></h3>
<ul>
<li>Identity management</li>
<li>./tools/deployment/component/keystone/keystone.sh</li>
</ul>
<a name="Heat"></a>
<h3 >Heat<a href="#Heat" class="wiki-anchor">¶</a></h3>
<ul>
<li>Templating / infra</li>
<li>Unclear</li>
<li>./tools/deployment/component/heat/heat.sh</li>
</ul>
<a name="Glance"></a>
<h3 >Glance<a href="#Glance" class="wiki-anchor">¶</a></h3>
<ul>
<li>Image service</li>
<li>./tools/deployment/component/glance/glance.sh</li>
</ul>
<a name="Placement-Nova-Neutron"></a>
<h3 >Placement, Nova, Neutron<a href="#Placement-Nova-Neutron" class="wiki-anchor">¶</a></h3>
<ul>
<li>OpenStack Nova is the compute service</li>
<li>Neutron is the networking service</li>
<li>Using openswitch, probably in hostnetwork mode (guess)</li>
</ul>
<pre>
cd ~/osh/openstack-helm
./tools/deployment/component/compute-kit/openvswitch.sh
./tools/deployment/component/compute-kit/libvirt.sh
./tools/deployment/component/compute-kit/compute-kit.sh
</pre>
<a name="Cinder"></a>
<h3 >Cinder<a href="#Cinder" class="wiki-anchor">¶</a></h3>
<ul>
<li>block storage service</li>
<li>probably interacts with ceph </li>
<li>not sure yet how/where the monitor is set, might be in the rook step</li>
</ul>
<pre>
cd ~/osh/openstack-helm
./tools/deployment/component/cinder/cinder.sh
</pre>
<a name="Image-management-ceph"></a>
<h2 >Image management (ceph?)<a href="#Image-management-ceph" class="wiki-anchor">¶</a></h2>
<ul>
<li>Should be able to use thin provisioning</li>
</ul> Open Infrastructure - Task #10411 (In Progress): Migrate ula.ungleich.ch into Kubernetes and upgr...http://localhost:3000/issues/104112022-03-19T19:37:01ZNico Schotteliusnico.schottelius@ungleich.chipv6 - Task #10239 (New): Recursive DNS, visible on IPv4, acting as a proxy to enable visibility ...http://localhost:3000/issues/102392022-01-31T13:27:26ZMoris Jones
<p>In order for a DNS server on an IPv6-only VM to be useful in the still-on-IPv4 real world, it needs to be able to make its data available to the IPv4-only world. Unlike HTTP, but in somewhat similar fashion to SMTP, this requires not just a pass-through but an actual DNS server, recursing its queries to the IPv6 server. This is most easily understood in a diagram</p>
<p>IPv4 client <-> IPv4-visible Ungleich Recursive DNS server <-> IPv6 DNS server</p>
<p>Domain registry records:</p>
<p>mydomain.com<br />ns1.mydomain.com myVM-ip6-address::blah::blah<br />ns2.mydomain.com ip4-address-of-ungleich-recursive-IPv4-to-IPv6-dns-proxy</p>
<p>Discussions were held regarding this some time ago, but no progress has been made.<br />The absence of a solution for DNS visibility of IPv6 VMs is holding them back as a useful product and forces their users to really on third-party DNS providers, or simply not to use them for any kind of world-visible service.</p>
<p>I am at this time willing to attempt an implementation of this, which if successful can be copied and made official. I'm not a BIND whizzkid, so I cannot do it blind. To do so I will require an IPv4-visible environment. Options include a VM dedicated to this purpose (I think this makes the most sense), or temporarily assigning an IPv4 address to my current VM.</p> ipv6 - Task #10238 (Waiting): ipv6-only DNS setup is misleading and misconfiguredhttp://localhost:3000/issues/102382022-01-31T13:05:33ZMoris Jones
<p><a class="external" href="https://redmine.ungleich.ch/issues/7496">https://redmine.ungleich.ch/issues/7496</a></p>
<p>Says that place5 and place6 should return ONLY AAAA records</p>
<p>But both of them, as well as every other ungleich DNS server I know of, return both A and AAAA records.</p>
<p>Most software today defaults to A records if they exist and only uses AAAA if they do not. Web browsers for example.</p>
<p>Furthermore, the following page says that by choosing place5 and place6 as DNS resolvers one can route almost all traffic through the VPN. But because they return A records, in practice this does not happen.</p>
<p><a class="external" href="https://redmine.ungleich.ch/projects/open-infrastructure/wiki/Ungleich_IPv6_wireguard_VPN">https://redmine.ungleich.ch/projects/open-infrastructure/wiki/Ungleich_IPv6_wireguard_VPN</a></p> Open Infrastructure - Task #9516 (New): Add proxy protocol support for IPv4<->IPv6 proxies to ena...http://localhost:3000/issues/95162021-07-17T19:43:13ZNico Schotteliusnico.schottelius@ungleich.ch
<ul>
<li>Based on <a class="external" href="https://www.haproxy.com/blog/haproxy/proxy-protocol/">https://www.haproxy.com/blog/haproxy/proxy-protocol/</a></li>
<li>Needs support in the backend</li>
<li>Need to check whether we can enable it <strong>per</strong> backend as an option <del>or</del> whether we make it a per proxy setting</li>
</ul> Open Infrastructure - Task #9401 (New): Building an IPv6 only Matrix networkhttp://localhost:3000/issues/94012021-06-07T20:10:21ZNico Schotteliusnico.schottelius@ungleich.ch
<a name="Objective"></a>
<h2 >Objective<a href="#Objective" class="wiki-anchor">¶</a></h2>
<p>Have a test case of an IPv6 only Matrix network or rooms. Servers/client that want to join are required to have IPv6.</p>
<a name="Implementation-core-network"></a>
<h2 >Implementation core network<a href="#Implementation-core-network" class="wiki-anchor">¶</a></h2>
<ul>
<li>Synapse running IPv6 only</li>
<li>No outgoing NAT64/DNS64</li>
<li>Possibly using the domain "ipv6.social" for the matrix domains (i.e. ungleich could run on @xyz:ungleich.ipv6.social, anyone joining can select a DNS name of their choice)
<ul>
<li>Only if of interest for a common view towards outside</li>
</ul>
</li>
<li>Only incoming IPv6
<ul>
<li>No proxies or similar to bridge from the IPv4 world</li>
</ul>
</li>
<li>Maybe removing A records from DNS</li>
</ul>
<a name="Implementation-federation-other-Servers"></a>
<h2 >Implementation federation / "other Servers"<a href="#Implementation-federation-other-Servers" class="wiki-anchor">¶</a></h2>
<ul>
<li>Other servers can be IPv6 only on dual stack
<ul>
<li>Need to define whether the federation should accept dual stack or not</li>
</ul></li>
</ul> Open Infrastructure - Task #8916 (In Progress): Add DNS over TLS or HTTP support in DCLhttp://localhost:3000/issues/89162021-02-18T14:47:22ZNico Schotteliusnico.schottelius@ungleich.ch
<ul>
<li>One or the other might make sense to be added</li>
<li>Will be added in bind 9.17: <a class="external" href="https://gitlab.isc.org/isc-projects/bind9/-/wikis/DoH/DOH-and-DoT-Design">https://gitlab.isc.org/isc-projects/bind9/-/wikis/DoH/DOH-and-DoT-Design</a></li>
<li>Currently we have 9.16 in production</li>
</ul> Open Infrastructure - Task #8537 (New): Check whether we can support DNS wildcard with our ipv4/i...http://localhost:3000/issues/85372020-10-26T13:38:02ZNico Schotteliusnico.schottelius@ungleich.ch
<p>Request:</p>
<pre>
Hi, I have a ipv6only vm have just set up a ipv4 to ivp6 proxy but it does not really work for my subdomain. is it needed that every subdomain is also included in the forwarding or is it possible that you set a wildcard?
</pre>
<p>We should be able to support this. We are currently using:</p>
<pre>
# HTTPS
use-server www.ungleich.ch if { req_ssl_sni -i www.ungleich.ch }
# HTTP
use-server ungleich.ch if { hdr(host) -i ungleich.ch }
</pre>
<p>Need to lookup how to match "ungleich.ch" and '*.ungleich.ch'</p> Open Infrastructure - Task #6762 (New): Allow IPv6 only hosts to properly send emails to IPv4 onl...http://localhost:3000/issues/67622019-06-03T16:18:42ZNico Schotteliusnico.schottelius@ungleich.ch
<p>Currently IPv6 only hosts get NAT64'ed to one of our IPv4 addresses. When there is a mail server running on an IPv6 only host that connects to an IPv4 host using the source address 185.203.114.1 .</p>
<p>This again is reverse DNS based mapped to 185-203-114-1.legacy.ipv4.at.ungleich.ch and usually does not fit the EHLO message of the mail server.</p>
<p>We need to find a nice fix for this problem short term so that people can run their mail server in IPv6 only networks</p>