[
https://issues.apache.org/jira/browse/SOLR-9475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man reopened SOLR-9475:
----------------------------
NOTE: master commit was
http://git-wip-us.apache.org/repos/asf/lucene-solr/commit/a1bbc996
----
Slurping in all of the files like this seems like a very bad idea and should be
rolled back...
{code}
+proc_version=`cat /etc/*-release 2>/dev/null`
{code}
...if for no other reason then how {{proc_version}} is used in the event of an
OS we don't recognize...
{code}
echo -e "\nERROR: Your Linux distribution ($proc_version) not supported by
this script!\nYou'll need to setup
Solr as a service manually using the documentation provided in the Solr
Reference Guide.\n" 1>&2
{code}
----
In general i would suggest that the correct behavior is to test, in order...
* {{lsb_release -i}}
** required by the "Linux Standard Base Core" spec (which AFAIK almost every
linux distro supports even if they don't get fully certified)
* {{uname -a}}
** required by POSIX, and contains the distro name in most cases
* {{/proc/version}}
** should be on every machine running a linux kernel, but is only required to
include the kernel version, not the distro info
* {{cat /etc/*release}}
The key element being that we should not just look to see if these *exist* in
that order, but actually be testing these against our list of pattern strings
("Debian", "Red Hat", etc...) in sequence before moving on the the next on the
list.
For example: our current logic is (psuedo code)...
{code}
try {
proc_version = `x`
} catch Error {
try {
proc_version = `y`
} catch Error {
try {
proc_version = `z`
}
}
}
for (d : known_distros) {
if (proc_version contains d) {
return d
}
}
{code}
Instead we should be doing...
{code}
for (cmd : { x, y, z }) {
try {
possibility = `cmd`
for (d : known_distros) {
if (possibility contains d) {
return d
}
}
}
{code}
...that way we can test more reliable options (like `uname -a`) earlier in the
list, but we can still proceed even if those commands exist & run but don't
return the name of the distribution on some platforms. (ala CentOS apparently)
(ie: we should not try the sketchy/risky stuff first, just because it's more
likely we'll get a match. we should test the stuff that's more well defined
and well structured first, even if we know there are many systems where the
command might exist but may not give us useful info)
> Add install script support for CentOS
> -------------------------------------
>
> Key: SOLR-9475
> URL: https://issues.apache.org/jira/browse/SOLR-9475
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Affects Versions: 6.2
> Environment: Centos 7
> Reporter: Nitin Surana
> Assignee: Jan Høydahl
> Fix For: 6.3, master (7.0)
>
> Attachments: SOLR-9475.patch, install_solr_service.sh
>
>
> [root@ns521582 tmp]# sudo ./install_solr_service.sh solr-6.2.0.tgz
> id: solr: no such user
> Creating new user: solr
> adduser: group '--disabled-password' does not exist
> Extracting solr-6.2.0.tgz to /opt
> Installing symlink /opt/solr -> /opt/solr-6.2.0 ...
> Installing /etc/init.d/solr script ...
> /etc/default/solr.in.sh already exist. Skipping install ...
> /var/solr/data/solr.xml already exists. Skipping install ...
> /var/solr/log4j.properties already exists. Skipping install ...
> chown: invalid spec: ‘solr:’
> ./install_solr_service.sh: line 322: update-rc.d: command not found
> id: solr: no such user
> User solr not found! Please create the solr user before running this script.
> id: solr: no such user
> User solr not found! Please create the solr user before running this script.
> Service solr installed.
> Reference -
> http://stackoverflow.com/questions/39320647/unable-to-create-user-when-installing-solr-6-2-0-on-centos-7
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
