Apologies for the late reply.
The parameterized environment is useful, however our primary usecase for this would be migrating existing environments with large catalogs, for which it would be onerous to go through this way. This way would allow using backups from existing instances without any real changes to the existing environment. I also have not looked into how the environment parameterization interacts with encryption or being used with a custom catalog/resource store, which is another requirement we have in mind.
···
On Sat, Feb 3, 2018 at 5:41 AM, Alessio Fabiani <alessio.fabiani@anonymised.com> wrote:
Hello Devon,
at a first glance I do not envisage any particular technical issue with your approach. I’m just wandering if could be a bit redundant having this hardcoded directly on the backup core code.
I did not dig into your branch in order to see the improvements you have done, but are there specific reasons to add custom parameters to the store? Is there maybe the possibility of having custom parameters for different environments?
If this is not the case, did you already try if it could work with the already in place environment parametrization?
http://docs.geoserver.org/stable/en/user/community/backuprestore/configtemplate.html
In the case you cannot afford this with the approach above or it would require too much work to modify (that feature affects GeoServer core in fact), have you evaluated the possibility of adding some extensions to the Backup and Restore code like for the ResouceInfo ?
http://docs.geoserver.org/stable/en/user/community/backuprestore/extensions.html
Cheers,
-A
Regards,
Alessio Fabiani
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information.
Ing. Alessio Fabiani
@alfa7691
Founder/Technical Lead
GeoSolutions S.A.S.
Via di Montramito 3/A
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 331 6233686
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
AVVERTENZE AI SENSI DEL D.Lgs. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e/o nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceviate questo messaggio senza esserne il destinatario, Vi preghiamo cortesemente di darcene notizia via e-mail e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse, costituisce comportamento contrario ai principi dettati dal D.Lgs. 196/2003.
The information in this message and/or attachments, is intended solely for the attention and use of the named addressee(s) and may be confidential or proprietary in nature or covered by the provisions of privacy act (Legislative Decree June, 30 2003, no.196 - Italy’s New Data Protection Code).Any use not in accord with its purpose, any disclosure, reproduction, copying, distribution, or either dissemination, either whole or partial, is strictly forbidden except previous formal approval of the named addressee(s). If you are not the intended recipient, please contact immediately the sender by telephone, fax or e-mail and delete the information in this message that has been received in error. The sender does not give any warranty or accept liability as the content, accuracy or completeness of sent messages and accepts no responsibility for changes made after they were sent or for other risks which arise as a result of e-mail transmission, viruses, etc.
2018-02-03 0:04 GMT+01:00 Devon Tucker <dtucker@anonymised.com>:
Hi everyone,
Wanted to solicit feedback on an idea. Internally we’d like to use backup/restore more, however how it interacts with encrypted store passwords is a bit of an issue. To that end I have been working on the ability for backup/restore to parameterize outgoing store passwords. I have a branch created with this work:
https://github.com/dvntucker/geoserver/tree/parameterize_passwords
To save people from having to dig, basically all I’ve done is create two new XML persisters, one for data stores that collects the fields that need to be parameterized (similar to what happens now, just collecting a little more info) and a new connections parameters converter that does the actual tokenization:
https://github.com/dvntucker/geoserver/blob/5e1f574c9e428357f6f3c824854936049632bd65/src/community/backup-restore/core/src/main/java/org/geoserver/backuprestore/BackupRestoreItem.java#L185
Next steps would be to update the restore job to do the token replacement, plus options in the UI and rest interface
Unfortunately, I realized a little too late that there is sort of an existing solution to this, which is the capability to parameterize the entire environment, but AFAICT this doesn’t work well with encrypted passwords. Personally, I like the approach of just replacing the password in the backups, since it requires less specialized config.
Any thoughts on this approach? Any potential issues? Any issue with contributing something along these lines?
Cheers,
Devon
Check out the vibrant tech community on one of the world’s most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
Geoserver-devel mailing list
Geoserver-devel@anonymised.comrge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel