SP v3 prerelease (windows)

classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|

SP v3 prerelease (windows)

Alan Buxey
hi,

no panic. just some initial feedback after testing an upgrade from
2.6.1.4 to the 3.0 pre-release
(via running installer (64bit) on a system with working 2.6.x install)


upgrade worked - no outstanding errors noted so far (haven't gone in
deep with IIS yet )


quick thoughts:

would be good if the shib3 read a shibboleth3.xml instead of
shibboleth2.xml if the file was present -
this would enable us to have both 2 and 3 configs present for quick
reversion without needing to
edit the file before degrade

the service is still called Shibboleth 2 Daemon (default) . would be
nice if the upgrade renamed that to
Shibboleth 3 Daemon. (cosmetic yes but annoying)


will check SAML1.1/SHA256 technical things next


alan
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Rod Widdowson
> no panic. just some initial feedback after testing an upgrade from
> 2.6.1.4 to the 3.0 pre-release
> (via running installer (64bit) on a system with working 2.6.x install)

Many thanks for this.
 
> would be good if the shib3 read a shibboleth3.xml instead of
> shibboleth2.xml if the file was present -
> this would enable us to have both 2 and 3 configs present for quick
> reversion without needing to
> edit the file before degrade

We tried that and it wasn't pretty.  I'll let Scott (who suffered the most) explain why.

 > the service is still called Shibboleth 2 Daemon (default) . would be
> nice if the upgrade renamed that to
> Shibboleth 3 Daemon. (cosmetic yes but annoying)

Onto it.

I don't suppose you are using IIS and have had a chance to kick the wheels with the new module?

Thanks again.


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Rod Widdowson
>  > the service is still called Shibboleth 2 Daemon (default) . would be
> > nice if the upgrade renamed that to
> > Shibboleth 3 Daemon. (cosmetic yes but annoying)
>
> Onto it.

Turns out I made this change a couple of days after we did the first beta...

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Cantor, Scott E.
In reply to this post by Alan Buxey
> would be good if the shib3 read a shibboleth3.xml instead of
> shibboleth2.xml if the file was present -

It was a total nightmare of proportions that could only be described as apocalyptic. You can't make RPM work when you change the filename like that, and the pain and work was far beyond any possibly benefit.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Alan Buxey
hmm, okay - its just that we have a pool of servers and it would be
nice if we could keep the same single configuration repository for
deployment
but have a mix of v2 and v3 servers for the upgrade, I'm not talking
about turning shibboleth2.xml into shibboleth3.xml , I'm just meaning
that
shibboleth2.xml is left alone (for those doing whatever upgrades they
are doing....with a shibboleth3.xml.dist provided (with the correct
3.0 stuff
at the top etc) - those doing upgrade process such as myself could
simply copy current shibboleth2.xml to shibboleth3.xml , make required
changes
and be able to use same config directory on shib2 and shib3 SP service
deployments (then , when last v2 SP is switched off, delete
shibboleth2.xml

(I note the v3 IdP also uses shibboleth2.xml - same problems with RPM
etc I guess....perhaps same idea for IdP v4 with shibboleth4.xml ? )


alan
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Alan Buxey
In reply to this post by Rod Widdowson
hi,

> I don't suppose you are using IIS and have had a chance to kick the wheels with the new module?

using IIS yes, havent had the chance to kick the wheels yet though (
as noted in my initial
email "(haven't gone in deep with IIS yet )"

the time spent so far was firing it up after upgrade (noting the small
cosmetic and DevOps streamlining
issue) and looking for all 'deprecated/soon to be removed' etc
messages...a few of those in the
current config, no biggies)

alan
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Cantor, Scott E.
In reply to this post by Alan Buxey
On 6/29/18, 2:26 PM, "dev on behalf of Alan Buxey" <[hidden email] on behalf of [hidden email]> wrote:

> I'm not talking about turning shibboleth2.xml into shibboleth3.xml

You are, you just don't realize it because you haven't tried to make it work in an RPM.

None of this is required anyway, if you want to change the name of the file on a server, you are completely free to do that as documented. The package can't without breaking upgrades. Changing the full software install location is hard, but just altering the default config name is easy and should work as it has before.

>  (I note the v3 IdP also uses shibboleth2.xml - same problems with RPM
> etc I guess....perhaps same idea for IdP v4 with shibboleth4.xml ? )

Not sure what you mean, that's not anything the IdP does.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Doan, Tommy
In reply to this post by Rod Widdowson
The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

A few other comments, and I'm still going through my initial experience with it.

not immediately clear what the installation checkbox "Configure IIS7 modules" is for
 - appears to be for configuring the module to work with IIS
 - assumption is that without being checked, the module is installed but not "enabled" for IIS
 - shouldn't this be enabled by default? that is the case for the ISAPI modules with the v2 installer
if the installer is run again after an existing installation,
 - the Change button does nothing
 - the Repair and Remove buttons do what you'd expect
the installer publisher (signing certificate) is unknown, which is also the case with the v2 installer
 - no functional problem, just the warning

-----Original Message-----
From: dev <[hidden email]> On Behalf Of Rod Widdowson
Sent: Friday, June 29, 2018 10:55 AM
To: 'Shib Dev' <[hidden email]>
Subject: RE: SP v3 prerelease (windows)

>  > the service is still called Shibboleth 2 Daemon (default) . would be
> > nice if the upgrade renamed that to
> > Shibboleth 3 Daemon. (cosmetic yes but annoying)
>
> Onto it.

Turns out I made this change a couple of days after we did the first beta...

--
To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Rod Widdowson
Thanks for this.  It's is immensely useful to get real deployment feedback.

> The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

Confirmed.  This is nasty - A new install works fine, but for historic reasons (which I cannot even remember) we do not touch the
SCM during upgrades.   I have opened SSPCPP-815 to track this.

> not immediately clear what the installation checkbox "Configure IIS7 modules" is for
>  - assumption is that without being checked, the module is installed but not "enabled" for IIS

That’s absolutely correct - you get the DLLs for all versions of all Web servers regardless of what webserver is actually installed

>  - appears to be for configuring the module to work with IIS

Yea, all it does is exactly this:

        appcmd install module /name:ShibNative32 /image:"c:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" /precondition:bitness32
        appcmd install module /name:ShibNative /image:"c:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" /precondition:bitness64

>  - shouldn't this be enabled by default? that is the case for the ISAPI modules with the v2 installer
> if the installer is run again after an existing installation,

You shouldn't be seeing it on an upgrade.  It is just for initial installs.  There is (as always) history there.  In IIS6 days the
IIS integration was distinctly fragile - hence the option to not doing and add it by hand later.  I just carried that forward.  I
can completely see the motivation to do the configure if you have IIS installed (the whole dialog is supressed if it isn't there).
But there is also a case to be made to do zero configuration now that "configure" is two command lines.  After all we do nothing to
configure Apache.

>  - the Change button does nothing
I've made a note in SSPCPP-817 to see if I can suppress it..

> the installer publisher (signing certificate) is unknown, which is also the case with the v2 installer
>  - no functional problem, just the warning

I'm surprised it has an embedded code signature certificate at all actually.  The whole area (& history) of "code signing" certs for
open source is fraught.  I'll observe that Apache's latest procrun executable (used to run Tomcat and the Shib IdP) is no longer
code signed...

Thanks again for the feedback

Rod

--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Doan, Tommy
Sorry I omitted the detail but my testing is being done on a new Server 2016 OS and as the initial IIS and Shib SP installation, not as an upgrade. I had downloaded the SP installer on Friday morning but I see now it's since been updated so I'll use the latest and go through my testing again. More to come later this week.

-----Original Message-----
From: dev <[hidden email]> On Behalf Of Rod Widdowson
Sent: Sunday, July 8, 2018 6:41 AM
To: 'Shib Dev' <[hidden email]>
Subject: RE: SP v3 prerelease (windows)

Thanks for this.  It's is immensely useful to get real deployment feedback.

> The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

Confirmed.  This is nasty - A new install works fine, but for historic reasons (which I cannot even remember) we do not touch the
SCM during upgrades.   I have opened SSPCPP-815 to track this.

> not immediately clear what the installation checkbox "Configure IIS7
> modules" is for
>  - assumption is that without being checked, the module is installed
> but not "enabled" for IIS

That's absolutely correct - you get the DLLs for all versions of all Web servers regardless of what webserver is actually installed

>  - appears to be for configuring the module to work with IIS

Yea, all it does is exactly this:

        appcmd install module /name:ShibNative32 /image:"c:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" /precondition:bitness32
        appcmd install module /name:ShibNative /image:"c:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" /precondition:bitness64

>  - shouldn't this be enabled by default? that is the case for the
> ISAPI modules with the v2 installer if the installer is run again
> after an existing installation,

You shouldn't be seeing it on an upgrade.  It is just for initial installs.  There is (as always) history there.  In IIS6 days the IIS integration was distinctly fragile - hence the option to not doing and add it by hand later.  I just carried that forward.  I can completely see the motivation to do the configure if you have IIS installed (the whole dialog is supressed if it isn't there).
But there is also a case to be made to do zero configuration now that "configure" is two command lines.  After all we do nothing to configure Apache.

>  - the Change button does nothing
I've made a note in SSPCPP-817 to see if I can suppress it..

> the installer publisher (signing certificate) is unknown, which is
> also the case with the v2 installer
>  - no functional problem, just the warning

I'm surprised it has an embedded code signature certificate at all actually.  The whole area (& history) of "code signing" certs for open source is fraught.  I'll observe that Apache's latest procrun executable (used to run Tomcat and the Shib IdP) is no longer code signed...

Thanks again for the feedback

Rod

--
To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Doan, Tommy
Just passing along feedback as I gain some experience with the new SP.

Uninstalling the v3 software, at least by running the installer again and choosing the Remove option, does not remove the iis7_shib.dll modules (ShibNative and ShibNative32). This prevents IIS from starting until the modules are manually removed. I had to remove the DLL from the Modules component at both the server and site level, and also modify applicationHost.config to remove these lines from the globalModules element.

            <add name="ShibNative32" image="C:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" preCondition="bitness32" />
            <add name="ShibNative" image="C:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" preCondition="bitness64" />

-----Original Message-----
From: Doan, Tommy
Sent: Sunday, July 8, 2018 8:20 AM
To: 'Shib Dev' <[hidden email]>
Subject: RE: SP v3 prerelease (windows)

Sorry I omitted the detail but my testing is being done on a new Server 2016 OS and as the initial IIS and Shib SP installation, not as an upgrade. I had downloaded the SP installer on Friday morning but I see now it's since been updated so I'll use the latest and go through my testing again. More to come later this week.

-----Original Message-----
From: dev <[hidden email]> On Behalf Of Rod Widdowson
Sent: Sunday, July 8, 2018 6:41 AM
To: 'Shib Dev' <[hidden email]>
Subject: RE: SP v3 prerelease (windows)

Thanks for this.  It's is immensely useful to get real deployment feedback.

> The 3.0.0.0 win64 installer still names the service "Shibboleth 2 Daemon (Default)".

Confirmed.  This is nasty - A new install works fine, but for historic reasons (which I cannot even remember) we do not touch the
SCM during upgrades.   I have opened SSPCPP-815 to track this.

> not immediately clear what the installation checkbox "Configure IIS7
> modules" is for
>  - assumption is that without being checked, the module is installed
> but not "enabled" for IIS

That's absolutely correct - you get the DLLs for all versions of all Web servers regardless of what webserver is actually installed

>  - appears to be for configuring the module to work with IIS

Yea, all it does is exactly this:

        appcmd install module /name:ShibNative32 /image:"c:\opt\shibboleth-sp\lib\shibboleth\iis7_shib.dll" /precondition:bitness32
        appcmd install module /name:ShibNative /image:"c:\opt\shibboleth-sp\lib64\shibboleth\iis7_shib.dll" /precondition:bitness64

>  - shouldn't this be enabled by default? that is the case for the
> ISAPI modules with the v2 installer if the installer is run again
> after an existing installation,

You shouldn't be seeing it on an upgrade.  It is just for initial installs.  There is (as always) history there.  In IIS6 days the IIS integration was distinctly fragile - hence the option to not doing and add it by hand later.  I just carried that forward.  I can completely see the motivation to do the configure if you have IIS installed (the whole dialog is supressed if it isn't there).
But there is also a case to be made to do zero configuration now that "configure" is two command lines.  After all we do nothing to configure Apache.

>  - the Change button does nothing
I've made a note in SSPCPP-817 to see if I can suppress it..

> the installer publisher (signing certificate) is unknown, which is
> also the case with the v2 installer
>  - no functional problem, just the warning

I'm surprised it has an embedded code signature certificate at all actually.  The whole area (& history) of "code signing" certs for open source is fraught.  I'll observe that Apache's latest procrun executable (used to run Tomcat and the Shib IdP) is no longer code signed...

Thanks again for the feedback

Rod

--
To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Cantor, Scott E.
> Uninstalling the v3 software, at least by running the installer again and choosing the Remove option, does not remove
> the iis7_shib.dll modules (ShibNative and ShibNative32).

I just uninstalled it via Programs -> uninstall, worked fine. Perhaps it's an issue with the uninstall methodology.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Cantor, Scott E.
Same result running Installer -> Remove.

Note that I don't think it would, and I wouldn't want it to, do that step if you didn't auto-configure the module during install, those are intended to be paired. Auto -> Auto, or Manual -> Manual.

-- Scott

On 7/9/18, 7:30 PM, "dev on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

> Uninstalling the v3 software, at least by running the installer again and choosing the Remove option, does not remove
> the iis7_shib.dll modules (ShibNative and ShibNative32).

I just uninstalled it via Programs -> uninstall, worked fine. Perhaps it's an issue with the uninstall methodology.


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Doan, Tommy
Agreed, and I had the "Configure IIS7 modules" checkbox enabled when I originally installed the SP software.

I just went through the Remove procedure again and confirmed the modules are not removed from IIS. I'm using the installer just downloaded today since I notice the file date had changed. To be clear, the DLLs are removed from the file system but not from the IIS configuration and not from C:\Windows\System32\inetsrv\config\applicationHost.config.

-----Original Message-----
From: dev <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, July 9, 2018 6:39 PM
To: Shib Dev <[hidden email]>
Subject: Re: SP v3 prerelease (windows)

Same result running Installer -> Remove.

Note that I don't think it would, and I wouldn't want it to, do that step if you didn't auto-configure the module during install, those are intended to be paired. Auto -> Auto, or Manual -> Manual.

-- Scott

On 7/9/18, 7:30 PM, "dev on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

> Uninstalling the v3 software, at least by running the installer again
> and choosing the Remove option, does not remove the iis7_shib.dll modules (ShibNative and ShibNative32).

I just uninstalled it via Programs -> uninstall, worked fine. Perhaps it's an issue with the uninstall methodology.


--
To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Cantor, Scott E.
On 7/9/18, 7:57 PM, "dev on behalf of Doan, Tommy" <[hidden email] on behalf of [hidden email]> wrote:

> I just went through the Remove procedure again and confirmed the modules are not removed from IIS.

On my test VM they definitely are, so that basically leaves it at "Windows is broken, news at 11."

You should still be able to use the appcmd.exe approach to "unregister" the module, I would think, there shouldn't be any need to manually do it (in the sense of using the GUI). Actually, if it doesn't, that basically *is* the problem, since that's what the installer actually does at uninstall. It can't make that work if the commands just refuse to do what they're supposed to, it doesn't directly touch the config.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Doan, Tommy
Probably functionally minor but environment variable SHIBSP_PREFIX should be set to C:\opt\shibboleth-sp rather than C:/opt/shibboleth-sp.

One other comment. This tripped me up for quite a while until I did a file compare to the dist version of shibboleth2.xml and then noticed the documentation.
https://wiki.shibboleth.net/confluence/display/SP3/FolderMetadataProvider 

        <MetadataProvider type="XML" validate="true" path="idp-metadata.xml"/>

Versus the v2 'file' attribute which is now a breaking configuration that prevents the service from starting or shibd -check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml.

        <MetadataProvider type="XML" file="idp-metadata.xml"/>

-----Original Message-----
From: dev <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, July 9, 2018 7:05 PM
To: Shib Dev <[hidden email]>
Subject: Re: SP v3 prerelease (windows)

On 7/9/18, 7:57 PM, "dev on behalf of Doan, Tommy" <[hidden email] on behalf of [hidden email]> wrote:

> I just went through the Remove procedure again and confirmed the modules are not removed from IIS.

On my test VM they definitely are, so that basically leaves it at "Windows is broken, news at 11."

You should still be able to use the appcmd.exe approach to "unregister" the module, I would think, there shouldn't be any need to manually do it (in the sense of using the GUI). Actually, if it doesn't, that basically *is* the problem, since that's what the installer actually does at uninstall. It can't make that work if the commands just refuse to do what they're supposed to, it doesn't directly touch the config.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Cantor, Scott E.
On 7/9/18, 8:42 PM, "dev on behalf of Doan, Tommy" <[hidden email] on behalf of [hidden email]> wrote:

> Probably functionally minor but environment variable SHIBSP_PREFIX should be set to C:\opt\shibboleth-sp rather than > C:/opt/shibboleth-sp.

The code all depends on and assumes portable paths. Forward slash works in the parser, so that's what it uses. Sometimes backslash will work and sometimes it does not, and it should never be used.
 
> Versus the v2 'file' attribute which is now a breaking configuration that prevents the service from starting or shibd -
> check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml.

"file" works in a legacy config and it warns. It will not work in a V3 config. The package doesn't supply any configuration of that plugin and I believe all the examples are fixed to use the proper syntax.

But I don't think there are any examples shipped before or now of the Folder plugin (it shouldn't be used anymore anyway but that's beside the point).

If you're seeing broken example it's probably a bug I already know about and only affects upgrades, it's not going to hold the release. It's not getting all the files in dist/ updated correctly. But I don't know where this one would be coming from.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: SP v3 prerelease (windows)

Cantor, Scott E.
On 7/9/18, 8:52 PM, "dev on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

> > Versus the v2 'file' attribute which is now a breaking configuration that prevents the service from starting or shibd -
> > check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml.

I misread you, the Folder reference confused me.

If you use this:

        <MetadataProvider type="XML" file="idp-metadata.xml"/>

That works fine in an upgraded system, and there will a DEPRECATED warning in the log telling you exactly what it found and what to do with it. And if you bump the namespace without fixing it first, yes, it breaks (and it should say why there also). If you see any DEPRECATEDs in the log, you are going to break it if you just change the namespace, with the exception of the warnings that are actually noting it's using the old namespace.

The deprecation warnings are, by and large, extremely specific.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Doan, Tommy
I'm testing with a fresh v3 installation, but my shibboleth2.xml was largely built from an existing v2 file where the file attribute of the MetadataProvider element is used, so this isn't coming from any documentation I've seen - at least not for many years. By the way, nothing is logged in any SP log when this causes a crash, but the following Event ID 1000 does appear in the Event Viewer's Application log although not very helpful.

Faulting application name: shibd.exe, version: 3.0.0.0, time stamp: 0x5b400ce7
Faulting module name: xmltooling3_0.dll, version: 3.0.0.0, time stamp: 0x5b4007d4
Exception code: 0xc0000005
Fault offset: 0x00042667
Faulting process id: 0x1010
Faulting application start time: 0x01d417e3efc6f310
Faulting application path: C:\opt\shibboleth-sp\sbin\shibd.exe
Faulting module path: C:\Program Files (x86)\Shibboleth\SP\lib\xmltooling3_0.dll
Report Id: c201d960-e372-45c8-b07d-8b64c3333f0b
Faulting package full name:
Faulting package-relative application ID:

-----Original Message-----
From: dev <[hidden email]> On Behalf Of Cantor, Scott
Sent: Monday, July 9, 2018 7:58 PM
To: Shib Dev <[hidden email]>
Subject: Re: SP v3 prerelease (windows)

On 7/9/18, 8:52 PM, "dev on behalf of Cantor, Scott" <[hidden email] on behalf of [hidden email]> wrote:

> > Versus the v2 'file' attribute which is now a breaking configuration
> > that prevents the service from starting or shibd - check from running. It would be helpful if possible for an error to be returned at least pointing to shibboleth2.xml.

I misread you, the Folder reference confused me.

If you use this:

        <MetadataProvider type="XML" file="idp-metadata.xml"/>

That works fine in an upgraded system, and there will a DEPRECATED warning in the log telling you exactly what it found and what to do with it. And if you bump the namespace without fixing it first, yes, it breaks (and it should say why there also). If you see any DEPRECATEDs in the log, you are going to break it if you just change the namespace, with the exception of the warnings that are actually noting it's using the old namespace.

The deprecation warnings are, by and large, extremely specific.

-- Scott


--
To unsubscribe from this list send an email to [hidden email]
--
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: SP v3 prerelease (windows)

Cantor, Scott E.
> I'm testing with a fresh v3 installation, but my shibboleth2.xml was largely
> built from an existing v2 file where the file attribute of the MetadataProvider
> element is used, so this isn't coming from any documentation I've seen - at
> least not for many years. By the way, nothing is logged in any SP log when
> this causes a crash, but the following Event ID 1000 does appear in the Event
> Viewer's Application log although not very helpful.

You don't have to file a bug if you can't for some reason, but I can't research something without the configuration to reproduce it.

-- Scott

--
To unsubscribe from this list send an email to [hidden email]
12