January 2020 - Heroes - openSUSE Mailing Lists

[heroes] forums migration - vbulletin
by Per Jessen 31 Jan '20

31 Jan '20

I need an opinion - I've hit a slight hurdle. The vBulletin code we are running in Provo is version 4.2.2, so quite old. It is so old it does not work with php 7.2, only older. (I haven't actually tried, that is what google tells me). I think we have three, maybe four options - a) upgrade vBulletin to the latest, cost USD249. May or may not make the migration easier, but at least we'd have an up-to-date platform. b) run the current 4.2.2 version, but on php7.0 or 7.1 - I don't know if we have packages available for Leap15.1. Might not be difficult to build. c) run the current 4.2.2 version, on Leap 42.3 with php7.0 - which I guess does not go well with our SLA. d) switch to something else, e.g. discourse. Apart from migrating the current contents, this is easy. I don't know what the forum admins would say to losing the contents. What's your vote? -- Per Jessen, Zürich (6.9°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

12 29

[heroes] Running anything on an unsupported OS is not an option
by Marcus Rückert 31 Jan '20

31 Jan '20

Seriously never an option. Learn to move forward efficiently and embrace it. -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

2 1

[heroes] FYI: wiki databases migrated
by Lars Vogdt 30 Jan '20

30 Jan '20

Hi I don't have much time, but want to let you know that all wiki databases are migrated to the galera cluster in the openSUSE heroes network. With this, there is no need any longer to proxy the mysql connections into the old network. The proxy port is disabled (commented out) on anna & elsa. Just in case there is a problem... With kind regards, Lars -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

3 2

[heroes] question about progress.o.o
by Per Jessen 29 Jan '20

29 Jan '20

Check out issue 62513. When I entered it, I gave the description '404'. When I now read the issue, it is displayed as '1.' - if I qoute it, I see the 404 ? -- Per Jessen, Zürich (5.7°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

2 3

[heroes] php 7.3 or php 7.4 in 15.2
by pgajdos 29 Jan '20

29 Jan '20

Hello, perhaps is too late now, but maybe there is still a chance to get 7.4 instead of 7.3. What is your position on that? Petr -- Have a lot of fun! -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

3 3

[heroes] need a database update - changing a column in pfx2asn.
by Per Jessen 28 Jan '20

28 Jan '20

I can probably do this myself, but I don't know if I need to do it everywhere (mirrordb[1234]) or if updates are automatically propagated ? See https://progress.opensuse.org/issues/62678. -- Per Jessen, Zürich (6.8°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

1 1

[heroes] Status update: fake iron machines
by Christian Boltz 27 Jan '20

27 Jan '20

Hello, You might have seen https://progress.opensuse.org/issues/62204 which is about VMs that appear as "physical" instead of "kvm" to salt, and therefore break applying the highstate. I had some fun (really!) debugging this yesterday - starting with reading the salt code that does the hardware detection to reading virt-what (used by salt if it's installed) and debugging it. If you are looking for an entertaining story how a small error was able to cause such a serious problem, read the ticket yourself (ideally while being logged in so that you also see the private comments). If you only want to hear about the actual reason and solution, scroll down - I'll add some whitespace (to prevent a spoiler) and then add what the actual fix was. However, reading the ticket is much more funny ;-) Regards, Christian Boltz PS: Scroll down for the end of the story ;-) scroll... scroll... scroll... scroll... Ok, enough scrolled ;-) In the end, it turned out that virt-what uses which virt-what-cpuid-helper to find one of its helper scripts. Unfortunately the virt-what package doesn't have "Requires: which" (only "Requires: util-linux", where which lived until 2013) - and without "which" installed, it's not a surprise that which $whatever fails ;-) The obvious workaround is to install "which". I added "which" to the package list in pillar/common.sls so that it gets installed on all 15.x machines, and opened a bugreport so that we don't need the same workaround in future releases. In case someone wonders why this only affected some VMs and not all with Leap 15.1: the condition to trigger this bug is that virt-what is installed and that which is not installed. If virt-what is not installed, salt uses systemd-detect-virt instead, which works without problems. -- >> MCSE: "Microsoft Certified Stupidity enclosed" [A. Spengler in dasr] > Ich dachte das heißt: > MCSE - Must Call Somebody Else [Markus Feilner in suse-linux] Na Na Na!!! Ihr könnt doch nicht so einfach über so ein Zertifikat herziehen! Das ist bestimmt der Neid der Besitzlosen! Wenn ich hier an die Wand sehe (da hängt das bei mir), dann lese ich ganz deutlich: Minsweeper Consultant and Solitaire Expert Und darauf lege ich doch grossen Wert!!!! [Konrad Neitzel in suse-linux] -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

1 0

[heroes] Re: ** RECOVERY Service Alert: anna.infra.opensuse.org/Public SSL cert is OK **
by Karol Babioch 26 Jan '20

26 Jan '20

Hi all, the certificates for *.opensuse.org where about to expire in 28 days or so. Unfortunately the automatic issuance and deployment of new certificates (via Let's Encrypt) didn't work as intended - once again. Luckily we have some monitoring setup for this, so we have been notified of this problem. It has been complaing about this for some days now, but I was somehow hoping for a miracle and for the problem to "fix itself". (Un)fortunately computers are deterministic after all, so the problem didn't go away. Upon login on "crtmgr.infra.opensuse.org", I've noticed that there have been two failed services, namely: - dehydrated - sssd sssd fails with the following error messages: > Jan 26 22:03:57 crtmgr sssd[682]: SSSD couldn't load the configuration database [2]: No such file or directory. Not sure why sssd is enabled at all on this machine, since the sssd configuration file doesn't contain anything at all. Maybe this was the result of some (unfinished) Salt run in the past? (The machine is currently not managed in Salt intentionally). I've disabled the sssd for now and consider it to be (totally) unrelated to the actual issue. The journal said the following for dehydrated: > Jan 26 01:39:07 crtmgr systemd[1]: dehydrated.service: Main process exited, code=exited, status=1/FAILURE > Jan 26 01:39:07 crtmgr systemd[1]: Failed to start Certificate Update Runner for Dehydrated. > Jan 26 01:39:07 crtmgr systemd[1]: dehydrated.service: Unit entered failed state. > Jan 26 01:39:07 crtmgr systemd[1]: dehydrated.service: Failed with result 'exit-code'. While dehydrated is a great set of script(s) for Let's Encrypt, there seems to be no further logging. The man page [1] does not even mention debug and/or log at all :-/. We had similar issues in the past (broken dehydrated service), and had to debug them by running the script with "bash -x", etc. pp. This time all I did was to reboot the machine (due to pending kernel updates) and triggering the "dehydrated.service" manually afterwards. To my surprise, it successfully run, fetched new certificates and deployed them through the infrastructure, so the "problem is fixed" now. However, I still don't know why it didn't work when triggered by the systemd timer and I don't see a way to learn more about the issue. I'm not super familiar with dehydrated, and I was not the one who originally set up all of this. Are there any recommendations on how to deal with issues like this in the future? Have I missed some log/debug output that might be helpful in understanding what the root cause of the issue has been? Or is it really impossible to tell why a previous run of the script failed? This seems odd to me ... Best regards, Karol Babioch [1]: https://github.com/lukas2511/dehydrated/blob/master/docs/man/dehydrated.1

1 0

[heroes] pontifex - daily fetch of routeviews disabled?
by Per Jessen 26 Jan '20

26 Jan '20

I see the daily fetch from mirrorbrain was stopped, last one was 10/1 - I presume because of the certificate problem? I was just wondering. -- Per Jessen, Zürich (-0.1°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

3 7

[heroes] bit of a mirror tidy up
by Per Jessen 21 Jan '20

21 Jan '20

Now that Lars has been cleaning up the ticket queue, there is room for some more :-) We have more than a few mirrors that need some TLC. Some are just gone, others are misconfigured (not on our side). I've opened a few tickets for some today, there is more to come. Thanks for the hint about the marker filename Lars - it had not occurred to me they might simply be wrong. Many of the markers used a file called 'content' which is apparently long gone. I've changed that to 'CHECKSUMS' instead. You might not notice, but http://mirrors.opensuse.org now has a lot(!) more ticks than it used to have. More will appear as mirrors are being scanned. I have also added a marker for 'Tumbleweed history' as well as for Leap 15.2, and removed old ones for Leap 42.x. The complete page should now fit the full browser on a wide screen, without a horizontal scrollbar. It is really just a minor update, except for tumbleweed - we have a good mirror setup for TW, but because of the faulty markers, most of it wasn't being used , so e.g. people in the US ended up using European mirrors. -- Per Jessen, Zürich (3.2°C) Member, openSUSE Heroes -- To unsubscribe, e-mail: heroes+unsubscribe(a)opensuse.org To contact the owner, e-mail: heroes+owner(a)opensuse.org

2 1

2022

2021

2020

2019

2018

2017

2016

Heroes January 2020