I'm just glancing at the code...
Reporting does this:
AdministrationService adminService = Context.getAdministrationService();
String userName =
adminService.getGlobalProperty(SchedulerConstants.SCHEDULER_USERNAME_PROPERTY);
String password =
adminService.getGlobalProperty(SchedulerConstants.SCHEDULER_PASSWORD_PROPERTY);
Context.authenticate(userName, password);
The quickest fix would be to just /not/ call Context.authenticate if
the password GP is not set, and do a log.warn instead. This would mean
that you could safely set up OpenMRS, though reporting's scheduled
tasks won't start working until you set the GPs. (And if you type the
password wrong in the GP, or you change the user's password without
changing the GP, the bug Mark mentioned will recur.)
Does that sound okay as a quick fix to unblock 1.9?
The "correct" fix requires figuring out how to have AbstractReportTask
(which isn't an OpenMRS scheduled task) be run as Daemon in 1.7+.
-Darius
On Tue, Apr 10, 2012 at 7:03 PM, Darius Jazayeri
<[email protected] <mailto:djazayeri%[email protected]>> wrote:
Burke, FYI, the Reporting and Logic modules both are written
against OpenMRS 1.6, whereas Daemon wasn't introduced until 1.7.
Logic already has some ugly reflection code to try using the
Daemon to run its scheduled task, and otherwise falls back to
proxy privileges, or something like that. I think Reporting needs
something similar.
Once we actually stop supporting OpenMRS 1.6, writing modules will
get easier, with respect to this, and also the improved activator
interface.
-Darius
On Tue, Apr 10, 2012 at 6:34 PM, Burke Mamlin
<[email protected] <mailto:[email protected]>> wrote:
Reporting should not be able to run something as Daemon; in
fact, it should be impossible to authenticate as the daemon
user. Rather, daemon threads can only be created by Daemon
and it will only start those things that it knows about.
Logic was known by Daemon because it was part of core. As
logic moves out of core, we'll need to come up with another
mechanism for Daemon to know about it (and reporting).
One such mechanism is schedule tasks. We trust that only
admins (e.g., admins installing a module) can add a scheduled
task; therefore, one of the things Daemon knows how to do is
to start an existing scheduled task.
If you don't want to be limited to scheduled tasks, we could
do something similar for modules – e.g., define a method for
OpenMRS modules (within the module interface) that Daemon
would know about and could invoke on a daemon thread.
Alternatively, you could start your processes during module
startup by spawning another daemon thread (daemon threads,
like the thread used for module startup, should be able to ask
Daemon to spawn another daemon thread).
-Burke
On Tue, Apr 10, 2012 at 8:40 PM, Michael Seaton
<[email protected] <mailto:[email protected]>> wrote:
I think we probably need to fix reporting to do what Ben
said Logic is doing. However, if the OpenMRS scheduler
benefits from use of the Daemon user "for free" in 1.7+,
we'll likely need to explicitly tell reporting to use the
Daemon user for the Spring-managed scheduled tasks.
Unfortunately, we're in a reporting sprint right now, so
we're not in the ideal position to patch reporting to work
with 1.9...
Mike
On 04/10/2012 08:14 PM, Darius Jazayeri wrote:
So what's the implication for what we should do with 1.9?
Is it a fix to 1.9.x to include the right reporting version?
Is it a fix to reporting to avoid running the tasks if it
doesn't have a username/password?
-Darius
On Tue, Apr 10, 2012 at 4:36 PM, Michael Seaton
<[email protected] <mailto:[email protected]>> wrote:
One wrinkle is that we (I) moved these tasks in 1.7.1
such that they are no longer scheduled tasks executed
by the OpenMRS scheduler, but rather tasks managed
directly by Spring's built-in scheduling mechanism.
The main reason for making this change was that I
didn't like how the OpenMRS scheduler-based Scheduled
Tasks hung around after the module was un-installed
and also because I was running into some Classloading
issues. With Spring-managed scheduled tasks, these
issues disappear - the tasks are run if the module is
installed, and not run if it isn't. The main
drawback is that the end user can't start / stop /
delete these tasks from within the management pages,
but these are not meant to be optional or
configurable - they are things the reporting module
relies on working in a specific way, so shouldn't be
end-user modifiable.
On 04/10/2012 06:37 PM, Ben Wolfe wrote:
The gps should not be set by openmrs after 1.7 the
daemon user is used instead. The reporting module
should work like the logic module and only
authenticate if pre 1.7.
I like the idea of clearing the scheduler gp, but
that might mess up modules like reporting that
haven't updated to not use the authenticated user.
Isnt there an authenticate() method that should be
called? Is that still looking fur the scheduler
username/pw in gps?
Ben
On Apr 10, 2012 6:24 PM, "Darius Jazayeri"
<[email protected]
<mailto:djazayeri%[email protected]>> wrote:
Wyclif,
That won't solve it--when you go through the
setup wizard, you are required to enter a strong
admin password ("test" is not allowed), so what
Mark is describing is the issue that as soon as
you've set up OpenMRS for the first time, you
are guaranteed to have incorrect GP values for
scheduler.username and scheduler.password. As a
result, your admin account will soon be locked
out, and it will stay that way forever due to
the scheduled task.
Options:
1. clear the scheduler.password property, and
make sure that scheduled tasks don't try to run
as admin if that isn't set
2. the setup wizard could set scheduler.password
to the new admin password (but this is insecure)
3. change the reporting module to /not/ use
those GPs, but rather to use an anonymous user,
but grant proxy privileges...
-Darius
On Tue, Apr 10, 2012 at 2:29 PM, Wyclif Luyima
<[email protected] <mailto:[email protected]>>
wrote:
Are you running the standalone or are you
using the 1.9 demo data from the demo data
downloads page?
If yes to any of the above, I ran into this
and i think the password for admin was
changed from *test*, try *Admin123*, we need
to change it back to *test*
Wyclif
On Tue, Apr 10, 2012 at 4:55 PM, Mark
Goodrich <[email protected]
<mailto:[email protected]>> wrote:
I’m having problems logging in to
OpenMRS 1.9 after doing a clean install
(as opposed to an update of an existing
database). Has anyone else run into
this issue? This is what I think might
be happening:
https://tickets.openmrs.org/browse/TRUNK-3272
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
------------------------------------------------------------------------
Click here to unsubscribe
<mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l>
from OpenMRS Developers' mailing list
