We have a Live mule server (Community edition ) 3.3.0 running on a Windows 2008 server.
We have several apps running on it.
We tried to hotdeploy a new app in it. It failed saying some port was already in use/bind - this was a JMX port. However we were unable to undeploy it. It didn't create any anchor file as it had failed deployment so we couldn't do the clean undeploy. When we tried to delete the exploded folder it didn't allow as it said the jars in the lib were in use.
We tried to re-deploy the same file with fix again but it had no effect.
Question is irrespective of what caused out application to fail - how can one undeploy or take out a Mule app (failed) completely? It doesn't have anchor file and trying to delete says jar in use. Only way we could do was to stop mule and then delete the folder and restart Mule - totally unacceptable in production environment.
Any clues?
This is a known bug on 3.3.0 that was fixed on 3.3.1.
Related
I need some information of log4j2 for updating our central versions of Mule CE 3.9.0 and Mule CE 3.9.5 (CE=Community Edition).
What is the best way to protect them and does downloading only jar files from Apache site https://dlcdn.apache.org/logging/log4j/2.12.3/ be useful to patch Mule CE 3.9?
Regards
As a summary you only need to find the vulnerable jars in the mule-server and in the mule flows deployed in the apps folder.
A Java project is a set of java class and libraries with complex dependencies relationship, but easy to replace one of them (manually or automated with maven), so no matter how or where log4j is being used, we just need replace the jar file.
mule community server 3.9.0
In this version, with this command find . -type f -iname "*log4j*" we will get the log4j jars:
As we can see, the version prior to the 2.14.x
log4j-jul-2.8.2.jar
log4j-jcl-2.8.2.jar
log4j-slf4j-impl-2.8.2.jar
log4j-core-2.8.2.jar
log4j-api-2.8.2.jar
log4j-1.2-api-2.8.2.jar
But according to the official maven repository, this version is affected too :(
Just the 2.17.0 is safe to use
Source: https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core
If this change breaks your mule, just delete the specific vulnerable class:
zip -q -d
log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
Source: https://www.docker.com/blog/apache-log4j-2-cve-2021-44228/
mule flow or mule app
This is not the server, is the app developed by programmers, packaged as .zip and deployed to the mule apps folder in the server.
In this layer, the app can ignore completely the server configurations and has its own jar versions.
If you don't use maven (rare), you need to search and replace the jar, app by app, similar to the server with find command but in the specific app folder:
/opt/mule_server/apps/my-mule-app
If you use maven, you could find if the jar is used with the pom.xml previewer of Eclipse Ide or with command mvn dependency:tree. Check this:
https://stackoverflow.com/a/68916675/3957754
Remember: If you not use directly this jar, you need to check if mule esb server uses it.
Here some tips from manual to automated pipelines:
mule esb monolithic with manual deployment
In this case you need to fix the server and your apps.
for the server, backup, stop, search the jar on lib folder and replace it with the 2.17 (after vulnerability fix) and start. Test if everything is working
for the mule apps, the process is the same: stop the mule server, go to your mule apps and one by one, search the jar and replace it. Start the mule server and test if everything is working
git repository , maven and one mule app by server
In this case, you don't have a big server with a big mule containing a lot of mule apps/flows. You have one light server for just one mule app.
Just search the dependency in your pom with maven and replace it.
Push your changes and in the next deploy( manual or automated) your mule app will be fixed.
Also note that this approach fix the app, not the server.
git, docker
If you are using docker, the things are easy. Just search the Dockerfile (usually in a git repository). In this file there are a lot of sentences, since the java installation until the star of mule server.
Choose the exact line between the download of mule and the start of server and put a sentence which replace the jar file
Next deploy will pick you new image version and that's all.
automated flow(devops)
Here you are using maven, gi, docker and some ci server. You just need:
update the git repository of your mule app (maven)
update the git repository of your docker image
deploy your fix using the ci server.
With this, you will not need human access to the production servers to fix your java application ( mule)
Developer server version is
mfp -v: 7.1.0.00.20160206-1603
Production server version is
wladm -version 7.1.0.00.20150807-0630
Project is mfp cordova type.
Building for developer server.
App built with Ant works.
App built with Gradle works.
Building for production server.
App built in release/debug with Ant - works fine.
App built in release/debug with Gradle, gets [...android/init] timeout or 500.
Signing is the same.
Configuration is the same.
wlapp is properly deployed to production and developer server.
On device app looks fine. Everything is ok, but cannot connect to WL server.
Looks like something is wrong with app authenticity.
But Ant signed-release works. Gradle signed-release/debug fails to connect.
Same project, same settings. Whats wrong. Have you seen this?
EDIT
Looking at logcat logs, found this error
java.lang.UnsatisfiedLinkError: dalvik.system.PathClassLoader[DexPathList[[zip file "/data/app/.../base.apk"],nativeLibraryDirectories=[/data/app/.../lib/arm, /vendor/lib, /system/lib]]] couldn't find "libauthjni.so"
But when I just change address (wlclient.properties) to local Dev server - everything is ok. No error.
Cordova applications created with the CLI are based on Cordova 3.7.
Cordova 3.7 does not support a Gradle-based project structure.
Every time i try to create a new Worklight server all of my resources get duplicated... and I believe its causing errors when i deploy.
What I have tried to fix this issue so far:
Deleted server, and created a new one. Same result
Deleted my workspace and started from scratch. Same result
Completed removed eclipse from my workstation. Same result
Is there any other explaination for this behavior? I am using a fresh Eclipse Luna SR2 install, with a fresh install of the MFP 7.1 plugin.
This is a known APAR: PI50480 ALL MOBILEFIRST SERVER .WAR FILES IN MOBILEFIRST STUDIO APPEAR TWICE
The development team is working on fixing it. That said, this duplication has no effect on your project. You can ignore it.
We upgraded our AIX Environment from WL 6.1.0 to 6.1.0.1 without stopping the WL Server (ApplicationCenter is not installed in this WAS Profile). We have WAS 8 in Netowrk Deployment Configuration.
Installation Manager installed it successfully, then we reboot the server and we got this trying accessing the console:
Error 500: javax.servlet.ServletException: Worklight Console
initialization failed.Logged Exception:
com.worklight.server.database.api.WorklightDataSourceException:
FWLSE0194E: Worklight server cannot be started because of failure
while getting a connection from data-source bound to resource
reference: jdbc/WorklightDS. Make sure the database is up, the
credentials are correct and the driver is available for the server.
[project buytec_worklight]
I searched the right way to upgrade and I saw that we should have stopped the server than we should follow this procedure:
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.upgrade.doc%2Fdevenv%2Fc_upgrade_to_srvr610_upgrading_wl_console_upgrade_console.html
But at first, with WL 6.1.0 we didn't use the ant-task to deploy the console, we just put the .war found in the Eclipse Studio with the right plugin, so now i cannot manage to understand how to upgrade the console manually.
Have you any suggestions?
I don't know what you mean by "upgrade the console manually". The Worklight Console is part of the .war file you deploy to the application server, but the console doesn't have anything to do with the connection to the database.
If you want to "upgrade the console", you actually mean that you want to update the .war file, so deploy a .war file that was generated using Worklight Studio 6.1.0.1.
You can also follow the manual upgrade instructions for 6.1.0.1: http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr610_addl_info_manual_app_srvr_upgrade.html
Because you didn't properly start the upgrade process, I suggest that you will take the time to review all upgrade topics, from the start: http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/topic/com.ibm.worklight.upgrade.doc/devenv/c_upgrade_to_srvr610_in_production_env.html
In addition, it doesn't matter how you first installed 6.1.0.0, you can still use either Ant or manual upgrading.
I simply re-add the .jar files driver for db2, checking that they are resolved, set again the Data sources JDBC, uploaded a new console.war created with eclipse and it worked!
For some reason our standalone JBoss 7.1.1 undeploys my war file on shutdown/restart.
Deployment happens with maven from a remote machine (jboss-as-maven-plugin).
Stopping happens with local cli 9999 shutdown command.
Any ideas?
I finally got it why this happens. I did not only restart but also replace/update my config file. But in the updated file the deployment part is missing. And then it seams that jboss does not re-deploy the war file.
Kind of a problem that configuration and deployment information are in the same file, there is no separation of concerns here.