My apologies if this is the wrong location to post this. I posted on
the forum a while back
(https://forums.opensuse.org/showthread.php/549649) about this issue I
am having with my OBS project. I disabled and re-enabled publishing
the repository, so now download.O.O and the Provo mirror have packages
with the same file name but different contents. MirrorBrain redirects
to the Provo mirror, which is out of date. When zypper tries to use
those packages, it chokes because the checksums don't match.
Is this a known issue and is there anything I can do from my end on
OBS to fix it? Thanks.
On 22/05/2021 02.27, Quantum Mirror wrote:
> Dear openSUSE infra team,
> I think the MB scanner is stuck and it does not update the file lists. I
> also see the normal scanner connections from 126.96.36.199 on opensuse
> dir and on the isos.
> My mirror hasn't received a single iso or package (ZYpp) download since
> yesterday morning. [21/May/2021:08:56:32 +0200]
I fixed it for now my switching pontifex2:
to use mirrordb1 again.
mirrordb2's postgres would not start (probably replication needs some
but I wonder if that replication is really worth all the hassle.
Often enough HA setups decrease availability via increased complexity
causing increased fragility.
E.g. booting up a single node always just works, but rebooting a pair of
HA nodes might well have both of them reject work for fear of split-brain.
(Note: this email was sent weeks ago, but it looks it didn't come trough).
As part of improvements to download.opensuse.org experience, currently new pilot service is available for using with zypper.
Its primary task is to redirect zypper requests to a mirror in client's country, similar to what MirrorBrain project does.
You can try to replace in /etc/zypp/repos.d/*.repo
If you are in Europe or America, the best experience is expected with these addresses:
mirrorcache-na.opensuse.org<https://mirrorcache.opensuse.org> (North America)
Since it is still a pilot, the service comes without any guarantee or obligations.
Reasons to try it may have those who:
- live in North America and don't want to be redirected to send cross-continent requests when possible;
- want to stick to https connection (mirrorcache will try to find a mirror in the same country, which supports https);
- are on ipv4-only or ipv6-only connection (mirrorcache will try to find a mirror which supports ipv4 or ipv6, depending on the request's connection);
- redirection from d.o.o leads to a mirror, which actually doesn't have the requested file (it is rare, but can happen);
- want to try hosting a mirrorcache instance for own location (e.g. organization, country or continent) and enjoy fast and reliable redirection. (with very modest disk space / HW requirements).
Additional reasons may have those who:
- want to help with improving d.o.o experience and provide feedback;
- are interested in mirror management, for which admin's UI is available, and non-admin UI is planned (so a user can add and manage own mirror without global admin rights);
(login using UI menu and ask me for admin rights if you want to use it or see more advanced controls, like job details).
- need some related functionality: it is possible that it can be easily achievable with mirrorcache.
Further read about differences from MirrorBrain:
How caching works:
- caching happens on folder level, so e.g., when zypper tries to access file, unknown for mirrorcache - it will be redirected to d.o.o, then a background job will collect info about mirrors. Thereafter further requests to the same folder will be properly redirected to a mirror in the client's country, honoring http/https scheme and ipv4/ipv6 connection used:
- requests to remodata/repomd.xml are not cached, so zypper always gets the latest version of packages.
If you are interested in current source code
(most of architecture is stolen from OpenQA):
In case of questions or any feedback do not hesitate to contact me.
Andrii Nikitin <andrii.nikitin(a)suse.com>
DevOPS Automation and Build Service Engineer
SUSE Software Solutions Germany GmbH
(HRB 247165, AG München)
Managing Director: Felix Imendörffer
Whoever decided that all outgoing DNS traffic should only go to
188.8.131.52 (iodine.enidan.com): I decided that it's time to be a bit
more generic and use 184.108.40.206, 220.127.116.11, 18.104.22.168 and 22.214.171.124 (in this
order) for now for all DNS queries that go out from our
infra.opensuse.org network into the world.
I also changed from dnsmasq to bind on anna/elsa and (re-)enabled the
infra.opensuse.org zone on chip.infra.opensuse.org (including
in-addr.arpa). At the moment, FreeIPA is still authoritative for all
infra.opensuse.org DNS entries - nothing changed here. But now it's
just a single "click" away to make chip our "one and only" DNS hidden
master server. Please note that we have another hidden master since a
while: scar is providing DNS for all openVPN clients:
~> host lrupp.vpn.opensuse.orglrupp.vpn.opensuse.org has address 192.168.253.202
lrupp.vpn.opensuse.org has address 192.168.252.202
lrupp.vpn.opensuse.org mail is handled by 1 relay.infra.opensuse.org.
~> host lrupp.tcp.vpn.opensuse.orglrupp.tcp.vpn.opensuse.org has address 192.168.253.202
lrupp.tcp.vpn.opensuse.org mail is handled by 1
~> host lrupp.udp.vpn.opensuse.orglrupp.udp.vpn.opensuse.org has address 192.168.252.202
lrupp.udp.vpn.opensuse.org mail is handled by 1
~> host 192.168.253.202
126.96.36.199.in-addr.arpa domain name pointer
~> host 192.168.252.202
188.8.131.52.in-addr.arpa domain name pointer
This means that hosts that currently use anna/elsa as resolver, should
show which VPN "user" is or was conntected to a machine.
Next task is to get LDAP authentication on chip up and running for the
WebUI. At the moment it looks like either the tool does not like me or
I do not like the LDAP settings in our FreeIPA - who knows...
Regarding DNSSec, I got good news from SUSE IT: while they currently
face some issues with our registrar, they want to support us as good as
possible. So we might end up in some temporary workaround - but that
should not block us. We might even get a dedicated account at another
registrar to manage the domains under openSUSE heroes control
completely on our own in the future. While this is currently not 100%
clear, I see this as a very positive sign that SUSE-IT is hearing us
and tries to do their best to support us.
Meanwhile, I like to get our DNS setup in order. Anyone who likes to
join me in this is more than welcome!
With kind regards,
-----BEGIN PGP SIGNED MESSAGE-----
I just noticed a ticket at <https://progress.opensuse.org/issues/92197>
that is obviously spam. What is the policy, delete them? If spam there is
a normal problem I can have a look now and then and delete them, same as I
do for connect.
But maybe you want to do something else, like blocking those addresses or
something that I do not know, so I ask first.
Carlos E. R.
(from openSUSE Leap 15.1 at Telcontar)
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
The Heroes team agreed last month that we will be making the Salt repo
that manages our infrastructure public on code.opensuse.org. We're
doing this in the interest of improving the transparency of how our
infrastructure is managed and to start opening up our infrastructure
projects to contributors.
Initially, the repository will be public on code.opensuse.org with
pull requests disabled until we get the CI workflow ported over. Once
that's done, we'll flip things over fully and enable pull requests.
The plan is to implement the first stage of this next week, with the
public repository and issue tracker. Until the CI is ported over,
changes are still going to be done in the internal system. I hope
we'll have everything cut over shortly after.
真実はいつも一つ！/ Always, there's only one truth!
here are the minutes of today's heroes meeting:
2021-05-04 heroes meeting
- checking random dnsmasq failures on anna, no obvious config errors
- forums upgrade:
* vBulletin mostly prepared
* blocked on single sign on integration (existing plugin no longer
* code of the old plugin is in /root/am_auth_code.php on
* maybe use https://github.com/oneall/social-login-vbulletin?
* apparently not, it's just a proxy to oneall
* we might be able to create a new login plugin based on the "login
with google" plugin (which also uses openID Connect) -
core/packages/googlelogin/library/externallogin.php could be a
good starting point for our login plugin
> We're just removing the makeup now.
The makeup is already part of the skin now, it looks fine and everyone
got used to it. Forcibly removing it *will* hurt, everyone has to get
used to it again and after it has healed it'll look at best the same.
[> Jan Engelhardt and Fabian Vogt in opensuse-factory]
the next heroes meeting will be on Tuesday (2021-05-04 ) at 18:00 UTC /
20:00 CEST in https://meet.opensuse.org/heroeshttps://progress.opensuse.org/issues/90728 already contains the usual
topics - feel free to add things you want to discuss ;-)
Die Jungs von FreePascal portieren zur Zeit auf alles was
nach Prozessor aussieht oder Prozessor im Namen hat ;-)
[Gerald Goebel in suse-programming]