Ah... that's the web page I couldn't find (not knowing my way around Spring Cloud). Subject to actually trying it, it looks relatively straight forward.
Thanks! On Wednesday, July 20, 2016 at 3:01:56 PM UTC-4, Misagh Moayyed wrote: > > That is included OOTB. You do not need to do anything extra. > > You are to use this: > > http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_encryption_and_decryption > > I created this issue to explain the above link better from the CAS > perspective: > https://github.com/apereo/cas/issues/1907 > > Keep an eye on that one. Some notes about it will show up in the CAS docs. > > -- > Misagh > > From: David Curry <[email protected]> <javascript:> > Reply: David Curry <[email protected]> <javascript:> > Date: July 20, 2016 at 11:52:30 AM > To: CAS Community <[email protected]> <javascript:> > Cc: [email protected] <javascript:> <[email protected]> <javascript:> > Subject: Re: [cas-user] Questions about configuration management (CAS > 5.0) > > 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]. >> 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/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] <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/1439ec30-708f-43a4-bb43-00932ea64de7%40apereo.org > > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/1439ec30-708f-43a4-bb43-00932ea64de7%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/273a8f20-4fe7-4465-ac4d-ba51a2951a12%40apereo.org. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
