Sure, Cameron, that's a good question, and there's more detail than I shared there. The issue of whether one NEEDS to rebuild the web server connectors on each CF10 update is a subtle one. I hope some of you (interested in CF10 updating) will follow along here and share your thoughts, as I think it's an important point that is not well-understood by most, I sense.
As you may know, some of the CF10 updates DO require a rebuild of the connectors, while others do not. (Even more subtle is that for some of the updates it would suffice if one only used the -upgrade argument from the command-line wsconfig tool, which is faster, while other of the updates do require a full remove/re-add of the connector(s), whether using the command-line or GUI wsconfig tool.) To your point, Cameron, I don't think the latest couple have required any tweak of the web server config, but some earlier ones did. And my point below was focused on that: for someone who is "migrating to 10" (Bettina's topic), who therefore doesn't have CF10 installed at all, they need to know that if they install it, they then have to do the "mandatory" update first, and then apply the latest update (8, for now, as they are said to be cumulative). It's because those earlier ones would be included in that, that one would need to do the rebuild of the web server connectors as a last step. Make sense now? In fact, some may notice that the hotfix notices have recently just said on each of update that one should redo the connectors. That's kind of a "punt", since as you note, it's not really required for each update. My sense is that they only have space for (or only want to write) a few sentences there, so they are not explaining all these details (that it's technically only needed depending on whether you're including one of the earlier updates that DID require it). For those really interested, I'll add that I think there are pros and cons to this blanket assertion they now make in each update to rebuild the connectors. On the one hand, an argument could be made that it's better that they DO say to rebuild it with each, because otherwise someone who DID do a later one which included those earlier ones (that did require a rebuild), but who DID NOT do that rebuild, might then have problems caused simply by that failure to rebuild. (I've seen it happen a LOT! And often people are moaning about CF10 sucking when it's this very issue. Or they thought did the rebuild, but it didn't really happen for some reason.) On the other hand, there's a potential negative implication to "just having everyone do the rebuild on each CF10 update". As you may already have in mind, Cam, it takes time. More specifically, though, the rebuild causes CF to remove and then add back the CFIDE virtual directory (which CF10 now always adds) in the site(s) that were connected to CF with that connector. What's so wrong with that, some may ask? Well, two things. First, if someone had applied the recently popularized security tweaks to secure (in the web server) the subdirectories of that CFIDE folder (like adminapi, administrator, and componentutils), such as adding IP and domain restrictions or requiring additional web server authentication, those tweaks are lost on the rebuild (since the tweaks are at the folder level, and lost when the CFIDE virtual directory is removed and added back by CF). (Fortunately, for those on IIS 7+, using the request filtering approach to block access to those dirs, those settings are NOT stored at the folder level but rather at the server and site levels.) A second problem (with "just rebuilding the connectors after each update") is that if one chooses to connect CF to "all sites" in the web server, then CF will add back a CFIDE folder to all sites--whether they are ones where a CFIDE was desired or not. Some folks have specifically removed the CFIDE from sites that they feel don't need it (though hopefully they are not assuming it's needed only for the CF Admin, as the CFIDE/scripts directory is also used by HTML code from many CFML tags!) Anyway, if someone DID intend that a given site would not have a CFIDE, so they removed it, and they rebuild the connector for "all sites", that will then add the CFIDE BACK to that and all the other sites. And now the vulnerability caused by those admin dirs. being publicly accessible would be opened up again, if they were relying on folder-level protections that would now need to be added back. (Again, someone using IIS request filtering WOULD be protected in this case. And perhaps Apache also offers an approach that would not be affected by a connector rebuild.) Anyway, I've been meaning to blog on this, and writing this here has sparked me to want to proceed to do that, perhaps even today. So I'll really look forward to any feedback anyone has about the above. /charlie From: [email protected] [mailto:[email protected]] On Behalf Of Cameron Childress Sent: Monday, March 04, 2013 3:07 PM To: [email protected] Subject: Re: [ACFUG Discuss] CF10 Migration Questions On Mon, Mar 4, 2013 at 12:05 PM, Charlie Arehart <[email protected]> wrote: Besides how it works, you could clarify how one MUST apply them even with a download of CF10 made today (it's not "updated" out of the box), and how one must apply the "mandatory" update first, and how/when one must rebuild the web server connectors after applying the, etc. Out of curiosity what happens if you don't rebuild the connectors after the update? I've recently applied the update to a couple of machines and forgot to rebuild them. Everything seems to still be working. Is it a security thing? Something else not obvious? -Cameron -- Cameron Childress -- p: 678.637.5072 im: cameroncf facebook <http://www.facebook.com/cameroncf> | twitter <http://twitter.com/cameronc> | google+ <https://profiles.google.com/u/0/117829379451708140985> ------------------------------------------------------------- To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -------------------------------------------------------------
