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 [email protected] <javascript:>. > To post to this group, send email to [email protected] <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 [email protected]. To post to this group, send email to [email protected]. 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.
