Beiträge von onetwobarbecue

Liebe QNAP-Gemeinde,

da ja nun schon seit einiger Zeit ein Office mit der File Station verzahnt ist, wollte ich fragen, ob jemand schon einmal erfolgreich die File Station als WOPI-Backend für Collabora/LibreOffice Online eingerichtet hat.

Da ich keine QNAP-ID verwende und das eigentlich auch zukünftig nicht möchte, funktioniert bei mir die Office-Bearbeitung nicht per File Station. Außerdem betreibe ich mehrere Services, in die ich gerne Collabora integrieren möchte (Kopano und Mattermost). Andererseits reichen mir die QNAP-Bordmittel (FileStation und WebDAV) vollkommen als Filesharing-Lösung aus und ich möchte eher nicht zusätzlich noch Nextcloud betreiben.

Collabora benötigt zum Betrieb einen WOPI-Server (wie NextCloud). Aber auch die File Station arbeitet mit WOPI, wie man hier nachlesen kann: Editing Documents in File Station

Deshalb müsste es doch eigentlich machbar sein, die FileStation direkt als WOPI-Server für Collabora/Libre Office Online zu verwenden.

Hat hier jemand vielleicht Erfahrung oder Tipps?

Beste Grüße,

Marco (OneTwo)

Hallo

"Sehr fit" wäre schön - bin ich aber gewiss nicht. Deshalb kann ich Dir leider nur meine NGINX-config geben. Damit funktioniert auch der VNC-Zugang auf die virtuellen Maschinen der Virtualization Station im Browser (bei mir Firefox). Was nicht funktioniert ist der Consolenzugang auf Container der Containerstation im Browser, aber das ist mir aus Sicherheitsgründen auch recht.

Hier die config für den ssl Block bzw. den Port 443, sofern er über die entsprechende Subdomain angesprochen wird:

upstream qnapbackend {
   server 192.168.....:....; # hier die LAN-IP und den SSL-Port der QNAP eintragen
   keepalive 32;
   }

server {
    listen 443 ssl http2;
    server_name SUBOMAIN.* www.SUBDOMAIN.*; # hier die Sub-Domain eintragen, die man als Weiterleitung verwenden möchte

    location / {
       client_max_body_size 1000M;
       add_header Vary Accept-Encoding;
       proxy_hide_header Upgrade;
       proxy_cookie_path / "/; HTTPOnly; Secure";
       proxy_set_header Connection "";
       proxy_set_header Host $http_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 $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_pass https://qnapbackend;
       proxy_buffering off;
       #proxy_http_version 2;
    }

    ssl_certificate /etc/letsencrypt/live/DEINDOMAINNAME.DE/fullchain.pem; # managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/DEINDOMAINNAME.DE/privkey.pem; # managed by Certbot
    ssl_session_timeout 1d;
    keepalive_timeout 300s;
    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256';
    ssl_prefer_server_ciphers on;
    add_header Strict-Transport-Security max-age=15768000;
    ssl_stapling on;
    ssl_stapling_verify on;

    location ~ /qvs {
       proxy_set_header Upgrade $http_upgrade;
       proxy_set_header Connection "upgrade";
       client_max_body_size 100M;
       proxy_set_header Host $http_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 $scheme;
       proxy_set_header X-Frame-Options SAMEORIGIN;
       proxy_buffers 256 16k;
       proxy_buffer_size 16k;
       client_body_timeout 60;
       send_timeout 300;
       lingering_timeout 5;
       proxy_connect_timeout 90;
       proxy_send_timeout 300;
       proxy_read_timeout 600s;
       proxy_pass https://qnapbackend;
    }
}

Ich kann Dir viele der Config-Parameter nicht erläutern. Die meisten habe ich von der QNAP selbst übernommen, nachdem ich mir dort die Einstellungen des Web-Servers angeschaut habe. Wenn ich mich recht erinnere läuft auf der QNAP ein Apache - vielleicht findest Du dort ja sogar die richtigen Einstellungen für deinen Webserver.

Damit alle Anfragen von http auf https umgeleitet werden reicht bei NINX folgende config-Einstellung aus:

server {
    listen 80;
    if ($scheme != "https") {
        return 301 https://$host$request_uri;
    }
}

Ich hoffe das hilft Dir ein wenig.

Falls jemand Sicherheitsrelevante Bedenken zu den Einstellungen hat würde ich mich freuen, hier davon zu erfahren.

Liebe Grüße,

Marco

Ein herzliches Hallo in die Runde,

weiß jemand, ob es endlich Bewegung in der Sache gibt?

Ich würde gerne meine kleinen Fotoapparat-Filme transkodieren lassen, um sie mobil streamen zu können. Leider nimmt die (Sony-)Kamera in ac3 auf und die Transkodierung schlägt aus bekanntem Grund fehl.

Plant QNAP endlich, eine Kaufmöglichkeit für die fehlenden Codecs zu implementieren? Das wäre doch nun wirklich eine gute Sache.

Herzliche Grüße,

OneTwo

Liebe QNAP-Gemeinde,

ich habe bemerkt, dass es unter /AdressederQNAP/photo/m/ eine mobile Variante des Photostation-Webinterfaces gibt (siehe Anhang).

Nur leider ist es dort nicht möglich, sich einzuloggen? Nach Eingabe einer korrekten Benutzername/Passwort-Kombination werden die Felder schlicht gelöscht und die Seite bittet erneut um Login.

Ein mobiles Webinterface wäre aber toll, weil man damit Dritten auf einfache Art und Weise einen Zugang ermöglichen könnte, ohne dass sie gleich die App installieren müssen.

Hat jemand das Photostation-Mobile-Webinterface in Betrieb und kann mir helfen?

Liebe Grüße,

OneTwo

Liebe QNAP-Gemeinde,

da ich viel mit VMs rumexperimentiere, könnte meine TS-253A ein Memory-Upgrade vertragen. Nun habe ich einerseits in der Datenbank gelesen, dass einige allem Anschein nach die TS-253A auf 16GB aufgerüstet haben, andererseits sagen die Tec-Specs des verbauten Prozessors, dass dieser nur 8GB ansprechen kann: Specs N3150 Specs N3160

Daher die Frage: Sind 16GB in der TS-253A nutzbar oder nicht?

Liebe Grüße,

Marco

Danke für die Rückmeldung - ich dachte IPv6 wäre so universell, dass die IPv6 nicht nur im LAN sondern auch im WAN gültig wäre. Aber da muss ich mich mal gescheit einlesen.

Tatsächlich scheint die Fritze wohl IPv6 generell zu blocken, sofern es keine Portforwarding-Regeln gibt. Gibts unter IPv6 auch Ports wie 80 und 443, die die Fritze offen lässt?

Ich vermute mal der Anfrageweg ist wohl: IPv6-Gerät im LAN fragt auf IPv6-PiHole den DNS - der fragt dann Cache/Fritzbox/externen DNS nach und spätestens die Fritze biegt um nach IPv4?

Na - da hab ich wohl noch ordentlich Nachholbefarf...

Weißt Du wie das mit anderen Clients im LAN ist? Handys, Drucker, Linux-Clients, die QNAP selbst... ?

Wenn die alle hinter meinem Rücken mit IPv6 rumfuchteln bekomme ich das auf dem PiHole doch sonst gar nicht mit - oder?

Hallöchen,

ich habe inzwischen herausgefunden, dass die Domäne bei mir auch fritz.box heißt und man sie allem Anschein nicht umstellen kann. Conditional Forwarding funktioniert immer noch nicht, aber ich habe die /etc/hosts nun soweit voll geschrieben. Vielleicht liegt es am Ubuntu-LXC.

IPv6 habe ich aktiviert, weil ich die Vermutung hatte, dass sonst Anfragen am PiHole vorbei laufen, die ich doch gerne sehen würde. Ich habe den Eindruck, dass viele Clients zweigleisig fahren. Mein Win10-Laptop hat sogar 2 v6-IPs, die beide genutzt werden, obwohl ich nie irgendwo IPv6 konfiguriert hatte.

Jetzt sehe ich zumindest im PiHole wirklich alle DNS-Anfragen in meinem Netz und ich habe tatsächlich den Eindruck, dass es mehr sind als zuvor. Z. B. ist mir vorher nicht aufgefallen, dass sich die QNAP stündlich mit Github verbindet. Vielleicht um nach App-Updates zu schauen?

Ich beobachte mal ne Weile.

Liebe Grüße und einen schönen Abend in die Runde,

Marco

Danke für die schnelle Antwort.

Was die lokale Domäne betrifft bin ich mir unsicher, ob sie nach Anpassen der IPv6-Einstellungen der Fritzbox immer noch fritz.local heißt.

Ich habe keinen Weg gefunden, um sie zu ermitteln oder in der Fritze einzustellen.

Hätte mir jemand einen Tipp?

Grüße,

Marco

Lieber Hassan,

sorry - ich hab nicht mitbekommen, dass Du gepostet hast.

Brauchst Du die Config noch?

Liebe Grüße,

Marco

Ergänzung:

Aus aktuellem Anlass habe ich meine Reverse-Proxy-Konfiguration erneut angepasst, weil interessanterweise gerade Safari-Clients SSL-verbundene Seiten nicht korrekt angezeigt haben. Für Safari bzw. Apple-Clients ist es wichtig, in den globalen SSL-Parametern z. B. in der default-Konfigurationsdatei (sie liegt in /etc/nginx/sites-available/default) von NGINX folgendes im listen 443 ssl -Block einzutragen:

ssl_session_cache shared:SSL:50m;

Ich hoste auch Mattermost, weshalb hier 50m angemessen sind, andernfalls reichen auch 10m.

Liebe Grüße

Ich hab's jetzt auch mal in nem LXC-Container zum Laufen bekommen. Ich dachte, das ist leichter zu pflegen.

Aus Gewohnheit habe ich den Ubuntu-LXC in Version 16.04 aufgesetzt.

Was ich auch nach Stunden nicht hinbekommen habe ist, dass das Conditional Forwarding vernünftig funktioniert. Die IPv6-Filterung habe ich am laufen und den IPv6-DNS auf der Fritzbox zum PiHole weitergeleitet.

Außerdem habe ich wie zuvor die IP der Fritzbox beim conditional forwarding eingetragen und auch wie zuvor die domain fritz.local

Hat das bei Euch geklappt?

Ich habe dann sowohl IPv6 als auch IPv4-Adressen in der /etc/hosts Datei eingetragen - was aber wenig elegant ist.

Es grüßt,

Marco

Das mit nem LCX-Container habe ich jetzt erst verstanden.

Da hat man ja ratzfatz quasi ein vollständiges vorinstalliertes Betriebssystem in einem Container zum Losbasteln - nix langes Installieren einer VM aus einem Image heraus

Meine Güte - von Euch lernt man Sachen! Weltklasse! Ich bin völlig begeistert!

Sorry - ist vielleicht of-topic...

Na da bin ich zumindest nicht allein mit dem Problem.

Ich betreibe auch den aktuellen Container /pihole/pihole in der Version 4.2 und er läuft - wie ich finde - toll performant und solide auf meiner TS-253A.

Mit den Rechten hatte ich auch schon ein wenig rumexperimentiert - leider auch erfolglos. Da allerdings auch wenige Einstellungen vorgenommen werden müssen, weil ich recht viel schon beim Erstellen des Containers übergebe, ist das Neuaufsetzen wirklich in 5 Min. erledigt. Einzig die Blocklist muss ich kurz einlesen und das Conditional Forwarding auf fritz.local stelle ich dann noch ein.

Falls jemand den Dreh mit ausgelagerten Config-Files raushat, gerne melden

Grüße,

Marco

Jogybaer - zur besseren Filterung solltest Du noch weitere Filterlisten hinzufügen (settings -> blocklists). Du findest gute Anregungen weiter vorne in diesem Thema.

Zum Docker-Betrieb hätte ich auch noch eine Frage.

Wie zuvor beschrieben, habe ich den Container nun wunderbar per Konsolenbefehl erstellt und zum Laufen gebracht (siehe früherer Post).

Was mir aber nicht gelingen will ist, die Konfigurationsdateien - sprich den Ordner /etc/pihole/ erfolgreich extern einzubinden. Der Dockerbefehl -v ... bindet zwar einen von mir zugewiesenen Ordner außerhalb des Containers ein und greift auf diesen zurück - im Logfile vom PiHole bekomme ich aber immer "permission denied" errors bei den Konfigurations-Dateien:

Feb  9 18:14:14 dnsmasq[322]: failed to load names from /etc/pihole/local.list: Permission denied
Feb  9 18:14:14 dnsmasq[322]: failed to load names from /etc/pihole/black.list: No such file or directory
Feb  9 18:14:14 dnsmasq[322]: failed to load names from /etc/pihole/gravity.list: Permission denied

Ich habe zuvor natürlich den Ordner /etc/pihole/ aus dem Container rauskopiert, verschoben und danach einen neuen Container mit zusätzlicher -v Verlinkung zum /etc/pihole "draußen" angelegt.

Klappt trotzdem nicht

Auch die Optionen "--privileged" und "--cap-add=FOWNER" habe ich schon probiert.

Wenn ich mir die Rechte anschaue, die local.list gehört admin:administrators.

Hat mir jemand einen Tipp?

Liebe Grüße,

Marco

Den DNS habe ich in der Fritzbox gesetzt.

Mir geht es nicht um Performance, die ist toll. Mir geht es darum, dass neue Clients bei Anfragen nicht auf IPV6 ausweichen können, sondern dass alles über den PiHole läuft. Oder kann ich das auch komplett in der FB unterbinden?

Liebe Grüße, Marco

Ich habe es hinbekommen. Das Posting und den Erstellungsbefehl für den Docker-Container habe ich oben entsprechend geändert.

Hallo,

vielleicht ist mein Docker-Befehl, wie ich ihn jetzt mal ins Laufen gebracht habe auch für andere interessant:

docker run -d --name pihole \
--restart always \
--net=qnet-static-eth0-a1b2c3 \
--ip=192.168.178.3 \
--mac-address 02:42:AC:C4:41:4E \
-p 80:80 -p 443:443 -p 53:53/tcp -p 53:53/udp \
--hostname pihole \
--cap-add=NET_ADMIN \
--dns=127.0.0.1 \
--dns=192.168.178.1 \
--memory=512M \
--cpus=1 \
-v /share/Container/PiHole-Konfigurationsfiles/etc/resolv.conf:/etc/resolv.conf \
-v /share/Container/PiHole-Konfigurationsfiles/log/pihole.log:/var/log/pihole.log \
-e ServerIP="192.168.178.3" \
-e ServerIPv6="fd00:0:0:0:111:1fff:f111:111F" \
-e IPv6="true" \
-e TZ="Europe/Berlin" \
-e WEBPASSWORD="" \
--dns=127.0.0.1 \
--dns=9.9.9.9 \
-e DNS1="192.168.178.1" \
-e DNS2="9.9.9.9" \
pihole/pihole:latest

Das Auslagern aller Konfigurationsfiles hat wegen Rechteproblemen zunächst nicht geklappt. Ich schätze, wenn ich ein Update des Containers mache bzw. einen aktuellen erstelle, ziehe ich mir den /etc/pihole-Ordner direkt aus dem Container an eine andere Stelle des NAS und binde es dann mit "-e" ein.

Allerdings fällt mir auf, dass der Container keine IPV6 erhält und ich dadurch auch recht schwer eine IPV6-DNS-Filterung hinkriege, wie z. B. hier:

https://adminforge.de/dns/pi-hole-ipv6-und-die-fritzbox/

beschrieben.

Habt ihr das hinbekommen?

Grüße, Marco

Wo ihr gerade so schön online seit - weshalb setzt du das --ulimit nofile ausgerechnet auf diesen Wert, lässt aber sonstige Ressourcen unbeschränkt?

Toll!

So langsam kommt Licht in das Dunkel meines Netzwerkverständnisses.

Ich dachte, PiHole übernimmt die Rolle des DNS komplett. Sorry- Denkfehler.

Danke für die ausführliche Antwort!

Grüße, Marco

Hallo,

ich versuche auch gerade einen PiHole im Docker auf meiner 253A aufzusetzen und würde natürlich wenn möglich gerne das aktuelle Repository benutzen.

Weite Teile der tollen Docker-Generierung von skoeber sind mir klar - ein paar Fragen hätte ich aber doch noch:

docker network create -d qnet --ipam-driver=qnet --ipam-opt=iface=eth1 --subnet=192.168.178.0/23 --gateway=192.168.178.1 qnet-static-eth1-a1b2c3
docker run -d --ulimit nofile=90000:90000 --name pihole --restart always --net=qnet-static-eth1-a1b2c3 --ip=192.168.178.7 --hostname pihole --dns=127.0.0.1 -v /share/NASext/container-data/pihole:/etc/pihole -v /share/NASext/container-data/pihole/log/pihole.log:/var/log/pihole.log -e ServerIP="192.168.178.7" -e IPv6="False" -e TZ="Europe/Berlin" -e WEBPASSWORD="" -e DNS1="192.168.178.1" -e DNS2="9.9.9.9" pihole/pihole:latest

Wenn ich es recht verstehe generierst Du erst eine neue Netzwerkbrücke für Docker. Das gateway im Subnetz setzt Du auf 192.168.178.1, was bei mir auch Sinn gäbe, denke ich, weil es die IP meiner FritzBox ist.

Andererseits ist das generierte Subnetz genau das Netz, das auch der DHCP meiner Fritzbox für mein LAN (derzeit rund 14 Geräte) vergibt

Beim Erstellen des PiHole-Containers setzt Du anschließend den ersten DNS-Server auf die 192.168.178.1, was bei mir wiederum die Fritzbox wäre. Da ich bei ihr ja gerade den PiHole als DNS eintragen würde, würde ich so doch einen Zirkel generieren, was letztlich vermutlich immer zum Fallback DNS2 führen würde - oder?

Stimmen meine Überlegungen und wie organisiert man das geschickt? Befindet sich dein LAN komplett außerhalb des 192.168.178.0/23er-Netzes? Ist es zweckmäßig, den PiHole aus dem LAN rauszuziehen, lässt man ihn gescheiter drin oder spielt das keine Rolle?

Für Tipps wäre ich dankbar.

Grüße, Marco

Liebe QNAP-Helden,

ich habe ein komisches Phänomen, bei dem ich nach vielen Stunden Fehlersuche doch den Rat der Helden suchen möchte.

Bislang konnte ich prima per Skript WebDAV-Freigaben SSL-verschlüsselt von Windows7 aus nutzen, seit ein paar Tagen geht es plötzlich nicht mehr, obwohl ich am Setup nichts verändert habe. Komisch - oder?

Hat sich inzwischen erledigt! -> siehe nächster Beitrag <-

Sorry für die Umstände und liebe Grüße,

Marco

Edit:

Man glaubt es nicht - wie blind muss man sein???

Aus irgendeinem Grund hat die QNAP ohne mein Zutun den https-Port des Webservers von 443 auf 8081 umgestellt. Damit WEBDav über nginx und https nach draußen richtig läuft, muss allem Anschein nach auch intern per https umgeleitet werden.

Das funktioniert natürlich nur dann, wenn die interne Umleitung auch den richtigen Port - in meinem Fall den Standardport 443 - anspricht, was andernfalls natürlich in's Leere läuft.

Prinizipiell logisch, aber komm' mal drauf, dass die QNAP den Port selbständig umstellt. Das scheint eine Folge des letzten Firmware-Updates gewesen zu sein, mit der ich nicht gerechnet habe.

Fall gelöst - vielleicht für andere hilfreich, lieber Admin, falls ihr den Beitrag löschen möchtet - Gerne!

Danke trotzdem an alle, die den Beitrag gelesen haben!

Keep QNAPPING