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 > > > > >
