My Websphere App needs to configure the "Web container transport chains" in the traditional Admin Console. But when I switch to the Liberty, I can't find it in the AdminCenter. Where can I do it?
I would rethink the settings you're using for WebSphere when using WebSphere Liberty. The configuration in Liberty is entirely in the server.xml. Rarely the bootstrap.properties, usually for things that need to be set before we read the server.xml. I would try instead to simply define the HTTP endpoints you want, along with the deployed application, as seen here. The full httpEndpoint configuration documentation is here.
Related
How can i set a path prefix for scdf UI. I already set the tomcat property (like server.contextPath=/api/) which works for the rest API but the UI is still giving errors.
Info: i have it running in Kubernetes using ingress.
We do not support GUI redirects with a overridden contextPath. The Dashboard is a SPA and this type of interaction requires special handling from the client-side.
Feel free to open an issue and consider also contributing to the project.
I'm using the ActiveMQ plugin for Grails (2.4.x) and it's messing with SSL connections. By messing with SSL connections I mean it's not allowing a client browser to connect to the Grails application using SSL.
Any attempt to connect to the SSL port (no matter what it's set to) for the web application results in ERR_SSL_PROTOCOL_ERROR being reported by the browser.
If I disable the plugin SSL works just fine.
I've reviewed the plugin source code and I don't see anything in there that should be doing this.
I'm at a complete and total loss and it's driving me mad. I'm not sure what other information I can provide to assist others in helping me but I'm hopeful that someone out there can point me to some kind of ActiveMQ setting that I can use to disable this odd behavior.
The included libraries from the plugin are as follows:
activemq-broker-5.10.1.jar
activemq-client-5.10.1.jar
activemq-jms-pool-5.10.1.jar
activemq-openwire-legacy-5.10.1.jar
activemq-pool-5.10.1.jar
activemq-spring-5.10.1.jar
As it turns out this is because Active MQ detects if the "Bouncy Castle" security provider is available on the classpath and will add it into the java.security.Security providers in the second position when it creates the broker.
Unfortunately there isn't an option within Active MQ to disable this feature, and it was discussed briefly in the JIRA and determined this wouldn't ever be an option.
Since this project also uses the crypto:2.0 plugin for Grails it was loading the Bouncy Castle security provider for the JVM. As a standalone this would be fine for Active MQ to do this, but when embedded into Tomcat this was causing issues with SSL. Not sure why exactly the Bouncy Castle provider wasn't handling SSL TLS correctly, but adding the following to BootStrap.groovy removes it from the providers and fixes the issue.
java.security.Security.removeProvider('BC')
In this project we are using ActiveMQ within the virtual machine and have no need for any additional security providers for Active MQ to use for SSL connections since it won't be using them anyway.
I have asp.Net MVC web application deployed on azure. And have some problems with Slow HTTP POST vulnerability. So I want to configure <\limits> to turn on connectionTimeout.
I can`t do this in Web.config (or mb just don`t know right place to write it).
In guides this thing configure on iis, but how to do this in azure?
The setting that you are talking about connectionTimeout needs to be set in the applicationhost.config file. This file is not found as part of your project, but is part of your azure website. If you want to view the configuration settings in this file you can go to the kudo service for your site which can be accessed by following the directions here:
https://github.com/projectkudu/kudu/wiki/Accessing-the-kudu-service
To get to the location of the file go to the cmd console, click on the globe icon and it should be in the the Configure folder. That is how you view the current settings. To actually change the settings you need to create an xdt transform file and drop it into your site root and restart the site. This can be done using ftp (the ftp host url can be found in the azure portal for you site).
You are also going to want to configure your <\webLimits> as well to help prevent a slow post attack.
We had a Windows Service Project hosting two of our WCF services and we could not figure out why the app.config settings on the WCF services were not pulling correctly to our client programs.
It turns out that the app.config for the windows service project takes precedent. When we moved the settings we wanted into the window service's app.config everything worked again.
Hope this saves someone a 4 hour long headache!
You must copy configuration to hosting application. Only configuration from hosting application is applied. Configuration in WCF services is only for testing purpose like WCFTestClient.
If I remember correctly, the reason for this is because ConfigurationManager does not support config files inside dll's.
For IIS6 I can use the IIS helpers in Wix to install a web application like this:
<iis:WebAppPool
Id="AP_MyApp"
Name="My Application Pool"
Identity="networkService" />
<iis:WebApplication
Id="WA_MyApp"
Name="MyApp"
WebAppPool="AP_MyApp">
<iis:WebApplicationExtension
CheckPath="no"
Executable="[NETFRAMEWORK20INSTALLROOTDIR]aspnet_isapi.dll"
Verbs="GET,HEAD,POST"/>
</iis:WebApplication>
Unfortunately, this doesn't work for IIS7. We don't want to use the aspnet_isapi.dll mechanism, and instead want the integrated pipeline to handle the request routing. The app pool created by this script is in Classic mode not Integrated mode so none of the handlers get run correctly.
How can I correctly install an MVC app on IIS 7?
I personally recommend using AppCmd.exe (matthewthurlow's first bullet) because you don't have to count on the legacy management components being installed, or risk modifying the configuration XML manually.
If you are not comfortable with AppCmd, Mike Volodarsky has a great article on Getting Started with AppCmd.exe, and the Microsoft IIS Configuration Reference is excellent, offering UI, Code and AppCmd examples for modifying each of the configuration items (e.g. Application Pools ). The IIS7 Administration Pack also includes a Configuration Editor that allows you to generate AppCmd scripts from any existing configuration.
To integrate AppCmd into WiX, you need to create and schedule two custom actions for each command. There is general information in the WiX v3 manual documenting this procedure, and I've included a concrete example below.
First, you need to set up an immediate action to store the command line in a property:
<CustomAction
Id="CreateAppPool_Cmd"
Property="CreateAppPool"
Execute="immediate"
Value=""[WindowsFolder]system32\inetsrv\APPCMD.EXE" add apppool /name:"[APP_POOL_NAME]"" />
Next you set up a deferred action which references this property:
<CustomAction
Id="CreateAppPool"
BinaryKey="WixCA"
DllEntry="CAQuietExec"
Execute="deferred"
Return="ignore"
Impersonate="no"/>
And finally, you need to schedule these. The immediate action that sets the properties seem to work well after InstallFinalize, and the deferred action works after InstallFiles. I haven't got as far as figuring out rollback actions yet.
MapGuide Open Source does this method extensively; you can see the CA scheduling in our MapGuide.wxs file, and the CA definition in our IIS7.wxs file.
Thanks to #matthewthurlow, I was able to use the XML utils to achieve what I needed to do:
<util:XmlFile
Id="ModifyAppPoolPipelineType"
Action="setValue"
ElementPath="//configuration/system.applicationHost/applicationPools/add[\[]#name='My Application Pool'[\]]/#managedPipelineMode"
File="[WindowsFolder]System32\inetsrv\config\applicationHost.config"
Value="Integrated"/>
The rest of the actions do seem to work fine with IIS 7.
The IIS extensions for WIX don't support IIS7. The IIS team keep rewriting the metabase between versions. There are quite a few things that don't work, the lack of an integrated app pool amongst them.
Until the extensions get rewritten, you're left with three options:
Use build in custom actions to invoke appcmd.exe
Use XmlConfig to update applicationHost.config
Write your own custom actions
I've opted for the xmlconfig option at the moment as you can do this within a component and tie it to a feature.