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 #10091 (In Progress): SBC router / board evaluation 2022http://localhost:3000/issues/100912021-12-31T21:13:59ZNico Schotteliusnico.schottelius@ungleich.ch
<a name="Objective"></a>
<h2 >Objective<a href="#Objective" class="wiki-anchor">¶</a></h2>
<ul>
<li>Finding low power routing/control plane boards</li>
</ul>
<a name="Requirements"></a>
<h2 >Requirements<a href="#Requirements" class="wiki-anchor">¶</a></h2>
<ul>
<li>Minimum 8 GB RAM</li>
<li>Likely x86_64 architecture</li>
</ul>
<a name="Candidates"></a>
<h2 >Candidates<a href="#Candidates" class="wiki-anchor">¶</a></h2>
<table>
<tr>
<td> Board </td>
<td> CPU/RAM </td>
<td> NICs </td>
<td> Cost </td>
</tr>
<tr>
<td> <a href="https://www.lattepanda.com/products/lattepanda-delta-432.html" class="external">Lattepanda</a> </td>
<td> 4C/8GB </td>
<td> 1 </td>
<td> ~420$ </td>
</tr>
<tr>
<td> <a href="https://shop.udoo.org/en/udoo-bolt-gear.html" class="external">udoo</a> </td>
<td> 4C/8T + upto 32gb </td>
<td> 1 </td>
<td> ~500 </td>
</tr>
<tr>
<td> <a href="https://up-shop.org/up-core-series.html" class="external">up core</a> </td>
<td> various </td>
<td> 2 </td>
<td> ~400 </td>
</tr>
<tr>
<td> <a href="https://www.odroid.co.uk/ODroid-H2" class="external">odroid h2+</a> </td>
<td> 4C / upto 32gb </td>
<td> 2 </td>
<td> DEAD/NOT sold anymore </td>
</tr>
<tr>
<td> Raspberry Pi4 (ARM!) </td>
<td> 8GB </td>
<td> 1 </td>
<td> ~150 CHF </td>
</tr>
<tr>
<td> <a href="https://teklager.se/en/products/routers/tlsense-i5-7200U" class="external">TLSense 7200U</a> </td>
<td> 8/16gb ram! </td>
<td> 6 </td>
<td> ~700 </td>
</tr>
</table>
<a name="Up-core"></a>
<h3 >Up core<a href="#Up-core" class="wiki-anchor">¶</a></h3>
<ul>
<li><a class="external" href="https://up-shop.org/boards-modules/systems.html">https://up-shop.org/boards-modules/systems.html</a></li>
<li>Various systems / boards</li>
<li>Many devices with 2 nics</li>
</ul>
<a name="Links"></a>
<h2 >Links<a href="#Links" class="wiki-anchor">¶</a></h2>
<ul>
<li><a class="external" href="https://all3dp.com/2/single-board-computer-x86-sbc/">https://all3dp.com/2/single-board-computer-x86-sbc/</a></li>
<li><a class="external" href="https://www.cnx-software.com/2021/04/24/the-5-best-intel-amd-single-board-computers-for-makers/">https://www.cnx-software.com/2021/04/24/the-5-best-intel-amd-single-board-computers-for-makers/</a></li>
<li><a class="external" href="https://www.slant.co/topics/1629/~best-single-board-computers">https://www.slant.co/topics/1629/~best-single-board-computers</a></li>
<li><a class="external" href="https://teklager.se/en/products/routers/tlsense-i7-8550U">https://teklager.se/en/products/routers/tlsense-i7-8550U</a></li>
</ul> Open Infrastructure - Task #9624 (Seen): [user request] Add support for email hostinghttp://localhost:3000/issues/96242021-08-09T15:23:59ZNico Schotteliusnico.schottelius@ungleich.ch
<ul>
<li>Self service</li>
</ul> 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 #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>