upgraded to tomcat9 issues

[Steve Herrera]

Peter,
That looks like it fixed it. I had to create that override file as you
documented. I was also under the same impression as others that there
should have been something written in the idp-process.log according to the
errors.  After creating the file and running the demon-reload command it
still wasn't working. Not even restarting tomcat. At this point I was about
ready to just rebuild from scratch but the reboot of the server worked.

Question about going forward with IDP4. Has the attribute-resolver.xml file
been split apart?  Do the encoded attributes still reside here or is there
a different place for them to go? I thought I had read that the encoded
items were moved out and only leaving connection details in there but I
can't seem to find where I read that at. For example would this remain in
attribute-resolver.xml or is IDP4 recommending this be moved out:

<AttributeDefinition xsi:type="Simple" id="givenName">

        <InputDataConnector ref="myLDAP" attributeNames="givenName"/>

        <AttributeEncoder xsi:type="SAML1String" name=
"urn:mace:dir:attribute-def:givenName" />

        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:2.5.4.42"
friendlyName="givenName" />

    </AttributeDefinition>

Steve Herrera
System Administration
Information Security
Bradley University
Phone: 309 / 677-2336
FAX: 309 / 677-3460
Email:  *sherrera at fsmail.bradley.edu <sherrera at fsmail.bradley.edu>*


On Tue, Sep 1, 2020 at 4:11 PM Peter Schober <peter.schober at univie.ac.at>
wrote:

> * Christopher Bongaarts via users <users at shibboleth.net> [2020-09-01
> 22:11]:
> > But if it got this far, I would have expected to see output in
> > idp-process.log, so you might also want to double-check your logging
> > configuration and filesystem permissions.
>
> There's also the possibility of changed Tomcat packaging. E.g. when
> Debian (which is the basis for Ubuntu) updated Tomcat 8 to 9 in Debian
> 10 they also moved the service management from SysV to systemd.
> And the default systemd configuration for tomcat included
> ProtectSystem=strict and a default set of ReadWritePaths limitations,
> preventing tomcat from writing anywhere else on the file system -- so
> no metadata file backups and no local log files.
>
> If that's the case the workaround is easy, cf.
> http://shibboleth.net/pipermail/users/2020-April/046659.html
> http://shibboleth.net/pipermail/users/2020-May/046924.html
>
> -peter
> --
> For Consortium Member technical support, see
> https://wiki.shibboleth.net/confluence/x/coFAAg
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20200902/2da07e88/attachment.htm>