Archiv Mai 2014

Mittwoch, 28. Mai 2014

AirPrint mit einem HP LaserJet 1300 auf einem Linux-Server aktivieren

Heute habe ich den Linux-Server in meinem Heimnetzwerk so konfiguriert, dass der dort per USB angeschlossene HP LaserJet 1300 auch von iOS-Geräten (iPhone und iPad) mittels AirPrint angesteuert werden kann.

Dies stellt sich heutzutage, anno 2014, als ein äusserst simples Unterfangen heraus:

CUPS installieren

Zuerst installiert man auf dem Server CUPS, das Common UNIX Printing System, welches von Apple gehegt und gepflegt wird. In meinem Fall hat dieses Drucksystem lprng ersetzt, welches automatisch deinstalliert wird:

# apt-get install cups

cups Web-Oberfläche freigeben

In /etc/cups/cupsd.conf sind in allen Location-Elementen (merke: CUPS verwendet Apache als Web-Frontend) die IPs des lokalen Netzwerks für erlaubte Zugriffe freizugeben:

...
Listen *:631
...
DefaultAuthType BasicDigest
...
<Location />
  Order allow,deny
  Allow From 10.0.10.0/24
</Location>
...
<Location /admin>
  Order allow,deny
  Allow From 10.0.10.0/24
</Location>
...

DefaultAuthType BasicDigest habe ich von Basic auf Digest umgestellt, damit ich das Passwort meines sudo-befähigten Benutzers nicht im Klartext über das Netzwerk gesendet wird. Damit man sich nach dieser Konfigurationsanpassung einloggen kann, muss man zuerst noch einen entsprechenden Benutzer erstellen:

# lppasswd -a <username>
Enter password: ********
Enter password again: ********

Eigener Benutzer der Gruppe lpadmin hinzufügen

Damit ich CUPS über die Web-Oberfläche administrieren kann, habe ich meinen persönlichen Benutzernamen zusätzlich der lokalen Gruppe lpadmin zugewiesen:

# usermod -aG lpadmin <username>

CUPS LPD-Druckserver einrichten

Obwohl heute IPP das Mass aller (Druck)dinge ist, verwende ich für Mac OS X- und Windows-Clients weiterhin das LPR/LPD-Druckprotokoll, weil es so simpel gestrickt und kaum fehleranfällig ist. Da CUPS aber lprng deinstalliert hat, muss in /etc/inetd.conf folgende Zeile eingefügt werden, welche den CUPS-eigenen LPD-Server aktiviert:

...
printer stream tcp nowait lp /usr/lib/cups/daemon/cups-lpd cups-lpd -o document-format=application/octet-stream

inetd startet man unter Debian folgendermassen neu:

# /etc/init.d/openbsd-inetd restart

Drucker einrichten und konfigurieren

Über die Web-Oberfläche, welche man unter http://localhost:631 erreicht (respektive über http://10.0.10.10:631) richtet man sich mit dem Installationsassistenten den USB-Drucker ein. Bei mir wurde das Gerät an der USB-Schnittstelle problemlos erkannt und auch entsprechende HP-Treiber angeboten.

WICHTIG: Ich hatte erhebliche Probleme mit dem Postscript-Druckertreiber (der HP LaserJet 1300 kann Postscript 2 emulieren): Jeder zweite Druckauftrag — egal ob von Mac oder vom iPad — blockierte den Drucker entweder oder liess ihn eine fast leere Seite mit der Fehlermeldung „Offending Command“ ausdrucken. Doch sobald ich den Drucker auf den Sample monochrome PCL XL/PCL 6 driver umgestellt hatte, funktionierte die Druckerei tadellos. In diesem Fall ist aber darauf zu achten, dass man unter Mac OS X ebenfalls mit dem PCL-Druckertreiber druckt, damit man dem CUPS-Druckserver die Umwandlung von PostScript zu PCL erspart.

Fertig!

Obwohl ältere AirPrint-Installationsanleitungen im Internet die Sysadmins nun auch noch auffordern, Avahi zu installieren (war bei mir schon vor dieser Neukonfiguration des Drucksystems auf dem Server aktiv) und mittels des Scripts airprint-generate.py einen Bonjour-Service anzukündigen, funktionierte die Anpreisung mit CUPS 1.7.2-3 ohne irgendwelche Konfigurationsanpassungen.

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Mai 2014

Einem mit puPHPet aufgesetztem Vagrant schreibenden Zugriff auf das synchronisierte wwwroot des Host-Systems geben

Das Web ist voll von Diskussionen zu diesem Thema, und einige Tipps erfordern zeitintensive Eingriffe in die Konfiguration:

Folgende Konfigurationsanpassung in der Vagrantfile-Konfigurationsdatei hat bei mir das Problem gelöst, dass Apache im VMBox-Container nicht in das synchronisierte wwwroot auf meinem Mac OS X-Host schreiben konnte:

...
data['vm']['synced_folder'].each do |i, folder|
    if folder['source'] != '' && folder['target'] != ''
      nfs = (folder['nfs'] == "true") ? "nfs" : nil
      if nfs == "nfs"
        config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{i}", type: nfs
      else
        config.vm.synced_folder "#{folder['source']}", "#{folder['target']}", id: "#{i}", type: nfs,
          group: 'www-data', user: 'www-data', mount_options: ["dmode=777", "fmode=777"]
      end
    end
  end
...

Mit dem Parameter mount_options: ["dmode=777", "fmode=777"] schreiben die Web-Applikationen ihre Cache-Dateien munter und fröhlich in das wwwroot des Host-Systems.

Und ja, mir ist ehrlich gesagt schnurz, wenn die Entwickler ideologisch-religiöse Gründe vorbringen, wieso dies eine ganz, ganz schlechte Idee ist … ich verwende Vagrant, um genau solchen Konfigurationsalpträume aus dem Weg zu gehen und innert Minuten auf all meinen Entwicklungssystemen eine homogene Entwicklungsumgebung zu haben.

Etwas gutes hatten die Probleme aber: Ich habe eine meiner Web-Applikationen so angepasst, dass sie nun beim Starten auch prüft, ob sie überhaupt Schreibberechtigung auf das Cache-Verzeichnis hat.

Labels: Uncategorized

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Mai 2014

lftp mit Zertifikatsproblemen

Wenn lftp auf Grund von Zertifikatsproblemen bockt …

Certificate verification: subjectAltName does not match »domain.tld«

… wechselt man folgendermassen auf unsichere FTP-Verbindungen:

$ lftp -e 'set ftp:ssl-allow off; cd public_html; put index.php; bye' www.domain.tld

Via: Lftp Fatal Error: Certificate Verification: Not Trusted

Tags: , , ,
Labels: Linux

Keine Kommentare | neuen Kommentar verfassen

Sonntag, 25. Mai 2014

curlftpfs unter Mac OS X

Ergänzungen meiner IT-Installation machten es kürzlich nötig, dass ich neu auch unter Mac OS X curlftpfs einsetze, um per FTP von bestimmten Web-Sites Sicherheitskopien anzufertigen (Stichwort: Vagrant und puPHPet, dank an Christian für die „Erleuchtung“!)

Entweder hat sich curlftpfs in der Zwischenzeit weiterentwickelt, oder unter Mac OS X läuft der „Karren“ etwas anders. Auf jeden Fall habe ich bei der Adaptierung meiner Linux-Scripte unter Mac OS X folgendes gelernt:

MacPorts

curlftpfs installiert man sich folgendermassen:

# port install curlftpfs

Wenn man curlftpfs dann zum ersten Mal ausführt, warnt einem Mac OS X (hier: 10.9 Mavericks), dass man eine Kernelextension aktiviert, welche von einem unbekannte Entwickler kompiliert wurde. Henusode … (NSA lässt grüssen). Die Warnung ist seither nie mehr aufgetaucht; ich hoffe, dass dies auch nach einem Reboot so bleibt.

Geduldiges mounten

In Tests hat sich herausgestellt, das das Mounten von FTP-Volumen längert dauert als unter Linux. Meinem Script habe ich deshalb folgendermassen Geduld beigebracht:

...
MAXIMUMITERATIONS=5000
...
TIME=$(date +%H:%M:%S)
echo -n "Checking whether mountpoint is populated ($TIME): "

COUNTER=0
while [ ! -d "$SOURCE" ]
do
	let COUNTER=COUNTER+1
	echo -n "."
	
	if [ "$COUNTER" -eq "$MAXIMUMITERATIONS" ]
	then
		echo "Mountpoint still not available after $COUNTER iterations. Aborting."
		exit 1
	fi
done
...

In der Variable $SOURCE ist der Pfad zu einem auf dem FTP-Server vorhandenen Unterordner gespeichert. Sobald bash meldet, dass dieser nun verfügbar ist, kann ich mit den Kopieraktionen beginnen.

Zugriff verweigert

Bei den Tests traf ich auch auf ein Berechtigungsproblem: Manchmal wurde rsync beim Traversieren von FTP-Ordnerstrukturen der Zugriff verweigert. Nach einigem Pröbeln realisierte ich, dass einige Ordner auf den FTP-Servern das Execution-Bit nur für den Owner gesetzt hatten, nicht aber für die Gruppe oder gar Dritte. In einem Fall passte ich die Berechtigungen über den FTP-Client meiner Wahl an, in einem anderen Fall war ich mir todsicher, dass ich allen Serverbenutzern definitiv keine Berechtigung zum Lesen aller meiner Dateien geben wollte. Was nun?

Folgende Option verhindert, dass curlftpfs respektive FUSE bei FTP-Verbindungen Berechtigungschecks durchführen (dies ist hier Aufgabe des FTP-Servers — gibt dieser Zugriff auf eine Datei, hat definitiv schon eine zuverlässige Authentifizierung und Authorisierung stattgefunden):

$ curlftpfs -o defer_permissions ...

Zeichensalat

In meinem älteren Blog-Artikel zu curlftpfs habe ich gezeigt, wie der Zeichensatzproblematik unter Linux begegnen kann. Unter Mac OS X klappt dies so nicht. Stattdessen sind folgende Werte an curlftpfs zu übergeben:

$ curlftpfs -o modules=iconv,from_code=latin1

Quelle: International characters (e.g. Swedish åäö) in remote file system folder names makes Finder hang #71

Den Ausgabezeichensatz finden FUSE respektive curlftpfs offenbar selber heraus.

Dem Parameter from_code ist natürlich der Zeichensatz des FTP-Servers mitzugeben. Es sind alle iconv bekannten Zeichensätze konfigurierbar:

$ iconv -l

In Verbindung mit rsync führt dies aber zum unerwünschten Verhalten, dass Verzeichnisse und Dateien mit Umlauten im Namen bei jeder Synchronisation erneut heruntergeladen werden (ich bin unschuldig, das war ein anderer Benutzer des Servers!).

Tags: , , , , ,
Labels: Apple, Linux

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 20. Mai 2014

Unter DD-WRT DNS-Server per DHCP an die Clients weitergeben

Dies erledigt man folgendermassen:

  1. Services
  2. Services
  3. DNSMasq
  4. Additional DNSMasq options
dhcp-option=6, 10.0.1.10, 195.186.4.111

DD-WRT - Services - Services - DNSMasq

Quelle: ISP DNS-Servers

10.0.1.10 ist mein lokaler DNS-Server, welche bestimmte Adressen intern anders auflöst als aus dem Internet. Bei 195.186.4.111 handelt es sich um einen DNS-Server von Swisscom (ex-Bluewin) und ist als Fallback gedacht, wenn 10.0.1.10 nicht reagieren sollte (10.0.1.10 leitet DNS-Anfragen, für welche er keine Authorität hat, transparent an denselben DNS-Server weiter).

Tags: , , , ,
Labels: IT

Keine Kommentare | neuen Kommentar verfassen

Dienstag, 20. Mai 2014

Die Tagesanzeiger-Paywall (eher: das Lehmmäuerchen) umgehen

In den letzten Monaten haben sich die Paywalls der traditionellen Zeitungen im Internet gehäuft: Die New York Times macht, die NZZ auch – und seit kurzem auch der Tagesanzeiger. Aus meiner Sicht war es auch wirklich an der Zeit, dass die Medienhäuser den von ihnen generierten Mehrwert entsprechend schützen und von den Konsumenten vergüten lassen. So wie man das seit Jahrhunderten in der Printpresse auch macht (wobei man anmerken muss, dass bei der Printpresse die Mehrheit der Einnahmen aus der Printwerbung stammen).

Doch wenn man eine Internet-Paywall aufbaut, welche angeblich drei Millionen Schweizer Franken gekostet haben soll, sollte sie dann aber auch der Chinesischen Mauer entsprechen, und nicht einem Lehmmäuerchen oder einem morschen Lattenzaun.

Nachdem man nämlich die maximale Zahl an kostenlosen Tagi-Artikeln gelesen hat, kriegt man die Artikelseiten weiterhin mit dem kompletten Inhalt ausgeliefert. Nach kurzer (oder längerer Ladezeit) wird mit CSS ein halbtransparenter Overlay eingeblendet, welcher den Internetbenutzer auffordert, ein Abonnement abzuschliessen.

Diese „CSS-Wall“ umgeht man unter Google Chrome folgendermassen:

  1. Stylebot herunterladen und installieren
  2. Rechtsklick auf CSS-Icon
  3. Optionen
  4. Stylebot Options
  5. Styles
  6. Edit Global Stylesheet

Dort gibt man ein:

div#overlay_wrap {
	display: none;
}

Abspeichern, Browser neu starten – et voilà!

Sollte diese Massnahme aus irgendeinem Grund nicht klappen, kann man Stylebot immer noch mittels Druck auf Alt+M aktivieren, auf die dunkle Overlay-Fläche klicken (#overlay_wrap) und im Abschnitt „Layout & Visibility“ den Wert „Visibilty“ auf „Hide“ setzen.

Tags: , , , , , ,
Labels: Web

18 Kommentare | neuen Kommentar verfassen

Montag, 12. Mai 2014

„Delete VPN“-Button fehlt unter iOS 7

Da ich heute erfahren habe, dass ich mit iOS eine PPTP-VPN-Verbindung zu meinen DD-WRT-Router herstellen und mich und meine Daten so in öffentliche Funknetzwerken schützen kann, habe ich mich hinter die Konfiguration meiner drei iOS-Geräte gemacht.

Auf dem kürzlich bei einer Mitarbeiteraktion erstandenen iPad 4 64GB WiFi + 3G war unter Settings > General > VPN bereits ein VPN-Profil meiner Alma Mater erfasst (Ursache: Ich habe das Backup meines iPad 1 auf das neue iPad geladen, welches ich während meiner Studienzeit verwendet habe). Dummerweise fehlte dem Cisco IPSec-Profil der Delete VPN-Knopf zuunterst in den Konfigurationseinstellungen (via Tastendruck auf das runde i-Symbol). Was zum Teufel … Wie kriege ich dieses längst nicht mehr genutzte VPN-Profil von meinem iPad weg?

Einige Minuten Internetrecherchen später hatte ich die Lösung meines Problems gefunden: „Can’t Delete VPN Profile“ Fix

Kurz zusammengefasst geht es darum, Benutzernamen, Serveradresse, Secret, Passwort, sonstige Formularfelder sowie den VPN-Typ mit Phantasiewerten anzupassen und das Profil zu speichern. Beim nächsten Aufruf der Konfigurationseinstellungen strahlte mir der Delete VPN-Knopf dann wie gewünscht entgegen — und das Profil lag innert Sekundenbruchteilen im digitalen Nirvana.

Tags: , , , , , , , , ,
Labels: Apple

Keine Kommentare | neuen Kommentar verfassen