Thanks for the detailed answers; that all makes sense. The GitHub approach to storing the application.properties file(s) sounds pretty neat; especially if we were to ever do some kind of split on-prem/cloud deployment (which we have been kicking around but won't be in our first iteration).
But what do you do about storing passwords in those files? I see a shortish mention of Java Simplified Encryption in the Security Guide... is that how you handle it? If so, is that included out of the box, or will I need to include something in the Maven overlay? And (of course), is there any guidance about how to actually use it? On Wednesday, July 20, 2016 at 1:31:57 PM UTC-4, Misagh Moayyed wrote: > > > > First, reloading changes. The first paragraph there explains the embedded > configuration server that notices when the application.properties file gets > updated and reloads the properties. But then the second paragraph talks > about an "adopter" needing to submit a request to CAS to refresh its > current state to make the new properties actually take effect. But it > doesn't say whether the embedded configuration server is considered an > adopter. So here's my first point of confusion -- If I edit > application.properties, will those changes take effect all by themselves > just by editing the file? Or do I also need to manually visit the server > dashboard page and click "Refresh"? > > It depends. > > If you are running CAS in embedded mode via the -jar option, any changes > you make to the externally-defined application.properties file must be > refreshed on the dashboard. This is a current limitation of the UI; there > is a screen that shows and lists all your properties, but it doesn’t yet > let you edit them right there. If it did, it would auto-refresh everything > and you wouldn’t have to worry about “where is my application.properties” > file. This bit of UI enhancement will likely not make it to 5 for the GA > release and so for the time being, you edit the file, and you refresh the > config by pressing that button (or you send a POST to the relevant endpoint > which is what that button does). We are working on that missing UI bit to > make sure the screen can be edited, and that will likely make its way into > subsequent patches post the 5 GA release. If it does, saving the > property/change on the UI will do the refresh. One-stop shop. > > If you were running CAS in embedded mode via the native boot plugin, > something we don’t yet have worked out, there is no refresh needed when you > edit settings that are under src/main/resources of your > configuration/overlay regardless of what those settings/files are. That > directory is and will be monitored by the plugin constantly and resources > there will be auto-loaded. This model is best suited for development. A > refresh is still needed for anything that sits outside your “workspace” > directory where your local CAS config files are. Same story with the UI. > > If you are running CAS in an external container, it’s the same as if you > were running it with a -jar option. Refresh is needed. > > > > Next, clustered deployments. I understand that if the Spring Cloud Bus is > configured, then when one of the servers reloads its properties, it will > broadcast them out to the other servers on the bus, so that they all get > them. But here's my next point of confusion -- Let's suppose I have 3 > servers (A, B, and C) and change the properties file on A. The Cloud Bus > will make sure those changes get propagated to the running instances on B > and C, but will it also update the properties file on those two servers? Or > do I need to make sure the files are kept in sync through some out-of-band > process? > > You still need to sync. Changes are not persisted on disk; they are only > broadcasted and applied to the runtime running instance. Ideally, you are > keeping track of those settings in a shared repository where you make a > change in once place and its broadcasted to all nodes. I have tested this > throughly with that repository being github. It’s amazing how Spring Cloud > does it. You make a change, you commit and CAS auto-recognizes it and > shoots a message to all nodes, who then recognize the change and update the > running CAS instance invisibly. > > If you are not using a shared “repository”, as I said, you do need to > sync. > > I have played around with the idea of using something other a properties > file to keep these changes, specially for the implementation of that UI and > specially when you don’t want to deal with source control. (Odd, but it > happens). A lightweight DB table or a MongoDB collection of some sort as an > option which would then allow you to centralize those settings better (and > hey, you can write your own UI on top of that if you wanted to). > > HTH. > > And I’ll see about formulating something intelligent for the docs. Thanks > for the feedback! > > > > Thanks, > --Dave > > > > -- > You received this message because you are subscribed to the Google Groups > "CAS Community" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to cas-user+u...@apereo.org <javascript:>. > To post to this group, send email to cas-...@apereo.org <javascript:>. > Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/ > . > To view this discussion on the web visit > https://groups.google.com/a/apereo.org/d/msgid/cas-user/2148dba1-c059-4c45-babe-4e6c48144924%40apereo.org > > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/2148dba1-c059-4c45-babe-4e6c48144924%40apereo.org?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/a/apereo.org/d/optout. > > -- You received this message because you are subscribed to the Google Groups "CAS Community" group. To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+unsubscr...@apereo.org. To post to this group, send email to cas-user@apereo.org. Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/1439ec30-708f-43a4-bb43-00932ea64de7%40apereo.org. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
