I am using cassandra 2.0.5 on Centos 6.5 and OpsCenter 4 worked fine until i updated OpsCenter to version 4.1 . I access OpsCenter page, click on manage existing cluster and give the ip address of my node (127.0.0.1) and it gives me the following: "Error creating cluster: max() arg is an empty sequence".
Any clues ?
The bug is on 4.1.0, and is affecting those running Python 2.6. The complete fix for this is 4.1.1 (http://www.datastax.com/dev/blog/opscenter-4-1-1-now-available). To workaround this issue on 4.1.0, users should disable the auto-update feature, and manually re-populate the latest definitions. This will only need to be done once. This doesn't need to be done with 4.1.1, and that's the best fix. See the Known issues of the release notes (http://www.datastax.com/documentation/opscenter/4.1/opsc/release_notes/opscReleaseNotes410.html)
Add the following to opscenterd.conf to disable auto-update:
[definitions]
auto_update = False
Manually download the definition files
for tarball installs:
cd ./conf/definitions
for packages installs:
cd /etc/opscenter/definitions
Apply the latest definitions
curl https://opscenter.datastax.com/definitions/4.1.0/definition_files.tgz | tar xz
Restart opscenterd
I jus had today the same problem that you. I downloaded an older versions of opscenter (particulary version 4.0.2) from http://rpm.datastax.com/community/noarch/ and the error has gone.
I am also using the sam cassandra version and also on centos
Related
I have the following setup
Databricks Cluster:
8.4 ML (includes Apache Spark 3.1.2, Scala 2.12)
Client side:
databricks==0.2
databricks-cli==0.14.3
databricks-connect==8.1.10 (The latest version up to date 20210813)
When I run databricks-connect test to test the connection, I got this error message
java.lang.IllegalArgumentException:
The cluster is running server version `dbr-8.4` but this client only supports Set(dbr-8.1).
You can find a list of client releases at https://pypi.org/project/databricks-connect/#history, and install the right client version with `pip install -U databricks-connect==<version>`.
For example, to install the latest 5.1 release, use `pip install -U databricks-connect==5.1.*`.
To ignore this error and continue, set DEBUG_IGNORE_VERSION_MISMATCH=1.
According to the error message, I understand there is a compatibility issue with the client and server versions. However, I am already using the latest client.
Does it mean the client doesn't add support for server version 8.4?
Is there any way to circumvent this issue?
Unfortunately, it's the latest version of databricks-connect for DBR 8.x., and versions for 8.2-8.4 aren't released. But it may work if you add DEBUG_IGNORE_VERSION_MISMATCH=1 before the databricks-connect test or other commands like, pyspark, spark-submit, etc.
I was following the installation manual for presto.
But when I lanched the presto server from the command line I got this error:
$ bin/launcher run
Unrecognized VM option 'ExitOnOutOfMemoryError'
Did you mean 'OnOutOfMemoryError=<value>'?
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
Per #kavehmb's answer on another question, as of June 2019 the way to work around this issue is:
brew tap adoptopenjdk/openjdk
brew cask install adoptopenjdk8
I suspected the java version was wrong and checked it. I had Java 1.8.0_65-b17.
The documentation for the installation did not mention anything about needed java version. It was hard to find out the needed Java version for the newest Presto version (v0.208)
I updated to the currently newest Java8 version using brew (on Mac).
brew cask install java8
After successful upgrading of Java I had version 1.8.0_181-b13.
Then prestodb could start.
I am trying to install logstash on SLES . Here are the version details
SUSE Linux Enterprise Server 12 (x86_64)
VERSION = 12
PATCHLEVEL = 2
# This file is deprecated and will be removed in a future service pack or release.
# Please check /etc/os-release for details about this release.
NAME="SLES"
VERSION="12-SP2"
VERSION_ID="12.2"
PRETTY_NAME="SUSE Linux Enterprise Server 12 SP2"
ID="sles"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:suse:sles:12:sp2"
Most of the instructions available over google are for ElasticSearch but not for logstash. I tried rpm based installation as described here https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html but here too they install elasticsearch using zypper install elasticsearch I am trying to install logstash 6.1 or later. what is the best way to install logstash on SLES? While installaing elasticsearch too I get an error as follows:
elasticsearch-6.1.3-1.noarch (Elasticsearch repository for 6.x packages): Signature verification failed [4-Signatures public key is not available]
Here is my elasticsearch.repo
[elasticsearch-6.x]
name=Elasticsearch repository for 6.x packages
baseurl=https://artifacts.elastic.co/packages/6.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
It's probably too late, but it's better late than never. Anyway, I had the same issue and this article gave me an idea for a solution: https://en.opensuse.org/User:Tsu2/elasticsearch_logstash_official_repos. This part specifically solved my issue:
Download TAR file and extract. Because Elasticsearch is a Java binary, the extracted files can be run from anywhere
So, what I did is I've downloaded the Logstash TAR file, SCPed it to my SUSE server, and extracted it to my ELK folder. Then I ran it using its bin/logstash executable.
I hope this solution helps you and others who stumble on this page on their search for the solution.
At present we are on Apache/2.2.15 (UNIX) version. To fix the vulnerabilities we are suggested to upgrade to new version. I got new version from online using "wget" command and followed steps mentioned on this link http://httpd.apache.org/docs/2.2/install.html#download.
Once I am done, checked version using httpd -v. It gives me old version Apache/2.2.15 (UNIX). If I check using /usr/local/apache2/bin/httpd - v. It gives me new version. Did I successfully upgraded the version or not? If not what should I do?
I tried "yum install httpd" - It says "Nothing to do".
You now have two versions of Apache installed. You have the one installed with the system package manager (yum) in /usr/sbin/httpd. You have one installed manually in /usr/local/apache2/....
Which one you get will be determined entirely by which path you use.
In general, mixing system-managed packages with manually installed packages is a recipe for trouble. If you want to stick with the newer version in /usr/local, you should remove the system version, and realize that you will lose some manageability. For example, you will no longer be able to use yum install ... to install new Apache modules, and you will not be able to verify the installed files using tools like rpmverify.
If your distribution currently has Apache 2.2.x, that suggests your distribution is fairly old. For example, RHEL (and CentOS) 7 (and similar variants) have version 2.4.6 packaged, so you may want to update your host to something newer than whatever you're running now.
Yes, its successfully upgraded as per the screenshot.
httpd 2.2.15 is the version with RHEL 6 repository, here HTTPD_HOME is /etc/httpd (Highest version provided for HTTPD via RPM RHEL 6 is 2.2.15)
httpd 2.4.6 is the version with EPEL-HTTPD24 repository, here HTTPD_HOME is /usr/local/apache2/
I recently updated Postgres from version 9.3 to 9.6. After the update all of my commands (such as pg_dumpall) all point to version 9.3. I get the error of version mismatch.
I found that if I change my symlink in /usr/bin to point to 9.6 it seems to work. Is there a better way to point my commands to version 9.6? Thanks you for your help!
The best way to do it is using the package manager of your linux distro: it ensures all symlinks are changed to the newer version.
From your question it is possible to infer that the upgrade was done without using the package manager. I suggest to try to install Postgres with the package manager or give a little more information about your system so we can give you a more accurate answer.