boot microservice not accessible due to laptop security - spring-boot

I crafted a simple Java8/Eclipse/Maven/spring boot microservice on my own personal laptop ie have admin privileges.
I start it with java -jar myService.jar from within a CommandPrompt pane.
I can then access it from my browser at http://localhost:808/myService and receive a ping message as expected.
So far so good.
I've entered this service onto a laptop where I'm just a user - no admin privileges.
It compiles w/o errors. I start it with java -jar myService.jar from within a CommandPrompt pane. But from the browser on this machine I get the default whitelabel error page.
I'm thinking this must be some security issue on the 2nd laptop. How can I prove/disprove this assertion? If proven, must I execute temporarily assume Admin rights and launch this jar-file as a service?
-update-
upon closer examination of the startup screens on personal laptop I see mappings occuring...
2022-04-29 00:07:51 INFO [o.a.c.c.C.[.[.[/]-log] - Initializing Spring embedded WebApplicationContext
2022-04-29 00:07:51 INFO [o.s.w.c.ContextLoader-prepareWebApplicationContext] - Root WebApplicationContext: initialization completed in 2242 ms
2022-04-29 00:07:51 INFO [o.s.b.w.s.ServletRegistrationBean-addRegistration] - Servlet dispatcherServlet mapped to [/]
2022-04-29 00:07:51 INFO [o.s.b.w.s.FilterRegistrationBean-configure] - Mapping filter: 'characterEncodingFilter' to: [/*]
2022-04-29 00:07:51 INFO [o.s.b.w.s.FilterRegistrationBean-configure] - Mapping filter: 'hiddenHttpMethodFilter' to: [/*]
2022-04-29 00:07:51 INFO [o.s.b.w.s.FilterRegistrationBean-configure] - Mapping filter: 'httpPutFormContentFilter' to: [/*]
2022-04-29 00:07:51 INFO [o.s.b.w.s.FilterRegistrationBean-configure] - Mapping filter: 'requestContextFilter' to: [/*]
2022-04-29 00:07:54 INFO [o.s.w.s.m.m.a.RequestMappingHandlerMapping-register] - Mapped "{[/SimpleSpringBootExample/TOD],methods=[GET],produces=[application/json]}" onto public org.springframework.http.ResponseEntity com.mybiz.application.controller.BaseController.indexHandlerF(javax.servlet.http.HttpServletRequest)
2022-04-29 00:07:54 INFO [o.s.w.s.m.m.a.RequestMappingHandlerMapping-register] - Mapped "{[/SimpleSpringBootExample/hello],methods=[GET]}" onto public org.springframework.http.ResponseEntity com.mybiz.application.controller.BaseController.indexHandlerB(javax.servlet.http.HttpServletRequest)
whereas on the other laptop no mapping messages are seen. That'd explain the whitelabel error page - no mapping is occuring. But why?
TIA,
Still-learning Steve

Hmm I would guess that, if it is a privilege issue, it wouldn't render the whitelabel error page, as this is the default page for telling you that the resource / url you try to access was not found. Do you maybe have docker container's running on the port you're trying to access? Had this issue once, as it could happened that a docker container runs on 8080 and your spring application too without the os complaining about an existing port binding

Related

Tomcat IOException: Duplicate accept detected. This is a known OS bug. Please consider reporting that you are affected:

I just migrated to a new spring boot version lately, namely v2.6.2 and now I find the following exception of some of the services logs.
23:27:45.148 [main] INFO o.s.b.w.e.tomcat.TomcatWebServer - Tomcat started on port(s): 8080 (https) with context path ''
23:27:47.046 [main] INFO o.a.c.i.engine.AbstractCamelContext - Routes startup (total:1 started:1)
23:27:47.048 [main] INFO o.a.c.i.engine.AbstractCamelContext - Started route1 (jms://queue:inp.contentextractor.entry)
23:27:47.049 [main] INFO o.a.c.i.engine.AbstractCamelContext - Apache Camel 3.14.0 (camel-1) started in 2s228ms (build:622ms init:1s32ms start:574ms)
23:27:47.061 [main] INFO eu.hermes.esb.cloud.Application - Started Application in 25.305 seconds (JVM running for 27.737)
23:28:20.356 [https-jsse-nio-8080-exec-4] INFO o.a.c.c.C.[Tomcat].[localhost].[/] - Initializing Spring DispatcherServlet 'dispatcherServlet'
23:28:20.357 [https-jsse-nio-8080-exec-4] INFO o.s.web.servlet.DispatcherServlet - Initializing Servlet 'dispatcherServlet'
23:28:20.359 [https-jsse-nio-8080-exec-4] INFO o.s.web.servlet.DispatcherServlet - Completed initialization in 2 ms
00:05:19.986 [https-jsse-nio-8080-Acceptor] ERROR org.apache.tomcat.util.net.Acceptor - Socket accept failed
java.io.IOException: Duplicate accept detected. This is a known OS bug. Please consider reporting that you are affected: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1924298
at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:545)
at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:78)
at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:129)
at java.base/java.lang.Thread.run(Thread.java:834)
05:20:49.981 [https-jsse-nio-8080-Acceptor] ERROR org.apache.tomcat.util.net.Acceptor - Socket accept failed
java.io.IOException: Duplicate accept detected. This is a known OS bug. Please consider reporting that you are affected: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1924298
at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:545)
at org.apache.tomcat.util.net.NioEndpoint.serverSocketAccept(NioEndpoint.java:78)
at org.apache.tomcat.util.net.Acceptor.run(Acceptor.java:129)
at java.base/java.lang.Thread.run(Thread.java:834)
What does it mean and how harmful is it ?
Following the link provided in the bug (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1924298), and looking into comments made by community members, it seems that there is something in tomcat usage that uncovered a hidden issue in linux kernal 5.10-rc4 and was most likely fixed in 5.10-rc6.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1924298/comments/15
This issue was reported across centOS, amazon linux, Arch linux and even Window 2019 - when using a lower linux kernel than 5.10.
The conclusion from this discussion seems to be the suggestion to update the OS itself to a stable version that uses linux kernel >= 5.10

ContextLoader - Root WebApplicationContext initialized 3 times on ubuntu tomcat

Dears,
I have a jersey - spring api deployed on apache tomcat 9.0.46. (Jersey to handle restful services JAX-RS and Spring to handle all my beans{controllers, DAO, SessionFactory, JPA etc...}).
Everything works fine on tomcat 9 on windows...
When deploying the exact same war in ubuntu tomcat 9.0.46, the ContextLoader is getting triggered 3 times and I have all my singletons instantiated 3 times. I'm deploying the api on tomcat ports 80 and 443 (https - godady certificate).
once I start tomcat the war is deployed and ports 80 and 443 get started (netstat -tulnp | grep java) and I see in log all singletons instantiated. (pool-2) Applicationcontext class my custom spring #Configuration class and it is getting triggered and DB is accessed without any issues
2021-06-09 14:41:52,128 1104 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 905 ms
2021-06-09 14:41:53,124 2100 [pool-2-thread-1] INFO skd.app.core.ApplicationContext - TASK::cleanExpiredStatuses
then the server takes few minutes (around 10 minutes 14:41 above then 14:51 below) and when port 8005 is started I see again the ContextLoader is triggered again 2 times.
09-Jun-2021 14:51:36.196 WARNING [main] org.apache.catalina.util.SessionIdGeneratorBase.createSecureRandom Creation of SecureRandom instance for session ID generation using [SHA1PRNG] took [584,064] milliseconds.
09-Jun-2021 14:51:36.592 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:37.042 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [588,185] ms
2021-06-09 14:51:39,388 696 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 581 ms
09-Jun-2021 14:51:39.632 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:40.013 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deploying web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war]
and again for the 3rd time:
2021-06-09 14:51:41,989 744 [main] INFO o.s.web.context.ContextLoader - Root WebApplicationContext initialized in 605 ms
09-Jun-2021 14:51:42.232 INFO [main] org.glassfish.jersey.server.ApplicationHandler.initialize Initiating Jersey application, version Jersey: 2.6 2014-02-18 21:52:53...
09-Jun-2021 14:51:42.602 INFO [main] org.apache.catalina.startup.HostConfig.deployWAR Deployment of web application archive [/opt/apache-tomcat-9.0.46/webapps/skd-service.war] has finished in [2,590] ms
Everything is working fine in windows, only when deploying to ubuntu tomcat, I'm getting this.
Does anyone have a clue why this difference in tomcat behaviour between windows and ubuntu for the same exact WAR file?
I have managed to figure out the problem. The issue was related to tomcat configuration in /conf/server.xml. Multiple Hosts will trigger the context loader to be triggered for each. I was keeping the default appBase to webapps for all host thus triggering the ContextLoader of each my war for each host. Another reason the ContextLoader will triggered multiple times as well is defining the option inside unless you need to load something external to your war.
I recommend reading specs:
https://tomcat.apache.org/tomcat-4.1-doc/config/host.html

Grails 4 - Google Cloud Platform deployment keeps restarting

My Grails 4 application, deployed to GCP appears to be trying to start up after being deployed but never comes up properly. Application requests return a 500 response. There are no errors or clues with DEBUG log level output at the root level.
The same application runs fine locally in development mode.
The production configuration is as per the Grails 3 deployment (to GCP) guide except for the adjustments that were necessary to make it work for Grails 4/Java 11.
Most of the bootstrapping appears to carry out as expected;
Spring Security configures successfully
Spring Security REST configures successfully
Spring beans are registered
Connects to Cloud SQL instance
Database schema is created (by Liquibase)
Plugins are loaded successfully
Then it gets to the following familiar lines of output logging;
INFO --- [main] o.s.b.w.embedded.tomcat.TomcatWebServer : Tomcat initialized with port(s): 8080 (http)
INFO --- [main] o.a.coyote.http11.Http11NioProtocol : Initializing ProtocolHandler ["http-nio-8080"]
INFO --- [main] o.apache.catalina.core.StandardService : Starting service [Tomcat]
INFO --- [main] org.apache.catalina.core.StandardEngine : Starting Servlet engine: [Apache Tomcat/9.0.17]
and restarts..
while normally, the next phase of bootstrapping (happens locally) would be;
[restartedMain] o.a.c.c.C.[Tomcat].[localhost].[/] : Initializing Spring embedded WebApplicationContext
[restartedMain] o.s.web.context.ContextLoader : Root WebApplicationContext: initialization completed in 42018 ms
Probably a long shot question but any level of clues or suggestions would be much appreciated.
I've run out of doors to open. :-(
You could try to update Tomcat version just in case.
But looking at Grails documentation:
https://docs.grails.org/latest/guide/upgrading.html
There's some configuration made when you upgrade to Grails 4 from
Grails 3.3.x to prevents the server from restarting when views or
message bundles are changed.
Either modifying a gsp in Grails 4 M2 cause the application to restart.
https://github.com/grails/grails-core/issues/11284

Spring-Boot Server is not running, hangs after Initializing Spring FrameworkServlet 'dispatcherServlet

After running the spring-boot App, I'm getting the below logs:
Using below:
Kubernetes
Bit-Bucket Pipeline
MySQL and Oracle
Consul
Running Debug Mode
2019-07-17 10:33:03 [0] [main] INFO c.n.c.sources.URLConfigurationSource - To enable URLs as dynamic configuration sources, define System property archaius.configurationSource.additionalUrls or make config.properties available on classpath.
2019-07-17 10:33:11 [0] [http-nio-9080-exec-2] INFO o.a.c.c.C.[Tomcat].[localhost].[/] - Initializing Spring FrameworkServlet 'dispatcherServlet'

Exclude resources in Spring Cloud Sleuth

I am investigating integrating Spring Cloud Sleuth into a new Spring Boot service we are building and want to exclude certain URL's from generating spans for example health check endpoints which are polled periodically.
Checking the code I can see that the TraceFilter created in the TraceWebAutoConfiguration.java has a DEFAULT_SKIP_PATTERN which can be overridden by setting spring.sleuth.instrument.web.skipPattern.
However even if I access a resource under the DEFAULT_SKIP_PATTERN I am still observing that a trace & span are being created i.e.
17:28:46.142 [XNIO-2 task-1] INFO o.s.c.sleuth.log.Slf4jSpanListener - Starting span: MilliSpan(begin=1454394526140, end=0, name=http/info, traceId=908b24a3-143f-4949-8f86-5df867e3985b, parents=[], spanId=908b24a3-143f-4949-8f86-5df867e3985b, remote=false, exportable=false, annotations={}, processId=null, timelineAnnotations=[])
17:28:46.143 [XNIO-2 task-1] INFO o.s.c.sleuth.log.Slf4jSpanListener - Continued span: MilliSpan(begin=1454394526140, end=0, name=http/info, traceId=908b24a3-143f-4949-8f86-5df867e3985b, parents=[], spanId=908b24a3-143f-4949-8f86-5df867e3985b, remote=false, exportable=false, annotations={}, processId=null, timelineAnnotations=[])
17:28:46.146 [XNIO-2 task-1] INFO io.undertow.servlet - Initializing Spring FrameworkServlet 'dispatcherServlet'
17:28:46.146 [XNIO-2 task-1] INFO o.s.web.servlet.DispatcherServlet - FrameworkServlet 'dispatcherServlet': initialization started
17:28:46.170 [XNIO-2 task-1] INFO o.s.web.servlet.DispatcherServlet - FrameworkServlet 'dispatcherServlet': initialization completed in 24 ms
17:28:46.216 [XNIO-2 task-1] INFO o.s.c.sleuth.log.Slf4jSpanListener - Stopped span: MilliSpan(begin=1454394526140, end=1454394526215, name=http/info, traceId=908b24a3-143f-4949-8f86-5df867e3985b, parents=[], spanId=908b24a3-143f-4949-8f86-5df867e3985b, remote=false, exportable=false, annotations={}, processId=null, timelineAnnotations=[])
Am I missing something? I am currently using 1.0.0.M4
A skipped resource does not stop a span from being created, it only stops the data from being collected and exported. So your logs look normal to me. In snapshots you would see the "exportable" flag set to false in skipped resources.

Resources