kleiner Spaß mit HowToForge

How To Forge .. kennt Ihr bestimmt. Ist so eine Webseite, wo Leute anderen Leuten zeigen, wie Dinge funktionieren. I.d.R. sind das spannende Sachen, wie man Webserver aufsetzt z.B.  . Es gibt aber auch Dinge, die nur eine Zeile lang sind, so wie der Artikel hier:  https://www.howtoforge.com/clear-bash-history/

Um was geht es überhaupt

„Das Löschen des BASH Kommandoarchives.“

Jeder der schon mal eine Bash-Shellkonsole benutzt hat, dürfte über die Bash-History gestolpert sein, als er ab- und unabsichtlich die Cursorsteuertasten benutzt hat. Damit kann man den vorherigen Befehl  nochmal sichtbar machen, Fehler beheben und wieder abschicken. Spart eine ganze Menge Tipparbeit.

Das lief dann auf … hinaus

Der Artikel lief dann auf diesen Einzeiler hinaus:

cat /dev/null > ~/.bash_history && history -c && exit

Und so schlicht das auch aussieht, da steckt doch glatt ein „Schönheitsfehler“ drin. Naja, ok, Fehler ist zu viel gesagt, ich würde es anders machen :

echo „“ > ~/.bash_history && history -c && exit

Bevor sich jemand zu Kommentarflames genötigt sieht, die eh gelöscht werden, was jetzt kommt ist rein akademisch.

Warum ?

Wir wollen die Datei leer haben, aber in einem definierten Zustand. Das Spezial-Device /dev/null erzeugt .. nichts.. Das ist aber weniger als „leer“ 🙂 Der Ansatz mit /dev/null funktioniert natürlich, weil cat solange was ausgibt, bis nichts mehr kommt und das passiert natürlich sofort. Also steht am Ende nichts mehr in der Datei, weil mit „>“ alles übergenagelt wird, was schon drin war.

Ich persönlich, finde ‚echo „“ >‘ als Konstrukt schöner, weil eindeutiger formuliert.

echo „“ zeigt deutlich, daß wir keinen Inhalt haben wollen. Bei /dev/null ergibt sich das nur indirekt aus dem Verhalten von cat und dem Verhalten von /dev/null . Beides muß man kennen um es zu verstehen. echo „“ sagt auch einem unbedarften Leser, daß es hier um „keinen Inhalt“ geht.

Wem das jetzt zu pingelig war, hat wohl noch nie versucht fremden Programmcode zu entziffern. Da spielt die eindeutige Benennung der Methode/Funktion eine wichtige Rolle, wenn der Code schon nicht Kommentiert ist. Das gleiche Prinzip gilt auch für Bashbefehle.

Soweit zu Teil 1..  jetzt reduzieren wir das mal brutalst auf 2 Befehle 🙂

echo „“ > ~/.bash_history; killall -9 bash

Was passiert hier ?

Zunächst mal machen wir die History platt, genau wie vorher. Jetzt killen wir alle Bash Shells die laufen, was in der Regel nur die eine sein wird. Shells von Root und anderen Benutzern können wir so nicht beenden, außer wir sind root. Da die Bash hart beendet wird, kann sie Ihre History nicht mehr auf Platte schreiben, womit die Datei auch nach dem Logout noch leer ist, welcher implizit beim Killen der Bashshell passiert. Ziel erreicht, ein Befehl weniger 😀

Zu Ursachen und Nebenwirkungen, fragen Sie Ihren Arzt und Drogendealer

Keine Frage, die Methode kann Kollateralschäden in anderen Bashsessions des Users verursachen. Sie ist auch um keinen Deut „besser“ als die ursprünglich vorgestellte Methode, nur kürzer. Und nur darum ging es heute.

Quelle: https://www.howtoforge.com/clear-bash-history/

How To Linux – Backspace funktioniert nicht ?

Du hast eine Linux CHROOT eingerichtet und die Backspace-Taste funktioniert nicht ?

Anstatt nach links, rückt die nach rechts ?

Du hast /etc/ komplett in die Chroot kopiert, aber es hilft nicht ?

stty -a gibt in der Chroot genau das gleiche aus, wie in der realen Umgebung ? (wenn nicht => stty sane )

Dann solltest Du mal das machen :

cd /
tar c /usr/share/terminfo | tar x -C /opt/chroot/

(den Pfad muß man natürlich an seine Installation anpassen)

 

 

Tip des Tages: Öfters mal Logfiles rotieren

Tomcat Logfiles können lang werden, daher sollte man diese desöftern rotieren.

Ganz unproblematisch ist das beim Tomcat aber nicht, denn im Gegensatz zu PHP Webanwendungen, stehen hier die Sessioninfos im RAM und nicht auf der Platte. Das hat beim Tomcat einen enormen Vorteil, weil der Server deutlich schneller an Infos kommt, als es z.B. PHP kann.

Der Nachteil liegt auf der Hand:  ein Neustart zerstört auch immer die Sessioninformationen. Gerade bei Shops ist das ein Problem. Hier muß die Sessionverwaltung dann auf Datenbanken ausgelagert werden, was bei verteilten Webanwendungen ohnehin gemacht werden muß.

Wo würde man daher das Logrotate ansetzen ?

Wer Serverdienste einsetzt, der braucht auch immer ein Startscript. Tomcat kommt zwar mit seinem eigenen startup.sh daher, aber auf ein klassisches Startscript ala init.d kann man eigentlich nicht verzichten. Hier ein Ausschnitt:

export CATALINA_HOME=/java/tomcat

ulimit -v unlimited -d unlimited -s unlimited -n 20000

PATH=$PATH:/usr/local/bin/

# See how we were called.
case "$1" in
 start)
 echo -n "Starting tomcat : "
 daemon /java/tomcat/bin/startup.sh
 RETVAL=$?
 echo
 ;;
 stop)
 echo -n "Stopping tomcat : "
 killtomcat
 RETVAL=$?
 echo
 ;;
 status)
 status tomcat
 RETVAL=$?
 ;;
 restart)
 $0 stop
 $0 start
 RETVAL=$?
 ;;
 *)
 echo "Usage: tomcat {start|stop|status|restart}"
 exit 1
esac

exit $RETVAL

und genau hier setzen wir an :

# See how we were called.
case "$1" in
 start)
 echo -n "Rotating Logs : "
 cd /usr/java/apache-tomcat/logs/
 echo "Deleting old files : "
 find . -ctime +100 -name "catalina.out*" -exec rm -fv {} \;
 COUNTER=0
 while [ $COUNTER -lt 99 ]; do
       echo The counter is $COUNTER
       let COUNTER=COUNTER+1
       if [ ! -f "catalina.out.$COUNTER" ]; then
           FILENAME="catalina.out.$COUNTER";
           break;
       fi
 done
 echo "Benutze $FILENAME";
 mv catalina.out $FILENAME
 echo "Compressing Logfile : $FILENAME"
 bzip2 -9 $FILENAME
 echo -n "Starting tomcat : "
 daemon /java/tomcat/bin/startup.sh
 RETVAL=$?
 echo
 ;;

Dieses Script ist natürlich nur ein Beispiel. Ihr müßt es noch anpassen an Eure Pfade und Präferenzen. Es wird Logfiles löschen, die älter als 100 Tage sind und maximal bis .99 zählen. Das kann je nach Häufigkeit des Starts Eures Tomcats dann eventuell nicht passen. Da müßt Ihr jetzt Eure Erfahrungen für Eurer System berücksichtigen.

Bitte beachtet, daß BZIP2 ein echter Zeitfresser ist, besonders in der Kombination mit 8 GB Logfile und -9 Option. Das packt hier auf einem nicht langsamen Server bereits seit 50 MInuten 😉 Das Ergebnis ist allerdings genial:

catalina.out.5: 53.987:1, 0.148 bits/byte, 98.15% saved, 8.250.838.531 in, 152.828.685 out.

Unter 2 % sind vom Logfile übrig geblieben 🙂

Wer jetzt meint, daß dieser Beitrag den 50 Minuten geschuldet ist, hat recht 😀 War leider ein echter Blocker.

 

Wie man in Bash Strings partiell vergleicht

Bash Stringvergleiche sind einfach :

if [ "$a" == "$b" ]; then 
          echo "gleich"
fi

Aber manchmal will man ja was auch nur Teilmengen vergleichen. Dazu braucht man die Doppelklammer und die Wildcards:

if [[ "$CERTNAME" == *"$HOSTNAME"* ]]; then
        echo "Teilvergleich erfolgreich"
fi

Wenn also HOSTNAME ein Teil von CERTNAME ist, dann trifft das obige zu. Wenn man == durch != ersetzt, kann man das Gegenteil abfragen. Es gibt aber noch einen anderen Weg, über RegExpressions:

if [[ "$CERTNAME" =~ .*$HOSTNAME.* ]]; then
   echo "RegExp ist gültig"
fi

Das hat den Vorteil, daß es auch etwas komplizierteres sein darf:

if [[ "$A" =~ .*(ab|vom).* ]]; then

Viel Spaß damit.