Thanks to #nmittler on gRPC + SSL = UnsatisfiedLinkError I've got gRPC + SSL working on my Windows PC and on the target Linux platform.
But only when I specify a <classifier> for the io.netty/netty-tcnative-boringssl-static/1.1.33.Fork17 dependency. That can be:
hard-coded (e.g. to windows-x86_64)
injected using os-maven-plugin and ${os.detected.classifier}
But that means I can only run on:
Windows (or whichever platform I hard-code)
the platform I used to compile
But what I'd really like to be able to do is compile on Windows but run on Linux. So, in theory, I can just leave off the <classifier> to bring in the uber-jar (as specified in the docs).
But this doesn't work: when I step through io.netty.util.internal.NativeLibraryLoader.load() I find a call to System.mapLibraryName().
On Windows this correctly returns netty-tcnative.dll.
But on Linux (RHEL 7) it returns libnetty-tcnative.so ... which isn't in the uber-jar (jar tf netty-tcnative-boringssl-static-1.1.33.Fork17.jar returns, among others, META-INF/native/libnetty-tcnative-linux-x86_64.so).
Looking at the classified linux version of the jar I can see it contains META-INF/native/libnetty-tcnative.so ... which implies either the uber jar needs to be built differently (to rename libnetty-tcnative-linux-x86_64.so to libnetty-tcnative.so) or NativeLibraryLoader somewhere needs to take account of the different naming...
Am I on the right track? Can someone help fix this?
You're right, the uber jar on Maven Central does not contain the shared libraries. It's not yet clear whether the issue is building or deploying the jar. I've raised https://github.com/netty/netty-tcnative/issues/145 to track the fix.
Upgrading to io.grpc/grpc-all/0.14.0 (from 0.13.2) cured my problem because it brings in a newer version of io.netty/netty-handler (4.1.0.CR7 vs. 4.1.0.CR3).
Related
ALL,
Does anyone succeeds building a client to libmysqlclient on Windows?
Following this instructions I can build the library itself
But then trying to follow mySQL documentaton which reads
To specify header and library file locations, use the facilities provided by your development environment.
With the old mySQL-Connector-C I was able to download just the code for the connector build it and then it had only 1 mysql.h
With the new library (8.0) I have t get the whole package, and there fore it will have multiple copies of mysql.h (yes, I did check by dong search of the file from Windows Explorer and Terminal/Bash).
In terms of library - it is easy as it will be hopefully just one and I can sue -L option for the linker.
But how do I get the proper include folder?
TIA!!
BTW, the tag here needs t be changed - it is not called connector-c anymore
I work in a lab and use a number of Windows VMs to run analysis software. I manage these VMs and am being asked to fix the log4j vulnerability. However, while I have some experience in research computing, I'm really lost as to exactly what I need to do.
I know I need to update to log4j 2.16.0. For next steps, I received instructions from our IT to "make sure that both of the patched API and Core jars are listed in your application’s classpath, which can be done from the command line or by using a manifest file." Unfortunately I don't know what that means.
What are the exact steps I should take to fix the log4j vulnerability on a Windows machine (Windows Server 2019 Datacentre)?
Java applications typically use JAR files that ar zip files with classes. The Log4J.jar file has to be updated. Java applications load these classes at startup, by loading all jar files and classfiles that are specified in the classpath. From the command line that may look like this
Java -cp log4j.jar;myapp.jar my.app.HelloWorld
Its enough to replace the jar file with a new version and restart the application. How the startup looks like for you and where the jar files are located can wildly vary and is impossible to guess without more information
R Greg Stacey
https://github.com/lunasec-io/lunasec/releases/
Apex One indicates a ramsomware
I'm trying to compile Snap Framework for Haskell on my ubuntu vps with VERY limited ram (220mb) and I keep getting errors about running out of memory when using "cabal install snap". I have tried to increase the swap size but because it is a OpenVZ box there is essentially no swap that exists.
My question is then is there some way I can use an external machine to compile all the files and then have them transfer to the correct locations on the VPS as if I had compiled it locally there?
Or if anyone else has any other suggestions on how I might be able to get this to work please let me know.
As Thomas M. DuBuisson stated you just need to compile the entire project into the final binary and copy that and all the project files (html, js, etc.) over to the server. Because the entire project is compiled and includes a webserver those are the only files you need.
So to reiterate the steps.
Get a different machine with the same operating system that can compile the framework. In my case I had a local virtual machine do it.
Compile the entire Snap project using that machine.
Copy the compiled project (binary, and web files) to the other machine (that can't compile).
Run the binary. It includes a server so there should not be any other dependencies. Unless your project utilizes dynamic libraries. In that case copy those over as well.
This works because the actual Snap Server is included with the Snap Framework application when you compile it. The answer is actually much simpler then I thought, and I was just overcomplicating it.
I am facing a strange problem, maybe somebody can point me to right direction.
I have an application that uses a shared library that I built back in the day, shared library is stored under /usr/lib/ folder. My application binary used to work OK with this set up. Yesterday I tried to install ORACLE-XE to my linux distro. Ran some scripts that set some environment variables. My installation failed and I had to uninstall ORACLE-XE.
When I came back to work today, I tried to run my binary just like I used to, but I've seen some errors about undefined symbol. Symbol name was related to the shared library that I used seamlessly for months. I have the same setup in other machines, I confirmed that application is still working there, so I copied application binary and shared library from other computers to the computer that I am working on, still no luck. It seemed to me that like shared library is not being loaded at all, I tried deleting the shared library and running the application one more time, I received the same error, right around the same time.
I think the oracle scripts might have mingled some of the environment variables, therefore shared library can not be loaded. I am not sure what to check next though, any suggestion would be appreciated.
ldd application-name helped me to identify where the shared library is being read from, it appears that there was another version of shared libary under /usr/local/lib, which was causing the issue.
How should I package and ship my groovy scripts without assuming groovy to be installed (and on PATH) on client machine? However, JDK/JRE will be available on all client machines.
What I'm currently doing is to groovy-compile & bundle related scripts in a jar with groovy-all-xxx.jar included in the lib (Netbeans does this automatically). But the problem with this approach is - with every independent small script (project), I have to bundle the huge groovy-all jar creating a big binary.
Just wanted to know if there is any better way of doing this.
You might be able to use the extension mechanism for this - that way each client machine would have to download groovy-all-xxx.jar just once.