BibTeX: en_plaindin.bst

What is en_plaindin.bst?

For creating a bibliography according to the German citation rules defined in DIN 1505 Part 2, the BibTeX style “plaindin.bst” exists. The file is available in the CTAN archive.

Unfortunately, this style is not suitable for publications written in English, since it contains some German words, e.g. “Hrsg.” for “eds.” .

Therefore, I created a translated version of the plaindin-style, which provides the same structure of the entries but does not use German language.

Download

The style is called en_plaindin.bst.

The style file can be downloaded here: Download.

How to use en_plaindin.bst

  1. Copy the downloaded file to the folder of your LaTeX-project.
  2. Put the following command into your tex-file before you create the bibliography:

\bibliographystyle{en_plaindin}

 Note:

This file comes without any warranty. Please take care, that the generated bibliography is free of errors and conforming the style you need for your usecase. I do not garantuee, that the generated bibliographies comply to the DIN norm.

LaTeX: Akronymliste mit glossaries anpassen

Ich benötige in einem Dokument ein Abkürzungsverzeichnis der folgenden Form:

DB (Deutsche Bahn)  Deutsches Schienenverkehrsunternehmen

Oder formal:
<Abkürzung> (<Langform>)
<Beschreibung>

Mittels des glossaries-Paket lässt sich dies mit folgendem selbstdefinierten Style umsetzen:

\newacronymstyle{my-short-long-desc}%
{%
    \GlsUseAcrEntryDispStyle{short-long}%
}%
{%
    \GlsUseAcrStyleDefs{short-long}%
    \renewcommand*{\GenericAcronymFields}{}%
    \renewcommand*{\acronymsort}[2]{##2}%
    \renewcommand*{\acronymentry}[1]{%
    \acronymfont{\glsentryshort{##1}}\space (\glsentrylong{##1})}%
}

\setacronymstyle{my-short-long-desc}

Diese Definition basiert auf der mitgelieferten short-long-desc-Definition (die nicht richtig funktioniert) und muss vor der Definition der ersten Definition einer Abkürzung erfolgen.

Android Gerät sichern ohne Root

An der Uni arbeite ich gerade mit mehreren Leuten an einem wissenschaftlichen Paper zum Thema Smartphone -Sicherheit. Dazu ist es notwendig, eine für eine Nutzerstudie programmierte App unter mehreren Android-Versionen zu testen.

Warum ein Backup?

Da ich mein Entwicklergerät (Galaxy Nexus) auch als mein Alltagsgerät nutze, möchte ich nicht bei jeder Neuinstallation meine kompletten Apps und Einstellungen manuell wiederherstellen.

Aus diesem Grund habe ich eine Möglichkeit gesucht, ein komplettes Backup des Geräts zu erstellen, ohne root-Zugriff zu benötigen. Da ich für die private Verwendung aus Sicherheitsgründen auf einen root-Zugriff verzichte, muss ein Backup auch ohne diese auskommen.

Was nicht funktioniert

Der erste Ansatz über die Backup-Funktionalität von adb (z.B. hier) hat nicht zuverlässig funktioniert. Beispielsweise werden gekaufte Anwendungen nicht korrekt gesichert, Passwörter für WiFi-Netzwerke nicht mitgesichert, etc. Somit ist es trotzdem ein Aufwand, die Wiederherstellung durchzuführen.

Die Lösung

Mittels des Recovery-Tools “clockworkmod” lässt sich eine Sicherung erstellen. Das Tool kann über die Webseite www.clockworkmod.com bezogen werden.

Backup durchführen

Voraussetzungen:

Um das Tool booten zu können muss der Bootloader entsperrt sein. Das funktioniert bei jedem Gerät anders – deshalb der Tipp: Google!

Zudem müssen die Entwicklerwerkzeuge für Android von Google installiert sein. Wichtig sind die Tools adb und fastboot.

Die Befehle adb und fastboot werden auf der Konsole ausgeführt. Das $-Zeichen markiert nur, den Kommandoprompt und muss nicht mit eingegeben werden.

  1. In den Bootloader starten: $ adb reboot bootloader
  2. Recovery-Image starten (nicht installieren!): $ fastboot boot clockworkmod.img
  3. Im nun startenden Menü den Punkt Backup and restore auswählen und dann das Backup durchführen.
  4. Backup auf die SD-Karte (oder den internen Speicher kopieren): Mittels $ adb shell eine Konsole auf dem Gerät öffnen.
  5. Das Backup liegt im Verzeichnis: /mnt/shell/emulated/clockworkmod/backup
    (Notiz: Das Verzeichnis kann sich eventuell je nach Gerät unterscheiden!)
  6. Mittels $ cp -R /mnt/shell/emulated/clockworkmod/backup/ /sdcard/clockworkmod/ wird das Backup auf die SD-Karte (oder deren interne Repräsentation) kopiert.
  7. Mit $ exit kann nun die Shell auf dem Gerät verlassen werden.
  8. Mittels $ adb pull /sdcard/clockworkmod/ kann das Backup auf den PC kopiert werden.

Wiederherstellung

  1. In den Bootloader starten: $ adb reboot bootloader
  2. Recovery-Image starten (nicht installieren!): $ fastboot boot clockworkmod.img
  3. Mittels $ adb shell eine Konsole auf dem Gerät öffnen.
  4. Um das Backup wiederherzustellen, muss es zuerst auf die SD-Karte in den Ordner /sdcard/clockworkmod kopiert werden. Dies kann über den Explorer oder über das adb push-Kommando passieren.
  5. Über Backup and Restore die Wiederherstellung starten.

Effizienter Gitlab-Server

Zur Verwaltung von Unidaten, geschäftlichen Daten und bestimmten privaten Daten verwende ich das Versionskontrollsystem git mit der komfortablen Weboberfläche gitlab, die Funktionen wie eine übersichtliche Darstellung der einzelnen Commits und einen Issue-Tracker bereitstellt.

Der Server muss nicht ständig in Betrieb sein, sondern nur, wenn ich an bestimmten Projekten arbeite und die Änderungen auf einen zentralen Server übertragen möchte. Somit kommen pro Monat meist  unter 100 Betriebsstunden zusammen – ein ständig betriebener Server lohnt sich also nicht. Trotzdem möchte ich nicht auf den Komfort und die Möglichkeiten der gitlab-Oberfläche sowie die zentralen Sicherung von Daten verzichten.

Bisher habe ich gitlab auf einem Server in der IaaS-Cloud jiffyBox von domainfactory gehostet. IaaS steht für Infrastructure as a Service – also Infrastruktur, die als Dienstleistung flexibel angemietet werden kann. JiffyBox ist ein toller Dienst, mit dem sich virtuelle Server leistungsmäßig skalieren lassen, ohne Daten zu verlieren. Durch die Möglichkeit, den Server einzufrieren, ist eine günstige Datenablage möglich, wenn der Serverbetrieb nicht ständig erforderlich ist. Je nach Nutzung hatte ich dafür monatliche Kosten von 4-6 Euro – also eine sehr günstige Lösung.

Da ich bei mir noch ungenutzte Hardware stehen hatte, habe ich mich trotzdem dazu entschieden, den Server in Zukunft selbst zu betreiben.

Die funktionalen Anforderungen sind:

  • Betrieb einer Gitlab-Instanz für einen Benutzer mit derzeit insgesamt 5 GB an Repositories, Platzbedarf steigend
  • Eine zusätzliche Standleitung ins Internet soll nicht erforderlich sein.
  • Der Server muss aus der Ferne startbar und wartbar sein.
  • Der Betrieb muss auch bei  Abwesenheit am Standort sicher sein.
  • Der Betrieb soll möglichst energieeffizient erfolgen.

Internetanbindung

Der Server wird an einem normalen Telekom-DSL-Anschluss für Geschäftskunden (DeutschlandLAN Connect S) betrieben. Als Router kommt eine Fritz!Box 7360 von AVM zum Einsatz. Die Datenraten sind:

  • Upload: ca. 2,5 MBit/s
  • Download: ca. 17 MBit/s

Für die von mir benötigen Anwendungsfälle sollte dies ausreichend sein, zumal ich derzeit der einzige Nutzer des Servers sein werde.

Starten aus der Ferne

Die Fritz!Box unterstützt über die Weboberfläche das Starten eines per LAN angebundenen Rechners per Wake-on-LAN. Da die Weboberfläche passwortgeschützt über das Internet erreichbar ist, lässt sich der Server weltweit starten.

Fernüberwachung

Um eine bestmögliche Kontrolle über den Server zu haben, hängt er an einer FRITZ!DECT 200-Steckdose. Dabei handelt es sich um eine schaltbare Steckdose, die sich an die Fritz!Box anbinden lässt. Als Funkstandard wird dabei verschlüsseltes DECT verwendet.

Über die Weboberfläche lässt sich die Steckdose einerseits ein- und ausschalten, andererseits lässt sich damit aber auch der Stromverbrauch überwachen. Es kann sowohl die aktuelle Leistung angezeigt und grafisch dargestellt werden, als auch der Energieverbrauch über verschiedene Zeiträume (Tag, Woche, Monat, Jahr) aufgezeichnet und dargestellt werden.

Mittels der Schaltfunktion lässt sich der Server sicher vom Strom trennen, wenn er nicht benötigt wird. Zudem besteht die Möglichkeit, den Server bei Softwareproblemen (z.B. “aufgehängt”) aus der Ferne physikalisch vom Stromnetz zu trennen, wenn beispielsweise ein Zugriff über ssh nicht mehr möglich ist.

Durch die Überwachung der aktuellen Leistung lassen sich zudem Schlüsse über den aktuellen Betriebszustand des Servers ziehen, welche die Handhabung aus der Ferne deutlich erleichtern:

  • Wurde der Server nach dem Versenden des Wake-on-LAN-Paketes gestartet?
  • Wurde der Server nach dem Absenden des shutdown-Befehls erfolgreich heruntergefahren?

Erreichbarkeit unter eigener Domain trotz dynamischer IP-Adresse

Der verwendete DSL-Anschluss beinhaltet leider keine feste IP-Adresse. Diese wechselt täglich, da alle 24 Stunden eine Zwangstrennung erfolgt. Die Fritz!Box bringt allerdings einen Dienst mit, der dem Gerät einen festen Domainnamen der Form xxxxxxxxxxxx.myfritz.net zuweist. Die aktuelle IP-Adresse wird automatisch mit diesem Domainnamen verknüpft.

Der Server soll aber auch unter einer eigenen Subdomain erreichbar sein. Meine Domains habe ich über domainfactory gebucht. Dieser Anbieter unterstützt das manuelle Editieren der Nameserver-Einstellungen.

Durch das Hinzufügen eines Eintrags vom Typ CNAME lässt sich ein Alias für die xxxxx.myfritz.net-Adresse anlegen. Die eigene Domain löst so immer korrekt auf die aktuelle IP-Adresse der Fritz!Box auf.

Portweiterleitungen

Damit Anfragen an diese Domain auch beim gitlab-Server und nicht bei der Fritz!Box landen, müssen noch die benötigten Ports an den Server weitergeleitet werden. Dies lässt sich sehr einfach über die Weboberfläche der Fritz!Box einstellen.

Folgende Ports müssen weitergeleitet werden:

  • Port 22 (SSH – für Fernwartung)
  • Port 80 (HTTP – für unverschlüsselten Zugriff)
  • Port 443 (HTTPS – für SSL-verschlüsselten Zugriff)

Der Port für die Fritz!Box-Weboberfläche muss noch auf einen anderen Port umgestellt, da sonst der SSL-Port (443) belegt ist.

Wie stabil der Betrieb auf die Dauer läuft, muss sich zeigen. In der Übergangszeit bleibt die JiffyBox-Instanz erhalten – falls unerwartete Probleme auftreten sollten.

Automatische Lautstärke-Anpassung unter Debian

Der von Debian 7.4 verwendete Audio-Server pulseaudio hat in der Standardeinstellung eine unangenehme Eigenschaft: Jede Anwendung kann die Master-Volume-Einstellung verändern. Dabei wird intern vermutlich versucht, die Lautstärke gleich zu halten.

Dies hat zur Folge, dass beispielsweise das Terminal beim Absenden eines Bell-Signals (“Ding”), z.B. bei der Auto-Vervollständigung von Pfadnamen, an der Lautstärke dreht. Im Hintergrund laufende Musik/Videos werden dadurch für ein paar Sekunden deutlich lauter abgespielt.

Um dieses störende Verhalten abzustellen ist folgende Änderung notwendig:

In der Datei /etc/pulse/daemon.conf folgende Zeile so anpassen:

Vorher:
; flat-volumes = yes

Nacher:
flat-volumes = no

Danach muss pulseaudio neugestartet werden, was z.B. durch den Neustart des Rechners erfolgen kann.

Quelle: http://wiki.gentoo.org/wiki/User%3aFeystorm#PulseAudio_per-application_volume_control