[dspace-tech] I am missing something in the build of DSpace 7
I want to start it in Tomcat.
1. I downloaded DSpace-master.zip and dspace-angular-master.zip from github
2. I built the dspace part as usual - maven, ant and deployed to
Tomcat/webapps
3. For the angular part I did:
yarn run global
yarn install
yarn run build:prod
Before that I changed (perhaps wrongly) in environment.dev.js and
environment.prod.js
// Angular Universal server settings.
ui: {
ssl: false,
host: 'localhost',
port: 8080,
// NOTE: Space is capitalized because 'namespace' is a reserved string
in TypeScript
nameSpace: '/dist'
},
// The REST API server settings.
rest: {
ssl: true,
host: 'localhost',
port: 8080,
// NOTE: Space is capitalized because 'namespace' is a reserved string
in TypeScript
nameSpace: '/spring-rest'
},
4. I started Tomcat and tried http://localhost:8080/dist
The message was that a file is not found at localhost:8080/
Any suggestions what should be done differently?
Virus-free.
www.avast.com
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
All messages to this mailing list should adhere to the DuraSpace Code of
Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
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] View Statistics links not working
Frustrated and starting fresh Monday morning. I commented out ALL of the virtual host configurations in my vhosts.conf file for ports 80 and 443; nothing remains. So, anything that goes through httpd will thus fall through the file untouched. Sure enough, as I expected, port 8080 continued to work just fine. So the problem must be in the httpd setup someplace. When I saw nothing obvious in the configuration I went back to the DSpace5.5 manual and might've found the culprit. There is a warning that Apache 2.4.2 (or lower) breaks the connection to the backend (Tomcat). I'd seen that warning before but, since it just said "Apache" (and I wasn't using httpd at the time) I thought it meant Apache Tomcat, so all was fine. Today I checked our version of httpd; we are running Apache/2.2.15. Updating httpd via yum gave the same version of httpd, just one compiled in Feb 2018 rather than Jul 2017. If that didn't fix the problem I'll obtain the source code and compile a version of httpd newer than v2.4.2. Stay tuned... Nope, that broke it so now even port 8080 doesn't work. Sigh... Looking for source code for Apache httpd. On Friday, October 26, 2018 at 1:23:45 PM UTC-8, wlruth...@alaska.edu wrote: > > Yes, it does make sense. It also means I must have something misconfigured > because the only way I can > currently access the site is if I explicitly specify http and port 8080 - > http://dspace36a.library.uaf.edu:8080/ > > > On Friday, October 26, 2018 at 12:37:42 PM UTC-8, Tim Donohue wrote: > > Hi Walter, > > No worries, we've all been newbies at some point :) > > Port 8080 is Tomcat. It should not be defined in Apache configuration. > Think of it this way, when you use Apache in front of Tomcat... your Tomcat > ports do *not* need to be publicly accessible. They are just internal ports > (only accessible on localhost). > > So, in the setup I described above, my *only public ports* are port 80 and > 443. I don't have port 8080 or port 8009 available publicly, so you cannot > access my site via http://my.url:8080/ (for example). Port 8080 and 8009 > are only accessible on the server (so they are private ports). So, if I > login to the server and do a "wget http://localhost:8080"; then Tomcat > responds. And Port 8009 is just used for proxying requests between Apache > and Tomcat on that server. > > So, with regards to SSL, in my setup the only port where SSL is configured > is port 443. As I have port 80 (HTTP) requests redirecting to port 443 > (HTTPS), *all* public requests (except sometimes OAI, as mentioned) go > through SSL. *After* SSL is validated, those requests *all* get proxied to > Tomcat (via port 8009). Port 8009 and 8080 don't need SSL (again, cause > they are not public ports and cannot be accessed unless you first login > directly on the server). > > Does that start to make a bit more sense? > > Tim > > On Fri, Oct 26, 2018 at 3:28 PM wrote: > > Good to know. That should simplify things. > > Now for the embarrassing newb questions. I'm still not clear how my httpd > secures port 8080 > (which everything is going through now) since a URL that includes port > 8080 isn't handled by > the port 443 virtual host configuration. And how does port 8009 (AJP > Tomcat) get involved; > it also is only referenced in the port 80 and 443 configurations. Your > example didn't show any- > configuration for port 8080 which otherwise should just fall thru the > other virtual hosts checks. > > I'm pretty sure I still have something misconfigured since our port 8080 > refuses any https > connection attempts, so I think SSL is being completely ignored. From your > earlier post httpd > should be handling all connection attempts first then passing control to > Tomcat. I added some > dummy rewrites to the port 80 and 443 vhost definitions that redirect to a > different site if the > URI matches "/catalog"; they are both definitely catching and handling > URLs for those ports. > > Do you also have a virtual host configuration for port 8080 and does it > also Proxy via 8009? > > Thank you, > > Walter R. > > > On Friday, October 26, 2018 at 10:17:46 AM UTC-8, Tim Donohue wrote: > > Hi Walter, > > The dspace.cfg settings (any that use a URL) do not *require* a port > number. The port number only needs to be specified if it's a non-standard > port (e.g. 8080). So, if you are using port 80 or 443, those can be left > off of any configuration as long as you appropriately use http:// or > https:// where necessary. > > > - Tim > > On Thu, Oct 25, 2018 at 6:04 PM wrote: > > Thanks, that does help clarify a lot. > > I already have port 80 forwarding everything to port 443 and I saw that > the AJP port was already setup by default in server.xml. > I just hadn't seen in the DSpace manual where I needed it and I wasn't > sure what it was used for. All that I'm missing is a virtual > host entry like you use to redirect (most) connections to pass thru to > Tomcat AJP. We've t
RE: [dspace-tech] View Statistics links not working
Hi Walter, I don’t think you need the DocumentRoot in the VirtualHost (since it’s a reverse-proxy). -- Sean From: dspace-tech@googlegroups.com On Behalf Of wlrutherf...@alaska.edu Sent: October 26, 2018 4:24 PM To: DSpace Technical Support Subject: Re: [dspace-tech] View Statistics links not working Yes, it does make sense. It also means I must have something misconfigured because the only way I can currently access the site is if I explicitly specify http and port 8080 - http://dspace36a.library.uaf.edu:8080/ On Friday, October 26, 2018 at 12:37:42 PM UTC-8, Tim Donohue wrote: Hi Walter, No worries, we've all been newbies at some point :) Port 8080 is Tomcat. It should not be defined in Apache configuration. Think of it this way, when you use Apache in front of Tomcat... your Tomcat ports do *not* need to be publicly accessible. They are just internal ports (only accessible on localhost). So, in the setup I described above, my *only public ports* are port 80 and 443. I don't have port 8080 or port 8009 available publicly, so you cannot access my site via http://my.url:8080/ (for example). Port 8080 and 8009 are only accessible on the server (so they are private ports). So, if I login to the server and do a "wget http://localhost:8080"; then Tomcat responds. And Port 8009 is just used for proxying requests between Apache and Tomcat on that server. So, with regards to SSL, in my setup the only port where SSL is configured is port 443. As I have port 80 (HTTP) requests redirecting to port 443 (HTTPS), *all* public requests (except sometimes OAI, as mentioned) go through SSL. *After* SSL is validated, those requests *all* get proxied to Tomcat (via port 8009). Port 8009 and 8080 don't need SSL (again, cause they are not public ports and cannot be accessed unless you first login directly on the server). Does that start to make a bit more sense? Tim On Fri, Oct 26, 2018 at 3:28 PM > wrote: Good to know. That should simplify things. Now for the embarrassing newb questions. I'm still not clear how my httpd secures port 8080 (which everything is going through now) since a URL that includes port 8080 isn't handled by the port 443 virtual host configuration. And how does port 8009 (AJP Tomcat) get involved; it also is only referenced in the port 80 and 443 configurations. Your example didn't show any- configuration for port 8080 which otherwise should just fall thru the other virtual hosts checks. I'm pretty sure I still have something misconfigured since our port 8080 refuses any https connection attempts, so I think SSL is being completely ignored. From your earlier post httpd should be handling all connection attempts first then passing control to Tomcat. I added some dummy rewrites to the port 80 and 443 vhost definitions that redirect to a different site if the URI matches "/catalog"; they are both definitely catching and handling URLs for those ports. Do you also have a virtual host configuration for port 8080 and does it also Proxy via 8009? Thank you, Walter R. On Friday, October 26, 2018 at 10:17:46 AM UTC-8, Tim Donohue wrote: Hi Walter, The dspace.cfg settings (any that use a URL) do not *require* a port number. The port number only needs to be specified if it's a non-standard port (e.g. 8080). So, if you are using port 80 or 443, those can be left off of any configuration as long as you appropriately use http:// or https:// where necessary. - Tim On Thu, Oct 25, 2018 at 6:04 PM mailto:wlruth...@alaska.edu>> wrote: Thanks, that does help clarify a lot. I already have port 80 forwarding everything to port 443 and I saw that the AJP port was already setup by default in server.xml. I just hadn't seen in the DSpace manual where I needed it and I wasn't sure what it was used for. All that I'm missing is a virtual host entry like you use to redirect (most) connections to pass thru to Tomcat AJP. We've tested OAI and it was working through port 443, but I'll keep that bypass in mind in case one of the other associated campuses has an SSL incompatible setup. The instructions/comments in the default dspace.cfg file say to include the port numbers for dspace.baseUrl and dspace.url, but your dspace.url does not include a port number. So I assume your dspace.baseUrl also doesn't include a port number and just lets rewrite rules handle that? Or does it even matter since all roads eventually lead to port 8009? I tried the new setup. httpd and Tomcat started but I ended up with the same situation. Only port 8080 is responding; ports 80 and 443 fail with an error: You don't have permission to access / on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. So I tried again with port 443 defined in dspace.url and dspace.baseUrl. No change. Still getting the above error. So I'm still missing something. This is what my new simpler vhosts.conf file looks like:
Re: [dspace-tech] To bundle or not to bundle
Hello Nils, I've done my best to answer your questions inline below... On Mon, Oct 29, 2018 at 7:09 AM wrote: > Both options have their pros and cons. To make an informed decision it > would be very helpful if our current assumptions about how bundles work are > true: > 1. A bundle is more or less a group of files inside a DSPace Item. > Correct. > 2. The standard way to do things is to only use Bundle:ORIGINAL. There are > no other bundle types available through the UI and, even more important, > other bundle types cannot be accessed/selected for uploads via the > addItemBitstream method in the REST API. > Correct, unless you modify the UI. It is possible, for example, in the XMLUI to customize your theme to display files from other Bundles. But, by default, DSpace only displays the ORIGINAL bundle > 3. You cannot change, alter or add to bundles once they are created. You > also cannot move a bundle into another bundle or item after creation. > Technically false, but it depends on what you mean by this. You can change/alter/add to bundles both through the UI (Edit Item screens) and through the Java API. However, the functionality of the current REST API is very limited in this area, and I don't think these features are available in the REST API yet. I don't believe you can move Bundles, unless you did so via custom database queries (not recommended). > 4. Bundles can be created through the Simple Archive Format or through > METS while importing or exporting to/from DSPace. The Bundle explicitly > defined inside the SAF/METS files will be created by DSpace without > further questions. > I'm not entirely sure that Bundles are auto-createdand it may depend on the import mechanism. You may want to simply test this...from the code though, it looks to me like the Bundle may need to exist prior to running Simple Archive Format or METS import. > 5. You cannot access a bundle directly but will always have to access the > item first. An item can be accessed through its UUID or its handle. You can > get a list of an items contents and access the bitstreams of the bundles > listed there. Therefore, the bundle is received as text when the item is > queried. > Depends on what you mean by "access". Bundles are actual objects in the database / Java API layer. So, you can access them in the Java API. But, in the UI and REST API, they usually just appear as "text". You are correct though that an Item can always be accessed through its UUID or handle. > 6. There is no special protection for bundles. DSpace does not provide a > fine-grained access control allowing access to a single bundle (let's say > "usage") but not another (say "master" ) belonging to the same Item. > > DSpace does not provide a special way to pre-configure access rights based on a bundle's "name". However, you *can* change access rights per bundle (after submission). Bundles are listed in the "Authorization Policies" of an Item, if you go to the "Edit Item" screen, and you can change their permissions like any other object. Hopefully that helps! Let us know on this list if you have more questions! Tim -- Tim Donohue Technical Lead for DSpace & DSpaceDirect DuraSpace.org | DSpace.org | DSpaceDirect.org -- All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/ --- 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] To bundle or not to bundle
Hello DSpace-Community,
we are currently planning to use DSpace as a repository for a reasonably big
(>> 100 TB) collection of images i.e. digitized archival assets.
Right now we need to figure out how to efficiently use the DSpace Content
Object Model (as described in
https://wiki.duraspace.org/display/DSPACE/DSpaceMETSSIPProfile ).
1. For one archival object / digitized asset we do not only have one image file
/ bitstream but four:
1. high resolution TIFF ("master")
2. good resolution JPEG ("usage")
3. lower resolution JPEG ("preview")
4. tiny JPEG ("thumbnail")
2. Users interact with our online finding aid which will have to retrieve the
requested images from DSpace via REST.
3. We could put all four bitstreams, belonging to the same archival item, under
one DSpace Item and place them in different bundles, each of them identifyable
through different tags in "Bundle:" for the different file types. Or we could
just move our currently used archival hierarchy one level up and make every
archival item a DSpace Collection, hence placing every bitstream under its own
DSpace Item with Bundle:ORIGINAL and different DC entries for "Type:".
Both options have their pros and cons. To make an informed decision it would be
very helpful if our current assumptions about how bundles work are true:
1. A bundle is more or less a group of files inside a DSPace Item.
2. The standard way to do things is to only use Bundle:ORIGINAL. There are no
other bundle types available through the UI and, even more important, other
bundle types cannot be accessed/selected for uploads via the addItemBitstream
method in the REST API.
3. You cannot change, alter or add to bundles once they are created. You also
cannot move a bundle into another bundle or item after creation.
4. Bundles can be created through the Simple Archive Format or through METS
while importing or exporting to/from DSPace. The Bundle explicitly defined
inside the SAF/METS files will be created by DSpace without further questions.
5. You cannot access a bundle directly but will always have to access the item
first. An item can be accessed through its UUID or its handle. You can get a
list of an items contents and access the bitstreams of the bundles listed
there. Therefore, the bundle is received as text when the item is queried.
6. There is no special protection for bundles. DSpace does not provide a
fine-grained access control allowing access to a single bundle (let's say
"usage") but not another (say "master" ) belonging to the same Item.
Any help confirming or disconfirming these assumptions would be of great value
and highly appreciated.
Thanks a lot!
Take care
Nils
- - - - - - - - - - - -
_Referent für Digitalisierung / _Hessisches Landesarchiv
Nils Reichert \
\ Friedrichsplatz 15
Tel.: 06421 9250-108 / 35037 Marburg
--
All messages to this mailing list should adhere to the DuraSpace Code of
Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
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.
