Re: [dspace-tech] Re: Two OAI problems with DSpace 6.2

2017-10-25 Thread Christian Scheible 

Hi Eugeni,

I just added this item: http://demo.dspace.org/xmlui/handle/10673/32
to the demo site of DSpace and this breaks the XMLUI and will break OAI 
as soon as it is re indexed.


So I think our problems might be unrelated but there is a DSpace bug 
regarding characters that are disallowed in XML 1.0.


Regards
Christian

Am 26.10.2017 um 00:13 schrieb Evgeni Dimitrov:


To close the problem I should say that there is no real issue with the 
non-ASCII characters and OAI.


But in XOAI there is conversion between String and byte array using 
the platform's default charset. Which is not always UTF-8. One can fix 
this starting Java/Tomcat with

  -Dfile.encoding=UTF8

One more thing I noticed now is that in some logs in dspace.log the 
non-ASCII characters are replaced by ??

To get the real non-ASCII characters one can add in log4j.properties
  log4j.appender.A1.encoding=UTF-8


On Thursday, October 19, 2017 at 9:04:39 PM UTC+3, Evgeni Dimitrov wrote:

I have a freshly installed DSpace 6.2 with 15 items in it.
I have not changed anything in the OAI configuration.
Two of the items have READ access for certain groups only. The
rest are accessible to everybody.

Problem 1.
When I run
dspace oai import -c

I get in dspace.log two exceptions (I suppose for each of the
restricted access items):

2017-10-19 17:55:22,650 WARN  org.dspace.xoai.util.ItemUtils @
Authorization denied for action READ on
BITSTREAM:3d21ebf7-ef3e-4d98-a265-c4a516b1740b by user null
org.dspace.authorize.AuthorizeException: Authorization denied for
action READ on BITSTREAM:3d21ebf7-ef3e-4d98-a265-c4a516b1740b by
user null

The whole text of the exception is very long.

Problem 2.
After that I am trying
http://localhost:8080/oai/request?verb=Identify

http://localhost:8080/oai/request?verb=ListSets

http://localhost:8080/oai/request?verb=ListMetadataFormats

http://localhost:8080/oai/request?verb=ListIdentifiers=xoai

and it all works.

But for

http://localhost:8080/oai/request?verb=GetRecord=oai:localhost:nls/3=xoai


(nls/3 is an item accessible to everybody)
I get in the browser

java.io.IOException:
com.lyncode.xoai.dataprovider.exceptions.WritingXmlException:
Error trying to output ''
   

org.dspace.xoai.services.impl.cache.DSpaceXOAICacheService.store(DSpaceXOAICacheService.java:113)

The whole text of the exception is very long.

My question is - am I missing something in the configuration or is
this a known problem with DSpace 6.2?



Virus-free. www.avg.com




--
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.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-25 Thread wlrutherford 

I may have it fixed but to do it I had to ignore the handle setup 
instructions and use
port 443 instead of port 8000. That forces a secure reference. Nothing 
appears to
happen when I click on the URI. Since http://hdl.handle.net/11122/ 
points
right back to the same page containing the link that makes perfect sense.


On Wednesday, October 25, 2017 at 1:11:49 PM UTC-8, wlruth...@alaska.edu 
wrote:
>
>
>
> On Wednesday, October 25, 2017 at 8:56:57 AM UTC-8, Mark H. Wood wrote:
>>
>> On Tuesday, October 24, 2017 at 9:46:58 PM UTC-4, wlruth...@alaska.edu 
>> wrote:
>>>
>>> We are using port 443 for secure connections and securing the site by 
>>> rewriting
>>> port 80 to also go to port 443. The handle server uses ports 2641 and 
>>> 8000 and
>>> needs them to to be non-SSL. But something is converting our 
>>> http://hdl.handle.net/
>>> URI links to https. So, rather than linking to the document page, we get 
>>> something
>>> like this:
>>>
>>> 
>>> 
>>> 400 Bad Request
>>> 
>>> Bad Request
>>> Your browser sent a request that this server could not understand.
>>> Reason: You're speaking plain HTTP to an SSL-enabled server port.
>>> Instead use the HTTPS scheme to access this URL, please.
>>> Hint: https://scholarworks.alaska.edu/ 
>>> ">https://scholarworks.alaska.edu/
>>> 
>>> Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 
>>> 443
>>> 
>>>
>>>
>>>
>>
>> I tried following the URI: link at 
>> https://scholarworks.alaska.edu/xmlui/handle/11122/6433 using 'curl'.  
>> The Handle link there is 'http://hdl.handle.net/11122/6433'.  
>> hdl.handle.net responded with a 303 redirect to '
>> http://scholarworks.alaska.edu:443/xmlui/handle/11122/6433' which is 
>> wrong:  it should either use 'https:' or omit the port 443.  I suspect that 
>> you've set 'dspace.url' to 'http://scholarworks.alaska.edu:443' instead 
>> of 'https://scholarworks.alaska.edu:443'.  The DSpace Handle resolver 
>> just appends the object's handle to the value of 'dspace.url' and sends 
>> that back to the master resolver at hdl.net.
>>
>>  
>  You're right, there was a mismatch in the dspace.cfg file between http:// 
> and the secure port 443. Unfortunately, changing dspace.url to clean 
> https:// didn't fix the problem. Same error.
>
>  
>>
>>> My best guess at the moment is that the virtualhost configurations are
>>> also somehow catching other ports and rewriting them in the same way.
>>>
>>> 
>>> #
>>> ### Redirect insecure ports to secure port 443
>>> ServerAdmin uaf-libra...@alaska.edu
>>> RewriteEngine On
>>> RewriteCond %{HTTPS} off
>>> #   RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]
>>> RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI}
>>>
>>
>>
>> This probably doesn't accomplish anything, since a rewrite to the same 
>> host will be stripped down to the localpart.  Forcing a redirect, as in the 
>> line above it, should evoke a new request to the proper port.  Try 
>> appending '[R,L]' or '[R=permanent,L]'.
>>
>>  
>>
>> DocumentRoot /dspace/webapps/xmlui
>>> ServerName scholarworks.alaska.edu
>>> ServerAlias scholarworks
>>>
>>> ErrorLog logs/scholarworks.alaska.edu-error_log
>>> CustomLog logs/scholarworks.alaska.edu-access_log common
>>>
>>> ProxyPass / http://127.0.0.1:443/  retry=10 connectiontimeout=5
>>> ### ^ this tells httpd to redirect it's / to localhost port 443
>>>
>>>
>>
>> No.  This is not a redirect.  HTTPD will act like a client and ask the 
>> target for the localpart, then send the reply back to *its* client.  Above 
>> HTTPD is proxying through itself, which is probably not what you want.  
>> Here we have no proxy rules at all for port 80, only actual redirects 
>> telling HTTPD's client to try again on port 443.  All the proxying happens 
>> in the port 443 virtual host.  I would just take all this proxy stuff out 
>> of this vhost.
>>
>> I commented out the proxyPass lines for  without 
> breaking anything. I also added the "[R,L]" per your suggestion. So far 
> I've noticed no difference.
>  
>
>>  
>>
>>> #timeout=300
>>> ProxyPassReverse / http://127.0.0.1:443/  retry=10
>>> ### ^ this tells httpd that tomcat's url's should be rewritten 
>>> to look
>>> ###   like they're coming from httpd.
>>>
>>> ProxyPreserveHost On
>>> ### ^ this tells httpd to keep the Host: information from the 
>>> client and
>>> ### pass it on to tomcat.
>>>
>>> 
>>>
>>> #
>>> 
>>>
>>> ### ^ this creates a httpd server that listens on port 443.
>>>
>>> ServerAdmin uaf-libra...@alaska.edu
>>> DocumentRoot /dspace/webapps/xmlui
>>> ServerName scholarworks.alaska.edu
>>> ServerAlias scholarworks
>>>
>>> ErrorLog logs/scholarworks.alaska.edu-https-error_log
>>> CustomLog

Re: [dspace-tech] Tomcat Cert Process for Dspace

2017-10-25 Thread wlrutherford 


On Wednesday, October 25, 2017 at 8:56:57 AM UTC-8, Mark H. Wood wrote:
>
> On Tuesday, October 24, 2017 at 9:46:58 PM UTC-4, wlruth...@alaska.edu 
>  wrote:
>>
>> We are using port 443 for secure connections and securing the site by 
>> rewriting
>> port 80 to also go to port 443. The handle server uses ports 2641 and 
>> 8000 and
>> needs them to to be non-SSL. But something is converting our 
>> http://hdl.handle.net/
>> URI links to https. So, rather than linking to the document page, we get 
>> something
>> like this:
>>
>> 
>> 
>> 400 Bad Request
>> 
>> Bad Request
>> Your browser sent a request that this server could not understand.
>> Reason: You're speaking plain HTTP to an SSL-enabled server port.
>> Instead use the HTTPS scheme to access this URL, please.
>> Hint: https://scholarworks.alaska.edu/ 
>> ">https://scholarworks.alaska.edu/
>> 
>> Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 
>> 443
>> 
>>
>>
>>
>
> I tried following the URI: link at 
> https://scholarworks.alaska.edu/xmlui/handle/11122/6433 using 'curl'.  
> The Handle link there is 'http://hdl.handle.net/11122/6433'.  
> hdl.handle.net responded with a 303 redirect to '
> http://scholarworks.alaska.edu:443/xmlui/handle/11122/6433' which is 
> wrong:  it should either use 'https:' or omit the port 443.  I suspect that 
> you've set 'dspace.url' to 'http://scholarworks.alaska.edu:443' instead 
> of 'https://scholarworks.alaska.edu:443'.  The DSpace Handle resolver 
> just appends the object's handle to the value of 'dspace.url' and sends 
> that back to the master resolver at hdl.net.
>
>  
 You're right, there was a mismatch in the dspace.cfg file between http:// 
and the secure port 443. Unfortunately, changing dspace.url to clean 
https:// didn't fix the problem. Same error.

 
>
>> My best guess at the moment is that the virtualhost configurations are
>> also somehow catching other ports and rewriting them in the same way.
>>
>> 
>> #
>> ### Redirect insecure ports to secure port 443
>> ServerAdmin uaf-libra...@alaska.edu 
>> RewriteEngine On
>> RewriteCond %{HTTPS} off
>> #   RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]
>> RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI}
>>
>
>
> This probably doesn't accomplish anything, since a rewrite to the same 
> host will be stripped down to the localpart.  Forcing a redirect, as in the 
> line above it, should evoke a new request to the proper port.  Try 
> appending '[R,L]' or '[R=permanent,L]'.
>
>  
>
> DocumentRoot /dspace/webapps/xmlui
>> ServerName scholarworks.alaska.edu
>> ServerAlias scholarworks
>>
>> ErrorLog logs/scholarworks.alaska.edu-error_log
>> CustomLog logs/scholarworks.alaska.edu-access_log common
>>
>> ProxyPass / http://127.0.0.1:443/  retry=10 connectiontimeout=5
>> ### ^ this tells httpd to redirect it's / to localhost port 443
>>
>>
>
> No.  This is not a redirect.  HTTPD will act like a client and ask the 
> target for the localpart, then send the reply back to *its* client.  Above 
> HTTPD is proxying through itself, which is probably not what you want.  
> Here we have no proxy rules at all for port 80, only actual redirects 
> telling HTTPD's client to try again on port 443.  All the proxying happens 
> in the port 443 virtual host.  I would just take all this proxy stuff out 
> of this vhost.
>
> I commented out the proxyPass lines for  without 
breaking anything. I also added the "[R,L]" per your suggestion. So far 
I've noticed no difference.
 

>  
>
>> #timeout=300
>> ProxyPassReverse / http://127.0.0.1:443/  retry=10
>> ### ^ this tells httpd that tomcat's url's should be rewritten to 
>> look
>> ###   like they're coming from httpd.
>>
>> ProxyPreserveHost On
>> ### ^ this tells httpd to keep the Host: information from the 
>> client and
>> ### pass it on to tomcat.
>>
>> 
>>
>> #
>> 
>>
>> ### ^ this creates a httpd server that listens on port 443.
>>
>> ServerAdmin uaf-libra...@alaska.edu 
>> DocumentRoot /dspace/webapps/xmlui
>> ServerName scholarworks.alaska.edu
>> ServerAlias scholarworks
>>
>> ErrorLog logs/scholarworks.alaska.edu-https-error_log
>> CustomLog logs/scholarworks.alaska.edu-https-access_log 
>> combinedssl
>>
>> Include conf.d/ssl.include
>> Include conf.d/ssl.include.star
>> ### ^ these point to a file which specifies where the ssl 
>> certificates
>> ###   live on the host.
>>
>> ProxyPass / http://127.0.0.1:8080/  retry=10 
>> connectiontimeout=5
>> ### ^ this tells httpd to redirect it's / to localhost port 8080
>>
>>
>
> Again, not a redirect; this causes HTTPD to send a request to whatever is 
> on port 8080 (Tomcat, I presume)

Re: [dspace-tech] Re: email test script works but jspui doesn't

2017-10-25 Thread Seun Ojedeji 
Hello,

I get a lot of the following:

INFO [main] (DSpaceKernelInit.java:52) - Created new kernel:
DSpaceKernel:org.dspace:name=a14a4b3f-d365-4643-993c-dc8a0ee21f9c,type=DSpaceKernel:lastLoad=null:loadTime=0:running=false:kernel=null

 INFO [main] (ConfigurationManager.java:1224) - Loading from
classloader: file:/dspace/config/dspace.cfg
 INFO [main] (ConfigurationManager.java:1224) - Using dspace provided
log configuration (log.init.config)
 INFO [main] (ConfigurationManager.java:1224) - Loading:
/dspace/config/log4j.properties

Thanks

On Wed, Oct 25, 2017 at 9:00 PM, Mark H. Wood  wrote:
> On Wednesday, October 25, 2017 at 4:20:22 AM UTC-4, Seun Ojedeji wrote:
>>
>> The dspace email test script works but doing a password reset, registering
>> a new account(which involves sending confirmation mail) or submitting a
>> feedback form on the jspui interface returns error. I have not been able to
>> figure out what could be the cause of this and will appreciate any pointer.
>
>
>
> What specific error do you see when an operation fails?  What messages
> appear in the DSpace log at that time?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "DSpace Technical Support" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/dspace-tech/nhDUypyjYzo/unsubscribe.
> To unsubscribe from this group and all its topics, 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.



-- 


Seun Ojedeji,
Federal University Oye-Ekiti
web:  http://www.fuoye.edu.ng
Mobile: +2348035233535
alt email: seun.ojed...@fuoye.edu.ng

Bringing another down does not take you up - think about your action!

-- 
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: email test script works but jspui doesn't

2017-10-25 Thread Mark H. Wood 
On Wednesday, October 25, 2017 at 4:20:22 AM UTC-4, Seun Ojedeji wrote:
>
> The dspace email test script works but doing a password reset, registering 
> a new account(which involves sending confirmation mail) or submitting a 
> feedback form on the jspui interface returns error. I have not been able to 
> figure out what could be the cause of this and will appreciate any pointer.
>


What specific error do you see when an operation fails?  What messages 
appear in the DSpace log at that time?

-- 
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] Tomcat Cert Process for Dspace

2017-10-25 Thread Mark H. Wood 
On Tuesday, October 24, 2017 at 9:46:58 PM UTC-4, wlrutherf...@alaska.edu 
wrote:
>
> We are using port 443 for secure connections and securing the site by 
> rewriting
> port 80 to also go to port 443. The handle server uses ports 2641 and 8000 
> and
> needs them to to be non-SSL. But something is converting our 
> http://hdl.handle.net/
> URI links to https. So, rather than linking to the document page, we get 
> something
> like this:
>
> 
> 
> 400 Bad Request
> 
> Bad Request
> Your browser sent a request that this server could not understand.
> Reason: You're speaking plain HTTP to an SSL-enabled server port.
> Instead use the HTTPS scheme to access this URL, please.
> Hint: https://scholarworks.alaska.edu/ 
> ">https://scholarworks.alaska.edu/
> 
> Apache/2.2.15 (Red Hat) Server at scholarworks.alaska.edu Port 
> 443
> 
>
>
>

I tried following the URI: link at 
https://scholarworks.alaska.edu/xmlui/handle/11122/6433 using 'curl'.  The 
Handle link there is 'http://hdl.handle.net/11122/6433'.  hdl.handle.net 
responded with a 303 redirect to 
'http://scholarworks.alaska.edu:443/xmlui/handle/11122/6433' which is 
wrong:  it should either use 'https:' or omit the port 443.  I suspect that 
you've set 'dspace.url' to 'http://scholarworks.alaska.edu:443' instead of 
'https://scholarworks.alaska.edu:443'.  The DSpace Handle resolver just 
appends the object's handle to the value of 'dspace.url' and sends that 
back to the master resolver at hdl.net.

 

> My best guess at the moment is that the virtualhost configurations are
> also somehow catching other ports and rewriting them in the same way.
>
> 
> #
> ### Redirect insecure ports to secure port 443
> ServerAdmin uaf-library-it-d...@alaska.edu
> RewriteEngine On
> RewriteCond %{HTTPS} off
> #   RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]
> RewriteRule (.*) https://%{HTTP_HOST}:443%{REQUEST_URI}
>


This probably doesn't accomplish anything, since a rewrite to the same host 
will be stripped down to the localpart.  Forcing a redirect, as in the line 
above it, should evoke a new request to the proper port.  Try appending 
'[R,L]' or '[R=permanent,L]'.

 

> DocumentRoot /dspace/webapps/xmlui
> ServerName scholarworks.alaska.edu
> ServerAlias scholarworks
>
> ErrorLog logs/scholarworks.alaska.edu-error_log
> CustomLog logs/scholarworks.alaska.edu-access_log common
>
> ProxyPass / http://127.0.0.1:443/  retry=10 connectiontimeout=5
> ### ^ this tells httpd to redirect it's / to localhost port 443
>
>

No.  This is not a redirect.  HTTPD will act like a client and ask the 
target for the localpart, then send the reply back to *its* client.  Above 
HTTPD is proxying through itself, which is probably not what you want.  
Here we have no proxy rules at all for port 80, only actual redirects 
telling HTTPD's client to try again on port 443.  All the proxying happens 
in the port 443 virtual host.  I would just take all this proxy stuff out 
of this vhost.

 

> #timeout=300
> ProxyPassReverse / http://127.0.0.1:443/  retry=10
> ### ^ this tells httpd that tomcat's url's should be rewritten to 
> look
> ###   like they're coming from httpd.
>
> ProxyPreserveHost On
> ### ^ this tells httpd to keep the Host: information from the 
> client and
> ### pass it on to tomcat.
>
> 
>
> #
> 
>
> ### ^ this creates a httpd server that listens on port 443.
>
> ServerAdmin uaf-library-it-d...@alaska.edu
> DocumentRoot /dspace/webapps/xmlui
> ServerName scholarworks.alaska.edu
> ServerAlias scholarworks
>
> ErrorLog logs/scholarworks.alaska.edu-https-error_log
> CustomLog logs/scholarworks.alaska.edu-https-access_log combinedssl
>
> Include conf.d/ssl.include
> Include conf.d/ssl.include.star
> ### ^ these point to a file which specifies where the ssl 
> certificates
> ###   live on the host.
>
> ProxyPass / http://127.0.0.1:8080/  retry=10 
> connectiontimeout=5
> ### ^ this tells httpd to redirect it's / to localhost port 8080
>
>

Again, not a redirect; this causes HTTPD to send a request to whatever is 
on port 8080 (Tomcat, I presume) and forward its response back to HTTPD's 
client.  This is what you need in order to actually serve user requests.

 

> #timeout=300
>
> ProxyPassReverse /  http://127.0.0.1:8080/  retry=10
> ### ^ this tells httpd that tomcat's url's should be rewritten to 
> look
> ###   like they're coming from httpd.
>
> ProxyPreserveHost On
> ### ^ this tells httpd to keep the Host: information from the 
> client and
> ### pass it on to tomcat.
>
> #SSLUseStapling on
> ### Added due to error when

Re: [dspace-tech] Cleaning the .bak

2017-10-25 Thread Creel, James Silas 
Hi Olivier,

These are perfectly safe to remove, assuming you have no need to revert to a 
prior deployment.  The ant installer backs up your previous deployment in case 
something breaks and you want to roll back.

Regards,

James

On 10/25/17, 4:36 AM, "dspace-tech@googlegroups.com on behalf of Olivier" 
 wrote:

Hello,

I am in desperate need to cleanup some space on my DSpace drive.

I have a serie of directories called webapps.bak-date-time that take a
total of 7GB, the last one having a date of Nov 2015. I want to know how
safe it is to remove them?

I am using DSpace 4.2

Thanks in advance,

Olivier
-- 

-- 
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.

Re: [dspace-tech] server flooded by search requests

2017-10-25 Thread Francis Brouns 
Dear Monica,

we have enabled sitemaps for quite some time now and did not make any 
changes to the server recently. Robots.txt is also present.

The problem is that this particular request targets the same community over 
and over again, with requests that differ only slightly. These requests 
occur 15-20 times per second.

kind regards,
Francis Brouns

-- 
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] server flooded by search requests

2017-10-25 Thread Monika Mevenkamp 
Francis 

66.249.76.34 is a googlebot IP

you should enable sitemaps, googlebots honor them 

have a look at Search Engine Optimization 
  
documentation 

Monika




 
Monika Mevenkamp
mo.me...@gmail.com

http://mo-meven.tumblr.com/
http://mcmprogramming.com/mo.meven/



> On Oct 25, 2017, at 9:39 AM, Francis Brouns  wrote:
> 
> Hi all,
> 
> our DSpace servers is being flooded with search request since the beginning 
> of October. Normally we get about 25 search requests in a month, now we 
> get 2.5 million in 2 weeks. It seems that these requests are all aimed at a 
> particular Community and are searching for combination of authors and 
> subjects over and over. Most of the time these search request have no results.
> 
> Running DSpace 5.4 on SLES Linux, tomcat 7, java 7, jspui
> 
> In the dspace log, I find numerous requests like these: 
> ip_addr=66.249.76.34:search:scope=org.dspace.content.Community@287,query="null",results=(0,0,0)
> 
> in tomcat localhost-access log
> 66.249.76.34  - - [24/Oct/2017:01:05:30 +0200] "GET 
> /handle/1820/2145/simple-search?location=1820%2F2145=_field_1=dateIssued_type_1=equals_value_1=2011_field_2=author_type_2=equals_value_2=Van+Hooft%2C+W.+F._field_3=author_type_3=equals_value_3=Leirs%2C+H._field_4=author_type_4=equals_value_4=Bauer%2C+H._field_5=subject_type_5=equals_value_5=phylogeography_field_6=author_type_6=equals_value_6=Van+Haeringen%2C+W.+A._field_7=author_type_7=equals_value_7=Bertola%2C+L.+D._field_8=subject_type_8=equals_value_8=evolutionary+history_field_9=author_type_9=equals_value_9=Tumenta%2C+P.+N._field_10=author_type_10=equals_value_10=York%2C+D.+S._field_11=subject_type_11=equals_value_11=Panthera+leo=5_by=dc.title_sort=DESC=0
>  HTTP/1.1" 200 30123 - /handle/1820/2145/simple-search
> - 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
> /solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=subject_keyword%3ASubsidiarity=subject_keyword%3ACollaborative%5C+Learning=subject_keyword%3AVirtual%5C+Campus=dateIssued_keyword%3A2009=subject_keyword%3AOrganizational%5C+Model=subject_keyword%3ALearning%5C+for%5C+Sustainable%5C+Development=subject_keyword%3AVirtual%5C+Mobility=subject_keyword%3ANetworked%5C+Learning=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+asc=javabin=2
>  HTTP/1.1" 200 611 - /solr/search/select
> - 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
> /solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=subject_keyword%3ASubsidiarity=subject_keyword%3ACollaborative%5C+Learning=subject_keyword%3AVirtual%5C+Campus=dateIssued_keyword%3A2009=subject_keyword%3AOrganizational%5C+Model=subject_keyword%3ALearning%5C+for%5C+Sustainable%5C+Development=subject_keyword%3AVirtual%5C+Mobility=subject_keyword%3ANetworked%5C+Learning=location%3Am18=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+desc=javabin=2
>  HTTP/1.1" 200 625 - /solr/search/select
> - 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
> /solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=dateIssued_keyword%3A2011=subject_keyword%3Alion=author_keyword%3ASogbohossou%2C%5C+E.=author_keyword%3AVan%5C+Haeringen%2C%5C+W.%5C+A.=author_keyword%3AVan%5C+Hooft%2C%5C+W.%5C+F.=subject_keyword%3AWest%5C+Africa=subject_keyword%3Aphylogenetics=author_keyword%3APrins%2C%5C+H.%5C+H.%5C+T.=author_keyword%3AYork%2C%5C+D.%5C+S.=author_keyword%3AUit%5C+de%5C+Weerd%2C%5C+D.%5C+R.=author_keyword%3AFunston%2C%5C+P.%5C+J.=subject_keyword%3Aevolutionary%5C+history=author_keyword%3AUdo%5C+de%5C+Haes%2C%5C+H.%5C+A.=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+asc=javabin=2
>  HTTP/1.1" 200 740 - /solr/search/select
> - 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
> /solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=dateIssued_keyword%3A2011=subject_keyword%3Alion=author_keyword%3ASogbohossou%2C%5C+E.=author_keyword%3AVan%5C+Haeringen%2C%5C+W.%5C+A.=author_keyword%3AVan%5C+Hooft%2C%5C+W.%5C+F.=subject_keyword%3AWest%5C+Africa=subject_keyword%3Aphylogenetics=author_keyword%3APrins%2C%5C+H.%5C+H.%5C+T.=author_keyword%3AYork%2C%5C+D.%5C+S.=author_keyword%3AUit%5C+de%5C+Weerd%2C%5C+D.%5C+R.=author_keyword%3AFunston%2C%5C+P.%5C+J.=subject_keyword%3Aevolutionary%5C+history=author_keyword%3AUdo%5C+de%5C+Haes%2C%5C+H.%5C+A.=location%3Am18=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+desc=javabin=2
>  HTTP/1.1" 200 758 -

[dspace-tech] server flooded by search requests

2017-10-25 Thread Francis Brouns 
Hi all,

our DSpace servers is being flooded with search request since the beginning 
of October. Normally we get about 25 search requests in a month, now we 
get 2.5 million in 2 weeks. It seems that these requests are all aimed at a 
particular Community and are searching for combination of authors and 
subjects over and over. Most of the time these search request have no 
results.

Running DSpace 5.4 on SLES Linux, tomcat 7, java 7, jspui

In the dspace log, I find numerous requests like these: 
ip_addr=66.249.76.34:search:scope=org.dspace.content.Community@287,query="null",results=(0,0,0)

in tomcat localhost-access log
66.249.76.34  - - [24/Oct/2017:01:05:30 +0200] "GET 
/handle/1820/2145/simple-search?location=1820%2F2145=_field_1=dateIssued_type_1=equals_value_1=2011_field_2=author_type_2=equals_value_2=Van+Hooft%2C+W.+F._field_3=author_type_3=equals_value_3=Leirs%2C+H._field_4=author_type_4=equals_value_4=Bauer%2C+H._field_5=subject_type_5=equals_value_5=phylogeography_field_6=author_type_6=equals_value_6=Van+Haeringen%2C+W.+A._field_7=author_type_7=equals_value_7=Bertola%2C+L.+D._field_8=subject_type_8=equals_value_8=evolutionary+history_field_9=author_type_9=equals_value_9=Tumenta%2C+P.+N._field_10=author_type_10=equals_value_10=York%2C+D.+S._field_11=subject_type_11=equals_value_11=Panthera+leo=5_by=dc.title_sort=DESC=0
 
HTTP/1.1" 200 30123 - /handle/1820/2145/simple-search
- 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
/solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=subject_keyword%3ASubsidiarity=subject_keyword%3ACollaborative%5C+Learning=subject_keyword%3AVirtual%5C+Campus=dateIssued_keyword%3A2009=subject_keyword%3AOrganizational%5C+Model=subject_keyword%3ALearning%5C+for%5C+Sustainable%5C+Development=subject_keyword%3AVirtual%5C+Mobility=subject_keyword%3ANetworked%5C+Learning=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+asc=javabin=2
 
HTTP/1.1" 200 611 - /solr/search/select
- 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
/solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=subject_keyword%3ASubsidiarity=subject_keyword%3ACollaborative%5C+Learning=subject_keyword%3AVirtual%5C+Campus=dateIssued_keyword%3A2009=subject_keyword%3AOrganizational%5C+Model=subject_keyword%3ALearning%5C+for%5C+Sustainable%5C+Development=subject_keyword%3AVirtual%5C+Mobility=subject_keyword%3ANetworked%5C+Learning=location%3Am18=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+desc=javabin=2
 
HTTP/1.1" 200 625 - /solr/search/select
- 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
/solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=dateIssued_keyword%3A2011=subject_keyword%3Alion=author_keyword%3ASogbohossou%2C%5C+E.=author_keyword%3AVan%5C+Haeringen%2C%5C+W.%5C+A.=author_keyword%3AVan%5C+Hooft%2C%5C+W.%5C+F.=subject_keyword%3AWest%5C+Africa=subject_keyword%3Aphylogenetics=author_keyword%3APrins%2C%5C+H.%5C+H.%5C+T.=author_keyword%3AYork%2C%5C+D.%5C+S.=author_keyword%3AUit%5C+de%5C+Weerd%2C%5C+D.%5C+R.=author_keyword%3AFunston%2C%5C+P.%5C+J.=subject_keyword%3Aevolutionary%5C+history=author_keyword%3AUdo%5C+de%5C+Haes%2C%5C+H.%5C+A.=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+asc=javabin=2
 
HTTP/1.1" 200 740 - /solr/search/select
- 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET 
/solr/search/select?q=*%3A*=dateIssued.year%2Chandle%2Csearch.resourcetype%2Csearch.resourceid=NOT%28withdrawn%3Atrue%29=NOT%28discoverable%3Afalse%29=dateIssued_keyword%3A2011=subject_keyword%3Alion=author_keyword%3ASogbohossou%2C%5C+E.=author_keyword%3AVan%5C+Haeringen%2C%5C+W.%5C+A.=author_keyword%3AVan%5C+Hooft%2C%5C+W.%5C+F.=subject_keyword%3AWest%5C+Africa=subject_keyword%3Aphylogenetics=author_keyword%3APrins%2C%5C+H.%5C+H.%5C+T.=author_keyword%3AYork%2C%5C+D.%5C+S.=author_keyword%3AUit%5C+de%5C+Weerd%2C%5C+D.%5C+R.=author_keyword%3AFunston%2C%5C+P.%5C+J.=subject_keyword%3Aevolutionary%5C+history=author_keyword%3AUdo%5C+de%5C+Haes%2C%5C+H.%5C+A.=location%3Am18=location%3Am18=dateIssued.year%3A%5B*+TO+*%5D=read%3A%28g0+OR+g0%29=0=1=dateIssued.year_sort+desc=javabin=2
 
HTTP/1.1" 200 758 - /solr/search/select
- 127.0.0.1 - - [24/Oct/2017:01:05:30 +0200] "GET

[dspace-tech] Re: OAI questions

2017-10-25 Thread Evgeni Dimitrov 
Hi,

One can do everything. And it is easy.

One can define new format - providing an xsl which transforms from xoai to 
the new format. If one needs more then one can call Java from the xsl.

One can define new filter based on existing conditions and if necessary one 
can code a new condition in Java.

On Tuesday, October 24, 2017 at 10:24:08 PM UTC+3, Keith Jones wrote:
>
>
> Hi,
>
> I'm trying to find information about how much customizing one can do with 
> OAI harvesting.
> Is it possible to define what level of data is returned when a Dspace 
> repository is accessed via OAI.
> Can you also set up different data returned based on 
> Community/Collection/Item levels?
>
> Thanks
> Keith
>
>

-- 
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] Cleaning the .bak

2017-10-25 Thread Olivier 
Hello,

I am in desperate need to cleanup some space on my DSpace drive.

I have a serie of directories called webapps.bak-date-time that take a
total of 7GB, the last one having a date of Nov 2015. I want to know how
safe it is to remove them?

I am using DSpace 4.2

Thanks in advance,

Olivier
-- 

-- 
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] Bad characters for OAI

2017-10-25 Thread Mariangels 
Hello,

We are working with DSpace 5.5 and Mirage theme.

We are having problems with the characters for OAI. The words with 
accent... Please look:

http://repositori.uvic.cat/oai/request?verb=ListSets

Where can I look for try to fix this problem?

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.

[dspace-tech] email test script works but jspui doesn't

2017-10-25 Thread Seun Ojedeji 
Hello,

The dspace email test script works but doing a password reset, registering 
a new account(which involves sending confirmation mail) or submitting a 
feedback form on the jspui interface returns error. I have not been able to 
figure out what could be the cause of this and will appreciate any pointer.

Regards

-- 
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] Mirage 2 layout for DSpace 5.5

2017-10-25 Thread Sisay Webshet 
Hello Everybody,

Here is the page (https://dspacetest.cgiar.org/handle/10568/80923) and 
we want to bring the collections and recent submissions on top of 
sub communities.

Hint:  DSpace 5.5 on Mirage2.
Iam happy if I may get your support on this.

Thanks,Sisay



-- 
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.