[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Chris Clawson
A bit late?? I will have this answered tomorrow (12/28). Solr now installed 
completely and I have fixed other errors. My web browser shows loads of 
CORS errors but less than I had.
I will make a summary and answer the tomcat install question later.
My Rest runs out of tomcat. You can view quite a summary by looking at my 
HAL browser at: https://meloware.com:8443/#/api  SSL port 8443 is where my 
DSpace 6.3 install runs at https://montaguearchive.org:8443/ . Maybe I have 
a problem using this port. Thanks and good night.

On Tuesday, December 28, 2021 at 7:03:59 PM UTC-5 Mohammad S. AlMutairi 
wrote:

> It is a little bit late here. Looking at what you posted as a tomcat entry 
> in the /etc/passwd file showed the tomcat user was either created manually 
> or by the solr installation script but was not created by apt ( apt install 
> tomcat9 ) so here comes a couple of questions. How did you install tomcat? 
> and which service did you install first tomcat? or solr?. See how the entry 
> looks like if it was installed by apt. ( tomcat:x:999:999:Apache 
> Tomcat:/:/sbin/nologin ). What I mean Apache Tomcat is what's in the name 
> field.
>
>
>
> On Wednesday, December 29, 2021 at 2:01:10 AM UTC+3 Chris Clawson wrote:
>
>> Oops! I just saw this question after making the changes to the tomcat 
>> user. The command now produces:
>> $ grep tomcat /etc/passwd
>> tomcat:x:1003:1004::/home/tomcat:/bin/bash
>>
>> On Tuesday, December 28, 2021 at 5:42:30 PM UTC-5 Mohammad S. AlMutairi 
>> wrote:
>>
>>> I was able to replicate the issue you have (see the attached snapshot). 
>>> It turned out it's happening when the user tomcat is defaulted to have the 
>>> login shell in /etc/passwd set to /sbin/nologin .. To resolve it you need 
>>> to execute the commands you see below in the sequence you see them and then 
>>> start the solr installation in the first post.
>>>
>>> 1) usermod -d /home/tomcat -s /bin/bash tomcat
>>> 2) mkhomedir_helper tomcat
>>> 3) passwd tomcat
>>>
>>> Good luck
>>> On Tuesday, December 28, 2021 at 9:37:23 PM UTC+3 Chris Clawson wrote:
>>>
 This is a KVM cloud server hosted at http://www.tektonic.net/. It is a 
 basic LAMP installation and has a Wordpress site installed (
 meloware.com) . I am trying to install DSpace 7 in preparation for 
 upgrading a live database DSpace 6.3 installation on a different cloud 
 VPS. 
 This Ubuntu 18 vps is a service I have been using for a few years. It is 
 not a new installation. The vps is installed in a very minimal 
 configuration and is not likely to have any packages installed that I 
 didn't do myself. The service allows 2 cpu cores and 4GB of ram. I have 
 full root access and can only re-install everything if I break it. I 
 believe Ubuntu 18 is compatible and I think I have  installed all the 
 packages required for DSpace 7. When building this DSpace with yarn, my 
 system ran out of memory. I was eventually able to get it to complete by 
 shutting down Tomcat during the build process.

 The command 'sestatus' was not available as a command, so I installed 
 policycoreutils. Now the command says "SELinux status: 
 disabled".

 The command, aa-status, produced the following:
 root@media:/# aa-status
 apparmor module is loaded.
 10 profiles are loaded.
 10 profiles are in enforce mode.
/sbin/dhclient
/usr/bin/man
/usr/lib/NetworkManager/nm-dhcp-client.action
/usr/lib/NetworkManager/nm-dhcp-helper
/usr/lib/connman/scripts/dhclient-script
/usr/sbin/mysqld
/usr/sbin/ntpd
/usr/sbin/tcpdump
man_filter
man_groff
 0 profiles are in complain mode.
 1 processes have profiles defined.
 1 processes are in enforce mode.
/usr/sbin/mysqld (867)
 0 processes are in complain mode.
 0 processes are unconfined but have a profile defined.
 root@media:/#

 It looks like someone is hammering ports for my root access. This  IP  
 221.131.165.50 is not anything I am part of and is probably a hacker. Here 
 are the last few lines from the journal:

 Dec 28 12:15:11 media sshd[2824]: Disconnected from authenticating user 
 root 221.131.165.50 port 19567 [preauth]
 Dec 28 12:15:11 media sshd[2824]: PAM 2 more authentication failures; 
 logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50  user=root
 Dec 28 12:15:13 media sshd[2826]: pam_unix(sshd:auth): authentication 
 failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50 
  user=root
 Dec 28 12:15:15 media sshd[2826]: Failed password for root from 
 221.131.165.50 port 16020 ssh2
 Dec 28 12:15:17 media sshd[2826]: Failed password for root from 
 221.131.165.50 port 16020 ssh2

 *
 Isn't the problem now related to permissions and setting up solr as a 
 startup service? I can always change any user:group 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Chris Clawson
Oops! I just saw this question after making the changes to the tomcat user. 
The command now produces:
$ grep tomcat /etc/passwd
tomcat:x:1003:1004::/home/tomcat:/bin/bash

On Tuesday, December 28, 2021 at 5:42:30 PM UTC-5 Mohammad S. AlMutairi 
wrote:

> I was able to replicate the issue you have (see the attached snapshot). It 
> turned out it's happening when the user tomcat is defaulted to have the 
> login shell in /etc/passwd set to /sbin/nologin .. To resolve it you need 
> to execute the commands you see below in the sequence you see them and then 
> start the solr installation in the first post.
>
> 1) usermod -d /home/tomcat -s /bin/bash tomcat
> 2) mkhomedir_helper tomcat
> 3) passwd tomcat
>
> Good luck
> On Tuesday, December 28, 2021 at 9:37:23 PM UTC+3 Chris Clawson wrote:
>
>> This is a KVM cloud server hosted at http://www.tektonic.net/. It is a 
>> basic LAMP installation and has a Wordpress site installed (meloware.com) 
>> . I am trying to install DSpace 7 in preparation for upgrading a live 
>> database DSpace 6.3 installation on a different cloud VPS. This Ubuntu 18 
>> vps is a service I have been using for a few years. It is not a new 
>> installation. The vps is installed in a very minimal configuration and is 
>> not likely to have any packages installed that I didn't do myself. The 
>> service allows 2 cpu cores and 4GB of ram. I have full root access and can 
>> only re-install everything if I break it. I believe Ubuntu 18 is compatible 
>> and I think I have  installed all the packages required for DSpace 7. When 
>> building this DSpace with yarn, my system ran out of memory. I was 
>> eventually able to get it to complete by shutting down Tomcat during the 
>> build process.
>>
>> The command 'sestatus' was not available as a command, so I installed 
>> policycoreutils. Now the command says "SELinux status: 
>> disabled".
>>
>> The command, aa-status, produced the following:
>> root@media:/# aa-status
>> apparmor module is loaded.
>> 10 profiles are loaded.
>> 10 profiles are in enforce mode.
>>/sbin/dhclient
>>/usr/bin/man
>>/usr/lib/NetworkManager/nm-dhcp-client.action
>>/usr/lib/NetworkManager/nm-dhcp-helper
>>/usr/lib/connman/scripts/dhclient-script
>>/usr/sbin/mysqld
>>/usr/sbin/ntpd
>>/usr/sbin/tcpdump
>>man_filter
>>man_groff
>> 0 profiles are in complain mode.
>> 1 processes have profiles defined.
>> 1 processes are in enforce mode.
>>/usr/sbin/mysqld (867)
>> 0 processes are in complain mode.
>> 0 processes are unconfined but have a profile defined.
>> root@media:/#
>>
>> It looks like someone is hammering ports for my root access. This  IP  
>> 221.131.165.50 is not anything I am part of and is probably a hacker. Here 
>> are the last few lines from the journal:
>>
>> Dec 28 12:15:11 media sshd[2824]: Disconnected from authenticating user 
>> root 221.131.165.50 port 19567 [preauth]
>> Dec 28 12:15:11 media sshd[2824]: PAM 2 more authentication failures; 
>> logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50  user=root
>> Dec 28 12:15:13 media sshd[2826]: pam_unix(sshd:auth): authentication 
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50 
>>  user=root
>> Dec 28 12:15:15 media sshd[2826]: Failed password for root from 
>> 221.131.165.50 port 16020 ssh2
>> Dec 28 12:15:17 media sshd[2826]: Failed password for root from 
>> 221.131.165.50 port 16020 ssh2
>>
>> *
>> Isn't the problem now related to permissions and setting up solr as a 
>> startup service? I can always change any user:group ownership as needed. 
>> When I used the DSpace 7 installation page, Solr would only install without 
>> making any changes to the owners or permissions. Solr only installed when 
>> the default 'solr' user was created. Any attempt to mention 'tomcat' 
>> resulted in the same error I am seeing now, when it seems the solr.service 
>> is being setup.
>>
>> I appreciate this help! DSpace is far more valuable than simply confining 
>> it to universities. There are many civil organizations in the world, which 
>> have major private collections and need to share them. Besides, many of we 
>> historians are dying off from old age. If we can't organize these 
>> collections and contribute our historic metadata, what happens to the 
>> history after we are all gone?
>> On Tuesday, December 28, 2021 at 12:53:32 PM UTC-5 Mohammad S. AlMutairi 
>> wrote:
>>
>>> Honestly I'm guessing here because the lack of information about your 
>>> server and or what has been done to it :-). As a first guess do you have 
>>> SELinux or AppArmor installed and enabled on your server? Can you check 
>>> it by typing as root the commands you see below.
>>>
>>> # To check SELinux
>>> sestatus
>>>
>>> # To check AppArmor
>>> aa-status
>>>
>>> # I want you to send the result of this command too.
>>> journalctl -xe
>>>
>>> I'll walk you through it if you provide enough information to pin point 
>>> the issue with your server 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Chris Clawson
I will try that. I need to give it a rest and regroup my thinking. After I 
have summarized what I have done, I can ask more intelligent questions, if 
needed. I am guessing it is late for you, so thanks and we may talk later.
C.

On Tuesday, December 28, 2021 at 5:42:30 PM UTC-5 Mohammad S. AlMutairi 
wrote:

> I was able to replicate the issue you have (see the attached snapshot). It 
> turned out it's happening when the user tomcat is defaulted to have the 
> login shell in /etc/passwd set to /sbin/nologin .. To resolve it you need 
> to execute the commands you see below in the sequence you see them and then 
> start the solr installation in the first post.
>
> 1) usermod -d /home/tomcat -s /bin/bash tomcat
> 2) mkhomedir_helper tomcat
> 3) passwd tomcat
>
> Good luck
> On Tuesday, December 28, 2021 at 9:37:23 PM UTC+3 Chris Clawson wrote:
>
>> This is a KVM cloud server hosted at http://www.tektonic.net/. It is a 
>> basic LAMP installation and has a Wordpress site installed (meloware.com) 
>> . I am trying to install DSpace 7 in preparation for upgrading a live 
>> database DSpace 6.3 installation on a different cloud VPS. This Ubuntu 18 
>> vps is a service I have been using for a few years. It is not a new 
>> installation. The vps is installed in a very minimal configuration and is 
>> not likely to have any packages installed that I didn't do myself. The 
>> service allows 2 cpu cores and 4GB of ram. I have full root access and can 
>> only re-install everything if I break it. I believe Ubuntu 18 is compatible 
>> and I think I have  installed all the packages required for DSpace 7. When 
>> building this DSpace with yarn, my system ran out of memory. I was 
>> eventually able to get it to complete by shutting down Tomcat during the 
>> build process.
>>
>> The command 'sestatus' was not available as a command, so I installed 
>> policycoreutils. Now the command says "SELinux status: 
>> disabled".
>>
>> The command, aa-status, produced the following:
>> root@media:/# aa-status
>> apparmor module is loaded.
>> 10 profiles are loaded.
>> 10 profiles are in enforce mode.
>>/sbin/dhclient
>>/usr/bin/man
>>/usr/lib/NetworkManager/nm-dhcp-client.action
>>/usr/lib/NetworkManager/nm-dhcp-helper
>>/usr/lib/connman/scripts/dhclient-script
>>/usr/sbin/mysqld
>>/usr/sbin/ntpd
>>/usr/sbin/tcpdump
>>man_filter
>>man_groff
>> 0 profiles are in complain mode.
>> 1 processes have profiles defined.
>> 1 processes are in enforce mode.
>>/usr/sbin/mysqld (867)
>> 0 processes are in complain mode.
>> 0 processes are unconfined but have a profile defined.
>> root@media:/#
>>
>> It looks like someone is hammering ports for my root access. This  IP  
>> 221.131.165.50 is not anything I am part of and is probably a hacker. Here 
>> are the last few lines from the journal:
>>
>> Dec 28 12:15:11 media sshd[2824]: Disconnected from authenticating user 
>> root 221.131.165.50 port 19567 [preauth]
>> Dec 28 12:15:11 media sshd[2824]: PAM 2 more authentication failures; 
>> logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50  user=root
>> Dec 28 12:15:13 media sshd[2826]: pam_unix(sshd:auth): authentication 
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50 
>>  user=root
>> Dec 28 12:15:15 media sshd[2826]: Failed password for root from 
>> 221.131.165.50 port 16020 ssh2
>> Dec 28 12:15:17 media sshd[2826]: Failed password for root from 
>> 221.131.165.50 port 16020 ssh2
>>
>> *
>> Isn't the problem now related to permissions and setting up solr as a 
>> startup service? I can always change any user:group ownership as needed. 
>> When I used the DSpace 7 installation page, Solr would only install without 
>> making any changes to the owners or permissions. Solr only installed when 
>> the default 'solr' user was created. Any attempt to mention 'tomcat' 
>> resulted in the same error I am seeing now, when it seems the solr.service 
>> is being setup.
>>
>> I appreciate this help! DSpace is far more valuable than simply confining 
>> it to universities. There are many civil organizations in the world, which 
>> have major private collections and need to share them. Besides, many of we 
>> historians are dying off from old age. If we can't organize these 
>> collections and contribute our historic metadata, what happens to the 
>> history after we are all gone?
>> On Tuesday, December 28, 2021 at 12:53:32 PM UTC-5 Mohammad S. AlMutairi 
>> wrote:
>>
>>> Honestly I'm guessing here because the lack of information about your 
>>> server and or what has been done to it :-). As a first guess do you have 
>>> SELinux or AppArmor installed and enabled on your server? Can you check 
>>> it by typing as root the commands you see below.
>>>
>>> # To check SELinux
>>> sestatus
>>>
>>> # To check AppArmor
>>> aa-status
>>>
>>> # I want you to send the result of this command too.
>>> journalctl -xe
>>>
>>> I'll walk you through it if you provide 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Mohammad S. AlMutairi
Is it possible to to send me the result of this command?. 

grep tomcat /etc/passwd

On Wednesday, December 29, 2021 at 1:42:30 AM UTC+3 Mohammad S. AlMutairi 
wrote:

> I was able to replicate the issue you have (see the attached snapshot). It 
> turned out it's happening when the user tomcat is defaulted to have the 
> login shell in /etc/passwd set to /sbin/nologin .. To resolve it you need 
> to execute the commands you see below in the sequence you see them and then 
> start the solr installation in the first post.
>
> 1) usermod -d /home/tomcat -s /bin/bash tomcat
> 2) mkhomedir_helper tomcat
> 3) passwd tomcat
>
> Good luck
> On Tuesday, December 28, 2021 at 9:37:23 PM UTC+3 Chris Clawson wrote:
>
>> This is a KVM cloud server hosted at http://www.tektonic.net/. It is a 
>> basic LAMP installation and has a Wordpress site installed (meloware.com) 
>> . I am trying to install DSpace 7 in preparation for upgrading a live 
>> database DSpace 6.3 installation on a different cloud VPS. This Ubuntu 18 
>> vps is a service I have been using for a few years. It is not a new 
>> installation. The vps is installed in a very minimal configuration and is 
>> not likely to have any packages installed that I didn't do myself. The 
>> service allows 2 cpu cores and 4GB of ram. I have full root access and can 
>> only re-install everything if I break it. I believe Ubuntu 18 is compatible 
>> and I think I have  installed all the packages required for DSpace 7. When 
>> building this DSpace with yarn, my system ran out of memory. I was 
>> eventually able to get it to complete by shutting down Tomcat during the 
>> build process.
>>
>> The command 'sestatus' was not available as a command, so I installed 
>> policycoreutils. Now the command says "SELinux status: 
>> disabled".
>>
>> The command, aa-status, produced the following:
>> root@media:/# aa-status
>> apparmor module is loaded.
>> 10 profiles are loaded.
>> 10 profiles are in enforce mode.
>>/sbin/dhclient
>>/usr/bin/man
>>/usr/lib/NetworkManager/nm-dhcp-client.action
>>/usr/lib/NetworkManager/nm-dhcp-helper
>>/usr/lib/connman/scripts/dhclient-script
>>/usr/sbin/mysqld
>>/usr/sbin/ntpd
>>/usr/sbin/tcpdump
>>man_filter
>>man_groff
>> 0 profiles are in complain mode.
>> 1 processes have profiles defined.
>> 1 processes are in enforce mode.
>>/usr/sbin/mysqld (867)
>> 0 processes are in complain mode.
>> 0 processes are unconfined but have a profile defined.
>> root@media:/#
>>
>> It looks like someone is hammering ports for my root access. This  IP  
>> 221.131.165.50 is not anything I am part of and is probably a hacker. Here 
>> are the last few lines from the journal:
>>
>> Dec 28 12:15:11 media sshd[2824]: Disconnected from authenticating user 
>> root 221.131.165.50 port 19567 [preauth]
>> Dec 28 12:15:11 media sshd[2824]: PAM 2 more authentication failures; 
>> logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50  user=root
>> Dec 28 12:15:13 media sshd[2826]: pam_unix(sshd:auth): authentication 
>> failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50 
>>  user=root
>> Dec 28 12:15:15 media sshd[2826]: Failed password for root from 
>> 221.131.165.50 port 16020 ssh2
>> Dec 28 12:15:17 media sshd[2826]: Failed password for root from 
>> 221.131.165.50 port 16020 ssh2
>>
>> *
>> Isn't the problem now related to permissions and setting up solr as a 
>> startup service? I can always change any user:group ownership as needed. 
>> When I used the DSpace 7 installation page, Solr would only install without 
>> making any changes to the owners or permissions. Solr only installed when 
>> the default 'solr' user was created. Any attempt to mention 'tomcat' 
>> resulted in the same error I am seeing now, when it seems the solr.service 
>> is being setup.
>>
>> I appreciate this help! DSpace is far more valuable than simply confining 
>> it to universities. There are many civil organizations in the world, which 
>> have major private collections and need to share them. Besides, many of we 
>> historians are dying off from old age. If we can't organize these 
>> collections and contribute our historic metadata, what happens to the 
>> history after we are all gone?
>> On Tuesday, December 28, 2021 at 12:53:32 PM UTC-5 Mohammad S. AlMutairi 
>> wrote:
>>
>>> Honestly I'm guessing here because the lack of information about your 
>>> server and or what has been done to it :-). As a first guess do you have 
>>> SELinux or AppArmor installed and enabled on your server? Can you check 
>>> it by typing as root the commands you see below.
>>>
>>> # To check SELinux
>>> sestatus
>>>
>>> # To check AppArmor
>>> aa-status
>>>
>>> # I want you to send the result of this command too.
>>> journalctl -xe
>>>
>>> I'll walk you through it if you provide enough information to pin point 
>>> the issue with your server and it's setup.  You should've installed Ubuntu 
>>> 20.04 LTS instead of 18.04 LTS . 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Chris Clawson
This is a KVM cloud server hosted at http://www.tektonic.net/. It is a 
basic LAMP installation and has a Wordpress site installed (meloware.com) . 
I am trying to install DSpace 7 in preparation for upgrading a live 
database DSpace 6.3 installation on a different cloud VPS. This Ubuntu 18 
vps is a service I have been using for a few years. It is not a new 
installation. The vps is installed in a very minimal configuration and is 
not likely to have any packages installed that I didn't do myself. The 
service allows 2 cpu cores and 4GB of ram. I have full root access and can 
only re-install everything if I break it. I believe Ubuntu 18 is compatible 
and I think I have  installed all the packages required for DSpace 7. When 
building this DSpace with yarn, my system ran out of memory. I was 
eventually able to get it to complete by shutting down Tomcat during the 
build process.

The command 'sestatus' was not available as a command, so I installed 
policycoreutils. Now the command says "SELinux status: 
disabled".

The command, aa-status, produced the following:
root@media:/# aa-status
apparmor module is loaded.
10 profiles are loaded.
10 profiles are in enforce mode.
   /sbin/dhclient
   /usr/bin/man
   /usr/lib/NetworkManager/nm-dhcp-client.action
   /usr/lib/NetworkManager/nm-dhcp-helper
   /usr/lib/connman/scripts/dhclient-script
   /usr/sbin/mysqld
   /usr/sbin/ntpd
   /usr/sbin/tcpdump
   man_filter
   man_groff
0 profiles are in complain mode.
1 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/mysqld (867)
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
root@media:/#

It looks like someone is hammering ports for my root access. This  IP  
221.131.165.50 is not anything I am part of and is probably a hacker. Here 
are the last few lines from the journal:

Dec 28 12:15:11 media sshd[2824]: Disconnected from authenticating user 
root 221.131.165.50 port 19567 [preauth]
Dec 28 12:15:11 media sshd[2824]: PAM 2 more authentication failures; 
logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50  user=root
Dec 28 12:15:13 media sshd[2826]: pam_unix(sshd:auth): authentication 
failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=221.131.165.50 
 user=root
Dec 28 12:15:15 media sshd[2826]: Failed password for root from 
221.131.165.50 port 16020 ssh2
Dec 28 12:15:17 media sshd[2826]: Failed password for root from 
221.131.165.50 port 16020 ssh2

*
Isn't the problem now related to permissions and setting up solr as a 
startup service? I can always change any user:group ownership as needed. 
When I used the DSpace 7 installation page, Solr would only install without 
making any changes to the owners or permissions. Solr only installed when 
the default 'solr' user was created. Any attempt to mention 'tomcat' 
resulted in the same error I am seeing now, when it seems the solr.service 
is being setup.

I appreciate this help! DSpace is far more valuable than simply confining 
it to universities. There are many civil organizations in the world, which 
have major private collections and need to share them. Besides, many of we 
historians are dying off from old age. If we can't organize these 
collections and contribute our historic metadata, what happens to the 
history after we are all gone?
On Tuesday, December 28, 2021 at 12:53:32 PM UTC-5 Mohammad S. AlMutairi 
wrote:

> Honestly I'm guessing here because the lack of information about your 
> server and or what has been done to it :-). As a first guess do you have 
> SELinux or AppArmor installed and enabled on your server? Can you check 
> it by typing as root the commands you see below.
>
> # To check SELinux
> sestatus
>
> # To check AppArmor
> aa-status
>
> # I want you to send the result of this command too.
> journalctl -xe
>
> I'll walk you through it if you provide enough information to pin point 
> the issue with your server and it's setup.  You should've installed Ubuntu 
> 20.04 LTS instead of 18.04 LTS . See why you should've done that here 
> https://wiki.ubuntu.com/Releases
> On Tuesday, December 28, 2021 at 8:05:09 PM UTC+3 Chris Clawson wrote:
>
>> I believe this has happened before... Problems begin with step 'f'. The 
>> following is the output from the bash command:
>>
>> root@media:/build# bash ./install_solr_service.sh solr-8.11.1.tgz -f
>> Extracting solr-8.11.1.tgz to /opt
>> Installing symlink /opt/solr -> /opt/solr-8.11.1 ...
>> Installing /etc/init.d/solr script ...
>> Installing /etc/default/solr.in.sh ...
>> Service solr installed.
>> Customize Solr startup configuration in /etc/default/solr.in.sh
>> Job for solr.service failed because the control process exited with error 
>> code.
>> See "systemctl status solr.service" and "journalctl -xe" for details.
>> ● solr.service - LSB: Controls Apache Solr as a Service
>>Loaded: loaded (/etc/init.d/solr; generated)
>>Active: failed (Result: exit-code) since Tue 2021-12-28 11:00:48 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Mohammad S. AlMutairi
Honestly I'm guessing here because the lack of information about your 
server and or what has been done to it :-). As a first guess do you have 
SELinux or AppArmor installed and enabled on your server? Can you check it 
by typing as root the commands you see below.

# To check SELinux
sestatus

# To check AppArmor
aa-status

# I want you to send the result of this command too.
journalctl -xe

I'll walk you through it if you provide enough information to pin point the 
issue with your server and it's setup.  You should've installed Ubuntu 
20.04 LTS instead of 18.04 LTS . See why you should've done that 
here https://wiki.ubuntu.com/Releases
On Tuesday, December 28, 2021 at 8:05:09 PM UTC+3 Chris Clawson wrote:

> I believe this has happened before... Problems begin with step 'f'. The 
> following is the output from the bash command:
>
> root@media:/build# bash ./install_solr_service.sh solr-8.11.1.tgz -f
> Extracting solr-8.11.1.tgz to /opt
> Installing symlink /opt/solr -> /opt/solr-8.11.1 ...
> Installing /etc/init.d/solr script ...
> Installing /etc/default/solr.in.sh ...
> Service solr installed.
> Customize Solr startup configuration in /etc/default/solr.in.sh
> Job for solr.service failed because the control process exited with error 
> code.
> See "systemctl status solr.service" and "journalctl -xe" for details.
> ● solr.service - LSB: Controls Apache Solr as a Service
>Loaded: loaded (/etc/init.d/solr; generated)
>Active: failed (Result: exit-code) since Tue 2021-12-28 11:00:48 CST; 
> 5s ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 1474 ExecStart=/etc/init.d/solr start (code=exited, 
> status=1/FAILURE)
>
> Dec 28 11:00:48 media systemd[1]: Starting LSB: Controls Apache Solr as a 
> Service...
> Dec 28 11:00:48 media su[1476]: Successful su for tomcat by root
> Dec 28 11:00:48 media su[1476]: + ??? root:tomcat
> Dec 28 11:00:48 media su[1476]: pam_unix(su:session): session opened for 
> user tomcat by (uid=0)
> Dec 28 11:00:48 media su[1476]: pam_unix(su:session): session closed for 
> user tomcat
> Dec 28 11:00:48 media systemd[1]: solr.service: Control process exited, 
> code=exited status=1
> Dec 28 11:00:48 media systemd[1]: solr.service: Failed with result 
> 'exit-code'.
> Dec 28 11:00:48 media systemd[1]: Failed to start LSB: Controls Apache 
> Solr as a Service.
> root@media:/build#
>
> On Tuesday, December 28, 2021 at 9:21:25 AM UTC-5 Mohammad S. AlMutairi 
> wrote:
>
>> Hello Chris,
>>
>> Your solr installation is broken so you really really really must remove 
>> the old installation and begin a fresh install. All the provided 
>> instructions is very simple and easy to follow so just follow it. Regarding 
>> step (e) it just another and easier way of changing SOLR_USER=solr to 
>> SOLR_USER=tomcat using perl substitution. Don't stop at it or the (g) step 
>> just remove the old solr and install solr following the installation steps 
>> above but you MUST BE ROOT during the removal or the installing of Solr to 
>> overcome any permission issues you might confront.
>>
>>  Here is what you suppose to see if Solr and dspace cores are done 
>> correctly. This is part of it.#
>> "search":{
>>   "name":"search",
>>   "instanceDir":"/var/solr/data/search",
>>   "dataDir":"/var/solr/data/search/data/",
>>   "config":"solrconfig.xml",
>>   "schema":"schema.xml",
>>   "startTime":"2021-12-28T10:55:06.841Z",
>>   "uptime":11865277,
>>   "index":{
>> "numDocs":45760,
>> "maxDoc":45760,
>> "deletedDocs":0,
>> "indexHeapUsageBytes":489928,
>> "version":678,
>> "segmentCount":22,
>> "current":true,
>> "hasDeletions":false,
>> 
>> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/search/data/index
>>  
>> lockFactory=org.apache.lucene.store.NativeFSLockFactory@12cd8c11; 
>> maxCacheMB=48.0 maxMergeSizeMB=4.0)",
>> "segmentsFile":"segments_2z",
>> "segmentsFileSizeInBytes":1947,
>> "userData":{
>>   "commitCommandVer":"0",
>>   "commitTimeMSec":"1640647856055"},
>> "lastModified":"2021-12-27T23:30:56.055Z",
>> "sizeInBytes":1641346285,
>> "size":"1.53 GB"}},
>> "statistics":{
>>   "name":"statistics",
>>   "instanceDir":"/var/solr/data/statistics",
>>   "dataDir":"/var/solr/data/statistics/data/",
>>   "config":"solrconfig.xml",
>>   "schema":"schema.xml",
>>   "startTime":"2021-12-28T10:55:07.565Z",
>>   "uptime":11864565,
>>   "index":{
>> "numDocs":78,
>> "maxDoc":78,
>> "deletedDocs":0,
>> "indexHeapUsageBytes":38772,
>> "version":46,
>> "segmentCount":11,
>> "current":false,
>> "hasDeletions":false,
>> 
>> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/statistics/data/index
>>  

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Chris Clawson
I guess things go 'wrong' when trying to setup solr as a service to run at 
system boot time. The script, 'solr.in.sh' gets written into the 
/etc/default  directory. It get the user/group settings of root:tomcat . 
Yes, I am logged in via SSH as root. I believe the /var/solr directories 
are owned by tomcat:tomcat and the /var/solr/logs directory is empty. The 
installation directory at /opt/solr-8.11.1 and the sym link 'solr' are 
root:root as well as all the recursive contents. Is this right? 
On Tuesday, December 28, 2021 at 12:05:09 PM UTC-5 Chris Clawson wrote:

> I believe this has happened before... Problems begin with step 'f'. The 
> following is the output from the bash command:
>
> root@media:/build# bash ./install_solr_service.sh solr-8.11.1.tgz -f
> Extracting solr-8.11.1.tgz to /opt
> Installing symlink /opt/solr -> /opt/solr-8.11.1 ...
> Installing /etc/init.d/solr script ...
> Installing /etc/default/solr.in.sh ...
> Service solr installed.
> Customize Solr startup configuration in /etc/default/solr.in.sh
> Job for solr.service failed because the control process exited with error 
> code.
> See "systemctl status solr.service" and "journalctl -xe" for details.
> ● solr.service - LSB: Controls Apache Solr as a Service
>Loaded: loaded (/etc/init.d/solr; generated)
>Active: failed (Result: exit-code) since Tue 2021-12-28 11:00:48 CST; 
> 5s ago
>  Docs: man:systemd-sysv-generator(8)
>   Process: 1474 ExecStart=/etc/init.d/solr start (code=exited, 
> status=1/FAILURE)
>
> Dec 28 11:00:48 media systemd[1]: Starting LSB: Controls Apache Solr as a 
> Service...
> Dec 28 11:00:48 media su[1476]: Successful su for tomcat by root
> Dec 28 11:00:48 media su[1476]: + ??? root:tomcat
> Dec 28 11:00:48 media su[1476]: pam_unix(su:session): session opened for 
> user tomcat by (uid=0)
> Dec 28 11:00:48 media su[1476]: pam_unix(su:session): session closed for 
> user tomcat
> Dec 28 11:00:48 media systemd[1]: solr.service: Control process exited, 
> code=exited status=1
> Dec 28 11:00:48 media systemd[1]: solr.service: Failed with result 
> 'exit-code'.
> Dec 28 11:00:48 media systemd[1]: Failed to start LSB: Controls Apache 
> Solr as a Service.
> root@media:/build#
>
> On Tuesday, December 28, 2021 at 9:21:25 AM UTC-5 Mohammad S. AlMutairi 
> wrote:
>
>> Hello Chris,
>>
>> Your solr installation is broken so you really really really must remove 
>> the old installation and begin a fresh install. All the provided 
>> instructions is very simple and easy to follow so just follow it. Regarding 
>> step (e) it just another and easier way of changing SOLR_USER=solr to 
>> SOLR_USER=tomcat using perl substitution. Don't stop at it or the (g) step 
>> just remove the old solr and install solr following the installation steps 
>> above but you MUST BE ROOT during the removal or the installing of Solr to 
>> overcome any permission issues you might confront.
>>
>>  Here is what you suppose to see if Solr and dspace cores are done 
>> correctly. This is part of it.#
>> "search":{
>>   "name":"search",
>>   "instanceDir":"/var/solr/data/search",
>>   "dataDir":"/var/solr/data/search/data/",
>>   "config":"solrconfig.xml",
>>   "schema":"schema.xml",
>>   "startTime":"2021-12-28T10:55:06.841Z",
>>   "uptime":11865277,
>>   "index":{
>> "numDocs":45760,
>> "maxDoc":45760,
>> "deletedDocs":0,
>> "indexHeapUsageBytes":489928,
>> "version":678,
>> "segmentCount":22,
>> "current":true,
>> "hasDeletions":false,
>> 
>> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/search/data/index
>>  
>> lockFactory=org.apache.lucene.store.NativeFSLockFactory@12cd8c11; 
>> maxCacheMB=48.0 maxMergeSizeMB=4.0)",
>> "segmentsFile":"segments_2z",
>> "segmentsFileSizeInBytes":1947,
>> "userData":{
>>   "commitCommandVer":"0",
>>   "commitTimeMSec":"1640647856055"},
>> "lastModified":"2021-12-27T23:30:56.055Z",
>> "sizeInBytes":1641346285,
>> "size":"1.53 GB"}},
>> "statistics":{
>>   "name":"statistics",
>>   "instanceDir":"/var/solr/data/statistics",
>>   "dataDir":"/var/solr/data/statistics/data/",
>>   "config":"solrconfig.xml",
>>   "schema":"schema.xml",
>>   "startTime":"2021-12-28T10:55:07.565Z",
>>   "uptime":11864565,
>>   "index":{
>> "numDocs":78,
>> "maxDoc":78,
>> "deletedDocs":0,
>> "indexHeapUsageBytes":38772,
>> "version":46,
>> "segmentCount":11,
>> "current":false,
>> "hasDeletions":false,
>> 
>> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/statistics/data/index
>>  
>> lockFactory=org.apache.lucene.store.NativeFSLockFactory@12cd8c11; 
>> maxCacheMB=48.0 maxMergeSizeMB=4.0)",
>>
>> On Tuesday, December 28, 2021 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Chris Clawson
I believe this has happened before... Problems begin with step 'f'. The 
following is the output from the bash command:

root@media:/build# bash ./install_solr_service.sh solr-8.11.1.tgz -f
Extracting solr-8.11.1.tgz to /opt
Installing symlink /opt/solr -> /opt/solr-8.11.1 ...
Installing /etc/init.d/solr script ...
Installing /etc/default/solr.in.sh ...
Service solr installed.
Customize Solr startup configuration in /etc/default/solr.in.sh
Job for solr.service failed because the control process exited with error 
code.
See "systemctl status solr.service" and "journalctl -xe" for details.
● solr.service - LSB: Controls Apache Solr as a Service
   Loaded: loaded (/etc/init.d/solr; generated)
   Active: failed (Result: exit-code) since Tue 2021-12-28 11:00:48 CST; 5s 
ago
 Docs: man:systemd-sysv-generator(8)
  Process: 1474 ExecStart=/etc/init.d/solr start (code=exited, 
status=1/FAILURE)

Dec 28 11:00:48 media systemd[1]: Starting LSB: Controls Apache Solr as a 
Service...
Dec 28 11:00:48 media su[1476]: Successful su for tomcat by root
Dec 28 11:00:48 media su[1476]: + ??? root:tomcat
Dec 28 11:00:48 media su[1476]: pam_unix(su:session): session opened for 
user tomcat by (uid=0)
Dec 28 11:00:48 media su[1476]: pam_unix(su:session): session closed for 
user tomcat
Dec 28 11:00:48 media systemd[1]: solr.service: Control process exited, 
code=exited status=1
Dec 28 11:00:48 media systemd[1]: solr.service: Failed with result 
'exit-code'.
Dec 28 11:00:48 media systemd[1]: Failed to start LSB: Controls Apache Solr 
as a Service.
root@media:/build#

On Tuesday, December 28, 2021 at 9:21:25 AM UTC-5 Mohammad S. AlMutairi 
wrote:

> Hello Chris,
>
> Your solr installation is broken so you really really really must remove 
> the old installation and begin a fresh install. All the provided 
> instructions is very simple and easy to follow so just follow it. Regarding 
> step (e) it just another and easier way of changing SOLR_USER=solr to 
> SOLR_USER=tomcat using perl substitution. Don't stop at it or the (g) step 
> just remove the old solr and install solr following the installation steps 
> above but you MUST BE ROOT during the removal or the installing of Solr to 
> overcome any permission issues you might confront.
>
>  Here is what you suppose to see if Solr and dspace cores are done 
> correctly. This is part of it.#
> "search":{
>   "name":"search",
>   "instanceDir":"/var/solr/data/search",
>   "dataDir":"/var/solr/data/search/data/",
>   "config":"solrconfig.xml",
>   "schema":"schema.xml",
>   "startTime":"2021-12-28T10:55:06.841Z",
>   "uptime":11865277,
>   "index":{
> "numDocs":45760,
> "maxDoc":45760,
> "deletedDocs":0,
> "indexHeapUsageBytes":489928,
> "version":678,
> "segmentCount":22,
> "current":true,
> "hasDeletions":false,
> 
> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/search/data/index
>  
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@12cd8c11; 
> maxCacheMB=48.0 maxMergeSizeMB=4.0)",
> "segmentsFile":"segments_2z",
> "segmentsFileSizeInBytes":1947,
> "userData":{
>   "commitCommandVer":"0",
>   "commitTimeMSec":"1640647856055"},
> "lastModified":"2021-12-27T23:30:56.055Z",
> "sizeInBytes":1641346285,
> "size":"1.53 GB"}},
> "statistics":{
>   "name":"statistics",
>   "instanceDir":"/var/solr/data/statistics",
>   "dataDir":"/var/solr/data/statistics/data/",
>   "config":"solrconfig.xml",
>   "schema":"schema.xml",
>   "startTime":"2021-12-28T10:55:07.565Z",
>   "uptime":11864565,
>   "index":{
> "numDocs":78,
> "maxDoc":78,
> "deletedDocs":0,
> "indexHeapUsageBytes":38772,
> "version":46,
> "segmentCount":11,
> "current":false,
> "hasDeletions":false,
> 
> "directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/statistics/data/index
>  
> lockFactory=org.apache.lucene.store.NativeFSLockFactory@12cd8c11; 
> maxCacheMB=48.0 maxMergeSizeMB=4.0)",
>
> On Tuesday, December 28, 2021 at 4:56:15 PM UTC+3 Chris Clawson wrote:
>
>> Thanks for revisiting this! There is detail here which I have never seen, 
>> especially step e) . I will probably attempt a removal/re-installation of 
>> Solr in a few hours. Here is the results of my status checks, using curl:
>> root@media:~# curl http://localhost:8983/solr/admin/cores
>> {
>>   "responseHeader":{
>> "status":0,
>> "QTime":70},
>>   "initFailures":{},
>>   "status":{}}
>> root@media:~# curl http://localhost:8983/solr/admin/cores?action=STATUS
>> {
>>   "responseHeader":{
>> "status":0,
>> "QTime":1},
>>   "initFailures":{},
>>   "status":{}}
>> root@media:~#
>>
>> ... I don't see any DSpace names mentioned in these returns, so 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Mohammad S. AlMutairi
Hello Chris,

Your solr installation is broken so you really really really must remove 
the old installation and begin a fresh install. All the provided 
instructions is very simple and easy to follow so just follow it. Regarding 
step (e) it just another and easier way of changing SOLR_USER=solr to 
SOLR_USER=tomcat using perl substitution. Don't stop at it or the (g) step 
just remove the old solr and install solr following the installation steps 
above but you MUST BE ROOT during the removal or the installing of Solr to 
overcome any permission issues you might confront.

 Here is what you suppose to see if Solr and dspace cores are done 
correctly. This is part of it.#
"search":{
  "name":"search",
  "instanceDir":"/var/solr/data/search",
  "dataDir":"/var/solr/data/search/data/",
  "config":"solrconfig.xml",
  "schema":"schema.xml",
  "startTime":"2021-12-28T10:55:06.841Z",
  "uptime":11865277,
  "index":{
"numDocs":45760,
"maxDoc":45760,
"deletedDocs":0,
"indexHeapUsageBytes":489928,
"version":678,
"segmentCount":22,
"current":true,
"hasDeletions":false,

"directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/search/data/index
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@12cd8c11; 
maxCacheMB=48.0 maxMergeSizeMB=4.0)",
"segmentsFile":"segments_2z",
"segmentsFileSizeInBytes":1947,
"userData":{
  "commitCommandVer":"0",
  "commitTimeMSec":"1640647856055"},
"lastModified":"2021-12-27T23:30:56.055Z",
"sizeInBytes":1641346285,
"size":"1.53 GB"}},
"statistics":{
  "name":"statistics",
  "instanceDir":"/var/solr/data/statistics",
  "dataDir":"/var/solr/data/statistics/data/",
  "config":"solrconfig.xml",
  "schema":"schema.xml",
  "startTime":"2021-12-28T10:55:07.565Z",
  "uptime":11864565,
  "index":{
"numDocs":78,
"maxDoc":78,
"deletedDocs":0,
"indexHeapUsageBytes":38772,
"version":46,
"segmentCount":11,
"current":false,
"hasDeletions":false,

"directory":"org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/solr/data/statistics/data/index
 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@12cd8c11; 
maxCacheMB=48.0 maxMergeSizeMB=4.0)",

On Tuesday, December 28, 2021 at 4:56:15 PM UTC+3 Chris Clawson wrote:

> Thanks for revisiting this! There is detail here which I have never seen, 
> especially step e) . I will probably attempt a removal/re-installation of 
> Solr in a few hours. Here is the results of my status checks, using curl:
> root@media:~# curl http://localhost:8983/solr/admin/cores
> {
>   "responseHeader":{
> "status":0,
> "QTime":70},
>   "initFailures":{},
>   "status":{}}
> root@media:~# curl http://localhost:8983/solr/admin/cores?action=STATUS
> {
>   "responseHeader":{
> "status":0,
> "QTime":1},
>   "initFailures":{},
>   "status":{}}
> root@media:~#
>
> ... I don't see any DSpace names mentioned in these returns, so I am 
> guessing there is an issue here.
>
> On Tuesday, December 28, 2021 at 7:41:15 AM UTC-5 Mohammad S. AlMutairi 
> wrote:
>
>> A lot of newcomers who want to try DSpace specially non-technical people 
>> do face an issue installing Solr for DSpace. The DSpace Solr installation 
>> portion doesn't cover specific details about any Linux OS so to make things 
>> easier for the folks who are using Ubuntu I'm posting a detailed 
>> instructions how Solr should be installed on Ubuntu in a hope someone who 
>> deserve helping save his time and get Solr up and running in no time. See 
>> Solr installation steps and also the removal of solr if you ever need to 
>> remove it below. Hope it doesn't fire back as it did not long time ago!.
>>
>> # Solr Installation 
>> #
>> # set a password for the root user.
>> sudo passwd root
>>
>> # login with root to start solr installation.
>> su - root
>>
>> a) mkdir /build
>> b) cd /build
>> c) wget https://downloads.apache.org/lucene/solr/8.11.1/solr-8.11.1.tgz
>> d) tar xzf solr-8.11.1.tgz solr-8.11.1/bin/install_solr_service.sh 
>> --strip-components=2
>> e) perl -i -pe 's/SOLR_USER=solr/SOLR_USER=tomcat/;' 
>> /build/install_solr_service.sh
>> f) bash ./install_solr_service.sh solr-8.11.1.tgz -f
>> g) echo SOLR_OPTS=\"\$SOLR_OPTS 
>> -Dsolr.allowPaths=/opt/dspace/solr/statistics,/opt/dspace/temp/solr-data\" 
>> >> /etc/default/solr.in.sh
>> h) cp -r /opt/dspace/solr/* /var/solr/data/ # Do this step after 
>> installing dspace backend (REST API server). You need to change /opt/dspace 
>> to the folder you installed dspace backend into.
>> i) chown -R tomcat:tomcat /opt/sol*
>> j) chown -R tomcat:tomcat /var/solr/data/
>> k) systemctl enable solr
>> l) systemctl restart 

[dspace-tech] Re: A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Chris Clawson
Thanks for revisiting this! There is detail here which I have never seen, 
especially step e) . I will probably attempt a removal/re-installation of 
Solr in a few hours. Here is the results of my status checks, using curl:
root@media:~# curl http://localhost:8983/solr/admin/cores
{
  "responseHeader":{
"status":0,
"QTime":70},
  "initFailures":{},
  "status":{}}
root@media:~# curl http://localhost:8983/solr/admin/cores?action=STATUS
{
  "responseHeader":{
"status":0,
"QTime":1},
  "initFailures":{},
  "status":{}}
root@media:~#

... I don't see any DSpace names mentioned in these returns, so I am 
guessing there is an issue here.

On Tuesday, December 28, 2021 at 7:41:15 AM UTC-5 Mohammad S. AlMutairi 
wrote:

> A lot of newcomers who want to try DSpace specially non-technical people 
> do face an issue installing Solr for DSpace. The DSpace Solr installation 
> portion doesn't cover specific details about any Linux OS so to make things 
> easier for the folks who are using Ubuntu I'm posting a detailed 
> instructions how Solr should be installed on Ubuntu in a hope someone who 
> deserve helping save his time and get Solr up and running in no time. See 
> Solr installation steps and also the removal of solr if you ever need to 
> remove it below. Hope it doesn't fire back as it did not long time ago!.
>
> # Solr Installation 
> #
> # set a password for the root user.
> sudo passwd root
>
> # login with root to start solr installation.
> su - root
>
> a) mkdir /build
> b) cd /build
> c) wget https://downloads.apache.org/lucene/solr/8.11.1/solr-8.11.1.tgz
> d) tar xzf solr-8.11.1.tgz solr-8.11.1/bin/install_solr_service.sh 
> --strip-components=2
> e) perl -i -pe 's/SOLR_USER=solr/SOLR_USER=tomcat/;' 
> /build/install_solr_service.sh
> f) bash ./install_solr_service.sh solr-8.11.1.tgz -f
> g) echo SOLR_OPTS=\"\$SOLR_OPTS 
> -Dsolr.allowPaths=/opt/dspace/solr/statistics,/opt/dspace/temp/solr-data\" 
> >> /etc/default/solr.in.sh
> h) cp -r /opt/dspace/solr/* /var/solr/data/ # Do this step after 
> installing dspace backend (REST API server). You need to change /opt/dspace 
> to the folder you installed dspace backend into.
> i) chown -R tomcat:tomcat /opt/sol*
> j) chown -R tomcat:tomcat /var/solr/data/
> k) systemctl enable solr
> l) systemctl restart solr
>
> # Run curl as you see it below to test Solr and check the status of dspace 
> cores you copied in step (h) above. Dspace cores names you should see and 
> see it's data are (authority, oai, search and statistics).
> curl http://localhost:8983/solr/admin/cores
> curl http://localhost:8983/solr/admin/cores?action=STATUS
>
> # End of Solr Installation 
> ##
>
> # Steps to manually uninstall Solr from Ubuntu 
> ##
> # You need to login with root.
> # login with root to remove old solr installation from your server.
> su - root
>
> 1) systemctl stop solr
> 2) rm -r /var/solr
> 3) rm -r /opt/sol*
> 4) rm /etc/init.d/solr
> 5) deluser --remove-home solr
> 6) deluser --group solr
> 7) update-rc.d -f solr remove
> 8) rm -rf /etc/default/solr.in.sh
> # End of Solr Removal instructions 
> ##
>
>
> "When the sage points at the moon, the fool looks at the finger"
>
>

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/4cd45117-bd78-4805-bb65-dd42740fdbaen%40googlegroups.com.


[dspace-tech] A How-To Solr installation on Ubuntu servers

2021-12-28 Thread Mohammad S. AlMutairi
A lot of newcomers who want to try DSpace specially non-technical people do 
face an issue installing Solr for DSpace. The DSpace Solr installation 
portion doesn't cover specific details about any Linux OS so to make things 
easier for the folks who are using Ubuntu I'm posting a detailed 
instructions how Solr should be installed on Ubuntu in a hope someone who 
deserve helping save his time and get Solr up and running in no time. See 
Solr installation steps and also the removal of solr if you ever need to 
remove it below. Hope it doesn't fire back as it did not long time ago!.

# Solr Installation 
#
# set a password for the root user.
sudo passwd root

# login with root to start solr installation.
su - root

a) mkdir /build
b) cd /build
c) wget https://downloads.apache.org/lucene/solr/8.11.1/solr-8.11.1.tgz
d) tar xzf solr-8.11.1.tgz solr-8.11.1/bin/install_solr_service.sh 
--strip-components=2
e) perl -i -pe 's/SOLR_USER=solr/SOLR_USER=tomcat/;' 
/build/install_solr_service.sh
f) bash ./install_solr_service.sh solr-8.11.1.tgz -f
g) echo SOLR_OPTS=\"\$SOLR_OPTS 
-Dsolr.allowPaths=/opt/dspace/solr/statistics,/opt/dspace/temp/solr-data\" 
>> /etc/default/solr.in.sh
h) cp -r /opt/dspace/solr/* /var/solr/data/ # Do this step after installing 
dspace backend (REST API server). You need to change /opt/dspace to the 
folder you installed dspace backend into.
i) chown -R tomcat:tomcat /opt/sol*
j) chown -R tomcat:tomcat /var/solr/data/
k) systemctl enable solr
l) systemctl restart solr

# Run curl as you see it below to test Solr and check the status of dspace 
cores you copied in step (h) above. Dspace cores names you should see and 
see it's data are (authority, oai, search and statistics).
curl http://localhost:8983/solr/admin/cores
curl http://localhost:8983/solr/admin/cores?action=STATUS

# End of Solr Installation 
##

# Steps to manually uninstall Solr from Ubuntu 
##
# You need to login with root.
# login with root to remove old solr installation from your server.
su - root

1) systemctl stop solr
2) rm -r /var/solr
3) rm -r /opt/sol*
4) rm /etc/init.d/solr
5) deluser --remove-home solr
6) deluser --group solr
7) update-rc.d -f solr remove
8) rm -rf /etc/default/solr.in.sh
# End of Solr Removal instructions 
##


"When the sage points at the moon, the fool looks at the finger"

-- 
All messages to this mailing list should adhere to the Code of Conduct: 
https://www.lyrasis.org/about/Pages/Code-of-Conduct.aspx
--- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/dspace-tech/842330a9-5fc1-4949-be7c-b52d2c5120e2n%40googlegroups.com.