Projekte Tech-Blogging by Thomas Winkler 2020-07-03T01:12:00+00:00 Thomas Winkler https://prismplex.io/blog [Protocol Multiplexer] SSLH https://prismplex.io/de/blog/sslh-protocol-multiplexer 2020-07-03T01:12:00+00:00 2020-07-03T01:12:00+00:00

Einleitung

Zuletzt war ich an einem internationalen Flughafen unterwegs und wollte etwas im Internet über das Flughafen-WLAN surfen. Nach allen möglich Angaben über meine Haustiere, näheren Verwandten und Lieblingsbars, die ich selbstverständlich absolut wahrheitsgemäß beantwortet habe, war ich dann auch letztendlich mit dem Internet verbunden. Jetzt gehört meine Wenigkeit jedoch zu jenen paranoiden, die grundsätzlich bei öffentlichen WLANs, bei denen ich den Administrator nicht kenne, bzw. auch nicht weiß, welche Sicherheitsmaßnahmen dieser integriert hat, ein VPN benutzt. Also öffne ich eine x-beliebige VPN-App, möchte mich verbinden, kann aber nicht. Nach einigen Sekunden wird mir dann auch klar warum. Alle Ports außer der http (80) und https (443) sind gesperrt. Nun hatte ich das Glück, dass mein VPN-Betreiber auch diese Ports unterstützen konnte, letztendlich fragte ich mich jedoch, ob es möglich wäre in Zukunft für so eine Eventualität auch mit dem heimischen VPN gerüstet zu sein. Auf meinem Server lief bereits ein OpenVPN über den gewohnten Port 1194, der mir in dieser Situation natürlich nicht viel nutzte. Gab es also eine Möglichkeit, den Port 443 für mehrere Anwendungen zu benutzen? Nach etwas Recherche fand ich dann auch, was ich brauchte - einen sog. Protocol Multiplexer namens SSLH. Die Konfiguration des Ganzen war nicht allzu einfach, daher hier mein Konfigurationsvorschlag für jene, die Ähnliches vorhaben.

Konfigurationsdateien

/etc/sslh.cfg

# Default Arch configuration
# You can find more examples in /usr/share/doc/sslh

timeout: 2;
foreground: true;
transparent: true;

listen:
(
    { host: "internal-network-adress"; port: "443"; }
);

protocols:
(
     { name: "ssh"; service: "ssh"; host: "localhost"; port: "22"; probe: "builtin"; },
     { name: "openvpn"; host: "localhost"; port: "1195"; probe: "builtin"; },
     { name: "xmpp"; host: "localhost"; port: "5222"; probe: "builtin"; },
     #{ name: "http"; host: "localhost"; port: "80"; probe: "builtin"; },
     { name: "tls"; host: "localhost"; port: "443"; probe: "builtin"; },
     { name: "anyprot"; host: "localhost"; port: "443"; probe: "builtin"; }
);

# vim:set ts=4 sw=4 et:

/usr/lib/systemd/system/sslh.service

[Unit]
Description=SSL/SSH multiplexer (socket mode)
Conflicts=sslh-fork.service sslh-select.service
Requires=sslh.socket
PartOf=sslh.socket

[Service]
ExecStart=/usr/bin/sslh --config --foreground
KillMode=process
ProtectSystem=strict
ProtectHome=true
ProtectKernelModules=true
ProtectKernelTunables=true
ProtectControlGroups=true
PrivateTmp=true
PrivateDevices=true
SecureBits=noroot-locked
MountFlags=private
NoNewPrivileges=true
CapabilityBoundingSet=CAP_SETGID CAP_SETUID CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_BIND_SERVICE
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
MemoryDenyWriteExecute=true
User=sslh
DynamicUser=true

sudo systemctl daemon-relod und sudo systemctl start sslh.service, sowie sudo systemctl enable sslh.service

Nginx umkonfigurieren

Nachdem mein Nginx standardmäßig auf dem 443 Port lauscht, muss hier einiges verändert werden: /etc/ngins/sites-enabled/site-xyz.conf

    server {
        listen 80;
        listen [::]:80;
        server_name domain.com;
        return 301 https://domain.com$request_uri;
    }

    server {
        listen 127.0.0.1:443 ssl; #http2;
        listen [::1]:443 ssl; #http2;
        server_name domain.com;
        server_tokens off;
    ...
    }

Externe IP-Adresse an den Server weitergeben (transparent mode)

/etc/sslh/iptables.sh

!/bin/bash

# Set route_localnet = 1 on all interfaces so that ssl can use "localhost" as destination
sysctl -w net.ipv4.conf.default.route_localnet=1
sysctl -w net.ipv4.conf.all.route_localnet=1

# DROP martian packets as they would have been if route_localnet was zero
# Note: packets not leaving the server aren't affected by this, thus sslh will still work
iptables -t raw -A PREROUTING ! -i lo -d 127.0.0.0/8 -j DROP
iptables -t mangle -A POSTROUTING ! -o lo -s 127.0.0.0/8 -j DROP

# Mark all connections made by ssl for special...
]]>
[KVM/QEMU] Cloud Gaming auf dem heimischen Linux Server https://prismplex.io/de/blog/cloud-gaming-selbstgebaut 2020-07-02T20:30:00+00:00 2020-07-02T20:30:00+00:00

Hintergrund

Immer mehr Anbieter stellen Cloud Gaming Server bereit, auf denen Kunden, die zuhause keine gute Grafikkarte (am Prozessor liegt es ja meistens nicht) im PC bzw. Laptop verbaut haben, ihre Spiele spielen und auf das heimische Gerät streamen können. Voraussetzung dafür ist natürlich eine entsprechend schnelle Internetverbindung. In die Details der Technik, die dahintersteckt möchte ich jetzt nicht eingehen, hier eine wirklich kurze Zusammenfassung: Der Client verfügt über eine Software, die alle Tastaturbefehle und Mauseingaben an einen Server weiterleitet auf dem das jeweilige Spiel läuft und wieder an den Client zurückgestreamt wird.

Ich habe mich gefragt, ob man sowas auch auf dem heimischen Server zum laufen bekommen könnte. Der Gedanke war recht simpel, die Umsetzung leider weniger. Zuallererst musste ein neues Gehäuse her, denn im alten Mini-ITX Gehäuse war neben den vielen Festplatten wenig Platz für eine ensprechend potente Grafikkarte. Auf meinem heimischen Server läuft ein Linux auf Arch Linux Basis (Manjaro), das natürlich nicht wirklich zum Gaming geeignet ist. Leider verstehe ich bis heute nicht, warum man die ganzen Verkaufsschlager nicht auch für Linux entwickeln kann, aber zum Glück gibt es im Open-Source Sektor potente Virtualiserungssoftware, nämlich KVM bzw. Qemu.

Voraussetzungen

Erstmal ist sicherzustellen, dass die Hardware passt:

Grafikkarte

  • Eine NVIDIA Grafikkarte (NVIDIA Shield in Kombination mit dem Open Source Client Moonlight ist die Software, die zumindest ich zum Game-Streamen verwende und die meiner Meinung nach neben Parsec die beste ist)

Prozessor und Mainboard

  • Virtualisierung (VT-d bei Intel bzw. AMD-V bei AMD)
  • IOMMU Unterstützung (aktuelle Mainboards und Prozessoren siehe hier: Wikipedia, eine weitere Liste siehe hier: passthroughpo.st. Grob gesagt sind aktuelle Mainboards mit dem Chipsatz Z370 keine schlechte Wahl. Soweit ich das verstanden habe, sollten diese (zumindest von der Firma Asrock) alle IOMMU unterstützen.)
  • Grafikkarte mit UEFI-Unterstützung (bei den aktuellen Modellen der Hersteller eher weniger das Problem)

RAM

  • Zu empfehlen sind 16GB oder mehr

Eine einfache Überprüfung, ob die Hardware so passt, liefert (zumindest unter Arch Linux (Derivaten) folgender Befehl: dmesg|grep -e DMAR -e IOMMU, der in diese Antwort hervorbringen solle: DMAR: IOMMU enabled

Umsetzung

  1. Als Erstes ein komplettes Systemupdate mit sudo pacman -Syu oder analog pikaur (sehr zu empfehlen, falls jemand Pakete aus dem AUR installiert hat)
  2. sudo pacman -S nano, falls nano noch nicht installiert ist. Anschließend sudo nano /etc/default/grub. In der Zeile GRUB_CMDLINE_LINUX_DEFAULT folgendes hinzufügen intel_iommu=on (oder analog für AMD-Prozessoren amd_iommu=on) und davor in der gleichen Zeile iommu=pt, falls man plant den ACS-Patch (siehe unten) zu nutzen, optional noch pcie_acs_override=downstream.
    Im nächsten Schritt ein Befehl zum updaten vom GRUB-Bootmenü: sudo update-grub. Die Zeile sollte dann bisher folgendermaßen (Beispiel AMD) aussehen: GRUB_CMDLINE_LINUX_DEFAULT="iommu=pt amd_iommu=on ...
  3. Nächster Befehl: lspci -nn. Ergebnis des Ganzen wird eine Liste an allen aktuell angeschlossenen PCI-Geräten sein mit entsprechender Hardware ID. In der Liste muss nun die Grafikkarte gefunden werden; fällt dies schwer, kann man zur Vereinfachung der List auch diesen Befehl wählen, der dann hoffentlich nur die Grafikkarte ausgibt: lspci -nn|grep -iP "NVIDIA|Radeon".
  4. Ist die Adresse der GPU herausgefunden, notiert/kopiert...
]]>
[DNS] Eigener DNS Server mit DNSCrypt https://prismplex.io/de/blog/dns-server-dnscrypt 2020-06-21T20:17:00+00:00 2020-06-21T20:17:00+00:00

Einleitung

In Zeiten von Provider DNS blocking eine schnellere, einfachere und genauso effektive Methode um gesperrte Webseiten zu erreichen.

Server (Docker)

Mithilfe von Docker lässt sich durch einen Befehl schnell ein eigener DNSCrypt-Server starten.

sudo docker run --name=dnscrypt-server -p external-port:internal-port/udp -p external-port:internal-port/tcp --net=host \
--ulimit nofile=90000:90000 --restart=unless-stopped \
-v /key-directory:/opt/encrypted-dns/etc/keys \
jedisct1/dnscrypt-server init -N domain.name -E 'domain.ip:external-port'

Anschließend kann man mithilfe von sudo docker logs dnscrypt-server die entsprechende "DNS Stamp" für die Clientkonfiguration auslesen und dann ganz unten in der dnscrypt-proxy.toml des Clients einfügen.

Client

Unter Linux installiert man sich einfach den dnscrpyt-proxy, unter Arch Linux mit sudo pacman -S dnscrypt-proxy. Anschließend fügt man die vorher herauskopierte "DNS Stamp" in der Datei /etc/dnscrypt-proxy/dnscrypt-proxy.toml ganz unten entsprechend in der Datei genannten Syntax ein. Ein Anpasen der resolv.conf mit Verweis auf 127.0.0.1, sudo systemctl start dnscrypt-proxy und sudo systemctl enable dnscrypt-proxy genügen, um ab sofort über DNSCrypt DNS-Anforderungen zu senden und zu erhalten.

]]>
[Read it later] Pocket/Read it later self-hosted https://prismplex.io/de/blog/wallabag-self-hosted 2020-06-21T19:30:00+00:00 2020-06-21T19:30:00+00:00

Einleitung

Read it later Dienste können ganz praktisch sein, um interessante Artikel, die man im Netz findet (und für die man gerade keine Zeit hat, sie zu lesen), zu archivieren und bei Gelegenheit und Zeiten zu lesen. Bekanntester Dienst hierfür ist z.B. Pocket. Das Open Source Pendant dazu heißt Wallabag. Anbei eine schnelle Anleitung, wie man den Dienst auf seinem eignen Server mit Docker zum Laufen bringt.

Docker

docker-compose.yml

version: '3'
services:
  wallabag:
    image: wallabag/wallabag
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
      - SYMFONY__ENV__DATABASE_DRIVER=pdo_mysql
      - SYMFONY__ENV__DATABASE_HOST=db
      - SYMFONY__ENV__DATABASE_PORT=3306
      - SYMFONY__ENV__DATABASE_NAME=wallabag
      - SYMFONY__ENV__DATABASE_USER=wallabag
      - SYMFONY__ENV__DATABASE_PASSWORD=wallapass
      - SYMFONY__ENV__DATABASE_CHARSET=utf8mb4
      #- SYMFONY__ENV__MAILER_HOST=smtp.host.com
      - SYMFONY__ENV__MAILER_HOST=smtp
      #- SYMFONY__ENV__MAILER_USER=email@from.com
      #- SYMFONY__ENV__MAILER_PASSWORD=password
      - SYMFONY__ENV__FROM_EMAIL=email@from.com
      - SYMFONY__ENV__DOMAIN_NAME=https://wallabag.domain.com
      - SYMFONY__ENV__FOSUSER_REGISTRATION=true
    ports:
      - "127:0.0.1:8500:80"
    volumes:
      - ./images:/var/www/wallabag/web/assets/images

  smtp:
    image: namshi/smtp
    restart: unless-stopped

  db:
    image: mariadb
    restart: unless-stopped
    environment:
      - MYSQL_ROOT_PASSWORD=wallaroot
    command: ["--character-set-server=utf8mb4",  "--collation-server=utf8mb4_unicode_ci"]
    volumes:
      - ./db:/var/lib/mysql
  redis:
    image: redis:alpine
    restart: unless-stopped

Im gleichen Verzeichnis dann sudo docker-compsoe up -d

Warte ca. 5 Minuten, bis im sudo docker-compsoe logs folgendes auftaucht: wallabag_1 | Provisioner finished. Dann folgt jetzt die abschließende Konfiguration (soll in den neueren Wallabag-Versionen nicht mehr manuell nötig sein): sudo docker exec -t your-wallabag-container /var/www/wallabag/bin/console wallabag:install --env=prod --no-interaction, danach sudo docker-compose restart und dann heißt es wieder warten bis wallabag_1 | Provisioner finished. in den Container Logs auftaucht.

Reverse proxy (nginx)

Reverse proxy konfigurieren: sudo nano /etc/nginx/sites-enabled/wallabag.domain.com.conf

upstream wallabag {
    server 127.0.0.1:8500;
    keepalive 512;
}

server {
   listen 80;
   listen [::]:80;
   server_name wallabag.domain.com www.wallabag.domain.com;
   return 301 https://wallabag.domain.com$request_uri;
}

server {
   listen 127.0.0.1:443 ssl;
   listen [::1]:443 ssl; #HTTPS IPv6 support
   server_name wallabag.domain.com www.wallabag.domain.com;
   server_tokens off;

   # Add headers to serve security related headers
   # Before enabling Strict-Transport-Security headers please read into this
   # topic first.
   add_header Strict-Transport-Security "max-age=15768000;
   # includeSubDomains; preload;";
   #
   # WARNING: Only add the preload option once you read about
   # the consequences in https://hstspreload.org/. This option
   # will add the domain to a hardcoded list that is shipped
   # in all major browsers and getting removed from this list
   # could take several months.
   add_header X-Content-Type-Options nosniff;
   add_header X-XSS-Protection "1; mode=block";
   add_header X-Robots-Tag none;
   add_header X-Download-Options noopen;
   add_header X-Permitted-Cross-Domain-Policies none;

   #charset utf-8;

   ssl_certificate /ssl-directory/fullchain.pem;
   ssl_certificate_key /ssl-directory/privkey.pem;
   ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
   ssl_prefer_server_ciphers   on;
   # used cloudflares ciphers https://github.com/cloudflare/sslconfig/blob/master/conf
   ssl_ciphers EECDH+CHACHA20:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!MD5;
   ssl_dhparam /etc/ssl/certs/dhparam.pem;

   #Logging accesses and errors - change to PATH according your needs
   access_log /access-log-directory/access.wallabag.log;
   error_log /error-log-directory/error.wallabag.log;

   client_max_body_size 16G; # set max upload size depending on your desires
   fastcgi_buffers 64 4K;

   location / {
   #     auth_basic "Root Login";
   #     auth_basic_user_file /if-you-want-a-plus-password-prompt/htpasswd;
        include /etc/nginx/conf.d/proxy.conf;
        proxy_pass http://wallabag;
   }

   location /nginx_status {
        stub_status on;    # activate stub_status module
        access_log off;
        allow 127.0.0.1;   # restrict access to local only
        deny all;
    }

}

sudo nano /etc/nginx/conf.d/proxy.conf

client_max_body_size 10m;
client_body_buffer_size 128k;

#Timeout if the real server is dead
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;

# Advanced Proxy Config
send_timeout 5m;
proxy_read_timeout 240;
proxy_send_timeout 240;
proxy_connect_timeout 240;

# Basic Proxy Config
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto https;
proxy_redirect  http://  $scheme://;
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_cache_bypass $cookie_session;
proxy_no_cache $cookie_session;
proxy_buffers 32 4k;

Quellen

]]>
[VPN] Wireguard VPN via Docker mit Webinterface (Updated) https://prismplex.io/de/blog/wireguard-server-docker 2020-06-20T19:30:00+00:00 2020-06-20T19:30:00+00:00

Einleitung

VPNs werden immer beliebter, um die Privatsphäre zu schützen. Ich möchte hier ein kurzes Tutorial zu einem VPN auf wireguard-Basis in einem Docker-Contaier geben.

Kernel Modules

Bevor man Wireguard (mit diesem Docker Image) in einem Docker Container laufen lassen kann, muss man zuerst die Kernel Header und das Kernel Modul installieren. Unter Manjaro geht das so:

$ sudo pacman -S linux-headers

Anmerkung: Es wird nun gefragt, welchen Header er installieren soll, man wählt hier den Header für die Version des installieren Linux Kernels aus. Wenn man gerade nicht weiß, welche Version man installiert hat, kann man das über diesen Befehl herausfinden: uname -r

Als nächstes installiert man das Kernel Modul über diesen Befehl:

sudo pacman -S dkms wireguard-dkms wireguard-tools

Wireguard im Docker Container

Als erstes sucht man sich einen Ordner und erstellt in diesem als Beispielkonfiguration (updated) folgende docker-compose.yml:

version: "2"
services:
 vpn:
  image: cmulk/wireguard-docker
  container_name: wireguard
  volumes:
   - ./etc-wireguard:/etc/wireguard
  networks:
   - net
  ports:
   - port-external:port-internal/udp
  restart: unless-stopped
  cap_add:
   - NET_ADMIN
   - SYS_MODULE
  environment:
   - IPTABLES_MASQ=1

 wg-gen-web:
  image: vx3r/wg-gen-web:latest
  container_name: wg-gen-web
  restart: unless-stopped
  ports:
   - port-external:8080
  environment:
   - WG_CONF_DIR=/data
   - WG_INTERFACE_NAME=wg0.conf
   - SMTP_HOST=mailserver.example.com
   - SMTP_PORT=465
   - SMTP_USERNAME=mail@example.com
   - SMTP_PASSWORD=password
   - SMTP_FROM=Wg Gen Web <mail@example.com>
   - OAUTH2_PROVIDER_NAME=oauth2oidc
   - OAUTH2_PROVIDER=https://gitlab.example.com
   - OAUTH2_CLIENT_ID=*
   - OAUTH2_CLIENT_SECRET=*
   - OAUTH2_REDIRECT_URL=https://wireguard.example.com
  volumes:
      - ./etc-wireguard:/data

networks:
  net:

Updated (automatische Konfiguration über das Webinterface)

Als nächstes erstellt man zwei Dateien, damit sich bei Änderungen über das Webinterface der wireguard docker container neu startet.

  1. sudo nano /etc/systemd/system/wg-gen-web.path

    [Unit]
    Description=Watch etc-wireguard for changes
    [Path]
    PathModified=/path/of/docker-wireguard-config/etc-wireguard
    [Install]
    WantedBy=multi-user.target
  2. sudo nano /etc/systemd/system/wg-gen-web.service

    [Unit]
    Description=Restart WireGuard Docker
    After=network.target
    [Service]
    Type=oneshot
    ExecStart=/usr/bin/docker restart wireguard
    [Install]
    WantedBy=multi-user.target
  3. sudo systemctl daemon-reload

nginx Konfiguration

sudo nano /etc/nginx/sites-enabled/wireguard.example.com.conf Hier den Reverse Proxy je nach vergebener Portnummer konfigurieren.

Archiv (manuelle Konfiguration ohne Webinterface)

Als nächstes erstellt man über mkdir etc-wireguard den entsprechenden Ordner für die Konfiguarationsdateien. server.conf

[Interface]
Address = 192.168.20.1/24
PrivateKey = <server-private-key>
ListenPort = 7777

[Peer]
PublicKey = <client-public-key>
AllowedIPs = 192.168.20.2

*client.config

[Interface]
Address = 192.168.20.2/24
PrivateKey = <client-private-key>
ListenPort = 0 #needed for some clients to accept the config

[Peer]
PublicKey = <server-public-key>
Endpoint = 24.134.225.237:7777
AllowedIPs = 0.0.0.0/0,::/0 #makes sure ALL traffic routed through VPN
PersistentKeepalive = 25

Die entsprechenden "private-keys" und "public-keys" lassen sich zum Beispiel über die Android-App oder die iOS-App. Jeweils zwei Konfigurationen anfangen zu erstellen und dort die entsprechenden Schlüssel generieren. Das ganze macht man zweimal, einmal für den Server und einmal für den Client und modifiziert dann die jeweiligen Konfiguarationsdateien. Die fertige Client-Konfiguration lässt sich dann einfach importieren. Zum Schluss wechselt man wieder in den Oder der "docker-compose.yml" und startet den Conatainer per sudo docker-compose up -d

Quellen

]]>
[DNS] DNSCrypt und Pi-hole auf einem Raspberry Pi 3 mit Autoupdate https://prismplex.io/de/blog/dnscrypt-pihole-raspberry 2019-07-24T16:50:00+00:00 2019-07-24T16:50:00+00:00

Einleitung

Vor einiger Zeit stieß ich auf einen Artikel zu DNS-Abfragen und die Rolle des Providers. Ich möchte diesen Artikel nur kurz aufs Wesentliche herunterbrechen: Jede Adresse, die man in die Adresszeile seines Browsers eingibt, landet bei einem sogenannten DNS-Server, der zur eingegebenen Webadresse die jeweilig zugehörige IP-Adresse abfragt und den Nutzer dann entsprechend auf den Zielserver weiterleitet. Nun ergibt sich bei genauerer Überlegung folgende Problematik: Heutzutage verwendet fast jede Webseite, die etwas von sich hält "https" also Webkommunikation über TLS-Verschlüsselung (zum Glück immer seltener SSL-Verschlüsselung). Die Anfragen an den DNS-Server sind jedoch unverschlüsselt, d.h. theoretisch könnte es jemanden mit entsprechendem Wissen gelingen, Anfragen, die an den DNS-Sender gesendet werden, entsprechend zu manipulieren und dann bei einem Aufruf von z.B. duckduckgo.com eine andere Adresse anzuzeigen. Freilich wird das dann schwieriger das "https"-Zertifikat zu fälschen, hierzu bräuchte der Angreifer Zugriff auf die DNS-Einstellungen der jeweiligen Domain. Aber eine "http"-Seite, ohne entsprechende Verschlüsselung, ließe sich damit theoreitsch relativ leicht, ohne Wissen den Nutzers umleiten, sogenanntes "DNS spoofing". Neben dem "DNS spoofing" muss man sich noch einer Tatsache bewusst werden. Standardmäßig surft man immer über den DNS-Server des eigenen Internetproviders. Im Klartext heißt das, dass dieser theoretisch jede Abfrage mitloggen kann und so jederzeit nachvollziehen kann, welcher Benutzer mit welcher IP zu welchen Zeiten auf welchen Webseiten war. Was den Datenschutz angeht, ist das höchst fragwürdig...

Um sich dagegen zu schützen, gibt es zwei Möglichkeiten:

  1. Eine Verschlüsselte zum DNS-Server über "https" (DoH)
  2. DNSCrypt mithilfe von verschiednen "private keys" und "public keys"

Hypriot OS

Als erstes installiert man sich Hypriot OS. Flashen der heruntergeladenen .zip Datei gelingt am besten mit balena Etcher. Nach erneutem mounten der SD-Karte sollte eine Partition namens "Hypriot OS" erscheinen. Hier sucht man die Datei user-data und bearbeitet diese nach Wünschen. Eine Beispielkonfiguration:

#cloud-config
# vim: syntax=yaml
#

# The current version of cloud-init in the Hypriot rpi-64 is 0.7.6
# When dealing with cloud-init, it is SUPER important to know the version
# I have wasted many hours creating servers to find out the module I was trying to use wasn't in the cloud-init version I had
# Documentation: http://cloudinit.readthedocs.io/en/0.7.9/index.html

# Set your hostname here, the manage_etc_hosts will update the hosts file entries as well
hostname: prismplex.hole
manage_etc_hosts: true

# You could modify this for your own user information
users:
  - name: username
    gecos: "Prismplex Hole"
    sudo: ALL=(ALL) NOPASSWD:ALL
    shell: /bin/bash
    groups: users,docker,video,input
    plain_text_passwd: hypriot
    lock_passwd: false
    ssh_pwauth: true
    chpasswd: { expire: false }

# # Set the locale of the system
# locale: "en_GB.UTF-8"

# # Set the timezone
# # Value of 'timezone' must exist in /usr/share/zoneinfo
timezone: "Europa/Berlin"

# # Update apt packages on first boot
package_update: true
package_upgrade: true
# package_reboot_if_required: true

# # Install any additional apt packages you need here
# packages:
#  - ntp
#  - dnscrypt-proxy

# Static IP address
write_files:
  - content: |
      persistent
      # Generate Stable Private IPv6 Addresses instead of hardware based ones
      slaac private
      # static IP configuration:
      interface eth0
      static ip_address=#ip-address/24
      static ip6_address=#ip-address/64
      static...
]]>
Neue Webseite https://prismplex.io/de/blog/neue-webseite 2017-08-23T13:07:00+00:00 2017-08-23T13:07:00+00:00

Neue Webseite prismplex.tech

Nach langer Arbeit habe ich meine Hauptseite aktualisiert. Im Hintergrund arbeiten GRAV, CSS-Bibliotheken (Pure CSS) und diverse Skripte (AOS.js, lightslider.js).

]]>