Change host from 127.0.0.1 to my ip JBoss EAP - server

I want to change the url to my web-app, i tries to change the interfaces in standalone.xml, but the app still running at 127.0.0.1:port.
my interfaces from standalone.xml:
<interfaces>
<interface name="management">
<inet-address value="${jboss.bind.address.management:192.168.24.216}"/>
</interface>
<interface name="public">
<inet-address value="${jboss.bind.address:192.168.24.216}"/>
</interface>
<interface name="unsecure">
<inet-address value="${jboss.bind.address.unsecure:192.168.24.216}"/>
</interface>
</interfaces>
What file I need to modify? Is JBoss EAP 6.4

Your application will still run on the local machine but you should be able to access it via your IP if you correctly port forward your router. This video explains how portforwarding works.

Related

Why postgresql#11 service failed instantly after i installed with brew on macos?

I've encountered problem about brew services on postgresql#11 right now. After i reinstalled (from this blog) postgresql#11 it instantly gives an error on brew services. Then i ran this brew services restart -vvv postgresql#11 it returns this result:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>KeepAlive</key>
<true/>
<key>Label</key>
<string>homebrew.mxcl.postgresql#11</string>
<key>ProgramArguments</key>
<array>
<string>~/.homebrew/opt/postgresql#11/bin/postgres</string>
<string>-D</string>
<string>~/.homebrew/var/postgresql#11</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>StandardErrorPath</key>
<string>~/.homebrew/var/log/postgresql#11.log</string>
<key>StandardOutPath</key>
<string>~/.homebrew/var/log/postgresql#11.log</string>
<key>WorkingDirectory</key>
<string>~/.homebrew</string>
</dict>
</plist>
When i check the ~/.homebrew/var/log/postgresql#11.log file, it is empty. Also i check permissions on that file but it is ok(r,w). Still getting this error without any explanation(empty logs). 2 days ago it was working but somehow i broke it. Also i checked postmaster.pid but the file is not exist on my machine, i searched like this: find . -name "postmaster.pid"
Additionally, after i reinstalled postgresql#11 in my postgresql#11 directory (~/.homebrew/var/postgresql#11) is all empty.
Lastly, in my directory -> ~/.homebrew/Cellar/postgresql#11/11.13/bin there is postmaster file but it is not postmaster.pid file i dont know what is it for, but when i do ls -al it shows like this -> postmaster -> postgres
My machine is macOS Big Sur 11.5.2 on m1 chip macos. Hopefully someone gives me an idea about it.
What i realize right now is i have problem with installation as well.
brew postinstall postgresql#11 as a result ->
Last 15 lines from ~/Library/Logs/Homebrew/postgresql#11/post_install.01.initdb:
2021-08-23 08:27:42 +0300
~/.homebrew/Cellar/postgresql#11/11.13/bin/initdb
--locale=C
-E
UTF-8
~.homebrew/var/postgresql#11
no data was returned by command ""~/.homebrew/Cellar/postgresql#11/11.13/bin/postgres" -V"
The program "postgres" is needed by initdb but was not found in the
same directory as "~/.homebrew/Cellar/postgresql#11/11.13/bin/initdb".
Check your installation.
Warning: The post-install step did not complete successfully
You can try again using:
brew postinstall postgresql#11
However what i see is initdb and postgres in the same bin folder :/
Thanks,
Homebrew on M1 should be installed into /opt/homebrew. But from your output, ~/.homebrew but not /opt/homebrew is used as $HOMEBREW_PREFIX. What happened to your installation?
Homebrew doesn't support to be installed into arbitrary directory. Don't export $HOMEBREW_PREFIX to change it.
Quote from Homebrew FAQ
Why should I install Homebrew in the default location?
Homebrew’s pre-built binary packages (known as bottles) of many packages can only be used if you install in the default installation prefix, otherwise they have to be built from source. Building from source takes a long time, is prone to fail, and is not supported. Do yourself a favour and install to the default prefix so that you can use our pre-built binary packages. The default prefix is /usr/local for macOS on Intel, /opt/homebrew for macOS on Apple Silicon/ARM, and /home/linuxbrew/.linuxbrew for Linux. Pick another prefix at your peril!

Error: Unable to get available storage types [Eclipse Che]

I am trying to install Eclipse Che version 7.29.1 in an air gapped environment and have run into an issue. We are using Helm, Chectl, and Kubectl on a Linux EC2 instance that’s connected to a Kubernetes cluster in AWS.
I have followed this documentation to set it up in a multiuser environment.
Once we figured out how to install in the air gapped environment, the installation went smoothly with no errors.
Here is the issue I am hitting:
Screenshot of Eclipse Che Error Page
Here is our ingress file that is used in conjunction with the one in the docs above:
Screenshot of Ingress File
Here is also our requirements.yaml which helm uses to install. Due to an air-gapped deployment, the file property is pointing to “custom-charts” so we can reference these images from our internal image repo:
Screenshot of our air-gapped Dependencies
Here is the version of the installed software tools:
Helm:
version.BuildInfo{Version:"v3.2.1", GitCommit:"fe51cd1e31e6a202cba7dead9552a6d418ded79a", GitTreeState:"clean", GoVersion:"go1.13.10"}
Chectl:
chectl/7.30.1 linux-x64 node-v12.22.1
Kubectl:
Client Version: version.Info{Major:"1", Minor:"17+", GitVersion:"v1.17.9-eks-4c6976", GitCommit:"4c6976793196d70bc5cd29d56ce5440c9473648e", GitTreeState:"clean", BuildDate:"2020-07-17T19:00:19Z", GoVersion:"go1.13.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"18+", GitVersion:"v1.18.16-eks-7737de", GitCommit:"7737de131e58a68dda49cdd0ad821b4cb3665ae8", GitTreeState:"clean", BuildDate:"2021-03-10T21:33:25Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"}
Here is the install command we are using:
chectl server:deploy --installer=helm --platform=k8s --domain=che.domain.com --multiuser
There is not too much information online about this issue. I have found these:
https://github.com/eclipse/che/issues/19465
And
https://github.com/eclipse/che/issues/19611 which has been closed and patched in the 7.29.0 version, however we are still hitting the issue.

How to install mysqlclient in SLES 12?

I tried installing libmysqlclient18 package but when I do mysql -u root -p
I get If 'mysql' is not a typo you can use command-not-found to lookup the package that contains it, like this: cnf mysql
I am running MySQL server in a docker container to which I want to connect using a MySQL-client from my local machine
Please note that I just want to install mysql-client and not the mysql-server
Try using sudo yum install mysql-community-server-client
The libmysqlclient18 package is a package of some shared libraries used by most mysql packages, but not the actual client.
SLES 12 SP5 using zypper:
zypper install mysql-devel
For SLES 12 SP 5 with the SDK repo installed, you can get the MySQL client with zypper install mysql-client.

how to specify IEDriverServer and geckoDriver in conf.js

As I know, with latest protractor, we can specify chromeDriver and seleniumServerJar in conf.js. So can we specify IEDriverServer and geckoDriver in conf.js as well? If yes, how to config them?

Dependencies error while installing packages with NuGet

I'm trying to install the following packages with NuGet on Visual Studio 2010
TweetSharp version 2.3.1 (which requires Newtonsoft.Json version 5.0.6)
SharpMap version 1.1.0 (which requires Newtonsoft.Json version 4.5.11)
using the following simple NuGet commands:
PM> Install-Package TweetSharp
PM> Install-Package SharpMap
however I'm getting the following dependencies error after installing the second package:
Install failed. Rolling back...
Install-Package : Updating 'Newtonsoft.Json 5.0.6' to 'Newtonsoft.Json 4.5.11' failed. Unable to find a version of 'TweetSharp' that is compatible with 'Newtonsoft.Json 4.5.11'.
At line:1 char:16
+ Install-Package <<<< SharpMap
+ CategoryInfo : NotSpecified: (:) [Install-Package], InvalidOperationException
+ FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PowerShell.Commands.InstallPackageCommand
is there anyway to fix this issue? thanks in advance.
The problem is that SharpMap has defined the dependency to be exactly
NewtonSoft.Json = 4.5.11
Not greater than or equal, but exactly equal. The best way forward is to contact the owners of the package and ask them to loosen the requirements. It's not very useful like it is, for exactly the reason demonstrated in this question.
However, you can attempt to use the -IgnoreDependencies switch:
> Install-Package SharpMap -IgnoreDependencies
This installs only SharpMap, so you'll need to explicitly install all the other dependencies (except NewtonSoft.Json) afterwards:
> Install-Package BruTile -Version 0.7.4.4
> Install-Package Common.Logging -Version 2.0.0
> Install-Package GeoAPI -Version 1.7.2
> Install-Package NetTopologySuite -Version 1.13.2
> Install-Package NetTopologySuite.IO -Version 1.13.2
> Install-Package ProjNET4GeoAPI -Version 1.3.0.3
However, SharpMap is still going to look for NewtonSoft.Json 4.5.11, so you'll need to add an assembly binding redirect in your application configuration file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json"
publicKeyToken="30ad4fe6b2a6aeed"
culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.0.6.0"
newVersion="5.0.6.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
This may work, but I haven't tried, because in the end, it'll depend on how you want to use these two libraries together.
The shift in major versions of Json.NET indicates that there are breaking changes between 4.x and 5.0, so if SharpMap relies on some of the features of Json.NET 4.5.11 that are affected by the breaking changes, it's not going to work.
However, in my experience, using newer versions of Json.NET with libraries compiled against older versions tend to work fine, so it's worth a shot.