Kategoriearchive: Snippets

Command-Line: Mail mit Anhang

Ein kleines Snippet, um Mails mit Anhang via „mail“-Befehl zu versenden.
Unter Debian und Ubuntu das Paket „sharutils“ installieren. Hiermit können Dateien für den Mail-Versand vorbereit werden:

sudo apt-get install sharutils

Das Format lautet: uuencode lokale_datei.any empfaenger_dateiname.any.
Die lokale Datei kann also unter anderem Namen versendet werden.

Hier ein paar Beispiele, angefangen mit dem einfachen Versenden einer Datei:

uuencode datei.jpeg datei.jpeg | mail empfaenger@domain.tld

Mit Nachricht – alternativ: „echo“:

(cat Nachricht; uuencode datei.jpeg datei.jpeg) | mail empfaenger@domain.tld

Mit Absender und Betreff:

(cat Nachricht; uuencode datei.jpeg datei.jpeg) | mail -a "From: Absendername " -s "Betreff" empfaenger@domain.tld

Mit Absender, Betreff und UTF-8 Encoding („multiple header“):

(cat Nachricht; uuencode datei.jpeg datei.jpeg) | mail -a "`echo -e "Charset: UTF-8\nFrom: Absendername "`" -s "Betreff" empfaenger@domain.tld

Alternativen

Heute, dem 15.01.2014, möchte ich noch moderne Alternativen ergänzen, angefangen mit „mutt“, welches MIME-konform ist:

sudo apt-get install mutt

Beispiel mit Nachricht und Betreff:

 echo "Nachricht" | mutt -s "Betreff" empfaenger@domain.tld -a datei.jpeg

Zweite Alternative mit „uuenview“ – Kann quasi alles, was „uuencode“ bietet, ist jedoch wie „mutt“ MIME-konform:

sudo apt-get install uudeview

Beispiel mit Nachricht und Betreff („-a“ für Eingabe der Nachricht via „stdin“:

cat Nachricht | uuenview -b datei.jpeg -m empfaenger@domain.tld -a

Debian: Non-interactive upgrade script

Oft nach gefragt, hier beantwortet: Im neuen Debian Handbook wird ein „non-interactive upgrade script“ wie folgt vorgeschlagen:

#!/bin/bash
export DEBIAN_FRONTEND=noninteractive
yes '' | apt-get -y -o Dpkg::Options::="--force-confdef" -o Dpkg::Options::="--force-confold" dist-upgrade

„force-confold“ und „force-confdef“ kombiniert gibt durchaus Sinn. So wird ein Hänger beim Upgrade definitiv verhindert. Es wird stets die aktuelle Konfiguration behalten, gibt es keine, werden die Standardwerte verwendet.

„SHELL“ und „PATH“ für alle Cronjobs definieren

Ein kleiner Hinweis im Bezug auf einen weiteren Beitrag von heute.

Wer einige Scripts via Cronjob ausführt, wird wahrscheinlich – wie ich – die Shell sowie den „Path“ als Variable im Script selber definieren. Sollen aber Bash-spezifische Befehle in einer Zeile ausgeführt werden, bleibt „eigentlich“ kein Platz für das Definieren von Shell und „Path“.

Abhilfe verschafft man sich durch das definieren im Kopf der Cron-Datei. Wie gewohnt „crontab -e“ ausführen, um einen Cronjob anzulegen:

crontab -e

Ganz oben nun Folgendes ergänzen:

SHELL=/bin/bash
PATH=/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11

Unten wie gewohnt die Cronjobs eintragen. Ein Bespiel für einen Cronjob, der ohne obige Definition nicht funktionieren würde:

0 10 * * * /home/X/script.sh "`echo -e "Zeile eins\nZeile zwei"`"

Die gesamte Cron-Datei (z.B. „/var/spool/cron/crontabs/user“):

# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.txt installed on Sat Dec 21 18:22:45 2013)
# (Cron version -- $Id: crontab.c,v 2.13 1994/01/17 03:20:37 vixie Exp $)
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/local/sbin:/sbin:/usr/sbin:/bin:/usr/bin:/usr/bin/X11
0 10 * * * /home/X/script.sh "`echo -e "Zeile eins\nZeile zwei"`"

Ladezeit verbessern: jQuery im Footer von WordPress laden

Ein kleines Snippet, um jQuery im Footer von WordPress zu laden. Daher ohne großes Getippe:

Gehört in die Datei „functions.php“ des jeweiligen Themes, z.B. „/wordpress/wp-content/themes/custom-1/functions.php“.

function evolution_clean_head() {
 
	remove_action('wp_head', 'wp_print_scripts'); 
	remove_action('wp_head', 'wp_print_head_scripts', 9); 
	remove_action('wp_head', 'wp_enqueue_scripts', 1); 
}
 
add_action( 'wp_enqueue_scripts', 'evolution_clean_head' );

Weiterlesen

Tiny Tiny RSS Update Daemon INIT-Script

„Yet another Update Daemon Script“, nachdem ich nicht wirklich vernünftige gefunden habe. Die meisten töten einfach „screen“ oder PHP, wenn sie den Daemon beenden wollen. Ich habe hier eine Lösung, in der der Session-Name für „screen“ gesetzt wird und diese Session dann explizit geschlossen wird.

Script + Beschreibung

Im Prinzip ein simples INIT-Script. Über Upstart wäre es natürlich viel kleiner. Allerdings benutze ich kein Upstart (oder Systemd) auf meinem Debian Server.

#!/bin/bash
### BEGIN INIT INFO
# Provides: TT-RSS Daemon
# Required-Start: $network $syslog
# Required-Stop: $network $syslog
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Description: Start TT-RSS Daemon
### END INIT INFO

UPDATEDAEMON=/var/www/path/to/update.php
RUNAS=www-data
SESSIONNAME=tinytinyrss

case "$1" in
start)
echo "Starting Tiny Tiny RSS daemon..."
su $RUNAS -c "screen -S $SESSIONNAME -d -m php $UPDATEDAEMON --daemon"
;;

stop)
echo "Stopping Tiny Tiny RSS daemon..."
su $RUNAS -c "screen -S $SESSIONNAME -X quit"
;;

*)
echo "Fehlerhafter Aufruf"
echo "Syntax: $0 {start|stop}"
exit 1
;;

esac

Es gibt 3 Variablen am Anfang des Scripts, die vorher natürlich angepasst werden müssen. Wer sich nicht sicher ist, ob der Webserver als www-data läuft, kann das vorher schnell prüfen:

ps aux | grep -E 'nginx|httpd|apache' | grep -v root

Sieht dann z.B. (www-data) so aus:

www-data 10430  0.0  0.0  69584  3068 ?        S    13:25   0:00 nginx: worker process

In dem Fall wäre RUNAS=www-data

UPDATEDAEMON ist selbsterklärend. Das ist der Pfad zur update.php von Tiny Tiny RSS.

SESSIONNAME muss ein eindeutiger Name für die „screen“ Session sein. Der Name ist frei wählbar. Natürlich darf keine Session mit dem selben Namen existieren.

Installation

Vorab „screen“ installieren, falls das nicht schon passiert ist:

apt-get install screen

Das Script nun einfügen. „nano“ kann mit STRG+X geschlossen werden, es wird vorher gefragt, ob gespeichert werden soll (alternativ STRG+W vorab benutzen):

sudo nano /etc/init.d/ttrssd

Das Script ausführbar machen, als Dienst installieren und direkt starten:

sudo chmod +x /etc/init.d/ttrssd && update-rc.d ttrssd defaults && sudo /etc/init.d/ttrssd start

Daemon überprüfen

Ob der Daemon läuft, kann mit mehreren Methoden überprüft werden. Der einfachste Weg wäre der über TT-RSS selbst. Alternativen für die Shell:

su www-data -c "screen -ls"

oder

ps aux | grep -i [u]pdate.php