Hi Peka,
it was not "intenionally removed" but the realm routing has undergone a
lot of rework and also has some new features based on new config items.
So the current behaviour might be a bug in the code or just some missing
config but I was not able to have a look into it.
Anyway the recommended way is to use the URL path based routing so if
you are already on it, that might be the better way forward.
Oliver
On 5/5/26 08:41, Pekka Länsiaho wrote:
Hi,
I would still like to hear if this is intentional and if it will
remain so, before altering anything ourselves.
best regards,
Pekka
On Tue, Apr 28, 2026 at 10:37 AM Pekka Länsiaho
<[email protected]> wrote:
Hi Oliver,
Thanks for the info, I'll probably reach out in the enterprise
channels.
As for the issue: We are using /select/ realm mode, with
/list/ layout. I tried using /path/ mode as suggested, and created
a quick map to test the realms, now manually entering
//webui/index/ takes you back to the realm list, but otherwise
the functionality is the same.
This behaviour is consistent with the demo install.
Some of our users have a workflow where they might need to go
between realms in a quick succession, so this will become a bit of
an inconvenience, if it is a design choice with no option to
change the behaviour.
Previous functionality was much more convenient in our use (where
if you logged off a realm, you were returned by default to the
realm index).
best regards,
Pekka
On Mon, Apr 27, 2026 at 8:20 PM Oliver Welter <[email protected]> wrote:
Hi Pekka,
glad you figured this out - no idea what went wrong with the
apache symlink, we really try to keep the upgrade path as
smooth as possible but especially if you miss some releases in
between or play around with the config yourself its hard to
tackle this in the CE versions. Perfect move over to your
question on EE support: The deployment model for EE is
different to CE and yes of course we assist our customers with
the upgrade so no need for you to mess around with this - we
maintain a working configuration for you and provide tools
(rpm, ansible, Makefiles) to get it installed in your
environment in a reproducible and safe manner :)
Regarding the realm selection issue - what type of realm
selection mode are you using? We recommend using the url path
layout which is the most robust version and also allows
parallel logins on different realms. You can then always move
back to the selection page using /webui/index - the next
release (3.34 - likely hitting the public in May) will even
bring some more improvments here.
Oliver
On 4/27/26 13:03, Pekka Länsiaho wrote:
Hi,
After setting up a new VM and comparing the two, I figured
out the issue was with apache; openxpki site configuration
file did not correctly get replaced with a symlink to the new
location during /apt install/ and caused the aforementioned
error. Once fixed, I can finally access the application
properly again.
However, I am left with one last issue (hopefully): After
logging out from a realm or using reset login after selecting
a realm, I am not able to go back to realm selection without
clearing session cookies. Is this a bug?
best regards,
Pekka
On Wed, Apr 22, 2026 at 4:44 PM Pekka Länsiaho
<[email protected]> wrote:
Hello,
I ruled out the browser cookie by trying out different
browsers and incognito mode. Results are mostly the same,
but there was no SessionCookie error in webui.log.
After that, I went through the socket settings again,
just in case, but couldn't pinpoint a leftover setting
anywhere. Then I walked back the whole install process
and lo-and-behold: Even a demo / sampleconfig fresh
install is no different. I deleted mariadb database,
/var/log/openxpki* -directories and /etc/openxpki
-directory, reinstalled debian packages, rebuilt schemas
and ran sampleconfig.sh after the initial setup steps
from debian quickstart section -- And I still get the
same result, albeit now I have nothing indicating an
error in logs, since the
earlier /var/log/openxpki/webui.log no longer exists by
default.
I will fire up a fresh debian VM and see if I can
replicate the behaviour, but other ideas are welcome in
the meantime.
Also, let me ask just in case: Did you provide tools for
easier upgrade to 3.32 in enterprise environments? If the
experience is better there, I might have something to
discuss with our mr. moneybags :)
best regards,
Pekka
On Mon, Apr 20, 2026 at 7:30 PM Oliver Welter
<[email protected]> wrote:
Hi Pekka,
did you try to clear your browser cookies? This
sounds a bit like you have changed the settings for
the session management and now the system tries to
decode/decrypt stuff from an older session/setting.
Oliver
On 4/17/26 11:27, Pekka Länsiaho wrote:
Hello again,
We have been a bit slow with the system updates, and
since v3.32 was a breaking change we had to put
off updates entirely for a while, so I am trying to
remediate that now.
I have managed to upgrade configuration following
instructions in the change log
https://openxpki.readthedocs.io/en/master/upgrading.html#release-v3-32,
and got both server and client services running
after upgrade to v3.32.15 and using community config
v3.32.8. (Old system version was v3.30.9, not quite
sure which config version, but I believe the
community branch commit was 17b96e5)
System is running Debian 12.13.
/openxpkictl status server/ and /client/ both report
running and accepting requests, and both clients and
serviced logs have no indication of errors.
However, when accessing webui at
https://openxpki/webui/index/#/openxpki/welcome,
application error appears: "/The webserver did not
return the expected data. Possible causes: OpenXPKI
client is not running; authentication session has
expired; an internal error. HTTP code: 503/".
And upon inspecting /var/log/openxpki/webui.log, I
am met with these lines:
/ERR Unable to decrypt cookie (AES: Data size must
be multiple of blocksize (16 bytes) at
/usr/share/perl5/Crypt/CBC.pm line 492.) at
/usr/share/perl5/OpenXPKI/Client/Service/WebUI/SessionCookie.pm
line 214./
/ERR Error creating backend client: Unable to
connect to socket [sid=....]/
/ERR Backend service is not reachable or not
responding [sid=....]/
I tried to look at the newly provided
'sampleconfig.sh' file to see if there was a step I
might have missed compared to a fresh system
install, but couldn't immediately point to any
particular step, unfortunately.
Help would be much appreciated, my eyes grow tired
of comparing things.
best regards,
Pekka
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
--
Protect your environment - close windows and adopt a penguin!
_______________________________________________
OpenXPKI-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openxpki-users
