Please I need help resolving why a form upload may not work on aggregate.
We installed on one server and it works fine and forms upload well.
we then copied the aggregate folder from tomcat webapps to a different
tomcat on a second system (windoze server), everything works fine on this
second system except that upload doesn't work. no errors on the screen,
nothing logged, no forms tables created.
both system are using a mysql backend, and permissions are in order.
I'm not sure others have experienced this but I cant really see any issues
logged.
You can't just copy the aggregate folder, as it has embedded within it the
fully-qualified hostname and ports used to communicate with the server on
which it is deployed. Either run the installer to generate an appropriate
war file for the new hostname, ports and database, or, to do it manually,
the relevant file to change is .../WEB-INF/lib/odk-settings.jar (this is
what is created during the install process). The relevant files to change
within that jar are (1) jdbc.properties -- to alter what database is being
used and (2) server.properties -- to alter what hostname, port, etc. is
used when interacting with the server.
If you just copy the directory over, the upload-form window that is
rendered when talking to server2 will, in fact, upload the form definition
to server1.
Mitch
···
On Mon, Nov 21, 2011 at 5:07 AM, Ime Asangansi wrote:
Hi,
Please I need help resolving why a form upload may not work on aggregate.
We installed on one server and it works fine and forms upload well.
we then copied the aggregate folder from tomcat webapps to a different
tomcat on a second system (windoze server), everything works fine on this
second system except that upload doesn't work. no errors on the screen,
nothing logged, no forms tables created.
both system are using a mysql backend, and permissions are in order.
I'm not sure others have experienced this but I cant really see any issues
logged.
Thanks for the quick reply.
I had actually changed those files before I built the war using the batch
file
and I have same settings for the second system ie same db and server
credentials.
Now, I've decided to use the installer but I get this; openid_login.html has resulted in too many redirects
If you are mucking with the configuration files, within the
server.properties file, you can specify an ODK superUser here:
security.server.superUserUsername=
This will initialize the system with an ODK user with this username that is
treated as a superUser.
The initial password for that user is "aggregate" and can be changed (and
should be).
The UI doesn't quite render correctly for ODK super-users (it is not an
exposed/supported functionality), so the SiteAdmin page might be a bit
funky.
Finally, note that 'localhost' is not going to allow a client to download
data from your server. Depending upon how you are going to connect devices
to your system to access the server (for downloading forms or uploading
submissions), you may find it useful to configure your system with a static
IP address and use that or configure it to be a gateway for the networked
devices and associate a name with your server within that gateway software
(e.g., via /etc/hosts).
Tech support for documenting or describing how to actually do that is
beyond my abilities at this time.
Mitch
···
On Tue, Nov 22, 2011 at 3:33 AM, asangansi wrote:
I've now solved the login issue by using 'localhost' as fully qualified
hostname.
But I'm wondering why you need to login for an offline system. is it
possible to avoid that initial openid authentication for offline systems?