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
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
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
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
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
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
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
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
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
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
