Re: [dspace-tech] Re: vagrant-dspace install issues - librarian-puppet?

[Andrea Schweer]

  
  
Hi all,

I too am having issues with vagrant-dspace -- I'm seeing different
error messages, but they are related to ssh too so perhaps another
symptom of the same problem? 

This is on a Linux machine that was successfully running
vagrant-dspace a few months back, updated to current master of
vagrant-dspace. I added a stanza to Vagrantfile to ensure the
network cable of the virtualbox is plugged in (I had run into this
with a different vagrant box). After that, vagrant up eventually
fails with

The SSH command responded with a non-zero
  exit status. Vagrant
  assumes that this means the command failed. The output for this
  command
  should be in the log above. Please read the output to determine
  what
  went wrong.


Further up in the log  I see failure messages that include
==> vagrant-dspace: Notice:
/Stage[main]/Main/Dspace::Tomcat_instance[/home/vagrant/dspace/webapps]/Service[tomcat]:
  Dependency Exec[Adding the fingerprint for GitHub so we can
  connect to it] has failures: true
  ==> vagrant-dspace: Warning:
/Stage[main]/Main/Dspace::Tomcat_instance[/home/vagrant/dspace/webapps]/Service[tomcat]:
  Skipping because of failed dependencies


and even further up
==> vagrant-dspace: Debug: Exec[Adding
  the fingerprint for GitHub so we can connect to
  it](provider=posix): Executing 'ssh -T -oStrictHostKeyChecking=no
  g...@github.com'
  ==> vagrant-dspace: Debug: Executing 'ssh -T
  -oStrictHostKeyChecking=no g...@github.com'
  ==> vagrant-dspace: Notice:
  /Stage[main]/Main/Dspace::Install[/home/vagrant/dspace]/Exec[Adding
  the fingerprint for GitHub so we can connect to it]/returns:
  Warning: Permanently added 'github.com,192.30.253.112' (RSA) to
  the list of known hosts.
  ==> vagrant-dspace: Notice:
  /Stage[main]/Main/Dspace::Install[/home/vagrant/dspace]/Exec[Adding
  the fingerprint for GitHub so we can connect to it]/returns:
  Permission denied (publickey).
  ==> vagrant-dspace: Error: ssh -T -oStrictHostKeyChecking=no
  g...@github.com returned 255 instead of one of [0,1]
  ==> vagrant-dspace: Error:
/Stage[main]/Main/Dspace::Install[/home/vagrant/dspace]/Exec[Adding
the fingerprint for GitHub so we can connect to it]/returns:
change from notrun to 0 1 failed: ssh -T
-oStrictHostKeyChecking=no g...@github.com returned 255 instead
of one of [0,1]
  ==> vagrant-dspace: Notice:
  /Stage[main]/Main/Dspace::Install[/home/vagrant/dspace]/Exec[Cloning
  DSpace source code into /home/vagrant/dspace-src]: Dependency
  Exec[Adding the fingerprint for GitHub so we can connect to it]
  has failures: true


I tried changing the Vagrantfile stanza to not actually attempt to
talk to github but that didn't help either -- it still tries to do
the fingerprint check (does that come from puppet-dspace?). My
changes are in
https://gist.github.com/aschweer/e521f1831fe874bc3f19a40c395eb513 

vagrant-ssh then ssh -T -oStrictHostKeyChecking=no g...@github.com
gives 
Permission denied (publickey). 
with an exit status of, as it says in the error message, 255.

cheers,
Andrea

-- 
Dr Andrea Schweer
Lead Software Developer, ITS Information Systems
The University of Waikato, Hamilton, New Zealand
+64-7-837 9120
  




-- 
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: vagrant-dspace install issues - librarian-puppet?

[Andrew Parker]

Having a very similar issue.  In the debug log, I can see the warden errors 
at the end of your snippet.  Vagrant up --debug ends with the "SSH 
responded with a non-zero exit status" message.  

I can SSH in, but the /home/vagrant/dspace-src folder is empty and 
/home/vagrant/dspace just contains an empty webapps folder.

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] DSpace deployment environment survey?

[Alan Orth]

Helix,

Popcon is a good example. It would have to be opt in to not be evil.
In the mean time, I've sent the four of you a preview (off list) of
the form I just developed—much quicker than developing plumbing and
infrastructure for the registry! We can discuss a bit off list then
come back here.

Ciao,

On Thu, Nov 17, 2016 at 6:12 PM, helix84  wrote:
> Alan pointed out that there is information about the system
> environment that could be interesting. Some of it is already in the
> registry (OS, DB, type of content, customizations), some isn't
> (OS/Java/DB version, virtualization/containerization technology). He
> also pointed out that a lot of information there is out of date -
> obviously, because it's entered manually.
>
> That's why I suggested improvements to the registry rather than a
> one-time survey:
>
> 1) Make it easier to participate in the registry. Provide benefits to
> those who register and provide their email address by offering
> security alerts. If we're going to have a simplified installation in
> the future, suggest joining the registry and make it trivial to join
> (like http://popcon.debian.org/ ).
>
> 2) Automate everything that can be automated. All this is publicly
> available information (UIs, versions, content statistics) that we
> could harvest regularly and often.
>
>
> Regards,
> ~~helix84
>
> Compulsory reading: DSpace Mailing List Etiquette
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>
> --
> You received this message because you are subscribed to the Google Groups 
> "DSpace Technical Support" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to dspace-tech+unsubscr...@googlegroups.com.
> To post to this group, send email to dspace-tech@googlegroups.com.
> Visit this group at https://groups.google.com/group/dspace-tech.
> For more options, visit https://groups.google.com/d/optout.



-- 
Alan Orth
alan.o...@gmail.com
https://englishbulgaria.net
https://alaninkenya.org
https://mjanja.ch
"In heaven all the interesting people are missing." ―Friedrich Nietzsche
GPG public key ID: 0x8cb0d0acb5cd81ec209c6cdfbd1a0e09c2f836c0

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] DSpace deployment environment survey?

[helix84]

Alan pointed out that there is information about the system
environment that could be interesting. Some of it is already in the
registry (OS, DB, type of content, customizations), some isn't
(OS/Java/DB version, virtualization/containerization technology). He
also pointed out that a lot of information there is out of date -
obviously, because it's entered manually.

That's why I suggested improvements to the registry rather than a
one-time survey:

1) Make it easier to participate in the registry. Provide benefits to
those who register and provide their email address by offering
security alerts. If we're going to have a simplified installation in
the future, suggest joining the registry and make it trivial to join
(like http://popcon.debian.org/ ).

2) Automate everything that can be automated. All this is publicly
available information (UIs, versions, content statistics) that we
could harvest regularly and often.


Regards,
~~helix84

Compulsory reading: DSpace Mailing List Etiquette
https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] DSpace deployment environment survey?

[Monika Mevenkamp]

YES +10
and if you want to take the lead - I’ll be happy to help 
and if there s a survey - we might also ask some general questions
XMLUI  or JSPUI
customization level
amount of content
type of content

Monika

—
Monika Mevenkamp
Digital Repository Infrastructure Developer
Princeton University
Phone: 609-258-4161
Skype: mo-meven


>> On Nov 17, 2016 5:23 AM, "Alan Orth" > > wrote:
>> Hello,
>> 
>> I wasn't thinking of anything very sophisticated, so I guess "survey"
>> isn't really the best word. Perhaps "DSpace Deployment Census"? Just a
>> series of multi-select checkboxes and short answers primarily targeted
>> at the technical users on this mailing list who would be able to
>> answer questions about the OS, servlet container, Java version, etc
>> that runs their production DSpace instances.
>> 
>> About privacy, I definitely wasn't planning on asking for any
>> sensitive information like server URLs, etc in the census—just
>> deployment stats. But I would absolutely advocate for making the
>> results of the census public, as an open data set.
>> 
>> I'll draw up an example form in Google Forms and maybe some of you can
>> help me have a look at it off list?
>> 
>> Cheers,
>> 
>> On Wed, Nov 16, 2016 at 5:12 PM, Monika Mevenkamp > > wrote:
>> > a survey sounds like a good idea to me
>> > the easier it is to send in responses the more answers you’ll get
>> >
>> > in a survey monkey type survey you’d have to give instructions on every 
>> > single question how to find the answer;
>> > eg: dspace version - look under into HTML headers
>> > database-type: look into dspace.cfg
>> > OS version — which command to run  eg:"uname -a" in Linux
>> > the simpler/fewer the questions the more answers
>> >
>> > alternatively: write a cli script - put it into /dspace/bin
>> > make ant update run the script and echo instructions how to mail results 
>> > to a collection email
>> > make sure output is easy to parse so results can be added to a spreadsheet 
>> > / accumulated / …
>> > that of cause is a lot more work and may not be worth the extra effort 
>> > compared to the survey monkey approach
>> >
>> > I also counsel against exposing the data publicly
>> >
>> > Monika
>> >
>> >
>> > —
>> > Monika Mevenkamp
>> > Digital Repository Infrastructure Developer
>> > Princeton University
>> > Phone: 609-258-4161 
>> > Skype: mo-meven
>> >
>> >
>> >> On Nov 16, 2016, at 10:07 AM, Monika C. Mevenkamp 
>> >> mailto:moni...@exchange.princeton.edu>> 
>> >> wrote:
>> >>
>> >> a survey sounds like a good idea to me
>> >> the easier it is to send in responses the more answers you’ll get
>> >>
>> >> in a survey monkey type survey you’d have to give instructions on every 
>> >> single question how to find the answer;
>> >> eg: dspace version - look under into HTML headers
>> >> database-type: look into dspace.cfg
>> >> OS version — which command to run  eg:"uname -a" in Linux
>> >>
>> >> alternatively: write a cli script - put it into /dspace/bin
>> >> make ant update run the script and echo instructions how to mail results 
>> >> to a collection email
>> >> make sure output is easy to parse so results can be added to a 
>> >> spreadsheet / accumulated / …
>> >>
>> >> I would also counsel against exposing the data publicly
>> >>
>> >> Monika
>> >>
>> >>
>> >> —
>> >> Monika Mevenkamp
>> >> Digital Repository Infrastructure Developer
>> >> Princeton University
>> >> Phone: 609-258-4161 
>> >> Skype: mo-meven
>> >>
>> >>> On Nov 16, 2016, at 8:15 AM, Alan Orth > >>> > wrote:
>> >>>
>> >>> I had forgotten about that registry, helix! Our repository is
>> >>> certainly very out of date there (name, version, link, etc).
>> >>>
>> >>> Anyways, my proposal was simply to circulate a survey that people
>> >>> could answer, very low tech. :)
>> >>>
>> >>> Regards,
>> >>>
>> >>> On Wed, Nov 16, 2016 at 1:53 PM, emilio lorenzo > >>> > wrote:
>> 
>>  El 16/11/2016 a las 12:23, helix84 escribió:
>> >
>> >
>> > That part is already available.
>> >
>> >> vote 1-  for second part Not very sure about harvesting or 
>> >> exposing
>> >> versions and modules across system interface. Too many advantages for
>> >> networks hooligans and hackers..
>> >
>> > Well, first, those parts are already there and publicly exposed
>> > (xmlui, jspui, oai, rest, rdf), so the right thing to do is to make
>> > them resilient against attacks, not to pretend they're not exposed.
>> > Second, there must be an option for the administrator not to expose
>> > this information (not all repositories are production and public
>> > installations).
>> 
>>  Well,  I understood Alan´s proposal as exposing the software stack of 
>>  the
>>  Dspace installations, not only Dspace interfaces  and telling the 
>>  world
>>  that an installation has a operating system or a data

Re: [dspace-tech] DSpace deployment environment survey?

[Bruno Nocera Zanette]

Good idea!

Em qui, 17 de nov de 2016 às 12:00, Hardy Pottinger <
hardy.pottin...@gmail.com> escreveu:

> I like this idea, if you need help, just ask.
>
> --Hardy
>
> On Nov 17, 2016 5:23 AM, "Alan Orth"  wrote:
>
> Hello,
>
> I wasn't thinking of anything very sophisticated, so I guess "survey"
> isn't really the best word. Perhaps "DSpace Deployment Census"? Just a
> series of multi-select checkboxes and short answers primarily targeted
> at the technical users on this mailing list who would be able to
> answer questions about the OS, servlet container, Java version, etc
> that runs their production DSpace instances.
>
> About privacy, I definitely wasn't planning on asking for any
> sensitive information like server URLs, etc in the census—just
> deployment stats. But I would absolutely advocate for making the
> results of the census public, as an open data set.
>
> I'll draw up an example form in Google Forms and maybe some of you can
> help me have a look at it off list?
>
> Cheers,
>
> On Wed, Nov 16, 2016 at 5:12 PM, Monika Mevenkamp 
> wrote:
> > a survey sounds like a good idea to me
> > the easier it is to send in responses the more answers you’ll get
> >
> > in a survey monkey type survey you’d have to give instructions on every
> single question how to find the answer;
> > eg: dspace version - look under into HTML headers
> > database-type: look into dspace.cfg
> > OS version — which command to run  eg:"uname -a" in Linux
> > the simpler/fewer the questions the more answers
> >
> > alternatively: write a cli script - put it into /dspace/bin
> > make ant update run the script and echo instructions how to mail results
> to a collection email
> > make sure output is easy to parse so results can be added to a
> spreadsheet / accumulated / …
> > that of cause is a lot more work and may not be worth the extra effort
> compared to the survey monkey approach
> >
> > I also counsel against exposing the data publicly
> >
> > Monika
> >
> >
> > —
> > Monika Mevenkamp
> > Digital Repository Infrastructure Developer
> > Princeton University
> > Phone: 609-258-4161
> > Skype: mo-meven
> >
> >
> >> On Nov 16, 2016, at 10:07 AM, Monika C. Mevenkamp <
> moni...@exchange.princeton.edu> wrote:
> >>
> >> a survey sounds like a good idea to me
> >> the easier it is to send in responses the more answers you’ll get
> >>
> >> in a survey monkey type survey you’d have to give instructions on every
> single question how to find the answer;
> >> eg: dspace version - look under into HTML headers
> >> database-type: look into dspace.cfg
> >> OS version — which command to run  eg:"uname -a" in Linux
> >>
> >> alternatively: write a cli script - put it into /dspace/bin
> >> make ant update run the script and echo instructions how to mail
> results to a collection email
> >> make sure output is easy to parse so results can be added to a
> spreadsheet / accumulated / …
> >>
> >> I would also counsel against exposing the data publicly
> >>
> >> Monika
> >>
> >>
> >> —
> >> Monika Mevenkamp
> >> Digital Repository Infrastructure Developer
> >> Princeton University
> >> Phone: 609-258-4161
> >> Skype: mo-meven
> >>
> >>> On Nov 16, 2016, at 8:15 AM, Alan Orth  wrote:
> >>>
> >>> I had forgotten about that registry, helix! Our repository is
> >>> certainly very out of date there (name, version, link, etc).
> >>>
> >>> Anyways, my proposal was simply to circulate a survey that people
> >>> could answer, very low tech. :)
> >>>
> >>> Regards,
> >>>
> >>> On Wed, Nov 16, 2016 at 1:53 PM, emilio lorenzo 
> wrote:
> 
>  El 16/11/2016 a las 12:23, helix84 escribió:
> >
> >
> > That part is already available.
> >
> >> vote 1-  for second part Not very sure about harvesting or
> exposing
> >> versions and modules across system interface. Too many advantages
> for
> >> networks hooligans and hackers..
> >
> > Well, first, those parts are already there and publicly exposed
> > (xmlui, jspui, oai, rest, rdf), so the right thing to do is to make
> > them resilient against attacks, not to pretend they're not exposed.
> > Second, there must be an option for the administrator not to expose
> > this information (not all repositories are production and public
> > installations).
> 
>  Well,  I understood Alan´s proposal as exposing the software stack of
> the
>  Dspace installations, not only Dspace interfaces  and telling the
> world
>  that an installation has a operating system or a database some years
> old is
>  quite sensible (IMHO), although a competent hacker could figure out a
> lot of
>  things about an installation without our help :-)
> 
>  and of course our first priority has to be
> >
> > make them resilient against attacks
> 
>  But not every installation has the time or resources to keep its
>  installation updated and safe. That is the reality...
>  Regards
>  Emilio
> 
> 
> 
> >>

Re: [dspace-tech] DSpace deployment environment survey?

[Hardy Pottinger]

I like this idea, if you need help, just ask.

--Hardy

On Nov 17, 2016 5:23 AM, "Alan Orth"  wrote:

> Hello,
>
> I wasn't thinking of anything very sophisticated, so I guess "survey"
> isn't really the best word. Perhaps "DSpace Deployment Census"? Just a
> series of multi-select checkboxes and short answers primarily targeted
> at the technical users on this mailing list who would be able to
> answer questions about the OS, servlet container, Java version, etc
> that runs their production DSpace instances.
>
> About privacy, I definitely wasn't planning on asking for any
> sensitive information like server URLs, etc in the census—just
> deployment stats. But I would absolutely advocate for making the
> results of the census public, as an open data set.
>
> I'll draw up an example form in Google Forms and maybe some of you can
> help me have a look at it off list?
>
> Cheers,
>
> On Wed, Nov 16, 2016 at 5:12 PM, Monika Mevenkamp 
> wrote:
> > a survey sounds like a good idea to me
> > the easier it is to send in responses the more answers you’ll get
> >
> > in a survey monkey type survey you’d have to give instructions on every
> single question how to find the answer;
> > eg: dspace version - look under into HTML headers
> > database-type: look into dspace.cfg
> > OS version — which command to run  eg:"uname -a" in Linux
> > the simpler/fewer the questions the more answers
> >
> > alternatively: write a cli script - put it into /dspace/bin
> > make ant update run the script and echo instructions how to mail results
> to a collection email
> > make sure output is easy to parse so results can be added to a
> spreadsheet / accumulated / …
> > that of cause is a lot more work and may not be worth the extra effort
> compared to the survey monkey approach
> >
> > I also counsel against exposing the data publicly
> >
> > Monika
> >
> >
> > —
> > Monika Mevenkamp
> > Digital Repository Infrastructure Developer
> > Princeton University
> > Phone: 609-258-4161
> > Skype: mo-meven
> >
> >
> >> On Nov 16, 2016, at 10:07 AM, Monika C. Mevenkamp <
> moni...@exchange.princeton.edu> wrote:
> >>
> >> a survey sounds like a good idea to me
> >> the easier it is to send in responses the more answers you’ll get
> >>
> >> in a survey monkey type survey you’d have to give instructions on every
> single question how to find the answer;
> >> eg: dspace version - look under into HTML headers
> >> database-type: look into dspace.cfg
> >> OS version — which command to run  eg:"uname -a" in Linux
> >>
> >> alternatively: write a cli script - put it into /dspace/bin
> >> make ant update run the script and echo instructions how to mail
> results to a collection email
> >> make sure output is easy to parse so results can be added to a
> spreadsheet / accumulated / …
> >>
> >> I would also counsel against exposing the data publicly
> >>
> >> Monika
> >>
> >>
> >> —
> >> Monika Mevenkamp
> >> Digital Repository Infrastructure Developer
> >> Princeton University
> >> Phone: 609-258-4161
> >> Skype: mo-meven
> >>
> >>> On Nov 16, 2016, at 8:15 AM, Alan Orth  wrote:
> >>>
> >>> I had forgotten about that registry, helix! Our repository is
> >>> certainly very out of date there (name, version, link, etc).
> >>>
> >>> Anyways, my proposal was simply to circulate a survey that people
> >>> could answer, very low tech. :)
> >>>
> >>> Regards,
> >>>
> >>> On Wed, Nov 16, 2016 at 1:53 PM, emilio lorenzo 
> wrote:
> 
>  El 16/11/2016 a las 12:23, helix84 escribió:
> >
> >
> > That part is already available.
> >
> >> vote 1-  for second part Not very sure about harvesting or
> exposing
> >> versions and modules across system interface. Too many advantages
> for
> >> networks hooligans and hackers..
> >
> > Well, first, those parts are already there and publicly exposed
> > (xmlui, jspui, oai, rest, rdf), so the right thing to do is to make
> > them resilient against attacks, not to pretend they're not exposed.
> > Second, there must be an option for the administrator not to expose
> > this information (not all repositories are production and public
> > installations).
> 
>  Well,  I understood Alan´s proposal as exposing the software stack of
> the
>  Dspace installations, not only Dspace interfaces  and telling the
> world
>  that an installation has a operating system or a database some years
> old is
>  quite sensible (IMHO), although a competent hacker could figure out a
> lot of
>  things about an installation without our help :-)
> 
>  and of course our first priority has to be
> >
> > make them resilient against attacks
> 
>  But not every installation has the time or resources to keep its
>  installation updated and safe. That is the reality...
>  Regards
>  Emilio
> 
> 
> 
> > And finally, this is supposed to actually help security. You'll be
> > able to register your instance (ju

Re: [dspace-tech] configure hanlde server without using CNRI's Handle system

[Benedikt Kroll]

Hi,

please see this previous mail and the links mentioned there for using 
DSpace without the handle system:


https://groups.google.com/d/msg/dspace-tech/rK9gEJvL16E/AMYtb_xKAwAJ

--bk

Am 17.11.2016 um 10:39 schrieb hoska...@gmail.com:

hello
In https://wiki.duraspace.org/ docs the method explained requires
registration at the CRCI's Handle system.
how can we configure handle server for dspace 6.0 without using CNRI's
Handle system?

thanks for help


--
You received this message because you are subscribed to the Google
Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to dspace-tech+unsubscr...@googlegroups.com
.
To post to this group, send email to dspace-tech@googlegroups.com
.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "DSpace 
Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Build failed and Solr statistic error

[Mariangels]

Hola,

We are working with DSpace 5.5 and found this error (in the file attached).

Someone can help us?

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

Re: [dspace-tech] DSpace deployment environment survey?

[Alan Orth]

Hello,

I wasn't thinking of anything very sophisticated, so I guess "survey"
isn't really the best word. Perhaps "DSpace Deployment Census"? Just a
series of multi-select checkboxes and short answers primarily targeted
at the technical users on this mailing list who would be able to
answer questions about the OS, servlet container, Java version, etc
that runs their production DSpace instances.

About privacy, I definitely wasn't planning on asking for any
sensitive information like server URLs, etc in the census—just
deployment stats. But I would absolutely advocate for making the
results of the census public, as an open data set.

I'll draw up an example form in Google Forms and maybe some of you can
help me have a look at it off list?

Cheers,

On Wed, Nov 16, 2016 at 5:12 PM, Monika Mevenkamp  wrote:
> a survey sounds like a good idea to me
> the easier it is to send in responses the more answers you’ll get
>
> in a survey monkey type survey you’d have to give instructions on every 
> single question how to find the answer;
> eg: dspace version - look under into HTML headers
> database-type: look into dspace.cfg
> OS version — which command to run  eg:"uname -a" in Linux
> the simpler/fewer the questions the more answers
>
> alternatively: write a cli script - put it into /dspace/bin
> make ant update run the script and echo instructions how to mail results to a 
> collection email
> make sure output is easy to parse so results can be added to a spreadsheet / 
> accumulated / …
> that of cause is a lot more work and may not be worth the extra effort 
> compared to the survey monkey approach
>
> I also counsel against exposing the data publicly
>
> Monika
>
>
> —
> Monika Mevenkamp
> Digital Repository Infrastructure Developer
> Princeton University
> Phone: 609-258-4161
> Skype: mo-meven
>
>
>> On Nov 16, 2016, at 10:07 AM, Monika C. Mevenkamp 
>>  wrote:
>>
>> a survey sounds like a good idea to me
>> the easier it is to send in responses the more answers you’ll get
>>
>> in a survey monkey type survey you’d have to give instructions on every 
>> single question how to find the answer;
>> eg: dspace version - look under into HTML headers
>> database-type: look into dspace.cfg
>> OS version — which command to run  eg:"uname -a" in Linux
>>
>> alternatively: write a cli script - put it into /dspace/bin
>> make ant update run the script and echo instructions how to mail results to 
>> a collection email
>> make sure output is easy to parse so results can be added to a spreadsheet / 
>> accumulated / …
>>
>> I would also counsel against exposing the data publicly
>>
>> Monika
>>
>>
>> —
>> Monika Mevenkamp
>> Digital Repository Infrastructure Developer
>> Princeton University
>> Phone: 609-258-4161
>> Skype: mo-meven
>>
>>> On Nov 16, 2016, at 8:15 AM, Alan Orth  wrote:
>>>
>>> I had forgotten about that registry, helix! Our repository is
>>> certainly very out of date there (name, version, link, etc).
>>>
>>> Anyways, my proposal was simply to circulate a survey that people
>>> could answer, very low tech. :)
>>>
>>> Regards,
>>>
>>> On Wed, Nov 16, 2016 at 1:53 PM, emilio lorenzo  wrote:

 El 16/11/2016 a las 12:23, helix84 escribió:
>
>
> That part is already available.
>
>> vote 1-  for second part Not very sure about harvesting or exposing
>> versions and modules across system interface. Too many advantages for
>> networks hooligans and hackers..
>
> Well, first, those parts are already there and publicly exposed
> (xmlui, jspui, oai, rest, rdf), so the right thing to do is to make
> them resilient against attacks, not to pretend they're not exposed.
> Second, there must be an option for the administrator not to expose
> this information (not all repositories are production and public
> installations).

 Well,  I understood Alan´s proposal as exposing the software stack of the
 Dspace installations, not only Dspace interfaces  and telling the world
 that an installation has a operating system or a database some years old is
 quite sensible (IMHO), although a competent hacker could figure out a lot 
 of
 things about an installation without our help :-)

 and of course our first priority has to be
>
> make them resilient against attacks

 But not every installation has the time or resources to keep its
 installation updated and safe. That is the reality...
 Regards
 Emilio



> And finally, this is supposed to actually help security. You'll be
> able to register your instance (just once) along with your email
> address and then get a custom-tailored notification that your
> particular installation is affected by a security bug because you're
> using version X.Y with module Z.
>
>
> Regards,
> ~~helix84
>
> Compulsory reading: DSpace Mailing List Etiquette
> https://wiki.duraspace.org/display/DSPACE/Ma

[dspace-tech] configure hanlde server without using CNRI's Handle system

[hoska . 18]

hello 
In https://wiki.duraspace.org/ docs the method explained requires 
registration at the CRCI's Handle system.
how can we configure handle server for dspace 6.0 without using CNRI's 
Handle system?

thanks for help


-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] SWORDV2 - submitted items from OJS not displayed in dspace

[RICARDO EITO BRUN]

Dear colleagues,
I am trying to submit items to dspace from OJS. I have set up dspace
according to the recommendations in the manual (swordv2.cfg file), and from
OJS, I can select the collection and I got the message that the submission
went ok.

The problem is that I cannot see the items in dspace, and the submission
does not seem to be fully completed (even if I log in dspace as dspace
administrator)

Any idea on the reason for this issue?

thanks in advance,

Ricardo

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.

[dspace-tech] Re: building with Mirage2 theme generates npm minimatch errors

[hoska . 18]

thanks for reply 
we migrated to version 6.0 and the problem is solved
the build of the package with mirage 2 ended without errors
thank you so mach


>

-- 
You received this message because you are subscribed to the Google Groups 
"DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dspace-tech+unsubscr...@googlegroups.com.
To post to this group, send email to dspace-tech@googlegroups.com.
Visit this group at https://groups.google.com/group/dspace-tech.
For more options, visit https://groups.google.com/d/optout.