Einfache Videobearbeitung mit freier Software

Ab und an will man mal ein selbst gedrehtes Video bearbeiten, schneiden und mit ein paar Effekten aufhübschen. Ist man Besitzer eines Mac oder Windows-PC’s so fällt die Wahl eines Programmes im ersten Augenblick nicht schwer. Microsoft und Apple liefern mit ihren Betriebssystemen sehr gute und einfach bedienbare Programme zur Videobearbeitung mit, welche für den Heimanwenderbereich mehr als ausreichend sind. Nutzer eines freien Betriebssystems können sich aus vielen Programmen das für sie geeignetste raus suchen, jedoch reicht da die Spanne von “Sehr anwenderfreundlich” bis zu “Sehr professionell”.
Heut möchte ich zwei meiner Favoriten vorstellen, mit denen man einfach und bequem seine Videos bearbeiten kann.
Meine Wahl ist in erster Linie auf  “OpenShot” gefallen. OpenShot ist recht selbsterklärend, übersichtlich gestaltet und bietet dennoch interessante Funktionen.
Das Programm ist in den meisten Paketpools diverser Distributionen mit enthalten und versteht mit Hilfe von ffmpeg auch nahezu jedes gängige Videoformat.
Es lassen sich Überblendeffekte und Filter verwenden – ebenso können auch wie in jedem guten Videobearbeitungsprogramm Titel hinzugefügt werden. Mehrere Videos oder Bilder können auch übereinander gelegt werden.
Das zweite Programm meiner Wahl ist “Kdenlive“. Hier wird dem Anwender mehr an Funktionen geboten, die Oberfläche ist auch dementsprechend komplexer, jedoch nicht überladen oder unübersichtlich.
Kdenlive liefert ähnlich wie Openshot diverse Effekte und Übergänge mit. In Kdenlive können auch Tonspuren hinzugefügt oder entfernt werden. Diese Funktion fehlt bei Openshot.
Da Kdenlive auch auf ffmpeg setzt, muss man sich bei diesem Programm ebenfalls keine Gedanken über das Videoformat machen, welches importiert oder exportiert werden soll. Nett ist auch der DVD-Asssistent, welcher einem die Arbeit bei der Erstellung einer Video-DVD erleichert.
Für jene, die eine Diashow als Video erstellen möchten, bringt das Programm eine Funktion namens “Diashow-Clip hinzufügen” mit. Diese Funktion importiert alle Bilder eines Ordners und reiht sie mit einer vom Benutzer festgelegten Länge nacheinander auf und es kann auch gleich eine Animation für den Übergang festgelegt werden.
Wem beide Tools nicht zusagen, dem sei die Übersichtsseite aus dem Ubuntuusers-Wiki nahegelegt, in der weitere Programme für die Videobearbeitung aufgeführt und kurz beschrieben sind.

Spielerische Auswertung von Webserver-Logs

Die Logfiles als lustiges Retro-Game – das geht mit dem kleinen “Spiel” Logstalgia, auch bekannt als “ApachePong”.
Logstalgia kann die bestehenden Logfiles auswerten oder den Livetraffic mitverfolgen. Dabei werden die Anfrangen als PingPong-Bälle dargestellt, die unterschiedlich groß sind (Dateigröße).
Wir haben uns den Spaß gemacht und auf icinga.org den Livetraffic als spannendes PingPong-Battle mitverfolgt, hier ein paar Screenshots:

Logstalgia läuft unter allen gängigen Betriebssystemen. In einigen Distributionen ist es sogar im Repository mit enthalten, somit reicht unter Debian/Ubuntu ein einfaches apt-get install logstalgia aus um seine eigenen Logfiles zu bestaunen.
Ein Blick in die Manpage bietet viele Optionen um Logstalgia seinen Wünschen nach einzustellen. So lassen sich beispielsweise auch Daten aus stdin an Logstalgia weiterreichen, wie folgendes Beispiel zeigt:
ssh root@server-adresse “tail -f /var/log/apache2/access.log” | logstalgia –

Apache 2: Authentifizierungsmethoden über Source-IP steuern

Mit den normalen Bordmitteln des Apache2 ist es aktuell nicht möglich, zwei verschiedene Authentifizierungsmethoden zu verwenden. Gebrauchen kann man das aber beispielsweise sehr gut, wenn man einen webbasierten Dienst hat, welchen man für das interne Firmennetzwerk gegen LDAP und von extern über MOTP authentifizieren lassen möchte. Vorteil ist dabei, dass die nach außen offene Seite nicht durch Bruteforce-Attacken “gehackt” werden kann.
Um diese Unterscheidung der Netze zu realisieren, wird eine iptables-Regel eingerichtet, welche alle Anfragen einer bestimmten Quelle auf einen anderen Port umleitet. Zusätzlich muss noch ein VHost angelegt werden, welcher auf diesem Port lauscht und die gewünschte Authentifizierung anbietet.
Ein kleines Praxisbeispiel:
Ich möchte, dass alle Anfragen, welche von extern kommen, gegen MOTP authentifiziert werden. Dafür lege ich einen VHost an, der auf Port 80 lauscht und MOTP als Authentifizierung anbietet.
Mein internes Netz, welches durch NAT nur eine IP (1.2.3.4) nach außen besitzt, soll sich gegen LDAP authentifizieren. Dafür lege ich ebenfalls einen VHost an, der auf Port 81 lauscht.
Nun leite ich den Verkehr, der von meinem Router des internen Netzes (IP 1.2.3.4) kommt auf Port 81 um. Da ich nicht will, dass alle Anfragen umgeleitet werden, weil ich noch mehrere Seiten auf meinem Server betreibe, habe ich zusätzlich den “LDAP-VHost” auf die IP 127.0.0.2 gebunden.
Jetzt richte ich meine iptables-Regel ein:

iptables -t nat -A PREROUTING -s 1.2.3.4 -d 127.0.0.2 \
                -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 81

Nun werden alle Anfragen wie gewünscht umgeleitet. Mit iptables-save kann ich mir die aktuellen Einstellungen ausgeben lassen und sie später per init-Skript wieder mit aufnehmen. Somit sind die Einstellungen auch “rebootfest”. Wichtig sei noch zu erwähnen, dass pro VHost eine eigene, externe IP benötigt wird.

Icinga-Mobile: Die Oberfläche für das Handy

Hat man schon einmal versucht auf einem Handy oder Tablet Icinga-Web zu benutzen, so ist mit Sicherheit aufgefallen, dass dieses nicht dafür ausgelegt ist um auf solch Geräten genutzt zu werden. Dafür wurde Icinga-Mobile entwickelt, welches sich schnell und effektiv über eine gut angepasste Oberfläche bedienen lässt.
Um Icinga-Mobile zu nutzen, wird im Vorfeld Icinga-Web benötigt und ein Benutzer, welcher die AuthKey Authentifizierung aktiviert hat. Sind beide Dinge gegeben, so lässt sich Icinga-Mobile recht einfach installieren.
Eine schöne Anleitung dazu findet sich im Wiki der Icinga-Projektseite. Wer Icinga-Mobile ausprobieren möchte dem steht eine Online-Demo zur Verfügung sowie eine Online-Galerie mit Screenshots.
Mit Icinga-Mobile hat man Zugriff auf alle wichtigen Funktionen. Es können mehrere Systeme oder Servicechecks ausgewählt und ähnlich wie bei Icinga-Web acknowledged werden.
Um eine Benutzerverwaltung zu erhalten, kann man sich mit einer Basic Auth behelfen, beispielsweise in Verbindung mit mod_ldap (Apache2), um eine einfache Anbindung an ein Active-Directory zu realisieren.

One Time Password Authentifizierung mit MOTP

Eine OTP Authentifizierung ist eine praktische und vor allem sichere Angelegenheit. Aus verschiedenen Daten wird ein Passphrase errechnet, welcher nur für einen kurzen Zeitraum und einmalig gültig ist und somit nicht mehrmals verwendbar.
Es gibt viele Lösungen, welche auf Hardware-Tokens setzen und entsprechende Anschaffungskosten anfallen. Als gute Alternative bietet sich das Mobile One Time Password-Projekt an, kurz MOTP. MOTP ist mehr der eigentliche Algorithmus, auf dessen Basis diverse Clients für alle gängigen Betriebssysteme und mobilen Endgeräte (J2ME, Blackberry, Android, iOS, WebOS …) sowie serverseitig viele Implementierungen entwickelt worden sind. Heut möchte ich kurz ein Apache Modul und einen iOS Client vorstellen, mit denen eine einfache OTP Authentifizierung realisiert werden kann.
MOTP berechnet seine OTPs auf Basis dreier Komponenten:

  • PIN (bleibt gleich, wird beim Client eingegeben)
  • Secret (Im Regelfall ein Hash, welcher aus Zufallsdaten vom Client generiert wird)
  • Uhrzeit (MOTP setzt auf zeitbasierte Generierung, Zeiten müssen auf Client und Server übereinstimmen! – NTP)

Das verwendete Apache Modul, mod_authn_otp, muss zunächst compiliert werden. Eine Anleitung, welche Abhängigkeiten installiert werden müssen und wie es ordnungsgemäß installiert wird, findet sich im Projektwiki.
Angesprochen wird das Modul in der Apache Config als normales Basic Auth. Hier wird auch ein UserFile angegeben, wo die jeweiligen Nutzer mit ihren Secrets und dazugehörigen Pins angegeben werden. Zu beachten ist, dass dieses File vom Apache Benutzer schreibbar sein muss, damit das Modul einen Timestamp setzen kann. Dies bietet die Funktion, dass ein Token für einen festgelegten Zeitraum gültig ist, und somit der Nutzer nicht ständig aufgefordert wird, einen neuen Token eingeben zu müssen.
Als Client habe ich mOTP aus dem AppStore genommen. Diese App ist sehr einfach in der Bedienung und generiert selbst einen Secret, welcher in das UserFile übernommen werden kann. Auf der MOTP Projektseite gibt es eine große Auswahl an weiteren Clients für diverse Systeme. Beispielsweise wurde ein Client in Python geschrieben, welcher auf jedem gängigen OS funktionieren sollte.

Einfaches und schnelles Erstellen und Verteilen von Dateisystemimages

In Vorbereitung auf unsere anstehenden Schulungstermine für Puppet und SLA, stelle ich heute die Software Clonezilla vor, mit der einfach und performant Images erstellt und über das Netzwerk verteilt und eingespielt werden können.
Clonezilla bedient sich dabei mehrerer Projekte und fasst diese unter einem Dach mit einer Konfigurationsoberfläche zusammen:

Somit bietet Clonezilla den Vorteil mit nahezu jedem gebräuchlichen Dateisystem zusammenarbeiten zu können, was bei der Einzellösung Partimage, beispielsweise nicht der fall ist, da NTFS nur experimentell unterstützt wird.
Ebenfalls hat das Team um Clonezilla eine LiveCD bereitgestellt, mit der ohne Installation ein bestehendes System auf lokale Datenträger oder Netzwerkfreigaben wie Samba, NFS oder SSH gesichert werden können. Die Menüführung ist dabei selbsterklärend.
Um die Images auf einzelnen Maschinen zurückzusichern, bietet sich ebenfalls die LiveCD von Clonezille an. Sollte jedoch die Anforderung bestehen über Multicast mehrere Geräte zurückzusichern, so muss man zu der CloneZilla Server Edition greifen. Die Server Edition kann dann in Verbindung mit DRBL den Clients einen PXE Boot anbieten, worüber dann automatisiert das Image zurückgespielt wird.
Auf der Projektseite von Clonezilla befinden sich zusätzlich auch sehr gute Dokumentationen und Beispiele für den praktischen Einsatz.
Das Team von DRBL hat auf seiner Prokeltseite zusätzlich ein Live System erstellt , welches ebenfalls CloneZilla ServerEdition beinhaltet. Diese LiveCD kann genutzt werden um schnell und ohne großen Konfigurationsaufwand eine laufende CloneZilla Umgebung zu bekommen.

ispCP: Einfaches Control Panel zur Webserververwaltung

Für viele Anwender ist das Anlegen von Apache-vhosts oft eine kryptische Angelegenheit, da man sich durch einige Zeilen Anweisungen der Apache-Syntax durchwühlen muss und der Dienst den Start wegen Fehler verweigert. Oder man möchte mehrere Kundenwebsites auf einem großen System bequem verwalten, Mail-Konten anlegen und zuweisen, Domainadressen vergeben oder um bei ca. 100 Kunden nicht den Überblick zu verlieren.
Genau für solche Szenarien eignet sich die freie und offene Software ispCP Omega, ein Fork aus dem nicht mehr aktiven VHCS Projekt. ispCP besticht durch seine gute Bedieneroberfläche und dem Funktionsumfang. So ist es beispielsweise möglich, Benutzer in verschiedene Rollen zu unterteilen wie “Administrator”, “Reseller” und “User” und ihnen auch gezielt bestimmte Berechtigungen zuzuweisen oder zu entziehen.
Die Installation wird über ein Installationsskript und den von ispCP bereitgestellten Dokumentationen sehr einfach vollzogen und es ist binnen weniger Minuten fertig.
Scheut man eine Versuchsinstallation, so kann man sich auf der Projektseite auch gern an den Online-Demos austoben und ispCP auf Herz und Nieren überprüfen.
Wir haben bei einem Kunden ispCP erfolgreich im Einsatz und stießen auf großen Zuspruch seinerseits. Ebenfalls haben wir ispCP in einem Cluster aus zwei Nodes im produktiven Betrieb und sogar die Installation vollkommen automatisiert in Puppet abgebildet.
ispCP wird schon seit einiger Zeit sehr aktiv entwickelt und steht aktuell in der stabilen Version 1.0.7 bereit. Wer gern schon jetzt einen Blick auf die neuen Features der kommenden Version werfen möchte, dem sei die Entwicklerversion 1.1.0 Beta empfohlen.

Backporting – Quick and a bit dirty

Oftmals steht man vor der Problematik, dass man auf seinem Produktivsystem eine aktuellere Version von einem Programm benötigt als sie bereits im Repository der stabilen Ausgabe von Debian vorhanden ist. Für solche Problemfälle gibt es das Backports-Projekt, indem aber natürlich auch nicht alle Pakete enthalten sind, da nur selektiv einzelne Pakete aus dem neuen “testing”-Zweig von Debian gegen ein Stable-Environment gebaut werden.
Häufig werden dann die benötigten Programme in aktueller Version selbst übersetzt und somit aus der Paketverwaltung ausgekoppelt, was das Einspielen von Updates erschwert.
Der direktere Weg ist selbst sich Pakete zu backporten. Dies hat folgende Vorteile:

  • Integration in die Paketverwaltung (Vereinfachung beim Einspielen von Updates oder einem Upgrade)
  • durch die Maintainer an das Debian-System angepasst
  • einfache Weitergabe und Verteilung auf mehreren Systemen

Grundlage bietet zunächst eine chroot-Umgebung, damit das System, auf dem Gearbeitet wird nicht “zugemüllt” wird durch diverse dev-Pakete. Das Anlegen eines chroots ist recht einfach und geschieht mit debootstrap (muss als root ausgeführt werden)

root@localhost:~# mkdir chroot_squeeze
root@localhost:~# debootstrap squeeze chroot_squeeze/ http://ftp.de.debian.org/debian
I: Retrieving Release
I: Retrieving Packages
....

Wenn debootstrap die Umgebung gebaut hat, kann mit chroot chroot_squeeze/ /bin/bash in das chroot gewechselt und ohne Gefahr gearbeitet werden. Weiterer großer Vorteil ist, dass wenn was schief geht und das System “zerschossen” wird, man den chroot-Ordner einfach löscht und neu anlegt.
In der chroot-Umgebung sollten zunächst die /etc/apt/sources.list angepasst und um die Source-Quellen erweitert werden. Empfehlenswert ist es zunächst ersteinmal komplett den stable-Zweig von Debian zu verwenden, um die Build-Dependencies von den Stable-Paketen zu installieren. Hintergrund ist, dass so schon einmal der Großteil der benötigten Pakete installiert wird und später schneller und gezielter die fehlenden Abhängigkeiten aufgelöst werden können.

root@localhost:~# chroot chroot_squeeze/ /bin/bash
root@localhost:/# cd ~
root@localhost:~# mkdir icinga ; cd icinga
root@localhost:~/icinga# apt-get build-dep icinga
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
....

Bei diesem Durchlauf sollten keine Fehler bzgl. Abhängigkeiten auftreten. Anschließend kann der Source-Eintrag in der /etc/apt/sources.list auf testing, unstable oder experimental geändert werden, je nachdem aus welcher Quelle man ein Paket benötigt. Anschließend erneut apt-get build-dep ausführen. Wenn hier Abhängigkeitsprobleme auftreten muss versucht werden diese Aufzulösen. In einigen Fällen kann es bedeuten, dass man zunächst andere Pakete backporten muss, damit die Abhängigkeiten der neuen Version stimmen. In unserem Beispiel von Icinga ist das jedoch nicht der Fall.
Es werden nun die Quellen mittels apt-get source icinga geholt und im Anschluss die Version mittels dch -v angepasst. Hierbei sollte man die Versionierung nehmen, wie sie auch beim Backports.org Projekt genutzt wird (paketname-1.0.2-2~xyz60+1 – genaueres ist aus backports.org zu entnehmen).

root@localhost:~/icinga# vi /etc/apt/sources.list
root@localhost:~/icinga# apt-get update
root@localhost:~/icinga# apt-get build-dep icinga
...
root@localhost:~/icinga# apt-get install devscripts #hier ist dch enthalten
root@localhost:~/icinga# cd icinga-1.4.1
root@localhost:~/icinga/icinga-1.4.1# dch --bpo

Nun öffnet sich ein Editor, der einem gleich die changelog Datei anbietet. Hier sollten noch Name und Email-Adresse angepasst werden und ggf. noch die Distribution (squeeze-backports, squeeze-backports-netways ..)
Nach dem Speichern kann das Paket mittels dpkg-buildpackage gebaut werden. Es kann sein, dass hier ebenfalls noch einmal Abhängigkeiten bemängelt werden, die man anschließend versuchen müsste aufzulösen, was jedoch aktuell und in unserem Beispiel nicht der Fall sein sollte.

root@localhost:~/icinga/icinga-1.4.1# dpkg-buildpackage
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
...

Ist der Build-Prozess erfolgreich durchgelaufen, liegen im übergeordneten Ordner die fertigen Debian-Pakete inklusive Quellpakete, welche dann in ein eigenes Repository hochgeladen werden können (bspw reprepro).
Ich möchte noch einmal darauf hinweisen, dass es unter unglücklichen Umständen (sehr große Versionssprünge und Abhängigkeitsprobleme) eine etwas umfangreicheres Unterfangen sein kann, ein Paket zurückzuportieren. Jedoch erntet man dafür die Vorteile und kann seine Ergebnisse mit anderen teilen.

Debian Web-Updateverwaltung mit Updian

Wer kennt das nicht: Man betreibt viele Server oder virtuelle Maschinen und immer wieder purzeln Updates herein, welche man dann per Hand einspielen darf. Dafür gibt es viele Lösungen, die einem die händische Arbeit abnehmen. Heute möchte ich gern eine auf Debian-Systeme zugeschnittene Variante vorstellen.
Es handelt sich dabei um die Software Updian, ein kleines Tool, welches in PHP geschrieben wurde.
Das Grundprinzip ist schnell erklärt. Updian prüft via SSH die Server, welche es in seiner Liste vorfindet, ob Updates über apt-get verfügbar sind. Dabei wird im Vorfeld die Paketliste aktualisiert. Das Ergebnis wird im Webfrontend dargestellt und man kann selektiv Server zu einer Update-Queue hinzufügen, welche dann abgearbeitet wird. Alle Operationsschritte, also das Sammeln der Informationen, ob Updates verfügbar sind und das Abarbeiten der Queue werden über einen eigenen Cronjob ausgeführt.
Zusätzlich bietet Updian eine “Multi-SSH” Funktion, welche es erlaubt einen Befehl auf allen Systemen auszuführen.
Wenn der Benutzer es möchte, dann kann Updian auch eine E-Mail versenden, wenn es bei einem Prüfungsdurchlauf feststellt, dass Updates verfügbar sind.
Aber kommen wir nun zur Einrichtung von Updian:
Updian ist recht genügsam und es benötigt lediglich die Pakete php5, php5-cli und einen Webserver, der PHP unterstützt.
root@localhost:~# apt-get install apache2 php5 php5-cli
Die Installation von Updian selbst ist relativ unspektakulär. Auf der Projektseite findet man ein Debian-Paket vor, von dem ich aber auf Grund des Alters abrate (seit 2009 wurden keine Änderungen mehr an der Software getätigt). Statt dessen empfehle ich das .tar.gz-File herunterzuladen und im DocumentRoot vom Apache zu entpacken.
root@localhost:/var/www# wget http://www.robhost.de/updian/updian_v0.2.tar.gz
root@localhost:/var/www# tar xvfz updian_v02.tar.gz

Nach dem Entpacken sollte ein Ordner “updian” vorhanden sein, indem alle Files liegen. Diesen Ordner sollte man dem Benutzer www-data zuordnen, da Updian in dem Ordner selbst Schreibrechte benötigt.
root@localhost:/var/www# chown -R www-data updian/
Updian bietet eine eigene Konfigurationsdatei (config.php), welche man seinen Wünschen anpassen kann.
Im nächsten Schritt wird ein Benutzer angelegt, welcher die Überprüfung der Systeme durchführt, quasi mit dem der Cronjob ausgeführt wird.
root@localhost:/var/www# adduser updian
Lege Benutzer »updian« an ...
.
.
Geben Sie ein neues UNIX-Passwort ein:
.
.
root@localhost:/var/www#

Anschließend benötigen wir einen SSH-Key, den wir auf den Systemen verteilen können, damit sich Updian ohne Passwortabfrage verbinden kann. Bei der Frage nach einem Kennwort oder Passphrase bitte nur die Entertaste drücken, da wir diesen nicht gebrauchen können.

root@localhost:/var/www# su - updian
updian@localhost:~# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/updian/.ssh/id_dsa): [ENTER]
Created directory '/home/updian/.ssh'.
Enter passphrase (empty for no passphrase): [ENTER]
Enter same passphrase again: [ENTER]
Your identification has been saved in /home/updian/.ssh/id_dsa.
Your public key has been saved in /home/updian/.ssh/id_dsa.pub.
The key fingerprint is:
00:00:00:00:00:01:00:10:00:00:00:a0:00:00:00:00 updian@localhost
The key's randomart image is:
+--[ DSA 1024]----+
| ..oooEoo|

Damit unsere Systeme den Key auch kennen, muss er noch kopiert werden. Dies geht am Besten auf folgendem Wege:
updian@localhost:~# ssh-copy-id -i ~/.ssh/id_dsa.pub root@remoteserver

Damit regelämßig die Queue abgearbeitet wird und die Überprüfung auf Updates statt findet, müssen noch die entsprechenden Cronjobs angelegt werden. Hierbei empfiehlt es sich die datei /etc/crontab zu bearbeiten und folgende Zeilen hinzuzufügen:
0 8 * * * updian php /var/www/updian/cron_collect.php > /dev/null 2>&1
0 9 * * * updian php /var/www/updian/cron_updates.php > /dev/null 2>&1

In dem genutzten Beispiel wird täglich um 8 Uhr überprüft, ob Updates vorhanden sind und täglich 9 Uhr die Queue abgearbeitet.
Jetzt kann man Updian bekannt geben, welche Server es überprüfen soll. Das geht ganz einfach über das Web-GUI unter dem Punkt “Servers”, dazu ein Bild:

Nun überprüft Updian im festgelegten Intervall (Cronjob) ob Updates verfügbar sind und benachrichtigt einen, sofern man dies auch eingestellt hat.
Wenn Updian feststellt, dass es Updates hat, so zeigt es das in der Startseite “Home” an, wo man auch die Möglichkeit hat, einzelne oder alle Server zur Update-Queue hinzuzufügen. Mit einem Klick auf den Servernamen kann man einsehen welche Pakete in einer neuen Version vorliegen.

Ein wichtiger Hinweis noch zum Schluss! Der Entwickler stuft Updian noch als Beta ein und weist auch darauf explizit hin. Bisher konnten wir im alltäglichen Betrieb keine Fehler erkennen und es hat sich in der Praxis bei vielen Systemen bewährt.

Druckauftrag an zwei Drucker senden

Gelegentlich kommt es vor, dass man vor der Aufgabe steht mehrere Dokumente in doppelter Ausführung zu drucken und das am besten noch in einer farbigen und in einer monochromen Ausgabe. Oft bedeutet das viel manuelle Arbeit, da jeweils der Druckauftrag für die farbige Fassung und für die schwarz/weiße gestartet werden muss.
Hierfür gibt es jedoch Abhilfe und verschiedene Lösungsansätze. Wer schon nach Software gesucht hat, welche das Verteilen eines Druckauftrages an zwei Drucker realisieren kann, ist bestimmt auf das Programm PrintMulti gestoßen. PrintMulti ist ein sehr mächtiges Tool, man hat viele Einstellungsmöglichkeiten und ist für Clientbetriebssysteme kostenfrei erhältlich, jedoch ist der Konfigurationsaufwand nicht ohne. Deswegen möchte ich hier eine Alternative vorstellen welche aus einer Kombination von Foxit-PDF Reader, CutePDF und einem AutoIT 3 Skript besteht.
Grundlage dafür bot mir aus dem AutoIT Forum ein Beitrag mit Codebeispiel, der schon fast dem entsprach, was ich in die Tat umsetzen zu versuchte. Die Funktionsweise ist schnell und einfach erklärt.
Es wird das zu druckende Dokument als PDF mittels CutePDF (oder anderen PDF-Exporten) ausgegeben und an einen bestimmten Ort abgelegt. Das AutoIT Skript schaut nach, ob neue Dateien vorhanden sind, wenn ja werden diese in einen Archivorder verschoben und umbenannt (aktuelles Datum+Uhrzeit) und im Anschluss mit FoxitPDF der Druckauftrag für beide Drucker gestartet. Zwar ist dies nicht die eleganteste Lösung, jedoch funktioniert sie in der Praxis recht gut und hat einen geringeren Einrichtungsaufwand als PrintMulti. Im Anschluss noch der Quelltext des AutoIT Skripts:

$ordner = "C:\PDFs\"
$archiv = "C:\druck\"
$foxit = "C:\Programme\Foxit Software\Foxit Reader\Foxit Reader.exe"
$drucker1 = "Drucker 1"
$drucker2 = "Drucker 2"
While 1
  Sleep(1000)
  $file = FileFindFirstFile($ordner & "*.pdf")
  If $file <> -1 Then Print()
  FileClose($file)
WEnd
Func Print()
While 1
  $pdffile = FileFindNextFile($file)
  $neuname = @YEAR & @MON & @MDAY & @HOUR & @MIN & @SEC & @MSEC
  If @error Then ExitLoop
    FileMove($ordner & $pdffile, $archiv & $neuname & ".pdf")
    While 1
      Sleep(100)
      If FileExists($archiv & $neuname & ".pdf") Then
    ExitLoop
  EndIf
WEnd
RunWait('"' & $foxit & '" /t "' & $archiv & $neuname & '.pdf" $drucker1')
RunWait('"' & $foxit & '" /t "' & $archiv & $neuname & '.pdf" $drucker2')
WEnd
EndFunc ;==>Print

In den Variablen $drucker1 und $drucker2 kann man die Druckernamen, welche auf dem System vorhanden sind definieren. Natürlich kann man auch die Drucker selber umbenennen. Wichtig hierbei ist, dass die Drucker direkt von dem Client angesprochen werden und nicht über eine Samba Freigabe. Die Ordner „druck“ und „PDFs“ müssen manuell angelegt werden und natürlich schreibende sowie auch lesende Zugriffsrechte für die jeweiligen Nutzer haben.
(Picture by glasseyes view)
Edit TA (13.12.2017):
@Sascha hat in den Kommentaren das Skript hergenommen, aktualisiert und um eine Funktion erweitert: Fächerauswahl!
Unbedingter Lesebefehl!