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 list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-users
