Project

General

Profile

Actions

Bug #4337

closed

cannot submit job, diffs in login.inc

Added by Dmitry Lyumkis almost 8 years ago. Updated over 7 years ago.

Status:
Won't Fix or Won't Do
Priority:
Normal
Category:
-
Target version:
-
Start date:
07/26/2016
Due date:
% Done:

0%

Estimated time:
Affected Version:
Appion/Leginon 3.2
Show in known bugs:
No
Workaround:

Description

We've been recently getting job submission errors after updating Appion. I've been able to pin some things down to differences in login.inc, as per diff trace below (also more clearly in repository between 0e65c028 and 260f023d). Anchi, it seems that you worked on this, can you point me in the right direction to figure out what the users now need to have?

dlyumkis@bpho-bladerunner-1 inc] diff login.inc ../../../myami-trunk-working/myamiweb/inc/
121,122c121
< function checkExptAccessPrivilege($sessionId,$privilege_type='data',$min_privilege_level=1) {
< // return true or redirect
---

function checkExptAccessPrivilege($sessionId,$privilege_type='data') {

134,146c133
< $r = hasExptAccessPrivilege($sessionId,$privilege_type, $min_privilege_level);
< if ( !$r ) {
< // arrives here if no view privilege
< redirect(BASE_URL.'accessdeny.php');
< exit;
< }
< return true;
< }
<
< function hasExptAccessPrivilege($sessionId,$privilege_type='data',$min_privilege_level=1) {
< // return true or false but not redirect
< //Access privilege of data means data viewing/downloading and processing result viewing are allowed
< $userId = getLoginUserId();
---

148,149d134
<
< // administrators
151,152c136
<
< if ($userId && $privilege_level >= $min_privilege_level) {
---

if ($userId && $privilege_level > 0) {

155d138
< // experiment shared to the user
161a145

if ((array)$r) return true;

163,164d146
<
< // project owner
178,180d159
< // arrives here if no privilege
< return false;
< }
182,186c161
< function checkExptAdminPrivilege($sessionId,$privilege_type='data') {
< // Admin privilege of data means data processing and session.comment editing is allowed
< // return true or redirect
< echo "checkingExptAdminPrivilege";
< if ( hasExptAdminPrivilege($sessionId,$privilege_type) ) return true;
---

// arrives here if no view privilege

191,193c166
< function hasExptAdminPrivilege($sessionId,$privilege_type='data') {
< // Admin privilege of data means data processing and session.comment editing is allowed
< // return true or false but not redirect
---

function checkExptAdminPrivilege($sessionId,$privilege_type='data') {

198,199c171,172
< // for other users,data processing is allowed if access is allowed and allow to administrate privilege_type.
< return hasExptAccessPrivilege($sessionId,$privilege_type='data', $min_privilege_level=2);
---

// for other users,data processing is allowed if access is allowed.
return checkExptAccessPrivilege($sessionId,$privilege_type='data');


Files

Actions #1

Updated by Anchi Cheng almost 8 years ago

At which point did you have problem ? All changes in that revision were meant to prevent under privileged users from accessing the processing setup page (i.e., runXXX.php) not for job submission.

The best way to make the user to have proper privilege for data processing is to meet these two criteria.
1. Make them in the "user", not "guest" group.
2. Make them an owner of the project.

Actions #2

Updated by Dmitry Lyumkis almost 8 years ago

I'm seeing this when I submit the job (as per attached image).
This is a bit strange, because I no longer can process with my account, so I suspect that (1) there might be a bug or (2) my configuration setup has always been wrong, and something triggered this issue.
Where, specifically in the database, projectdb, or administration, do the privileges have to be set? Have you guys had any issues on your end?

Actions #3

Updated by Dmitry Lyumkis over 7 years ago

Anchi, you guys have no problems submitting jobs from the web? I cannot seem to get this to work on our end, even for my user ID (oddly). Something switched when I updated last month, which is coming from the new login code, but I'm not sure what. As best as I can tell, all users (including myself) are in the "user" group and owners of the project. I'm putting Sargis on this thread, in case he might have some ideas.
Dmitry

Actions #4

Updated by Sargis Dallakyan over 7 years ago

We have been using myami-beta brunch at NYSBC. I see that the code changes in login.inc are not in myami-beta brunch. Try git clone -b myami-beta http://emg.nysbc.org/git/myami/ to see if it works.

Actions #5

Updated by Anchi Cheng over 7 years ago

Dmitry, login.inc in the two branches are the same. I will write a script for you to test.

Actions #6

Updated by Dmitry Lyumkis over 7 years ago

Sargis, no luck with myami-beta.

Actions #7

Updated by Anchi Cheng over 7 years ago

  • Status changed from New to Won't Fix or Won't Do
  • Assignee changed from Anchi Cheng to Dmitry Lyumkis

Dmitry,

I know we resolve this with something unrelated to what you suspect here. Please say something here so that if someone has the same problem will know where to start.

Thanks.

Actions #8

Updated by Dmitry Lyumkis over 7 years ago

We did several things:

First, there were new python dependencies, h5py, for job submission that Donnie committed, which needed to be installed on our system. This could be figured out by running the runjob.py command manually in a terminal. I executed as root

yum install h5py

Next, each user had to be setup with his/her own sinedon.cfg file, or, alternatively, a global sinedon.cfg file. I did not have a global sinedon.cfg file in my myami installation (/path/to/myami/sinedon/sinedon.cfg), and thus the new user was not able to access it. I made one, and it works. Alternatively, the user could have a local sinedon.cfg file in the home directory.

That is all we did. Hope this helps.

Dmitry

Actions

Also available in: Atom PDF