its back up now
Den fre 24 nov. 2023 kl 10:58 skrev Luna Jernberg <droidbittin(a)gmail.com>:
>
> Hey!
>
> I wanted to vote but the voting site is currently down
>
> Den tors 23 nov. 2023 kl 22:33 skrev Douglas DeMaio <douglas.demaio(a)suse.com>:
> >
> > Hi all,
> > Read the article about the logos contest at https://news.opensuse.org/2023/11/23/selecting-the-new-face-of-os-is-underw… or go to survey.opensuse.org to vote.
> > v/r
> > Doug
On 11/14/23 15:39, Michael Matz wrote:
> Hello Georg,
>
> On Sat, 11 Nov 2023, Georg Pfuetzenreuter wrote:
>
>> 5. Proxying
>>
>> We try to keep the amount of machines with direct exposure to the internet to
>> a minimum in the new infrastructure. Hence all traffic for most public
>> services will need to pass the atlas{1,2}.infra.opensuse.org reverse proxy
>> servers. This was already implemented for all existing services, but should be
>> noted when designing new ones.
>
> So, I gather from this and remarks in Slack that gate.opensuse.org
> deliberately switched off ssh port forwarding. Ergo our method to push
> data from inside the SUSE network to gcc-stats (via ssh -p 2271
> gcc(a)gate.opensuse.org) doesn't work anymore.
>
> What's the alternative to that? openVPN doesn't seem viable as we need to
> rsync-push data from different machines (again, all inside the SUSE
> engineering networks) to gcc-stats. openVPN only normally supports one
> source machine, and additionally the credentials should probably not just
> lie around on random devel machines. In effect I don't really _want_ any
> of these devel machines to be part of the heroes VPN network. Maybe our
> own sshd on gcc-stats open to the SUSE network? But that requires routing
> from SUSE networks directly to gcc-stats. The port forwarding was
> basically the most efficient and secure mechanism for this.
>
> So, yeah, what's the alternative? Thanks for any insight.
Hi Michael,
thanks for reaching out.
A colleague of yours (?) had the same request regarding gcc-stats.i.o.o
and opened a ticket regarding it, in which I already proposed an
alternative two days ago:
https://progress.opensuse.org/issues/139244
Please follow-up in the ticket and coordinate with other users of
gcc-stats.i.o.o in order for all of you to have a common solution.
Best,
Georg
>
>
> Ciao,
> Micha.
Hi Ish,
I noticed strange behaviour of your opensuse-mirror.datakeepers.co.za on
stage.o.o rsync.
It seems as if multiple parallel rsync sessions try to sync the same
files. This could happen, if there is no locking on your side to prevent
concurrent sync runs.
Additionally, you could use
rsync://stage-main-repos.opensuse.org
as source. It has copies of the most interesting 4TB on fast SSDs on a
better network connection.
Ciao
Bernhard M.
Hi everyone,
with our migration from Nuremberg to Prague, several changes in the
infrastructure were introduced.
I yet have to update our admin wiki, but want to highlight some
differences you will need to consider when connecting to the VPN and
navigating around machines.
1. VPN gateway
There is a new VPN gateway in place. If you were using an IP address as
the VPN "remote", please update it to "gate.opensuse.org", or, if you
have specific reasons to not use the domain name, the new addresses
gate.opensuse.org resolves to now.
2. DNS forwarders
The new gateway announces new DNS servers as well, but if you use a
custom forwarding setup (for example using dnsmasq), please update your
forwarding nameservers for
infra.opensuse.org
e.7.2.b.0.4.e.d.7.0.a.2.ip6.arpa.
to
2a07:de40:b27e:1203::11 and 2a07:de40:b27e:1203::12
3. Network segments and shell access
The new infrastructure uses multiple network segments (VLANs) to
separate services. Most existing VMs were migrated to the
"openSUSE-internal" network, which is accessible directly from your VPN
client, hence you should be able to reach such machines as before. Same
applies for connectivity to VMs hosted in Provo.
New, non migrated, machines, might be installed in more restricted
segments. Those are accessible through the thor.infra.opensuse.org
bastion host.
To find which network segments are implemented at a given time, check
the file "pillar/infra/networks.yaml" in our Salt repository.
To find which network segment a machine is residing in, check the
respective "source" field in the file "pillar/infra/hosts.yaml".
https://code.opensuse.org/heroes/salt/blob/production/f/pillar/infra
4. Firewalling
The new network segments implement strict firewalling to ensure both
separation between the segments, but also to the internet. This
firewalling is based on a whitelist-only principle, meaning _all_
traffic is blocked by default, and legitimate connectivity needs to be
allowed on a case-by-case basis.
We tried to track down and implement all necessary connectivity as part
of the server migrations, but if you notice some traffic which is
required for the operation of your service to still be blocked, please
reach out to discuss the options.
5. Proxying
We try to keep the amount of machines with direct exposure to the
internet to a minimum in the new infrastructure. Hence all traffic for
most public services will need to pass the atlas{1,2}.infra.opensuse.org
reverse proxy servers. This was already implemented for all existing
services, but should be noted when designing new ones.
6. IPv6
We believe in the future and decided to run our new internal
infrastructure in a "single-stack", IPv6-only, fashion. Whilst it might
be unexpected for some users to not find an IPv4 address on a network
interface, it was ensured that this new design functions as
transparently as possible. Connectivity to IPv4-only internet services
(for example github.com) is still possible, and so is connectivity to
machines in Provo which have not yet been changed to IPv6 - but note
that the firewall restrictions described in 4. apply here as well.
Of course, we still implemented IPv4 on servers which need to be
reachable by the wide internet audience, such as our proxy servers (5.).
We tried our best to mitigate all possible issues arising with the
firewalling and IPv6, but it is possible that some slipped through.
Please let us know if you encounter any issues, either in
#opensuse-admin or by opening a ticket in
https://progress.opensuse.org/projects/opensuse-admin/issues.
To find which VMs have already been migrated and which are still
pending, please reference the lists at the bottom of
https://etherpad.opensuse.org/p/move-nue-prg.
Have a lot of fun with the new setup ...
Georg
