genex-dev — GeneX developers

[GeneX-dev] Installation experience..

[Michael P. <mic...@ho...>]

Hi Jason,

Here is some feedback regarding pre6...it is looking really good. There =
is only
one problem that really should be addressed in your script: make sure =
that when
an executable is supplied that it REALLY is an executable file instead =
of a directory.

Other than that, many of the other things are fine tuning or =
documentation in the INSTALL
doc.

Great work! I know you'll be glad when this is over.

Regards,

Michael Pear

-----------------------------------
****It is possible to enter a directory name as a substitute for an =
executable in the section asking program names, and it is particularly =
sticky once this is done. After installing dtd2html in my local =
directory not in the path, I accidentally entered /var/genex/local/bin =
without pointing all the way to the executable. After that, the only way =
I could recover was to edit the Bio/Genex/Config.pm file directly. Even =
when I ask to answer the installation questions again, it appears that =
it is checking the location of the executables rather than asking, so it =
keeps finding the directory. I think this is the most critical issue =
left in the installation, for those of us prone to making mistakes.

***Perl modules are still one of the  most difficult to get right. I =
suggest you recommend XML::Parser and XML::DOM to make sure that parser =
works right before other tests.
The problem with the XQL tests throws  a wrinkle in because those =
problems are acceptable, but ones with the XML:Parser for example =
aren't. Harry noted that Class::ObjectTemplate isn't brought in =
automagically through dependency when installing =
Class::ObjectTemplate::DB, so you need to make those separate.

**Rcluster queue_master gets mentioned, but I didn't need to start it =
before to get Rcluster to work..why not? ***Also, what happens on system =
reboot?=20

**Installation itself completing  with no errors depends on dtd2html, it =
appears, so you might as well check earlier and kick things out if the =
it isn't installed.

**Question reusing cached values vs. setting new values is confusing. =
Currently, the formatting always throws  me.I never quite know until I =
read the question several times what enter will do. I suggest changing =
this to a yes/no question with yes as default. "Enter/No" isn't really a =
common way people look at answering questions.

*Looks like all doc mods are made to INSTALL..README is out of date and =
probably should be removed or changed to refer installer to INSTALL =
file.

*-init-dump.pl assumes write permissions for the postgres user to the =
install database so that init-dump.pl can be created. Perhaps should be =
noted  in instructions, or can init-dump.pl be created in a tmp location =
and used from there? Any other things written?

*Readonly and genex passwords password not masked on entry he first =
time. The genex password is requested later on and it is masked and =
verified. Does it need to ask twice?

*Java dependency should be noted for Jpython. Jpythonc is part of =
Jpython1.1. Direct installer to look for JPython1.1 rather than =
jpythonc. It isn't clear what this is used for on the server, anyways. =
Can it be left out? I thought this was more of a development issue for =
the dendogram applet. (It will be nice to get rid of this in a future =
release, python may be a great scripting language, but you have plenty =
of languages to go around at the moment in GeneX!)

*Xgobi directory requested.why? Xgobi/xgvis are requested later on =
independent of this request. Also, it sort of throws me off in the flow =
because my first instinct when it asks for xgobi again is to enter a =
directory, not the executable.=20

*/usr/sbin/sendmail not detected, although it is a common location often =
not in  non-root user's path.

*Looking for xcluster in path, but executable by default  from stanford =
is cluster in xcluster directory.

*Missed picking up existing tmp file definition in rerun of install. =
Most values are picked up and presented as defaults, but tmp file =
definition is not for some reason.=20

=20

Re: [GeneX-dev] extra gibberish at top of list messages?

[Greg D. C. <gd...@nc...>]

This is what it looks like to me. Since I did a REPLY TO I assume your filter 
will not recognize the lines anymore. The header you see in my REPLY copy should 
have 17 lines. I have enclosed this area with two dashed lines.

By the way there is another odd behavior. When I do a REPLY TO ALL with my 
mailer the group address (gen...@li...) appears twice.

Another strange thing I haven't analyzed is when Jason sends mail to this list, 
I get two copies of his email. I don't believe this has happened with anyone 
else.

Greg

----------------------------------
>From: Harry Mangalam <man...@ho...>
>X-Accept-Language: en
>MIME-Version: 1.0
>To: genexdev at SF <gen...@li...>
>Content-Transfer-Encoding: 7bit
>Subject: [GeneX-dev] extra gibberish at top of list messages?
>X-BeenThere: gen...@li...
>X-Mailman-Version: 2.0
>List-Help: <mailto:gen...@li...?subject=help>
>List-Post: <mailto:gen...@li...>
>List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/genex-dev>, 
<mailto:gen...@li...?subject=subscribe>
>List-Id: GeneX Developers' List <genex-dev.lists.sourceforge.net>
>List-Unsubscribe: <http://lists.sourceforge.net/lists/listinfo/genex-dev>, 
<mailto:gen...@li...?subject=unsubscribe>
>List-Archive: <http://lists.sourceforge.net/archives//genex-dev/>
>Date: Wed, 24 Jan 2001 17:14:17 -0800
----------------------------------
>
>Hi All,
>
>Greg says that there are several extra lines at the top of things that get sent 
to the SF genex list (ie this message).  I don't see them (using Netscape mail); 
does anyone else?  could be they escape
>the header filter for Greg's mail reader?
>-- 
>Cheers,
>Harry
>
>Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev

[GeneX-dev] extra gibberish at top of list messages?

[Harry M. <man...@ho...>]

Hi All,

Greg says that there are several extra lines at the top of things that get sent to the SF genex list (ie this message).  I don't see them (using Netscape mail); does anyone else?  could be they escape
the header filter for Greg's mail reader?
-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...

Re: [GeneX-dev] Server 1.0.0-pre6, DB 0.8.1

[Harry M. <man...@ho...>]

"Jason E. Stewart" wrote:
> NOTICE: You must install two new pieces of software for this release
> 
> * You must install one new software utility: dtd2html from
>   perlSGML.2001Jan23.tar.gz off: ftp://genex.sourceforge.net/pub/genex/

This worked fine.

> * There are two new required CPAN modules:
>   - Class::ObjectTemplate::DB

this requires installation of 'Class::ObjectTemplate' 1st

ie

perl -MCPAN -e shell
cpan> install Class::ObjectTemplate

...installation churn ..

cpan> install Class::ObjectTemplate::DB




>   - Term::ReadKey

This installs fine with the std CPAN install:

cpan> install Term::ReadKey

hjm


[deletia]
---

Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...

[GeneX-dev] Re: Streamlining repetitive data entry..

[Michael P. <mic...@ho...>]

Hi Greg,


> Michael:
>
> I am really impressed that you had the patience to go into the Curation
Tool
> code.
>

I thought that is what open source is all about.

> We have spent a lot of time in the past thinking about this problem, and
came to
> the conclusion it is better to implement the USE AS TEMPLATE button.
Here's
> why...

I don't think it is an question of preferring one approach over another.
There is room for both.

>
> If you make an ADD button have defaulted fields, it is in effect a MODIFY
> button. This confuses the meaning of ADD. As a user, I have no way to get
a set
> of blank fields if ADD always produces default values.

ADD = create a new entry
MODIFY=change an existing entry

>
> USE AS TEMPLATE gives the user more power over the default values. It does
not
> simply rely on the last values (although I suspect, as with virtual
memory, that
> the last values entered make the best defaults for the next pass).
>
> Finally, the USE AS TEMPLATE button will do a deep copy clone of the
record it
> is templating. This means that all screens at all levels below will have
the
> correct default values, and all records will already be saved. I don't
think
> this happens in ADD mode. I think you must force each screen entered to
have its
> dirty bit set to guarantee a save if the user changes no values in the
screen.
> Or am I missing something here?

I think your intention for USE A TEMPLATE is becoming clearer...if I USE A
TEMPLATE
on a Hybridization set, then it clones all of the array measurements and
spot data in it as well.
COPY might be a more clear term for this operation.

Regards,

Michael Pear

[GeneX-dev] Server 1.0.0-pre6, DB 0.8.1

[<ja...@op...>]

Hey,

So, it took longer than I expected. Two attempts at the server
release, and three attempts on the DB release...

I do not yet have a way to upgrade an existing DB via XML. That will
have to happen on the next DB update, sorry.

I also put the DB dumps in the genex public ftp site:
   ftp://genex.sourceforge.net/pub/genex/

NOTICE: You must install two new pieces of software for this release

* You must install one new software utility: dtd2html from
  perlSGML.2001Jan23.tar.gz off: ftp://genex.sourceforge.net/pub/genex/

* There are two new required CPAN modules: 
  - Class::ObjectTemplate::DB 
  - Term::ReadKey

RELEASE NOTES:

New user-defined configuration options:
===========================
 * CURATOR_EMAIL -- person/group to receive exp set submission notices
 * GENEX_SECRET -- LoginUtil.pm MD5 secret

Changes to install-all
======================
- no more chown() calls (super user no longer required)
- dtd2html automatically creates HTML versions of DTDs
- genex UserSec account information installed 
- all commands run quiet unless --VERBOSE is used
- RCluster installation better integrated
- passwords no longer echoed to command line

Changes to Genex.pm
===================
- Now uses permanent namespace, Bio::Genex
- Now uses Class::ObjectTemplate::DB instead of ObjectTemplate 
- All classes related to Canonical Sequence Feature are gone


Changes to db2xml
=================
- Experiment set caching now works
- User/Password authentication is now optional
- contact information retrieved directly through new contact methods instead of indirectly via UserSec entries

Changes to WWW
==============
- more pages substituted to remove hard-code URLs

Bugs Fixed
===========
- all NCGR hard-code emails replaced with CONTACT_EMAIL or CURATOR_EMAIL
- fixed write permissions all on directories
- control bundle download directory now in CGITMPDIR (no more write permission in HTMLDIR)
- fixed get_objects() for linking table classes
- check_password() no longer calls die() on bad password
- RCluster queuemaster is now started in install-all

Re: What To Do Next? (was: Re: [GeneX-dev] Re: usersec table)

[<ja...@op...>]

"Jiaye Zhou" <ze...@in...> writes:

> Hi Greg,
> 
> On Tue, 23 Jan 2001, Greg D. Colello wrote:
> > >We don't need to re-write anything to communicate over SSL. All we
> > >have to do is run an SSL-enable apache, and all our CGI scripts will
> > >work fine. We were supposed to be doing that all along. 
> > 
> > This is true. But it does also require that each lab that installs
> > GeneX and wants SSL must SSL-enable their apache. That costs extra
> > money from RedHat or requires we add a new set of modules to our
> > distribution.
> 
> Hmmm, Apache-SSL comes with the distribution. It is freely available
> anyway...

on a debian system it's as simple as 'apt-get install apache-ssl', and
wait a minute while it downloads the package and installs it. Free as
free can be, and pretty darn simple, too.

> > I think we need to address this question if we wish to rapidly extend our 
> > install base or even attract new developers.
> 
> Yes indeed! Perhaps we are better off spending time on some of these issues? 
> I agree that the SSL improvements that have been discussed are useful. But
> I don't know how big an issue it really is at this point, especially if
> someone installs GeneX in his or her lab, or on their own network...On the
> other hand improvements on better addressing research needs will be a lot
> more noticable and attractive to potential users.

I think SSL will be good for NCGR. They will want it for their
collaborators. I would suggest making it a fee-for-service module, but
we wrote it into the grant.

jas.

Re: What To Do Next? (was: Re: [GeneX-dev] Re: usersec table)

[Jiaye Z. <ze...@in...>]

Hi Greg,

On Tue, 23 Jan 2001, Greg D. Colello wrote:
> >We don't need to re-write anything to communicate over SSL. All we
> >have to do is run an SSL-enable apache, and all our CGI scripts will
> >work fine. We were supposed to be doing that all along. 
> 
> This is true. But it does also require that each lab that installs GeneX and 
> wants SSL must SSL-enable their apache. That costs extra money from RedHat or 
> requires we add a new set of modules to our distribution.

Hmmm, Apache-SSL comes with the distribution. It is freely available
anyway...

> User response to GeneX seems to be that we have done a great job laying down a 
> foundation, but what does the system do for me now? How do I use it to solve the 
> problems I have on my mind? In other words users are impressed with our 
> technical vision, but it isn't clear to them how to use the system to address 
> issues of immediate importance to them. Thus, systems like Silicon Genetics, 
> that seem targeted to answer research questions, have an edge on us. A simple 
> example of how this plays out is right in our backyard (UNM).
> 
> I think we need to address this question if we wish to rapidly extend our 
> install base or even attract new developers.

Yes indeed! Perhaps we are better off spending time on some of these issues? 
I agree that the SSL improvements that have been discussed are useful. But
I don't know how big an issue it really is at this point, especially if
someone installs GeneX in his or her lab, or on their own network...On the
other hand improvements on better addressing research needs will be a lot
more noticable and attractive to potential users.

Jiaye

[GeneX-dev] ultramonkey.sourceforge.net

[<ja...@op...>]

We've been talking about load balancing and queueing especially in
regards to CPU intensive tasks like RCluster.

I gave a cursory glance at ultramonkey. It might be useful.

jas.

What To Do Next? (was: Re: [GeneX-dev] Re: usersec table)

[Greg D. C. <gd...@nc...>]

Jason:


>Delivered-To: fix...@li...@fixme
>To: gen...@li...
>Subject: Re: [GeneX-dev] Re: usersec table
>Mime-Version: 1.0 (generated by tm-edit 1.5)
>From: ja...@op... (Jason E. Stewart)
>List-Archive: <http://lists.sourceforge.net/archives//genex-dev/>
>Date: 22 Jan 2001 22:10:28 -0700
>

>In general, we have way more things to do than time and money to do
>them.

Agreed.

>To my mind re-writing what already works (even if it's
>sub-optimal) is a spectacular waste of time, and money.

I know where you are coming from on this. But I'm not sure that's going to work, 
considering the audience.

>We don't need to re-write anything to communicate over SSL. All we
>have to do is run an SSL-enable apache, and all our CGI scripts will
>work fine. We were supposed to be doing that all along. 

This is true. But it does also require that each lab that installs GeneX and 
wants SSL must SSL-enable their apache. That costs extra money from RedHat or 
requires we add a new set of modules to our distribution.

>So of course we could do a whole lot better than everything we've
>already done, but wouldn't it be a good idea to be smart about we
>spend our time on? Here's my tentative list:
>
>1. Get a full GeneX release on sourceforge
>2. Get all developer modules in CVS on sourceforge
>3. Spread the word about the open source GeneX project
>4. Improve the query interface to do real queries instead of
>   pre-canned ones
>5. Add more analysis tools
>6. Improve how GeneXML communicates data
>7. Improve the data model to support security
>8. Improve the data model to support updates

This gets at the heart of what we must decide in the next couple of weeks. What 
is our strategy? The above items certainly make sense in light of past 
discussions, but I don't think it's simply a matter of adding more analyses or 
queries. I suggest we step back a bit and ask ourselves what it is we are trying 
to accomplish before we decide what new features we are planning to add.

User response to GeneX seems to be that we have done a great job laying down a 
foundation, but what does the system do for me now? How do I use it to solve the 
problems I have on my mind? In other words users are impressed with our 
technical vision, but it isn't clear to them how to use the system to address 
issues of immediate importance to them. Thus, systems like Silicon Genetics, 
that seem targeted to answer research questions, have an edge on us. A simple 
example of how this plays out is right in our backyard (UNM).

I think we need to address this question if we wish to rapidly extend our 
install base or even attract new developers.

Greg

Re: [GeneX-dev] RCluster fixes, release delays

[<ja...@op...>]

"Greg D. Colello" <gd...@nc...> writes:

> Hey. That's good news.
> 
> >I've checked in some major changes to rcluster. Sorry no code
> >improvements, just installation improvements. It is now completely
> >integrated into the rest of the installation process, and I even fixed
> >a bug along the way.

Maybe yes, maybe no. I hope it was good. In the short run it was
stupid. I could have broken it completely. I was just so irritated at
having CVS tell me that I had modified rcluster files that I hadn't
checked in, when I didn't.

Andrew Dalke is very clever. And I recognize a pattern that he and I
share, we can easily find ways to fix problems that often works
complete around the way things were intended to be done. Andrew
created some really elaborate installation stuff that he didn't need
to. Perl will do most of it for you if you let it. Because Andrew's
code wasn't letting Perl handle the installation, things were overly
complex.

So: 
1) I gave all his modules an appropriate namespace under RCluster::*
   (appropriate meaning they all live in the unifying RCluster::
   namespace, and they all begin with a capital Letter -- all
   lowercase module names should be reserved for compiler pragmas). 
2) I also removed his file substitution mechanism, and used the one
   built in to the installer (all files with substitutable parameters
   start life as a '.in' file, e.g. configure.pl.in, then the
   substitution program takes all .in files, substitutes any
   parameters and creates the real file, e.g. configure.pl). That way
   we have all the .in files checked into CVS, and *not* the files
   with your installation-specific information in them. 

This was the piece that ticked me off so much, Andrew's substitution
mechanism modified the CVS files *in-place*, so CVS thought I had code
changes that needed to be checked in.

So, like I said the module organization is still as confusing as ever,
8 different modules that are only about 100 lines long and all seem to
include each other, but at least the installation is cleaner...

jas.

Re: [GeneX-dev] RCluster fixes, release delays

[Greg D. C. <gd...@nc...>]

Hey. That's good news.

Greg

>Delivered-To: fix...@li...@fixme
>To: gen...@li...
>Mime-Version: 1.0 (generated by tm-edit 1.5)
>From: ja...@op... (Jason E. Stewart)
>Subject: [GeneX-dev] RCluster fixes, release delays
>X-BeenThere: gen...@li...
>X-Mailman-Version: 2.0
>List-Help: <mailto:gen...@li...?subject=help>
>List-Post: <mailto:gen...@li...>
>List-Subscribe: <http://lists.sourceforge.net/lists/listinfo/genex-dev>, 
<mailto:gen...@li...?subject=subscribe>
>List-Id: GeneX Developers' List <genex-dev.lists.sourceforge.net>
>List-Unsubscribe: <http://lists.sourceforge.net/lists/listinfo/genex-dev>, 
<mailto:gen...@li...?subject=unsubscribe>
>List-Archive: <http://lists.sourceforge.net/archives//genex-dev/>
>Date: 23 Jan 2001 00:02:13 -0700
>
>Hey All,
>
>I've checked in some major changes to rcluster. Sorry no code
>improvements, just installation improvements. It is now completely
>integrated into the rest of the installation process, and I even fixed
>a bug along the way.
>
>Meanwhile, I like to wait to cut the new release until after I run the
>install on genesoup and Harry tries it on Harwin, this should make the
>new release ready around lunch tomorrow.
>
>jas.
>
>_______________________________________________
>Genex-dev mailing list
>Gen...@li...
>http://lists.sourceforge.net/lists/listinfo/genex-dev

[GeneX-dev] Warning: Testing new CVS code

[<ja...@op...>]

Hey,

Harry and others, if you're going to try the new installer code I
checked in last night make sure you run 'cvs update -d', because there
was a directory that got renamed.

jas.

[GeneX-dev] Why CVS is so good ...

[<ja...@op...>]

I created a separate installation branch a week ago to Change Genex.pm
over to the namespace that I registered with the Comprehensive Perl
Archive Network (CPAN). I had been using just Genex::* as a toplevel
namespace, but that made little sense as a global module, so I
registered it as Bio::Genex::*

It took me a few days to get that branch working completely, and then
I let it hang to work on other pieces. 

It just took me a little over 5 minutes to merge in namespace changes
into around 300 files from the branch into the main trunk. Most of
those 5 minutes was spent typing ChangeLog entries before I ran the
merge ...

No conflicts, totally automatic. 

I love CVS,
jas.

[GeneX-dev] RCluster fixes, release delays

[<ja...@op...>]

Hey All,

I've checked in some major changes to rcluster. Sorry no code
improvements, just installation improvements. It is now completely
integrated into the rest of the installation process, and I even fixed
a bug along the way.

Meanwhile, I like to wait to cut the new release until after I run the
install on genesoup and Harry tries it on Harwin, this should make the
new release ready around lunch tomorrow.

jas.

Re: [GeneX-dev] Re: usersec table

[<ja...@op...>]

I'd rather avoid an advocacy of whether Java or Perl or better
languages. 

I agree that the use of a browser in between the curation tool was a
hack. It was a hack that was supposed to enable us to have a working
prototype a year ago. Well that prototype was more than a year in the
making, it's here now, so good riddance to the browser.

I'm glad that we now have a module that enables the CT to speak SSL on
it's own. That's a big improvement.

The control bundle process being slow has nothing to do with the
browser, or the internet. The expat library which generates the
control bundle is written in optimized C code, even though it has perl
interface. Java won't make that faster. The real slowdown is *what* is
in the control bundle. It is fat and bloated and shouldn't be. One way
to fix that if for the curation tool to keep it's own local mini-genex
DB, and store what it needs, getting updates only when needed, instead
of downloading everything each time it logs on.

In general, we have way more things to do than time and money to do
them. To my mind re-writing what already works (even if it's
sub-optimal) is a spectacular waste of time, and money. We already
have an experiment set submission script, and although it's made of
bailing wire, it works. I'd be thrilled if anybody re-wrote it to be
better.

We don't need to re-write anything to communicate over SSL. All we
have to do is run an SSL-enable apache, and all our CGI scripts will
work fine. We were supposed to be doing that all along. 

The whole point of the meeting we had in Nov. was to identify what are
the most *important* things to do, prioritize things, and get to work,
either fixing what's broke, or adding new features.

I think have a Java API to the DB would wonderful. That would enable
you and everyone else to write client side applications that talk
directly to the DB. This is what we've wanted all along. It would be a
big boost to the project.

However, the server side doesn't really need it. Once the Java API is
written, sure, replace the Perl CGI scripts if you want, but that just
seems like a real low priority compared to enable client-side access
to the DB.

There's a lot of things I wish I had time to make more sexy, but if I
want to get GeneX working, and get more developers adding code, than
there is a lot of stuff that I need to get done. In case you hadn't
noticed, we are losing NCGR developers on this project a lot faster
than we are getting new ones. If we want to make any real progress we
will need to win over more talented people like Michael Pear as
quickly as possible. To do that we fist need a functional system,
which luckily we seem to finally have. Second we need to make it
available to the outside world, which I am busting my butt to do,
about 10-12 hours/day. And third, we need to document the hell out
things, which luckily, a lot has already been done.

So of course we could do a whole lot better than everything we've
already done, but wouldn't it be a good idea to be smart about we
spend our time on? Here's my tentative list:

1. Get a full GeneX release on sourceforge
2. Get all developer modules in CVS on sourceforge
3. Spread the word about the open source GeneX project
4. Improve the query interface to do real queries instead of
   pre-canned ones
5. Add more analysis tools
6. Improve how GeneXML communicates data
7. Improve the data model to support security
8. Improve the data model to support updates

That's a big list.

jas.


"Todd Peterson" <tf...@nc...> writes:

> We have a lot of trouble with browsers. The SSLServer takes care of the
> things that make life difficult on the curation tool side. The current issue
> is that logins, control-bundle downloads, experiment set downloads and
> experiment set submittals are not secure (just checked to confirm). They
> travel on an unencrypted socket in both directions. The control bundle
> download process is slow and full of ways to mess up (another separate
> issue...I think the database/web interface should be re-written using Java;
> servlets or SSL sockets), the user is relied upon to put the file in the
> correct location, the user is relied upon to select the correct control
> bundle in the correct location, the browser may mangle the filename, etc.,
> etc. The web server really doesn't have to be modified to implement this
> change. It's really just another module on the server side. The benefits are
> non-reliance on browser configuration, secure communications using sound
> certificate authentication technology, speed improvement (I'll bet $1) and a
> project-wide movement to standardization on a common language (Java). Right
> now, the tools for the GeneX suite are a hodge-podge of baling-wire, twine
> and duct-tape. We can do better than that.
> 
> Todd
> 
> ----- Original Message -----
> From: "Jason E. Stewart" <ja...@op...>
> To: "Todd Peterson" <tf...@nc...>
> Cc: <gen...@li...>
> Sent: Monday, January 22, 2001 3:32 PM
> Subject: [GeneX-dev] Re: usersec table
> 
> 
> > "Todd Peterson" <tf...@nc...> writes:
> >
> > > This is for curation tool. Password would come from user on curation
> > > tool to web server (connection encrypted by SSL, certificates signed
> > > and authenticated on both sides, public keys exchanged and
> authenticated,
> > > etc.).  Java SSLServer on Web server would query usersec
> > > table and attempt to match userid/password. If match SSLServer
> > > responds to curation tool with OK, otherwise responds with ERROR.
> >
> > I believe it's secure. So you're writing a Java module that's needed
> > by the server? I'm a bit Java stupid, so pardon any ignorance, but
> > what is Java SSLServer? Is there some way that we can reuse the
> > existing CGI scripts instead of making new ones?
> >
> >
> > > ----- Original Message -----
> > > From: "Jason E. Stewart" <ja...@op...>
> > > To: "Todd Peterson" <tf...@nc...>
> > > Cc: <gen...@li...>
> > > Sent: Monday, January 22, 2001 2:07 PM
> > > Subject: Re: usersec table
> > >
> > >
> > > hmm..taking my entry for example:
> > >    31   53  tfp          tf32BeZ2ZCE9o
> > > and using the crypt shell command I try:
> > > echo tf32BeZ2ZCE9o | crypt tf
> > > and get garbage
> > > what am i missing?
> > >
> > > even tried:
> > > echo print(crypt("tf32BeZ2ZCE9o", "tf")); > temp.pl
> > > perl < temp.pl
> > > tfUTCnrBskQVU
> >
> > crypt() encrypts the password, not decrypts it. So in perl you would
> > way to check:
> >    crypt($salt, $plain_text_pwd) eq $encrypted_pwd
> >
> >
> > so if you have a command-line crypt, then you would want:
> >    echo $plain_text_pwd |crypt $salt
> >
> > I tried it using the command line crypt() on solaris and got
> > crap. However, perl on solaris gives the proper answer. I have no idea
> > what the interface to the command line version is supposed to be,
> > sorry.
> >
> > jas.
> >
> > _______________________________________________
> > Genex-dev mailing list
> > Gen...@li...
> > http://lists.sourceforge.net/lists/listinfo/genex-dev
> >
> 
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev

Re: [GeneX-dev] Re: usersec table

[Todd P. <tf...@nc...>]

We have a lot of trouble with browsers. The SSLServer takes care of the
things that make life difficult on the curation tool side. The current issue
is that logins, control-bundle downloads, experiment set downloads and
experiment set submittals are not secure (just checked to confirm). They
travel on an unencrypted socket in both directions. The control bundle
download process is slow and full of ways to mess up (another separate
issue...I think the database/web interface should be re-written using Java;
servlets or SSL sockets), the user is relied upon to put the file in the
correct location, the user is relied upon to select the correct control
bundle in the correct location, the browser may mangle the filename, etc.,
etc. The web server really doesn't have to be modified to implement this
change. It's really just another module on the server side. The benefits are
non-reliance on browser configuration, secure communications using sound
certificate authentication technology, speed improvement (I'll bet $1) and a
project-wide movement to standardization on a common language (Java). Right
now, the tools for the GeneX suite are a hodge-podge of baling-wire, twine
and duct-tape. We can do better than that.

Todd

----- Original Message -----
From: "Jason E. Stewart" <ja...@op...>
To: "Todd Peterson" <tf...@nc...>
Cc: <gen...@li...>
Sent: Monday, January 22, 2001 3:32 PM
Subject: [GeneX-dev] Re: usersec table


> "Todd Peterson" <tf...@nc...> writes:
>
> > This is for curation tool. Password would come from user on curation
> > tool to web server (connection encrypted by SSL, certificates signed
> > and authenticated on both sides, public keys exchanged and
authenticated,
> > etc.).  Java SSLServer on Web server would query usersec
> > table and attempt to match userid/password. If match SSLServer
> > responds to curation tool with OK, otherwise responds with ERROR.
>
> I believe it's secure. So you're writing a Java module that's needed
> by the server? I'm a bit Java stupid, so pardon any ignorance, but
> what is Java SSLServer? Is there some way that we can reuse the
> existing CGI scripts instead of making new ones?
>
>
> > ----- Original Message -----
> > From: "Jason E. Stewart" <ja...@op...>
> > To: "Todd Peterson" <tf...@nc...>
> > Cc: <gen...@li...>
> > Sent: Monday, January 22, 2001 2:07 PM
> > Subject: Re: usersec table
> >
> >
> > hmm..taking my entry for example:
> >    31   53  tfp          tf32BeZ2ZCE9o
> > and using the crypt shell command I try:
> > echo tf32BeZ2ZCE9o | crypt tf
> > and get garbage
> > what am i missing?
> >
> > even tried:
> > echo print(crypt("tf32BeZ2ZCE9o", "tf")); > temp.pl
> > perl < temp.pl
> > tfUTCnrBskQVU
>
> crypt() encrypts the password, not decrypts it. So in perl you would
> way to check:
>    crypt($salt, $plain_text_pwd) eq $encrypted_pwd
>
>
> so if you have a command-line crypt, then you would want:
>    echo $plain_text_pwd |crypt $salt
>
> I tried it using the command line crypt() on solaris and got
> crap. However, perl on solaris gives the proper answer. I have no idea
> what the interface to the command line version is supposed to be,
> sorry.
>
> jas.
>
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev
>

Re: [GeneX-dev] IGNORE this too - more foolishness

[Harry M. <man...@ho...>]

Harry Mangalam wrote:
> 
> Sorry abot this,.
> --
> Cheers,
> Harry
> 
> Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...
> 
> _______________________________________________
> Genex-dev mailing list
> Gen...@li...
> http://lists.sourceforge.net/lists/listinfo/genex-dev

-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...

[GeneX-dev] IGNORE - just testing some foolishness

[Harry M. <man...@ho...>]

Sorry abot this,.
-- 
Cheers,
Harry

Harry J Mangalam -- (949) 856 2847 (v&f) -- hj...@nc... || man...@ho...