Ok I've figured out the issue I'm having, once again due to my not doing due diligence. I should have looked closer at the install script. In these cases, I already had a geonode database set up on the production side. I had, incorrectly, assumed that it was like using postgres on a development version and that you set up the database first and that the install script read the password from the settings file. In fact it is the other way around: the pw is generated and written to the local_settings file. Given my different structure for settings files* it didn't even update the password. I just need to write my own install script; simple solution.
There is one minor issue, probably related to the my use case of make_release not being for what it was originally intended for? I want to take my dev version and transfer it to a prod server, which means I want to change my local settings file so it packages the right one. However, the package step includes packing up the settings file (in pavement.py this is the package_webapp function). if you skip this stage you will be stuck with whatever the settings file was at the last packaging. Instead, I commented out the build step from the packaging. * am using GeoNode with multiple sites using django's Sites framework. Each site has it's own Setting file to set site specific variables (SITE_ID, SITEURL, etc) which uses exec() to include a settings_global file. The settings_global file then uses exec() to include a settings_local_dev.py or a settings_local_prod.py file depending on if it's production or development. Thus, the local_settings file that the install script updates is never looked at. - matt On Thu, Mar 8, 2012 at 10:43 AM, David Winslow <[email protected]> wrote: > Setting the password should be an install-time thing, not really related to > the packaging. This patch is applied: > https://github.com/GeoNode/geonode/blob/master/shared/package/support/geonetwork.patch > > Are you using the install.sh script to set up your server? I don't think it > persists the database password anywhere other than the geonetwork config, so > it would be randomly regenerated for each install. > > -- > David Winslow > OpenGeo - http://opengeo.org/ > > On Thu, Mar 8, 2012 at 10:38 AM, Matthew Hanson > <[email protected]> wrote: >> >> Thanks David, >> >> I think this may be related issue, or more specifically a side effect >> of not doing the build with make_release.? >> >> I did paver make_release and skipped packaging. No problem. >> However, I then got a Search error, which was an exercise in keeping >> my sanity due to the general dearth of meaningful errors in the >> geonetwork log....turns out, the database password for geonode that's >> in geonetwork's config.xml file was incorrect. It was *not* >> incorrect when I didn't skip packaging. So I assume that it is in >> the build step that reads the db password from the settings file and >> updates geonetworks config file. >> >> It's not a huge problem since I can just manually update it, but it >> would be nice to know where that step is taking place. >> >> - matt >> >> >> >> On Wed, Mar 7, 2012 at 1:03 PM, David Winslow <[email protected]> >> wrote: >> > The geonode build script could definitely use a little love. However, if >> > you've already done a build then you can skip "packaging" in making a >> > release (packaging in the sense of packaging up all the geonode >> > subprojects, >> > i guess.) with the "skip_packaging=y" flag. I do a full build for >> > actual >> > releases, but for just testing I usually use this option. >> > >> > $ paver skip_packaging=yes make_release >> > >> > The syncdb shouldn't affect the correctness (the database is not >> > included in >> > the package) but you're right that it's not appropriate for the >> > packaging >> > process. >> > >> > -- >> > David Winslow >> > OpenGeo - http://opengeo.org/ >> > >> > On Wed, Mar 7, 2012 at 12:14 PM, Matthew Hanson >> > <[email protected]> wrote: >> >> >> >> Hello, >> >> >> >> I've been trying to make the step of moving between my development >> >> version and production version seamless, so the paver make_release >> >> function seemed to be exactly what I needed. In pavement.py >> >> make_release calls package_all, but package_all has 'build' as a >> >> prerequisite. >> >> >> >> I don't understand why, if you want to build a package for installing, >> >> why you would want to rebuild it. The biggest problem is that for my >> >> release I change out local_settings....but then during the build >> >> process it calls syncdb....but I don't want it to syncdb at that >> >> point, the whole thing will be installed and sync on another machine. >> >> Calling syncdb on my dev machine with my production local_setttings >> >> of course won't work. Can I safely comment out the build step from >> >> the package building process or is there something I am missing here >> >> and that it needs to be rebuilt before packaging for deployment ? >> >> >> >> @needs( >> >> 'build', >> >> 'package_geoserver', >> >> 'package_geonetwork', >> >> 'package_webapp', >> >> 'package_bootstrap' >> >> ) >> >> def package_all(options): >> >> info('all is packaged, ready to deploy') >> >> >> >> >> >> >> >> Matt Hanson >> >> Applied GeoSolutions >> >> 403 Kent Place >> >> Newmarket, NH 03857 >> > >> > > >
