March 2009 - Mg-rast - mailman3.cels.anl.gov

Re: [mg-rast] mg-rast valid users
by Folker Meyer 30 Mar '09

30 Mar '09

Hi Rob, sounds like you are objecting to the idea of having the token timeout? I think having the PW in source code is not a really good idea, how about a compromise, a token that does not expire? this way, users can opt in by creating a token (and or deleting it). Token wouldn't expire, but users can delete it for their account if they want? FOlker On Mar 28, 2009, at 8:58 PM, Rob Edwards wrote: > I think this is a complete programmatic nightmare and against the > entire spirit of web services. We want people (in fact we have > people) writing code to access data in mg-rast. It simply will not > work if they have to stop each time and go get a token. The code > needs to work each time, and there will almost certainly not be a > human to point to a web site. > > Why can't we just pass the password via SOAP? Is it any less secure > than our (non-https) approach we use now? > > Rob > > On Mar 27, 2009, at 10:03 AM, Folker Meyer wrote: > >> Hi Rob: >> >> can we use tokens with a one week timeout instead of passwords? >> >> I think that would make me sleep easier. I also think that we >> should require user to explicitly activate WS support. >> >> They could do that by creating a token. If they don't update the >> token WS access will expire after one week. >> >> We could either use proper public/private-key stuff or create a >> light-weight security a simple token like: $token= md5( drand48() >> + "username" + ctime() ) >> >> The access function could check on the file date for the token, if >> it is older than 7*24hrs, it should return an error msg pointing >> the user to the web page for token renewal. >> >> What do you think? >> >> Best, >> Folker >> >> >> On Mar 27, 2009, at 9:25 AM, Rob Edwards wrote: >> >>> For the web services (and probably else where), I would like a >>> piece of code that takes a username, a password, and an mg-rast >>> job (number, directory, or object ?) and just returns true if that >>> user has the ability to see that job. >>> >>> Is it hard to construct a subroutine that does that? >>> >>> Thanks! >>> >>> Rob >> >

1 0

Re: [mg-rast] format contigs file
by Folker Meyer 30 Mar '09

30 Mar '09

this sounds like a good feature for the next version folker On Mar 30, 2009, at 11:44 AM, Rob Edwards wrote: > Can we (someone?) format the contigs file in the rp/ directory for > (at least) the public metagenomes? It would be great if we could > tblastn individual proteins against those metagenomes .... its > something that a lot of people want to see, and we should probably > provide a web page for it eventually. > > I suggest making the title of the database the same as the genome > name (perhaps with our id at the end) and also putting the formatdb > log into the directory. > > I could do it but don't have perms to write to the rp/ directory. > > Thanks > > Rob

1 0

removing a project
by Alberto Lopez Bueno 30 Mar '09

30 Mar '09

Dear sirs, last friday I uploaded (by error) the same metagenome twice . Could you please remove the analysis of the project with ID number 4443041.3 (Job 3032)? Regards, Alberto Lï¿½pez Bueno, PhD.

1 0

format contigs file
by Rob Edwards 30 Mar '09

30 Mar '09

Can we (someone?) format the contigs file in the rp/ directory for (at least) the public metagenomes? It would be great if we could tblastn individual proteins against those metagenomes .... its something that a lot of people want to see, and we should probably provide a web page for it eventually. I suggest making the title of the database the same as the genome name (perhaps with our id at the end) and also putting the formatdb log into the directory. I could do it but don't have perms to write to the rp/ directory. Thanks Rob

1 0

Re: [mg-rast] mg-rast valid users
by Rob Edwards 28 Mar '09

28 Mar '09

I think this is a complete programmatic nightmare and against the entire spirit of web services. We want people (in fact we have people) writing code to access data in mg-rast. It simply will not work if they have to stop each time and go get a token. The code needs to work each time, and there will almost certainly not be a human to point to a web site. Why can't we just pass the password via SOAP? Is it any less secure than our (non-https) approach we use now? Rob On Mar 27, 2009, at 10:03 AM, Folker Meyer wrote: > Hi Rob: > > can we use tokens with a one week timeout instead of passwords? > > I think that would make me sleep easier. I also think that we should > require user to explicitly activate WS support. > > They could do that by creating a token. If they don't update the > token WS access will expire after one week. > > We could either use proper public/private-key stuff or create a > light-weight security a simple token like: $token= md5( drand48() + > "username" + ctime() ) > > The access function could check on the file date for the token, if > it is older than 7*24hrs, it should return an error msg pointing the > user to the web page for token renewal. > > What do you think? > > Best, > Folker > > > On Mar 27, 2009, at 9:25 AM, Rob Edwards wrote: > >> For the web services (and probably else where), I would like a >> piece of code that takes a username, a password, and an mg-rast job >> (number, directory, or object ?) and just returns true if that user >> has the ability to see that job. >> >> Is it hard to construct a subroutine that does that? >> >> Thanks! >> >> Rob >

1 0

Re: [mg-rast] mg-rast valid users
by Robert Olson 27 Mar '09

27 Mar '09

what are you concerned about here? On Mar 27, 2009, at 12:03 PM, Folker Meyer wrote: > Hi Rob: > > can we use tokens with a one week timeout instead of passwords? > > I think that would make me sleep easier. I also think that we should > require user to explicitly activate WS support. > > They could do that by creating a token. If they don't update the > token WS access will expire after one week. > > We could either use proper public/private-key stuff or create a > light-weight security a simple token like: $token= md5( drand48() + > "username" + ctime() ) > > The access function could check on the file date for the token, if > it is older than 7*24hrs, it should return an error msg pointing the > user to the web page for token renewal. > > What do you think? > > Best, > Folker > > > On Mar 27, 2009, at 9:25 AM, Rob Edwards wrote: > >> For the web services (and probably else where), I would like a >> piece of code that takes a username, a password, and an mg-rast job >> (number, directory, or object ?) and just returns true if that user >> has the ability to see that job. >> >> Is it hard to construct a subroutine that does that? >> >> Thanks! >> >> Rob >

1 0

Re: [mg-rast] mg-rast valid users
by Folker Meyer 27 Mar '09

27 Mar '09

Hi Rob: can we use tokens with a one week timeout instead of passwords? I think that would make me sleep easier. I also think that we should require user to explicitly activate WS support. They could do that by creating a token. If they don't update the token WS access will expire after one week. We could either use proper public/private-key stuff or create a light- weight security a simple token like: $token= md5( drand48() + "username" + ctime() ) The access function could check on the file date for the token, if it is older than 7*24hrs, it should return an error msg pointing the user to the web page for token renewal. What do you think? Best, Folker On Mar 27, 2009, at 9:25 AM, Rob Edwards wrote: > For the web services (and probably else where), I would like a piece > of code that takes a username, a password, and an mg-rast job > (number, directory, or object ?) and just returns true if that user > has the ability to see that job. > > Is it hard to construct a subroutine that does that? > > Thanks! > > Rob

1 0

mg-rast valid users
by Rob Edwards 27 Mar '09

27 Mar '09

For the web services (and probably else where), I would like a piece of code that takes a username, a password, and an mg-rast job (number, directory, or object ?) and just returns true if that user has the ability to see that job. Is it hard to construct a subroutine that does that? Thanks! Rob

1 0

changing metagenome names
by Rob Edwards 27 Mar '09

27 Mar '09

I hope that many of the public metagenomes now have more meaningful names. We updated a whole bunch to try and reduce the confusion about what we have already processed. Rob

1 0

Re: [mg-rast] sge priorities, disk space etc.
by Mark D'Souza 26 Mar '09

26 Mar '09

Thanks Jared. Mark On Thu, 26 Mar 2009, Jared Wilkening wrote: > Neither of those jobs are ours (2949, 2997). > > We currently have ~1T free on job directory space, 230G free on db so we > should be good. > > Jared > > On Thu, Mar 26, 2009 at 3:06 PM, Folker Meyer > <folker.meyer(a)googlemail.com>wrote: > >> Mark: >> >> please check with Jared to see that this is not one of our jobs. >> >> Also, the new titanium jobs are on the order of .5GB a piece. And we want >> to offer a quick turn-around for them >> >> FOlker >> >> >> On Mar 26, 2009, at 12:04 PM, Mark D'Souza wrote: >> >> Hi, >>> >>> The 2949 (550 MB) sims computation is using up all the cluster resources >>> available to mgrast and there are a lot of tiny (< 1MB) jobs in the queue. >>> >>> Can we set the priority of the sge jobs based on the size of the mgrast >>> job so that these go through quickly? >>> >>> I can do this manually, but this time there are a lot of small jobs, and I >>> would also be commandeering cluster resources for jobs which are not really >>> high priority. >>> >>> Also, we have a second large job (2997, > 0.5GB) waiting to be processed. >>> Could someone (i.e. Jared and Bob) check that there is adequate disk space >>> (job directories and database) before these go through? >>> >>> Thanks, >>> Mark >>> >> >> >

1 0