Schlagwort: remote

Tomcat / Java Tools

prego Schreib einen Kommentar

Vor einiger Zeit habe ich schon mal ein paar Dinge ueber Tomcat und Java festgehalten. Den Blogeintrag von damals gibt es hier:

Heute nochmal der Hinweis auf ein paar nuetzliche Tools hinterher

jvmtop

Das Tool ist wie „top“ auf der Kommandozeile, nur fuer die JVM. Wenn man ihm zum Beispiel die PID eines Tomcat Prozesses uebergibt, dann sieht man welche Threads wie viel CPU verbrauchen etc. Beispiel:

./jvmtop.sh $(pidof java)

URL: https://code.google.com/p/jvmtop/wiki/Documentation

 

Java Thread Dump Analyser

Mit dem Tool kann man sich den Inhalt eines Thread Dumps ein bisschen besser ausgewertet anzeigen lassen. Beispiel:

jstack -l $(pidof java) > /tmp/threaddump.txt
java -jar jtda.jar /tmp/threaddump.txt

URL: http://mchr3k.github.io/javathreaddumpanalyser/

 

VisualVM

Der Klassiker. Ueber JMX mit der JVM verbinden und dann alle moeglichen Informationen live daraus ziehen. Dafuer notwendige Konfiguration:

-Djava.rmi.server.hostname=localhost 
-Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=9991 
-Dcom.sun.management.jmxremote.authenticate=false 
-Dcom.sun.management.jmxremote.ssl=false

URL: http://visualvm.java.net/

 

psi-probe

Der „bessere“ Tomcat Manager. Wer noch den Klassischen nutzt sollte sich diese Applikation unbedingt angucken. Einfach die war in den Tomcat legen und den Benutzernamen den man fuer den Tomcat Manager vergeben hat dafuer mit nutzen.

URL: https://code.google.com/p/psi-probe/

 

Eclipse Memory Analyzer (MAT)

Wer seine JVM so konfiguriert hat das bei einem OutOfMemory Fehler ein HeapDump geschrieben wird, der kann diesen mit MAT am besten oeffnen und hineinschauen. Dafuer notwendige Konfiguration:

-XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/tmp/dumps/

URL: https://www.eclipse.org/mat/

Remote Kommandos auf Server via xinetd ausfuehren / Adminfun

prego Schreib einen Kommentar

Es gibt Sachen die machen Spass, z.B. diese Spielerei. Es geht darum auf einem Server ein Remotekommando / Shellskript via Webbrowser auszufuehren, ohne das dafuer irgendeine grosse Software-Remotemanagement-Loesung laufen muss. Die Antwort ist der gute alte (x)inetd verbunden mit einem kleinen PHP-Skript. Ich kommentiere das jetzt hier nicht weiter sondern schreibe es einfach mal runter:

Als erstes muessen die Programme installiert werden:

 aptitude install xinetd php5-cli

Danach die folgende Datei unter /etc/xinetd.d/test ablegen

# description: xinetd + php = fun
service test
{
        socket_type     = stream        
        protocol	= tcp
	wait            = no
        user            = root
	server		= /usr/bin/php5
	server_args	= /root/test.php
	disable		= no
}

Anschliessend die /etc/services editieren und die folgende Zeile einfuegen:

test		44444/tcp			# test

und nun noch diese PHP-Datei unter /root/test.php ablegen:

<?php
echo "+++ xinetd + php = fun +++
 
";
 
## read parameter
$handle = fopen('php://stdin','r');
$input = fgets($handle);
fclose($handle);
 
## split get parameter 
$out1=str_replace("GET /", "", $input);
$out2=str_replace(" HTTP/1.1", "", $out1);
$parameter=explode("/", $out2);
 
## check if we shall do sth. and if we know it
if (trim($parameter[0]) == "doStuff") {
 
  if (empty($parameter[1])) {
    echo "no job start requested...
    ";
  }
 
  elseif (! trim(empty($parameter[1])) AND trim($parameter[1]) == "psaux") {
    $out = shell_exec('ps aux');
    echo "$out";
  }
 
}
else {
  echo "no job start requested...
";
}
?>

Ich denke die PHP-Datei erklaert sich von selber und kann beliebig erweitert werden. Ein Aufruf von http://example.net:44444/doStuff/psaux gibt dann die Ausgabe des Befehls „ps aux“ wieder. Nun sind bei dem shell_exec keine Grenzen gesetzt… ;-) Wichtig daran ist, dass wir die GET Parameter via stdin auslesen, da der xinetd das Zeugs ja nicht per GET an das php-Skript weiterleitet. Aber was solls… Der Kreativitaet sind da keine Grenzen gesetzt.

Ich wuerde natuerlich noch den Zugriff ueber irgendeine iptables Regel beschraenken ala:

iptables -A INPUT -p tcp -m tcp --dport 44444 -s 1.2.3.4 -j ACCEPT
iptables -A INPUT -p tcp -m tcp --dport 44444 -j REJECT

Und ueber Security von wegen das Skript als root laufen zu lassen usw. reden wir hier nicht weiter, es geht ja auch nicht darum das als Superloesung zu verkaufen, sondern einfach als simple kleine Adminspielerei ;-)