Hi Oliver, I was looking to understand what kind of change it was, so thank you for the information. We will use url paths for the time being.
best regards, Pekka On Tue, May 5, 2026 at 10:24 AM Oliver Welter <[email protected]> wrote: > 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 >>>>> [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 >>> [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 > [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
