Smartphone-Recycling: Alte Geräte sinnvoll einsetzen

Smartphone-Recycling: Alte Geräte sinnvoll einsetzen

19.03.2017 | 16:09 Uhr | Hermann Apfelböck

 

Nicht wegwerfen! Alte Smartphones können noch sinnvoll genutzt werden.

VergrößernNicht wegwerfen! Alte Smartphones können noch sinnvoll genutzt werden.

© Maksym Yemelyanov – Fotolia

Smartphones sind bekanntlich ein kompletter Mini-PC, Hardware-technisch mit leistungsstarken Platinen-PCs zu vergleichen, dabei kompletter ausgestattet. Ausrangierte Smartphones sind daher dankbare Kandidaten fürs Re-und Upcycling.

Das Display hat einen Sprung, der Akku ist hinüber, oder der Arbeitgeber hat ein neues Modell spendiert: Selbst bei Pragmatikern, die nicht an der hochansteckenden Volkskrankheit Neophilie leiden, landen Smartphones irgendwann in der Schublade „Elektroschrott“. Dabei ist kaum eine andere Geräteklasse so gut geeignet, neue Aufgaben zu übernehmen. Bastler, die gerade überlegen, sich einen Platinenrechner, ein Mobilradio, eine IP-Kamera (und, und, und …) anzuschaffen, sollten erst das alte Handy aus der Schublade holen. CPU-Leistung, RAM und vor allem die Peripherie-Ausstattung sind exzellent, lediglich an Anschlussports mangelt es.

Siehe auch: Das iPhone als Wandgadget einsetzen 

Andere Geräte ins Netz bringen

Shopping Cart Icon Samsung Galaxy S5 bei Amazon ansehen

Auch ältere Android-Smartphones bieten standardmäßig Netzwerkfunktionen, die sie zumindest zur Behelfsbrücke ins Internet befähigen. Hat ein PC oder ein Notebook im Heimnetz keinen funktionierenden WLAN-Adapter und keine Kabelverbindung, hilft das Smartphone aus: Das Smartphone muss selbst mit dem WLAN verbunden sein und über sein USB-Kabel mit dem Rechner. Sobald unter „Verbindungen -> Weitere

Einstellungen -> Tethering […] -> USB-Tethering“ aktiviert ist, erhält der Rechner eine „Kabelnetzverbindung“ und kann ins Internet.

Eine etwas aufwendigere Lösung macht das ausgediente Handy zum mobilen WLAN-Hotspot für Notebooks oder Tablets, die kein Mobilfunknetz besitzen. Dazu muss das Handy über „Mobile Daten“ im Netz sein und dieses über „Verbindungen -> Weitere Einstellungen -> Tethering […] -> Mobiler WLAN-Hotspot“ als WLAN anbieten. Damit können sich dann andere Geräte wie gewohnt verbinden. Eine solche Lösung lässt sich etwa dauerhaft im Auto realisieren, wenn Sie das Handy mit einem Ladeadapter mit Strom versorgen (ab circa zehn Euro). Aufwendiger ist dieses Szenario aber auch deshalb, weil das recycelte Smartphone eine aktive SIM-Karte benötigt.

Apps und Server-Apps für einzelne Funktionen

Mit Kamera, Mikrofon, Audio Line Out, GPS, Bewegungssensoren, WLAN, Bluetooth und Mobilfunknetzen, USB-Zugriff (OTG), Hotspot-Funktion sowie DLNA-Medien-Streaming („Geräte in der Nähe“) haben auch ältere Android-Smartphones viel Potenzial an Bord. Manche Apps nutzen lediglich diese Gerätefunktionen mehr oder weniger kreativ, andere fügen einen kleinen Server hinzu, um die gewünschte Komponente über den Browser oder eine andere Netz-Software auf anderen Rechnern anzubieten. Hier nur wenige typische Beispiele:

<![if !supportLists]>·         <![endif]>Apps wie Radio FM oder Tune In ersetzen ein Radio. Sie brauchen nur WLAN und – sehr zu empfehlen – ein direkt am Klinkenstecker angeschlossenes oder per Bluetooth empfangendes Lautsprechersystem (je nach Anspruch ab zehn und bis 300 Euro).

<![if !supportLists]>·         <![endif]>Die App Cerberus nutzt den GPS-Chip des Smartphones und dient eigentlich dazu, ein verlorenes oder gestohlenes Smartphone zu orten. Auf einem ausgedienten Android-Handy, das Sie im Auto deponieren und dort per Ladeadapter mit Strom versorgen, dient es zum Auffinden des Fahrzeugs.

<![if !supportLists]>·         <![endif]>Die App Mobile Alarmanlage macht aus dem Smartphone eine simple Alarmanlage. Die kostenlose Version schaltet fast alle interessantesten Optionen ab, daher sind bei Interesse die 0,99 Cent unvermeidlich. Die App schaltet auf Wunsch einzelne oder sämtliche Komponenten scharf (Mikro, Kamera, Bewegungssensor, Ladekabel) und verschickt bei einem Ereignis SMS oder Mail. Die laute Alarmfunktion eignet sich eher für Scherzaktionen.

<![if !supportLists]>·         <![endif]>Die Android-App Baby Monitor nutzt das Smartphone-Mikrofon zur Überwachung des Kinderzimmers. Ein einstellbarer „Sensity Level“ definiert, ab welcher Lautstärke Ihre Telefonnummer angerufen werden soll.

<![if !supportLists]>·         <![endif]>Eine simple, aber nützliche Monofunktionalisierung alter Handys ist der Einsatz als Fernsteuerung für Smart-TVs oder Mediencenter. In beiden Fällen ist es wichtig, dass das zu steuernde Gerät über den Router stets eine feste IP-Adresse erhält. Steuerungs-Apps für Fernseher bietet Google Play zuhauf, am besten grenzen Sie die Suche gleich auf den TV-Hersteller ein (etwa „Samsung“ oder „LG“). Für das Mediencenter XBMC/Kodi sind die Apps Kore , Yatse und XBMC remote zu empfehlen.

Zwei Szenarien in der Praxis

Android-Apps für Internetradio gibt es zuhauf. Zusätzlich brauchen Sie nur noch ein kleines Lautsprechersystem für zehn Euro aufwärts.

VergrößernAndroid-Apps für Internetradio gibt es zuhauf. Zusätzlich brauchen Sie nur noch ein kleines Lautsprechersystem für zehn Euro aufwärts.

Das Handy als Kamera: Ein altes Smartphone bringt alles mit, um als IP-Webcam oder Überwachungskamera zu arbeiten. Das einzige technische Problem ist die Fixierung des Handys an der gewünschten Position; die sollte für einen längeren Einsatz zudem in der Nähe einer Steckdose liegen. Der Rest ist einfach: Die Android-App IP Webcam ist schnell installiert. In den App-Einstellungen aktivieren Sie „Local broadcasting“ und den untersten Punkt „Starte Server“. Schon geht’s los. Wenn Sie die IP-Adresse des Handys nicht kennen, hilft die App mit dem Punkt „Wie verbinde ich mich?“. Jeder Browser im gleichen Netz zeigt den „Android Webcam Server“ nach Eingabe der IP in die Adresszeile. Der Live-Stream erscheint, sobald Sie hier einen „Video Renderer“ anklicken. Über „Aufnahme Kontrolle“ lässt sich der Stream aufzeichnen, der dann am Handy unter „/ipwebcam_videos“ abgelegt wird. Einzelfotos speichern Sie am einfachsten gleich am PC mit „Foto Ausnahme“ und dann „Bild speichern unter“ im Browser. Die App bietet überdies zahlreiche Qualitäts-und Feineinstellungen.

Tipp: Funktionen von Android 6 nachrüsten 

Das Handy als Daten-und Medienserver: Um Audio-und Videodateien vom Handy zu streamen, brauchen Sie noch nicht mal eine spezielle App (wie BubbleUPnP). Nicht allzu alte Android-Smartphones zeigen unter „Verbindungen“ die Option „Geräte in der Nähe“. Es genügt diese zu aktivieren, und schon erscheint die Medienbibliothek auf den Rechnern und TV-Geräten im Netz – als UPnP-Medienbibliothek (PC) oder als „All Share“-Quelle (TV).

Wer das Smartphone zu einem echten NAS-Server ausbauen will, muss Kompromisse eingehen und einige technische Probleme lösen. Da der Verkehr über das Funknetz laufen muss, sollte das WLAN wenigstens stabil und schnell sein. Wir konnten einen Durchsatz von 40 bis 50 MBit/s erzielen, was sicher nicht schnell ist, aber für Streaming und Büro-Backups allemal ausreicht.

Damit wird das Handy zu einem kleinen PC und kann auch als Daten-Server genutzt werden.

VergrößernDamit wird das Handy zu einem kleinen PC und kann auch als Daten-Server genutzt werden.

Nächster Punkt ist der Speicherplatz: Ohne externe USB-Festplatte hätte der Smartphone-Server seinen Namen nicht verdient. Nun ist es zwar kein Problem, mit einem USB-OTG-Kabel (circa fünf Euro) eine USB-Festplatte anzuschließen. Wenn diese keine eigene Stromversorgung hat, müssen Sie jedoch ein USB-OTG-Y-Kabel (ab acht Euro) wählen.

Das Hauptproblem: Hängt eine Festplatte am Micro-USB-Adapter des Handys, kann das Smartphone nicht gleichzeitig laden. Damit wäre das Server-Projekt eigentlich begraben – es sei denn, Sie entschließen sich zu einem Upcycling mit geeigneter Investition:Multimedia-Docking-Stations insbesondere für Samsung-Smartphones (Produktbezeichnungen EDD-S20E und ähnlich) bieten USB-Anschlüsse, HDMI, Audioausgang plus Ladefunktion. Sie kosten 20 Euro aufwärts, Markenprodukte 45 bis 70 Euro. Achten Sie auf die angegebenen kompatiblen Smartphone-Modelle und darauf, dass Ladefunktion und USB-Anschluss gewährleistet sind.

Passende Apps gibt es in Menge: Servers Ultimate mit Servers Ultimate Pack B (für Samba), ferner Samba Droid bringen die Smartphone-Daten zu Linux-und Windows-Rechnern, fordern aber zu diesem Zweck ein gerootetes Android. Wem eine Weboberfläche für Up-und Downloads reicht, kommt ohne Rooten mit Droid over Wifi über die Runden.

 

DSL-Modem im Bridging-Modus betreiben

> Von wogri

Wir hören es fast jeden Tag in den Medien: Großflächige DDoS-Angriffe auf strategisch interessante Ziele im Internet. Bei DDoS-Angriffen haben Angreifer in der Regel private Geräte unter ihrer Kontrolle, ohne dass die Besitzer davon wissen.

Ein mögliches Angriffsziel ist hier der alte DSL-Router, dessen Hersteller schon Jahre kein Softwarupdate mehr ausliefert, und der vor Exploits nur so strotzt. Ein Angriff auf dieses Gerät bleibt unbemerkt, da es weiterhin seinen Dienst verrichtet und der Besitzer kein Fehlverhalten feststellen kann. Während einer DDoS-Attacke sendet das Gerät eine Sequenz von IP-Paketen, die dem privaten User wahrscheinlich nicht auffallen.

Dieser Artikel ist der erste Teil einer Serie aus vorerst zwei Artikeln[1]. Der vorliegende größere Teil beschreibt die Änderung der Router-Einstellungen und die Einrichtung eines Linux-Rechners mit Firewall. Der zweite Teil behandelt die Konfiguration von IPv6 mit DHCP und Firewall.

Wie kann ich mein DSL-Modem schützen?

Abgesehen von regelmäßigen Software-Updates gibt es noch eine mögliche Alternative: Das DSL-Modem vom Internet aus nicht ansprechbar zu machen. Das bedeutet, dass man dem Modem keine öffentliche IP-Adresse zuweist. Ohne öffentliche IP-Adresse ist jedoch keine Teilnahme am Internet möglich. Der Trick ist, das Modem in einen Bridging-Modus zu versetzen und die öffentliche IP-Adresse an einen Linux Software-Router zu vergeben.

Ein weiterer Vorteil dieses Modus ist, dass man frei aus den Netzwerkfähigkeiten von Linux schöpfen kann. VLANs, IPv6 Tunnel, Dynamisches DNS, IPSec, Split Horizon DNS – alles wird möglich. Es muss natürlich erwähnt werden, dass man damit eine Linux-Installation als Angriffsziel im Internet exponiert. Im Unterschied zu proprietären DSL-Boxen hat man hier jedoch selbst die Möglichkeit, das Gerät auf dem aktuellen Softwarestand zu halten, wie auch das Gerät mit Firewall-Regeln komplett von außen unzugänglich zu machen.

Bridging-Modus im DSL-Modem

Nicht jedes DSL-Modem unterstützt den Bridging-Modus. Um herauszufinden, ob ein DSL-Modem dazu fähig ist, muss man in der Konfigurationsoberfläche (oder im Manual) nachsehen. Bei meinem Zyxel-Modem war es glücklicherweise sehr einfach. Man kann ganz unkompliziert zwischen Routing und Bridging Mode umschalten.

Router-Konfiguration

WOLFGANG HENNERBICHLER

Router-Konfiguration

Wie man die jeweiligen DSL-Modems in den Bridging-Modus versetzt, ist im Handbuch der jeweiligen Hersteller nachzulesen. Nicht jedes Modem wird diesen Modus unterstützen.

Achtung: Sobald sich das Modem im Bridging-Modus befindet, ist es vorbei mit der Internet-Verbindung. Man möchte daher diesen Schritt daher gut vorbereiten und auf jeden Fall die Zugangsdaten zum DSL-Provider zur Hand haben, falls man doch wieder auf Routing umkonfigurieren möchte.

Was bedeutet Bridging-Modus?

Falls man bisher mit gebridgten Netzwerken nicht so viel zu tun hatte, ist der Bridging-Modus etwas schwer zu begreifen. Was hier passiert ist, dass das Modem etwaige PPPoE-Pakete direkt an die physische DSL-Schnittstelle weiterleitet. Das kann man mit einem WLAN Access Point vergleichen, der LAN-Pakete ins WLAN weiterleitet. Das Modem braucht nicht mal mehr eine IP-Adresse, um als DSL-Bridge zu fungieren. Ich empfehle dennoch, unbedingt eine lokale IP-Adresse auf dem LAN-Interface zu konfigurieren, damit das DSL-Modem nach wie vor über eine Administrations-Schnittstelle konfiguriert werden kann. Diese lokale IP-Adresse wird von der Linux Firewall geschützt und ist von außen nicht zugänglich, außer man befiehlt der Linux-Firewall explizit, Pakete an dieses Interface weiterzuleiten.

An welche IP-Adresse müssen PPPoE-Pakete geschickt werden?

Die genaue Erklärung findet man auf Wikipedia[2], die kurze Antwort hier: Man muss es nicht konfigurieren. PPPoE hat zwei Phasen. Zuerst die Discovery Phase (auch PADI genannt, steht für PPPoE Active Discovery Initiation) in der ein spezieller Ethernet Broadcast (an FF:FF:FF:FF:FF:FF) geschickt wird. Als Antwort erhält der Absender die MAC-Adresse des DSL-Modems. Ab diesem Zeitpunkt weiß der PPPoE-Client, an welche Ziel-MAC er die PPPoE-Pakete schicken soll.

Das Modem im Bridging-Modus nimmt die PPPoE-Pakete in Empfang und leitet sie an das DSL-Interface weiter. Aus diesem Grund braucht das DSL-Modem keine IP-Adresse im LAN, sobald es als Bridge funktioniert. Wie oben erwähnt empfehle ich dennoch, eine Management-IP auf das LAN-Interface des Modems zu konfigurieren.

Linux wird zum DSL-Router

Unterstützt das Modem den Bridging-Modus, braucht man noch einen Computer für die DSL-Einwahl. Ein Rasperry Pi mit Linux ist wahrscheinlich ausreichend dafür. Da der Pi seine Ethernet-Schnittstelle mit dem restlichen USB-Bus teilt, bevorzuge ich in meinem Beispiel eine virtuelle Maschine mit Debian Jessie, um die Netzwerk-Latenz für berufliche Videokonferenzen gering zu halten.

In diesem Tutorial probiere ich nicht nur, das Ding zum Laufen zu bringen, ich probiere auch, moderne Software dafür zu verwenden. Das war endlich ein Grund, mich zumindest etwas näher mit systemd zu beschäftigen und nftables zu verstehen.

systemd

Wie vorher erwähnt, verwende ich als PPPoE-Dialer und Firewall eine dezidierte virtuelle Maschine mit Debian. Um meine Skripte und Konfigurationsdateien etwas leserlicher zu gestalten, habe ich mir vorgenommen, die physischen Schnittstellen gleich vorneweg richtig zu benennen. Systemd hilft hier sehr, und es ist einfacher als jemals zuvor (ich denke hier an udev), physische Schnittstellen richtig zu benennen. Leider hat Debian Jessie noch nicht alle Features, die wir für unser Setup benötigen. Daher holen wir uns Systemd aus den Backports:

echo deb ftp.debian.org/debian jessie-backports main >> /etc/apt/sources.list
apt-get update
apt-get -t jessie-backports install "systemd"

Zuerst ist es notwendig, systemd-networkd zu aktivieren, um von den vielen Vorteilen der Netzwerkkonfiguration mit systemd zu profitieren: systemct enable systemd-networkd.service aktiviert den networkd. Um ein Interface namens lan als solches zu benennen, geht man nach /etc/systemd/network und erzeugt eine Datei namens 01-lan.link. Der Dateiname muss auf .link enden, und das 01 gibt die Reihenfolge in der Bootsequenz bekannt. Die Datei schaut bei mir folgendermaßen aus:

[Match]
MACAddress=52:54:00:c1:f8:1a
[Link]
Name=lan

Die IP-Adressen des Systems habe ich nicht altmodisch in /etc/network/interfaces konfiguriert, sondern auch mit systemd in der Datei /etc/systemd/network/lan.network:

[Match]
Name=lan
 
[Network]
Address=192.168.1.1/24
IPForward=yes

Dann selbiges auch noch mit dem Loopback-Interface in der Datei lo.network:

[Match]
Name=lo
 
[Network]
Address=127.0.0.1/8

PPPoE

PPPoE setzt ein paar Pakete voraus, die eventuell im System noch nicht vorinstalliert sind:

apt-get install pppd pppoeconf

Mit pppoeconf kann man die angesprochene Discovery anstoßen. Bevor wir die Discovery anstoßen, sollten wir aber die PPP-Parameter noch setzen. Zuerst tragen wir die Zugangsdaten zu unserem Provider in /etc/ppp/chap-secrets ein:

wogri@myprovider.com * my-secret-password *

Danach konfigurieren wir den pppd in /etc/ppp/peers/provider. Die Datei namens provider stellt den Default-Provider für pppd dar. Da die meisten User nur einen DSL-Provider haben, ist es praktisch diese Datei zu verwenden, da sonsten immer der Provider in den anschließenden Befehlen separat angegeben werden muss. Hier also die Konfiguration:

# Use Roaring Penguin's PPPoE implementation.
plugin rp-pppoe.so lan
 
# Login settigns.
user "wogri@myprovider.com&quot;
noauth
hide-password
 
# Connection settings.
persist
maxfail 0
holdoff 5
 
# LCP settings.
lcp-echo-interval 10
lcp-echo-failure 3
 
# PPPoE compliant settings.
noaccomp
default-asyncmap
mtu 1492
 
# IP settings.
noipdefault
defaultroute

Man beachte hier die MTU von 1492. Bei Ethernet ist der Default 1500. Das wird im weiteren Verlauf der Konfiguration noch wichtig (Stichwort MSS Clamping).

Mit pon sollte man nun eine Verbindung zum ISP aufbauen können. ip address show ppp0 sollte die verhandelte IPv4-Konfiguration zeigen.

PPP-Verbindung beim Booten aufbauen

Natürlich müssen wir sicherstellen, dass bei einem Neustart die PPP-Verbindung wieder zuverlässig aufgebaut wird. Dafür müssen wir systemd mitteilen, dass wir eine neuen Service haben:

cat <<EOF >/etc/systemd/system/pppoe.service
[Unit]
Description=PPPoE connection
After=network-online.target
 
[Service]
Type=oneshot
RemainAfterExit=true
ExecStart=/usr/bin/pon
ExecStop=/usr/bin/poff -a
 
[Install]
WantedBy=default.target
EOF
systemctl daemon-reload
systemctl enable pppoe.service
systemctl start pppoe.service

Routing

Das IPForward=yes in der systemd-networkd-Konfiguration erledigt das Setzen der bekannten ip_forwarding-Parameter, somit sollte ein manuelles Bearbeiten von sysctl.conf nicht notwendig sein.

Die Maschine sollte von nun an mit dem Internet verbunden sein. Was hier aber noch fehlt, ist das Masquerading. Da das interne Netzwerk mit privaten IP-Adressen betrieben wird, ist es notwendig, die private Quell-IP-Adresse der nach außen gerichteten Pakete zu verändern. Unter Linux wird diese Technik Masquerading genannt. Da dieses Tutorial neue Technologien verwendet, werde ich zuerst auf die Masquerading-Konfiguration von nftables eingehen, danach auch kurz iptables aufzeigen.

Firewall

Ziel dieses Tutorials ist es, die Angriffsfläche aufs Heimnetzwerk zu verkleinern. Daher konfigurieren wir eine Firewall, die per Default von außen keine Verbindungen erlaubt. Ich empfehle StrongSwan + IKEv2, sollte jemand das Bedürfnis haben, von außen auf sein Heimnetzwerk zugreifen zu wollen.

nftables

NFTables[3] ist die geplante Ablöse von IPTables. NFTables befindet sich bereits im Linux-Kernel seit Version 3.13. Ein schönes Tutorial über nftables[4] hat Martin Loschwitz im Linux-Magazin geschrieben. Mein Fazit zu nftables ist, dass es bereits ganz gut verwendbar ist, jedoch noch ein paar Features fehlen, bzw. teilweise die Syntax für mich nicht ganz verständlich ist. Fehlende Features für meine Anwendungsfälle sind:

  • mangelnde IPSec-Integration
  • teilweise inkonsistente Syntax der nft-Befehlszeile.
  • Spezial-Features wie MSS Clamping (mehr dazu später) sind noch nicht verfügbar.

Ich gehe davon aus, dass diese Probleme mit der Zeit gelöst werden.

Nun zur Installation: Das Userspace-Tool ist in Debian Jessie nur aus den Backports zu beziehen:

apt-get -t jessie-backports install "nftables"

Nftables kann man wie iptables mit einzelnen Befehlen betreiben oder aber über eine Datei, die atomar in den Kernel geladen (oder geändert) wird. Ich bevorzuge, eine Datei zu pflegen, die atomar in den Kernel geladen wird, ähnlich zum pf-System unter BSD. Eine weitere Eigenheit von nftables NAT ist, dass iptables NAT nicht geladen sein darf. Daher ist es erforderlich, das iptabes NAT-Modul zu entladen:

rmmod iptables_nat

Hier sieht man ein einfaches Beispiel, das nur ein Masquerading mit nftables macht und sinnvolle Chains für die weitere Verwendung angelegt hat:

#!/usr/sbin/nft -f
 
flush ruleset
 
table inet filter {
  chain input {
    type filter hook input priority 0;
    iifname lo accept
    iifname lan accept
    iifname ppp0 jump input_ppp0
    drop
  }
  chain input_ppp0 { # rules applicable to public interface
    ct state {established,related} counter accept
    ct state invalid counter drop
    log
    drop
  }
  chain ouput {
    type filter hook output priority 0;
    accept
  }
  chain forward {
    type filter hook forward priority 0;
    iifname ppp0 counter jump from_internet
    accept
  }
  chain from_internet {
    ct state {established,related} counter accept
    ct state invalid counter drop
    drop
  }
}
 
table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
  }
  chain postrouting {
    type nat hook postrouting priority 0;
    oifname ppp0 counter masquerade
  }
}

Mit diesem Regelwerk sollte die einfachste Variante von nft, nämlich ein simples NAT, erledigt sein. Wer ein Beispiel mit mehr Komplexität in seinen Regeln braucht, hier meine Konfiguration, inkl. IPv6:

#!/usr/sbin/nft -f
 
define server_net = 1.2.3.0/28
define my_phone = 192.168.1.100
 
# ipv6
define dovecot_ip6 = 2001:dead:beef:2::143
define server_net_ip6 = 2001:dead:beef::/64
 
flush ruleset
 
table inet filter {
  chain input {
    type filter hook input priority 0;
    iifname lo accept
    iifname lan accept
    iifname servlan accept
    iifname ipsec0 accept
    iifname ppp0 jump input_ppp0
    drop
  }
  chain input_ppp0 { # rules applicable to public interface
    ct state {established,related} counter accept
    ct state invalid counter drop
    ip6 nexthdr icmpv6 icmpv6 type echo-request limit rate 10/second counter accept
    ip6 nexthdr icmpv6 icmpv6 type {
      destination-unreachable, packet-too-big, time-exceeded, 
      parameter-problem, nd-router-advert, nd-neighbor-solicit, 
      nd-neighbor-advert } counter accept
    ip protocol icmp icmp type echo-request limit rate 10/second counter accept
    ip6 daddr fe80::/64 udp dport dhcpv6-client counter accept
    ip6 saddr $server_net_ip6 tcp dport {22} counter accept
    # letsencrypt
    ip saddr 0.0.0.0/0 tcp dport {80,443} counter accept
    ip6 saddr ::/0 tcp dport {80,443} counter accept
    # ipsec
    ip protocol esp accept
    ip saddr 0.0.0.0/0 udp dport {500,4500} counter accept
    log
    drop
  }
  chain ouput {
    type filter hook output priority 0;
    accept
  }
  chain forward {
    type filter hook forward priority 0;
    iifname ppp0 counter jump from_internet
  }
  chain from_internet {
    ct state {established,related} counter accept
    ct state invalid counter drop
    ip6 daddr $dovecot_ip6 jump to_dovecot
    log
    drop
  }
  chain to_dovecot {
    ip6 saddr $server_net_ip6 tcp dport {22} counter accept
  }
}
 
table ip nat {
  chain prerouting {
    type nat hook prerouting priority 0;
    iifname ppp0 counter jump dnat_from_internet 
  }
  chain dnat_from_internet {
    udp dport { sip, 16384-16400 } counter dnat $my_phone
  }
  chain postrouting {
    type nat hook postrouting priority 0;
    oifname ppp0 counter masquerade
  }
}

iptables

Wer sich nftables nicht antun möchte, kann das simple NAT mit IPv4 mit iptables folgendermaßen einrichten:

#!/bin/bash                                                                         
                                                                                    
iptables --flush                                                                    
iptables -t nat --flush                                                             
iptables -X                                                                         
                                                                                    
set -x                                                                              
iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE                                
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu 
iptables -A FORWARD -i ppp0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A INPUT -i ppp0 -m state --state RELATED,ESTABLISHED -j ACCEPT            
iptables -A INPUT -i ppp0 -j LOG                                                    
iptables -A INPUT -i ppp0 -j DROP                                                   
set +x                                                                              

Firewall-Skript automatisch laden

Egal ob man iptables oder nftables verwendet, man muss sicherstellen, dass die Regeln geladen werden, wenn das PPP-Interface hochkommt. Das erledigt man am einfachsten, indem man eine ausführbare Datei nach /etc/ppp/ip-up.d legt. Bei mir sieht der Inhalt folgendermaßen aus:

#!/bin/bash
nft -f /etc/nftables.conf
iptables --flush
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Ich habe an dieser Stelle nicht überprüft, wann dieses Skript ausgeführt wird – theoretisch könnte es einen kurzen Zeitpunkt geben, wo das PPP-Interface bereits von außen erreichbar, aber die Firewall noch nicht geladen worden ist (oder aufgrund eines Syntax-Fehlers in der Datei die Firewall gar nicht aktiviert wird). Da auf meiner Firewall außer SSH keine Internet-Dienste laufen, mache ich mir darüber keine weiteren Sorgen.

MSS Clamping

Eingangs habe ich erwähnt, dass das PPPoE-Protokoll zum Einsatz kommt. Aus diesem Grund muss man bei der gesetzten MTU besonders aufpassen. PPP setzt die MTU mit dem ISP auf 1492. Ethernet hat eine MTU von 1500. Da vor das PPP-Paket mit 1492 Bytes noch ein 8 Byte Header kommt, kommuniziert der pppd mit dem ISP mit 1500 Bytes.

Wird ein TCP Paket jedoch im Ethernet (das annimmt, 1500 Byte als MTU im gesamten Pfad bis ins Internet zu haben) mit einer Paketgröße von 1500 Bytes versendet, muss unser PPP-Router das Paket fragmentieren.

Hier kommt eine Technik namens Maximum Segment Size Clamping zum Einsatz. Kurzum, mit dem Befehl

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

wird der Header in TCP-Paketen derart verändert, dass kein TCP-Paket größer als 1492 von innen oder außen gesendet wird. Das kann für einige Provider erforderlich sein. Manche ISPs erlauben jedoch MTUs, die größer als 1500 Bytes sind, dann wird das MSS Clamping nicht benötigt. Für IPv6 ist kein MSS Clamping notwendig, da IPv6 die MTU im gesamten Routing-Pfad ermittelt.

Über den Autor

Wolfgang Hennebichler (Webseite[5]) ist Site Reliability Engineer bei Google.

Linkverweise:


[1] www.pro-linux.de/artikel/1/73/dsl-modem-im-bridging-modus-betreiben.html 
[2] de.wikipedia.org/wiki/PPP_over_Ethernet 
[3] www.pro-linux.de/news/1/21853/netfilter-projekt-veröffentlicht-nftables-04.html 
[4] www.linux-magazin.de/Ausgaben/2014/01/NFtables 
[5] www.wogri.at/

http://www.pro-linux.de/images/NB3/base/print/nb3_logo.png

Mediadaten RSS/Feeds Datenschutz Impressum

© 2017 Pro-Linux

 

[WEB] Dauer der Datenübertragung berechnen

Datenübertragung: Dauer | Geschwindigkeit | Größe | Komprimierung || Rechneronline.de | Impressum & Datenschutz


Dauer der Datenübertragung berechnen

Dieser Rechner berechnet die Dauer von Datenübertragungen mit verschiedenen USB-Versionen und über das Internet. Geben Sie die Dateigröße ein und klicken Sie auf Ausrechnen. Bei USB muss man zwischen Lesen und Schreiben unterscheiden, bei der Internetverbindung zwischen Download und Upload.

 

Dateigröße:       

Übertragung mittels

r
w

USB 1.0
Low Speed
r: 1 Mbit/s
w: 0,75 Mbit/s

USB 1.0
Full Speed
r: 8 Mbit/s
w: 6 Mbit/s

USB 2.0
Hi Speed
r: 310 Mbit/s
w: 240 Mbit/s

USB 3.0
SuperSpeed
r: 2600 Mbit/s
w: 2000 Mbit/s

USB 3.1
SuperSpeed +
r: 5200 Mbit/s
w: 4000 Mbit/s

r = Lesen (read), w = Schreiben (write)

d
u

56k Modem
d: 0,005 Mbit/s
u: 0,003 Mbit/s

ISDN
d: 0,0075 Mbit/s
u: 0,0075 Mbit/s

2x ISDN
d: 0,015 Mbit/s
u: 0,015 Mbit/s

DSL
d: 10 Mbit/s
u: 1 Mbit/s

Glasfaser
d: 100 Mbit/s
u: 50 Mbit/s

d = herunterladen (Download), u = hochladen (Upload)

Eigener Wert 1:       

Eigener Wert 2:       


 

Die Geschwindigkeitsangaben sind ungefähre Durchschnittwerte, nicht die theoretischen Maximalwerte. Bei DSL und Glasfaser gibt es natürlich noch viele andere Geschwindigkeitsstufen. Handelt es sich um viele, kleine Dateien, wird die Übertragungsgeschwindigkeit mitunter langsamer. Der Umrechnungsfaktor für die Vorsätze ist 1000, also z.B. 1 GB = 1000 MB. Wenn Sie wissen möchten, wie schnell Ihre Internetverbindung ist, suchen Sie nach „Internet Speed Test“.


English: 
Calculate Data Transfer Time | © jumk.de Webprojekte | Alle Angaben ohne Gewähr 

Cisco vs. Extreme Networks Switching Commands

 

Cisco vs. Extreme Networks Switching Commands

JULY 18, 2007

Don’t get your hopes up, I’m not taking sides here. I just wanted to show how the companies differ in basic switch configuration. Now for you who don’t know who Extreme is, they are the purple ones, better known as Extreme Networks. They offer some pretty nice products that compete very well with the likes of Cisco or HP. Feel free to check out their product line at www.extremenetworks.com/.

Configuring VLANs:

Extreme – Create 2 VLANs and basic configuration

create vlan data
configure vlan data tag 2
configure vlan data ipaddress 10.0.2.1/24
create vlan voice
configure vlan voice tag 3
configure vlan voice ipaddress 10.0.3.1/24
enable ipforwarding

Cisco – Create 2 VLAN interfaces and basic configuration

vlan dat
vlan 2 name data
vlan 3 name voice
exit
configure terminal
interface vlan 2
ip address 10.0.2.1 255.255.255.0
no shutdown
interface vlan 3
ip address 10.0.3.1 255.255.255.0

Port Configuration

Extreme

-switch to pc on (vlan 2)
configure vlan data add port 4 untagged
-switch to phone (vlan 3) and PC (vlan 2)
configure vlan voice add port 4 tagged
configure vlan data add port 4 untagged
-switch to phone (vlan 3)
configure vlan voice add port 4 tagged
-switch to switch
configure vlan default add port 1 tagged
configure vlan data add port 1 tagged
configure vlan voice add port 1 tagged

Cisco (skipping configure terminal)

-switch to pc on (vlan 2)

interface g0/4
sw mode access
sw acc vlan 2
-switch to phone (vlan 3) and PC (vlan 2)
interface g0/4
switchport mode trunk
switchport trunk encapsulation dot1q
switchport access vlan 2
-switch to phone (vlan 3)
interface g0/4
switchport mode trunk
switchport trunk encapsulation dot1q
-switch to switch
interface g0/4
switchport mode trunk
switchport trunk encapsulation dot1q

Show Commands

Extreme – show port 4 information detail
Cisco – show interface g0/4
Extreme – show iproute
Cisco – show ip route
Extreme – show edp port all
Cisco – show cdp neigh
Extreme – show vlan
Cisco – show vlan
Extreme – show fdb
Cisco – show mac-address-table
Extreme – show config
Cisco – show run

Saving your work

Extreme – save
Cisco – write memory
Extreme – upload configuration vr vr-default 10.0.0.100
Cisco – copy start tftp

Starting over

Extreme – unconfigure switch all
Cisco – write erase

 

Image-Dateien virtueller Maschinen flink übers Netzwerk kopieren

> Von Urs Pfister

Unter Linux dürften allgemein die Programme »scp« und »rsync« bekannt sein, um Dateien von einem auf einen anderen Rechner zu übertragen. Im Rahmen unserer Virtualisierungslösung ArchivistaVM sowie der freien Version ArchivistaMini werden die Instanzen mit DRDB jeweils auf zwei Maschinen gespeichert. Die erste Maschine überträgt die Daten der ersten Platte auf die zweite Platte der zweiten Maschine, die zweite Maschine überträgt ihre Daten (erste Platte) auf den dritten Rechner (zweite Platte) und so weiter, bis der letzte Rechner des Clusters die Daten auf die erste Maschine in die zweite Platte überträgt.

Geht es darum, Instanzen innerhalb des Clusters von einem Knoten auf einen anderen Knoten zu übertragen, so können dabei beträchtliche Daten anfallen. Virtuelle Festplatten-Dateien in der Größenordnung mehrer hundert Gbyte sollen dabei möglichst effizient auf den gewünschten Zielrechner übertragen werden. Erschwerend hinzu kommt, dass diese Festplatten-Dateien meist im sogenannten Sparse-Format vorliegen, d.h. zu Beginn wird eine Datei erzeugt, die maximal z.B. 200 Gbyte groß werden kann, allerdings nehmen diese Images nur soviel Platz ein, wie es bereits Daten in der Instanz gibt. So gesehen kann eine Sparse-Datei mit 200 Gbyte angelegt werden, sie benötigt am Anfang aber nur 0 Bytes. Der Unterschied wird ersichtlich, wenn die Dateien mit ls -ls gelistet werden:

       0 -rw-r--r-- 1 root root 214748364800 Nov 18 13:51 vm-230-disk-2.raw
12378804 -rw-r--r-- 1 root root  13128695808 Mar 23  2013 vm-230-disk.qcow2
29440368 -rw-r--r-- 1 root root 128849018880 Nov  3 12:38 vm-230-disk.raw

Die erste Zeile zeigt eine solche Datei. In der Datei sind 0 Bytes belegt, bei der zweiten Angabe wird die maximale Größe der Datei (hier 200 Gbyte) ausgeweisen. Beim zweiten Beispiel handelt es sich um eine Datei, die nicht mit dem Sparse-Format erstellt wurde und bei der dritten Datei sind ca. 29 GB belegt, die Datei kann jedoch bis zu 120 Gbyte Platz einnehmen.

Geht es darum, derartige Dateien von einem Rechner auf einen anderen Rechner zu verschieben, was bei der Migration von Maschine A auf B der Fall ist, so gilt es einige Besonderheiten zu beachten. Erstens eignet sich scp grundsätzlich nicht dafür, solche Dateien zu kopieren. Eine Sparse-Datei mit 0 Bytes und 200 Gbyte Maximalgrösse wird mit scp auf 200 Gbyte »aufgeblasen«. Auch rsync löst den Job nicht wirklich ideal, denn ohne die Option --sparse oder -S wird auf dem Zielrechner ebenfalls eine Datei mit 200 Gbyte erstellt. Vor allem aber lässt sich rsync beim Kopiervorgang viel Zeit. Sofern die Daten über eine 1 Gbit-Netzwerkkarte übertragen werden, können gut und gerne mehrere Stunden vergehen, bis die Daten den Zielrechner erreichen, auch wenn auf beiden Maschinen schnelle SSD-RAID-Verbünde (Durchsatz 800 MB/s) vorhanden sind. Sofern mit 1 Gbit-Netzwerkkarten gerarbeitet wird, lässt sich ja noch halbwegs erahnen, dass die Karte den Flaschenhals darstellt, da pro Sekunde ja maximal ca. 125 Mbyte übertragen werden können.

Bei 10 Gbit-Netzwerkkarten müsste dies anders aussehen, da hier pro Sekunde um die 1 Gbyte übertragen werden können. Dennoch konnte mit rsync, egal welche Dateien übertragen wurden, nicht mehr als ein Durchsatz von 200 MB/s erreicht werden. Die Fragestellung lautete daher, lässt sich dieser Prozess schneller gestalten und wenn ja, wie?

Ein Netzlaufwerk mit Samba oder NFS ist eine Alternative. NFS ist unter Linux viel unkomplizierter und in der Regel auch schneller und wird daher vorgezogen. Das Paket wird unter Debian mit apt-get install nfs-kernel-server installiert. Allfällig ist noch apt-get install rpcbind notwendig. Um nun von einem anderen Knoten mit NFS zugreifen zu können, ist die Datei /etc/exports anzulegen. Ein Eintrag kann wie folgt aussehen:

/var/lib/vz/images 10.0.1.126(ro,no_root_squash,async,no_subtree_check)

Nun kann vom betreffenden Rechner aus das Verzeichnis /var/lib/vz/images eingebunden werden, womit die Daten bequem mit cp -rp quelle ziel kopiert werden können. Die ersten Ergebnisse ließen aufhorchen, die großen Dateien konnten viel schneller kopiert werden. Nur die eingangs erwähnte Sparse-Datei mit 0 Bytes wollte irgendwie noch immer nicht so richtig.

Daher wurde der Versuch gestartet, die Daten direkt über das DRBD-Laufwerk zu lesen. Nun können diese Laufwerke ja nur gelesen werden, wenn der DRBD-Knoten den »primary«-Status hat. Dennoch kann der »secondary«-Knoten mit drbdadm down <Name des Devices> heruntergefahren werden. Dann spricht nichts mehr dagegen, das darunterliegende Device lesend zu öffnen. Angenommen, /dev/drbd1 liegt über der Partion /dev/sdb4, so kann mit mount -r -o noatime /dev/sdb4 /mnt/save der »secondary«-Knoten des DRBD-Verbundes auf dem Zielrechner lesend eingebunden werden, dies freilich natürlich nur, wenn der Knoten mit drbdadm down xy zuvor ausgeklinkt wurde.

Hier muss natürlich darauf hingewiesen werden, dass die DRBD-Methode nur möglich ist, wenn man den Cluster von vornherein mit DRBD konfiguriert hat, da eine nachträgliche Einrichtung von DRBD die Partition neu formatieren würde. Um schnell einmal beliebige Dateien zu kopieren, ist DRBD nicht nutzbar. Eine Anleitung zur Einrichtung von DRBD wurde im Rahmen des Workshops »Virtueller hochverfügbarer Linux-Server[1]« veröffentlicht.

Interessanterweise lassen sich die Sparse-Dateien mit cp nun ohne jegliche Zeitverzögerung kopieren, genau dies gelingt bei NFS mit cp so nicht. Die nachfolgenden Zahlen geben einen Einblick, was mit zwei SSD-Platten, einer 10 Gbit-Karte und einem mITX-Board heute machbar ist, wobei immer auch das Zeitverhalten mit rsync mit angegeben ist.

Datei (15G) + Sparse-Datei (30G belegt/130G maximal)

rsync über 1 Gbit/s-Intel-Karte: 1220 Sekunden
NFS über 10 Gbit/s-Intel-Karte: 195 Sekunden
DRBD über 10 Gbit/s-Intel-Karte: 100 Sekunden

http://www.pro-linux.de/images/NB3/imgdb/o_zeitvergleich-datei-15g-sparse-datei-30g-belegt130g-maximal.jpg

URS PFISTER

Geschwindigkeitsvorteil 6,25 bis 12,2

Datei (60G)

rsync über 1 Gbit/s-Intel-Karte: 520 Sekunden
NFS über 10 Gbit/s-Intel-Karte: 150 Sekunden
DRBD über 10 Gbit/s-Intel-Karte: 150 Sekunden

http://www.pro-linux.de/images/NB3/imgdb/o_zeitvergleich-datei-60g.jpg

URS PFISTER

Geschwindigkeitsvorteil 3,4

Datei (150G)

rsync über 1 Gbit/s-Intel-Karte: 1300 Sekunden
NFS über 10 Gbit/s-Intel-Karte: 390 Sekunden
DRBD über 10 Gbit/s-Intel-Karte: 390 Sekunden

http://www.pro-linux.de/images/NB3/imgdb/o_zeitvergleich-datei-150g.jpg

URS PFISTER

Geschwindigkeitsvorteil 3,33, kein Unterschied NFS/DRBD

Sparse-Datei (150G, 0 Bytes enthaltend)

rsync über 10 Gbit/s-Intel-Karte: 1300 Sekunden
NFS über 10 Gbit/s-Intel-Karte: 195 Sekunden
DRBD über 10 Gbit/s-Intel-Karte: 0 Sekunden

http://www.pro-linux.de/images/NB3/imgdb/o_zeitvergleich-sparse-datei-150g-0-bytes-enthaltend.jpg

URS PFISTER

Geschwindigkeitsvorteil 6,8 bis unlimitiert

Gesamtmessung über 9 Images (8 Instanzen)

 

Image

Größe GB

 

1

27/80

 

2

11/11

 

3

3,9/3,9

 

4

5,1/5,1

 

5

2,2/32

 

6

14/120

 

7

13/13

 

8

29/120

 

9

26/84

 

Werden diese Images zusammengezählt, so entstehen 131,2 GByte Daten (27 + 11 + 3,9 + 5,1 + 2,2 + 14 + 13 + 29 + 26), wobei sämtliche Abbilder maximal 469 GByte (80 + 11 + 3,9 + 5,1 + 32 + 120 + 13 + 120 + 84) einnehmen werden können.

Folgende Ergebnisse konnten hier gemessen werden:

rsync über 1 Gbit/s-Intel-Karte: 4275 Sekunden
NFS über 10 Gbit/s-Intel-Karte: 740 Sekunden
DRBD über 10 Gbit/s-Intel-Karte: 595 Sekunden

http://www.pro-linux.de/images/NB3/imgdb/o_zeitvergleich-summe-1312-gb.jpg

URS PFISTER

Geschwindigkeitsvorteil 5,77 bis 7,18

Aus diesen Zahlen wird eindrücklich ersichtlich, dass NFS, noch mehr DRBD-Laufwerke, auch sehr große Dateien jederzeit verschieben können, in allen Testfällen sind NFS und DRBD rsync um mindestens den Faktor 3,33 überlegen, im Schnitt gar um den Faktor irgendwo zwischen sechs und acht. Wer unter diesen Prämissen noch weiter mit rsync arbeitet, ist letztlich ganz einfach selber schuld.

Hinweis: Dieser Beitrag ist für den Vortrag »ArchivistaVM – Cloud-Virtualsierung auf dem Schreibtisch« entstanden, der anlässlich des linxday.at am 26. November in Dornbirn gehalten wurde. Das komplette Skript zur Cloud-Virtualisierung kann von archivista.ch[2] bezogen werden.

Linkverweise:


[1] www.pro-linux.de/artikel/2/1664/projekt-virtueller-hochverfügbarer-linux-server-teil-11.html 
[2] archivista.ch/cms/language/de/aktuell-blog/vortrag-linuxday-at/

http://www.pro-linux.de/images/NB3/base/print/nb3_logo.png

Mediadaten RSS/Feeds Datenschutz Impressum

© 2017 Pro-Linux

 

Raspberry Pi: Root-Rechte an Benutzer vergeben

Raspberry Pi: Root-Rechte an Benutzer vergeben

Der Benutzer „root“ ist ein Standard-Benutzer, der sich in jedem Linux-System befindet. Dieser Benutzername ist nicht nur bekannt, sondern auch noch mit uneingeschränkten Rechten ausgestattet. Wenn man einen Raspberry Pi normal nutzt, dann wird man das nicht als „root“ tun, sondern als Benutzer „pi“. Der hat aber nur eingeschränkte Rechte. Das heißt, er darf nicht alles tun.

Gelegentlich kommt es aber vor, dass man Änderungen am Raspberry Pi vornehmen muss, und dann braucht man die Rechte von „root“ bzw. Root-Rechte. Bei der Linux-Distribution Raspbian ist es so, dass der Standard-Benutzer „pi“ auf der Kommandozeile jederzeit Root-Rechte mit Hilfe von „sudo“ oder „su“ erhalten kann. Und das ohne Kenntnis des Root-Passworts. Je nach Sicherheitsbedürfnis möchte man diese Möglichkeit einschränken.

Hinweis: Der Root-Zugang ist ein Arbeitsmittel. Ohne Root-Rechte kann man auf keinem System Änderungen vornehmen. Allerdings stellt ein direkter Root-Zugang immer auch ein Sicherheitsrisiko dar, insbesondere dann, wenn der Zugriff nicht eingeschränkt wird.

 

Aufgaben

  1. Wie funktionieren die Root-Rechte in der Standard-Konfiguration?
  2. Schränken Sie die Root-Rechte für den Benutzer „pi“ ein.
  3. Aktivieren Sie den Root-Account durch Festlegen eines Passworts.
  4. Deaktivieren Sie den Root-Account.

Hinweis: Änderung von Berechtigungen

Wenn man Berechtigungen ändert, dann testet man die in der Regel gleich. Nur so kann man sicherstellen, das es funktioniert, wie es gewünscht ist. Es kommt allerdings vor, dass beim Testen die Berechtigungen nicht wie eigentlich gewünscht funktionieren, obwohl die Änderung richtig durchgeführt wurde.
In solchen Fällen sollte man daran denken, dass Änderungen an Berechtigungen und Konfigurationen erst von aktiven Instanzen übernommen werden müssen. Je nach Instanz muss dazu die Instanz neu gestartet werden. Im Falle von Benutzerberechtigungen (Gruppen, usw.) muss sich der Benutzer erst abmelden und neu anmelden. Erst dann werden zum Beispiel Gruppenzuweisungen übernommen. Oder bei einer Änderung einer Server-Konfiguration muss der Dienst neu gestartet werden. Erst dann übernimmt der Dienst die geänderte Konfiguration. Es gibt sogar Konfigurationsänderungen, bei denen ein kompletter Neustart des Systems erforderlich ist.
Das bedeutet, bei der Änderung von Berechtigungen und Konfigurationen sollte man sich klar machen, wo man die Änderung vorgenommen hat (laufender Prozess oder Datei) und dann überlegen, welche Instanz davon betroffen ist (Benutzer, Dienst oder System) und ob diese Instanz neu gestartet werden muss, um die Änderung zu übernehmen.

Lösung: Root-Rechte in der Standard-Konfiguration

In der Standard-Konfiguration von Raspbian (Images ab Ende 2014) ist für den Benutzer „root“ kein Passwort gesetzt. Dafür darf der Standard-Benutzer „pi“ mittels „sudo“ mit Root-Rechten arbeiten. Und zwar ohne Einschränkungen.
„sudo“ wird im Allgemeinen als „super user do“ bezeichnet. Allerdings steht „sudo“ für „substitute user do“. Mit „sudo“ kann man also mit den Rechten jedes beliebigen Benutzers Kommandos ausführen und nicht nur „root“. Vorausgesetzt man hat Root-Rechte.

sudo {KOMMANDO}

Lösung: Zu „root“ wechseln

Allerdsings kann es ziemlich nervig sein immer „sudo“ vor jeder Aktion zu schreiben. Deshalb gibt es Wege, wie man temporär oder dauerhaft zu „root“ werden kann, um systemweite Änderungen vorzunehmen.

sudo -s
sudo su
sudo su -

Nach der Eingabe des Passworts wird die normale Shell zur Root-Shell.

Das Kommando „su“ steht für „substitute user“. Im Allgemeinen sagt man auch „super user“ dazu. Mit „super user“ ist „root“ gemeint, der unbeschränkte Rechte auf einem System hat. Allerdings kann man mit „su“ nicht nur zu „root“, sondern zu jedem Benutzer werden.
Der Bindestrich „-“ nach „su“ bedeutet, das die komplette Umgebung (Aliase, Pfade u.s.w.) des Users zur Verfügung stehen und dabei auch in sein Home-Verzeichnis gewechselt wird. Lässt man das „-“ weg, arbeitet man in der selben Umgebung weiter, aus welcher man gewechselt hat. In dem Fall werden nur die Berechtigungen übernommen.

Bei „sudo su -„, was die Kurzform von „sudo su – root“ ist, wechselt man ins Home-Verzeichnis von „root“.

Mit „exit“ kann man den übernommenen Benutzer verlassen und zum vorherig angemeldeten Benutzer zurückkehren. Eine eventuell aufgebaute SSH-Verbindung wird dabei aber nicht beendet.

Lösung: „sudo“ installieren

In der Regel ist „sudo“ auf Mehrbenutzer-Distributionen installiert. Es kann jedoch vorkommen, dass es nicht der Fall ist. Dann kann man es nachträglich installieren.

apt-get update
apt-get install sudo

Lösung: Root-Rechte einschränken (Benutzer-Passwort abfragen)

Normalerweise ist es so, dass der Benutzer „pi“ nur beim Login nach seinem Passwort gefragt wird. Danach wird er nicht mehr nach seinem Passwort gefragt. Wenn der Benutzer dann seinen Arbeitsplatz verlässt, dann kann jeder ohne Beschränkung an diesem System arbeiten. Auch mit Root-Rechten mittels „sudo“. Die Idee ist, die Berechtigungen so weit einzuschränken, dass der Benutzer „pi“ ab und zu nach seinem Passwort gefragt wird, wenn er „sudo“ verwendet.
Dazu muss man sicherstellen, dass der Benutzer „pi“ der Benutzergruppe „sudo“ zugeordnet ist.

sudo gpasswd -a pi sudo

Grundsätzlich kann man dadurch auch jeden anderen Benutzer zu einem Systemadministrator machen.
Diese Änderung wird aber erst nach der Ab- und Wiederanmeldung des Benutzers wirksam, sofern der Benutzer „pi“ nicht schon vorher in der Benutzergruppe „sudo“ drin war.

id pi

Anschließend ändern wir die sudo-Benutzersteuerung (Sudoers) mit „visudo“. Damit wird eine Datei editiert, die man nie direkt editieren sollte.

sudo visudo

Verantwortlich für die Passwort-Abfrage bei der Nutzung von „sudo“ ist die folgende Zeile. Sie sollte in der Konfigurationsdatei enthalten sein.

%sudo   ALL=(ALL:ALL) ALL

In der Konfigurationsdatei ändern wir die folgende Zeile:

pi ALL=(ALL) NOPASSWD: ALL

in

#pi ALL=(ALL) NOPASSWD: ALL

Damit kommentieren wir die Zeile, die ursprünglich dafür da war, dass der Benutzer „pi“ ohne Passwort-Eingabe „sudo“ benutzen durfte.
Danach die Datei speichern und schließen: Strg + O, Return, Strg + X.
„visudo“ verifiziert vor dem Überschreiben der Original-Datei die Syntax. Falls man etwas falsch gemacht hat wird so verhindert, dass man sich auf diese Weise aussperrt.

Die Änderung gilt sofort. Jetzt muss „pi“ beim ersten Kommandozeilenzusatz „sudo“ sein eigenes Passwort eingeben, um Root-Rechte zu erlangen. Für ein paar Minuten darf „pi“ dann ohne Passwort-Eingabe „sudo“ weiter benutzen.

Lösung: Root-Account aktivieren

Im Allgemeinen fährt man bei Raspbian gut damit, den Root-Account deaktiviert zu lassen und das System ausschließlich als Benutzer „pi“ mit Hilfe von „sudo“ oder „su“ zu administrieren. Es gibt allerdings Gründe, für den Benutzer „root“ ein Passwort anzulegen und damit den Root-Account zu aktivieren. Beispielsweise dann, wenn nicht-vertrauenswürdige Benutzer Zugang zum Raspberry Pi haben. Die könnten unbemerkt den Root-Account aktivieren und weiteren Unfug treiben.
Deshalb gilt, wenn der Raspberry Pi als Multi-User-Umgebung benutzt wird, sollte der Root-Account aktiviert werden.

Das Aktivieren des Root-Accounts erfolgt dadurch, dass wir dem Benutzer „root“ ein Passwort geben.

sudo su
passwd

Hinweis: Wenn man den Root-Account aktiviert, dann wird dadurch auch der Root-Zugang per SSH aktiviert. Das ist natürlich abhängig von der SSH-Server-Konfiguration. Aus Sicherheitsgründen macht es Sinn, den SSH-Server so zu konfigurieren, dass ein Login per „root“ NICHT möglich ist.

Lösung: Root-Rechte für Benutzer nur mit Root-Passwort

Wir möchten, dass ein Benutzer wie gewohnt mit dem Kommandozusatz „sudo“ Root-Rechte erlangen kann. Bei Verwendung von „sudo“ soll zusätzlich das Root-Passwort abgefragt werden und somit eine doppelte Sicherheit hergestellt werden.
Ein Benutzer soll „sudo“ also nur dann verwenden können, wenn er das Root-Passwort kennt. Dazu müssen wir sicherstellen, dass der Root-Account aktiviert ist, also dass „root“ ein Passwort hat.

Als Benutzer „pi“ kann man sich mit „su“ zum Benutzer „root“ machen.

sudo su

Wenn an dieser Stelle NICHT nach dem Root-Passwort gefragt wird, dann ist auch keines eingerichtet. Das sollte man an der Stelle nachholen.

passwd

Nach dem man das Passwort und die Bestätigung eingegeben hat, verlässt man „root“.

exit

Anschließend versucht man es noch einmal.

sudo su

Jetzt lässt uns „su“ erst dann zu „root“ werden, wenn das Root-Passwort richtig eingegeben wurde. Anschließend kann man als „root“ alle Kommandos ohne „sudo“ eingeben.

Als „root“ fügen wir „pi“ zuerst der Benutzergruppe „sudo“ hinzu, sofern der Benutzer „pi“ nicht bereits zugeordnet ist.

gpasswd -a pi sudo

Anschließend fügen wir einen Parameter in der sudo-Benutzersteuerung (Sudoers) hinzu.

visudo

Hier fügt man folgende Zeile ein:

Defaults        rootpw

Diese Einstellung sorgt dafür, dass bei Nutzung von „sudo“ nicht das Benutzer-Passwort, sondern das Root-Passwort abgefragt wird.
Nach der Änderung die Datei speichern und schließen: Strg + O, Return, Strg + X.

Anschließend verlässt man den Benutzer „root“.

exit

Hinweis: Die zusätzliche Abfrage des Root-Passworts ist natürlich nur sinnvoll, wenn dieses Passwort vom eigentlichen Benutzer-Passwort abweicht. Sind beide identisch, würde ein aktivierter Root-Account überhaupt keinen Sinn machen und wäre auch nicht sicher.

Lösung: Root-Account deaktiveren

Folgendermaßen bringt man den Root-Account wieder in den „deaktivierten“ Zustand.

Zuerst muss man aber „Defaults rootpw“ per „visudo“ entfernen. Wenn das noch drin steht, wenn man das Root-Passwort löscht, dann kann man als normaler Nutzer kein „sudo“ mehr nutzen. Und Anmelden als „root“ geht unter Umständen auch nicht mehr.
Erst wenn man sichergestellt hat, dass „sudo“ nicht mehr nach dem Root-Passwort fragt, dann darf man das Root-Passwort löschen.

sudo passwd -d root

Hinweis: Unterschied zwischen „sudo“ oder „su“?

Mit Hilfe von „sudo“ kann man Kommandos mit den Rechten eines jeden Benutzers ausführen. In der Regel benutzt man „sudo“, um Kommandos mit den Rechten von „root“ auszuführen.

Mit Hilfe von „su“ wechselt man zu einem beliebigen Benutzer, um anschließend mit dessen Rechte zu arbeiten. In der Regel wechselt man mit „sudo su“ zu „root“, um Kommandos mit dessen Rechte auszuführen.

Der Unterschied hängt davon ab, ob man einmalig mit „sudo“ ein Kommando mit den Rechten eines anderen Nutzers ausführen möchte, oder ob man mit „su“ zu einem anderen Nutzer wechselt und alle darauf folgenden Kommandos mit dessen Rechten ausführt. Selbstverständlich kann man auch mit „sudo“ alle Kommandos mit den Rechten eines anderen Nutzers ausführen. Das wechseln des Benutzers mit „su“ ist aber häufig bequemer, weil man dann auf „sudo“ verzichten kann.

Erweiterungen

Weitere verwandte Themen:

Add timestamp to history command output in Linux

Add timestamp to history command output in Linux

My last post was about adding timestamp to terminal in Linux. But isn’t it better to simply add timestamp to history command? This enables you to open your terminal anytime, run history command and find out when you ran which command, all without keeping terminal or putty windows open indefinitely. I guess it’s helpful in some cases. Here’s how to add timestamp to history command output in Linux:

Modify .bashrc file

We need to set HISTTIMEFORMAT environment variable. Add the following line to your .bashrc file.

export HISTTIMEFORMAT="%F-%T "

Add timestamp to history command output in Linux - blackMORE Ops - 1

Save the file and open a new terminal, type in history and voila.

root@kali:~# history | tail -5
69 2016-10-11-21:33:48 vi .bashrc
70 2016-10-11-21:34:13 exit
71 2016-10-11-21:34:49 history | tail -5
72 2016-10-11-21:40:47 clear
root@kali:~#

Pretty neat. You can go further by adding it in the skel or default so that it affects all new accounts that are created. You can use config managers such as Puppet or Spacewalk or Chef to deploy these little snippet so that all machines in the managed network has timestamp in history. Either way, this is a nice handy snippet for any Linux Administrator to have.

 

Let’s Encrypt

> Von Christoph Schmidt

Was ist Let’s Encrypt?

Let’s Encrypt[1] ist eine von der Internet Security Research Group (ISRG) betriebene Zertifizierungsstelle (CA, certificate authority), die sich zum Ziel gesetzt hat, das Verschlüsseln von Daten im Internet zum Standard zu machen. Dazu stellt sie kostenlose und leicht installierbare X.509-Zertifikate zur Verfügung, mit denen Internetdienste wie zum Beispiel Webseiten sich im Internet authentifizieren und ihre Daten verschlüsseln können. Nach einer geschlossenen Testphase trat das Projekt am 3. Dezember 2015 in eine öffentliche Testphase ein, in der jeder ein Zertifikat beantragen kann.

Die ISRG ist eine gemeinnützige Organisation mit Sitz in den USA, deren Hauptsponsoren die Electronic Frontier Foundation (EFF), die Mozilla Foundation, Akamai und Cisco Systems sind.

Wozu dienen Zertifikate?

Die von einer CA ausgestellten Zertifikate haben zwei Funktionen: Erstens identifiziert sich der Internetdienst mit diesem Zertifikat, d.h. der Besucher einer Webseite kann sich sicher sein, sich wirklich auf der Seite zu befinden, welche er besuchen wollte. Zweitens wird der Datenverkehr zwischen der besuchten Webseite und dem Rechner des Besuchers verschlüsselt, sodass unbefugte Dritte, die Zugriff auf den Datenstrom haben, diesen nicht mitlesen können.

Webseiten mit einem solchen Zertifikat erkennt man daran, dass die URL (Uniform Resource Locator oder »Internetadresse«) mit https:// anstelle von http:// beginnt. Browser stellen normalerweise auch ein Vorhängeschloss in der Adresszeile vor die URL. Betreibt man nun selbst einen solchen Internetdienst und hat bisher die Komplikationen und/oder Kosten eines Zertifikats gescheut, gibt es nun einen einfachen und kostenlosen Weg, seinen Server mit einem solchen auszustatten.

Let’s Encrypt stellt Zertifikate sowohl für Domains als auch Sub-Domains aus. Eine Domain setzt sich aus dem eigentlichen Domainnamen (z.B. freiesmagazin) und der TLD (Top-Level-Domain, z.B. de) zusammen: freiesmagazin.de. Sub-Domains enthalten einen weiteren vorangestellten Namensteil, welcher sich traditionell auf einen Rechner bezog, z.B. www.freiesmagazin.de. www war früher dabei der Rechner, auf dem der Webserver lief – zu Zeiten, als jeder Service seine eigene Hardware besaß.

Heute werden Sub-Domains häufig bei dynamischem DNS (Domain Name Service) verwendet. Dieser Service wird meist von Privatpersonen in Anspruch genommen, die über einen gewöhnlichen DSL-Anschluss mit dynamischer IP-Adresse mit dem Internet verbunden sind. Dabei ändert der Internet Service Provider (ISP, z.B. Telekom, Vodafone) in regelmäßigen Abständen die IP-Adresse des Anschlusses, sodass der Server im eigenen Heim nicht immer unter der gleichen IP-Adresse vom Internet aus zu erreichen ist. Um dieses Problem zu umgehen, meldet sich der Server nach jeder Änderung der IP-Adresse beim DNS Service, damit dieser die neue IP-Adresse wieder der eigenen Sub-Domain zuweist. Eine solche Sub-Domain hat die allgemeine Form meine-sub-domain.domain.tld, wobei meine-sub-domain ein frei wählbarer Name ist und domain.tld dem DNS-Anbieter gehört.

Installation von Let’s Encrypt

Eines vorneweg: Dieser Artikel beschäftigt sich nicht mit dem Aufsetzen und Konfigurieren eines Webservers, sondern nur mit der Installation und dem Erneuern der Zertifikate. Die Einrichtung eines Webservers würde den Umfang eines einzelnen Artikels bei weitem übertreffen.

Als Beispiel wird in diesem Artikel ein Apache-Webserver auf Debian 8 (»Jessie«) verwendet. Die Installation und Aktualisierung der Zertifikate ist unabhängig vom verwendeten Webserver, lediglich die Einbindung in den Webserver ist verschieden.

Die Let’s Encrypt-Anwendung kann entweder über das Klonen des Projektes von Github oder durch Download eines ZIP-Archivs von dort installiert werden. Let’s Encrypt selbst empfiehlt die Installation von Github wegen der einfacheren Aktualisierung der Anwendung. Dazu muss zuerst git über die Paketverwaltung installiert werden. Anschließend kann das Projekt geklont werden:

$ git clone github.com/letsencrypt/letsencrypt

Nach dem Klonen des Projektes erscheint ein neues Verzeichnis letsencrypt. Zum Aktualisieren wechselt man in das neue Verzeichnis und führt folgenden Befehl aus:

$ git pull

Erstellen des ersten Zertifikates

Zum Erstellen des ersten Zertifikates führt man im Verzeichnis letsencrypt das folgende Kommando aus:

$ ./letsencrypt-auto --server acme-v01.api.letsencrypt.org/directory auth

Läuft der Webserver hierbei hinter einer Firewall, muss sichergestellt sein, dass die Ports 80 (HTTP) und 443 (HTTPS) offen sind. Weiterhin muss der Webserver auch unter der Domain, für die das Zertifikat ausgestellt werden soll, vom Internet aus über DNS erreichbar sein.

Zunächst überprüft letsencrypt-auto, ob irgendwelche Aktualisierungen verfügbar sind, und installiert diese gegebenenfalls. Danach werden dem Anwender einige Fragen gestellt, die zur Erstellung des Zertifikates notwendig sind:

  • Zuerst muss der zu verwendende Webserver angegeben werden. Falls bereits ein Webserver aufgesetzt ist, sollte dieser verwendet werden, da nur ein Webserver auf den HTTP(S) Port zugreifen kann. Ansonsten bietet letsencrypt-auto auch an, einen eigenen Webserver zu verwenden (standalone).
  • Danach wird nach einer E-Mail-Adresse gefragt, unter der das Zertifikat registriert werden soll. Diese wird von Let’s Encrypt für dringende Benachrichtigungen und zur Wiederherstellung verlorener Zertifikate verwendet.
  • Anschließend müssen die Servicebedingungen (terms of service) akzeptiert werden.
  • Zuletzt wird eine Liste mit den Domainnamen abgefragt. Falls Zertifikate für mehr als eine Domain angefordert werden sollen, müssen die Domainnamen mit Komma oder Leerzeichen getrennt werden.

Sobald das Zertifikat erstellt wurde, legt letsencrypt-auto das Verzeichnis /etc/letsencrypt an und speichert dort die Zertifikate unter /etc/letsencrypt/archive/domain.tld/, wobei domain.tld dem Domainnamen entspricht, für welchen das Zertifikat ausgestellt wurde. Alle zukünftigen Zertifikate werden ebenfalls in diesem Verzeichnis abgelegt und durchnummeriert. Das letzte aktuell gültige Zertifikat wird im Verzeichnis /etc/letsencrypt/live/domain.tld/ verlinkt. Von dort sollte der Webserver auch das Zertifikat lesen, da der Link bei jeder Aktualisierung des Zertifikats entsprechend angepasst wird.

Einbinden der Zertifikate

Nachdem die Zertifikate nun auf dem Server installiert sind, müssen diese auch noch im Webserver eingebunden werden. Dies kann entweder automatisch oder manuell erfolgen. Für die automatische Installation muss beim Erstellen des Zertifikates lediglich letsencrypt-auto run anstelle von letsencrypt-auto auth angegeben werden oder – falls die Zertifikate bereits erstellt wurden – letsencrypt-auto install. Die automatische Installation funktioniert derzeit sowohl mit Apache und – momentan noch als Beta – mit NGINX.

Wer nicht möchte, dass letsencrypt-auto die Konfiguration seines Webservers automatisch verändert, kann die Zertifikate auch manuell einbinden. Hierzu muss zuallererst das SSL-Modul in Apache aktiviert werden:

# a2enmod ssl

Danach muss ein virtueller Host für SSL angelegt werden. Hierfür erstellt man eine neue Datei im Verzeichnis /etc/apache2/sites-available. Der Dateiname ist hierbei irrelevant, es empfiehlt sich aber, den Domainnamen im Dateinamen unterzubringen, zum Beispiel ssl.domain.tld.conf, damit man bei diversen Domains die entsprechende Datei schnell findet. Ein minimaler Inhalt für diese Datei könnte der Folgende sein:

<IfModule mod_ssl.c>
    <VirtualHost _default_:443>
 
        SSLEngine on
 
        SSLCertificateFile      /etc/letsencrypt/live/domain.tld/cert.pem
        SSLCertificateKeyFile   /etc/letsencrypt/live/domain.tld/privkey.pem
        SSLCertificateChainFile /etc/letsencrypt/live/domain.tld/chain.pem
 
    </VirtualHost>
</IfModule>
  • SSLEngine: Diese Anweisung aktiviert das SSL/TLS Protokoll für diesen virtuellen Host.
  • SSLCertificateFile: Dies ist der öffentliche Teil des Zertifikat-Schlüssels.
  • SSLCertificateKeyFile: Dies ist der private Teil des Zertifikats-Schlüssels.
  • SSLCertificateChainFile: Diese Datei enthält alle öffentlichen Zertifikat-Schlüssel der CAs, welche das Zertifikat ausgestellt haben.

Anzumerken bleibt noch, dass die oben gezeigte Datei lediglich eine minimale Konfiguration des virtuellen Hosts darstellt. Abhängig vom Einsatzzweck muss die Konfiguration deshalb noch entsprechend erweitert werden. Dazu ist entweder die Dokumentation der verwendeten Distribution oder die der Apache Foundation[2] zu Rate zu ziehen.

Möchte man jede HTTP-Verbindung auf HTTPS umleiten, kann man dafür einen weiteren virtuellen Host anlegen, welcher auf dem HTTP-Port 80 lauscht und die Anfragen entsprechend umleitet:

<VirtualHost *:80>
        RewriteEngine on
        RewriteRule ^ %{HTTP_HOST}/%{REQUEST_URI} [L,QSA,R=permanent]
</VirtualHost>
  • RewriteEngine: Diese Anweisung erlaubt das Ändern von URLs.
  • RewriteRule: Mit dieser Anweisung werden alle HTTP-Anfragen auf HTTPS umgeleitet. Der Rest der URL bleibt dabei unverändert, zum Beispiel domain.tld/login wird zu domain.tld/login. HTTP_HOST entspricht hierbei der Domain (domain.tld) und REQUEST_URI der angeforderten Seite (login).

Nachdem die virtuellen Hosts eingerichtet sind, müssen diese noch aktiviert werden:

# a2ensite ssl.domain.tld

Dieser Befehl legt einen Link in /etc/apache2/sites-enabled auf die neue Seite in /etc/apache2/sites-available an. Sollten bereits Seiten eingerichtet sein, muss man diese gegebenenfalls mit a2dissite deaktivieren oder mit der Anweisung ServerName in der Konfiguration des virtuellen Hosts (in /etc/apache2/sites-available) auf bestimmte Hosts beschränken, um Konflikte zu vermeiden.

Zuletzt wird der Webserver neu gestartet:

# apache2ctl restart

Aktualisieren der Zertifikate

Die von Let’s Encrypt ausgestellten Zertifikate sind nur drei Monate lang gültig. Um nach Ablauf dieses Zeitraums ein neues Zertifikat zu beantragen, kann man die oben beschriebenen Schritte wiederholen oder aber den ganzen Prozess automatisieren. Hierfür müssen lediglich die Antworten für die von letsencrypt-auto gestellten Fragen bereits beim Aufruf mitgeliefert werden. Dies geschieht entweder über die Kommandozeilen-Parameter oder man legt die Konfigurationsdatei cli.ini im Verzeichnis /etc/letsencrypt entsprechend an:

server = acme-v01.api.letsencrypt.org/directory
email = webmaster@domain.tld
authenticator = webroot
webroot-path = /var/www/html/
domains = domain.tld
agree-tos = True
renew-by-default = True
  • server: Hiermit wird der Server angegeben, von dem das Zertifikat bezogen werden soll, d.h. der Let’s Encrypt Server.
  • email: Dies ist die Kontakt-E-Mail für dringende Benachrichtigungen und die Wiederherstellung verlorener Zertifikate.
  • authenticator/webroot-path: Mithilfe dieser Anweisung teilt man letsencrypt-auto mit, dass man zur Authentifizierung einen bereits aufgesetzten Webserver verwenden möchte. letsencrypt-auto wird dann im Verzeichnis webroot-path ein Unterverzeichnis .well-known anlegen, das eine Datei zur Authentifizierung enthält. Mithilfe dieser Datei wird dann sichergestellt, dass der Antragsteller auch wirklich Zugriff auf die Domain besitzt und nicht ein Zertifikat für eine andere, seinem Zugriff nicht unterliegende, Domain anfordert. Der Wert für webroot-path hängt von der verwendeten Distribution und Version ab, ist aber meistens entweder /var/www oder /var/www/html.
  • domains gibt die Domain an, für welche das Zertifikat ausgestellt werden soll.
  • agree-tos: Hiermit werden die Servicebedingungen bestätigt.
  • renew-by-default: Dies fordert ein neues Zertifikat an anstelle einer neuen Kopie des bereits vorhandenen Zertifikats.

Der automatisierte Ablauf kann nun getestet werden, indem man letsencrypt-auto auth als root ausführt. Dabei sollten keine interaktiven Abfragen mehr erscheinen. Anzumerken bleibt noch, dass Let’s Encrypt nur zehn Anfragen pro Domain und Tag zulässt, man muss sich also mit seinen Versuchen etwas zurückhalten.

Funktioniert die Aktualisierung des Zertifikats ohne weitere Interaktion, kann man zum Beispiel eine ausführbare Datei update-cert in /etc/cron.monthly/ mit folgendem Inhalt erstellen:

#!/bin/sh
 
/path/to/letsencrypt-auto auth
apache2ctl restart

Damit wird jeden Monat automatisch ein neues Zertifikat angefordert. /path/to/ muss natürlich noch mit dem Installationsverzeichnis von letsencrypt-auto ersetzt werden.

Fazit

Wer sich bereits etwas mit Webservern auskennt, hat nun einen einfachen und kostenlosen Weg, seinen Server mit einem Zertifikat auszustatten. Auch wenn das Versprechen von Let’s Encrypt, eine Ein-Klick-Lösung anzubieten, noch nicht ganz erreicht ist, dürfte die Installation auch für Hobby-Administratoren zu machen sein.

Die von Let’s Encrypt ausgestellten Zertifikate werden momentan von allen aktuellen Browsern aus den Häusern Microsoft, Google und Mozilla anerkannt. Apple konnte mangels Apple-Geräten nicht getestet werden.

In diesem Sinne: Let’s Encrypt!

Autoreninformation

Christoph Schmidt ist ein Hobby-Linuxer, welcher unter Verständnislosigkeit seiner Umwelt versucht, möglichst viel seiner privaten IT auf FOSS-Lösungen umzustellen.

Dieser Artikel ist in freiesMagazin 01/2016[3] (ISSN 1867-7991) erschienen. Veröffentlichung mit freundlicher Genehmigung.

Linkverweise:


[1] letsencrypt.org/ 
[2] httpd.apache.org/docs/ 
[3] www.freiesmagazin.de/20160103-januarausgabe-erschienen

http://www.pro-linux.de/images/NB3/base/print/nb3_logo.png

Mediadaten RSS/Feeds Datenschutz Impressum

© 2017 Pro-Linux

 

cut out selected fields of each line of a file

Von Markus Schnalke

Funktionsweise

Ursprünglich hatte cut zwei Modi, die später um einen dritten erweitert wurden. cut schneidet entweder gewünschte Zeichen aus den Zeilen der Eingabe oder gewünschte, durch Trennzeichen definierte, Felder.

Der Zeichenmodus ist optimal geeignet, um Festbreitenformate zu zerteilen. Man kann damit beispielsweise bestimmte Zugriffsrechte aus der Ausgabe von ls -l ausschneiden, in diesem Beispiel die Rechte des Besitzers:

$ ls -l foo
-rw-rw-r-- 1 meillo users 0 May 12 07:32 foo
$ ls -l foo | cut -c 2-4
rw-

Oder die Schreibrechte des Besitzers, der Gruppe und der Welt:

$ ls -l | cut -c 3,6,9
ww-

Mit cut lassen sich aber auch Strings kürzen:

$ long=12345678901234567890
$ echo "$long" | cut -c -10
1234567890

Dieser Befehl gibt die ersten maximal 10 Zeichen von $long aus. (Alternativ kann man hierfür printf "%.10sn" "$long" verwenden.)

Geht es aber nicht um die Darstellung von Zeichen, sondern um ihre Speicherung, dann ist -c nicht unbedingt geeignet. Früher, als US-ASCII noch die omnipräsente Zeichenkodierung war, wurde jedes Zeichen mit genau einem Byte gespeichert. Somit selektierte cut -c gleichermaßen sowohl Ausgabezeichen als auch Bytes. Mit dem Aufkommen von Multibyte-Kodierungen (wie UTF-8) musste man sich jedoch von dieser Annahme lösen. In diesem Zug bekam cut mit POSIX.2-1992 einen Bytemodus (Option -b). Will man also nur die ersten maximal 500 Bytes vor dem Newline-Zeichen stehen haben (und den Rest stillschweigend ignorieren), dann macht man das mit:

$ cut -b -500

Den Rest kann man sich mit cut -b 501- einfangen. Diese Funktion ist insbesondere für POSIX wichtig, da man damit Textdateien mit begrenzter Zeilenlänge[1] erzeugen kann.

Wenn auch der Bytemodus neu eingeführt worden war, so sollte er sich doch nur so verhalten wie der alte Zeichenmodus normalerweise schon implementiert war. Beim Zeichenmodus aber wurde eine neue Implementierungsweise gefordert. Das Problem war folglich nicht, den neuen Bytemodus zu implementieren, sondern den Zeichenmodus neu zu implementieren.

Neben dem Zeichen- und Bytemodus bietet cut noch den Feldmodus, den man mit -f einleitet. Mit ihm ist es möglich, Felder auszuwählen. Das Trennzeichen (per Default der Tab) kann mit -d geändert werden. Es gilt in gleicher Weise für die Eingabe und die Ausgabe.

Der typische Anwendungsfall für cut im Feldmodus ist die Auswahl von Information aus der passwd-Datei. Hier z.B. der Benutzername und seine ID:

$ cut -d: -f1,3 /etc/passwd
root:0
bin:1
daemon:2
mail:8
...

Die einzelnen Argumente für die Optionen können bei cut übrigens sowohl mit Whitespace abgetrennt (wie oben zu sehen) als auch direkt angehängt folgen.

Dieser Feldmodus ist für einfache tabellarische Dateien, wie eben die passwd-Datei, gut geeignet. Er kommt aber schnell an seine Grenzen. Gerade der häufige Fall, dass an Whitespace in Felder geteilt werden soll, wird damit nicht abgedeckt. Der Delimiter kann bei cut nur genau ein Zeichen sein. Es kann demnach nicht sowohl an Leerzeichen als auch an Tabs aufgetrennt werden. Zudem unterteilt cut an jedem Trennzeichen. Zwei aneinander stehende Trennzeichen führen zu einem leeren Feld. Dieses Verhalten widerspricht den Erwartungen, die man an die Verarbeitung einer Datei mit Whitespace-getrennten Feldern hat. Manche Implementierungen von cut, z.B. die von FreeBSD, haben deshalb Erweiterungen, die das gewünschte Verhalten für Whitespace-getrennte Felder bieten. Ansonsten, d.h. wenn man portabel bleiben will, verwendet man awk in diesen Fällen.

awk bietet noch eine weitere Funktion, die cut missen lässt: Das Tauschen der Feld-Reihenfolge in der Ausgabe. Bei cut ist die Reihenfolge der Feldauswahlangabe irrelevant; ein Feld kann selbst mehrfach angegeben werden. Dementsprechend gibt der Aufruf von cut -c 5-8,1,4-6 die Zeichen Nummer 1, 4, 5, 6, 7 und 8 in genau dieser Reihenfolge aus. Die Auswahl entspricht damit der Mengenlehre in der Mathematik: Jedes angegebene Feld wird Teil der Ergebnismenge. Die Felder der Ergebnismenge sind hierbei immer gleich geordnet wie in der Eingabe. Um die Worte der Manpage von Version 8 Unix wiederzugeben: »In data base parlance, it projects a relation.« cut[2] führt demnach die Datenbankoperation Projektion auf Textdateien aus. Die Wikipedia erklärt das folgendermaßen[3]:

»Die Projektion entspricht der Projektionsabbildung aus der Mengenlehre und kann auch Attributbeschränkung genannt werden. Sie extrahiert einzelne Attribute aus der ursprünglichen Attributmenge und ist somit als eine Art Selektion auf Spaltenebene zu verstehen, das heißt, die Projektion blendet Spalten aus.«

Geschichtliches

Cut erblickte 1982 mit dem Release von UNIX System III das Licht der öffentlichen Welt. Wenn man die Quellen von System III durchforstet, findet man cut.c mit dem Zeitstempel 1980-04-11[4]. Das ist die älteste Implementierung des Programms, die ich aufstöbern konnte. Allerdings spricht die SCCS-ID im Quellcode von Version 1.5. Die Vorgeschichte liegt – der Vermutung Doug McIlroys[5] zufolge – in PWB/UNIX, dessen Entwicklungslinie die Grundlage für System III war. In den von PWB 1.0 (1977) verfügbaren Quellen[6] ist cut noch nicht zu finden. Von PWB 2.0 scheinen keine Quellen oder hilfreiche Dokumentation verfügbar zu sein. PWB 3.0 wurde später aus Marketinggründen als System III bezeichnet und ist folglich mit ihm identisch. Eine Nebenlinie zu PWB war CB UNIX, das nur innerhalb der Bell Labs genutzt wurde. Das Handbuch von CB UNIX Edition 2.1 vom November 1979 enthält die früheste Erwähnung von cut, die meine Recherche zutage gefördert hat: eine Manpage für cut[7].

Nun ein Blick auf die BSD-Linie: Dort ist der früheste Fund ein cut.c mit dem Dateimodifikationsdatum 1986-11-07[8] als Teil der Spezialversion 4.3BSD-UWisc[9], die im Januar 1987 veröffentlicht wurde. Die Implementierung unterscheidet sich nur minimal von der in System III. Im bekannteren 4.3BSD-Tahoe (1988) tauchte cut nicht auf. Das darauf folgende 4.3BSD-Reno (1990) enthielt aber wieder ein cut. Dieses cut war ein von Adam S. Moskowitz und Marciano Pitargue neu implementiertes cut, das 1989 in BSD aufgenommen wurde[10]. Seine Manpage[11] erwähnt bereits die erwartete Konformität mit POSIX.2. Nun muss man wissen, dass POSIX.2 erst im September 1992 veröffentlicht wurde, also erst gut zwei Jahre, nachdem Manpage und Programm geschrieben worden waren. Das Programm wurde folglich anhand von Arbeitsversionen des Standards implementiert. Ein Blick in den Code bekräftigt diese Vermutung. In der Funktion zum Parsen der Feldauswahlliste findet sich dieser Kommentar:

»This parser is less restrictive than the Draft 9 POSIX spec. POSIX doesn’t allow lists that aren’t in increasing order or overlapping lists.«

Im Draft 11.2 (1991-09) fordert POSIX diese Flexibilität bereits ein:

»The elements in list can be repeated, can overlap, and can be specified in any order.«

Zudem listet Draft 11.2 alle drei Modi, während in diesem BSD cut nur die zwei alten implementiert sind. Es könnte also sein, dass in Draft 9 der Bytemodus noch nicht vorhanden war. Ohne Zugang zu Draft 9 oder 10 war es leider nicht möglich, diese Vermutung zu prüfen.

Die Versionsnummern und Änderungsdaten der älteren BSD-Implementierungen kann man aus den SCCS-IDs, die vom damaligen Versionskontrollsystem in den Code eingefügt wurden, ablesen. So z.B. bei 4.3BSD-Reno: »5.3 (Berkeley) 6/24/90«.

Das cut der GNU Coreutils enthält folgenden Copyrightvermerk:

Copyright (C) 1997-2015 Free Software Foundation, Inc.
Copyright (C) 1984 David M. Ihnat

Der Code hat also recht alte Ursprünge. Wie aus weiteren Kommentaren zu entnehmen ist, wurde der Programmcode zuerst von David MacKenzie und später von Jim Meyering überarbeitet. Letzterer hat den Code 1992 auch ins Versionskontrollsystem eingestellt. Weshalb die Jahre vor 1997, zumindest ab 1992, nicht im Copyright-Vermerk auftauchen, ist unklar.

Trotz der vielen Jahreszahlen aus den 80er Jahren gehört cut, aus Sicht des ursprünglichen Unix, zu den jüngeren Tools. Wenn cut auch ein Jahrzehnt älter als Linux, der Kernel, ist, so war Unix schon über zehn Jahre alt, als cut das erste Mal auftauchte. Insbesondere gehörte cut noch nicht zu Version 7 Unix, das die Ausgangsbasis aller modernen Unix-Systeme darstellt. Die weit komplexeren Programme sed und awk waren dort aber schon vertreten. Man muss sich also fragen, warum cut überhaupt noch entwickelt wurde, wo es schon zwei Programme gab, die die Funktion von cut abdecken konnten. Ein Argument für cut war sicher seine Kompaktheit und die damit verbundene Geschwindigkeit gegenüber dem damals trägen awk. Diese schlanke Gestalt ist es auch, die der Unix-Philosophie entspricht: Mache eine Aufgabe und die richtig! cut überzeugte. Es wurde in andere Unix-Varianten übernommen, standardisiert und ist heutzutage überall anzutreffen.

Die ursprüngliche Variante (ohne -b) wurde schon 1985 in der System V Interface Definition, einer wichtigen formalen Beschreibung von UNIX System V, spezifiziert und tauchte anschließend in allen relevanten Standards auf. Mit POSIX.2 im Jahre 1992 wurde cut zum ersten Mal in der heutigen Form (mit -b) standardisiert.

Multibyte-Unterstützung

Nun sind der Bytemodus und die damit verbundene Multibyte-Verarbeitung des POSIX-Zeichenmodus bereits seit 1992 standardisiert, wie steht es aber mit deren Umsetzung? Welche Versionen implementieren POSIX korrekt? Die Situation ist dreiteilig: Es gibt historische Implementierungen, die nur -c und -f kennen. Dann gibt es Implementierungen, die -b zwar kennen, es aber lediglich als Alias für -c handhaben. Diese Implementierungen funktionieren mit Single-Byte-Encodings (z.B. US-ASCII, Latin1) korrekt, bei Multibyte-Encodings (z.B. UTF-8) verhält sich ihr -c aber wie -b (und -n wird ignoriert). Schließlich gibt es noch Implementierungen, die -b und -c tatsächlich POSIX-konform implementieren.

Historische Zwei-Modi-Implementierungen sind z.B. die von System III, System V und die aller BSDs bis in die 90er.

Pseudo-Multibyte-Implementierungen bieten GNU und die modernen NetBSDs und OpenBSDs. Man darf sich sicher fragen, ob dort ein Schein von POSIX-Konformität gewahrt wird. Teilweise findet man erst nach genauerer Suche heraus, dass -c und -n nicht wie erwartet funktionieren; teilweise machen es sich die Systeme auch einfach, indem sie auf Singlebyte-Zeichenkodierungen beharren, das aber dafür klar darlegen[12]:

»Since we don’t support multi-byte characters, the -c and -b options are equivalent, and the -n option is meaningless.«

Tatsächlich standardkonforme Implementierungen, die Multibytes korrekt handhaben, bekommt man bei einem modernen FreeBSD und bei den Heirloom Tools. Bei FreeBSD hat Tim Robbins im Sommer 2004 den Zeichenmodus POSIX-konform reimplementiert[13]. Warum die beiden anderen großen BSDs diese Änderung nicht übernommen haben, bleibt offen. Es scheint aber an der im obigen Kommentar formulierten Grundausrichtung zu liegen.

Wie findet man nun als Nutzer heraus, ob beim cut des eigenen Systems Multibytes korrekt unterstützt werden? Zunächst einmal ist entscheidend, ob das System selbst mit einem Multibyte-Encoding arbeitet, denn tut es das nicht, dann entsprechen sich Zeichen und Bytes und die Frage erübrigt sich. Man kann das herausfinden indem man sich das Locale anschaut, aber einfacher ist es, ein typisches Mehrbytezeichen, wie zum Beispiel einen Umlaut, auszugeben und zu schauen ob dieses in einem oder in mehreren Bytes kodiert ist:

$ echo ä  | od -c
0000000 303 244  n
0000003

In diesem Fall sind es zwei Bytes: oktal 303 und 244. (Den Zeilenumbruch fügt echo hinzu.)

Mit dem Programm iconv kann man Text explizit in bestimmte Kodierungen konvertieren. Hier Beispiele, wie die Ausgabe bei Latin1 und wie sie bei UTF-8 aussieht:

$ echo ä  | iconv -t latin1 | od -c
0000000 344  n
0000002
$ echo ä  | iconv -t utf8 | od -c
0000000 303 244  n
0000003

Die Ausgabe auf dem eigenen System (ohne die iconv-Konvertierung) wird recht sicher einer dieser beiden Ausgaben entsprechen.

Nun zum Test der cut-Implementierung. Hat man ein UTF-8-System, dann sollte sich eine POSIX-konforme Implementierung folgendermaßen verhalten:

$ echo ä  | cut -c 1 | od -c
0000000 303 244  n
0000003
 
$ echo ä  | cut -b 1 | od -c
0000000 303  n
0000002
 
$ echo ä  | cut -b 1 -n | od -c
0000000  n
0000001

Bei einer Pseudo-POSIX-Implementierung ist die Ausgabe in allen drei Fällen wie die mittlere: Es wird das erste Byte ausgegeben.

Implementierungen

Nun ein Blick auf den Code. Betrachtet wird eine Auswahl an Implementierungen.

Für einen ersten Eindruck ist der Umfang des Quellcodes hilfreich. Typischerweise steigt dieser über die Jahre an. Diese Beobachtung kann hier in der Tendenz, aber nicht in jedem Fall, bestätigt werden. Die POSIX-konforme Umsetzung des Zeichenmodus erfordert zwangsläufig mehr Code, deshalb sind diese Implementierungen tendenziell umfangreicher.

Verschiedene Implementierungen von cut

SLOC

Zeilen

Bytes

Gehört zu

Dateidatum

Kategorie

116

123

2966

System III

1980-04-11

(hist)

118

125

3038

4.3BSD-UWisc

1986-11-07

(hist)

200

256

5715

4.3BSD-Reno

1990-06-25

(hist)

200

270

6545

NetBSD

1993-03-21

(hist)

218

290

6892

OpenBSD

2008-06-27

(pseudo)

224

296

6920

FreeBSD

1994-05-27

(hist)

232

306

7500

NetBSD

2014-02-03

(pseudo)

340

405

7423

Heirloom

2012-05-20

(POSIX)

382

586

14175

GNU coreutils

1992-11-08

(pseudo)

391

479

10961

FreeBSD

2012-11-24

(POSIX)

588

830

23167

GNU coreutils

2015-05-01

(pseudo)

In der Tabelle mit »(hist)« bezeichnete Implementierungen beziehen sich auf ältere Implementierungen, die nur -c und -f kennen. Pseudo-Implementierungen, die -b zwar kennen, es aber nur als Alias für -c handhaben, sind mit »(pseudo)« gekennzeichnet. POSIX-konforme Implementierungen von cut sind mit »(POSIX)« markiert.

Das Kandidatenfeld teilt sich grob in vier Gruppen:

  1. Die zwei ursprünglichen Implementierungen, die sich nur minimal unterscheiden, mit gut 100 SLOCs
  2. Die fünf BSD-Versionen mit gut 200 SLOCs
  3. Die zwei POSIX-konformen Programme und die alte GNU-Version mit 340-390 SLOCs
  4. Und schließlich die moderne GNU-Variante mit fast 600 SLOCs

Die Abweichung zwischen logischen Codezeilen (SLOC, ermittelt mit SLOCcount) und der Anzahl von Zeilenumbrüchen in der Datei (wc -l) erstreckt sich über eine Spanne von Faktor 1,06 bei den ältesten Vertretern bis zu Faktor 1,5 bei GNU. Den größten Einfluss darauf haben Leerzeilen, reine Kommentarzeilen und die Größe des Lizenzblocks am Dateianfang.

Betrachtet man die Abweichungen zwischen den logischen Codezeilen und der Dateigröße (wc -c), so pendelt das Teilnehmerfeld zwischen 25 und 30 Bytes je Anweisung. Die Heirloom-Implementierung weicht mit nur 21 nach unten ab, die GNU-Implementierungen mit fast 40 nach oben. Bei GNU liegt dies hauptsächlich an deren Programmierstil, mit spezieller Einrückung und langen Bezeichnern. Ob man die Heirloom-Implementierung[14] als besonders kryptisch oder als besonders elegant bezeichnen will, das soll der eigenen Einschätzung des Lesers überlassen bleiben. Vor allem der Vergleich mit einer GNU-Implementierung[15] ist eindrucksvoll.

Die interne Struktur der Programmcodes (in C) ist meist ähnlich. Neben der obligatorischen main-Funktion, die die Kommandozeilenargumente verarbeitet, gibt es im Normalfall eine Funktion, die die Feldauswahl in eine interne Datenstruktur überführt. Desweiteren haben fast alle Implementierungen separate Funktionen für jeden ihrer Modi. Bei den POSIX-konformen Implementierungen wird die Kombination -b -n als weiterer Modus behandelt und damit in einer eigenen Funktion umgesetzt. Nur bei der frühen System III-Implementierung (und seiner 4.3BSD-UWisc-Variante) wird außer den Fehlerausgaben alles in der main-Funktion erledigt.

cut-Implementierungen haben typischerweise zwei limitierende Größen: Die Maximalanzahl unterstützter Felder und die maximale Zeilenlänge. Bei System III sind beide Größen auf 512 begrenzt. 4.3BSD-Reno und die BSDs der 90er Jahre haben ebenfalls fixe Grenzen (_BSD_LINE_MAX bzw. _POSIX2_LINE_MAX). Bei modernen FreeBSDs, NetBSDs, bei allen GNU-Implementierungen und bei Heirloom kann sowohl die Felderanzahl als auch die maximale Zeilenlänge beliebig groß werden; der Speicher dafür wird dynamisch alloziert. OpenBSD ist ein Hybrid aus fixer Maximalzahl an Feldern, aber beliebiger Zeilenlänge. Die begrenzte Felderanzahl scheint jedoch kein Praxisproblem darzustellen, da _POSIX2_LINE_MAX mit mindestens 2048 durchaus groß genug sein sollte.

Beschreibungen

Interessant ist zudem ein Vergleich der Kurzbeschreibungen von cut, wie sie sich in der Titelzeile der Manpages oder manchmal am Anfang der Quellcodedatei finden. Die folgende Liste ist grob zeitlich geordnet und nach Abstammung gruppiert:

CB UNIX:

»cut out selected fields of each line of a file«

System III:

»cut out selected fields of each line of a file«

System III (src):

»cut and paste columns of a table (projection of a relation)«

System V:

»cut out selected fields of each line of a file«

HP-UX:

»cut out (extract) selected fields of each line of a file«

4.3BSD-UWisc (src):

»cut and paste columns of a table (projection of a relation)«

4.3BSD-Reno:

»select portions of each line of a file«

NetBSD:

»select portions of each line of a file«

OpenBSD 4.6:

»select portions of each line of a file«

FreeBSD 1.0:

»select portions of each line of a file«

FreeBSD 10.0:

»cut out selected portions of each line of a file«

SunOS 4.1.3:

»remove selected fields from each line of a file«

SunOS 5.5.1:

»cut out selected fields of each line of a file«

Heirloom Tools:

»cut out selected fields of each line of a file«

Heirloom Tools (src):

»cut out fields of lines of files«

GNU coreutils:

»remove sections from each line of files«

Minix:

»select out columns of a file«

Version 8 Unix:

»rearrange columns of data«

»Unix Reader«:

»rearrange columns of text«

POSIX:

»cut out selected fields of each line of a file«

Die mit »(src)« markierten Beschreibungen sind aus dem jeweiligen Quellcode entnommen. Der POSIX-Eintrag enthält die Beschreibung im Standard. Der »Unix Reader[16]« ist ein rückblickendes Textdokument von Doug McIlroy, das das Auftreten der Tools in der Geschichte des Research Unix zum Thema hat. Eigentlich sollte seine Beschreibung der in Version 8 Unix entsprechen. Die Abweichung könnte ein Übertragungsfehler oder eine nachträgliche Korrektur sein. Alle übrigen Beschreibungen entstammen den Manpages.

Oft ist mit der Zeit die POSIX-Beschreibung übernommen oder an sie angeglichen worden, wie beispielsweise bei FreeBSD[17]. Interessant ist, dass die GNU coreutils seit Anbeginn vom Entfernen von Teilen der Eingabe sprechen, wohingegen die Kommandozeilenangabe klar ein Auswählen darstellt. Die Worte »cut out« sind vielleicht auch zu missverständlich. HP-UX hat sie deshalb präzisiert.

Beim Begriff, was selektiert wird, ist man sich ebenfalls uneins. Es wird von Feldern (POSIX), Abschnitten bzw. Teilen (BSD) oder Spalten (Research Unix) geredet. Die seltsame Beschreibung bei Version 8 Unix (»rearrange columns of data«) ist dadurch zu erklären, dass sie aus der gemeinsamen Manpage für cut und paste stammt. In der Kombination der beiden Werkzeuge können nämlich Spalten umgeordnet werden.

Autoreninformation

Markus Schnalke interessiert sich für die Hintergründe von Unix und seinen Werkzeugen. Für die Erarbeitung dieses Textes wurde er regelrecht zum Historiker.

Dieser Artikel ist in freiesMagazin 07/2015[18] (ISSN 1867-7991) erschienen. Veröffentlichung mit freundlicher Genehmigung.

Linkverweise:


[1] pubs.opengroup.org/onlinepubs/9699919799/utilities/cut.html#tag_20_28_17 
[2] man.cat-v.org/unix_8th/1/cut 
[3] de.wikipedia.org/wiki/Projektion_%28Informatik%29#Projektion 
[4] minnie.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/cmd 
[5] minnie.tuhs.org/pipermail/tuhs/2015-May/004083.html 
[6] minnie.tuhs.org/Archive/PDP-11/Distributions/usdl/ 
[7] ftp://sunsite.icm.edu.pl/pub/unix/UnixArchive/PDP-11/Distributions/other/CB_Unix/cbunix_man1_02.pdf 
[8] minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-UWisc/src/usr.bin/cut 
[9] gunkies.org/wiki/4.3_BSD_NFS_Wisconsin_Unix 
[10] minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut 
[11] minnie.tuhs.org/cgi-bin/utree.pl?file=4.3BSD-Reno/src/usr.bin/cut/cut.1 
[12] cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/cut/cut.c?rev=1.18&content-type=text/x-cvsweb-markup 
[13] svnweb.freebsd.org/base?view=revision&revision=131194 
[14] heirloom.cvs.sourceforge.net/viewvc/heirloom/heirloom/cut/cut.c?revision=1.6&view=markup 
[15] git.savannah.gnu.org/gitweb/?p=coreutils.git;a=blob;f=src/cut.c;hb=e981643 
[16] doc.cat-v.org/unix/unix-reader/contents.pdf 
[17] svnweb.freebsd.org/base?view=revision&revision=167101 
[18] www.freiesmagazin.de/20150705-juliausgabe-erschienen

 

[Raspberry Pi] Hausautomatisierung mit Raspberry Pi – Folge 4

Hausautomatisierung mit Raspberry Pi – Folge 4

08.10.2014 | 08:30 Uhr | Daniel Böber

http://bilder.pcwelt.de/3897729_75x75.jpg

Daniel Böber

Daniel Böber ist Geschäftsführer von Smarthome Agentur. Mehr

Autorenprofil schließen

Hausautomatisierung mit Raspberry Pi

VergrößernHausautomatisierung mit Raspberry Pi

© Daniel Böber

Haus- und Heimautomatisierung wird immer populärer – aber es gibt viele Standards und noch mehr Hersteller. Wenn man sich für ein Gesamtsystem entscheidet, ist man meist daran gebunden. Alternativ baut man das Ganze selber, so wie Daniel Böber.

 

Daniel Böber studiert Medieninformatik, sein Leben dreht sich um Technik, seit er denken kann. Vor allem interessieren ihn Trends und Projekte, die den Alltag erleichtern. Sie noch besser zu machen, ist Herausforderung für ihn. Auf http://siio.de stellt er seine Projekte vor.

In Folge 1 ging es um das Kennenlernen des Minicomputers Raspberry Pi und die grundlegende Inbetriebnahme.

In Folge 2 haben wir erklärt, wie wir das Ganze mit der passenden Hardware bestücken, die wir dann mit der intuitiven Software Pilight bedienen.

In Folge 3 haben wir die Heimautomatisierungs-Software Pimatic vorgestellt und die Zentrale dazu gebracht, einige Aufgaben selbstständig zu erledigen.

In dieser Folge geht es um die Installation eines digitalen Temperatursensors, der nebenbei die Luftfeuchtigkeit misst. Er ist sehr günstig und die Inbetriebnahme ist ein Kinderspiel. In der Praxis können Sie damit Heizungssteuerungen umsetzen oder Räume zur Schimmelprävention überwachen. Am Ende dieser Folge werden wir den Temperaturverlauf in übersichtlichen Diagrammen auswerten können.

Sie sollten sich die Folgen 1 bis 3 durchlesen, um die Programme Pilight und Pimatic zu verstehen. Wenn Sie das schon gemacht haben, sollten Sie jetzt auch ein Grundgefühl für den Umgang mit der Konsole haben. Ich stelle hier ein Image (ca. 1,5 GB) bereit, das den Stand am Ende von Folge 3 abbildet. Eine schöne Anleitung für die Image-Installation gibt es hier in Jan Karres Blog (Schritt 1 bis 3)

Das brauchen Sie für Folge 4:

<![if !supportLists]>·         <![endif]>Temperatursensor DHT22  (8 Euro)

<![if !supportLists]>·         <![endif]>Ein Widerstand 4,7 kOhm bis 10 kOhm (auch im Elektronikfachhandel) (10 Cent)

<![if !supportLists]>·         <![endif]>Schaltdraht  (3 Euro)

<![if !supportLists]>·         <![endif]>Lötkolben

<![if !supportLists]>·         <![endif]>Raspberry Pi mit installierter Software

Wenn Sie jetzt merken, dass Ihnen das Basteln viel Spaß macht, können Sie auch über ein Steckbrett mit Kabeln  nachdenken. Damit kann man sehr gut experimentieren, ohne jedesmal alles zu verlöten.

Anbringen des Temperatursensors

Der Sensor hat drei Anschlüsse: Plus, Masse und die Datenleitung. Man spricht auch von “One Wire”, denn es wird ja nur ein einziger Pin für die Kommunikation genutzt. Wie man es von Netzwerken kennt, hat jeder Sensor eine ID, wird vom Raspberry Pi angesprochen und gibt dann die Werte zurück.

Wer etwas Fantasie besitzt, merkt jetzt: Über eine Leitung können auch mehrere Sensoren hintereinander geschaltet und ausgelesen werden. Darauf möchte ich hier aber erst einmal nicht weiter eingehen.

Verkabelung des Temperatursensors

VergrößernVerkabelung des Temperatursensors

© Daniel Böber

Der Widerstand ist wichtig, um die Datenleitung bei Nichtbenutzung in einen festen Zustand zu versetzen. Es wäre sonst nicht klar, ob sie aktiv ist oder nicht. Ohne den Widerstand würden schon kleinste elektromagnetische Schwingungen reichen, um die Datenleitung zu beeinflussen.

Konfiguration der Software

Der Sensor wird in der Konfigurationsdatei von Pilight definiert. Von dort aus wird er automatisch an Pimatic übergeben, kann also dann in beiden Weboberflächen verwendet werden.

Ich liste hier gleich noch die Einstellungen für eine weitere Komponente auf, nämlich einen zweiten virtuellen Temperatursensor, der mit Daten eines Wetterdienstes gefüttert wird.

Als erstes loggen wir uns via SSH ins Raspberry Pi ein.

sudo service pilight stop

Pilight beenden. WICHTIG!

cd /etc/pilight/

Pilight Verzeichnis aufrufen.

sudo nano config.json

Konfiguration im Editor öffnen. Wir fügen folgende beiden “Devices” hinzu:

Konfiguration Codezeilen

VergrößernKonfiguration Codezeilen

© Daniel Böber

Achten Sie hier vor allem auf die “,” die nach den “}” kommen. Nur der letzte Block in der Konfiguration schließt NICHT mit Komma am Ende. “gpio :4″ ist der Pin, an dem der Sensor angeschlossen ist, hier im Beispiel wie in der Abbildung oben. Wenn alles fertig ist, speichern mit Strg+X -> Y(es) -> Enter.  

sudo service pilight start

Pilight wieder starten. Sollte das nicht klappen (es kommt die Meldung “[FAIL] Starting : pilight failed!”, können Sie nach Fehlern suchen. Das geht am einfachsten, indem Sie sich erst einmal die Log-Datei anschauen:

tail -f /var/log/pilight.log

Wenn es Fehler bei der Formatierung gibt, kommt etwa so eine Meldung im log-file:

[ Sep 22 16:36:29:88074] pilight-daemon: ERROR: config is not in a valid json format

Das war’s. Der Temperatursensor und die “Wetterstation” sind jetzt eingebunden. Sie haben damit eine genaue Temperaturmessung für den Raum und eine recht zuverlässige für die Außentemperatur. Beide Werte können wir jetzt in diversen Regeln kombinieren.

Temperaturdaten aufzeichnen

Um die Temperatur aufzuzeichnen, muss nicht viel gemacht werden. Pimatic hat bereits einen Data-Logger installiert. Sie sehen den Temperaturverlauf in der Weboberfläche und können einfach das Diagramm anklicken. Die Achsen können frei eingestellt werden, und Sie können so auch über mehrere Tage beobachten.

Die Dateiaufzeichnung im Web

VergrößernDie Dateiaufzeichnung im Web

© Daniel Böber

Der Temperatursensor in der Praxis

Zum Schluss noch ein kleines Praxisbeispiel. Für eine Heizungssteuerung fehlen uns noch die Heizregler, darum etwas anderes. Wir fügen Wetterdaten aus dem Internet für die Außentemperatur ein und lassen uns warnen, wenn es sinnvoll ist, das Fenster zu schließen. Die Regel sieht folgendermaßen aus:

Pilight Regel: Fenster offen

VergrößernPilight Regel: Fenster offen

© Daniel Böber

Hier wird, wenn die Außentemperatur 30 Minuten lang 2 °C höher als die Innentemperatur ist, eine Meldung ans Smartphone geschickt. Der “then” Teil ist hier beliebig. Es kann auch eine Mail verschickt oder ein Alarm ausgelöst werden.

Wie Sie die Infos bekommen, erfahren Sie in der nächsten und damit auch letzten Folge, in der es um die Einbindung des Smartphones geht. Ich zeige, wie Sie sich Push-Mitteilungen auf das Handy schicken können. Ihr Smart Home informiert damit über wichtige Ereignisse, etwa zu hohe Luftfeuchtigkeit, eine offene Tür oder auch die Anwesenheit von Personen. Folge 5 erscheint demnächst. 

Hinweis für alle Bastler:  Wenn auch Sie ein kreatives Projekt entwickelt haben, schreiben Sie uns. Wir würden Ihre Konstruktionen, nützlich oder einfach nur schräg, gern im Hacks-Bereich auf www.pcwelt.de vorstellen. Schreiben Sie an Birgit Götz – bgoetz@pcwelt.de.