Joel,

Point taken.

I do think there is some misdirection in this original thread.  One
should be setting the database username/password in the
[dspace-src]dspace/config/dspace.cfg and it will be used during the
fresh install after you've run mvn package.  Perhaps this is another
case where the documentation should be more explicit.

---

Your points are certainly valid when it comes to setting up DSpace on
a server in production where other activities may occur, however, in a
production environment I don't generally recommend running DSpace on a
system with more than just system administrator access requirements in
the shell.  DSpace isn't really designed to be a shell utility, most
of the stuff written to run fromt he command-line has been designed to
be "system/admin" centric.  Its been recognized that commands like
ItemImport and ItemExport somewhat violate this practice/policy and
efforts have been made to create services like SWORD or LNI to replace
those.  Unfortunately, those scripts still exist in the code and
continue to be used by the community instead of focusing on using
these new client/server startegies.

With virtualization and enterprise topologies, I'd more recommend that
if services will be shared that they be scaled by separating the
database service entirely on a separate server firstly.  In which
case, of course greater security would be a best recommendation by not
only using md5, but also restricting access to that data to that
server ip alone.  Likewise in such cases your IT department would not
only be responsible for establishing the security policies and
guidelines appropriate levels of security.

-----

If we wish to change the security recommendations we have recommended
traditionally in the past, someone will need to put forward examples
of these settings and identify the sections that should be changed, we
certainly welcome any contribution an experienced system administrator
such as yourself might be willing to contribute in this area.


Mark


On Fri, Jan 8, 2010 at 7:23 AM, Richard, Joel M <[email protected]> wrote:
> Mark,
>
> This is, of course, if you aren't concerned about someone on that machine 
> deleting all your databases. Do you also allow anyone on localhost to access 
> the root account? :) If so, then that's what you're doing to PostgreSQL if 
> you set the postgres account to "trust".
>
> In today's world, we all need to be conscious of security. If you're talking 
> about a test installation, then yes, "trust" might be appropriate. But if 
> it's a development or production server, then I can't find a reason where 
> "trust" would ever be needed. (On the other hand, "ident" is a bit overkill 
> sometimes.)
>
> I'd say that the Install Docs and the "fresh_install" script need to be 
> updated to encourage "md5" and to supply a password when setting up the 
> database.
>
> --Joel
>
> -----Original Message-----
> From: Mark Diggory [mailto:[email protected]]
> Sent: Thursday, January 07, 2010 2:27 PM
> To: William Hays
> Cc: [email protected]
> Subject: Re: [Dspace-devel] Postgres 8.4.2 client authentication breaks fresh 
> install of DSpace
>
> Bill,
>
> I tend to favor setting postgres to "trust" on localhost, I also
> encountered this on a recent installation on Enterprise RedHat 5 as
> well.
>
> Mark
>
> On Thu, Jan 7, 2010 at 8:38 AM, William Hays <[email protected]> wrote:
>> The most recent Postgres version 8.4.2 has changed the default client
>> authentication mechanisms in pg_hba.conf from "trust" to "ident" and
>> "md5".  This is at least true of the Ubuntu package distribution.  This
>> has the unfortunate result of breaking the fresh_install ant script for
>> deploying DSpace with a database authentication exception.   My
>> experience was with a recent DSpace 1.5.2 distribution.
>>
>> At the very least, DSpace install documentation should probably specify
>> the appropriate authentication mechanism in pg_hba.conf to support the
>> local jdbc connection made by the ant fresh_install script.  Whether
>> this is the most appropriate solution is another question.
>>
>>
>> --
>> ------------
>> William Hays
>> Technology Research & Development
>> MIT Libraries E25-131
>> 617.324.5682 (phone)
>> [email protected]
>>
>>
>>
>> ------------------------------------------------------------------------------
>> This SF.Net email is sponsored by the Verizon Developer Community
>> Take advantage of Verizon's best-in-class app development support
>> A streamlined, 14 day to market process makes app distribution fast and easy
>> Join now and get one step closer to millions of Verizon customers
>> http://p.sf.net/sfu/verizon-dev2dev
>> _______________________________________________
>> Dspace-devel mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>>
>
>
>
> --
> Mark R. Diggory
> Head of U.S. Operations - @mire
>
> http://www.atmire.com - Institutional Repository Solutions
> http://www.togather.eu - Before getting together, get t...@ther
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>



-- 
Mark R. Diggory
Head of U.S. Operations - @mire

http://www.atmire.com - Institutional Repository Solutions
http://www.togather.eu - Before getting together, get t...@ther

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel

Reply via email to