Re: StaticMembers within Multiple Clusters
> Can you post the rest of that stack trace? Yes, here are 2 stack traces that were encountered. We basically had the cluster working for a few years. We introduced a new Valve for authentication purposes. Also, with this change we had to set a proxy in CATALINA_OPTS, I'm not sure if that affected local communication between the nodes? For now we commented out the cluster on each of our nodes in order to have it running. Exception in thread "Tribes-Task-Receiver[Catalina-Channel]-9" java.lang.NoClassDefFoundError: Could not initialize class org.apache.catalina.tribes.ChannelException at org.apache.catalina.tribes.transport.nio.ParallelNioSender.sendMessage(ParallelNioSender.java:110) at org.apache.catalina.tribes.transport.nio.PooledParallelSender.sendMessage(PooledParallelSender.java:51) at org.apache.catalina.tribes.transport.ReplicationTransmitter.sendMessage(ReplicationTransmitter.java:65) at org.apache.catalina.tribes.group.ChannelCoordinator.sendMessage(ChannelCoordinator.java:83) at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:89) at org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.sendMessage(MessageDispatchInterceptor.java:93) at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:89) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.sendMessage(TcpFailureDetector.java:89) at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:89) at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:89) at org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.sendMessage(EncryptInterceptor.java:127) at org.apache.catalina.tribes.group.ChannelInterceptorBase.sendMessage(ChannelInterceptorBase.java:89) at org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:280) at org.apache.catalina.tribes.group.GroupChannel.send(GroupChannel.java:231) at org.apache.catalina.tribes.group.RpcChannel.messageReceived(RpcChannel.java:171) at org.apache.catalina.tribes.group.GroupChannel.messageReceived(GroupChannel.java:345) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:96) at org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.messageReceived(EncryptInterceptor.java:148) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:96) at org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor.messageReceived(TcpPingInterceptor.java:182) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:96) at org.apache.catalina.tribes.group.interceptors.TcpFailureDetector.messageReceived(TcpFailureDetector.java:114) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:96) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:96) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:288) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:272) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:228) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:103) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:750) WARNING [https-jsse-nio-9443-exec-22] org.apache.catalina.tribes.transport.nio.ParallelNioSender.keepalive Error during keepalive test for sender:[org.apache.catalina.tribes.transport.nio.NioSender@ee16415] java.nio.channels.NotYetConnectedException at sun.nio.ch.SocketChannelImpl.ensureReadOpen(SocketChannelImpl.java:258) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:299) at org.apache.catalina.tribes.transport.nio.NioSender.read(NioSender.java:175) at org.apache.catalina.tribes.transport.nio.ParallelNioSender.keepalive(ParallelNioSender.java:395) at
Re: StaticMembers within Multiple Clusters
I hate to bring back my original thread and I am probably not doing this correctly, but I've been seeing this message occur on my cluster. My tomcat is now at 9.0.70. Possibly there was a breaking change since I first started using the cluster? java.lang.NoClassDefFoundError: Could not initialize class org.apache.catalina.tribes.ChannelException - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Secondary Authentication method for application
On Wed, Jul 13, 2022 at 10:21 AM EXT-Denton, Sam T wrote: > > This may help you: > https://stackoverflow.com/questions/15742580/how-to-programmatically-login-to-j-security-check > > Sam Denton > Advisor, Solutions Architect > Mobile (314) 827-4017 > 24x7 SBS Suppot (405) 312-9936 > Thanks for the reply, but what I'm trying to do is a bit different as I won't have the users password. I was basically looking for a backdoor way to establish a session using just the username. I think I was able to get it working but don't know if its the best way. What I was missing was, I was not saving the principal to the Session, only the Request initially. Also, I created a dummy servlet in my webapp that has both doGet and doPost methods so that the status codes would not be a 404-405. The valve will only create a new Principal for a POST request to a specific url. Eventually, my custom realm (form login) may go away and the login for my app will be done by this external app which will be the only thing that will be able to call this new "backdoor" way. Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Secondary Authentication method for application
Hello, I currently have a custom realm in Tomcat 9 that uses form authentication (j_username/j_password POST to j_security_check). I'm looking to create a secondary way to establish an authenticated session. I want to allow trusted sources to be able to POST a username param to a specific URL and establish an authenticated session with that provided username (I know, seems kind of scary, but it's just for a proof of concept right now). Eventually this secondary method may replace the custom realm all together, i.e. offloading authentication to an external provider. I've searched the list and other internet sources which led me to attempt to extend the ValveBase to try and set a UserPrincipal on the org.apache.catalina.connector.Request. I was trying to intercept POST requests to a new specific RequestURI and if the provided username param is acceptable, I do the request.setUserPrincipal with the role that is required. Am I going down the wrong path to accomplish this? When the valve code gets hit, It doesn't seem that the user is really getting authenticated; I believe because the request comes/goes and the principal is getting lost when the request is done... Also, I'm getting a 405 error on the actual POST, even though it appears the principal gets established for that request... Not sure if this has something to do with the JSESSIONID cookie... Thanks, Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting a Request Attribute from a custom Realm
On Tue, Apr 13, 2021 at 9:22 PM Tim K wrote: > > On Fri, Apr 9, 2021 at 7:48 AM Tim K wrote: > > As mentioned in that url, doing a pre-login of sorts before calling > > HttpServletRequest.login() may be a workaround to accomplish this, but > > then I would need to call my backend authentication service twice for > > each login. > > > > -Tim > > I've been looking into this further. Is it possible to completely > disable or change the URL for the "j_security_check" to something else > while still keeping form-login? I want to write my own servlet to > perform the login via HttpServletRequest.login() instead of putting > the password verification logic in the realm so that I have scope to > the request to display custom error messages back to the user. I'll > want the realm to be very generic, almost just creating a Principle > for anything that hits it, but I want to ensure my custom login is the > only thing that performs the login() for obvious reasons. > > -Tim Bringing back this one as I never got any bites on it. I'm still faced with figuring out a solution. If I only want to programmatically login the user via HttpServletRequest.login(), how could I prevent users from just directly POST-ing to j_security_check on their own and bypassing my own login action? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Potential Memory Leak with StandardManager [EXTERNAL]
On Mon, Oct 18, 2021 at 2:51 PM Beard, Shawn wrote: > Update to Tomcat 9.0.54. This could be a known security bug that is fixed > in this version. > > https://tomcat.apache.org/security-9.html#Fixed_in_Apache_Tomcat_9.0.54 > I tried updating to that version but it does not appear to be related; that looks to be related to web socket connections.
Potential Memory Leak with StandardManager
Running 4 balanced nodes of tomcat 9.0.52 in Linux. While running with production load, memory usage is slowly growing, it does not appear to really drop unless the OS/tomcat is restarted. I did a load test locally with just login actions, did a heap dump, and MAT says: One instance of org.apache.catalina.session.StandardManager loaded by sun.misc.Launcher$AppClassLoader @ 0x9978028 occupies 59,628,760 (57.09%) bytes. The memory is accumulated in one instance of java.util.concurrent.ConcurrentHashMap$Node[], loaded by , which occupies 59,615,224 (57.07%) bytes. My session timeout is set to 15 minutes... I set just a name and userId in the session object in our single application running on these servers. Not sure how else to troubleshoot and/or resolve this from reaching the heap max. Are there settings to change in order to get these sessions removed from heap? Does GC occur out of the box with tomcat or do I need to define that in order for it to happen? Thanks, Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting a Request Attribute from a custom Realm
On Fri, Apr 9, 2021 at 7:48 AM Tim K wrote: > As mentioned in that url, doing a pre-login of sorts before calling > HttpServletRequest.login() may be a workaround to accomplish this, but > then I would need to call my backend authentication service twice for > each login. > > -Tim I've been looking into this further. Is it possible to completely disable or change the URL for the "j_security_check" to something else while still keeping form-login? I want to write my own servlet to perform the login via HttpServletRequest.login() instead of putting the password verification logic in the realm so that I have scope to the request to display custom error messages back to the user. I'll want the realm to be very generic, almost just creating a Principle for anything that hits it, but I want to ensure my custom login is the only thing that performs the login() for obvious reasons. -Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting a Request Attribute from a custom Realm
On Thu, Apr 8, 2021 at 1:38 PM Christopher Schultz wrote: > > I have some sketches of something like this literally on paper somewhere > around here to create an interface for applications subscribe to > authentication events. It would, for example, allow you to write a > "failed login" record to your database that includes not only the user's > username who failed, but also their IP address (which comes from the > request, of course. > > Would that kind of thing help in your use-case? I'm looking for a way to give more information back to the user if their account is locked or not... Right now it's very generic and that is good from a security perspective, but I need to be able to tell the user that their account is locked after so many attempts and they will need to take action to unlock it. I found this on the web: https://stackoverflow.com/questions/7584208/detect-a-realm-authentication-failure-reason-in-tomcat Is the "com.ofc.tomcat.LOGIN_FAILURE_MESSAGE" still around in Tomcat 9? Not sure how to use it even if it way... As mentioned in that url, doing a pre-login of sorts before calling HttpServletRequest.login() may be a workaround to accomplish this, but then I would need to call my backend authentication service twice for each login. -Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Setting a Request Attribute from a custom Realm
On Wed, Apr 7, 2021, 3:43 PM Christopher Schultz < ch...@christopherschultz.net> wrote: > You can't, using the existing API. > > You might be able to do it with some nasty ThreadLocal solution, but I > think you are stuck without resorting to legerdemain. > > -chris Would it be possible to implement a new feature to the existing realm API so it can accommodate messages passed back to the front end? For example, when using the LockoutRealm, is there from the front-end to alert the user that they are actually locked out? - Tim
Setting a Request Attribute from a custom Realm
I have a custom realm which I'm receiving custom messages back within the realm code and I want to display these messages on the login page, but I have no idea how this can be accomplished with a custom realm which is overriding the Principle authenticate method. Any help would be appreciated, Tomcat is version 9. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Intermittent JSP Caching/Compiling Issue while under load
Was the fix for this added to 9.0.28 or 9.0.29 official releases? Thanks, Tim
Re: Intermittent JSP Caching/Compiling Issue while under load
On Thu, Nov 7, 2019, 1:58 PM Mark Thomas wrote: > On 07/11/2019 18:04, Mark Thomas wrote: > > On 07/11/2019 16:44, Mark Thomas wrote: > >> On 07/11/2019 14:14, Tim K wrote: > >> > >> > >>> I pulled the latest code from GitHub, I see the commit related to this > >>> email thread in the log, I built from master with ant (9.0.28-dev) > >> > >> Thanks. This is really helpful. > >> > >>> and I'm > >>> still experiencing the issue... I have a curl command executing every > >>> second (via watch -n1) going to a JSP while making an edit to it. I > can > >>> reproduce the cached issue every 2-3 edits. > >> > >> Drat. I'll look further. Not sure at this point if the previous fix is > >> incomplete or if there is a second cause. > > > > My bad. I "improved" the patch to address a test failure and essentially > > made the whole thing a NO-OP. > > > > I'll fix it shortly. > > Done. Please re-test. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Looks good to me! Tried 20+ edits in a row, no caching occurred! Thank you so much for fixing!
Re: Intermittent JSP Caching/Compiling Issue while under load
On Thu, Nov 7, 2019, 6:40 AM Mark Thomas wrote: > On 06/11/2019 20:04, Mark Thomas wrote: > > I've found the root cause. > > > > When checking the timestamps of JSPs, the JSP engine (because it has to > > access all resources via the Servlet API) requests a URL for the JSP, > > opens a connection to the URL and then checks the last modified time. > > This goes directly to the on-disk file. > > > > When reading the content, the request goes via the static resource cache > > because we can intercept the call to ServletContext.getResourceAsStream() > > > > The problem is the following sequence: > > - request for JSP > > - no change in JSP timestamp found > > - cache re-validated (for 5s by default) > > - JSP is modified (within 5s) > > - request for JSP (within 5s) > > - change in JSP timestamp found > > - JSP content read (sees cached version rather than new version) > > > > So we end up with the old version of the JSP content with the updated > > last modification time. > > > > I'm currently looking at options to return a URL for the resource where > > we can intercept the call to URLConnection.getLastModified(). > > Fixed in: > - master for 9.0.28 onwards > - 8.5.x for 8.5.48 onwards > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org I pulled the latest code from GitHub, I see the commit related to this email thread in the log, I built from master with ant (9.0.28-dev) and I'm still experiencing the issue... I have a curl command executing every second (via watch -n1) going to a JSP while making an edit to it. I can reproduce the cached issue every 2-3 edits.
Re: Intermittent JSP Caching/Compiling Issue while under load
On Tue, Nov 5, 2019 at 3:01 AM Mark Thomas wrote: > This looks like some sort of concurrency issue. In your test > environment, how likely is it that: > - there are concurrent (or at least very close together) changes to a > JSP > - that there are concurrent requests for a modified JSP? In my test env, I am the sole person making changes to the JSP. Also, in production, its only 1 single person making changes to a particular JSP. It is very likely that there are concurrent requests for the modified JSP. That is exactly how I am reproducing this, I basically have a curl command being executed every 0.5-1 seconds for that modified JSP when this intermittent issue occurs. With high production traffic, it's very possible that one or more users are hitting a modified JSP. > Also, what process are you using to update the JSP content? In my tests, I'm simply using VIM, in production, it's using a content management system which likely just copies the new JSP over, similar to an rsync or cp command. The issue is reproducible in both cases, as long as there are active requests for the modified JSP. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Intermittent JSP Caching/Compiling Issue while under load
On Mon, Nov 4, 2019, 6:19 PM M. Manna wrote: > I’m just trying to understand, is there really a plausible solution here ? > Unless we have loadbalanced tomcat instances, can we truly ever stop such > behaviour (or more importantly, does it make sense to do so)? > > For my use case, We do it in production almost every other day for > patching, but we do it on our 60 servers over a duration of 15-20 minutes > (and by rolling 1-by-1). That said, this may not be an acceptable > delay/solution for others. Also, if it happens to be a critical piece > (index.jsp or something more client-faces), you may not be able to wait > that long. > > It’s be good to know what others think. > > Regards, > The cached JSP actually survives a tomcat restart because the work directory still contains the cached JSP content even though the timestamp of the class/java files appear to match that of the latest JSP file's content. >
Re: Intermittent JSP Caching/Compiling Issue while under load
On Mon, Nov 4, 2019, 10:30 AM Mark Thomas wrote: > > Thanks. That helps as it means the issue should be reproducible on a > single, stand-alone instance. > > Mark > I was able to reproduce this behavior with a single server running a vanilla 9.0.21 using the example hello.jsp file... I was hitting the url every 0.5 seconds. >
Re: Intermittent JSP Caching/Compiling Issue while under load
On Mon, Nov 4, 2019, 10:06 AM Mark Thomas wrote: > > How are you distributing the updates to the JSP to all 4 servers? > > Is there a shared file system involved? If yes, exactly what is shared > between the instances? > > Mark > Common NFS storage included via (DirResourceSet) within the of my clustered application. But to rule out any issue with that, I tried using local storage within the war directory itself and updated the JSP on local storage exactly at the same time and the problem still persisted. >
Re: Intermittent JSP Caching/Compiling Issue while under load
> > In my tests when hitting it every second, I make a few changes and it > works fine (all within the same min). Then I'll let it go for a few mins, > make a change and more often than not, one or more of the servers gets > stuck on the previous jsp change... I'm pretty sure the class/java > timestamps get updated but the content does not. > This morning I made one single change to the JSP which appeared the get stuck on all 4 of my servers, as shown below: https://pasteboard.co/IF8nrEG.jpg Also, with additional logging, it appears that Tomcat sees the change and regenerates the java and class files but yet it still serves the former JSP content. If I manual delete the class/java files under the work dir, it will successfully pick up the latest. 04-Nov-2019 07:30:30.646 FINE [Catalina-utility-2] org.apache.jasper.compiler.Compiler.isOutDated Compiler: outdated: /apache-tomcat-9.0.21/work/Catalina/localhost/context-root/org/apache/jsp/abcxyz/test_jsp.class 1572443847000 04-Nov-2019 07:30:30.646 FINE [Catalina-utility-2] org.apache.jasper.compiler.Compiler.removeGeneratedClassFiles Deleting /apache-tomcat-9.0.21/work/Catalina/localhost/context-root/org/apache/jsp/abcxyz/test_jsp.class 04-Nov-2019 07:30:30.647 FINE [Catalina-utility-2] org.apache.jasper.compiler.Compiler.removeGeneratedFiles Deleting /apache-tomcat-9.0.21/work/Catalina/localhost/context-root/org/apache/jsp/abcxyz/test_jsp.java 04-Nov-2019 07:30:30.652 FINE [Catalina-utility-2] org.apache.jasper.compiler.Compiler.generateJava Generated /apache-tomcat-9.0.21/work/Catalina/localhost/context-root/org/apache/jsp/abcxyz/test_jsp.java total=4 generate=1 validate=3 04-Nov-2019 07:30:30.718 FINE [Catalina-utility-2] org.apache.jasper.compiler.JDTCompiler.generateClass Compiled /apache-tomcat-9.0.21/work/Catalina/localhost/context-root/org/apache/jsp/abcxyz/test_jsp.java 59ms
Re: Intermittent JSP Caching/Compiling Issue while under load
On Fri, Nov 1, 2019, 3:11 AM Mark Thomas wrote: > On 31/10/2019 22:07, Mark Thomas wrote: > > > > > > On 29/10/2019 14:31, Tim K wrote: > >> I'm on Tomcat 9.0.21 on Linux. I have Jsps that get updated while > >> Tomcat is running. I believe development mode is set to true by > >> default, I do not have it set to true or false in the > >> $CATALINA_BASE/conf/web.xml for the Jsp servlet init-params. I have a > >> cluster of 4-8 servers across different envs. I'm noticing an > >> intermittent issue where 1 or more of my tomcat instances do not > >> always compile the latest Jsp content while the server is under load. > >> I've tried debugging the org.apache.jasper.compiler, it appears that > >> the class/java files of the tomcat work directory are getting > >> deleted/regenerated (get a new timestamp as well) but occasionally the > >> contents of the Jsp becomes out of sync in the generated class file > >> within the tomcat work directory. I've tried different combinations > >> of development mode, checkInterval, modificationTestInterval but none > >> seem to help resolve this issue. This only seems to be an issue when > >> the server is under a load. I was able to reproduce in my lower env > >> (4 server cluster) while hitting the Jsp every 1 seconds while > >> changing the jsp contents. I can make a subsequent change and the Jsp > >> content likely get's picked up by the same server(s) which previous > >> didn't pick it up. > > > > That you see the issue when hitting the JSP once a second makes me think > > it is something to do with timestamp resolution. Are you making > > modifications within a similarly short time-frame? Or do you still see > > the issue when the modifications are, say, minutes apart? > > Could this be the issue: > https://bz.apache.org/bugzilla/show_bug.cgi?id=63897 > > Mark > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org In my tests when hitting it every second, I make a few changes and it works fine (all within the same min). Then I'll let it go for a few mins, make a change and more often than not, one or more of the servers gets stuck on the previous jsp change... I'm pretty sure the class/java timestamps get updated but the content does not.
Intermittent JSP Caching/Compiling Issue while under load
I'm on Tomcat 9.0.21 on Linux. I have Jsps that get updated while Tomcat is running. I believe development mode is set to true by default, I do not have it set to true or false in the $CATALINA_BASE/conf/web.xml for the Jsp servlet init-params. I have a cluster of 4-8 servers across different envs. I'm noticing an intermittent issue where 1 or more of my tomcat instances do not always compile the latest Jsp content while the server is under load. I've tried debugging the org.apache.jasper.compiler, it appears that the class/java files of the tomcat work directory are getting deleted/regenerated (get a new timestamp as well) but occasionally the contents of the Jsp becomes out of sync in the generated class file within the tomcat work directory. I've tried different combinations of development mode, checkInterval, modificationTestInterval but none seem to help resolve this issue. This only seems to be an issue when the server is under a load. I was able to reproduce in my lower env (4 server cluster) while hitting the Jsp every 1 seconds while changing the jsp contents. I can make a subsequent change and the Jsp content likely get's picked up by the same server(s) which previous didn't pick it up. Thanks in advance, Tim - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: StaticMembers within Multiple Clusters
On Tue, Feb 12, 2019, 3:17 AM Keiichi Fujino wrote: > > Are you using SSO(org.apache.catalina.authenticator.SingleSignOn)? > DeltaManager/BackupManager replicate sessions. They do not replicate SSO > entries. > > If you want to replicate SSO Entry in cluster, you can use > ClusterSingleSignOn. > > > http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-valve.html#org.apache.catalina.ha.authenticator.ClusterSingleSignOn > > > > -- > Keiichi.Fujino > Yes. I tried adding a Value element for ClusterSingleSignOn to my Cluster (removed the JvmBinderValue I had) and upon login, I'm noticing that subsequent calls to my app are removing my SSO cookie, but I don't understand why. It successfully gets created but a subsequent call immediately removes it. >
Re: StaticMembers within Multiple Clusters
On Fri, Jan 18, 2019, 12:44 PM Tim K wrote: > On Fri, Jan 18, 2019 at 11:05 AM Christopher Schultz > wrote: > > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > Tim, > > > > On 1/18/19 06:38, Tim K wrote: > > > Thanks for this. The video helps explain it a bit better than the > > > documentation. So I set it up with a backup manager instead of the > > > delta manager, changing the channelSendOptions to 6 for the > > > cluster. > > > > If you think you can help clarify the documentation, patches are of > > course always welcome. > > > > > From a maintenance standpoint, what is the best way to stop/start > > > the nodes without losing sessions; one at a time, letting it fully > > > come up before moving on to the next one (like a ripple restart)? > > > I presume you don't want too many nodes to be down at a single > > > time. > > > > I definitely wouldn't bring two down simultaneously if your can avoid > > it. The cluster needs time to re-stabalize after the loss of a member, > > meaning that new backup nodes must be selected for each session and > > then the sessions must be transmitted to those backups nodes. If you > > have small amounts of data in the sessions, this will probably be > > fairly fast. If you have lots of data or a very busy network, it will > > take longer. > > > > I would recommend setting-up a scenario (even in production) where you > > intentionally disable a node in the cluster and watch to see how long > > the cluster takes to re-stabalize. I think you'll learn a lot from > > that exercise and it will help you plan for scheduled maintenance and > > downtime. > > > > - -chris > > Is there a way to tell which server was assigned as the primary and > backup roles? > > When I stop a member, is it this line which would tell me how long it > took to sync up the sessions? > Relocation of map entries was complete in [X] ms. > > Another question, I'm using the StaticMembershipService; do I need to > define a LocalMember for each of my nodes or is that optional/assumed? > > Also, I recall reading something about the uniqueId might not really > be used? Do I need to set that for each member? > I'm noticing my SSO cookie is being removed when I force myself to another node. Is this a bug? >
Re: StaticMembers within Multiple Clusters
On Fri, Jan 18, 2019 at 11:05 AM Christopher Schultz wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > On 1/18/19 06:38, Tim K wrote: > > Thanks for this. The video helps explain it a bit better than the > > documentation. So I set it up with a backup manager instead of the > > delta manager, changing the channelSendOptions to 6 for the > > cluster. > > If you think you can help clarify the documentation, patches are of > course always welcome. > > > From a maintenance standpoint, what is the best way to stop/start > > the nodes without losing sessions; one at a time, letting it fully > > come up before moving on to the next one (like a ripple restart)? > > I presume you don't want too many nodes to be down at a single > > time. > > I definitely wouldn't bring two down simultaneously if your can avoid > it. The cluster needs time to re-stabalize after the loss of a member, > meaning that new backup nodes must be selected for each session and > then the sessions must be transmitted to those backups nodes. If you > have small amounts of data in the sessions, this will probably be > fairly fast. If you have lots of data or a very busy network, it will > take longer. > > I would recommend setting-up a scenario (even in production) where you > intentionally disable a node in the cluster and watch to see how long > the cluster takes to re-stabalize. I think you'll learn a lot from > that exercise and it will help you plan for scheduled maintenance and > downtime. > > - -chris Is there a way to tell which server was assigned as the primary and backup roles? When I stop a member, is it this line which would tell me how long it took to sync up the sessions? Relocation of map entries was complete in [X] ms. Another question, I'm using the StaticMembershipService; do I need to define a LocalMember for each of my nodes or is that optional/assumed? Also, I recall reading something about the uniqueId might not really be used? Do I need to set that for each member? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: StaticMembers within Multiple Clusters
On Fri, Jan 18, 2019, 4:55 AM Mark Thomas On 18/01/2019 01:40, Tim K wrote: > > On Thu, Jan 17, 2019, 3:36 PM Mark Thomas > > >> On 17/01/2019 15:28, Tim K wrote: > >> > >>> With the DeltaManager, instead of it notifying all nodes when sessions > >> get > >>> established, is there a way for it to only share that single node's > >>> sessions during a shutdown event of that particular node? For example, > >>> node 1 of 8 has 5 sessions on it. When node 1 is shut down, only then > >> will > >>> it replicate those 5 sessions to the other 7 nodes... This would > reduce > >>> the all-to-all traffic that would be occurring constantly but would put > >>> more weight on a shutdown event... Also, another wrinkle, the shutdown > >> port > >>> is disabled in server.xml for security reasons. > >> > >> None of the managers can be configured to replicate only on shutdown. > >> > >> The BackupManager is closer to the behaviour you describe. Note it is a > >> common misconception that in the BackupManager a single node acts as a > >> backup for all the other nodes. This is incorrect. Backups are > >> distributed on a round-robin basis between all other nodes. > >> > >> The shutdown port being disabled should be a non-issue. As long as you > >> kill -15 rather than kill -9 then you'll get a clean shutdown. > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > So to switch to Backup manager, just swap out the DeltaManager for it on > > each serve or just one? > > All of them. > > > You're right, it does seem the backup manager was > > a single node, even after looking again at the documentation. Is the > > backup manager "battle tested" enough since the documentation was > written? > > Yes. > > > Is there less network traffic with backup manager? > > Yes. > > > My nodes all have the > > same single app installed, I'm not sure what the advantage would be in > > using the backup manager. > > Less network traffic. > > See: > https://www.youtube.com/watch?v=6LoAdy9-jBI > > particularly from around 29:30 > > Mark > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Thanks for this. The video helps explain it a bit better than the documentation. So I set it up with a backup manager instead of the delta manager, changing the channelSendOptions to 6 for the cluster. >From a maintenance standpoint, what is the best way to stop/start the nodes without losing sessions; one at a time, letting it fully come up before moving on to the next one (like a ripple restart)? I presume you don't want too many nodes to be down at a single time.
Re: StaticMembers within Multiple Clusters
On Thu, Jan 17, 2019, 3:36 PM Mark Thomas On 17/01/2019 15:28, Tim K wrote: > > > With the DeltaManager, instead of it notifying all nodes when sessions > get > > established, is there a way for it to only share that single node's > > sessions during a shutdown event of that particular node? For example, > > node 1 of 8 has 5 sessions on it. When node 1 is shut down, only then > will > > it replicate those 5 sessions to the other 7 nodes... This would reduce > > the all-to-all traffic that would be occurring constantly but would put > > more weight on a shutdown event... Also, another wrinkle, the shutdown > port > > is disabled in server.xml for security reasons. > > None of the managers can be configured to replicate only on shutdown. > > The BackupManager is closer to the behaviour you describe. Note it is a > common misconception that in the BackupManager a single node acts as a > backup for all the other nodes. This is incorrect. Backups are > distributed on a round-robin basis between all other nodes. > > The shutdown port being disabled should be a non-issue. As long as you > kill -15 rather than kill -9 then you'll get a clean shutdown. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org So to switch to Backup manager, just swap out the DeltaManager for it on each serve or just one? You're right, it does seem the backup manager was a single node, even after looking again at the documentation. Is the backup manager "battle tested" enough since the documentation was written? Is there less network traffic with backup manager? My nodes all have the same single app installed, I'm not sure what the advantage would be in using the backup manager.
Re: StaticMembers within Multiple Clusters
On Tue, Jan 15, 2019, 3:14 PM Mark Thomas On 15/01/2019 18:36, Tim K wrote: > > > Question: what's considered a "large" cluster I've seen a lot of > > documentation about small vs large but I'd like to know what is > considered > > large. Could the DeltaManager handle one single cluster (all-to-all) > with > > 8 members with 8GB allocated to each jvm, separate servers? Not storing > > much in the session besides 3-4 short strings. > > It depends more on the frequency and size of session updates. > > With the DeltaManager traffic volume is proportional to n(n-1) where n > is the number of nodes. With the BackupManager it is proportional to n. > > With 8 nodes the DeltaManager generates 7 times the cluster traffic that > the BackManager generates. Whether your network will cope with that will > depend on the app and usage pattern. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org With the DeltaManager, instead of it notifying all nodes when sessions get established, is there a way for it to only share that single node's sessions during a shutdown event of that particular node? For example, node 1 of 8 has 5 sessions on it. When node 1 is shut down, only then will it replicate those 5 sessions to the other 7 nodes... This would reduce the all-to-all traffic that would be occurring constantly but would put more weight on a shutdown event... Also, another wrinkle, the shutdown port is disabled in server.xml for security reasons.
Re: javax.security.auth.subject within session
On Thu, Jan 17, 2019, 8:09 AM Mark Thomas On 17/01/2019 12:46, Tim K wrote: > > When I dump the session object of an authenticated (JNDIRealm) user on my > > local dev environment versus my development server, for some reason > > the javax.security.auth.subject shows up on the dev server but not my > > local. I also spun up a docker container with pretty much default tomcat > > config and javax.security.auth.subject doesn't show up in the session > > object there either. My code is exactly the same in all envs, is there > > something within tomcat configuration which would determine if > > javax.security.auth.subject is added to the session object? I can't > figure > > out the difference why it's on one instance but not the other. > > At a guess, the development server is running under a SecurityManager > whereas the other environments are not. > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Thank you! You are correct; I had disabled security locally because the eclipse paths were much different than the servers so I just disabled it to get it running locally. I presume this value in the session for the javax.security.auth.subject is consistent as long as security is enabled?
javax.security.auth.subject within session
When I dump the session object of an authenticated (JNDIRealm) user on my local dev environment versus my development server, for some reason the javax.security.auth.subject shows up on the dev server but not my local. I also spun up a docker container with pretty much default tomcat config and javax.security.auth.subject doesn't show up in the session object there either. My code is exactly the same in all envs, is there something within tomcat configuration which would determine if javax.security.auth.subject is added to the session object? I can't figure out the difference why it's on one instance but not the other.
Re: StaticMembers within Multiple Clusters
On Tue, Jan 15, 2019, 12:51 PM Tim K On Tue, Jan 15, 2019, 4:10 AM Keiichi Fujino >> Hi >> >> If you use StaticMembershipInterceptor, you must set the >> Cluster#channelStartOptions to 3 to avoid starting membershipservice. >> If you are using Tomcat 9, you can also use StaticMembershipService >> instead >> of StaticMembershipInterceptor. >> >> >> 2019年1月10日(木) 22:39 Tim K : >> >> > On Wed, Jan 9, 2019, 2:16 PM Christopher Schultz < >> > ch...@christopherschultz.net wrote: >> > >> > > -----BEGIN PGP SIGNED MESSAGE- >> > > Hash: SHA256 >> > > >> > > Tim, >> > > >> > > On 1/9/19 10:39, Tim K wrote: >> > > > I'm trying to split 4 separate tomcat instances into 2 clusters >> > > > (2x2) to try and avoid the all-to-all traffic, but even when >> > > > setting up the Receiver and Static members to only speak to 1 other >> > > > instance, some still seems to find and add the other members >> > > > outside of the defined config to the wrong cluster. I read that >> > > > mcast is still used when you have StaticMembers, could that be >> > > > causing this issue? >> > > >> > > Multicast is only used for membership, so if you are using static, >> > > there should be no multicast. >> > > >> > > Do you want to post your configuration(s)? >> > > >> > > - -chris >> > > -BEGIN PGP SIGNATURE- >> > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ >> > > >> > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw2SIEACgkQHPApP6U8 >> > > pFh//A//WldkBxcRVWZ0Nj/FVjFqdhxr8dkystbk114wk8pjF/h5JOSmncQjvUn6 >> > > 999ZT54rXToS+Dl2svp9imR266o0+56bUvJVXG2O4NK7TQZsEsBdOsqfnWPoHBM3 >> > > kYS7lhzhlpmw1SDFlKVW0PnRX9acah5+SfVci5gL0cWTVqSkdmm4P6v2wqH1z7ej >> > > AeMZ0w2LaoRH0TTxJk8cD2vJpvnB3oNjrtUhHZCPJCraITPHhFNFMOSmhhf3+e1S >> > > K63D6l9kE3x4WDNtxKBBjr+5FaULM6kL5DotQlJPo0j7I4mL9DBgt2HkgTfoS39m >> > > M7QBGBR4tZ1zRIJiGXQRViMRhqL+Xjny61RxtU7zUlfWSChTEonUiv5z6aZ7q5n2 >> > > xz1Evrw+gLmoR+YecOazMHef/7z6GFNCGyE80BFbR8LgHeOubaPfY+zhYw6iWSQP >> > > eHt32x48vzPewYlV1HLJR7C1oXhFPN9QVT2r+UENcsMtlDdWIhaflw6nb3qXhP8N >> > > t4xqlUJebON1KolHRXXReNgz6TieKLmup1jSgRvVhohSYBOputLB01PY5S7E6vLy >> > > 33EZGHbCOWlZzC1qyiXRd7jIfkdsQ9oRRHknty1gi0id/20M+iqYS22ZggnXMtFX >> > > P0lORhhEiWBSyMHytrIb+uO7HglocrSuQfgVaoAkiaRUDtyBdHg= >> > > =PM9e >> > > -END PGP SIGNATURE- >> > > >> > > - >> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> > > For additional commands, e-mail: users-h...@tomcat.apache.org >> > >> > >> > Essentially I'm trying to have server1 and server2 only in cluster1 and >> > server3 and server4 in only cluster2, but for some reason, members are >> > getting added to clusters that they aren't configured for. >> > >> > >> > >> > server1 config: >> > >> > > > channelSendOptions="8"> >> > >> > > > className="org.apache.catalina.ha.session.DeltaManager" >> > expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> >> > >> > > > className="org.apache.catalina.tribes.group.GroupChannel"> >> > >> > > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" >> > address="auto" port="4000" autoBind="100" selectorTimeout="5000" >> > maxThreads="6"/> >> > >> > > > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> >> > >> > > > >> className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> >> > >> > >> > >> > > > >> > >> className="org.apache.catalina.tribes.group.interceptors.EncryptInterceptor" >> > encryptionKey="Removed" /> >> > >> > > > >> > >> className="org.apache.catalina.tribes.group.interceptors
Re: StaticMembers within Multiple Clusters
On Tue, Jan 15, 2019, 4:10 AM Keiichi Fujino Hi > > If you use StaticMembershipInterceptor, you must set the > Cluster#channelStartOptions to 3 to avoid starting membershipservice. > If you are using Tomcat 9, you can also use StaticMembershipService instead > of StaticMembershipInterceptor. > > > 2019年1月10日(木) 22:39 Tim K : > > > On Wed, Jan 9, 2019, 2:16 PM Christopher Schultz < > > ch...@christopherschultz.net wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA256 > > > > > > Tim, > > > > > > On 1/9/19 10:39, Tim K wrote: > > > > I'm trying to split 4 separate tomcat instances into 2 clusters > > > > (2x2) to try and avoid the all-to-all traffic, but even when > > > > setting up the Receiver and Static members to only speak to 1 other > > > > instance, some still seems to find and add the other members > > > > outside of the defined config to the wrong cluster. I read that > > > > mcast is still used when you have StaticMembers, could that be > > > > causing this issue? > > > > > > Multicast is only used for membership, so if you are using static, > > > there should be no multicast. > > > > > > Do you want to post your configuration(s)? > > > > > > - -chris > > > -BEGIN PGP SIGNATURE- > > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > > > > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw2SIEACgkQHPApP6U8 > > > pFh//A//WldkBxcRVWZ0Nj/FVjFqdhxr8dkystbk114wk8pjF/h5JOSmncQjvUn6 > > > 999ZT54rXToS+Dl2svp9imR266o0+56bUvJVXG2O4NK7TQZsEsBdOsqfnWPoHBM3 > > > kYS7lhzhlpmw1SDFlKVW0PnRX9acah5+SfVci5gL0cWTVqSkdmm4P6v2wqH1z7ej > > > AeMZ0w2LaoRH0TTxJk8cD2vJpvnB3oNjrtUhHZCPJCraITPHhFNFMOSmhhf3+e1S > > > K63D6l9kE3x4WDNtxKBBjr+5FaULM6kL5DotQlJPo0j7I4mL9DBgt2HkgTfoS39m > > > M7QBGBR4tZ1zRIJiGXQRViMRhqL+Xjny61RxtU7zUlfWSChTEonUiv5z6aZ7q5n2 > > > xz1Evrw+gLmoR+YecOazMHef/7z6GFNCGyE80BFbR8LgHeOubaPfY+zhYw6iWSQP > > > eHt32x48vzPewYlV1HLJR7C1oXhFPN9QVT2r+UENcsMtlDdWIhaflw6nb3qXhP8N > > > t4xqlUJebON1KolHRXXReNgz6TieKLmup1jSgRvVhohSYBOputLB01PY5S7E6vLy > > > 33EZGHbCOWlZzC1qyiXRd7jIfkdsQ9oRRHknty1gi0id/20M+iqYS22ZggnXMtFX > > > P0lORhhEiWBSyMHytrIb+uO7HglocrSuQfgVaoAkiaRUDtyBdHg= > > > =PM9e > > > -END PGP SIGNATURE- > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > Essentially I'm trying to have server1 and server2 only in cluster1 and > > server3 and server4 in only cluster2, but for some reason, members are > > getting added to clusters that they aren't configured for. > > > > > > > > server1 config: > > > > > channelSendOptions="8"> > > > > > className="org.apache.catalina.ha.session.DeltaManager" > > expireSessionsOnShutdown="false" notifyListenersOnReplication="true"/> > > > > > className="org.apache.catalina.tribes.group.GroupChannel"> > > > > > className="org.apache.catalina.tribes.transport.nio.NioReceiver" > > address="auto" port="4000" autoBind="100" selectorTimeout="5000" > > maxThreads="6"/> > > > > > className="org.apache.catalina.tribes.transport.ReplicationTransmitter"> > > > > > > className="org.apache.catalina.tribes.transport.nio.PooledParallelSender"/> > > > > > > > > > > > > className="org.apache.catalina.tribes.group.interceptors.EncryptInterceptor" > > encryptionKey="Removed" /> > > > > > > > > className="org.apache.catalina.tribes.group.interceptors.TcpPingInterceptor"/> > > > > > > > > className="org.apache.catalina.tribes.group.interceptors.TcpFailureDetector"/> > > > > > > > > className="org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor"/> > > > > > > > > cl
Re: StaticMembers within Multiple Clusters
On Wed, Jan 9, 2019, 2:16 PM Christopher Schultz < ch...@christopherschultz.net wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > On 1/9/19 10:39, Tim K wrote: > > I'm trying to split 4 separate tomcat instances into 2 clusters > > (2x2) to try and avoid the all-to-all traffic, but even when > > setting up the Receiver and Static members to only speak to 1 other > > instance, some still seems to find and add the other members > > outside of the defined config to the wrong cluster. I read that > > mcast is still used when you have StaticMembers, could that be > > causing this issue? > > Multicast is only used for membership, so if you are using static, > there should be no multicast. > > Do you want to post your configuration(s)? > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlw2SIEACgkQHPApP6U8 > pFh//A//WldkBxcRVWZ0Nj/FVjFqdhxr8dkystbk114wk8pjF/h5JOSmncQjvUn6 > 999ZT54rXToS+Dl2svp9imR266o0+56bUvJVXG2O4NK7TQZsEsBdOsqfnWPoHBM3 > kYS7lhzhlpmw1SDFlKVW0PnRX9acah5+SfVci5gL0cWTVqSkdmm4P6v2wqH1z7ej > AeMZ0w2LaoRH0TTxJk8cD2vJpvnB3oNjrtUhHZCPJCraITPHhFNFMOSmhhf3+e1S > K63D6l9kE3x4WDNtxKBBjr+5FaULM6kL5DotQlJPo0j7I4mL9DBgt2HkgTfoS39m > M7QBGBR4tZ1zRIJiGXQRViMRhqL+Xjny61RxtU7zUlfWSChTEonUiv5z6aZ7q5n2 > xz1Evrw+gLmoR+YecOazMHef/7z6GFNCGyE80BFbR8LgHeOubaPfY+zhYw6iWSQP > eHt32x48vzPewYlV1HLJR7C1oXhFPN9QVT2r+UENcsMtlDdWIhaflw6nb3qXhP8N > t4xqlUJebON1KolHRXXReNgz6TieKLmup1jSgRvVhohSYBOputLB01PY5S7E6vLy > 33EZGHbCOWlZzC1qyiXRd7jIfkdsQ9oRRHknty1gi0id/20M+iqYS22ZggnXMtFX > P0lORhhEiWBSyMHytrIb+uO7HglocrSuQfgVaoAkiaRUDtyBdHg= > =PM9e > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Essentially I'm trying to have server1 and server2 only in cluster1 and server3 and server4 in only cluster2, but for some reason, members are getting added to clusters that they aren't configured for. server1 config: server2 [everything the same except the is]: server3 [everything the same except the is]: server4 [everything the same except the is]:
StaticMembers within Multiple Clusters
I'm trying to split 4 separate tomcat instances into 2 clusters (2x2) to try and avoid the all-to-all traffic, but even when setting up the Receiver and Static members to only speak to 1 other instance, some still seems to find and add the other members outside of the defined config to the wrong cluster. I read that mcast is still used when you have StaticMembers, could that be causing this issue?
Re: 9.0.13 encrypted cluster traffic
On Sat, Dec 22, 2018, 11:56 AM Christopher Schultz < ch...@christopherschultz.net wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > On 12/21/18 08:14, Tim K wrote: > > On Thu, Dec 20, 2018, 10:11 PM Christopher Schultz < > > ch...@christopherschultz.net wrote: > > > > Tim, > > > > On 12/20/18 10:18, Tim K wrote: > >>>>> > >>>>> I just downloaded and tried 9.0.14 but I'm still getting > >>>>> the same BadPaddingException upon starting the second > >>>>> instance. I confirmed the encryptionKey matches on my two > >>>>> instances. > >>>>> > >>>> > >>>> Maybe something is wrong with my config? For this test, I > >>>> have both Tomcats on the same server using different ports: > > > > This is the only thing that matters to the encryption interceptor: > > > >>>> >>>> className="org.apache.catalina.tribes.group.interceptors.EncryptInt > erc > > > >>>> > eptor" > >>>> > >>>> > > encryptionKey="e0f2cdf931e99fdce0453964294f97f3" /> > > > > I'm not sure if the order of encrypt/asyncdispatch interceptors > > matters much. > > > > I copy/pasted your key into the TestEncryptInterceptor unit test > > and I didn't get any errors. I generated 4 new 32-character > > (16-byte) keys and tried all of them and didn't get any errors. > > > > Oddly, the very first time I copy/pasted it from your email > > message into the tester it failed with BadPaddingException, but > > when I re-copied "just in case" it stopped failing. Can you > > download and build the 9.0.14 source and run that unit test in your > > environment? Like this: > > > > $ ant test > > -Dtest.entry=org.apache.catalina.tribes.group.interceptors.TestEncrypt > In > > > > > terceptor > > > > If that works, try copy/pasting your key into the source file of > > the test -- it's right up at the top, called "encryptionKey128" -- > > then save and re-run the test (ant will recompile it). If that > > works... then I'm stumped. > > > > -chris > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > I grabbed the src from the site and built it successfully, tried > > the test but it is looking for a message.bin file... > > If the file doesn't exist, it skips the test. That's normal. > > > I tried just touch'ing that file and the first test fails with a > > NegativeArraySizeException > > Right... because it should contain an encrypted message. A zero-byte > file won't be decrypted properly. > > (BTW this explains why I got a BadPaddingException in that *single* > test... I forgot that the test decrypts the file left-behind from the > previous test. This was intentional, to ensure that there wasn't some > magical state being held within the JVM allowing it to decrypt the > message.) > > > and it deletes the message.bin file and the subsequent 2 tests > > can't find it. Is there something special I need to do with that > > message.bin file to run the junit tests? > No. The tests are running as expected. > > > Also, I tried just using the exact encryptionKey128 you had within > > the test class and that one didn't work in my config either, same > > BadPaddingException. > > Try running the test twice in a row. From your output, it looks like > the test runs fine. > > Oh, you meant using my cafebabe key in your setup didn't work? Please > see Keiichi's reply: it seems that the EncryptInterceptor must be > "outside" of the TcpFailureDetector. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwebM8ACgkQHPApP6U8 > pFg2ew/+K1IqiZQR7brZVz7Oi8wa7VdRWvVz8viQDrTj05dbRCdicntdxz7PTWXQ > SGNH/qxXaPfgDHq2N7S8zDHwpj0gTfadn6IFuWUgZYR3jaufpEAS4lmNpyg8e5K4 > +JIacYRZDGaMWzGo+MvhNLPZQ/RhdMc2MMHW6Gmg4PSU7vwYP6o3Pp5TZsOd7U6p > asQKKDfleVjavxeLUOVlUoXwxXIGdYBe8Jd0iuS725xG68GX//8az85nHkbJfrqd > 0jgKx2YpWONStGjOtlsNhBEn9Sj5XTdZ3qJV36O1KtfT1vYBFZtzD748iuLTS+GI > xxcVZuxdZgbF2qrISnPCfjnGVC0lJn6mDJgXMdVNCJ//kqlsrq1BTu5elOgRZxsG > dLNF5WqVdPpBzFnHXaTg1nLxK0/wtox6RVR6ENid5jto6vu+nX5M+Fnus02st5W0 > 7OsKkODnz8Vc32tB1u6HwvfQiVvEYU/kTQhMG6Crvouqzguzl4rjH9A3rLzYugSs > 5bULs57Ac6d+xnp/8lwM0742piCJD60oBHEYqLWDZQjYPc0sIo77bzBceJXk3t4K > tIPZuOJOaQVBTom/CThoWMmliaECD7QL9dJnci2Rr4G8QBL+Bw86vvDOej/HnW6b > N5A1brToQjHJQ7M2DeKm/u+mT0xG8zBgGAI0VL6DK229yOLpvFo= > =nSuF > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Moving the encryption interceptor to the first position appears to have resolved this for me. Thank you all for the assistance!
Re: 9.0.13 encrypted cluster traffic
On Thu, Dec 20, 2018, 10:11 PM Christopher Schultz < ch...@christopherschultz.net wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > On 12/20/18 10:18, Tim K wrote: > >> > >> I just downloaded and tried 9.0.14 but I'm still getting the same > >> BadPaddingException upon starting the second instance. I > >> confirmed the encryptionKey matches on my two instances. > >> > > > > Maybe something is wrong with my config? For this test, I have > > both Tomcats on the same server using different ports: > > This is the only thing that matters to the encryption interceptor: > > > > className="org.apache.catalina.tribes.group.interceptors.EncryptInterc > eptor" > > > > > encryptionKey="e0f2cdf931e99fdce0453964294f97f3" /> > > I'm not sure if the order of encrypt/asyncdispatch interceptors > matters much. > > I copy/pasted your key into the TestEncryptInterceptor unit test and I > didn't get any errors. I generated 4 new 32-character (16-byte) keys > and tried all of them and didn't get any errors. > > Oddly, the very first time I copy/pasted it from your email message > into the tester it failed with BadPaddingException, but when I > re-copied "just in case" it stopped failing. Can you download and > build the 9.0.14 source and run that unit test in your environment? > Like this: > > $ ant test > - -Dtest.entry=org.apache.catalina.tribes.group.interceptors.TestEncryptIn > terceptor > > If that works, try copy/pasting your key into the source file of the > test -- it's right up at the top, called "encryptionKey128" -- then > save and re-run the test (ant will recompile it). If that works... > then I'm stumped. > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwcWdEACgkQHPApP6U8 > pFhClRAAnW4mZ59yG6exLzJqv6nNW8wdUhrLY2eGWFroWN3JMADU7kwA14ndNZfv > iOEIaaE1zvtEiScivqAj6VhIetrb/j07NUSX8eoUYzsEWS6GlFtAY53ok/6xPX4F > 5MUxJTjklQr16C/IAx+4mgbTE/eUKWodfE58Q5sZo6acKxmikwMFFdRkGfqlkLe3 > Gmed6zCHMjbhr/yq3g7J484wEqmzYXhGcOHHfNERxunjrcnfd4m4pqQhjTiLMNRN > wRG6wovEbAwv3P/PPlGu30d776m3OKNAaYIh17AHFEB2dS6Xn5GToMHAyp5nmRFs > Tt+bWhWnB37EmsvvvU+yH17CqUtatdnCw1UHVseoVZGmzefpxQdwuh57Hs1NLSSN > 683giOomSALGWupBd6XV56XfV19k+PuB1gv2He4AfJRmBzJhyS4WTJgwalMcIEOF > 4r2hmJQGhoopTZR3grvycLTzKvSH/s35Lbf2C1BSxZ+lxsig46NYeemX8xe9H39g > s/30ACCNV3h2LUjrqHTQ+wT4VBtOvC7VviZnWzaegmjDuP7xPEENr2uYt230eRGt > Z+WkHrhTkLchwmdK4v1ziCNPgggfI8vEM6IOQwxxmwiwthYpfxA7zDBFgqiJUMO4 > HN/74VauFxG2YeK4LFPYd3i65fCYZRqLceMuzfquYgdmX6ccgQQ= > =IAd9 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org I grabbed the src from the site and built it successfully, tried the test but it is looking for a message.bin file... I tried just touch'ing that file and the first test fails with a NegativeArraySizeException and it deletes the message.bin file and the subsequent 2 tests can't find it. Is there something special I need to do with that message.bin file to run the junit tests? test-nio: [junit] Running org.apache.catalina.tribes.group.interceptors.TestEncryptInterceptor [junit] Tests run: 17, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 0.364 sec [junit] File message.bin does not exist. Skipping test. test-nio2: [junit] Running org.apache.catalina.tribes.group.interceptors.TestEncryptInterceptor [junit] Tests run: 17, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 0.625 sec [junit] File message.bin does not exist. Skipping test. test-apr-exists: test-apr: [junit] Running org.apache.catalina.tribes.group.interceptors.TestEncryptInterceptor [junit] Tests run: 17, Failures: 0, Errors: 0, Skipped: 2, Time elapsed: 0.465 sec [junit] File message.bin does not exist. Skipping test. cobertura-report: test: [concat] Testsuites with skipped tests: [concat] TEST-org.apache.catalina.tribes.group.interceptors.TestEncryptInterceptor.APR.txt [concat] TEST-org.apache.catalina.tribes.group.interceptors.TestEncryptInterceptor.NIO.txt [concat] TEST-org.apache.catalina.tribes.group.interceptors.TestEncryptInterceptor.NIO2.txt [concat] Testsuites with failed tests: BUILD SUCCESSFUL Total time: 11 seconds Also, I tried just using the exact encryptionKey128 you had within the test class and that one didn't work in my config either, same BadPaddingException. -Tim
Re: 9.0.13 encrypted cluster traffic
> > I just downloaded and tried 9.0.14 but I'm still getting the > same BadPaddingException upon starting the second instance. I confirmed > the encryptionKey matches on my two instances. > Maybe something is wrong with my config? For this test, I have both Tomcats on the same server using different ports: server1: server2:
Re: 9.0.13 encrypted cluster traffic
On Wed, Dec 19, 2018, 11:00 PM Christopher Schultz < ch...@christopherschultz.net wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > Tomcat 9.0.14 is available and should work much better. Would it be > possible for you to test the latest release with the encrypted clusterin > g? > > Thanks, > - -chris > > On 11/24/18 11:13, Christopher Schultz wrote: > > Tim, > > > > On 11/23/18 12:55, Christopher Schultz wrote: > >> Okay, the problem is that I built the EncryptInterceptor without > >> realizing that cluster-messaging isn't single-threaded. It's > >> completely non-thread-safe and it needs to be. > > > >> There is a simple fix that can be applied (synchronize the > >> encrypt and decrypt methods) but it'll create a big bottleneck > >> for you. On the other hand, it's easy to apply and test and > >> ensure it's working in your environment. Are you willing to grab > >> the Tomcat source and compile it? If you get the 9.0.13 source > >> and are able to compile it, I can give you a 2-line patch that > >> should fix your issue. Alternatively, I can give you a patched > >> catalina-tribes.jar that you can just drop-in-replace to try > >> out. > > > >> I have a more elaborate patch that I'm going to apply soon and it > >> should be available in the next release of Tomcat 9. > > > > I think this should be fixed, now. If you build from trunk, I > > think things will work remarkably better for you. Or, just wait > > until the next release (a few weeks maybe). If you *can* build from > > source, it would be great to get some real-world mileage on this > > code before the next release. > > > > -chris > > > > - > > > > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlwbE9MACgkQHPApP6U8 > pFhHPQ/+PMCSp8YuG811TLmzZg91gdgbxXgMOKrSnNDh/w3paiUhQD2+uPW8FPbP > 3E8yRgN34JOm+r5ND3x57e3TpXXO9QzQ287d7Pka2RxLlkz4tj/wPbRmyiNaot/t > f/IjVx0NdLdfCxEkntcTAwQUUkqP6VM8umrN2URJqsWqTVs0tqFGMtw2xe8zVCIT > FkZCfwTqGFCHa65iCTlA8LCJbhc1E1d8lDJVBetYrEREE//3y6U1xEbfOJPcKdEv > s8RsTcdOt4A0iQDyqdY0Zsj58Bb6xSUfdRVSqgmQDUDUF3SQLif9a38VNwp2xaPE > BgQiiLHa6Mpmd2+2iZPM/k3GcTSVeFq21opvmlKmYI1QNhy++UsOHbQ1KaSPbDed > GIQ+MWE8K4SPIbX3RSz9lJqKySJabDsQliI+Cfktz6Q0MhvQoFH33E2IsrxgFUxn > 3tU/Yyaa6fUpRYmWuersKU2ps3BMoMT4dwou57cQiTqcgHDVYXcXj64pJv5EM2Ap > /dL1pzAlv0mKkS+wIeFraVvAbH0qeg2sjk0kEjQTN+hrYi74UpKrp076Oc2i8TUI > Wc7TmSiuBqpAIjNb3oLjs1EjbI/B8V2tULOUJYlWz2GTPSdJAQp/u/8lQpu26m6W > EisenCnlc18ANvuIko/ZqlXNKrYIkociip1krluNGH2gCmq/6N4= > =5/TA > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org I just downloaded and tried 9.0.14 but I'm still getting the same BadPaddingException upon starting the second instance. I confirmed the encryptionKey matches on my two instances. > >
Re: 9.0.13 encrypted cluster traffic
On Wed, Nov 21, 2018, 9:48 AM Christopher Schultz < ch...@christopherschultz.net wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > On 11/20/18 13:36, Tim K wrote: > > On Tue, Nov 20, 2018, 12:19 PM Christopher Schultz < > > ch...@christopherschultz.net wrote: > > > > Tim, > > > > On 11/20/18 11:42, Tim K wrote: > >>>>> > >>>>> Ignore the secure port. The code behind that setting was > >>>>> never implemented. We really should remove it. > >>>>> > >>>>> You want: > >>>>> > >>>>> http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-interceptor > .ht > > > >>>>> > ml#org.apache.catalina.tribes.group.interceptors.EncryptInterceptor_Attr > > <http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-interceptor.ht > ml#org.apache.catalina.tribes.group.interceptors.EncryptInterceptor_Attr > <http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-interceptor.html#org.apache.catalina.tribes.group.interceptors.EncryptInterceptor_Attr> > > > > > > > ibutes > >>>>> > >>>>> > >>>>> > > Mark > >>>> > >>>> > >>>> I'm having some trouble getting it working. Can you provide > >>>> an example of the new EncryptInterceptor with an algorithm > >>>> and key? > > > > Each node in the cluster needs an interceptor configured, like > > this: > > > > > className="org.apache.catalina.tribes.group.interceptors.EncryptInterc > ep > > > > > tor" > > encryptionKey="[the key]" /> > > > > All nodes need the same key. The default algorithm > > (AES/CBC/PKCS12Padding) is sufficient. > > > > To generate a key, just get some random garbage and convert it > > into hex, like this: > > > > $ dd if=/dev/urandom bs=128 count=1 2>/dev/null | md5 > > > > That'll give you a 128-bit key you can use for encryption. You can > > also use a 256-bit key if you'd like, or a 192-bit key. For keys > > larger than 128 bite (32 bytes), you'll need to use a different > > signature algorithm such as sha1 or later. > > > > I just chose MD5 because it generates the right number of output > > characters for a 128-bit key. You can get your random key from > > anywhere, including pounding on the keyboard. Remember that the > > key must be in hex-encoded binary (so only characters 0-9 and > > a-f). > > > > -chris > >> > >> - > >> > >> > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > I tried this between 2 nodes but it fails with this error on each: > > > > dd if=/dev/urandom bs=128 count=1 2>/dev/null | md5sum > > e0f2cdf931e99fdce0453964294f97f3 - > > > > > className="org.apache.catalina.tribes.group.interceptors.EncryptInterc > eptor" > > > > > encryptionKey="e0f2cdf931e99fdce0453964294f97f3" /> > > > > 20-Nov-2018 13:31:20.070 SEVERE > > [Tribes-Task-Receiver[Catalina-Channel]-1] > > org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.messa > geReceived > > > > > Failed to decrypt message > > > > javax.crypto.BadPaddingException: Given final block not properly > > padded. Such issues can arise if a bad key is used during > > decryption. > > Both nodes have the same encryption key, right? The key itself looks > fine. For example, I dropped that key into the unit test file and it > worked as expected. > > I've been working on a patch yesterday and today that uses random IVs > instead of re-using them. It really shouldn't change anything about > the config, etc. but both nodes will require the new code to re-test. > I've also expanded the unit tests to cover cipher block modes other > than CBC. > > I don't actually have a cluster here for testing, though, so > everything is being done with the unit tests. > > I thought I had reproduced your issue (BadPaddingException) except it > turned out that the test itself was wrong and the interceptor code was > correct. > > Are you able to build from source? I'm about to commit these changes > to the trunk (9.0.x), which really shouldn't change anything for you, > but it might fix some edge case that you are hitting. > > - -chris > -BEGIN PGP SIGNATURE- &
Re: 9.0.13 encrypted cluster traffic
On Tue, Nov 20, 2018, 12:19 PM Christopher Schultz < ch...@christopherschultz.net wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > On 11/20/18 11:42, Tim K wrote: > >> > >> Ignore the secure port. The code behind that setting was never > >> implemented. We really should remove it. > >> > >> You want: > >> > >> http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-interceptor.ht > ml#org.apache.catalina.tribes.group.interceptors.EncryptInterceptor_Attr > <http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-interceptor.html#org.apache.catalina.tribes.group.interceptors.EncryptInterceptor_Attr> > ibutes > >> > >> > >> > Mark > > > > > > I'm having some trouble getting it working. Can you provide an > > example of the new EncryptInterceptor with an algorithm and key? > > Each node in the cluster needs an interceptor configured, like this: > > className="org.apache.catalina.tribes.group.interceptors.EncryptIntercep > tor" > encryptionKey="[the key]" /> > > All nodes need the same key. The default algorithm > (AES/CBC/PKCS12Padding) is sufficient. > > To generate a key, just get some random garbage and convert it into > hex, like this: > > $ dd if=/dev/urandom bs=128 count=1 2>/dev/null | md5 > > That'll give you a 128-bit key you can use for encryption. You can > also use a 256-bit key if you'd like, or a 192-bit key. For keys > larger than 128 bite (32 bytes), you'll need to use a different > signature algorithm such as sha1 or later. > > I just chose MD5 because it generates the right number of output > characters for a 128-bit key. You can get your random key from > anywhere, including pounding on the keyboard. Remember that the key > must be in hex-encoded binary (so only characters 0-9 and a-f). > > - -chris > -BEGIN PGP SIGNATURE- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlv0Qg0ACgkQHPApP6U8 > pFhEMg//fqPv9UfiJ0H1XYSEhca0+XANYY11wdJCrUzjFZrBKweZtsPwBm6VErw1 > 65xx/SiBBtcbp317VoBNjrrMtgCWVxNuz9FG6YKqXuWu2PeFSlB9C8vHfsMEce2B > 1Jk8TixIdw7zWx4IHVgQsPIKvszQ9YsjMeMa2wTK8Us1AB3HEkwHYiV84UckdQmH > 3oac1rGS+4YxAvpYSe7WF4rRAusKkKLC/1hgbiF+pEPPoax2g8sDW/Upk2ijEWIe > 5B5qrpH9fJIeuQjsR0xlZWEuyQ3KQpdu9j6DyhJnjAqBFLyyg6TiD3uD3M3ZO3es > xgwlLd8C0BDS8ZzpvPOyN3IyygEwVas1+v8YHhqJF8VedGfZVkBplGKuNm7Yoqrg > 1OxGGKCN06cVG+TbH3JzLfuhoYMNN92soqZH+Nm9BUf9G3A5Ll2oTDDYO1peyhHw > kw3FigfUueNPM/sjb42wJp2QvSm9jpRDr8S/Vrv8SxpKmmwgGM/VDNlDcbccRQ5s > FtY3inV9KNH7n2+V69yY8at50HKn4pTLvBRFncZ5pLoOE5DfhVt9PZeefMKzAQQd > LGUJa7Fl+5wovL++Sclaf/MYBJ9BNSg1gpw+P33ga/c63G0JR9lzM9e8xYELJ6Mu > 44GJAgwGzAOq2/TSimmVEffERRxXRTErRORMgG5Qo8KFDsfoDvo= > =J0P5 > -END PGP SIGNATURE- > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org I tried this between 2 nodes but it fails with this error on each: dd if=/dev/urandom bs=128 count=1 2>/dev/null | md5sum e0f2cdf931e99fdce0453964294f97f3 - 20-Nov-2018 13:31:20.070 SEVERE [Tribes-Task-Receiver[Catalina-Channel]-1] org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.messageReceived Failed to decrypt message javax.crypto.BadPaddingException: Given final block not properly padded. Such issues can arise if a bad key is used during decryption. at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:991) at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:847) at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) at javax.crypto.Cipher.doFinal(Cipher.java:2164) at org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.decrypt(EncryptInterceptor.java:369) at org.apache.catalina.tribes.group.interceptors.EncryptInterceptor.messageReceived(EncryptInterceptor.java:114) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:91) at org.apache.catalina.tribes.group.interceptors.StaticMembershipInterceptor.messageReceived(StaticMembershipInterceptor.java:96) at org.apache.catalina.tribes.group.ChannelInterceptorBase.messageReceived(ChannelInterceptorBase.java:91) at org.apache.catalina.tribes.group.ChannelCoordinator.messageReceived(ChannelCoordinator.java:274) at org.apache.catalina.tribes.transport.ReceiverBase.messageDataReceived(ReceiverBase.java:261) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.drainChannel(NioReplicationTask.java:213) at org.apache.catalina.tribes.transport.nio.NioReplicationTask.run(NioReplicationTask.java:101) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)
Re: 9.0.13 encrypted cluster traffic
> > Ignore the secure port. The code behind that setting was never > implemented. We really should remove it. > > You want: > > http://tomcat.apache.org/tomcat-9.0-doc/config/cluster-interceptor.html#org.apache.catalina.tribes.group.interceptors.EncryptInterceptor_Attributes > > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org I'm having some trouble getting it working. Can you provide an example of the new EncryptInterceptor with an algorithm and key?
9.0.13 encrypted cluster traffic
I see encrypted cluster traffic has been added to 9.0.13, but upon using a securePort on the NioReceiver and StaticMember, I'm still able to see clear text information being passed around with Wireshark... Is there some other config to set to take advantage of this new feature? Thank you.
SSL Encryption for Cluster Conversations (NioReceiver and Members)
Using latest Tomcat 9.0.11. I'm using the securePort attribute for both the NioReceiver and StaticMembers but when capturing and inspecting the traffic over the secure ports with WireShark, I'm seeing all my session data in clear text, even my username as password (user principal)! I tried removing the port attribute from both, elements, leaving just the securePort there but this does not encrypt the traffic.
Re: Cluster more than 2 tomcat servers
On Fri, Sep 7, 2018, 2:35 AM Jäkel, Guido wrote: > Dear Tim, > > maybe you can do an "independent" check using the JGroups lib stand-alone, > which offers two sets of a cluster demo. This may help to narrow down the > issue to the Tomcat setup or the "other" (OS or network configuration) > areas. > > Please refer to http://www.jgroups.org/tutorial-3.x/html_single/ , > section "1.4. Running a Demo Program" > > You just need the lib and a JVM, i.e. you can use it out of the box at > your Tomcat machines. The "Draw Demo" requires Graphics, but you also may > use another Testcase offering a textmode receiver and sender. You may start > this receivers on every machine and then one or more senders on demand. > > On both demo's, cluster status messages are displayed on stdout. > > > Here my somewhat older starter scripts: > > > root@genless /opt/jgroups # cat _receiver > ( cd `dirname $0` || exit 1 > java -cp jgroups.jar org.jgroups.tests.McastReceiverTest -mcast_addr > 224.10.10.10 -port $@ > ) > > root@genless /opt/jgroups # cat _sender > ( cd `dirname $0` || exit 1 > java -cp jgroups.jar org.jgroups.tests.McastSenderTest -mcast_addr > 224.10.10.10 -port $@ > ) > > root@genless /opt/jgroups # cat _draw-demo > ( cd `dirname $0` || exit 1 > java -Djava.net.preferIPv4Stack=true -cp jgroups.jar > org.jgroups.demos.Draw $@ > ) > > root@genless /opt/jgroups # tree > . > |-- _draw-demo > |-- _receiver > |-- _sender > |-- _src > | |-- jgroups-2.9.0.GA.jar > | `-- jgroups-3.0.10.Final.jar > `-- jgroups.jar -> _src/jgroups-3.0.10.Final.jar > > > Yours > > Guido > Thank you Guido. That appears to be using multicast which I'm not using at the moment, I'm trying to use static members with the secure ports. Everything works fine with my config if I don't use the secure ports... So I would think that would rule out OS or Networking issues... >
Re: Cluster more than 2 tomcat servers
> > Can you post your configuration(s)? Presumably, all 4 are nearly > identical. Please post one of them (minus any secrets) and describe or > copy/paste the differences for the other notes. > > - -chris > > Here is my cluster config that I got working, all 4 nodes can talk to each other after I added them as StaticMembers (without this, the mcast appeared that 2 of them would pair up with each other). I now was interested in setting these up with SSL (securePorts), so for both the NioReceiver and the StaticMember(s), I removed port="4000" in favor of securePort="4000" (I did replace the securePort="-1" in the StaticMembers). In doing this and starting them all up, it appears to act the same as it did with mcast without StaticMembers, 2 of them pair up instead of all 4 joining the single cluster. I don't understand why this is happening.
Cluster more than 2 tomcat servers
I'm experimenting with Tomcat 9.0.8 enabling Cluster support. I've uncommented the line for it within the server.xml. I have 4 separate servers on different hosts, all with the same config, except unique jvmRoute values. Upon startup, it appears that server1 and server4 pair up and server2 and server3 pair up, every time! I'm using the default udp multicast, again, just uncommenting the single cluster line in server.xml. I'm expecting that all 4 would see each other and I would have a single cluster of 4, not 2 clusters of 2. I confirmed each server can see each other over port 4000. Any help is appreciated. Regards, Tim
Re: Persist authenticated sessions across tomcat restarts
On Tue, Jul 31, 2018, 7:42 AM Burghard Britzke wrote: > that is, what „transient“ means... > -- > Gruß > burghard.britzke > https://britzke.berlin/ > > Am 31.07.2018 um 13:39 schrieb Tim K : > > On Tue, Jul 31, 2018, 7:31 AM Felix Schumacher < > felix.schumac...@internetallee.de> wrote: > > Am 30.07.2018 17:57, schrieb Tim K: > > On Mon, Jul 30, 2018, 4:26 AM Felix Schumacher < > felix.schumac...@internetallee.de> wrote: > > Am 27.07.2018 13:36, schrieb Tim K: > > Hello, > > I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live > servers: linux). > > I have successfully created a custom JAAS authentication, which works > just > fine. > > I have SSO enabled at the moment, but not sure if I really need it. > > I left the default StandardManager config in place, I do see > the SESSIONS.ser get created upon a shutdown and I see it get removed > upon > startup, so I'm assuming it's reading it in... > > I'm expecting that once a user authenticates with the JAAS module one > time, > and has a valid session, if I restart tomcat on the backend, that user > will > NOT need to re-authenticate, but it appears to be kicking them back to > the > login screen after the restart, and it's not accepting their > > JSESSIONID > > cookie value, it's giving them a new one upon hitting a secured > resource. > > From what I've read, I believe that JAAS can cache an authenticated > session, but it doesn't appear to be working for me. Is there > something > I'm missing? Also, I'm using form-login. > > > Are your Principal classes serializable? > Do you see any Exceptions in the log files when you restart Tomcat? > > Regards, > Felix > > > Thank you, > > Tim > > > > No exceptions in log. And it doesn't work even when I don't store > anything within the session. > > > I have digged deeper now and it seems that the principal object is > removed from the session before it is persisted. > > In StandardSession.java you can find the following comment: > > /** >* The authenticated Principal associated with this session, if any. >* IMPLEMENTATION NOTE: This object is not saved and >* restored across session serializations! >*/ > protected transient Principal principal = null; > > > This variable stores the authenticated user. > > Regards, > Felix > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > So are you saying that persisting the authenticated session is not > possible with tomcat? > > I stumbled upon this page: https://gist.github.com/tdakanalis/06d168925f80a72859cb It appears you can do it with some customization.
Re: Persist authenticated sessions across tomcat restarts
On Tue, Jul 31, 2018, 7:31 AM Felix Schumacher < felix.schumac...@internetallee.de> wrote: > Am 30.07.2018 17:57, schrieb Tim K: > > On Mon, Jul 30, 2018, 4:26 AM Felix Schumacher < > > felix.schumac...@internetallee.de> wrote: > > > >> Am 27.07.2018 13:36, schrieb Tim K: > >> > Hello, > >> > > >> > I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live > >> > servers: linux). > >> > > >> > I have successfully created a custom JAAS authentication, which works > >> > just > >> > fine. > >> > > >> > I have SSO enabled at the moment, but not sure if I really need it. > >> > > >> > I left the default StandardManager config in place, I do see > >> > the SESSIONS.ser get created upon a shutdown and I see it get removed > >> > upon > >> > startup, so I'm assuming it's reading it in... > >> > > >> > I'm expecting that once a user authenticates with the JAAS module one > >> > time, > >> > and has a valid session, if I restart tomcat on the backend, that user > >> > will > >> > NOT need to re-authenticate, but it appears to be kicking them back to > >> > the > >> > login screen after the restart, and it's not accepting their > JSESSIONID > >> > cookie value, it's giving them a new one upon hitting a secured > >> > resource. > >> > > >> > From what I've read, I believe that JAAS can cache an authenticated > >> > session, but it doesn't appear to be working for me. Is there > >> > something > >> > I'm missing? Also, I'm using form-login. > >> > >> Are your Principal classes serializable? > >> Do you see any Exceptions in the log files when you restart Tomcat? > >> > >> Regards, > >> Felix > >> > >> > > >> > Thank you, > >> > > >> > Tim > > > > > No exceptions in log. And it doesn't work even when I don't store > > anything within the session. > > I have digged deeper now and it seems that the principal object is > removed from the session before it is persisted. > > In StandardSession.java you can find the following comment: > > /** > * The authenticated Principal associated with this session, if any. > * IMPLEMENTATION NOTE: This object is not saved and > * restored across session serializations! > */ > protected transient Principal principal = null; > > > This variable stores the authenticated user. > > Regards, > Felix > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > So are you saying that persisting the authenticated session is not > possible with tomcat?
Re: Persist authenticated sessions across tomcat restarts
On Mon, Jul 30, 2018, 4:26 AM Felix Schumacher < felix.schumac...@internetallee.de> wrote: > Am 27.07.2018 13:36, schrieb Tim K: > > Hello, > > > > I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live > > servers: linux). > > > > I have successfully created a custom JAAS authentication, which works > > just > > fine. > > > > I have SSO enabled at the moment, but not sure if I really need it. > > > > I left the default StandardManager config in place, I do see > > the SESSIONS.ser get created upon a shutdown and I see it get removed > > upon > > startup, so I'm assuming it's reading it in... > > > > I'm expecting that once a user authenticates with the JAAS module one > > time, > > and has a valid session, if I restart tomcat on the backend, that user > > will > > NOT need to re-authenticate, but it appears to be kicking them back to > > the > > login screen after the restart, and it's not accepting their JSESSIONID > > cookie value, it's giving them a new one upon hitting a secured > > resource. > > > > From what I've read, I believe that JAAS can cache an authenticated > > session, but it doesn't appear to be working for me. Is there > > something > > I'm missing? Also, I'm using form-login. > > Are your Principal classes serializable? > Do you see any Exceptions in the log files when you restart Tomcat? > > Regards, > Felix > > > > > Thank you, > > > > Tim > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > No exceptions in log. And it doesn't work even when I don't store > anything within the session.
Persist authenticated sessions across tomcat restarts
Hello, I'm creating a new app under Tomcat 9.0.8 (local dev: windows, live servers: linux). I have successfully created a custom JAAS authentication, which works just fine. I have SSO enabled at the moment, but not sure if I really need it. I left the default StandardManager config in place, I do see the SESSIONS.ser get created upon a shutdown and I see it get removed upon startup, so I'm assuming it's reading it in... I'm expecting that once a user authenticates with the JAAS module one time, and has a valid session, if I restart tomcat on the backend, that user will NOT need to re-authenticate, but it appears to be kicking them back to the login screen after the restart, and it's not accepting their JSESSIONID cookie value, it's giving them a new one upon hitting a secured resource. >From what I've read, I believe that JAAS can cache an authenticated session, but it doesn't appear to be working for me. Is there something I'm missing? Also, I'm using form-login. Thank you, Tim
