Unable to start Cassandra Daemon 1.2.4 with Java 8 - java

Hi I am using Cassandra 1.2.4 with Java 8(moving on from 7) as a service .I can run cassandra as a standalone process without any hassle, however when I use it with an Apache Virgo application(3.7.0.D-20150114193621) it fails.
Following is the output in the status.out log file and nothing in the system.log.
+ case "$1" in
+ echo 'Checking status of Cassandra daemon......'
Checking status of Cassandra daemon......
+ is_running
++ get_cass_pid
+++ ps -fC java
+++ grep -w org.apache.cassandra.service.CassandraDaemon
+++ head -n 1
+++ awk '{print $2}'
++ echo
+ pid=
+ '[' x = x ']'
+ return 1
+ stat=1
+ case "$stat" in
+ echo 'Cassandra is not running'
Cassandra is not running
+ exit 1
I only get the below stacktrace in the virgo logs:
ERROR TaskExec-1-thread-8 DE0005I Failed to start cassandra service
Since, it can run fine as a standalone process, there is no issue with setting the $CASSANDRA_HOME,$CLASSPATH or other variables.
I have verified the API call from the application and looks like its not able to start the daemon. Also,any information relating to the cassandra logging will be helpful to debug.

Related

Java version check using ansible is getting skipped for no apparent reason

As part of my ansible setup I'm currently checking in the VM what is the Java version and if that's not the one expected then download and install that version. I have given the standard regex to find the Java version but that step is getting skipped
- name: "[install] Check for Java install"
shell: "java -version 2>&1 | grep version | awk '{print $3}'"
changed_when: False
register: java_installed
ignore_errors: True
- when: java_installed.stdout != "17.0.2"
block:
- debug:
msg: "Java is not installed"
- name: "[install] Installing Java 17"
become: true
yum:
name: /var/tmp/jdk-17_linux-x64_bin.rpm
state: present
But these steps are getting skipped while executing
TASK [java : [install] Check for Java install] *****************************************************************************************************************************
skipping: [VM name hidden by me ]
TASK [java : debug] ********************************************************************************************************************************************************
skipping: [VM name hidden by me]
TASK [java : [install] Installing Java 17] *********************************************************************************************************************************
skipping: [VM name hidden by me]
when I execute
java -version 2>&1 | grep version | awk '{print $3}'
This is what I get
"1.8.0_312"
Does anyone know why it's getting skipped. Thanks
Note: below is an answer to your direct problem. Meanwhile if java was installed as a system package, I strongly suggest you have a look at the answer by #Jaay to get the version directly from package facts rather than using shell/command
This is what I get
"1.8.0_312"
As you can see, the quotes are part of the output. Hence if you debug java_installed.stdout you get (ran on my local machine with java 11):
TASK [debug] ********************************************************************************************************************
ok: [localhost] => {
"java_installed.stdout": "\"11.0.15\""
}
A simple workaround is to read the incoming value as json. The following does the job (once again customized for my local machine to test and using the version test as good practice)
---
- hosts: localhost
gather_facts: false
tasks:
- name: "[install] Check for Java install"
shell: "java -version 2>&1 | grep version | awk '{print $3}'"
changed_when: false
failed_when: false
register: java_installed
- name: show the raw and refactored captured var
vars:
my_msg:
- "Raw value for version is: {{ java_installed.stdout }}"
- "Refactored value for version is: {{ java_installed.stdout | from_json }}"
debug:
msg: "{{ my_msg }}"
- when: java_installed.stdout | from_json is version("11.0.15", "==")
debug:
msg: "Java 11 is installed"
- when: java_installed.stdout | from_json is not version("17.0.2", "==")
debug:
msg: "Java 17 is not installed"
and gives
PLAY [localhost] ****************************************************************************************************************
TASK [[install] Check for Java install] *****************************************************************************************
ok: [localhost]
TASK [show the raw and refactored captured var] *********************************************************************************
ok: [localhost] => {
"msg": [
"Raw value for version is: \"11.0.15\"",
"Refactored value for version is: 11.0.15"
]
}
TASK [debug] ********************************************************************************************************************
ok: [localhost] => {
"msg": "Java 11 is installed"
}
TASK [debug] ********************************************************************************************************************
ok: [localhost] => {
"msg": "Java 17 is not installed"
}
PLAY RECAP **********************************************************************************************************************
localhost : ok=4 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0
Not really a big fan of shell command in Ansible, you can use the package facts core plugin to retrieve the installed Java version. This way you should get rid of the outputs problem using shell command
- name: get the rpm or apt package facts
package_facts:
manager: "auto"
- name: show Java version
debug: var=ansible_facts.packages.jdk[0].version
PS: This will work only if java is installed with a package manager (not just copied in your system)

unable to execute oracle data setup script from docker compose

I am trying to set up oracle data once my oracle container is up and running, below is my compose file:
version: '3'
services:
oracle:
image: absolutapps/oracle-12c-ee
container_name: oracle-docker
ports:
- 8080:8080
- 1521:1521
environment:
CASSANDRA_BROADCAST_ADDRESS: 127.0.0.1
ORACLE_ALLOW_REMOTE: "true"
volumes:
- ./scripts/oracle-init.sh:/oracle-init.sh
oracle-init.sh:
#!/usr/bin/env bash
echo "### SETUP EXECUTION! ###"
sqlplus -s "system/oracle#localhost:1521/orcl /scripts/init-oracle.sql"
echo "### SETUP EXECUTED! ###"
init-oracle.sql :
CREATE USER ot_consumer_tryout IDENTIFIED BY ot_consumer_tryout;
Can anyone help me what is wrong with above snippets. My docker container getting started but sql script does not execute ,here is the log from terminal:
oracle-docker | Running init scripts...
oracle-docker | Init scripts in /oracle.init.d/: Ignoring /oracle.init.d/*
oracle-docker |
oracle-docker | Done with scripts we are ready to go
Look at the volume you created
- ./scripts/oracle-init.sh:/oracle-init.sh
which means inside your container the file is in '/oracle-init.sh' but your
container might be expecting in a different location something with folder name oracle.init.d as per your container log.
oracle-init.sh is trying to run /scripts/init-oracle.sql , hope your image already has it otherwise you will have to mount it as well in compose file.

Log4j vulnerability - Is Log4j 1.2.17 vulnerable (was unable to find any JNDI code in source)?

With regard to the Log4j JNDI remote code execution vulnerability that has been identified CVE-2021-44228 - (also see references) - I wondered if Log4j-v1.2 is also impacted, but the closest I got from source code review is the JMS-Appender.
The question is, while the posts on the Internet indicate that Log4j 1.2 is also vulnerable, I am not able to find the relevant source code for it.
Am I missing something that others have identified?
Log4j 1.2 appears to have a vulnerability in the socket-server class, but my understanding is that it needs to be enabled in the first place for it to be applicable and hence is not a passive threat unlike the JNDI-lookup vulnerability which the one identified appears to be.
Is my understanding - that Log4j v1.2 - is not vulnerable to the jndi-remote-code execution bug correct?
References
Apache Log4j Security Vulnerabilities
Zero-day in ubiquitous Log4j tool poses a grave threat to the Internet
Worst Apache Log4j RCE Zero day Dropped on Internet
‘Log4Shell’ vulnerability poses critical threat to applications using ‘ubiquitous’ Java logging package Apache Log4j
This blog post from Cloudflare also indicates the same point as from AKX....that it was introduced from Log4j 2!
Update #1 - A fork of the (now-retired) apache-log4j-1.2.x with patch fixes for few vulnerabilities identified in the older library is now available (from the original log4j author). The site is https://reload4j.qos.ch/. As of 21-Jan-2022 version 1.2.18.2 has been released. Vulnerabilities addressed to date include those pertaining to JMSAppender, SocketServer and Chainsaw vulnerabilities. Note that I am simply relaying this information. Have not verified the fixes from my end. Please refer the link for additional details.
The JNDI feature was added into Log4j 2.0-beta9.
Log4j 1.x thus does not have the vulnerable code.
While not affected by the exact same Log4Shell issue, the Apache Log4j team recommends to remove JMSAppender and SocketServer, which has a vulnerability in CVE-2019-17571, from your JAR files.
You can use the zip command to remove the affected classes. Replace the filename/version with yours:
zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class
zip -d log4j-1.2.16.jar org/apache/log4j/net/SocketServer.class
You can look through through the files in your zip using less and grep, e.g. less log4j-1.2.16.jar | grep JMSAppender
That being said, Apache recommends that you upgrade to the 2.x version if possible. According to their security page:
Please note that Log4j 1.x has reached end of life and is no longer supported. Vulnerabilities reported after August 2015 against Log4j 1.x were not checked and will not be fixed. Users should upgrade to Log4j 2 to obtain security fixes.
In addition to giraffesyo's answer and in case it helps anyone - I wrote this Bash script - which removes classes identified as vulnerabilities (link here to Log4j dev thread) and sets properties files are read-only - as suggested here on a Red Hat Bugzilla thread.
Note 1 - it does not check for any usage of these classes in properties it is purely a way to find and remove - use at own risk!
Note 2 - it depends on zip and unzip being installed
#!/bin/bash
DIR=$1
APPLY=$2
# Classes to be searched for/removed
CLASSES="org/apache/log4j/net/SimpleSocketServer.class
org/apache/log4j/net/SocketServer.class
org/apache/log4j/net/JMSAppender.class"
PROGNAME=`basename $0`
PROGPATH=`echo $0 | sed -e 's,[\\/][^\\/][^\\/]*$,,'`
usage () {
echo >&2 Usage: ${PROGNAME} DIR [APPLY]
echo >&2 Where DIR is the starting directory for find
echo >&2 and APPLY = "Y" - to perform purification
exit 1
}
# Force upper case on Apply
APPLY=$(echo "${APPLY}" | tr '[:lower:]' '[:upper:]')
# Default Apply to N
if [ "$APPLY" == "" ] ; then
APPLY="N"
fi
# Check parameters
if [ "$DIR" == "" ] ; then
usage
fi
echo $APPLY | grep -q -i -e '^Y$' -e '^N$' || usage
# Search for log4j jar files - for class file removal
FILES=$(find $DIR -name *log4j*jar)
for f in $FILES
do
echo "Checking Jar [$f]"
for jf in $CLASSES
do
unzip -v $f | grep -e "$jf"
if [ "$APPLY" = "Y" ]
then
echo "Deleting $jf from $f"
zip -d $f $jf
fi
done
done
# Search for Log4j properties files - for read-only setting
PFILES=$(find $DIR -name *log4j*properties)
for f in $PFILES
do
echo "Checking permissions [$f]"
if [ "$APPLY" = "Y" ]
then
echo "Changing permissons on $f"
chmod 444 $f
fi
ls -l $f
done

VanillaSoftwareProcess Entity does not work in Apache Brooklyn

I have the last Apache Brooklyn (24.08.2015), Version: 0.8.0-SNAPSHOT, and when I am trying the example of the blueprint which is here: https://brooklyn.incubator.apache.org/v/latest/yaml/custom-entities.html
name: Simple Netcat Server Example
location: localhost
services:
- type: brooklyn.entity.basic.VanillaSoftwareProcess
name: Simple Netcat Server
launch.command: |
echo hello | nc -l 4321 &
echo $! > $PID_FILE
# The following overrides demonstrate the use of a custom shell environment as well as
# check-running and stop commands. These are optional; default behavior will "do the
# right thing" with the pid file automatically.
env: { CHECK_MARKER: "checkRunning", STOP_MARKER: "stop" }
checkRunning.command: echo $CHECK_MARKER >> DATE && test -f "$PID_FILE" && ps -p `cat $PID_FILE` >/dev/null
stop.command: echo $STOP_MARKER >> DATE && test -f "$PID_FILE" && { kill -9 `cat $PID_FILE`; rm /tmp/vanilla.pid; }
# can also define download.url, in which case the launch command defaults to ./start.sh in that (archive) file
When I tried to create the application with the Apache Brooklyn, I get an Internal error. I debugged the application, and the Exception I get is the following (PlanToSpecFactory.java):
java.lang.UnsupportedOperationException: Deployment plan item
org.apache.brooklyn.camp.spi.pdp.Service#62abec8e[name=Simple Netcat
Server,description=,serviceType=brooklyn.entity.basic.VanillaSoftwareProcess,characteristics=[],customAttributes={launch.command=echo
hello | nc -l 4321 & echo $! > $PID_FILE ,
env={CHECK_MARKER=checkRunning, STOP_MARKER=stop},
checkRunning.command=echo $CHECK_MARKER >> DATE && test -f "$PID_FILE"
&& ps -p cat $PID_FILE >/dev/null, stop.command=echo $STOP_MARKER
DATE && test -f "$PID_FILE" && { kill -9 cat $PID_FILE; rm /tmp/vanilla.pid; }}] cannot be matched
The trace in debug.log
DEBUG o.a.b.c.plan.PlanToSpecFactory
[brooklyn-jetty-server-8443-qtp1119923741-24]: Plan could not be
transformed; failure will be propagated (other transformers tried =
[]): [java.lang.IllegalArgumentException: Transformer for Brooklyn
OASIS CAMP interpreter gave an error creating this plan]
Any idea why? In the past this has worked
(I would like to post in the mailing list of Apache Brooklyn, but I get an error and I can not contact nobody)
The latest SNAPSHOT versions went through an heavy refactoring to change the package name to org.apache.brooklyn.*. That's probably why your version of Brooklyn cannot find the VanillaSoftwareProcess anymore.
Based on the Github repository, this entity is now located here: org.apache.brooklyn.entity.software.base.VanillaSoftwareProcess

Wait until tomcat finishes starting up

I have a script that needs to run after tomcat has finished starting up and is ready to start deploying applications. I'm using $TOMCAT_HOME/bin/startup.sh which returns immediately. How can I wait until tomcat has finished starting up?
There are probably several ways to do this. The trick we use is:
#!/bin/bash
until [ "`curl --silent --show-error --connect-timeout 1 -I http://localhost:8080 | grep 'Coyote'`" != "" ];
do
echo --- sleeping for 10 seconds
sleep 10
done
echo Tomcat is ready!
Hope this helps!
It's not hard to implement programaticaly. You can implement org.apache.catalina.LifecycleListener and then you'll have
public void lifecycleEvent(LifecycleEvent lifecycleEvent) {
if(lifecycleEvent.getType().equals(Lifecycle.START_EVENT))
//do what you want
}
}
in web.xml :
<Context path="/examples" ...>
...
<Listener className="com.mycompany.mypackage.MyListener" ... >
...
</Context>
Please notice that some things could differ between 6-9 Tomcats.
Are you still looking for an answer? It depends on your definition of started. If your definition of started is "Now its safe to stop" then you might want to verify if port 8005 is listening.
Depends on what you mean by finishing. What do you want to wait for?
You could, for example, have a script that hits a URL repeatedly until it gets a desirable result that would only be available once the app is properly initialized.
You could also have a context listener that writes out an "I'm ready" file that you use to signal the readiness of your application. (If you do this, be sure the file doesn't exist before starting your app container).
I needed this to test from jenkins if the tomcat from the remote server started for a system check.
until [[ `ssh -o StrictHostKeyChecking=no root#${DEPLOY_HOST} 'netstat -tulpn | grep 8005'` != "" ]] ; do echo "waiting for tomcat"; sleep 6; done
There isn't an easy method. As far as startup.sh and catalina.sh are concerned, tomcat is running when they finish. Although, internally, tomcat is still initializing and starting contexts.
It would help to know if you were trying to find out if your context finished loading or if you are just wanting a general, "Tomcat is runnnig although your contexts might not be completely loaded..."
If it is the latter you could create a web app that simply has a context listener that will execute a script using Runtime. If you were handy, you could make the webapp configuable via the web.xml file to accept a parameter that points to the script to execute.
Personally, I would just watch catalinas log for a specific string depending on how your setup and what exact phase your looking for.
I have done it with the following code in jenkins pipelinescript with tomcat.
Before i just call
sudo /bin/systemctl restart tomcat
And have an entry in my sudoers file for the jenkins user.
Now here is the oneliner:
until [ "$(curl -w '%{response_code}' --no-keepalive -o /dev/null --connect-timeout 1 -u USERNAME:PASSWORD http://localhost:8080/manager/text/list)" == "200" ]; do echo --- sleeping for 1 second; sleep 1; done
Better readable:
until [ "$(curl -w '%{response_code}' --no-keepalive -o /dev/null --connect-timeout 1 -u USERNAME:PASSWORD http://localhost:8080/manager/text/list)" == "200" ];
do echo --- sleeping for 1 second;
sleep 1;
done

Categories